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
