Mutex vs Monitor

Continuing our discussion from the previous section on locking and signaling mechanisms, we'll now pore over an advanced concept, the monitor. It is exposed as a concurrency construct by some programming language frameworks, including Python.

Concisely, a monitor is a mutex and then some. The additional composition of monitors consists of condition variables, which we shortly describe. Monitors are generally language-level constructs whereas mutex and semaphore are lower-level or OS-provided constructs.

To understand monitors, let's first see the problem they solve. Usually, in multi-threaded applications, a thread needs to wait for some program predicate to be true before it can proceed forward. Think about a producer/consumer application. If the producer hasn't produced anything the consumer can't consume anything. So the consumer must wait on a predicate that lets the consumer know that something has indeed been produced. What could be a crude way of accomplishing this? The consumer could repeatedly check in a loop for the predicate to be set to true. The pattern would resemble the pseudocode below:

void busy_wait_function() {
    // acquire mutex
    while (predicate is false) {
      // release mutex
      // acquire mutex
    }
    // do something useful
    // release mutex
}

Within the while loop we'll first release the mutex giving other threads a chance to acquire it, and set the loop predicate to true. Before we check the loop predicate again, we make sure we have acquired the mutex. This works but is an example of "spin waiting" which wastes a lot of CPU cycles. Let's see how condition variables solve the spin-waiting issue.

Condition Variables

Mutex provides mutual exclusion. However, at times mutual exclusion is not ...