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 (or exporting OCLGRIND_DATA_RACES=1). 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 0x1000000000004
    Kernel: global_read_write_race

    First entity:  Global(2,0,0) Local(0,0,0) Group(2,0,0)
      %tmp11 = load i32 addrspace(1)* %tmp10, align 4, !dbg !23
    At line 6 of input.cl
      data[i] = data[i-1];
    
    Second entity: Global(1,0,0) Local(0,0,0) Group(1,0,0)
      store i32 %tmp11, i32 addrspace(1)* %tmp15, align 4, !dbg !23
    At line 6 of input.cl
      data[i] = data[i-1];

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.