Re: Threads

From: scleary_at_[hidden]
Date: 2000-08-04 11:59:19

> > 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 have experience in multithreading under Win32, and some knowledge of
Solaris & POSIX threads (haven't used those since college).  All my
knowledge of POSIX threads pre-dates the acceptance of the standard.  So I
don't expect to have a big part in the development of this library.

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

This makes mutexes, the simplest of primitives, actually fairly complicated.
(OTOH, I think more "complicated" primitives will end up with simpler
feature diagrams).

        -Steve