使用 ReaderWriterLock 的真正缺点是什么

Question

我们有针对 .NET 2.0 RTM 的项目（是的，它应该是 .NET 2.0 RTM，我们有一些正统的客户端）。我只是想知道ReaderWriterLock 的缺点是什么？为什么每个人都说“不要使用它，尝试使用其他类似lock 声明”的东西那么糟糕？如果我们可以使用 .NET 3.5，我肯定会使用 ReaderWriterLockSlim，但是对于 ReaderWriterLock，我有点害怕所有这些来自各处的警告。有没有人测量性能或其他什么？如果存在一些性能问题，我们可以在什么有效负载下遇到它们？

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

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