Ian Griffiths' article on preferring Monitor to ReaderWriterLock is a great reminder to avoid complex solutions when simpler solutions will do nicely. My natural tendency would be to use a ReaderWriterLock rather than a Monitor any time I had data that would support multiple reader threads, but Ian reminds me that there's another factor at play here – contention. If contention is unlikely – that is, if multiple threads reading the same data would be a rare occurrence – a Monitor is better because it is faster and simpler than a ReaderWriterLock. Premature optimization strikes again...

Far more disturbing was this little tidbit: “Also, remember that most of the classes in the .NET Framework aren't written to be safe even for read-only use – most of them are documented as being safe only for access on one thread at a time.” I must confess that I had assumed that most classes in the .NET Framework had been written to be safe for read-only use among multiple threads. Fortunately, things are not as grim as Ian makes them sound, at least from my perspective; from the MSDN documentation (emphasis mine): “By default, Collections classes are generally not thread safe. Multiple readers can read the collection with confidence; however, any modification to the collection produces undefined results for all threads that access the collection, including the reader threads.” Whew! Still, it is a good reminder to check the thread safety of any classes I'm using for data storage before making any assumptions...