Suppose I have the following code:
public class SomeClass()
{
private readonly object _lock = new object();
public void SomeMethodA()
{
lock
If you need this under .NET 4.5 see the accepted answer from @Dave .
However, if you need this under .NET 3.5 or 4, you could replace the use of Monitor locks for a ReaderWriterLockSlim as follows.
According to Joeseph Albahari this will approximately double your (uncontested) locking overhead, but it is still really fast (est. 40nS). (Disclaimer, that page does not state if the tests were done using a recursive lock policy.)
public class SomeClass()
{
private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim(LockRecursionPolicy.SupportsRecursion);
public void SomeMethodA()
{
_lock.EnterWriteLock();
try
{
SomeHelperMethod();
//do something that requires lock on _lock
}
finally
{
_lock.ExitWriteLock();
}
}
private void SomeHelperMethod()
{
Debug.Assert(_lock.IsWriteLockHeld);
//do something that requires lock on _lock
}
}
If you feel that is too non-performant you can of course write your own wrapper class around Monitor locks. However, other posts have mentioned a boolean flag which is misleading as the question is not "Is the lock held by any thread?" (which is a foolish and dangerous question to ask). The correct question is "Is the lock held by THIS thread?". No problem though, just make the 'flag' a ThreadLocal counter(for recursive lock support) and ensure updates are done after Monitor.Enter and before Monitor.Exit. As an improvement assert that the counter does not drop below 0 on "unlock" as that would indicate unbalanced Enter/Exit calls.
Another reason for the wrapper would be to avoid having someone slip in _lock.EnterReadLock calls. Depending on the usage of the class those might actually be helpful, but a surprising number of coders do not understand Reader-Writer Locks.