CODEWITHSUNDEEP
cmultithreadingmacosincludeopenmp
Andrew Dalke
Andrew Dalke

Reputation: 15335

What's a better workaround compiling both OpenMP and single-threaded versions of an algorithm?

I use an ugly workaround to compile the same source code once for OpenMP and once for single-threaded code. It includes compiler macros and a double #include of a C file. I'm looking for a better solution.

OpenMP and Mac threads don't mix. This is apparently well-known. Quoting from http://www.imagemagick.org/script/architecture.php#threads .

The OpenMP committee has not defined the behavior of mixing OpenMP with other threading models such as Posix threads. However, using modern releases of Linux, OpenMP and Posix threads appear to interoperate without complaint. If you want to use Posix threads ... from Mac OS X or an older Linux release, you may need to disable OpenMP support within ImageMagick.

I have a Python library with a C extension which scales very nicely with OpenMP, and it really involved only a scattering of #pragma statements and the right compiler flags.

I also develop on Macs. When I use my library in something other than the main thread, I get a segfault. For example, if I use OpenMP support then I can't use my library in Django.

I could of course compile without OpenMP support, but then the single-threaded batch code, which does well with OpenMP, wouldn't work.

I instead want a user-defined function to select at run-time between the OpenMP implementation and the single-threaded implementation.

The only solution I've come up with is a horrible hack where I #include the same C code twice:

#ifdef _OPENMP

#define MYFUNC static int _myfunc_openmp
#include "algorithm.c"
#undef MYFUNC
#define MYFUNC static int _myfunc_single
#include "algorithm.c"

int myfunc(int arg) {
  if (omp_get_num_threads() <= 1) {
      return _myfunc_single(arg);
  } else {
      return _myfunc_openmp(arg);
  }
}

#else

#define MYFUNC int myfunc
#include "algorithm.c"

#endif

and where "algorithm.c" looks like

MYFUNC(int arg) {
#ifdef _OPENMP
  #pragma omp for ...
#endif
   ... algorithm here ...
}

This does work, but it feels like I'm taking the wrong approach.

I tried using OpenMP's "if()" clause, as in

  int in_parallel = (omp_get_num_threads() > 1);
  #pragma omp for ... if(in_parallel)

but that still causes OpenMP on a thread to segfault my program. I presume that it's allocating space for the lock in the critical section of my code, even though it's not needed.

Do you know a better way to have the same algorithm used for both the OpenMP and non-OpenMP code paths?

Upvotes: 2

Views: 374

Answers (1)

Jens Gustedt
Jens Gustedt

Reputation: 78993

If you have C99 (gcc and clang do for that case) you can use the _Pragma operator. It is useful especially inside macros:

#ifdef WITH_OPENMP
# define PARALLEL_FOR _Pragma("omp for")
#else
# define PARALLEL_FOR
#endif

Now you can just prefix the appropriate for loops with that macro, and thus avoid all other the ugly #if/#else in the rest of the code, which make it difficult to maintain.

The double inclusion per se of the file doesn't look wrong to me. Having a special case that is compiled statically without OpenMp avoids any run time decision that OpenMp could try to take.

What I wouldn't do, is passing storage specification, return type and name in one macro. In any case having the two functions visible by the linker costs you nothing, so the static is superfluous. The only thing that you should watch is that linker symbols starting with an underscore are reserved, better rename them to something decent.

Upvotes: 2

Related Questions