I have 2 threads, each set to a different real-time priority using SCHED_FIFO. Thread throttling has been disabled, so theoretically the highest priority thread should be able to use 100% of CPU resources, preventing lower priority threads from ever running. If I create a tight infinite loop in the lower priority thread that doesn't yield or sleep, I expect that no lower priority threads will ever get to run. However it appears as though the higher priority thread's standard output also stops, indicating that it is also prevented from running, which confuses me.
Why can this lower priority thread interfere with a higher priority thread that should always have priority? Does it have something to do with the tight infinite loop, or am I fundamentally misunderstanding how Linux thread priorities should work?
I've tried to make the question as general as possible, but since the answer might be related to my very specific setup, I'm using kernel version 4.1.33 with the RT Preempt patch, running on an ARMV7 CPU.
I created a dead simple test program to recreate the issue without any complication, and as expected, the problem disappeared. This indicates that some shared resource was likely to blame for the higher priority thread not being able to run (as was suggested in the comments below). However, I can't think of any such resources the higher priority thread would need access to.
Part of my problem now is that I'm not sure what types of resources would require an exclusive lock. Things like access to the system clock, or access to the filesystem, or access to standard output, are common things that I'm unsure of in regard to whether a lock is used. Could any of those (or perhaps something similar that I overlooked) prevent the higher priority thread from running?