Process scheduling is obviously important on multi-user systems. It's also important on systems we use as individuals. For example, contrast the startup of my Mac OS X box and my wife's XP system. Both have certain programs set to start up at login, but they obviously handle the scheduling much differently. On the Mac, I can click into any process that has started and can use it while other programs are still starting. On XP, I can't: the other programs will command the CPU's attention until everything is running.
Process scheduling is an extremely complex subject. Algorithms can favor one type of process over another - a batch system would use a different method than one designed for interactive use, a real-time system necessarily has to work much differently than a system that doesn't need real-time capability. This article barely scratches the surface of all that, but will attempt to give an overview of scheduling.
On a typical OS, a process runs until it either finishes, waits for I/O or some other event (sleeping for a specific period, for example), or is interrupted by some external event. If nothing else, a timer has been set (by the kernel) giving the process a maximum time slice, and an interrupt will occur when that time slice expires (the concept of a timer is what differentiates a preemptive multi-tasking system from a "cooperative" system like Mac OS 9 or Windows 98 where a runaway process can hang the entire system).
When one of these things occurs, the kernel scheduler selects a new process to run. Exactly how it determines which process will get cpu time is where all the complexity comes in. Obviously the first thing to look at is whether the process is ready to run - if it is still voluntarily sleeping or waiting for some I/O event that hasn't completed, there is no point in scheduling it. But given two or more processes that are ready to run, how does the scheduler decide which is next?
On all Unix-like systems, including Linux, every process has a priority that varies from -20 to +20. Lower numbers mean higher priority. This is also called the "nice" value because the "nice" command (and "renice" on some systems) sets the priority. If you want to decrease the priority of the Linux process "myjob" with PID 43211, you could:
renice +20 -p 43211
Or, you could have started "myjob" with low priority to begin with:
nice -n +20 myjob &
(there are related system calls that let a process set its own priority)
On Windows XP, the Processes tab in the Task Manager (Ctrl-Alt-Del) lists processes. Right click on any process, and you can change its priority. You can start a Windows program at a specific priority by using the START command in a batch file - see "start ?" at a command prompt for details.
Priority is seldom the only factor an OS uses for scheduling, however. Much more complexity goes into deciding which process will run next. How the scheduler makes these decisions is often referred to as the scheduling policy For example, interactive processes (you at the keyboard) are usually given more attention than background processes. Within otherwise equal choices, a process that didn't use up its entire time slice the last time it ran will have a better chance of running sooner than one that did. The scheduler may also set the time slice for a process that it does decide to run, thereby affecting the maximum time it gets to use the cpu, and therefore being more (or less) fair to other processes still waiting to run.
Some operating systems only let you adjust priority, while others will let you adjust much more of the scheduler's activities. The dispadmin command in Solaris and Unixware is a good example of that type of flexibility. Modern Linux versions have the same capability.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2010-10-29 Tony Lawrence