I've got a simple .NET program, which checks to see if another instance has been started:
Mutex mutex = new Mutex(false,"MyMutexName");
if (!mutex.WaitOne(1))
return;
try{
//do stuff
}
catch{ //exceptions}
finally
{
mutex.ReleaseMutex();
}
My question is, what exactly happens to the mutex if you forget to release it when the program ends? Is it visible in some windows control panel component? Where does it live?
It is a named mutex so it is visible and can be opened in other processes. Windows uses a simple reference count on the handle. If you don't Dispose() it explicitly yourself then the finalizer will close the handle for you. If your program bombs hard and never executes the finalizer then Windows will do it when it cleans up the resources used by your program.
That will automatically decrement the reference count. If that counts down to zero (no other processes have a handle open on it) then the kernel object is released.
In other words: you don't have a problem no matter how badly things turn out. The actual mutant object lives in the kernel memory pool. You can see it with the SysInternals' WinObj tool.
From MSDN
If a thread terminates while owning a mutex, the mutex is said to be abandoned. The state of the mutex is set to signaled and the next waiting thread gets ownership. If no one owns the mutex, the state of the mutex is signaled. Beginning in version 2.0 of the .NET Framework, an AbandonedMutexException is thrown in the next thread that acquires the mutex. Prior to version 2.0 of the .NET Framework, no exception was thrown.
Caution
An abandoned mutex often indicates a serious error in the code. When a thread exits without releasing the mutex, the data structures protected by the mutex might not be in a consistent state. The next thread to request ownership of the mutex can handle this exception and proceed, if the integrity of the data structures can be verified.
In the case of a system-wide mutex, an abandoned mutex might indicate that an application has been terminated abruptly (for example, by using Windows Task Manager).
Mutexes are OS-level handles. They'll get closed when your process does (if you don't close them sooner, that is.)
edit
Ok, I clearly misunderstood the example and the question. If you're just trying to detect whether another instance exists, you'd create a named mutex (or similar object) and simply check for its existence without ever locking on it.
The call to WaitOne
locks on it, taking ownership, while ReleaseMutex
gets rid of it (so long as there are no additional calls to WaitOne
). If you end the thread without releasing the mutex fully, it does leave the object in a bad state, as explained in the text Micah quotes.
I took your question as being about whether you close the handle before the process completes, which is another thing entirely.
additional
At the SDK [API][1] level, you can call CreateMutex
with the expectation of failing when a mutex of the same name has already been created. In .NET (well, in 4.0, at least), there's a [constructor][2] that fills a createdNew
bool.
[1]: http://msdn.microsoft.com/en-us/library/ms682411(VS.85).aspx CreateMutex
[2]: http://msdn.microsoft.com/en-us/library/bwe34f1k(v=VS.90).aspx Mutex
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With