A topic in the Open Knowledge Graph — a free, open map of 15,290 topics and the order to learn them in.
A monitor is a high-level synchronization abstraction that encapsulates shared data and the procedures that operate on it, automatically enforcing mutual exclusion — only one thread executes inside the monitor at a time. Condition variables are synchronization objects used inside monitors: a thread calls wait() to release the lock and sleep until some condition holds, and another thread calls signal() (or broadcast()) to wake waiting threads. The Mesa-style semantics (used by Java, pthreads) require waiting threads to re-check their condition in a loop after waking because the condition may no longer hold. Monitors eliminate many subtle synchronization errors inherent in raw semaphore use.
Re-implement the bounded-buffer using Java synchronized methods and wait()/notifyAll(). Compare the code structure and potential for bugs against the semaphore solution.
From your work with semaphores, you know that concurrency primitives must solve two problems: mutual exclusion (only one thread in a critical section at a time) and coordination (threads waiting for conditions that other threads establish). Semaphores handle both — a binary semaphore acts as a lock, and a counting semaphore can signal between threads — but combining them for complex problems like bounded buffers requires careful, error-prone reasoning about the order of `wait()` and `signal()` operations. Monitors were invented to make this safer by raising the abstraction level.
A monitor is a language-level construct that bundles shared data with the procedures that operate on it and enforces a single rule: only one thread may be executing inside the monitor at any time. You do not write `lock.acquire()` and `lock.release()` manually — the compiler or runtime inserts them at the entry and exit of every monitor procedure. Think of it as a room with one door and a lock: when a thread enters, the door locks behind it; when it leaves, the next waiting thread can enter. This eliminates an entire class of bugs where programmers forget to release a lock or release the wrong one.
Condition variables provide the coordination mechanism inside monitors. Suppose a consumer thread enters the monitor and finds the buffer empty. It cannot simply hold the monitor lock and spin — no producer could ever enter to add an item. Instead, it calls `wait(notEmpty)`, which does two things atomically: releases the monitor lock and suspends the thread. When a producer later adds an item and calls `signal(notEmpty)`, one waiting consumer is woken up. The critical design question is what happens next. In Hoare semantics, the signaling thread immediately yields the monitor to the woken thread, guaranteeing the condition still holds when the waiter resumes. In Mesa semantics (used by Java, pthreads, and virtually all real systems), the signaling thread continues running, and the woken thread merely moves to the ready queue to compete for the monitor lock. By the time it re-enters, another thread may have consumed the item, so the condition might be false again. This is why Mesa-style code must always wait in a `while` loop: `while (buffer.isEmpty()) { wait(notEmpty); }`.
The practical payoff is visible when you compare solutions. A bounded-buffer implementation with raw semaphores requires three semaphores (mutex, empty slots, full slots) and getting their order wrong causes deadlock. The monitor version has a single monitor with two condition variables (notFull, notEmpty) and two procedures (put, get) whose logic reads almost like pseudocode: "if full, wait on notFull; insert item; signal notEmpty." The synchronization structure is explicit in the code rather than hidden in the ordering of opaque semaphore operations. This clarity is why monitors and condition variables are the preferred synchronization abstraction in modern languages and systems.