Last month, we saw that the threads library implements a relatively simple queue of runnable threads, in which threads at the same user-thread priority are maintained on a linked list. Each list of threads is rooted in an array, and there's one array location for each of the 128 (0 through 127) possible thread priorities. User-thread scheduling is accomplished by the unbound threads calling into preemption and dispatcher routines at various points in the code path, such as when a thread blocks on a user-defined synchronization object.

User threads can inherit their priority from their calling thread. This thread will have a default value of zero, though it can be explicitly increased with a pthread_attr_setschedparam(3thr) or pthread_setschedparam(3thr) call. The difference between the two interfaces can be summarized as follows:

pthread_attr_setschedparam(3thr) makes use of an attribute object (see last month's column for a list of thread attributes), which can be set and passed as an argument to a pthread_create(3thr) call. Once the thread has been created, attribute changes can't be made, because there's no runtime linkage between a user thread and an attribute object.

pthread_setschedparam(3thr) takes a thread ID as an argument, and can alter the priority of a running thread. For that reason, the desired attributes of a thread must be determined prior to the thread's creation, as most of them cannot be changed once the thread has been created.

The priorities of Solaris threads can be altered using either the thr_setprio(3thr) or thr_getprio(3thr) interface to retrieve the threads' priority.

Three possible scheduling policies are available for POSIX threads. The default policy is SCHED_OTHER, which is defined as implementation-specific. In Solaris, it provides for a new thread inheriting the scheduling policy of the creator thread. By default, it provides timeshare or interactive scheduling behavior. Note that POSIX threads provide an attribute allowing for a thread to ignore inherited scheduling policy. (See pthread_attr_setinheritsched(3thr).) We'll revisit that idea in a moment. For now, assume the default behavior if inheriting scheduling policy.

POSIX also provides for SCHED_FIFO (first in, first out) and SCHED_RR (round robin) policies. Solaris support for these policies first appeared in Solaris 7. Both scheduling policies will cause the newly created thread to be placed in the realtime scheduling class if the thread is bound. In other words, if the contentionscope attribute is PTHREAD_SCOPE_SYSTEM (which is how one creates bound threads using POSIX interfaces), the threads library issues a priocntl(2) system call internally to place the bound pthread in the realtime scheduling class. As such, the effective user identification (UID) of the user executing the code must be root, as only root can place processes and threads in the realtime scheduling class.

The difference between the two policies when dealing with bound threads is somewhat subtle. The documentation indicates that a SCHED_FIFO thread will execute to completion unless it's preempted by a higher priority

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine