Re: Boost.Threads - once functions

From: williamkempf_at_[hidden]
Date: 2001-08-01 08:49:46

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > Any way, the implementation is going to require some 
initialization
> > code that needs to be run only once even if multiple threads 
access
> > the data after it's initialized.  POSIX uses pthread_once to do 
this,
> > but there's no Win32 equivalent.  Instead, Win32 programmers are
> > expected to make use of DllMain to handle this sort of 
initialization
> > and tear down stuff.  There's obvious drawbacks to this approach 
and
> > it's not portable in any event.  So the question is, does
> > Boost.Threads need once functions, and if so what sort of 
interface
> > should we put on it?
> 
> how about some generic singleton template.

A singleton is not the same thing as what we're talking about here 
(though once methods will help in the creation of singletons).  I 
also don't think that any template or base class is ever going to be 
of real benefit in creating singletons, but that's just me.

> ideally,
> in thread-aware C++200x ;) it would be really great
> to be able to write something like:
> 
> Singleton& Singleton::getInstance()
> {
>   static synch Singleton singleton( .... );
>   return singleton;
> }

It would be great to have a synch keyword like this, and if we had 
one there'd be no need for once functions.  However, I doubt the 
language itself is going to be extended in this way, and if it was, 
that doesn't help the current Boost.Threads. :(
 
> (synchronized static locals)
> 
> regards,
> alexander.
> 
> ps. a) linuxthreads has a portable impl. for pthread_once
>        using DCL with memory barriers macros;

I know.  I've looked at the implementation.  We don't have the memory 
barrier stuff, and I don't want to get into that since it's really a 
platform issue, i.e. an implementation detail.
 
>     b) pthreads-win32 uses DCL w/o memory barriers;
>        OK on win32 (IA32; in-order memory model);
>        not so sure with respect to IA64 windows
>        version (out-of-order native memory model)

I dislike the pthreads-win32 implementation because it uses a poor 
implementation of a spin lock.  If the once method does some lengthy 
initialization this implementation could cause some rather poor 
performance results.
 
>     c) completely portable version could
>        be implemented via DCL with ThreadLocals

I've heard this mentioned and would love to see the implementation if 
you've got the algorithm handy.  In any event, this doesn't address 
the actual questions I asked.  First, should there even be once 
methods?  Many think that they are a legacy hack for C short comings 
and that a proper design should never need them.  However, in C++ 
there's often a need for "globals" that are complex objects requiring 
construction and with out once methods it's going to be difficult to 
code such things, so I'm not sure the argument is valid (or to put it 
better, it is valid, but the reasons why it must exist in C remain 
for C++ and not all designs can be modified to eliminate this need).

Second, what interface should we put on such a concept (if we include 
it)?  I think that the same interface as exists with POSIX threads is 
probably the only valid interface we can use, but this is a very C 
like interface so I just wanted to make sure that no one has a 
different design in mind.

Bill Kempf