Why mutexes protect shared resources in FreeRTOS - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why do mutexes prevent data corruption?

In FreeRTOS, why does using a mutex help prevent data corruption when multiple tasks access the same variable?

A Because a mutex automatically fixes corrupted data after tasks finish.

B Because a mutex speeds up the execution of tasks accessing the variable.

C Because a mutex duplicates the variable for each task to use separately.

D Because a mutex allows only one task to access the variable at a time, preventing simultaneous changes.

💡 Hint

Think about what happens if two friends try to write on the same paper at the same time.

A mutex ensures that only one task can access the shared resource at once. This prevents two tasks from changing the data at the same time, which could cause errors or corruption.

❓ Predict Output

intermediate

Output of code using mutex to protect shared counter

What will be the output of this FreeRTOS code snippet where two tasks increment a shared counter protected by a mutex?

FreeRTOS

int shared_counter = 0;
SemaphoreHandle_t mutex;

void Task1(void *params) {
  for (int i = 0; i < 5; i++) {
    xSemaphoreTake(mutex, portMAX_DELAY);
    shared_counter++;
    xSemaphoreGive(mutex);
  }
  vTaskDelete(NULL);
}

void Task2(void *params) {
  for (int i = 0; i < 5; i++) {
    xSemaphoreTake(mutex, portMAX_DELAY);
    shared_counter++;
    xSemaphoreGive(mutex);
  }
  vTaskDelete(NULL);
}

// After both tasks finish, what is shared_counter?

A Could be any number between 0 and 10

B 10

C 0

D 5

💡 Hint

Each task increments 5 times, but the mutex prevents overlap.

Because the mutex ensures exclusive access, all increments happen without interference. So 5 increments from each task add up to 10.

❓ Predict Output

advanced

What error occurs without mutex protection?

Consider two FreeRTOS tasks incrementing a shared variable without a mutex. What error is most likely to happen?

FreeRTOS

int shared_var = 0;

void TaskA(void *params) {
  for (int i = 0; i < 1000; i++) {
    shared_var++;
  }
  vTaskDelete(NULL);
}

void TaskB(void *params) {
  for (int i = 0; i < 1000; i++) {
    shared_var++;
  }
  vTaskDelete(NULL);
}

// What problem can occur here?

A Race condition causing shared_var to have a value less than 2000

B Memory leak due to missing mutex

C Deadlock where both tasks stop running

D Compile error because mutex is missing

💡 Hint

Think about what happens if two friends try to write the same number on a paper at the same time.

Without a mutex, both tasks can read, increment, and write back the variable simultaneously, causing some increments to be lost. This is called a race condition.

🔧 Debug

advanced

Identify the bug in mutex usage

What is wrong with this FreeRTOS code snippet that uses a mutex to protect a shared resource?

FreeRTOS

SemaphoreHandle_t mutex;
int shared_data = 0;

void Task(void *params) {
  xSemaphoreTake(mutex, 0);
  shared_data++;
  xSemaphoreGive(mutex);
  vTaskDelete(NULL);
}

// Assume mutex was created before tasks start.

A Using 0 as block time in xSemaphoreTake causes immediate failure if mutex is not available

B Mutex was not created before use

C shared_data should be volatile to be protected

D xSemaphoreGive should be called before xSemaphoreTake

💡 Hint

Check the meaning of the block time parameter in xSemaphoreTake.

Using 0 as block time means the task will not wait for the mutex if it is not available, so the take can fail and the shared_data increment happens without protection.

🚀 Application

expert

How to avoid priority inversion with mutexes?

In FreeRTOS, when a low priority task holds a mutex needed by a high priority task, what mechanism helps avoid priority inversion?

A Disabling interrupts while the mutex is held

B Using a binary semaphore instead of a mutex

C Priority inheritance where the low priority task temporarily inherits the high priority

D Increasing the stack size of the low priority task

💡 Hint

Think about how the system can help the low priority task finish faster when a high priority task is waiting.

Priority inheritance temporarily raises the priority of the low priority task holding the mutex to the level of the high priority task waiting for it, preventing priority inversion.

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