Monitors
Imagine handing every programmer on a team raw locks and condition variables. Someone will forget to release a lock. Someone else will check a queue's length without holding the mutex first. In a large codebase with dozens of shared data structures, this is not a hypothetical — it is a certainty. The resulting bugs are the worst kind. They appear once in ten thousand runs, under load, in production. Monitors solve this by moving synchronization from a discipline you must remember to a property of the language. A monitor bundles shared data, the procedures that touch it, and the Condition Variables that coordinate waiting threads. All of this is bundled into a single syntactic unit. The compiler or runtime guarantees that at most one thread executes inside the monitor's procedures at a time. You no longer write `lock(); ...; unlock()` by hand around every access. You simply write a procedure inside the monitor, and mutual exclusion is automatic. This matters because concurrency bugs are structural, not incidental. Manual locking scatters the "same" invariant-protecting logic across every call site that touches shared state. Every call site is a chance to get it wrong. Monitors instead centralize the shared state and its protection in one place. The monitor itself becomes the single source of truth. It holds both the data and the rules that keep it consistent. This is the same design instinct behind encapsulation in object-oriented programming, applied specifically to concurrency. This article defines the monitor construct precisely. It walks through Hoare's and Mesa's semantics for signaling. It gives full pseudocode for a bounded buffer built as a monitor. It proves the mutual-exclusion and condition-variable invariants. It traces a worked execution with several threads. Finally, it previews the two canonical problems that monitors are classically used to solve. These are The Producer-Consumer Problem and The Dining Philosophers Problem.
- A monitor bundles shared data + procedures + condition variables, with the runtime enforcing mutual exclusion across all procedure calls automatically.
- Only one thread executes inside a monitor at a time; others block at the monitor's boundary, not inside the code.
- Condition variables inside a monitor implement `wait` and `signal`, but the meaning of signal differs between Hoare monitors (immediate handoff) and Mesa monitors (signal is a hint — recheck the condition).
- Practically all modern languages (Java `synchronized`, C++ `std::condition_variable` + mutex, Python's `threading.Condition`) implement Mesa-style monitors, so waiters must always re-test their condition in a `while` loop.
- Monitors don't eliminate deadlock or starvation risk — they eliminate forgetting to lock, not logic errors in what you do while locked.
- The bounded-buffer, dining-philosophers, and readers-writers problems are the standard exercises for mastering monitor-based design.
A monitor makes mutual exclusion a property the language enforces automatically, replacing scattered lock/unlock discipline with one procedure-call boundary that a thread can never accidentally cross.
The idea
A monitor is a language-level (or library-level) construct that packages three things together: a set of shared variables, a set of procedures that are the only way to touch those variables, and zero or more condition variables used to block and wake threads. The defining guarantee is mutual exclusion at the procedure boundary: at any instant, at most one thread is actively executing code inside the monitor. If a thread calls a monitor procedure while another thread is already inside, the caller blocks automatically, with no explicit lock acquisition written by the programmer. This is different from raw mutex + condition variable code in one crucial way: with raw primitives, the programmer decides which lock protects which data and must remember to acquire it before every access. With a monitor, the language ties the lock to the data structure itself — you cannot touch the monitor's private state except by calling one of its procedures, and calling a procedure implies acquiring the monitor's implicit lock. The mutual exclusion is not optional and not forgettable. Condition variables inside a monitor let a thread give up the monitor temporarily while waiting for some condition (buffer not empty, queue not full, some counter reaching zero) to become true. Calling `wait` on a condition variable atomically releases the monitor's lock and suspends the calling thread; when another thread later calls `signal` on that condition variable, one waiting thread is woken and eventually reacquires the lock before resuming. This wait/signal atomicity is exactly the piece that is fiendishly easy to get wrong with hand-rolled locks (the classic lost wakeup bug), and it is exactly what the monitor construct provides for free. Two historical semantics diverge on what "signal" means precisely:
- Hoare monitors (C. A. R. Hoare, 1974): signaling immediately transfers control and the lock to a waiting thread. The signaler blocks until the woken thread either exits the monitor or itself waits again. Under this semantics, the condition a waiter was waiting for is guaranteed still true the instant it wakes — no recheck needed, and `if` suffices instead of `while`.
- Mesa monitors (Xerox PARC, Lampson & Redell, 1980): signaling merely moves the waiter to the ready queue. The signaler keeps running and keeps the lock. The waiter must compete for the lock again later, by which time some other thread may have changed the condition. Under Mesa semantics, waiters must recheck their condition in a loop.
Virtually every mainstream language implements Mesa semantics because it is simpler to build efficiently and imposes no extra context switch on every signal. This has a direct, testable consequence for how you must write monitor code, covered below.
How it works
The mechanism has two layers: an implicit mutex around monitor procedure entry/exit, and condition variables for waiting inside the monitor.
Entry/exit protocol. When a thread calls any procedure of the monitor, the runtime acquires the monitor's lock on the thread's behalf (blocking if another thread holds it). When the procedure returns (or the thread calls `wait`), the lock is released. This is invisible in the source — you write ordinary-looking procedures, and the monitor keyword or class annotation does the locking.
Condition variables. Each condition variable `cv` supports:
- `cv.wait()` — atomically release the monitor lock and block the calling thread on `cv`; upon being woken, reacquire the lock before returning.
- `cv.signal()` — wake one thread waiting on `cv`, if any exist; if none, this is a no-op (the signal is not remembered/queued).
- `cv.broadcast()` — wake all threads waiting on `cv`.
Because Mesa semantics is the practical default, the canonical waiting idiom is a `while` loop, never an `if`: ``` procedure removeItem(): monitor.enter() # implicit; acquire monitor lock while buffer.isEmpty(): notEmpty.wait() # atomically: release lock, block; on wake, reacquire lock item = buffer.dequeue() notFull.signal() monitor.exit() # implicit; release monitor lock return item ``` Below is a complete monitor implementation of the bounded buffer — the shared data structure at the heart of the producer-consumer problem — written explicitly so every step of entry, wait, and signal is visible. ``` monitor BoundedBuffer:
# ---- shared state, private to the monitor ---- data: array[0 .. CAPACITY-1] count: integer = 0 head: integer = 0 tail: integer = 0 notFull: condition notEmpty: condition
# ---- procedures: the ONLY way to touch data/count/head/tail ---- procedure insert(item):
# entry: monitor lock acquired automatically here while count == CAPACITY: notFull.wait() # release lock, sleep; reacquire lock on wakeup data[tail] = item tail = (tail + 1) mod CAPACITY count = count + 1 notEmpty.signal() # wake one waiting consumer, if any
# exit: monitor lock released automatically here procedure remove(): while count == 0: notEmpty.wait() item = data[head] head = (head + 1) mod CAPACITY count = count - 1 notFull.signal() # wake one waiting producer, if any return item
# exit: monitor lock released automatically here ``` Every field (`data`, `count`, `head`, `tail`) is private to the monitor: no code outside `insert` and `remove` can read or write them. That is the encapsulation half of the guarantee; the mutual exclusion half is that `insert` and `remove` can never run concurrently with each other or with themselves, on any thread. The figure below shows the monitor as a single door with one room inside: threads calling any procedure queue at the entry queue; a thread that calls `wait()` steps out to a condition queue associated with that specific condition variable, giving up its exclusive occupancy of the room; a `signal()` moves a thread from a condition queue back to competing for entry.
Complexity & correctness
Time. Monitor entry/exit costs exactly what acquiring/releasing an ordinary mutex costs: O(1) in the uncontended case, and O(1) plus a possible context switch in the contended case (the blocked thread is parked, not spin-waiting, in any serious implementation). `wait()` is O(1) to enqueue onto the condition's wait queue plus the cost of one context switch out and, later, one context switch back in. `signal()`/`broadcast()` are O(1) and O(k) respectively, where k is the number of waiters woken. None of this is asymptotically different from raw mutex + condition-variable code — a monitor is a disciplined packaging of the same primitives, not a different algorithm, so it inherits their cost exactly.
Space. O(1) extra state per monitor instance (one lock, plus one wait queue per condition variable), and O(n) total across n blocked threads for the queue nodes — identical to plain condition variables.
Correctness — mutual exclusion. Let the monitor invariant I be any predicate over the shared state that every procedure is written to preserve (e.g., for the bounded buffer, "0 ≤ count ≤ CAPACITY and count equals the number of live elements between head and tail"). The construct guarantees: 1. At entry to any procedure, at most one thread holds the monitor lock — enforced by the runtime's mutex, by definition of "monitor lock." 2. `wait()` releases the lock atomically with going to sleep — no other thread can observe the caller as "inside the monitor but not holding the lock," and no signal can be lost between the check of the loop condition and going to sleep, because the check and the wait are both performed while holding the lock. 3. Therefore, if every procedure body preserves I whenever it holds the lock, I holds at every point where no thread is inside the monitor — precisely the standard partial-correctness argument for critical sections, specialized to a construct where "critical section" and "procedure body" coincide by construction. The crux of point 2 is exactly what the monitor buys you over raw primitives: a hand-written implementation of "check condition, then wait" using a separate mutex and condition variable has a race window between releasing the mutex and calling wait, during which a signal can be sent and lost forever (the lost wakeup bug). A correct monitor implementation performs the release-and-sleep as one atomic runtime operation, closing that window entirely.
Correctness — why `while`, not `if`, for the wait condition. Under Mesa semantics, `signal()` only makes a thread runnable again; it does not transfer the lock or guarantee the condition still holds by the time the woken thread actually reacquires the lock and resumes. Between the signal and the resumption, an arbitrary number of other threads may enter the monitor and change the state (e.g., another consumer could drain the buffer the signaling producer just filled). Using `while` re-establishes the loop invariant "recheck condition under the lock before proceeding" — this is not a defensive habit, it is required for correctness under Mesa semantics. Under Hoare semantics, `if` would be sufficient because the signal is the handoff, but virtually no production system implements Hoare semantics because it forces an extra mandatory context switch on every signal and complicates the scheduler (the signaler must block until the waiter either exits or waits again).
Tradeoffs. Monitors buy safety and locality of reasoning, at the cost of coarser-grained locking by default: an entire procedure holds the lock even for parts of its body that don't touch shared state, unless the programmer manually structures the code to `wait`/re-enter around expensive non-shared work. They also do not prevent deadlock — a monitor procedure that calls into another monitor (nested monitor calls) can still deadlock exactly as two raw locks can, and monitors do not automatically detect or prevent this ordering problem.
Worked example
Trace three threads against `BoundedBuffer` with `CAPACITY = 2`, starting empty (`count = 0`). Assume Mesa semantics (the practical default) and a runtime that resolves entry-queue contention in FIFO order among ready threads.
| Step | Thread | Action | Monitor state after | Notes |
|---|---|---|---|---|
| 1 | C1 (consumer) | calls `remove()`, acquires lock | count=0 | condition `count==0` true |
| 2 | C1 | `notEmpty.wait()` | count=0, C1 asleep on notEmpty | lock released atomically |
| 3 | P1 (producer) | calls `insert(A)`, acquires lock | count=0 | loop condition `count==CAPACITY` false, skips wait |
| 4 | P1 | writes data[0]=A, tail=1, count=1 | count=1 | |
| 5 | P1 | `notEmpty.signal()` | count=1, C1 moved to entry queue (Mesa: not run yet) | signal ≠ handoff |
| 6 | P1 | exits `insert`, releases lock | count=1 | |
| 7 | P2 (producer) | calls `insert(B)`, acquires lock (races C1 for lock, wins) | count=1 | |
| 8 | P2 | writes data[1]=B, tail=0, count=2 | count=2 | buffer now full |
| 9 | P2 | `notFull.signal()` — no one waiting, no-op | count=2 | signal to empty queue is a no-op, not lost — no one was waiting yet |
| 10 | P2 | exits, releases lock | count=2 | |
| 11 | C1 | finally reacquires lock, rechecks `while count==0` | count=2 | condition false now — good thing it rechecked! |
| 12 | C1 | dequeues data[0]=A, head=1, count=1 | count=1 | returns A |
| 13 | C1 | `notFull.signal()` — no one waiting, no-op | count=1 | |
| 14 | C1 | exits, releases lock | count=1 |
Step 11 is the entire point of Mesa semantics and the `while` loop. C1 was signaled once, back at step 5, when `count` had just become 1. But by the time C1 actually got the lock back, P2 had already run and pushed `count` to 2 — the state that made the signal "correct" at the moment it was sent is stale by the time C1 resumes. Had C1 used `if` instead of `while`, it would still have correctly dequeued (count=2 ≠ 0 happens to hold here), but consider a variant trace where a second consumer C2 sneaks in between steps 10 and 11 and drains the buffer to `count=0` before C1 resumes: with `if`, C1 would proceed to dequeue from an empty buffer — undefined or out-of-bounds behavior. With `while`, C1 re-checks, finds `count==0` again, and correctly goes back to sleep. This is precisely why the `while`-loop idiom is not stylistic — it is load-bearing.
Common pitfalls & traps
| Pitfall | Why it happens | Consequence |
|---|---|---|
| Using `if` instead of `while` around a condition check | Assuming Hoare (signal = handoff) semantics on a Mesa runtime | Thread wakes to a stale condition and corrupts shared state |
| Calling `wait()` without holding the monitor lock | Treating the condition variable as a free-standing object | Undefined behavior; the release-and-sleep atomicity requires holding the lock at the wait call |
| Nested monitor calls creating a lock-ordering cycle | Monitor A's procedure calls into monitor B's procedure, and vice versa on another path | Classic deadlock; monitors do not detect this automatically |
| Signaling before mutating shared state, then continuing to mutate after | Assuming signal instantly transfers control | On Mesa semantics the signaler keeps running, so this is usually fine — but code written assuming Hoare semantics breaks |
| Using `signal()` when multiple distinct wake conditions share one condition variable | One condition variable overloaded for two logically different waits | The wrong-purpose thread wakes, rechecks, finds its own condition false, and goes right back to sleep — wasted wakeup, or worse, starvation of the intended waiter if `broadcast` is needed but not used |
| Forgetting that a spurious-looking extra wakeup is expected under Mesa semantics | Not internalizing that signal is a hint, not a promise | Leads to `if`-based bugs described above |
Pioneers & history
Origins · 1 minC. A. R. Hoare and how this was discovered
Hoare formalized monitors in his 1974 paper "Monitors: An Operating System Structuring Concept," building on earlier informal ideas from Brinch Hansen and Dijkstra's work on mutual exclusion. His semantics — signal as immediate handoff — became the theoretical baseline against which all later monitor implementations, including Mesa's, are compared and contrasted.
Where this matters
Java's `synchronized` methods and blocks, combined with `Object.wait()`/`notify()`/`notifyAll()`, are a direct, mainstream implementation of the monitor concept — every `synchronized` method is a monitor procedure. C#'s `lock` statement plus `Monitor.Wait`/`Pulse` is explicitly named after this construct. POSIX threads (pthreads) expose the underlying primitives (mutex + `pthread_cond_t`) that higher-level monitor abstractions, including Python's `threading.Condition` and C++'s `std::condition_variable`, are built from — and all of them require the `while`-loop idiom because they follow Mesa semantics. Database engines and in-memory caches use monitor-style locking around buffer pools and page tables to guarantee that structural invariants (free-list consistency, reference counts) survive concurrent access. Operating system kernels use monitor-like discipline around scheduler run-queues and device driver state, even when implemented in C with explicit spinlocks rather than a language-level monitor keyword, because the pattern — bundle data with the only code allowed to touch it, guard entry, use condition variables to wait — is what actually prevents the race, independent of which language enforces it. This same pattern is the direct setup for The Producer-Consumer Problem, where a monitor-protected bounded buffer decouples producers from consumers, and for The Dining Philosophers Problem, where monitor-encapsulated fork state is the standard vehicle for demonstrating both correct mutual exclusion and the deadlock/starvation pitfalls that mutual exclusion alone does not solve.
Ask the tutor: How would you restructure the `BoundedBuffer` monitor to use a single condition variable instead of two, and what would that cost you in wasted wakeups?
Is a monitor just a mutex with extra syntax?
Not quite. A mutex only provides mutual exclusion for whatever region of code you remember to wrap in lock/unlock calls, and it says nothing about the data it protects. A monitor ties the lock to specific shared data by construction: the data is only reachable through the monitor's own procedures, so there is no code path that can touch the data without holding the lock, because such a code path doesn't exist. The monitor also bundles condition variables with atomic release-and-sleep semantics for `wait()`, closing the lost-wakeup race that a naively hand-coded mutex-plus-condition-variable pattern can fall into if the release and the sleep aren't performed as one atomic step.
Why do almost all real systems use Mesa semantics instead of Hoare's original semantics?
Hoare semantics requires that when a thread signals, it immediately hand off the lock and the CPU to a waiting thread, and the signaler itself must block until that waiter either finishes or waits again. That is a strong ordering guarantee, but it forces an extra mandatory context switch on every single signal and complicates scheduler design, since the signaler's continued execution is now entangled with the woken thread's behavior. Mesa semantics decouples signaling from scheduling: signal just marks a thread ready, and the scheduler picks who runs next using its normal policy. This is simpler and faster to implement, at the modest cost of requiring `while` loops instead of `if` statements around condition checks.
Can two threads be inside the same monitor at once if they call different procedures?
No. The mutual exclusion is at the level of the monitor as a whole, not per-procedure. If thread A is executing `insert()` and thread B calls `remove()` on the same monitor instance, B blocks at the monitor's entry until A exits (or calls `wait()`, releasing the lock). This is deliberate: two different procedures can still race on the same shared fields, so the exclusion must cover the entire monitor, not just calls to the identical procedure name.
What happens if signal() is called but no thread is waiting on that condition variable?
It is a no-op. Unlike a semaphore's `signal`/`V()` operation, which increments a counter that is remembered for a future `wait`, a condition variable's signal is not "banked" for someone who waits later. If you signal `notEmpty` when nobody happens to be waiting on it at that instant, the signal has no effect and is simply lost — this is safe precisely because the corresponding `wait()` always rechecks its condition under the lock before sleeping, so a thread never actually sleeps through a state change it needed to see; it would have found the condition already true and skipped waiting entirely.
Do monitors prevent deadlock?
No. Monitors guarantee that a single monitor's internal state is only ever touched by one thread at a time, and they close the lost-wakeup race for waiting — but they say nothing about the order in which a program acquires multiple different monitors. If procedure P in monitor A calls into monitor B while procedure Q in monitor B calls back into monitor A, you can construct the same circular-wait deadlock you'd get with two raw mutexes acquired in inconsistent order. Avoiding this requires the same discipline used for any multi-lock system: a fixed global acquisition order, or avoiding nested monitor calls entirely where possible.
How do monitors relate to the producer-consumer and dining philosophers problems?
Both are the standard exercises for practicing monitor design because both require more than plain mutual exclusion — they require threads to wait for a condition on shared state, not just lock it briefly. The producer-consumer problem needs a monitor-protected bounded buffer where producers wait on "not full" and consumers wait on "not empty," exactly the `BoundedBuffer` monitor shown here. The dining philosophers problem needs a monitor around shared fork state where each philosopher waits on a condition capturing "both my forks are free," and it is the classic setting for demonstrating that correct mutual exclusion (which a monitor gives you automatically) does not by itself prevent deadlock or starvation (which you must still design against).
Does using a monitor cost more performance than hand-rolled locking?
In the common case, no — a well-implemented monitor compiles down to the same mutex-acquire, mutex-release, and condition-variable operations you would write by hand, so the asymptotic cost is identical: O(1) uncontended, O(1) plus a context switch when contended. The overhead, if any, is a thin, usually inlined layer of bookkeeping added by the compiler or runtime, not an extra layer of indirection at every access. The real cost of monitors is coarser granularity by default: an entire procedure call holds the lock, even portions that don't touch shared state, unless the programmer deliberately restructures the code — this is a design tradeoff, not an inherent performance tax of the construct.