Hi,
Korona wrote:
Assume that we have three threads: (1) a bus driver (e.g. for the USB or PS/2 bus), (2) a HID driver (e.g. for the USB HID protocol or for the AT keyboard protocol) and (3) a compositor. For the sake of this argument, the relative priority of the HID driver and compositor does not matter. We certainly want to give the bus driver a lower priority than the HID driver and the compositor: If we do otherwise, input events and redraws will be preempted by notifications from completely unrelated devices (e.g. HDDs on the USB bus). However, once the HID driver waits for data from the bus driver (e.g. completion of a DMA request), we're in a priority inversion situation: Instead of handling control to the bus driver in order to receive input events ASAP, we might switch to some other low-priority process and hence increase input latency.
That's just correctly honouring priorities (that are wrong) without inverting the priorities (allowing a lower priority task like the bus driver to steal CPU time from a higher priority task like the HID driver).
As a general rule; if X depends on Y (e.g. HID driver depends on services provided by the bus driver) then the priority of Y needs to be higher than or equal to the priority of X. In other words, "give the bus driver a
higher priority than both the HID driver and the compositor".
If priority is inherited when a request is made (e.g. when the HID driver asks the bus driver to do something, the priority of the HID driver is inherited by the bus driver) the system would automatically fix priorities (that shouldn't have been wrong and shouldn't have needed fixing).
For priority inversion; I use the "avoid blocking" solution (asynchronous communication, no shared memory, no shared locks), so there's nothing a low priority task can do to cause a higher priority task to block and priority inversion can't happen. Of course even though it's immune to priority inversion; I can still get the priorities wrong (and end up with a medium priority task stealing CPU time from a task that should've been higher priority but is actually lower priority).
Cheers,
Brendan