Skip Navigation Links | |
Exit Print View | |
![]() |
Multithreaded Programming Guide Oracle Solaris 11 Express 11/10 |
1. Covering Multithreading Basics
4. Programming with Synchronization Objects
5. Programming With the Solaris Software
Forking Issues in Process Creation
Fork-One Safety Problem and Solution
Process Creation: exec and exit Issues
Profiling a Multithreaded Program
Nonlocal Goto: setjmp and longjmp
Setting the Thread's Signal Mask
Sending a Signal to a Specific Thread
Waiting for a Specified Signal
Waiting for Specified Signal Within a Given Time
Signal Handlers and Async-Signal Safety
Interrupted Waits on Condition Variables
I/O as a Remote Procedure Call
Waiting for I/O Operation to Complete
Shared I/O and New I/O System Calls
6. Programming With Solaris Threads
The Solaris kernel has three ranges of dispatching priority. The highest-priority range (100 to 159) corresponds to the Realtime (RT) scheduling class. The middle-priority range (60 to 99) corresponds to the system (SYS) scheduling class. The system class cannot be applied to a user process. The lowest-priority range (0 to 59) is shared by the timesharing (TS), interactive (IA), fair-share (FSS), and fixed priority (FX) scheduling classes.
A scheduling class is maintained for each LWP. When a process is created, the initial LWP inherits the scheduling class and priority of the creating LWP in the parent process. As more threads are created, their associated LWPs also inherit this scheduling class and priority.
Threads have the scheduling class and priority of their underlying LWPs. Each LWP in a process can have a unique scheduling class and priority that are visible to the kernel.
Thread priorities regulate contention for synchronization objects. By default, LWPs are in the timesharing class. For compute-bound multithreading, thread priorities are not very useful. For multithreaded applications that use the MT libraries to do synchronization frequently, thread priorities are more meaningful.
The scheduling class is set by priocntl(2). How you specify the first two arguments determines whether only the calling LWP or all the LWPs of one or more processes are affected. The third argument of priocntl() is the command, which can be one of the following commands.
PC_GETCID - Get the class ID and class attributes for a specific class.
PC_GETCLINFO - Get the class name and class attributes for a specific class.
PC_GETPARMS - Get the class identifier and the class-specific scheduling parameters of a process, an LWP with a process, or a group of processes.
PC_SETPARMS - Set the class identifier and the class-specific scheduling parameters of a process, an LWP with a process, or a group of processes.
The user-level priority of an LWP is its priority within its class, not its dispatch priority. This does not change over time except by the application of the priocntl() system call. The kernel determines the dispatch priority of an LWP based on its scheduling class, its priority within that class, and possibly other factors such as its recently-used CPU time.
Timeshare scheduling attempts to distribute processor resources fairly among the LWPs in the timesharing (TS) and interactive (IA) scheduling classes.
The priocntl(2) call sets the class priority of one or more processes or LWPs. The normal range of timesharing class priorities is -60 to +60. The higher the value, the higher the kernel dispatch priority. The default timesharing class priority is 0.
The old concept of a nice value for a process, where a lower nice value means a higher priority, is maintained for all of the TS, IA, and FSS scheduling classes. The old nice-based setpriority(3C) and nice(2) interfaces continue to work by mapping nice values into priority values. Setting a nice value changes the priority and vice-versa. The range of nice values is -20 to +20. A nice value of 0 corresponds to a priority of 0. A nice value of -20 corresponds to a priority of +60.
The dispatch priority of time-shared LWPs is calculated from the instantaneous CPU use rate of the LWP and from its class priority. The class priority indicates the relative priority of the LWPs to the timeshare scheduler.
LWPs with a smaller class priority value get a smaller, but nonzero, share of the total processing. An LWP that has received a larger amount of processing is given lower dispatch priority than an LWP that has received little or no processing.
The Realtime class (RT) can be applied to a whole process or to one or more LWPs in a process. You must have superuser privilege to use the Realtime class.
The normal range of realtime class priorities is 0 to 59. The dispatch priority of an LWP in the realtime class is fixed at its class priority plus 100.
The scheduler always dispatches the highest-priority Realtime LWP. The high-priority Realtime LWP preempts a lower-priority LWP when a higher-priority LWP becomes runnable. A preempted LWP is placed at the head of its level queue.
A Realtime LWP retains control of a processor until the LWP is preempted, the LWP suspends, or its Realtime priority is changed. LWPs in the RT class have absolute priority over processes in the TS class.
A new LWP inherits the scheduling class of the parent process or LWP. An RT class LWP inherits the parent's time slice, whether finite or infinite.
A finite time slice LWP runs until the LWP terminates, blocks on an I/O event, gets preempted by a higher-priority runnable Realtime process, or the time slice expires.
An LWP with an infinite time slice ceases execution only when the LWP terminates, blocks, or is preempted.
The fair share scheduler (FSS) scheduling class allows allocation of CPU time based on shares.
The normal range of fair share scheduler class priorities is -60 to 60, which get mapped by the scheduler into dispatch priorities in the same range (0 to 59) as the TS and IA scheduling classes. All LWPs in a process must run in the same scheduling class. The FSS class schedules individual LWPs, not whole processes. Thus, a mix of processes in the FSS and TS/IA classes could result in unexpected scheduling behavior in both cases.
The TS/IA or the FSS scheduling class processes do not compete for the same CPUs. Processor sets enable mixing TS/IA with FSS in a system. However, all processes in each processor set must be in either the TS/IA or the FSS scheduling class.
The FX, fixed priority, scheduling class assigns fixed priorities and time quantum not adjusted to accommodate resource consumption. Process priority can be changed only by the process that assigned the priority or an appropriately privileged process. For more information about FX, see the priocntl(1) and dispadmin(1M) man pages.
The normal range of fixed priority scheduler class priorities is 0 to 60, which get mapped by the scheduler into dispatch priorities in the same range (0 to 59) as the TS and IA scheduling classes.