Mutexes for Shared Resource Protection

1. The Problem: Race Conditions and Critical Sections

In a multitasking environment, a "shared resource" can be anything that multiple tasks need to access, such as:

• A global variable used as a counter or status flag.
• A communication peripheral like a UART, SPI, or I2C bus.
• A shared memory buffer for data exchange.

A race condition occurs when the system's behavior depends on the unpredictable sequence or timing of events, like how the RTOS scheduler interleaves the execution of multiple tasks. If two tasks access a shared resource without any coordination, the last one to write "wins," potentially overwriting changes made by the other and corrupting the data.

As the video explained, the issue arises because an operation like shared_variable++ is not atomic. In assembly, it's a three-step process:

1. Read the variable's value from memory into a CPU register.
2. Modify the value in the register.
3. Write the new value from the register back to memory.

If a context switch occurs after one task has read the value but before it has written it back, another task can perform the same operation on the old value, leading to lost updates.

The section of code that accesses the shared resource is called a critical section. To prevent race conditions, we must enforce mutual exclusion, which means ensuring that only one task can execute its critical section at any given time.

Your work with communication stacks like CAN and Ethernet involves managing shared hardware resources. Without mutual exclusion, one task could be in the middle of sending a CAN frame while another task preempts it and tries to reconfigure the CAN controller's bit rate, leading to chaos.

2. The Solution: The Mutex

A Mutex (short for Mutual Exclusion) is a kernel object designed specifically for this purpose. It acts like a key to a shared resource.

• Before entering a critical section, a task must "take" or "acquire" the mutex.
• If the mutex is available, the task takes it and proceeds. The mutex is now considered "locked."
• If another task tries to take the same mutex while it's locked, the RTOS will block that task (move it to the Blocked state) until the mutex becomes available.
• After leaving the critical section, the task must "give" or "release" the mutex, making it available for other tasks.

The key analogy is very effective: imagine a single key for a restroom in a busy coffee shop. Only the person holding the key can enter. Anyone else who wants to use it has to wait for the key to be returned.

3. Implementing Mutexes in FreeRTOS

Let's move from theory to practice. Implementing mutexes in FreeRTOS involves three main API functions.

The core FreeRTOS mutex API consists of:

1. SemaphoreHandle_t xSemaphoreCreateMutex(void): Creates a mutex and returns a handle to it. You must have configUSE_MUTEXES set to 1 in your FreeRTOSConfig.h file.
2. BaseType_t xSemaphoreTake(SemaphoreHandle_t xSemaphore, TickType_t xTicksToWait): Acquires the mutex. If the mutex isn't available, it will wait for up to xTicksToWait ticks. Returning pdTRUE means success.
3. BaseType_t xSemaphoreGive(SemaphoreHandle_t xSemaphore): Releases the mutex.

Now, let's see a complete, practical example.

The example you just read demonstrates several best practices:

• Minimal Critical Section: The tasks copy the shared data to a local variable immediately after taking the mutex, then release the mutex before doing any lengthy processing. This minimizes the time other tasks are kept waiting.
• Use Timeouts: Using a specific timeout (pdMS_TO_TICKS(100)) with xSemaphoreTake is safer than blocking forever (portMAX_DELAY). It allows the system to detect if a mutex is held for too long and handle the error gracefully.
• Initialization: The mutex is created once during system initialization, before the tasks that use it are started.

This video provides a live coding demonstration that reinforces these steps.

4. Mutex vs. Binary Semaphore: A Critical Distinction

This is a frequent point of confusion for developers and a common interview question to gauge your depth of knowledge. A binary semaphore can also be used for mutual exclusion in a simplistic way (it has two states, 0 or 1, like locked/unlocked), but it lacks crucial features that make mutexes the correct and safer choice for resource protection.

Here is a summary of the key differences from that table:

The ownership model is a critical safety feature. It prevents a bug where one task accidentally releases a lock held by another. The most important difference, however, is priority inheritance, which is our next topic.

5. The Danger of Priority Inversion (A Preview)

When using mutexes, you can encounter a dangerous condition called priority inversion. Imagine this scenario:

1. A low-priority task takes a mutex to access a shared I2C bus.
2. A high-priority task preempts it and tries to take the same mutex. It can't, so it blocks.
3. A medium-priority task (that doesn't need the I2C bus) becomes ready. Since it has a higher priority than the low-priority task holding the mutex, it preempts it and runs.

The result? The high-priority task is stuck waiting not for the low-priority task, but for the medium-priority task to finish. The high-priority task's execution is now effectively dictated by a medium-priority task, "inverting" the priority scheme and potentially causing it to miss critical deadlines.

Fortunately, FreeRTOS mutexes have a built-in solution: priority inheritance. When a high-priority task blocks on a mutex held by a low-priority task, the scheduler temporarily boosts the low-priority task's priority to that of the high-priority task. This ensures the low-priority task can finish its critical section quickly and release the mutex, minimizing the high-priority task's blocking time.

6. Interview Preparation: Key Questions

Mastering mutexes is non-negotiable for an embedded role using an RTOS. Expect questions like these:

• Question: "What is a race condition? Can you give an example relevant to an automotive system?"

  • Your Answer: "A race condition occurs when multiple tasks access a shared resource, and the outcome depends on the unpredictable timing of their execution. For example, if one task is updating a global struct with vehicle speed from a CAN message, while another task is reading that same struct to log it, a context switch could happen mid-update. The logging task might read a struct that is partially old and partially new, resulting in corrupted data. To prevent this, the entire read/write operation must be protected by a mutex."

• Question: "What is the difference between a mutex and a binary semaphore in FreeRTOS? Why can't you just use a binary semaphore for everything?"

  • Your Answer: "While they seem similar, their intended purposes are different. A mutex is for protecting shared resources, while a semaphore is for signaling. The three key differences are: 1) Ownership: A mutex must be released by the same task that acquired it, which is a safety mechanism. 2) Priority Inheritance: Mutexes implement priority inheritance to solve priority inversion, a critical feature for real-time systems that semaphores lack. 3) Recursion: Mutexes can be configured to be taken multiple times by the same task, while semaphores cannot. Using a binary semaphore for resource protection is risky because it's vulnerable to priority inversion and accidental release by the wrong context."

• Question: "Describe the code pattern you would use to safely write to a shared peripheral, like an I2C device, from a FreeRTOS task."

  • Your Answer: "First, I'd create a mutex (xI2C_Mutex) during initialization. In the task, before any I2C transaction, I would call xSemaphoreTake(xI2C_Mutex, xTicksToWait), checking the return value. If successful, I'd perform the I2C write. Crucially, I'd ensure xSemaphoreGive(xI2C_Mutex) is called on all possible exit paths from that code block, including error conditions, to prevent the mutex from being locked forever. I would also keep the critical section—the code between take and give—as short as possible to minimize blocking time for other tasks."

xSemaphoreTake(voltageMutex, portMAX_DELAY);
g_SystemState.voltage = read_voltage();
xSemaphoreTake(currentMutex, portMAX_DELAY);
g_SystemState.current = read_current();
xSemaphoreGive(currentMutex);
xSemaphoreGive(voltageMutex);

Conclusion

Today we've tackled one of the most fundamental concepts in concurrent programming. You now understand how multiple tasks can create race conditions and how to use mutexes to ensure safe, synchronized access to shared resources.

Key Takeaways:

• Uncontrolled access to shared resources by concurrent tasks leads to race conditions.
• A mutex is a kernel object that provides mutual exclusion to protect critical sections of code.
• The standard pattern is xSemaphoreCreateMutex, xSemaphoreTake, and xSemaphoreGive.
• Mutexes are superior to binary semaphores for resource protection due to ownership and priority inheritance.
• Using mutexes introduces the risk of priority inversion and deadlock, which require careful design to mitigate.

Next Lesson Preview:
We've had a glimpse of priority inversion and its solution, priority inheritance. In our next lesson, we will dive deep into this topic. You will learn precisely how priority inversion occurs, how FreeRTOS's priority inheritance mechanism works under the hood, and how to configure it to build robust, deterministic real-time systems.