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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-24 17:51:17

Howard Hinnant wrote:

> On Aug 24, 2007, at 5:22 PM, Howard Hinnant wrote:
>
>> The current boost::condition::wait(lock) throws if lock.locked()
>> returns false.  To people view this as a recoverable run time
>> error?  Or a debug feature that should not be present in release
>> builds?
>>
>> I.e. if lock.locked() (lock.owns() or lock.holds_mutex() or
>> whatever) returns false, is that undefined or defined behavior?

Good question.

It should be consistent with whatever unique_lock::unlock does. In your case 
it throws lock_error, and so should condition::wait.

In N2178 I have

    void basic_lock<Mx>::unlock();

    Requires: locked().

and consequently

    template< class Lock > int basic_condition<Mx>::wait( Lock & lock );

    Requires: lock.locked(); Lock::mutex_type shall be Mx.

N2178 basic_lock<> throws lock_error( r ) in situations where your proposal 
would throw system_error( r, posix_category ).

> Or should condition::wait() not take any parameters, or take only
> mutexes, making the issue moot?

I think that we ought to keep the lock argument, even if we end up not using 
it for anything except debug checks. It helps people avoid accidental calls 
to 'wait' without locking the mutex first.