Introduction

std::async can absolutely appear to run serially, and that behavior is permitted by the standard when you do not force the launch policy. The confusing part is that many developers expect every call to std::async to create parallel work immediately, but in reality the implementation may choose deferred execution instead.

Why It Can Run Serially

std::async supports launch policies, and the default call form leaves room for the implementation to choose how the task starts.

In practice, the important policies are:

• 'std::launch::async, which requests asynchronous execution'
• 'std::launch::deferred, which delays execution until you wait on the future'

If you call std::async without specifying a policy, the implementation may choose either behavior. That means the same source code can look parallel on one runtime and effectively serial on another.

A Minimal Example

1#include <chrono>
2#include <future>
3#include <iostream>
4#include <thread>
5
6int work(int id) {
7    std::this_thread::sleep_for(std::chrono::milliseconds(500));
8    return id * 10;
9}
10
11int main() {
12    auto f1 = std::async(work, 1);
13    auto f2 = std::async(work, 2);
14
15    std::cout << f1.get() << '\n';
16    std::cout << f2.get() << '\n';
17}

If both futures are deferred, work(1) may run only when f1.get() is called, and work(2) may run only when f2.get() is called. That makes the total behavior look serial.

Force Real Asynchronous Execution

If you require concurrent execution, pass std::launch::async explicitly.

1#include <chrono>
2#include <future>
3#include <iostream>
4#include <thread>
5
6int work(int id) {
7    std::this_thread::sleep_for(std::chrono::milliseconds(500));
8    return id * 10;
9}
10
11int main() {
12    auto start = std::chrono::steady_clock::now();
13
14    auto f1 = std::async(std::launch::async, work, 1);
15    auto f2 = std::async(std::launch::async, work, 2);
16
17    int a = f1.get();
18    int b = f2.get();
19
20    auto end = std::chrono::steady_clock::now();
21    auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
22
23    std::cout << a << ' ' << b << '\n';
24    std::cout << "Elapsed: " << ms << " ms\n";
25}

On a machine with enough resources, the elapsed time should be close to one task duration instead of the sum of both durations.

Deferred Execution Is Not a Bug

It is tempting to think deferred execution means something is broken, but it can be an intentional optimization. If a future is never observed, delaying the computation may avoid unnecessary thread creation and scheduling overhead.

So the real problem is not deferred execution itself. The real problem is assuming a concurrency guarantee that your code never explicitly requested.

Detect Deferred Futures While Debugging

You can inspect whether a future is deferred by using wait_for with a zero timeout.

1#include <chrono>
2#include <future>
3#include <iostream>
4
5int compute() {
6    return 42;
7}
8
9int main() {
10    auto future = std::async(compute);
11
12    if (future.wait_for(std::chrono::seconds(0)) == std::future_status::deferred) {
13        std::cout << "Deferred execution\n";
14    } else {
15        std::cout << "Running asynchronously or already ready\n";
16    }
17
18    std::cout << future.get() << '\n';
19}

This is useful when performance measurements suggest that work is not starting when you expect it to.

Why get() Placement Matters

Even with true asynchronous tasks, your program can still behave almost serially if you wait too early.

For example:

1auto f1 = std::async(std::launch::async, work, 1);
2int a = f1.get();
3auto f2 = std::async(std::launch::async, work, 2);
4int b = f2.get();

This is mostly serial because you block on the first task before even starting the second one. Concurrency depends on both launch policy and how you structure the waits.

When std::async Is Not Enough

std::async is convenient, but it is intentionally high-level. If you need:

• bounded concurrency
• task queues
• explicit thread-pool behavior
• stable scheduling across platforms

then a dedicated executor or thread-pool model is often a better fit.

std::async is great for simple task-based parallelism, but it is not a full scheduling framework.

Common Pitfalls

The biggest mistake is calling std::async without a policy and assuming parallel execution is guaranteed. It is not.

Another issue is measuring only the call to std::async rather than the whole timeline through get(). Hidden blocking often shows up only when the future is consumed.

Developers also accidentally serialize their own program by waiting on each future immediately after creating it.

Finally, do not overcorrect by launching huge numbers of std::launch::async tasks without any concurrency limits. That can create a different performance problem.

Summary

• 'std::async may run serially if the implementation chooses deferred execution.'
• The default call form does not guarantee concurrent execution.
• Use std::launch::async when you need actual asynchronous start behavior.
• Check for std::future_status::deferred during debugging if behavior looks suspicious.
• Concurrency still depends on where you place get() and wait(), not just on how tasks are launched.