Accelerating Dynamic Data Race Detection Using Static Thread Interference Analysis

Abstract

Precise dynamic race detectors report an error if and only if more than one thread concurrently exhibits conflict on a memory access. They insert instrumentations at compiletime to perform runtime checks on all memory accesses to ensure that all races are captured and no spurious warnings are generated. However, a dynamic race check for a particular memory access statement is guaranteed to be redundant if the statement can be statically identified as thread interference-free. Despite significant recent advances in dynamic detection techniques, the redundant check remains a critical factor that leads to prohibitive overhead of dynamic race detection for multithreaded programs.In this paper, we present a new framework that eliminates redundant race check and boosts the dynamic race detection by performing static optimizations on top of a series of thread interference analysis phases. Our framework is implemented on top of LLVM 3.5.0 and evaluated with an industry dynamic race detector TSAN which is available as a part of LLVM tool chain. 11 benchmarks from SPLASH2 are used to evaluate the effectiveness of our approach in accelerating TSAN by eliminating redundant interference-free checks. The experimental result demonstrates our new approach achieves from 1.4x to 4.0x (2.4x on average) speedup over original TSAN under 4 threads setting, and achieves from 1.3x to 4.6x (2.6x on average) speedup under 16 threads setting.

MUZZ: Thread-aware Grey-box Fuzzing for Effective Bug Hunting in Multithreaded Programs

“…The reason is that it might be called within multithreading contexts (Line 13 and Line 15)modify is protected by mutex m at Line 15 while unprotected at Line 13. It is worth noting that line 15, although protected by m, may still happen-in-parallel [11,45] with lines 10 and 11. However, since lines 10 and 11 have already been put in L m , we consider it sufficient to help provide more feedback to track thread-interleavings, with line 15 excluded from L m .…”

“…During A :instrumentation ( §4), for a multithreaded program P o , MUZZ firstly computes thread-aware interprocedural control flow graph (ICFG) and the code segments that are likely to interleave with others during execution [11,45], namely suspicious interleaving scope, in §4.1. Based on these results, it performs three instrumentations inspired by §2.3.…”

“…Note that L m is used to emphasize multithreading-relevant paths via instrumentations for state exploration during fuzzing. Therefore the conditions are different from the constraints required by static models (e.g., may-happen-in-parallel [11,45]) or dynamic concurrency-bug detection algorithms (e.g., happens-before [12] or lockset [41]).…”

Analysis of correct synchronization of operating system components

“…При этом экспериментальная оценка Locksmith показала, что он имеет проблемы с масштабируемостью. В [37] авторы представили расширение анализа алиасов Андерсена на случай многопоточных программ. Идея был похожа на подход с раздельным анализом потоков, так как вычислялось множество операторов, которое могло выполняться параллельно, а затем эти операторы применялись к другим потокам.…”

Securing software systems via fuzz testing and verification

“…S1 Instead of equally choosing the entry instruction of a basicblock as the deputy instruction, we apply a stratified exploration-oriented instrumentation by distinguishing whether an instruction may happen-in-parallel with others [93,94]. This helps the fuzzer to track more thread-interleaving transitions.…”