Scheduling in the user threads library, Part 2

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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

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