Dynamic deadlock verification for general barrier synchronisation

Abstract

We present Armus, a dynamic verification tool for deadlock detection and avoidance specialised in barrier synchronisation. Barriers are used to coordinate the execution of groups of tasks, and serve as a building block of parallel computing. Our tool verifies more barrier synchronisation patterns than current state-of-the-art. To improve the scalability of verification, we introduce a novel event-based representation of concurrency constraints, and a graph-based technique for deadlock analysis. The implementation is distributed and fault-tolerant, and can verify X10 and Java programs. To formalise the notion of barrier deadlock, we introduce a core language expressive enough to represent the three most widespread barrier synchronisation patterns: group, split-phase, and dynamic membership. We propose a graph analysis technique that selects from two alternative graph representations: the Wait-For Graph, that favours programs with more tasks than barriers; and the State Graph, optimised for programs with more barriers than tasks. We prove that finding a deadlock in either representation is equivalent, and that the verification algorithm is sound and complete with respect to the notion of deadlock in our core language. Armus is evaluated with three benchmark suites in local and distributed scenarios. The benchmarks show that graph analysis with automatic graph-representation selection can record a 7-fold execution increase versus the traditional fixed graph representation. The performance measurements for distributed deadlock detection between 64 processes show negligible overheads.

Safety verification of phaser programs

“…This gave 48 different instances with 2 to 3 phasers and 2 to 4 tasks (except for the parameterized case). Our tool uses global phaser and task variables as in [5]. We have experimented with adapting the view abstraction technique [16] to verify phaser programs generating arbitrary many tasks, i.e., parameterized verification where the number of phasers is fixed.…”

“…Indeed, reachability of configuration (s F , 0, 0, 0) (three counters x, y, z with zero values at some control location s F ) is undecidable for reset-VASs. Figures (4)(5) in the appendix describe a phaser program where a main task t spawns three tasks {t 12 , t 23 , t 31 } s.t. t $a$b runs task$a$b for each $a$b ∈ {12, 23, 31}.…”

“…Unlike [6], we focus on fully automatic verification and consider the richer and more challenging phaser construct. The work of [5] considers the dynamic verification of phaser programs and can therefore only reason about particular program inputs and runs. The work in [7] uses Java Path Finder [8] to explore several runs, but still for one concrete input at a time.…”

Parameterized Verification of Synchronized Concurrent Programs

“…Unlike [93] which proposes an approach for verifying correct synchronization of static and dynamic barriers, we focus on fully automatic verification and consider the richer and more challenging phaser construct. The work of [40] considers the dynamic verification of phaser programs and can therefore only reason about particular program inputs and runs. The work in [10] uses Java Path Finder [68] to explore several runs, but still for only one concrete input at a time.…”

On Reachability in Parameterized Phaser Programs

“…This is well beyond [9] and requires a more complex symbolic representation with a deeper termination argument. The work of [6] considers the dynamic verification of phaser programs and can therefore only be used to detect deadlocks at runtime. The work in [2] uses Java Path Finder [10] to explore all execution paths of the application.…”