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

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

を使用するReaderWriterLock場合は、次のように宣言します。

ReaderWriterLock rwLock = new ReaderWriterLock;

保護したいリソースにアクセスしようとしているすべての異なるスレッドに対してこれを行っている場合、それらはすべて（おそらく）異なるReaderWriterLockインスタンスを使用しています。

ReaderWriterLockインスタンスはスレッド間でどのように共有されますか？

また、ボーナスとして、あなたが本当に「ロック」しているのはReaderWriterLock状態であり、リソースではないことを誰かが確認できますか。とは異なりlock(someResourceToLock)、ReaderWriterLockインスタンスの状態（読み取りモードか書き込みモードか、および読み取りと書き込みがまだ許可されているかどうか）以外はロックしていません。

iphone dev 用に pthread_rwlock_t のラッパーを実装しています。ドキュメントによると、書き込みロックを取得した後に読み取りロックを取得することは未定義です。POSIX では、既に書き込みロックを持っているかどうかを問い合わせることができますか? または、この状況が起こらないようにする最善の方法は何ですか?

ありがとう！

これはリーダー/ライターの実装です。つまり、多くのリーダーは読み取ることができますが、一度に書き込むことができるライターは 1 つだけです。これは期待どおりに機能しますか?

また、この実装は各メソッドの宣言とは異なりますか

例えば？

ありがとう

物語

どこかから定期的にデータを収集するライタースレッドがあります（リアルタイムですが、問題ではそれほど重要ではありません）。これらのデータから読み取る多くのリーダーがあります。これに対する通常の解決策は、次のように 2 つのリーダー/ライターのロックと 2 つのバッファーを使用することです。

または

問題

どちらの方法でも、他のロックの取得操作が失敗した場合、スワップは行われず、ライターは以前のデータを上書きします (ライターはリアルタイムであるため、リーダーを待つことができないため)。したがって、この場合、すべてのリーダーはそのフレームを失います。データの。

これは大したことではありませんが、リーダーは私自身のコードであり、短いので、ダブル バッファーを使用すると、この問題は解決されます。問題が発生した場合は、トリプル バッファー (またはそれ以上) にすることができます。

問題は、最小限にしたい遅延です。ケース 1 を想像してください。

**この時点**で、理論的にはbuffer0、次の期間を待つのではなく、リーダーが終了した後にライターだけがスワップを実行できれば、他のリーダーはデータを読み取ることができたはずです。この場合、1 つのリーダーが少し遅れただけで、すべてのリーダーが 1 フレームのデータを見逃していましたが、問題は完全に回避できたはずです。

ケース 2 も同様です。

解決策を混ぜてみたので、ライターは書き込み直後にバッファーのスワップを試み、それができない場合は次のピリオドでウェイクアップした直後に試行します。だから、このようなもの：

遅延の問題はまだ残っています：

再び **この時点** で、すべてのリーダーが を読み始めることができますbuffer0。これは、 が書き込まれてから少し遅れbuffer0ますが、代わりに、ライターの次のピリオドまで待たなければなりません。

質問

問題は、これをどのように処理するかです。希望の周期で正確にライターを実行させたい場合は、RTAI関数を使用してその周期を待つ必要があり、私はそれを行うことができません

これにより、ジッターが発生します。「数回」が「次の期間を待つ」よりも長くなる可能性があるため、ライターはその期間の開始を見逃す可能性があります。

より明確にするために、ここに私がしたいことがあります：

私がすでに見つけたもの

私が理解している限り、バッファーにメモリを割り当て続け、リーダーがそれらを使い果たすまでそれらを解放するread-copy-updateを見つけましたが、これは多くの理由で私には不可能です。1 つは、スレッドがカーネルとユーザー空間の間で共有されることです。次に、RTAI を使用すると、リアルタイム スレッドでメモリを割り当てることができません (スレッドが Linux のシステム コールを呼び出すことになり、リアルタイム性が損なわれるためです!)同じ理由で）

また、より高い頻度でバッファーのスワップを試行する追加のスレッドを用意することも考えましたが、それはあまり良い考えではないように思えます。まず、それ自体がライターと同期する必要があります。次に、これらのライター/リーダーの多くがさまざまな部分で並行して動作しているため、ライターごとに 1 つの余分なスレッドが多すぎるように思われます。すべてのライターに対して 1 つのスレッドというのは、各ライターとの同期に関して非常に複雑に思えます。

私は現在、Reader-Writer問題の正しい実装に取り​​組んでいます（ここを参照）。

このソリューションは、セマフォとミューテックスを使用してリーダースレッドとライタースレッドの公平な処理を保証するQtドックで見つかりました。基本的なコードは次のとおりです。

これは非常にエレガントな解決策のようです。このSOの回答pthread_rwlock_*で詳しく説明されている動作よりも簡単で効率的です。

以下のこのコードは、リーダースレッドを優先するためのQtソリューションの正しい調整であるかどうか疑問に思いました。

OS の書籍では、リーダーとライターが同時にデータにアクセスするのを防ぐためにロックが必要であると述べています。しかし、x86 マシンで簡単な例をテストすると、うまく動作します。知りたいのですが、ここのロックは必要ですか?

そこにもっと速い種類はTMultiReadExclusiveWriteSynchronizerありますか？おそらくFastCode？

Windows Vista 以降、Microsoft はSlim Reader/Writer lockを追加しました。Delphiよりもはるかに優れたパフォーマンスを発揮しますTMultiReadExclusiveWriteSynchronizer。残念ながら、これは Windows Vista 以降にしか存在せず、実際にまだほとんどのユーザーが持っていません。

おそらく、内部で使用されている概念はSlim Reader/Writer lock、ネイティブの Delphi コードでやり直すことができますが、それを行った人はいますか?

TMultiReadExclusiveWriteSynchronizer（競合がない場合でも、単一のスレッドで）ロックを取得および解放すると、 100％のオーバーヘッドが発生する（操作時間が2倍になる）状況があります。ロックせずに実行できますが、クラスはスレッドセーフではなくなります。

より速いものはありますTMultiReadExclusiveWriteSynchronizerか？

注: i を使用するとTCriticalSection、2% のパフォーマンス ヒットしか発生しません (ただし、取得が成功した場合、つまりシングル スレッドで競合がない場合、クリティカル セクションは高速であることが知られています)。CS の欠点は、「複数のリーダー」機能を失うことです。

測定

内部とTMultiReadExclusiveWriteSynchronizer内部でかなりの時間を費やしています。BeginReadEndRead

次に、Windows 独自のSlimReaderWriter Lockを使用するようにコードを移植し(再帰的なロックの取得をサポートしていないため、一部のコードを書き換えます)、結果をプロファイリングしました。

• TMultiReadExclusiveWriteSynchronizer: 反復ごと
  に 10,698 ns 1,000,000 回反復するには 10,697,772,613 ns

• SRWLock: 反復ごとに 8,802 ns
  1,000,000 回反復するには 8,801,678,339 ns

• Omni Reader-Writer lock: 反復ごとに 8,941 ns
  1,000,000 回反復するには 8,940,552,487 ns

SRWLocks (別名 Omni の回転ロック) を使用すると 17% の改善。

現在、まだ Windows XP を使用している企業全体が存在するため、Windows Vista SRWLocksを使用するようにコードを永続的に切り替えることはできません。

スリムロックは、InterlockedCompareExchange機能を慎重に使用するだけです。しかし、私がうまく使用できるよりも慎重です。関係する 140 の機械語命令を盗むには程遠いです。

ボーナスリーディング

• クリティカル セクションは常に高速ですか?
• 高速なマルチスレッド Delphi アプリケーションを作成する方法

POSIXという名前のセマフォを使用して単純なリーダー/ライタープログラムを作成しようとしていますが、一部のシステムでは、最初のセマフォですぐに停止し、それだけです...私は今では本当に必死です。誰か助けてもらえますか？私のシステムでは正常に動作しているため、ltraceで問題を追跡することはできません。（コメント申し訳ありませんが、私はチェコ共和国から来ました）

https://www.dropbox.com/s/hfcp44u2r0jd7fy/readerWriter.c

上記は、ライターがリーダーよりも優先されるリーダー書き込み問題の解決策です。

最初に1000人のリーダーがデータを読み取るためのコードの実行を開始し（データコードの読み取りが巨大で、スレッドごとに1秒かかると仮定します）、次に1人のライターがデータを書き込もうとします。したがって、ライターは1000人のリーダーが最初に終了するのを待つ必要があります（つまり、1000秒）。

たとえば、1人のライターが時間を更新し、多くのリーダーが時間を読み取るアプリケーションでは、ライターは1000秒待つ必要があります。これは膨大な時間です。

ライターが書き込もうとしたときに、ライターがタスクを完了するまですべてのリーダーがプリエンプトされる解決策はありますか？