> The problem with e.g. a Jack callback trying to take a lock > is that the lock could be held by a non-RT thread, and you > have no idea how long it could take before that thread > releases it. Even if the Jack thread blocks waiting for > the lock, that doesn't mean the one holding the lock will > continue, and even if it does that provides no guarantee.
Priority inversion. A low-priority "disk thread" could hold a lock needed by the high-priority Jack process thread. But the disk thread is pre-empted by some other non-related medium-priority process. The medium-priority process could keep running for a long time. So the inversion is that, indirectly, a high-priority thread is waiting for some medium-priority process. Some RTOS's deal with this kind of stuff (like "hard" real-time OSs) -- Dan _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
