> 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.
This is correct. Even if the thread C is running in another application and doesn\'t share any resources with A and B it will still be able to preempt A (whilst holding the mutex) and thus block C indefinately. This is called priority inversion. In any realistic environment there will always be a thread C. This is why I said the threads should be the same priority. --martijn Powered by ASHosting
