Bug with threadprivate and GCC ... please help!

General OpenMP discussion

Bug with threadprivate and GCC ... please help!

Postby rrossi » Mon Jul 27, 2009 2:20 am

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
 
Posts: 8
Joined: Mon Jul 27, 2009 2:07 am

Re: Bug with threadprivate and GCC ... please help!

Postby rrossi » Wed Jul 29, 2009 11:39 am

Unfortunately the answer is ...

NOT A BUG ... a missing feature :-(
rrossi
 
Posts: 8
Joined: Mon Jul 27, 2009 2:07 am

Re: Bug with threadprivate and GCC ... please help!

Postby rrossi » Sat Aug 14, 2010 8:48 am

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
rrossi
 
Posts: 8
Joined: Mon Jul 27, 2009 2:07 am

Re: Bug with threadprivate and GCC ... please help!

Postby ejd » Mon Aug 16, 2010 7:18 am

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.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: Bug with threadprivate and GCC ... please help!

Postby rrossi » Tue Aug 31, 2010 10:20 am

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
rrossi
 
Posts: 8
Joined: Mon Jul 27, 2009 2:07 am

Re: Bug with threadprivate and GCC ... please help!

Postby ejd » Tue Aug 31, 2010 11:06 am

I will see if I can get a response from one of the gcc developers on this issue.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: Bug with threadprivate and GCC ... please help!

Postby jakub » Tue Aug 31, 2010 11:31 am

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).
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Bug with threadprivate and GCC ... please help!

Postby rrossi » Tue Aug 31, 2010 11:59 am

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
rrossi
 
Posts: 8
Joined: Mon Jul 27, 2009 2:07 am


Return to Using OpenMP

Who is online

Users browsing this forum: Google [Bot] and 9 guests