Re: [Threads-devel] Mutexes

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?

Indeed.

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

http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.mutexes

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 
trait)
#  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:

boost::mutex::scoped_lock
boost::recursive_mutex::scoped_lock
boost::try_mutex::scoped_lock
boost::recursive_try_mutex::scoped_lock
boost::timed_mutex::scoped_lock
boost::recursive_timed_mutex::scoped_lock
boost::try_mutex::scoped_try_lock
boost::recursive_try_mutex::scoped_try_lock
boost::timed_mutex::scoped_try_lock
boost::recursive_timed_mutex::scoped_try_lock
boost::timed_mutex::scoped_timed_lock
boost::recursive_timed_mutex::scoped_timed_lock

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

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

matt.