Data Race Detection

Oclgrind has support for detecting when race conditions have occurred during the execution of a kernel. This feature is not enabled by default, and must be explicitly enabled by passing the --data-races flag to oclgrind. There is a small performance penalty when detecting data-races and you may also experience significantly higher memory usage, so it is recommended to only run small problems when using this feature.

If Oclgrind encounters a data-race while executing your code, it will output a diagnostic message like this:

Read-write data race at global memory address 1000000000004
    Work-item:  Global(2,0,0) Local(0,0,0)
    Work-group: (2,0,0)
    Kernel:     global_read_write_race
      %tmp6 = load i32 addrspace(1)* %arrayidx, align 4, !dbg !26
    At line 6 of input.cl
    
    Race occured with work-item (1,0,0)
      store i32 %tmp6, i32 addrspace(1)* %arrayidx3, align 4, !dbg !26
    At line 6 of input.cl

This indicates the two work-items involved in the race, and which instruction and source-line they were each executing.

There are some limitations with data-race detection which mean that Oclgrind will not be able to catch all data-races. In particular, there are some known issues surrounding detection of races that involve a mixture of atomic and non-atomic operations across different work-groups, and the atomic_cmpxchg builtin is currently excluded from race detection completely. Oclgrind can only report data-races that it observes when running the kernel, and so there could also be many data-races that occur with a different set of inputs or execution configuration.

By default, Oclgrind will ignore data-races where the same data is being written by multiple work-items, since this situation occurs in real codes. To prevent Oclgrind from filtering these races, you can supply the --uniform-writes flag when running it.