ThreadPrivate and allocatables

[jimdempseyatthecove]

Steve you will likely be the one answering this

In an application I have various arrays of user defined types. These user defined types contain pointers to other user defined types. The other user defined types contain pointers to arrays. eg;

type TypeThreadContext
SEQUENCE
type(TypeObject), pointer :: pObject
type(TypeTether), pointer :: pTether
type(TypeFSInput), pointer :: pFSInput
integer :: LastObjectLoaded
end type TypeThreadContext
type(TypeThreadContext) :: ThreadContext
COMMON /CONTEXT/ ThreadContext
!$OMP THREADPRIVATE(/CONTEXT/)

Where pTether is a pointer to an element of an array of TypeTether an the element of the array contains a pointer to a different defined types oneof type named TypeFiniteSolution. The type TypeFiniteSolution currently contains pointers to arrays of REAL(8). Due to a discussion of performance issues on a seperate thread I would prefer to have the REAL(8) declared as ALLOCATABLE instead of pointer.

Currently

ThreadContext%pTether%pFiniteSolution%someArray(index)

references an element of an array (assuming pionters initialized correctly)

However, if I declare the someArray as allocatable then I receive an error in the compilation:

Error: Variables containing ultimate allocatable array components cannot appear in COMMON or EQUIVALENCE statement.

I believe this error is in error since the item being common'd/equivalence'd is a pointer and not the eventual array itself.

I can work around this by placing indexes in the thread private context area and than extracting the appropriate pointer on every dereference but this seems rather silly and unnecessary.

Can you explain the reasoning behind this?

Jim Dempsey

[Steven_L_Intel1]

You're asking me to explain the reasoning behind a standard restriction???

All I can say is that the compiler is faithfully, in my opinion, implementing the standard in this regard. Your pointer variable is a variable of derived type with allocatable components - that it also has the POINTER attribute is not called out as an exception in the standard.

I will ask our standards rep about this. The standard forbids allocatable variables of all flavors in COMMON but allows pointers (in general) - why a distinction is made here, I am not sure.

[jimdempseyatthecove]

The particular problem is that THREADPRIVATE is implimented by way of named COMMON block.

Pointer to derived type is valid within the common. The allocatable variable or pointer to allocatable variable within the object being pointed to by the pointer within common is not within the scope of the common, it is within the scope of the object being pointed to. i.e. the array descriptor (in both cases) is not a member of the common data structure (whereas the pointer to the derived type is a member of the common data structure).

If the standard was short sighted and forbids this then please extend !$OMP THREADPRIVATE(...) to include instance of user derived type (as opposed to a named common block), or to a module name.

! **** proposed implementation

module MOD_ThreadPrivate
type MyThreadPrivate
real, allocatable :: Array(:)
real, pointer :: pOtherArray(:)
...
end type MyThreadPrivate
type(MyThreadPrivate) :: aThreadPrivate
!$OMP THREADPRIVATE(aThreadPrivate)
end module MOD_ThreadPrivate

Or

!$OMP THREADPRIVATE(MOD_ThreadPrivate)

Or

!DEC$ ATTRIBUTES:THREADPRIVATE :: MOD_ThreadPrivate
module MOD_ThreadPrivate
...

Jim Dempsey