Re: Threads

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-04 12:26:56

--- In boost_at_[hidden], scleary_at_j... wrote:
> > > Everyone knows what a "mutex" is.  However, the problem comes 
with the
> > > precise definition of a mutex.  Is it recursive (i.e., can a 
thread lock
> it
> > > if it already owns it)?  Is it statically-initializable (so it 
can be
> used
> > > in program startup/shutdown code)?  These questions demonstrate 
the need
> for
> > > a hard definition even of the simplest of synchronization 
primitives.
> > 
> > Are the implications to saying 'Yes' to both these?
> 
> I don't know.  The point of my message was that we need to flesh 
out all the
> details so we know how we can use it.  Are pthread-mutexes 
recursive?
> AFAIK, there is no way to statically-initialize a mutex 
(CRITICAL_SECTION)
> under Win32.

I don't believe that pthread mutexes (muti?) are recursive.  I'm also 
unaware of any problems specifically with critical sections being 
statically initialized under Win32.  However, most "mutex" 
implementations are C based implementations that require two step 
creation that even when wrapped in a C++ object results in a race 
condition when attempted to be used in this manner.  It would be 
possible to work around such limitations in our library, however.  At 
least to the extent that the language will allow us to... 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.

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...).

> We can use features & generative programming here to define the
> characteristics of the mutex type we want.  The problem comes in 
when
> features are not available for some platforms (e.g., static-init & 
Win32) --
> what do we do then?  My pool<> allocator uses a non-static-init 
mutex, and
> just says that there can't be multiple threads running before main
() starts.
> If we had a static-init mutex, multithreading before main() would be
> acceptable.  So the semantics of another piece of boost can change 
(in a
> subtle way) based on what platform we're running on; there should 
at least
> be a warning to note this (BOOST_COMPILE_TIME_WARN, anyone? :).

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.