Monitor vs WaitHandle

http://*.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://*.com/questions/1717194/autoresetevent-manualresetevent-vs-monitor
http://*.com/questions/11381771/thread-sleep-vs-monitor-wait-vs-registeredwaithandle