46:"/_next/static/chunks/33yus346z0l_n.js" 47:"/_next/static/chunks/1r8ezocsukqp8.js" 48:"/_next/static/chunks/0iv56yrji_20j.js" 49:"/_next/static/chunks/0wa9m1-tphf9u.js" 4a:"/_next/static/chunks/08cuqqn_f60pp.js" 4b:"/_next/static/chunks/3zdsl3f9b0--r.js" 4c:"/_next/static/chunks/2j22cxchii_xx.js" 4d:"/_next/static/chunks/3bgoyiso1rhn7.js" 4e:"/_next/static/chunks/01a-3hvnqu8wl.js" 4f:"/_next/static/chunks/3m1xjj5kw5fie.js" 50:"/_next/static/chunks/0om3fkgfnicab.js" 51:"/_next/static/chunks/0gafyzg9j9yqj.js" 52:"/_next/static/chunks/20w4eaqlekefm.js" 53:"/_next/static/chunks/449--h5z1s6nq.js" 54:"/_next/static/chunks/3k2gyg36fnag_.js" 55:"/_next/static/chunks/18ggtgz2yf759.js" 56:"/_next/static/chunks/0hlb44ca7-4a2.js" 57:"/_next/static/chunks/253gnmj0-cj17.js" 58:"/_next/static/chunks/09nq57stwzkgf.js" 59:"/_next/static/chunks/082jo-0ajazgr.js" 5a:"/_next/static/chunks/2ozcrjb_hh74t.js" 5b:"/_next/static/chunks/05i8en-x14ibi.js" 5c:"/_next/static/chunks/32izpn90gvm22.js" 5d:"/_next/static/chunks/0jbzid2v9xv3h.js" 5e:"/_next/static/chunks/0i3-eynrkvqi7.js" 5f:"/_next/static/chunks/1tn-0fivsxsv1.js" 60:"/_next/static/chunks/34h36hyf_ggow.js" 61:"/_next/static/chunks/20329i6m_04t6.js" 62:"/_next/static/chunks/161uxd62cjny2.js" 63:"/_next/static/chunks/2k8pepwc4pxns.js" 64:I[593304,["$2b","$2c","$2d","$2e","$2f","$30","$46","$47","$48","$49","$4a","$4b","$4c","$4d","$4e","$4f","$50","$51","$52","$53","$54","$55","$56","$57","$58","$59","$5a","$5b","$5c","$5d","$5e","$5f","$60","$61","$62","$63"],"OwnedHydration"] 65:T437,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.66:T4a9,// ⚠️ BROKEN: Classic race condition example class NaiveBuffer { 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; } }67:T49d,// ⚠️ BROKEN: Classic race condition example public class NaiveBuffer { private final List buffer = new ArrayList<>(); private final int capacity; public NaiveBuffer(int capacity) { this.capacity = capacity; } // ❌ PRODUCER: Check-then-act race condition public void produce(T item) { // Thread A checks: buffer.size() < capacity (true, size = 9) // Thread B checks: buffer.size() < capacity (true, size = 9) if (buffer.size() < capacity) { // Thread A adds item (size = 10) // Thread B adds item (size = 11) ← OVERFLOW! buffer.add(item); } // Both threads passed the check, but only one slot was available } // ❌ CONSUMER: Check-then-act race condition public T consume() { // Thread A checks: buffer.size() > 0 (true, size = 1) // Thread B checks: buffer.size() > 0 (true, size = 1) if (buffer.size() > 0) { // Thread A removes item (size = 0) // Thread B removes from empty ← IndexOutOfBoundsException return buffer.remove(0); } return null; } }68:T413,# ⚠️ BROKEN: Classic race condition example class NaiveBuffer: def __init__(self, capacity: int): self.buffer: list = [] self.capacity = capacity # ❌ PRODUCER: Check-then-act race condition def produce(self, item) -> None: # Thread A checks: len(buffer) < capacity (true, len = 9) # Thread B checks: len(buffer) < capacity (true, len = 9) if len(self.buffer) < self.capacity: # Thread A adds item (len = 10) # Thread B adds item (len = 11) ← OVERFLOW! self.buffer.append(item) # Both threads passed the check, but only one slot was available # ❌ CONSUMER: Check-then-act race condition def consume(self): # Thread A checks: len(buffer) > 0 (true, len = 1) # Thread B checks: len(buffer) > 0 (true, len = 1) if len(self.buffer) > 0: # Thread A removes item (len = 0) # Thread B pops from empty list ← IndexError! return self.buffer.pop(0) return None69:T64f,// ⚠️ 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 { 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 yielding6a:T5c5,// ⚠️ DEADLOCK SCENARIO // Buffer capacity: 1, Producers: 1, Consumers: 1 public class DeadlockProne { private T item = null; private volatile boolean hasItem = false; private final Object lock = new Object(); // ❌ BROKEN: Wrong lock ordering can cause deadlock public void produce(T newItem) throws InterruptedException { synchronized (lock) { while (hasItem) { lock.wait(); // Wait for consumer // BUG: If consumer also waits on same condition, // and notify isn't called properly, DEADLOCK } item = newItem; hasItem = true; // BUG: What if we forget to notify? // Consumer waits forever! // lock.notifyAll(); // MISSING! } } public T consume() throws InterruptedException { synchronized (lock) { while (!hasItem) { lock.wait(); // Wait for producer // If producer doesn't notify, DEADLOCK } T result = item; hasItem = false; // BUG: What if we forget to notify? // Producer waits forever! // lock.notifyAll(); // MISSING! return result; } } } // Missing notifyAll() calls = guaranteed deadlock // Wrong condition checks = potential deadlock // Single notify() instead of notifyAll() = potential deadlock with multiple threads6b:T4ad,// ⚠️ STARVATION SCENARIO // Multiple consumers competing for items class UnfairBuffer { private items: T[] = []; // When item arrives, only first waiter gets notified // Others may never wake up! async produce(item: T): Promise { 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 { 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 guarantees6c:T504,// ⚠️ STARVATION SCENARIO // Multiple consumers competing for items public class UnfairBuffer { private final Queue items = new LinkedList<>(); private final Object lock = new Object(); public void produce(T item) { synchronized (lock) { items.add(item); // BUG: notify() only wakes ONE waiting consumer // The same "lucky" consumer might always win lock.notify(); // Only one wakes up } } public T consume(String consumerId) throws InterruptedException { synchronized (lock) { while (items.isEmpty()) { lock.wait(); // Even if woken, another consumer might grab item first! // Consumer must re-check condition (while loop, not if) } // Thread that was waiting longest is NOT guaranteed to win return items.poll(); } } } // Result: Consumer A always grabs items (OS scheduling favor) // Consumer B, C, D wait indefinitely = STARVATION // ----------------------------------------- // Fair approach: // 1. Use notifyAll() instead of notify() // 2. Use fair ReentrantLock(true) // 3. Use LinkedBlockingQueue with fair mode // 4. Implement explicit fairness policy45:["$","$L64",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792315934017,"state":{"data":{"json":{"id":"seed_ea1aa3727949eebe8718e1480f709631","slug":"producer-consumer-pattern","category":"System Design (LLD)","topic":"Concurrency Patterns","title":"Producer-Consumer Pattern","description":"Master the Producer-Consumer pattern for coordinating data production and consumption in concurrent systems. Learn bounded buffer implementations, synchronization strategies, and real-world applications across distributed architectures.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_d46d4da586632cfa80ddc6a21b327062","title":"Problem: Coordinating Producers and Consumers","order":0,"content":[{"id":"opening-hook","title":"The Fundamental Coordination Challenge","content":[{"data":{"content":"$65"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"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.","variant":"info"},"type":"callout"}]},{"id":"core-problem-statement","title":"The Core Problem Statement","content":[{"data":{"content":"At its essence, the Producer-Consumer problem describes a coordination challenge with deceptively simple requirements:\n\n1. **Producers** generate data items and place them into a shared buffer\n2. **Consumers** remove data items from the buffer and process them\n3. **The buffer** has finite capacity (it cannot hold unlimited items)\n4. **Coordination** must ensure correctness under concurrent execution\n\nThe problem seems trivial until you consider what happens when:\n- A producer tries to add an item to a **full buffer**\n- A consumer tries to remove an item from an **empty buffer**\n- Multiple producers simultaneously try to add items\n- Multiple consumers simultaneously try to remove items\n- A system crash occurs mid-operation\n\nEach of these scenarios, if handled incorrectly, leads to system failures ranging from subtle data corruption to complete system deadlock."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Illusion of Simplicity","content":"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.","variant":"warning"},"type":"callout"},{"data":{"rows":[["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"]],"caption":"Producer-Consumer Problem Components","headers":["Component","Role","Constraints","Failure Mode"]},"type":"table"}],"titleType":"number","titleNumber":1},{"id":"naive-solutions-fail","title":"Why Naive Solutions Fail","content":[{"data":{"content":"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**.\n\n### The \"Check-Then-Act\" Anti-Pattern\n\nThe most common naive approach involves checking a condition, then taking action based on it:"},"type":"text"},{"data":{"fileName":"naive-producer-consumer.ts","languages":[{"code":"$66","label":"TypeScript","value":"typescript"},{"code":"$67","label":"Java","value":"java"},{"code":"$68","label":"Python","value":"python"}]},"type":"code"},{"data":{"content":"### The Race Condition Anatomy\n\nThe failure pattern above is called a **Time-of-Check to Time-of-Use (TOCTOU)** race condition. The problem occurs because:\n\n1. **Thread A** checks the condition (buffer not full)\n2. **Thread B** checks the same condition (still sees not full)\n3. **Thread A** acts on its check (adds item, now buffer is full)\n4. **Thread B** acts on its **stale** check (adds item, now buffer overflows)\n\nThe 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."},"type":"text"},{"data":{"items":["**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."],"title":{"icon":"AlertCircle","text":"Naive Approach Failure Modes","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"titleType":"number","titleNumber":2},{"id":"rate-mismatch-problem","title":"The Rate Mismatch Problem","content":[{"data":{"content":"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.\n\n### Scenario 1: Producers Faster Than Consumers\n\nWhen production outpaces consumption, the buffer fills up. Without proper handling, several failure modes emerge:"},"type":"text"},{"data":{"left":[{"data":{"items":["**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"],"title":{"icon":"AlertCircle","text":"Fast Producer Problems","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**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"],"title":{"icon":"CheckCircle","text":"Proper Handling","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"### Scenario 2: Consumers Faster Than Producers\n\nWhen consumption outpaces production, the buffer drains completely. This creates a different set of challenges:"},"type":"text"},{"data":{"left":[{"data":{"items":["**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"],"title":{"icon":"AlertCircle","text":"Fast Consumer Problems","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**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"],"title":{"icon":"CheckCircle","text":"Proper Handling","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Info","title":"Real-World Rate Variability","content":"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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"deadlock-danger","title":"The Deadlock Danger","content":[{"data":{"content":"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:\n\n1. **They don't crash** — The system appears frozen but process is still running\n2. **They're intermittent** — May only occur under specific timing conditions\n3. **They're hard to detect** — No error messages, no exceptions, just silence\n4. **They're hard to debug** — Reproducing the exact timing is nearly impossible\n\n### Classic Producer-Consumer Deadlock Scenario\n\nConsider a system with a single-slot buffer:"},"type":"text"},{"data":{"fileName":"deadlock-scenario.ts","languages":[{"code":"$69","label":"TypeScript","value":"typescript"},{"code":"$6a","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"### Four Conditions for Deadlock (Coffman Conditions)\n\nDeadlock occurs when all four of these conditions hold simultaneously:"},"type":"text"},{"data":{"rows":[["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"]],"caption":"Coffman Conditions Applied to Producer-Consumer","headers":["Condition","Definition","Producer-Consumer Example"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"Deadlock in Production","content":"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.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"resource-starvation","title":"Resource Starvation","content":[{"data":{"content":"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.\n\n### Producer Starvation\n\nOccurs when producers cannot add items because:"},"type":"text"},{"data":{"items":["**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"],"variant":"accent"},"type":"list"},{"data":{"content":"### Consumer Starvation\n\nOccurs when consumers cannot retrieve items because:"},"type":"text"},{"data":{"items":["**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"],"variant":"accent"},"type":"list"},{"data":{"fileName":"starvation-example.ts","languages":[{"code":"$6b","label":"TypeScript","value":"typescript"},{"code":"$6c","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Starvation vs Deadlock","content":"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.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"real-world-manifestations","title":"Real-World Manifestations","content":[{"data":{"content":"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."},"type":"text"},{"data":{"rows":[["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"]],"caption":"Producer-Consumer in Production Systems","headers":["System","Producer","Consumer","Buffer","Failure If Broken"]},"type":"table"},{"data":{"content":"### Case Study: Message Queue Failure\n\nConsider a real production incident that illustrates the Producer-Consumer problem:\n\n**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).\n\n**What went wrong:**\n\n1. **Black Friday traffic** caused checkout rate to spike 10x\n2. Fulfillment service couldn't keep up—rate mismatch\n3. Queue's in-memory buffer filled completely\n4. Queue started rejecting new messages (no backpressure to checkout)\n5. Checkout service had no retry logic—orders were lost\n6. Buffer didn't persist to disk—system restart lost queued orders\n\n**Result:** Thousands of orders lost, customer refunds required, reputation damaged.\n\n**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."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Always Ask These Questions","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"requirements-correct-solution","title":"The Requirements for a Correct Solution","content":[{"data":{"content":"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:"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"Target","text":"Correctness Requirements","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"### The Synchronization Building Blocks\n\nTo satisfy these requirements, we need synchronization primitives that provide:"},"type":"text"},{"data":{"rows":[["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"]],"caption":"Required Synchronization Capabilities","headers":["Capability","Purpose","Primitive Examples"]},"type":"table"},{"data":{"icon":"Info","title":"The Next Step","content":"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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Understanding the Problem","content":[{"data":{"content":"Before we can design solutions, we must deeply understand the problem. The Producer-Consumer coordination challenge encompasses:"},"type":"text"},{"data":{"type":"ordered","items":["**The Core Challenge** — Coordinating producers that create data with consumers that process it, using a finite buffer between them.","**Naive Solutions Fail** — Check-then-act patterns create race conditions. Multiple threads can pass the same check and violate constraints.","**Rate Mismatch is Fundamental** — Producers and consumers rarely operate at the same speed. Systems must handle both directions of mismatch gracefully.","**Deadlock is Silent Death** — Improper synchronization leads to all threads waiting forever. No errors, no output, just frozen systems.","**Starvation is Subtle** — Some threads may never progress while others monopolize resources. The system appears to work but is unfair.","**Real Systems Are Complex** — From web servers to message queues to logging systems, the Producer-Consumer problem appears everywhere in production.","**Requirements Are Precise** — A correct solution must guarantee mutual exclusion, respect bounds, ensure progress, prevent starvation, and signal properly."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nWith a deep understanding of the problem space, we're ready to explore the solution. The next page introduces the **bounded buffer with synchronization**—the classic solution to the Producer-Consumer problem. We'll see how proper use of locks, condition variables, and signaling creates a correct, efficient implementation."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the Producer-Consumer coordination problem in depth: the race conditions that break naive solutions, the rate mismatch challenges, the dangers of deadlock and starvation, and the precise requirements for correctness. This foundation is essential for understanding why the solutions work the way they do.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_aa33783934d088a077b0dcb3b0c8c39a","title":"Solution: Bounded Buffer with Synchronization","order":1,"content":null,"isLocked":true},{"id":"seed_1b2ab7a29c0984d887029deca7a1d583","title":"Implementation Strategies","order":2,"content":null,"isLocked":true},{"id":"seed_7b53321dc415252674cfcbb453af33bc","title":"Use Cases and Examples","order":3,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792315933926,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"producer-consumer-pattern"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"producer-consumer-pattern\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315934019,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315934015,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_ea1aa3727949eebe8718e1480f709631"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_ea1aa3727949eebe8718e1480f709631\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315934019,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315934017,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","get"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_aa33783934d088a077b0dcb3b0c8c39a"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_aa33783934d088a077b0dcb3b0c8c39a\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315934019,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792315934017,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","getUserLike"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_aa33783934d088a077b0dcb3b0c8c39a"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_aa33783934d088a077b0dcb3b0c8c39a\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315934019,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792315934017,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["highlights","getHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_aa33783934d088a077b0dcb3b0c8c39a"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_aa33783934d088a077b0dcb3b0c8c39a\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792315934019,"state":{"data":"$undefined","dataUpdateCount":0,"dataUpdatedAt":0,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"pending","fetchStatus":"fetching"},"queryKey":[["highlights","getPopularHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_aa33783934d088a077b0dcb3b0c8c39a","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_aa33783934d088a077b0dcb3b0c8c39a\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@6d"}]},"children":"$L6e"}]