A Tool for Detecting First Races in OpenMP Programs

Kang, Mun-Hye; Ha, Ok-Kyoon; Jun, Sang-Woo; Jun, Yong-Kee

doi:10.1007/978-3-642-03275-2_29

Cited by 9 publications

(4 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, ARCHER [2] first identifies data race-free code regions (i.e., which do not contain data dependencies) with a static analysis, and then instruments only the remaining, potentially unsafe regions, for data race detection. Another approach is the combination of a thread labeling scheme (to maintain the logical concurrency of thread segments) with the happens-before technique (to analyze the happens-before relations to detect conflicting accesses to every shared memory location) [19,21]. The ThreadSafe [1] tool (for Java code) applies the principles of the lockset algorithm in the setting of a static analysis: locksets are computed for abstract summaries of methods.…”

Section: Related Workmentioning

confidence: 99%

Hunting Superfluous Locks with Model Checking

Nguyên

Serwe

Mateescu

et al. 2019

From Software Engineering to Formal Methods and Tools, and Back

View full text Add to dashboard Cite

Parallelization of existing sequential programs to increase their performance and exploit recent multi and many-core architectures is a challenging but inevitable effort. One increasingly popular parallelization approach is based on OpenMP, which enables the designer to annotate a sequential program with constructs specifying the parallel execution of code blocks. These constructs are then interpreted by the OpenMP compiler and runtime, which assigns blocks to threads running on a parallel architecture. Although this scheme is very flexible and not (very) intrusive, it does not prevent the occurrence of synchronization errors (e.g., deadlocks) or data races on shared variables. In this paper, we propose an iterative method to assist the OpenMP parallelization by using formal methods and verification. In each iteration, potential data races are identified by applying to the OpenMP program a lockset analysis, which computes the set of shared variables that potentially need to be protected by locks. To avoid the insertion of superfluous locks, an abstract, action-based formal model of the OpenMP program is extracted and analyzed using the ACTL on-the-fly model checker of the CADP formal verification toolbox. We describe the method, compare it with existing work, and illustrate its practical use.

show abstract

Section: Related Workmentioning

confidence: 99%

Hunting Superfluous Locks with Model Checking

Nguyên

Serwe

Mateescu

et al. 2019

From Software Engineering to Formal Methods and Tools, and Back

View full text Add to dashboard Cite

show abstract

“…Terboven discussed the limitations of Intel Thread Checker [25] and Sun Thread Analyzer [19] in [32]. Kim et al [16] implemented a race detection tool on shared data structures using labeling schemes and protocol schemes. Basupal li et al…”

Section: Related Workmentioning

confidence: 99%

Symbolic consistency checking of OpenMp parallel programs

Yang

Wang

et al. 2012

Proceedings of the 13th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, Tools and Theory for Embedded Syst

View full text Add to dashboard Cite

We present a symbolic approach for checking consistency of OpenMP parallel programs. A parallel program is consistent if it yields the same result as its sequential version despite the execution order among threads. We find race conditions of an OpenMP parallel program, construct the formal model of its raced segments under relaxed memory models, and perform guided symbolic simulation to search consistency violations. The simulation terminates when (1) a witness has been found (the program is inconsistent), or (2) all reachable states have been explored (the program is consistent). We have developed the tool Pathg by incorporating Omega library to solve race constraints and Red symbolic simulator to perform guided search. We show that Pathg can prove consistency of programs, identify races that modern OpenMP checkers failed to report, and find inconsistency witnesses effectively against benchmarks from the OpenMP Source Code Repository and the NAS Parallel benchmark suite.

show abstract

“…A simplified portion of this GPU kernel code is shown in Figure 3. From the code, we can see that there are four arrays declared in the shared memory (lines 3-7) and there is one nested for loop (lines [8][9][10][11][12][13][14][15][16][17][18][19][20][21][22]. Looking into the memory accesses within those four arrays on shared memory, three of those arrays (rowCS at line 12, Acomp at line 16, and rowQual at line 17) are read-only and the last one (sh rowCL at line 21) is write only.…”

Section: Static Analyzermentioning

confidence: 99%

“…Additionally, researchers also proposed to detect data races using model checking [20], which has the limitation of state explosion problem in general. Furthermore, happensbefore relation has also be applied to detect races in OpenMP programs [22]. Unlike these approaches, our work focuses on detecting races in GPU programs, which have different characteristics to deal with.…”

Section: Related Workmentioning

confidence: 99%

GRace

et al. 2011

View full text Add to dashboard Cite

In recent years, GPUs have emerged as an extremely cost-effective means for achieving high performance. Many application developers, including those with no prior parallel programming experience, are now trying to scale their applications using GPUs. While languages like CUDA and OpenCL have eased GPU programming for non-graphical applications, they are still explicitly parallel languages. All parallel programmers, particularly the novices, need tools that can help ensuring the correctness of their programs.Like any multithreaded environment, data races on GPUs can severely affect the program reliability. Thus, tool support for detecting race conditions can significantly benefit GPU application developers. Existing approaches for detecting data races on CPUs or GPUs have one or more of the following limitations: 1) being illsuited for handling non-lock synchronization primitives on GPUs; 2) lacking of scalability due to the state explosion problem; 3) reporting many false positives because of simplified modeling; and/or 4) incurring prohibitive runtime and space overhead.In this paper, we propose GRace, a new mechanism for detecting races in GPU programs that combines static analysis with a carefully designed dynamic checker for logging and analyzing information at runtime. Our design utilizes GPUs memory hierarchy to log runtime data accesses efficiently. To improve the performance, GRace leverages static analysis to reduce the number of statements that need to be instrumented. Additionally, by exploiting the knowledge of thread scheduling and the execution model in the underlying GPUs, GRace can accurately detect data races with no false positives reported.Based on the above idea, we have built a prototype of GRace with two schemes, i.e., GRace-stmt and GRace-addr, for NVIDIA GPUs. Both schemes are integrated with the same static analysis. We have evaluated GRace-stmt and GRace-addr with three data race bugs in three GPU kernel functions and also have compared them with the existing approach, referred to as B-tool. Our experimental results show that both schemes of GRace are effective in detecting all evaluated cases with no false positives, whereas Btool reports many false positives for one evaluated case. On the one hand, GRace-addr incurs low runtime overhead, i.e., 22-116%, and low space overhead, i.e., 9-18 MB, for the evaluated kernels. On the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

show abstract

A Tool for Detecting First Races in OpenMP Programs

Cited by 9 publications

References 1 publication

Hunting Superfluous Locks with Model Checking

Hunting Superfluous Locks with Model Checking

Symbolic consistency checking of OpenMp parallel programs

GRace

Contact Info

Product

Resources

About