[boost] TSD and TLS [was: Re: More threads review]

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-10-18 11:50:00

David Abrahams wrote:
> 
> tss.html - ....

Speaking and/or thinking of TSD and TLS you might want to consider 
the following: (don't miss ISO/EIC "edits" below)

Subject: Re: local statics and TLS objects 
Date: 2002-10-11 05:37:42 PST 

Alexander Terekhov wrote:
>

Well, "thread-private" was a bit confusing. I should have used something 
like "thread-local". Also... Momchil, see yet another "fixed" DCL below.

> < was: Re: volatile -- what does it mean in relation to member functions?
>   comp.lang.c++.moderated >
> 
> James Kanze wrote:
> [...]
> > > > Posix says nothing about C++.  A C++ compiler can do what it wants,
> > > > and not affect Posix compliance.  Still, I can't imagine a C++
> > > > compiler not extending the guarantees of C to cover its operations.
> > > > (It does mean, however, that a fair number of C++ compilers do not
> > > > generate thread safe code, particularly when it comes to
> > > > initializing local statics. [...]
> > > Been there done that. That static local initialization doesn't work in
> > > a lot of compilers is very unfortunate. Since the C++ standard clearly
> > > says that it should be initialized on the first call there's really no
> > > excuse. It doesn't say under which circumstances so this means this
> > > should hold under *any* circumstances and if your compiler even has a
> > > switch to notify it about multithreaded code...
> >
> > I tend to agree with you here. ....
> 
> I disagree. And, BTW, I'd be quite happy to be able to write
> something like:
> 
> ThreadLocalLazySingleton&
>   ThreadLocalLazySingleton::get() // static
> {
>    // Kinda "static" but might throw std::bad_alloc even
>    // if used with throw() [throw nothing] constructor[1].
>    static(thread_private) ThreadLocalLazySingleton thing(/**/);
>    return thing;
> }
> 
> and
> 
> GlobalLazyImmutableSingleton const&
>   GlobalLazyImmutableSingleton::get() // static
> {
>    // Thread shared/safe version of "classic" local static. See
>    // the link below (i.e. it's synchronized using __cxa__guards).
>    static(thread_shared) const GlobalLazyImmutableSingleton thing(/**/);
>    return thing;
> }
> 
> leaving
> 
> ThreadsUnawareGlobalLazySingleton&
>   ThreadsUnawareGlobalLazySingleton::get() // static
> {
>    // This thing is "single threaded" -- NOT meant to use
>    // http://www.codesourcery.com/cxx-abi/abi.html#once-ctor
>    // "sync-guards"/synchronization-by-default
>    static ThreadsUnawareGlobalLazySingleton thing(/**/);
>    return thing;
> }
> 
> alone (with respect to threading)... for things like:
> 
> // Module
> 
> static ReadWriteLock s_lock;
> 
> LazySingletonWithReadWriteAccess*
>   LazySingletonWithReadWriteAccess::s_inst = 0; // set in c-tor
> 
> auto_unlock_ptr< LazySingletonWithReadWriteAccess >
>   LazySingletonWithReadWriteAccess::getForWrite() // static
> {
>   ReadWriteLock::WriteGuard guard( s_lock );
>   static LazySingletonWithReadWriteAccess thing(/**/);
>   return auto_unlock_ptr<
>            LazySingletonWithReadWriteAccess >(&thing,guard);
> }
> 
> auto_unlock_ptr< const LazySingletonWithReadWriteAccess >
>   LazySingletonWithReadWriteAccess::getForRead() // static
> {
>   {
>     ReadWriteLock::ReadGuard guard( s_lock );
>     if ( s_inst )
>       return auto_unlock_ptr<
>          const LazySingletonWithReadWriteAccess >(s_inst,guard);
>   } return getForWrite().degradeToReadOnlyAccess();
> }
> 
> Or am I just missing and/or misunderstanding something?
> 
> How is this currently done by the existing C++ implementations
> that already provide TLS (supporting constructors/destructors)?
> 
> regards,
> alexander.
> 
> [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() );

< was: Re: Talking about volatile and threads synchronization... >

Momchil Velikov wrote:
[...]
> So, the DCL case will looke like this, right ?
> 
> void foo ()
> {
>   static int initialized;
>   int i;
> 
>    i = initialized;
> 
>    /* Read memory barrier, so the above read of ``initialized''
>       is issued before reads of memory, initialized by ``do_stuff''.
>       We may not need this on some architectures. Which ones ? */
>    rmb ();
>    if (i == 0)
>    {
>       lock ();
>       if (initialized == 0)
>       {
>          do_stuff ();
> 
>          /* Write memory barrier - prevent CPU from reordering
>             writes across this point. Necessary (but not
>             necessarily sufficient) to ensure the reader sees
>             the new values written in ``do_stuff''
>             whenever it sees ``initialized'' being nonzero.  */
>          wmb ();
>          initialized = 1;
>       }
>       unlock ();
>    }
> 
>   do_more_stuff ();
> }

Nah, given the following {rather intereseting(*)} 
"ISO/EIC xxxx:xxxx edits": ;-)

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)

So, the DCL case will look like this:

void foo ()
{
  static int initializedGlobal;
  static __thread int initializedThreadLocal;

  if (initializedThreadLocal == 0)
  {
      lock ();
      if (initializedGlobal == 0)
      {
         do_stuff ();
         
         initializedGlobal = 1;
      }
      unlock ();

      initializedThreadLocal = 1;
   }
 
  do_more_stuff ();
}

regards,
alexander.

(*) Does DEC's/Compaq's/NewHP's TLS have the same "semantics" with 
    respect to non-lazy/eager "static" TLS inits -- NOT supporting 
    dynamic initialization/C++ c-tors? What about dlopen(), then?