13 Jul
2004
13 Jul
'04
7:48 p.m.
From: "Paul Davis" <paul(a)linuxaudiosystems.com>
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.
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. 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