問題タブ [readerwriterlock]

これは私には非常にうるさいようです。5 行のオーバーヘッドは多すぎます。

では、これをどのように単純化しますか？

デッドロックが原因でハングした .Net プロセスのダンプを取得しました (GUI スレッドが応答しなくなり、ログにはいくつかのスレッドが応答を停止したことが示されています)。私はスナップショットを撮り、現在windbgでそれを調べています.1つを除くすべてのスレッドが最後のものを待っています. その 1 つのスレッドのスタック トレースを !clrstack -p で見ると、ReaderWriterLock への書き込みを取得しようとしていることがわかります。

デッドロックがどのように発生したかを理解できるように、他のどのスレッドがそのロックを保持しているかを知るにはどうすればよいですか?

ありがとう

[編集] .Net1.1 の sos.dll にはこれを支援するコマンド !rwlocks があったようですが、.Net2.0 バージョンにはありません。狩りは続く

IDictionary<TKey,TValue>内部でn個のその他Dictionary<TKey, TValue>を保持し、その挿入をキーのHashCodeによって個々のサブ辞書に配布する実装があります。16 個のサブディクショナリがあるため、4 コア マシンでの衝突の数はかなり少なくなります。

並列挿入の場合、 Add メソッドをReaderWriterLockSlimでロックし、個々のサブ辞書のみをロックします。

4 つのスレッドで項目を挿入すると、約 32% の CPU 使用率しか得られず、パフォーマンスが低下しました。そこで、ReaderWriterLockSlim を Monitor (つまり、lockキーワード) に置き換えました。CPU 使用率はほぼ 100% になり、パフォーマンスは 2 倍以上になりました。

私の質問は、CPU 使用率が増加したのはなぜですか? 衝突の数は変わっていないはずです。ReaderWriterLock.EnterWriteLock が何度も待たされるのはなぜですか?

こんにちは、メソッドで writerreaderlock を使用する必要があります。正しい使い方が知りたいです。

ObjectA の辞書を取得しました

私のメソッドでは、ObjectA の辞書を使用します。キーは Guid であるため、dict[guid] を呼び出すと、常に ObjectA のインスタンスが返されると仮定します (例として)。

リーダーとライターの使用方法がよくわかりません。条件付き検証を使用して、リーダーとライターのロックをどのように使用する必要がありましたか?

私は.net 2.0にアプリケーションを持っており、アプリケーションにグローバルにDataTableオブジェクトがあり、アプリケーション全体に異なるデータビューがあります。

アクションが実行されると、多くのスレッドが作成され、データが異なるデータビューから読み取られる 5 と言えます。一方、2/3 のスレッドがデータを読み取っている間 (データを読み取るために残り 2 つすべてではありません)、スレッドはデータテーブルにデータを書き込みます。そのため、「列挙型の更新」や「パラメーターが null ではない」タイプなどの例外が発生します。

これには ReadWriteLock を使用しましたが、ReaderWriterLock.AcquireWriterLock() で停止する運がありません。

どこが間違っているのかわかりません。

誰かが何か考えがあれば。データテーブルとデータビューのこのシナリオで ReaderWriterLock を実装する方法を教えてください。

ありがとう！！

たとえば、リーダーとライターが同時に実行されるリーダー/ライター システムがあるとします。'a' と 'b' は 2 つの共有変数であり、互いに関連しているため、それらの変更はアトミック操作である必要があります。

リーダー/ライター システムには、次の種類があります。

1. rr
2. ww
3. 右
4. r-ww
5. rr-w
6. うーんww

[ r : シングル リーダーrr
: マルチ リーダー
w : シングル ライター
ww: マルチ ライター ]

さて、次のように、リーダー用の読み取りメソッドとライター用の書き込みメソッドを使用できます。私はそれらをシステムタイプごとに書きました。

1. rr

   /li>

2. ww

   /li>

3. 右

4. r-ww
5. rr-w

6. うーんww

   /li>

複数のリーダー システムの場合、共有変数へのアクセスはアトミックである必要はありません。

複数の書き込みシステムの場合、共有変数へのアクセスはアトミックである必要があるため、'm' でロックされます。

しかし、システム タイプ 3 ～ 6 の場合、私の read_method と write_method は正しいですか? どうすれば改善できますか？

敬具、
スリニバス・ナヤク

lock(){...} を使用すると、どのスレッドが最初にロックに入るか保証できません。

ReaderWriterLock はどうですか？ライターの FIFO のように機能しますか?

プロセス間で機能する読み取り/書き込みロック メカニズムはありますか (Mutex に似ていますが、排他ロックではなく読み取り/書き込み)? 同時読み取りアクセスを許可したいのですが、書き込みアクセスは排他的です。

順序付けられたロックパターンは、ReaderWriterLock（またはReaderWriterLockSlim）で使用した場合にデッドロックを防ぎますか？

明らかに、このパターンはミューテックスによるデッドロックを防ぎます。複数のリソースを（（読み取りロック付きのNリソース）および（書き込みロック付きの1つまたは2つのリソース））でロックしている場合でも、デッドロックは防止されますか？

例:(太字の数字は書き込みロックのあるリソースを表します）

1 2 3 4 5

2 3 4

1 4 5

優先度の低いライターをサポートするリーダー/ライターロックを見つけようとしています（または実装しようとしています）が、既存のソリューションの調査に失敗しました。

優先度の低いライターとは、次の読者や通常のライターに「一列に並ぶ」という意味です。

リーダーが絶えず流れている場合は確かに飢餓につながりますが、これは時限ロックのバリエーション（「時限低優先度ライターロックを試してからタイムアウト時に通常のロックに切り替える」）またはリーダーの方法を変更することで解決できます。が発行されます（おそらく、短いウィンドウで定期的に読み取りを停止します）。

これらの線に沿って何かを説明している文献があれば、私はそれを見つけていません。

通常のロックを利用する既知の（正しい！）解決策がある場合は、説明をいただければ幸いです。