Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2007-08-22 14:59:00

On 8/22/07, Howard Hinnant <hinnant_at_[hidden]> wrote:
> Vendor C, with the best of intentions, decides that the release build
> of the std::lib should contain this checking (std::lib vendors
> including debug checks in release builds should sound familiar to many
> of you).  Now we have goal #3, but have lost goal #1, and there is no
> wrapper we can use to get it back.
>
> How do we prevent, or at least discourage, Vendor C from taking this
> path?
>
> One answer would be to eliminate the condition constructor taking a
> mutex.
<snip>
> Now you can *only* wait on a std::condition with a std::mutex (or a
> lock referencing a std::mutex).  There is no error checking.  There is
> no generalizing to shared_mutex.  The good news is that a more general
> (templated) g_condition<Mutex> can be built on top of such a
> std::condition.  The bad news is that it is sufficiently error prone
> that Anthony, Peter, and myself have all made very subtle multithread
> mistakes in implementing the generalized condition.  This is not
> something that is trivial to reinvent.  The correct (as far as I know)
> code for the general condition is freely available:
>
>     http://home.twcny.rr.com/hinnant/cpp_extensions/condition
>
> The source isn't that long.  But I repeat, it is subtle.

This is exactly the sort of thing I try to avoid.  Very direct and
obvious multithreading code is hard to get right; why would I want to
mess with subtle multithreading code?

> So, those of you who were very much in favor of goal #1 (zero
> overhead), and/or goal #3 (run time consistency checking), this is
> your chance to make lots of noise.  These goals are in danger of being
> dropped.

In case it wasn't obvious from my previous emails, I am in this camp.
I think that the zero-overhead goal is important for the same reason
that the STL should try to be as efficient as low-level data
structures whenever possible -- to allow people to use abstractions
without paying high penalties.  Goal #3 is useful because every bit of
checking helps make this difficult type of programming a bit easier to
get right.

I find these arguments so fundamental I have a hard time expressing
them.  I'd like to know what objections people have to these as goals,
per se.  As goals I think they're bang-on, and from Howard's responses
to the comments in this thread, I think the rest of the design flows
inherently from these goals.  Could the folks who object to the
current design spell it out for me a bit more explicitly -- what in
the design is dangerous/inconvenient enough to throw away one or more
of the 4 goals?

Zach Laine