Re: [boost] Comments about N2320

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 
that cost.

>>>> 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  
>> document.
>> That implies importance. My claim is that there is no importance to  
>> it,
>> 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.