Johan Torp <johan.torp@gmail.com> writes:
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.
The library does provide both. unique_lock is flexible, lock_guard is strict.
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.
Yes.
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?
There are use cases where it is desirable to unlock early if certain conditions are met, or defer locking until we need to. Also, sometimes it is necessary to transfer lock ownership between scopes. To this end, unique_lock is default-constructible and movable, and supports lock and unlock operations. If you don't need these facilities, use lock_guard: it locks on construction, and unlocks on destruction with no flexibility whatsoever. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL