96 How to Make a Correct Multipro cess Program Execute Correctly on a Multipro cessor Leslie Lamp ort February 14, 1993 Systems Research Center DEC's business and technology ob jectives require a strong research program. The Systems Research Center (SRC) and three other research lab oratories are committed to lling that need. SRC b egan recruiting its rst research scientists in l984|their charter, to advance the state of knowledge in all asp ects of computer systems research. Our currentwork includes exploring high-p erformance p ersonal computing, distributed computing, programming environments, system mo delling tech- niques, sp eci cation technology, and tightly-coupled multipro cessors. Our approach to b oth hardware and software research is to create and use real systems so that we can investigate their prop erties fully. Complex systems cannot b e evaluated solely in the abstract. Based on this b elief, our strategy is to demonstrate the technical and practical feasibility of our ideas by building prototyp es and using them as daily to ols. The exp erience we gain is useful in the short term in enabling us to re ne our designs, and invaluable in the long term in helping us to advance the state of knowledge ab out those systems. Most of the ma jor advances in information systems have come through this strategy, including time-sharing, the ArpaNet, and distributed p ersonal computing. SRC also p erforms work of a more mathematical avor which complements our systems research. Some of this work is in established elds of theoretical computer science, such as the analysis of algorithms, computational geome- try, and logics of programming. The rest of this work explores new ground motivated by problems that arise in our systems research. DEC has a strong commitment to communicating the results and exp erience gained through pursuing these activities. The Companyvalues the improved understanding that comes with exp osing and testing our ideas within the research community. SRC will therefore rep ort results in conferences, in professional journals, and in our research rep ort series. We will seek users for our prototyp e systems among those with whom wehave common research interests, and we will encourage collab oration with university researchers. Rob ert W. Taylor, Director iii HowtoMake a Correct Multipro cess Program Execute Correctly on a Multipro cessor Leslie Lamp ort February 14, 1993 iv c Digital Equipment Corp oration 1993 This work may not b e copied or repro duced in whole or in part for any com- mercial purp ose. Permission to copy in whole or in part without payment of fee is granted for nonpro t educational and research purp oses provided that all such whole or partial copies include the following: a notice that such copying is by p ermission of the Systems Research Center of Digital Equipment Corp oration in Palo Alto, California; an acknowledgment of the authors and individual contributors to the work; and all applicable p ortions of the copyright notice. Copying, repro ducing, or republishing for any other purp ose shall require a license with payment of fee to the Systems Research Center. All rights reserved. v Author's Abstract Amultipro cess program executing on a mo dern multipro cessor must issue explicit commands to synchronize memory accesses. A metho d is prop osed for deriving the necessary commands from a correctness pro of of the algo- rithm. Capsule Review Recently,anumb er of mechanisms for interpro cess synchronization have b een prop osed. As engineers attempt to implementmultipro cessors of in- creasing scale and p erformance, these mechanisms have b ecome quite com- plex and dicult to reason ab out. This short pap er presents a formalism based only on two ordering relations between the events of an algorithm, \precedes" and \can a ect". It allows the mechanisms that must b e provided to ensure the algorithm's correctness to b e determined directly from the correctness pro of. The formalism and its application to an example mutual exclusion algorithm are presented and discussed. Although the pap er is quite terse, a careful reading will reward those inter- ested in concurrency or multipro cessor design. Chuck Thacker vi Contents 1 The Problem 1 2 The Formalism 2 3 An Example 3 3.1 An Algorithm and its Pro of :: ::: ::: ::: :: ::: ::: 3 3.2 The Implementation ::: ::: ::: ::: ::: :: ::: ::: 5 3.3 Observations :: :: ::: ::: ::: ::: ::: :: ::: ::: 6 4 Further Remarks 7 References 8 vii 1 The Problem Accessing a single memory lo cation in a multipro cessor is traditionally as- sumed to b e atomic. Such atomicity is a ction; a memory access consists of anumb er of hardware actions, and di erent accesses may b e executed con- currently. Early multipro cessors maintained this ction, but more mo dern ones usually do not. Instead, they provide sp ecial commands with which pro cesses themselves can synchronize memory accesses. The programmer must determine, for each particular computer, what synchronization com- mands are needed to make his program correct. One prop osed metho d for achieving the necessary synchronization is with a constrained style of programming sp eci c to a particular typ e of multipro- cessor architecture [7, 8]. Another metho d is to reason ab out the program in a mathematical abstraction of the architecture [5]. We take a di erent ap- proach and derive the synchronization commands from a pro of of correctness of the algorithm. The commonly used formalisms for describing multipro cess programs as- sume atomicity of memory accesses. When an assumption is built into a formalism, it is dicult to discover from a pro of where the assumption is ac- tually needed. Pro ofs based on these formalisms, including invariance pro ofs [4, 16] and temp oral-logic pro ofs [17], therefore seem incapable of yielding the necessary synchronization requirements. We derive these requirements from pro ofs based on a little-used formalism that makes no atomicity as- sumptions [11, 12, 14]. This pro of metho d is quite general and has b een applied to a numb er of algorithms. The metho d of extracting synchroniza- tion commands from a pro of is describ ed by an example|a simple mutual exclusion algorithm. It can b e applied to the pro of of any algorithm. Most programs are written in higher-level languages that provide abstrac- tions, suchaslocks for shared data, that free the programmer from concerns ab out the memory architecture. The compiler generates synchronization commands to implement the abstractions. However, some algorithms| esp ecially within the op erating system|require more ecient implemen- tations than can b e achieved with high-level language abstractions. It is to these algorithms, as well as to algorithms for implementing the higher-level abstractions, that our metho d is directed. 1 2 The Formalism An execution of a program is represented by a collection of operation execu- - - tions with the two relations (read precedes ) and (read can a ect ). An op eration execution can b e interpreted as a nonempty set of events, where - - the relations and have the following meanings. - A B :every eventin Aprecedes every eventin B. - A B: some eventin Aprecedes some eventin B. However, this interpretation serves only to aid our understanding. Formally, we just assume that the following axioms hold, for any op eration executions A, B , C , and D . - - - - A1. is transitive(A B C implies A C ) and irre exive - (A A). = - - - A2. A B implies A B and B A. = - - - - - B C or A B C implies A C . A3. A - - - - A4. A B C D implies A D . - A5. For any A there are only a nite number of B such that A B . = The last axiom essentially asserts that all op eration executions terminate; nonterminating op erations satisfy a di erent axiom that is not relevant here. Axiom A5 is useful only for proving liveness prop erties; safety prop erties are proved with Axioms A1{A4. prop erties. Anger [3] and Abraham and Ben- David [1] intro duced the additional axiom - - - - B C D implies A D . A6. A and showed that A1{A6 form a complete axiom system for the interpretation based on op eration executions as sets of events. Axioms A1{A6 are indep endent of what the op eration executions do. Rea- soning ab out a multipro cess program requires additional axioms to capture the semantics of its op erations. The appropriate axioms for read and write op erations will dep end on the nature of the memory system. 2 The only assumptions we make ab out op eration executions are axioms A1{ A5 and axioms ab out read and write op erations. We do not assume that - - and are the relations obtained byinterpreting an op eration execu- tions as the set of all its events. For example, sequential consistency [10]is - equivalent to the condition that is a total ordering on the set of op er- ation executions|a condition that can b e satis ed even though the events comprising di erent op eration executions are actually concurrent. This formalism was develop ed in an attempt to provide elegant pro ofs of concurrent algorithms|pro ofs that replace conventional b ehavioral argu- - - ments with axiomatic reasoning in terms of the two relations and . Although the simplicity of such pro ofs has b een questioned [6], they do tend to capture the essence of why an algorithm works. 3 An Example 3.1 An Algorithm and its Pro of Figure 1 shows pro cess i of a simple N -pro cess mutual exclusion algo- rithm [13]. We prove that the algorithm guarantees mutual exclusion (two pro cesses are never concurrently in their critical sections).