問題タブ [readerwriterlock]

最近、マルチスレッドのパフォーマンスの問題にぶつかり、現在のコードを最適化する方法を調査し始めました。

私の問題に対する最も適切な解決策は、リーダーライター ロックを使用することですが、Jeffrey Richter のこの記事を読んで、この種のロックの使用に疑問を抱くようになりました。ライターよりもリーダーの方がはるかに多いのですが、ライターの変更はできるだけ早く適用する必要があります。

この動作は、リーダーライター ロックの .net 4.5 バージョンでも残りますか? つまり、ライター スレッドよりもリーダー スレッドが優先されるということですか?

この関数で ReaderWriterLock を使用したい:

この関数は 1 秒間に 30 回呼び出され、そのたびに関数はデータをテキスト ファイルに書き込みます。毎回サンプリングしたデータを書き終わるまで関数をロックするコードを追加したい。vs2013 c# xaml でうまく動作するように、どのコードを追加する必要がありますか?

以下は、ミューテックスと条件変数の代わりに std::atomics とビジー待機を使用して、リーダーとライターの間で同期する複数のリーダー/ライター共有データの試みです。そこにあるアサーションがなぜヒットしているのか、私は困惑しています。ロジックのどこかにバグがあることは確かですが、どこにあるのかはわかりません。

実装の背後にある考え方は、ライターが書き込みを完了するまで読み取りスレッドが回転しているということです。読み取り関数に入ると m_numReaders カウントが増加し、ライターを待機しているときは m_numWaiting カウントが増加します。

m_numWaiting が常に m_numReaders の後にインクリメントされ、m_numReaders の前にデクリメントされる場合、m_numWaiting は常に m_numReaders より小さいか等しい必要があるという考え方です。

m_numWaiting が m_numReaders よりも大きい場合 (または表示されていない場合) はありません。リーダーは常に最初にリーダー カウンターをインクリメントし、待機カウンターをインクリメントする場合があり、待機カウンターは常に最初にデクリメントされるためです。

それでも、アサートがヒットしているため、これが起こっているようです。もしあなたがそれを見たら、誰かが論理エラーを指摘できますか?

ありがとう！

共有キュー (シングルトン キュー ラッパーを使用して実装) と、リーダー スレッドとライター スレッドがあります。また、ライター スレッドがキューに要素を追加 (エンキュー) したときに、リーダー スレッドに通知するメカニズムもあります。リーダー スレッドは、通知されたときに 1 つの要素のみをデキューします。このシナリオでは、読み取り書き込みロックが必要ですか。

ライターはエンキューとリーダーのデキューのみであるため、デキュー時にリーダーがキューサイズをチェックする場合、ロックの必要はないように感じます。

アプリの作成中。アーキテクチャ 私は、以下で説明する 1 つの構造の必要性に直面しました。

同じ機能を持つよく知られたデザイン パターンがあることは確かです。なぜなら、私がそれを開発した問題は非常に一般的だと思うからです。

私はこれの独自の実装を書いていますが、私は常にパターンの「ビルドイン言語」実装を使用しようとしているので、この構造に名前を付けるのを手伝ってください。

アイデアはリーダーライターのパターンに近いです。キー（）でオブジェクトを追加できる「コンテナ」があります。また、このオブジェクトをキーで取得して、コンテナーから削除することもできます。

したがって、実装されたクラスには 2 つのメソッドが必要です。

次が一番面白い。 このコンテナーは、次のようにマルチスレッド環境で動作する必要があります。

1. key に関連付けられたオブジェクトがない場合、get(Key key) メソッドを呼び出している間、呼び出し元スレッドはこのコンテナー内のオブジェクトを待機する必要があります。
2. 別のスレッドが putObject(Key key, Object object) メソッドを呼び出す場合、このオブジェクトを正確に待機するスレッドがあるかどうかを確認し、存在する場合は、待機しているスレッドにシグナルを送信してウェイクアップします。

一般的な構造だと思いますが、「正式な」名称はありますか？

このパターンの私の Java 実装:

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

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

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

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

C で最初のリーダー ライターの問題 (リーダーの好み) を実装しようとしています。ミューテックス ロックとロック解除を使用して、リーダーにロックがある場合はライターがスレッドにアクセスできず、最初の場合はどのリーダーもスレッドにアクセスできるようにしています。リーダーにはロックがあります。これが私のコードです。最後までコードを取得できません。つまり、スレッド結合部分に到達していません。どこかでデッドロックが発生していると思います。または、ミューテックスのロックとロック解除を間違った場所に配置している可能性があります。

メモリにデータを保持する Web アプリを実装しています。一部のリクエストは処理のためにこのデータを読み取り、一部のリクエストはこのデータを更新します。

このシナリオでは、複数のリーダーが同時にデータを操作できますが、ライターはメモリ内のデータに排他的にアクセスする必要があります。この問題を解決するために、リーダー/ライター ロックを実装したいと考えています。また、読み取りと書き込みの枯渇を回避するために、ロックの待機者が FIFO の順序で処理されるという公平性のプロパティも必要です。

Haskell 標準ライブラリは、そのような機能を提供していないようです。この機能を提供することがわかりましconcurrency-extraたが、ライブラリは維持されていないようです (LTS 3.22 の後にスタックから削除されました)。また、その公平性のプロパティは明確ではありません。

標準の haskell ライブラリとスタックにリーダー/ライター ロック ライブラリがないことは少し驚くべきことです。リーダー/ライター パターンは多くのソフトウェアで一般的ではありませんか? それとも、Haskell で好まれるまったく異なる (おそらくロックフリーの) アプローチはありますか?

EDIT :より正確には、公平性プロパティについて、ライターがロックの取得を待機してブロックされている場合、後続の読み取りロック要求は、ライターが書き込みロックを取得して解放した後にのみ許可する必要がありMVarます - s 公平性プロパティと同様 - MVars には FIFO があります財産

サイコロのランダムな抽選に基づいてそれぞれが 4 回実行される 3 つのスレッドの同期を制御するために、リーダー/ライター ロック メカニズムを実装しようとしています。たとえば、スレッド i の場合、random.randint(1, 6) が呼び出され、出力が偶数の場合はスレッド i が読み取られ、奇数の場合はスレッド i が書き込みになります。ここで、リーダー/ライター ロックの一般的な実装を見つけましたが、3 つのスレッドに対してこれら 4 つの操作を実行することに成功しませんでした。元のコードの一部と、最後に追加したものを次に示します。

なにか提案を？