Re: [boost] [thread] Expected behaviour of condition variable wait when the mutex is not locked

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-07 12:30:25

vicente.botet wrote:
> 
>> I'm not sure what's best in this case. I find that there is often a 
>> certain
>> trade-off between ease of use and runtime insecurities.
> 
> Yes you are right, we need to maintain a ease of use. Could you show me
> why 
> my proposal using a strict_lock is  not easy to use?
> 

Don't get me wrong, strict_lock is easier to use than unique_lock - it has a
smaller interface. Just as you do, I think the gained compile time security
is worth quite a lot. However, if both classes are needed, the threading
library gets bigger and more complicated and hence we have a trade-off. That
was my point.

I guess condition_variable::wait() doesn't check if the lock is locked for
performance reasons. I think that is a common strategy for most of the
standard library.

I don't know the rationale why unique_lock has a default constructor and
lock/unlock methods but I'm interested in hearing it. Anyone?

Best Regards, Johan
-- 
View this message in context: http://www.nabble.com/-thread--Expected-behaviour-of-condition-variable-wait-when-the-mutex-is-not-locked-tp17049218p17109128.html
Sent from the Boost - Dev mailing list archive at Nabble.com.