Basic OpenMP Test Program Not Exiting

[hirschbergerm]

I’m running the following basic parallelized Hello World program in VS Code:

program Hello

  Use omp_lib

  Implicit None

  INTEGER :: nthreads
  nthreads = 4

  CALL OMP_SET_NUM_THREADS(nthreads)

  write(*,*) omp_get_num_procs()
  write(*,*) omp_get_max_threads()
  write(*,*) omp_get_num_threads()

  !$OMP PARALLEL
    PRINT *, "Hello from process: ", OMP_GET_THREAD_NUM()
  !$OMP END PARALLEL

end program Hello

This correctly prints out “Hello from process: X” 4 times, but then the program doesn’t exit. Is this expected behavior? I haven’t found any posts online that address this.

[Arjen]

No, this is not what I would expect. It seems that the call to OMP_SET_NUM_THREADS does not work properly. If I leave it out, the program does finish (on my laptop it uses 24 cores by default). This is the behaviour with gfortran. If I use ifx, thne the original program stops nicely.

One curious thing: with both compilers (and with or without the call to OMP_SET_NUM_THREADS) I get the value 1 for OMP_GET_NUM_THREADS. Odd.

[PierU]

Hello,

Definitely not expected. Which platform/compiler/version are you using?

@Arjen

One curious thing: with both compilers (and with or without the call to OMP_SET_NUM_THREADS) I get the value 1 for OMP_GET_NUM_THREADS. Odd.

This is the normal output of this function if called from outside of a parallel region. It returns the number of threads that are currently active.

[Arjen]

Oops, yes, you’re absolutely right!

[hirschbergerm]

Hey thanks for the reminder, I’ll remember to include platform/compiler/version going forward.

I’m using gfortran 12.3.0. I’m just using the terminal in VS Code Windows 10 64-bit.

EDIT:

Actually I just tested Arjen’s idea of removing OMP_SET_NUM_THREADS() and the program finished executing.

Why would this be the case. It’s not urgent right now, but in the future I think that’s a variable I’d like to be able to control.

[PierU]

@hirschbergerm

I’m using gfortran 12.3.0. I’m just using the terminal in VS Code Windows 10 64-bit.

With gfortran 13.2 under the MSYS2 environment on Windows, this program correctly exits. I suspect some bad interaction (?) between gfortran and VS code.

[quote=“hirschbergerm, post:5, topic:9413”]
Actually I just tested Arjen’s idea of removing OMP_SET_NUM_THREADS() and the program finished executing.

Why would this be the case. It’s not urgent right now, but in the future I think that’s a variable I’d like to be able to control.[/quote]

For performance reasons (I think), it’s generally recommended to set the number of threads using the OMP_NUM_THREADS environment variable once for all rather than using the omp_set_num_threads() routine. That said, it shoud be work… Did you try using the NUM_THREADS() clause instead of the routine?
!$OMP PARALLEL NUM_THREADS(nthreads)

[hirschbergerm]

Using the NUM_THREADS clause fixed the issue for me! Thank you so much!

I wonder why calling omp_set_num_threads() lead to the issue?

[ivanpribec]

Maybe it is this issue

OpenMP and thread-safety of I/Os (write, read...)

Actually I am OK with my current practice of putting all I/Os in critical sections. I was just wondering of the thread-safety of I/Os was covered by the standards (Fortran and/or OpenMP) or not. It seems that the answer is “no” (in which case one should always use critical sections if one wants the code to be portable and not depend on a specific compiler). Do you have a link?

Can you try to use the modified program:

  !$OMP PARALLEL
    !$OMP CRITICAL
    PRINT *, "Hello from process: ", OMP_GET_THREAD_NUM()
    !$OMP END CRITICAL
  !$OMP END PARALLEL

Or maybe this other modification:

!$OMP PARALLEL
   id = omp_get_thread_num()
   print *, "Hello from process: ", id
!$OMP END PARALLEL

Just curious if it changes anything.

[ivanpribec]

Maybe this is relevant too:

The GNU Fortran runtime library uses various C library functions that depend on the locale, such as strtod and snprintf . In order to work correctly in locale-aware programs that set the locale using setlocale , the locale is reset to the default “C” locale while executing a formatted READ or WRITE statement. On targets supporting the POSIX 2008 per-thread locale functions (e.g. newlocale , uselocale , freelocale ), these are used and thus the global locale set using setlocale or the per-thread locales in other threads are not affected. However, on targets lacking this functionality, the global LC_NUMERIC locale is set to “C” during the formatted I/O. Thus, on such targets it’s not safe to call setlocale concurrently from another thread while a Fortran formatted I/O operation is in progress. Also, other threads doing something dependent on the LC_NUMERIC locale might not work correctly if a formatted I/O operation is in progress in another thread.

Source: Thread-safety of the runtime library (The GNU Fortran Compiler)

@PierU

That said, it shoud be work… Did you try using the NUM_THREADS() clause instead of the routine?
!$OMP PARALLEL NUM_THREADS(nthreads)

I don’t see major differences at the application level: Compiler Explorer

[JohnCampbell]

This problem with using CALL OMP_SET_NUM_THREADS(nthreads) was introduced after Gfortran ver 11.1.0 on the Windows version supplied by equation.com
implementation. I have not been able to get a response to reporting this issue.
I have not tested other sources of Windows versions of Gfortran, since 11.1.0.

As noted, using the NUM_THREADS clause fixed the issue, but this requires a rework of all previous codes.

I have previously noted this issue, including at the end of:

OpenMP and FORTRAN

Hi, I put my 30-year old FORTRAN code on 2D Euler-flow turbulence simulations here: It runs fine in my 12-core-CPU-15GB RAM laptop with all cores getting triggered, but wondering if I still missed any trick in optimization like gfortran -O3 -Ofast -openmp hooks. Added openmp stuff like: USE OMP_LIB !$OMP PARALLEL Am I missing any other trick in the book … Thanks, Suki

Non Windows versions do not have this problem.