Threads

Multiplexed thread scheduling

Multiplexed threads are subjected to two levels of scheduling:

Threads Library Scheduling: The Threads Library scheduler assigns multiplexed threads to LWPs for execution and, at times, preempts them so the LWP can pick up another thread.
System Scheduling: The kernel assigns LWPs to (hardware) processors and later preempts them.

The Threads Library maintains a ``priority level'' for each multiplexed thread. This value plays a role in the selection of a thread for assignment to an LWP. The priority value of a multiplexed thread can be modified by any other thread in the process via the thr_setprio(3thread) function.

   int thr_setprio(
   	thread_t tid,
   	int      prio
   );

Runnable, multiplexed threads are scheduled for execution as follows:

A thread with a higher priority value will be scheduled to run before a thread with a lower value.
Threads with the same priority will be scheduled on a first-come, first-serve basis.
The valid range of priorities is 0 to MAXINT-1; however, the Threads Library is optimized for a maximum priority of 126 (or less).

The Threads Library must select a thread for assignment to an LWP on the following occasions:

When an LWP becomes available, the highest priority runnable multiplexed thread will be assigned to it.
For example, an LWP becomes available when a thread exits, or when a multiplexed thread blocks on a thread synchronization mechanism (discussed later), or when the concurrency level is increased.
When a multiplexed thread becomes runnable (perhaps a mutex has been released by one thread and acquired by another), it will preempt a running multiplexed thread of a lower priority.
When an executing thread calls thr_yield(3thread), it deliberately surrenders its LWP to a runnable thread of equal or higher priority (if any).

Threads Library scheduling and system scheduling are independent of each other.

The Threads Library can assign a thread to an LWP but cannot say when that LWP will actually execute.
The kernel is unaware that the Threads Library is using LWPs to implement (user-level) threads. The kernel maintains its own scheduling context (for example, current priority, ``nice value'', priority class) that is separate from similar features that the Threads Library maintains for threads.

The interaction of these two levels of scheduling can produce some interesting effects:

LWPs of the time-sharing priority class will have their kernel priority adjusted dynamically according to processor usage and other factors.
NOTE: See the priocntl(2) manual page for further details of the time-sharing priority class. Note that using the priocntl(2) system call directly from a multiplexed thread should be avoided because it may interfere with thread scheduling by the Threads Library.
Consequently, a thread picked up by an LWP may run with a kernel priority determined by the activity of the prior thread on that LWP.
It is possible for a thread of high priority from the point of view of the Threads Library to be picked up by an LWP of relatively low priority to the kernel.

Additional points to consider:

A thread that is blocked in a system call will remain with its LWP until that system call returns.
Each LWP in the pool used for multiplexed LWPs is of the same kernel scheduling class (that is, time-sharing or fixed priority). That class is determined by the scheduling class (that is, time-sharing or fixed priority) of the LWP running the initial thread of the program.
One step in associating a thread with an LWP is to make the signal mask of the LWP agree with that of the thread. On each thread context switch there is a check for agreement. If the mask of the new thread differs from that of the prior thread, there is a system call to update the mask of the LWP. One implication of this is that using threads with a wide variety of signal masks can add to the cost of switching threads.