Free lesson · Operating Systems

Monitors A Higher Level Abstraction

Easy11 min readoperating-systemsosconcurrency

The Problem with Low-Level Primitives

You now know the three fundamental synchronization building blocks: mutexes, semaphores, and condition variables. They are powerful, but they are also dangerous. They require the programmer to manually acquire and release locks in the right order, signal and wait on condition variables at the right moments, and maintain the right discipline across every piece of code that touches shared data. One mistake - a forgotten unlock, a missing signal, a lock acquired in the wrong order - and the program deadlocks, corrupts data, or hangs.

The problem gets worse as programs grow. In a small program with one shared resource and two threads, keeping the locking correct is manageable. In a large system with dozens of shared resources, hundreds of threads, and code written by multiple developers over years, the chance that every single lock acquisition and release is correct across every code path drops rapidly toward zero.

A monitor is a higher-level synchronization abstraction that packages a mutex, one or more condition variables, and the shared data they protect into a single unit. The monitor guarantees that only one thread can execute any of its procedures at a time - mutual exclusion is automatic, not manual. The programmer defines what the shared data is and what operations are allowed on it. The monitor handles the locking.

Monitors were proposed by C.A.R. Hoare in 1974 and Per Brinch Hansen around the same time. They remain one of the most successful ideas in concurrent programming - Java's synchronized keyword is a monitor implementation, and every thread-safe class you have used in Java, Python, or C# is conceptually a monitor even if the language does not use that term.

What a Monitor Is

A monitor is a software module that encapsulates three things:

Shared data - the variables that multiple threads need to access. These variables are private to the monitor - no thread can access them directly. The only way to read or modify the shared data is through the monitor's procedures.

Procedures (methods) - the operations that threads can perform on the shared data. These are the monitor's public interface. The monitor guarantees that at most one thread executes any procedure at any time. When a thread calls a monitor procedure, it implicitly acquires the monitor's lock. When the procedure returns, the lock is implicitly released.

Condition variables - used inside monitor procedures to wait for specific conditions. A thread that calls wait on a condition variable inside a monitor releases the monitor's lock and goes to sleep. When another thread calls signal on that condition variable, a waiting thread is woken up and re-acquires the monitor's lock.

The key insight is that mutual exclusion is structural, not manual. The programmer does not write lock.acquire() and lock.release(). The monitor's structure guarantees that every procedure executes under mutual exclusion. The only coordination the programmer handles is the wait/signal logic for condition variables - and even that is simpler inside a monitor because the lock management is automatic.

graph TD
    subgraph MONITOR["Monitor: BoundedBuffer"]
        subgraph PRIVATE["Private Shared Data"]
            BUF["buffer[]"]
            COUNT["count"]
        end
        
        subgraph PROCS["Public Procedures<br/>(only one thread at a time)"]
            PUT["put(item)"]
            GET["get() → item"]
        end
        
        subgraph CVS["Condition Variables"]
            NF["notFull"]
            NE["notEmpty"]
        end
    end
    
    T1["Thread 1"] -->|"calls put()"| PUT
    T2["Thread 2"] -->|"calls get()"| GET
    T3["Thread 3"] -->|"calls put() - BLOCKED<br/>(Thread 1 is inside)"| MONITOR
    
    PUT -.->|"if full: wait(notFull)"| NF
    GET -.->|"if empty: wait(notEmpty)"| NE
    PUT -.->|"signal(notEmpty)"| NE
    GET -.->|"signal(notFull)"| NF

This diagram shows the structure of a monitor called BoundedBuffer. Inside the monitor are three sections: private shared data (the buffer array and a count variable), public procedures (put and get - only one thread can execute inside any procedure at a time), and condition variables (notFull and notEmpty). Thread 1 is executing put inside the monitor. Thread 2 is executing get inside the monitor - but in practice only one can be inside at a time; they take turns. Thread 3 is trying to call put but is blocked because Thread 1 is already inside. The put procedure waits on notFull if the buffer is full and signals notEmpty after adding an item. The get procedure waits on notEmpty if the buffer is empty and signals notFull after removing an item.

Monitor Semantics: Hoare vs Mesa

When a thread inside a monitor calls signal on a condition variable, a sleeping thread is woken up. But now there are two threads that want to be inside the monitor - the signaler (which is currently executing) and the woken thread (which was waiting). Only one can be inside the monitor at a time. Which one gets to continue?

This question defines the two major monitor semantics:

Hoare Monitors (Signal-and-Wait)

In Hoare semantics, the signaler immediately gives up the monitor to the woken thread. The signaler is suspended, and the woken thread resumes execution inside the monitor. After the woken thread leaves the monitor (or waits again), the signaler continues.

Advantage: The condition is guaranteed to be true when the woken thread resumes. There is no gap between the signal and the woken thread's execution, so no other thread can change the condition in between. The woken thread does not need to re-check the condition - an if statement is sufficient instead of a while loop.

Disadvantage: The signaler must be suspended and later resumed, adding two context switches. The implementation is more complex because the monitor must manage a "signaler queue" in addition to the "entry queue" and the condition variable queues.

Mesa Monitors (Signal-and-Continue)

In Mesa semantics (named after the Xerox Mesa language where they were first implemented), the signaler continues executing inside the monitor after calling signal. The woken thread is moved from the condition variable's wait queue to the monitor's entry queue - it will enter the monitor when the signaler leaves (or when some later thread leaves), but not immediately.

Advantage: Simpler implementation. The signaler does not need to be suspended. No extra context switches. More efficient in practice.

Disadvantage: By the time the woken thread actually enters the monitor, the condition might have changed - another thread might have entered the monitor and modified the shared data between the signal and the woken thread's execution. This is why Mesa monitors require the while loop for waiting. The woken thread must re-check the condition because it might no longer be true.

Almost all real systems use Mesa semantics. Java's synchronized and wait/notify, Python's threading.Condition, POSIX pthread_cond_wait, and Go's sync.Cond all use Mesa semantics. This is why every condition variable tutorial insists on the while loop - it is a direct consequence of Mesa monitor semantics.

graph TD
    subgraph HOARE["Hoare: Signal-and-Wait"]
        H1["Thread A signals"] --> H2["Thread A suspended"]
        H2 --> H3["Thread B wakes up<br/>Condition guaranteed true<br/>if check is sufficient"]
        H3 --> H4["Thread B finishes or waits"]
        H4 --> H5["Thread A resumes"]
    end
    
    subgraph MESA["Mesa: Signal-and-Continue"]
        M1["Thread A signals"] --> M2["Thread A continues executing"]
        M2 --> M3["Thread A eventually leaves monitor"]
        M3 --> M4["Thread B wakes up<br/>Condition might be false<br/>while loop required"]
    end

This diagram compares Hoare and Mesa monitor semantics. In Hoare semantics, when Thread A signals, Thread A is immediately suspended and Thread B wakes up with the condition guaranteed to be true. After Thread B finishes or waits again, Thread A resumes. In Mesa semantics, Thread A signals but continues executing. Thread A eventually leaves the monitor. Only then does Thread B wake up, and because other threads might have modified the shared data between the signal and Thread B entering the monitor, Thread B must re-check the condition using a while loop.

Monitors in Java

Java is the most widely used language that has monitors built directly into the language. Every Java object is a monitor - it has an implicit lock and supports wait(), notify(), and notifyAll() through the synchronized keyword.

Using synchronized

When you declare a method as synchronized, the method body is a monitor procedure. The JVM automatically acquires the object's lock when the method is entered and releases it when the method returns (even if it returns via an exception).

public class BoundedBuffer<T> {
    private final Object[] buffer;
    private int count = 0;
    private int putIndex = 0;
    private int getIndex = 0;
    
    public BoundedBuffer(int capacity) {
        buffer = new Object[capacity];
    }
    
    // Monitor procedure - automatic mutual exclusion
    public synchronized void put(T item) throws InterruptedException {
        while (count == buffer.length) {
            wait();                    // Release monitor lock + sleep
        }
        buffer[putIndex] = item;
        putIndex = (putIndex + 1) % buffer.length;
        count++;
        notifyAll();                   // Wake all waiters
    }
    
    // Monitor procedure - automatic mutual exclusion
    @SuppressWarnings("unchecked")
    public synchronized T get() throws InterruptedException {
        while (count == 0) {
            wait();                    // Release monitor lock + sleep
        }
        T item = (T) buffer[getIndex];
        buffer[getIndex] = null;
        getIndex = (getIndex + 1) % buffer.length;
        count--;
        notifyAll();                   // Wake all waiters
        return item;
    }
    
    public synchronized int size() {
        return count;
    }
}

This is the same bounded-buffer logic from the condition variable and semaphore topics, but the code is cleaner. There are no explicit lock() and unlock() calls. The synchronized keyword handles mutual exclusion. The wait() and notifyAll() calls handle condition synchronization. The entire class is a monitor.

Limitations of Java's Built-In Monitors

Java's synchronized mechanism has a significant limitation: each object has only one implicit condition variable. All calls to wait() wait on the same condition, and all calls to notify() and notifyAll() signal the same condition.

In the bounded buffer above, producers waiting for "not full" and consumers waiting for "not empty" share the same wait queue. When notifyAll() is called, all of them wake up - even if only one condition changed. This causes unnecessary wakeups and context switches.

Java's java.util.concurrent.locks.ReentrantLock with explicit Condition objects solves this. You can create multiple conditions on the same lock, enabling targeted signaling:

public class EfficientBoundedBuffer<T> {
    private final Lock lock = new ReentrantLock();
    private final Condition notFull = lock.newCondition();   // Separate condition
    private final Condition notEmpty = lock.newCondition();  // Separate condition
    
    // ... buffer data ...
    
    public void put(T item) throws InterruptedException {
        lock.lock();
        try {
            while (isFull()) notFull.await();    // Wait on specific condition
            addItem(item);
            notEmpty.signal();                    // Signal only consumers
        } finally {
            lock.unlock();
        }
    }
    
    public T get() throws InterruptedException {
        lock.lock();
        try {
            while (isEmpty()) notEmpty.await();   // Wait on specific condition
            T item = removeItem();
            notFull.signal();                     // Signal only producers
            return item;
        } finally {
            lock.unlock();
        }
    }
}

Monitors in Other Languages

Python

Python does not have monitors as a language keyword, but threading.Condition provides the same functionality. A Condition object wraps a Lock and provides wait(), notify(), and notify_all() methods. A class that uses a Condition to protect its internal state is a monitor in everything but name.

class MonitorQueue:
    """A bounded queue implemented as a monitor."""
    def __init__(self, capacity):
        self._queue = []
        self._capacity = capacity
        self._condition = threading.Condition()
    
    def put(self, item):
        with self._condition:                  # Enter monitor
            while len(self._queue) >= self._capacity:
                self._condition.wait()          # Wait: not full
            self._queue.append(item)
            self._condition.notify_all()        # Signal: state changed
    
    def get(self):
        with self._condition:                  # Enter monitor
            while len(self._queue) == 0:
                self._condition.wait()          # Wait: not empty
            item = self._queue.pop(0)
            self._condition.notify_all()        # Signal: state changed
            return item

Go

Go does not have monitors in the language, and the Go community generally prefers channels over shared-memory synchronization. But when shared-memory synchronization is needed, sync.Mutex combined with sync.Cond provides monitor functionality.

C#

C# has the lock keyword (equivalent to Java's synchronized) and Monitor.Wait()/Monitor.Pulse() (equivalent to wait()/notify()). Like Java, every object in C# can be used as a monitor.

Why Monitors Matter for Interviews

Monitors appear in interviews in three ways:

Conceptual questions. "What is a monitor? How does it differ from a mutex?" The answer: a monitor is a structured abstraction that bundles a mutex, condition variables, and shared data into a single unit with automatic mutual exclusion. A mutex is just the lock - the programmer must manually manage when to acquire and release it. A monitor makes mutual exclusion structural rather than manual.

Java-specific questions. "Explain how synchronized works in Java." The answer: synchronized makes the object a monitor. The JVM acquires the object's intrinsic lock when a synchronized method is entered and releases it on exit. wait() releases the lock and sleeps. notify() wakes one waiter. notifyAll() wakes all waiters. This is Mesa-monitor semantics, so waiters must re-check their condition in a while loop.

Design questions. "Design a thread-safe bounded buffer." The monitor pattern is the cleanest answer - define the shared data (buffer, count, indices), the public operations (put, get), and the condition variables (not full, not empty). Explain why you use while instead of if for waiting. Discuss the tradeoff between notify() and notifyAll().

Interview: "What is a monitor and how does it relate to Java's synchronized?"

"A monitor is a synchronization abstraction that combines shared data, procedures that operate on it, and condition variables - all under automatic mutual exclusion. Only one thread can execute inside the monitor at a time. The programmer does not manually lock and unlock - the structure guarantees it.

Java's synchronized keyword implements monitors. Every Java object has an intrinsic lock and a wait set. A synchronized method or block acquires the intrinsic lock on entry and releases it on exit. wait() atomically releases the lock and sleeps. notify() and notifyAll() wake waiting threads, which re-acquire the lock before continuing.

Java uses Mesa semantics - the signaler continues executing, and the woken thread must re-check its condition because another thread might modify the data between the signal and the wakeup. This is why wait() must always be called in a while loop."

Follow-up: "What is the disadvantage of Java's built-in monitors?"

"Each object has only one implicit condition variable. All waiters share the same wait queue, so notifyAll() wakes threads that might not care about the condition that changed. For better efficiency, you can use explicit Lock and Condition objects from java.util.concurrent.locks, which allow multiple condition variables on the same lock."

Monitors vs Manual Lock-and-Condition-Variable

The monitor pattern and the manual mutex-plus-condition-variable pattern achieve the same result. The difference is in how the programmer interacts with them:

For most application-level synchronization, the monitor pattern is preferred because it reduces the chance of mistakes. For systems-level or performance-critical code where you need fine-grained control over lock granularity, manual locks and condition variables give you more options.

The practical advice is: start with a monitor (or the monitor pattern). Switch to manual locks only when profiling shows the monitor's coarser granularity is a bottleneck. In most applications, it never is.

Exercise: Starter: Implement a thread-safe counter in Python using the monitor pattern. The class should have increment(), decrement(), and get_value() methods, all protected by a single threading.Condition. Add a wait_for_zero() method that blocks the calling thread until the counter reaches zero. Test it with threads that increment and decrement randomly, and a main thread that waits for zero.

Intermediate: Implement a Readers-Writers monitor in Java using synchronized, wait(), and notifyAll(). The monitor should have start_read(), end_read(), start_write(), and end_write() methods. Multiple readers can be inside simultaneously, but a writer must have exclusive access. Implement the writers-preferred variant where a waiting writer blocks new readers. Test with 6 reader threads and 2 writer threads.

Advanced: Implement the Dining Philosophers problem using a monitor. The monitor has pickup_forks(philosopher_id) and putdown_forks(philosopher_id) methods. A philosopher can only pick up both forks simultaneously (no partial acquisition - this prevents deadlock). Use a condition variable per philosopher: a philosopher waits on their own condition variable until both adjacent forks are available. When a philosopher puts down their forks, they signal the condition variables of their left and right neighbors. Test with 5 philosophers each eating 10 times.

Back to Operating Systems