Processor Management The heart
of managing the processor comes down to two related issues: First,
ensuring that each process and application receives enough of the
processor's time to function properly and, second, using as many
processor cycles for real work as is possible. The basic unit of
software that the operating system deals with in scheduling the work
done by the processor is either a process or a thread,
depending on the operating system.
It's tempting to think of a process as an application, but that
gives an incomplete picture of how processes relate to the operating
system and hardware. The application you see (word processor or
spreadsheet or game) is, indeed, a process, but that application may
cause several other processes to begin, for tasks like
communications with other devices or other computers. There are also
numerous processes that run without giving you direct evidence that
they ever exist. A process, then, is software that performs some
action and can be controlled -- by a user, by other applications or
by the operating system.
It is processes, rather than applications, that the operating
system controls and schedules for execution by the CPU. In a
single-tasking system, the schedule is straightforward. The
operating system allows the application to begin running, suspending
the execution only long enough to deal with interrupts and user
input. Interrupts are special signals sent by hardware or software
to the CPU. It's as if some part of the computer suddenly raised its
hand to ask for the CPU's attention in a lively meeting. Sometimes
the operating system will schedule the priority of processes so that
interrupts are masked, that is, the operating system will ignore the
interrupts from some sources so that a particular job can be
finished as quickly as possible. There are some interrupts (such as
those from error conditions or problems with memory) that are so
important that they can't be ignored. These non-maskable interrupts
(NMIs) must be dealt with immediately, regardless of the other tasks
at hand.
While interrupts add some complication to the execution of
processes in a single-tasking system, the job of the operating
system becomes much more complicated in a multi-tasking system. Now,
the operating system must arrange the execution of applications so
that you believe that there are several things happening at once.
This is complicated because the CPU can only do one thing at a time.
In order to give the appearance of lots of things happening at the
same time, the operating system has to switch between different
processes thousands of times a second. Here's how it happens.
A process occupies a certain amount of RAM. In addition, the
process will make use of registers, stacks and queues within the CPU
and operating system memory space. When two processes are
multi-tasking, the operating system will allow a certain number of
CPU execution cycles to one program. After that number of cycles,
the operating system will make copies of all the registers, stacks
and queues used by the processes, and note the point at which the
process paused in its execution. It will then load all the
registers, stacks and queues used by the second process and allow it
a certain number of CPU cycles. When those are complete, it makes
copies of all the registers, stacks and queues used by the second
program, and loads the first program.
All of the information needed to keep track of a process when
switching is kept in a data package called a process control
block. The process control block typically contains an ID number
that identifies the process, pointers to the locations in the
program and its data where processing last occurred, register
contents, states of various flags and switches, pointers to the
upper and lower bounds of the memory required for the process, a
list of files opened by the process, the priority of the process,
and the status of all I/O devices needed by the process. When the
status of the process changes, from pending to active, for example,
or from suspended to running, the information in the process control
block must be used like the data in any other program to direct
execution of the task-switching portion of the operating system.
This process swapping happens without direct user interference,
and each process will get enough CPU time to accomplish its task in
a reasonable amount of time. Trouble can come, though, if the user
tries to have too many processes functioning at the same time. The
operating system itself requires some CPU cycles to perform the
saving and swapping of all the registers, queues and stacks of the
application processes. If enough processes are started, and if the
operating system hasn't been carefully designed, the system can
begin to use the vast majority of its available CPU cycles to swap
between processes rather than run processes. When this happens, it's
called thrashing, and it usually requires some sort of direct
user intervention to stop processes and bring order back to the
system.
One way that operating system designers reduce the chance of
thrashing is to reduce the need for new processes to perform various
tasks. Some operating systems allow for a "process-lite," called a
thread, that can deal with all the CPU-intensive work of a normal
process, but generally does not deal with the various types of I/O,
and does not establish structures requiring the extensive process
control block of a regular process. Finally, a process may start
many threads or other processes, but a thread cannot start a
process.
So far, all the scheduling we've discussed has concerned a single
CPU. In a system with two or more CPUs, the operating system must
divide the workload among the CPUs, trying to balance the demands of
the required processes with the available cycles on the different
CPUs. Some operating systems (called asymmetric) will use one
CPU for their own needs, dividing application processes among the
remaining CPUs. Other operating systems (called symmetric)
will divide themselves among the various CPUs, balancing demand
versus CPU availability even when the operating system itself is all
that's running. Even if the operating system is the only software
with execution needs, the CPU is not the only resource to be
scheduled. Memory management is the next crucial step in making sure
that all processes run smoothly.