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

2032. Incorrect synchronization clause of async function

Section: 33.10.9 [futures.async] Status: C++11 Submitter: Alberto Ganesh Barbati Opened: 2011-02-17 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [futures.async].

View all other issues in [futures.async].

View all issues with C++11 status.

Discussion:

Clause 33.10.9 [futures.async] has undergone significant rewording in Batavia. Due to co-presence of at least three different sources of modification there is a part where changes have overlapped (marked by an Editor's note), which should be reconciled. Moreover, I believe that a few non-overlapping sentences are now incorrect and should be fixed, so the problem cannot be handled editorially. (See c++std-lib-29667.)

[Adopted in Madrid, 2011-03]

Proposed resolution:

1. Edit 33.10.5 [futures.state], paragraph 3 as follows.

   An asynchronous return object is an object that reads results from an associated asynchronous state. A waiting function of an asynchronous return object is one that potentially blocks to wait for the associated asynchronous state to be made ready. If a waiting function can return before the state is made ready because of a timeout (30.2.5), then it is a timed waiting function, otherwise it is a non-timed waiting function.

2. Edit within 33.10.9 [futures.async] paragraph 3 bullet 2 as follows.

   Effects: [...]

   • if policy & launch::deferred is non-zero — [...] The associated asynchronous state is not made ready until the function has completed. The first call to a non-timed waiting function (30.6.4 [futures.state]) requiring a non-timed wait on an asynchronous return object referring to the this associated asynchronous state created by this async call to become ready shall invoke the deferred function in the thread that called the waiting function;. once Once evaluation of INVOKE(g, xyz) begins, the function is no longer considered deferred. [...]

3. Edit 33.10.9 [futures.async] paragraph 5 as follows.

   Synchronization: Regardless of the provided policy argument,

   • the invocation of async synchronizes with (1.10) the invocation of f. [Note: this statement applies even when the corresponding future object is moved to another thread. —end note]; and
   • the completion of the function f is sequenced before (1.10) the associated asynchronous state is made ready. [Note: f might not be called at all, so its completion might never happen. —end note]

   If policy & launch::async is non-zero, If the implementation chooses the launch::async policy,

   • a call to a waiting function on an asynchronous return object that shares the associated asynchronous state created by this async call shall block until the associated thread has completed, as if joined (30.3.1.5);
   • the join() on the created thread object the associated thread completion synchronizes with (1.10) the return from the first function that successfully detects the ready status of the associated asynchronous state or with the return from the last function that releases the associated asynchronous state returns, whichever happens first. [Editor's note: N3196 changes the following sentence as indicated. N3188 removes the sentence. Please pick one.] If the invocation is deferred, the completion of the invocation of the deferred function synchronizes with the successful return from a call to a waiting function on the associated asynchronous state.