Why doesn't Mutex get released when disposed?
Solution 1:
The documentation explains (in the "Remarks" section) that there is a conceptual difference between instantiating a Mutex object (which does not, in fact, do anything special as far as synchronization goes) and acquiring a Mutex (using WaitOne
). Note that:
-
WaitOne
returns a boolean, meaning that acquiring a Mutex can fail (timeout) and both cases must be handled - When
WaitOne
returnstrue
, then the calling thread has acquired the Mutex and must callReleaseMutex
, or else the Mutex will become abandoned - When it returns
false
, then the calling thread must not callReleaseMutex
So, there's more to Mutexes than instantiation. As for whether you should use using
anyway, let's take a look at what Dispose
does (as inherited from WaitHandle
):
protected virtual void Dispose(bool explicitDisposing)
{
if (this.safeWaitHandle != null)
{
this.safeWaitHandle.Close();
}
}
As we can see, the Mutex is not released, but there is some cleanup involved, so sticking with using
would be a good approach.
As to how you should proceed, you can of course use a try/finally
block to make sure that, if the Mutex is acquired, that it gets properly released. This is likely the most straightforward approach.
If you really don't care about the case where the Mutex fails to be acquired (which you haven't indicated, since you pass a TimeSpan
to WaitOne
), you could wrap Mutex
in your own class that implements IDisposable
, acquire the Mutex in the constructor (using WaitOne()
with no arguments), and release it inside Dispose
. Although, I probably wouldn't recommend this, as this would cause your threads to wait indefinitely if something goes wrong, and regardless there are good reasons for explicitly handling both cases when attempting an acquire, as mentioned by @HansPassant.
Solution 2:
This design decision was made a long, long time ago. Over 21 years ago, well before .NET was ever envisioned or the semantics of IDisposable were ever considered. The .NET Mutex class is a wrapper class for the underlying operating system support for mutexes. The constructor pinvokes CreateMutex, the WaitOne() method pinvokes WaitForSingleObject().
Note the WAIT_ABANDONED return value of WaitForSingleObject(), that's the one that generates the exception.
The Windows designers put the rock-hard rule in place that a thread that owns the mutex must call ReleaseMutex() before it exits. And if it doesn't that this is a very strong indication that the thread terminated in an unexpected way, typically through an exception. Which implies that synchronization is lost, a very serious threading bug. Compare to Thread.Abort(), a very dangerous way to terminate a thread in .NET for the same reason.
The .NET designers did not in any way alter this behavior. Not in the least because there isn't any way to test the state of the mutex other than by performing a wait. You must call ReleaseMutex(). And do note that your second snippet is not correct either; you cannot call it on a mutex that you didn't acquire. It must be moved inside of the if() statement body.