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

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-27 14:57:57

I'm trying to summarize the renaming suggestions so they do not get  
lost.  Here's my current list:

The format is:

current name
------------
suggestion 1
suggestion 2
...

unique_lock<Mutex>
------------------
exclusive_lock<Mutex>
The boost name is Mutex::scoped_lock

unique_lock<Mutex>::owns()
--------------------------
owned()
owns_lock()
held()
holds_lock()
The boost name is locked()

try_to_lock
-----------
immediate
The boost name is true

defer_lock
----------
deferred
Boost doesn't have this functionality

accept_ownership
----------------
prelocked
Boost doesn't have this functionality

Have I missed any "renaming" suggestions?

Comments pro or con on any of the above?

My current feeling is that exclusive_lock has strong support, and I  
have no problem with that one myself.

I'm not quite sure which of the owns() substitutes is the current  
front runner (holds_lock?).  My only concern with this decision is  
that the name we choose should clearly not be ambiguous with  
"referencing a mutex".  And the name should also not be ambiguous with  
asking if the mutex is locked (it may be locked by another thread).

"try_lock" or "trylock" is a well known term.  I fear "immediate" is  
not a good substitute as it does not imply to me that a "try_lock" is  
going to be performed.  The existing "try_to_lock" is a compromise to  
avoid conflicts with a namespace-scope try_lock function.  "try" would  
be nice, but is a keyword.

I have no opinion on the last two (defer_lock, accept_ownership).

-Howard