What are the real downsides of using ReaderWriterLock

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 Read开发者_运维知识库erWriterLockSlim, 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

Jeffrey Richter on an alternative to ReaderWriterLock

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.