the classic priority inversion situation is where a low
priority thread holds a resource, while a high priority process is
blocked waiting for it. since the low-pri thread is rarely scheduled
the high-pri thread suffers as a result, running effectively at the
priority of the holder.
in this case, if we use FIFO, then we will be fair (all processes will
eventually get the lock), but the scheduling goals may not be met (a
higher priority process could wait a long time for a lower priority
process).
this may not be such a problem if we assume that a process taking the
semaphore is obviously in kernel mode and non-preemptible. so it is quite
likely to run through its critical section without blocking and up() the
semaphore, thus minimizing any ill effects of priority inversion due to FIFO.
however, if processes do block often after acquiring a semaphore or need
more than one semaphore, then we still have a problem. I don't know the
source well enough to know which case predominates. but if it is the
former, then I really can't understand why we didn't just wake the
first process off the queue instead of the elaborate thundering herd
mechanism we have.
ganesh
-
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/