What is a Mutex in .NET, how is it different from lock, and when would you use a named Mutex?

1. What "kernel object" means

On Windows, new Mutex(...) calls CreateMutexEx, producing a kernel object with a handle in the process's handle table. WaitOne calls a wait function (WaitForSingleObjectEx); ReleaseMutex calls ReleaseMutex. Every operation crosses into kernel mode, which is why it costs microseconds, even uncontended. lock stays in user mode unless it must block.

2. Thread affinity in practice

mutex.WaitOne();
await Task.Delay(10);       // may resume on another thread
mutex.ReleaseMutex();       // ApplicationException: "Object synchronization method was called from an unsynchronized block of code"

The original thread is still recorded as the owner. If it exits, the mutex becomes abandoned. Async code must never hold a mutex across await.

3. Holding a mutex for an app's lifetime

For single-instance apps, keep the mutex referenced (a static field) until exit. If it's only a local and the JIT/GC decides it's dead, it can be finalised and released early, allowing a second instance. GC.KeepAlive(mutex) at the end of Main or a static field avoids this.

4. Waiting on several handles

WaitHandle[] handles = [mutex, shutdownEvent];
int index = WaitHandle.WaitAny(handles, TimeSpan.FromSeconds(30));

This is one capability lock doesn't offer: wait for "lock acquired OR shutdown requested". WaitAll with a mutex in an STA thread isn't supported.

5. Security and naming

• Named objects live in a shared namespace. Use specific names (Company.Product.Purpose).
• On Windows, a hostile process could pre-create the name; for sensitive cases set ACLs (MutexAcl.Create, Windows only).
• Avoid user-controlled names.

6. Distributed alternatives

All require expiry + fencing: assume a lock holder can pause (GC, network) past its lease and design writes to be idempotent or guarded by a fencing token.

7. Version notes

8. Try it yourself

1. Run the code example twice in parallel; the second exits.
2. Start one instance, kill -9 / End Task it while a third instance blocks in WaitOne(); catch AbandonedMutexException in the third.
3. Benchmark 1 million uncontended lock vs Mutex.WaitOne/ReleaseMutex pairs.
4. Add await Task.Delay(1) between WaitOne and ReleaseMutex with ConfigureAwait(false) and observe the exception.
5. Run two Docker containers with the same mutex name and see that they don't exclude each other.
6. Use WaitHandle.WaitAny with a mutex and a ManualResetEvent for shutdown.

using System.Threading;

const string Name = @"Global\Contoso.InvoiceExporter";
using var mutex = new Mutex(initiallyOwned: false, Name);

bool owned;
try
{
    owned = mutex.WaitOne(TimeSpan.Zero); // do not wait: single instance
}
catch (AbandonedMutexException)
{
    owned = true; // we own it, but the previous owner died mid-run
    Console.WriteLine("Previous run crashed; validating output file first");
}

if (!owned)
{
    Console.WriteLine("Another exporter is running. Exiting.");
    return;
}

try
{
    Console.WriteLine("Exporting invoices...");
    Thread.Sleep(2000); // synchronous work only: the mutex is thread-affine
}
finally
{
    mutex.ReleaseMutex();
}