私は、ReentrantReadWriteLock
の書き込みロックが、起動中のスレッドがそのロックを保持しているかどうかを確認するためにisHeldByCurrentThread()
メソッドを提供することを発見しました。現在のスレッドがReentrantReadWriteLockの読み取りロックを保持しているかどうかをチェックする方法がないのはなぜですか?
しかし、対応する読み取りロックの方法はありません(isHeldByCurrentThread()
)。何故なの?
私は、ReentrantReadWriteLock
の書き込みロックが、起動中のスレッドがそのロックを保持しているかどうかを確認するためにisHeldByCurrentThread()
メソッドを提供することを発見しました。現在のスレッドがReentrantReadWriteLockの読み取りロックを保持しているかどうかをチェックする方法がないのはなぜですか?
しかし、対応する読み取りロックの方法はありません(isHeldByCurrentThread()
)。何故なの?
私はこの問題について彼が与えたDoug Leasのコメントに答えがあると思います:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6207928。
ダグ・リーは書いている:
現在の設計と動作が意図的です。読み取りロックは通常、所有権の概念を持つように定義されていないため、所有権はテストできません。 ... JSR166 EGは、スレッド単位の読み取り/保持追跡をオプションでサポートする要求をいくつか受け取りました。これを行うと、ロックオーバーヘッドが大幅に増加するため、オプションの構築パラメータで管理する必要があります。我々はそれを検討している。
ReentrantReadWriteLock.getReadHoldCount()はジョブを実行しているようです。
あなたのコードがリエントラントリードロックを実行していない限り、これは動作します – Renan
いいえ、それはありません。 ThreadAが読み取りロックを取得したとします。カウントは1になりました。ThreadAがロックを解放する前に、ThreadBはgetReadHoldCount()> 0に依存し、 "protected"コードを入力します。今度はThreadAがロックを解除しますが、ThreadBはまだ保護されたコードのままです。 ThreadCは動作し、書き込みロックを獲得し、それを取得し(リーダ数がゼロであるため)、いくつかのデータを更新する。 - > ThreadBは矛盾したデータを見る。 – Heri
わかりました。それにもかかわらず、現在のスレッドがReentrantReadWriteLockの読み込みロックを保持しているかどうかを確認する方法があると思いました。 – rollaeriu360