使用ReaderWriterLock的真正缺点是什么？

Question

我们有针对.NET 2.0RTM的项目(是的，它应该是.NET 2.0RTM，我们有一些正统的客户端)。我想知道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. 使用我在第一篇文章中建议的读取器-写入器锁。如果锁性能有问题，可以将这里的实现作为.NET System.ReaderWriterLock的“直接”替代。在微软修复其库中的版本之前，请随意使用此实现。
2. 自旋锁是一种非常有价值的低锁技术。这里使用它来创建一个干净、简单但高效的读取器-写入器锁，它用托管代码编写得很好。这个锁比我见过的大多数实现都要简单得多，但也是最优的。这样做的原因是，使用旋转锁大大简化了锁的设计和分析，而不会牺牲性能。可以随意使用这里展示的自旋锁实现来创建其他高性能的并发构造。
3. 甚至像读写器锁这样简单的东西也有其行为的微妙之处(特别是当您考虑到性能问题时)。保持简单在这里是值得的。