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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-25 14:11:29

Howard Hinnant:

> What would you recommend for back porting your proposal into boost?  A
> boost debug build?  Or to always include the check?  And why?

Boost already has a debug build and doesn't promise compatibility between 
debug and release, so in this case the path of least resistance would 
certainly be to #ifdef the extra pointer on NDEBUG and use BOOST_ASSERT.

On an implementation that must withstand inconsistent definitions of NDEBUG 
and/or wants to include checking in release, I'd use a variation of "checked 
release" from my previous post.

> Also note that I specifically showed that no matter what we do, we can
> not make it impossible for the user to explicitly associate a mutex
> with the condition:

Sure, but this doesn't help with discovering bugs in code where the user did 
not associate a mutex with the condition because you made him jump through 
hoops to do so. Your original design did encourage users to associate with a 
mutex by default, and this was a good thing.

> On Aug 25, 2007, at 11:53 AM, Howard Hinnant wrote:
>
>> The above being said, it is easy to add a "constrained condition" with
>> a variety of syntaxes and semantics.
> ...
>> condition<constrain<Mutex>> cv(mut);
>> constrain_condition<Mutex>  cv(mut);
>> constrain::condition<Mutex> cv(mut);
>>
>> All of the above syntaxes could be achieved either by the std::lib, or
>> by the client.
>
> For the client who has a use case where they want a constrained
> condition, and want to correct any mis-bindings at run time, what do
> you recommend for them?

I'll wait for this hypothetical client to appear, suggest a 
checked_condition wrapper, then consider adding boost::checked_condition (or 
constrained_condition if you prefer) if this proves a common occurence.

> What do you tell the client who wants to regularly change the mutex/
> condition binding, and whose design makes it impossible for there to
> be a mis-binding (because there's only one waiting thread)?

I'll wait for this hypothetical client to appear.

To try to provide a summary: we have three conditions on the table: (1) 
unchecked, (2) possibly checked, and (3) checked. Your original design has 
(3) as default, (1) when the mutex argument is wrapped by unchecked<>. The 
direction you now seem to be exploring is (1) by default, (3) as an option, 
which I regard as a regression. I suggest (2) by default, with (3) as an 
option, but only if there proves to be demand.

Regardless of what is chosen, I maintain that the three conditions must 
syntactically have the same interface, that is, it must be possible to pass 
a mutex even to (1). It would be painful to switch between them if they do 
not.