問題タブ [reentrantreadwritelock]

reentrantReadWriteLock を適用し、それがロックされている場合、別のスレッドが既に別のブロックを実行している間に別のスレッドが Lock にアクセスするとどうなりますか? (したがって、.unlock に到達する前に)

メソッドはキャンセルされますか？それとも止まっているのでしょうか？:O

この質問からReentrantReadWriteLock の「不公平な」モードを理解する方法は? 、どのスレッドが先に来ても、すべてのスレッドがロックを取得する機会は同じだと思います。

だから私はそれをテストするためにこのコードを書きます：

最初に、スレッドが書き込みロックを取得し、それを 3 秒間保持しました。この間、1 つのスレッドが読み取りロックを取得しようとし、次に 1000 のスレッドが書き込みロックを取得しようとします。

ReentrantReadWriteLock はデフォルトで非公平モードを使用するため、書き込みスレッドが書き込みロックを取得する絶好の機会があると思います。しかし、私はそれを何度も実行し、そのたびに読み取りスレッドが勝ちました!

出力は次のとおりです。

「不公平」の理解は間違っていますか？

更新 paxdiabloの回答に従って、コードを次のように変更しました。

現在、書き込みロックを必要とするスレッドがあり、1000 の読み取りスレッドが読み取りロックを必要としています。しかし、出力は次のとおりです。

まだ「先着順」のようです。

ロックを作成するメソッドがあります。

次に、このオブジェクトをLockInterfaceを使用するメソッドに渡します。

メソッド内では、次のようにします。

私がやろうとしているのは、現在のスレッドが一度に保持する読み取りカウントの数を取得することです。そのためのラッパーを作成しましたが、私の問題は、ReadLock（）メソッドがReentrantReadWriteLock.WriteLockを返すため、後でgetThreadReadLockCountを取得します。必要なのは、readLock（）メソッドが返してくれるので、countメソッドを超過できるようにすることです。何か案は。？

私は持っていReentrantReadWriteLockます。にはReentrantReadWriteLock、サブクラスとして ReadLock と WriteLock が含まれています。

次に、以下のようなことができる必要があります

また

これを達成することは可能ですか？

リーダー書き込みの問題を解決するには、 を使用しようとしますReentrantReadWriteLock。すべてのリーダーが同時に読み取りロックを取得できることはわかっていますが、書き込みロックはすべての読み取りロックが解放されるまで待機する必要があります。多くの読者がいる場合、ライターは飢餓状態になりますか?

書き込みロックを保持しているスレッドから ForkJoinPool または ParallelArray にタスクを送信したいと考えています。ドメイン モデルへのアクセスは、現在のスレッドが関連するロックを保持していることを確認することで保護されます。FJ ワーカーがタスク (読み取り専用、クエリなど) を実行できるようにするには、それらを生成したスレッドにアクセス チェックを委任する必要があります。

生成スレッドへの参照を使用して、ForkJoinWorkerThread をサブクラス化しました。次に、ReentrantReadWriteLock をサブクラス化し、isWriteLockedByCurrentThread をオーバーライドして通常のチェックを実行し、スレッドがデリゲート FJWorker のインスタンスである場合は、ReentrantReadWriteLock#getOwnerを使用して、デリゲート スレッド (親) がロックの所有者であることをチェックします。 () :

ただし、getOwner() のドキュメントには次のように記載されています。

このメソッドが所有者ではないスレッドによって呼び出された場合、戻り値は現在のロック ステータスのベスト エフォート近似を反映します。たとえば、ロックを取得しようとしているがまだ取得していないスレッドがある場合でも、所有者が一時的に null になることがあります。

これは、既にアクセスが許可されているスレッド内でタスクを送信した場合、このメソッドがそのスレッドへの参照を正しく返すことを意味することを理解したいと思います。残念ながら、これは暗示されていません。

この方法を使用できない場合、この種の委任には他にどのような方法がありますか?

ありがとうございました。

ReentrantReadWriteLockJavaは API バージョン <9 と >=9 で異なることに気付きました。私にとって特に重要なのは、この方法getReadHoldCount()が古いバージョンでは利用できないことです。

ここで私の質問は、このメソッドを使用せずに現在のスレッドが ReadLock を保持しているかどうかを検出するにはどうすればよいですか? 手動カウンターまたはラッパー クラスの可能性しか見えませんが、これを実現する組み込みの方法はありますか?

このコンストラクターが無期限にハングする理由は何ですか? スレッドセーフなシングルトンを作成しようとしています。

ところで、静的なゲッターにロックを配置する方が良いかもしれません。コンストラクターでロックを使用することが本質的に間違っているかどうかを知りたいだけです

以下は、典型的なリーダーとライターのパターンです (読み取りが多く、書き込みが少ない)。

ライターとリーダーを優先することは可能ですか？たとえば、通常、ライターは、他のスレッドによって保持されている読み取りロックが常に保持されている場合、非常に長い時間 (おそらく永遠に) 待機する可能性があるため、より高い優先度のライターを使用することは可能ですか?優先度の高い（スキップライン）そのようなもの。