問題タブ [reentrantreadwritelock]

ReentrantReadWriteLock多数の異なる読み取りおよび書き込み操作を持つかなり複雑なデータ構造へのアクセスを制御しようとしているときに、いくつかの密接に関連する質問がポップアップしました。ドキュメントの例に従って、読み取りロックと書き込みロックをフェッチし、それらを使用して (私が知る限り) このデータ構造への同時アクセスを正常に管理しています。ただし、別の問題をデバッグしているときに、同じスレッドで複数の読み取りロックを取得する場合があることに気付きました。これの基本的な理由は、単純なクエリを呼び出す複雑なクエリが多数あるためです (以下の例を参照)。複雑なクエリはトランザクションと考えることができます。つまり、 と へのgetVersion()アクセスの間に書き込みがあってはなりませんdatamyQuery. この現在の解決策は機能しますが、コード内のいくつかの場所で、同じスレッドが複数の読み取りロックを所有することになります。同等の書き込みにはisHeldByCurrentThread()メソッドがあることに気付きましたが、これは奇妙なことに にはありませんreadLock。以下のことがわかりませんでした。

• 同じスレッドに複数の読み取りロックを設定するのは悪いことですか (スタイル、パフォーマンス、または将来のバグのリスク)?
• エラーをチェックするために使用WriteLock.isHeldByCurrentThreadするのは不適切ですか (たとえば、書き込みロックを期待しているが何も存在しない、または書き込みロックを解放する条件として)?
• これが問題である場合、どのように進めるかを決定するためのベストプラクティスはありますか? lockedAquired既にロックを所有しているコードから呼び出される可能性のあるメソッドにブール値を渡すか、それらが一意に取得されるようにするか、または使用する必要がありますReadLock.tryLock()か?

コードサンプルは次のとおりです。

ReentrantReadWriteLockドキュメントでは次のように述べられています。

私が正しく理解していれば、同じスレッドから実行できることを意味します：

これは理にかなっています。すでにロックされている場合write、他のスレッドはロックされたコードに入ることができません。しかし、 をロックした場合、他のスレッドがロックを作成していない場合、同じスレッドでブロックにread入ることができないのはなぜですか? したがって、これは機能しません:writeread

同じスレッドでロックするread前にロックを解除する必要があるのはなぜですか?write

ロックを取得せずに Writer スレッドが不足しているという問題があります。次のコードを見てください。読み取りロックを使用してロックを取得しようとするとtryLock()、ライター プロセスが枯渇し、書き込みができなくなります。公平性があっても、ライター プロセスは完全に枯渇し、決して実行されません。代わりに、試してみるとreader.readLock()、ライタープロセスがロックを取得できます。

何か不足している場合はお知らせください。ライタープロセススレッドは、優先度が高く設定されていても、ロックを取得することはなく、ロックを待っている間にスタックします。

で使えるかどうか誰か教えてtrylock()くださいReadWriteLocks。

次のオブジェクトがあります。

次のブロックがあります。

ご覧のとおり、誰も何かを書き込もうとしていないときにスレッドがこのコードから読み取れるようにするために、このコードの一部をロックしました。

また、次のコードがあります。

さて、最初のコード ブロックが発生すると、2 番目のブロックは最初のブロックが完了するまで待機することを知っています。私の質問dataStructureは、次のコード ブロックで、誰かが書き込むと同時にオブジェクトから読み取ることができるかどうかです。または、ReentrantReadWriteLock ロックについて言及していないにもかかわらず、彼から読んでください。

前もって感謝します！