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... Sent from the Boost - Dev mailing list archive at Nabble.com.