On 06-07-08 02:27, Peter Teoh wrote:
And for the phenomena of "unbounded priority inversion", I found
this very useful:
http://lkml.org/lkml/2006/5/10/52
Thank you to Rene and Roberto for the discussion.....
Just a final note; note that the above linked document does use a
slightly different definition of priority inversion then I did.
It already calls the high-prio process blocking because the
low-prio process is holding a lock "priority inversion" while I in
fact sort of insist on not doing that -- only call the _medium_
prio process having an effectively higher priority than the
high-prio process "priority inversion".
So what I can deduce is that (another variation):
If there is a low prio + medium prio process running.......and only
these two....no problem. So what if another process with "high prio"
now comes in - that will also creates a problem right?
Not in itself. The unwanted situation is a process with a priority in
between the priority of two other processes that syncronize among
themselves using a mutual exclusion mechanism. That is, the extra bit
you need here is for that high-prio process coming in to start
synchronizing itself with the low-prio proccess, and then yes, same
thing ofcourse.
Or similarly two process - medium + high prio running, and now comes
another low prio process - that will also be a problem, right?
Essentially, the original algorithm (without priority inversion) can
only be used for two level priority processing, but once another
level (in between, higher or lower) comes in, problem comes, correct?
Certainly when there's only two priorities ever, the problem with
priority inversion does not exist (not according to my definition of
"problem" at least, see above and below). But in a situation where the
high and medium-prio process are synschronzing among themselves using a
mutex, another low-priority process running and doing its thing does not
constitute a problem ever. Nor when a a medium and low-prio process are
mutexing and a high-prio process is the third one. You need the "in
between" for the discussed problem to appear.
I do so because if you do it like the linked document you'll have
to describe priority inversion as "generally not a problem and the
expected and designed way of things" and this causes confusion.
Priority inversion is really only ever discussed in the context of
it being a problem, so let's make sure our definition agrees with
that.
But definitions are up for grabs ofcourse and whichever one will do
as long as you remember the problem scenario...
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
