Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 53

Semaphore-Protected Producer-Consumer Problem

Recommended resources

Hello! Welcome back to our RTOS module.

In our last lesson, we established the fundamental differences between spinlocks, mutexes, and semaphores. We concluded that semaphores, with their signaling capability and lack of ownership, are the ideal tool for many task synchronization problems. We specifically introduced the producer-consumer problem as a classic scenario where semaphores shine.

Today, we'll move from theory to a full-fledged implementation. Your learning goal is to solve the classic producer-consumer problem using a shared buffer protected by semaphores. This is a cornerstone of concurrent programming and a very frequent topic in technical interviews for senior embedded roles, as it thoroughly tests your understanding of synchronization, race conditions, and resource management.

1. Understanding the Producer-Consumer Problem

Let's begin by formally defining the problem. We have one or more "producer" tasks that generate data and place it into a shared, fixed-size buffer. We also have one or more "consumer" tasks that retrieve data from that same buffer and process it.

This simple setup presents three critical challenges that any robust solution must address.

Producer - Consumer Problem in Multi-Threading

This video from CodeVault provides an excellent overview of the problem and its inherent challenges. It clearly explains the roles of the producer, consumer, and the shared buffer.

Watch the first 4 minutes and 32 seconds of the video. As you watch, focus on understanding these three core problems: Shared Memory Access: How do we prevent producers and consumers from corrupting the buffer by accessing it at the same time? Buffer Full: What should a producer do when the buffer is full? It cannot simply overwrite existing data. Buffer Empty: What should a consumer do when the buffer is empty? It cannot consume non-existent data.

2. A Naive Approach and Its Failures

A common first attempt at solving this might involve using a single mutex to protect the buffer and simple if conditions to check the buffer's state. However, this leads to significant inefficiencies.

Producer - Consumer Problem in Multi-Threading

Let's continue with the same video to see why a naive implementation using simple if checks is not a viable solution.

Watch from 11:39 to 14:40. Pay attention to the two major flaws that emerge: Wasted CPU Cycles (Busy-Waiting): The consumer continuously loops, acquiring the lock, checking if the buffer has data, finding it empty, and releasing the lock. This burns CPU cycles for no productive work. Dropped Data: The producer, finding the buffer full, simply skips producing the item. In a real system, this could mean losing a critical sensor reading or a network packet.

This demonstrates that we need a mechanism that allows tasks to block efficiently—to go to sleep until there is work to do—rather than spinning in a loop. This is precisely what semaphores are for.

3. The Semaphore-Based Solution

The elegant solution to the producer-consumer problem uses a combination of two counting semaphores and one mutex.

Producer-Consumer Problem with Bounded Buffer and Semaphores
This diagram visually represents the setup. Producers add items to a circular buffer, and consumers remove them. The process is orchestrated by a mutex and two counting semaphores, `empty` and `full`.

Here are the three primitives and their roles:

  1. filled_slots (Counting Semaphore):

    • Represents the number of items currently in the buffer.
    • Initialized to 0.
    • Consumers wait() on this semaphore. If the count is 0 (buffer is empty), the consumer task blocks until a producer post()s to it.

  2. empty_slots (Counting Semaphore):

    • Represents the number of available empty slots in the buffer.
    • Initialized to BUFFER_SIZE.
    • Producers wait() on this semaphore. If the count is 0 (buffer is full), the producer task blocks until a consumer post()s to it.

  3. mutex (Mutex):

    • Provides mutual exclusion for the critical section where the buffer's internal state (the data array and its read/write indices) is being modified.
    • This is crucial to prevent race conditions between producers or between consumers.

The Logic in Pseudocode

The logic flows as follows. Note the order of operations—it is deliberate and important.

Producer-Consumer Problem with Semaphores
This pseudocode clearly shows the classic three-semaphore solution. `empty` and `full` handle the synchronization of buffer capacity, while `mutex` protects the integrity of the buffer access itself.

Producer Task Logic:

  1. sem_wait(&empty_slots): Decrement the empty count. If it was zero, block until a consumer frees up a slot.
  2. mutex_lock(&mutex): Acquire exclusive access to the buffer.
  3. Add item to the buffer and update write index.
  4. mutex_unlock(&mutex): Release exclusive access.
  5. sem_post(&filled_slots): Increment the filled count, potentially waking up a sleeping consumer.

Consumer Task Logic:

  1. sem_wait(&filled_slots): Decrement the filled count. If it was zero, block until a producer adds an item.
  2. mutex_lock(&mutex): Acquire exclusive access to the buffer.
  3. Remove item from the buffer and update read index.
  4. mutex_unlock(&mutex): Release exclusive access.
  5. sem_post(&empty_slots): Increment the empty count, potentially waking up a sleeping producer.

This pattern elegantly solves all three challenges: tasks block efficiently instead of busy-waiting, data is never lost, and access to the shared data structure is safe.

Producer - Consumer Problem in Multi-Threading

The CodeVault video demonstrates this exact semaphore-based solution, showing how it solves the problems of the naive approach.

Watch the video from 04:32 to 11:39 and then from 14:40 to 20:35. The first part sets up the code with just a mutex, revealing the race condition. The second part introduces the two counting semaphores to correctly solve the blocking and signaling problem.

4. Implementation in Practice

Now let's look at how this pattern is implemented in code. We'll examine two versions: one using the POSIX pthreads API common in Linux environments, and one using the FreeRTOS API, which is highly relevant to your automotive background.

POSIX pthreads Example

The pthreads library is standard in Linux and other Unix-like systems. Understanding it is valuable for interviews, as many embedded systems run Linux.

Day 12: Mutex and Semaphores - Code Example

This article provides a clean and complete C implementation of the producer-consumer problem using pthreads, a mutex, and semaphores. Study this code to see the concepts put into practice.

Focus on the code block provided in this section. Trace the logic within the produce_item and consume_item functions. Note the use of: pthread_mutex_init, pthread_mutex_lock, pthread_mutex_unlock sem_init, sem_wait, sem_post How the SharedBuffer struct encapsulates all the necessary components.

FreeRTOS Example

Now, let's translate this to an environment you're likely very familiar with. In FreeRTOS, the concepts are identical, but the API calls have different names.

  • sem_init() becomes xSemaphoreCreateCounting().
  • sem_wait() becomes xSemaphoreTake().
  • sem_post() becomes xSemaphoreGive().

Hands-On FreeRTOS: Producer-Consumer Problem with a Circular Buffer

This article provides an excellent hands-on example of the producer-consumer problem implemented on an STM32 microcontroller using FreeRTOS. This directly maps the POSIX concepts to a real-world embedded framework.

Read 'Use case 02' (section 3-1 and 3-2). Don't worry about the STM32-specific hardware calls (HAL_GPIO_TogglePin). Instead, focus on: The initialization of xSemaphoreEmptySlots and xSemaphoreFilledSlots using xSemaphoreCreateCounting(). The producer task (StartBlink01) taking from xSemaphoreEmptySlots and giving to xSemaphoreFilledSlots. The consumer task (StartBlink02) doing the reverse. Notice that this example omits the mutex for simplicity, but in a multi-producer/multi-consumer scenario, you would still need one to protect the buffer, bufferIndexProducer, and bufferIndexConsumer variables, just as we saw in the POSIX example.

Conclusion

You have now analyzed and implemented one of the most fundamental concurrency patterns in embedded systems. Mastering this is a significant step in your interview preparation.

Key Takeaways:

  • The producer-consumer problem is solved using a combination of synchronization primitives, not just one.
  • Counting semaphores are used for synchronization and resource counting. They allow tasks to block efficiently when the buffer is full or empty.
  • A mutex is used for mutual exclusion. It protects the integrity of the shared data structure (the buffer and its indices) during access, preventing race conditions.
  • The pattern involves two counting semaphores (filled_slots, empty_slots) and one mutex.

Preview of the Next Lesson:

While these synchronization primitives are powerful, their incorrect use can lead to new, complex problems. One of the most dangerous is deadlock, where two or more tasks are blocked forever, each waiting for a resource held by the other. In our next lesson, we will dissect the conditions that cause deadlock and explore strategies to prevent or avoid it.