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

[Martijn Sipkema]

From: "Paul Davis" <paul at linuxaudiosystems.com>
> >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.

The time that the high priority thread has to wait is bounded (in a well
designed application) and can be calculated; it equals the execution time
of the critical section in the low priority thread plus time for the context
switches. It is unbounded in the case of priority inversion.

In general all synchronization may block participating threads for some
short period; the need for synchronizing means that there are some things
that threads are not allowed to do simultaneously. (the lock-free ringbuffer
is a special case since the only synchronizing that is done, i.e. read/write
access to an int, is done by the processor. I'm not convinced that this will
work on all architectures) It is not a problem to block in a realtime thread
as long as the blocking is bounded.

--ms


the processor