問題タブ [readerwriterlock]

多くの読者に好まれる rwlock があることを私は知っています。通常、読者に好まれると考えられている RCU などのさらに積極的な設計もあります。

しかし、書き手が読み手よりもはるかに少なくない場合はどうなるでしょうか? ライターのみの rwlock が排他ロックにフォールバックすることはわかっていますが、次のパターンを検討してください。

• ライターがほとんどですが、読者もいます。おそらく、80% W 対 20% R?
• ライターとリーダーは偶数、50% W 対 50% R
• リーダーが最も多いですが、ライターは無視できず、待ち時間に関する要件があります。20% W 対 80% R

2つの質問があります

1. そのようなケース、特に最初の 2 つのケースは本当に存在しますか? これらのタイプに適合するユーザーレベルのアプリケーションは知りません。ユーザーレベルの例が優先されます。
2. タイプ 1/2/3 に該当するアプリケーションが実際にある場合、ロックのパフォーマンスを向上させる既存の方法はありますか?

ReaderWriterLock2つの間の共有リソースに aを使用しようとしていますTasks。何らかの理由で、無期限に待機し始めます:

タスクgetがプロパティを試行すると、LastIssuedAtブロックされるだけで、その理由がわかりません。

このリーダー/ライター ロックを GCD に実装しましたが、並列テストで失敗しました。失敗する理由について説明を得ることができますか?

これは iOS 開発用です。コードは Objective C に基づいています。データ保護のために、GCD でリーダー/ライター ロックを使用して RWCache を作成しました。

デッドロックがない場合、プログラムは 0 で終了します。それ以外の場合、プログラムはハングして終了しません。

私は遊んでいるこのおもちゃの構造を持っています:

私の理論は、 ofのArc周りに複数のライターを配置し、これらのライターがviaのフィールドとフィールドを個別に/同時に変更できるようにすることでした。RwLockCommunityRwLockfriendsindexCommunityContentsRc<RefCell

これは可能ですか？RwLock一度に複数のライターを許可しないでください。その場合、を削除してRefCells構造全体を単純化する必要がありますか?