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