Condition Variable

A condition variable is a synchronization object that lets a task sleep until a protected predicate may have changed. It is used when ownership of a mutex is not the event being waited for. The task is waiting for a state condition, such as “queue not empty”, “space available”, “configuration loaded” or “shutdown requested”.

Condition variables appear in operating systems, concurrent services, embedded gateways, device drivers, producer-consumer pipelines and worker pools. They are useful only when the predicate, mutex and notification rule are designed together.

Protected Predicate

Let the shared state be:

and the condition being waited for be:

The predicate must be checked while holding the associated mutex. The condition variable does not store the truth of the predicate. It only coordinates sleeping and waking around state changes.

Wait Loop

A correct wait is usually a loop:

The loop matters because wakeups can be spurious, multiple waiters can race after one notification, and the predicate can become false again before a woken task reacquires the mutex. Treating one wakeup as proof that the condition is true is a common correctness bug.

Atomic Release and Sleep

The wait operation must release the mutex and enter sleep as one atomic protocol. If release and sleep are separated incorrectly, the notifying task may signal between those operations. The waiter then sleeps after the signal has already happened.

That failure is a lost wakeup. In event terms, if the signal time is:

and the task actually starts waiting at:

then a lost-wakeup risk exists when:

Correct condition-variable implementations close this window by combining unlock, waiter registration and sleep in the runtime or kernel.

Signal and Broadcast

A signal wakes one waiter. A broadcast wakes all current waiters. Let waiter count be:

and useful waiters after a state change be:

A broadcast can create unnecessary wakeups:

If many waiters wake and immediately contend for the same mutex, the result can look like a thundering herd. Broadcast is appropriate when many waiters may now proceed, or when the implementation cannot know which waiter needs the condition.

Timeout and Deadline

Condition-variable waits should respect the caller’s useful deadline. For wait time:

remaining service time:

and recovery or cleanup allowance:

the caller deadline screen is:

The margin is:

An indefinite wait is rarely acceptable for request paths, safety monitors or control gateways unless another supervisor can detect and recover the stalled task.

Worked Wait Check

A telemetry worker waits for a buffer-not-empty predicate. The caller deadline is:

The maximum allowed condition wait is:

After waking, parsing and forwarding require:

Cleanup or degraded-mode handoff requires:

The total path is:

The deadline margin is:

The wait timeout is acceptable only with a small margin. A broadcast storm, mutex convoy, scheduler delay or slow downstream dependency can consume that margin.

Boundary With Semaphores

A semaphore counts permits or events. A condition variable waits for a predicate protected by shared state. A semaphore can be enough for simple item counts. A condition variable is often clearer when several fields define readiness, such as queue not empty, no shutdown flag, and available memory. The predicate should remain the source of truth.

Failure Modes

Common failure modes include checking the predicate outside the mutex, using if instead of a wait loop, lost wakeups, missed notifications, broadcast wakeup storms, indefinite waits without timeout, cancellation while holding the mutex, notifying before publishing state, and failing to retest the predicate after waking.

Validation Evidence

Useful evidence includes waiter counts, wait-time distribution, timeout counters, signal and broadcast traces, spurious-wakeup tests, cancellation tests, shutdown tests, stress runs with many waiters, mutex hold-time traces and predicate-invariant checks. The test should also force notification before, during and after waiter registration so lost-wakeup assumptions are exercised. A release claim should show that no accepted path can sleep beyond its deadline without recovery.