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

["Martijn Sipkema" <msipkema@sipkema-digital.com>]

From: "Paul Davis" <paul@linuxaudiosystems.com>
> >Thus, the fact that Linux does not support protocols to prevent priority
> >inversion (please correct me if I am wrong) kind of suggests that supporting
> >realtime applications is not considered very important.
> 
> we went through this (you and i in particular) right here on LAD a
> year or so ago. while i might agree with you about the priority given
> to RT-ish apps, my recollection of the end of that discussion is that
> priority inheritance is neither necessary nor sufficient to allow
> adequate RT performance.

I don't recall that that is what was concluded.

Priority inheritance or some other protocol for priority inversion _is_
needed for realtime applications that have threads with different priorities
accessing common data. One could increase the priority of the low priority
thread before taking the mutex and release it afterwards (as in priority
ceiling), but I doubt that's optimal.

> priority inversion generally can be factored
> out through application redesign, and the protocols i've seen to
> address it are not useful for RT purposes - they just help deadlock.

For cases where some form of message passing does not work you
will need shared data with a mutex to serialize access and you _will_
need to prevent priority inversion. Mutexes are part of the POSIX
realtime threading extensions; you can use a semaphore when
priority inversion is not an issue.

IMHO it is the lack of a mutex implementation with priority ceiling
or inheritance and the stories about relying on either being a design
problem that have caused the Linux audio community to not use
mutexes and declare them non-RT safe while in fact they are
required according to POSIX to synchronize memory between
cooperating threads.

--ms