Suppose Pi has higher priority than P_{i-1}.
Even if there is a priority queue, once P0 has the lock, P1 must wait
until P0 unlocks. So, you promote the priority of P0 to equal that of P1
and then P2 runs and reaches the lock. Then P0 is promoted again etc.
Or worse, as in my example, P0 has lock L0 and P1 locks L1 and then
hangs on L0, and P3 locks L3 and then L2 .... so that priority promotions
are cascaded
> When P0 leaves for whatever reason it simply gets it's original
> priority back. What do you want to recalculate here in P1 or P2?
This is one of the choices of wrong answers. Suppose P0 has lock L0
and lock L1 and gets promoted on both of them. If unlocking either
returns P0 to its original priority then you still have inversion, if
you need to look at all held locks/resources then you have a rather
significant overhead.
> You don't have that problem if the queue gets reorderd by priority,
> since then P0 wouldn't get a higher priority at all. The only situation
> where P0 needs to get higher priority is when it actually got the lock
> and tries to continue execution. In this case it needs to inherit the
> priority of the first process in the queue until it reaches the unlock.
See above.
> >And then consider how a kernel that depends on the operation of many daemon
> >processes will continue to operate when users can introduce arbitrarily many
> >"RT" processes that can block daemons indefinitely.
>
> Users can only lower priority.
Not in the soft RT scheme.
> The easiest solution seems to be to give all processes at least a small
> minimum timeslice and to not inherit anything. Then things basically
> work like they already work. Just that nice processes will be much
> nicer than currently.
That is a much better solution. It's compatible with the general
unix design and can be implemented very efficiently.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/