Proposed resolution:

Replace [thread.condition.condvar] p12, p19 and [thread.condition.condvarany] p10, p16:

Throws: std::system_error when the effects or postcondition cannot be achieved.

Error conditions:

• equivalent error condition from lock.lock() or lock.unlock().

Throws: It is implementation-defined whether a std::system_error with implementation-defined error condition is thrown if the precondition is not met.

[ 2011-03-24 Madrid ]

[ 2010 Pittsburgh: ]

There are heavy conflicts with adopted papers.

This issue is dependent on LWG 1268.

Leave open pending outstanding edits to the working draft. Detlef will provide wording.

Possibly related to 964.

[ 2009-11-18 Anthony adds: ]

condition_variable::wait takes a unique_lock<mutex>. We know whether or not a unique_lock owns a lock, through use of its owns_lock() member.

I would like to propose the following resolution:

Modify the first sentence of [thread.condition.condvar] p9:

void wait(unique_lock<mutex>& lock);

9 Precondition: lock is locked by the calling thread lock.owns_lock() is true, and either

...

Replace [thread.condition.condvar] p11-13 with:

void wait(unique_lock<mutex>& lock);

...

11 Postcondition: lock is locked by the calling thread lock.owns_lock() is true.

12 Throws: std::system_error when the effects or postcondition cannot be achieved if the implementation detects that the preconditions are not met or the effects cannot be achieved. Any exception thrown by lock.lock() or lock.unlock().

13 Error Conditions: The error conditions are implementation defined.

• equivalent error condition from lock.lock() or lock.unlock().

[ 2009-10 Santa Cruz: ]

Leave open, Detlef to provide improved wording.

[ 2009-10-23 Detlef Provided wording. ]

Detlef's wording put in Proposed resolution. Original wording here:

Change [thread.condition.condvar] p12, p19 and [thread.condition.condvarany] p10, p16:

Throws: May throw std::system_error if a precondition is not met. when the effects or postcondition cannot be achieved.

[ 2009-10 Santa Cruz: ]

Leave open, Detlef to provide improved wording.

[ 2009-08-01 Howard provides wording. ]

The proposed wording is inspired by the POSIX spec which says:

[EINVAL]

The value specified by cond or mutex is invalid.

[EPERM]

The mutex was not owned by the current thread at the time of the call.

I do not believe [EINVAL] is possible without memory corruption (which we don't specify). [EPERM] is possible if this thread doesn't own the mutex, which is listed as a precondition. "May" is used instead of "Shall" because not all OS's are POSIX.

[ Summit: ]

Move to open. Requires wording. Agreed this is an issue, and the specification should not require detecting deadlocks.

[thread.condition.condvar]: condition_variable::wait and condition_variable::wait_until both have a postcondition that lock is locked by the calling thread, and a throws clause that requires throwing an exception if this postcondition cannot be achieved. How can the implementation detect that this lock can never be obtained?