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

I have a coworker that was burned twice in one day by surprises while using text encodings with the .NET Framework. He was working with files that were meant to be encoded as UTF-8, but were accidentally encoded in code page 1252.

First, he wanted to decode a text document as UTF-8, knowing that there might be invalid UTF-8 characters and hoping to detect that fact somehow. Logically, he used Encoding.UTF8; unfortunately, that seemed to quietly remove invalid characters. Nor did creating a new instance of UTF8Encoding work – until he discovered the constructor with two Booleans, the second of which causes an exception to be thrown if an invalid character is found... (Let me take this opportunity to express my dislike of Boolean parameters to methods and constructors. I hope that the .NET Framework API designers discontinue this practice in the future; an enumerated type would be far more appropriate.)

Second, he wanted to use StreamReader to decode a text document with code page 1252, knowing that it might look like UTF-8. Logically, he created a StreamReader with the constructor that takes a file name and an Encoding object – he used Encoding.GetEncoding("windows-1252") as the encoding, but eventually he realized that the documents were actually being decoded as UTF-8. Ultimately, he discovered the StreamReader constructor with an additional Boolean parameter, which specifies whether or not to allow a byte order mark to override the encoding.

Things like this can take a while to track down, so I post them here in the hopes that readers will avoid similar confusion.

The latest article in MSDN Magazine on the new C++/CLR syntax and support explains in great detail why I'm so looking forward to Visual Studio 2005. I love the .NET Framework, I love C++, and the new stuff looks to provide me a beautiful integration of the two. Question is, once it is released, will I ever code in C# again?