Atom-Aid: Detecting and Surviving Atomicity Violations

Lucia,; Devietti,; Strauss,; Ceze,

doi:10.1109/isca.2008.4

Cited by 104 publications

(28 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Some race bug detection techniques provide annotation mechanisms for users to specify atomic regions on the target programme code . Other techniques automatically infer an operation block specification by using predefined code patterns or execution patterns . Still, other techniques simply consider executions of function/method body of certain types as operation blocks .An operation block corresponds to an execution of ‘atomic code block’ , ‘unit of work’ or ‘transaction’ that occurs in the literature.…”

Section: Overview Of Race Bug Classificationmentioning

confidence: 99%

“…Figure illustrates an example of a block race bug; operation 21 of Thread 2 interferes the intended data flow on m between operation 11 to operation 12 of Thread 1 . Block race bug is called as ‘AI‐invariant violation’ or ‘atomicity violation’ in the literature. Multi‐data race bug (Section 6)A multi‐data race bug is defined as two operations of two different threads that manipulate data associated memory locations without proper synchronization.…”

Section: Overview Of Race Bug Classificationmentioning

confidence: 99%

See 1 more Smart Citation

A survey of race bug detection techniques for multithreaded programmes

Hong

Kim

2014

Software Testing Verif & Rel

View full text Add to dashboard Cite

SummaryAs multithreaded programmes become popular to fully utilize multicore CPUs, many race bug detection techniques have been developed to find concurrency errors in multithreaded programmes effectively. Because these techniques have different views on target programme execution and detect race bugs of various types, it is difficult to characterize, compare and improve race bug detection techniques. This paper presents a formal execution model, which can uniformly represent various views of race bug detection techniques on target programme execution. Then, this paper classifies 43 race bug detection techniques according to their target race bugs. We classify race bugs on whether or not a bug violates operation block specification and/or data association specification. This survey provides researchers with a clear top‐down view of various race bug detection techniques. In addition, the concrete examples of various race bugs in this survey can help field engineers avoid race bugs in their multithreaded programmes. Copyright © 2014 John Wiley & Sons, Ltd.

show abstract

Section: Overview Of Race Bug Classificationmentioning

confidence: 99%

Section: Overview Of Race Bug Classificationmentioning

confidence: 99%

A survey of race bug detection techniques for multithreaded programmes

Hong

Kim

2014

Software Testing Verif & Rel

View full text Add to dashboard Cite

show abstract

“…This approach constrains program execution all the time to prevent potential manifestations of some concurrency bugs. For example, Atomtracker [21] and AtomAid [17] group instructions into chunks and execute every chunk atomically. This approach constrains interleavings even during correct runs and relies on transactional memory or other custom hardware to achieve good performance.…”

Section: Motivationmentioning

confidence: 99%

“…As we have discussed in Section 4.4, ConAir is incapable of tolerating many kinds of bugs. And the other concurrency bug tolerating methods like Frost [30], LifeTx [36] and AtomAid [17] are all constrained in type of bugs that they can handle, such as data races or atomicity violations. In contrast, AI can tolerate both atomicity and order violations without roll-back and incurs moderate overhead.…”

Section: Related Workmentioning

confidence: 99%

AI: a lightweight system for tolerating concurrency bugs

Zhang

et al. 2014

Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering

View full text Add to dashboard Cite

Concurrency bugs are notoriously difficult to eradicate during software testing because of their non-deterministic nature. Moreover, fixing concurrency bugs is time-consuming and error-prone. Thus, tolerating concurrency bugs during production runs is an attractive complementary approach to bug detection and testing. Unfortunately, existing bug-tolerating tools are usually either 1) constrained in types of bugs they can handle or 2) requiring roll-back mechanism, which can hitherto not be fully achieved efficiently without hardware supports.This paper presents a novel program invariant, called Anticipating Invariant (AI), which can help anticipate bugs before any irreversible changes are made. Benefiting from this ability of anticipating bugs beforehand, our software-only system is able to forestall the failures with a simple thread stalling technique, which does not rely on execution roll-back and hence has good performance Experiments with 35 real-world concurrency bugs demonstrate that AI is capable of detecting and tolerating most types of concurrency bugs, including both atomicity and order violations. Two new bugs have been detected and confirmed by the corresponding developers. Performance evaluation with 6 representative parallel programs shows that AI incurs negligible overhead (< 1%) for many nontrivial desktop and server applications.

show abstract

“…Similarly, Abadi et al [20] use page-level protection to guarantee strong atomicity in software transactional memory. Lucia et al [21] tolerate some degree of atomicity violation with implicit atomicity by grouping consecutive memory operations into atomic blocks. To avoid concurrency bugs, Yu and Narayanasamy [22] constrain thread interleavings in production runs with Lifeguard Transactions (LifeTx).…”

Section: Race Tolerationmentioning

confidence: 99%

Hardware support for enforcing isolation in lock-based parallel programs

Ratanaworabhan

Burtscher

Kirovski

et al. 2012

Proceedings of the 26th ACM International Conference on Supercomputing

View full text Add to dashboard Cite

When lock-based parallel programs execute on conventional multicore hardware, faulty software can cause hard-to-debug race conditions in critical sections that violate the contract between locks and their protected shared variables. This paper proposes new hardware support for enforcing isolation of critical section execution. It can detect and tolerate races, allowing programs to execute race-free. Our hardware scheme targets the existing large code base of lockedbased parallel programs written in type unsafe languages such as C and C++. Our approach works directly on unmodified executables. An evaluation of 13 programs from the SPLASH2 and PARSEC suites shows that the cost of the additional hardware and the impact on the overall execution time is minimal for these applications. Our mechanism is complementary to hardware transactional memory in that it uses similar structures but focuses on enhancing the reliability of existing lock-based programs.

show abstract

Atom-Aid: Detecting and Surviving Atomicity Violations

Cited by 104 publications

References 35 publications

A survey of race bug detection techniques for multithreaded programmes

A survey of race bug detection techniques for multithreaded programmes

AI: a lightweight system for tolerating concurrency bugs

Hardware support for enforcing isolation in lock-based parallel programs

Contact Info

Product

Resources

About