This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 33.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:
33.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 33.7.4 [thread.condition.condvar] p12, p19 and 33.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 aunique_lock<mutex>
. We know whether or not aunique_lock
owns a lock, through use of itsowns_lock()
member.I would like to propose the following resolution:
Modify the first sentence of 33.7.4 [thread.condition.condvar] p9:
void wait(unique_lock<mutex>& lock);9 Precondition:
lock
is locked by the calling threadlock.owns_lock()
istrue
, and either...
Replace 33.7.4 [thread.condition.condvar] p11-13 with:
void wait(unique_lock<mutex>& lock);...
11 Postcondition:
lock
is locked by the calling threadlock.owns_lock()
istrue
.12 Throws:
std::system_error
when the effects or postcondition cannot be achievedif the implementation detects that the preconditions are not met or the effects cannot be achieved. Any exception thrown bylock.lock()
orlock.unlock()
.13 Error Conditions: The error conditions are implementation defined.
equivalent error condition fromlock.lock()
orlock.unlock()
.
[ 2010 Pittsburgh: ]
There are heavy conflicts with adopted papers.
This issue is dependent on LWG 1268(i).
Leave open pending outstanding edits to the working draft. Detlef will provide wording.
[2011-03-24 Madrid]
Rationale:
This has been resolved since filing, with the introduction of system_error
to the thread specification.
Proposed resolution:
Replace 33.7.4 [thread.condition.condvar] p12, p19 and 33.7.5 [thread.condition.condvarany] p10, p16:
Throws:std::system_error
when the effects or postcondition cannot be achieved.
Error conditions:
equivalent error condition fromlock.lock()
orlock.unlock()
.Throws: It is implementation-defined whether a
std::system_error
with implementation-defined error condition is thrown if the precondition is not met.