C# ReaderWriterLock 与锁{}

ReaderWriterLock vs lock{}

提问by kenny

Please explain what are the main differences and when should I use what.
The focus on web multi-threaded applications.

请解释主要区别是什么以及我什么时候应该使用什么。
专注于 Web 多线程应用程序。

采纳答案by Darin Dimitrov

lockallows only one thread to execute the code at the same time. ReaderWriterLockmay allow multiple threads to read at the same time or have exclusive access for writing, so it might be more efficient. If you are using .NET 3.5 ReaderWriterLockSlimis even faster. So if your shared resource is being read more often than being written, use ReaderWriterLockSlim. A good example for using it is a file that you read very often (on each request) and you update the contents of the file rarely. So when you read from the file you enter a read lock so that many requests can open it for reading and when you decide to write you enter a write lock. Using a lockon the file will basically mean that you can serve one request at a time.

lock只允许一个线程同时执行代码。ReaderWriterLock可能允许多个线程同时读取或具有写入的独占访问权限，因此它可能更有效。如果您使用 .NET 3.5 ReaderWriterLockSlim，速度会更快。因此，如果共享资源的读取频率高于写入频率，请使用ReaderWriterLockSlim. 使用它的一个很好的例子是一个你经常阅读的文件（在每次请求时），你很少更新文件的内容。因此，当您从文件中读取时，您会输入一个读锁，以便许多请求可以打开它进行读取，而当您决定写入时，您会输入一个写锁。lock在文件上使用 a基本上意味着您可以一次处理一个请求。

回答by Ian Ringrose

Consider using ReaderWriterLock if you have lots of threadsthat only need to read the dataand these threads are getting blocked waiting for the lock and and you don't often need to change the data.

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

However ReaderWriterLock may block a thread that is waiting to write for a long time.

但是 ReaderWriterLock 可能会阻塞等待写入很长时间的线程。

Therefore only use ReaderWriterLock after you have confirmedyou get high contentionfor the lock in “real life” and you have confirmed you can't redesign your locking design to reduce how long the lock is held for.

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

Also consider if you can't rather store the shared data in a database and let it take care of all the locking, as this is a lot less likely to give you a hard time tracking down bugs, iff a database is fast enough for your application.

还要考虑是否您不能将共享数据存储在数据库中并让它处理所有锁定，因为这不太可能让您很难追踪错误，如果数据库对您来说足够快应用。

In some casesyou may also be able to use the Aps.net cache to handle shared data, and just remove the item from the cache when the data changes. The next read can put a fresh copy in the cache.

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

Remember

记住

"The best kind of locking is the locking you don't need (i.e. don't share data between threads)."

“最好的锁定是你不需要的锁定（即不要在线程之间共享数据）。”

回答by Richard

Monitor and the underlying "syncblock" that can be associated with any reference object—the underlying mechanism under C#'s lock—support exclusive execution. Only one thread can ever have the lock. This is simple and efficient.

监视器和可以与任何引用对象关联的底层“同步块”（C# 下的底层机制）lock支持独占执行。只有一个线程可以拥有锁。这是简单而有效的。

ReaderWriterLock(or, in V3.5, the better ReaderWriterLockSlim) provide a more complex model. Avoid unless you knowit will be more efficient (i.e. have performance measurements to support yourself).

ReaderWriterLock（或者，在 V3.5 中，更好ReaderWriterLockSlim）提供更复杂的模型。避免，除非你知道它会更有效率（即有性能测量来支持你自己）。

The best kind of locking is the locking you don't need (i.e. don't share data between threads).

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

回答by InvertedAcceleration

ReaderWriterLock allows you to have multiple threads hold the ReadLock at the same time... so that your shared data can be consumed by many threads at once. As soon as a WriteLock is requested no more ReadLocks are granted and the code waiting for the WriteLock is blocked until all the threads with ReadLocks have released them.

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

The WriteLock can only ever be held by one thread, allow your 'data updates' to appear atomic from the point of view of the consuming parts of your code.

WriteLock 只能由一个线程持有，从代码的消耗部分的角度来看，允许您的“数据更新”看起来是原子的。

The Lock on the other hand only allows one thread to enter at a time, with no allowance for threads that are simply trying to consume the shared data.

另一方面，Lock 一次只允许一个线程进入，不允许仅仅尝试使用共享数据的线程。

ReaderWriterLockSlim is a new more performant version of ReaderWriterLock with better support for recursion and the ability to have a thread move from a Lock that is essentially a ReadLock to the WriteLock smoothly (UpgradeableReadLock).

ReaderWriterLockSlim 是 ReaderWriterLock 的性能更高的新版本，它更好地支持递归，并且能够让线程从本质上是 ReadLock 的 Lock 平滑地移动到 WriteLock (UpgradeableReadLock)。

回答by Egil Hansen

I would suggest looking through http://www.albahari.com/threading/part4.aspx#_Reader_Writer_Locks. It talks about ReaderWriterLockSlim (which you want to use instead of ReaderWriterLock).

我建议浏览http://www.albahari.com/threading/part4.aspx#_Reader_Writer_Locks。它讨论了 ReaderWriterLockSlim（您想使用它而不是 ReaderWriterLock）。

回答by Hans Passant

ReaderWriterLock/Slim is specifically designed to help you efficiently lock in a multiple consumer/ single producer scenario. Doing so with the lock statement is possible, but not efficient. RWL/S gets the upper hand by being able to aggressively spinlock to acquire the lock. That also helps you avoid lock convoys, a problem with the lock statement where a thread relinquishes its thread quantum when it cannot acquire the lock, making it fall behind because it won't be rescheduled for a while.

ReaderWriterLock/Slim 专门设计用于帮助您有效地锁定多消费者/单生产者场景。使用 lock 语句这样做是可能的，但效率不高。RWL/S 通过能够积极地自旋锁来获取锁而占据上风。这也可以帮助您避免锁护送，这是 lock 语句的一个问题，当线程无法获取锁时，它会放弃其线程量，使其落后，因为它不会被重新调度一段时间。

回答by Michael

It is true that ReaderWriterLockSlim is FASTER than ReaderWriterLock. But the memory consumption by ReaderWriterLockSlim is outright outrageous. Try attaching a memory profiler and see for yourself. I would pick ReaderWriterLock anyday over ReaderWriterLockSlim.

确实，ReaderWriterLockSlim 比 ReaderWriterLock 更快。但是 ReaderWriterLockSlim 的内存消耗是非常离谱的。尝试连接内存分析器并亲自查看。我会选择 ReaderWriterLock 而不是 ReaderWriterLockSlim。