On 9/25/07, Jonathan Walsh <jwalsh@atl....> wrote:
> I am attempting to set up a program that has 3 threads. The first
> thread is a receiver process that listens on a UDP port and puts a
> struct on a one of two queues depending on a flag in the packet. The
> other two threads block on a pthread_cond_t (that is signaled when a
> message is added to their queue), then take messages off their
> corresponding queues and perform a fixed amount of computation. I am
> setting thread priorities as follows:
> pthread_t tid_processor;
> struct sched_param sparam;
> pthread_attr_t tattr;
> pthread_attr_getschedparam(&tattr, &sparam);
> sparam.sched_priority = SOME_THREAD_PRIORITY;
> pthread_attr_setschedpolicy(&tattr, SCHED_FIFO);
> pthread_attr_setschedparam(&tattr, &sparam));
> pthread_create(&tid, &tattr, &thread_function, NULL );
> I set the receiver thread to the highest priority, then one of the
> processor threads is higher than the other.
> I have two questions about this situation:
> 1) Are pthread priorities reversed from Linux priorities. In other
> words, does a lower number mean a higher priority?
No. SCHED_FIFO or SCHED_RR have an allowed range of 1 to 99 with lower
numbers representing lower thread priorities.
> 2) Will a higher priority thread preempt the execution of a lower
> priority thread?
Normally, this is the true for SCHED_FIFO, where threads run until
preempted by a thread of higher priority, or until blocked.
However, Linux limits the scheduling policies SCHED_RR and SCHED_FIFO
to processes with superuser privileges. So, unless your program runs
with elevated privileges SCHED_OTHER will be selected by default which
is "based on the nice level ... and increased for each time quantum
the process [i.e. thread] is unable to run." according to
(Note, the pthread_set_schedparam() call maps to the
sched_setscheduler() call. An operation that requires root
For SCHED_OTHER the allowed mininmum and maximum priorities are 0.
Therefore it is not possible to change the priority.