1 コンシューマー 1 プロデューサーの標準アルゴリズムを実装する必要があります。Queueいくつかのlockステートメントを使用して簡単に実装できます。または、単に使用できますConcurrentQueue。何が良いですか？
を使用するQueue + lockと、「複数の追加/検索」を最適化できlockますAdd。
ConcurrentQueue一般的にどちらが速いQueue + lockですか?また、その差はどれくらいですか? もちろんConcurrentQueue、これは最も簡単な方法ですが、HFT 取引アプリケーションでこれを使用しているため、パフォーマンスを大幅に低下させたくありません。
一言で言えばC＃から：
並行スタック、キュー、およびバッグクラスは、リンクリストを使用して内部的に実装されます。
Stackこれにより、非並行クラスやクラスよりもメモリ効率が低下Queueしますが、リンクリストはロックフリーまたはローロックの実装につながるため、同時アクセスには適しています。
言い換えれば、パフォーマンスの違いがどうなるかを予測することは言うまでもなく、一般的なケースを定義することは困難です。
コレクションのサイズと使用法によって異なります。十分な同時アクセスがあれば、パフォーマンスは向上することが期待でき、メモリ消費は悪化します。
さらに、ConcurrentQueue(T) と Queue(T) に関する Microsoft ドキュメントから:
各要素の処理時間が非常に短い (いくつかの命令) 純粋なプロデューサー/コンシューマー シナリオでは、System.Collections.Concurrent.ConcurrentQueue は、外部ロックを持つ System.Collections.Generic.Queue よりも適度なパフォーマンス上の利点を提供できます。 . このシナリオでは、ConcurrentQueue は、1 つの専用スレッドがキューに入れられ、1 つの専用スレッドがキューから取り出されたときに最高のパフォーマンスを発揮します。このルールを適用しない場合、複数のコアを持つコンピューターで Queue が ConcurrentQueue よりもわずかに速く実行されることさえあります。
処理時間が約 500 FLOPS (浮動小数点演算) 以上の場合、2 スレッド ルールは ConcurrentQueue に適用されず、非常に優れたスケーラビリティがあります。このシナリオでは、キューは適切にスケーリングされません。
生産者と消費者が混在するシナリオでは、処理時間が非常に短い場合、外部ロックを持つ Queue は ConcurrentQueue よりも適切にスケーリングされます。ただし、処理時間が約 500 FLOPS 以上の場合、ConcurrentQueue はより適切にスケーリングされます。