[...]
Please double-check that there are no priority
inversion problems and that
the application is correctly setting the scheduling policy and that it is
mlocking everything appropriately.
I don't think it is currently possible to have cooperating threads with
different priorities without priority inversion when using a mutex to
serialize access to shared data; and using a mutex is in fact the only portable
way to do that...
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.
It is often heard in the Linux audio community that mutexes are not realtime
safe and a lock-free ringbuffer should be used instead. Using such a lock-free
ringbuffer requires non-standard atomic integer operations and does not
guarantee memory synchronization (and should probably not perform
significantly better than a decent mutex implementation) and is thus not
portable.
--ms