What are the real downsides of using ReaderWriterLock

Question

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.

Eatables

Answer 1

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

Whereabouts

Answer 2

If you are really facing the ideal use case for ReaderWriterLock (i.e. many concurrent reads and few writes) then use it!

If you find it is too slow there are alternatives. Sanjeevakumar provided some links in his answer. I'll provide one in mine too:
Low-Lock Techniques in action: Implementing a Reader-Writer lock

I'll quote the takeaways from that link here:

1. Use reader-writer locks as suggested in my first article. If lock perf is a problem, take the implementation here as a 'drop in' replacement for the .NET System.ReaderWriterLock. Feel free to use this implementation until Microsoft fixes the version in its library.
2. Spin-locks are a really valuable low lock technique. There were used here to make a clean, simple but efficient reader-writer lock written competely in managed code. This lock is significantly simpler than most implementations I have seen, yet is clost to optimal. The reason for this is that the use of spin locks GREATLY simplifies the design and analysis of the lock, without sacrificing performance. Feel free to use the Spin lock implementation show here to make other high performance concurrent constructs.
3. Even something as simple as a Reader-Writer lock has subtleties about its behavior (especially when you factor in performance concerns). Keeping it simple really pays off here.

Abadan

Well, I'm not very sure that it is an ideal case. We don't have a lot of threads simultaneously reading and writing from shared resource. I mean that we don't have 100 or 200 or 500 threads, it's about 15-20 threads. I'll try to go with a simple lock statement and if we face the problem of multiple locks I'll try using ReaderWriterLock or look into alternatives. – Eatables