You are implementing a fixed-capacity buffer using a mutex plus condition variables (wait/signal). Why must a waiting thread re-check its condition in a loop rather than a single if, and when does waking only one waiter cause the system to hang?

## What a condition variable is A **condition variable** is a wait queue attached to a mutex. It offers roughly: - `wait(cv, mutex)` — atomically release `mutex` and block on `cv`; when woken, re-acquire `mutex` before returning. - `signal(cv)` / `notify` — wake **one** arbitrary waiter (if any). - `broadcast(cv)` / `notifyAll` — wake **all** waiters. The crucial part is the word *atomically* in `wait`: releasing the lock and joining the wait queue happen as one step, so a signal issued by another thread cannot slip in between and be missed. That is the whole reason condition variables exist rather than "unlock; sleep; lock". A condition variable carries **no state**. Signalling an empty wait queue does nothing at all — the signal is not remembered. All state lives in the data you protect with the mutex; the CV only says "something you care about may have changed, go look". ## The canonical bounded buffer ``` lock(m) while count == CAPACITY: # predicate loop, not if wait(notFull, m) store item; count++ signal(notEmpty) unlock(m) ``` and symmetrically for take, waiting on `notEmpty` and signalling `notFull`. ## Why the loop, reason 1: the wakeup is a hint, not a guarantee Signalling does not transfer the lock or the state. Timeline with three threads and a full buffer: ``` C1: take() -> count-- (now CAPACITY-1) -> signal(notFull) -> unlock P1: wakes from wait, must now re-acquire m ... still queued P2: arrives fresh, acquires m first, fills the slot, count == CAPACITY P1: finally acquires m ``` If P1 used `if`, it would proceed to write into a full buffer — overwriting an item, corrupting the count, or blowing an assertion. With `while`, P1 re-tests, sees the buffer full again, and goes back to waiting. This is called **Mesa semantics**: the signaller keeps running and the state may change before the waiter resumes. Essentially every real runtime uses Mesa semantics; the alternative (Hoare semantics, where the lock and state are handed directly to the waiter) is a textbook construct. ## Why the loop, reason 2: spurious wakeups Most platforms explicitly permit `wait` to return without any corresponding signal — a consequence of how futexes and POSIX threads interact with signals and internal restarts. A single `if` therefore has a latent bug even in code where no other thread could have raced. The loop makes the code immune to both causes at zero design cost, which is why the predicate loop is a hard rule rather than a style choice. ## The lost-wakeup hang from waking one waiter Suppose you economise and use a **single** condition variable for both waiting reasons — producers and consumers all block on `cv` — plus `signal` (wake one). Capacity 1, one item present, two producers blocked because the buffer is full, one consumer arrives: ``` buffer: [x] waiting on cv: P1, P2 C1: take() -> count = 0 -> signal(cv) -> wakes P1 -> unlock P1: re-tests: count(0) != CAPACITY, proceeds, puts y, count = 1 signal(cv) -> wakes P2 P2: re-tests: count(1) == CAPACITY -> waits again ``` Now no one is running, an item is available, and no consumer is waiting — fine so far. But run the mirror case: several consumers blocked on empty, one producer puts an item and signals; the wakeup lands on another *consumer* only in a healthy system. The failure is when a waiter that cannot make progress consumes the signal and goes back to sleep: the notification is gone forever, because condition variables do not remember signals. The buffer holds work, a thread that could take it is asleep, and nothing will ever wake it. That is a **lost wakeup**, and it is a genuine deadlock — no timeout, no error, just a stalled pipeline. ## The two correct fixes 1. **Two condition variables, `signal` each.** `notFull` holds only producers, `notEmpty` holds only consumers. A signal on `notEmpty` can only reach a thread that can actually proceed. This is the standard, and it is the cheap option. 2. **One condition variable, `broadcast` always.** Correct because every waiter re-tests its predicate, so the one that can proceed will. Cost: a **thundering herd** — with N waiters you wake all N, they all contend for the mutex, N-1 re-test and sleep again. O(N) context switches per operation instead of O(1). Mixing them (one CV plus `signal`) is the classic bug. Note also that even with two CVs you may need `broadcast` if waiters wait on *different* predicates over the same variable — for example a buffer where `put` can add a variable number of items, so a signal aimed at a waiter needing 3 slots may reach one needing 5. ## Multi-producer / multi-consumer notes All of the above is unchanged with many threads on each side; the pattern is inherently MPMC because the mutex serialises access. What changes is contention: with many threads, the single mutex becomes the bottleneck and every operation costs a context switch on the critical path. That is the motivation for lock-splitting (separate head and tail locks, so a producer and a consumer can work simultaneously) or array-based ring buffers with atomic index claims — a different implementation, same external contract.