# Is a race condition with no downside still a race condition?

I am writing a piece of code which takes the difference between two numbers, finds that location in memory, and then sets the location to true.

Currently my method of performing this is as follows. Note the function i_jlocation just does the comparison.

``````    #pragma omp parallel for collapse(2)
for(int particleRow = 0; particleRow < numberOfDipolesI; particleRow++)
{
for(int particleColumn = 0; particleColumn < numberOfDipolesJ; particleColumn++)
{
int ijx , ijy , ijz;
//
// Find location
//
i_jlocation(objData.dimensions,dipolePositionsI,dipolePositionsJ,particleRow,particleColumn,&ijx,&ijy,&ijz);

int truePos = ijx*2*2*objData.dimensions[1]*objData.dimensions[2]+ijy*2*objData.dimensions[2]+ijz;
//#pragma omp critical (flipCrit)
{
temp[truePos] = true;
}

}
}
``````

Now in this piece of code I recognise that if I am to write true to that data block, there are many possible combinations of `particleRow` and `particlecolumn` which could lead to a race condition to any cell of memory. If I use the critical section above then the code will take ~180 seconds to complete using 12 cores, whereas without a critical section it is ~5 seconds. Now from my understanding of a race condition you get write-write and read-write races which could cause problems if different data is being input/read. However, I can guarantee that the data being input will always be the same. This means that no matter which order this occurs in, the outcome will never change.

Would this be considered an acceptable time to ignore a race condition? Personally I feel this is not acceptable, but I am struggling to find an algorithmic way to avoid hitting the same cell twice, and the speed increase is a necessity due to the HPC nature of the problem I am trying to tackle.

• Depends on the language. I think in C++11, a data race is undefined behaviour, so you have to use relaxed atomics or something. Dec 13, 2018 at 7:14