【问题标题】:Optimized ReaderWriterLock Read Access优化 ReaderWriterLock 读取权限
【发布时间】:2009-10-16 15:23:53
【问题描述】:

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

那么,如何做到这一点,或者更好的是,有没有可以指出我的框架或“标准”实现? (或者如果我误解了它已经被支持了,太好了!)

所以对于我的作品: 似乎如果有一个读取器/写入器数量的计数器(受 Interlocked.Increment 保护),这足以让读取器检查写入器计数是否非零,然后才获取锁. (如果获得,则在锁内递增。)

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

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

【问题讨论】:

    标签: c# .net synchronization readerwriterlockslim


    【解决方案1】:

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

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

    【讨论】:

    • 谢谢格雷格,你说得对。我拔出反射器,它使用 Interlocked.CompareExchange 在获取锁之前进行检查。干杯!
    【解决方案2】:

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-12-21
      • 2014-10-07
      • 2013-11-27
      • 2018-09-21
      相关资源
      最近更新 更多