問題タブ [producer-consumer]

プロデューサーとコンシューマーがいます。プロデューサーはその内部キューをオブジェクトで満たし、コンシューマーはこれらのオブジェクトを 1 つずつ受け取ります。オブジェクトの準備ができていないときに消費者がブロックするように、消費者を生産者と同期させたい、キューがいっぱいになったときに生産を停止するように生産者をそれ自体と同期させたい（スペースがあると再開する） . それ、どうやったら出来るの？を使用して、キューを使用せずに単純なケースを解決できましたが、キューを使用するNSConditionalLockと、問題はより複雑に見えます。

Boostスレッドと条件を使用して、基本的なスレッド化されたプロデューサー-コンシューマー（スレッド1 =プロデューサー、スレッド2 =コンシューマー）を実装しました。私はwait（）で無期限に頻繁に立ち往生しています。ここで何が悪いのか本当にわかりません。以下はいくつかの擬似コードです：

いくつかの追加情報：

• Boostv1.44の使用
• LinuxとAndroidで問題が発生しています。それがWindowsで起こるかどうかはまだわかりません

何か案は？

更新：私は問題を切り分けたと思います。確認したらさらに更新します。明日になることを願っています。

更新2：上記のコードに問題はないことがわかりました。私はAddToQueue（）の基盤となるAPIに依存していました-ワーカースレッドでデータを処理してAPIに戻すときに、AddToQueue（）を再度呼び出すという循環的なバグがありました...これは修正されました;-)

私はBlockingCollection生産者消費者パターンに を使用していますが、例外があり、特許を書いていると思います-グーグルでの結果は2つだけです! 期待は「CompleteAddingはコレクションへの追加と同時に使用できない可能性があります」であり、次のようにTryAddBlockingCollectionでiが発生した場合に発生します。

これCompleteAddingは Consumer-Producer ラッパー クラスの破棄時に呼び出されます。

マイクロソフトの誰かがアイデアを得ましたか? キャンセル後、CompleteAdding を呼び出す前にスリープ状態にする必要がありますか?

これは主に概念の理解に関するものであり、私を混乱させます。

ミューテックスとは、1つのスレッドが共有リソースのアクセスを制御し、操作を実行してロックを解除すると、他のスレッドのみがロックにアクセスできることを意味します。

バイナリセマフォは、スレッドが共有リソースにアクセスできるが、ロックにアクセスできるようなものですが、別のスレッドはロックを解除できます

私がここで見た最後の質問では、"semaphores are more suitable for some synchronization problems like producer-consumer".

私の質問は、たとえば、プロデューサースレッドがロックを取得し、キューをデータでいっぱいにし、同時にコンシューマーがロックを解除した場合、同時実行性の問題はありませんか？

簡単に言えば、単一のプロデューサーと単一のコンシューマーのシナリオの下で、プロデューサーとコンシューマーの間で同期とデータとメッセージの受け渡しに可変オブジェクトを使用しました。共有バッファはConcurrentQueueバイト配列です。循環バッファーを実装し、ヒープの断片化と頻繁なオブジェクトのスワップを防ぐために、使用済みバイト配列のごみ箱としてバイト配列を使用しましたGC。スレッドの同期に使用されます。コード内のバイト配列への参照が失われることがあります。以下は、詳細が必要な場合に備えて、私のコードの簡略化されたバージョンですが、これはスレッドを操作する際の日常的な間違いだと思います。ConcurrentBagManualResetEventSlim

実際GetEmptyBuffer()、メソッドは頻繁に新しいバッファを作成し、使用されたバッファはごみ箱に保存されますが、ごみ箱の数が増えないことがあります。

System.Collection.Concurrent およびいくつかの同期クラスの下に追加された新しい同時実行機能用の .NET。これらの機能を使用した単一の生産者と単一の消費者のパターンの良いサンプルはありますか? (実際には、共有バッファーとしてまだ実装されていない場合は、循環バッファー パターンを追加します)

生産者と消費者の問題の古典的なアルゴリズムについて私が理解していないこと (ウィキペディアから:)

プロデューサーとコンシューマーの両方が、バッファーをいじる前に「ミューテックス」をロックし、その後ロックを解除することに注意してください。その場合、つまり、任意の時点で単一のスレッドのみがバッファーにアクセスしている場合、上記のアルゴリズムが、保護ミューテックスをバッファーに配置するだけの単純なソリューションとどのように異なるかはわかりません。

「fillCount」および「emptyCount」セマフォを使用する必要があると私が考えることができる唯一のものは、スケジューリングです。

おそらく最初のアルゴリズムは、5 つのコンシューマーが空のバッファー (ゼロ 'fillCount') で待機している状態で、新しいプロデューサーが登場したときに、その "down(emptyCount)" を通過することを保証するためのものです。ステートメントをすばやく実行し、「ミューテックス」をすばやく取得します。

(一方、他のソリューションでは、新しいプロデューサーがそれを取得してアイテムを挿入するまで、消費者は不必要に「ミューテックス」を取得して放棄するだけです)。

私は正しいですか？何か不足していますか？

私は次のコードを書きました：

すべての変数が適切に初期化されます。タスクは、JOB_SIZE 要素を生成し、それらを消費することです。時々デッドロックに陥ります。私はposixスレッドにまったく慣れていないので、おそらく非常に明白な何かが欠けているでしょう(Java/C#/pythonでプロデューサー/コンシューマーを何度もやりましたが、今は本当に行き詰まっています)。セマフォを使用する方がはるかに簡単であることはわかっていますが、この方法で行う必要があります。

助言がありますか？

制限付きバッファーでプロデューサー/コンシューマースレッドを操作しようとしています。バッファーの長さは5です。1つのミューテックスと2つのセマフォがあり、バッファーのサイズで始まる空と、0で始まる完全です。

最後にsleep（）を使用せずにコードを実行すると、バッファーが完全にいっぱいになるまで継続的に生成され、空になるまで消費されるため、出力は次のようになります。

ただし、最後にsleep（）を使用して実行すると、次のように出力されます。

するとロックされたように見えますが、睡眠の有無に関係なく、なぜそのように動作するのかよくわかりません。助言がありますか？私のメインメソッドは基本的にいくつかの宣言を行い、次に生成するスレッドと消費するスレッドを1つ作成します。これらのメソッドは、以下のとおりです。

TIJ4 P1208には、1つのコンシューマー（WaitPerson）と1つのプロデューサー（Chef）があります。利用可能な食事があるかどうかを確認するとき、それぞれがそれ自体で同期します。代わりに食事で同期する必要があると思います。そうでなければ、給仕人が食事が利用可能かどうかをチェックしているときに、シェフが食事を生産している可能性があり、給仕人がチェックしているときに食事が一貫性のない状態になります。

どう思いますか？ありがとう

コードは次のとおりです。