Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at