OpenMP: shared vars and scope

[binky]

Hello, I'm trying to debug an OpenMP/Fortran code and it's quite hard because neither the debuggernor thread checker tell much. So I'm in the dark. PGI compiled code works fine but Intel does not. But that does not mean the code is bug free.

Anyway, the question I wanted to ask is this: when inside a parallel do loop you call a function then localvariables inside it might be saved across calls but there is no guarantee. By default the OpenMP loop assumesthat all the variables in its scopeare shared. So far so good. But when I want to guarantee that my local variable in the calledfunction is saved and put SAVE it suddenly becomes shared across the threads even though it's not explicitly inthe caller's program (lexical) scope. SoIhave toput THREADPRIVATE as well.

I wish the documentation was more clear about different levels of scopes and default sharing behaviour. Is there any nicely put info on that. What about USE? All the docs I've seen talk about vars and COMMONs although the latterare obsolete. What if I USE a module in the callee which is not in the callers scope?

Thanks!

[TimP]

SAVE cannot work in the serial fashion inside a parallel region. This should be almost obvious. The writers of the OpenMP docs tried to make them readable by developers; it's certainly better than the language standards.
Don't accuse COMMON of being obsolete until you prove you have something which works better. I don't know anyone who is willing to eliminate COMMON from a working application.

[binky]

tim18:

SAVE cannot work in the serial fashion inside a parallel region. This should be almost obvious. The writers of the OpenMP docs tried to make them readable by developers; it's certainly better than the language standards.

It was not obvious to me. I figured that out only by trial and error.

Am I right in thinking that if I call a function from a parallel region then by default (DEFAULT(SHARED) in the callee)

• all local variables are PRIVATE
• SAVEd variables are SHARED
• USEd variables are SHARED too ?

If DEFAULT(PRIVATE) thenSAVEd and USEd vars become PRIVATE.

tim18:

Don't accuse COMMON of being obsolete until you prove you have something which works better. I don't know anyone who is willing to eliminate COMMON from a working application.

I agree with the last bit. But Fortran90 was available for quite some time and surely you can do all the right things that COMMON does using modules and USE.

[jimdempseyatthecove]

The scoping rules for local variables of a subroutine/function are not inhereted from the scoping rules of what called the subroutine/function. The passed arguments came from within the callers scoping rules but the declared objects withing the subroutine/function obey the scoping rules as declared with the subroutine/function.

SAVEd vars in a called subroutine/functioncannot be affected by the DEFAULT setting of the calling code. Depending on how the pieces of the program are assembled (linked) and the O/S capabilities the SAVEd vars are either a) global to the context of all call paths into the subroutine/function .OR. b) are global to each Process context calling the subroutine/function. In both of these two situations all threads within a Process will share the same SAVEd variable.

USEd variables on the other hand have a flexibility whereby the programmer can declare the variables either in the context of the module or in the context of a thread private area of the module.

Note, all local variables are not necessarily private. Variables that contain array descriptors may or may not place the data on the stack. The programmer has control over placement generally with the use of the AUTOMATIC attribute. Example: if a parallel loop contains a call to a subroutine and if the subroutine has a local array such as

real :: temp(16)

Then depending on compiler options the memory for temp is either on the stack or in a global function private area (same as for SAVE). To avoid misunderstanding at the source level use either AUTOMATIC or SAVE.

real, automatic :: temp(16)! stack local data

Jim Dempsey