Multiple Conditions — Condition Variables:… | OneNoughtOne

0/105

Operating SystemsCondition Variables

Condition Variables: Synchronization for Complex Coordination

LevelIntermediate

Duration75 mins

TopicCondition Variables

5 / 5

Multiple Conditions

Beyond a Single Condition Variable

So far, we've examined condition variables in relative isolation—one condition variable for one waiting need. But real-world synchronization often involves multiple distinct conditions that threads must wait for. Consider a bounded buffer: Producers need to wake when: buffer is not full Consumers need to wake when: buffer is not empty These are fundamentally different conditions. Using a single condition variable forces inefficiencies: when a consumer signals, we might wake a consumer instead of a producer. Using separate condition variables for each condition type enables precise signaling —wake exactly the threads that can make progress. In this page, we'll explore the design patterns, tradeoffs, and implementation strategies for systems with multiple condition variables. You'll learn when to split conditions, how to coordinate multiple CVs with a single mutex, and how to solve classic problems with elegant multi-CV designs.

What You Will Learn

By the end of this page, you will understand: when and why to use multiple condition variables; how multiple CVs share a single mutex; the precise signaling pattern; classic synchronization solutions using multiple CVs; and advanced patterns for complex coordination.

The Case for Multiple Condition Variables

Let's understand why a single condition variable often isn't enough. The bounded buffer with one CV:

single_cv_buffer.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
// Bounded buffer with SINGLE condition variable
// Shows why this is suboptimal
 
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;  // One CV for everything
int count = 0;
#define SIZE 10
 
void producer(Item item) {
    pthread_mutex_lock(&mutex);
    while (count == SIZE) {
        pthread_cond_wait(&cond, &mutex);  // Wait: buffer not full
    }
    add_item(item);
    count++;
    pthread_cond_broadcast(&cond);  // Must broadcast! Why?
    pthread_mutex_unlock(&mutex);
}
 
void consumer(void) {
    pthread_mutex_lock(&mutex);
    while (count == 0) {
        pthread_cond_wait(&cond, &mutex);  // Wait: buffer not empty
    }
    consume_item();
    count--;
    pthread_cond_broadcast(&cond);  // Must broadcast!
    pthread_mutex_unlock(&mutex);
}
 
// Problems:
// 1. Must use broadcast (signal might wake wrong thread type)
// 2. When producer broadcasts, all consumers wake up
// 3. All but one consumer immediately wait again
// 4. Thundering herd! N consumers = N context switches for 1 item

Why broadcast is required: With a single CV: Thread A (producer) waits on "not full" Thread B (consumer) waits on "not empty" Thread C (consumer) removes an item and signals Signal might wake Thread A (producer), who finds buffer still not full... but that's wrong! Thread A wanted "not full", not "not empty" Actually, with signal, Thread A would recheck, find the condition ("not full") true (since an item was removed), and proceed. But if Thread B had been woken instead, Thread B would find "not empty" is now false and wait again—a wasted wakeup. The real issue is that the wrong thread might be woken, requiring broadcast to ensure the right thread eventually wakes.

Inefficiency Compounds

With 100 waiting consumers and 1 waiting producer, a consumer adding an item must broadcast. All 100 consumers wake, 99 immediately wait again, and the producer (who actually needs to wake) competes with all of them for the mutex. This is extremely wasteful.

Separate CVs, Same Mutex

The solution is elegant: use multiple condition variables that share one mutex . The key insight: The mutex protects the shared state (the buffer and count). Each condition variable represents a different condition on that state. Same state, different conditions, multiple CVs.

multiple_cv_buffer.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
36
// Bounded buffer with MULTIPLE condition variables
// This is the correct, efficient design
 
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t not_full = PTHREAD_COND_INITIALIZER;   // CV for producers
pthread_cond_t not_empty = PTHREAD_COND_INITIALIZER;  // CV for consumers
int count = 0;
#define SIZE 10
 
void producer(Item item) {
    pthread_mutex_lock(&mutex);
    while (count == SIZE) {
        pthread_cond_wait(&not_full, &mutex);  // Wait on not_full
    }
    add_item(item);
    count++;
    pthread_cond_signal(&not_empty);  // Signal consumers! (no broadcast needed)
    pthread_mutex_unlock(&mutex);
}
 
void consumer(void) {
    pthread_mutex_lock(&mutex);
    while (count == 0) {
        pthread_cond_wait(&not_empty, &mutex);  // Wait on not_empty
    }
    consume_item();
    count--;
    pthread_cond_signal(&not_full);  // Signal producers! (no broadcast needed)
    pthread_mutex_unlock(&mutex);
}
 
// Benefits:
// 1. Signal (not broadcast) is correct - only wake matching waiters
// 2. Producer adding item signals not_empty - wakes consumer directly
// 3. Consumer removing item signals not_full - wakes producer directly
// 4. No wasted wakeups, no thundering herd

The relationship visualized: ┌─────────────────────────┐ │ mutex │ │ (protects count, │ │ buffer state) │ └───────────┬─────────────┘ │ ┌──────────────┴──────────────┐ │ │ ┌───────▼───────┐ ┌─────────▼───────┐ │ not_full │ │ not_empty │ │ (producers │ │ (consumers │ │ wait here) │ │ wait here) │ └───────────────┘ └─────────────────┘ Both condition variables are associated with the same mutex. The mutex is passed to wait() for both. But each CV has its own wait queue with threads waiting for that specific condition.

One Mutex, Many CVs

A single mutex can be associated with any number of condition variables. Each CV represents a different condition on the shared state protected by that mutex. This is the fundamental pattern for efficient multi-condition synchronization.

The Precise Signaling Pattern

Using multiple CVs enables precise signaling : wake exactly the threads that can make progress. Let's formalize this pattern. The pattern: Identify the distinct conditions threads wait for Create one CV for each distinct condition When waiting, wait on the CV for YOUR condition When signaling, signal the CV for whose condition you've affected Identifying distinct conditions:

Example: Conditions in a Bounded Buffer
Condition	Who Waits?	When Signaled?
Buffer not full	Producers	After consumer removes item
Buffer not empty	Consumers	After producer adds item

precise_signaling_rules.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
36
37
38
39
// Rules for precise signaling
 
// Rule 1: Wait on the CV for YOUR condition
// If you are a producer waiting for space:
pthread_cond_wait(&not_full, &mutex);  // Wait on not_full
 
// If you are a consumer waiting for items:
pthread_cond_wait(&not_empty, &mutex);  // Wait on not_empty
 
 
// Rule 2: Signal the CV whose condition you affect
// When consumer takes an item (now there's space):
pthread_cond_signal(&not_full);  // Producers care about space
 
// When producer adds an item (now there's data):
pthread_cond_signal(&not_empty);  // Consumers care about data
 
 
// Rule 3: Signal, don't broadcast (when conditions are uniform)
// All producers wait for the same thing: space
// All consumers wait for the same thing: items
// So signal() is correct - wake one waiter, any waiter works
 
 
// Rule 4: Match signal quantity to resource quantity
// Adding 1 item -> signal once (wake 1 consumer)
// Adding N items -> either signal N times or broadcast
void producer_batch(Item* items, int n) {
    pthread_mutex_lock(&mutex);
    for (int i = 0; i < n; i++) {
        while (count == SIZE) {
            pthread_cond_wait(&not_full, &mutex);
        }
        add_item(items[i]);
        count++;
        pthread_cond_signal(&not_empty);  // One signal per item
    }
    pthread_mutex_unlock(&mutex);
}

Precise Signaling Checklist

•Enumerate conditions: List all distinct predicates threads wait for
•One CV per condition: Create a condition variable for each distinct predicate
•Wait selectively: Each thread waits on the CV matching its predicate
•Signal accurately: After modifying state, signal the CV(s) whose predicates are affected
•Signal minimally: Use signal when one waiter should proceed; broadcast when all should

Classic Solution: Bounded Buffer

Let's implement a complete, production-quality bounded buffer using multiple condition variables.

bounded_buffer_complete.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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
#include <pthread.h>
#include <stdlib.h>
#include <stdbool.h>
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t not_full;    // For producers waiting
    pthread_cond_t not_empty;   // For consumers waiting
    
    void** items;
    int capacity;
    int count;
    int head;
    int tail;
    
    bool shutdown;              // For graceful shutdown
} BoundedBuffer;
 
BoundedBuffer* buffer_create(int capacity) {
    BoundedBuffer* b = malloc(sizeof(BoundedBuffer));
    pthread_mutex_init(&b->mutex, NULL);
    pthread_cond_init(&b->not_full, NULL);
    pthread_cond_init(&b->not_empty, NULL);
    b->items = malloc(capacity * sizeof(void*));
    b->capacity = capacity;
    b->count = 0;
    b->head = 0;
    b->tail = 0;
    b->shutdown = false;
    return b;
}
 
// Put: blocks until space available or shutdown
// Returns: true if item was added, false on shutdown
bool buffer_put(BoundedBuffer* b, void* item) {
    pthread_mutex_lock(&b->mutex);
    
    while (b->count == b->capacity && !b->shutdown) {
        pthread_cond_wait(&b->not_full, &b->mutex);
    }
    
    if (b->shutdown) {
        pthread_mutex_unlock(&b->mutex);
        return false;
    }
    
    b->items[b->tail] = item;
    b->tail = (b->tail + 1) % b->capacity;
    b->count++;
    
    pthread_cond_signal(&b->not_empty);  // Precise: wake one consumer
    pthread_mutex_unlock(&b->mutex);
    return true;
}
 
// Get: blocks until item available or shutdown
// Returns: item, or NULL on shutdown with empty buffer
void* buffer_get(BoundedBuffer* b) {
    pthread_mutex_lock(&b->mutex);
    
    while (b->count == 0 && !b->shutdown) {
        pthread_cond_wait(&b->not_empty, &b->mutex);
    }
    
    if (b->count == 0 && b->shutdown) {
        pthread_mutex_unlock(&b->mutex);
        return NULL;
    }
    
    void* item = b->items[b->head];
    b->head = (b->head + 1) % b->capacity;
    b->count--;
    
    pthread_cond_signal(&b->not_full);  // Precise: wake one producer
    pthread_mutex_unlock(&b->mutex);
    return item;
}
 
// Shutdown: wake all waiters so they can exit
void buffer_shutdown(BoundedBuffer* b) {
    pthread_mutex_lock(&b->mutex);
    b->shutdown = true;
    pthread_cond_broadcast(&b->not_empty);  // Wake ALL consumers
    pthread_cond_broadcast(&b->not_full);   // Wake ALL producers
    pthread_mutex_unlock(&b->mutex);
}
 
void buffer_destroy(BoundedBuffer* b) {
    pthread_mutex_destroy(&b->mutex);
    pthread_cond_destroy(&b->not_full);
    pthread_cond_destroy(&b->not_empty);
    free(b->items);
    free(b);
}

Shutdown Uses Broadcast

Notice that shutdown() uses broadcast on both CVs. This is intentional: ALL waiting threads need to check the shutdown flag. This is the correct use of broadcast—when the state change affects all waiters, not just one.

Classic Solution: Readers-Writers

The readers-writers problem is a perfect case study for multiple condition variables. Different conditions govern reader and writer access: Readers wait for: no writers active Writers wait for: no readers AND no writers active Let's implement a fair solution where neither readers nor writers starve.

readers_writers_fair.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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
#include <pthread.h>
#include <stdbool.h>
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t can_read;      // Readers wait here
    pthread_cond_t can_write;     // Writers wait here
    
    int active_readers;           // Currently reading
    int active_writers;           // Currently writing (0 or 1)
    int waiting_writers;          // Writers waiting
    
    // For fairness: when writers are waiting, new readers wait
} RWLock;
 
void rwlock_init(RWLock* rw) {
    pthread_mutex_init(&rw->mutex, NULL);
    pthread_cond_init(&rw->can_read, NULL);
    pthread_cond_init(&rw->can_write, NULL);
    rw->active_readers = 0;
    rw->active_writers = 0;
    rw->waiting_writers = 0;
}
 
void rwlock_read_lock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    
    // Wait if: writer is active OR writers are waiting (fairness)
    while (rw->active_writers > 0 || rw->waiting_writers > 0) {
        pthread_cond_wait(&rw->can_read, &rw->mutex);
    }
    
    rw->active_readers++;
    pthread_mutex_unlock(&rw->mutex);
}
 
void rwlock_read_unlock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    rw->active_readers--;
    
    // If last reader and writers waiting, wake ONE writer
    if (rw->active_readers == 0 && rw->waiting_writers > 0) {
        pthread_cond_signal(&rw->can_write);
    }
    
    pthread_mutex_unlock(&rw->mutex);
}
 
void rwlock_write_lock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    rw->waiting_writers++;
    
    // Wait for all readers and writers to finish
    while (rw->active_readers > 0 || rw->active_writers > 0) {
        pthread_cond_wait(&rw->can_write, &rw->mutex);
    }
    
    rw->waiting_writers--;
    rw->active_writers = 1;
    pthread_mutex_unlock(&rw->mutex);
}
 
void rwlock_write_unlock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    rw->active_writers = 0;
    
    // Priority to waiting writers (maintains fairness)
    if (rw->waiting_writers > 0) {
        pthread_cond_signal(&rw->can_write);  // Wake one writer
    } else {
        pthread_cond_broadcast(&rw->can_read);  // Wake ALL readers
    }
    
    pthread_mutex_unlock(&rw->mutex);
}

Key observations: Two CVs for two conditions: Readers wait on can_read, writers on can_write Signal vs. Broadcast used appropriately: Signal can_write : Only one writer can proceed at a time Broadcast can_read : All waiting readers can proceed together Fairness through waiting_writers: Readers check waiting_writers > 0 and wait, preventing reader starvation of writers

RW Lock State Transitions and Signals
Event	Action	CV Signaled
Last reader unlocks	If writers waiting	Signal can_write (one)
Writer unlocks	If writers waiting	Signal can_write (one)
Writer unlocks	If no writers waiting	Broadcast can_read (all)

Advanced: Per-Waiter Condition Variables

Sometimes you need even finer control than "one CV per condition type." An advanced pattern uses one condition variable per waiting thread . When this is useful: You need to wake a specific thread (not just any thread waiting for a condition) FIFO ordering is critical and must be enforced Each waiter has a unique, non-overlapping condition Example: Request queue with ordering

per_waiter_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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#include <pthread.h>
#include <stdlib.h>
#include <stdbool.h>
 
// Each request has its own condition variable
typedef struct Request {
    pthread_cond_t done_cond;     // Signal when this request is done
    void* result;
    bool completed;
    struct Request* next;
} Request;
 
typedef struct {
    pthread_mutex_t mutex;
    Request* head;
    Request* tail;
} RequestQueue;
 
// Client creates a request and waits for its completion
void* submit_and_wait(RequestQueue* q, void* data) {
    // Create request with its own CV
    Request* req = malloc(sizeof(Request));
    pthread_cond_init(&req->done_cond, NULL);
    req->result = NULL;
    req->completed = false;
    req->next = NULL;
    
    // Enqueue
    pthread_mutex_lock(&q->mutex);
    if (q->tail) {
        q->tail->next = req;
    } else {
        q->head = req;
    }
    q->tail = req;
    
    // Wait for THIS specific request to complete
    while (!req->completed) {
        pthread_cond_wait(&req->done_cond, &q->mutex);
    }
    
    void* result = req->result;
    pthread_mutex_unlock(&q->mutex);
    
    // Cleanup
    pthread_cond_destroy(&req->done_cond);
    free(req);
    
    return result;
}
 
// Worker completes a specific request
void complete_request(RequestQueue* q, Request* req, void* result) {
    pthread_mutex_lock(&q->mutex);
    req->result = result;
    req->completed = true;
    pthread_cond_signal(&req->done_cond);  // Wake THIS specific waiter
    pthread_mutex_unlock(&q->mutex);
}

When Per-Waiter CVs Shine

This pattern is common in database systems (waiting for specific transaction commits), RPC frameworks (waiting for specific responses), and async I/O (waiting for specific operation completions). The overhead of creating/destroying CVs is offset by perfect signaling precision.

The State-Change Notification Pattern

A powerful pattern combines multiple CVs with state change notification: whenever state changes, signal all CVs that might care. The pattern: Each distinct condition has its own CV When state changes, determine which conditions might now be satisfiable Signal those CVs (signal for uniform waiters, broadcast if varied)

state_notification.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
36
37
38
39
40
41
42
43
44
// Complex resource manager with multiple conditions
 
typedef struct {
    pthread_mutex_t mutex;
    
    // Multiple conditions on the resource state
    pthread_cond_t resource_available;   // count > 0
    pthread_cond_t all_returned;         // count == total
    pthread_cond_t below_threshold;      // count < threshold
    
    int count;
    int total;
    int threshold;
} ResourcePool;
 
void notify_state_change(ResourcePool* p) {
    // After any state change, signal relevant CVs
    if (p->count > 0) {
        pthread_cond_signal(&p->resource_available);
    }
    if (p->count == p->total) {
        pthread_cond_broadcast(&p->all_returned);
    }
    if (p->count < p->threshold) {
        // This might be used for "low watermark" alerts
        pthread_cond_signal(&p->below_threshold);
    }
}
 
void return_resource(ResourcePool* p) {
    pthread_mutex_lock(&p->mutex);
    p->count++;
    notify_state_change(p);  // Let CVs figure out who cares
    pthread_mutex_unlock(&p->mutex);
}
 
// Wait for all resources returned (e.g., for shutdown)
void wait_all_returned(ResourcePool* p) {
    pthread_mutex_lock(&p->mutex);
    while (p->count != p->total) {
        pthread_cond_wait(&p->all_returned, &p->mutex);
    }
    pthread_mutex_unlock(&p->mutex);
}

Benefits of this pattern: Decouples state changes from notifications: The modifier doesn't need to know who's waiting for what Extensible: Adding a new condition just adds a CV and updates the notification function Clear: Each CV corresponds to a named condition Drawback: You might signal CVs that don't have waiters (minor overhead).

Operating SystemsCondition Variables

Condition Variables: Synchronization for Complex Coordination

LevelIntermediate

Duration75 mins

TopicCondition Variables

5 / 5

Multiple Conditions

Beyond a Single Condition Variable

So far, we've examined condition variables in relative isolation—one condition variable for one waiting need. But real-world synchronization often involves multiple distinct conditions that threads must wait for. Consider a bounded buffer: Producers need to wake when: buffer is not full Consumers need to wake when: buffer is not empty These are fundamentally different conditions. Using a single condition variable forces inefficiencies: when a consumer signals, we might wake a consumer instead of a producer. Using separate condition variables for each condition type enables precise signaling —wake exactly the threads that can make progress. In this page, we'll explore the design patterns, tradeoffs, and implementation strategies for systems with multiple condition variables. You'll learn when to split conditions, how to coordinate multiple CVs with a single mutex, and how to solve classic problems with elegant multi-CV designs.

What You Will Learn

By the end of this page, you will understand: when and why to use multiple condition variables; how multiple CVs share a single mutex; the precise signaling pattern; classic synchronization solutions using multiple CVs; and advanced patterns for complex coordination.

The Case for Multiple Condition Variables

Let's understand why a single condition variable often isn't enough. The bounded buffer with one CV:

single_cv_buffer.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
// Bounded buffer with SINGLE condition variable
// Shows why this is suboptimal
 
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;  // One CV for everything
int count = 0;
#define SIZE 10
 
void producer(Item item) {
    pthread_mutex_lock(&mutex);
    while (count == SIZE) {
        pthread_cond_wait(&cond, &mutex);  // Wait: buffer not full
    }
    add_item(item);
    count++;
    pthread_cond_broadcast(&cond);  // Must broadcast! Why?
    pthread_mutex_unlock(&mutex);
}
 
void consumer(void) {
    pthread_mutex_lock(&mutex);
    while (count == 0) {
        pthread_cond_wait(&cond, &mutex);  // Wait: buffer not empty
    }
    consume_item();
    count--;
    pthread_cond_broadcast(&cond);  // Must broadcast!
    pthread_mutex_unlock(&mutex);
}
 
// Problems:
// 1. Must use broadcast (signal might wake wrong thread type)
// 2. When producer broadcasts, all consumers wake up
// 3. All but one consumer immediately wait again
// 4. Thundering herd! N consumers = N context switches for 1 item

Why broadcast is required: With a single CV: Thread A (producer) waits on "not full" Thread B (consumer) waits on "not empty" Thread C (consumer) removes an item and signals Signal might wake Thread A (producer), who finds buffer still not full... but that's wrong! Thread A wanted "not full", not "not empty" Actually, with signal, Thread A would recheck, find the condition ("not full") true (since an item was removed), and proceed. But if Thread B had been woken instead, Thread B would find "not empty" is now false and wait again—a wasted wakeup. The real issue is that the wrong thread might be woken, requiring broadcast to ensure the right thread eventually wakes.

Inefficiency Compounds

With 100 waiting consumers and 1 waiting producer, a consumer adding an item must broadcast. All 100 consumers wake, 99 immediately wait again, and the producer (who actually needs to wake) competes with all of them for the mutex. This is extremely wasteful.

Separate CVs, Same Mutex

The solution is elegant: use multiple condition variables that share one mutex . The key insight: The mutex protects the shared state (the buffer and count). Each condition variable represents a different condition on that state. Same state, different conditions, multiple CVs.

multiple_cv_buffer.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
36
// Bounded buffer with MULTIPLE condition variables
// This is the correct, efficient design
 
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t not_full = PTHREAD_COND_INITIALIZER;   // CV for producers
pthread_cond_t not_empty = PTHREAD_COND_INITIALIZER;  // CV for consumers
int count = 0;
#define SIZE 10
 
void producer(Item item) {
    pthread_mutex_lock(&mutex);
    while (count == SIZE) {
        pthread_cond_wait(&not_full, &mutex);  // Wait on not_full
    }
    add_item(item);
    count++;
    pthread_cond_signal(&not_empty);  // Signal consumers! (no broadcast needed)
    pthread_mutex_unlock(&mutex);
}
 
void consumer(void) {
    pthread_mutex_lock(&mutex);
    while (count == 0) {
        pthread_cond_wait(&not_empty, &mutex);  // Wait on not_empty
    }
    consume_item();
    count--;
    pthread_cond_signal(&not_full);  // Signal producers! (no broadcast needed)
    pthread_mutex_unlock(&mutex);
}
 
// Benefits:
// 1. Signal (not broadcast) is correct - only wake matching waiters
// 2. Producer adding item signals not_empty - wakes consumer directly
// 3. Consumer removing item signals not_full - wakes producer directly
// 4. No wasted wakeups, no thundering herd

The relationship visualized: ┌─────────────────────────┐ │ mutex │ │ (protects count, │ │ buffer state) │ └───────────┬─────────────┘ │ ┌──────────────┴──────────────┐ │ │ ┌───────▼───────┐ ┌─────────▼───────┐ │ not_full │ │ not_empty │ │ (producers │ │ (consumers │ │ wait here) │ │ wait here) │ └───────────────┘ └─────────────────┘ Both condition variables are associated with the same mutex. The mutex is passed to wait() for both. But each CV has its own wait queue with threads waiting for that specific condition.

One Mutex, Many CVs

A single mutex can be associated with any number of condition variables. Each CV represents a different condition on the shared state protected by that mutex. This is the fundamental pattern for efficient multi-condition synchronization.

The Precise Signaling Pattern

Using multiple CVs enables precise signaling : wake exactly the threads that can make progress. Let's formalize this pattern. The pattern: Identify the distinct conditions threads wait for Create one CV for each distinct condition When waiting, wait on the CV for YOUR condition When signaling, signal the CV for whose condition you've affected Identifying distinct conditions:

Example: Conditions in a Bounded Buffer
Condition	Who Waits?	When Signaled?
Buffer not full	Producers	After consumer removes item
Buffer not empty	Consumers	After producer adds item

precise_signaling_rules.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
36
37
38
39
// Rules for precise signaling
 
// Rule 1: Wait on the CV for YOUR condition
// If you are a producer waiting for space:
pthread_cond_wait(&not_full, &mutex);  // Wait on not_full
 
// If you are a consumer waiting for items:
pthread_cond_wait(&not_empty, &mutex);  // Wait on not_empty
 
 
// Rule 2: Signal the CV whose condition you affect
// When consumer takes an item (now there's space):
pthread_cond_signal(&not_full);  // Producers care about space
 
// When producer adds an item (now there's data):
pthread_cond_signal(&not_empty);  // Consumers care about data
 
 
// Rule 3: Signal, don't broadcast (when conditions are uniform)
// All producers wait for the same thing: space
// All consumers wait for the same thing: items
// So signal() is correct - wake one waiter, any waiter works
 
 
// Rule 4: Match signal quantity to resource quantity
// Adding 1 item -> signal once (wake 1 consumer)
// Adding N items -> either signal N times or broadcast
void producer_batch(Item* items, int n) {
    pthread_mutex_lock(&mutex);
    for (int i = 0; i < n; i++) {
        while (count == SIZE) {
            pthread_cond_wait(&not_full, &mutex);
        }
        add_item(items[i]);
        count++;
        pthread_cond_signal(&not_empty);  // One signal per item
    }
    pthread_mutex_unlock(&mutex);
}

Precise Signaling Checklist

•Enumerate conditions: List all distinct predicates threads wait for
•One CV per condition: Create a condition variable for each distinct predicate
•Wait selectively: Each thread waits on the CV matching its predicate
•Signal accurately: After modifying state, signal the CV(s) whose predicates are affected
•Signal minimally: Use signal when one waiter should proceed; broadcast when all should

Classic Solution: Bounded Buffer

Let's implement a complete, production-quality bounded buffer using multiple condition variables.

bounded_buffer_complete.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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
#include <pthread.h>
#include <stdlib.h>
#include <stdbool.h>
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t not_full;    // For producers waiting
    pthread_cond_t not_empty;   // For consumers waiting
    
    void** items;
    int capacity;
    int count;
    int head;
    int tail;
    
    bool shutdown;              // For graceful shutdown
} BoundedBuffer;
 
BoundedBuffer* buffer_create(int capacity) {
    BoundedBuffer* b = malloc(sizeof(BoundedBuffer));
    pthread_mutex_init(&b->mutex, NULL);
    pthread_cond_init(&b->not_full, NULL);
    pthread_cond_init(&b->not_empty, NULL);
    b->items = malloc(capacity * sizeof(void*));
    b->capacity = capacity;
    b->count = 0;
    b->head = 0;
    b->tail = 0;
    b->shutdown = false;
    return b;
}
 
// Put: blocks until space available or shutdown
// Returns: true if item was added, false on shutdown
bool buffer_put(BoundedBuffer* b, void* item) {
    pthread_mutex_lock(&b->mutex);
    
    while (b->count == b->capacity && !b->shutdown) {
        pthread_cond_wait(&b->not_full, &b->mutex);
    }
    
    if (b->shutdown) {
        pthread_mutex_unlock(&b->mutex);
        return false;
    }
    
    b->items[b->tail] = item;
    b->tail = (b->tail + 1) % b->capacity;
    b->count++;
    
    pthread_cond_signal(&b->not_empty);  // Precise: wake one consumer
    pthread_mutex_unlock(&b->mutex);
    return true;
}
 
// Get: blocks until item available or shutdown
// Returns: item, or NULL on shutdown with empty buffer
void* buffer_get(BoundedBuffer* b) {
    pthread_mutex_lock(&b->mutex);
    
    while (b->count == 0 && !b->shutdown) {
        pthread_cond_wait(&b->not_empty, &b->mutex);
    }
    
    if (b->count == 0 && b->shutdown) {
        pthread_mutex_unlock(&b->mutex);
        return NULL;
    }
    
    void* item = b->items[b->head];
    b->head = (b->head + 1) % b->capacity;
    b->count--;
    
    pthread_cond_signal(&b->not_full);  // Precise: wake one producer
    pthread_mutex_unlock(&b->mutex);
    return item;
}
 
// Shutdown: wake all waiters so they can exit
void buffer_shutdown(BoundedBuffer* b) {
    pthread_mutex_lock(&b->mutex);
    b->shutdown = true;
    pthread_cond_broadcast(&b->not_empty);  // Wake ALL consumers
    pthread_cond_broadcast(&b->not_full);   // Wake ALL producers
    pthread_mutex_unlock(&b->mutex);
}
 
void buffer_destroy(BoundedBuffer* b) {
    pthread_mutex_destroy(&b->mutex);
    pthread_cond_destroy(&b->not_full);
    pthread_cond_destroy(&b->not_empty);
    free(b->items);
    free(b);
}

Shutdown Uses Broadcast

Notice that shutdown() uses broadcast on both CVs. This is intentional: ALL waiting threads need to check the shutdown flag. This is the correct use of broadcast—when the state change affects all waiters, not just one.

Classic Solution: Readers-Writers

The readers-writers problem is a perfect case study for multiple condition variables. Different conditions govern reader and writer access: Readers wait for: no writers active Writers wait for: no readers AND no writers active Let's implement a fair solution where neither readers nor writers starve.

readers_writers_fair.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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
#include <pthread.h>
#include <stdbool.h>
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t can_read;      // Readers wait here
    pthread_cond_t can_write;     // Writers wait here
    
    int active_readers;           // Currently reading
    int active_writers;           // Currently writing (0 or 1)
    int waiting_writers;          // Writers waiting
    
    // For fairness: when writers are waiting, new readers wait
} RWLock;
 
void rwlock_init(RWLock* rw) {
    pthread_mutex_init(&rw->mutex, NULL);
    pthread_cond_init(&rw->can_read, NULL);
    pthread_cond_init(&rw->can_write, NULL);
    rw->active_readers = 0;
    rw->active_writers = 0;
    rw->waiting_writers = 0;
}
 
void rwlock_read_lock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    
    // Wait if: writer is active OR writers are waiting (fairness)
    while (rw->active_writers > 0 || rw->waiting_writers > 0) {
        pthread_cond_wait(&rw->can_read, &rw->mutex);
    }
    
    rw->active_readers++;
    pthread_mutex_unlock(&rw->mutex);
}
 
void rwlock_read_unlock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    rw->active_readers--;
    
    // If last reader and writers waiting, wake ONE writer
    if (rw->active_readers == 0 && rw->waiting_writers > 0) {
        pthread_cond_signal(&rw->can_write);
    }
    
    pthread_mutex_unlock(&rw->mutex);
}
 
void rwlock_write_lock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    rw->waiting_writers++;
    
    // Wait for all readers and writers to finish
    while (rw->active_readers > 0 || rw->active_writers > 0) {
        pthread_cond_wait(&rw->can_write, &rw->mutex);
    }
    
    rw->waiting_writers--;
    rw->active_writers = 1;
    pthread_mutex_unlock(&rw->mutex);
}
 
void rwlock_write_unlock(RWLock* rw) {
    pthread_mutex_lock(&rw->mutex);
    rw->active_writers = 0;
    
    // Priority to waiting writers (maintains fairness)
    if (rw->waiting_writers > 0) {
        pthread_cond_signal(&rw->can_write);  // Wake one writer
    } else {
        pthread_cond_broadcast(&rw->can_read);  // Wake ALL readers
    }
    
    pthread_mutex_unlock(&rw->mutex);
}

Key observations: Two CVs for two conditions: Readers wait on can_read, writers on can_write Signal vs. Broadcast used appropriately: Signal can_write : Only one writer can proceed at a time Broadcast can_read : All waiting readers can proceed together Fairness through waiting_writers: Readers check waiting_writers > 0 and wait, preventing reader starvation of writers

RW Lock State Transitions and Signals
Event	Action	CV Signaled
Last reader unlocks	If writers waiting	Signal can_write (one)
Writer unlocks	If writers waiting	Signal can_write (one)
Writer unlocks	If no writers waiting	Broadcast can_read (all)

Advanced: Per-Waiter Condition Variables

Sometimes you need even finer control than "one CV per condition type." An advanced pattern uses one condition variable per waiting thread . When this is useful: You need to wake a specific thread (not just any thread waiting for a condition) FIFO ordering is critical and must be enforced Each waiter has a unique, non-overlapping condition Example: Request queue with ordering

per_waiter_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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#include <pthread.h>
#include <stdlib.h>
#include <stdbool.h>
 
// Each request has its own condition variable
typedef struct Request {
    pthread_cond_t done_cond;     // Signal when this request is done
    void* result;
    bool completed;
    struct Request* next;
} Request;
 
typedef struct {
    pthread_mutex_t mutex;
    Request* head;
    Request* tail;
} RequestQueue;
 
// Client creates a request and waits for its completion
void* submit_and_wait(RequestQueue* q, void* data) {
    // Create request with its own CV
    Request* req = malloc(sizeof(Request));
    pthread_cond_init(&req->done_cond, NULL);
    req->result = NULL;
    req->completed = false;
    req->next = NULL;
    
    // Enqueue
    pthread_mutex_lock(&q->mutex);
    if (q->tail) {
        q->tail->next = req;
    } else {
        q->head = req;
    }
    q->tail = req;
    
    // Wait for THIS specific request to complete
    while (!req->completed) {
        pthread_cond_wait(&req->done_cond, &q->mutex);
    }
    
    void* result = req->result;
    pthread_mutex_unlock(&q->mutex);
    
    // Cleanup
    pthread_cond_destroy(&req->done_cond);
    free(req);
    
    return result;
}
 
// Worker completes a specific request
void complete_request(RequestQueue* q, Request* req, void* result) {
    pthread_mutex_lock(&q->mutex);
    req->result = result;
    req->completed = true;
    pthread_cond_signal(&req->done_cond);  // Wake THIS specific waiter
    pthread_mutex_unlock(&q->mutex);
}

When Per-Waiter CVs Shine

This pattern is common in database systems (waiting for specific transaction commits), RPC frameworks (waiting for specific responses), and async I/O (waiting for specific operation completions). The overhead of creating/destroying CVs is offset by perfect signaling precision.

The State-Change Notification Pattern

A powerful pattern combines multiple CVs with state change notification: whenever state changes, signal all CVs that might care. The pattern: Each distinct condition has its own CV When state changes, determine which conditions might now be satisfiable Signal those CVs (signal for uniform waiters, broadcast if varied)

state_notification.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
36
37
38
39
40
41
42
43
44
// Complex resource manager with multiple conditions
 
typedef struct {
    pthread_mutex_t mutex;
    
    // Multiple conditions on the resource state
    pthread_cond_t resource_available;   // count > 0
    pthread_cond_t all_returned;         // count == total
    pthread_cond_t below_threshold;      // count < threshold
    
    int count;
    int total;
    int threshold;
} ResourcePool;
 
void notify_state_change(ResourcePool* p) {
    // After any state change, signal relevant CVs
    if (p->count > 0) {
        pthread_cond_signal(&p->resource_available);
    }
    if (p->count == p->total) {
        pthread_cond_broadcast(&p->all_returned);
    }
    if (p->count < p->threshold) {
        // This might be used for "low watermark" alerts
        pthread_cond_signal(&p->below_threshold);
    }
}
 
void return_resource(ResourcePool* p) {
    pthread_mutex_lock(&p->mutex);
    p->count++;
    notify_state_change(p);  // Let CVs figure out who cares
    pthread_mutex_unlock(&p->mutex);
}
 
// Wait for all resources returned (e.g., for shutdown)
void wait_all_returned(ResourcePool* p) {
    pthread_mutex_lock(&p->mutex);
    while (p->count != p->total) {
        pthread_cond_wait(&p->all_returned, &p->mutex);
    }
    pthread_mutex_unlock(&p->mutex);
}

Benefits of this pattern: Decouples state changes from notifications: The modifier doesn't need to know who's waiting for what Extensible: Adding a new condition just adds a CV and updates the notification function Clear: Each CV corresponds to a named condition Drawback: You might signal CVs that don't have waiters (minor overhead).

Multiple Conditions

Beyond a Single Condition Variable

The Case for Multiple Condition Variables

Separate CVs, Same Mutex

The Precise Signaling Pattern

Classic Solution: Bounded Buffer

Classic Solution: Readers-Writers

Advanced: Per-Waiter Condition Variables

The State-Change Notification Pattern

There’s more to understand.

Multiple Conditions

Beyond a Single Condition Variable

The Case for Multiple Condition Variables

Separate CVs, Same Mutex

The Precise Signaling Pattern

Classic Solution: Bounded Buffer

Classic Solution: Readers-Writers

Advanced: Per-Waiter Condition Variables

The State-Change Notification Pattern

There’s more to understand.