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.

### 966. Various threading bugs #16

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