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

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-26 10:20:01

on Fri Aug 24 2007, Howard Hinnant <howard.hinnant-AT-gmail.com> wrote:

>> 2. I think the concept of unique_lock is too fuzzy.  I know what
>>   unique_ptr (and auto_ptr, and shared_ptr, and scoped_ptr) mean.
>>   With unique_lock, I can't quite tell.  This might ultimately end up
>>   being fixed by a naming change, but I think there's an underlying
>>   conceptual problem, or at the very least, a missing rationale.
>
> I will try to better fill out the rationale.  And am certainly open to  
> a name change.
>
> In a nutshell, the current unique_lock<Mutex> is an evolution of the  
> current boost::detail::thread::scoped_lock<Mutex>.  It has been taken  
> out of namespace detail, renamed, given move semantics, and slightly  
> more flexibility in how it handles the mutex.  The only invariant that  
> has changed from the boost design is that one can have a unique_lock  
> which doesn't reference a mutex.  This was a consequence of a moved- 
> from unique_lock.

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?  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)?  What does it mean to return one from a function
or store it in a container?

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

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