[...] > 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
