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

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2007-08-27 00:13:10

On 8/26/07, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
>
> Conceptually a unique_lock is the sole RAII owner of the exclusive
> lock state of an object that meets certain Mutex concepts.
>
> >  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:
>
> 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
> can put a mutex into a exclusive locked state) without having already
> executed __l1.unlock().  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.
>
> -Howard
>

Is 'exclusive_lock' a better name?  'exclusive' implies unique, but
seems better for locks.

There may also be some confusion between
- owning the object
- referencing the object
- owning the state of the object

a unique_ptr references an object, and owns the object, exclusively.
In this sense, 'ref' and 'own' mean the same thing.

a unique_lock references an objet, and has exclusive ownership of its
locked state.  Slightly different.  And 'ref' != 'own'.  Or 'own' is
ambiguous between owning the object and owning the state of the
object.

Does that help?
Tony