ReaderWriterLock与锁定{}


72

请说明主要区别是什么,何时应使用。
专注于Web多线程应用程序。

Answers:


71

只允许一个线程同时执行代码。ReaderWriterLock可能允许多个线程同时读取或具有独占访问权限以进行写入,因此它可能会更有效率。如果使用的是.NET 3.5,ReaderWriterLockSlim甚至更快。因此,如果您的共享资源被读取而不是被写入,请使用ReaderWriterLockSlim。一个使用它的很好的例子是一个文件(您经常在每次请求时都阅读)并且很少更新文件的内容。因此,当您从文件中读取文件时,您将输入一个读取锁,以便许多请求可以打开该文件以进行读取;而当您决定写入文件时,则输入了写入锁。lock在文件上使用基本上意味着您可以一次处理一个请求。


1
因此,您要说的是,如果第一个线程读取的是lock {}内部的值,那么其他线程无法同时读取它?
肯尼,2010年

1
恰恰是,这lock将只允许一个线程执行锁语句的主体。
达林·迪米特洛夫

5
“这样可能会更有效”:但是可能不会,您的代码也会更复杂。它应该保留给小众案例。
理查德

2
不建议使用BTW ReaderWriterLock,而推荐使用ReaderWriterLockSlim。如果选择使用其中之一,请使用后一个。
user192472 '01

4
@flq:如果您允许读取而没有先授予读取锁定(并确保在完成操作后释放读取锁定),那么您可能不知道何时可以安全地发出写入锁定,因为您将不会跟踪读取该代码块的使用者。
Brett Widmeier 2011年

21

如果您有很多需要读取数据的线程,而这些线程在等待锁时被阻塞,并且您通常不需要更改数据,请考虑使用ReaderWriterLock 。

但是,ReaderWriterLock可能会阻塞正在等待很长时间的线程。

因此,只有在确认您对“现实生活”中的锁有很高的争用并且确认不能重新设计锁设计以减少锁的持有时间之后,才使用ReaderWriterLock 。

还请考虑是否您不能宁愿将共享数据存储在数据库中并让其处理所有锁定,因为如果数据库对您的数据库足够快,这会使您很难跟踪错误。应用。

某些情况下,您也许还可以使用Aps.net缓存来处理共享数据,并且只需在数据更改时从缓存中删除该项即可。下次读取可以将新副本放入缓存中。

记得

“最好的锁定类型是不需要的锁定(即,不要在线程之间共享数据)。”


9

Monitor和可与任何引用对象关联的基础“ syncblock”(C#的基础机制)均lock支持排他执行。只有一个线程可以拥有该锁。这是简单而有效的。

ReaderWriterLock(或者在V3.5中,更好ReaderWriterLockSlim)提供了更复杂的模型。除非您知道这样做会更有效率,否则请避免使用(即通过性能测量来支持自己)。

最好的锁定类型是不需要的锁定(即,不要在线程之间共享数据)。


4
+1表示“最好的锁定类型是不需要的锁定(即,不要在线程之间共享数据)”。
伊恩·林罗斯

7

ReaderWriterLock允许您让多个线程同时持有ReadLock ...,以便共享的数据可以一次被多个线程使用。一旦请求了WriteLock,就不再授予其他ReadLock,并且等待WriteLock的代码将被阻塞,直到所有具有ReadLocks的线程都释放了它们。

WriteLock只能由一个线程持有,从代码使用部分的角度来看,您的“数据更新”看起来像是原子的。

另一方面,“锁”仅一次允许一个线程进入,而不允许仅尝试使用共享数据的线程。

ReaderWriterLockSlim是ReaderWriterLock的更高性能的新版本,它具有更好的递归支持,并且能够使线程从本质上为ReadLock的锁平稳地移动到WriteLock(UpgradeableReadLock)。


6

ReaderWriterLock / Slim是专门为帮助您有效锁定多消费者/单一生产者方案而设计的。使用lock语句可以这样做,但效率不高。RWL / S能够主动进行自旋锁定以获取锁定,从而占据了上风。这也可以帮助您避免锁护身符,这是lock语句的问题,在该语句中,线程在无法获取锁时会放弃其线程数量,从而使它落在后面,因为它不会在一段时间内重新安排时间。


2

的确,ReaderWriterLockSlim比ReaderWriterLock更快。但是ReaderWriterLockSlim的内存消耗是完全荒唐的。尝试连接内存分析器并亲自查看。我会每天都通过ReaderWriterLockSlim选择ReaderWriterLock。


3
多么离谱 您可以在对帐单上加数字吗?
user3613932 '18

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.