Operating system principles

• Authors: Per Brinch Hansen
• Venue: Operating system principles
• Year: 1973

From the PrefaceMAIN GOALThis book tries to give students of computer science andprofessional programmers a general understanding of operatingsystems--the programs that enable people to share computersefficiently.To make the sharing of a computer tolerable, an operating systemmust enforce certain rules of behavior on all its users. One wouldtherefore expect the designers of operating systems to do theirutmost to make them as simple, efficient, and reliable aspossible.A number of operating systems made in the early 1960's had thesecharacteristics; but in the late 1960's designers were oftenoverambitious and built enormous systems with poor performance.I see no inherent reason why operating systems should not reachthe quality of program construction found in present compilers;this will require an understanding of the principles common to alloperating systems and a consistent use of safe methods of designinglarge programs. It is my hope that this book will give you a startin this direction.I assume that you are familiar with the basic structure ofcomputers and programming languages and have some experience inwriting and testing non-trivial programs. In a few cases aknowledge of elementary calculus and probability theory is alsoneeded.THEMESThe main theme of the book is that operating systems are notradically different from other programs. The difficultiesencountered in the design of efficient, reliable operating systemsare the same as those one encounters in the design of other largeprograms, such as compilers or payroll programs.The historical importance of operating systems is that they ledto the discovery of new principles of resource sharing,multiprogramming, and program construction. Theseprinciples have a general validity beyond operating systems, and Ithink that they should be taught as part of a core of computerscience courses, following courses on programming languages,data structures, and computer structures.The purpose of an operating system is to share computationalresources among competing users. To do this efficiently adesigner must respect the technological limitations of theseresources.Present computers consist of a small number of components(processors, store modules, and peripherals) which operate strictlysequentially. It is possible to multiplex a single processor and asmall internal store (supported by a large backing store) amongseveral computations to create the illusion that they are executedconcurrently and have access to a large, homogeneous store. Butthese abstractions are not supported by the underlying technology,and if they are carried too far, the result is a total collapse ofcomputational service known as thrashing.One of the difficulties of operating systems is the highlyunpredictable nature of the demands made upon them. Independentusers submit jobs with varying resource requirements at irregularintervals. An operating system is expected to schedule thisunpredictable mixture of jobs in such a manner that the resourcesare utilized efficiently and the users can expect response withinreasonably predictable times!The only way to satisfy these expectations is probably to putrestrictions on the characteristics of jobs so the designer cantake advantage of the expected usage of resources. This iscertainly the main reason for the success of small, specializedoperating systems. It also gives a plausible explanation of thefailure of recent "general-purpose" operating systems which try tohandle a much greater variety of jobs (in some cases for a varietyof machine configurations as well).Although most components of present computers are sequential innature, they can work simultaneously to some extent. Thisinfluences the design of operating systems so much that the subjectcan best be described as the management of sharedmultiprogramming systems.The main difficulty of multiprogramming is that concurrentactivities can interact in a time-dependent manner which makes itpractically impossible to locate programming errors by systematictesting. Perhaps, more than anything else, this explains thedifficulty of making operating systems reliable.If we wish to succeed in designing large, reliablemultiprogramming systems, we must use programming tools which areso well-structured that most time-dependent errors can be caught atcompile time. It seems hopeless to try to solve this problem atthe machine level of programming, nor can we expect to improve thesituation by means of so-called "implementation languages," whichretain the traditional "right" of systems programmers to manipulateaddresses freely.I use the programming language Pascal throughout the text todefine operating system concepts concisely by algorithms. Pascalcombines the clarity needed for teaching with the efficiencyrequired for design. It is easily understood by programmersfamiliar with Algol 60 or Fortran, but Pascal is a far more naturalprogramming tool than these languages, particularly with respect todata structuring. As we go along, I extend Pascal with awell-structured notation for multiprogramming.STRUCTUREThe book contains eight chapters:Chapter 1 is an overview of operating systems. It definesthe purpose of operating systems and outlines their historicaldevelopment from early batch processing to recent interactivesystems. It also points out the influence of technologicalconstraints on the services offered by operating systems.Chapter 2 on sequential processes discusses the role ofabstraction and structure in problem solving and the nature ofcomputations. It summarizes structuring principles of data andsequential programs and gives an example of hierarchal programconstruction.Chapter 3 on concurrent processes emphasizes the role ofreproducible behavior in program testing and compares variousmethods of process synchronization: simple and conditional criticalregions, semaphores, message buffers, and event queues. Itconcludes with an analysis of the prevention of deadlocks by ahierarchal ordering of process interactions.Chapters 2 and 3 present an abstract view of computationalprocesses and their representation in programming languages. Thefollowing Chapters, 4 to 6, discuss techniques of implementingprocesses on computers with limited resources. This problem ismainly technological, and it seems unrealistic to look for aunifying view of how different kinds of components are usedefficiently. I try to describe various techniques and point outunder which circumstances they are successful.Chapter 4 on processor management discusses theshort-term problems of scheduling concurrent processes on a limitednumber of processors at the lowest level of programming. It alsoexplains the implementation of synchronizing primitives andevaluates the influence of these abstractions on the real-timecharacteristics of a system.Chapter 5 on store management considers the short-termproblems of sharing an internal store of limited capacity amongconcurrent processes. It summarizes current store technology andexplains the influence of recursive procedures, concurrentprocesses, and dynamic relocation on store addressing. It ends withan analysis of placement algorithms and store multiplexing.Chapter 6 analyzes the performance of various medium-termscheduling algorithms. It uses elementary queuing theory toderive analytical results for the average response time to userrequests in a single processor system with these priority rules:first-come first-served, shortest job next, highest response rationext, and round robin. Foregound-background scheduling is discussedinformally.Chapter 7 is concerned with resource protection--theproblem of ensuring that physical resources and data are accessedby well-defined operations within computations authorized to usethem. This is a fundamental problem of program design which shouldhave been presented earlier in the book, if only I understood itbetter. It is handled inadequately in all present operatingsystems. As fragments of a solution I mention two of the moresystematic techniques used: the class concept in Simula 67 and thecapability concept.It is important that a designer of operating systems understandthe underlying common principles. But the danger of this divisionof the subject into separate chapters is that you may find itdifficult to see how they fit together into a working system and beunaware of the more subtle interactions between, say, processcommunication, store management, input/output, and preemptivescheduling.I have therefore tried to describe a complete operating systemin some detail in Chapter 8. It is a case study of the RC 4000multiprogramming system. It is by no means an ideal system, butit is the only one I know in detail, and is regarded as aconsistent, simple, and reliable design which illustrates theconcepts and implementation of concurrent processes.It should perhaps be explained why there are no chapters oninput/ output and filing systems. For a particular operatingsystem, considerations about how these tasks are handled are highlyrelevant. But in this book I have concentrated on the moreelementary aspects of these complicated tasks, namely processsynchronization, store management, scheduling, and resourceprotection.VOCABULARYIn each chapter many words are first used intuitively to giveyou a feeling for the subject. Later I return to these words andtry to give reasonably precise verbal definitions of their meaning.My use of a common word may not always agree completely with thevarious shades of meaning it has acquired elsewhere, but I hope tojustify the usefulness of the concept behind the word and show thatit is possible to describe operating systems in an informal butconsistent terminology.The most important terms are collected in a Vocabulary sectionat the end of the book.LITERATUREThis book is only one designer's view of operating systems. Iurge you to examine my viewpoints critically and compare them withother literature on the subject. As a guide to such a study I haveincluded an annotated selective bibliography at the end ofeach chapter.For the sake of completeness I have listed all referencesmentioned in the text at the end of the book.