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

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-25 13:33:10

On Aug 25, 2007, at 1:12 PM, Peter Dimov wrote:

> Howard Hinnant:
>
>> Adding the condition(Mutex&) constructor which does nothing but
>> specify undefined behavior provides no benefit, and quite possibly
>> adds cost to valid use cases of condition which use the default
>> constructor instead.
>
> I disagree with both statements, even when taken individually.  
> Together,
> they obviously contradict one another.
>
> The mutex constructor MAY provide no benefit (except portability and  
> the
> potential to do a designated checked build) if the implementation  
> chooses to
> ignore it, in which case there is no cost. I would expect this to be  
> the
> case on embedded or realtime platforms.
>
> The mutex constructor MAY add cost to the constructor that takes no  
> mutex,
> in which case it does provide benefit since the cost presumably  
> comes from
> the checking logic.
>
> It MAY even provide benefit at a cost that is acceptable to the target
> audience. See "checked release" and vary the number 17041 according to
> taste.
>
> In contrast, if you make it impossible for the user to explicitly  
> associate
> a mutex with the condition, the implementation MAY NOT check, even  
> if it can
> somehow do that for free (it knows about an unused void* in the
> pthread_cond_t, for example).

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

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:

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?

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)?  Would the  
boost version of your proposal be best for them?

-Howard