Atomizer: a dynamic atomicity checker for multithreaded programs (2004)
Cached
Download Links
- [www.cs.williams.edu]
- [www.cs.uoregon.edu]
- [sp09.pbwiki.com]
- DBLP
Other Repositories/Bibliography
| Venue: | In POPL |
| Citations: | 164 - 14 self |
BibTeX
@INPROCEEDINGS{Flanagan04atomizer:a,
author = {Cormac Flanagan and Stephen N. Freund},
title = {Atomizer: a dynamic atomicity checker for multithreaded programs},
booktitle = {In POPL},
year = {2004},
pages = {256--267}
}
Years of Citing Articles
OpenURL
Abstract
Ensuring the correctness of multithreaded programs is difficult, due to the potential for unexpected interactions between concurrent threads. We focus on the fundamental non-interference property of atomicity and present a dynamic analysis for detecting atomicity violations. This analysis combines ideas from both Lipton’s theory of reduction and earlier dynamic race detectors such as Eraser. Experimental results demonstrate that this dynamic atomicity analysis is effective for detecting errors due to unintended interactions between threads. In addition, the majority of methods in our benchmarks are atomic, supporting our hypothesis that atomicity is a standard methodology in multithreaded programming. 1 The Need for Atomicity Multiple threads of control are widely used in software development because they help reduce latency and provide better utilization of multiprocessor machines. However, reasoning about the correctness of multithreaded code is complicated by the nondeterministic interleaving of threads and the potential for unexpected interference between concurrent threads. Since exploring all possible interleavings of the executions of the various threads is clearly impractical, methods for specifying and controlling the interference between concurrent threads are crucial for the development of reliable multithreaded software. Much previous work on controlling thread interference has focused on race conditions, which occur when two threads simultaneously access the same data variable, and at least one of the accesses is a write [1]. Unfortunately, the absence of race conditions is not sufficient to ensure the absence of errors due to unexpected interference between threads. As a concrete illustration of







