Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-04 14:24:10

--- In boost_at_[hidden], scleary_at_j... wrote:
> > I'm also
> > unaware of any problems specifically with critical sections being
> > statically initialized under Win32.
> Under pthreads, you can do:
> pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
> Under Win32, there's no such thing.
> > . . . but unless
> > there's a language change then static initialization is
> > at best any way, since there's no gaurantee about the order or
> > concurrency requirements of using static data with multiple
> All static initialization is done before dynamic initialization (and
> therefore before any threads could be created).

I'm not sure this works even in pthreads (though I'm not as familiar
with them or with this particular issue). C++ uses constructors
during initialization of objects, which is code that could well
create a thread. I don't see how this can be prevented.

> > Regardless, I don't see how any of this applies here, since
> > library need be used for the implementation details here. (Not
> > I'm saying they shouldn't or won't be...).
> >
> > The mutex, especially, need not rely on any underlying support
> > another thread library in it's implementation. If we're to
devise a
> > proper library we may need to ignore the existance of other
> > libraries. Yes, the implications you mention need to be
> > thoroughly, but that's precisely what I'm trying to get started
> Um. . . if you're talking about doing an entire user-level thread
> then you've got quite a project ahead of you. I was thinking of
> more along the lines of a thin-as-possible wrapper over Win32,
> etc.

A wrapper, especially a "thin as possible wrapper" isn't a good
approach. Boost hopes to define existing practice that may at least
be considered for inclusion by the language standard. Not all
platforms have a thread library that could be leveraged here, so the
library design must allow for implementations on platforms with out a
thread library. Plus, the differences between the libraries that do
exist will make it difficult to have a "thin wrapper" that will work
for all. In the case of the mutex, especially, the existing
libraries need not be considered since the implementation can be
easily done using a spin lock with out any ill ramifications to
existing thread libraries. Things will get more problematic as we
move along to other parts of any thread library... especially the
thread creation and scheduling routines.

In a nut shell, I fully expect that at least initially we will be
wrapping existing thread libraries, but the design must exclude
library specific issues as much as possible. After all, they are
simply an implementation detail.

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