IanG continues his recent "mini-series" on locking in .NET with a post that redresses the balance a bit by pointing out when the ReaderWriterLock can be a better choice than his excellent Monitor-derived TimedLock (a whole bunch of posts track the development of this class - see Ian's blog for more details).

One point I'd like to add is that in this coarse-grained, multi-reader scenario you have to think a little about the possibility of writer-starvation, i.e. ensuring any writing processes will get a reasonable enough "bite at the cherry" so that performance is not adversely affected. Of course, even better than thinking is measuring...