Re: Threads

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 
problematic 
> > at best any way, since there's no gaurantee about the order or 
> > concurrency requirements of using static data with multiple 
threads.
> 
> 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 
neither 
> > library need be used for the implementation details here.  (Not 
that 
> > I'm saying they shouldn't or won't be...).
> >
> > The mutex, especially, need not rely on any underlying support 
from 
> > another thread library in it's implementation.  If we're to 
devise a 
> > proper library we may need to ignore the existance of other 
threading 
> > libraries.  Yes, the implications you mention need to be 
discussed 
> > thoroughly, but that's precisely what I'm trying to get started 
here.
> 
> Um. . . if you're talking about doing an entire user-level thread 
library,
> then you've got quite a project ahead of you.  I was thinking of 
something
> more along the lines of a thin-as-possible wrapper over Win32, 
pthreads,
> 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.