What is priority inversion and how is it solved?

Priority inversion occurs when a high-priority task is indirectly blocked by a low-priority task, and a medium-priority task runs instead of the high-priority task. Here is the classic scenario: Task L (low priority) acquires a mutex. Task H (high priority) becomes ready and tries to acquire the same mutex — it blocks because Task L holds it. Now Task M (medium priority) becomes ready. Since Task L has low priority, Task M preempts it and runs. Task H, the highest-priority task in the system, is now waiting for Task M to finish, even though Task M has lower priority than Task H. This is unbounded priority inversion.

The standard solution is priority inheritance: when Task H blocks on the mutex held by Task L, the RTOS temporarily raises Task L's priority to match Task H's. Now Task M cannot preempt Task L, so Task L finishes its critical section quickly, releases the mutex, drops back to its original priority, and Task H runs immediately. This bounds the inversion to the duration of Task L's critical section.

The Mars Pathfinder incident (1997) is the textbook example of priority inversion in the real world. The spacecraft's VxWorks RTOS had a shared bus mutex between a high-priority bus management task and a low-priority meteorological task. A medium-priority communication task caused unbounded priority inversion, triggering a watchdog reset. The fix was enabling priority inheritance on the mutex. This is a very commonly asked story in embedded interviews.