問題タブ [readerwriterlockslim]

.NET 3.5 を使用しています。ReaderWriterLockSlimを使用して顧客オブジェクトをキャッシュに保存しています。問題は、顧客 Aのユーザーがアクションを実行すると、キャッシュ内の顧客オブジェクトが更新されることです。EnterWriteLock()は、顧客 Bに属し、別の顧客オブジェクトを持っている場合でも、すべてのユーザーがキャッシュから顧客オブジェクトを読み取ることを一時的に停止します。

複数のスレッドからディクショナリをすばやく読み書きする小さなコードを書きました。コードを保護するために ReaderWriterLockSlim を使用しましたが、重複したキーを追加しようとしたとされる例外を受け取りました。

スレッドのない正確なコードは完全に実行されることに注意してください。

WindowsAzureで実行されているアプリケーション用のグローバルエラーハンドラー/ロガーを作成しています。アプリケーションでエラーが発生すると、アトミックに発生する必要のあるいくつかの操作が実行されます。前のエラーが完了するまでエラーがログに記録されないようにする必要があります。その間、必要に応じてログの読み取りを実行したいと思います。

私の最初の考えは、モニター/ロックを使用して、エラー書き込みのみをロックすることでした。そうすれば、読み取りがまったく禁止されません。ReaderWriterLockSlimの方が適切かどうか疑問に思いました。あるアプローチと他のアプローチの価値を本当に理解しているとは言えません。

ReaderWriterLockSlimを作成し、次のようなことを行う必要があります（読み取りはEnterReadLockでラップされます）...

または、書き込みセクションのみをロックして、次のようなことを行うだけですか。

任意の考え/アドバイスをいただければ幸いです。

WinNT v6.x 以降でスレッドを同期するために、新しい条件変数プリミティブまたは Windows イベントのいずれかを使用できます。次の 2 つのアプローチを検討してください。main で「go」が設定されている場合はワーカーを同時に実行する必要があります。それ以外の場合は、すべてブロックする必要があります。

また

最初のアプローチでは、ワーカーは SleepConditionVariableSRW でブロックされ、WakeAllConditionVariableで起動されます。2 つ目では、 WaitForSingleObjectでブロックされ、 SetEventによって起動されます。

オーバーヘッドに関してのみ、実際にはどちらが優れていますか? (ヒント:コンテキスト スイッチ、ロック競合、ブロッキング スレッドのオーバーヘッド)

私は最初を選びますが、正当化の欠如を感じます。

プロジェクトは.NET2.0RTMを対象としています（はい、.NET 2.0 RTMである必要があり、いくつかのオーソドックスなクライアントがあります）。そして、ReaderWriterLockの欠点は何ですか？誰もが「使わないで、lockステートメントのようなものを使ってみてください」と言うほど悪いのはなぜですか？.NET 3.5を使用できれば、間違いなくReaderWriterLockSlimをReaderWriterLock使用しますが、これらすべての警告がどこからでも発生するので、少し怖いです。誰かがパフォーマンスなどを測定しましたか？パフォーマンスの問題がある場合、どのペイロードでそれらに遭遇する可能性がありますか？

ReaderWriterLock主な目的、つまり複数の読み取りとめったにない書き込みという点で、古典的な状況があります。ステートメントを使用lockすると、すべてのリーダーがブロックされます。おそらくそれは私たちにとってひどい問題ではありませんが、私が使うことができれば私はReaderWriterLockもっと満足するでしょう。いくつかのモニターを導入するIMOは、実に非常に悪い考えです。

最近、C＃コードの一部をリファクタリングしていて、いくつかのダブルチェックされたロック方法が実行されていることに気付きました。当時はそれが悪い習慣だとは知らなかったので、本当にそれを取り除きたいと思っています。

問題は、怠惰に初期化され、多くのスレッドによって頻繁にアクセスされる必要があるクラスがあることです。また、初期化されたオブジェクトがメモリ内に長く留まらないようにするために弱参照を使用することを計画しているため、初期化を静的初期化子に移動したくありません。ただし、必要に応じて、オブジェクトを「復活」させて、これがスレッドセーフな方法で行われるようにします。

C＃でReaderWriterLockSlimを使用し、最初のチェックの前にUpgradeableReadLockを入力してから、必要に応じて初期化用の書き込みロックを入力することが許容できる解決策になるかどうか疑問に思いました。これが私が念頭に置いていることです：

私のポイントは、他のスレッドがアイテムをもう一度初期化しようとするべきではないということですが、値が初期化されると、多くのスレッドが同時に読み取る必要があります。アップグレード可能な読み取りロックは、書き込みロックが取得された場合にすべてのリーダーをブロックする必要があるため、オブジェクトの初期化中の動作は、アップグレード可能な読み取りロックが開始されるロックステートメントの場合と同様になります。初期化後、アップグレード可能な読み取りロックは複数のスレッドを許可するため、各スレッドを待機することによるパフォーマンスへの影響はありません。

また、ここでvolatileを使用すると、読み取り前と書き込み後にメモリバリアが自動的に挿入されるという記事を読みました。したがって、_valueReferenceオブジェクトが正しく読み取られるようにするには、読み取りと書き込みの間に手動で定義されたバリアが1つだけあれば十分だと思います。このアプローチを使用することについてのあなたのアドバイスと批判に喜んで感謝します。

私は主にPOCOクラスとして設計されたクラスを持っており、さまざまなスレッドとタスクがその値を読み取ることができ、他の人だけがこれらの値をたまに更新するだけです。これは、ReaderWriterLockSlimにとって理想的なシナリオのようです。

問題は、クラスで、スレッドセーフである必要があるプロパティ、プロパティがブール値である場合、それはやり過ぎですか？それがintの場合はどうなりますか？日付時刻？

このコードはすべてやり過ぎで、単純です...

...十分でしょうか？タイプはブール値なので安全ですか？もしそうなら、それはいつ安全でなくなるのですか？バイト？int？日付時刻？

編集
私の基本的なアーキテクチャは、このクラスストアの状態にすることです。たぶん、このクラスへの書き込みを担当するサービスが1つあります。他のすべてのクラスは、この状態データに基づいてロジックを読み取り、実行できます。私はすべてのデータが一貫していることを確認するために最善を尽くしますが、以下に述べるように、私の主な関心事はデータの原子性と分裂でした。

結論
皆さんの回答に感謝します。すべてが貴重でした。私の主な関心事は、書き込み/読み取りの原子性でした（つまり、スプリンチングについて心配していました）。.NETプラットフォームの場合、問題の変数が4バイト未満の組み込み値型である場合、読み取りと書き込みはアトミックです（たとえば、shortとintは問題ありませんが、longとdoubleは問題ありません）。

最近ReaderWriterLockSlim、複数のスレッド間で共有される複数のリソースへのアクセスを同期するために使用する必要がありました。ReaderWriterLockSlimやっていくうちに、特に複数の場所で使わなければならない場合は使いにくいと感じました。ブロックが必要でtry...finally、ロックを開閉することを忘れないでください。多くの場合、書き込みロックを閉じるのではなく、書き込みロックを開き、読み取りロックを閉じていることにも気づきました。そこで、もっと簡単に使える方法を考えてみましたReaderWriterLockSlim。これは私が得た場所です

たとえば、へのアクセスを同期する必要がある場合、List<string>これは上記のクラスを使用して行う方法です

このアプローチの方が優れていると思いますか? 欠点や欠陥はありますか。

複数のスレッド間で共有される辞書があります。すべてのスレッドは、指定されたキーに従ってディクショナリから特定の値を読み取りますが、キーがディクショナリに存在しない場合、スレッドはそれをディクショナリに追加する必要があります。
同期の問題を解決するために、基本的にリーダーとライターのロック同期を提供する ReaderWriterLockSlim クラスを使用します (つまり、リーダーは並行して実行できますが、一度に 1 つのライターしか実行できません...) が、リーダーのアップグレード オプションを追加します。アップグレード オプションを使用すると、特定のキーが既にディクショナリにあるかどうかをテストできます。そうでない場合は、ロックをアップグレードして書き込み、キーごとに 1 つの追加のみを約束します。

私の問題は、一度に 2 つのアップグレード可能なロックを作成できないことです。つまり、この解決策は役に立ちません... :(

Microsoft がアップグレード可能なロックをこのように実装することを選択した理由 (一度に複数のアップグレード可能なロックを使用することはできません...) を説明してください。また、アップグレード可能なロックを自分で実装する方法を教えてください共有辞書を同期する別のアイデアはありますか?

実行時にオブジェクトを格納するために ConcurrentBag を使用しています。ある時点で、バッグを空にして、バッグの内容をリストに保存する必要があります。これが私がすることです：

私の質問は同期です。ブックロックを読む限り、他の同期方法よりも高速です。ソース - http://www.albahari.com/threading/part2.aspx .

パフォーマンスは私の 2 番目の関心事です。この時点で ReaderWriterLockSlim を使用できるかどうかを知りたいです。ReaderWriterLockSlim を使用する利点は何ですか? その理由は、この操作で受信リクエストをブロックしたくないからです。

はいの場合、アップグレード可能なロックを使用する必要がありますか?

何か案は ？コメント?