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