Boost logo

Boost :

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-21 17:57:01

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

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...>


Boost list run by bdawes at, gregod at, cpdaniel at, john at