Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofResolved status.

1046. Provide simple facility to start asynchronous operations

Section: 32.10[futures]Status:ResolvedSubmitter: Alisdair MeredithOpened: 2009-03-12Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [futures].

View all issues withResolved status.

Discussion:

Addresses UK 329 [CD1]

future,promise andpackaged_task provide aframework for creating future values, but a simple function to tie allthree components together is missing. Note that we only need asimplefacility for C++0x. Advanced thread pools are to be left for TR2.

Simple Proposal:

Provide a simple function along the lines of:

template< typename F, typename ... Args >  requires Callable< F, Args... >    future< Callable::result_type > async( F&& f, Args && ... );

Semantics are similar to creating athread object with apackaged_taskinvokingf withforward<Args>(args...)but details are left unspecified to allow different scheduling and threadspawning implementations.

It is unspecified whether a task submitted to async is run on its own threador a thread previously used for another async task. If a call toasyncsucceeds, it shall be safe to wait for it from any thread.

The state ofthread_local variables shall be preserved duringasync calls.

No two incomplete async tasks shall see the same value ofthis_thread::get_id().

[Note: this effectively forces new tasks to be run on a new thread, or afixed-size pool with no queue. If the library is unable to spawn a new thread or there are no free worker threadsthen theasync call should fail.--end note]

[Summit:]

The concurrency subgroup has revisited this issue and decided that itcould be considered a defect according to the Kona compromise. A taskgroup was formed lead by Lawrence Crowl and Bjarne Stroustrup to write apaper for Frankfort proposing a simple asynchronous launch facilityreturning afuture. It was agreed that the callable must be run on aseparate thread from the caller, but not necessarily a brand-new thread.The proposal might or might not allow for an implementation that usesfixed-size or unlimited thread pools.

Bjarne in c++std-lib-23121: I think that what we agreed was that toavoid deadlockasync() would almost certainly be specified to launch ina different thread from the thread that executedasync(), but I don'tthink it was a specific design constraint.

[2009-10 Santa Cruz:]

Proposed resolution: seeN2996(Herb's and Lawrence's paper on Async). Move state toNAD editorialResolved.

Proposed resolution: