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