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.
> they obviously contradict one another.
> The mutex constructor MAY provide no benefit (except portability and
> 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
> case on embedded or realtime platforms.
> The mutex constructor MAY add cost to the constructor that takes no
> 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
> In contrast, if you make it impossible for the user to explicitly
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk