On Thu, 11 Jul 2002, Martijn Sipkema wrote: >> CPU. If we have two SCHED_FIFO threads communicating with a mutex >> protected queue, different priorities are not a problem as for priority >> inversion to happen, one of them needs to block on the shared mutex. And >> if the thread is blocked, it then isn\'t in the run queue, and thus cannot >> get the CPU. > Not true as far as I know. FIFO only means that the thread won\'t be preempted > after a certain time in case a thread of the same priority is ready to run. > AFAIK all threads running either SCHED_FIFO or SCHED_RR will always be > preempted by higher priority SCHED_* threads. Please correct me if I am wrong > in this.
Let's say we have threads A (SCHED_FIFO/50) and B (SCHED_FIFO/90). If both threads are runnable, B will always be selected and it will run until (quoting the man page) "... either it is blocked by an I/O request, it is preempted by a higher priority process, or it calls sched_yield". But if B blocks on a mutex currently owned by A, B will then become blocked and A will be selected to run. A can now run until it unlocks the mutex, B becomes unblocked and once the next scheduling decision occurs, B will again be chosen to run. But it's true that if we have more threads the situation gets complex pretty quickly. Let's say we have C (SCHED_FIFO/70) that holds a resource needed by B, and is currently blocked by a long i/o operation. Then all three threads will be stuck for an unbounded time. Do correct me if this seems wrong to you. Btw; great day today on lad - lots of very interesting discussion! ;) -- http://www.eca.cx Audio software for Linux!
