Messages in this thread | | | From | "Martijn Sipkema" <> | Subject | Re: [linux-audio-dev] Re: desktop and multimedia as an afterthought? | Date | Tue, 13 Jul 2004 23:37:12 +0100 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |