A Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock

Techy News Blog » A Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock

Sun, 07 Oct 2007 21:31:11 GMT

PingBack from http://www.artofbam.com/wordpress/?p=5919

re: A Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock

Robert Mircea — Mon, 14 Jan 2008 21:40:07 GMT

Hi,

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?

Thanks,

Robert

re: A Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock

pedramr — Tue, 15 Jan 2008 01:01:41 GMT

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.

Pedram

re: A Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock

Rick O'Shay — Mon, 22 Dec 2008 01:33:39 GMT

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.