Processor Management
The
heart of managing the processor comes down to two
related issues:
- Ensuring that each process and application
receives enough of the processor's time to function
properly
- 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. It
also makes use of registers, stacks and queues within
the CPU and operating-system memory space.
- When two processes are multi-tasking, the
operating system allots a certain number of CPU
execution cycles to one program.
- After that number of cycles, the operating system
makes copies of all the registers, stacks and queues
used by the processes, and notes the point at which
the process paused in its execution.
- It then loads all the registers, stacks and queues
used by the second process and allows 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
- 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 gets enough CPU cycles 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 by reducing 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. 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. Asymmetric operating systems use
one CPU for their own needs and divide application
processes among the remaining CPUs. Symmetric
operating systems 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.