問題タブ [readerwriterlockslim]

次のコードが ThreadAbortException に対して耐性があり、孤立したロックに至らないかどうかを確認したいと思います。そうでない場合、ここで孤立ロックを回避するための最良のパターンは何ですか?

次のリンクhttp://chabster.blogspot.cz/2013/07/a-story-of-orphaned-readerwriterlockslim.htmlによると、孤立したロックを作成する方法はあります (または少なくともありました) が、サンプルを実行していましたしばらくの間、何の運もありません。

.NET 4.0 を使用しています

Debug と Release の動作に違いはありますか?

MSDN ドキュメントおよびクラスの使用例の多くでReaderWriterLockSlimは、次のパターンの使用が推奨されています。

しかし、それが完全に安全かどうかは気になります。ロックが取得された後、tryステートメントの前に何らかの例外が発生して、ロックがロックされた状態でスタックする可能性はありますか? 最も明白な候補はThreadAbortExceptionです。この状況の可能性は非常に小さいことは理解していますが、結果は非常に悪いので、検討する価値があると思います. tryコンパイラがこのパターンを理解し、プロセッサがステートメントの前にスレッドを中断するのを防いでいるとは思えません。

このコードが安全ではないという理論的な可能性がある場合、より安全にする方法はありますか?

Web アプリケーションには完全な -s がいくつかlockありますが、それらを読み取り/書き込みロックに置き換えると、パフォーマンスが向上する可能性があります。RW ロックの追加のオーバーヘッドがあっても、コードはより並列になります。残念ながら、ReaderWriterLockSlim特定のハードウェアでデッドロックを引き起こす可能性があるかなり大きな同期バグのように見えるため、使用できません。この記事では、この問題について詳しく説明します。

上記の問題は .NET Framework 4.0.30319.33440 で修正されているようですが、すべての Windows サーバー バージョンでこの修正が適用されるわけではありません。Windows 8.1 および Windows Server 2012 R2 には修正プログラムがあります。Windows Server 2012 (R2 ではない) および Windows Server 2008 R2 には、最新のパッチを適用した後でもまだバグがあります。Microsoft は、すべてのプラットフォームでこの問題を修正する予定はないようです。

私たちのさまざまなサーバー環境はさまざまなバージョンの Windows Server を使用しており、一部のサーバーには修正プログラムがあり、一部のサーバーには修正されていないことが確認されています。これは、一部のサーバーではアプリケーションがランダムにデッドロックする可能性があるため、これらすべてのlockステートメントをリーダー/ライター ロックに安全に変更できないことを意味します。

ReaderWriterLockSlim別の方法として、 System.Core のコードを逆コンパイルしMyRWLock、1 つの (既知の) バグのある関数がExitMyLock修正された新しいクラス (のようなもの) を作成して再実装することを検討しています。その他のコードはすべてオリジナルと同じReaderWriterLockSlimです。

これには、すべての属性を削除し、 の__DynamicallyInvokable内部にある 2 つまたは 3 つのクラス/構造を追加する必要がありますSystem.Core。私はこれをすべて行い、新しいロッククラスをエラーなしでコンパイルしました。

私の質問は、この新しいクラスが元のクラスのように機能しない理由を考えられる人はReaderWriterLockSlimいますか? スレッド化に関しては、自分はかなり上手だと思いますが、専門家ではありません。MyRWLockコードを変更していないので (一部の型名を and 属性の代わりにnew を指すように修正する以外はReaderWriterLockSlim)、これでうまくいくと思います。しかし、デバッグが難しいさまざまな興味深い方法でこれを壊す可能性のある何かを忘れていたのではないかと思います。

あるいは、私の（およびリンクされた記事の）理解は間違っていますか？そもそもこの問題は修正する必要がないのでしょうか? その記事の著者は非常に詳細な分析を行ったようで、私には正しいように見えますが、Microsoft は特定の Windows Server バージョンに変更を適用しませんでした。

これについての考えは大歓迎です。

編集：

完全なロックのコンテキストをさらに追加するために、これがその目的です。リモートサービスが作業を実行するときに読み取り/書き込みを行うサービスがあります。書き込みより読み取りの方が多い。読み取りには 1 回のネットワーク ラウンドトリップが含まれ、書き込みにはリモート サービスへの 3 回のネットワーク ラウンドトリップが含まれます。書き込みが発生すると、読み取りが発生しない場合があります (書き込みは、実際には読み取り -> 削除 -> 追加です)。現在、lockこれらすべての操作で完全な -s を使用していますが、これは、書き込みがなくても、読み取りを試みるすべてのスレッドが現在の読み取りが完了するまでキューに入れなければならないことを意味します。これにはRWロックが理想的だと思います。

ReaderWriterLockSlim と ExitWriteLock の遅延に不満があります。タイマー コールバックで WriteLock が解放されるのはなぜですか?

私は.NET 4.5 Single Instance WCFサービスを持っています。これはリスト内のアイテムのコレクションを同時に保持し、同時にリーダーとライターを持っていますが、ライターよりもはるかに多くのリーダーを持っています。

現在、BCL を使用するかConcurrentBag<T>、独自のカスタム汎用ThreadSafeListクラスを使用するかを決定しています (BCL を拡張IList<T>およびカプセル化するのReaderWriterLockSlimは、複数の同時読み取りにより適しているためです)。

100 万人のリーダー (Sum Linq クエリを実行するだけ) と 100 人のライター (リストに項目を追加する) の同時シナリオをシミュレートして、これらの実装をテストしたところ、多数のパフォーマンスの違いが見つかりました。

私のパフォーマンス テストでは、タスクのリストがあります。

テスト 1: 次のコードを使用して、100 万個のリーダー タスクに続いて 100 個のライター タスクを作成した場合:

次のタイミング結果が得られます。

• コンカレントバッグ: ~300ms
• スレッドセーフリスト: ~520ms

テスト 2: ただし、100 個のライター タスクと混合された 100 万のリーダー タスクを作成すると (これにより、実行されるタスクのリストは {Reader,Reader,Writer,Reader,Reader,Writer etc} になります。

次のタイミング結果が得られます。

• コンカレントバッグ: ~4000ms
• スレッドセーフリスト: ~800ms

各テストの実行時間を取得するための私のコードは次のとおりです。

カスタム実装よりも、テスト 1 の ConcurrentBag の効率が良く、テスト 2 の ConcurrentBag の効率が悪いため、どちらを使用するかを判断するのは難しいと思います。

Q1. リスト内のタスクの順序だけを変更しているのに、結果がこれほど異なるのはなぜですか?

Q2. テストをより公平にするためにテストを変更するより良い方法はありますか?