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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk