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