3

1）昨日だけ私はこの質問をしました条件対待機通知メカニズム

2) 同じものを編集して質問にいくつかの if を追加したかったのですが、煩雑になり、読者の興味をそそったり困惑させたりするのに十分なテキストが含まれていた可能性があるため、ここで新しい質問をすることを考えました。

3) ポイント番号 1) で URL が指定されている私の投稿のコンテキストで、単一のデータ構造「S」で動作する P1、T1 および P2、T2 の 4 つのスレッドのケースを考えてみましょう。

4) 待機通知よりも Condition インターフェースを使用する利点を再び引き出すことを試みています。

5) コードを検討する

final Lock lock = new ReentrantLock();
Condition c1 = lock.newCondition();
Condition c2 = lock.newCondition();
Condition c3 = lock.newCondition();
Condition c4 = lock.newCondition();

6) (標準の await()/signalAll() の方法で) c1,c2 を使用する P1,T1 を検討してください。P2、T2 がそれぞれ put、take、put1、take1 メソッドとしましょう。

7) c1.signalAll() を実行すると、条件 1 で待機しているスレッドだけがシグナルを受信します。私は理にかなっていますか？

8) 同じ発言を実装するための待機/通知メカニズムを検討してください。

private static final Object lock= new Object();
synchronized(lock)

put、take、put1、take1 を考えてみましょう。したがって、いずれかのスレッドが条件を満たす条件のいずれかで lock.notifyAll() を実行すると、他の条件のために待機中のスレッドでも通知を受け取ります。本当 ？。これは、条件メカニズムで待機/通知を使用することの欠点として数えることができるものですか?

4

1 に答える 1

6

はい、あなたは正しいです。このクラスは、組み込み条件キュー ( 、 、およびConditionによって制御されるもの) の一般化です。Object.waitObject.notifyObject.notifyAll

Brian Goetz の Java Concurrency in Practice [p.306-307] を引用します。

固有条件キューには、いくつかの欠点があります。各固有ロックには関連付けられた条件キューを 1 つだけ持つことができます。つまり、BoundedBuffer のようなクラスでは、複数のスレッドが同じ条件キューで異なる条件述語を待機する可能性があり、ロックの最も一般的なパターンには、条件キュー オブジェクトの公開が含まれます。これらの要因により、notifyAll を使用するための均一なウェイター要件を適用することができなくなります。複数の条件述語を持つ並行オブジェクトを作成する場合、または条件キューの可視性をより詳細に制御する場合は、明示的な Lock クラスと Condition クラスを使用すると、固有のロックと条件キューに代わるより柔軟な方法が提供されます。

条件キューが単一の固有ロックに関連付けられているのと同様に、条件は単一のロックに関連付けられています。[...] そして、Lock が固有のロックよりも豊富な機能セットを提供するのと同様に、Condition は固有の条件キューよりも豊富な機能セットを提供します: ロックごとの複数の待機セット、割り込み可能および割り込み不可能な状態の待機、期限ベースの待機、および公平または不公平なキューイング。

于 2012-06-30T07:04:47.490 に答える