使用ReaderWriterLock的真正缺點是什麼

Question

我們有針對.NET 2.0 RTM的項目（是的，它應該是.NET 2.0 RTM，我們有一些正統的客戶端）。我只是想知道ReaderWriterLock有什麼缺點？爲什麼這麼糟糕，每個人都說「不要使用它，嘗試使用其他類似lock聲明」？如果我們可以使用.NET 3.5，我肯定會使用ReaderWriterLockSlim，但ReaderWriterLock我有點恐慌，所有這些警告來自任何地方。有人測量性能或其他？如果有一些性能問題，我們可以在什麼樣的有效載荷下遇到它們？

根據ReaderWriterLock的主要目的，我們有一個經典的情況，即多讀取和很少寫入。使用lock聲明會阻止所有讀者。也許這對我們來說不是一個可怕的問題，但是如果我可以使用ReaderWriterLock，我會更滿意。國際海事組織介紹幾臺顯示器的確是一個非常糟糕的主意

Answer 1

以下幾篇文章可以爲您提供您正在尋找的想法。

Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock

Rico Mariani on Using ReaderWriterLock part這篇文章解釋了一些成本和場景的使用ReaderWriterLock，還要檢查part 1和part 2

Jeffrey Richter on an alternative to ReaderWriterLock

Answer 2

如果你真的面臨ReaderWriterLock了理想的使用情況下（即許多併發讀取和少量寫入）然後使用它！

如果您發現它太慢，有替代品。 Sanjeevakumar在他的回答中提供了一些鏈接。我將在我的一個提供過：
Low-Lock Techniques in action: Implementing a Reader-Writer lock

我會從這裏鏈接引用外賣：

1. 使用讀寫鎖在我的第一篇文章建議。如果鎖定perf是一個問題，請將此實現作爲.NET System.ReaderWriterLock的「放入」替換。在Microsoft修復其庫中的版本之前，請隨意使用此實現。
2. 旋轉鎖是一種非常有價值的低鎖定技術。這裏使用的是一個乾淨，簡單而高效的讀寫器鎖，它在託管代碼中進行了很好的編寫。這個鎖比我看到的大多數實現都要簡單得多，但卻是最佳的。原因在於使用自旋鎖極大地簡化了鎖的設計和分析，而不會犧牲性能。隨意使用這裏的旋轉鎖實現展示來製作其他高性能併發結構。
3. 即使像Reader-Writer鎖那樣簡單的事情對其行爲有微妙的影響（特別是當考慮到性能問題時）。保持簡單真的在這裏得到回報。