Multiparty Interactions for Interprocess Communication and Synchronization
Total Page：16
File Type：pdf, Size：1020Kb
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 15, NO. II, NOVEMBER 1989 1417 Multiparty Interactions for Interprocess Communication and Synchronization MICHAEL EVANGELIST, NISSIM FRANCEZ, AND SHMUEL KATZ Abstract-The essential properties are considered of a multiparty in- understanding of the functions and properties of multi- teraction construct which serves as a primitive for interprocess com- party constructs is an important and relevant research munication and synchronization in distributed programs. It is claimed that more general constructs, which violate the suggested properties, topic. We present here some steps in this direction, in an are appropriate for abstraction, but should not be seen as a communi- informal manner. Some existing formal studies are indi- cation primitive, and that both facilities are needed. Several accept- cated where appropriate. ability criteria are posed for multiparty interactions, and various pos- One purpose of a construct involving multiple pro- sibilities for constructs satisfying these criteria are presented. These cesses is to create abstractions and modularize distributed include introducing a new kind of nondeterminism within the assign- ments of an interaction, allowing restricted iteration within interac- programs, so that an abstraction can be defined only once tions, weakening the synchronization among the participants in an in- but used repeatedly, possibly by varying process groups. teraction, and varying the number of participants in order to provide The abstraction encapsulates representation details, in- a high-level treatment of fault tolerance. cluding lower-level interprocess activity. Such an abstrac- Index Terms-Fault tolerance, horizontal nondeterminism, inter- tion idea is captured by the sc:ipr [18] or team [ 131 con- process communication, multiparty interaction, quorum interaction, structs, which have formal roles to which an actual synchronization mechanism. process may enroll. While crucial for the development of distributed systems, this type of construct is not treated in this paper. I. INTRODUCTION Rather, we stress that the above abstraction constructs N designing languages for distributed programming, encapsulate multiple activations of a lower-level opera- Ithere are several possible approaches to incorporating a tion for the actual synchronization and communication construct which generalizes a point-to-point activity to a among subsets of roles. Here we concentrate on this com- multiprocess activity. These approaches have in common munication primitive, which is generically called an in- that numerous processes will somehow “come together,” teraction. Interactions may be in mutual conflict by hav- generate a temporary combined state, perform some ac- ing nondisjoint sets of participants. The issue of conflict tions on the combined state, and then separate to continue resolution (how it is decided which eligible interaction executing independently. will occur) is orthogonal to the question of the appropriate We strongly believe that this approach is promising and contents of an interaction or the criteria for eligibility and that future languages for distributed programming will is not treated here. Conflict resolution is related to the provide more of these constructs, in addition to several notion offairness and its appropriate interpretation in this existing proposals in this vein. The current prejudice in context, as seen in [2], [3], and [6]. Also, we do not treat favor of binary message-passing constructs seems to us to here the nature of the agents participating in interactions reflect too closely certain architectures which are common (formal roles, actual processes, naming conventions, in implementing physically distributed processes, but are etc.). In the sequel the term role is used generically for not the only ones possible. In fact, these binary constructs an arbitrary participant in a multiparty interaction. are often not natural for describing transfers of informa- One extreme approach to constructs for multiparty ac- tion. They are simply too “low-level” and are more ap- tivity is seen in thejoint actions of [5], [6], shared acrions propriate for an assembly language of distributed pro- of [23], or the multiway rendezvous of [8]. There an ar- gramming than for a high-level language. Thus, a better bitrary sequential program (including a nonterminating one) may be executed on the combined state during the interaction. However this violates our intuitive notion of Manuscript received June 13. 1988; revised May 29, 1989. Recom- mended by P. A. Ng. N. Francez was supported in part at the Technion by a communication primitive where the full expressiveness the Fund for the Promotion of Research in the Technion and by the Foun- needed for general protocols are left to the abstraction or dation for Research in Electronics. Computers, and Communications (ad- encapsulation mechanisms. ministered by the Israeli Academy of Sciences and Humanities). M. Evangelist is with MCC Software Technology Program, Austin, TX At the other extreme, the simplest multiparty activities 78759. mentioned in the literature are the broadcast or more gen- N. Francez and S. Katz are with MCC Software Technology Program, erally the multicast primitives (see, e.g., [71, [9], [191, Austin, TX 78759, on leave from the Department of Computer Science, The Technion, Haifa 32000, Israel. [20], [24]), in which exactly one value is passed from one IEEE Log Number 89305 12. participant to all others (or a subset thereof in the second 0098-5589/89/1100-1417$01.00 0 1989 IEEE Authorized licensed use limited to: Kansas State University. Downloaded on February 12, 2010 at 10:32 from IEEE Xplore. Restrictions apply. 1418 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 15. NO. II. NOVEMBER 1989 case). We refer to such primitives as direcred interac- of the combined state itself. It becomes reasonable to con- tions. Their characteristic is that the activity is directed in sider the number of interactions executed as an indication that the value is sent to one or more recipients, as in mes- of the time complexity of the programs which use them. sage-passing. Most of these constructs do not serve to In particular, property 4) is crucial, since it disallows gen- synchronize the participants. eral iteration within an interaction body. In more general Neither joint actions nor broadcasts are appropriate for constructs, such as the joint or shared actions mentioned the level of abstraction needed in a multiparty interaction above, this simple mapping is lost since an arbitrary se- construct. Here we reserve the term “interaction” for ac- quential program on the combined state may take place tivities defined on a combined state, where each partici- after synchronization. pating role may both provide and use state components. One may wonder why synchronous termination of an Thus, this is an undirected activity, which will synchro- interaction (wherein its participants are jointly released) nize its participants. On the other hand, actions allowed is not considered as a separate issue, e.g., as in [18]. The within an interaction will be severely restricted. answer is that, even with full synchronization upon entry, To provide criteria for evaluating the appropriateness as long as some local state is always assumed to exist of various possibilities and to further justify considering between two consecutive executions of interactions, then the above constructs nonprimitive, we suggest several synchronous termination of interactions is unnecessary. properties as characterizing a multiparty interaction that This is because the other properties ensure that any serves as an interprocess communication primitive: changes to the state made by a role are entirely local, and I) Synchronization Upon Entry: The main effect of this can be sensed by another role only by participation in a requirement is to provide a consistent combined state for subsequent interaction. That latter interaction again re- the interaction. We consider other alternatives in Section quires synchronization of all participant roles upon entry, VI. and thus by that time all of the participants must have 2) Split Bodies, Affecting Only Local States: By this finished their part in the previous interaction and com- we mean that each participant role in an interaction in- pleted any indicated local actions. There is no way to ex- cludes within its own program an interaction body which ternally distinguish a process still active in a previous in- lists all changes to its local variables within the interac- teraction body from one “resting” in the immediately tion. These changes may depend on the values of vari- following local state. ables of other participants. The collection of relevant lo- In Sections 11-V, we deal with the structure of the al- cal bodies determines the effect of the entire interaction. lowed global actions within an interaction, rather than This feature is particularly useful in that it facilitates the with the way the roles “come together.” The question of verification of programs using interactions by applying the the degree of synchronization (e.g., whether all the par- cooperating proofs methodology, which has proven use- ticipants must initiate executing an interaction at the same ful for many other communication primitives (see [ 171). time) is treated in Section VI, and varying the number of 3) Interprocess Access to Variables of Participants participants (needed for fault tolerance) is considered in Only Within