Executing a Future in a Separate Thread with Coroutines

This post concludes my posts about co_return in C++20. I started with an eager future, and continued with a lazy future. Today, I execute the future in a separate thread using coroutines as an implementation detail.

Before I continue, I want to emphasize this. The reason for this mini-series about coroutines in C++20 is simple: I want to help you to build an intuition about the complicated workflow of coroutines. This is what has happened so far in this mini-series. Each post is based on the previous ones.

co_return:

Now, I want to execute the coroutine on a separate thread.

Execution on Another Thread

The coroutine in the previous example, “Lazy Futures with Coroutines in C++20” was fully suspended before entering the coroutine body of createFuture.

MyFuture<int> createFuture() {
    std::cout << "createFuture" << '\n';
    co_return 2021;
}

The reason was that the function initial_suspend of the promise returns std::suspend_always. This means that the coroutine is at first suspended and can, hence, be executed on a separate thread

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Embedded Programming with Modern C++": January 2025

"Generic Programming (Templates) with C++": February 2025

"Clean Code: Best Practices for Modern C++": May 2025

Do you want to stay informed: Subscribe.

// lazyFutureOnOtherThread.cpp

#include <coroutine>
#include <iostream>
#include <memory>
#include <thread>

template<typename T>
struct MyFuture {
    struct promise_type;
    using handle_type = std::coroutine_handle<promise_type>; 
    handle_type coro;

    MyFuture(handle_type h): coro(h) {}
    ~MyFuture() {
        if ( coro ) coro.destroy();
    }

    T get() {                                           // (1)
        std::cout << "    MyFuture::get:  " 
                  << "std::this_thread::get_id(): " 
                  << std::this_thread::get_id() << '\n';
        
        std::thread t([this] { coro.resume(); });       // (2)
        t.join();
        return coro.promise().result;
    }

    struct promise_type {
        promise_type(){ 
            std::cout << "        promise_type::promise_type:  " 
                      << "std::this_thread::get_id(): " 
                      << std::this_thread::get_id() << '\n';
        }
        ~promise_type(){ 
            std::cout << "        promise_type::~promise_type:  " 
                      << "std::this_thread::get_id(): " 
                      << std::this_thread::get_id() << '\n';
        }

        T result;
        auto get_return_object() {
            return MyFuture{handle_type::from_promise(*this)};
        }
        void return_value(T v) {
            std::cout << "        promise_type::return_value:  " 
                      << "std::this_thread::get_id(): " 
                      << std::this_thread::get_id() << '\n';
            std::cout << v << std::endl;
            result = v;
        }
        std::suspend_always initial_suspend() {
            return {};
        }
        std::suspend_always final_suspend() noexcept {
            std::cout << "        promise_type::final_suspend:  " 
                      << "std::this_thread::get_id(): " 
                      << std::this_thread::get_id() << '\n';
            return {};
        }
        void unhandled_exception() {
            std::exit(1);
        }
    };
};

MyFuture<int> createFuture() {
    co_return 2021;
}

int main() {

    std::cout << '\n';

    std::cout << "main:  " 
              << "std::this_thread::get_id(): " 
              << std::this_thread::get_id() << '\n';

    auto fut = createFuture();
    auto res = fut.get();
    std::cout << "res: " << res << '\n';

    std::cout << '\n';

}

I added a few comments to the program that show the id of the running thread. The program lazyFutureOnOtherThread.cpp is quite similar to the previous program lazyFuture.cpp in the post “Lazy Futures with Coroutines in C++20“. The client calls get (line 1) for the next value. The call std::thread t([this] { coro.resume(); }); (line 2) resumes the coroutine on another thread.

You can try out the program on the Wandbox online compiler.

I want to add a few additional remarks about the member function get. It is crucial that the promise is resumed in a separate thread, and finishes before it returns coro.promise().result; .

T get() {
    std::thread t([this] { coro.resume(); });
    t.join();
    return coro.promise().result;
}

When I join the thread t after the call return coro.promise().result, the program would have undefined behavior. In the following implementation of the function getI use a std::jthread. Here is my post about std::jthread in C++20: “An Improved Thread with C++20“. Since std::jthread automatically joins when it goes out of scope. This is too late.

T get() {   
    std::jthread t([this] { coro.resume(); });
    return coro.promise().result;
}

In this case, the client likely gets its result before the promise prepares it using the member function return_value. Now, result has an arbitrary value, and therefore so does res.

Other possibilities exist to ensure the thread is done before the return call.

std::jthread has its scope

T get() {
    {
        std::jthread t([this] { coro.resume(); });
    }
    return coro.promise().result;
}

Make std::jthread a temporary object

T get() {
    std::jthread([this] { coro.resume(); });
    return coro.promise().result;
}

In particular, I don’t like the last solution because it may take you a few seconds to recognize that I just called the constructor of std::jthread.

Now, it is the right time to add more theories about coroutines.

`promise_type`

You may wonder that the coroutine, such as MyFuture always has inner type promise_type. This name is required. Alternatively, you can specialize std::coroutines_traits on MyFuture and define a public promise_type in it. I mentioned this point explicitly because I know a few people, including me who already fall into this trap.

Here is another trap I fall into on Windows.

`return_void` and `return_value`

The promise needs either the member function return_void or return_value.

The promise needs a return_void member function if
- the coroutine has no co_return statement.
- the coroutine has a co_return statement without argument.
- the coroutine has a co_return expression a statement where the expression has type void.
The promise needs a return_value member function if it returns co_return expression statement where expression must not have the type void

Falling off the end of a void-returning coroutine without a return_void a member function is an undefined behavior. Interestingly, Microsoft, but not the GCC compiler, requires a member function return_void if the coroutine is always suspended at its final suspension point and, therefore, does not fail at the end: std::suspend_always final_suspend() noexcept; From my perspective, the C++20 standard is not clear, and I always add a member function void return_void() {} to my promise type.

What’s next?

After I discussed the new keyword co_return, I want to continue with co_yield. co_yield enables you to create infinite data streams. I will show in my next post, how.

Post Views: 6,700

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS