Mutexes for Race Condition Prevention

1. The Problem: Understanding Race Conditions

Before we can fix the problem, we must understand it. A race condition occurs when the behavior of a system depends on the unpredictable sequence or timing of events, like how the RTOS scheduler interleaves tasks. When multiple tasks try to read, modify, and write to a shared resource, the final state of that resource can become incorrect if the operations are not atomic (indivisible).

Let's watch a video that perfectly illustrates this issue. It starts with a simple program where two tasks increment the same global variable, a classic recipe for a race condition.

As you saw, even a seemingly simple operation like shared_variable++ is not atomic at the machine-code level. It involves three steps: read from memory, increment the value in a CPU register, and write back to memory. If a context switch happens between these steps, another task can read the old value, leading to corrupted data.

The segment of code that accesses the shared resource (e.g., the global variable in the video) is known as a critical section. To prevent race conditions, we must ensure that only one task can execute its critical section at any given time. This principle is called mutual exclusion.

2. The Solution: Mutexes for Mutual Exclusion

A Mutex (short for Mutual Exclusion) is a synchronization primitive designed specifically to enforce this rule. It acts as a lock or a token. Before entering a critical section, a task must acquire (or "take") the mutex. Once it has the mutex, it is guaranteed exclusive access to the shared resource. Any other task that tries to take the same mutex will be blocked by the RTOS (without consuming CPU time) until the first task releases (or "gives back") the mutex.

The video you just watched has a great analogy for this.

This take-use-give pattern is the fundamental way we use mutexes to protect shared resources.

3. Using Mutexes in FreeRTOS

Now, let's translate this concept into FreeRTOS code. The API is straightforward and consists of three main functions:

1. Create: xSemaphoreCreateMutex()
   • This function creates a mutex and returns a handle of type SemaphoreHandle_t. You should store this handle in a global variable accessible to all tasks that need to share the resource.
2. Take: xSemaphoreTake(SemaphoreHandle_t xSemaphore, TickType_t xTicksToWait)
   • This attempts to acquire the mutex.
   • xSemaphore: The handle of the mutex you want to take.
   • xTicksToWait: The maximum time the task should block while waiting for the mutex. Using portMAX_DELAY will cause the task to wait indefinitely.
   • It returns pdTRUE if the mutex was successfully taken, and pdFALSE if the timeout expired.
3. Give: xSemaphoreGive(SemaphoreHandle_t xSemaphore)
   • This releases the mutex, making it available for another waiting task.

Let's see how these are used to fix the race condition from the first video.

The basic structure is always:

// Outside the task, typically in app_main()
mutexHandle = xSemaphoreCreateMutex();

// Inside the task
void sharedResourceTask(void *parameters) {
    for (;;) {
        // Attempt to take the mutex
        if (xSemaphoreTake(mutexHandle, portMAX_DELAY) == pdTRUE) {
            // --- CRITICAL SECTION START ---
            // Safely access the shared resource here
            // e.g., Serial.println("This is a protected message");
            // --- CRITICAL SECTION END ---

            // Release the mutex for other tasks
            xSemaphoreGive(mutexHandle);
        }
        vTaskDelay(pdMS_TO_TICKS(10)); // Yield to other tasks
    }
}

4. Mutex vs. Binary Semaphore: Priority Inheritance

At this point, you might be thinking, "This sounds a lot like a binary semaphore, which we learned about two lessons ago. Why not just use one of those?"

This is an excellent question. While a binary semaphore can be used to achieve mutual exclusion, a mutex has a crucial, built-in feature that makes it superior for protecting shared resources: Priority Inheritance.

This feature solves a dangerous problem called Priority Inversion. To understand this, let's dive into an article that explains it clearly.

To summarize this critical concept:

• Priority Inversion: A high-priority task gets stuck waiting for a low-priority task, but a medium-priority task (that doesn't need the resource) keeps preempting the low-priority task, preventing it from releasing the resource. The high-priority task is effectively blocked by a medium-priority one.
• Priority Inheritance: When a high-priority task blocks on a mutex held by a low-priority task, the RTOS temporarily boosts the low-priority task's priority to that of the high-priority task. This ensures the low-priority task runs without interruption from any medium-priority tasks, finishes its critical section quickly, and releases the mutex.

Because of this automatic protection against priority inversion, you should always prefer mutexes over binary semaphores for guarding shared resources. Use semaphores for signaling and synchronization.

5. A Better C++ Approach: RAII and Lock Guards

The xSemaphoreTake() / xSemaphoreGive() pattern is functional, but it has a weakness common in C-style APIs. What happens if your critical section has multiple exit points?

void processData() {
    if (xSemaphoreTake(myMutex, portMAX_DELAY) == pdTRUE) {
        if (!readSensor()) {
            xSemaphoreGive(myMutex); // Don't forget to give it back!
            return; // Exit point 1
        }
        if (!processSensorData()) {
            xSemaphoreGive(myMutex); // And here too!
            return; // Exit point 2
        }
        updateDisplay();
        xSemaphoreGive(myMutex); // And here!
    }
}

Forgetting to call xSemaphoreGive() on any single path results in a deadlock—the mutex is never released, and any other task waiting for it will be blocked forever.

With your background and goal of mastering C++, we can use a powerful C++ idiom to make this much safer and cleaner: RAII (Resource Acquisition Is Initialization).

The idea is simple: we create a small wrapper class. Its constructor takes the mutex, and its destructor gives the mutex back.

Let's implement a simple version of this LockGuard class ourselves.

// A simple RAII Lock Guard for a FreeRTOS Mutex
class LockGuard {
public:
    // Constructor: Takes the mutex
    LockGuard(SemaphoreHandle_t mutex) : _mutex(mutex) {
        xSemaphoreTake(_mutex, portMAX_DELAY);
    }

    // Destructor: Gives the mutex back
    ~LockGuard() {
        xSemaphoreGive(_mutex);
    }

private:
    SemaphoreHandle_t _mutex;
};

Now, look how our previous example is simplified. The C++ compiler guarantees that the destructor (~LockGuard()) is called whenever the lock object goes out of scope, no matter how the function exits.

// BEFORE: Manual locking
void processData_manual() {
    if (xSemaphoreTake(myMutex, portMAX_DELAY) == pdTRUE) {
        // ... critical section with multiple returns ...
        // ... must call xSemaphoreGive() at every exit point ...
    }
}

// AFTER: Using RAII Lock Guard
void processData_RAII() {
    LockGuard lock(myMutex); // Mutex is taken here

    // --- CRITICAL SECTION ---
    if (!readSensor()) {
        return; // Destructor called automatically, mutex released!
    }
    if (!processSensorData()) {
        return; // Destructor called automatically, mutex released!
    }
    updateDisplay();
    
} // Destructor called automatically here too, mutex released!

This RAII pattern is far more robust and is a hallmark of professional C++ embedded development. It eliminates a whole class of bugs related to unreleased resources.

Conclusion

In this lesson, you've tackled one of the most fundamental challenges in multitasking programming: protecting shared resources. By understanding and using mutexes, you can build complex, multi-task applications that operate reliably without data corruption or unpredictable behavior.

Key Takeaways:

• Race conditions occur when multiple tasks access a shared resource without synchronization, leading to unpredictable outcomes.
• Code that accesses a shared resource is called a critical section.
• A mutex provides mutual exclusion, ensuring only one task can be in its critical section at a time using a take/give mechanism.
• Mutexes solve the problem of priority inversion through built-in priority inheritance, making them safer than binary semaphores for resource protection.
• Using the C++ RAII pattern with a "lock guard" class provides a robust, exception-safe way to manage mutexes, automatically releasing the lock when the guard goes out of scope.

In our next lesson, we will explore Task Notifications, a lightweight and highly efficient FreeRTOS feature for sending simple signals or values directly from one task (or an ISR) to another, often with less overhead than queues or semaphores.