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

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-22 19:05:04

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