On the future of global threadprivate variables in OpenMP

Discuss the OpenMP 3.0 API Specifications with the OpenMP Arch. Review Board. (Read Only)
Forum rules
The OpenMP Forums are now closed to new posts. Please visit Stack Overflow if you are in need of help: https://stackoverflow.com/questions/tagged/openmp
Locked
rrossi

On the future of global threadprivate variables in OpenMP

Post by rrossi »

Hi all,
some time ago i raised a question about global threadprivate variables for general objects:

http://openmp.org/forum/viewtopic.php?f=3&t=552

as apparently i am using a feature of OpenMP 3.0 that is not supported by GCC (nor will be in the future).

An interesting comment was made in the thread:

"threadprivate with constructors/destructors is really hard to implement reliably, because the shared library in which threadprivate objects are present can be dlopened or dlclosed at any time, including a parallel region.
The ctors could be perhaps invoked when the threadprivate/__thread variable is touched for the first time in some thread, but if dlclose is called while the threadprivate object lives in many threads, dlclose would need to signal them all and request dtors to be run in each thread. I wonder what other implementations do here (if they just ignore the problem or solve it somehow)."

i am writing to ask if this issue is likely to be better specified in OpenMP 3.1 or in OpenMP 4.0.

I also would like some comments (possibly non gcc specific) to understand if it is a reasonable expectation that other compilers will allow this ... or not

thanks in advance
Riccardo

ejd
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: On the future of global threadprivate variables in OpenM

Post by ejd »

At this point in time the OpenMP V3.1 spec is available for public comment. I don't believe anything has been added to the specification to cover this. If you feel as though this is something that should be considered, then I recommend that you post a comment in the V3.1 public review forum and it will be reviewed by the committee.

Locked