0
votes

I have an OpenMP code that looks like the following

while(counter < MAX)  {
  #pragma omp parallel reduction(+:counter) 
  {
     // do monte carlo stuff
     // if a certain condition is met, counter is incremented

  }
}

Hence, the idea is that the parallel section gets executed by the available threads as long as the counter is below a certain value. Depending on the scenario (I am doing MC stuff here, so it is random), the computations might take long than others, so that there is an imbalance between the workers here which becomes apparent because of the implicit barrier at the end of the parallel section.

It seems like #pragma omp parallel for might have ways to circumvent this (i.e. nowait directive/dynamic scheduling), but I can't use this, as I don't know an upper iteration number for the for loop.

Any ideas/design patterns how to deal with such a situation?

Best regards!

1

1 Answers

1
votes

Run everything in a single parallel section and access the counter atomically.

int counter = 0;
#pragma omp parallel
while(1) {
     int local_counter;
     #pragma omp atomic read
     local_counter = counter;
     if (local_counter >= MAX) {
          break;
     }
     // do monte carlo stuff
     // if a certain condition is met, counter is incremented
     if (certain_condition) {
         #pragma omp atomic update
         counter++;
     }
}

You can't check directly in the while condition, because of the atomic access. Note that this code will overshoot, i.e. counter > MAX is possible after the parallel section. Keep in mind that counter is shared and read/updated by many threads.