Contracts for concurrency

Abstract

The SCOOP model extends the Eiffel programming language to provide support for concurrent programming. The model is based on the principles of Design by Contract. The semantics of contracts used in the original proposal (SCOOP 97) is not suitable for concurrent programming because it restricts parallelism and complicates reasoning about program correctness. This article outlines a new contract semantics which applies equally well in concurrent and sequential contexts and permits a flexible use of contracts for specifying the mutual rights and obligations of clients and suppliers while preserving the potential for parallelism. We argue that it is indeed a generalisation of the traditional correctness semantics. We also propose a proof technique for concurrent programs which supports proofs-similar to those for traditional non-concurrent programs-of partial correctness and loop termination in the presence of asynchrony.

Flexible access control policy for SCOOP

“…The proposed solution allows the implementation of many synchronisation scenarios that were difficult (or impossible) to express in the original model; at the same time, all scenarios implementable in the original model can also be expressed in the extended framework. Both mechanisms support polymorphism and dynamic binding; they are compatible with the general rules of DbC, and underpin the novel proof technique for concurrent programs described in [NMO08].…”

“…separate callbacks, without compromising the atomicity guarantees. We generalise the semantics of argument passing in a way that accommodates the lock passing mechanism and ensures the soundness of the proof technique for SCOOP programs developed in [Nie07,NMO08].…”

“…The proof technique for SCOOP programs introduced in [Nie07,NMO08] supports sequential-like reasoning about concurrent code involving asynchronous calls. Essentially, the proof technique follows the traditional approach to reasoning about feature calls whereby suppliers assume the precondition on entry to the routine body and must establish the postcondition on exit, whereas clients must establish the precondition before the call and may assume the postcondition after the call.…”

Parallel Object Contracts for High Performance Computing

“…However, in this work, we want to differentiate the two in order to target our contract mechanism specifically to parallel objects. Previous work in applying DbC to concurrent programs has led to a number of interesting approaches [8], [9], [10] that had some influence on our system's design.…”

SuperContra: Cross-Language, Cross-Runtime Contracts as a Service

“…[7], for sequential [1], [11], [12], [13], [14] and concurrent [15], [16], [17] programs. There are programming languages [18], [12] that consider contracts as first-class structures, and DbC frameworks that extend existing programming languages [11], [19].…”