Future contracts

Abstract

Many recent research projects focus on language support for behavioral software contracts, that is, assertions that govern the boundaries between software building blocks such as procedures, classes, or modules. Contracts primarily help locate bugs in programs, but they also tend to affect the performance of the program, especially as they become complex.In this paper, we introduce future contracts and parallel contract checking: software contracts annotated with future are checked in parallel with the main program, exploiting the nowcommon multiple-core architecture. We present both a model and a prototype implementation of our language design. Our model comprises a higher-order imperative language and we use it to prove the correctness of our design. Our implementation is robust enough to measure the performance of reasonably large benchmarks, demonstrating that the use of future contracts can lead to significant performance improvements.

Asynchronous assertions

“…Our work is closely related to recent work on future contracts [7], a technique for concurrently checking behavioral software contracts in Scheme programs. The authors propose (but only partially implement) a very different approach for handling mutations in the store.…”

An extended account of contract monitoring strategies as patterns of communication

“…Unlike eager and semi-eager verification, the user evaluator is not interrupted during monitoring, and may proceed with its own computation separate from contract verification. As Dimoulas et al (2009) observe, this approach reveals a potential optimization in multi-processor settings: the user evaluator may proceed in parallel with the monitoring evaluator, allowing the user evaluator to spend less time awaiting monitoring results.…”

“…Even so, Degen et al (2012) observe that such lazy verification violates basic blame consistency, and thus has questionable utility. Dimoulas et al (2009) and Disney et al (2011) each explore the notion of contracts using message passing, and, further, the runtime verification literature contains a number of additional examples of using messages to verify program properties (Havelund & Rosu, 2001;Barnett et al, 2005;Chen & Roşu, 2007). In each case, however, the work has different design goals from Swords et al (2015) and our work.…”

“…Researchers have proposed myriad contract enforcement strategies in response to these rising complexities, including lazy monitors (Degen et al, 2009;Chitil, 2012), concurrent monitoring systems (Dimoulas et al, 2009), optional enforcement (Dimoulas et al, 2013), and probabilistic contract verification (Moore et al, 2016;Hickey, 2018).…”

Contracts and Specifications for Functional Logic Programming

“…For instance, [25] proposes an assertion language for (constraint) logic programming that is combined in [21] with a static verification framework. [10] considered a strict language with side effects and proposed the evaluation of assertions in parallel to the application program to exploit the power of multi-core computers. In non-strict languages, one has the option between lazy assertions [7], which do not change the meaning of a program (apart from reporting violated assertions) but might not report some violations, and strict assertions which could influence the evaluation order.…”