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

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