does OpenMP prohibit a throw inside a parallel region even when not running multithreaded?

First of all, yes, I am aware of answers such as this on SO:

https://stackoverflow.com/q/13663231/2752221

But I don't think it answers my specific question. Here's my situation. I have a loop that I want to parallelize, and for reasons not important here, it is done with #pragma omp parallel followed by #pragma omp for, rather than with #pragma omp parallel for, like so:

#pragma omp parallel default(none) shared(...) if(will_parallelize)
{
	...
								
#pragma omp for schedule(dynamic, 1)
	for (...)
	{

I've elided unimportant details with ellipses, .... The only important thing about the specifics of the above code is the if(will_parallelize) on the #pragma omp parallel directive. We'll return to that in a moment.

Inside the loop, various functions get called, and inside that call tree, at some point there is a critical section, and inside that critical section is code that can raise:

#pragma omp critical (MyName)
{
	... stuff that might raise ...
}

Here's the key point: outside of the parallel region, my code can determine whether or not a raise is possible. If it is possible, I set will_parallelize to false, and so the whole thing runs single-threaded. If no raise is possible, then will_parallelize gets set to true, and the loop runs in parallel.

Here's the problem: when will_parallelize is false, if a raise occurs my program gets terminated with the error:

libc++abi: terminating due to uncaught exception of type std::runtime_error

My understanding was that throwing was only illegal when running parallel, and that if I avoid running parallel, as with my if() above, I can throw. I was expecting the critical section to be a no-op when running single-threaded, such that throwing from within it is OK when running single-threaded. But apparently not...? Or have I confused myself, and something else is actually going on?

If I'm not allowed to raise when I'm inside a parallel region even when my if() test tells it not to run in parallel, what's the recommended fix here? It feels like I would have to actually copy/paste the whole chunk of code with the for loop, and test will_parallelize myself and avoid the #pragma omp parallel altogether, like so:

if (will_parallelize)
{
#pragma omp parallel default(none) shared(...)
	{
		...
								
#pragma omp for schedule(dynamic, 1)
		for (...)
		{
			...
		}
	}
}
else
{
	... DUPLICATED CODE ...
	
	for (...)
	{
		... DUPLICATED CODE ...
	}
}

This is rather awful. But I'm not sure even this would fix the problem, if I'm not allowed to raise when inside an OpenMP construct like #pragma omp critical even when running single-threaded, because remember, the raise is occurring inside a critical region that is deep down in nested function calls. So maybe even doing the above fix wouldn't suffice; maybe I need to do something like this, in that nested function:

if (omp_in_parallel())
{
#pragma omp critical (MyName)
	{
		... stuff that does not raise when we choose to run parallel ...
	}
}
else
{
	... DUPLICATED CODE that might raise when single-threaded ...
}

This is, again, rather awful. I thought the whole design of OpenMP was intended to make it so that the same code would run both single-threaded and multithreaded; but in this case, it seems like the design is not ensuring that, and so I'm fighting OpenMP. Probably my fault. What am I doing wrong?

If it matters, this is on macOS 13.3.1, Xcode 14.3, with whatever version of Apple Clang that implies; I'm not going to tag this question with any of that, though, since my question is really about what the OpenMP spec does and does not allow, and how to work within the parameters of what is allowed without writing ugly duplicated code.

OpenMP is able to be compiled with or without threading depending on whether or not you have omp, but once it's compiled it is set.

A solution could be to "break" rather than throw:

set another variable to track a reason (if you want), set the loop variable to meet the end condition, then continue the loop to break.

int main(int argc,char **argv) {
  bool will_parallelize = true;
  for (int i=0;i<2;++i) {
    if (i) will_parallelize=false;
    int failcode = 0;
    #pragma omp parallel if(will_parallelize)
    {
      #pragma omp for schedule(static, 1)
      for (int x=0;x<20;++x) {
        if (i) { failcode=1; x=19; continue; }
        const int tid = omp_get_thread_num();
        printf("%d:%d\n",tid,x);
      }
      // close off any other place if you want to do more
      if (!failcode) {
        ...
      }
    }
    if (failcode) printf("Error set\n");
  }
}

Also you can try omp cancel construct, but it may slowdown the execution. Also, IIRC it requires turning on special environment variable (OMP_CANCELLATION)

I'm not happy with where I ended up, but as far as I can tell, it's the best option I have, so I'm posting it here.

First of all, it does turn out that you can't throw an exception inside a parallel region whether the region is "active" (using more than one thread) or "inactive" (using only one thread) (but see below more a more precise statement). For critical regions, as far as I can tell, the rules are even more strict – you can't throw an exception inside a critical region at all, period, even if you are not inside a parallel region at all (whether active or inactive). These restrictions seem surprisingly... restrictive. But what do I know, I don't make the rules and there are probably good reasons for them.

In any case, what I just wrote is not quite right – you can throw an exception, it just can't cross outside of the construct you're in (parallel region, critical region, etc.). You need to catch it inside the same construct.

Given those rules, what to do? Where I ended up looks like this:

#ifdef _OPENMP
bool saw_error_in_critical = false;
#endif

#pragma omp critical (MyName)
{
	try {
		... do stuff that might raise ...
	} catch (...) {
#ifdef _OPENMP
		saw_error_in_critical = true;
#else
		throw;
#endif
	}
}

#ifdef _OPENMP
if (saw_error_in_critical)
{
	... raise a new exception ...
}
#endif

So when my program is compiled without OpenMP, it just rethrows any exception that occurs. I could get rid of the try/catch altogether in that case, in fact. These exceptions are rare, so it doesn't really matter, and this way of doing seemed to involve slightly less preprocessor ugliness. When the program is compiled with OpenMP, it catches the exception, sets a flag, and exits the critical region by the natural flow of the code. Once outside the critical region, it throws a new exception. It would be nice if I could throw the same exception, but I haven't figured out how to do that – I think you can't, according to the C++ spec, in fact – so I just throw a new one instead.

I do the same thing for my parallel regions – try/catch, set a flag if we're under OpenMP, and throw again outside the parallel region if the flag is set. It's not pretty, and I wish the OpenMP spec weren't quite so strict about exceptions, but I suppose they have their reasons. This solution seems to work, AFAICT. It lets me retain the overall design of my code (where an exceptional condition inside a deeply nested function can occasionally raise) without massive restructuring, and without violating OpenMP's rules. I could probably define macros for these things that would let me make the code look prettier, but honestly I prefer to see the ugly guts so I can see what's happening explicitly. :->

There is a potential race of sorts, I think, in the sense that one thread could finish the critical region, and then before it gets to the re-throw, another thread comes along and starts executing the critical region, potentially doing stuff with the (presumably) bad state left behind by the previous thread after the exception occurred. For my code, I don't need to worry about that; but I can imagine that that might pose a problem for some other code, so caveat lector. You could probably use a static/global lock or some such, to prevent another thread from entering the critical region until the previous thread has let go of the lock without re-throwing. (At that point, I guess maybe you don't even need the critical region, the lock is doing much the same thing – although without a barrier.)

Oh, and by the way: if you break the rules, and throw inside such a region without catching inside the region, you get an "uncaught C++ exception" runtime error, at least on my platform. So that's nice – you don't just get "undefined behavior" in the general sense, you get something you can break on in the debugger. That was very helpful.