Boost logo

Threads-Devel :

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2006-03-02 09:50:31

On Thursday 02 March 2006 11:15, David Abrahams wrote:
> Anthony Williams <anthony_at_[hidden]> writes:
> > I thought I'd start off some discussion about mutexes, to inaugurate
> > our new mailing list.
> >
> > The mutex is the basic synchronization primitive for shared-memory
> > threading models, such as that of boost.thread, so it is very
> > important that the model, and implementation, is sound. With a
> > working mutex, you can build more pexpressive synchronization
> > mechanisms, such as the smart shared pointers proposed by Roland.
> I think it's great to discuss these things, and we should probably
> pursue them. That said, and I hate to be a killjoy, don't we need to
> focus on the library reimplementation and stabilization before we look
> at new design ideas?


Though I still wonder if the boost mutex concept is all wrong:

Fundamentally a mutex is simply a lockable dude.

It's locking strategy may have the following policies:
# rescursiveness: yes, no, whater_is_minimal_for_my_platform ( should be
diagnosable by trait at compile time ).
# recursive_checkedness: yes, no, unspecified (should be diagnosable by
# scheduling policy (all current mutex types are unspecified which is fine
but the platform should allow it to be queried)

How should the try and timed aspects really relate to a mutex as they are part
of the locking interface but may impact the mutex housekeeping state but
should they?

What should the relationship with conditions really be? Is there just a
single type of mutex that is to be supported by a condition var?

Should the concepts attempt to model the platform with a portable interface
that provides feature availability queries at compile time and just not
support non-native features?

Should there be a fundamental base of feature that is supported across all
platforms or even all features supported by all platforms in a portable way?

The current models supported by boost are:


Such specification is crying out for a different, policy like interface.

The type of portability being offerred by boost.thread really needs to be
thought about and agreed to.

Currently it is a strange mix of concepts that result in you requiring
knowledge of the implementation. For example, is your boost::mutex really
recursive or checked?

I'm now of the opinion that boost's default boost::mutex should be a recursive

I don't like the fact that boost::mutex, boost::try_mutex and
boost::timed_mutex have unspecified locking strategies that result in
undefined behaviour. Yet anything else might impact on the simplicity of
implementation, especially w.r.t. the use of posix.

Should the try and timed concepts really have anything to do with the mutex?

Boost current supplies:
   1. boost::mutex
   2. boost::recursive_mutex
   3. boost::try_mutex
   4. boost::recursive_try_mutex
   5. boost::timed_mutex
   6. boost::recursive_timed_mutex

I think there needs to be a distinction between physical and logical mutexes.

Features of physical mutexes should be able to be compile time queries (with
undefined a potential answer?).

A boost::mutex should be a logical mutex. I believe that its physical
implementation should be a boost::recursive_mutex.

I'm not convinced timed and try are really part of a mutex concept I can see
arguments for and against.

This is getting way too distracting and far from the point.

I think we probably have to just ignore this kind of argument for the time
being, bite our tongues, re-implement the library as-is and then consider
rewriting and perhaps throwing the whole thing out and starting again. It
does seem to be kind of frustrating to redo something that seems
fundamentally broken though...


Threads-Devel list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at