on Mon Aug 27 2007, Howard Hinnant <howard.hinnant-AT-gmail.com> wrote:
unique_lock<Mutex> ------------------ exclusive_lock<Mutex> The boost name is Mutex::scoped_lock
I have no problem with unique_lock now, and I don't think exclusive_lock adds anything of value.
unique_lock<Mutex>::owns() -------------------------- owned()
-1. It's the mutex that's owned
owns_lock()
-1. Does a shared_lock "own" a lock on the mutex?
held()
-1. It's the Mutex that's held.
holds_lock()
-1. Cumbersome. And a lock holds a lock? Ugh.
The boost name is locked()
-1 You gave the reasons why not. Too many "locks" running around also; it will make code hard to talk about. I think acquired() might be best. IMO nothing will be truly satisfying because of the grammatical ambiguities (there's the lock object which owns a lock on the mutex) and because the analogy to the real-life thing called a lock is incomplete.
try_to_lock ----------- immediate The boost name is true
+1 for immediate in principle, though it might not be an identifier we want to reserve in std.
defer_lock ---------- deferred Boost doesn't have this functionality
ditto.
accept_ownership ---------------- prelocked Boost doesn't have this functionality
prelocked is good. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com