Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at