The Slim Reader/Writer Lock in Orcas

time to read 3 min | 425 words

Joe Duffy has posted about the new ReaderWriterLockSlim class in oracs, everything is cool, and I am very happy to see a replacement for the ReaderWriterLock. The Dynamic Proxy library had (twice!) bugs related to the way ReaderWriterLock was used (vs. the way it ought to work), which cause it to fail under high load.

So, I was very happy, until I get to the end of the post, and I saw this:

Lastly, I mentioned there are some caveats around where this lock’s use is appropriate.  Well, there’s one, really: it’s not hardened to be reliable.  This means a few things.


Next, the lock is not robust to asynchronous exceptions such as thread aborts and out of memory conditions.  If one of these occurs while in the middle of one of the lock’s methods, the lock state can be corrupt, causing subsequent deadlocks, unhandled exceptions, and (sadly) due to the use of spin locks internally, a pegged 100% CPU.

So, I can't use this for anything that need to be reliable. Where do I usually use a lock, for multi threading scenarios, which often happens on servers, which has to be reliable. Hell, the way it sounds, using it in a web enviornment and editing the web.config is playing russian roulette*. I tried to play with in on the January CTP, but it is not there yet.

What about cross AppDomain stuff? Does it work across the AppDomains? If so, it really does need to handle AppDomain unloads, while keeping the process (and lock) safe to further use. What happens if I am using a plugins and I need to monitor rouge code and maybe kill it if it takes too long. That is a greate DoS attack against my code (actually, throwing exception from new thread or simply doing stack overflow will both do that as well).

* Okay, not fair, the CLR is supposed to handle AppDomain unload cleanly, but I am not sure whatever this holds here as well.