Boost logo

Boost :

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

on Fri Aug 24 2007, Howard Hinnant <> 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
The Astoria Seminar ==>

Boost list run by bdawes at, gregod at, cpdaniel at, john at