Trace priority through a lock dependency

Use three tasks on one CPU, with priorities ordered high, medium, and low. The low task first acquires a mutex. The high task later requests the same mutex and blocks because mutual exclusion prevents simultaneous ownership. The medium task then becomes runnable. Without an appropriate inheritance protocol, it can run ahead of the low owner even though the high task depends on that owner's progress. The high task is not merely waiting for the remaining protected computation; it is also exposed to interference from the medium task. Increasing the high task's base priority changes neither the lock ownership nor that indirect dependency.

Some blocking is intrinsic to sharing. Even with perfect inheritance, the owner generally must finish the relevant protected work before the waiting task can enter safely. The engineering question is whether unrelated lower-priority activity can stretch that wait beyond a justified bound. Draw a dependency edge from each blocked task to the current owner of the lock it needs. This graph makes a hidden relationship visible: delaying an owner can delay every task upstream of it. A trace that shows the high task sleeping and the medium task running is therefore incomplete until you know which task owns the contested resource.

With an inheritance-capable mutex, a blocked high-priority waiter can cause its low-priority owner to execute at an effective priority reflecting that waiter. The medium task can no longer preempt the owner solely because its base priority exceeds the owner's original priority. Once the ownership dependency changes, the effective priority must be recomputed from remaining waiters and owned locks; blindly resetting to the original value would be wrong when another high-priority waiter still depends on the same task. Base priority expresses normal scheduling intent, while effective priority incorporates temporary dependencies. Treating the boost as a permanent promotion misunderstands both fairness and correctness.

Dependencies can extend beyond one mutex. If the boosted owner is itself blocked on another inheritance-capable mutex, progress may require propagation to the next owner. A complete analysis must inspect the chain, not just the first lock named by the delayed task. Linux rt-mutex documentation explains this mechanism, and userspace mutex protocols can request priority inheritance where supported. A regular mutex should not be assumed to provide the protocol automatically. Check initialization, return values, platform support, and the deployed implementation. For real-time design, verify the entire dependency path; one unexamined lock or resource wait can invalidate a reassuring diagram.

Consider a deliberately narrow bound: one CPU, one relevant owner, no nested locks, bounded remaining protected CPU execution, an operational inheritance protocol, and no higher-priority interference or blocking inside the critical section. The wait then consists of the owner's remaining work plus measured protocol and dispatch overhead. Relaxing these assumptions changes the calculation. An owner sleeping on storage may need the storage device rather than additional CPU priority. A nonpreemptible kernel interval or another higher-priority task may still delay dispatch. A cycle in which two owners wait for each other's locks is deadlock; donating priority cannot make either release a lock it will never reach code to release.

Reduce avoidable critical-section work, define a consistent lock acquisition order, and avoid performing unbounded external operations while holding locks on timing-sensitive paths. Then instrument actual contention, ownership transitions, and dispatch events instead of inferring safety from the word inheritance. The queue lab illustrates only a related capacity lesson: available service must be sufficient for arriving work. Its backlog has no mutex owner, priority values, inheritance chain, or deadlock state, so it cannot test the protocol. To inspect aggregate pressure, compare separate fixed-rate runs at arrival 4, service 3 and arrival 2, service 3. Before each run, press Reset, re-set both rates, predict the direction from four work units, then press Play or Step; the second run does not inherit the first run's backlog. Keep this capacity comparison separate from the ownership mechanism, and use the numerical exercise here to assemble a narrowly specified blocking bound.