Deadlock avoidance in parallel programs with futures: why parallel tasks should not wait for strangers

Abstract

Futures are an elegant approach to expressing parallelism in functional programs. However, combining futures with imperative programming (as in C++ or in Java) can lead to pernicious bugs in the form of data races and deadlocks, as a consequence of uncontrolled data flow through mutable shared memory. In this paper we introduce the Known Joins (KJ) property for parallel programs with futures, and relate it to the Deadlock Freedom (DF) and the Data-Race Freedom (DRF) properties. Our paper offers two key theoretical results: 1) DRF implies KJ, and 2) KJ implies DF. These results show that data-race freedom is sufficient to guarantee deadlock freedom in programs with futures that only manipulate unsynchronized shared variables. To the best of our knowledge, these are the first theoretical results to establish sufficient conditions for deadlock freedom in imperative parallel programs with futures, and to characterize the subset of data races that can trigger deadlocks (those that violate the KJ property). From result 2), we developed a tool that avoids deadlocks in linear time and space when KJ holds, i.e., when there are no data races among references to futures. When KJ fails, the tool reports the data race and optionally falls back to a standard deadlock avoidance algorithm by cycle detection. Our tool verified a dataset of ∼2,300 student's homework solutions and found one deadlocked program. The performance results obtained from our tool are very encouraging: a maximum slowdown of 1.06× on a 16-core machine, always outperforming deadlock avoidance via cycle-detection. Proofs of the two main results were formalized using the Coq proof assistant.

Static prediction of parallel computation graphs

“…We tested the deadlock detector on a number of example programs with and without deadlocks, including some synthetic, adversarial examples with difficult-to-detect deadlocks, a version of the webserver case study with a subtle deadlock (as well as the original, deadlock-free version), and a motivating example from prior work on dynamic deadlock detection [Cogumbreiro et al 2017]. Our deadlock detector was correct on all tested examples, where the ground truth was determined by manual inspection of the code.…”

“…While we focus on the work on cost semantics because much of it tends to be more theoretical in nature, papers in other areas have also presented dynamic semantics augmented with some form of graph. For example, Cogumbreiro et al [2017] present such a semantics in the context of deadlock detection.…”

“…As tracking and analyzing all of the necessary information at runtime can be quite expensive, much work has focused on only tracking some subset of it [Flanagan and Freund 2009;Utterback et al 2019Utterback et al , 2016Xu et al 2020]. Other work on deadlock detection, such as Known Joins (KJ) [Cogumbreiro et al 2017] and Transitive Joins (TJ) [Voss et al 2019] has traded precision for overhead by tracking certain dependency patterns that can lead to deadlock. These patterns are easier to track at runtime, leading to low overhead.…”

Dynamic deadlock verification for general barrier synchronisation

“…Alternatively, we could treat advanceAll in Armus without these extensions, through its encoding into split-phase synchronisations (call resume on each clock in arbitrary order, followed by advance on each in arbitrary order). 16 Distributed Deadlock Detection. One of the key design goals of X10 is to promote a smooth migration between shared memory and distributed deployments of barrier programs [10].…”

“…HJ avoids deadlocks that originate from the interaction between phasers and finish blocks by limiting the use of phasers to the scope of finish blocks. Cogumbreiro et al use Armus in the context of a tool that specialises in avoiding deadlocks caused by futures [16].…”