7

プロジェクトは.NET2.0RTMを対象としています（はい、.NET 2.0 RTMである必要があり、いくつかのオーソドックスなクライアントがあります）。そして、ReaderWriterLockの欠点は何ですか？誰もが「使わないで、lockステートメントのようなものを使ってみてください」と言うほど悪いのはなぜですか？.NET 3.5を使用できれば、間違いなくReaderWriterLockSlimをReaderWriterLock使用しますが、これらすべての警告がどこからでも発生するので、少し怖いです。誰かがパフォーマンスなどを測定しましたか？パフォーマンスの問題がある場合、どのペイロードでそれらに遭遇する可能性がありますか？

ReaderWriterLock主な目的、つまり複数の読み取りとめったにない書き込みという点で、古典的な状況があります。ステートメントを使用lockすると、すべてのリーダーがブロックされます。おそらくそれは私たちにとってひどい問題ではありませんが、私が使うことができれば私はReaderWriterLockもっと満足するでしょう。いくつかのモニターを導入するIMOは、実に非常に悪い考えです。

4

2 に答える 2

7

次のいくつかの投稿はあなたが探しているアイデアを提供することができます。

ReaderWriterLockSlimとReaderWriterLockのパフォーマンス比較

ReaderWriterLockの使用に関するRicoMarianiパートこの投稿では、ReaderWriterLockを使用するためのコストとシナリオのいくつかについて説明しています。また、パート1とパート2も確認してください。

ReaderWriterLockの代わりにジェフリー・リッチター

于 2011-04-12T04:13:34.720 に答える
1

ReaderWriterLockの理想的なユースケース（つまり、多数の同時読み取りと少数の書き込み）に実際に直面している場合は、それを使用してください。

遅すぎる場合は、別の方法があります。Sanjeevakumarは彼の答えにいくつかのリンクを提供しました。私も1つ提供します：
実際のローロックテクニック：リーダーライターロックの実装

ここでそのリンクからのポイントを引用します：

  1. 私の最初の記事で提案されているように、リーダーライターロックを使用してください。ロックパフォーマンスが問題になる場合は、ここでの実装を.NETSystem.ReaderWriterLockの「ドロップイン」置換として使用してください。Microsoftがライブラリ内のバージョンを修正するまで、この実装を自由に使用してください。
  2. スピンロックは本当に価値のあるローロック技術です。ここでは、マネージコードで完全に記述された、クリーンでシンプルだが効率的なリーダーライターロックを作成するために使用されました。このロックは、私が見たほとんどの実装よりも大幅に単純ですが、最適な状態になっています。この理由は、スピンロックを使用すると、パフォーマンスを犠牲にすることなく、ロックの設計と分析が大幅に簡素化されるためです。ここにあるスピンロック実装ショーを自由に使用して、他の高性能並行構造を作成してください。
  3. リーダーライターロックのような単純なものでさえ、その動作について微妙な点があります（特に、パフォーマンスの問題を考慮に入れる場合）。シンプルに保つことは、ここで本当に報われます。
于 2011-04-12T04:17:10.183 に答える