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
> > if it already owns it)? Is it statically-initializable (so it can be
> > in program startup/shutdown code)? These questions demonstrate the need
> > 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)
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk