How are Qopenmp and reentrancy related?

[markus]

Hello,

if an application has OpenMP statements, does it need the "reentrancy" option also?
How are these options related?

Markus

[TimP]

Subroutines and run-time library functions called in parallel regions must be reentrant. /Qopenmp sets the appropriate options implicitly.
Evident differences from serial compilation are the avoidance of local SAVE variables and the requirement for multi-thread libraries. ifort gives local arrays a default SAVE status, unless one of the options Qopenmp, or Qauto is set.
Incidentally, VS2005 and 2008 no longer include libraries which aren't compatible with OpenMP.

[Steven_L_Intel1]

The "reentrancy" option affects the run-time library only. It gets set by default if you say /Qopenmp. As Tim says, /Qopenmp also has the effect of /recursive.

[jimdempseyatthecove]

FWIW

For local arrays, you may find it necessary to explicitly state your intentions

subroutine foo()
real,automatic:: A(3)
...

As Steve stated, the default array storage is SAVE

Jim Dempsey

[Steven_L_Intel1]

... but not if you say /Qopenmp. If you use /Qopenmp the compiler will apply appropriate defaults - it is not necessary to use the AUTOMATIC attribute (which is an extension.)

More important is to understand which variables need to be shared among threads (and protected with synchronization) and which do not. Use of OpenMP constructs such as reductions can help improve performance.

[markus]

Thanks for your fast responses.

I have my local vars "automatic" as default, so I definitely know those which are not.

But I have found I must set /reentrancy explicitely otherwise my OpenMP-program fails with "forrtl: severe (152): unresolved contention for Intel Fortran RTL global resource".

Alternatively it helps to call iret=for_set_reentrancy(for_k_reentrancy_threaded). I did this just one line before the parallel region.

Seems /Qopenmp does not include /reentrancy.

Since /reentrancy is a RTL setting, it is rather confusing that this option is located under "Code Generation" in Visual Studio 2003 and the help text is also speaking of "code generation". The console help (ifort /help) is correct. GUIs are nice, but...

Markus

[Steven_L_Intel1]

There's two (at least!) issues at work. First is to choose whether the libraries being used are thread-safe or not. It would appear that you have to explicitly choose the multithreaded library (this is the /threads command line switch). Then there is generated code that tells the run-time library whether or not to enable thread reentrancy - this is /reentrancy. I know this is confusing.

/Qopenmp does imply /reentrancy:threaded (by my tests), but apparently not the multithreaded libraries. I'll discuss this with the development team to see if this should change. Note that with VS2005, the default is multithread static libraries anyway as there are no single-threaded libraries.

You should not have to call for_set_reentrancy directly, as far as I know.