Abstract
Context. TypeState-Oriented Programming (TSOP) is a paradigm intended to help developers in the implementation and use of mutable objects whose public interface depends on their private state. Under this paradigm, well-typed programs are guaranteed to conform with the protocol of the objects they use. Inquiry. Previous works have investigated TSOP for both sequential and concurrent objects. However, an important difference between the two settings still remains. In a sequential setting, a well-typed program either progresses indefinitely or terminates eventually. In a concurrent setting, protocol conformance is no longer enough to avoid deadlocks, a situation in which the execution of the program halts because two or more objects are involved in mutual dependencies that prevent any further progress. Approach. In this work, we put forward a refinement of TSOP for concurrent objects guaranteeing that well-typed programs not only conform with the protocol of the objects they use, but are also deadlock free. The key ingredients of the type system are behavioral types, used to specify and enforce object protocols, and dependency relations, used to represent abstract descriptions of the dependencies between objects and detect circularities that might cause deadlocks. Knowledge. The proposed approach stands out for two features. First, the approach is fully compositional and therefore scalable: the objects of a large program can be type checked in isolation; deadlock freedom of an object composition solely depends on the types of the objects being composed; any modification/refactoring of an object that does not affect its public interface does not affect other objects either. Second, we provide the first deadlock analysis technique for join patterns, a high-level concurrency abstraction with which programmers can express complex synchronizations in a succinct and declarative form. Grounding. We detail the proposed typing discipline for a core programming language blending concurrent objects, asynchronous message passing and join patterns. We prove that the type system is sound and give non-trivial examples of programs that can be successfully analyzed. A Haskell implementation of the type system that demonstrates the feasibility of the approach is publicly available. Importance. The static analysis technique described in this work can be used to certify programs written in a core language for concurrent TSOP with proven correctness guarantees. This is an essential first step towards the integration and application of the technique in a real-world developer toolchain, making programming of such systems more productive and less frustrating.
Highlights
The public interface of a mutable object may depend on its private state [ ]
We see an instance of the problem in the following program, which creates a future variable [ ] and its user in an object-based language that supports concurrent TypeState-Oriented Programming (TSOP) and uses asynchronous message passing as the sole interaction mechanism [ ]: new future : #FutureT
Actors are a special instance of concurrent objects where the synchronization patterns always match two messages, one that represents the state of the actor and is always self-inflicted by the actor with a so-called “become” operation, and another message that represents a request sent to the actor from a different one
Summary
Calculus [ ] as formal model for concurrent TSOP. We assume an infinite set of object names ranged over by a, b, and a disjoint, infinite set of variables ranged over by x, y. One of them can combine with A and be consumed by the reaction, but the other one becomes junk Neither of these two programs is conformant according to Definition because their final state contains a B message, the type (∗(A · B))[B] A · ∗(A · B) is relevant, and no other occurrence of obj exists in the program. The rule does not introduce new interesting elements It checks that each object definition in is well typed and so is the parallel composition of all the processes in. The advantage of using a dedicated class keyword instead of defining Future as a plain object is that we inform CobaltBlue that Future is a stateless object: its only reaction has a simple join pattern involving only one message, meaning that the use of Future cannot contribute in creating any significant dependency between objects This helps keeping dependency relations small, reducing the possibility that mutual dependencies arise. Notice that the chain of objects increases in size each time a new prime number is discovered and that deadlock freedom guarantees that the program will run forever
Sign-in/Register to view highlights & summary 
Published Version (
Free)
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call