Process scheduling Sun Aug 1 16:14:46 2004
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
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
nice -n +20 myjob &
(there are related system calls that let a process set its own
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.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2010-10-29 Tony Lawrence