2100. timed waiting functions cannot timeout if launch::async policy used

Section: 32.10.9 [futures.async] Status: C++14 Submitter: Jonathan Wakely Opened: 2011-11-14 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++14 status.

Discussion:

32.10.9 [futures.async] p5 says

If the implementation chooses the launch::async policy,

• a call to a waiting function on an asynchronous return object that shares the shared state created by this async call shall block until the associated thread has completed, as if joined (32.4.3.6 [thread.thread.member]);

That should say a non-timed waiting function, otherwise, calling a timed waiting function can block indefinitely waiting for the associated thread to complete, rather than timing out after the specified time.

Since std::thread does not provide a timed_join() function (nor does Pthreads, making it impossible on many platforms) there is no way for a timed waiting function to try to join but return early due to timeout, therefore timed waiting functions either cannot guarantee to timeout or cannot be used to meet the requirement to block until the thread is joined. In order to allow timed waiting functions to timeout the requirement should only apply to non-timed waiting functions.

[2012, Portland: move to Review]

Detlef: Do we actually need this fix — is it detectable?

Yes — you will never get a timeout. Should we strike the whole paragraph?

Hans: issue with thread local destruction.

Niklas: I have a strong expectation that a timed wait will respect the timeout

agreed

Detlef: we want a timed wait that does not time out to return like a non-timed wait; but is this implementable?

Pablo: Could we simply append ", or else time out"

Detlef: the time out on the shared state needs implementing anyway, even if the underlying O/S does not support a timed join.

Hans: the net effect is the timeout does not cover the thread local destruction... ah, I see what you're doing

Detlef: happy with Pablo's proposal

Wording proposed is to append after the word "joined" add ", or else time out"

Moved to review with this wording.

[2013, Bristol]

"Non-timed" made the new wording redundant and the result overly weak. Remove it.

Attempted to move to add this to the working paper (Concurrency motion 2) without the addition of "non-timed". Motion was withdrawn after Jonathan Wakely expressed implementability concerns.

[2013-09, Chicago]

Discussion of interaction with the absence of a Posix timed join.

Jonathan Wakely withdrew his objection, so moved to Immediate.

Accept for Working Paper

Proposed resolution:

[This wording is relative to the FDIS.]

Change 32.10.9 [futures.async] p5 as indicated:

If the implementation chooses the launch::async policy,

• a call to a waiting function on an asynchronous return object that shares the shared state created by this async call shall block until the associated thread has completed, as if joined, or else time out (32.4.3.6 [thread.thread.member]);