
Oh, please modify my comment below by assert or whatever. I should've used the word "undefined" instead of throws. I just copied/pasted from the current proposal. -Howard On Aug 22, 2007, at 6:56 PM, Howard Hinnant wrote:
On Aug 22, 2007, at 6:31 PM, David Abrahams wrote:
on Wed Aug 22 2007, Howard Hinnant <howard.hinnant-AT-gmail.com> wrote:
This is a class that we're proposing can be used in two different ways:
Who's "we?" Does this correspond to your proposal, or, say, Peter's suggested modification?
This is my proposal plus Peter's suggested modification. Sorry for the confusion.
My original proposal was:
condition(); // All waits must reference the same mutex of type mutex_type, else condition_error thrown
Peter's suggested modification is:
condition(); // No mutex consistency checking
The motivation for the suggested change is not that it saves performance (it doesn't). But that there may be valid use cases.
The other constructor remains unmodified:
explicit condition(mutex_type& m); // All waits must reference m, else condition_error thrown
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?
I didn't understand any of that sentence after the word "constructor." Could you rephrase?
With the current proposal, as modified by Peter's suggestion above, waiting on a single cv with multiple mutexes (as long as the waits are not simultaneous) is legal if the condition is default constructed, and illegal if the condition is constructed with a mutex.
If a given bit of code waits on a single cv with multiple mutexes in a legal fashion when the condition is default constructed. Why is that same code necessarily a logic error if the constructor is changed? A contrived example (sorry, best I can do on short notice): The user, via std::cin, selects a mutex to wait on. He is supposed to pick the right one. But he makes a mistake and picks the wrong one. Logic error or exceptional runtime condition? If a logic error, why is it not still a logic error if the condition is default constructed? Simply because we declare it to be so in the documentation?
-Howard
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost