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.

### 1046. Provide simple facility to start asynchronous operations

Section: 33.10 [futures] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [futures].

View all issues with Resolved status.

Discussion:

Addresses UK 329 [CD1]

`future`, `promise` and `packaged_task` provide a framework for creating future values, but a simple function to tie all three components together is missing. Note that we only need a simple facility 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 a `thread` object with a `packaged_task` invoking `f` with `forward<Args>(args...)` but details are left unspecified to allow different scheduling and thread spawning implementations.

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

The state of `thread_local` variables shall be preserved during `async` calls.

No two incomplete async tasks shall see the same value of `this_thread::get_id()`.

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

[ Summit: ]

> The concurrency subgroup has revisited this issue and decided that it could be considered a defect according to the Kona compromise. A task group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a paper for Frankfort proposing a simple asynchronous launch facility returning a `future`. It was agreed that the callable must be run on a separate thread from the caller, but not necessarily a brand-new thread. The proposal might or might not allow for an implementation that uses fixed-size or unlimited thread pools.

> Bjarne in c++std-lib-23121: I think that what we agreed was that to avoid deadlock `async()` would almost certainly be specified to launch in a different thread from the thread that executed `async()`, but I don't think it was a specific design constraint.

[ 2009-10 Santa Cruz: ]

> Proposed resolution: see N2996 (Herb's and Lawrence's paper on Async). Move state to NAD editorial Resolved.

Proposed resolution: