Priority inheritance behavior in FreeRTOS - Step-by-Step Execution

Concept Flow - Priority inheritance behavior

Task A (Low Priority) locks Mutex

↓

Task B (High Priority) tries to lock Mutex

↓

Task B blocked, Task A inherits High Priority

↓

Task A runs at High Priority, finishes work

↓

Task A releases Mutex

↓

Task A reverts to Low Priority

↓

Task B acquires Mutex and continues

Shows how a low priority task inherits a higher priority when blocking a higher priority task on a mutex, preventing priority inversion.

Execution Sample

FreeRTOS

TaskA: Lock Mutex
TaskB: Try Lock Mutex (blocked)
TaskA: Priority Inherits High
TaskA: Release Mutex
TaskB: Acquires Mutex

Simulates two tasks where a low priority task holds a mutex and a high priority task waits, causing priority inheritance.

Execution Table

Step	Task	Action	Priority Before	Priority After	Mutex State	Blocked Tasks
1	Task A	Locks Mutex	Low	Low	Locked by Task A	None
2	Task B	Tries to Lock Mutex	High	High	Locked by Task A	Task B blocked
3	System	Priority Inheritance	-	-	Locked by Task A	Task B blocked
4	Task A	Inherits Priority	Low	High	Locked by Task A	Task B blocked
5	Task A	Releases Mutex	High	High	Unlocked	Task B unblocked
6	Task A	Reverts Priority	High	Low	Unlocked	None
7	Task B	Acquires Mutex	High	High	Locked by Task B	None
8	End	No more actions	-	-	Locked by Task B	None

💡 Task B acquires mutex and no tasks are blocked, priority inheritance ends.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 4	After Step 5	After Step 6	Final
Task A Priority	Low	Low	Low	High	High	Low	Low
Task B Priority	High	High	High	High	High	High	High
Mutex State	Unlocked	Locked by Task A	Locked by Task A	Locked by Task A	Unlocked	Unlocked	Locked by Task B
Blocked Tasks	None	None	Task B	Task B	None	None	None

Key Moments - 3 Insights

Why does Task A's priority change when Task B is blocked?

Because Task B is higher priority and blocked on the mutex held by Task A, Task A temporarily inherits Task B's priority to prevent priority inversion (see Step 4 in execution_table).

When does Task A revert to its original priority?

Task A reverts to its original low priority after it releases the mutex and Task B is unblocked (see Step 6 in execution_table).

What happens if Task A does not release the mutex?

Task B remains blocked and Task A keeps the inherited high priority, potentially delaying other tasks (implied by Steps 2-5).

Visual Quiz - 3 Questions

Look at the execution_table, what is Task A's priority after Step 4?

A Medium

B Low

C High

D Unchanged

💡 Hint

Check the 'Priority After' column for Task A at Step 4.

At which step does Task B become unblocked?

A Step 3

B Step 5

C Step 6

D Step 7

💡 Hint

Look at the 'Blocked Tasks' column to see when Task B is no longer blocked.

If Task A never releases the mutex, what happens to Task B?

A Task B remains blocked indefinitely

B Task B acquires the mutex anyway

C Task B lowers its priority

D Task B terminates

💡 Hint

Refer to the blocked state of Task B in the execution_table rows before mutex release.

Concept Snapshot

Priority inheritance prevents priority inversion.
When a high priority task blocks on a mutex held by a low priority task,
the low priority task temporarily inherits the higher priority.
This lets the low priority task run sooner and release the mutex.
After releasing, it reverts to its original priority.
This ensures timely resource sharing without blocking high priority tasks.

Full Transcript

Priority inheritance behavior in FreeRTOS helps avoid priority inversion. When a low priority task locks a mutex and a higher priority task tries to lock the same mutex, the higher priority task blocks. To prevent it from waiting too long, the low priority task temporarily inherits the higher priority. This allows the low priority task to run sooner and release the mutex. Once the mutex is released, the low priority task returns to its original priority, and the higher priority task acquires the mutex and continues. This behavior ensures that high priority tasks are not unduly delayed by lower priority tasks holding needed resources.

Practice

1. What is the main purpose of priority inheritance in FreeRTOS?

easy

A. To increase the priority of all tasks equally

B. To prevent low priority tasks from blocking high priority tasks for too long

C. To allow tasks to run in a random order

D. To disable task scheduling temporarily

Solution

1. Step 1: Understand priority inversion problem

   Priority inversion happens when a low priority task holds a resource needed by a high priority task, causing delays.

2. Step 2: Role of priority inheritance

   Priority inheritance temporarily raises the low priority task's priority to the high priority task's level to reduce blocking time.

3. Final Answer:

   To prevent low priority tasks from blocking high priority tasks for too long -> Option B

4. Quick Check:

   Priority inheritance prevents blocking = A [OK]

Hint: Priority inheritance helps high priority tasks run faster [OK]

Common Mistakes:

• Thinking it raises all tasks' priorities
• Confusing it with disabling scheduling
• Believing it randomizes task order

2. Which FreeRTOS synchronization primitive automatically supports priority inheritance?

easy

A. Semaphore (binary)

B. Event group

C. Mutex

D. Queue

Solution

1. Step 1: Identify synchronization primitives

   FreeRTOS offers semaphores, mutexes, queues, and event groups for task synchronization.

2. Step 2: Check which supports priority inheritance

   Mutexes in FreeRTOS implement priority inheritance automatically to avoid priority inversion.

3. Final Answer:

   Mutex -> Option C

4. Quick Check:

   Mutex = priority inheritance support [OK]

Hint: Mutexes handle priority inheritance automatically [OK]

Common Mistakes:

• Choosing binary semaphore which lacks priority inheritance
• Confusing queues or event groups with mutexes
• Assuming all synchronization primitives support priority inheritance

3. Consider three tasks: High, Medium, and Low priority. Low holds a mutex needed by High. Medium is ready to run. What happens when priority inheritance is enabled?

medium

A. Medium task runs before Low and High

B. Low task is blocked until Medium finishes

C. High task runs immediately, ignoring mutex

D. Low task inherits High priority, runs before Medium

Solution

1. Step 1: Analyze priority inversion scenario

   Low priority task holds mutex needed by High priority task, but Medium priority task is ready.

2. Step 2: Effect of priority inheritance

   Low task temporarily inherits High priority, so it runs before Medium to release mutex faster.

3. Final Answer:

   Low task inherits High priority, runs before Medium -> Option D

4. Quick Check:

   Priority inheritance boosts Low task priority = B [OK]

Hint: Low task runs at High priority to unblock High task [OK]

Common Mistakes:

• Assuming Medium runs before Low despite inheritance
• Thinking High runs without mutex
• Believing Low is blocked by Medium

4. You wrote code using a binary semaphore to protect a shared resource, but high priority tasks are blocked too long. What is the likely issue?

medium

A. Binary semaphore does not support priority inheritance

B. Mutex was not created properly

C. High priority tasks are not using the semaphore

D. Task priorities are all equal

Solution

1. Step 1: Identify synchronization primitive used

   Binary semaphore is used to protect shared resource.

2. Step 2: Check priority inheritance support

   Binary semaphores do not support priority inheritance, causing priority inversion issues.

3. Final Answer:

   Binary semaphore does not support priority inheritance -> Option A

4. Quick Check:

   Binary semaphore lacks priority inheritance = A [OK]

Hint: Use mutex, not binary semaphore, for priority inheritance [OK]

Common Mistakes:

• Assuming binary semaphore supports priority inheritance
• Blaming task priorities without checking synchronization
• Ignoring mutex creation correctness

5. In a system with tasks A (priority 3), B (priority 2), and C (priority 1), task C holds a mutex needed by A. Task B is CPU intensive. How does FreeRTOS priority inheritance help avoid priority inversion here?

hard

A. Task C temporarily inherits priority 3, preempting B to release mutex faster

B. Task B inherits priority 3 to run before C and A

C. Task A runs without waiting for mutex

D. Task C is blocked until B finishes

Solution

1. Step 1: Understand task priorities and mutex ownership

   Task C (low priority) holds mutex needed by Task A (high priority), while Task B (medium priority) is CPU intensive.

2. Step 2: Apply priority inheritance behavior

   Task C inherits Task A's high priority (3) temporarily, allowing it to preempt Task B and release the mutex quickly.

3. Final Answer:

   Task C temporarily inherits priority 3, preempting B to release mutex faster -> Option A

4. Quick Check:

   Priority inheritance boosts C to A's priority = C [OK]

Hint: Low priority task inherits high priority to beat medium task [OK]

Common Mistakes:

• Thinking medium priority task inherits high priority
• Assuming high priority task runs without mutex
• Believing low priority task is blocked by medium task