Re: [boost] [thread] RFC standard proposed mutex, read-write mutex, condition

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-27 12:11:25

On Aug 27, 2007, at 11:41 AM, David Abrahams wrote:

>
> on Sun Aug 26 2007, Howard Hinnant <howard.hinnant-AT-gmail.com>  
> wrote:
>
>>> That's not the rationale I'm looking for.  I don't mean "how did we
>>> get here?"  I mean, what *is* this thing, conceptually?
>>
>> Conceptually a unique_lock is the sole RAII owner of the exclusive
>> lock state of an object that meets certain Mutex concepts.
>
> Meaning, unless ownership is transferred away from the unique_lock,
> when it is destroyed, the object is unlocked?

Yes.

>> On Aug 22, 2007, at 10:36 AM, David Abrahams wrote:
>>
>>> on Tue Aug 21 2007, Howard Hinnant <howard.hinnant-AT-gmail.com>
>>> wrote:
>>>
>>>> This line:
>>>>
>>>>        unique_lock<_L1> __u1(__l1);
>>>>
>>>> implicitly calls __.l1.lock() inside of the unique_lock  
>>>> constructor.
>>>> If __l1 is a mutex, the deed is done.  If __l1 is a lock, hopefully
>>>> that will forward to the referenced mutex's lock() function in the
>>>> proper manner.  And in the process, that should set the lock's  
>>>> owns()
>>>> data to true as well.
>>>
>>> That's part of what I found counfounding about the name "unique_."
>>> Now you have two locks (__l1 and __u1) that "own" the mutex.
>>
>> __u1 now uniquely owns the exclusive lock state of __l1.  __u1 does
>> not know or care what it means for __l1 to be in an exclusive locked
>> state.  It only knows that it uniquely owns it.  That is, until
>> further notice, no other object in the program has executed
>> __l1.lock(), or __l1.try_lock() (or any of the other functions  
>> which a
>> can put a mutex into a exclusive locked state) without having already
>> executed __l1.unlock().
>
> It sounds like you're saying that it's legit for some "other object in
> the program" to call __l1.unlock() while __u1 is uniquely holding
> __l1's lock state.  Are you really saying that?

No.  I'm saying __u1 owns the exclusively locked state of __l1.  What  
that ownership means is __l1's business.  That ownership is not  
relinquished until __l1.unlock() is executed.

>> Anything that happens inside of __l1 when
>> __l1 is in its exclusively locked state is an implementation detail  
>> of
>> __l1, which __u1 is not privy to.
>
> That part, I understand.  __u1 might be analagous to
>
>     unique_ptr<shared_ptr<T> >
>
> if __l1 is a lock analagous to shared_ptr<T>.  Right?

Sure.  Another analogy might be:

     unique_ptr<unique_ptr<T>>

if __l1 is a lock analogous to unique_ptr<T>.

-Howard