Expressiveness of Notations for Reasoning about Concurrency

It might appear that having highly expressive notations is an advantage in writing specifications and subsequently reasoning about programs. Even for sequential programs, this is not always true: simple type systems that are statically decidable or fixed formats of specifications that yield intuitive proof obligations both indicate that constrained expressiveness can increase tractability. The aim here is to examine some of the trade-offs in expressiveness for notations that address concurrency. The Rely/Guarantee approach to top-down development of concurrent programs offers a way of recording assumptions and commitments about interference. In the same way that pre conditions invite the designer of a component to ignore the possibility that the artifact they are to create will start in states that fail to satisfy the predicate, rely conditions record assumptions the developer is invited to make about any interfering state transitions from the environment in which the artifact will be deployed. In other words, the developer cannot be held liable for the behaviour of the artifact in environments that do not satisfy either assumption. In contrast, just as the post condition expresses a relation that must hold between the initial and final, a guarantee condition records the relation that must exist over any state transition of the artifact. (There are obvious robustness arguments for making components as general as possible; this is not the subject here; it is inevitable that any non-trivial component will need some assumptions.) The decision to use simple relations on pairs of states for (post and) rely and guarantee conditions is a restriction on expressiveness. The restriction, however, means that a reasonably tractable set of proof rules can be given for compositional development of concurrent programs (see [1]; a more recent soundness proof is [2]). In contrast, the initial goal of Concurrent Separation Logic [3] was the bottom-up analysis of intricate code that manipulates heap variables. Here again, there is a deliberate decision to focus on expressing a set of issues: those concerned with separation or ownership. Separation logic has spawned many variants (cf. [4]) but each has a set of operators with neat algebraic properties.