SE<ER,1 N

Research during the last decade has revealed techniques by which future
operating systems can avoid the problems associated with
previous and present systems.

Operating Systems
D. A. Anderson
Bell Telephone Laboratories

An operating system is a program that resides on a partial initialization to flush an insane job or recover from
computer and acts as an interface between the user or ap- a transient hardware error without losing all active jobs.
plication programmer and the bare machine. It is a layer Total initialization is also called "bootstrapping" or
of software that surrounds and hides the physical hard- "initial program loading." Typically, the bootstrap
ware-a relationship depicted in Figure 1. The chief pur- mechanism consists of either hardware or firmware read-
pose of an operating system is to allow several users or ap- ing in a small bootstrap program which in turn reads in the
plications to share the computer in an efficient and operating system. In addition, the processor, memory,
noninterfering manner. and peripherals are initialized to the extent necessary
Although all computers have some form of operating before accepting the first external inputs or jobs.
system, exactly which program modules are part of the
operating system can be a matter of opinion. Generally,
those modules controlling machine resources such as pro-
cessors, primary and secondary memory, and peripheral
devices are considered the operating system. Compilers,
loaders, debuggers, and other application-oriented mod-
ules are usually not considered part of the operating sys-
tem.
While operating systems have existed since the first
stored program computers over 30 years ago, the com-
mon features and problems of operating systems have
been studied extensively only in the last 10 to 15 years.
Concepts and techniques resulting from this research are
applicable to all operating systems and help us to avoid
many of the pitfalls of the past. Highlights from this
research include the notion of processes and monitors for
the synchronization of parallel tasks,memory manage-
ment techniques, and improvements in system perfor-
mance, protection, and reliability.
Purpose. The earliest operating systems did little more
than initialize the hardware, bringing the machine up into a
state to run the first job. Initialization remains an impor-
tant function of all operating systems. However, in most
modern operating systems, this function now includes not
only total initialization for initial system bring up but also Figure 1. Operating system relationship.
June 1981 0018-9162/81/0600-O 069$00.75 ". 1981 IEEE 69
 Partial initialization can be much more difficult than
total initialization since it involves being selective about
what is initialized to preserve as many active jobs as possi-
ble. Partial initialization can also involve complex
schemes for recovery and rollback to save all active jobs.
Triggers for partial initializations include hardware er-
rors, sanity timer timeouts, or protection violations.
Schemes for partial initialization are especially important
in fault-tolerant, real-time, or large multiuser systems.
Another important function of an operating system is
acting as an "extended machine" to hide the complexities
of the bare machine from the user. To do this, an operat-
ing system must provide both an internal and an external
interface. For example, an internal user such as an ap-
plication programmer may perform I/O via system calls
to the operating system. The complexities of controlling
the physical I/O device are hidden by an I/O device driver
in the operating system. Such system calls are the internal
view of the operating system. The external view of the
operating system, on the other hand, is the command or
job control language or other method of presenting exter-
nal inputs or jobs to the system. Such an input language
attempts to provide a simple method for entering new
work into the computer.
Figure 2. Batch system flow.
Figure 3. Multiprogramming in a uniprocessor.
The third function of an operating system is providing a
resource management facility so that many users or pro-
cesses can share the machine. By far the most important
function of an operating system, this is also the most dif-
ficult to implement reliably. It is important primarily for
economic reasons, since the throughput of a computer
system is maximized when each resource-processor,
memory, or peripheral device-is managed well. Re-
source management is the means by which these resources
are shared among several concurrent processes in a man-
ner that is both fair and guaranteed to prevent unwanted
interference. The purpose of sharing is to maximize the
percent utilization of each resource.
Evolution of systems and techniques
General-purpose operating systems-the ones with
which most users have contact-run a wide variety of jobs
in a short period of time and are designed to handle such a
job mix well. The evolution of these general-purpose
operating systems can be traced from the first simple
single-job-at-a-time systems to the current complex, mul-
tiprogrammed distributed processing systems.
Single job. The earliest general-purpose operating sys-
tems were very primitive, executing only a single job at a
time. The typical input device was a card reader and the
typical output device was a line printer-both very slow in
comparison with a computer processor. The chief draw-
backs of executing only one job at a time were that the
processor and I/O devices were idle a large percentage of
the time and job execution was strictly sequential. Early
systems also had problems with erroneous user programs
bringing the machine down.
Batch. Improvements in system performance occurred
when secondary memory devices, such as magnetic tape
and disks, were used. These I/O devices operate at speeds
closer to that of the processor and primary memory.
Throughput on the main computer increased when it got
all of its input from and put all of its output on secondary
memory. Several small inexpensive computers would
copy input jobs from the card readers to the input batch
tapes and then copy the output batch tapes to the line
printers. These were known as the first batch systems,
since several jobs were batched together on tape. Figure 2
shows the flow of a job through a batch system.
While the first batch systems were improvements over
the earlier single-job systems, they still ran jobs sequen-
tially. Consequently, short jobs could have lengthy turn-
around time if they ended up behind long jobs. Further
delays resulted since the printed output of the first job on
a batch tape was not available until the entire batch had
executed. Manual delays for mounting tapes were also a
drawback of these early batch systems.
Multiprogramming. These problems associated with
the early batch systems were solved by introducing the in-
terrupt. When an interrupt occurs, a processor suspends
COMPUTER
the execution of the current program and starts another curred if the user tried to use privileged commands or to
program. The execution of the interrupted program is re- access certain areas of memory. Furthermore, program
sumed later, when it has finished handling the interrupt. synchronization techniques, described more fully below,
Interrupts are ways of breaking up the strictly sequential were developed to eliminate unwanted interaction.
nature of a computer as well as mechanisms by which
several jobs can be made to execute concurrently. The Multiprocessing. With multiprogramming, one pro-
technique supporting this concurrent operation is called cessor could control all of the I/O devices and keep them
",multiprogramming." and itself busy. However, the overhead of handling many
Multiprogramming was introduced to keep the pro- interrupts tended to slow a single processor. This situa-
cessor and I/O devices busy as much as possible. The tion led to the use of several processors-or "multipro-
basic technique is to have several jobs in memory at any cessing"-to improve throughput. Multiprocessing is
one time. One job executes on the processor until it needs characterized by two or more processors sharing the same
to do some peripheral I/O. The 1/0 device, being much memory. The techniques developed to support multipro-
slower than the processor, needs attention from the pro- gramming on a single processor, where two or more jobs
cessor only at infrequent times which can be signaled by share the same memory, are equally applicable to multi-
means of an interrupt. The one executing job starting an processing. Figure 5 provides an example of a multipro-
I/O operation is suspended, and a second job ready to ex- cessor system.
ecute is given control and begins execution on the pro- The most successful multiprocessing configurations
cessor. The 1/0 of the first job is done in small pieces at have been master/slave arrangements where one main pro-
each interrupt during the execution of the second job. In cessor controls several specialized I/O processors or chan-
this way, several jobs can execute concurrently, with one nels. In turn, the 1/0 processors each control one or more
job actually executing on the processor and the rest per- 1/0 devices and, with direct memory access, require little
forming some I/O operation. This technique utilizes the help from the main processor. In this way, the interrupt
system well as long as thejobs have a nice mix of computa- overhead of the main processor is significantly reduced.
tion and 1/0. Multiprocessing configurations with several main pro-
Soon it was realized that a timed interrupt could be used cessors in a loadsharing arrangement have been less suc-
to force multiprogramming. A job could be allowed to ex- cessful because each processor tends to perform worse in
ecute for a certain period of time, say one second, at a multiprocessor configuration than as a uniprocessor.
which time the job is interrupted by a timer. Then, the The main advantages of loadsharing multiprocessor sys-
operating system selects another job which runs until tems are that they are more fault tolerant because of their
stopped by I/O or the timed interrupt, and so forth. Thus, inherent redundancy and they are more expandable or
a long job with little 1/0 is forced to execute concurrently shrinkable as workloads change. Multiprocessing is be-
with other jobs. This is called "preemptive" scheduling. coming even more attractive as processors become
Since job execution is no longer strictly sequential, a short cheaper, since maximizing the utilization of each pro-
job can have good turnaround time-even if it starts be-
hind a long job. Figure 3 shows a multiprogramming
block diagram.
Spooling. Multiprogramming introduced the possibili-
ty of interleaving the output of several jobs on the line
printer, a problem solved by a technique called "spool-
ing,"-that is, simultaneous peripheral operations on-
line. When a job tries to write to the line printer, a spool-
ing program intercepts the request and converts it to a
write to secondary memory, such as a disk, converting
one line printer into many "logical" line printers on the
disk. The output from a job is printed correctly on a
physical line printer after it is done executing. This tech-
nique is also applied to any slow output or input device,
such as a card reader, which would otherwise have to be
dedicated to a job throughout its execution. Figure 4
shows how a spooling system is organized.
Protection. Although multiprogramming greatly im-
proved the performance of general-purpose systems, it
also increased system complexity. It was important to
keep concurrently running users from interfering with
one another or with the operating system. Protection was
provided by building computers that executed in two dif-
ferent states-a "privileged" state for the operating
system and a "restricted" state for the user. In the
restricted state, an interrupt to the operating system oc- Figure 4. Spooling organization.
June 1981
 cessor becomes less important. This trend is especially ap-
parent in microprocessor systems.
Timesharing. The job-oriented operating systems
described above are still referred to as batch systems. The
next major improvement was to get rid of the card reader
and minimize the use of the line printer. This was ac-
complished by introducing timesharing operating systems
that interact with users via terminals. All input and much
output goes directly to and from the individual user at a
terminal. Instead of submitting multistatement jobs, the
user types simple single-statement commands on the ter-
minal. This mode of interaction is also called "interac-
tive" or "conversational" since, for most commands, the
computer responds quickly with a simple answer. A mul-
titerminal timesharing system is shown in Figure 6.
To minimize response time to terminal-originated com-
mands-an important requirement for timesharing oper-
ating systems-these operating systems rely heavily on
multiprogramming techniques and preemptive sched-
uling. Responding to terminal commands is referred to as
"foreground" work in a timesharing system. Most
timesharing systems also allow input to be submitted in a
Figure 5. Example multiprocessor system.
batch mode as "background" work, which is given a
lower priority for use of the processor.
Distributed processing. Distributed processing, also
called "computer networking, " is the latest research area
regarding operating systems. A computer network is a
multicomputer arrangement where the computers com-
municate via special processor-to-processor data links.
This is a looser coupling than the shared memory commu-
nication of multiprocessing systems. A network can link
computers hundreds of miles or just a few feet apart. Short-
distance networks, perhaps contained in one building, are
referred to as "local" networks. Figure 7 shows a simple
distributed processing arrangement with just two comput-
ers. Most networks, however, contain many computers.
Computer networks have the same advantages of fault
tolerance and growth that multiprocessing systems have.
In addition, computer networks can greatly extend the ac-
Figure 6. Timesharing system.
cessibility and, hence, utilization of an expensive local-
ized subsystem such as a high-speed processor or large
data base. These advantages have been enhanced by the
availability of low-cost microprocessors and data link in-
terfaces produced by LSI circuit techniques.

Figure 7. Distributed processing system.
Special-purpose systems
Although general-purpose operating systems are the
most well-known, many special-purpose operating sys-
tems do exist and it would be an oversight not to mention
some of their features. Special-purpose operating systems
are custom-built either for a unique computer architec-
ture, such as an array processor, or for an application
with unique requirements, such as industrial process con-
trol. While most operating system research has been
directed toward improving general-purpose operating
systems, many of the ideas that have emerged can also be
applied to special-purpose systems.

72 COMPUTER
 Real-time. An importa-nt example of special-purpose
systems, real-time operating systems have requirements
that are similar to timesharing systems. However, there
are also some significant differences. Real-time inputs do
not wait indefinitely to be accepted by the computer. If
not accepted quickly, they may disappear or become er-
roneously out-of-date. Real-time systems typically are
dedicated and run the same programs over and over
again. Many of these programs may be tied down in pri-
mary memory to ensure a good response to the inputs they
handle.
Examples of real-time systems are computer systems
that control rapid-transit vehicles, collect data from
nuclear physics experiments, interpret radar data on an
aircraft, or control a telephone switching system. All of
these systems have as a common feature that they monitor
and/or control external ongoing activities with input data
rates that cannot be forced to adhere to a particular pace.
Sometimes real-time systems in business applications are
also referred to as "on-line" systems.
Fault tolerance. Fault-tolerant computer systems are
used in applications where providing continuous service
or preventing data mutilation is worth the additional ex-
pense of the redundancy necessary for fault tolerance.
Operating systems in such computer systems must pro-
vide the means for detecting errors and possibly recover-
ing from them. Recovery may mean either switching to a
standby unit when a fault occurs in an active unit or stop-
ping certain actions to prevent loss of data.
While fault-tolerant systems can be used in applica-
tions and environments where repair is possible, they can
also be used in environments where repair is not possible,
such as with space-borne applications. Different strate-
gies are used in each case. In addition, real-time systems
are often designed to be fault tolerant.
Virtual. Virtual operating systems are designed to run
several other operating systems concurrently on one
machine, creating the illusion of several machines. To do
this, an operating system running under a virtual opera-
ting system physically executes in restricted state but
behaves as if it were in the privileged state. When a
privileged instruction is executed, an interrupt occurs.
The virtual operating system handles the interrupt in a
way that corresponds to the privileged instruction actual-
ly being executed. In this way, several different operating
systems-or several different versions of one operating
system-may operate concurrently on one machine. This
technique can be used to check out new operating system
releases or to defer or eliminate user conversions to a dif-
ferent operating system.
Review of computer structures
All operating systems must provide certain common
services. Furthermore, they execute on machines with
common features and deal with similar program and data
structures. Since the discussion that follows concentrates
June 1981
on these aspects common to operating systems, it would
be useful to review briefly at this point a few basic at-
tributes of processor, memory, program, and data struc-
tures.
Processor. A processor or CPU executes program in-
structions fetched from primary memory. These instruc-
tions are 'normally executed sequentially by increasing
memory address. However, branching instructions can
cause a group of instructions to be skipped, repeated, or
called as a subroutine. When a subroutine is called, the
return memory address is saved for use by the return in-
struction at the end of the subroutine. Typically, the
return address is saved by being pushed on the top of a
stack in memory. The top of the stack is identified by a
stack-pointer register in the processor.
Interrupts are another way of breaking up the strict se-
quential execution of instructions. An interrupt
automatically forces the processor to begin execution at a
fixed address and, like a subroutine call, saves the return
address and usually a few other processor state registers
on the top of the stack. Such saving is necessary so that the
interrupt handler can return and resume proper execution
of the interrupted program.
Processors also have a number of general registers for
doing arithmetic, logical, and addressing operations.
These registers are directly referred to in assembly
language programs, but the compiler keeps track of them
in high-level language programs. In some microproces-
sors, these general registers are actually in memory, rather
than in the processor device, at a position identified by a
register-pointer register in the processor.
Memory. Used to store programs and data for im-
mediate access by the processor, primary memory is most
often read/write RAM with access times compatible with
the processor. Primary memory may also contain some
ROM for tied down programs or data that do not change.
While ROM information is available after power up,
many types of RAM must be reloaded following power
up.
For economic reasons, computer systems generally
have secondary memory devices which are slower but
much less costly per bit of storage. These devices may be
further classified as direct access, such as disk, or sequen-
tial access, such as tape. Secondary memory is always ac-
cessed through 1/0 drivers in the operating system. In
many cases, user programs do not have to be aware of
secondary memory.
Program. For portability and ease of maintenance,
most user programs and operating systems today are writ-
ten in a high-level language. Some parts of an operating
system-generally less than 10 percent of the code-may
still have to be written in assembly language. In the past,
operating systems were usually written entirely in assem-
bly language to minimize overhead.
Large programs written today, including operating sys-
tems, are usually designed in a modular hierarchical
fashion consisting of one or more structures of nested
73
subroutine calls as shown in Figure 8.* Such a nested
structure makes considerable use of the subroutine stack-
ing capability of the processor.
Data. Program languages also provide the means for
defining and allocating data structures and referencing
them symbolically in a program. There are primitive data
types, such as "character" and "integer," and structured
data types which are a prescribed collection of primitive
types. For example, an array-a structured type-may be
used to allocate a stack.
Most high-level languages provide the means for local-
izing data structure references to a single function or set
of functions. Such hiding of data structures is important
for enforcing at compile time any unwanted program in-
teractions. Hiding of data structures can be provided in a
compiler by limiting the scope of variable names-that is,
the portion of the code over which the name is defined.
For example, the symbolic name of a variable declared
local to a single function would stand only for that
variable within the body of the function. Use of the name no effect on each other-unless they interact by mistake
external to the function would either reference a different or by design. A single process is sequential and deter-
variable or be flagged as an error by the compiler.
Processes
The concept of a process, or task, is crucial to
understanding an operating system. The basic multipro-
gramming unit in a computer, a process is defined as the
set of states of a program in execution.
'In this article, the terms "module," "subroutine," "function," and
"procedure" all mean the same thing: a body of code with one entry point
that can be called and that returns upon completion of execution. It may
receive input parameters and return a result.
Figure 8. Modular hierarchical program structure.
When a new job enters the system, a process is created
by allocating memory to that job for program and data.
This block of memory can be thought of as the process
since it defines the current state of the process. As the pro-
gram executes and writes data, the state of the process
changes. When the program is interrupted, the state of
the process is temporarily fixed. When the program com-
pletes, the process is destroyed.
One's first impression may be that there is little dif-
ference between a job and a process. However, they are
not the same since a job may result in the creation of
several processes. For example, the initial job process
may spawn a second 1/0 process to write a file. This 1/0
process may execute on the same processor or on another
I/O processor. Another exarmple of a job creating several
processes would be a job consisting of several parts that
can be run in parallel. Each of these parts could be as-
signed to separate concurreni processes.
Concurrency. Processes can be run concurrently with
ministic. That is, its operations are executed in sequence
one at a time, and its outputs and ending state are always
predicable from its inputs and initial state.
Process images. The process image is that portion of
writable memory belonging to a process and defining its
state. The process image changes with the execution of a
program associated with the process. Process images, or
the head cells for them, are also called "process descrip-
tors" or "process control blocks." For all practical pur-
poses, the terms "process" and "process image" are in-
terchangeable.
A process image contains items such as process iden-
tifier, current state, active work area, local save area, and
system save area. It contains the local variables written as
the process executes as well as the variables that must be
saved intact when the process is interrupted or asks to be
interrupted by calling an operating system function. The
program associated with the process may be a single func-
tion, but more likely it is a nested structure of functions.
In the latter case, the process image must contain the
string of return addresses and local variables of each par-
tially executed function. In stack machines, these save
areas are on a stack which must be contained within the
process image. In any case, a process image can be quite
large.
Reentrant programs. If the program associated with a
process is reentrant, it need not be a part of the process im-
age. A reentrant program does not modify itself or write
global variables outside of the process image. Thus, a
single copy of a reentrant program in memory may sup-
port several identical processes, each in a different state of
execution. In fact, this program can be stored in ROM
since it does not change. Many operating system I/O pro-
cesses are implemented in this manner-that is, they are
supported by a single reentrant program copy.
Some of the problems of associating a nonreentrant
program with a process are worth mentioning. For exam-
ple, a program that modifies itself must be contained in its
COMPUTER
associated process image, and a program that writes
global variables can be associated with only one process at
a time.
Process states. The contents of the process image
define the precise state of the process at any time. Further-
more, a few high-level states common to all processes can
be defined. For example, a "running" process is one that
is actually executing on the processor. In a uniprocessor
system, only one process can be in the "running" state. A
"waiting" process is one that is waiting for an event such
as the completion of an 1/0 process or the expiration of a
certain period of time. A "ready" process is one that is
ready to be selected by the operating system to enter the
"running" state. A process is "dormant" before it is
created and after it is destroyed. Figure 9 shows these four
possible process states and the transitions between them.
Such states can be implemented in an operating system
in numerous ways. One way would be to define a linked-
list head cell for each state defined and then to link the
process image to the appropriate list for each process in
that particular state.
porary, or consumable, resources such as messages and
signals. Figure 10 illustrates the competing and non-
competing relationships between two processes.
Deadlock. Known more descriptively as a "deadly em-
brace," deadlock is a situation in which two or more pro-
cesses wait indefinitely for resources that are held by each
other and, thus, never available. Such a situation is pic-
torially represented in Figure 11. Deadlocks are a
possibility in any system where processes wait for
resources. However, they can and should be prevented
from existing indefinitely in any reliable system.
A number of deadlock avoidance schemes have been
proposed, and some have been implemented. First, let us
consider schemes pertaining to permanent resources that
are seized and released by competitive processes. Dead-

Process communication
As mentioned above, processes can execute concur-
rently until they need to interact. Planned and controlled
interaction is referred to as "process communication" or
"process synchronization." Process communication
must take place through shared or global variables exter-
nal to each process image.

Readers/writers. Improper reading and writing of

shared variables is the classic cause of difficult-to-find
operating system bugs. The basic problem is that two pro-
cesses, executing concurrently, may interleave read and
write operations in such a way that improper decisions are
made and the shared variables are left in an improper Figure 9. Possible process states and transitions.
state. This kind of bug is insidious, for it may only show
up infrequently-and then with symptoms that rarely or
never repeat since they depend on a particular concurren-
cy relationship.
Since processes that are only readers of shared variables
cannot cause this problem by themselves, several read-
only processes may execute concurrently with no prob-
lems at all. However, to write correctly, a writing process
must have a clever rule worked out with other processes or
else ensure that the shared variables are not being accessed
by any other process while the variables are being exam-
ined and modified.

Cooperation. Cooperating processes must communi-

cate to synchronize or limit their concurrency. The
relationship between two cooperating processes regard-
ing a resource falls into one of two fundamental
categories. They are either competitors or producers/
consumers. Since process communication takes place
through shared memory, competitors access this memory
to seize and release permanent, or reusable, resources.
Producers/consumers access this memory to pass tem- Figure 10. Competing and noncompeting relationships.

June 1981 75

Figure 11. Deadlock situation.
locks can be avoided by having processes seize all
resources at one time-that is, by not allowing processes
to wait for a resource while holding other resources.
Another scheme requires processes to seize resources in a
particular order to prevent the circular waiting that is
characteristic of deadlock. An even more complex
scheme requires processes to declare in advance the max-
imum resources possibly needed.
Most of these avoidance schemes, however, are too
restrictive or too time-consuming. The simplest technique
is not to wait indefinitely for a resource. But this means
that when a process times out, it must be aborted from the
system and its resources released. Whether or not this is
perfectly acceptable depends on the frequency of occur-
rence and the importance of the process. Most real-time
systems prevent deadlocks in this manner because their
processes cannot afford to wait indefinitely for resources.
A program bug can cause a deadlock even in
situations where deadlocks theoretically
cannot occur.
Finally, let us consider temporary resources, such as
messages, that are produced by one process and con-
sumed by another. Any number of producers and con-
sumers cannot be deadlocked with respect to a single
message buffer as long as a consumer is willing to remove
anything in a nonempty buffer. However, if two or more
processes are connected in a circle by two or more buffers,
and if each process is willing to wait for either a message or
an acknowledgment, a deadlock may occur. In fact, a
deadlock may even occur between a single producer and a
single consumer if the former is waiting for an acknowl-
edgment and the latter for a message. A simple deadlock
solution for temporary resources is not to wait indefinitely. reason, most operating systems provide other process
An important point to remember is that a program bug
can cause a deadlock even in situations where deadlocks
theoretically cannot occur. An ultimate timeout can be a
simple defensive check on the correctness of the system as
well as a way to prevent indefinite deadlocks.
Mutual exclusion. A sufficient condition for proper er process signals an event, all processes waiting on that
process communication is the exclusion of mutual acces- event are placed on the ready queue. Other variations are
sing of shared variables in time. The sections of a program also possible. One potential problem with events is that a
that access shared variables are referred to as "critical
regions. " If means are introduced to keep processes from
executing concurrently within their associated critical
regions, the requirement for mutual exclusion will be met
and time-dependent errors will not occur. Standard tech-
niques for providing such synchronization are becoming
well-known and essential to modern operating systems.
Synchronization. The simplest synchronization tech-
nique in a uniprocessor system is for a program to block
interrupts before entering a critical region and restore
them after exiting. This ensures that the critical region is
executed as an indivisible block. In more complex sys-
tems, the following techniques are used.
Test and set. A solution suitable for a multiprocessor
system is to use processors with the ability to test and set a
flag in a single instruction. This technique also works in a
uniprocessor system since it reduces the critical region
associated with the shared flag variable to a single indivisi-
ble instruction.
Using these machine-level techniques, higher-level
sychronization primitives can be built as operating system
functions to be called by cooperating processes. These
higher-level primitives must be indivisible. Generally,
they include a process waiting queue that saves processor
time by preventing looping-called "busy waiting" or
"spin lock"-when a process tries to enter a critical
region.
Semaphore. A standard synchronization primitive, the
semaphore consists of a counter, a process waiting queue,
and two functions, P and V. Initially, the counter equals
the number of resources, and the waiting queue is empty.
The P function decrements the counter by one. If the
result is less than zero, the process is placed on the waiting
queue (effectively interrupted); otherwise, the process
continues. The V function increments the counter by one.
If the result is greater than zero, the process continues;
otherwise, one of the waiting processes is placed on the
ready queue and the process continues. When negative,
the counter identifies the number of waiting processes.
When nonnegative, the counter identifies the number of
resources left. Semaphores with an initial value of one are
sometimes called "binary semaphores" since they act as
lock bits, allowing only one process at a time within an
associated critical region.
Although simple, semaphores are known to be suffi-
cient solutions to synchronization problems for perma-
nent resource competitors and temporary resource pro-
ducers/consumers. However, semaphores are often very
inconvenient because they are too primitive. For this
communication mechanisms. Two examples are events
and messages.
Events. Event primitives are typically provided by two
functions, "wait" and "signal." A process can wait on an
event or a combination of events to be true. When anoth-
COMPUTER
process has the possibility of waiting on an event that would simplify the problems of program validation and
either never becomes true or was signaled earlier. A slight maintenance. If a data structure changed, it would be
variation of waiting on an event, used especially in real- clear which functions were affected, and the addition of a
time systems, is waiting on a timing queue administered new process or monitor would not require the revalida-
by the operating system for a specified time period to tion of unchanged components.
elapse.
Monitor images. A monitor image is the portion of
Messages. Messages provide an even more flexible and writable memory associated with the monitor program
direct method of process-to-process communication, and defining the current state of the monitor. A monitor
especially for producer/consumer relationships. Typical image represents either permanent or temporary re-
primitives are the functions "send" and "receive" which sources which are the elements of process interaction. In
allow a string of characters to be passed between pro- the absence of process activity, process images and
cesses. Implementation variations are numerous. For ex- monitor images differ significantly. In this idle state, pro-
ample, send may or may not wait for an acknowledgment. cess images are of no importance and may vanish.
Receive usually waits if no message has been sent. However, monitor images-at least those representing
Some systems also provide other very efficient ways of permanent resources-must remain and resume a
communicating with certain operating system processes. nonassigned state.
These are sometimes called "demons" or "phantoms" Monitor functions are reentrant but contain nonreen-
since they interact frequently-and often mysteriously- trant sections-i.e., critical regions-that must not be ex-
with many user processes. ecuted concurrently by more than one process. Indeed,
monitor functions must be designed to protect against
this. Monitor functions need not be considered as part of
the monitor image. In fact, if two different monitor
Monitors variables are accessed in the same way, a single copy of a
program may be shared between the two monitors.
If the evolution of synchronization techniques has an When a monitor function is called but is blocked from
acme, the concept of a monitor may very well be it. A handling the request immediately, it may take several ac-
monitor is a shared data structure and a set of functions tions. It may immediately return a blocked indication, it
that access the data structure to control the synchroniza- may loop or busy wait until the request can be handled, or
tion of concurrent processes. This very unspecific defini- it may place the process on a waiting queue for the re-
tion includes semaphores, events, and messages as specif- source requested. In the latter case, the waiting queue
ic implementations. The notion of a monitor is not more must be a part of the monitor data structure. In real-time
powerful than these other techniques-just more general. systems, it is sometimes best to return a blocked indica-
While a process is a useful abstraction for multiprogram- tion and let the process decide whether to try again later or
ming, a monitor is a useful abstraction for process com- give up.
munication.
To assure the correctness of a program, it is useful to Kernel. The kernel, or nucleus, of an operating system
associate data structures with the operations performed contains a few special processes to handle initialization
on them. A monitor provides a body in which to associate and interrupts and a basic monitor to support the concept
shared data structures with their critical regions. By so do-
ing, the data structures are no longer shared or global, but
local or hidden within the body of a monitor. In addition,
process functions no longer contain critical regions. In-
stead, the critical regions are centralized and protected
within the monitor functions. The restricted access to
shared data structures provided by a monitor is even more
attractive if it can be checked by a compiler. Many high-
level languages today provide the means for controlling
the scope of variable names.
Monitors provide support for processes to form a
multiprogramming system. While a process is active in the
sense that it performs a job, a monitor is passive in the
sense that it only executes when called by a process. A
monitor is necessary only when two or more processes
communicate to ensure that they communicate properly.
Figure 12 is a representation of two processes com-
municating through shared data hidden by a monitor.
Pushing the monitor concept to its logical limit suggests
that systems should be designed as collections of pro-%
cesses and monitors only. In this case, every data struc-
ture would be local to either a process or monitor. This
decomposition would be valuable in large systems since it Figure 12. Monitor representation.
June 1981 77
 of a process. The basic monitor includes functions to allow new inputs to cause interrupts are said to be
switch environments between processes and to "create"- interrupt-driven. The interrupt-driven method provides
sometimes called "spawn" or fork"-new processes. The immediate attention for important inputs at the expense
kernel is also one part of an operating system that executes of delaying current work. However, most systems poll or
in the privileged state. scan for new inputs because it is less expensive and allows
Besides the kernel, an operating system consists of better control of excessive inputs.
many monitors and a few processes. The processes in- If there are more inputs available than the system can
clude several kinds of I/O processes that are activated as handle, the load scheduler must perform the important
needed and at least one active process to look for new jobs function of limiting the inputs accepted to the maximum
and create user processes for them. All monitors are part number that can be handled concurrently. This overload
of the operating system and form the bulk of the system. control is important because system throughput can ac-
They are used to manage the resources of the system. For tually decrease if too many inputs enter the system at
example, monitors transmit messages between processes, once. Nevertheless, many operating systems-including
control competing processes, enforce access rights, and ones widely used today-behave poorly when given too
communicate with I/O processes. many jobs because they lack adequate overload controls.
When inputs are limited by the load scheduler, the policy
Process creation. In some systems when processes are for deciding which inputs are accepted is an important
created, they exist as unrelated units, independent of each design consideration that depends on the system applica-
other. In other systems, the order of creation is remem- tion and other factors.
bered and a parent/child relationship is maintained be-
tween one process and the new process it creates. Both ap- Process scheduling. The process scheduler, or dis-
proaches have advantages and disadvantages. Typically, patcher, performs its function each time the running pro-
a "child" process is limited to using only those resources cess is blocked or preempted. Its purpose is to select the
owned by its "parent" and is destroyed if its "parent" is next running process from the ready queue. The process
destroyed. scheduler resides in the kernel and can be considered a
In most general-purpose systems, when a process is monitor for the ready queue. Probably the most frequent-
destroyed, its process image is returned to a pool of ly executed program in the system, it should be fairly effi-
unallocated memory. However, in many dedicated or cient to minimize operating system overhead.
real-time systems, processes are never destroyed. Instead, Process scheduling can be either preemptive or non-
they are created at compile time or initialization time and preemptive. In nonpreemptive systems, processes execute
run forever, even at times when there is no work to do. until they are blocked voluntarily by a monitor call. Ob-
viously, some jobs can monopolize the processor in such a
system. In preemptive systems, each ready process is
given, in turn, a time slice for execution. At the end of a
Management time slice, the running process is interrupted, placed at the
end of the ready queue, and the next process is given con-
Processor management. Processor management is con- trol. This cycle is repeated endlessly.
cerned with scheduling work to be done on a physical pro- crease the operating system overhead,Preemption
but
can in-
it gives all pro-
cessor. It is a term describing the managing of the pro- cesses
a more equal share of the processor. Therefore,
cessor as a shared resource among both external users and short
jobs
internal processes. As a result, processor management processor. are penalized by big jobs monopolizing the
not
consists of two basic kinds of scheduling: a long-term ex-
ternal load scheduling and a short-term internal process
scheduling. Scheduling policies. Scheduling policies are used in
both load scheduling and process scheduling. A load
scheduling policy is a rule for selecting the next input; a
Preemption can increase operating system process scheduling policy is a rule for selecting the next
overhead, but it gives all processes a more process to run. In a particular operating system, these two
equal share of the processor. policies may not be the same.
A good policy should be fair-giving preference to high
priority jobs, yet preventing "starvation" of low priority
Load scheduling. In a batch processing system, the jobs-and maximize system throughput. Since "fair"
load scheduler is usually called the job scheduler. In a and "priority" are subjective terms, many different
timesharing system, it may be called the command inter- scheduling policies are used in systems today. Only a few
preter or shell. In a telephone switching system, it is re- of the more common policies will be mentioned here.
ferred to as the telephone line scanner. Whatever its "First-come-first-served" is a simple policy for load
name, the load scheduler is a continuously active scheduling. However, in real-time systems, "last-come-
operating system process responsible for choosing which first-served" is sometimes used to obtain the least stale in-
new inputs will enter the system. It creates a user process put and maximize the probability of it being processed
to handle each new input accepted. correctly. Other policies are based on externally assigned
There are two basic ways for the load scheduler to priorities or give I/O intensive jobs preference to keep the
discover new inputs-interrupt or polling. Systems that peripherals busy.
78 COMPUTER
 "Round robin" is a typical process scheduling policy. such as bank switching are used to identify which parts of
Multilevel round robin is used to give higher priority pro- the primary memory are currently accessible by the pro-
cesses more frequent control without starving lower cessor. In the second case, secondary memory is used to
priority ones. Policies based on priority can be static. store the information, parts of which are physically
whereby priority remains fixed, or dynamic, whereby transferred to and from primary memory as required.
priority is allowed to change. Numerous methods exist for controlling this information
A quickly evaluated policy is important for preemptive transfer between secondary and primary memory. The
process scheduing in order to minimize the interrupt level relationship among the processor and primary and sec-
overhead of each time slice. For this reason, round robin ondary memory is depicted in Figure 13.
is often used in preemptive systems. Long time slices also Operating systems differ in their needs for memory
reduce the overhead, but this tends to approach a first- management. In some small dedicated systems, especially
come-first-served nonpreemptive scheduling policy as the those using microprocessors, there is no memory manage-
time slice interval increases. Other policies that favor ment. All programs are resident in primary memory.
short jobs are shortest-job-first or smallest-remaining- There is no secondary memory containing "nonresident"
time, both of which require jobs to declare run-time programs, and the primary memory is directly accessible
estimates. by the processor as a linear contiguous address space.

Environment switching. There are several forms of en- Bank switching. If the size of primary memory exceeds
vironment, or context, switching in a computer system. the addressing range of the processor, the physical
When one function calls another, a return address and memory can be divided into blocks-called "banks" or
possibly other state variables must be saved to permit "pages"-and a bank select register or page map is used
return to the environment of the calling function. This is a to identify which blocks are immediately accessible by the
very simple form of environment switching supported by basic processor addressing capability. In variations of this
subroutine calling instructions, compiler conventions, or basic idea, instruction fetches are mapped differently
other methods. than data fetches. An example of a bank switching
A more significant form of environment switching oc- scheme is shown in Figure 14.
curs when a process is interrupted by hardware or is
placed on a monitor waiting queue. In these cases, a pro-
cess switch must occur. The entire process image must be
saved intact so that the process may resume execution
later. This also requires saving various important pro-
cessor register contents before passing control of the pro-
cessor to another process.
Since process switching generally occurs quite often in
an operating system, it should be implemented as effi-
ciently as possible. This means that as little data as possi-
ble should be moved in memory. In stack-oriented
machines, this may be accomplished by changing the
stack-pointer register instead of moving the stacks
themselves.
The user should be unaware of process switches to
preserve the illusion that he has sole use of the processor,
albeit a slower one. Voluntary process switches should ap-
pear to the user as a monitor function call that returns at a Figure 13. Primary/secondary memory relationship.
later time. This is important, since it allows application
programs to be structured in a modular hierarchical
fashion.
Memory management. Memory management is con-
cerned with administering the use of primary memory,
which is where program instructions and associated data
must be stored for direct access by the processor. Memory
management by the operating system is needed for one or
both of the following reasons.
* The size of primary memory exceeds the addressing
range of the processor.
* The primary memory is not large enough to store all
programs and data needed.
In both cases, the processor is not able to directly ad-
dress all of the existing programs and data without help
from the operating system. In the first case, techniques Figure 14. Example bank switching scheme.

June 1981 79
 The combination of the basic address and the bank
number (or page map state) forms an enhanced address-
ing capability. Note that the entire enhanced address must
be saved in many environment switching situations to per-
mit the proper restoration of the old environment.
Bank switching is very similar to using secondary
memory, except that it is much faster since no physical
transfer of information from a slow peripheral device has
to take place. Many of the strategies are the same. For ex-
ample, in both cases, it is important to hide memory
management mechanisms from users so that they do not
have to be concerned about the details of the machine.
This can be done by having the operating system receive
control each time an unaccessible block is addressed by
the user. This is sometimes called a "page fault." The
operating system reconfigures the memory before return-
ing control to the user.
Allocation. The use of secondary memory to store pro-
grams and data is required largely for economic reasons.
The cost per bit of secondary memory can be several
orders of magnitude less than primary memory. Not
many systems need to or can afford to store all informa-
tion in primary memory. Therefore, most c,perating sys-
tems-from the earliest to the most modern ones-use
secondary memory.
Memory "allocation" refers to the rules for assigning
primary memory to jobs for execution. To review the
methods of allocation that have evolved, we begin with
the early systems. They allocated primary memory to only
one job at a time for the duration of its execution. The
next step was to divide the memory into several fixed par-
titions, each of which could be allocated to a job. After-
wards, several jobs could run concurrently, but there was a
lot ofwasted memory because job sizes did not match parti-
tion sizes. As a result, dynamic memory allocation was
developed to produce variable partitions that matched job
sizes. However, this resulted in fragmentation of un-
allocated memory since different sized jobs completed at
different times. The solution was to make programs
relocatable during execution. This required that address
Figure 15. Segmented addressing.
80
sensitive instructions in a program be based relative to a
relocation register. Unallocated memory fragments could
then be combined into a large usable area by relocating ex-
ecuting programs.
Swapping. Jobs do not have to remain continuously in
primary memory until they complete. A low priority job
can be "rolled out" to secondary memory to accom-
modate a high priority job and later be "rolled in" to
complete. Many small-scale timesharing systems use this
technique. Swapping is greatly aided by a relocatable en-
vironment since jobs do not have to be rolled in to exactly
the same memory space from which they were rolled out.
Overlays. All parts of a job do not have to be simulta-
neously in primary memory for the job to execute. Large
programs can be accommodated by allowing program
sections to overlay other sections that do not have to be in
memory at the same time. The disadvantage of overlays is
that the user generally has to specify the overlay structure
in advance. However, the notibn of swapping combined
with automatic overlays led to two important develop-
ments-segmentation and paging.
Segmentation. All programs consist of a number of
logical segments, such as data areas and program func-
tions. All segments do not have to be in primary memory
at one time and all do not have to be stored in contiguous
address locations for proper execution. Any word in a
program can be identified by a two-part segmented ad-
dress consisting of a segment number and a segment off-
set. A segment map converts the segmented address to a
physical address. If a program tries to access a segment
which is not in primary memory-an occurrence called a
"segment fault"-the operating system intervenes and
brings the segment in from secondary memory. The seg-
ment map is also updated. Figure 15 shows the conversion
from segmented address to physical address.
Segmentation has many advantages. Swapping and
overlaying are done automatically since only actively used
segments are kept in primary memory. Memory is not
wasted since variably sized segments accommodate pro-
gram divisions of any size. However, there is difficulty in
managing variably sized segments in secondary memory.
Furthermore, primary memory allocation is more com-
plicated with variably sized segments.
Paging. Paging is identical to segmentation except that
all segments are the same size. While this eliminates the
major disadvantages of segmentation, it is also slightly
more wasteful of memory since programs seldom break
up into an integral number of pages. One way to gain the
benefits of both segmentation and paging is to subdivide
each segment into pages and use a three-part address con-
sisting of a segment number, a page number, and an offset.
Virtual memory. The major advantage of paging or
segmentation is that it supports the notion of virtual
memory. With virtual memory, each process "thinks"
that it has all of its information in a very large primary
memory. The memory management required by the oper-
COMPUTER
ating system to provide this view is invisible to the user
and need not be considered when programs are written.
However, virtual memory or paging requires signifi-
cant memory management overhead. Each time a new
page is brought in, an old page must leave primary mem-
ory. If the old page was modified, it must first be written
back into secondary memory. The page replacement
policy is very important to the performance of the system.
Some policies used are "first-in-first-out" and "least-
recently-used. "
Furthermore, when primary memory becomes over-
committed, system performance can be seriously de-
graded by a phenomenon called "thrashing. " This occurs
when every page fault forces the replacement of a useful
page, perhaps belonging to another job. As a result,
operating system overhead increases severely since most
processor time is spent servicing page faults. To prevent
thrashing, each job requires some minimum number of
pages, sometimes referred to as the "working set," to ef-
ficiently utilize the processor. The number of pages in a
working set depends on the pattern of execution over a
period of time.
It is important to remember that virtual memory-as
well as any other memory management technique-has a
certain overhead associated with it and that problems can
occur if it is not implemented carefully. Furthermore,
memory management does not necessarily eliminate the
need for a large primary memory. In large systems, per-
formance may be unacceptable due to thrashing if the
primary memory is too small.
Future trends
Operating system techniques are becoming more ac-
ceptable today, even in small microprocessor systems
with dedicated applications. It is recognized now that all
computer systems perform certain common operating
system functions and that most systems must support
some form of concurrent process execution. As a result,
process communication is inevitable. Techniques that en-
sure proper synchronization can eliminate many of the
time-dependent program bugs that have occurred in
many operating systems.
Operating systems will continue to have a major effect
on processor designs. Single-chip microprocessors and
larger processors will become less clumsy for operating
systems to use. System performance will improve dramat-
ically as more operating system primitives are provided in
hardware or microcode. This will include support for pro-
cess synchronization, queue manipulation, environment
switching, process scheduling, and memory manage-
ment. The frequently executed sections of today's
operating system programs will be implemented in the
future by large microprograms. In addition, these fea-
tures will decrease the development cost and increase the
security and correctness of future operating systems.
Improved operating systems will, in turn, improve the
quality of application programs by requiring certain
structures and interfaces. With these restrictions and
proper operating system support, the quality of applica-
June 1981
tion programs will be less tied to the skill of programmers.
While the distributed processing capabilities provided
by computer networks are presently generating a lot of in-
terest, they are also creating a number of new operating
system problems. With no shared memory, processes in
two different computers must communicate via messages
over a data link. Reliable communication is provided by
several layers of protocol to handle various kinds of errors.
The frequently executed sections of today's
operating system programs will be
implemented in the future by
large microprograms.
Local networks favor simple protocols and possible
error-handling by the application (rather than by the op-
erating system) due to the high reliability of the local net-
work. Geographically dispersed networks are less reliable
and require more complex protocols to preserve message
order and to prevent message loss, duplication, or mutila-
tion. Long distances also introduce problems associated
with significant time delays and limited transfer rates. All
of these problems have yet to be solved completely.
Computer networks usually imply distributed data
bases. This means that there are multiple copies of por-
tions of a data base, each copy at a different site.
This tutorial is a decision-making aid designed to help
those responsible for purchasing an ECG computer sys-
temi. It consists of pertinent articles from a variety of jour-
nals and a substantial amount of new material. In 19 ar-
ticles, the nature of computerized ECG systems, the avail-
able analytical programs, criteria for choosing a system,
economic considerations, system impact on staff and pa-
tient care, and the limitations of computer systems are
discussed. 227 pp. Order #325
Tutorial-Computer Systems for the Processing
of Diagnostic Electrocardiograms
Edited by T. Allan Pryor, Erica Drazen, and
Michael Laks
November 1980
Members-$18.75
Non-members-$25.00
Use order form on p. 136C.
 Although this is necessary to increase the availability of Anderson, D. A., "A Microprocessor Operating System for
Real-Time Applications," Proc. Compsac 78, Chicago, Nov.
important information, it introduces some new syn- 1978, pp. 104-109.*
chronization problems. With multiple copies of shared
memory, traditional synchronization techniques will puter, Atwood, J. W., "Concurrency in Operating Systems," Com-
Vol. 9, No. 10, Oct. 1976, pp. 18-26.
have to be augmented or replaced by new techniques to
maintain data integrity. Bierman, E., "Changing Technology in Switching System Soft-
ware," Proc. IEEE, Vol. 65, No. 9, Sept. 1977, pp. 1329-1335.
One proposal is to attach network-wide sequence
Brinch Hansen, P., Operating System Principles, Prentice-Hall,
numbers to data-base transactions to ensure that updates Englewood Cliffs, N.J., 1973.
are applied in the same order to multiple copies of a data
Dijkstra, E. W., "Hierarchical Ordering of Sequential Pro-
base. Limiting transactions to those that are repeatable- cesses," in Operating
run System Techniques, ed. by C. A. R. Hoare
that is, that have the same effect if accidentally and R. H. Perrott, Academic Press, New York, 1972.
twice-has also been proposed. Attaching a version Habermann, A. N., Introduction to Operating System Design,
number to each copy of distributed data has also been Science Research Assoc., Chicago, 1976.
proposed for resolving conflicts. N "Monitors: An Operating System Structuring
Hoare, C. A. R.,
Concept," Comm. ACM, Vol. 17, No. 10, Oct. 1974, pp.
549-557.
Acknowledgments Hoare, C. A. R., and R. M. McKeag, "Store Management
Techniques," in Operating System Techniques, ed. by C. A. R.
The careful review of this tutorial by Professors A. V. Hoare and R. H. Perrott, Academic Press, New York, 1972.
Pohm and T. A. Smay, both of Iowa State University, is Holt, R. C. "Some Deadlock Properties of Computer
gratefully acknowledged and appreciated. The sugges- Systems," Computing Surveys, Vol. 4, No. 3, Sept. 1972, pp.
tions given for improvement were very valuable. 179-196.
Katzan, H., Jr., Operating Systems, Van Nostrand Reinhold,
New York, 1973.
Selected bibliography Madnick, S. E., - and J. J. Donovan, Operating Systems,
McGraw-Hill, New York, 1974.
Alsberg, P. A., et al., Synchronization and Deadlock, CAC Patterson, D. A., and C. H. Sequin, "Design Considerations for
Document No. 185, University of Illinois, Mar. 1976. Single-Chip Computers of the Future," IEEE Trans. Com-
puters, Vol. C-29, No. 2, Feb. 1980, pp. 108-116.
Rauscher, T. G., and P. M. Adams, "Microprogramming: A
Tutorial and Survey of Recent Developments," IEEE Trans.
Computers, Vol. C-29, No. 1, Jan. 1978, pp. 2-20.
Ritchie, D. M., and K. Thompson, "The Unix Time-Sharing
K, System," Bell System Technical J., Vol. 57, No. 6, Part 2, July
/ 21st Annual
1978, pp. 1905-1929.
Symposium on Foundations
of Computer Science
Satyanarayanan, M., "Commercial Multiprocessing Systems,"
Computer, Vol. 13, No. 5, May 1980, pp. 75-96.
Thompson, K., "Unix Implementation," BellSystem Technical
J., Vol. 57, No. 6, Part 2, July 1978, pp. 1931-1946.
Tsichritzis, D. C., and P. A. Bernstein, Operating Systems,
Academic Press, New York, 1974.

These proceedings are available from the Order Desk, IEEE Computer
Society, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720.

- I
This symposium, sponsored by the IEEE Computer
Society's Technical Committee on the Math;-
matical Foundations of Computing, was formerly
the Annual Symposium on Switching and
Automata Theory. The 47 papers published were
selected from 146 submitted abstracts. 421 pp.
Order #323
Proceedings-21st Annual Symposium on
Foundations of Computer Science
October 13.15, 1980
Members-$22.50
I He is a member of the IEEE.
Non-members-$30.00
Use order form on p.
Douglas A. Anderson is a supervisor of a
software development group at Bell Labo-
ratories in Naperville, Illinois. His inter-
ests include real-time operating systems,
programming methodologies, fault-toler-
ant computing, and self-checking designs.
Since joining Bell Laboratories in 1965, he
has helped develop a number of electronic
A~~switching systems, including No. 2 ESS,
No. 3 ESS, RSS, and currently No. 5 ESS.
Anderson received a BS in 1965 from the University of Col-
orado, an MS in 1966 from Purdue University, and a PhD in
1971 from the University of Illinois, all in electrical engineering.
COMPUTER
136C.