問題タブ [readerwriterlockslim]

ReaderWriterLockSlim を使用すると、リソースへのアクセスを管理するために使用されるロックが可能になり、読み取り用の複数のスレッドまたは書き込み用の排他的アクセスが可能になります。現在、次のコードが配置されています。

さて、A型とB型の両方のオブジェクトのデータを保護する必要がある場合、どのようなアプローチが必要で、なぜですか?

ReaderWriterLockSlim一部の操作を保護するために使用しています。ライターよりもリーダーを優先したいと思います。これにより、リーダーがロックを長時間保持し、ライターが書き込みロックを取得しようとしているときに、その先のリーダーがライターの試みによってブロックされないようにすることができます (代わりに、ライターは でブロックされましたlock.EnterWriteLock())。

この目的のために、ライターがTryEnterWriteLockループ内で短いタイムアウトを使用できるので、後続のリーダーは引き続き読み取りロックを取得でき、ライターは取得できないと考えました。しかし、驚いたことに、 の呼び出しに失敗するとTryEnterWriteLock、ロックの状態が変更され、今後のリーダーがブロックされることがわかりました。概念実証コード:

このコードの出力は次のとおりです。

ご覧のとおり、スレッド 2 (「ライター」) はライター ロックを取得しておらず、EnterWriteLock呼び出し中ではありませんが、スレッド 3 は完全にブロックされます。で同様の動作が見られReaderWriterLockます。

私は何か間違ったことをしていますか？そうでない場合、ライターがキューに入れられたときにリーダーを優先するために必要なオプションは何ですか?

以下の単純なソケット クライアント クラスを使用して、それを TCP サーバーに接続します (オンラインで無料で入手できる SocketTest3 を使用します)。次に、サーバーを切断して、少し待ちます。を取得する必要がありLockRecursionExceptionます。

与えられた単純化された例でなぜそれが起こるのか理解できません。ReceiveOne長さ 0 のメッセージを受信したらすぐに通話を停止する必要があることはわかっていますが、これは練習問題です。同様のバグが、バックグラウンドで実行されているコールバックの一定のストリームを維持し、明らかに悪いことが起こることなくリソースを盗むことができるかどうか疑問に思いました. この特定の例外を予期していなかったことを認めなければなりません。

質問 1: なぜこれが起こるのですか? BeginXYZ同じスレッドで、メソッドがコールバックを即座に実行できる可能性がありますか? もしそうなら、これが通常の実行時に起こり得ないと誰が言えるでしょうか?

質問 2: この場合、「望ましい」動作を維持しながら、この例外を回避する方法はありますか? つまり、コールバックのノンストップ ストリームを起動するということです。

.NET 4 で Visual Studio 2010 を使用しています。

同時に複数のライター/単一リーダーを許可する必要があります。

ReaderWriterLockSlimクラスを見つけましたが、名前付けに問題があります。ライターに書き込みを許可するには EnterReadLock() を使用し、リーダーに書き込みを許可するには EnterWriteLock() を使用する必要があります。

ReaderWriterLockSlim クラスには私の問題のラッパー クラスがありますか、それとも別の解決策を提案できますか。

ありがとう！

リソースにアクセスするための ReaderWriterLockSlim オブジェクトのディクショナリを維持しました: (サンプル コードはここでは見苦しく、私の目的を理解してもらうだけです)

そして、次のように使用します：

リソースは動的に追加または削除される可能性があり、そのライフサイクルは予測できません (リソースの削除を監視できません)。リソースの量が増えると、rwResourceLocks のサイズも大きくなり、メモリの問題が発生します。この問題を解決する方法はありますか? (明らかに、これを行うために単純に rwResourceLocks.Clear() を呼び出すことはできません)

私はそれが少し複雑であることを知っています:(

ReaderWriterLockSlim が現在別のスレッドによって書き込みロックされているかどうかを知る方法は?

はい、rwls.TryEnterWriteLock(1) を呼び出して、書き込みがロックされているかどうかを確認できますが、パフォーマンスが低下します

書き込みロック状態を取得する直接的な方法はありますか?

1 つの専用スレッドによって管理されるデータベース書き込み用のアクションのキューがあります。そして、いつでもデータベースから読み取るスレッドがたくさんあります。

READ/WRITE アクセス制御に ReaderWriterLockSlim を使用しています。

私の質問は、なぜ LockRecursionPolicy.SupportsRecursion が推奨されないのですか? MSDN のドキュメントには次のように書かれています。

再帰の使用は、不要な複雑さをもたらし、コードがデッドロックを起こしやすくなるため、新しい開発にはお勧めしません。

ここでデッドロックをどのように達成できますか? たとえば、WriteReadLock が既に取得されているときに EnterReadLock を呼び出そうとすると (そして、SupportsRecursion ポリシーの下にある場合)、例外が発生します...