Question

Joe Duffy's article about ReaderWriterLockSlim does not fill me with confidence!

Introducing the new ReaderWriterLockSlim in Orcas

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.

How can I safely use ReaderWriterLockSlim in ASP.NET?

Was it helpful?

Solution

Is your ASP.NET application regularly encountering thread aborts (from other threads) or trying to survive OutOfMemoryExceptions? If not, I can't see that the post is too worrying... and if it is, I'd argue you've got bigger problems.

In particular, note this bit:

There are some downsides to the new lock, however, that may cause programmers writing hosted or low-level reliability-sensitive code to wait to adopt it. Don’t get me wrong, most people really don’t need to worry about these topics, so I apologize if my words of warning have scared you off: but those that do really need to be told about the state of affairs.

Now yes, ASP.NET is "hosted", but it's not quite as severe as the SQL Server CLR hosting. I don't think you need to worry.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top