|
|
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:
>
> http://www.boost.org/doc/html/threads/concepts.html#threads.concepts.mutexes
...
> 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.
Why?
> 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.
Why?
> 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.
Why?
> Features of physical mutexes should be able to be compile time queries (with
> undefined a potential answer?).
Why?
> A boost::mutex should be a logical mutex. I believe that its physical
> implementation should be a boost::recursive_mutex.
Why?
> This is getting way too distracting and far from the point.
Probably.
> 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 www.boost-consulting.com