1

所以我的理解是，在 ReaderWriterLock（或者更具体地说是 ReaderWriterLockSlim）上，读取和写入都需要获取互斥锁来获取锁。我想优化锁的读取访问，这样如果没有挂起的写入，就不需要获取锁。（而且我愿意牺牲写入的性能，对读取添加一些约束，使第一次读取慢，第二次读取快等等。如果有必要，只要绝大多数读取尽可能快。 )

那么，如何做到这一点，或者更好的是，是否有一个框架或“标准”实现可以指向我？（或者如果我误解了它已经被支持了，太好了！）

所以对于我的文章：似乎如果有一个读者/作者数量的计数器（受 Interlocked.Increment 保护），这足以让读者检查作者计数是否非零，并且然后才获取锁。（如果获得，则在锁内递增。）

编写器总是递增、获取锁、旋转直到读者计数变为 0（愿意假设读者总是快速完成，甚至在乐观的情况下完全绕过读者计数），最后递减。（当我们阻塞时，也可以设置某种形式的优先级，或者可能一次性清除所有待处理的读取器/写入器，因为我只保护一个值，但我现在会放弃它......）

所以..有人见过类似的东西或有什么建议吗？如果一段时间后没有任何内容，我很乐意将初始实现放在一起并更具体地进行讨论。

4

2 回答 2

3

您所描述的是，在基本层面上，读/写锁已经是如何工作的。他们不需要取出互斥锁，因为读取器/写入器锁通过使用读取器和写入器的内部计数来控制访问（实际上，互斥锁意味着读取器会相互阻塞，而实际上多个并发读取器是允许——这就是锁类型的重点！）。

所以是的，有一个框架/标准实现：ReaderWriterLockSlim. 我真的怀疑您是否能够编写性能比这更好的读/写锁。无论如何——你确定这个锁是你性能问题的根源吗？

于 2009-10-16T15:33:49.890 回答
-2

恐怕你错了，因为 ReaderWriterLockSlim 是基于自旋锁定，而不是互斥锁（你可以在 Reflector 中看到这一点）。

于 2009-10-16T15:34:55.487 回答