From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-10-31 07:15:32
Howard Hinnant wrote:
> On Oct 30, 2007, at 3:43 PM, Yuval Ronen wrote:
>>>> 2. Make sizeof(unique_lock) smaller - no need for bool owns.
>>> Even if we remove defer_lock, unique_lock will still need the
>>> internal bool to support try and timed locks. This functionality
>>> still retains a reference to the mutex even if the try/timed lock
>>> fails (so that further action with the mutex can be easily taken).
>> This is something I don't understand. Why should the lock retain a
>> reference to the mutex even if the try/timed lock fails?
> Because if the try_lock fails, I might want to take some corrective
> action and then do a blocking lock() on the mutex. If the lock has
> retained the reference to the mutex, I don't have to store that
> reference elsewhere "just in case" the try_lock fails.
But now you do it (by "it" I mean "retained the reference, just in
case") all the time, for everyone, even if unnecessary. I believe this
is a rare use case (I never written or read such code), and it's also
something that can be easily implemented externally (either as a
unique_lock wrapper, or not). It seems pity that everyone should pay
>>>> In general it seems you paid a lot of attention to being able to
>>>> pass a
>>>> lock instead of a mutex wherever possible. I think it's
>>>> absolutely not
>>>> necessary. It's an undue complication.
>>> Actually I tried to pay attention to what the minimal requirements
>>> were on template parameters. It just turned out that some generic
>>> code would accept either locks or mutexes.
>> But you made the effort of mentioning it several times in the
>> That implies importance. My claim is that there is no importance to
>> because there's no use for it, even if it happens that we named
>> unique_lock::lock the same way we named mutex::lock. We could've have
>> named them differently. And while I'm thinking of it, why is there a
>> lock() method for unique_lock anyway? Isn't it unnecessary?
> The original answer is because that's the way boost::scoped_lock
> specified its API. After further study and experience, I find myself
> in complete agreement with the boost API in this regard, at least for
> unique_lock. I think the member lock() functions on unique_lock are
> quite convenient. That being said, please see lock_guard in N2447
> which both lacks the defer_lock functionality, and lacks member lock,
> try_lock and unlock functions. It also lacks the internal bool you
> would like to get rid of. I think we may already have what you're
> looking for, just under a different name.
What makes member lock() functions on unique_lock convenient? In other
words, when are they convenient?
I've skimmed N2447 very quickly, and it seems that lock_guard is a
rename of scoped_lock, right? The major difference between lock_guard
and a stripped unique_lock, is the moveability. There is no
vector<lock_guard>, and if we are to support vector<unique_lock>, then
we should support it well, which means reducing the used size by half.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk