Reasoning about Java’s Reentrant Locks

Abstract

This paper presents a verification technique for a concurrent Java-like language with reentrant locks. The verification technique is based on permissionaccounting separation logic. As usual, each lock is associated with a resource invariant, i.e., when acquiring the lock the resources are obtained by the thread holding the lock, and when releasing the lock, the resources are released. To accommodate for reentrancy, the notion of lockset is introduced: a multiset of locks held by a thread. Keeping track of the lockset enables the logic to ensure that resources are not re-acquired upon reentrancy, thus avoiding the introduction of new resources in the system. To be able to express flexible locking policies, we combine the verification logic with value-parameterized classes. Verified programs satisfy the following properties: data race freedom, absence of null-dereferencing and partial correctness. The verification technique is illustrated on several examples, including a challenging lock-coupling algorithm.

Formal Reasoning about Concurrent Assembly Code with Reentrant Locks

“…A recent work [16] proposes a verification technique for a concurrent Java-like language with reentrant locks. The verification technique is based on permission accounting separation logic.…”

“…The verification technique is based on permission accounting separation logic. The essential differences between [16] and our paper are: we focus on verifying concurrent assembly code with reentrant locks and develop an extension to the PCC framework; instead of using hand-writing proof, we provide machine-checkable proof for our framework.…”

Specification and verification of synchronisation classes in Java : a practical approach

“…To give a flavour of this logic, Figure 4.2 quotes the proof rules from [41], preserving the original syntax, for initial and reentrant acquiring of a lock. The first rule states that if a thread locks u, and the set of currently held locks does not contain u yet, and the lock is initialised, then upon completion of the u.lock() statement, u is in the lock set, and the resource invariant has been transferred to the thread holding the lock on u.…”

“…Neither was it to develop yet another new logic for concurrent data structures verification. Instead, the permission-based Separation Logic from Hurlin and Haack [46,41] is lifted into the specification language to specify and verify expected behaviour of the main synchronisers available in the java.util.concurrent library. This allowed us to develop the VerCors tool-set that can reason about correctness of concurrent Java programs synchronised with various synchronisers.…”

“…We present how the logic for built-in reentrant locks from [10,41] is generalized to specify the Lock interface, and how the specifications of ReentrantLock and ReadWriteLock both are built on top of this general specification for Locks. Then, we discuss how we treat lock initialization at specification level.…”