[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: faster pthread_getspecific

phil-list redhat com schrieb am 26.11.02 01:19:05:
> Alexander Terekhov wrote:
> > dank schrieb am 26.11.02 00:40:21:
> > 
> >>Alexander Terekhov wrote:
> >>
> >>>What's "static constructor" ("C++ programs thread-local variables must 
> >>>not require a static constructor.")? Do you mean dynamic initialization?
> >>
> >>I'll take a crack at this, since it seems obvious:
> >>
> >>Static contruction is when you invoke a constructor before main(), e.g.
> >>
> >>static myObject foo;
> >>
> >>This invoks myObject::myObject() early, and is presumably
> >>illegal if myObject contains any native TLS.
> > 
> > Yeah. Now read this:
> > 
> > http://gcc.gnu.org/onlinedocs/gcc/C99-Thread-Local-Edits.html#C99%20Thread-Local%20Edits
> > (ISO/IEC 9899:1999 Edits for Thread-Local Storage)
> > 
> > http://gcc.gnu.org/onlinedocs/gcc/C--98-Thread-Local-Edits.html#C++98%20Thread-Local%20Edits
> > (ISO/IEC 14882:1998 Edits for Thread-Local Storage)
> Got it.  It sounds like that latter document disallows static objects
> containing TLS that require nontrivial constructors or destructors.
> So (as Ulrich points out) it's legal for static objects to contain
> ELF TLS, but only if the TLS members have trivial constructors and destructors.

Sort of. TLS doesn't work with non-static members/stuff, to begin with 
[that's OK]. 

However... The current TLS doesn't work with dynamic initialization and 
nontrivial c-tors/d-tors. The current TLS isn't lazy [as Ulrich seems to 
think]. The current TLS design/Std."edit(s)" is brain-damaged [or I'm an 
idiot], I'm afraid.


P.S. http://groups.google.com/groups?selm=3A53160D.7D2CFA96%40compaq.com

 Some POSIX systems (e.g., Compaq C on Tru64 UNIX) provide the Win32
 language extension __declspec(__thread) storage class. Again, this is
 implemented on top of POSIX thread specific data. For (one definition of)
 efficiency we did add some extensions to the interfaces, to allow declaring
 a constructor function with a key, such that each thread created will start
 out with a value. That means the compiler-generated access code doesn't
 need to check the current value and be prepared to allocate storage and
 call pthread_setspecific() at each point where the value is referenced. (On
 the other hand, it means each thread will construct a value for that key,
 even though it may never use the variable.) The real advantage is in
 allowing the compiler to completely inline TLS access with a small code

P.P.S. http://groups.google.com/groups?selm=348810EC.64727774%40zko.dec.com

"Perhaps what might be more interesting, though, is that the implementation 
 of TLS relies on a new type of TSD key that I invented. Which, in addition 
 to a destructor, has a CONSTRUCTOR called before the thread start routine 
 is called (but within the context of the new thread). The constructor would 
 normally allocate and initialize storage -- but in your case it could add 
 the thread to the list."

P.P.P.S. http://groups.google.com/groups?selm=3DA6C62A.AB8FF3D3%40web.de
         (Subject: Re: local statics and TLS objects)

"> [1] So, basically:
 > extern void operation( Something& );
 > extern(thread_private) Something thing = blah_blah;
 > /* ... */
 > operation( thing );
 > would actually mean something along the lines of:
 > extern void operation( Something& );
 > extern Something& __thing() // throw( std::bad_alloc, ... )
 > {
 >   static(thread_private) Something thing = blah_blah;
 >   return thing;
 > }
 > operation( __thing() ); ...."

"There's really nothing special about ELF (or Tru64) TLS. It's just TSD 
 with a different key space (your dtv array index, or in our case 
 literally a separate TSD key space mapped into the same TCB vector). 
 __tls_get_addr is just pthread_getspecific() with the allocation and 
 initialization of a TSD value built in (because it can find the size and 
 an initialization template automatically). It's nice to have that built 
 in to the compiler and linker, but that's a convenience and nothing 
 radically different." -- Butenhof [http://tinyurl.com/3047]

Ihnen fehlen die richtigen Worte fur Ihre SMS? WEB.DE FreeMail hat die
besten Spruche fur Sie. http://freemail.web.de/features/?mc=021169

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]