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