質問で「3.5」を強調したいと思います。 4.0でこのようなことの多くが変更されていることは承知していますが、まだアクセスできません。.NET 3.5には、あるスレッドがデータを追加できるようにするコレクションがありますが、別のスレッドはデータをすべてロックすることなくデータを削除できますか？
私は、別のアプリケーションからデータを取り出してキューに入れ、UIスレッドは定期的にそこからデータを取得する関数を呼び出します。現在のところ、私は両側からアクセスしている間、キューをロックしていますが、ネットワークを介して大量のデータが入ってくると問題が発生します。
私は、これを動作させるために何らかの種類の循環バッファを実装することができますが、これは既に.NETクラスを使用して行うことができると仮定しています。
Queue合理的なアプローチのように思える、と私は限り、あなたは唯一のQueue法（ライタ側）またはDequeueメソッドの呼び出し（読者側）のためにロックを保持しているとして、パフォーマンスの問題を期待していません。ロックが問題であると確信していますか？
@ Jon Bの答えに示唆されているReaderWriterLockは、読者が1人しかいないため、実際に役に立たないことに注意してください。どんな場合でもDequeueを呼び出すには書き込みロックが必要です。
ReaderWriterLockあなたはPeekメソッドを呼び出して、複数のリーダースレッドがあった場合だろうに役立つかもしれない唯一のケース - 彼らは唯一の読み取りロックを必要とすることになるために。
書き込みロックについての良い点はありません:) –
キューとロックはボトルネックではありませんでした。 – Almo
キューがボトルネックである場合は、次の方法を試してください。ロードバランサと各コンシューマのキューを用意します。ロードバランサは、着信要求をコンシューマのキューに入れます。これは、どのコンシューマ・キューが最もフリーであるかに基づいて行われます（最小キュー・サイズ）。
ここでは、生産者と消費者のスピードと数について多くの仮定をしていますが、これは基本的な考え方です。新しいボトルネックがロードバランサになります。ご覧のとおり、これは、消費者が行う計算集中的な作業がある場合に機能します。
また、ReaderWriterLockSlimを試してみることもできます。このリンクには、その使用方法のサンプルも含まれています。そして、それはReaderWriterLockよりも好ましい：
.NET Frameworkには、2リーダライタロック、ReaderWriterLockSlim とReaderWriterLockを持っています。新しいすべての 開発にはReaderWriterLockSlimをお勧めします。 ReaderWriterLockSlimはReaderWriterLockと似ていますが、 は再帰とアップグレードのための簡略化されたルールと ロック状態をダウングレードしています。 ReaderWriterLockSlimは、多くの場合、 の潜在的なデッドロックを回避します。さらに、 ReaderWriterLockSlimのパフォーマンスは、ReaderWriterLockよりも大幅に優れています。
しかし、@Joeが正しく指摘するように、ポップ操作とプッシュ操作の両方にライターロックを設定する必要があります。ロック付き
@Oded System.Collections.Concurrentはフレームワーク4以降にのみあります –
いいえ - – Yahia