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.