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

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

On Aug 25, 2007, at 4:54 PM, Peter Dimov wrote:

> Howard Hinnant:
>
>> The main philosophical difference between us is that I want to be  
>> able
>> to choose "check", and be assured that I'm actually getting checking.
>> And then I want to be able to choose "don't check".  And then not  
>> have
>> to pay for it.  I want both choices.
>
> The main philosophical difference between us is that you want the
> specification to guarantee you that, instead of merely allowing the
> implementor to give you that.
>
> Guaranteed checks on a specification level are only possible if you  
> demand
> an exception. Guaranteed non-paying is, in your view, only possible  
> if you
> don't give the adversary the mutex pointer, lest he subvert your  
> intent and
> increase sizeof(condition) to store it.

Well put.  The use of adversary is a bit dramatic, but I must admit to  
having a good chuckle over it (and thanks!). :-)

I also note that I've supplied a reasonable use case for correcting  
the exceptional condition at run time (giving justification that  
program termination is too strong of a reaction for all use cases).

> As an academic debate solely concerned with this specific class,  
> this can go
> on. You can cite list::size as evidence that the implementors cannot  
> be
> trusted to do the right thing, and I can respond with a list of bullet
> points of why this doesn't apply to our case. You will note that  
> MSVC8 does
> runtime checks in release builds, and I will counter that while  
> these can
> show up on the profiler if one is careless, they have helped me find  
> bugs in
> code and it's possible to eliminate them from the performance-critical
> regions, so I consider them non-evil.

Just to be clear, I'm extremely well positioned to know that vendors  
are not evil, and are not adversaries.  They are people, just like you  
and me.  And when the standard gives them choices, they must make  
them.  They try to make them in such a way as to please most of their  
customers.  Sometimes they choose correctly, and sometimes they do not  
(as a vendor I admit to having chosen incorrectly sometimes).  No  
vendor that I'm aware of is immune to making incorrect choices.

> In practice, however, sizeof(string), vector, map, list will have  
> much more
> of an impact on my code than sizeof(condition), for the simple  
> reasons that
> they (a) occur much more frequently and (b) don't involve blocking  
> kernel
> calls that can shadow thousands of L1 cache misses. If the implementor
> doesn't care about the size of the stdlib classes, condition will be  
> the
> least of my worries.

The above is a valid forward looking statement.  But I stress "forward  
looking".  To date:

*  We have no std::condition to take the sizeof.
*  The sizeof(boost::condition) == sizeof(pthread_cond_t).
*  We anticipate a massive explosion in the growth of multithreading  
code in the next decade, due to an anticipated explosion in the number  
of cores per processor.  And the motivation for that multithreading  
code explosion is to extract further *performance*, not further  
functionality out of the hardware.

I don't know any more than you do, so my "forward looking" is no more  
or less valid than yours.  But I strongly believe that it would be  
careless of us to be careless with sizeof(std::condition).

-Howard