問題タブ [reentrantlock]

このAPIから直接:

公平に構成されている場合、スレッドは近似到着順ポリシーを使用してエントリを競います。現在保持されているロックが解放されると、最も長く待機している単一の書き込みスレッドに書き込みロックが割り当てられるか、待機中のすべての書き込みスレッドよりも長く待機している読み取りスレッドのグループがある場合は、そのグループに読み取りロックが割り当てられます。

単一の書き込みスレッドを読み取りスレッドのグループと比較します。API が指定するスレッドのグループではなく、待機中のスレッドが 1 つしかない場合はどうでしょうか。

前もって感謝します。

このウェブサイトから直接:

しかし、新しい ReentrantLock オブジェクトを作成するときに公平性パラメーターを「true」に指定すると、最も長く待機しているスレッドが次にロックを取得することが保証されます。かなりいいですね。

スケジューラの決定に影響を与えるだけで、決して保証されるものではないと思いました。それまたは上記のリンク先のウェブサイトは実際に真実を言っているのではないですか?

前もって感謝します。

このAPIから次の点を取り上げました。次の 2 つの点の違いを知りたいです。

1. 待機中のスレッドは FIFO 順で通知されます。

2. 待機中のメソッドから戻るスレッドのロック再取得の順序は、スレッドが最初にロックを取得する場合と同じです。これはデフォルトのケースでは指定されていませんが、公平なロックでは、最も長く待機しているスレッドが優先されます。

Conditionこれは、通常 ReentrantLock メソッドによって返されるクラスに関連しており、引用したビットは、 Object クラスのメソッドと通常の監視メソッドの.newCondition()違いを説明しています。Condition

「待機中のスレッドは FIFO 順で通知されます」。が公平に作成されているlockかどうかにかかわらず、待機中のスレッドが FIFO の順序で通知されるという事実はまったく無関係だと思います。とにかく、それらがどのようにキューに入れられるかを決定するのは、それらが構築されたかどうか、公正かどうかです。

確認を求めるだけです。

前もって感謝します。

次の非常に単純なコードが機能しない理由..スタックします..明示的なロックjava.util.concurrent.locks.ReentrantLock;とそのnewCondition()メソッドを使用しようとしています。

これが私のコードです：

私は同じロックをロックしているので、動作するはずです...代わりに、メインスレッドが呼び出されるとブロックされますincrementVariable()。なぜ、このようなことが起こるのでしょうか？前もって感謝します。

ここでjdk 5 ReentrantLockの機能を（ある程度）理解しています

しかし、なぜ「再入可能」ロックが必要なのでしょうか? つまり、スレッドがすでにオブジェクトのロックを取得している場合、なぜそれを再度取得する必要があるのでしょうか?

ReentrantLock で "lock()" を呼び出していますが、明らかにすべきではないスレッドがスタックしてしまいます。

"lock()" の呼び出しの直前にブレークポイントを指定してデバッグすると、最初のスレッドがそこで停止し、プログラム ポインターが "Thread.exit()" に移動していました。ロック オブジェクトの toString() は「ロック解除済み」と表示され、その「状態」属性は「0」です。動作は常に同じではありません。最初のスレッドが期待どおりにロックを通過することがあります。