Broadcast - Learning Module

Loading content...

0/240

When to Broadcast: Identifying the Right Scenarios

Making the Right Choice

Knowing how broadcast works is only half the battle. The more challenging question is: when should you use broadcast instead of signal?

This decision is subtle and consequential. Use signal when broadcast is needed, and you may face deadlock or starvation. Use broadcast when signal would suffice, and you waste CPU cycles and increase latency. The difference between these choices can mean the difference between a system that scales elegantly and one that buckles under load.

This page provides a comprehensive framework for making this decision correctly, every time.

What You Will Learn

By the end of this page, you will be able to instantly recognize scenarios that require broadcast, understand the underlying principles that make broadcast necessary in those cases, and apply systematic reasoning to any new synchronization problem you encounter.

The Fundamental Principle: State Change Scope

At its core, the choice between signal and broadcast comes down to one fundamental question:

How many threads can meaningfully proceed after this state change?

This seemingly simple question has profound implications. Let's break it down systematically.

The State Change Analysis Framework:

┌─────────────────────────────────────────────────────────────────┐
│                  STATE CHANGE ANALYSIS                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Q1: Does this state change affect ONE waiter or MANY?          │
│      ├─ ONE    → Signal is a candidate                         │
│      └─ MANY   → Broadcast may be necessary                    │
│                                                                 │
│  Q2: Are all waiters waiting for the SAME condition?            │
│      ├─ YES    → Signal may work                              │
│      └─ NO     → Broadcast is REQUIRED                         │
│                                                                 │
│  Q3: Is any waiter interchangeable with any other?             │
│      ├─ YES    → Signal is appropriate                         │
│      └─ NO     → Broadcast may be necessary                    │
│                                                                 │
│  Q4: Could signal wake the 'wrong' thread?                      │
│      ├─ NO     → Signal is safe                                │
│      └─ YES    → Broadcast prevents deadlock                   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

The Safe Default Rule

If you cannot confidently answer YES to Q2 and Q3, or if you answer YES to Q4, use broadcast. Signal is an optimization that requires proof of correctness. Broadcast is always correct (though potentially less efficient).

Scenario Category 1: State Change Affects All Waiters

The most clear-cut case for broadcast is when a state change inherently affects all waiting threads, not just one. In these scenarios, every waiter needs to observe the new state and respond accordingly.

Classic 'Affects All' Patterns

•Shutdown/Termination Notification — When a server shuts down, ALL worker threads must wake up, detect the shutdown, and exit gracefully.
•Barrier Synchronization — When the last thread reaches a barrier, ALL threads at the barrier must proceed together.
•Configuration Changes — When configuration changes, ALL processing threads may need to wake and reload their settings.
•Epoch/Generation Changes — When entering a new processing phase, ALL threads from the previous phase must wake and transition.
•Resource Pool Exhaustion Recovery — When a resource pool is replenished, ALL waiters might now have resources available.

Example: Graceful Shutdown Pattern

Consider a thread pool that needs to gracefully shut down all worker threads:

Graceful Shutdown Pattern
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
// Thread pool with graceful shutdown using broadcast
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t work_available;
    
    // Work queue
    queue_t *work_queue;
    
    // Shutdown state
    bool shutdown_requested;
    int active_workers;
    pthread_cond_t all_workers_stopped;
} thread_pool_t;
 
// Worker thread function
void *worker_thread(void *arg) {
    thread_pool_t *pool = (thread_pool_t *)arg;
    
    pthread_mutex_lock(&pool->mutex);
    
    while (1) {
        // Wait for work OR shutdown
        while (queue_empty(pool->work_queue) && !pool->shutdown_requested) {
            pthread_cond_wait(&pool->work_available, &pool->mutex);
        }
        
        // Check if we're shutting down
        if (pool->shutdown_requested && queue_empty(pool->work_queue)) {
            pool->active_workers--;
            
            // If we're the last worker, signal the shutdown coordinator
            if (pool->active_workers == 0) {
                pthread_cond_signal(&pool->all_workers_stopped);
            }
            
            pthread_mutex_unlock(&pool->mutex);
            return NULL;  // Exit the thread
        }
        
        // Get and process work
        work_t *work = queue_dequeue(pool->work_queue);
        pthread_mutex_unlock(&pool->mutex);
        
        // Execute work (outside lock)
        execute_work(work);
        free(work);
        
        pthread_mutex_lock(&pool->mutex);
    }
}
 
// Initiate graceful shutdown
void thread_pool_shutdown(thread_pool_t *pool) {
    pthread_mutex_lock(&pool->mutex);
    
    // Set shutdown flag
    pool->shutdown_requested = true;
    
    // BROADCAST to wake ALL workers
    // Signal would only wake one — the others would sleep forever!
    pthread_cond_broadcast(&pool->work_available);
    
    // Wait for all workers to finish
    while (pool->active_workers > 0) {
        pthread_cond_wait(&pool->all_workers_stopped, &pool->mutex);
    }
    
    pthread_mutex_unlock(&pool->mutex);
    
    printf("All workers stopped, shutdown complete
");
}
 
// Why broadcast is REQUIRED here:
// - The state change (shutdown_requested = true) affects ALL workers
// - Every worker must wake up, observe the flag, and exit
// - Signal would wake only one worker
// - Other workers would wait forever for work that will never come

Example: Barrier Synchronization

Barriers are another canonical case where broadcast is mandatory:

Barrier Implementation
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
// Reusable barrier implementation
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t cond;
    int count;        // Threads that have arrived
    int threshold;    // Threads needed to release barrier
    int generation;   // For barrier reuse
} barrier_t;
 
int barrier_wait(barrier_t *b) {
    pthread_mutex_lock(&b->mutex);
    
    // Record our generation before potentially incrementing count
    int local_gen = b->generation;
    
    b->count++;
    
    if (b->count == b->threshold) {
        // We are the LAST thread to arrive
        // Release all other threads
        
        // Reset for next use
        b->count = 0;
        b->generation++;  // Increment generation to distinguish reuses
        
        // BROADCAST: Wake ALL waiting threads
        // Signal would be catastrophically wrong here:
        // - We need ALL (threshold - 1) threads to proceed
        // - Signal would wake only one, leaving (threshold - 2) stuck
        pthread_cond_broadcast(&b->cond);
        
        pthread_mutex_unlock(&b->mutex);
        return PTHREAD_BARRIER_SERIAL_THREAD;  // Special return for last arriver
    }
    
    // Not the last thread — wait for release
    // Use generation to handle spurious wakeups AND barrier reuse
    while (local_gen == b->generation) {
        pthread_cond_wait(&b->cond, &b->mutex);
    }
    
    pthread_mutex_unlock(&b->mutex);
    return 0;
}
 
// Barrier invariant analysis:
// - After broadcast: ALL (threshold - 1) waiting threads wake up
// - Each checks: local_gen != b->generation (true after increment)
// - All proceed past the barrier
// - Barrier can be safely reused because generation changed

Scenario Category 2: Heterogeneous Waiters

One of the most subtle situations requiring broadcast is when different types of threads wait on the same condition variable. This is sometimes called the 'mixed waiters' problem, and it's a common source of deadlocks when signal is incorrectly used.

Why Heterogeneous Waiters Require Broadcast:

When different thread types wait for different conditions on the same condition variable, signal has a fundamental problem: it cannot guarantee that the 'right' thread will be awakened.

┌─────────────────────────────────────────────────────────────┐
│             HETEROGENEOUS WAITERS PROBLEM                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Condition Variable CV Wait Queue:                          │
│  [Producer P1] → [Consumer C1] → [Producer P2] → [Consumer C2]
│                                                             │
│  Consumer finishes consuming, buffer now has space.         │
│  Calls signal() intending to wake a producer...            │
│                                                             │
│  But wait queue order might wake Consumer C1 instead!       │
│  C1 wakes, finds buffer still empty, goes back to sleep.   │
│  P1 and P2 remain sleeping despite buffer having space.     │
│                                                             │
│  If this pattern repeats, DEADLOCK can occur.              │
└─────────────────────────────────────────────────────────────┘

The Deadlock Scenario

With heterogeneous waiters and signal(): A consumer wakes, but is not the intended recipient. It re-waits. The producer still sleeps. If all subsequent signals also wake the 'wrong' type of thread, the intended recipients may never wake, causing deadlock.

Heterogeneous Waiters - Wrong Approach
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
// DANGEROUS: Single CV for both producers and consumers
// This can cause deadlock when using signal()
 
#define BUFFER_SIZE 10
 
typedef struct {
    int buffer[BUFFER_SIZE];
    int count;
    int in, out;
    pthread_mutex_t mutex;
    pthread_cond_t cond;  // SHARED by producers AND consumers
} buffer_t;
 
void produce(buffer_t *buf, int item) {
    pthread_mutex_lock(&buf->mutex);
    
    // Producers wait while buffer is FULL
    while (buf->count == BUFFER_SIZE) {
        pthread_cond_wait(&buf->cond, &buf->mutex);  // Wait on shared CV
    }
    
    buf->buffer[buf->in] = item;
    buf->in = (buf->in + 1) % BUFFER_SIZE;
    buf->count++;
    
    // BUG: Signal might wake another producer!
    pthread_cond_signal(&buf->cond);
    
    pthread_mutex_unlock(&buf->mutex);
}
 
void consume(buffer_t *buf, int *item) {
    pthread_mutex_lock(&buf->mutex);
    
    // Consumers wait while buffer is EMPTY
    while (buf->count == 0) {
        pthread_cond_wait(&buf->cond, &buf->mutex);  // Wait on shared CV
    }
    
    *item = buf->buffer[buf->out];
    buf->out = (buf->out + 1) % BUFFER_SIZE;
    buf->count--;
    
    // BUG: Signal might wake another consumer!
    pthread_cond_signal(&buf->cond);
    
    pthread_mutex_unlock(&buf->mutex);
}
 
// DEADLOCK SCENARIO:
// Initial: buffer empty, 2 producers (P1, P2) waiting, 1 consumer (C1) running
// 1. Item arrives externally, C1 processes it
// 2. C1 signals, P1 or P2 should wake... but say P1 wakes
// 3. P1 produces, buffer count=1, signals
// 4. The signal wakes... P2! (wrong type)
// 5. P2 finds buffer not full, produces, count=2, signals
// 6. Signal wakes... C1? No, C1 isn't waiting. Wakes nobody? Or if C1 had re-entered wait...
// 
// The core problem: You can't control WHICH thread type signal() wakes

The Correct Solution: Broadcast or Separate CVs

There are two correct approaches for heterogeneous waiters:

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
// CORRECT but potentially inefficient: Use broadcast
 
void produce(buffer_t *buf, int item) {
    pthread_mutex_lock(&buf->mutex);
    
    while (buf->count == BUFFER_SIZE) {
        pthread_cond_wait(&buf->cond, &buf->mutex);
    }
    
    buf->buffer[buf->in] = item;
    buf->in = (buf->in + 1) % BUFFER_SIZE;
    buf->count++;
    
    // BROADCAST wakes ALL waiters
    // Some will re-wait (producers if buffer is full)
    // Others will proceed (consumers if buffer has items)
    pthread_cond_broadcast(&buf->cond);
    
    pthread_mutex_unlock(&buf->mutex);
}
 
void consume(buffer_t *buf, int *item) {
    pthread_mutex_lock(&buf->mutex);
    
    while (buf->count == 0) {
        pthread_cond_wait(&buf->cond, &buf->mutex);
    }
    
    *item = buf->buffer[buf->out];
    buf->out = (buf->out + 1) % BUFFER_SIZE;
    buf->count--;
    
    // BROADCAST wakes ALL waiters
    pthread_cond_broadcast(&buf->cond);
    
    pthread_mutex_unlock(&buf->mutex);
}
 
// This works correctly but wakes more threads than necessary
// Acceptable for small numbers of waiters

Design Principle

When you have heterogeneous waiters, the best solution is usually separate condition variables for each waiter type. This allows you to use efficient signal() operations while maintaining correctness. Broadcast on a shared CV is a simpler but less efficient alternative.

Scenario Category 3: Multiple Resources Available

When multiple resources become available simultaneously, broadcast may be necessary to allow multiple waiters to proceed. Signal would only wake one waiter, leaving available resources underutilized.

The Multiple Resource Pattern:

Consider a resource pool where multiple resources can become available at once:

Multiple Resources Pattern
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
// Resource pool with bulk return capability
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t resources_available;
    int available_count;
    resource_t *resources[MAX_RESOURCES];
} resource_pool_t;
 
// Acquire a single resource
resource_t *acquire_resource(resource_pool_t *pool) {
    pthread_mutex_lock(&pool->mutex);
    
    while (pool->available_count == 0) {
        pthread_cond_wait(&pool->resources_available, &pool->mutex);
    }
    
    pool->available_count--;
    resource_t *r = pool->resources[pool->available_count];
    
    pthread_mutex_unlock(&pool->mutex);
    return r;
}
 
// Return a single resource
void return_resource(resource_pool_t *pool, resource_t *r) {
    pthread_mutex_lock(&pool->mutex);
    
    pool->resources[pool->available_count] = r;
    pool->available_count++;
    
    // Signal is sufficient here - one resource, one waiter can proceed
    pthread_cond_signal(&pool->resources_available);
    
    pthread_mutex_unlock(&pool->mutex);
}
 
// Return MULTIPLE resources at once (e.g., batch completion)
void return_resources_bulk(resource_pool_t *pool, resource_t **resources, int count) {
    pthread_mutex_lock(&pool->mutex);
    
    for (int i = 0; i < count; i++) {
        pool->resources[pool->available_count] = resources[i];
        pool->available_count++;
    }
    
    // BROADCAST needed: We just made 'count' resources available
    // Up to 'count' waiters could potentially proceed
    // Signal would only wake one, leaving resources underutilized
    pthread_cond_broadcast(&pool->resources_available);
    
    pthread_mutex_unlock(&pool->mutex);
}
 
// Analysis:
// - return_resource(): Adds 1 resource, signal is correct
// - return_resources_bulk(): Adds N resources, need broadcast
//   - If 5 resources returned and 3 threads waiting:
//     - Broadcast wakes all 3, they each get a resource
//   - If we used signal:
//     - Only 1 waiter wakes, gets resource
//     - 4 resources unused, 2 waiters still sleeping

Example: Dynamic Work Distribution

Another common case is when a batch of work items arrives:

Batch Work Distribution
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
// Work queue with batch enqueueing
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t work_available;
    queue_t *work_queue;
} work_distributor_t;
 
// Single work item - signal is appropriate
void submit_work(work_distributor_t *wd, work_t *work) {
    pthread_mutex_lock(&wd->mutex);
    queue_enqueue(wd->work_queue, work);
    pthread_cond_signal(&wd->work_available);  // Wake ONE worker
    pthread_mutex_unlock(&wd->mutex);
}
 
// Batch of work items - broadcast is necessary
void submit_work_batch(work_distributor_t *wd, work_t **work_items, int count) {
    pthread_mutex_lock(&wd->mutex);
    
    for (int i = 0; i < count; i++) {
        queue_enqueue(wd->work_queue, work_items[i]);
    }
    
    // We added 'count' items, up to 'count' workers could be busy
    // Broadcast to maximize parallelism
    pthread_cond_broadcast(&wd->work_available);
    
    pthread_mutex_unlock(&wd->mutex);
}
 
// Alternative: Multiple signals (less efficient but correct)
void submit_work_batch_v2(work_distributor_t *wd, work_t **work_items, int count) {
    pthread_mutex_lock(&wd->mutex);
    
    for (int i = 0; i < count; i++) {
        queue_enqueue(wd->work_queue, work_items[i]);
        pthread_cond_signal(&wd->work_available);  // Signal for each item
    }
    
    pthread_mutex_unlock(&wd->mutex);
}
 
// The broadcast version is typically more efficient because:
// 1. Single synchronization operation instead of 'count' signals
// 2. Less lock contention on internal CV structures
// 3. All wakeups happen in one batch, reducing scheduling overhead

Scenario Category 4: Complex or Varying Conditions

When waiters have varying conditions that they're waiting for—even if they're all the same 'type' of thread—broadcast may be necessary to ensure the right thread wakes up.

Pattern: Waiters with Different Size Requirements

Consider a memory allocator where threads request different-sized blocks:

Variable Size Allocation
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
// Memory allocator with variable size requests
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t memory_freed;
    size_t available_memory;
    // ... memory management structures
} memory_pool_t;
 
// Allocate memory - waiters have DIFFERENT size requirements
void *allocate(memory_pool_t *pool, size_t size) {
    pthread_mutex_lock(&pool->mutex);
    
    // Each waiter needs a DIFFERENT amount
    while (pool->available_memory < size) {
        pthread_cond_wait(&pool->memory_freed, &pool->mutex);
    }
    
    // Allocate the memory
    void *ptr = do_allocation(pool, size);
    pool->available_memory -= size;
    
    pthread_mutex_unlock(&pool->mutex);
    return ptr;
}
 
// Free memory - which waiter should we wake?
void deallocate(memory_pool_t *pool, void *ptr, size_t size) {
    pthread_mutex_lock(&pool->mutex);
    
    do_deallocation(pool, ptr);
    pool->available_memory += size;
    
    // PROBLEM: We freed 'size' bytes
    // Waiter A might need 100 bytes (satisfied if size >= 100)
    // Waiter B might need 1000 bytes (needs more than we freed)
    // Waiter C might need 50 bytes (satisfied if size >= 50)
    //
    // If we signal and wake B, B finds memory insufficient and re-waits
    // A and C remain sleeping despite having enough memory!
    //
    // BROADCAST is necessary here
    pthread_cond_broadcast(&pool->memory_freed);
    
    pthread_mutex_unlock(&pool->mutex);
}
 
// Analysis of why signal fails:
// - Wait queue: [A:100] -> [B:1000] -> [C:50]
// - We free 100 bytes
// - Signal wakes A (first in queue), A proceeds - OK
// 
// - Wait queue: [B:1000] -> [C:50] -> [D:200]
// - We free 75 bytes (total available = 75)
// - Signal wakes B, B needs 1000, re-waits
// - C needs only 50, but C is still sleeping!
// 
// Broadcast wakes everyone, C can proceed while B re-waits

Pattern: Priority-Based Waiting

When threads wait with different priorities or criteria:

Priority-Based Access
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
// Access control with priority levels
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t access_granted;
    int current_priority_threshold;  // Only threads at or above can proceed
    int resource_in_use;
} priority_access_t;
 
// Request access - different threads have different priorities
void request_access(priority_access_t *pa, int my_priority) {
    pthread_mutex_lock(&pa->mutex);
    
    // Wait until resource is free AND our priority is acceptable
    while (pa->resource_in_use || my_priority < pa->current_priority_threshold) {
        pthread_cond_wait(&pa->access_granted, &pa->mutex);
    }
    
    pa->resource_in_use = 1;
    
    pthread_mutex_unlock(&pa->mutex);
}
 
void release_access(priority_access_t *pa) {
    pthread_mutex_lock(&pa->mutex);
    
    pa->resource_in_use = 0;
    
    // BROADCAST: Different waiters have different priorities
    // The waiter with the right priority needs to wake up
    // We can't know which one that is, so wake them all
    pthread_cond_broadcast(&pa->access_granted);
    
    pthread_mutex_unlock(&pa->mutex);
}
 
// Change priority threshold (e.g., entering high-priority mode)
void set_priority_threshold(priority_access_t *pa, int new_threshold) {
    pthread_mutex_lock(&pa->mutex);
    
    pa->current_priority_threshold = new_threshold;
    
    // If we LOWERED the threshold, more threads can now enter
    // BROADCAST to let them check
    pthread_cond_broadcast(&pa->access_granted);
    
    pthread_mutex_unlock(&pa->mutex);
}

When Conditions Vary

Whenever different waiters are waiting for different specific conditions (not just 'resource available' but 'enough resource for MY needs'), broadcast is typically required. This ensures that the right waiter—the one whose specific condition is now satisfied—gets a chance to proceed.

Scenario Category 5: Reader-Writer Lock Transitions

Reader-writer locks present interesting cases where both signal and broadcast have roles to play, depending on the type of transition.

Reader-Writer Lock Signal/Broadcast
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
// Reader-Writer lock with optimal signal/broadcast usage
 
typedef struct {
    pthread_mutex_t mutex;
    pthread_cond_t read_ok;     // Readers wait here
    pthread_cond_t write_ok;    // Writers wait here
    int readers;                // Active readers
    int writers;                // Active writers (0 or 1)
    int waiting_writers;        // Waiting writers
} rwlock_t;
 
void read_lock(rwlock_t *rw) {
    pthread_mutex_lock(&rw->mutex);
    
    // Wait if there's an active writer OR waiting writers (writer preference)
    while (rw->writers > 0 || rw->waiting_writers > 0) {
        pthread_cond_wait(&rw->read_ok, &rw->mutex);
    }
    
    rw->readers++;
    
    pthread_mutex_unlock(&rw->mutex);
}
 
void read_unlock(rwlock_t *rw) {
    pthread_mutex_lock(&rw->mutex);
    
    rw->readers--;
    
    if (rw->readers == 0 && rw->waiting_writers > 0) {
        // Last reader exiting with writers waiting
        // SIGNAL: Only ONE writer can enter at a time anyway
        pthread_cond_signal(&rw->write_ok);
    }
    
    pthread_mutex_unlock(&rw->mutex);
}
 
void write_lock(rwlock_t *rw) {
    pthread_mutex_lock(&rw->mutex);
    
    rw->waiting_writers++;
    
    // Wait for no readers AND no active writer
    while (rw->readers > 0 || rw->writers > 0) {
        pthread_cond_wait(&rw->write_ok, &rw->mutex);
    }
    
    rw->waiting_writers--;
    rw->writers = 1;
    
    pthread_mutex_unlock(&rw->mutex);
}
 
void write_unlock(rwlock_t *rw) {
    pthread_mutex_lock(&rw->mutex);
    
    rw->writers = 0;
    
    if (rw->waiting_writers > 0) {
        // Writers are waiting - give them priority
        // SIGNAL: Only one writer can proceed
        pthread_cond_signal(&rw->write_ok);
    } else {
        // No waiting writers, let all waiting readers in
        // BROADCAST: Multiple readers can proceed simultaneously
        pthread_cond_broadcast(&rw->read_ok);
    }
    
    pthread_mutex_unlock(&rw->mutex);
}
 
// Analysis:
// - read_unlock() uses SIGNAL for write_ok (only one writer at a time)
// - write_unlock() uses SIGNAL for write_ok (only one writer at a time)
// - write_unlock() uses BROADCAST for read_ok (multiple readers can enter)
// 
// The choice depends on HOW MANY can proceed after the state change:
// - Writers: always at most 1 -> signal
// - Readers: potentially many -> broadcast

Reader-Writer Insight

In reader-writer locks, the key insight is: writers are mutually exclusive (signal), but readers can be concurrent (broadcast). When a writer releases the lock and readers are waiting, broadcast allows all readers to enter simultaneously, maximizing read parallelism.

Complete Decision Flowchart

Let's consolidate everything into a systematic decision process you can apply to any synchronization scenario:

┌─────────────────────────────────────────────────────────────────────┐
│              SIGNAL vs BROADCAST DECISION FLOWCHART                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  START: You need to notify waiters on a condition variable          │
│         │                                                           │
│         ▼                                                           │
│  ┌─────────────────────────────────────────────┐                    │
│  │ Q1: Does the state change affect ALL        │                    │
│  │     waiters (shutdown, barrier, config)?    │                    │
│  └───────────────────────────┬─────────────────┘                    │
│                   YES ───────┤                                      │
│                   │          │ NO                                   │
│                   ▼          ▼                                      │
│             ┌──────────┐  ┌─────────────────────────────────────┐   │
│             │ BROADCAST│  │ Q2: Are there heterogeneous waiters │   │
│             └──────────┘  │     (different types waiting for    │   │
│                           │     different conditions)?          │   │
│                           └───────────────────┬─────────────────┘   │
│                                    YES ───────┤                     │
│                                    │          │ NO                  │
│                                    ▼          ▼                     │
│                              ┌──────────┐  ┌──────────────────────┐ │
│                              │ BROADCAST│  │ Q3: Do multiple      │ │
│                              │ (or split │  │     waiters need     │ │
│                              │  CVs)    │  │     different        │ │
│                              └──────────┘  │     conditions?      │ │
│                                            │     (size, priority) │ │
│                                            └──────────┬───────────┘ │
│                                                 YES ──┤             │
│                                                 │     │ NO          │
│                                                 ▼     ▼             │
│                                           ┌──────────┐ Q4: Are     │
│                                           │ BROADCAST│ multiple    │
│                                           └──────────┘ resources   │
│                                                        becoming    │
│                                            YES         available?  │
│                                            ┌───────────────┬───────┤
│                                            ▼               │ NO    │
│                                      ┌──────────┐          ▼       │
│                                      │ BROADCAST│    ┌──────────┐  │
│                                      └──────────┘    │  SIGNAL  │  │
│                                                      │  is safe │  │
│                                                      └──────────┘  │
└─────────────────────────────────────────────────────────────────────┘

Quick Reference Summary
Scenario	Choice	Reason
Server shutdown	BROADCAST	All workers must respond
Barrier release	BROADCAST	All threads must proceed
Producer/consumer, separate CVs	SIGNAL	One waiter per event
Producer/consumer, shared CV	BROADCAST	Heterogeneous waiters
Batch resource release	BROADCAST	Multiple can proceed
Single resource available	SIGNAL	Only one can use it
Variable-size allocation	BROADCAST	Different requirements
RW-lock: writer exit, readers waiting	BROADCAST	Multiple readers can enter
RW-lock: reader exit, writer waiting	SIGNAL	Only one writer allowed

Summary: When to Broadcast

Key Takeaways

•State change scope is key — Ask 'how many threads can meaningfully proceed?' to guide your choice.
•All-waiters cases require broadcast — Shutdown, barriers, and configuration changes affect everyone.
•Heterogeneous waiters require broadcast — When different thread types share a CV, signal can wake the wrong one.
•Multiple resources often need broadcast — When N resources become available, N waiters could proceed.
•Varying conditions need broadcast — When waiters need 'different amounts' of something, broadcast lets the right one proceed.
•When in doubt, broadcast — It's always correct; signal is an optimization requiring proof.

Next Steps:

Now that you know when to broadcast, the next page explores the thundering herd problem—the performance pathology that occurs when broadcast wakes far more threads than can actually proceed, and how to mitigate it.

Page Complete

You now have a systematic framework for deciding between signal and broadcast. You can identify the scenarios that require broadcast and understand why signal would fail in those cases. Next, we'll examine the performance implications when broadcast wakes too many threads.