966. Various threading bugs #16

Section: 32.7.4 [thread.condition.condvar] Status: Resolved Submitter: Pete Becker Opened: 2009-01-07 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [thread.condition.condvar].

View all issues with Resolved status.

Discussion:

32.7.4 [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?

[ Summit: ]

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

[ 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.

[ 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 32.7.4 [thread.condition.condvar] p12, p19 and 32.7.5 [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-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 32.7.4 [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 32.7.4 [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().

[ 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.

[2011-03-24 Madrid]

Rationale:

This has been resolved since filing, with the introduction of system_error to the thread specification.

Proposed resolution:

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

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

Error conditions:

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