Visible to Intel only — GUID: GUID-7202FDEF-0268-4966-A163-E9A08F734754
Visible to Intel only — GUID: GUID-7202FDEF-0268-4966-A163-E9A08F734754
Data Race
Occurs when multiple threads access the same memory location without proper synchronization and at least one access is a write.
Write -> Write Data Race
Occurs when multiple threads write to the same memory location without proper synchronization.
ID |
Code Location |
Description |
---|---|---|
1 |
Allocation site |
If present, and if the memory involved is heap memory, represents the location and associated call stack from which the memory block was allocated. |
2 |
Write |
Represents the instruction and associated call stack of the thread responsible for the first memory write. |
3 |
Write |
Represents the instruction and associated call stack of the thread responsible for the second memory write. |
4 |
HINT: Synchronization allocation site |
If present, represents the location and associated call stack of a synchronization object to protect the first memory write and resolve the Data race problem. |
5 |
HINT: Synchronization allocation site |
If present, represents the location and associated call stack of a synchronization object to protect the second memory write and resolve the Data race problem. |
C Example
Preparation |
CRITICAL_SECTION cs; int *p = malloc(sizeof(int)); // Allocation Site InitializeCriticalSection(&cs); // HINT for first Write |
Thread #1 |
*p = 1; // First Write |
Thread #2 |
EnterCriticalSection(&cs); *p = 2; // Second Write LeaveCriticalSection(&cs); |
If thread #1 and thread #2 are concurrent and there is no other synchronization between thread #1 and thread #2, the Intel Inspector detects a Data race problem because the final value of *p depends on the write order and is therefore non-deterministic.
Fortran Example
Preparation |
include "omp_lib.h" integer(omp_lock_kind) lock integer, allocatable :: x allocate(x) ! Allocation site call omp_init_lock(lock) ! HINT for First Write |
Thread #1 |
x = 1 ! First Write |
Thread #2 |
call omp_set_lock(lock) x = 2 ! Second Write call omp_set_lock(lock) |
If thread #1 and thread #2 are concurrent and there is no other synchronization between thread #1 and thread #2, the Intel Inspector detects a Data race problem because the final value of x depends on the write order and is therefore non-deterministic.
Read -> Write Data Race
Occurs when one thread reads while a different thread concurrently writes to the same memory location without proper synchronization.
ID |
Code Location |
Description |
---|---|---|
1 |
Allocation site |
If present, and if the memory involved is heap memory, represents the location and associated call stack from which the memory block was allocated. |
2 |
Read |
Represents the instruction and associated call stack of the thread responsible for the memory read. |
3 |
Write |
Represents the instruction and associated call stack of the thread responsible for the memory write. |
4 |
HINT: Synchronization allocation site |
If present, represents the location and associated call stack of a synchronization object to protect the memory read and resolve the Data race problem. |
5 |
HINT: Synchronization allocation site |
If present, represents the location and associated call stack of a synchronization object to protect the memory write and resolve the Data race problem. |
C Example
Preparation |
CRITICAL_SECTION cs; int *p = malloc(sizeof(int)); // Allocation Site *p = 0; InitializeCriticalSection(&cs); // HINT for Read |
Thread #1 |
int x; x = *p; // Read |
Thread #2 |
EnterCriticalSection(&cs); *p = 2; // Write LeaveCriticalSection(&cs); |
If thread #1 and thread #2 are concurrent and there is no other synchronization between thread #1 and thread #2, the Intel Inspector detects a Data race problem because the value of *p read by thread #1 depends on when the write by thread #2 occurs and is therefore non-deterministic.
The example shows the case if x = *p occurs in thread #1 before *p = 2 occurs in thread #2.
Fortran Example
Preparation |
include "omp_lib.h" integer(omp_lock_kind) lock integer, allocatable :: x integer y allocate(x) ! Allocation site call omp_init_lock(lock) ! HINT for Read |
Thread #1 |
y = x ! Read |
Thread #2 |
call omp_set_lock(lock) x = 2 ! Write call omp_set_lock(lock) |
If thread #1 and thread #2 are concurrent and there is no other synchronization between thread #1 and thread #2, the Intel Inspector detects a Data race problem because the value of x read by thread #1 depends on when the write by thread #2 occurs and is therefore non-deterministic.
The example shows the case if y = x occurs in thread #1 before x = 2 occurs in thread #2.
About the HINTs
The hints are generated based on the memory and synchronization events in the application, not the logic of the application.
There can be multiple solutions to the problem, and the suggested solution may not be the best solution.
It is up to you to select the best solution.
Possible Correction Strategies
First consider the algorithm. Not all sequential algorithms can run directly in parallel or be parallelized. If the algorithm is sequential in nature and cannot be parallelized, consider changing it to a concurrent algorithm or running the code sequentially.
Privatize memory shared by multiple threads so each thread has its own copy.
For Microsoft Windows* threading, consider using TlsAlloc() and TlsFree() to allocate thread local storage.
For OpenMP* threading, consider declaring the variable in a private, firstprivate, or lastprivate clause, or making it threadprivate.
Consider using thread stack memory.
Synchronize access to the shared memory using synchronization objects.
For Microsoft Windows* threading, consider using mutexes or critical sections.
For OpenMP* threading, consider using atomic or critical sections or OpenMP* locks.