Question 3 of 5 · staff level

Explain starvation and priority inversion. How did priority inversion nearly kill the Mars Pathfinder mission?

🎤 Say this first

Starvation: a runnable task waits unboundedly because the policy always prefers others — fix with aging (waiting raises effective priority). Priority inversion is subtler: a HIGH-priority task blocks on a lock held by a LOW-priority task, and a MEDIUM-priority task (which needs no lock at all) preempts LOW — so MEDIUM effectively outranks HIGH indefinitely. Pathfinder (1997): the high-priority bus task blocked on a mutex held by a low-priority meteorological task while medium-priority work starved it → watchdog resets on Mars. Fix then and now: priority inheritance — the lock holder temporarily inherits the highest waiting priority.

The full picture

The inversion triangle: H waits on L's lock; M preempts L; therefore M > H in practice. It needs three parties — with only H and L, L would run and release.
Fixes: priority inheritance (holder boosted to max waiter priority — pthreads PTHREAD_PRIO_INHERIT, RT-mutexes in Linux), priority ceiling (lock has a fixed high ceiling), or design-level: don't share locks across priority classes at all.
Pathfinder details worth citing: VxWorks RTOS, the mutex had a priority-inheritance flag defaulted off, JPL debugged from Earth via a replica and toggled it live — the canonical 'observability + remote config saves the mission' story.
Where you meet it off Mars: GC threads vs application threads, a low-priority batch job holding a DB row lock a latency-critical request needs (DBs don't do priority inheritance — your 'priority' design must avoid cross-tier lock sharing), and cgroup-throttled containers holding futexes.

🔄 Likely follow-up questions

Why doesn't priority inheritance help with condition variables or semaphores in general?
How does Linux's RT-mutex implement inheritance chains?
Give a distributed-systems analog of priority inversion you've seen.