Priority inversion in FreeRTOS occurs when a high-priority task is blocked while waiting for resources (such as a mutex) held by a low-priority task, allowing a medium-priority task to execute in the meantime, which leads to scheduling anomalies where the high-priority task cannot run in a timely manner.
Scenario Example:
Task Priorities: There are three tasks with priorities from high to low: Task_H (high), Task_M (medium), and Task_L (low).
Shared Resource: Both Task_L and Task_H need to access a shared resource (such as a mutex).
Execution Flow:
Task_L acquires the mutex and begins operating on the shared resource.
Task_H becomes ready and attempts to acquire the mutex but finds it occupied, thus it is blocked.
At this point, Task_M (medium priority) starts running and preempts Task_L.
Task_L, being preempted by Task_M, cannot release the mutex in a timely manner, causing Task_H to be blocked for an extended period.
Result: The high-priority task Task_H is indirectly blocked by the low-priority task Task_L, while Task_M (which is unrelated to the shared resource) executes first, violating real-time constraints.
FreeRTOS Solution
1. Priority Inheritance
Mechanism: When a high-priority task is blocked waiting for a mutex, the low-priority task holding that mutex temporarily inherits the priority of the high-priority task.
Effect: The priority of the low-priority task Task_L is elevated to that of Task_H, allowing it to execute quickly and release the mutex, thus avoiding preemption by Task_M.
Trigger Condition: Mutexes created using xSemaphoreCreateMutex() have priority inheritance enabled by default.
Priority inheritance does not completely resolve priority inversion; it merely minimizes the impact in certain situations.