4

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.

EDIT:

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?

Improve this question
2
  • Are there any resources used by the lower-priority thread that the higher-priority thread might need?
    – mattdm
    Commented Sep 28, 2017 at 21:30
  • The lower priority thread simple waits for a flag to be set, and then enters the infinite loop. It doesn't access any shared resources that I can think of. There aren't any explicitly defined mutexes or semaphores that the higher priority thread would be stuck waiting on. However, I'm not exactly sure how things like filesystem access or program output being shown in the terminal are handled in a situation like this.
    – Echo404
    Commented Sep 28, 2017 at 21:36

1 Answer 1

Reset to default
2

In our Linux system, without our application running, the "ktimersoftd" thread is the highest priority, with a real-time priority of 1. However, our application, along with the third-party-libraries we were utilizing, all created higher priority real-time threads, preempting "ktimersoftd". It turned out that one of the third-party-libraries libraries we were utilizing depended on soft interrupts, which requires the "ktimersoftd" thread to be higher priority than the threads in the third-party-library. Raising the "ktimersoftd" thread's priority to real-time priority 98 solved the issues we were seeing.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .