Mutexes and condition variables: protect a predicate

Suppose one mutex guards a queue, its item count, its capacity, and a closed flag. Every access that can conflict uses this same protection, including checks that appear harmless. A producer may append only when capacity remains and closure has not occurred. A consumer may remove only when an item exists. Describe what closed means: no future appends, while already queued items may still drain. Keeping related fields under one lock makes this multi-field invariant understandable.

Acquiring a mutex excludes other exclusive owners, and the synchronization rules connect prior protected writes to subsequent owners. Scope-based lock management helps release ownership on ordinary returns and exceptions. It does not prevent all design errors: callbacks invoked inside the critical section might acquire another lock, block on a network request, or reenter the same object. Keep the protected transition small, and decide explicitly whether moving or destroying an item may execute arbitrary application code.

A consumer acquires the mutex, checks the predicate, and waits when neither work nor closure permits progress. A condition-variable wait atomically unlocks and blocks as specified by the API, then reacquires the mutex before returning. Use a loop or the predicate overload. Waking does not reserve an item: another consumer may acquire the lock first, and spurious wakeups are allowed. The predicate must be evaluated while its associated shared state is properly protected.

A producer changes the guarded state, then notifies an appropriate waiter. Notification may occur while holding the lock or after releasing it when the surrounding lifetime and protocol are correct. The important handoff is the protected state transition and subsequent lock acquisition, not a belief that a notification accumulates as a future permit. On shutdown, update closed under the mutex and wake all classes of waiters whose predicates can now change. A bounded producer may need its own not-full condition and a closed-aware predicate.

A perfectly protected queue can still deadlock if consumers hold its mutex while waiting on a second resource needed by producers. Establish one lock order or use a suitable multi-lock operation where the contract fits; draw a wait-for graph when analyzing a failure. Do not assume a normal mutex or notify-one policy grants starvation freedom. Scheduling, critical-section duration, task behavior, and implementation details influence latency even when all state accesses are race-free.

Use the queue lab for capacity intuition only. For a growing fixed-rate run, choose Reset, explicitly set arrival to four and service to three items per second, predict the slope, then Play or Step. For a separate draining run, choose Reset again, explicitly set both rates to arrival two and service three, predict, then Play or Step from the initial four jobs. Changing a rate pauses playback but retains elapsed time and recomputes from the initial backlog; it does not preserve a prior backlog across a live rate switch. The fluid backlog is continuous and unbounded above, so it does not implement the bounded queue, notifications, a mutex, or wakeup scheduling. Its separate M/M/1 residence estimate assumes a stable stochastic model. Compare the lab's capacity warning with a real design's explicit blocking, rejection, and shutdown behavior rather than mistaking it for a correctness test.