If you have ever used the System.Threading.ReaderWriterLock to achieve synchronised access to shared resources which are frequently read but infrequently updated then you probably know why we have created a new Reader/Write lock. In this MSDN Magazine’s concurrent affairs column, Jeffery Richter explains some of the short comings of the existing ReaderWriterLock in .NET Framework.
One of the hidden gems of the new .NET Framework 3.5 is a fast Reader/Writer lock called “ReaderWriterLockSlim”. If you are not familiar with this new lock then read this blog entry.
Before recommending this new lock to my customers, I wanted to see some comparisons with Monitor and the existing ReaderWriterLock. So, I devised the following comparison tests:
- Acquiring a Read lock in comparison with taking a lock using Monitor
- Acquiring a Write lock in comparison with taking a lock using Monitor
- Acquiring a Read/Write lock in comparison with taking a Read/Write lock using ReaderWriterLock
After executing the test for 1000 times, it became apparent that ReaderWriterLockSlim with no recursion support is 1.67 times slower than Monitor and it is 1.74 times slower when recursion is supported:
ReaderWriterLockSlim, in average, is 1.71 times slower than Monitor, and when recursion is supported it is 1.77 times slower.
It also turns out that acquiring a Read lock using the new slim lock class is slightly quicker than taking a Write lock.
ReaderWriterLock is significantly slower than its successor:
- Taking a ReaderWriterLockSlim Read lock is almost 3 times quicker than ReaderWriterLock
- Taking a ReaderWriterLockSlim Write lock is 2.8 times quicker than ReaderWriterLock
The table below compares both Reader/Writer locks with Monitor:
ReaderWriterLockSlim (No recursion support)
ReaderWriterLockSlim (recursion support)
PingBack from http://www.artofbam.com/wordpress/?p=5919
Considering the above results why would you recommend using ReaderWriterLockSlim instead of the Monitor?
It seems to me that the monitor is the fastest method performing synchronization of certain code blocks.
In my application I have Dictionaries which are very frequently read by a high number of threads and occasionally updated by some user. Taking into account the above results, would you still recommend using ReaderWriterLockSlim?
A reader-writer lock allows for multiple concurrent reads to enter a read-lock all at the same time and depending on the scenario, it can significantly improve the overall performance of your application when used instead of a mutual exclusive lock. A read-lock takes a shared lock and a write-lock takes an exclusive lock.
The new ReaderWriterLockSlim correctly gives priority to write requests therefore only use when reads are frequent and writes are less common.
Hope that clarifies it.
Clearly the Monitor is the preferred mechanism if you only have a couple of simultaneous reader threads. You can have hundreds of threads, the question is how many of those are going to try concurrently read the writable resource? With an average of 10 concurrent accesses, you're going to have to wait an average of 10 times longer than "slim" users. I noticed the "slim" version collects some nice metrics. You may determine you're not bottlenecking, but ironically you might not care that "slim" takes 0.7 times longer and keep using it.
very interesting, thank you. I think I will not use it!