Shared Variables Interaction Diagrams Rajeev Alur Radu Grosu Department of Computer and Information Science Department of Computer Science University of Pennsylvania State University of New York at Stony Brook [email protected] [email protected] Abstract variables paradigm. Textbooks on concurrent programming (e.g., [14, 17]) contain many pictures describing the interac- Scenario-based specifications offer an intuitive and vi- tions of processes communicating by shared variables, and sual way of describing design requirements of distributed similar scenarios arise in diverse areas such as transaction software systems. For the communication paradigm based processing in concurrent databases (c.f. [18]) and consis- on messages, message sequence charts (MSC) offer a stan- tency in shared-memory multiprocessors [13]. dardized and formal notation amenable to formal analysis. In our definition of an SVID, an action corresponds to, In this paper, we define shared variables interaction dia- possibly multiple, reading/writing of shared variables. The grams (SVID) as the counterpart of MSCs when processes actions of one process are visually ordered. The causal de- communicate via shared variables. After formally defining pendence among actions of different processes is illustrated SVIDs, we develop an intuitive as well as formal definition Ô by arrows: an arrow from an action a of process to an ac- of refinement for SVIDs. This notion provides a basis for Õ Õ tion b of process means that reads a value that was writ- systematically adding details to SVID requirements. ten by Ô. If the variable involved in this communication is write-shared, then there is an implicit additional constraint b that between these two actions a and , there is no interven- 1. Introduction ing action that writes to this variable. Checking whether all such implicit constraints are consistent with one another can Message Sequence Charts (MSCs) are a commonly used be computationally hard, and is shown to be NP-complete in visual description of design requirements for concurrent general. We also establish that the problem can be solved in systems such as telecommunications software [19], and linear-time when all the variables are read-shared but write- have been incorporated into software design notations such exclusive. Benefits of SVIDs are the same as that of MSCs: as UML [6]. On one hand, the clear graphical layout of an they give an intuitive and visual understanding of interac- MSC immediately gives an intuitive understanding of the tions among processes in a single execution, and have a intended system behavior, and on the other, the notation formal semantics. The execution of a concurrent program has been standardized (ITU standard Z.120) with precise can also be depicted by a linear trace involving actions of semantics, and hence, can be subjected to analysis. This all processes, but a single SVID captures many such execu- has already motivated the development of algorithms for a tions succinctly, and makes causal dependencies explicit. variety of analyses including detecting race conditions and An appealing notion for systematic hierarchical develop- timing conflicts [3], pattern matching [16], detecting non- ment of specifications or models involves refinement (this is local choice [7], and model checking [4], and tools such as present in all concurrency formalisms [20]). The definition uBET [11] and MESA [5]. of SVIDs, and the underlying shared-variables paradigm, An MSC depicts the desired exchange of messages suggests many natural ways of refining SVIDs. We identify among communicating entities in distributed software sys- different ways of visually adding more details to an SVID: tems. An alternative paradigm for communication in dis- by moving arrows depicting dependencies, by introducing tributed systems involves shared variables. Communication new variables, actions, and/or new arrows, by splitting com- and synchronization via shared objects provides a higher posite actions, and by splitting processes into subprocesses. level of abstraction, and is supported by many modern con- All these cases are captured by our formal definition of re- current programming languages. In this paper, we propose finement for SVIDs. The definition requires existence of a shared variables interaction diagrams (SVID) as a formal mapping of implementation actions to specification actions and visual notation for describing scenarios in the shared consistent with the dependencies. We show the problem of checking refinement to be NP-complete. When the commu- The inter-process communication via shared variables is nication is point-to-point, that is, each variable has a sin- depicted by arrows (or edges) between boxes. An arrow b b ¾ gle writer and a single reader, the problem can be solved in pointing from a box ½ to a box indicates that the value of b b ¾ polynomial time. the variables updated by ½ is read (or checked) by .For Å b b ½¾ ¾4 The remaining paper is organized as follows. Section 2 instance, in Figure 1, in ¾ , the arrow from to spec- f Ô b ¾ ¾4 introduces the definition of SVIDs. Section 3 defines the ifies that the value of ½ read by in box is the value f Ô b ½ ½¾ notion of refinement for SVIDs. Section 4 compares SVIDs written to ½ by in box . Thus, the arrows establish a to related formalisms, and in particular to message sequence causal order between actions of different processes: the ac- Ô b ¾4 charts (MSCs). tion of ¾ corresponding to must happen after the action Ô b ½¾ of ½ corresponding to . For write-shared variables, the arrows establish an additional causal dependence between 2. Shared Variables Interaction Diagrams reads and writes, namely, not only the read should happen after the write, but in addition, there should be no interven- Å Peterson’s mutual exclusion protocol. In order to il- ing write to the shared variable. For instance, in ¾ ,the b b Ø ½¿ lustrate the use and utility of shared variables interaction arrow from box ¾¾ to says that the value of read by Ô b Ø Ô b ½¿ ¾ ¾¾ diagrams (SVID) let us consider the Peterson’s mutual ex- ½ in box is the value written to by in box .This Ô Ô Ô b ½ ¾ ½¿ clusion protocol for two asynchronous processes and . means that the action of ½ corresponding to happens af- Ô Ô Ô b ½ ¾ ¾¾ The protocol makes sure that and never simultane- ter the action of ¾ corresponding to , and between these ously reach their critical sections and that each may eventu- two actions there is no action involving writing to the shared ally enter its critical section provided it desires to do so. variable Ø. In this case, this enforces an implicit causal de- Ô Ô b b Ô Ø ¾ ½¾ ¾¾ ¾ To achieve the desired synchronization among ½ and pendence between box and (i.e, writes to after f Ô ½ the protocol uses three variables. The first variable ½ is a in this scenario). Ô boolean variable (or flag), that when set, signals that ½ de- To simplify the notation we adopt the (usual) convention Ô sires to enter its critical section. It is writable only by ½ but that, write exclusive variables of a process preserve their Ô f b ¾ it can be read by ¾ . The second variable, the flag ,plays values if not explicitly updated. Hence, a box contained Ô Ô f Ô Ø ½ ½ thesamerolefor ¾ as does for . Finally, the variable by a process exports not only the variables explicitly up- Ô (turn) is used to resolve the conflict when both processes try dated by b but also the write exclusive variables of that are to simultaneously enter their critical sections. The variable not updated by b. This allows the use of empty boxes (not is written and read by both processes and ranges over the explicitly drawn) as sources for arrows. Similarly to MSCs ½; ¾g set of process identifiers, i.e., f in the binary case. the arrows may be labeled. However, the arrow labels are not messages. They are conditions over variables that have Exemplary SVIDs for the protocol. In Figure 1 we to hold in order to perform the update operation at the head show four typical scenarios for the Peterson’s protocol as of the arrow. basic SVIDs. They intuitively capture the synchronization The vertical process lines define a top down linear or- Ô Ô ¾ (communication) patterns between the processes ½ and . der among the update operations (boxes) of the same pro- Å Å ¿ The SVIDs ½ and describe the situations where only cess (like in MSCs time flows top/down). Hence, verti- Ô Ô Å ¾ ¾ ½ or only requests the critical section. The SVIDs cal lines describe local synchronization whereas arrows de- Å and 4 show how the tie is resolved when both processes scribe global synchronization. Ô Ô ¾ ½ and request the critical section. These scenarios can To improve readability we use, as with MSCs, condi- be used for understanding the behavior of the protocol, or tions. They are drawn inside hexagonal boxes. Intuitively, they can be used as a specification for designing the proto- a condition is an update of the program counter variable as- col. Clearly, there are many more scenarios that are possi- sociated with the relevant process. ble, and the specified ones serve only as a guide. In the following we define SVIDs in a formal way. To As with message sequence charts (MSCs), vertical lines simplify the definition we do not consider arrow labels. correspond to processes. However, in contrast to MSCs, They might be understood simply as comments that reflect the processes do not communicate with each other via mes- the most recent value of the associated variables. Similarly, sages. Instead, they communicate via shared variables.The we do not include the conditions in the formal definition. way a process updates its variables is given textually in the left compartment of rectangular boxes (or vertices). The Definition 1 (Shared variables interaction diagram) A variables needed (or read) by the update operations in a box shared variables interaction diagram Å consists of the fol- are given in the right compartment of the same box.