What is priority inversion?

Priority inversion occurs when a high-priority task is blocked waiting for a resource held by a low-priority task, and medium-priority tasks preempt the low-priority task — effectively running before the high-priority task. Classic scenario: Task L (low priority): holds Resource R Task M (medium priority): no resource, just runnable Task H (high priority): wants Resource R 1. L acquires Resource R 2. H wakes up, preempts L (higher priority) 3. H tries to acquire R -- blocked! (held by L) 4. M wakes up, preempts L (M > L priority, and L is still runnable) 5. M runs to completion while H is waiting! 6. Eventually M finishes, L resumes, completes, releases R 7. H finally runs Priority order achieved: M ran before H -- INVERTED!. Famous example: Mars Pathfinder (1997) — VxWorks RTOS priority inversion caused system resets. High-priority bus management task blocked waiting for resource held by low-priority sensor task, while medium-priority tasks ran. Fix: re-enabled priority inheritance. Solutions: (1) Priority inheritance: when a high-priority task is blocked waiting for a resource, temporarily boost the lock holder's priority to that of the highest-priority waiter. Ensures the holder completes quickly. When it releases the lock, priority returns to normal. Implemented in most RTOS and Linux PTHREAD_PRIO_INHERIT; (2) Priority ceiling protocol: each resource has a "priority ceiling" = priority of highest-priority task that can use it. Any task that acquires the resource is temporarily raised to the ceiling. Prevents inversion entirely. More predictable but requires knowing all resource users in advance; (3) Disable preemption: hold the lock briefly with preemption disabled — only works for very short critical sections.