On 8/22/07, Howard Hinnant <hinnant@twcny.rr.com> 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