Scheduling Policy
If the contention scope is RW_THR_PROCESS_SCOPE, then the scheduling policy is fixed at RW_THR_PREEMPTIVE because, under Solaris, process-scope, or “unbound” threads run until preempted or blocked; the threads are not time-sliced.
NOTE: The scheduling under RW_THR_PROCESS_SCOPE is not truly preemptive, because unbound threads are scheduled for execution on one or more LWPs, and these LWPs are scheduled independently of the unbound threads, usually in a time-sliced manner. This results in a hybrid form of scheduling that is difficult to describe using a single policy.
If the contention scope is RW_THR_PROCESS_SCOPE, you may query the scheduling policy, and may set the scheduling policy to RW_THR_PREEMPTIVE, but any attempt to change to another policy will produce an exception.
If the contention scope is RW_THR_SYSTEM_SCOPE, then the thread will be “bound” to an LWP which, depending on the scheduling attributes of the creating thread, the attributes of the thread’s LWP, and the current process privileges, may support any one of RW_THR_TIME_SLICED_DYNAMIC, RW_THR_TIME_SLICED_FIXED, or RW_THR_PREEMPTIVE scheduling policies.
The Threads Module implementation for Solaris maps scheduling policies to the underlying API as follows:
RW_THR_TIME_SLICED_DYNAMICThe LWP associated with the bound thread is assigned to the time-shared (TS)) scheduling class.
RW_THR_TIME_SLICED_FIXEDThe LWP is assigned to the real-time (RT) scheduling class with the time-slice quantum variables,
((rtparms_t *)pcparms_t.pc_clparms)->rt_tqsecs
((rtparms_t *)pcparms_t.pc_clparms)->rt_tqnsecs
set to a default, inherited, or other specified legal time-slice quantum value. The current process must have root privileges in order to specify this policy.
RW_THR_PREEMPTIVEFor process-scope threads, this is the default and only policy available. For system-scope threads, the thread’s LWP is assigned to the real-time (RT) scheduling class with the time-slice quantum variable,
((rtparms_t *)pcparms_t.pc_clparms)->rt_tqnsecs,
set equal to RT_TQINF to indicate that the thread is to receive an infinite time quantum. The current process must have root privileges in order to specify this policy for system-scope threads.
If the contention scope is RW_THR_SYSTEM_SCOPE, you may query the scheduling policy, and you may attempt to set the scheduling policy to any of the three policies listed above, but if the process lacks the necessary privileges, or if an unsupported policy is specified, then these attempts will produce an exception.
The Solaris implementation of the Threads Module requires the use of two separate priority values for threads with system contention scope; one priority value sets the system-level scheduling priority for a thread (a thread’s LWP, actually), while the second value is used to prioritize access to any thread-level synchronization resources shared with other threads in the same process. The process-level synchronization priority is called the process scope priority value, and the system-level scheduling priority is called the system-scope priority value.
The RWThreadAttribute class provides separate families of member functions for independently manipulating these two priority values; see the Threads Module User’s Guide for a listing of these functions.
You should only need to define a separate process-scope priority for a system-scope thread when you have used more than one priority value for your process-scope threads, and it is possible that your system-scope thread may deadlock as a result of priority inversion because it was created with the default process-scope priority value.
A new thread’s scheduling policy is inherited from the creating thread, unless the scheduling policy attribute has been explicitly set or the inheritance policy is set to RW_THR_EXPLICIT. If the inheritance policy is RW_THR_EXPLICIT, the Threads Module defines the default scheduling policy based on the current contention scope:
Contention Scope | Default Scheduling Policy |
|---|---|
RW_THR_PROCESS_SCOPE | RW_THR_PREEMPTIVE |
RW_THR_SYSTEM_SCOPE | RW_THR_TIME_SLICED_DYNAMIC |
If you change the scheduling policy attribute, the Threads Module will check that the priority and time-slice quantum values are still legal under the new scheduling policy, and if not, will force those attributes to the appropriate default values. (See the next sections on Scheduling Priority and Scheduling Time-Slice Quantum.)
Similarly, changing the contention scope attribute may force changes in the scheduling policy and related attribute values.
