Deadlock prevention patterns in FreeRTOS - Mini Project: Build & Apply

Deadlock Prevention Patterns in FreeRTOS

📖 Scenario: You are working on a FreeRTOS-based embedded system where multiple tasks share resources. To keep the system running smoothly, you need to prevent deadlocks by using proper resource management patterns.

🎯 Goal: Build a simple FreeRTOS program that demonstrates deadlock prevention by acquiring multiple mutexes in a fixed order.

📋 What You'll Learn

Create two mutex handles named mutex1 and mutex2

Create a task called Task1 that tries to take mutex1 then mutex2

Create a task called Task2 that tries to take mutex1 then mutex2 (same order as Task1)

Use xSemaphoreTake and xSemaphoreGive to manage mutexes

Print messages to show when each mutex is taken and given

Demonstrate deadlock prevention by consistent mutex acquisition order

💡 Why This Matters

🌍 Real World

Embedded systems often have multiple tasks sharing hardware or data resources. Preventing deadlocks ensures the system runs reliably without freezing.

💼 Career

Understanding deadlock prevention is crucial for embedded software engineers working with real-time operating systems like FreeRTOS to build safe and responsive applications.

1

Create mutex handles

Create two mutex handles called mutex1 and mutex2 using xSemaphoreCreateMutex().

FreeRTOS

# Create mutex1 and mutex2 using xSemaphoreCreateMutex()
# Your code here

Hint

Use xSemaphoreCreateMutex() to create each mutex and assign it to mutex1 and mutex2.

2

Create Task1 with fixed mutex order

Create a FreeRTOS task called Task1 that tries to take mutex1 first, then mutex2. Use xSemaphoreTake with portMAX_DELAY to wait indefinitely. After taking both mutexes, give them back in reverse order using xSemaphoreGive. Use printf to print messages when each mutex is taken and given.

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"

SemaphoreHandle_t mutex1;
SemaphoreHandle_t mutex2;

void Task1(void *pvParameters) {
    // Take mutex1
    // Take mutex2
    // Print messages when taken
    // Give mutex2
    // Give mutex1
    // Print messages when given
    // Delete task
}

int main(void) {
    mutex1 = xSemaphoreCreateMutex();
    mutex2 = xSemaphoreCreateMutex();

    // Create Task1

    return 0;
}

Hint

Inside Task1, take mutex1 first, then mutex2. Print messages after each take and give. Finally, delete the task.

3

Create Task2 with same mutex order

Create a FreeRTOS task called Task2 that also takes mutex1 first, then mutex2, following the same pattern as Task1. Use printf to show when mutexes are taken and given. Create Task2 in main() with the same priority as Task1.

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include 

SemaphoreHandle_t mutex1;
SemaphoreHandle_t mutex2;

void Task1(void *pvParameters) {
    xSemaphoreTake(mutex1, portMAX_DELAY);
    printf("Task1 took mutex1\n");
    xSemaphoreTake(mutex2, portMAX_DELAY);
    printf("Task1 took mutex2\n");

    xSemaphoreGive(mutex2);
    printf("Task1 gave mutex2\n");
    xSemaphoreGive(mutex1);
    printf("Task1 gave mutex1\n");

    vTaskDelete(NULL);
}

void Task2(void *pvParameters) {
    // Take mutex1
    // Take mutex2
    // Print messages
    // Give mutex2
    // Give mutex1
    // Print messages
    // Delete task
}

int main(void) {
    mutex1 = xSemaphoreCreateMutex();
    mutex2 = xSemaphoreCreateMutex();

    xTaskCreate(Task1, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

    // Create Task2

    vTaskStartScheduler();
    return 0;
}

Hint

Make sure Task2 takes mutex1 then mutex2 in the same order as Task1. Print messages and delete the task at the end.

4

Run and observe deadlock prevention

Add printf statements in main() before starting the scheduler to print "Starting scheduler". Run the program and observe the output showing that both tasks take and give mutexes without deadlock because they acquire mutexes in the same order.

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include "semphr.h"
#include 

SemaphoreHandle_t mutex1;
SemaphoreHandle_t mutex2;

void Task1(void *pvParameters) {
    xSemaphoreTake(mutex1, portMAX_DELAY);
    printf("Task1 took mutex1\n");
    xSemaphoreTake(mutex2, portMAX_DELAY);
    printf("Task1 took mutex2\n");

    xSemaphoreGive(mutex2);
    printf("Task1 gave mutex2\n");
    xSemaphoreGive(mutex1);
    printf("Task1 gave mutex1\n");

    vTaskDelete(NULL);
}

void Task2(void *pvParameters) {
    xSemaphoreTake(mutex1, portMAX_DELAY);
    printf("Task2 took mutex1\n");
    xSemaphoreTake(mutex2, portMAX_DELAY);
    printf("Task2 took mutex2\n");

    xSemaphoreGive(mutex2);
    printf("Task2 gave mutex2\n");
    xSemaphoreGive(mutex1);
    printf("Task2 gave mutex1\n");

    vTaskDelete(NULL);
}

int main(void) {
    mutex1 = xSemaphoreCreateMutex();
    mutex2 = xSemaphoreCreateMutex();

    xTaskCreate(Task1, "Task1", configMINIMAL_STACK_SIZE, NULL, 1, NULL);
    xTaskCreate(Task2, "Task2", configMINIMAL_STACK_SIZE, NULL, 1, NULL);

    printf("Starting scheduler\n");

    vTaskStartScheduler();
    return 0;
}

Hint

Print "Starting scheduler" before calling vTaskStartScheduler(). Run the program and check that both tasks take and give mutexes without deadlock.

Practice

1.

What is a common method to prevent deadlocks in FreeRTOS when multiple tasks need several mutexes?

Choose the best practice.

easy

A. Avoid using mutexes altogether

B. Allow tasks to take mutexes in any order

C. Use recursive mutexes without order

D. Always take mutexes in a fixed global order

Solution

1. Step 1: Understand deadlock cause in FreeRTOS

   Deadlocks happen when tasks wait forever for mutexes held by each other in a cycle.

2. Step 2: Apply fixed order mutex acquisition

   Taking mutexes always in the same order prevents circular wait, stopping deadlocks.

3. Final Answer:

   Always take mutexes in a fixed global order -> Option D

4. Quick Check:

   Fixed mutex order = deadlock prevention [OK]

Hint: Take mutexes always in the same order to avoid deadlocks [OK]

Common Mistakes:

• Taking mutexes in random order
• Ignoring priority inheritance
• Using recursive mutexes incorrectly

2.

Which of the following is the correct way to create a mutex in FreeRTOS to help prevent deadlocks?

?

easy

A. xSemaphoreCreateMutex();

B. xSemaphoreCreateCounting(1, 1);

C. xQueueCreateMutex();

D. xSemaphoreCreateRecursiveMutex();

Solution

1. Step 1: Identify FreeRTOS mutex creation functions

   FreeRTOS uses xSemaphoreCreateMutex() to create a standard mutex.

2. Step 2: Differentiate from other semaphore types

   Counting semaphores and recursive mutexes serve different purposes; standard mutex is best for deadlock prevention.

3. Final Answer:

   xSemaphoreCreateMutex(); -> Option A

4. Quick Check:

   Standard mutex creation = xSemaphoreCreateMutex() [OK]

Hint: Use xSemaphoreCreateMutex() for standard mutex creation [OK]

Common Mistakes:

• Confusing counting semaphore with mutex
• Using recursive mutex without need
• Trying to create mutex with queue functions

3.

Consider this FreeRTOS code snippet where two tasks try to take two mutexes in different orders:

Task1:
  xSemaphoreTake(mutexA, portMAX_DELAY);
  xSemaphoreTake(mutexB, portMAX_DELAY);

Task2:
  xSemaphoreTake(mutexB, portMAX_DELAY);
  xSemaphoreTake(mutexA, portMAX_DELAY);

What is the likely outcome?

medium

A. One task always fails to take mutex

B. Both tasks run without blocking

C. Deadlock occurs because tasks wait on each other's mutex

D. Tasks release mutexes immediately, no deadlock

Solution

1. Step 1: Analyze mutex acquisition order

   Task1 takes mutexA then mutexB; Task2 takes mutexB then mutexA, creating circular wait.

2. Step 2: Identify deadlock condition

   Each task waits for the other's mutex, causing deadlock with portMAX_DELAY blocking indefinitely.

3. Final Answer:

   Deadlock occurs because tasks wait on each other's mutex -> Option C

4. Quick Check:

   Opposite mutex order + infinite wait = deadlock [OK]

Hint: Opposite mutex order with infinite wait causes deadlock [OK]

Common Mistakes:

• Assuming tasks run without blocking
• Ignoring portMAX_DELAY effect
• Thinking one task fails immediately

4.

Given this FreeRTOS code snippet, identify the problem that can cause deadlock:

void Task1(void *pvParameters) {
  xSemaphoreTake(mutex1, portMAX_DELAY);
  vTaskDelay(10);
  xSemaphoreTake(mutex2, portMAX_DELAY);
  // ...
  xSemaphoreGive(mutex2);
  xSemaphoreGive(mutex1);
}

void Task2(void *pvParameters) {
  xSemaphoreTake(mutex2, portMAX_DELAY);
  vTaskDelay(10);
  xSemaphoreTake(mutex1, portMAX_DELAY);
  // ...
  xSemaphoreGive(mutex1);
  xSemaphoreGive(mutex2);
}

What is the best fix to prevent deadlock?

medium

A. Remove all delays between mutex takes

B. Make both tasks take mutexes in the same order

C. Use recursive mutexes instead

D. Increase delay time to avoid overlap

Solution

1. Step 1: Identify cause of deadlock

   Task1 takes mutex1 then mutex2; Task2 takes mutex2 then mutex1, causing circular wait and deadlock.

2. Step 2: Apply fixed mutex order to both tasks

   Changing Task2 to take mutex1 then mutex2 avoids circular wait and prevents deadlock.

3. Final Answer:

   Make both tasks take mutexes in the same order -> Option B

4. Quick Check:

   Same mutex order = no deadlock [OK]

Hint: Fix mutex order in all tasks to the same sequence [OK]

Common Mistakes:

• Removing delays does not fix deadlock
• Using recursive mutexes won't solve order problem
• Increasing delay time only delays deadlock

5.

You have three tasks that need to access three shared resources protected by mutexes: mutexX, mutexY, and mutexZ. To prevent deadlocks, which strategy is best?

1. Task A needs mutexX and mutexY
2. Task B needs mutexY and mutexZ
3. Task C needs mutexX and mutexZ

Choose the best deadlock prevention pattern.

hard

A. Each task takes mutexes in alphabetical order: mutexX, mutexY, mutexZ

B. Each task takes mutexes in random order to improve speed

C. Use recursive mutexes for all mutexes

D. Tasks take mutexes only when all are free simultaneously

Solution

1. Step 1: Analyze mutex requirements and potential deadlocks

   Tasks share mutexes in overlapping pairs, risking circular wait if order differs.

2. Step 2: Apply fixed global order for mutex acquisition

   Taking mutexes always in alphabetical order (mutexX, mutexY, mutexZ) prevents circular wait and deadlocks.

3. Final Answer:

   Each task takes mutexes in alphabetical order: mutexX, mutexY, mutexZ -> Option A

4. Quick Check:

   Global fixed mutex order = deadlock prevention [OK]

Hint: Use global fixed order for all mutex acquisitions [OK]

Common Mistakes:

• Taking mutexes randomly causes deadlocks
• Recursive mutexes don't fix order issues
• Waiting for all mutexes simultaneously is complex