0

This is my first time using OpenMP and I feel I have a core misunderstanding in the implementation of the following:

 #include <omp.h>
 #include <stdio.h>

 int main(int argc, char *argv[])  {

 int   i, n;
 float a[100], b[100], result;

 /* Some initializations */
 n = 100;
 result = 0.0;
 for (i=0; i < n; i++) {
   a[i] = i * 1.0;
   b[i] = i * 2.0;
   }

   //pragma statement for omp here 
   for (int i=0; i < n; i++)
     result = result + (a[i] * b[i]);

 printf("Final result= %f\n",result);

 }

The program is designed to calculate a dot product which involves a summation. In this question the person answering suggests using reduction to implement the parallel summation in the for loop using #pragma omp parallel for reduction(+:results) however when experimenting I get the same answer as if I just used #pragma omp parallel for, which naively I assumed to be correct but left me with a feeling of unease as I could not find any documentation saying this isn't correct. An explanation of why I am probably wrong would be helpful.

  • 2
    Your program is not probably wrong, it is certainly wrong. The updates to `result` are made by all threads without synchronisation. The program has a canonical *data race*. So far you've been lucky (yeah, right) enough to not see this. Try increasing `n` to, say, `10^6` and see what happens. – High Performance Mark Jun 20 '17 at 15:32

1 Answers1

3

Using #pragma omp parallel for reduction(+:result) is correct. #pragma omp parallel for is wrong. The latter means that all threads write to result in an unprotected way. It is a classical race condition. In practice, you may very well get the same result by coincidence, for example because the hardware works atomically, the OS doesn't schedule threads on different cores or just pure luck. Don't be fooled, the code is still wrong.

Unfortunately, you cannot prove a code to be correct, just by showing it produces a correct result some times. Just so you cannot show two codes to be equal by testing having them produce the same result a few times. Or in other words, a incorrect code does not always reveal itself easily.

Zulan
  • 21,896
  • 6
  • 49
  • 109