views:

7463

answers:

4

What is the difference between a Monitor and a Mutex in C#?

When to use a Monitor and when to use a Mutex in C#?

+16  A: 

http://stackoverflow.com/questions/301160/what-are-the-differences-between-various-threading-synchronization-options-in-c

Monitors

lock(obj) is implemented internally using a Monitor. You should prefer lock(obj) because it prevents you from goofing up like forgetting the cleanup procedure. It 'idiot-proof's the Monitor construct if you will. Using Monitor is generally preferred over mutexes, because monitors were designed specifically for the .NET Framework and therefore make better use of resources.

Using a lock or monitor is useful for preventing the simultaneous execution of thread-sensitive blocks of code, but these constructs do not allow one thread to communicate an event to another. This requires synchronization events, which are objects that have one of two states, signaled and un-signaled, that can be used to activate and suspend threads. Mutex, Semaphores are OS-level concepts. e.g with a named mutex you could synchronize across multiple (managed) exes (ensuring that only one instance of your application is running on the machine.)

Mutex:

Unlike monitors, however, a mutex can be used to synchronize threads across processes. When used for inter-process synchronization, a mutex is called a named mutex because it is to be used in another application, and therefore it cannot be shared by means of a global or static variable. It must be given a name so that both applications can access the same mutex object. In contrast, the Mutex class is a wrapper to a Win32 construct. While it is more powerful than a monitor, a mutex requires interop transitions that are more computationally expensive than those required by the Monitor class.

http://msdn.microsoft.com/en-us/library/ms173179%28VS.80%29.aspx

joe
I agree with using lock per default, but you need to call Monitor.Enter/Exit if 1) a timeout is needed or 2) if the locking scope is not restricted to a single method for some reason.
Brian Rasmussen
As an added note, Monitors provide what are often called "condition variables" with its Wait/Pulse methods. It allows one thread to wait for something until another thread call Pulse on the monitor.
nos
+2  A: 

A Mutex can be shared across processes, and is much more heavy-weight than a Monitor.

Use a Monitor unless you need to synchronize across process boundaries.

Kim Gräsman
+1  A: 

A Monitor is managed, and more lightweight - but is restricted to your AppDomain. A Mutex can be named, and can span processes (allowing some simple IPC scenarios between applications), and can be used in code that wants a wait-handle).

For most simple scenarios, Monitor (via lock) is fine.

Marc Gravell
A: 

A good source of advice on this stuff is the "Threading in C#" by Joseph Albahari. All the content is available online. In my opinion, it's worth to read the whole book, but yo can check these parts:

Although it does not cover .NET 4.0 new parallel constructs, it's a very good starting point.

jpbochi