Why mutexes protect shared resources in FreeRTOS

Introduction

Mutexes help make sure only one task uses a shared resource at a time. This stops problems when tasks try to use the same thing together.

When two or more tasks need to write to the same variable or memory area.

When tasks share hardware like sensors or communication ports.

When you want to avoid data getting mixed up or lost during multitasking.

When you want to keep your program stable and predictable.

When tasks need to wait their turn to use a resource safely.

Syntax

FreeRTOS

SemaphoreHandle_t xMutex;
xMutex = xSemaphoreCreateMutex();

// To take the mutex before using resource
if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
    // Access shared resource
    xSemaphoreGive(xMutex); // Release mutex after use
}

You create a mutex with xSemaphoreCreateMutex().

Use xSemaphoreTake() to lock and xSemaphoreGive() to unlock the mutex.

Examples

Task1 locks the mutex before using the shared resource and unlocks it after.

FreeRTOS

SemaphoreHandle_t xMutex = xSemaphoreCreateMutex();

void Task1(void *pvParameters) {
    if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
        // Use shared resource
        xSemaphoreGive(xMutex);
    }
}

Task2 tries to take the mutex but waits only 100 ticks before giving up.

FreeRTOS

void Task2(void *pvParameters) {
    if (xSemaphoreTake(xMutex, 100 / portTICK_PERIOD_MS) == pdTRUE) {
        // Use shared resource
        xSemaphoreGive(xMutex);
    } else {
        // Could not get mutex, handle error or retry
    }
}

Sample Program

This program creates two tasks. One adds 1 to a shared counter, the other subtracts 1. Both use a mutex to avoid changing the counter at the same time. The output shows the counter changing safely.

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include <stdio.h>

SemaphoreHandle_t xMutex;
int sharedCounter = 0;

void vTaskIncrement(void *pvParameters) {
    for (int i = 0; i < 5; i++) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
            sharedCounter++;
            printf("Task Increment: Counter = %d\n", sharedCounter);
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(10 / portTICK_PERIOD_MS);
    }
    vTaskDelete(NULL);
}

void vTaskDecrement(void *pvParameters) {
    for (int i = 0; i < 5; i++) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
            sharedCounter--;
            printf("Task Decrement: Counter = %d\n", sharedCounter);
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(10 / portTICK_PERIOD_MS);
    }
    vTaskDelete(NULL);
}

int main(void) {
    xMutex = xSemaphoreCreateMutex();
    if (xMutex == NULL) {
        printf("Mutex creation failed!\n");
        return 1;
    }

    xTaskCreate(vTaskIncrement, "Increment", 1000, NULL, 1, NULL);
    xTaskCreate(vTaskDecrement, "Decrement", 1000, NULL, 1, NULL);

    vTaskStartScheduler();

    // Should never reach here
    for(;;);
    return 0;
}

Important Notes

Always create the mutex before starting tasks that use it.

Never forget to give back the mutex after using the shared resource.

If a task cannot get the mutex, it can wait or handle the situation gracefully.

Summary

Mutexes let only one task use a shared resource at a time.

This prevents data errors and keeps your program stable.

Use xSemaphoreTake() and xSemaphoreGive() to lock and unlock the mutex.

Practice

1. Why do we use mutexes in FreeRTOS when accessing shared resources?

easy

A. To allow only one task to access the resource at a time

B. To speed up the execution of all tasks simultaneously

C. To permanently lock the resource so no task can use it

D. To create multiple copies of the resource for each task

Solution

1. Step 1: Understand what a shared resource is

   A shared resource is something multiple tasks want to use, like a variable or hardware.

2. Step 2: Understand mutex purpose in FreeRTOS

   Mutexes ensure only one task uses the resource at a time to avoid conflicts or errors.

3. Final Answer:

   To allow only one task to access the resource at a time -> Option A

4. Quick Check:

   Mutex = single task access [OK]

Hint: Mutex means one task at a time [OK]

Common Mistakes:

• Thinking mutex speeds up all tasks
• Believing mutex locks resource forever
• Assuming mutex duplicates resources

2. Which FreeRTOS function is used to lock a mutex before accessing a shared resource?

easy

A. xSemaphoreGive()

B. vTaskDelay()

C. xSemaphoreTake()

D. xQueueSend()

Solution

1. Step 1: Identify the function to lock a mutex

   In FreeRTOS, xSemaphoreTake() is used to take or lock a mutex.

2. Step 2: Confirm other functions' purposes

   xSemaphoreGive() releases the mutex, vTaskDelay() delays a task, and xQueueSend() sends data to a queue.

3. Final Answer:

   xSemaphoreTake() -> Option C

4. Quick Check:

   Lock mutex = xSemaphoreTake() [OK]

Hint: Take locks, Give unlocks mutex [OK]

Common Mistakes:

• Confusing xSemaphoreGive() as lock
• Using vTaskDelay() to lock mutex
• Mixing queue functions with mutex

3. What will happen if two tasks try to access a shared variable without using a mutex in FreeRTOS?

medium

A. Data corruption or unexpected behavior may occur

B. Both tasks access safely without issues

C. The system automatically locks the variable

D. The second task waits automatically until the first finishes

Solution

1. Step 1: Understand shared resource risks without mutex

   Without mutex, tasks can change the variable at the same time, causing data corruption.

2. Step 2: Check FreeRTOS behavior without explicit locking

   FreeRTOS does not automatically lock variables; tasks run concurrently unless synchronized.

3. Final Answer:

   Data corruption or unexpected behavior may occur -> Option A

4. Quick Check:

   No mutex = risk of data corruption [OK]

Hint: No mutex means unsafe shared access [OK]

Common Mistakes:

• Assuming FreeRTOS auto-locks variables
• Thinking tasks wait automatically
• Believing no issues happen without mutex

4. Given this code snippet, what is the error related to mutex usage?

if(xSemaphoreTake(mutex, 0) == pdTRUE) {
  sharedVar++;
}
// Missing xSemaphoreGive(mutex) here

medium

A. The mutex is taken twice without giving

B. The mutex is given before taking

C. The shared variable is not incremented

D. The mutex is never released, causing a deadlock

Solution

1. Step 1: Check mutex take and give usage

   The code takes the mutex but never calls xSemaphoreGive() to release it.

2. Step 2: Understand consequences of not releasing mutex

   Not releasing the mutex causes other tasks to wait forever, leading to deadlock.

3. Final Answer:

   The mutex is never released, causing a deadlock -> Option D

4. Quick Check:

   Missing give = deadlock risk [OK]

Hint: Always give mutex after take [OK]

Common Mistakes:

• Forgetting to release mutex
• Assuming increment fails without mutex
• Confusing order of take/give

5. You have two tasks that both update a shared sensor reading variable. How should you use a mutex to ensure safe updates and avoid blocking tasks too long?

hard

A. Take the mutex once at system start and never release it

B. Take the mutex, update the variable quickly, then give the mutex immediately

C. Update the variable without mutex and rely on task priorities

D. Use two separate mutexes for the same variable

Solution

1. Step 1: Understand mutex best practice for shared data

   Mutex should be held only briefly to protect the critical section (variable update).

2. Step 2: Evaluate options for safe and efficient updates

   Taking and giving mutex immediately around update prevents blocking other tasks too long.

3. Final Answer:

   Take the mutex, update the variable quickly, then give the mutex immediately -> Option B

4. Quick Check:

   Short mutex hold = safe and efficient [OK]

Hint: Lock only during update, then unlock fast [OK]

Common Mistakes:

• Holding mutex too long blocking tasks
• Never releasing mutex causing deadlock
• Ignoring mutex and risking data errors