Issue 2190: Condition variable specification

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

2190. Condition variable specification

Section: 32.7 [thread.condition] Status: C++14 Submitter: Hans Boehm Opened: 2012-09-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [thread.condition].

View all issues with C++14 status.

Discussion:

The condition variable specification possibly leaves it unclear whether the effect of a notify_one() call can effectively be delayed, so that a call unblocks a wait() call that happens after the notify_one call. (For notify_all() this is not detectable, since it only results in spurious wake-ups.) Although this may at first glance seem like a contrived interpretation, it gains relevance since glibc in fact allows the analogous behavior (see here) and it is currently controversial whether this is correct and the Posix specification allows it (see here).

The following proposed resolution disallows the glibc implementation, remaining consistent with the believed intent of C++11. To make that clear, we require that the "unspecified total order" O from 32.7 [thread.condition] p4 be consistent with happens-before. We also intend that the 3 components of a wait occur in order in O, but stating that explicitly seems too pedantic. Since they are numbered, it appears clear enough that they are sequenced one after the other.

Another uncertainty with the current phrasing is whether there is a single total order that includes all c.v. accesses, or one total order per c.v. We believe it actually doesn't matter, because there is no way to tell the difference, but this requires a bit more thought. We resolved it one way, just to remove the potential ambiguity.

[2012, Portland: Move to Review]

This is linked to a glibc issue, and a POSIX specification issue.

We believe the proposed wording fixes the ambiguity in C++ and is compatible with the proposed resolution for Posix (which confirms the glibc behaviour as illegal).

Moved to review (Detlef hopes to send some improved wording to the reflector).

[2013-04-20, Bristol]

Accepted for the working paper

Proposed resolution:

This wording is relative to N3376.

Change 32.7 [thread.condition] p4 as indicated:

-4- The implementation shall behave as if all executions of notify_one, notify_all, and each part of the wait, wait_for, and wait_until executions are executed in ~~some~~a single unspecified total order consistent with the "happens before" order.