44:"/_next/static/chunks/33yus346z0l_n.js" 45:"/_next/static/chunks/2j22cxchii_xx.js" 46:"/_next/static/chunks/0iv56yrji_20j.js" 47:"/_next/static/chunks/32izpn90gvm22.js" 48:"/_next/static/chunks/3j8bi-zu9bqs4.js" 49:"/_next/static/chunks/1z-pox7hqp2x3.js" 4a:"/_next/static/chunks/20w4eaqlekefm.js" 4b:"/_next/static/chunks/1tn-0fivsxsv1.js" 4c:"/_next/static/chunks/09nq57stwzkgf.js" 4d:"/_next/static/chunks/3m1xjj5kw5fie.js" 4e:"/_next/static/chunks/0gafyzg9j9yqj.js" 4f:"/_next/static/chunks/3k2gyg36fnag_.js" 50:"/_next/static/chunks/3bgoyiso1rhn7.js" 51:"/_next/static/chunks/3cstd6xzfli_o.js" 52:"/_next/static/chunks/253gnmj0-cj17.js" 53:"/_next/static/chunks/0hlb44ca7-4a2.js" 54:"/_next/static/chunks/20329i6m_04t6.js" 55:"/_next/static/chunks/40mq7ggq-ozo4.js" 56:"/_next/static/chunks/082jo-0ajazgr.js" 57:"/_next/static/chunks/2ozcrjb_hh74t.js" 58:"/_next/static/chunks/01a-3hvnqu8wl.js" 59:"/_next/static/chunks/05i8en-x14ibi.js" 5a:"/_next/static/chunks/3m0r7x0jt5wm7.js" 5b:"/_next/static/chunks/2k8pepwc4pxns.js" 5c:"/_next/static/chunks/0wa9m1-tphf9u.js" 5d:"/_next/static/chunks/30jdm3dwz834g.js" 5e:"/_next/static/chunks/0k9bl6dipnsvu.js" 5f:"/_next/static/chunks/18ggtgz2yf759.js" 60:"/_next/static/chunks/0i3-eynrkvqi7.js" 61:I[593304,["$2a","$2b","$2c","$2d","$2e","$2f","$44","$45","$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"],"OwnedHydration"] 62:T882,#include #include #include #define BUFFER_SIZE 10 int buffer[BUFFER_SIZE]; int in = 0; // Next position for producer to insert int out = 0; // Next position for consumer to remove sem_t mutex; // Binary semaphore for mutual exclusion sem_t empty; // Counting semaphore: number of empty slots sem_t full; // Counting semaphore: number of filled slots void init_synchronization() { sem_init(&mutex, 0, 1); // Binary semaphore, initial = 1 sem_init(&empty, 0, BUFFER_SIZE); // Initially all slots are empty sem_init(&full, 0, 0); // Initially no slots are full } void producer(int item) { // Step 1: Wait for an empty slot // Decrements 'empty' count; blocks if 'empty' == 0 sem_wait(&empty); // Step 2: Acquire mutual exclusion to modify buffer sem_wait(&mutex); // Step 3: Critical section - insert item buffer[in] = item; in = (in + 1) % BUFFER_SIZE; printf("Produced: %d at position %d ", item, (in - 1 + BUFFER_SIZE) % BUFFER_SIZE); // Step 4: Release mutual exclusion sem_post(&mutex); // Step 5: Signal that a slot is now full // Increments 'full' count; wakes waiting consumer if any sem_post(&full); } int consumer() { int item; // Step 1: Wait for a full slot // Decrements 'full' count; blocks if 'full' == 0 sem_wait(&full); // Step 2: Acquire mutual exclusion to modify buffer sem_wait(&mutex); // Step 3: Critical section - remove item item = buffer[out]; out = (out + 1) % BUFFER_SIZE; printf("Consumed: %d from position %d ", item, (out - 1 + BUFFER_SIZE) % BUFFER_SIZE); // Step 4: Release mutual exclusion sem_post(&mutex); // Step 5: Signal that a slot is now empty // Increments 'empty' count; wakes waiting producer if any sem_post(&empty); return item; } // Thread functions void* producer_thread(void* arg) { for (int i = 0; i < 20; i++) { producer(i); } return NULL; } void* consumer_thread(void* arg) { for (int i = 0; i < 20; i++) { consumer(); } return NULL; }63:T420,**Correctness Analysis:** Let's verify this implementation satisfies all three requirements: **1. Mutual Exclusion:** - The `mutex` semaphore ensures only one thread executes the critical section at a time - Both producer and consumer acquire `mutex` before modifying `buffer`, `in`, or `out` **2. Buffer-Full Protection:** - Before inserting, producer calls `sem_wait(&empty)` - If `empty == 0` (buffer full), producer blocks - When consumer removes an item, it calls `sem_post(&empty)`, incrementing the count and potentially waking a blocked producer **3. Buffer-Empty Protection:** - Before removing, consumer calls `sem_wait(&full)` - If `full == 0` (buffer empty), consumer blocks - When producer inserts an item, it calls `sem_post(&full)`, incrementing the count and potentially waking a blocked consumer **Invariant:** - At all times: `empty + full = BUFFER_SIZE` (every slot is either empty or full) - This invariant is maintained because every `sem_wait(&empty)` is paired with a `sem_post(&full)` (production), and vice versa (consumption)64:T69b,#include #include #define BUFFER_SIZE 10 int buffer[BUFFER_SIZE]; int count = 0; // Current number of items in buffer int in = 0; // Next insert position int out = 0; // Next remove position pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t not_full = PTHREAD_COND_INITIALIZER; // Signaled when buffer becomes non-full pthread_cond_t not_empty = PTHREAD_COND_INITIALIZER; // Signaled when buffer becomes non-empty void producer(int item) { pthread_mutex_lock(&mutex); // Wait while buffer is full // CRITICAL: Use 'while' not 'if' - handles spurious wakeups while (count == BUFFER_SIZE) { // Atomically: release mutex AND wait for signal // Upon return: mutex is re-acquired pthread_cond_wait(¬_full, &mutex); } // Invariant: count < BUFFER_SIZE (buffer has space) buffer[in] = item; in = (in + 1) % BUFFER_SIZE; count++; printf("Produced: %d (buffer count: %d) ", item, count); // Signal waiting consumers that buffer is no longer empty pthread_cond_signal(¬_empty); pthread_mutex_unlock(&mutex); } int consumer() { int item; pthread_mutex_lock(&mutex); // Wait while buffer is empty while (count == 0) { pthread_cond_wait(¬_empty, &mutex); } // Invariant: count > 0 (buffer has items) item = buffer[out]; out = (out + 1) % BUFFER_SIZE; count--; printf("Consumed: %d (buffer count: %d) ", item, count); // Signal waiting producers that buffer is no longer full pthread_cond_signal(¬_full); pthread_mutex_unlock(&mutex); return item; }65:T48d,// Ring Buffer Implementation Details #define BUFFER_SIZE 8 // Should be power of 2 for optimization typedef struct { int data[BUFFER_SIZE]; int in; // Write index (next position for producer) int out; // Read index (next position for consumer) int count; // Number of items currently in buffer } RingBuffer; // Initialize ring buffer void rb_init(RingBuffer* rb) { rb->in = 0; rb->out = 0; rb->count = 0; } // Check if buffer is empty int rb_is_empty(RingBuffer* rb) { return rb->count == 0; } // Check if buffer is full int rb_is_full(RingBuffer* rb) { return rb->count == BUFFER_SIZE; } // Insert item (assumes buffer is not full) void rb_insert(RingBuffer* rb, int item) { rb->data[rb->in] = item; rb->in = (rb->in + 1) % BUFFER_SIZE; // Wrap around rb->count++; } // Remove item (assumes buffer is not empty) int rb_remove(RingBuffer* rb) { int item = rb->data[rb->out]; rb->out = (rb->out + 1) % BUFFER_SIZE; // Wrap around rb->count--; return item; } // OPTIMIZATION: If BUFFER_SIZE is power of 2, use bitwise AND // (rb->in + 1) & (BUFFER_SIZE - 1) is faster than % BUFFER_SIZE66:T5aa,// MPMC Queue with separate locks (two-lock algorithm) // Reduces contention between producers and consumers typedef struct Node { int value; struct Node* next; } Node; typedef struct { Node* head; // Consumer end Node* tail; // Producer end pthread_mutex_t h_lock; // Lock for head (consumers) pthread_mutex_t t_lock; // Lock for tail (producers) sem_t items; // Count of items sem_t slots; // Count of available slots } TwoLockQueue; void enqueue(TwoLockQueue* q, int value) { sem_wait(&q->slots); // Wait for available slot Node* node = malloc(sizeof(Node)); node->value = value; node->next = NULL; pthread_mutex_lock(&q->t_lock); q->tail->next = node; q->tail = node; pthread_mutex_unlock(&q->t_lock); sem_post(&q->items); // Signal item available } int dequeue(TwoLockQueue* q) { sem_wait(&q->items); // Wait for available item pthread_mutex_lock(&q->h_lock); Node* node = q->head; Node* new_head = node->next; int value = new_head->value; q->head = new_head; pthread_mutex_unlock(&q->h_lock); free(node); sem_post(&q->slots); // Signal slot available return value; } // Key insight: Producers only touch tail, consumers only touch head // This allows concurrent produce and consume operations // Much better scalability than single-lock approach42:["$","$L61",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792309656305,"state":{"data":{"json":{"id":"seed_7309f1f0928cf7a5720ccde483bb68f4","slug":"common-concurrency-patterns","category":"Operating Systems","topic":"Common Concurrency Patterns","title":"Common Concurrency Patterns","description":"Master the foundational concurrency patterns that power modern software systems. From producer-consumer to actor models, learn the patterns that solve real-world coordination problems between concurrent processes and threads.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_97f57d516f043c84bc4c8f456eb0575d","title":"Producer-Consumer Pattern","order":0,"content":[{"id":"opening-hook","title":"The Coordination Problem at the Heart of Concurrent Systems","content":[{"data":{"content":"Imagine a manufacturing assembly line. Workers at one station produce components, placing them on a conveyor belt. Workers at the next station consume these components, assembling them into final products. The belt serves as a buffer—it absorbs differences in production and consumption rates, preventing both bottlenecks and wasted effort.\n\nThis simple industrial metaphor captures one of the most fundamental challenges in concurrent programming: **How do we coordinate work between entities that produce data and entities that consume it?** This is the essence of the **producer-consumer pattern**, also known as the **bounded-buffer problem**—a pattern so pervasive that you'll find it embedded in everything from operating system kernels to web servers, message queues to video streaming pipelines."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will deeply understand the producer-consumer pattern: its theoretical foundations, the synchronization challenges it addresses, multiple implementation strategies using different primitives, performance considerations, and its manifestation across real-world systems. You'll be equipped to recognize, analyze, and implement this pattern in any concurrent environment.","variant":"info"},"type":"callout"}]},{"id":"pattern-definition","title":"Pattern Definition and Core Concepts","content":[{"data":{"content":"The producer-consumer pattern is a classic concurrency design pattern that describes the interaction between two types of concurrent entities through a shared buffer or queue.\n\n**Formal Definition:**\n\nThe producer-consumer pattern involves:\n- **Producers**: One or more threads/processes that generate data items and place them into a shared buffer\n- **Consumers**: One or more threads/processes that remove data items from the shared buffer and process them\n- **Bounded Buffer**: A finite-capacity data structure that decouples producers from consumers, allowing asynchronous operation\n\nThe pattern addresses a fundamental coordination problem: producers and consumers operate at different rates, have different processing times, and may be temporarily unavailable. The buffer absorbs these variations, enabling the system to function smoothly without tight coupling."},"type":"text"},{"data":{"rows":[["Producer(s)","Generate data items, insert into buffer","Must wait if buffer is full (back-pressure)"],["Consumer(s)","Remove data items, process them","Must wait if buffer is empty (starvation)"],["Bounded Buffer","Store items, enforce capacity limits","Must ensure thread-safe access (mutual exclusion)"],["Synchronization","Coordinate access, signal state changes","Must prevent races, deadlocks, and lost signals"]],"caption":"Core Components of the Producer-Consumer Pattern","headers":["Component","Responsibility","Synchronization Concern"]},"type":"table"},{"data":{"content":"**Why 'Bounded'?**\n\nThe buffer is typically bounded (finite capacity) for several critical reasons:\n\n1. **Memory Management**: Unbounded buffers can grow indefinitely, leading to memory exhaustion if producers outpace consumers\n2. **Back-Pressure Mechanism**: A bounded buffer naturally applies back-pressure—when full, producers must wait, preventing runaway production\n3. **Latency Control**: Bounded buffers limit the maximum time an item spends waiting, providing predictable latency bounds\n4. **Resource Allocation**: Finite buffers enable static memory allocation, avoiding dynamic allocation overhead in performance-critical paths\n\nThe choice of buffer size is a crucial design decision that affects throughput, latency, and memory usage."},"type":"text"},{"data":{"icon":"BookOpen","title":"Historical Context","content":"The producer-consumer problem was first formalized by Edsger Dijkstra in 1965 as a demonstration of his semaphore concept. It has since become a canonical example for teaching synchronization and remains directly applicable to modern systems—from operating system I/O buffers to distributed message queues like Kafka and RabbitMQ.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"synchronization-challenge","title":"The Synchronization Challenge","content":[{"data":{"content":"The producer-consumer pattern introduces three distinct synchronization requirements that must be simultaneously satisfied. Failure to address any one of these leads to correctness bugs, crashes, or undefined behavior.\n\n**The Three Synchronization Requirements:**"},"type":"text"},{"data":{"items":["**Mutual Exclusion**: Only one thread can modify the buffer at a time. Concurrent modifications corrupt the data structure—imagine two producers simultaneously trying to insert at the same index, or a producer and consumer accessing a partially-written item.","**Buffer-Full Condition**: Producers must block when the buffer is full. Without this, producers either overwrite existing data (data loss) or write beyond buffer bounds (memory corruption).","**Buffer-Empty Condition**: Consumers must block when the buffer is empty. Without this, consumers either read stale/garbage data or access uninitialized memory."],"title":{"icon":"AlertCircle","text":"Critical Synchronization Requirements","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The Naive Approach Fails:**\n\nConsider a naive implementation using only a mutex for mutual exclusion:"},"type":"text"},{"data":{"code":"// BROKEN IMPLEMENTATION - DO NOT USE\n#define BUFFER_SIZE 10\nint buffer[BUFFER_SIZE];\nint count = 0; // Number of items in buffer\nint in = 0; // Next insert position\nint out = 0; // Next remove position\npthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;\n\nvoid producer(int item) {\n pthread_mutex_lock(&mutex);\n \n // PROBLEM: What if buffer is full?\n // This busy-waits while holding the lock!\n while (count == BUFFER_SIZE) {\n // Spin... but we're holding the mutex!\n // Consumer can NEVER acquire the lock to consume!\n // DEADLOCK!\n }\n \n buffer[in] = item;\n in = (in + 1) % BUFFER_SIZE;\n count++;\n \n pthread_mutex_unlock(&mutex);\n}\n\nvoid consumer(int *item) {\n pthread_mutex_lock(&mutex);\n \n // Same problem if buffer is empty\n while (count == 0) {\n // Spin while holding lock - Consumer starves\n }\n \n *item = buffer[out];\n out = (out + 1) % BUFFER_SIZE;\n count--;\n \n pthread_mutex_unlock(&mutex);\n}","fileName":"naive_producer_consumer.c","showLineNumbers":true},"type":"code"},{"data":{"content":"The naive approach demonstrates a critical insight: **we cannot use a single lock for both mutual exclusion and condition waiting**. If a thread holds a lock while waiting for a condition, no other thread can acquire the lock to change that condition—resulting in deadlock.\n\n**The Core Insight:**\n\nWe need mechanisms that:\n1. Allow threads to **wait for conditions** without holding locks\n2. Allow threads to **signal condition changes** to waiting threads\n3. Ensure **atomic check-and-wait** to prevent lost signals\n\nThis is precisely what condition variables, semaphores, and monitors provide—primitives designed for coordination, not just exclusion."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Lost Wakeup Problem","content":"A subtle bug occurs when a thread checks a condition, finds it false, and prepares to wait—but before it actually waits, another thread changes the condition and signals. The first thread then waits for a signal that already occurred. This 'lost wakeup' can cause indefinite blocking. Proper synchronization primitives atomically combine the condition check and wait operation to prevent this.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"semaphore-implementation","title":"Semaphore-Based Implementation","content":[{"data":{"content":"Dijkstra's original solution to the producer-consumer problem used semaphores—counting synchronization primitives that elegantly encode the buffer state. This implementation remains instructive for understanding the pattern's mechanics.\n\n**Semaphore Strategy:**\n\nWe use three semaphores:\n- **`mutex`** (binary semaphore, initialized to 1): Ensures mutual exclusion for buffer access\n- **`empty`** (counting semaphore, initialized to BUFFER_SIZE): Counts empty slots; producers wait on this\n- **`full`** (counting semaphore, initialized to 0): Counts filled slots; consumers wait on this\n\nThe counting semaphores encode buffer capacity directly—their values always reflect the number of available slots (empty) and items (full)."},"type":"text"},{"data":{"code":"$62","fileName":"semaphore_producer_consumer.c","showLineNumbers":true},"type":"code"},{"data":{"content":"$63"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Critical: Semaphore Ordering Matters","content":"The order of sem_wait operations is CRITICAL. If we swap the order and acquire mutex before checking empty/full, we recreate the deadlock from the naive solution. The producer would hold mutex while waiting for empty slots, preventing consumers from acquiring mutex to create empty slots. Always wait on condition semaphores BEFORE acquiring the mutex.","variant":"warning"},"type":"callout"},{"data":{"code":"// WRONG - CAUSES DEADLOCK\nvoid producer_WRONG(int item) {\n sem_wait(&mutex); // Acquire lock first\n sem_wait(&empty); // Now wait for empty slot while holding lock\n // If buffer is full, we block here holding mutex\n // Consumer can never acquire mutex to consume!\n // DEADLOCK!\n \n buffer[in] = item;\n in = (in + 1) % BUFFER_SIZE;\n \n sem_post(&mutex);\n sem_post(&full);\n}\n\n// CORRECT - As shown above\nvoid producer_CORRECT(int item) {\n sem_wait(&empty); // Wait for condition WITHOUT holding lock\n sem_wait(&mutex); // THEN acquire lock\n // We only reach here if there's an empty slot\n // Other threads can still access buffer while we wait\n \n buffer[in] = item;\n in = (in + 1) % BUFFER_SIZE;\n \n sem_post(&mutex);\n sem_post(&full);\n}","fileName":"WRONG_ordering.c","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":3},{"id":"condition-variable-implementation","title":"Condition Variable Implementation","content":[{"data":{"content":"Modern POSIX systems typically implement producer-consumer using condition variables rather than semaphores. Condition variables provide more flexibility and integrate naturally with mutexes, making the synchronization logic more explicit.\n\n**Condition Variable Strategy:**\n\nWe use:\n- **One mutex** for mutual exclusion\n- **Two condition variables**: `not_full` (producers wait on this) and `not_empty` (consumers wait on this)\n- **Explicit count variable** to track buffer occupancy (unlike semaphores where the count is implicit)"},"type":"text"},{"data":{"code":"$64","fileName":"condvar_producer_consumer.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**Critical Detail: The `while` Loop for Waiting**\n\nNotice we use `while (count == BUFFER_SIZE)` rather than `if`. This is not optional—it's essential for correctness due to **spurious wakeups** and **signal stealing**:\n\n**Spurious Wakeups:**\nPOSIX permits `pthread_cond_wait` to return even without a corresponding signal (for implementation efficiency). The condition must be re-checked after waking.\n\n**Signal Stealing:**\nWith multiple waiters, a signal might wake thread A, but before A re-acquires the mutex, thread B (which wasn't waiting) acquires it and consumes the item. When A finally runs, the condition is again false.\n\n**The Pattern:**\n```c\npthread_mutex_lock(&mutex);\nwhile (!condition) { // Always use while, never if\n pthread_cond_wait(&cv, &mutex);\n}\n// Condition is guaranteed true here\n// Do work...\npthread_mutex_unlock(&mutex);\n```"},"type":"text"},{"data":{"icon":"Lightbulb","title":"pthread_cond_signal vs pthread_cond_broadcast","content":"signal() wakes ONE waiting thread; broadcast() wakes ALL waiting threads. For producer-consumer with multiple producers/consumers, signal() is usually correct—one new slot can only satisfy one waiter. Use broadcast() when multiple waiters might proceed (e.g., if you add multiple items at once), or when conditions overlap. When in doubt, broadcast() is always safe but may cause unnecessary context switches (thundering herd).","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"circular-buffer-mechanics","title":"Circular Buffer (Ring Buffer) Mechanics","content":[{"data":{"content":"The underlying data structure for the bounded buffer is typically a **circular buffer** (also called a ring buffer). Understanding its mechanics is essential for implementing producer-consumer correctly.\n\n**Circular Buffer Concept:**\n\nA circular buffer treats a fixed-size array as if it were circular—after reaching the end, indices wrap around to the beginning. This eliminates the need for expensive data shifting that would occur in a linear buffer."},"type":"text"},{"data":{"height":"350px","mermaidSyntax":"graph LR\n subgraph \"Circular Buffer (size=8)\"\n A0[\"[0] Item A\"] \n A1[\"[1] Item B\"]\n A2[\"[2] Item C\"]\n A3[\"[3] \"]\n A4[\"[4] \"]\n A5[\"[5] \"]\n A6[\"[6] \"]\n A7[\"[7] \"]\n end\n \n subgraph \"Pointers\"\n OUT[\"out=0 (Consumer reads here)\"]\n IN[\"in=3 (Producer writes here)\"]\n end\n \n OUT --> A0\n IN --> A3"},"type":"mermaid-excalidraw"},{"data":{"code":"$65","fileName":"ring_buffer.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**Key Properties of Circular Buffers:**\n\n1. **O(1) Insert and Remove**: No data movement required—only pointer updates\n2. **Fixed Memory**: Size determined at creation; no dynamic allocation during operation\n3. **Cache-Friendly**: Sequential memory access improves cache utilization\n4. **Power-of-Two Optimization**: If size is 2^n, modulo becomes cheap bitwise AND\n\n**Alternative: Count-Free Implementation:**\n\nSome implementations avoid the `count` variable by using pointer positions alone. This works but wastes one slot (distinguishing full from empty):"},"type":"text"},{"data":{"code":"// Alternative: No count variable, but wastes one slot\n\n#define BUFFER_SIZE 8\nint buffer[BUFFER_SIZE];\nint in = 0;\nint out = 0;\n\n// Buffer is empty when in == out\nint is_empty() {\n return in == out;\n}\n\n// Buffer is full when next position of 'in' equals 'out'\n// This means we can only store BUFFER_SIZE - 1 items\nint is_full() {\n return ((in + 1) % BUFFER_SIZE) == out;\n}\n\n// Available items = (in - out) mod BUFFER_SIZE\nint item_count() {\n return (in - out + BUFFER_SIZE) % BUFFER_SIZE;\n}\n\n// Tradeoff: Save one variable, waste one buffer slot\n// Modern systems typically prefer the count variable approach","fileName":"ring_buffer_no_count.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"Zap","title":"Lock-Free Ring Buffers","content":"For single-producer single-consumer (SPSC) scenarios, lock-free ring buffers can be implemented using atomic operations and memory barriers. The producer updates 'in' after writing data; the consumer reads 'in' to know how far it can safely read, then updates 'out'. This achieves very high throughput by avoiding mutex overhead entirely. Linux's kernel implements this in kfifo.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"multi-producer-consumer","title":"Multiple Producers and Multiple Consumers","content":[{"data":{"content":"Real-world systems often have multiple producers and multiple consumers operating concurrently. This introduces additional considerations beyond the basic pattern.\n\n**Terminology:**\n- **SPSC**: Single Producer, Single Consumer\n- **MPSC**: Multiple Producers, Single Consumer\n- **SPMC**: Single Producer, Multiple Consumers\n- **MPMC**: Multiple Producers, Multiple Consumers\n\nEach configuration has different synchronization requirements and optimization opportunities."},"type":"text"},{"data":{"rows":[["SPSC","Minimal - can be lock-free with memory barriers","Audio/video pipeline stages"],["MPSC","Producer-side locking only","Logging from multiple threads to single file"],["SPMC","Consumer-side locking only","Single data source to multiple workers"],["MPMC","Full synchronization required","General work queue, thread pool"]],"caption":"Producer-Consumer Configurations","headers":["Configuration","Synchronization Needs","Example Use Case"]},"type":"table"},{"data":{"content":"**MPMC Considerations:**\n\nWith multiple producers and consumers, several additional issues arise:\n\n**1. Fairness:**\n- Are all producers/consumers guaranteed eventual access, or can some be starved?\n- FIFO ordering of waiting threads may be important for fairness\n- Some implementations use separate locks for insert and remove operations\n\n**2. Order Preservation:**\n- Items may not be consumed in the order they were produced\n- If order matters, additional sequencing mechanisms are needed\n\n**3. Batch Operations:**\n- Inserting/removing multiple items atomically improves throughput\n- Requires careful API design to maintain buffer invariants"},"type":"text"},{"data":{"code":"$66","fileName":"mpmc_considerations.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Work Stealing for Load Balancing","content":"In systems with multiple consumers, 'work stealing' improves load balance. Each consumer has its own queue; when a consumer's queue is empty, it 'steals' work from another consumer's queue. This is used in Go's goroutine scheduler, Java's ForkJoinPool, and Intel TBB. It combines local access (fast) with global balancing (fair).","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"real-world-applications","title":"Real-World Applications","content":[{"data":{"content":"The producer-consumer pattern is ubiquitous in systems programming. Understanding where and how it appears helps you recognize the pattern and apply appropriate solutions."},"type":"text"},{"data":{"items":["**I/O Buffers**: Keyboard input buffer—hardware interrupts (producer) add keystrokes; user programs (consumer) read them. The buffer decouples interrupt speed from program processing.","**Print Spooler**: Applications (producers) submit print jobs to a queue; the print daemon (consumer) processes them in order. Enables multiple apps to 'print' without waiting for hardware.","**Pipe Implementation**: The `|` operator in shells connects processes via bounded buffers. `ls | grep txt` has `ls` producing output and `grep` consuming it.","**Terminal I/O**: Input/output buffers for terminal devices use producer-consumer to handle asynchronous character I/O at different speeds."],"title":{"icon":"Target","text":"Producer-Consumer in Operating Systems","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"items":["**Thread Pools**: Work items (produced by request handlers) queued for worker threads (consumers). Every web server uses this pattern.","**Message Queues**: Kafka, RabbitMQ, SQS—distributed producer-consumer with persistence, multiple consumers, and replay capabilities.","**Video Streaming**: Decode thread produces frames; render thread consumes them. Buffer absorbs variation in decode time.","**Logging Systems**: Application threads produce log entries; dedicated logging thread consumes and writes to disk. Decouples application from I/O latency.","**Event-Driven Systems**: GUI event loop: user actions produce events; event handlers consume them from the queue."],"title":{"icon":"Code2","text":"Producer-Consumer in Applications","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"code":"# Python's queue module provides producer-consumer infrastructure\nimport queue\nimport threading\n\n# Bounded queue - thread-safe producer-consumer\nwork_queue = queue.Queue(maxsize=100) # Bounded buffer\n\ndef producer():\n for i in range(1000):\n work_queue.put(f\"work_item_{i}\") # Blocks if queue full\n work_queue.put(None) # Sentinel to signal completion\n\ndef consumer():\n while True:\n item = work_queue.get() # Blocks if queue empty\n if item is None:\n break\n process(item)\n work_queue.task_done() # Mark item as processed\n\n# Java's BlockingQueue provides similar functionality\n# Go's channels are producer-consumer primitives\n# Rust's std::sync::mpsc provides MPSC channels","fileName":"examples_in_practice.py","showLineNumbers":true},"type":"code"},{"data":{"icon":"Info","title":"Distributed Producer-Consumer","content":"Modern distributed systems extend producer-consumer across networks. Apache Kafka is essentially a distributed, persistent, replicated producer-consumer pattern with guaranteed ordering and exactly-once delivery semantics. Understanding the local pattern makes the distributed version intuitive.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: The Producer-Consumer Pattern","content":[{"data":{"content":"The producer-consumer pattern is a foundational concurrency pattern that you'll encounter throughout your career. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Three Synchronization Requirements**: Mutual exclusion for buffer access, producer blocking on full buffer, consumer blocking on empty buffer. All three must be addressed.","**Semaphore Solution**: Use counting semaphores (empty, full) for condition waiting, binary semaphore (mutex) for exclusion. Order matters—wait on condition BEFORE acquiring mutex.","**Condition Variable Solution**: Use explicit count with while-loop waiting. while() handles spurious wakeups; signal() vs broadcast() affects performance.","**Circular Buffers**: O(1) operations, fixed memory, power-of-two optimization. Fundamental data structure for bounded buffers.","**Configuration Matters**: SPSC can be lock-free; MPMC needs full synchronization. Choose implementation based on actual usage pattern.","**Ubiquitous Pattern**: I/O buffers, thread pools, message queues, logging systems—producer-consumer is everywhere in systems programming."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nHaving mastered the producer-consumer pattern, we'll next explore the **reader-writer pattern**—another fundamental coordination problem where multiple readers can access shared data concurrently, but writers require exclusive access. This pattern appears in databases, caches, and any system with read-heavy workloads."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a deep understanding of the producer-consumer pattern—from theoretical foundations through practical implementation to real-world applications. This pattern will appear repeatedly throughout your work with concurrent systems. Next, we'll examine the reader-writer pattern for coordinating shared data access.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_d5f5c156fcbf489314a9aaa597ef273d","title":"Reader-Writer Pattern","order":1,"content":null,"isLocked":true},{"id":"seed_0f20b13c5e20be2665aac7b12e3dc1f5","title":"Pipeline Pattern","order":2,"content":null,"isLocked":true},{"id":"seed_2cc8d9e6b14648998d5cbef798c4c84d","title":"Map-Reduce Pattern","order":3,"content":null,"isLocked":true},{"id":"seed_45a4ca84cf970ea5a575b92d94624055","title":"Actor Model","order":4,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792309656268,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"common-concurrency-patterns"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"common-concurrency-patterns\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309656306,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309656267,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_7309f1f0928cf7a5720ccde483bb68f4"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_7309f1f0928cf7a5720ccde483bb68f4\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309656306,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309656267,"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_d5f5c156fcbf489314a9aaa597ef273d"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_d5f5c156fcbf489314a9aaa597ef273d\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309656306,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309656267,"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_d5f5c156fcbf489314a9aaa597ef273d"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_d5f5c156fcbf489314a9aaa597ef273d\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309656306,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792309656267,"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_d5f5c156fcbf489314a9aaa597ef273d"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_d5f5c156fcbf489314a9aaa597ef273d\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309656306,"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_d5f5c156fcbf489314a9aaa597ef273d","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_d5f5c156fcbf489314a9aaa597ef273d\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@67"}]},"children":"$L68"}]