使用ReaderWriterLock的真正缺点是什么?
本文关键字：缺点 是什么 ReaderWriterLock 使用 | 更新日期: 2023-09-27 17:50:09
我们有一个针对。net 2.0 RTM的项目(是的，它应该是。net 2.0 RTM，我们有一些正统的客户端)。我想知道ReaderWriterLock的缺点是什么?为什么每个人都告诉"不要用它，试着用其他的东西，比如lock声明"?如果我们可以使用。net 3.5，我肯定会使用ReaderWriterLockSlim，但是对于ReaderWriterLock，我有点害怕所有这些来自四面八方的警告。有人衡量过业绩吗?如果有一些性能问题，我们会在什么有效载荷下遇到它们?
在ReaderWriterLock的主要目的方面，我们有一个经典的情况，即多次读，很少写。使用lock语句会阻塞所有的读取器。也许这对我们来说不是一个可怕的问题，但如果我可以使用ReaderWriterLock，我会更满意。在我看来，引进几个监视器确实是一个非常非常糟糕的主意。
以下几篇文章可以为你提供你正在寻找的想法。
ReaderWriterLockSlim与ReaderWriterLock的性能比较
Rico Mariani on Using ReaderWriterLock部分这篇文章解释了使用ReaderWriterLock的一些成本和场景，也可以查看第1部分和第2部分
Jeffrey Richter谈ReaderWriterLock的替代方案
如果你真的面临ReaderWriterLock的理想用例(即多并发读和少并发写)，那么使用它!
如果你发现它太慢了，还有其他选择。Sanjeevakumar在他的回答中提供了一些链接。我也会提供一个:
低锁技术的应用:实现读写锁
我将在这里引用该链接的要点:
- 按照我第一篇文章中的建议使用读写锁。如果锁性能是一个问题，把这里的实现作为。net System.ReaderWriterLock的"临时"替代。在Microsoft在其库中修复此版本之前，您可以随意使用此实现。
- 自旋锁是一种非常有价值的低锁技术。这里使用了一个干净、简单但高效的读写锁，完全用托管代码编写。这个锁比我见过的大多数实现要简单得多，但也接近于最优。这样做的原因是，使用自旋锁大大简化了锁的设计和分析，而不会牺牲性能。您可以随意使用此处展示的自旋锁实现来创建其他高性能并发结构。
- 即使是像读写锁这样简单的东西，其行为也有微妙之处(特别是当您考虑性能问题时)。在这里，保持简单是值得的。