2

私は持ってSystem.Collections.Generic.List _myListおり、多くのスレッドがそれから読み取ったり、アイテムを同時に追加したりできます。私が読んだことから、「BlockingCollection」を使用する必要があるため、これは機能します。ReaderWriterLockSlimとについても読みましたが、lockの代わりにそれらを使用する方法がわからないBlockingCollectionので、私の質問は次のように同じことができますか?

  1. ReaderWriterLockSlim
  2. ロック

「BlockingCollection」を使用する代わりに。はいの場合、簡単な例と、、、を使用することの長所と短所を教えBlockingCollectionてReaderWriterLockSlimくださいlock。

更新され た読者は、作家以上のものになります!

4

2 に答える 2

5

ReaderWriterLockSlim:

  • リソースからの読み取りが書き込みよりも頻繁に発生するユースケース向けに最適化されています。
  • ハイブリッド同期構造であるため、(コレクションだけでなく) あらゆる種類のリソースを操作できます。

lock:

  • 最適化されていない汎用のかなり単純なハイブリッド同期構造です。したがって、パフォーマンスが低下する可能性があります。
  • Monitorクラスの C# ラッパーです。
  • あらゆる種類のリソースを処理できます。

BlockingCollection:

  • 特定のタイプのコレクション (リソースの具体的なタイプ) であり、「生産者と消費者」のタスクを解決することを目的としています。
  • タイムアウトとキャンセル メカニズム (キャンセル トークン経由) をサポートしているため、TPL を使用するコードへの統合が容易になります。

あなたの選択はBlockingCollection（あなたが本当に多くの読者と作家を持っている場合）だと思います。

于 2012-06-04T10:39:46.263 に答える
2

リストを頻繁に変更する場合は、単一の書き込みアクセスのみが許可され、オーバーヘッドが少ないためReaderWriterLockSlim、おそらく役に立ちません。lock個人的にはlock、各アクセスの期間中は（いくつかのロックオブジェクトに対して）だけです。

aの問題は、BlockingCollection個々の操作がアトミックであることを保証するだけであるということです。ただし、多くの場合、複数の操作を1つの単位として実行する必要があります（単なるTryAddなどではありません）。したがって、狂気を避けるために、alockはより単純です。

他の利点は、の使用法lockが非常に簡単であることです。

lock(syncLock) {
   // do stuff with the list
}

Monitor.Wait（また、とを介したシグナリングが組み込まれていますMonitor.Pulse*。これは素晴らしいことです）

于 2012-06-04T10:36:58.293 に答える