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