Subject: Re: [linux-audio-dev] priority inversion & inheritance
From: Paul Davis (pbd_AT_op.net)
Date: Fri Jul 12 2002 - 00:56:51 EEST
>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.
the hard case is a common one: thread A ("audio thread";
SCHED_FIFO/whatever) and thread B ("gui thread";
SCHED_OTHER/whatever).
when thread A blocks on a mutex owned by B, it leaves the realm of
SCHED_FIFO entirely, and becomes dependent on SCHED_OTHER scheduling.
this is a common form of communication between a GUI (or network
intermediary) and the real-time component, and so it is really rather
easy for it to occur. this is where priority inversion appears to be
appealing, because thread B gets promoted to SCHED_FIFO and runs like
that till it releases the lock.
the problem is that unless you know that thread B's use of the mutex
is always "well behaved" (basically, very short ownership times), this
doesn't ensure anything. the programmer therefore still has to be
really careful in sharing the mutex between SCHED_FIFO and
SCHED_OTHER threads, probably almost as careful as if she avoids the
mutex entirely and uses lock-free methods.
--p
This archive was generated by hypermail 2b28 : Fri Jul 12 2002 - 01:00:37 EEST