The Nucleus of A Multiprogramming System: Operating Systems
The Nucleus of A Multiprogramming System: Operating Systems
The Nucleus of A Multiprogramming System: Operating Systems
RANDELL, Editor
2. System Nucleus
This p a p e r describes the philosophy and structure of a multi- Our basic attitude during the designing was to make no
programming system that can be extended with a hierarchy of assumptions about the particular strategy needed to
operating systems to suit diverse requirements of program optimize a given type of installation, but to concentrate on
scheduling and resource allocation. The system nucleus sim- the fundamental aspects of the control of an environment
ulates an environment in which program execution and input/ consisting of parallel, cooperating processes.
output are handled uniformly as parallel, cooperating proc- Our first task was to assign a precise meaning to the
esses. A fundamental set of primitives allows the dynamic process concept, i.e. to introduce an unambiguous ter-
creation and control of a hierarchy of processes as well as the minology defining what a process is and how it is imple-
communication among them. mented on the actual computer.
KEY WORDS AND PHRASES: multiprogramming,operating systems, paralle I The next step was to select primitives for the synchro-
processes, processconcept, processcommunication,message buffering, process nization and transfer of information among parallel
hierarchy, processcreation, process removal processes.
CR CATEGORIES: 4.30, 4.31, 4.32, 4.41 Our final decisions concerned the rules for the dynamic
creation, control, and removal of processes.
The purpose of the system nucleus is to implement these
l, Introduction fundamental concepts: simulation of processes; communi-
The multiprogramming system developed by Regnecen- cation among processes; creation, control, and removal of
tralen for the RC 4000 computer is a general tool for the processes.
design of operating systems. I t allows the dynamic creation
of a hierarchy of processes in which diverse strategies of 3. Processes
program scheduling and resource allocation can be imple- We distinguish between internal and external processes,
mented. roughly corresponding to program execution and i n p u t /
For the designer of advanced information systems, a. output.
vital requirement of any operating system is t h a t it allow More precisely, an internal process is the execution of one
him to change the mode of operation it controls; otherwise. or more interruptable programs in a given storage area. An
his freedom of design can be seriously limited. Unfortu- internal process is identified b y a unique process name.
nately, this is precisely what present operating systems do, Thus other processes need not be aware of the actual loca-
not allow. Most of them are based exclusively on a single, tion of an internal process in the store, but can refer to it by
mode of operation, such as batch processing, priority name.
scheduling, real-time scheduling, or conversational access. A sharp distinction is made between the concepts pro-
When the need arises, the user often finds it hopeless to, gram and internal process. A program is a collection of
modify an operating system that has made rigid assump- instructions describing a computational process, whereas
tions in its basic design about a specific mode of operation. an internal process is the execution of these instructions in
The alternative--to replace the original operating system a given storage area.
with a new one--is in most computers a serious, if not im- In connection with i n p u t / o u t p u t , the system distin-
possible, matter because the rest of the software is inti- guishes between peripheral devices, documents, and ex-
mately bound to the conventions required by the origina~ ternal processes.
system. A peripheral device is an item of hardware connected to
This unfortunate situation indicates that the mairr. the data channel and identified by a device number. A
problem in the design of a multiprogiramming system is not. document is a collection of data stored on a physical
to define functions t h a t satisfy specJ.fie operating needs, but~ medium, such as a deck of punched cards, a printer form, a
rather to supply a system lmeleus that can be extended: reel of magnetic tape, or a file on the backing store.
with new operating systems i~ an orderly manner. This is: An external process is the i n p u t / o u t p u t of a given docu-
the primary objective of the R C 4000 system. ment identified by a unique process name. This concept
B
F G 6200
H
The communication primitives are executed in the un-
interruptable mode within the system nucleus. The execu-
tion times of these set a limit to the system's response to
Fro. 1 real-time events:
msec
Initially all system resources are owned by the basic send message 0.6
operating system S. For details of process control and re- wait answer 0.4
source allocation, the reader should consult the manual of wait message 0.4
the system [1]. send answer 0.6
We emphasize that the only function of the family tree
is to define the rules of process control and resource alloca- An analysis shows t h a t the 2 milliseconds required by a
tion. Computing time is shared by round-robin scheduling complete conversation (the sum of the four primitives) are
among active processes regardless of their position in the used as follows:
hierarchy, and each process can communicate with all percent
other processes. validity checking 25
Regarding the future development of operating systems, process activation 45
the most important characteristics of the system can now message buffering 30
be seen as the following.
This distribution is so even that one cannot hope to in-
1. New operating systems can be implemented as other
crease the speed of the system by introducing additional,
programs without modification of the system nucleus. In
ad hoc machine instructions. The only realistic solution is
this connection, we should mention that the ALGOL and
to make the hardware faster.
FORTRAN languages for the RC 4000 contain facilities for
T h e primitives for creation, start, stop, and removal of
calling the nucleus and initiating parallel processes. Thus
processes are implemented in an anonymous internal
it is possible to write operating systems I in high-level lan-
process within the system nucleus to avoid intolerably long
guages.
periods in the uninterruptable mode. Typical execution
2. Operating systems can be replaced dynamically, thus
times for these are:
enabling an installation to switch among various modes of
operation; several operating systems can, in fact, be active msec
simultaneously. create process 3
3. Standard programs and user programs can be start process 26
executed under different operating systems without modi- stop process 4
fication, provided there is common agreement on the possi- remove process 30
ble communication between parents and children. (Continued on page 250)
Hansen--cont'd from page 241 Acknowledgments. The design philosophy was de-
veloped by J~rn 5ensen, S~ren Lauesen, and the author.
The excessive times for the start and removal of an internal Leif Svalgaard participated in the implementation and
process are due to the peculiar storage protection system of testing of the final product.
the RC 4000, which requires the setting of a protection key Regarding fundamentals, we have benefited greatly from
in every storage word of a process. Dijkstra's analysis of cooperating sequential processes.
RECEIVED JULY, 1969; REVISED JANUARY, 1970
9. Conclusion
REFERENCES
Ideas similar to those described here have been sug- 1. RC $000 Soflware: Multiprogramming System. P. Brinch Hansen
gested by others [4-6]. We have presented our system (Ed.). A/S Regnecentralen, Copenhagen, 1969.
because we feel that, taken as a whole, it represents a sys- 2. RC 4000 Computer: Reference Manual. P. Brinch Hansen (Ed.).
tematic and practical approach to the design of replaceable A/S Regnecentralen, Copenhagen, 1969.
operating systems. As an inspiration to other designers, it 3. DIJKSTRA, E. W. Cooperating Sequential Processes. Math.
Dep., Technological U., Eindhoven, Sept. 1965.
is perhaps most important that it illustrates a sequence of 4. I'IARRISON, M. C., A N D SCHWARTZ, J. W. SHARER, a time
design steps leading to a general system nucleus, namely, sharing system for the CDC 6600. Comm. ACM 10, (Oct. 1967),
the definition of the process concept, the communication 659.
scheme, and the dynamic creation and structuring of 5. I'IUXTABLE, D. H. R., AND WARWICK, M. T. Dynamic super-
processes. visors--their design and construction. Proc. ACM Syrup. on
Operating System Principles, Gatlinburg, Tenn., Oct. 1--4,
We realize, of course, that a final evaluation of the sys- 1967.
tem can only be made after it has been used to design a 6. WICHMANN, B. A. A modular operating system. Proc. I F I P
number of operating systems. Cong. 1968, North Holland Pub. Co., Amsterdam, p. C48.