1

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?

Ian Boyd
  • 246,734
  • 253
  • 869
  • 1,219
Andrew Davey
  • 5,441
  • 3
  • 43
  • 57

1 Answers1

1

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.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • I take the point, but the problem is that just one abort in a sensitive spot would deadlock my whole app - for example never releasing a write lock. My sites are not high traffic but the thought of a one in a million deadlock still gives me the creeps. – Andrew Davey Sep 21 '09 at 15:14
  • I'm looking into using the approach described here http://www.nobletech.co.uk/Articles/ReaderWriterLockMgr.aspx – Andrew Davey Sep 21 '09 at 15:15
  • @Andrew: That article isn't going to solve the problem, if I understand Joe's post correctly. I believe it could be an issue if an asynchronous exception is thrown *during* a lock method call. However, I would be surprised if your web site is coded so perfectly that this "one in a million" deadlock (and it's probably a *much* smaller chance than that) ended up being your biggest risk. – Jon Skeet Sep 21 '09 at 15:19
  • By the way, if this isn't a high traffic site - have you actually profiled it and checked that "normal" locking is prohibitively expensive? I wouldn't start venturing into reader/writer territory without hard numbers suggesting that a simpler full mutual exclusion policy was prolematic. – Jon Skeet Sep 21 '09 at 15:21
  • Thanks for the insightful comments Jon. I'll keep an eye on the performance (across the various sites using the library I'm developing with this code). – Andrew Davey Sep 21 '09 at 15:36