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

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-27 11:41:38

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?

>> What can I understand about a function that accepts one as an
>> argument (for unique_ptr it's very clear, and exceedingly so for
>> scoped_lock, since you can't do that)?
>
> To accept a unique_lock (which currently owns the exclusive state) by  
> value in a function parameter means transferring the ownership of that  
> exclusive lock state from the current scope, to the scope within the  
> called function.
>
>>  What does it mean to return one from a function
>> or store it in a container?
>
> It means to transfer the sole ownership of the exclusive lock state  
> from within the function, to the calling scope.
>
>> I understand what scoped_lock means.  If unique_lock doesn't mean "no
>> ownership or sole ownership of the mutex it references" then what does
>> it mean, and what's the justification for calling it "unique?"
>
> unique_lock means "no ownership or sole ownership of the mutex it  
> references".
>
> I think your concern began with my std::lock example:

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?

> 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?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com