Per [futures.async]/3 bullet 1 of the C++ Standard, when a function f is passed to std::async with the std::launch::async launch policy, f will run "as if in a new thread of execution".
Given that f can do anything, including loop infinitely and block forever, how can an implementation offer the behavior of f running on its own thread without actually running it on its own thread? That is, how can an implementation take advantage of the "as if" wiggle room the Standard provides?
Looking in the C++ refs as appear here and here, it seems that the "as if" goal is to let the library implementer some degree of freedom. For example, it says
as if spawned by std::thread(std::forward(f), std::forward(args)...), except that if the function f returns a value or throws an exception, it is stored in the shared state accessible through the std::future that async returns to the caller.
in the first source, and
as if a thread object is constructed with fn and args as arguments, and accessing the shared state of the returned future joins it
in the second. So it looks like the behavior is similar to that of std::thread but might be implemented in a different way. This is interesting, since the phrase thread of execution you quote here is distinguishable from std::thread. Still, it seems that both sources understand the as-if that way.
Another option might be, as suggested by François Andrieux to allow usage of threadpool, as expressed in the first source:
The template function async runs the function f asynchronously (potentially in a separate thread which may be part of a thread pool)
Some ways I can think of that f could run "as if" on a new thread without actually doing so would be if f does not actually use any state shared with other threads; then the implementation could run it as a separate process (since it doesn't need shared memory space) it could also just run it on the main thread as just another function call (if it can prove that f doesn't block or have observable side effects that would differ when run this way). It could also be scheduled to run on an existing (but idle) thread (thread pool).
And if you want to be silly, I guess you could also consider the notion of not running f at all, since there are no guarantees about when new threads will be scheduled to run by an operating system, so an evil implementation could just say that the OS never schedules any thread except the main thread, thus not running f at all is equivalent to scheduling it on a new thread. Of course this is stupid/silly and no sane implementation would ever do that - but in theory the language allows such a degenerate implementation (I think).
The advantage of this solution is when you have optimized implementation for specific role in multi threading world. As I am involved in software update procedures I will use such example. For optimization reason you can call:
std::thread::hardware_concurrency();
You will receive:
Returns the number of concurrent threads supported by the implementation.
Let's say you have result equal 4. You want to perform update many things in parallel. Main thread is monitoring list of futures(3 left) and checking from time to time is it done or not and if done execute next thing from ToDo list. Profit here is for example if you are updating different type of memory like 1-FileSystem, 2-EEPROM, 3-NOR memory or something like that. There is no profit of checking in loop without delay, so you want to give a task to 4-th thread between checks. You are writing function that is digging bitcoins for 50 miliseconds :) and you trigger it as deferred between checks.
And then as you mentioned we have:
advantage of the "as if" wiggle room the Standard provides
AFAIK the C++ runtime is able to manage some internal (or specialized) threads, distinguished from the standard threads.
My guess (I'am still learning the advanced features of C++) is that, with the std::launch::async flag, the std::async() will launch f in a new internal thread.
You could launch f in a new standard thread using std::thread. In this case the exceptions will be handled on the called thread and the main code will have to fetch the return value of f.
With the internal thread, the return value and the eventual exception are stored into std::future, returned by std::async() and shared between the threads.
So "as if" stands for "as if I launch f with std::thread but I don't have to". But for sure, f will run on a new thread.
To answer your question about implementation, once the runtime already has standard threads implemented, it would be just the effort to specialize them for specific uses. See also the execution policy for algorithms that support parallelization.
I see main idea of "f will run "as if in a new thread of execution"" is that f will run asynchronously. Whether should it be new thread or something else is implementation details.
The only solution without Thread, I can think of is the yesterdayer' Time-Slicing which is a form of multi-tasking. The functions have to be made re-entrant. In such scenario, every function will run as if they are on different threads, although practically they are on single thread.
In the docs, it stated there,
The template function async runs the function f asynchronously (potentially in a separate thread which may be part of a thread pool) and returns a std::future that will eventually hold the result of that function call.
