問題タブ [cyclicbarrier]

そこで、サイクリックバリアを使用してこのロボット クラスの複数のスレッドを実行し、スレッドを同期させるプログラムを作成しました。サイクリックバリアについてはほとんど理解していなかったので、スレッドが自動的に同期されると思っていましたが、そうではないようです。進行状況の整数値に基づいてロボット スレッドを同期するにはどうすればよいですか?

パブリッククラスコントローラー{

この方法で実装したい Java のスレッドのグループがいくつかあるとしましょう。各時点で実行できるスレッドのグループは 1 つだけで、他のグループはその順番 (周期的) を待つ必要があります。

どのようにそうすることをお勧めしますか?

私はJavaでcountdownLatchを使用する方法を学んでおり、コードで以下に示すように簡単な例を作成しました。

そのメカニズムについて私が学んだことは、1つのスレッドだけが他のスレッドが作業を完了するまで待機するように強制する方法であり、待機していたスレッドは、他のスレッドが終了するとジョブを開始します.

私の質問は、4 つのスレッド 't1、t2、t3、および t4' があり、それらが記載されている順序で開始され、先頭/前のスレッドが終了したときに各スレッドが開始する必要がある場合です。つまり、t2 は t1 を待って t1 が終了したときに開始し、t3 は t2 を待って t2 が終了したときに開始し、t4 は t3 を待って t3 が終了したときに開始します。

1-CountDownLatch と循環バリアを使用してこれを行う方法は?

2- CountDownLatch クラスのコンストラクタに渡される countDown パラメータは、待機しているスレッドの数を表す必要がありますか?

コード:

}

スレッドを開始する次のメソッド テストがあります。

CallBack スレッドは次のようになります。

アプリケーションを実行すると、次の出力が表示されます。

アプリケーションがハングします。

理由がわかりません。

結合ロジックをメインメソッドに置き換える場合 - すべての商品がうまくいきます。

この違いを説明できますか。
私見それは同じように動作するはずです。

ビジネスケースを Cyclic Barriers の使用法にマッピングしようとしています。プロモーション オファーが進行中で、3 人の顧客のみがプロモーション オファーを取得できるとします。残りはオファーを受けません。

このシナリオをマッピングするために、Cyclic Barrier を利用しました。コードは機能していますが、一部の顧客がオファーを受けられないというシナリオをどのように処理すればよいかわかりません。今、タイムアウト値を指定して await() API を使用しようとしました。これにより、TimeoutExceptionをキャッチして、プロモーション オファーを利用できないことを顧客に知らせることができます。これにより、別の待機中のスレッドでBarrierBrokenExceptionが発生しました。

選択した顧客がプロモーション オファーを利用できる一方で、別のコード パスをたどることができなかった顧客など、これらのシナリオを適切に処理するにはどうすればよいか知りたいです。

私のコード -

実行の 1 つからの出力 -

• スレッド 1 プロモーション オファーを取得しようとしています!
• スレッド 4 プロモーション オファーを取得しようとしています!
• メインスレッドが完了しました
• スレッド 3 プロモーション オファーを取得しようとしています!
• スレッド 2 プロモーション オファーを取得しようとしています!
• スレッド 5 プロモーション オファーを取得しようとしています!
• トップ 3 のバリアに到達しました。彼らはプロモーション オファーを受け取ります!
• スレッド 2 はプロモーションオファーを受け取りました!
• スレッド 1 がプロモーションのオファーを受け取りました!
• スレッド 5 はプロモーションオファーを受け取りました!
• タイムアウト例外のため、スレッド 3 はプロモーション オファーを取得できませんでした
• バリア例外のため、スレッド 4 はプロモーション オファーを取得できませんでした

調整された方法のシナリオで CyclicBarrier と共に join() を使用する方法について詳しく学ぼうとしました - 送信と受信。基本的なコードは以前のポスターのもので、特定のループ アカウント (例: 10 回) を実行するように変更しました。コードは次のとおりです。

ただし、解決できなかった結果に遭遇し、await() のロジックとほとんど混乱していません。結果は予想通りのようですが、SENDとACKが交互に10回。実際には SEND で余分な時間を実行し、10 回目の -ACK 実行でステータス Sender.stop を true 状態に変更しても、Send-run() の while ループが「停止」しなかったようです。また、スレッドは10回（または11回）後に終了しなかったため、main（）で「終了しました..」出力に入ることがありませんでした。プロセスがどこかでハングしているように見えました。