Re: [boost] Comments about N2320

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-11-01 09:35:47

Anthony Williams wrote:
> Yuval Ronen <ronen_yuval_at_[hidden]> writes:
> 
>> 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.
> 
> unique_lock needs to retain a reference to the mutex in order to unlock it in
> the destructor. The cost comes from the fact that retaining the reference
> means you need a separate bool to indicate locked/unlocked.

You say that you need both a reference and a bool to implement 
unique_lock's interface. This is obvious. My claim was that there is no 
use case that cannot be satisfied with a *simpler* interface, one that 
can be implemented with a single mutex pointer that is NULL when the 
mutex is not owned by the lock. And even if there is such a use case, 
it's very rate (and can be done externally). I haven't seen any yet.

> Depending on the
> pointer format and alignment requirements of the mutex, this could be stored
> as the LSB of a pointer to the mutex to save the space (for example).

"Depending on the pointer format and alignment requirements" is hardly 
an argument that there is no cost, you surely know that...

> unique_lock is a lock object associated with a mutex. The mutex doesn't change
> through the life of the lock object, though it may be locked or unlocked many
> times. Code that uses the lock object doesn't need to know which mutex it
> refers to: it can just call lock() and unlock() on the lock object. Condition
> variables have to do that: they call unlock() at the start of the wait, and
> lock() when done.

Condition variables are still not the use case I'm looking for (anyone 
remembers the line form Star Wars IV "These are not the men you're 
looking for"? :) ) The cv code can easily call lock() and unlock() for 
lk.mutex(), and anyway, it needs intimate knowledge of the mutex, so it 
probably bypasses the lock.

Well, it seems we're not going to convince each other that easily. So 
anyway it goes, thanks for all the hard work.