Sched_Fifo Higher Priority Thread Is Getting Preempted by the Sched_Fifo Lower Priority Thread

Linux SCHED_FIFO not respecting thread priorities

When you start the two threads

// Declare and init thread objects
std::thread thread_1(std::move(task_1), 1, 50000000);
std::thread thread_2(std::move(task_2), 2, 50000000);

they may (!) immediately run and fetch the schedule parameters

// Get information about thread
pthread_getschedparam(pthread_self(), &policy, &sch);

even before you set them with pthread_setschedparam() to another value.
The output might even show 0 and 0, if both threads are scheduled accordingly.

---

The child threads may (!) both be scheduled after the main thread has set the priority. Then you would get the expected output. But any result is possible.

---

When you move pthread_getschedparam() to the end of the thread just before the output, you are more likely to get the expected output of 97 and 98. But even then both threads may run until the end, even before the main thread is scheduled to set the priority.

Linux not respecting SCHED_FIFO priority ? ( normal or GDB execution )

There are a few things obviously wrong with your MCVE:

1. You have a data race on b, i.e. undefined behavior, so anything can happen.

2. You are expecting that the divisor thread will have finished pthread_setschedparam call before the ratio thread gets to computing the ratio.

   But there is absolutely no guarantee that the first thread will not run to completion long before the second thread is even created.

   Indeed that is what's likely happening under GDB: it must trap thread creation and destruction events in order to keep track of all the threads, and so thread creation under GDB is significantly slower than outside of it.

To fix the second problem, add a counting semaphore, and have both threads randevu after each executed the pthread_setschedparam call.

What is the relationship between pthread priority and pthread policy?

Documentation for SCHED_RR says that it is the same as SCHED_FIFO except in certain cases when two or more threads have the same static priority.

Documentation for SCHED_FIFO makes it clear that if a thread with higher static priority is ready-to-run but not running, and if one or more threads with lower static priority are running, then one of the lower priority threads will be preempted in favor of the higher priority thread.

would thread 1 run at all [in the SCHED_RR case]?

That depends. What is thread 0 doing? How many CPUs does the system have? If those were the only two threads on a system that had only one CPU, then thread 1 would be allowed to run whenever thread 0 did not want to run.

Generally speaking, when you use static priorities, you want the highest priority threads to do the least amount of work. A high priority thread should spend most of its time waiting for some event. Then when the event happens, the thread should promptly acknowledge it, and then possibly signal a lower-priority thread if some kind of follow-up computation is required.

would thread 1 run at all [in the SCHED_OTHER case]?

As mentioned in my comment, if you're talking about static priorities (i.e., as set by the sched_setattr() system call, then the question is meaningless because threads that are scheduled under the SCHED_OTHER policy are all required to have the same static priority--zero.

---

Related Topics