Boost logo

Boost :

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)
unique_lock<mutex> lk(m2);
while (pred)

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at