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

Question

我们的项目针对.NET 2.0 RTM（是的，应该是.NET 2.0 RTM，我们有一些正统的客户）。我想知道ReaderWriterLock有什么缺点？为什么每个人都说“不要使用它，尝试使用其他东西，如lock语句”？如果我们能使用.NET 3.5，我肯定会使用ReaderWriterLockSlim，但使用ReaderWriterLock时，我有点担心到处都有这些警告。是否有人测量过性能或其他方面的问题？如果存在性能问题，在什么负载下会遇到它们？

我们的情况符合ReaderWriterLock的主要目的，即多次读取和很少写入。使用lock语句将阻止所有读取。也许对我们来说这不是一个可怕的问题，但如果我可以使用ReaderWriterLock，我会更加满意。在我看来，引入几个监视器确实是一个非常非常糟糕的想法。

- Dmitrii Lobanov

Answer 1

以下几篇文章可以为您提供所需的想法。

使用ReaderWriterLockSlim与ReaderWriterLock的性能比较

Rico Mariani关于使用ReaderWriterLock的部分本文解释了一些使用ReaderWriterLock的成本和场景，还要检查第一部分和第二部分

Jeffrey Richter关于替代ReaderWriterLock的方案

- Sanjeevakumar Hiremath

Answer 2

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

如果您发现它太慢了，那么有一些替代方案。Sanjeevakumar在他的答案中提供了一些链接。我也会在我的答案中提供一个链接：
Low-Lock Techniques in action: Implementing a Reader-Writer lock

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

1. 如我第一篇文章所建议的那样，使用读写锁。如果锁的性能是一个问题，可以将此实现作为.NET System.ReaderWriterLock的“插入式”替代品。在微软修复其库中的版本之前，可以随意使用此实现。 2. 自旋锁是一种非常有价值的低级锁技术。它们被用于编写完全托管代码的干净、简单但高效的读写锁。这个锁比我见过的大多数实现都要简单得多，但接近最优。原因在于自旋锁的使用极大地简化了锁的设计和分析，而不会牺牲性能。可以随意使用此处展示的自旋锁实现来创建其他高性能并发结构。 3. 即使像读写锁这样简单的东西也有关于其行为的微妙之处（特别是当考虑到性能问题时）。在这里保持简单确实会带来回报。

- Justin Waugh

---

嗯，我不太确定这是否是一个理想的情况。我们没有很多线程同时从共享资源读取和写入。我的意思是，我们没有100、200或500个线程，只有大约15-20个线程。我将尝试使用简单的“lock”语句，如果我们遇到多个锁的问题，我将尝试使用“ReaderWriterLock”或寻找替代方案。 - Dmitrii Lobanov