Bug with threadprivate and GCC ... please help!

[rrossi]

Dear List

i am having serious troubles with GCC threadprivate support:

the following (minimal) code compiles correctly using intel compile 10 or 11 (possibly also earlier) but fails miserably using even the gcc4.4.1.
I believe this is a bug in gcc ... please correct me if i am wrong on this.

Is there any way i can get around this ? Otherwise i'll have to abandon gcc for my application

thank you
Riccardo

Code: Select all

#include <iostream>
#include <omp.h>

//this compiles correctly both with Intel and GCC
double c = 1;
#pragma omp threadprivate(c)

//this does not compile ...even with GCC4.4.1!!!!!!!!!!!
class A
{
  public :
  A(){mtmp = 1.0;}
  A(const A& b){mtmp=b.mtmp;}
  ~A(){};
 
  double mtmp;
};

A objA;
#pragma omp threadprivate(objA)


int main( int argc, char* argv[] )
{
  std::cout << "testing omp 3" << std::endl;
}






[rrossi]

Unfortunately the answer is ...

NOT A BUG ... a missing feature

[rrossi]

One year later ... any news on the issue above?

i could not find any bug on this on the gcc bug list so i guess the thing has been fixed. Is this a correct assumption? if so which version should i use?

thank you
Riccardo

[ejd]

I tried this with the compilers I have around (the Intel and Sun compilers) and the program works. I tried compiling it with g++ version 4.4.3 and it still fails. I went out to the gcc bug tracking system (bugzilla) and did a search on threadprivate and found open bug 27557 OpenMP threadprivate directive does not work with non-POD types. It was submitted 2006-05-11 and needed support in glibc and binutils before it could be fixed. That is all the information I have.

[rrossi]

Thank you ejd,
sorry for long silence ... i was off on holidays and i did not spot your answer

it is really a shame that gcc does not support this feature as it effectively prevents many c++ applications.

let's hope it will be fixed sometimes...but it does not look like it is of interest to gcc people

ciao
Riccardo

[ejd]

I will see if I can get a response from one of the gcc developers on this issue.

[jakub]

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).

[rrossi]

Hi Jackub, ejd,

i honestly do not understand the complexity of the compiler internals, but i guess this is a rather hairy issue (for example i am pretty sure i read some warnings on the Sun Compiler documentation about issues that may arise).

Unfortunately the possibility of having threadprivate static (or global) storage is in my opinion an important advantage of OpenMP over say TBB. TBB will never be able to do this sort of things!

In our case this is a performance critical issue since we use this global storage to avoid allocating deallocating millions of times auxiliary objects used as temporary storage inside class public functions.
The thing is that each object in our hierarchy needs different temporary storage ... so there is no way we can know how to handle it outside of the object itself.

Concluding...in my opinion a partial implementation( with less guarantees than it should ) would be far better than no implementation at all. For example in our case we expect this memory to be allocated once at the beginning of the program and to be deallocated on exit...

anyway ... thank you very much for your attention

greetings
Riccardo