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.

Note that Oclgrind can only report data-races that it observes when running a particular instance of a kernel, and so it's possible to have undetected data-races that would only 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.