3 Concurrent Processes

Before we can start a detailed study of operating systems, we need to introduce

some basic concepts and develop a few tools. This will be the purpose of the
present chapter.

3.1 PROGRAMS, PROCESSES AND PROCESSORS

We start by considering an operating system as a set of activities, each providing

one of the functions. such as scheduling or I/O handling, described in chapter 2.
Each activity consists of the execution 01 one or more programs. and will be
invoked whenever the corresponding function is to be provided. We use the word
process to describe an activity of this kind. (Other names in the literature are
task and computation.) A process may thus be thought of as a sequence of
actions. performed by executing a sequence of instructions (a program), whose
net result is the provision of some system function. We can extend the concept to
include the provision of user functions as well as system functions, so that the
execution of a user program is also called a process.
A process may involve the execution of more than one program: conversely; a
single program or routine may be involved in more than one process. For example,
a routine for adding an item to a list might be used by any process engaged in
queue manipulation. Hence the knowledge that a particular program is currentiy
being executed does not tell us much about what activity is being pursued or
what function is being implemented. It is largely for this reason that the concellt
of a process is more useful than that of a program when talking about operating
systems.
A process is able to proceed by virtue of an agent which executes the associated
program. This agent is known as a processor. We say that a processor runs a
process, or that a process runs on a processor. A processor is something which
executes instructions; depending 011 the nature of the instructions the processor
may be implemented in hardware alone, or in a combination of both hardware
and software. For example, a central processing unit (CPU) is a processor for
executing machine language instructions, while a CPU together with a BASIC
interpreter can form a processor for executing BASIC instructions. The
transformation, discussed in chapter 1, of a raw computer into a virtual machlrte
may in fact be regarded as the combination of the computer hardware and the
13
A. M. Lister, Fundamentals of Operating Systems
© Springer Science+Business Media New York 1984
14 Fundamentals of Operating Systems
operating system to provide a processor capable of running user processes (that is,
a processor capable of executing user instructions).
The program or programs associated with a process need not be implemented
as software. The action of a channel, for example, in performing a data transfer,
may be looked on as a process in which the associated program is wired into the
channel hardware. Viewed in this way the channel, or indeed any peripheral
device, is a processor which is capable of executing only a single process.
The concepts of process and processor can readily be used to interpret both
concurrency and nondeterminacy, which were two of the operating system
characteristics outlined in the last chapter.
Concurrency can be regarded as the activation of several processes (that is,
the execution of several programs) at the same time. Provided there are as many
processors as processes this presents no logical difficulty. If, as is more usual,
there are fewer processors than processes then apparent concurrency can be
obtained by switching processors from one process to another. If the switching
is done at suitably small intervals of time then the system will give the illusion
of concurrency when viewed on a longer time scale. Apparent concurrency is in
effect achieved by interleaving processes on a single processor.
It may be helpful at this point to draw an analogy with the activities of a
secretary in a general office. Each of the jl)bs a secretary has to perform, such as
typing letters, filing invoices, or taking dictation, can be likened to a process in
an operating system. The processor is the secretary herself, and the sequence of
instructions which defines each job is analogous to a program. If the office is busy
then the secretary may have to break off one job to do another, and in this
situation she would probably complain of 'doing several jobs at the same time'.
Of course she is only doing one job at once, but the frequent switching from one
activity to another gives an overall impression of concurrency. We may pursue
the analogy further by observing that before the secretary can change to another
activity she must make sufficient note of what she is currently doing in order to
pick up the thread again later. Similarly, a processor in a compu ting system must
record information about the process it is currently running before it can switch
to some other process. The precise nature of the information to be stored will
be discussed in the next chapter; for the moment we remark only that it must be
sufficient to enable the process to be resumed at some later time.
Carrying the analogy still further, we can introduce additional secretaries
(processors) into the office. True concurrency can now exist between the various
secretaries performing different tasks, though apparent concurrency may still
persist as each secretary switches from one task to another and back again. Only
when the number of secretaries is equal to the number of jobs to be done can
all the jobs be performed in a truly concurrent manner. The analogue of the
processor, such as an I/O device, which can perform only a single process, is the
junior secretary who is capable only of making the tea.
Bearing in mind the foregoing discussion, we define concurrent processing (or
parallel processing) to mean that if a snapshot is taken of the system as a whole
then several processes may be found somewhere between their starting points