Boost logo

Threads-Devel :

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-04 15:34:09

Matt Hurd <matt.hurd_at_[hidden]> writes:

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

Great! But now we proceed down the same old road...

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


> Should the concepts attempt to model the platform with a portable interface
> that provides feature availability queries at compile time

Do you have a use case for such queries? Personally I can't imagine
generic code that could use them.

> and just not support non-native features?

I don't get that point.

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

Isn't that the point of a portable threading library?

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

What is a "type of portability?"

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

Irrelevant. The documentation doesn't tell you that boost::mutex is
either of those things, so you have to assume that it isn't. That's
totally appropriate.

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

What are you talking about?

> Yet anything else might impact on the simplicity of implementation,
> especially w.r.t. the use of posix.

I'm now thoroughly lost.

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

If there are platforms where a mutex providing try or timed locks is
more expensive than one that doesn't, then yes.

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


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

There are parts of the design I *really* dislike. I wouldn't want to
standardize it as is. However, I fundamentally disagree that the
design (of the interface) is _fundamentally_ broken.

Dave Abrahams
Boost Consulting

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