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

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

On Aug 22, 2007, at 5:29 PM, Yuval Ronen wrote:

> Checking
> that mutexes match to avoid errors is in the realm of bug-finding aids
> of debug builds. Putting it in the hands of the implementors is just
> fine and if they choose to assert, it's best.

In general I agree with the philosophies expressed by you and others  
in this area.  It is best to assert on logic errors.  It is best to  
leave debug/release policies in the hands of the vendors, etc.

I think std::condition is a special case.  The exception to the rule.

This is a really low-level class where we have very strong motivation  
to provide two conflicting goals:  ultimate performance and  
consistency checking.  It must deliver as much performance as  
possible, because it is a foundation class.  It will potentially be  
used (mostly indirectly) by a large body of code.  At the same time,  
it is inherently easy to misuse.  It has two separate parts that must  
be used together correctly (the condition and the mutex).

This is a class that we're proposing can be used in two different ways:

Use the default constructor and this code is legal:

mutex m1;
mutex m2;
condition<mutex> cv;
...
unique_lock<mutex> lk(m1);
while (pred)
    cv.wait(lk);
...
unique_lock<mutex> lk(m2);
while (pred)
    cv.wait(lk);

Simply change the condition construction to:

condition<mutex> cv(m1);

And all of the sudden the above code is no longer legal.  If the code  
is legal with one constructor, what is it that makes the code a logic  
error **100% of the time**, instead of a fixable exceptional  
circumstance when using the second constructor?

The API of a condition variable is difficult and complex just by its  
very nature (all designs, not just this one).  I think it deserves  
special treatment.

-Howard