Ich habe festgestellt, dass die Schreibsperre der ReentrantReadWriteLock bietet eine isHeldByCurrentThread() Methode, um zu überprüfen, ob der aufrufende Thread diese Sperre hält.Warum gibt es keine Möglichkeit zu überprüfen, ob der aktuelle Thread die Lesesperre von ReentrantReadWriteLock enthält?
Aber es gibt keine entsprechende isHeldByCurrentThread() Methode für die Lesesperre. Warum nicht?
Ich denke, die Antwort ist in dem Kommentar von Doug Leas, dass er für diese Ausgabe gab: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6207928.
Doug Lea schreibt:
Das aktuelle Design und Verhalten vorsätzlich begangen werden. Read-Locks sind normalerweise nicht so definiert, dass sie Eigentümer sind, daher kann der Besitz nicht getestet werden. ... Der JSR166 EG hat einige Anfragen erhalten, um die Lese-Halte-Verfolgung pro Thread optional zu unterstützen. Dies würde den Sperraufwand beträchtlich erhöhen und müsste daher durch einen optionalen Konstruktionsparameter geregelt werden. Wir untersuchen es.
ReentrantReadWriteLock.getReadHoldCount() scheint den Job zu erledigen.
Solange Ihr Code nicht reentrant readlocks tut, wird dies funktionieren – Renan
Nein, tut es nicht. Angenommen, ThreadA hat die Lesesperre erhalten. Die Anzahl ist jetzt 1. Bevor ThreadA die Sperre aufgibt, verlässt sich ThreadB auf getReadHoldCount()> 0 und gibt den "geschützten" Code ein. Jetzt gibt ThreadA a die Sperre frei, aber ThreadB befindet sich immer noch im geschützten Code. ThreadC kommt ins Spiel, erwirbt eine Schreibsperre, ruft sie ab (weil die Leseranzahl gleich Null ist) und aktualisiert einige Daten. -> ThreadB sieht inkonsistente Daten. – Heri
Ok, ich habe verstanden. Trotzdem habe ich erwartet, dass es eine Möglichkeit gibt, zu überprüfen, ob der aktuelle Thread die Lesesperre von ReentrantReadWriteLock enthält. – rollaeriu360