ReaderWriterLock vs lock{}

Question

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

Darin Dimitrov · Accepted Answer · 2010-01-22T12:01:59.680

78

lock allows only one thread to execute the code at the same time. ReaderWriterLock may 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 ReaderWriterLockSlim is 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 lock on the file will basically mean that you can serve one request at a time.

edited Jan 22 '10 at 12:01

answered Jan 22 '10 at 11:51

Darin Dimitrov

1,023,142
271
3,287
2,928

1

so what you are saying is that if first thread reads a value that is inside lock{} no other thread can read it in the same time? – kenny Jan 22 '10 at 11:53
1

Exactly, `lock` will allow one and only one thread to execute the body of the lock statement. – Darin Dimitrov Jan 22 '10 at 11:54
5

"so it might be more efficient": but probably won't be and your code will be more complex. It should be reserved for niche cases. – Richard Jan 22 '10 at 11:56
Yes, performing stress testing and measuring is a good way to know for sure. – Darin Dimitrov Jan 22 '10 at 11:59
If you *just* wish to cache a file in memory, it is likely that the Asp.net cache would be a better solution, with a refresh policy setup so your object is removed from the cache when the file changes. – Ian Ringrose Jan 22 '10 at 12:02
2

BTW ReaderWriterLock is deprecated in favour of ReaderWriterLockSlim. If you chose to use one of them, use the latter one. – user192472 Jan 22 '10 at 12:03
Stupid question: If the read lock allows concurrent access to a resource, why do I have to use any kind of locking? Could I not allow reads without any locking? – flq May 25 '10 at 13:37
@Frank, this will depend on whether the shared resource allows concurrent readers. If it does then of course you don't need to lock. But remember that even basic things like enumerating a collection is not thread safe. – Darin Dimitrov May 25 '10 at 14:00
4

@flq: If you allow reads without first granting a read lock (and making sure to release your read lock when you are done), then you may not know when it is safe to issue a write lock because you will not be tracking the read consumers of the code block in question. – Brett Widmeier Jun 24 '11 at 19:51
1

It is very important to note that the performance cost of a `ReaderWriterLockSlim` over a regular `lock`. Even when you get a read lock, it is slower than a vanilla lock. Therefore, if your critical section is fast, it is preferable to use a vanilla lock. References: [1](https://blogs.msdn.microsoft.com/pedram/2007/10/07/a-performance-comparison-of-readerwriterlockslim-with-readerwriterlock/) and [2](http://kenegozi.com/blog/2010/08/15/readerwriterlockslim-vs-lock). – user3613932 Oct 24 '18 at 01:15

score 22 · Answer 2 · edited Jan 11 '13 at 09:14

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

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

Therefore only use ReaderWriterLock after you have confirmed you get high contention for 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.

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 cases you 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.

Remember

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

How many is "lots of threads" ? – Anand Undavia Dec 28 '22 at 07:03 — Anand Undavia, Dec 28 '22 at 07:03

score 9 · Answer 3 · answered Jan 22 '10 at 11:55

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.

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

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

+1 for "The best kind of locking is the locking you don't need (i.e. don't share data between threads)." — Ian Ringrose, Jan 22 '10 at 12:00

InvertedAcceleration · Answer 4 · 2010-01-22T12:06:23.430

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.

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.

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.

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).

score 6 · Answer 5 · answered Jan 22 '10 at 12:20

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.

score 2 · Answer 6 · answered May 22 '13 at 10:19

2

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.

answered May 22 '13 at 10:19

Michael

21
1

4

How outrageous? Can you add numbers to your statement? – user3613932 Oct 22 '18 at 20:48

score 2 · Answer 7 · edited Oct 22 '18 at 23:55

2

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).

edited Oct 22 '18 at 23:55

user3613932

1,219
15
16

answered Jan 22 '10 at 12:01

Egil Hansen

15,028
8
37
54

ReaderWriterLock vs lock{}

7 Answers7

Linked

Related