最近、マルチスレッドのパフォーマンスの問題にぶつかり、現在のコードを最適化する方法を調査し始めました。
私の問題に対する最も適切な解決策は、リーダーライター ロックを使用することですが、Jeffrey Richter のこの記事を読んで、この種のロックの使用に疑問を抱くようになりました。ライターよりもリーダーの方がはるかに多いのですが、ライターの変更はできるだけ早く適用する必要があります。
この動作は、リーダーライター ロックの .net 4.5 バージョンでも残りますか? つまり、ライター スレッドよりもリーダー スレッドが優先されるということですか?
まず、新しいReaderWriterLockSlimクラスを使用する必要があります。これは、古いクラスよりも効率的であり、潜在的なデッドロックの多くのケースも回避します。
第 2 に、ライターが書き込みを希望する時点で、既に読み取り (または書き込み) ロックを保持しているスレッドを待機する必要があることを回避することはできません。これは、リーダー/ライター ロックの要件の基本的な部分です。
第三に、書き込みロックを待機している場合、ライターはリーダーよりも優先されます。
のドキュメントからReaderWriterLockSlim.EnterWriteLock()：
他のスレッドが読み取りモードでロックに入った場合、EnterWriteLock メソッドを呼び出すスレッドは、それらのスレッドが読み取りモードを終了するまでブロックされます。
書き込みモードに入るのを待っているスレッドがある場合、書き込みモードに入るのを待っているすべてのスレッドがタイムアウトするか、書き込みモードに入ってから終了するまで、読み取りモードまたはアップグレード可能モードに入ろうとする追加のスレッドがブロックされます。
この点で異なるようですReaderWriterLock- これは修正されたものの 1 つに見えます。
これはあなたが得ることができる最高のものです。重要なことは、読者がロックを可能な限り短時間維持することです。
ReaderWriterLockまた、どちらもReaderWriterLockSlimプロセス間ロックをサポートしていないことに注意してください。