What is priority inversion in an RTOS, and how would you prevent a low-priority task from blocking a high-priority one on a shared resource?
technical-conceptual · Junior level · software-engineering
What the interviewer is really asking
Tests understanding of a classic RTOS concurrency hazard and the standard mitigation (priority inheritance / using a mutex rather than a binary semaphore for mutual exclusion).
What to say
- Describe the scenario: a high-priority task waits on a resource (a mutex) held by a low-priority task, and a medium-priority task preempts the low one, so the high task is stalled indefinitely.
- Give the standard fix: use a mutex with priority inheritance so the holder is temporarily bumped to the waiter's priority and finishes quickly, instead of a plain binary semaphore for mutual exclusion.
- Mention reducing shared state and keeping critical sections short to shrink the window where inversion can happen.
What to avoid
- Confusing priority inversion with a deadlock or a plain race condition.
- Saying 'just raise the high task's priority more' (that doesn't fix it; the medium task still starves the holder).
- Using a binary semaphore for mutual exclusion and not knowing why a mutex with inheritance is the right primitive.
Example answers
Strong: Priority inversion is when a high-priority task is blocked on a mutex held by a low-priority task, and then a medium-priority task preempts the low one. The high task can't run even though it's the most important, because the resource holder isn't getting CPU. The standard fix is a mutex with priority inheritance: while the low task holds the lock the kernel temporarily raises it to the high task's priority so it finishes and releases quickly. I'd also keep the critical section as short as possible.
Weak: That's when tasks get their priorities mixed up so the wrong one runs. I'd fix it by giving the important task a much higher priority number so the scheduler always picks it first over the others.