Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk