使用 ReaderWriterLock 的真正缺点是什么

Question

我们有一个针对.NET 2.0 RTM 的项目（是的，它应该是.NET 2.0 RTM，我们有一些正统的客户）。我只是想知道 ReaderWriterLock？为什么它如此糟糕以至于每个人都告诉“不要使用它，尝试使用其他东西，比如 lock 语句”？如果我们可以使用.NET 3.5，我肯定会使用 ReaderWriterLockSlim，但是有了 ReaderWriterLock，我对来自四面八方的所有这些警告感到有点害怕。有人测量性能或其他什么吗？如果存在一些性能问题，在什么负载下我们会遇到这些问题？

就 ReaderWriterLock 的主要用途而言，我们有一个典型的情况，即多次读取而很少写入。使用 lock 语句会阻止所有读取器。也许这对我们来说不是一个可怕的问题，但如果我可以使用 ReaderWriterLock 我会更满意。在我看来，引入多个显示器确实是一个非常非常糟糕的主意。

Answer 1

以下几篇文章可以为您提供您正在寻找的想法。

性能ReaderWriterLockSlim 与 ReaderWriterLock 的比较

Rico Mariani 使用ReaderWriterLock 部分 这篇文章解释了使用 ReaderWriterLock 的一些成本和场景，另请查看 第 1 部分 和 第 2 部分

Jeffrey Richter 探讨 ReaderWriterLock 的替代方案

Answer 2

如果您确实面临 ReaderWriterLock 的理想用例（即许多并发读取和少量写入），那么请使用它！

如果您发现它太慢，还有其他选择。 Sanjeevakumar 在他的回答中提供了一些链接。我也会提供一份：
低锁技术实际应用：实现读写锁

我将在这里引用该链接的要点：

1. 按照我第一篇文章中的建议使用读写锁。如果锁定性能存在问题，请采用此处的实现作为 .NET System.ReaderWriterLock 的“直接”替代。在 Microsoft 修复其库中的版本之前，请随意使用此实现。
2. 自旋锁是一种非常有价值的低锁技术。这里用来制作一个干净、简单但高效的读写锁，完全用托管代码编写。这个锁比我见过的大多数实现要简单得多，但也接近最佳。原因是自旋锁的使用极大地简化了锁的设计和分析，而不会牺牲性能。请随意使用此处显示的自旋锁实现来创建其他高性能并发构造。
3. 即使是像读写锁这样简单的东西，其行为也有微妙之处（特别是当您考虑性能问题时）。保持简单在这里确实有回报。