Program Conversion for Detecting Data Races in Concurrent Interrupt Handlers

Lee, Byoung-Kwi; Kang, Mun-Hye; Park, Kyoung Choon; Jin, Yi; Yang, Sang Woo; Jun, Yong-Kee

doi:10.1007/978-3-642-27207-3_45

Cited by 3 publications

(4 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Thus, accesses from different tasks are considered from the same thread since tasks, by definition, are all ordered by happens-before. Similarly, accesses (4) if (any access with a label pLb exists in AH (5) such that pLb = Lb) then return true; (6) else (7) return false; (c) Filtering Redundant Accesses (1) maintain ah(Label Lb, Access History AH) (2) if (Lb.tt = true) then (3) delete all entries in AH with label pLb (4) such that pLb.tt = true (5) else (6) delete all entries in AH with label pLb such (7) that pLb.tt = Lb.tt and pLb.tid = Lb.tid (8) end if (9) add ah(Lb, AH) (d) Maintaining Access History Algorithm 3: Labeling algorithms. from different instances of the same interrupt handler are considered from a single instance of the interrupt handler.…”

Section: Precise Detection Protocolmentioning

confidence: 99%

“…Dynamic data race detection methods are generally classified into on-the-fly [5][6][7][8][9] and postmortem [15,16] techniques. While postmortem techniques collect runtime data for post-execution analysis, on-the-fly techniques on the other hand will dynamically detect data races at runtime.…”

Section: Introductionmentioning

confidence: 99%

“…However, legacy race detectors for multithreaded programs [7][8][9] are very intrusive and cannot directly be applied to interrupt-driven due not only to differences between the programming models, but also to the high overhead they incur. Thus, Lee et al [6] proposed to convert an interruptdriven program into a corresponding multithreaded program and to use an existing dynamic race detection tool to detect data races into the newly generated program. This technique fails to capture the semantics of interrupts and incurs high space and time overheads due to the use of tools basically 2 International Journal of Distributed Sensor Networks designed for multithreaded programs.…”

Section: Introductionmentioning

confidence: 99%

“…Few dynamic race detectors [5, 6] have recently been proposed for detecting data races in interrupt-driven programs. However, legacy race detectors for multithreaded programs [7–9] are very intrusive and cannot directly be applied to interrupt-driven due not only to differences between the programming models, but also to the high overhead they incur.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Verification of Data Races in Concurrent Interrupt Handlers

Tchamgoue

Kim

Jun

2013

International Journal of Distributed Sensor Networks

Self Cite

View full text Add to dashboard Cite

Data races are common in interrupt-driven programs and have already led to well-known real-world problems. Unfortunately, existing dynamic tools for reporting data races in interrupt-driven programs are not only unsound, but they also fail to verify the existence of data races in such programs. This paper presents an efficient and scalable on-the-fly technique that precisely detects, without false positives, apparent data races in interrupt-driven programs. The technique combines a tailored lightweight labeling scheme to maintain logical concurrency between the main program and every instance of its interrupt handlers with a precise detection protocol that analyzes conflicting shared memory accesses by storing at most two accesses for each shared variable. We implemented a prototype of this technique, called iRace, on top of the Avrora simulation framework. An empirical evaluation of iRace revealed the presence of data races in some existing TinyOS components and applications with a worst-case slowdown of only about 6 times on average and an increased average memory consumption of only about 20% in comparison with the original program execution. The evaluation also proved that the labeling scheme alone generates an average runtime overhead of only about 0.4x while consuming only about 12% more memory than the original program execution.

show abstract