我查看了.NET 2.0中的ReaderWriterLock和.NET 3.5中的ReaderWriterLockSlim,而slim版本不使用内核对象进行锁定。对于我的上下文,它可能会产生大量(但不是很大)的对象,这听起来更好。
但是我编写的代码需要在过渡期间在.NET 2.0和3.5中使用,因此3.5版本虽然看起来很适合我的目的,但却无法使用。
是否有人拥有或知道类似的类,我可以插入.NET 2.0并获得一些相同的好处?
答案 0 :(得分:5)
据我所知,没有一个来自微软(否则ReaderWriterLockSlim
会有点毫无意义)如果你找到一个来自第三方的人而不是你信任的第三方优秀的花了很长时间思考,实施和测试它的人,我不相信它。我当然不会相信随机的CodeProject实现,例如。
您是否有任何具体措施建议使用ReaderWriterLockSlim
如此更好,以至于值得寻找.NET 2.0的替代品?这肯定是“很高兴”,但我怀疑它大规模显着的情况相对罕见。除非你已经知道锁定对你来说是个瓶颈,否则我会坚持你所拥有的东西,并且随时准备升级。
你可能想尝试使用普通显示器而不是ReaderWriterLock
- 在很多情况下,RWL的开销超过了好处。
当然,这一切都是根据具体情况而定的 - 你的应用程序可能是ReaderWriterLockSlim
真正做得更快,更快的应用程序......
答案 1 :(得分:1)
No hard lock ReadWriteLocker - 此类是基于ReaderWriterLock Alternative设计的,比ReaderWriterLock快20%-30%。
我所做的不同之处是:
- 通过在read内嵌套写锁来支持升级锁 锁。 与ReaderWriterLock不同,升级锁是线程安全的。
- 有示例集合,向您展示如何设计线程安全 集合。 它们不如.NET 4.0的PFX集合那么高效,但它们还有其他好处。
- 如果启动的所有锁都已解锁,则无法死锁。然后 所有其他 锁定机制与该锁定器互斥。
- 能够检测死锁并关闭死锁检测开销, 一旦你确认死锁没有发生。
- 高度递归,并且更强大 比ReaderWriterLock和ReaderWriterLockSlim。
醇>
我已经花了很多工作,我希望它有用。到目前为止,这是非常新的,需要对其他锁定机制进行测试。当然,一切都是.NET 2.0投诉。
答案 2 :(得分:0)
PowerThreading库中的ReaderWriterGate
呢?
答案 3 :(得分:0)
我问了一个关于使用ReaderWriterLock
的缺点的问题,并且有一些有趣的链接包含ReaderWriterLock
的替代方法。看看answer to my question。