Coder Perfect

How do I boost the priority of a thread in pthreads?


In Linux, I use pthread. I’d like to boost the thread priority by using the sched param.priority arguments. However, I couldn’t find much information on the internet about the thread priority range that I could select or the explanation of the thread priority.

Also, I’d like to know about the relative thread priority because I don’t want to make the thread priority too high and cause the OS to crash. Is there anyone that could assist me with this?

Asked by Steveng

Solution #1

The default Linux scheduling policy is SCHED OTHER, which has no priority setting but does have a good level to play with within the policy.

You’ll need to use the method pthread setschedparam to switch to a different scheduling strategy (see also man sched setscheduler).

(from sched setscheduler(2)) ‘Normal’ scheduling policies:

   SCHED_OTHER   the standard round-robin time-sharing policy;
   SCHED_BATCH   for "batch" style execution of processes; and
   SCHED_IDLE    for running very low priority background jobs.

Real-time scheduling policies:

   SCHED_FIFO    a first-in, first-out policy; and
   SCHED_RR      a round-robin policy.

In your scenario, SCHED BATCH would be a good option because it doesn’t require root access.

Warning: Using real-time scheduling policies incorrectly can cause your system to hang. This is why this type of action necessitates root privileges.

You can use the chrt utility from the util-linux package to see what your computer is capable of just to be sure. Consider the following scenario:

$ chrt -m 
SCHED_OTHER min/max priority    : 0/0
SCHED_FIFO min/max priority     : 1/99
SCHED_RR min/max priority       : 1/99
SCHED_BATCH min/max priority    : 0/0
SCHED_IDLE min/max priority     : 0/0

A technique for wasting less time (which I frequently employ):

alias batchmake='time chrt --batch 0 make --silent'

This increases the make by 15% while maintaining user privileges (in my case).

Edit: great, SCHED BATCH, SCHED IDLE, and the chrt tool are now available. For the sake of accuracy! 🙂

Answered by levif

Solution #2

For the current NPTL thread implementation on Linux, levif’s current answer (recommending SCHED BATCH) is incorrect (you can check which implementation your kernel has by running ‘getconf GNU LIBPTHREAD VERSION’).

Only the Real Time Scheduling policies (SCHED OTHER, SCHED BATCH, and SCHED IDLE) in today’s kernel allow setting of sched priority; it is always 0 for non-RT policies (SCHED OTHER, SCHED BATCH, and SCHED IDLE). For non-RT policies, your only option is to use ‘nice’ values, such as setpriority (). However, there are no solid descriptions of the exact behavior to expect when setting ‘nice,’ and it could change, as least in theory, from kernel version to kernel version. Because ‘nice’ has a strong effect similar to priority in modern Linux kernels, you can use it alternatively. Reduce your ‘nice’ value to enhance the frequency with which your thread is scheduled. This requires the CAP SYS NICE capability (usually root, but not always; see and set proc.3.html for further information).

In fact, SCHED BATCH is intended for the polar opposite of the questioner’s request: it is intended for CPU-intensive, long-running processes that can live with a lower priority. It instructs the scheduler to reduce the threads’ wake-up priority by a little amount.

Also, to respond to one of the earlier comments (I don’t currently have enough reputation to respond – some upvotes for this answer would be helpful:)). The bad news is that ‘nice’ only affects processes, not individual threads, according to the POSIX.1 definition. The good news is that both NPTL and the original Linux Threads implementations break the specification, allowing it to affect individual threads. This is frequently mentioned in the “BUGS” portion of the man pages, which I find hilarious. I believe the issue was in the POSIX.1 specification, which should have allowed this behavior, rather than in the implementations, which were forced to deliver it despite the specification and did so knowingly and intentionally. To put it another way

Most of this is detailed on the sched(7) man page (which for some reason is not delivered on my Fedora 20 system):

If you truly needed to change sched priority, look into Real Time policies like SCHED RR).

Answered by BobDoolittle

Solution #3

POSIX defines a query, which allows you to ask the operating system for the permitted range of priorities.

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

Expect increased priority to have no effect on the machine. In fact, unless you’re already using 100% of your CPU cycles, don’t expect it to do anything. If the query informs you that there is no priority greater than the default, don’t be startled.

Answered by Potatoswatter

Post is based on