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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-25 18:24:57

Howard Hinnant:

> Just to be clear, I'm extremely well positioned to know that vendors
> are not evil, and are not adversaries.

For the record, I applied "non-evil" to the runtime checks done in a release 
build, not to a vendor. :-)

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

I accept that. So what's the problem? Vendor A ignores the mutex argument, 
his users complain, so he finds a way to add checking that doesn't increase 
sizeof(condition) and doesn't compromise performance for the rest of the 
user base. Vendor B stores the mutex pointer in std::condition, his users 
complain, he waits for the next ABI breakage and finds a way to achieve 
comparable checking quality and efficiency without increasing 
sizeof(condition). Everyone is happy.

...

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

I'm not being careless with sizeof(condition). I already demonstrated two 
ways to achieve checking without storing the pointer into the condition 
itself, and hinted at another possibility (exploiting an unused void* in 
pthread_cond_t). I also questioned your assertion that increasing 
sizeof(condition) from 28 to 32 is of practical importance.