Re: [boost] [thread] Expected behaviour of condition variable wait when the mutex is not locked

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-05-08 04:51:18

Johan Torp <johan.torp_at_[hidden]> 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