CSharp : Monitor - Wait,Pulse,PulseAll

Question

I am having hard time in understanding Wait(),Pulse(),PulseAll(). Will all of them avoid Deadlock ? I would appreciate if you programmatically explain how to use them?

Answer 1

Read Jon Skeet's multi-part threading article.

It's really good. The ones you mention are about a third of the way in.

Answer 2

Hello,

No, they don't protect you from deadlocks. They are just more flexible tools for thread synchronization. Here is a very good explanation how to use them and very important pattern of usage - without this pattern you will break all the things: http://www.albahari.com/threading/part4.aspx

Answer 3

They are tools for synchronizing and signaling between threads. As such they do nothing to prevent deadlocks, but if used correctly they can be used to synchronize and communicate between threads.

Unfortunately most of the work needed to write correct multithreaded code is currently the developers' responsibility in C# (and many other languages). Take a look at how F#, Haskell and Clojure handles this for an entirely different approach.

Answer 4

Short version:

lock(obj) {...}

is short-hand for Monitor.Enter / Monitor.Exit (with exception handling etc). If nobody else has the lock, you can get it (and run your code) - otherwise your thread is blocked until the lock is aquired (by another thread releasing it).

Deadlock typically happens when either A: two threads lock things in different orders:

thread 1: lock(objA) { lock (objB) { ... } }
thread 2: lock(objB) { lock (objA) { ... } }

(here, if they each acquire the first lock, neither can ever get the second, since neither thread can exit to release their lock)

This scenario can be minimised by always locking in the same order; and you can recover (to a degree) by using Monitor.TryEnter (instead of Monitor.Enter/lock) and specifying a timeout.

or B: you can block yourself with things like winforms when thread-switching while holding a lock:

lock(obj) { // on worker
    this.Invoke((MethodInvoker) delegate { // switch to UI
        lock(obj) { // oopsiee!
            ...
        }
    });
}

The deadlock appears obvious above, but it isn't so obvious when you have spaghetti code; possible answers: don't thread-switch while holding locks, or use BeginInvoke so that you can at least exit the lock (letting the UI play).

---

Wait/Pulse/PulseAll are different; they are for signalling. I use this in this answer to signal so that:

• Dequeue: if you try to dequeue data when the queue is empty, it waits for another thread to add data, which wakes up the blocked thread
• Enqueue: if you try and enqueue data when the queue is full, it waits for another thread to remove data, which wakes up the blocked thread

Pulse only wakes up one thread - but I'm not brainy enough to prove that the next thread is always the one I want, so I tend to use PulseAll, and simply re-verify the conditions before continuing; as an example:

        while (queue.Count >= maxSize)
        {
            Monitor.Wait(queue);
        }

With this approach, I can safely add other meanings of Pulse, without my existing code assuming that "I woke up, therefore there is data" - which is handy when (in the same example) I later needed to add a Close() method.