Menu
We have project targeted .NET 2.0 RTM (yes, it should be .NET 2.0 RTM, we have some orthodox clients). And I'm just wondering what are the downsides of ReaderWriterLock? Why is it so bad that everyone tell "don't use it, try to use something else like lock statement"? If we could use .NET 3.5, I would definitely use ReaderWriterLockSlim, but with ReaderWriterLock I'm a little scary with all these warning coming from everywhere. Does anybody measured performance or whatever? If there are some performance issues, under what payload can we encounter them?
We have a classic situation in terms of ReaderWriterLock main purpose, i.e. multiple reads and rarely writes. Using lock statement would block all readers. Perhaps it's not an awful issue for us, but if I could use ReaderWriterLock I would be more satisfied. IMO introducing several monitors is a very very bad idea indeed.
453
The ReaderWriterLock class is used to synchronize access to a resource. At any given time, it allows concurrent read access to multiple (essentially unlimited) threads, or it allows write access for a single thread. The . NET Framework provides several threading locking primitives.
ReaderWriterLockSlim Class (System.Threading) Represents a lock that is used to manage access to a resource, allowing multiple threads for reading or exclusive access for writing.
Following few posts can provide you the ideas you are looking for.
Performance Comparison of ReaderWriterLockSlim with ReaderWriterLock
Rico Mariani on Using ReaderWriterLock part this post explains some of the costs and scenarios to use ReaderWriterLock, also check part 1 and part 2
Jeffrey Richter on an alternative to ReaderWriterLock
169
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
