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

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-24 09:26:24

On Aug 22, 2007, at 10:17 PM, David Abrahams wrote:

>
> on Wed Aug 22 2007, Howard Hinnant <howard.hinnant-AT-gmail.com>  
> wrote:
>
>> Ok, this is my last post for approximately 24 hours (for unrelated,
>> personal reasons).  If I don't answer in a timely fashion for a day,
>> please know that it is not because I'm ignoring you.
>>
>> I wanted to leave off with a few "PS" type comments:
>>
>> On Aug 22, 2007, at 2:59 PM, Zach Laine wrote:
>>
>>> Could the folks who object to the
>>> current design spell it out for me a bit more explicitly -- what in
>>> the design is dangerous/inconvenient enough to throw away one or  
>>> more
>>> of the 4 goals?
>>
>> I would like to see an answer to Zach's question too.  I do not know
>> what the major objection is with the "current proposal".  I only know
>> that people are suggesting alternatives.
>
> 1. I'm extremely wary of turning what is almost certainly a
>   programming error into an exception (std::vector<T>::at
>   notwithstanding), for reasons laid out in this thread:
>   http://tinyurl.com/2ph58t

I now believe I have realistic and valid use cases.  Still working ...

> 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.

Thus the current rationale dwells on the changes from  
boost::detail::thread::scoped_lock<Mutex>, as opposed to rationale for  
those features already existing in  
boost::detail::thread::scoped_lock<Mutex>.

-Howard