Boost logo

Boost :

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

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