GRace

Abstract

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.

Structural testing for CUDA programming model

“…Towards identifying faults commonly found in CUDA programs, a comprehensive search of related work focused on testing GPU programs [9][10][11][12][13][14][17][18][19][20][21][22]36,37 was conducted. CUDA programming books and Nvidia reference guide 6,7,38,39 were consulted.…”

“…Boyer, Skadron, and Weimer developed the first to test CUDA programs for race conditions on shared memory 9 by running the program in emulation mode and analyzing the data generated. Other tools such as Grace/GMRace, 10,11 Test Amplification, 36 GPUVerify, 12 LD, 13 BARRACUDA 14 and CURD 15 also focused on detecting race conditions. Alur, Devietti, and Singhania 20 analyzed faults related to the configuration size of thread blocks.…”

“…The literature has progressed regarding the identification of specific faults that may occur in CUDA programs (e.g., race conditions, [9][10][11][12][13][14][15][16][17][18] deadlocks, 17,19 and incorrect size configuration of thread blocks 20 )-several of those studies have employed formal verification or concolic execution techniques to detect them. 16,19,[21][22][23] However, some techniques have been criticized for producing false positives and supporting only small kernels due to the large number of threads expected to run on GPUs.…”

CL-Vis: Visualization Platform for Understanding and Checking the OpenCL Programs

“…Relay was a static race detector based on the locksets that could be scaled to millions of lines of C code [28], and Pacer was low-overhead sampling-based data race detector based on the FastTrack [6]. However, most of these approaches are inapplicable to the GPU because the GPU programs only support the barrier function for synchronization [32].…”

“…Oclgrind is a dynamic simulator, which can identify the race through monitoring the memory accesses [18]. GRace [32] and GMRace [31] are hybrid mechanisms that combine the static and the dynamic ways, reduces the number of statements, and monitors only the survived memory accesses. HAccRG [9] and Hydra [30] designed special kinds of hardware for this problem.…”