Pacman: Tolerating asymmetric data races with unintrusive hardware

Qi, Shanxiang; Otsuki, Norimasa; Nogueira, Lois Orosa; Muzahid, Abdullah; Torrellas, Josep

doi:10.1109/hpca.2012.6169039

Cited by 13 publications

(8 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This section compares and contrasts the two other isolation enforcement techniques most closely related to ours, transactional memory (TM) and PACMAN [8]; the former is a well-studied technique whereas the latter is quite new.…”

Section: Discussionmentioning

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

Section: Discussionmentioning

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

show abstract

“…It is possible that different threads executing on different contexts of the same processor concurrently execute different IF statements. In this case, HW-IF can use an approach similar to the one described by Pacman [28]. The approach requires an extension where the messages sent by processors to the AWT include both the processor ID and the hardware context ID within the processor.…”

Section: Hw-if Implementation Issuesmentioning

confidence: 99%

“…Some techniques try to avoid data races at runtime (e.g., [6,28,29,30,42]). In particular, ToleRace [30] and ISO-LATOR [29] focus on asymmetric races, where a wellsynchronized thread inside a critical section has a race with a second thread lacking proper synchronization.…”

Section: Specialized Data Race Detectorsmentioning

confidence: 99%

See 1 more Smart Citation

Dynamically detecting and tolerating IF-Condition Data Races

Muzahid

Ahn

et al. 2014

2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA)

Self Cite

View full text Add to dashboard Cite

An IF-Condition Invariance Violation (ICIV) occurs when, after a thread has computed the control expression of an IF statement and while it is executing the THEN or ELSE clauses, another thread updates variables in the IF's control expression. An ICIV can be easily detected, and is likely to be a sign of a concurrency bug in the code. Typically, the ICIV is caused by a data race, which we call IF-Condition Data Race (ICR).In this paper, we analyze the data races reported in the bug databases of popular software systems and show that ICRs occur relatively often. Then, we present two techniques to handle ICRs dynamically. They rely on simple code transformations and, in one case, additional hardware help. One of them (SW-IF) detects the races, while the other (HW-IF) detects and prevents them. We evaluate SW-IF and HW-IF using a variety of applications. We show that these new techniques are effective at finding new data race bugs and run with low overhead. Specifically, HW-IF finds 5 new (unreported) race bugs and SW-IF finds 3 of them. In addition, 8-threaded executions of SPLASH-2 codes show that, on average, SW-IF adds 2% execution overhead, while HW-IF adds less than 1%.

show abstract

“…Figure 5 summarizes the number of concurrency bugs according to the category. From a total of 351 bug reports, almost half of them (i.e., 47%) concern data races (or race conditions), a well-known and common concurrent bug [27], while only two bug reports (< 1% of the reports) were identified as Livelock.…”

Section: Rq1: How Common Are Different Types Of Concurrency Bugs Compmentioning

confidence: 99%

Concurrency bugs in open source software: a case study

Asadollah

Sundmark

Eldh

et al. 2017

J Internet Serv Appl

View full text Add to dashboard Cite

Concurrent programming puts demands on software debugging and testing, as concurrent software may exhibit problems not present in sequential software, e.g., deadlocks and race conditions. In aiming to increase efficiency and effectiveness of debugging and bug-fixing for concurrent software, a deep understanding of concurrency bugs, their frequency and fixing-times would be helpful. Similarly, to design effective tools and techniques for testing and debugging concurrent software, understanding the differences between non-concurrency and concurrency bugs in real-word software would be useful. This paper presents an empirical study focusing on understanding the differences and similarities between concurrency bugs and other bugs, as well as the differences among various concurrency bug types in terms of their severity and their fixing time, and reproducibility. Our basis is a comprehensive analysis of bug reports covering several generations of five open source software projects. The analysis involves a total of 11860 bug reports from the last decade, including 351 reports related to concurrency bugs. We found that concurrency bugs are different from other bugs in terms of their fixing time and severity while they are similar in terms of reproducibility. Our findings shed light on concurrency bugs and could thereby influence future design and development of concurrent software, their debugging and testing, as well as related tools.

show abstract

Pacman: Tolerating asymmetric data races with unintrusive hardware

Cited by 13 publications

References 35 publications

Hardware support for enforcing isolation in lock-based parallel programs

Hardware support for enforcing isolation in lock-based parallel programs

Dynamically detecting and tolerating IF-Condition Data Races

Concurrency bugs in open source software: a case study

Contact Info

Product

Resources

About