Problem: Coordinating… — Producer-Consumer Pattern | OneNoughtOne

0/105

System Design (LLD)Concurrency Patterns

Producer-Consumer Pattern

LevelIntermediate

Duration90 mins

TopicConcurrency Patterns

1 / 4

Problem: Coordinating Producers and Consumers

The Fundamental Coordination Challenge

In concurrent programming, one of the most ubiquitous challenges is coordinating work between entities that produce data and entities that consume it . This seemingly simple problem—one component creates something, another component uses it—becomes extraordinarily complex when production and consumption happen at different rates, across different threads, and with limited buffer space between them. The Producer-Consumer problem is not merely an academic exercise; it is the foundational coordination pattern underlying nearly every concurrent system you have ever used. From web servers handling requests to message queues processing events, from logging systems writing to disk to video players buffering streams—this pattern is everywhere. Understanding this problem deeply is essential because getting it wrong leads to some of the most insidious bugs in software engineering : deadlocks that freeze systems, race conditions that corrupt data, resource exhaustion that crashes applications, and starvation that makes systems mysteriously stop processing.

What You Will Learn

By the end of this page, you will deeply understand the producer-consumer coordination problem: why naive approaches fail catastrophically, what specific challenges arise when producers and consumers operate at different speeds, and why proper synchronization is non-negotiable in concurrent systems.

The Core Problem Statement

At its essence, the Producer-Consumer problem describes a coordination challenge with deceptively simple requirements: Producers generate data items and place them into a shared buffer Consumers remove data items from the buffer and process them The buffer has finite capacity (it cannot hold unlimited items) Coordination must ensure correctness under concurrent execution The problem seems trivial until you consider what happens when: A producer tries to add an item to a full buffer A consumer tries to remove an item from an empty buffer Multiple producers simultaneously try to add items Multiple consumers simultaneously try to remove items A system crash occurs mid-operation Each of these scenarios, if handled incorrectly, leads to system failures ranging from subtle data corruption to complete system deadlock.

The Illusion of Simplicity

Many developers underestimate this problem because single-threaded solutions are trivial. But concurrency transforms 'add to queue' from a one-liner into a minefield of race conditions. The gap between 'works on my machine' and 'works under production load' is measured in countless debugging hours.

Producer-Consumer Problem Components
Component	Role	Constraints	Failure Mode
Producer	Creates data items	Cannot produce if buffer is full	Blocks indefinitely or data loss
Consumer	Processes data items	Cannot consume if buffer is empty	Blocks indefinitely or null processing
Buffer	Holds items temporarily	Fixed capacity, thread-safe access	Overflow, underflow, corruption
Coordinator	Manages access	Must ensure atomicity	Race conditions, deadlocks

Why Naive Solutions Fail

To truly appreciate the complexity of the Producer-Consumer problem, we must examine why intuitive, straightforward solutions fail catastrophically under concurrent execution. Understanding these failures is essential because they represent the exact bugs you will create if you don't apply proper synchronization . The "Check-Then-Act" Anti-Pattern The most common naive approach involves checking a condition, then taking action based on it:

naive-producer-consumer.ts
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
// ⚠️ BROKEN: Classic race condition example
class NaiveBuffer<T> {
    private buffer: T[] = [];
    private readonly capacity: number;
    
    constructor(capacity: number) {
        this.capacity = capacity;
    }
    
    // ❌ PRODUCER: Check-then-act race condition
    produce(item: T): void {
        // Thread A checks: buffer.length < capacity (true, length = 9)
        // Thread B checks: buffer.length < capacity (true, length = 9)
        if (this.buffer.length < this.capacity) {
            // Thread A adds item (length = 10)
            // Thread B adds item (length = 11) ← OVERFLOW!
            this.buffer.push(item);
        }
        // Both threads passed the check, but only one slot was available
    }
    
    // ❌ CONSUMER: Check-then-act race condition
    consume(): T | undefined {
        // Thread A checks: buffer.length > 0 (true, length = 1)
        // Thread B checks: buffer.length > 0 (true, length = 1)
        if (this.buffer.length > 0) {
            // Thread A removes item (length = 0)
            // Thread B calls shift() on empty array ← UNDEFINED!
            return this.buffer.shift();
        }
        return undefined;
    }
}

The Race Condition Anatomy The failure pattern above is called a Time-of-Check to Time-of-Use (TOCTOU) race condition. The problem occurs because: Thread A checks the condition (buffer not full) Thread B checks the same condition (still sees not full) Thread A acts on its check (adds item, now buffer is full) Thread B acts on its stale check (adds item, now buffer overflows) The check and the action are not atomic —another thread can interleave between them. This window of vulnerability is called the race window, and it exists regardless of how fast the operations appear.

Naive Approach Failure Modes

•Buffer Overflow — Multiple producers pass the capacity check simultaneously, causing buffer to exceed its limit and potentially crash or corrupt memory.
•Buffer Underflow — Multiple consumers pass the empty check simultaneously, causing reads from empty buffer leading to null values, exceptions, or undefined behavior.
•Lost Updates — Two threads read the same buffer state, make decisions, and both write—one update is silently lost without any error indication.
•Data Corruption — Partial writes interleave with reads, producing items that are half-written or contain mixed data from multiple sources.
•Heisenbugs — Failures that disappear when you add logging or debugging, because the additional code changes timing and masks the race condition.

The Rate Mismatch Problem

Beyond thread safety, the Producer-Consumer problem must address a fundamental reality: producers and consumers rarely operate at the same rate . This rate mismatch creates distinct challenges that must be handled explicitly. Scenario 1: Producers Faster Than Consumers When production outpaces consumption, the buffer fills up. Without proper handling, several failure modes emerge:

Fast Producer Problems

•Memory Exhaustion — Unbounded buffer grows until system runs out of memory
•Data Loss — Items dropped when buffer is full, potentially losing critical data
•Latency Explosion — Items wait increasingly long in buffer before processing
•Backpressure Collapse — Upstream systems overwhelmed when they can't write
•Cascade Failures — One slow consumer causes entire pipeline to back up

Proper Handling

•Bounded Buffers — Fixed capacity prevents memory exhaustion
•Blocking Producers — Producers wait when buffer is full
•Timeouts — Producers fail fast with timeout rather than block forever
•Backpressure Signals — Communicate overflow upstream
•Overflow Policies — Drop oldest, drop newest, or reject with error

Scenario 2: Consumers Faster Than Producers When consumption outpaces production, the buffer drains completely. This creates a different set of challenges:

Fast Consumer Problems

•Busy Waiting — Consumers spin-check for items, wasting CPU cycles
•Polling Overhead — Repeated empty checks consume resources
•Starvation — Consumers block indefinitely waiting for items
•Resource Waste — Consumer threads idle, consuming memory and context-switch overhead
•Latency Spikes — Items not processed immediately when they arrive

Proper Handling

•Blocking Consumers — Consumers sleep until items arrive
•Condition Variables — Efficient wait/notify mechanism
•Timeouts — Consumers can give up and check for shutdown
•Batch Processing — Wait for multiple items before processing
•Adaptive Scaling — Reduce consumer count when work is scarce

Real-World Rate Variability

In production systems, rates are never constant. Traffic spikes cause sudden production bursts. Consumer processing time varies based on item complexity. Network latency introduces unpredictable delays. A robust Producer-Consumer implementation must handle this dynamic variability gracefully.

The Deadlock Danger

One of the most dangerous failure modes in Producer-Consumer systems is deadlock —a state where all threads are waiting for conditions that can never be satisfied. Deadlocks are particularly insidious because: They don't crash — The system appears frozen but process is still running They're intermittent — May only occur under specific timing conditions They're hard to detect — No error messages, no exceptions, just silence They're hard to debug — Reproducing the exact timing is nearly impossible Classic Producer-Consumer Deadlock Scenario Consider a system with a single-slot buffer:

deadlock-scenario.ts
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
// ⚠️ DEADLOCK SCENARIO
// Buffer capacity: 1, Producers: 1, Consumers: 1
 
// Initial state: buffer is empty
 
// Step 1: Consumer runs first, sees empty buffer
// Consumer: "Buffer is empty, I'll wait for producer"
// Consumer WAITS (but has no way to be notified)
 
// Step 2: Producer runs, buffer is empty so it can add
// Producer: "Buffer has space, adding item"  
// Producer adds item (buffer now has 1 item)
// Producer: "Done! But how do I tell consumer to wake up?"
// Producer has no mechanism to notify consumer!
 
// Step 3: Consumer is still waiting
// Producer is still running (or exits)
// Consumer waits FOREVER for notification that never comes
 
// DEADLOCK: Consumer blocked, producer not signaling
 
// ---------------------------------------------
// Even worse with poor signaling:
 
class DeadlockProne<T> {
    private item: T | null = null;
    private hasItem = false;
    
    // Problematic: Uses busy-wait that can cause livelock
    produce(newItem: T): void {
        while (this.hasItem) {
            // Busy wait - wastes CPU, may never yield
            // If producer never yields, consumer never runs
        }
        this.item = newItem;
        this.hasItem = true;
    }
    
    consume(): T {
        while (!this.hasItem) {
            // Busy wait - same problem
            // JavaScript is single-threaded, this is infinite loop!
        }
        const result = this.item!;
        this.hasItem = false;
        return result;
    }
}
 
// In single-threaded environments like JS, this is ALWAYS deadlock
// In multi-threaded, it depends on scheduler and CPU yielding

Four Conditions for Deadlock (Coffman Conditions) Deadlock occurs when all four of these conditions hold simultaneously:

Coffman Conditions Applied to Producer-Consumer
Condition	Definition	Producer-Consumer Example
Mutual Exclusion	Resources cannot be shared	Only one thread can modify buffer at a time
Hold and Wait	Holding one resource while waiting for another	Holding buffer lock while waiting for space/items
No Preemption	Resources cannot be forcibly taken	Cannot force a thread to release buffer access
Circular Wait	Circular chain of waiting	Producer waits for consumer, consumer waits for producer's signal

Deadlock in Production

A deadlock in a production system can be catastrophic. Message queues stop processing. Order processing halts. Users see spinning loaders that never resolve. The entire system appears frozen while consuming full resources. Without proper monitoring, deadlocks can go undetected for hours.

Resource Starvation

Even when deadlock is avoided, Producer-Consumer systems can suffer from starvation —a condition where some threads are perpetually denied access to resources while others monopolize them. Producer Starvation Occurs when producers cannot add items because:

•Slow consumers keep buffer perpetually full
•Priority inversion allows consumers to always acquire the lock first
•Unfair scheduling repeatedly skips producer threads
•Large batch consumers drain buffer completely, refill triggers competition where producers lose

Consumer Starvation Occurs when consumers cannot retrieve items because:

•Slow producers keep buffer perpetually empty despite consumer demand
•Unfair wake-up always chooses the same consumer subset
•Greedy consumers with poor synchronization grab all items before others wake
•Priority scheduling favors certain consumer threads

starvation-example.ts
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
// ⚠️ STARVATION SCENARIO
// Multiple consumers competing for items
 
class UnfairBuffer<T> {
    private items: T[] = [];
    
    // When item arrives, only first waiter gets notified
    // Others may never wake up!
    
    async produce(item: T): Promise<void> {
        this.items.push(item);
        // BUG: notify() only wakes ONE waiting consumer
        // The same "lucky" consumer might always win
        this.notifyOneWaiter();  // Only one wakes up
    }
    
    async consume(consumerId: string): Promise<T> {
        while (this.items.length === 0) {
            await this.wait();
            // Even if woken, another consumer might grab item first!
            // Consumer must re-check condition (while loop, not if)
        }
        // Multiple consumers might reach here simultaneously
        // Only one will get an item, others loop back
        return this.items.shift()!;
    }
}
 
// Result: Consumer A always grabs items
// Consumer B, C, D wait indefinitely = STARVATION
 
// -----------------------------------------
// Fair approach requires:
// 1. notifyAll() instead of notify()
// 2. FIFO ordering of waiters
// 3. Bounded wait times with fairness guarantees

Starvation vs Deadlock

Unlike deadlock where ALL threads stop, starvation means SOME threads never progress while others continue. This makes starvation harder to detect—the system appears to be working, but some consumers never process items or some producers never get to write. In logs, you'll see certain threads with zero throughput.

Real-World Manifestations

The Producer-Consumer problem isn't abstract theory—it manifests constantly in production systems. Understanding these real-world examples helps you recognize when you're implementing (or misimplementing) this pattern.

Producer-Consumer in Production Systems
System	Producer	Consumer	Buffer	Failure If Broken
Web Server	Network listener accepting connections	Worker threads handling requests	Connection queue	Dropped connections, timeouts
Message Queue	Publishers sending events	Subscribers processing events	Message broker queue	Message loss, duplicate processing
Logging System	Application code writing logs	Log aggregator/shipper	In-memory log buffer	Lost logs, memory exhaustion
Video Streaming	Network buffer receiving frames	Video decoder rendering	Frame buffer	Buffering, playback stuttering
Database	Transaction processors	Write-ahead log flusher	WAL buffer	Data loss, corruption
Print Spooler	Applications sending documents	Printer processing jobs	Print queue	Lost print jobs, memory issues

Case Study: Message Queue Failure Consider a real production incident that illustrates the Producer-Consumer problem: Scenario: An e-commerce platform uses a message queue for order processing. The queue sits between the checkout service (producer) and the fulfillment service (consumer). What went wrong: Black Friday traffic caused checkout rate to spike 10x Fulfillment service couldn't keep up—rate mismatch Queue's in-memory buffer filled completely Queue started rejecting new messages (no backpressure to checkout) Checkout service had no retry logic—orders were lost Buffer didn't persist to disk—system restart lost queued orders Result: Thousands of orders lost, customer refunds required, reputation damaged. Root cause: The team didn't think about the Producer-Consumer problem holistically. They assumed "queue handles it" without considering buffer limits, rate mismatches, or failure handling.

Always Ask These Questions

When designing any concurrent system with data flow: What happens when the buffer is full? What happens when the buffer is empty? What's the maximum latency an item can endure in the buffer? What happens if a producer or consumer crashes? How do we handle rate mismatches? Answering these questions IS the Producer-Consumer pattern.

The Requirements for a Correct Solution

Having explored how things go wrong, let's now articulate what a correct Producer-Consumer implementation must guarantee. These requirements form the specification that any proper solution must satisfy:

Correctness Requirements

•Mutual Exclusion — Only one thread modifies the buffer at any time. Concurrent modifications must be prevented to avoid corruption.
•Buffer Bounds Respected — Producers cannot add to a full buffer. Consumers cannot remove from an empty buffer. Capacity constraints are never violated.
•Progress (No Deadlock) — If producers want to produce and there's space, they eventually succeed. If consumers want to consume and there are items, they eventually succeed.
•Bounded Waiting (No Starvation) — Every producer and consumer that requests access will eventually be granted access. No thread waits indefinitely.
•Correct Signaling — When space becomes available, blocked producers are notified. When items become available, blocked consumers are notified.
•Order Preservation (Optional) — Depending on requirements, items may need FIFO ordering—first produced = first consumed.

The Synchronization Building Blocks To satisfy these requirements, we need synchronization primitives that provide:

Required Synchronization Capabilities
Capability	Purpose	Primitive Examples
Mutual Exclusion	Protect buffer from concurrent access	Mutex, Lock, synchronized blocks
Condition Waiting	Block until condition is satisfied	Condition variables, wait/notify
Atomic Operations	Check-and-act atomically	Compare-and-swap, atomic counters
Thread Signaling	Wake blocked threads when state changes	notify, signal, semaphores

The Next Step

In the next page, we'll explore the solution to this problem: the bounded buffer with proper synchronization. We'll see how semaphores, condition variables, and locks combine to create a correct, efficient implementation that satisfies all these requirements.

System Design (LLD)Concurrency Patterns

Producer-Consumer Pattern

LevelIntermediate

Duration90 mins

TopicConcurrency Patterns

1 / 4

Problem: Coordinating Producers and Consumers

The Fundamental Coordination Challenge

In concurrent programming, one of the most ubiquitous challenges is coordinating work between entities that produce data and entities that consume it . This seemingly simple problem—one component creates something, another component uses it—becomes extraordinarily complex when production and consumption happen at different rates, across different threads, and with limited buffer space between them. The Producer-Consumer problem is not merely an academic exercise; it is the foundational coordination pattern underlying nearly every concurrent system you have ever used. From web servers handling requests to message queues processing events, from logging systems writing to disk to video players buffering streams—this pattern is everywhere. Understanding this problem deeply is essential because getting it wrong leads to some of the most insidious bugs in software engineering : deadlocks that freeze systems, race conditions that corrupt data, resource exhaustion that crashes applications, and starvation that makes systems mysteriously stop processing.

What You Will Learn

By the end of this page, you will deeply understand the producer-consumer coordination problem: why naive approaches fail catastrophically, what specific challenges arise when producers and consumers operate at different speeds, and why proper synchronization is non-negotiable in concurrent systems.

The Core Problem Statement

At its essence, the Producer-Consumer problem describes a coordination challenge with deceptively simple requirements: Producers generate data items and place them into a shared buffer Consumers remove data items from the buffer and process them The buffer has finite capacity (it cannot hold unlimited items) Coordination must ensure correctness under concurrent execution The problem seems trivial until you consider what happens when: A producer tries to add an item to a full buffer A consumer tries to remove an item from an empty buffer Multiple producers simultaneously try to add items Multiple consumers simultaneously try to remove items A system crash occurs mid-operation Each of these scenarios, if handled incorrectly, leads to system failures ranging from subtle data corruption to complete system deadlock.

The Illusion of Simplicity

Many developers underestimate this problem because single-threaded solutions are trivial. But concurrency transforms 'add to queue' from a one-liner into a minefield of race conditions. The gap between 'works on my machine' and 'works under production load' is measured in countless debugging hours.

Producer-Consumer Problem Components
Component	Role	Constraints	Failure Mode
Producer	Creates data items	Cannot produce if buffer is full	Blocks indefinitely or data loss
Consumer	Processes data items	Cannot consume if buffer is empty	Blocks indefinitely or null processing
Buffer	Holds items temporarily	Fixed capacity, thread-safe access	Overflow, underflow, corruption
Coordinator	Manages access	Must ensure atomicity	Race conditions, deadlocks

Why Naive Solutions Fail

To truly appreciate the complexity of the Producer-Consumer problem, we must examine why intuitive, straightforward solutions fail catastrophically under concurrent execution. Understanding these failures is essential because they represent the exact bugs you will create if you don't apply proper synchronization . The "Check-Then-Act" Anti-Pattern The most common naive approach involves checking a condition, then taking action based on it:

naive-producer-consumer.ts
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
// ⚠️ BROKEN: Classic race condition example
class NaiveBuffer<T> {
    private buffer: T[] = [];
    private readonly capacity: number;
    
    constructor(capacity: number) {
        this.capacity = capacity;
    }
    
    // ❌ PRODUCER: Check-then-act race condition
    produce(item: T): void {
        // Thread A checks: buffer.length < capacity (true, length = 9)
        // Thread B checks: buffer.length < capacity (true, length = 9)
        if (this.buffer.length < this.capacity) {
            // Thread A adds item (length = 10)
            // Thread B adds item (length = 11) ← OVERFLOW!
            this.buffer.push(item);
        }
        // Both threads passed the check, but only one slot was available
    }
    
    // ❌ CONSUMER: Check-then-act race condition
    consume(): T | undefined {
        // Thread A checks: buffer.length > 0 (true, length = 1)
        // Thread B checks: buffer.length > 0 (true, length = 1)
        if (this.buffer.length > 0) {
            // Thread A removes item (length = 0)
            // Thread B calls shift() on empty array ← UNDEFINED!
            return this.buffer.shift();
        }
        return undefined;
    }
}

The Race Condition Anatomy The failure pattern above is called a Time-of-Check to Time-of-Use (TOCTOU) race condition. The problem occurs because: Thread A checks the condition (buffer not full) Thread B checks the same condition (still sees not full) Thread A acts on its check (adds item, now buffer is full) Thread B acts on its stale check (adds item, now buffer overflows) The check and the action are not atomic —another thread can interleave between them. This window of vulnerability is called the race window, and it exists regardless of how fast the operations appear.

Naive Approach Failure Modes

•Buffer Overflow — Multiple producers pass the capacity check simultaneously, causing buffer to exceed its limit and potentially crash or corrupt memory.
•Buffer Underflow — Multiple consumers pass the empty check simultaneously, causing reads from empty buffer leading to null values, exceptions, or undefined behavior.
•Lost Updates — Two threads read the same buffer state, make decisions, and both write—one update is silently lost without any error indication.
•Data Corruption — Partial writes interleave with reads, producing items that are half-written or contain mixed data from multiple sources.
•Heisenbugs — Failures that disappear when you add logging or debugging, because the additional code changes timing and masks the race condition.

The Rate Mismatch Problem

Beyond thread safety, the Producer-Consumer problem must address a fundamental reality: producers and consumers rarely operate at the same rate . This rate mismatch creates distinct challenges that must be handled explicitly. Scenario 1: Producers Faster Than Consumers When production outpaces consumption, the buffer fills up. Without proper handling, several failure modes emerge:

Fast Producer Problems

•Memory Exhaustion — Unbounded buffer grows until system runs out of memory
•Data Loss — Items dropped when buffer is full, potentially losing critical data
•Latency Explosion — Items wait increasingly long in buffer before processing
•Backpressure Collapse — Upstream systems overwhelmed when they can't write
•Cascade Failures — One slow consumer causes entire pipeline to back up

Proper Handling

•Bounded Buffers — Fixed capacity prevents memory exhaustion
•Blocking Producers — Producers wait when buffer is full
•Timeouts — Producers fail fast with timeout rather than block forever
•Backpressure Signals — Communicate overflow upstream
•Overflow Policies — Drop oldest, drop newest, or reject with error

Scenario 2: Consumers Faster Than Producers When consumption outpaces production, the buffer drains completely. This creates a different set of challenges:

Fast Consumer Problems

•Busy Waiting — Consumers spin-check for items, wasting CPU cycles
•Polling Overhead — Repeated empty checks consume resources
•Starvation — Consumers block indefinitely waiting for items
•Resource Waste — Consumer threads idle, consuming memory and context-switch overhead
•Latency Spikes — Items not processed immediately when they arrive

Proper Handling

•Blocking Consumers — Consumers sleep until items arrive
•Condition Variables — Efficient wait/notify mechanism
•Timeouts — Consumers can give up and check for shutdown
•Batch Processing — Wait for multiple items before processing
•Adaptive Scaling — Reduce consumer count when work is scarce

Real-World Rate Variability

In production systems, rates are never constant. Traffic spikes cause sudden production bursts. Consumer processing time varies based on item complexity. Network latency introduces unpredictable delays. A robust Producer-Consumer implementation must handle this dynamic variability gracefully.

The Deadlock Danger

One of the most dangerous failure modes in Producer-Consumer systems is deadlock —a state where all threads are waiting for conditions that can never be satisfied. Deadlocks are particularly insidious because: They don't crash — The system appears frozen but process is still running They're intermittent — May only occur under specific timing conditions They're hard to detect — No error messages, no exceptions, just silence They're hard to debug — Reproducing the exact timing is nearly impossible Classic Producer-Consumer Deadlock Scenario Consider a system with a single-slot buffer:

deadlock-scenario.ts
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
// ⚠️ DEADLOCK SCENARIO
// Buffer capacity: 1, Producers: 1, Consumers: 1
 
// Initial state: buffer is empty
 
// Step 1: Consumer runs first, sees empty buffer
// Consumer: "Buffer is empty, I'll wait for producer"
// Consumer WAITS (but has no way to be notified)
 
// Step 2: Producer runs, buffer is empty so it can add
// Producer: "Buffer has space, adding item"  
// Producer adds item (buffer now has 1 item)
// Producer: "Done! But how do I tell consumer to wake up?"
// Producer has no mechanism to notify consumer!
 
// Step 3: Consumer is still waiting
// Producer is still running (or exits)
// Consumer waits FOREVER for notification that never comes
 
// DEADLOCK: Consumer blocked, producer not signaling
 
// ---------------------------------------------
// Even worse with poor signaling:
 
class DeadlockProne<T> {
    private item: T | null = null;
    private hasItem = false;
    
    // Problematic: Uses busy-wait that can cause livelock
    produce(newItem: T): void {
        while (this.hasItem) {
            // Busy wait - wastes CPU, may never yield
            // If producer never yields, consumer never runs
        }
        this.item = newItem;
        this.hasItem = true;
    }
    
    consume(): T {
        while (!this.hasItem) {
            // Busy wait - same problem
            // JavaScript is single-threaded, this is infinite loop!
        }
        const result = this.item!;
        this.hasItem = false;
        return result;
    }
}
 
// In single-threaded environments like JS, this is ALWAYS deadlock
// In multi-threaded, it depends on scheduler and CPU yielding

Four Conditions for Deadlock (Coffman Conditions) Deadlock occurs when all four of these conditions hold simultaneously:

Coffman Conditions Applied to Producer-Consumer
Condition	Definition	Producer-Consumer Example
Mutual Exclusion	Resources cannot be shared	Only one thread can modify buffer at a time
Hold and Wait	Holding one resource while waiting for another	Holding buffer lock while waiting for space/items
No Preemption	Resources cannot be forcibly taken	Cannot force a thread to release buffer access
Circular Wait	Circular chain of waiting	Producer waits for consumer, consumer waits for producer's signal

Deadlock in Production

A deadlock in a production system can be catastrophic. Message queues stop processing. Order processing halts. Users see spinning loaders that never resolve. The entire system appears frozen while consuming full resources. Without proper monitoring, deadlocks can go undetected for hours.

Resource Starvation

Even when deadlock is avoided, Producer-Consumer systems can suffer from starvation —a condition where some threads are perpetually denied access to resources while others monopolize them. Producer Starvation Occurs when producers cannot add items because:

•Slow consumers keep buffer perpetually full
•Priority inversion allows consumers to always acquire the lock first
•Unfair scheduling repeatedly skips producer threads
•Large batch consumers drain buffer completely, refill triggers competition where producers lose

Consumer Starvation Occurs when consumers cannot retrieve items because:

•Slow producers keep buffer perpetually empty despite consumer demand
•Unfair wake-up always chooses the same consumer subset
•Greedy consumers with poor synchronization grab all items before others wake
•Priority scheduling favors certain consumer threads

starvation-example.ts
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
// ⚠️ STARVATION SCENARIO
// Multiple consumers competing for items
 
class UnfairBuffer<T> {
    private items: T[] = [];
    
    // When item arrives, only first waiter gets notified
    // Others may never wake up!
    
    async produce(item: T): Promise<void> {
        this.items.push(item);
        // BUG: notify() only wakes ONE waiting consumer
        // The same "lucky" consumer might always win
        this.notifyOneWaiter();  // Only one wakes up
    }
    
    async consume(consumerId: string): Promise<T> {
        while (this.items.length === 0) {
            await this.wait();
            // Even if woken, another consumer might grab item first!
            // Consumer must re-check condition (while loop, not if)
        }
        // Multiple consumers might reach here simultaneously
        // Only one will get an item, others loop back
        return this.items.shift()!;
    }
}
 
// Result: Consumer A always grabs items
// Consumer B, C, D wait indefinitely = STARVATION
 
// -----------------------------------------
// Fair approach requires:
// 1. notifyAll() instead of notify()
// 2. FIFO ordering of waiters
// 3. Bounded wait times with fairness guarantees

Starvation vs Deadlock

Unlike deadlock where ALL threads stop, starvation means SOME threads never progress while others continue. This makes starvation harder to detect—the system appears to be working, but some consumers never process items or some producers never get to write. In logs, you'll see certain threads with zero throughput.

Real-World Manifestations

The Producer-Consumer problem isn't abstract theory—it manifests constantly in production systems. Understanding these real-world examples helps you recognize when you're implementing (or misimplementing) this pattern.

Producer-Consumer in Production Systems
System	Producer	Consumer	Buffer	Failure If Broken
Web Server	Network listener accepting connections	Worker threads handling requests	Connection queue	Dropped connections, timeouts
Message Queue	Publishers sending events	Subscribers processing events	Message broker queue	Message loss, duplicate processing
Logging System	Application code writing logs	Log aggregator/shipper	In-memory log buffer	Lost logs, memory exhaustion
Video Streaming	Network buffer receiving frames	Video decoder rendering	Frame buffer	Buffering, playback stuttering
Database	Transaction processors	Write-ahead log flusher	WAL buffer	Data loss, corruption
Print Spooler	Applications sending documents	Printer processing jobs	Print queue	Lost print jobs, memory issues

Case Study: Message Queue Failure Consider a real production incident that illustrates the Producer-Consumer problem: Scenario: An e-commerce platform uses a message queue for order processing. The queue sits between the checkout service (producer) and the fulfillment service (consumer). What went wrong: Black Friday traffic caused checkout rate to spike 10x Fulfillment service couldn't keep up—rate mismatch Queue's in-memory buffer filled completely Queue started rejecting new messages (no backpressure to checkout) Checkout service had no retry logic—orders were lost Buffer didn't persist to disk—system restart lost queued orders Result: Thousands of orders lost, customer refunds required, reputation damaged. Root cause: The team didn't think about the Producer-Consumer problem holistically. They assumed "queue handles it" without considering buffer limits, rate mismatches, or failure handling.

Always Ask These Questions

When designing any concurrent system with data flow: What happens when the buffer is full? What happens when the buffer is empty? What's the maximum latency an item can endure in the buffer? What happens if a producer or consumer crashes? How do we handle rate mismatches? Answering these questions IS the Producer-Consumer pattern.

The Requirements for a Correct Solution

Having explored how things go wrong, let's now articulate what a correct Producer-Consumer implementation must guarantee. These requirements form the specification that any proper solution must satisfy:

Correctness Requirements

•Mutual Exclusion — Only one thread modifies the buffer at any time. Concurrent modifications must be prevented to avoid corruption.
•Buffer Bounds Respected — Producers cannot add to a full buffer. Consumers cannot remove from an empty buffer. Capacity constraints are never violated.
•Progress (No Deadlock) — If producers want to produce and there's space, they eventually succeed. If consumers want to consume and there are items, they eventually succeed.
•Bounded Waiting (No Starvation) — Every producer and consumer that requests access will eventually be granted access. No thread waits indefinitely.
•Correct Signaling — When space becomes available, blocked producers are notified. When items become available, blocked consumers are notified.
•Order Preservation (Optional) — Depending on requirements, items may need FIFO ordering—first produced = first consumed.

The Synchronization Building Blocks To satisfy these requirements, we need synchronization primitives that provide:

Required Synchronization Capabilities
Capability	Purpose	Primitive Examples
Mutual Exclusion	Protect buffer from concurrent access	Mutex, Lock, synchronized blocks
Condition Waiting	Block until condition is satisfied	Condition variables, wait/notify
Atomic Operations	Check-and-act atomically	Compare-and-swap, atomic counters
Thread Signaling	Wake blocked threads when state changes	notify, signal, semaphores

The Next Step

In the next page, we'll explore the solution to this problem: the bounded buffer with proper synchronization. We'll see how semaphores, condition variables, and locks combine to create a correct, efficient implementation that satisfies all these requirements.

Problem: Coordinating Producers and Consumers

The Fundamental Coordination Challenge

The Core Problem Statement

Why Naive Solutions Fail

The "Check-Then-Act" Anti-Pattern

The Race Condition Anatomy

The Rate Mismatch Problem

Scenario 1: Producers Faster Than Consumers

Scenario 2: Consumers Faster Than Producers

The Deadlock Danger

Classic Producer-Consumer Deadlock Scenario

Four Conditions for Deadlock (Coffman Conditions)

Resource Starvation

Producer Starvation

Consumer Starvation

Real-World Manifestations

Case Study: Message Queue Failure

The Requirements for a Correct Solution

The Synchronization Building Blocks

There’s more to understand.

Problem: Coordinating Producers and Consumers

The Fundamental Coordination Challenge

The Core Problem Statement

Why Naive Solutions Fail

The "Check-Then-Act" Anti-Pattern

The Race Condition Anatomy

The Rate Mismatch Problem

Scenario 1: Producers Faster Than Consumers

Scenario 2: Consumers Faster Than Producers

The Deadlock Danger

Classic Producer-Consumer Deadlock Scenario

Four Conditions for Deadlock (Coffman Conditions)

Resource Starvation

Producer Starvation

Consumer Starvation

Real-World Manifestations

Case Study: Message Queue Failure

The Requirements for a Correct Solution

The Synchronization Building Blocks

There’s more to understand.