On 04-07-08 02:05, Peter Teoh wrote:
I see....eh...or I don't see......the original problem was that the
highest prio cannot acquire the lock, even though it has the highest
prio.
No. That is or was not the problem. This I believe is the fundamental
misunderstanding left.
Please note how I said "All fine and well up to this point" when the
high-prioriy process went to sleep since the low-priority process was
holding the lock.
Such is the nature of the mutex/futex locking model. Holding a lock
_overrides_ any scheduler priority, makes it irrelevant, and this is how
things are supposed to work. If we just have the high-priority and the
low-priority process, we have no priority inversion issues, no problem.
It's mixing in that third medium priority process that's causing the
problem. It itself does _not_ grab the lock, yet it still keeps the
high-priority process from running since it keeps the low priority
process from running to the point where it releases the lock. So we have
here a situation where a process that isn't holding a lock the higher
priority process is waiting for is still keeping the higher priority
process from running -- effectively, the medium priority process has a
higher priority then the high-priority process since it has a higher
priority then the low-priority process.
That's the problem called "priority inversion".
I suppose once that's clear, the priority inheritance solution will also
be: just assign the priority of the high-prio process to the low-prio
process when the high prio-process blocks on the lock so that the
medium-prio process won't keep the (originally) low-prio process from
running (tweak solution to "assign the maximum of current prio of lock
holder and prio of process about to be blocked to lock holder" in the
general case of more than just 3 possible processes ofcourse).
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
