問題タブ [readerwriterlockslim]

ASP.NET アプリケーションのキャッシュへのアクセスを保護するために ReaderWriterLockSlim を使用しています。MSDN には、ロックの使用例があります。ただし、この記事http://www.nobletech.co.uk/Articles/ReaderWriterLockMgr.aspxでは、デッドロックについて心配しています。これは本当にリスクですか？MSDN ドキュメントでこれについて言及する必要がありますか?

ReaderWriterLockSlimに関する Joe Duffy の記事を読んでも、自信が持てません!

Orcas の新しい ReaderWriterLockSlim の紹介

ロックは、スレッド アボートやメモリ不足状態などの非同期例外に対して堅牢ではありません。ロックのいずれかのメソッドの途中でこれらのいずれかが発生すると、ロック状態が破損し、その後のデッドロック、未処理の例外、および (悲しいことに) 内部でのスピン ロックの使用による 100% の CPU の固定が原因で発生する可能性があります。

ASP.NET で ReaderWriterLockSlim を安全に使用するにはどうすればよいですか?

したがって、ReaderWriterLock（またはより具体的にはReaderWriterLockSlim）では、読み取りと書き込みの両方がロックを取得するためにミューテックスを取得する必要があることを理解しています。保留中の書き込みがない場合にロックを取得する必要がないように、ロックの読み取りアクセスを最適化したいと思います。（そして、必要に応じて、読み取りの大部分が可能な限り高速である限り、書き込みのパフォーマンスを犠牲にし、読み取りにいくつかの制約を追加し、最初の読み取りを遅くし、2番目を速くするなどを行います。 ）。

では、これをどのように行うのでしょうか。さらに良いのは、私に指摘できるフレームワークまたは「標準」の実装があるのでしょうか。（または、誤解していて、すでにサポートされている場合は、すばらしいです！）

だから私の作品の場合：リーダー/ライターの数（Interlocked.Incrementによって保護されている）のカウンターがあれば、リーダーはライターの数がゼロ以外であるかどうかを確認するのに十分であるように見えます。その時だけロックを取得します。（取得した場合は、ロック内で増分します。）

ライターは常にインクリメントし、ロックを取得し、リーダー数が0になるまでスピンし（リーダーが常に迅速に終了すると想定するか、楽観的なシナリオではリーダー数を完全にバイパスすることさえあります）、最後にデクリメントします。（ブロックするときに何らかの形式の優先順位をスローするか、1つのパスですべての保留中のリーダー/ライターをクリアする可能性があるので、1つの値のみを保護しているので便利ですが、今はそれを放棄します。）

だから..誰かが似たようなものを見たり、提案がありますか？少し経っても何も出てこない場合は、最初の実装をまとめて、より具体的に話していただければ幸いです。

いくつかのスレッドコードを書く際に、私はReaderWriterLockSlim変数への同期アクセスを処理するためにクラスを使用してきました。これを行うと、メソッドとプロパティごとに同じ、try-finallyブロックを常に作成していることに気付きました。

繰り返しを避けてこの動作をカプセル化する機会を見つけて、C＃ブロック構文ReaderWriterLockSectionで使用できるロックの薄いラッパーとして使用することを目的としたクラスを作成しました。using

クラスは主に次のとおりです。

私は次のようにセクションを使用します：

私には、これは良い考えのように思えます。ロックを解除することを決して忘れないので、コードを読みやすくし、一見より堅牢に見えるようにするものです。

誰かがこのアプローチの問題を見ることができますか？これが悪い考えである理由はありますか？

キャッシュとして使用するスレッド セーフなクラスを開発しています。これは .NET と Mono で動作するはずです。

アイテムには有効期限があり、オブジェクトが取得されるたびに有効期限が更新されます。アイテムを追加するたびに、同じキーを持つ別のコレクションにタイムスタンプが追加されます。タイマーは、古いアイテムを探して削除するメソッドを発生させます。

アイテムを取得しようとすると、キャッシュに存在しない場合に取得する方法を示すデリゲートも提供する必要があります。

私はテストしましたが、アイテムの削除はテストで 30 秒ごとに発生するはずですが、非常に頻繁に、ほぼ毎秒発生しており、その理由はわかりません。

これはクラスです：

ご覧のとおり、デバッグ モードでは、アイテムが追加されると「_」記号が出力され、アイテムが削除されると「-」記号が出力されます。テストでは、2 分後に、アイテムが 30 秒ごとにのみ削除される必要があるときに、アイテムが同じ秒でどのように削除および追加されるかを確認できますが、その理由はわかりません。

これは私がテストする方法です：

GenericCache クラスに問題はありますか?

よろしくお願いします。

そのため、複数のスレッド間で共有されるリソースに対して、非常に多くの読み取りがあり、たまにしか書き込みがないという状況があります。

ずいぶん前に私は について読み、多くの書き込みが切り札の読み取りに来てパフォーマンスを損なうという問題を軽減する試みReaderWriterLockについて読んだことがあります。ReaderWriterGateしかし、今になって気づいたReaderWriterLockSlim...

ドキュメントから、「アップグレード可能モード」のスレッドは一度に 1 つしか存在できないと思います。私が使用している唯一のアクセスがEnterUpgradeableReadLock()（私のシナリオに適している）である状況では、そのままにしておくことと大きな違いはありlock(){}ますか?

抜粋は次のとおりです。

アップグレード可能モードのスレッドが既に存在する場合、書き込みモードに入るのを待っているスレッドがある場合、または書き込みモードのスレッドが 1 つしかない場合、アップグレード可能モードに入ろうとするスレッドはブロックされます。

または、再帰ポリシーはこれに違いをもたらしますか?

アイテムのコレクションを保持するオブジェクトがあります。AddItem メソッドを使用してコレクションにアイテムを追加し、コレクション内のすべてのアイテムを調べたいと考えています。私のオブジェクトはスレッドセーフでなければなりません。適切な同期を保証するために ReaderWriterLockSlim を使用しています。GoThroughAllItems メソッドを同期するにはどうすればよいですか? 全体の期間全体にわたって大きな ReadLock を開始する必要がありますが、これは非常に長くなる可能性があります。それとも、コレクションからフェッチされた各アイテムのロックを解放し、次のアイテムのために再度ロックを取得する必要がありますか?

サンプルコードは次のとおりです。

ReaderWriterLockSlim メンバー変数を持つクラスで GC.Collect が実行されたときのコードの問題を示すコードの例があります。GC.Collect の実行には 2 ～ 3 秒かかります。私のアプリケーションは非常にメモリを集中的に使用するため、定期的に GC を実行する必要があります。

誰かが同様の問題を抱えていましたか？

ありがとうイアン

の C# のショートカットが気に入っていlock(myLock){ /* do stuff */}ます。読み取り/書き込みロックに相当するものはありますか? (具体的には ReaderWriterLockSlim です。) 現在、次のカスタム メソッドを使用しています。これは機能すると思いますが、アクションを匿名関数として渡す必要があるため、少し面倒です。可能であれば、標準のロック メカニズムを使用したいと考えています。 .

スレッドセーフでなければならないいくつかのコードがあり、その動作は次のようになります。

計算は値とカウンターの両方をロックする必要があります。そうしないと、競合状態が if(...) ブロックに影響を与える可能性がありますが、読み取り時に同期する必要はまったくありません。両方を読んでください。それは私にとって 100% 大丈夫です。

読み取りのインターロックは、64 ビット値のスレッドセーフ読み取りのためにあります。

1. このようにインターロックとロックを混在させても安全ですか? 他の Web ページでそれらを混在させることは安全ではないことを読みましたが、これがそれらを混在させることが微妙なバグを導入するための優れた方法であることを意味するのか、またはシステムレベルでこれが関連するデータ構造を破損する可能性があるのか​​ を明確にすることはできません.

2. このすべてのインターロック (64 ビット .NET 4.0 ランタイム) のコストは、プロパティ get() メソッドの周りの ReaderWriterSlim ロックを保存する目的を完全に無効にしますか?