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
> One answer would be to eliminate the condition constructor taking a
> 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:
> 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
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk