したがって、ReaderWriterLock（またはより具体的にはReaderWriterLockSlim）では、読み取りと書き込みの両方がロックを取得するためにミューテックスを取得する必要があることを理解しています。保留中の書き込みがない場合にロックを取得する必要がないように、ロックの読み取りアクセスを最適化したいと思います。（そして、必要に応じて、読み取りの大部分が可能な限り高速である限り、書き込みのパフォーマンスを犠牲にし、読み取りにいくつかの制約を追加し、最初の読み取りを遅くし、2番目を速くするなどを行います。 ）。
では、これをどのように行うのでしょうか。さらに良いのは、私に指摘できるフレームワークまたは「標準」の実装があるのでしょうか。（または、誤解していて、すでにサポートされている場合は、すばらしいです！）
だから私の作品の場合：リーダー/ライターの数（Interlocked.Incrementによって保護されている）のカウンターがあれば、リーダーはライターの数がゼロ以外であるかどうかを確認するのに十分であるように見えます。その時だけロックを取得します。（取得した場合は、ロック内で増分します。）
ライターは常にインクリメントし、ロックを取得し、リーダー数が0になるまでスピンし（リーダーが常に迅速に終了すると想定するか、楽観的なシナリオではリーダー数を完全にバイパスすることさえあります）、最後にデクリメントします。（ブロックするときに何らかの形式の優先順位をスローするか、1つのパスですべての保留中のリーダー/ライターをクリアする可能性があるので、1つの値のみを保護しているので便利ですが、今はそれを放棄します。）
だから..誰かが似たようなものを見たり、提案がありますか？少し経っても何も出てこない場合は、最初の実装をまとめて、より具体的に話していただければ幸いです。