Could you clarify the distinction between priority inheritance and priority inversion in FreeRTOS?
My understanding is that priority inheritance ensures that a high priority task isn’t blocked by a lower priority task holding a shared resource, while priority inversion occurs when a high priority task is delayed by a lower priority task holding the same resource. Is this accurate?
There are are number of posts here in the forum like this one and in the net related to this basic principles.
After reviewing the replies, it appears that my understanding is correct :
Priority Inheritance: This mechanism ensures that a high-priority task will not be blocked by a lower-priority task that holds a shared resource.
Priority Inversion: This occurs when a high-priority task is blocked by a lower-priority task that holds a shared resource.
No. That’s incorrect.
Please read section 8.3.2 and 8.3.3 in this book - https://www.freertos.org/Documentation/Mastering-the-FreeRTOS-Real-Time-Kernel.v1.0.pdf.
You are missing that Priority Inversion is a THREE task situation, where a middle priority task holds off a high priority task that wants a Mutex, because it prevents the lower priority task that currently holds the Mutex from completing and releasing the mutex.
Let me explain my understanding
In a three-task situation, there are three tasks involved: a high-priority task, a middle-priority task, and a low-priority task.
The high-priority task needs to access a shared resource protected by a mutex.
Meanwhile, the low-priority task holds the mutex and is currently executing, but it takes longer than expected to complete its task.
The middle-priority task becomes ready to execute and preempts the low-priority task due to its higher priority.
Since the middle-priority task is now running, the high-priority task cannot execute because it’s waiting for the mutex, which is still held by the low-priority task.
The high-priority task remains blocked until the middle-priority task finishes and releases the mutex.
Finally, the low-priority task completes its execution and releases the mutex, allowing the high-priority task to resume.
Right, but it might not be the case that the low priority task is taking “longer than expected”, but just that it was interrupted in the middle of its operation (perhaps by the middle priority task).
The “inversion” being talked about is that the unrelated middle-priority task has effectively interrupted the high-priority tasks ability to run, by blocked the (related by resource) low-priority task. By giving the low-priority task (temporarily) the same priority as the higher-priority task wanting the resource that is has, it is given the CPU resource at the high priority so it can complete and turn the Mutex over to the high-priority task.