[linux-audio-dev] Re: desktop and multimedia as an afterthought?

[Paul Davis]

>Hmm, I've just recently learned about the Priority Ceiling Protocol,
>an extension to Priority Inversion Protocol, which explicitly prevents
>deadlocks. And I've learned about both in a RTOS course, so I'm a little
>surprised by your statement about them not being useful for RT purposes :-)

solving priority inversion generally means that a low priority thread
cannot delay the execution of a high priority thread. but in practice,
what it tends to mean is that a low priority, lock-holding thread
temporarily runs with high priority until it releases the lock, and
then high priority thread can continue.

if there are no bounds on the operations the low priority thread
carries out while holding the lock, then having it inherit the higher
priority doesn't really guarantee anything except that everything runs
as fast as possible. there are no deadlocks, but the low priority
thread still executes *all* of its code before releasing the lock.

the real problem with such a design is that lock-based synchronization
was being used between two threads, one of which is subject to RT
constraints and one is not. that is what has to be solved, and this is
an application design issue rather than something that can be solved
using general methods.

--p