Thank you Rene, one last scenario: On 7/5/08, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > On 04-07-08 18:28, 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? 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? > 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. > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
