Dynamic deadlock avoidance in systems code using statically inferred effects

Abstract

Deadlocks can have devastating effects in systems code. We have developed a type and effect system that provably avoids them and in this paper we present a tool that uses a sound static analysis to instrument multithreaded C programs and then links these programs with a run-time system that avoids possible deadlocks. In contrast to most other purely static tools for deadlock freedom, our tool does not insist that programs adhere to a strict lock acquisition order or use lock primitives in a block-structured way, thus it is appropriate for systems code and OS applications. We also report some very promising benchmark results which show that all possible deadlocks can automatically be avoided with only a small run-time overhead. More importantly, this is done without having to modify the original source program by altering the order of resource acquisition operations or by adding annotations.

An Ownership Policy and Deadlock Detector for Promises

“…We consider logical deadlocks, which are distinct from resource deadlocks in that there is an unresolvable cyclic dependence among computational results. Solutions in the logical deadlock domain include techniques that dynamically detect cycles [29,30,37,38,40,54], that raise alarms upon the formation or possible formation of cycles [1,6,14,15,23,55], that statically check for cycles through analysis [42,45,57] or through type systems [7,52], or that preclude cycles by carefully limiting the blocking synchronization semantics available to the programmer, either statically or dynamically [10,12,15,50,55]. The present work includes a dynamic, precise cycle detection algorithm, enabled only by the introduction of a structured ownership semantics on the otherwise unrestricted promise primitive.…”

“…Finally, Set(𝑝, 𝑣) achieves rule 4, checking that the current task owns 𝑝 and marking 𝑝 as fulfilled by assigning it no owner (lines [23][24][25]. The procedure then invokes the underlying mechanism for actually setting the promise value to 𝑣 (line 26).…”

Radius aware probabilistic testing of deadlocks with guarantees

“…There are totally 10 test cases and 10 unique deadlocks, covering most of deadlocks cases [39]. All these benchmarks and their test cases have been used in previous works multiple times [15] [22][33] [59] and are available either online [1] [4][5] [7] or from the previous works [33] [59]. Table 1 shows the statistics of all benchmarks, including benchmark names with version numbers (if available), Bug IDs (if available), program size (SLOC [6]), the numbers of threads of each benchmark ("prog") and its threads in each unique deadlock ("dlk"), the number of deadlocks ("#dlks", as a deadlock may have two or more variants) in each benchmark.…”

Dynamic deadlock verification for general barrier synchronisation

“…In general, deadlock avoidance can only disallow actions that lead to a deadlock and inform the culprit task of its error, e.g., Armus throws an unchecked exception. For some synchronisation mechanisms, however, it is possible to preclude schedules that may lead to a deadlock by controlling the lock acquisition order [6,27,51,70]; using transactions to avoid data races which lead to deadlocks with futures [50,72]; executing critical regions as transactions [55]; and adding extra data in streaming computation [45]. To our best knowledge, techniques that avoid deadlocks in the context of barrier synchronisation only handle a few situations of barrier deadlocks, unlike our proposal that is complete (with reference to Theorem 5.11).…”