The architecture of concurrent programs

• Authors: Per Brinch Hansen
• Venue: The architecture of concurrent programs
• Year: 1977

From the PrefaceCONCURRENT PROGRAMMINGThis book describes a method for writing concurrent computerprograms of high quality. It is written for professionalprogrammers and students who are faced with the complicated task ofbuilding reliable computer operating systems or real-time controlprograms.The motivations for mastering concurrent programming are botheconomic and intellectual. Concurrent programming makes it possibleto use a computer where many things need attention at the sametime--be they people at terminals or temperatures in an industrialplant. It is without doubt the most difficult form ofprogramming.This book presents a systematic way of developing concurrentprograms in a structured language called ConcurrentPascal--the first of its kind. The use of this language isillustrated by three non-trivial concurrent programs: a single-useroperating system, a job-stream system, and a real-time scheduler.All of these have been used successfully on a PDP 11/45 computer.The book includes the complete text of these three programs andexplains how they are structured, programmed, tested, anddescribed.In an earlier book, Operating System Principles[Prentice-Hall, 1973], I tried to establish a background forstudying existing operating systems in terms of basic concepts.This new text tells the other side of the story: how concurrentprograms can be constructed systematically from scratch. It alsoillustrates details of important design problems--the management ofinput/output, data files, and programs--which were deliberatelyomitted from the first book. So it is useful both as a practicalsupplement to operating system courses and also as a handbook onstructured concurrent programming for engineers.COMPILATION AND TESTINGA concurrent program consists of sequential processes that arecarried out simultaneously. The processes cooperate on common tasksby exchanging data through shared variables. The problem is thatunrestricted access to the shared variables can make the result ofa concurrent program dependant on the relative speeds of itsprocesses. This is obvious if you think of a car and a trainpassing through the same railroad crossing : it is the relativetiming of these "processes" that determines whether they willcollide.Unfortunately, the execution speed of a program will varysomewhat from one run to the next. It will be influenced by other(unrelated) programs running simultaneously and by operators:responding to requests. So you can never be quite sure what anincorrect, concurrent program is going to do. If you execute itmany times with the same data you will get a different result eachtime. This makes it hopeless to judge what went wrong. Programtesting is simply useless as a means of locating time-dependenterrors.Some of these errors can no doubt be located by proofreading. Ihave seen a programmer do this by looking at an assembly languageprogram for a week. But, to proofread a large program, you mustunderstand it in complete detail. So the search for an error mayinvolve all of the people who wrote the program, and even then youcannot be sure it will be found.Well, if we cannot make concurrent programs work byproofreading or testing, then I can see only one other effectivemethod at the moment: to write all concurrent programs in aprogramming language that is so structured that you can specifyexactly what processes can do to shared variables and depend on acompiler to check that the programs satisfy these assumptions.Concurrent Pascal is the first language that makes thispossible.In the long run it is not advisable to write large concurrentprograms in machine-oriented languages that permit unrestricted useof store locations and their addresses. There is just no way wewill be able to make such programs reliable (even with the help ofcomplicated hardware mechanisms).CONCURRENT PASCALFrom 1963-65 I was one of ten programmers who wrote a Cobolcompiler in assembly language. This program of 40,000 instructionstook 15 man-years to build. Although it worked well, the compilerwas very difficult to maintain since none of us understood itcompletely.Five years later, compiler writing was completely changed by thesequential programming language Pascal, invented by NiklausWirth. Pascal is an abstract language that hides irrelevant machinedetail from the programmer. At the same time it is efficient enoughfor system programming. It is easily understood by programmersfamiliar with Fortran, Algol 60, Cobol, or PL/I.In 1974 A1 Hartmann used Sequential Pascal to write a compilerfor my new programming language, called Concurrent Pascal.This compiler is comparable to a machine program of 35,000instructions. But, written in Pascal, the program text is only8,300 lines long and can be completely understood by a singleperson. The programming and testing of this compiler took only 7months.The aim of Concurrent Pascal is to do for operating systems whatSequential Pascal has done for compilers: to reduce the programmingeffort by an order of magnitude.Concurrent Pascal extends Sequential Pascal with concurrentprocesses and monitors. The compiler prevents sometime-dependent programming errors by checking that the privatevariables of one process are inaccessible to another. Processes canonly communicate by means of monitors.A monitor defines all the possible operations on a shared datastructure. It can, for example, define the send and receiveoperations on a message buffer. The compiler will check thatprocesses only perform these two operations on a buffer.A monitor can delay processes to make their interactionsindependent of their speeds. A process that tries to receive amessage from an empty buffer will, for example, be delayed untilanother process sends a message to it.If a programmer can design a process or monitor correctly, therest of a program will not be able to make that component behaveerratically (since no other part of the program has direct accessto the variables used by a component). The controlled access toprivate and shared variables greatly reduces the risk oftime-dependent program behavior caused by erroneousprocesses.MODEL OPERATING SYSTEMSThis book stresses the practice of concurrent; programming. Itcontains a complete description of three model operating systemswritten in Concurrent Pascal.Chapter 5 describes a single-user operating system, called Solo.It supports the development of Sequential and Concurrent Pascalprograms on the PDP 11/45 computer. Input/output are handled byconcurrent processes. Pascal programs can call one anotherrecursively and pass arbitrary parameters among themselves. Thismakes it possible to use Pascal as a job control language. Solo isthe first major example of a hierarchical concurrent program madeof processes and monitors.Chapter 6 presents a job-stream system that compiles andexecutes short Pascal programs which are input from a card readerand are output on a line printer. Input, execution, and output takeplace simultaneously, using buffers stored on disk.Chapter 7 discusses a real-time scheduler for processcontrol applications in which a fixed number of concurrent tasksare carried out periodically with frequencies chosen by anoperator.These chapters not only describe how to build different kinds ofoperating systems but also illustrate the main steps of the programdevelopment process.The Solo system shows how a concurrent program of more than athousand lines can be structured and programmed as asequence of components of less than one page each. The real-timescheduler is used to demonstrate how a hierarchical, concurrentprogram can be tested systematically. The job-stream systemillustrates how a program structure can be derived fromperformance considerations.LANGUAGE DEFINITION AND IMPLEMENTATIONI have tried to make this book as readable as possible to sharean architectonic view of concurrent programming effectively.Formalism is often a stumbling block in the first encounter with anew field, and the practice of structured concurrent programming isnot commonplace yet. So I have assumed in chapters 3 and 4 that youare so familiar with one or more programming languages that it issufficient to show the flavor of Sequential and Concurrent Pascalby examples before describing the model operating systems.But when you wish to use a new programming language in your ownwork, a precise definition of it becomes essential. So theConcurrent Pascal report is included in chapter 8.The whole purpose of this work is to show how much a concurrentprogramming effort can be reduced by using an abstract languagethat suppresses as much machine detail as one can afford to withoutlosing control of program efficiency. For this reason theintroduction to Concurrent Pascal ignores the question of how thelanguage is implemented.Chapter 9 is an overview of the language implementationfor those who feel uncomfortable unless they have a dynamic feelingfor what their programs make the machine do. I suspect that most ofus belong to that group. Once you understand what a machine does,however, it is easier to forget the details again and start relyingcompletely on the abstract concepts that are built into thelanguage.TEACHING AND ENGINEERINGVery few operating systems are so well-structured andwell-documented that they are worth studying in detail. And few (ifany) computing centers make it possible for students to write theirown concurrent programs in an abstract language. Since students canneither study nor build realistic operating systems it is almostimpossible to make them feel comfortable about the subject.This book tries to remedy that situation. It defines an abstractlanguage for concurrent programming that has been implemented onthe PDP 11/45 computer. The compiler can be moved to othercomputers since it is written in Sequential Pascal and generatescode for a simple machine that can be simulated efficiently bymicroprogram or machine language.The book also offers complete examples of model operatingsystems that can be studied by students.If you are a professional programmer you can seldom choose yourown programming language for large projects. But you can benefitfrom new language constructs--such as processes and monitors--bytaking them as models of a systematic programming style that can beimitated as closely as possible in other languages (includingassembly languages).The system kernel that is described in chapter 9 illustratesthis. It is an assembly language program written entirely by meansof classes (a concept similar to monitors). Since this concept isnot in the assembly language it is described by comments only.The book can also be used as a handbook on the design of smalloperating systems and significant portions of larger ones.If you are a software engineer you may feel that the operatingsystems described here are much smaller than those you are asked tobuild. This raises the question of whether the concepts used herecan help you build huge systems. My recommendation is to useabstract programming concepts (such as processes and monitors)wherever you can. 'This will probably solve most programmingproblems in a simple manner and leave you with only a few reallymachine-dependent components (such as a processor scheduler and astorage allocator). As a means of organizing :your thoughts,Concurrent Pascal can only be helpful.But I should also admit that I do not see a future for largeoperating systems. They never worked well and they probably neverwill. They are just too complicated for the human mind. They werethe product of an early stage in which none of us had a goodfeeling for what software quality means. The new technology thatsupports wide-spread use of cheap, personal computers will soonmake them obsolete.Although operating systems have provided the most spectacularexamples of the difficulty of making concurrent programs reliable,there are other applications that present problems of their own. Asan industrial programmer I was involved in the design of processcontrol programs for a chemical plant, a power plant, and ameteorological institute. These realtime applications had one thingin common: they were all unique in their software requirements.When the cost of developing a large program cannot be shared bymany users the pressure to reduce the cost is much greater than itis for generalpurpose software, such as compilers and operatingsystems. The only practical way of reducing cost then is to givethe process control engineers an abstract language for concurrentprogramming. To illustrate this I rewrote an existing real-timescheduler from machine language into Concurrent Pascal (chapter7).The recent reduction of hardware costs for microprocessors willsoon put even greater pressure on software designers to reducetheir costs as well. So there is every reason for a realisticprogrammer to keep an eye on recent developments in programmingmethodology.PROJECT BACKGROUNDIn 1971, Edsger Dijkstra suggested that concurrent programsmight be easier to understand if all synchronizing operations on ashared data structure were collected into a single program unit(which we now call a monitor).In May 1972 I wrote a chapter on Resource Protection forOperating System Principles. I introduced a languagenotation for monitors and pointed out that resource protection inoperating systems and type checking in compilers are solutions tothe same problem: to verify automatically that programs onlyperform meaningful operations on data structures. My conclusion wasthat "I expect to see many protection rules in future operatingsystems being enforced in the cheapest possible manner by typechecking at compile time. However, this will require exclusive useof efficient, well-structured languages for programming." Thisis still the idea behind Concurrent Pascal.I developed Concurrent Pascal at the California Institute ofTechnology from 1972-75. The compiler was written by A1 Hartmann.Robert Deverill and Tom Zepko wrote the interpreter for the PDP11/45. I built the model operating systems, and Wolfgang Franzenmade improvements to one of them (Solo).