Boost logo

Boost :

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
> > code that needs to be run only once even if multiple threads
> > the data after it's initialized. POSIX uses pthread_once to do
> > but there's no Win32 equivalent. Instead, Win32 programmers are
> > expected to make use of DllMain to handle this sort of
> > and tear down stuff. There's obvious drawbacks to this approach
> > it's not portable in any event. So the question is, does
> > Boost.Threads need once functions, and if so what sort of
> > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at