問題タブ [producer-consumer]

2つのバッファがあるとしましょう。プロデューサーはバッファー＃1を満たし、次にバッファー＃2を満たします。コンシューマーは一度に1つのバッファーを消費し、非常に低速です。バッファー＃1を消費している間、プロデューサーは別のバッファーをいっぱいにする準備ができていますが、それらはすべていっぱいであり、コンシューマーはまだ＃1を終了していません。それで、プロデューサーは待ちます。

待つのではなく、プロデューサーに「空き」バッファーを更新してもらいたい。つまり、コンシューマーがバッファー＃1を消費している間、プロデューサーはバッファー＃2の準備ができたらすぐに新しいデータをバッファー＃2に書き込む必要があります（「古い」データは上書きされて失われます）。コンシューマーがまだ＃1を終了しておらず、プロデューサーが書き込むデータがさらにある場合は、 ＃2に再度書き込む必要があります。コンシューマーが最終的に＃1のすべてのデータを消費すると、すぐにバッファー＃2に新しく書き込まれたデータの消費を開始し、プロデューサーは＃1を更新し続ける必要があります。

（プロデューサーがビデオフレームを高速でリアルタイムで取得し、コンシューマーがゆっくりと作成していると想像してください。コンシューマーは、一部のフレームをスキップしてもかまいませんが、最後に取得したフレームを常に処理する必要があります。代わりに、プロデューサーはできません。すべてのフレームを取得する必要があるため、速度を落とすか待つことはありません）。

セマフォでこの種のことを行う方法はありますか？それはよく知られている並行性の問題ですか？そして、場合によっては、この問題をn> 2個のバッファーに拡張することは可能ですか？

ありがとう！

私は ruby​​ openid 準拠のライブラリを使用しているので、openid コンシューマーになることができます。サンプルを取得し、サービスを開始しようとすると、次のようなエラーが表示されます。

任意のアイデアをいただければ幸いです、ありがとう

ブロッキング キューを備えた単一のプロデューサー/単一の消費者モデルを使用しています。プロデューサーが生産を終了したら、キューが空になるのを待ってから戻るようにしたいと思います。

ここで Marc Gravellが提案した BlockingQueue を実装しました。

私のモデルでは、プロデューサー (レンダラー) はイベントを使用して、ファイルがレンダリングされているとき (ワーカーがアイテムをキューに入れているとき)、およびすべてのファイルがレンダリングされたとき (終了したとき) にワーカー (プリンター) に通知します。

現在、レンダラーが完了すると、メソッドが終了し、ワーカーが強制終了されるため、印刷されていないレンダリング ファイルが 10 ～ 15 個残っています。

キューが空になるまで、たとえばすべてのファイルが印刷されるまで、終了イベント ハンドラをブロックしたいと考えています。キューが空になるまでブロックする「WaitToClose()」メソッドのようなものを追加したいと思います。

(違いを生むためにワーカースレッドを設定しIsBackground = trueますか?)

次のような単純な 1 プロデューサー/2 コンシューマー コードがありますが、出力C2は消費のみを示しています。コードにバグはありますか?

出力は次のとおりです。

複数のプロデューサー、単一のコンシューマーモデルを持つアプリケーションを作成しています（複数のスレッドが単一のファイルライタースレッドにメッセージを送信します）。

各プロデューサースレッドには2つのキューが含まれ、1つは書き込み用、もう1つはコンシューマー用のキューです。コンシューマースレッドのすべてのループは、各プロデューサーを反復処理し、そのプロデューサーのミューテックスをロックし、キューを交換し、ロックを解除して、プロデューサーが使用しなくなったキューから書き込みます。

コンシューマースレッドのループでは、すべてのプロデューサースレッドを処理した後、指定された時間スリープします。私がすぐに気付いたのは、プロデューサーがキューに何かを書き込んで戻るまでの平均時間が、1つのプロデューサースレッドから2に移動したときに劇的に（5倍）増加したことです。スレッドが追加されると、この平均時間は底に達するまで減少します。アウト-10人のプロデューサーと15人のプロデューサーの所要時間に大きな違いはありません。これはおそらく、処理するプロデューサーが多いほど、プロデューサースレッドのミューテックスの競合が少なくなるためです。

残念ながら、プロデューサーが5人未満の場合は、アプリケーションでかなり一般的なシナリオです。プロデューサーの数に関係なく、妥当なパフォーマンスが得られるように、スリープ時間を最適化したいと思います。スリープ時間を長くすると、プロデューサー数が少ない場合はパフォーマンスが向上しますが、プロデューサー数が多い場合はパフォーマンスが低下することに気付きました。

他の誰かがこれに遭遇しましたか？もしそうなら、あなたの解決策は何でしたか？スレッドの数でスリープ時間をスケーリングしようとしましたが、マシン固有であり、かなり試行錯誤のようです。

Cで複数の生産者/消費者問題を試みていますが、期待どおりに機能していません。以下は、私の実装を表すためのいくつかの擬似コードです。

ただし、このソリューションではdata1がいっぱいになりますが、thread2はロックされ、実行されません。私の実装に何か問題がありますか？

編集＃1

私が見つけた問題の1つは、2番目のミューテックスが正しく作成されていなかったことです。何が問題なのかわからないので、すべてのスレッドに最初のミューテックスを使用しています。それを機能させるために私が行った他のこともあるので、後でこれを反映するように擬似コードを更新します。

ユーザーが外部リソースへのリクエストをトリガーできるようにするWebアプリケーションがあります。外部リソースは、結果を収集するために不特定の時間を費やすため、更新を取得し、完了時に最終結果を収集するために、外部リソースをポーリングする必要があります。

ユーザーがリクエストをトリガーするとキューに追加され、ユーザーが他のことをしている間に、多数のワーカースレッドが各リクエストを取得してポーリングを実行するようにします。

日中のリクエスト数は大きく異なるため、遅いときに多くのワーカーが何もしないのはリソースの無駄になると考えられますが、同時に、ピーク負荷を処理するのに十分なワーカーが必要です。システム。

待機中のリクエストが多い場合はワーカーを追加できるものが必要ですが、やることがほとんどない場合はワーカーを強制終了します。

EJBを使用してこれを行うことは可能でしたが、使用したくありません。また、JMSやその他の大規模なフレームワークを使用してこれを処理することは、すでに使用しているもの（Spring、Quartz、多くのApacheのもの）でない限り、使用したくありません。

EJBはこれをサポートしており、そこで見つかったより便利な機能の1つであるため、誰かがすでにこの問題を解決していると思います。提案？

私にはプロデューサーとコンシューマーがいます。プロデューサーは特定の共有メモリ領域に固定サイズのアイテムを書き込み、コンシューマーはそれらを取得します。

プロデューサーは、ランダムに、コンシューマーよりも著しく遅いまたは速い場合があります。

私たちが欲しいのはそれです

1. プロデューサーがコンシューマーよりも高速に実行されている場合、循環バッファーがいっぱいになると、最も古いフレーム（もちろん、コンシューマーが消費しているフレーム以外）に書き込みを続けます。この点を強調します。プロデューサーとコンシューマーはで同期する必要があります。それらは無関係なプロセスであるため、ソリューション）。

2. 代わりに、コンシューマーがプロデューサーよりも速い場合は、新しいフレームを待機し、そこにあるときにそれを消費する必要があります。

循環バッファーを使用したプロデューサー/コンシューマーの実装を見つけましたが、最初のリクエストを尊重しなかったものだけです（つまり、循環バッファーがいっぱいの場合、コンシューマーが終了するのを待ちますが、必要なのは最も古いフレームを上書きすることです）。

私は自分自身の（バグが発生しやすい）ソリューションをロールバックしたくないのですが、事前に缶詰にされ、テストされたソリューションを使用します。誰かが私に良いCの実装を教えてもらえますか？（C ++も問題ありません）。

どうもありがとう。