using System;
using System.Threading;

namespace NobleTech.Products.Library
{
class ReaderWriterLockMgr : IDisposable
{
private ReaderWriterLockSlim _readerWriterLock = null;
private bool _isDisposed = false;
private enum LockTypes { None, Read, Write }
LockTypes _enteredLockType = LockTypes.None;

public ReaderWriterLockMgr(ReaderWriterLockSlim ReaderWriterLock)
{
_readerWriterLock = ReaderWriterLock;
}

public void EnterReadLock()
{
_readerWriterLock.EnterReadLock();
_enteredLockType = LockTypes.Read;
}

public void EnterWriteLock()
{
_readerWriterLock.EnterWriteLock();
_enteredLockType = LockTypes.Write;
}

public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
if (!_isDisposed)
{
if (disposing)
{
switch (_enteredLockType)
{
case LockTypes.Read:
_readerWriterLock.ExitReadLock();
break;
case LockTypes.Write:
_readerWriterLock.ExitWriteLock();
break;
}
}
}

_isDisposed = true;
}
}
}

I want to warn you for the given solution. There is a subtle bug that can occur during asynchronous exceptions (read: thread abort exceptions). The problem is that there is a time frame between “m_Lock.EnterReadLock();” statement in the constructor and the start of the try statement. When a async exception happens in this time frame, the finally will never run and the “m_Lock.ExitReadLock();” will therefore not run either. This could then lead to a deadlock.

Note that the C# lock() statement (or in fact the Monitor.Enter call) doesn’t have this problem, because the JIT has a specific optimization for this that eliminates the time frame. Your simple ‘using’ statement doesn’t have this ‘feature’ and therefore, you’ll need another way to protect yourself against this. You should consider to write code like this:

using (var locker = LockAcquirer(theLock))
{
// Because the lock is acquired within the
// try..finally, the operation is safe from
// async exceptions.
locker.AcquireReadLock();

// access the shared state for reading here
}

From an usability perspective, this proposal is actually less pleasing, because users may forget to call AcquireReadLock() leaving your code open for race conditions. And if you really need to be this paranoid, of course depends on your system requirements and the frequency that async exceptions occur. Some hosts are pretty aggressive about killing threads (like ASP.NET and SQL Server).

Joe Duffy wrote an amazing article about this almost two years ago. You can read it here:
http://www.bluebytesoftware.com/blog/CommentView,guid,d9ff204a-a8a5-400e-bcbc-dedb90a7d11a.aspx
And as you could imagine, in response to Joe’s blog, I wrote about it too: http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=21