問題タブ [blockingqueue]

以下の擬似コードにはpoll()、メインスレッドで永久に呼び出される関数があります。sleep()のステートメントなしでこれを行うとpoll()、他のスレッドによって1分間に2〜3個のアイテムのみがキューに追加されます。これは、ポーリングがput()ステートメントをブロックすることを意味しますか？

どうすればこの問題を解決できますか？

Swing を使用して Java でアプリケーションを作成しましたが、現在は C++ で書き直そうとしています。Java のプログラムには、イベントの Model、View、および BlockingQueue への参照を持つ Controller がありました。View で何かが発生すると、新しいイベントが BlockingQueue に入れられ、Controller と Model によって処理されました。次に、SwingUtilities.invokeLater() によって Swing で何らかのアクションが呼び出されました。

Qt を使用して C++ でこのようなことを行うにはどうすればよいですか? モデルを作成しましたが、Java の BlockingQueue などを介して Qt で作成された UI に接続する方法がわかりません。

Quartz フレームワークのジョブに BlockingQueue を渡す方法はありますか? BlockingQueue を渡すために JobDataMap を使用しようとしましたが、うまくいかないようです。関連するコードフラグメントは次のとおりです。

おそらく誰かがこれを達成する方法について考えを持っています。

ArrayBlockingQueueとLinkedBlockingQueueのソースコードを調べていました。LinkedBlockingQueueには、挿入と削除のためにそれぞれputLockとtakeLockがありますが、ArrayBlockingQueueは1つのロックのみを使用します。LinkedBlockingQueueは、シンプル、高速、実用的な非ブロッキングおよびブロッキング並行キューアルゴリズムで説明されている設計に基づいて実装されたと思います。このホワイトペーパーでは、デッドロックシナリオを回避するために、エンキューアがヘッドにアクセスする必要がなく、デキューアがテールにアクセスする必要がないように、ダミーノードを保持していると述べています。ArrayBlockingQueueが同じアイデアを借用せず、代わりに2つのロックを使用するのはなぜだろうと思っていました。

これは、クラスターを介したストリーム処理のためにノード化された処理にタプルを発行するための入力スパウトのコード スニペットです。問題は、 BlockingQueue が InterruptedException をスローしていることです。

例外の説明は次のとおりです:---

java.lang.InterruptedException10930 [Thread-20] INFO backtype.storm.util - 非同期ループが中断されました!

そして nextTuple(InputStreamSpout.java:65 は ------>

ありがとう

Java でプロデューサー/コンシューマー パターンを作成しようとしています。私は、一連の異なる接続を介して多くのサーバーに接続されているネットワーク クライアントです。サーバーはさまざまな「作業」パケットを生成し、それらはすべて 1 つのブロッキング キューに入れられます。私がやろうとしているのは、特定の種類の作業パケットのみが特定の消費者に配信されるように、消費者をブロックすることです。

例：

• ブロッキング キューは、A、B、C の 3 種類のワーク パケット オブジェクトで満たされます。
• 2 つのコンシューマーがワーク パケット オブジェクトを待機しています。コンシューマ 1 はタイプ A のみを必要とし、コンシューマ 2 はタイプ B または C のみを必要とします

java.util に標準クラスはありますか? それとも独自のクラスを作成する必要がありますか? また、必要に応じて自分でロールする最良の方法は何ですか?

前もって感謝します！

アンドリュー・クロファス

エントリの結合を可能にする java.util.concurrent.BlockingQueue の効率的な (すべてを同期することなく) 実装はありますか?

結合とは、着信アイテムをキュー上の既存の「等しい」エントリ (存在する場合) とマージすることを意味します。それ以外の場合、アイテムは通常どおり最後に追加されます。

StackOverflowの助けを借りた後、私は以下に実装したソリューションを見つけました。

問題文：-

各スレッドはUNIQUE ID毎回使用する必要があり、60 minutesそれ以上実行する必要があるため60 minutes、すべてID'sが終了する可能性があるため、それらを再利用する必要がありID'sます。だから私はArrayBlockingQueueここでコンセプトを使用しています。

2つのシナリオ：-

1. command.getDataCriteria()が含まれている場合、Previous各スレッドは常にUNIQUE ID間で使用1 and 1000し、再利用するために解放する必要があります。
2. それ以外の場合、command.getDataCriteria()が含まれている場合、New各スレッドは常にUNIQUE ID間で使用2000 and 3000し、再利用するために解放する必要があります。

質問：-

私が今気づいた奇妙なことの1つは、以下のelse ifループで、runメソッドに以下のコードが表示されている場合、command.getDataCriteria() is Previousそれが入力されてelse if block(which is for New)いること.equals checkです。なぜこれが起こっているのですか？

以下は私のコードです：-

アップデート：-

私が今気づいた奇妙なことの1つは、以下のelse if loop場合、command is Previousそれが正しく発生してはならない他のifブロックにも入力されているということです。なぜこれが起こっているのですか？なぜこのようなことが起こっているのか分かりませんか？

キューを実装する必要があり（によって実行されるNSMutableArray）、Producerキューにデータを追加するオブジェクトがある場合。1つのプロデューサーまたは複数のプロデューサーが存在する可能性があります。また、キューがいっぱいの場合（たとえば、サイズが100の場合）、スレッドを「ブロック」する必要があります（キューが実際に100アイテムよりも小さいサイズになるまで待機します）。（キューからデータを取り出す場合も同様です。データが空の場合、データの取得もブロックされます）。

この「ブロッキング」はどのように実装できますか？今はMutexを使っています

NSMutableArrayのカウントが取得され、アイテムの追加が一緒に行われるようにします（カウントは99になる可能性がありますが、アイテムが追加されると、カウントはすでに異なる可能性があるため）。

しかし、ブロッキング効果については、実際にカウントを確認し、100の場合は、ロックを解除して0.1秒間スリープしてから、もう一度ロックを取得してカウントを取得し、上記のように繰り返します。

これは「ブロッキング」動作を実装するための良い方法ですか？canAddNowLockメカニズムによって単純にブロックされているを取得する別の方法があるようですNSLock。キューアイテムが削除されたら、これを解放しますcanAddNowLockが、複数のデータプロデューサーとデータコンシューマーが存在する可能性があるため、複数のプロデューサーがブロック解除された場合、または複数のコンシューマーcanAddNowLockが連続してロックを解除し、1つのプロデューサーのみがブロック解除された場合（実際には複数のプロデューサーがブロック解除されるべきである場合）はどうなりますか？そうすれば、もっと複雑なデザインのように見えます。

私が取り組んでいるロギング機能では、ジョブを待機し、カウントが特定の数に達するか超えたときにバッチで実行する処理スレッドが必要です。これはプロデューサ コンシューマの問題の標準的なケースなので、 BlockingQueuesを使用するつもりです。add()メソッドを使用してキューにエントリを追加する多くのプロデューサーがいますが、キューで待機するためにtake()を使用するコンシューマー スレッドは 1 つしかありません。

LinkedBlockingQueueはサイズ制限がないため、適切なオプションのようですが、ドキュメントからこれを読んで混乱しています。

通常、リンクされたキューはアレイベースのキューよりもスループットが高くなりますが、ほとんどの同時実行アプリケーションではパフォーマンスが予測しにくくなります。

この声明が何を意味するのかは明確に説明されていませんでした。誰かがそれに光を当ててくれませんか？LinkedBlockingQueue がスレッドセーフではないということですか? LinkedBlockingQueue を使用して問題に遭遇した人はいますか。

プロデューサーの数がはるかに多いため、追加される多数のエントリでキューが圧倒されるシナリオが常に発生する可能性があります。代わりに、キューのサイズをコンストラクターのパラメーターとして受け取る ArrayBlockingQueueを使用すると、容量がいっぱいになることに関連する例外が常に発生する可能性があります。これを回避するために、ArrayBlockingQueue をインスタンス化する必要があるサイズを決定する方法がわかりません。ArrayBlockingQueue を使用して同様の問題を解決する必要がありましたか?