如何停止OpenMP 2.0的并行区域

Question

I look for a better way to cancel my threads. In my approach, I use a shared variable and if this variable is set, I just throw a continue. This finishes my threads fast, but threads keep theoretically spawning and ending, which seems not elegant. So, is there a better way to solve the issue ( break is not supported by my OpenMP)?

I have to work with Visual, so my OpenMP Lib is outdated and there is no way around that. Consequently, I think #omp cancel will not work

int progress_state = RunExport;
#pragma omp parallel
{
#pragma omp for
  for (int k = 0; k < foo.z; k++)
  for (int j = 0; j < foo.y; j++)
  for (int i = 0; i < foo.x; i++) {
    if (progress_state == StopExport) {
      continue;
    }

// do some fancy shit 

// yeah here is a condition for speed due to the critical
#pragma omp critical
    if (condition) {
      progress_state = StopExport;
    }
  }
}

Answer 1

You should do it the simple way of "just continue in all remaining iterations if cancellation is requested". That can just be the first check in the outermost loop (and given that you have several nested loops, that will probably not have any measurable overhead).

std::atomic<int> progress_state = RunExport;

// You could just write #pragma omp parallel for instead of these two nested blocks.
#pragma omp parallel
{
#pragma omp for
  for (int k = 0; k < foo.z; k++)
  {
    if (progress_state == StopExport)
      continue;

    for (int j = 0; j < foo.y; j++)
    {
      // You can add break statements in these inner loops.
      // OMP only parallelizes the outermost loop (at least given the way you wrote this)
      // so it won't care here.
      for (int i = 0; i < foo.x; i++)
      {

        // ...

        if (condition) {
          progress_state = StopExport;
        }
      }
    }
  }
}

Generally speaking, OMP will not suddenly spawn new threads or end existing ones, especially not within one parallel region. This means there is little overhead associated with running a few more tiny iterations. This is even more true given that the default scheduling in your case is most likely static , meaning that each thread knows its start and end index right away. Other scheduling modes would have to call into the OMP runtime every iteration (or every few iterations) to request more work, but that won't happen here. The compiler will basically see this code for the threaded work:

// Not real omp functions.
int myStart = __omp_static_for_my_start();
int myEnd = __omp_static_for_my_end();
for (int k = myStart; k < myEnd; ++k)
{
  if (progress_state == StopExport)
    continue;

  // etc.
}

You might try a non-atomic thread-local "should I cancel?" flag that starts as false and can only be changed to true (which the compiler may understand and fold into the loop condition). But I doubt you will see significant overhead either way, at least on x86 where int is atomic anyway.

which seems not elegant

OMP 2.0 does not exactly shine with respect to elegance. I mean, iterating over a std::vector requires at least one static_cast to silence signed -> unsigned conversion warnings. So unless you have specific evidence of this pattern causing a performance problem, there is little reason not to use it.