> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jul 12 04:15:03 2011
This archive was generated by hypermail 2.1.8 : Tue Jul 12 2011 - 04:15:03 EEST