Thread priority problem on Linux

[Chih-Chung Chang]

Hi,

I found that PR_SetThreadPriority does not work
on Linux because (the default) SCHED_OTHER processes
can only have static priority 0 on Linux. Should
setpriority() be used instead in this case?

Thanks,
Chih-Chung Chang

[Wan-Teh Chang]

Post by Chih-Chung Chang
Hi,
I found that PR_SetThreadPriority does not work
on Linux because (the default) SCHED_OTHER processes
can only have static priority 0 on Linux.

You are right. I verified that
sched_get_priority_max(SCHED_OTHER) and
sched_get_priority_min(SCHED_MIN) both
return 0 on Red Hat Linux Advanced Server 2.1
(using LinuxThreads) and 3 (using "NPTL", see
below).

Post by Chih-Chung Chang
Should setpriority() be used instead in this case?

I don't know. setpriority() will be inappropriate
when you use the new Native POSIX Thread Library
(NPTL) because in NPTL the threads aren't process
clones any more.

I'm also worried about using a function that
is not part of the pthread library. It may
have unforseen interaction with the pthread
library.

Does your code rely on thread priorities?

Wan-Teh

[Chih-Chung Chang]

Post by Wan-Teh Chang

Post by Chih-Chung Chang
Hi,
I found that PR_SetThreadPriority does not work
on Linux because (the default) SCHED_OTHER processes
can only have static priority 0 on Linux.

You are right. I verified that
sched_get_priority_max(SCHED_OTHER) and
sched_get_priority_min(SCHED_MIN) both
return 0 on Red Hat Linux Advanced Server 2.1
(using LinuxThreads) and 3 (using "NPTL", see
below).

Post by Chih-Chung Chang
Should setpriority() be used instead in this case?

I don't know. setpriority() will be inappropriate
when you use the new Native POSIX Thread Library
(NPTL) because in NPTL the threads aren't process
clones any more.

It seems setpriority() still works under NPTL, but
you need to use the value returned by (Linux specific)
gettid() instead of getpid() for the second parameter.

Post by Wan-Teh Chang
I'm also worried about using a function that
is not part of the pthread library. It may
have unforseen interaction with the pthread
library.

I found the interaction is defined, but Linux
doesn't follow it:
http://www.opengroup.org/onlinepubs/009695399/functions/setpriority.html

Post by Wan-Teh Chang
Does your code rely on thread priorities?

Yes, it is a video player, and a high priority
thread is used to ensure images can be displayed
on screen at regular intervals.

[Wan-Teh Chang]

Post by Chih-Chung Chang

Post by Wan-Teh Chang
I'm also worried about using a function that
is not part of the pthread library. It may
have unforseen interaction with the pthread
library.

I found the interaction is defined, but Linux
http://www.opengroup.org/onlinepubs/009695399/functions/setpriority.html

I quote the relevant text from that page:

The nice value set with setpriority() shall be
applied to the process. If the process is
multi-threaded, the nice value shall affect
all system scope threads in the process.

Any processes or threads using SCHED_FIFO or
SCHED_RR shall be unaffected by a call to
setpriority(). This is not considered an error.
A process which subsequently reverts to
SCHED_OTHER need not have its priority affected
by such a setpriority() call.

This interaction does not seem desirable. It
seems that setpriority sets a different kind of
priority called a "nice value". It's not clear
what the relation between a nice value and a
pthread's priority is.

Post by Chih-Chung Chang

Post by Wan-Teh Chang
Does your code rely on thread priorities?

Yes, it is a video player, and a high priority
thread is used to ensure images can be displayed
on screen at regular intervals.

Can you achieve that without relying on thread
priorities?

Can you use thread synchronization (mutex +
condition variable) to ensure that the image
display thread gets an opportunity to run
at regular intervals?

Thread priorities are not portable. In most
cases, proper thread synchronization rather
than thread priority is the right solution.

Wan-Teh

[Chih-Chung Chang]

Post by Wan-Teh Chang

Post by Chih-Chung Chang
I found the interaction is defined, but Linux
http://www.opengroup.org/onlinepubs/009695399/functions/setpriority.html

The nice value set with setpriority() shall be
applied to the process. If the process is
multi-threaded, the nice value shall affect
all system scope threads in the process.
Any processes or threads using SCHED_FIFO or
SCHED_RR shall be unaffected by a call to
setpriority(). This is not considered an error.
A process which subsequently reverts to
SCHED_OTHER need not have its priority affected
by such a setpriority() call.
This interaction does not seem desirable. It
seems that setpriority sets a different kind of
priority called a "nice value". It's not clear
what the relation between a nice value and a
pthread's priority is.

In http://www.opengroup.org/onlinepubs/009695399/functions/nice.html
it says:

Calling the nice() function has no effect on the priority of
processes or threads with policy SCHED_FIFO or SCHED_RR. The effect on
processes or threads with other scheduling policies is
implementation-defined.

Post by Wan-Teh Chang

Post by Chih-Chung Chang

Post by Wan-Teh Chang
Does your code rely on thread priorities?

Yes, it is a video player, and a high priority
thread is used to ensure images can be displayed
on screen at regular intervals.

Can you achieve that without relying on thread
priorities?
Can you use thread synchronization (mutex +
condition variable) to ensure that the image
display thread gets an opportunity to run
at regular intervals?
Thread priorities are not portable. In most
cases, proper thread synchronization rather
than thread priority is the right solution.

Yes, but to achieve this, another thread doing
lengthy computation must often check current
time and yield the cpu to the display thread
if the deadline is near. It is infeasible if
the lengthy computation is done in some other
library.