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