Typing Non-uniform Concurrent Objects [chapter]

António Ravara, Vasco T. Vasconcelos
2000 Lecture Notes in Computer Science  
Concurrent objects may offer services non-uniformly, constraining the acceptance of messages on the states of objects. We advocate a looser view of communication errors. Safe programmes must guarantee that every message has a chance of being received if it requests a method that may become enabled at some point in the future. We formalise non-uniform concurrent objects in TyCO, a name-passing object calculus, and ensure program safety via a type system. Types are terms of a process algebra that
more » ... describes dynamic aspects of the behaviour of objects. Traditional type systems assign rigid interface-like types to the names of objects [15, 27] . Take the example of a one-place buffer that only allows read operations when it is full, and write operations when it is empty. We like to specify it as follows, showing that the buffer alternates between write and read. def The referred type systems reject the example above, since name b alternates its interface. An alternative typable implementation uses the busy-waiting technique to handle non-available operations. In the second implementation, a process containing the redex Buf[b, v, empty] | b!read [r] is not an error, and the presence of a message of the form b!write[u] makes possible the acceptance of the read message. Similarly, in the first implementation, a process containing the redex Empty[b] | b!read [r] should not be considered an error, as again, the presence of a message like b!write[u] also makes the reception of the read message possible. Nonetheless, notice that a deadlocked process like νb (Empty[b] | b!read [r]) should be considered an error. In conclusion, the implementations behave similarly, in the sense that both accept a read message when the buffer is full, afterwards becoming empty, and accept a write message when the buffer is empty, afterwards becoming full. A more thorough discussion on non-uniform objects in TyCO, with more complex examples, can be found elsewhere [20]. We have been working on a theory of types able to accommodate this style of programming [21, 22] . We adopt a types-as-behaviours approach, such that a type characterises the semantics of a concurrent objects by representing all its possible life-cycles as a state-transition system. Types are terms of a process algebra, fuelled by an higher-order labelled transition system, providing an internal view of the objects that inhabit them. It constitutes a synchronous view, since a transition corresponds to the reception of a message by an object. Hence, the types enjoy the rich algebraic theory of a process algebra, with an operational semantics defined via a labelled transition system, and a notion of equivalence. The equivalence is based on a bisimulation that is incomparable with other notions in the literature, and for which we define an axiomatic system, complete for image-finite types [21] . Therefore, types are partial specifications of the behaviour of objects, able to cope with non-uniform service availability. They are also suitable for specifying communication protocols, like pop3, since a type can represent sequences of requests to a server, and also deals with choice. Equipped with a more flexible notion of error and with these richer types, we develop a type system which guarantees that typable processes will not run into communication errors.
doi:10.1007/3-540-44618-4_34 fatcat:u7d2clsy2za77ic27ohxdxjpfi