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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-08-26 11:39:42

David Abrahams wrote:
> on Fri Aug 24 2007, Howard Hinnant <howard.hinnant-AT-gmail.com> wrote:
> 
>> The above appears to be a reasonable and valid use case to me for  
>> "correcting" the condition/mutex binding.  The retooling operation is  
>> a rare (exceptional) event.  Using exceptions for this makes the main  
>> processing routine simpler/cleaner as it does not have to deal with  
>> the complication of retooling.
>>
>> In summary, we have valid use cases for both not checking condition/ 
>> mutex consistency, and for checking condition/mutex consistency, with  
>> both use cases built on "correctness" concerns as opposed to  
>> "performance" concerns.  Where this leads us next, I'm not yet sure...
> 
> This is exactly the sort of use case in which I'd want to have
> complete control of detecting the need for an exception and throwing
> it myself.  And, as described in http://tinyurl.com/2ph58t, if you
> rely on the std's checking and exception here you end up with the same
> exception representing a severe programming error in one part of the
> program and an expected, recoverable condition in another.  At some
> point up the call stack, you don't know which is which.  I would
> always want a specific "retooling" exception for the non-error case.
> 
> And, I repeat, when the mutex mismatch *does* represent an error, I
> *really* don't want a mandated throw.

So would you like to see two classes?

One (Peter suggested "condition") that asserts on mutex mismatch, and 
another (Peter suggested "checked_condition" ) that throws on mutex 
mismatch.

Or would you prefer only "condition", but with one or more additional 
signatures that take an additional argument that says, in effect, "throw 
rather than assert on mutex mismatch?

--Beman