Deadlock prevention patterns in FreeRTOS - Step-by-Step Execution

Concept Flow - Deadlock prevention patterns

Start Task Requests

↓

Check Resource Availability

↓

Apply Prevention Pattern?

No→Wait or Block

Yes↓

Grant Resource

↓

Task Executes

↓

Release Resource

↓

End or Next Request

Tasks request resources; system checks availability and applies prevention patterns to avoid deadlocks before granting resources.

Execution Sample

FreeRTOS

void Task1() {
  if (xSemaphoreTake(mutex1, 0) == pdTRUE) {
    if (xSemaphoreTake(mutex2, 0) == pdTRUE) {
      // Critical section
      xSemaphoreGive(mutex2);
    }
    xSemaphoreGive(mutex1);
  }
}

Task1 tries to take two mutexes in order without waiting to prevent deadlock.

Execution Table

Step	Action	Resource Requested	Result	Reason
1	Task1 tries to take mutex1	mutex1	Success	mutex1 is free
2	Task1 tries to take mutex2	mutex2	Success	mutex2 is free
3	Task1 enters critical section	-	-	Both mutexes acquired
4	Task1 releases mutex2	mutex2	Released	End of critical section
5	Task1 releases mutex1	mutex1	Released	End of critical section
6	Task1 ends or requests next resource	-	-	Resources freed
7	If mutex2 was busy at step 2	mutex2	Fail	No wait to prevent deadlock, task retries later

💡 Task releases all resources after use or retries if resource unavailable to prevent deadlock.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 4	After Step 5	Final
mutex1	Free	Taken by Task1	Taken by Task1	Taken by Task1	Free	Free
mutex2	Free	Free	Taken by Task1	Free	Free	Free

Key Moments - 3 Insights

Why does Task1 try to take mutex2 with zero wait time?

To avoid waiting and causing deadlock if mutex2 is held by another task, as shown in execution_table step 7.

What happens if mutex2 is not available when Task1 tries to take it?

Task1 fails to take mutex2 immediately and releases mutex1 to avoid deadlock, as shown in execution_table step 7.

Why must Task1 release mutexes after use?

Releasing mutexes frees resources for other tasks and prevents deadlock, as shown in steps 4 and 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of mutex1 after step 2?

A Taken by Task1

B Free

C Released

D Unknown

💡 Hint

Check the 'Result' column at step 1 and step 2 for mutex1 status.

At which step does Task1 release mutex2?

A Step 5

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the 'Action' column for releasing mutex2.

If Task1 waited indefinitely for mutex2, what risk increases according to the table?

A Faster execution

B Deadlock

C Resource leak

D No risk

💡 Hint

Refer to the 'Reason' column in step 7 about no wait to prevent deadlock.

Concept Snapshot

Deadlock prevention in FreeRTOS:
- Tasks try to take mutexes with zero wait time.
- If resource unavailable, release held mutexes immediately.
- Acquire resources in fixed order.
- Always release mutexes after use.
- Avoid waiting to prevent circular waits.

Full Transcript

In FreeRTOS, deadlock prevention patterns help tasks avoid waiting forever for resources. Tasks try to take mutexes without waiting. If a mutex is busy, the task releases any held mutexes and retries later. This avoids circular waiting and deadlocks. Tasks acquire mutexes in a fixed order and release them after use. The execution table shows Task1 taking mutex1, then mutex2, entering critical section, and releasing both. If mutex2 is busy, Task1 fails immediately and releases mutex1 to prevent deadlock. This pattern ensures system resources are used safely without freezing tasks.

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