Operating SystemsCondition Variables

Condition Variables: Synchronization for Complex Coordination

LevelIntermediate

Duration75 mins

TopicCondition Variables

4 / 5

Relationship to Mutex

The Inseparable Partnership

Condition variables and mutexes are inseparable partners in the dance of synchronization. Unlike semaphores, which are self-contained synchronization primitives, condition variables cannot function alone. Every condition variable operation—especially wait—requires an associated mutex.

But why this marriage? What makes condition variables so dependent on mutexes that they cannot exist independently?

The answer lies in the fundamental problem condition variables solve: waiting for a predicate on shared state. The predicate involves shared data. Shared data requires mutual exclusion. Therefore, checking and modifying the predicate must happen while holding a lock. The condition variable provides the wait-and-signal mechanism; the mutex provides the protection for the predicate.

In this page, we'll explore this relationship in depth—why it exists, how to maintain it correctly, what happens when it's violated, and advanced patterns that leverage it for elegant concurrent code.

What You Will Learn

By the end of this page, you will understand: why condition variables require mutexes; the invariants that must hold for correct operation; common violations and their consequences; proper pairing patterns; and how different languages handle the CV-mutex relationship.

Why the Pairing is Fundamental

To understand why condition variables require mutexes, let's trace through the logic step by step.

Step 1: You're waiting for shared state to reach a certain condition.

Example: "buffer is not empty" or "worker threads are all idle."

Step 2: To check the condition, you must read shared state.

Reading count > 0 or idle_workers == total_workers accesses shared variables.

Step 3: Reading shared state without synchronization is a data race.

If another thread modifies count while you read it, you get undefined behavior.

Step 4: Therefore, you need a lock when checking the condition.

The mutex provides this protection.

Step 5: If the condition is false, you need to wait.

But you can't hold the mutex while waiting—that would prevent anyone from modifying the state to make the condition true.

Step 6: You must release the mutex when you wait.

This allows other threads to acquire it and modify the state.

Step 7: After waking up, you must re-check the condition.

Mesa semantics and spurious wakeups mean the condition might not be true.

Step 8: Re-checking requires holding the mutex again.

The wait operation must re-acquire the mutex before returning.

Conclusion:

The mutex is integral to the entire wait pattern. The condition variable merely provides the block-and-wake mechanism; the mutex provides the protection for the predicate.

pairing_necessity.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// This code demonstrates why the mutex is inseparable
 
// The predicate involves shared state
int count;          // Shared!
pthread_mutex_t mutex;
pthread_cond_t cond;
 
void waiter(void) {
    pthread_mutex_lock(&mutex);       // MUST lock to read count
    
    while (count == 0) {              // Check predicate (reads count)
        
        // Inside wait:
        // 1. Release mutex (so others can modify count)
        // 2. Block until signaled
        // 3. Re-acquire mutex (so we can safely re-check count)
        
        pthread_cond_wait(&cond, &mutex);
        
        // Back here: we hold mutex, can safely check count
    }
    
    // count > 0, we hold mutex, safe to proceed
    count--;                          // Modify shared state
    
    pthread_mutex_unlock(&mutex);
}
 
// Every step requires the mutex:
// - Reading count to check predicate
// - Modifying count when proceeding
// - Re-checking count after wakeup

The Core Insight

The condition variable provides wait/signal. The mutex protects the predicate. Together they enable safe waiting for shared state conditions. Neither is useful for this purpose without the other.

The Invariants That Must Hold

For condition variables to work correctly, several invariants must be maintained. Violating any of them leads to bugs ranging from data races to deadlocks.

Invariant 1: The mutex must be held when calling wait.

This is the most critical invariant. The wait operation releases the mutex and reacquires it. If you don't hold it initially:

invariant1_violation.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
// WRONG: Wait without holding mutex
 
void buggy_waiter(void) {
    // Forgot to lock mutex!
    
    pthread_cond_wait(&cond, &mutex);  // UNDEFINED BEHAVIOR
    
    // Possible outcomes:
    // - Crash
    // - Deadlock
    // - Silent corruption of internal state
    // - Sometimes appears to work (worst case!)
}

Invariant 2: The same mutex must be used consistently with a condition variable.

Once you pair a mutex with a condition variable, all operations must use that pairing:

invariant2_violation.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// WRONG: Using different mutexes with the same condition variable
 
pthread_mutex_t mutex1, mutex2;
pthread_cond_t cond;
 
void thread_a(void) {
    pthread_mutex_lock(&mutex1);
    while (!ready) {
        pthread_cond_wait(&cond, &mutex1);  // Uses mutex1
    }
    pthread_mutex_unlock(&mutex1);
}
 
void thread_b(void) {
    pthread_mutex_lock(&mutex2);
    while (!done) {
        pthread_cond_wait(&cond, &mutex2);  // Uses mutex2 - BUG!
    }
    pthread_mutex_unlock(&mutex2);
}
 
// This is undefined behavior. POSIX says:
// "The effect of using more than one mutex for concurrent
//  pthread_cond_wait() or pthread_cond_timedwait() operations
//  on the same condition variable is undefined."

Invariant 3: The predicate must be protected by the same mutex.

The state checked in the while condition must be protected by the mutex passed to wait:

invariant3_violation.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// WRONG: Predicate protected by different mutex
 
pthread_mutex_t mutex_a, mutex_b;
pthread_cond_t cond;
int shared_value;  // Protected by mutex_b, not mutex_a!
 
void broken(void) {
    pthread_mutex_lock(&mutex_a);
    
    while (shared_value == 0) {       // Reads state protected by mutex_b!
        pthread_cond_wait(&cond, &mutex_a);  // Releases mutex_a, not mutex_b
    }
    
    // This is a data race on shared_value
    pthread_mutex_unlock(&mutex_a);
}

Condition Variable Invariants
Invariant	Requirement	Consequence of Violation
Hold mutex on wait	Call wait() only while holding the mutex	Undefined behavior, crashes, deadlock
Consistent mutex	Always use same mutex with a given CV	Undefined behavior, lost wakeups
Predicate protection	Mutex must protect all predicate state	Data races, checking stale values
Hold mutex on check	Check predicate only while holding mutex	Race between check and wait

The Wait-and-Hold Dance

The interaction between condition variables and mutexes during wait is a carefully choreographed dance. Let's trace through exactly what happens:

wait_dance_trace.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// Detailed trace of mutex ownership during wait
 
void waiter_detailed(void) {
    // T0: Thread holds NO locks
    
    pthread_mutex_lock(&mutex);
    // T1: Thread holds mutex
    
    while (!condition) {
        // T2: Still holds mutex, about to wait
        
        pthread_cond_wait(&cond, &mutex);
        // Inside wait():
        // T3: Added to wait queue (still holds mutex momentarily)
        // T4: Mutex released atomically with entering wait queue
        // T5: Thread is blocked (holds NO locks)
        // ... time passes, other threads run ...
        // T6: Signaled! Thread is woken
        // T7: Thread tries to reacquire mutex (may block again)
        // T8: Mutex acquired!
        // T9: Returns from wait()
        
        // T10: Holds mutex again, will loop and recheck
    }
    
    // T11: Condition is TRUE, holds mutex
    do_work();
    
    pthread_mutex_unlock(&mutex);
    // T12: Holds NO locks
}

Key observations:

At T5, the thread holds no locks. This is essential—if it held the mutex, no other thread could modify the condition.
T6-T8 involves two types of blocking. First, the thread blocks on the condition variable. Then, after being signaled, it may block again waiting for the mutex.
The mutex acquisition at T8 may not be immediate. Other threads might hold the mutex when the signaled thread wakes.
Between T6 and T10, the state may change. This is why while-loop checking is mandatory.

Two Potential Blocking Points

A thread calling cond_wait() may block twice: first waiting for the signal, then waiting for the mutex. This can be surprising to programmers who expect a 'signaled' thread to immediately proceed.

Choosing Your Mutex Type

Not all mutexes are created equal. POSIX defines several mutex types, and your choice affects condition variable behavior.

PTHREAD_MUTEX_NORMAL (default):

The basic mutex type. Undefined behavior if locked twice by the same thread.

PTHREAD_MUTEX_RECURSIVE:

Can be locked multiple times by the same thread. Must be unlocked the same number of times. Works with condition variables, with caveats:

recursive_mutex_cv.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Recursive mutex with condition variable - CAUTION REQUIRED
 
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
 
pthread_mutex_t rmutex;
pthread_mutex_init(&rmutex, &attr);
 
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
 
void recursive_function(int depth) {
    pthread_mutex_lock(&rmutex);  // Lock count = depth
    
    if (depth > 0) {
        recursive_function(depth - 1);
    } else {
        while (!ready) {
            // WARNING: cond_wait releases ALL lock levels
            // Not just one! This may surprise you.
            pthread_cond_wait(&cond, &rmutex);
            // On return, all levels are restored
        }
    }
    
    pthread_mutex_unlock(&rmutex);
}
 
// The behavior with recursive mutexes and CVs is:
// cond_wait() releases the mutex fully (lock count -> 0)
// On return, the full lock count is restored
// Most implementations support this, but it's tricky

PTHREAD_MUTEX_ERRORCHECK:

Returns an error (instead of undefined behavior) for programming errors like double-locking from the same thread. Good for debugging.

Reader-Writer Locks:

POSIX reader-writer locks (pthread_rwlock_t) do NOT work with standard condition variables. If you need CV-like semantics with reader-writer locks, you need a more complex design.

Prefer Normal Mutexes for CVs

Unless you have a specific reason to use recursive mutexes, prefer normal mutexes with condition variables. The semantics are simpler and the code is easier to reason about. Recursive mutexes often indicate a design problem.

Mutex Types with Condition Variables
Mutex Type	CV Compatible?	Behavior on Wait
PTHREAD_MUTEX_NORMAL	Yes	Standard semantics
PTHREAD_MUTEX_RECURSIVE	Yes*	*Fully releases, restores on return
PTHREAD_MUTEX_ERRORCHECK	Yes	Same as normal, with error checking
pthread_rwlock_t	No	Not supported with pthread_cond

Static vs. Dynamic Association

In POSIX threads, the association between a condition variable and its mutex is dynamic—you pass the mutex as a parameter to each wait call. Other languages use static associations.

POSIX (Dynamic Association):

posix_dynamic.c
C
1
2
3
4
5
6
7
8
9
10
// POSIX: Mutex passed explicitly to each wait call
 
pthread_mutex_t mutex;
pthread_cond_t cond;
 
// The association is made at each call site
pthread_cond_wait(&cond, &mutex);  // Pair cond with mutex
 
// Technically, you could use different mutexes (but shouldn't)
// The relationship is not enforced by the type system

Java (Static Association with Lock):

java_static.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Java with Lock interface: Static association
 
Lock lock = new ReentrantLock();
Condition notEmpty = lock.newCondition();  // Created FROM lock
Condition notFull = lock.newCondition();   // Also from same lock
 
lock.lock();
try {
    while (isEmpty()) {
        notEmpty.await();  // No lock parameter - it's implicit!
    }
} finally {
    lock.unlock();
}
 
// The Condition is permanently tied to its Lock
// You cannot await on notEmpty while holding a different lock
// This prevents the "different mutex" bug at compile time

Rust (Static Association with Type System):

rust_static.rs
Rust
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Rust: Association enforced by ownership
 
use std::sync::{Mutex, Condvar};
 
// The Condvar and data are bundled together
let pair = Arc::new((Mutex::new(false), Condvar::new()));
 
let (lock, cvar) = &*pair;
 
// To wait, you need the MutexGuard, which proves you hold the lock
let mut guard = lock.lock().unwrap();
while !*guard {
    guard = cvar.wait(guard).unwrap();  // Takes and returns guard
}
 
// The type system ensures:
// 1. You must hold the lock to call wait
// 2. You get the lock back after waiting
// 3. Cannot mix up which lock goes with which condvar

Static Association Advantages

•Compile-time safety: Cannot accidentally use the wrong mutex
•Clearer code: The association is explicit in the type structure
•Fewer parameters: No need to pass mutex to every wait call
•Easier to teach: The relationship is built into the abstraction

Common Violations and Debugging

Let's examine the most common violations of the CV-mutex relationship and how to debug them.

Violation 1: Wait without holding mutex

violation1.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// BUG: Forgot to lock
 
void buggy_wait(void) {
    while (!ready) {
        pthread_cond_wait(&cond, &mutex);  // CRASH or worse
    }
}
 
// Symptoms:
// - May crash immediately with assertion failure
// - May appear to work (dangerous!)
// - Helgrind/ThreadSanitizer will catch this
 
// Detection:
// mutex attribute type = PTHREAD_MUTEX_ERRORCHECK
// Returns EPERM instead of undefined behavior
 
// Fix:
void fixed_wait(void) {
    pthread_mutex_lock(&mutex);  // Add this!
    while (!ready) {
        pthread_cond_wait(&cond, &mutex);
    }
    pthread_mutex_unlock(&mutex);
}

Violation 2: Check predicate without holding mutex

violation2.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// BUG: Data race on predicate check
 
void buggy_check(void) {
    if (!ready) {                      // DATA RACE! No mutex held
        pthread_mutex_lock(&mutex);
        pthread_cond_wait(&cond, &mutex);
        pthread_mutex_unlock(&mutex);
    }
}
 
// Problem:
// - 'ready' can change between check and wait
// - Another thread sets ready=true and signals
// - We miss the signal and wait forever
 
// Fix:
void fixed_check(void) {
    pthread_mutex_lock(&mutex);
    while (!ready) {                   // Check inside lock
        pthread_cond_wait(&cond, &mutex);
    }
    pthread_mutex_unlock(&mutex);
}

Violation 3: Wrong mutex with condition variable

violation3.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// BUG: Inconsistent mutex usage
 
pthread_mutex_t mutex_a, mutex_b;
pthread_cond_t cond;
int count;  // Protected by mutex_a
 
void thread1(void) {
    pthread_mutex_lock(&mutex_a);
    while (count == 0) {
        pthread_cond_wait(&cond, &mutex_a);  // Uses mutex_a
    }
    count--;
    pthread_mutex_unlock(&mutex_a);
}
 
void thread2(void) {
    pthread_mutex_lock(&mutex_b);            // WRONG: uses mutex_b
    while (count == 0) {
        pthread_cond_wait(&cond, &mutex_b);  // BUG: different mutex!
    }
    count--;                                 // DATA RACE!
    pthread_mutex_unlock(&mutex_b);
}
 
// This is undefined behavior. May cause:
// - Lost wakeups
// - Data races on 'count'
// - Strange deadlocks

Debugging Tools

Use ThreadSanitizer (-fsanitize=thread) or Helgrind (Valgrind tool) to detect CV/mutex violations. These tools can catch incorrect mutex usage, data races, and other concurrency bugs. Enable them in your CI pipeline!

Design Patterns for CV-Mutex Pairing

Good design makes the CV-mutex relationship obvious and hard to violate.

Pattern 1: Bundle CV, mutex, and state together

bundle_pattern.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Pattern: Encapsulate related items in a struct
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t not_empty;
    pthread_cond_t not_full;
    Item* items;
    int head, tail, count, capacity;
} BoundedBuffer;
 
void buffer_init(BoundedBuffer* b, int capacity) {
    pthread_mutex_init(&b->mutex, NULL);
    pthread_cond_init(&b->not_empty, NULL);
    pthread_cond_init(&b->not_full, NULL);
    b->items = malloc(capacity * sizeof(Item));
    b->head = b->tail = b->count = 0;
    b->capacity = capacity;
}
 
void buffer_put(BoundedBuffer* b, Item item) {
    pthread_mutex_lock(&b->mutex);          // Always use b->mutex
    while (b->count == b->capacity) {
        pthread_cond_wait(&b->not_full, &b->mutex);
    }
    b->items[b->tail] = item;
    b->tail = (b->tail + 1) % b->capacity;
    b->count++;
    pthread_cond_signal(&b->not_empty);
    pthread_mutex_unlock(&b->mutex);
}
 
// The bundling makes it clear which CV goes with which mutex

Pattern 2: Helper functions that enforce pairing

helper_pattern.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Pattern: Hide mutex operations behind abstraction
 
typedef struct Monitor {
    pthread_mutex_t mutex;
    pthread_cond_t cond;
} Monitor;
 
void monitor_wait(Monitor* m, bool (*predicate)(void*), void* arg) {
    pthread_mutex_lock(&m->mutex);
    while (!predicate(arg)) {
        pthread_cond_wait(&m->cond, &m->mutex);
    }
    // Note: returns WITH mutex held!
    // Caller must call monitor_leave()
}
 
void monitor_signal(Monitor* m) {
    pthread_cond_signal(&m->cond);
    // Assumes caller holds mutex
}
 
void monitor_leave(Monitor* m) {
    pthread_mutex_unlock(&m->mutex);
}
 
// Usage:
bool is_ready(void* arg) {
    return *((bool*)arg);
}
 
void user_code(void) {
    monitor_wait(&m, is_ready, &ready);
    // Do work...
    monitor_leave(&m);
}

Pattern 3: RAII-style lock management (C++)

raii_pattern.cpp
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// C++ RAII: Lock is acquired and released automatically
 
#include <mutex>
#include <condition_variable>
 
class ProducerConsumer {
    std::mutex m;
    std::condition_variable cv;
    bool ready = false;
    
public:
    void wait_for_ready() {
        std::unique_lock<std::mutex> lock(m);  // Acquires mutex
        
        // Lambda makes predicate clear
        cv.wait(lock, [this]{ return ready; });
        
        // Mutex is released automatically when 'lock' is destroyed
    }
    
    void signal_ready() {
        {
            std::lock_guard<std::mutex> lock(m);
            ready = true;
        }  // Mutex released here
        
        cv.notify_one();
    }
};
 
// The unique_lock/lock_guard pattern makes it impossible to:
// - Forget to unlock
// - Call wait without holding lock (wait() checks lock.owns_lock())
// - Leak lock on exception

The Mutex in Signal Operations

Unlike wait, signal and broadcast do not require the mutex as a parameter. In fact, POSIX permits calling them without holding the mutex at all. But this doesn't mean the mutex is irrelevant to signaling.

Why signal doesn't take a mutex parameter:

The signal operation only manipulates the condition variable's wait queue. It doesn't access your predicate or shared state. The mutex's role is to protect your state, not the raw signaling mechanism.

However:

You almost always should hold the mutex when signaling. Here's why:

mutex_signal_importance.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// Scenario: Why hold mutex when signaling
 
// If you don't hold the mutex when signaling:
 
void producer_no_lock(Item item) {
    // No lock acquired!
    
    buffer_add(item);  // Where's the protection for buffer?
    
    pthread_cond_signal(&not_empty);  // Legal, but dubious
}
 
// Problems:
// 1. You needed to modify shared state (buffer) - race condition!
// 2. State change and signal are not atomic
 
// Correct pattern:
void producer_with_lock(Item item) {
    pthread_mutex_lock(&mutex);
    
    buffer_add(item);  // Safe: we hold mutex
    count++;           // Safe: we hold mutex
    
    pthread_cond_signal(&not_empty);  // Signal while locked
    
    pthread_mutex_unlock(&mutex);
}
 
// The mutex isn't logically required for signal(),
// but it's required for modifying the state that
// makes the signal meaningful!

The "unlock then signal" debate revisited:

Some argue for signaling after unlocking for performance:

Signal While Locked

•State change and signal are atomic
•Simpler reasoning about program state
•No race window between modify and signal
•Recommended for most code

Signal After Unlock

•Woken thread can acquire mutex immediately
•May reduce context switches
•Requires careful analysis of races
•Only worthwhile if proven by profiling

Simple Rule

Signal while holding the mutex unless you have profiling data showing it matters AND you've carefully analyzed the race conditions. The simpler pattern is almost always correct and fast enough.

Summary: Condition Variables and Mutexes

The relationship between condition variables and mutexes is fundamental to their correct use. Let's consolidate the key points:

Key Takeaways

•The pairing is fundamental — Condition variables wait for predicates; predicates are shared state; shared state needs mutex protection
•Always hold the mutex when waiting — This is a mandatory precondition; violating it is undefined behavior
•Use the same mutex consistently — Never mix mutexes with the same condition variable
•Protect the predicate with the same mutex — The mutex passed to wait must protect the state you're checking
•Wait releases and reacquires the mutex — The thread holds no locks while blocked
•Signal doesn't require mutex, but you usually need it — You're modifying state that requires protection
•Prefer normal mutexes — Recursive mutexes with CVs have complex semantics
•Bundle related items — Keep CV, mutex, and state together in data structures

The golden pattern:

pthread_mutex_lock(&mutex);
while (!predicate) {
    pthread_cond_wait(&cond, &mutex);
}
// predicate is true, mutex is held
do_protected_work();
pthread_mutex_unlock(&mutex);

Every line of this pattern is essential. The lock protects the predicate check. The while loop handles spurious wakeups. The wait releases and reacquires. The unlock allows others to proceed.

What's next:

In the final page of this module, we'll explore multiple condition variables—how to use several CVs with the same mutex to enable more precise signaling and avoid wakeup issues.

Page Complete

You now understand the essential relationship between condition variables and mutexes. This understanding is crucial for writing correct concurrent code—the CV provides the wait/signal mechanism, the mutex protects the predicate. They are inseparable partners in synchronization.

4 / 5

Loading learning content...