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

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-27 13:37:38

On Aug 27, 2007, at 1:29 PM, David Abrahams wrote:

>
> on Mon Aug 27 2007, Howard Hinnant <howard.hinnant-AT-gmail.com>  
> wrote:
>
>>>> until further notice, no other object in the program has executed
>>>> __l1.lock(), or __l1.try_lock() (or any of the other functions
>>>> which a can put a mutex into a exclusive locked state) without
>>>> having already executed __l1.unlock().
>>>
>>> It sounds like you're saying that it's legit for some "other  
>>> object in
>>> the program" to call __l1.unlock() while __u1 is uniquely holding
>>> __l1's lock state.  Are you really saying that?
>>
>> No.  I'm saying __u1 owns the exclusively locked state of __l1.  What
>> that ownership means is __l1's business.
>
> What was all that about executing __l1.unlock(), then?  Should I just
> ignore it?

I was trying to be precise.  Instead I was confusing.  Please ignore  
it.  unique_lock<Mutex> works just like  
boost::thread::detail::scoped_lock<Mutex>.

-Howard