Formal Specifications for Java's Synchronisation Classes

Abstract

This paper discusses formal specification and verification of the synchronisation classes of the Java API. In many verification systems for concurrent programs, synchronisation is treated as a primitive operation. As a result, verification rules for synchronisation are hard-coded in the logic, and not verified. These rules describe the concrete semantics of the given synchronisation primitive, and manage how resources are protected by synchronisation.In contrast, this paper describes several synchronisation primitives at the specification level, by specifying the behaviour of synchronisation routines from the Java API at method level using permission-based Separation Logic. This gives a generalised, high-level, and easily extendable approach to formalisation of arbitrary synchronisation mechanisms, which allows for modular treatment of synchronisation in verification. Notably, our approach does not only apply to locks, but also to other synchronisation mechanisms such as semaphores and latches that we also discuss in the paper. Finally, we used the verification tool that we are developing and successfully verified (so far simplified) reference implementations of all presented synchronisers; the paper discusses the verification of one of them.

Transactions on Modularity and Composition I

“…Particular API instances of the Lock interface would have such distinction embedded in the implementation, like the ReentrantReadWriteLock that provides two sub-locks for the shared and exclusive access. A fully configurable specification that can be related to particular implementations of the lock, like presented in [3], would require further extensions of our specification shown here. Still, the example we presented here is a typical use case for model methods to provide generic, client independent specifications for the purpose of reasoning about data non-interference.…”

Dynamic Frames Based Verification Method for Concurrent Java Programs

“…Instead, their semantics is given with a generic API specification, which is external to the concrete use case. By passing a suitably defined resource predicate one makes such a generic specification concrete [21].…”

“…In each such case a generic specification that would cover the typical usage scenarios is possible. Our Lock specification is not fully generic in this respect, in particular it does not cover Java re-entrant locks, but it can be extended to resemble the ones we developed before for Separation Logic [21] that cover all kinds of Java lock flavours. However, there will always be scenarios that would not fall within such a generic scheme.…”

A Symbolic Approach to Permission Accounting for Concurrent Reasoning

“…In essence, the problematic points are reasoning about rational fractions [3] and the necessity to provide concrete fractions (or relative amounts [13]) in specifications. Real programming languages bring further challenges, such as re-entrant locks and other complex synchronisation methods, like count-down latches [4] in Java. To provide an intuition how permissions can be treated symbolically, this section discusses two examples.…”

“…This relieves both the specifier and the verification tool of the need to, respectively, specify and reason about concrete fractions, which requires dedicated complex decision procedures in first-order reasoning [3]. To specify complex synchronisation scenarios such as Java threads with multi-join possibilities, and latches [4], the system tracks the permission originators in the permission expressions, which can be used to determine the permission return path. To handle all scenarios, under certain conditions, it is allowed to modify this return path.…”