Specifying concurrent objects

• Authors: B. Krämer
• Venue: OOPSLA/ECOOP '88 Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming
• Year: 1988

The object-oriented style of programming (OOP) is gaining increasing importance as a practical technique for organizing large designs and programs. Another striking aspect of OOP is its potential for concurrent and distributed applications which is based on the fact that objects may coexist in time and concurrently may exchange information by message passing. Up to now, however, there is only little progress in the development of formal computation models that exploit the full power of concurrency inherent in the OOP paradigm. (One of the few exceptions is the actor model [1].) As a consequence, there are not many OOP languages such as POOL [2] or Trellis/Owl [7] that provide mechanisms allowing the designer to keep control of how objects are dynamically created, how they interact in a distributed environment, and how objects can be allocated on a network of processors.Our Model. We propose a model of concurrent objects that integrates ideas from three different research areas to cope with what we think is the substance of the object-oriented paradigm: 1) Cardelli's work on a formal semantics of multiple inheritance [3] influenced our way of thinking about object decomposition and inheritance relationships between them; in particular, we adopt his idea to base the decomposition of objects on labeled Cartesian products and disjoint sums. 2) The algebraic foundation of abstract data types provides a representation independent notion of data structures and encapsulation concepts. 3) To support a notion of distributed state and concurrent state changes, we use high level Petri nets. They describe dynamic behavior of concurrent systems in a way that is at the same time formal and visual. It is easy to see that record and variant type constructors can be handled in an algebraic framework, if taking some care of variants. Moreover, in [5] and [6] we have shown that algebraic and Petri net based specification techniques can be unified in a conceptually and semantically coherent framework.In the sequel we give two examples to explain this combination of concepts. Similar to [4], we distinguish between functions to denote object attributes and methods to denote state changing operations: we use Cardelli's notation of variants and records, and an intuitive notation for signatures and conditional axioms. We allow methods to operate concurrently on an object's attributes, provided that they do not share any attribute of that object. Variant objects. Variants are taken to model sequential objects. The disjoint cases of a variant are used to describe the set of distinct states in which a variant object can be observed. All methods defined on a variant object mutually exclude each other and affect a specific state transition. For example, the simple object module SENDER specified below might form a component in the specification of an alternating bit protocol: The axioms both specify constraints to the applicability of methods and the effect a method invocation has on the state of an instance. For example, method get-ack is only applicable if an instance, say S, is in the state labeled snt: the effect of get-ack either is that S is in state ack (in which a new message can be accepted) or in state rdy (in which the old message is to be resent). Like Cardelli, we assume basic operations as-L to extract the contents of a variant object with a particular label L.In place of the axioms, we better could have used high level Petri nets1 to visualize the dynamic behavior of sender objects: Remark: The dependency between the control bits B, B' and the label L involved in method get-ack must be specified by an axiom. The new method is omitted. Record objects. More interesting behavioral aspects are associated with record objects as we view their attributes as potential candidates for concurrent manipulation. To achieve this, we conceptually treat record objects as distributed data structures by splitting them along their decomposition in attributes. For each method we have to indicate which attributes it needs to access. Then, concurrency arises when methods access different attributes of a particular object.In the specification below we discuss some aspects of a host in a communications network. It is composed of different, partly independent subsystems such as a server providing diverse client services, input and output buffers to store incoming and outgoing messages, a sender, and a receiver which are responsible message transmission to other hosts. For simplification we give meaning only to a few of the conceivable methods. Discussion. The above Petri net reflects the behavioral concepts we are interested in as follows: 1) Independently accessible local data appear as distinct data tokens: 2) mutual exclusion between methods is manifested in terms of conflicting accesses to such tokens: 3) sequential dependencies are expressed by a producer-consumer relationship w.r.t. particular tokens (cf. the previous example); 4) concurrency arises when methods access different tokens; and (what has not been shown) 5) object interaction is expressed as participation in common method invocations. Conclusions. The underlying theory of Petri nets offers concepts for reasoning about lifeness and safeness of a behavior specification and provides an appropriate notion of nonsequential observations of method executions while many-sorted partial algebras provide a precise meaning of the local data operated on. Inheritance mechanism have not been discussed here as we are not yet sure whether our initial ideas to extend Cardelli's structural approach to behavior specifications really will hold.