From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-07 12:30:25
>> I'm not sure what's best in this case. I find that there is often a
>> 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
> 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
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.