ReaderWriterLockSlim performance
A while ago I blogged about the performance of various thread synchronization primitives. Due to the insufficient accuracy of my memory cells, I forgot ReaderWriterLockSlim out of the comparison. Let that be fixed here and now.
The comparison method is still the same, and I have amended the previous post with the results of the Slim version. To summarize:
The Slim version performs significantly better, at approximately 34% of the time it takes for the older version ReaderWriterLock. Below is a duplication of the table containing the relative execution times from my other post. So, the ReaderWriterLockSlim beats its “full” sibling hands down, but is still considerably slower than using Interlocked, and loses somewhat to the Monitor.
| Method | Execution time |
| Non-locking | 1 |
| lock statement / Monitor | 18 |
| ReaderWriterLock | 93 |
| ReaderWriterLockSlim | 32 |
| Interlocked | 8 |
Also: The Slim version exhibits the same characteristics re lock type as the ReaderWriterLock: Acquiring a Reader lock takes the same time as acquiring a Writer one. Acquiring an Upgradeable reader lock is also equally fast, but upgrading takes roughly the same time as acquiring a full lock, putting a Read+Upgrade cycle at approximately 65 in the table above.
I strongly urge everyone to read the performance notes in the previous post before making conclusions based on these numbers. The fact that the ReaderWriterLock is slower than a lock statement doesn’t mean you should use lock statements in your real-world apps. For example, the benefit of allowing multiple simultaneous readers might well offset the slight impact of acquiring the lock.
December 29, 2009
В· 
Jouni Heikniemi В· 
2 Comments
Tags: concurrency, performance В· Posted in: .NET
2 Responses
Heikniemi Hardcoded » Performance overhead of thread synchronization - December 29, 2009
[…] in the comments section, ReaderWriterLockSlim was accidentally forgotten out of the comparison. See a separate follow-up for […]
Thread synchronization basics! « A Place for C Sharpers/.Netters - January 13, 2013
[…] http://www.heikniemi.net/hardcoded/2009/12/readerwriterlockslim-performance/ http://stackoverflow.com/questions/407238/readerwriterlockslim-vs-monitor "For write-only load the Monitor is cheaper than ReaderWriterLockSlim, however, if you simulate read + write load where read is much greater than write, then ReaderWriterLockSlim should out perform Monitor." […]
Leave a Reply