On Aug 21, 2007, at 5:14 PM, Peter Dimov wrote:
Howard Hinnant wrote:
Did I make more sense this time? I often complain when people use too much English and not enough C++ in their arguments, and then I find myself being guilty of the same thing. :-)
Hmmm. Maybe I need to heed this advice as well.
<snipped much appreciated code example> :-) No, not ignoring your suggestion. Still contemplating it. Of all the condition suggestions I've heard (not just here, but over the past month or so) I like yours second best. ;-) I'm concerned that we would be relegating goal #3:
1. Minimum size - performance overhead. 2. The freedom to dynamically associate mutexes with condition variables. 3. The ability to apply run time check consistency concerning the associated mutex. 4. The ability to wait on general mutex / lock types.
to a non-standard-mandated debug library. In your favor, I believe most current vendors are supplying debug libs. However the checks are not uniform. Even the error reporting mechanism isn't uniform. And (thanks Zach): On Aug 21, 2007, at 4:41 PM, Zach Laine wrote:
- The ability to add runtime checking to the mutexes/locks used with conditions, via the one-argument condition ctor. Without this sort of automatic checking, you're relegated to correctness by inspection. Writing multithreaded code is hard enough; automated correctness checks are always welcome.
- The condition memory overhead solution in Q17, for the reason you state. If this sort of efficiency is not transparently possible with the high-level tools, one may be forced/encouraged to use lower level tools instead.
Additionally, and I haven't come up with a compelling use case yet (which is why I hadn't and still shouldn't be responding yet), there may be a use case where your "My Library" interface design exposes the condition in such a way that even after you're fully debugged, it is possible for clients to use your library in such a way as to get the cv/mutex binding wrong (unlike the shared_mutex example). So then, if you wanted to maintain the cv/mutex run time consistency check, you would be forced to ship with the debug build of the std::lib which would almost certainly have such a performance penalty as to not be practical. All that being said, if one of the above 4 goals has to be relegated to a non-standards-mandated debug build, #3 would be my first choice. I'm currently still thinking #3 belongs in the standard, but I also know that I need to support that view with a motivating use case (suggestions welcome). <still contemplating...> -Howard