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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-25 16:54:10

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.

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.

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.