Monitor vs WaitHandle

http://stackoverflow.com/questions/1355398/monitor-vs-waithandle-based-thread-sync

A problem with

Monitor.Pulse/Wait

is that the signal may get lost.

For example:

var signal = new ManualResetEvent(false);

// Thread 1
signal.WaitOne();

// Thread 2
signal.Set();

This will always work no matter in which the two statements in the different threads are executed. It's also a very clean abstraction and expresses very clearly your intent.

Now have a look at the same example using a monitor:

var signal = new object();

// Thread 1
lock (signal)
{
Monitor.Wait(signal);
}

// Thread 2
lock (signal)
{
Monitor.Pulse(signal);
}

Here the signal (

Pulse

) will get lost if

Pulse

is executed before

Wait

.

To fix this problem, you need something like this:

var signal = new object();
var signalSet = false;

// Thread 1
lock (signal)
{
while (!signalSet)
{
Monitor.Wait(signal);
}
}

// Thread 2
lock (signal)
{
signalSet = true;
Monitor.Pulse(signal);
}

This works and is probably even more performant and lightweight, but is less readable. And it's where the headache called concurrency starts.

Does this code really work?

In every corner case?

With more than two threads? (Hint: it doesn't)

How do you unit-test it?

A solid, reliable, readable abstraction is often better than raw performance.

Additionally, WaitHandles provide some nice stuff like waiting for a set of handles to be set, etc. Implementing this with monitors makes the headache even worse...

Rule of thumb:

Use Monitors (

lock

) to ensure exclusive access to a shared resource

Use WaitHandles (Manual/AutoResetEvent/Semaphore) to send signals between threads

扩展

http://stackoverflow.com/questions/1717194/autoresetevent-manualresetevent-vs-monitor
http://stackoverflow.com/questions/11381771/thread-sleep-vs-monitor-wait-vs-registeredwaithandle