AtomRace: data race and atomicity violation detector and healer

2009

Data races are one of the most common and subtle causes of pernicious concurrency bugs. Static techniques for preventing data races are overly conservative and do not scale well to large programs. Past research has produced several dynamic data race detectors that can be applied to large programs. They are precise in the sense that they only report actual data races. However, dynamic data race detectors incur a high performance overhead, slowing down a program's execution by an order of magnitude.

ETRI Journal, 2016

He currently leads many projects funded by the Korean government and industry. His research interests include software safety, software testing, quality-driven software development, embedded software design, and mining software repositories.

2008

Data races are one of the most common and subtle causes of pernicious concurrency bugs. Static techniques for preventing data races are overly conservative and do not scale well to large programs. Past research has produced several dynamic data race detectors that can be applied to large programs and are precise in the sense that they only report actual data races. However, these dynamic data race detectors incur a high performance overhead, slowing down a program's execution by an order of magnitude.

Data races represent the most notorious class of concurrency bugs in multithreaded programs. To detect data races precisely and efficiently during the execution of multithreaded programs, the epoch-based FastTrack technique has been employed. However, FastTrack has time and space complexities that depend on the maximum parallelism of the program to partially maintain expensive data structures, such as vector clocks. This paper presents an efficient algorithm, called iFT, that uses only the epochs of the access histories. Unlike FastTrack, our algorithm requires í µí±‚(1) operations to maintain an access history and locate data races, without any switching between epochs and vector clocks. We implement this algorithm on top of the Pin binary instrumentation framework and compare it with other on-the-fly detection algorithms, including FastTrack, which uses a state-of-the-art happens-before analysis algorithm. Empirical results using the PARSEC benchmark show that iFT reduces the average runtime and memory overhead to 84% and 37%, respectively, of those of FastTrack.

2013 25th Chinese Control and Decision Conference (CCDC), 2013

The industry of software applications has been increased significantly because of the high demand of using the software applications. This revolution leads on developing many concurrent software systems. Noticeably, some of these concurrent software systems have falsely report data race condition to one or more of their shared variables. Debugging such concurrent software systems to find the race condition is a challenge, especially for large and complex software systems. Since the race condition concerned mostly ignored in the concurrent software systems, adopting it could help to ensure the efficiency of these software systems. There are few detector tools that have been known in the industry focusing on data race detectors. This paper aims to study those tools. We are going to conduct empirical study of data race using well known tools in order to measure the correctness, performances and effectiveness of those tools in practical by using some benchmarks. Those benchmarks will be tested on each tool and compare it with others to see the similarity and differentiate.

2010

Bugs in concurrent programs are extremely difficult to find and fix during testing. In this paper, we propose Kivati, which can efficiently detect and prevent atomicity violation bugs. Kivati imposes an average run-time overhead of 19%, which makes it practical to deploy on software in production environments. The key attribute that allows Kivati to impose this low overhead is its use of hardware watchpoints, which can be found on most commodity processors. Kivati combines watchpoints with a simple static analysis that annotates regions of codes that likely need to be executed atomically. The watchpoints are then used to monitor these regions for interleaving accesses that may lead to an atomicity violation. When an atomicity violation is detected, Kivati dynamically reorders the access to prevent the violation from occurring. Kivati can be run in prevention mode, which optimizes for performance, or in bug-finding mode, which trades some performance for an enhanced ability to find bugs. We implement and evaluate a prototype of Kivati that protects applications written in C on Linux/x86 platforms. We find that Kivati is able to detect and prevent atomicity violation bugs in real applications, and imposes very reasonable overheads when doing so.

IEEE Micro, 2009

Writing shared-memory parallel programs is error-prone. Among the concurrency errors that programmers often face are atomicity violations, which are especially challenging. They happen when programmers make incorrect assumptions about atomicity and fail to enclose memory accesses that should occur atomically inside the same critical section. If these accesses happen to be interleaved with conflicting accesses from different threads, the program might behave incorrectly. Recent architectural proposals arbitrarily group consecutive dynamic memory operations into atomic blocks to enforce memory ordering at a coarse grain. This provides what we call implicit atomicity, as the atomic blocks are not derived from explicit program annotations. In this paper, we make the fundamental observation that implicit atomicity probabilistically hides atomicity violations by reducing the number of interleaving opportunities between memory operations. We then propose Atom-Aid, which creates implicit atomic blocks intelligently instead of arbitrarily, dramatically reducing the probability that atomicity violations will manifest themselves. Atom-Aid is also able to report where atomicity violations might exist in the code, providing resilience and debuggability. We evaluate Atom-Aid using buggy code from applications including Apache, MySQL, and XMMS, showing that Atom-Aid virtually eliminates the manifestation of atomicity violations.

International Journal of Parallel Programming, 2018

Among the various types of concurrency bugs, the data race is one of the primary causes of other concurrency bugs. Thus, it is important to detect as many data races as possible during the development step of multithreaded programs. A hybrid data race detection technique that uses the Lockset algorithm and happens-before relation, can detect actually occurred and hidden data races in one execution trace. However, high runtime slowdown obstructs the frequent use of hybrid detectors. In this paper, we empirically demonstrate that most data race bugs are caused by the absence of a lock, and that multiple locks are rarely involved in a data race bug in the real world. Thus, we propose a fast hybrid detection algorithm that does not introduce additional false positives and false negatives to the current hybrid detectors. The suggested algorithm replaces the lock-set intersection by a simple comparison operation that focuses on exploring data-race-prone locking patterns. The experimental results indicate that the proposed algorithm detects the same data races as Multilock-HB, which is the most accurate hybrid detector, with a 1.18× slowdown of FastTrack for eight large-scale benchmark programs.

Proceedings of the 19th international conference on Architectural support for programming languages and operating systems, 2014

Researchers have proposed always-on data-race exceptions as a way to avoid the ill effects of data races, but slow performance of accurate dynamic data-race detection remains a barrier to the adoption of always-on data-race exceptions. Proposals for accurate low-level (e.g., hardware) data-race detection have the potential to reduce this performance barrier. This paper explains why low-level data-race detectors are wrong for programs written in high-level languages (e.g., Java): they miss true data races and report false data races in these programs. To bring the benefits of low-level datarace detection to high-level languages, we design low-level abstractable race detection (LARD), an extension of the interface between low-level data-race detectors and run-time systems that enables accurate language-level data-race detection using low-level detection mechanisms. We implement accurate LARD data-race exception support for Java, coupling a modified Jikes RVM Java virtual machine and a simulated hardware race detector. We evaluate our detector's accuracy against an accurate dynamic Java data-race detector and other low-level race detectors without LARD, showing that naïve accurate low-level data-race detectors suffer from many missed and false language-level races in practice, and that LARD prevents this inaccuracy.

2000

We present a precise data race detection for programs with procedures, threads and monitors. Our program model abstracts away guarded branching by nondeterministic branching. The main result of this paper is that the problem of deciding whether the program has a datarace is NP-complete, and that the main source of complexity is the number and nesting of monitors rather than