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.


 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

// 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)
        return coro.promise().result;

    struct promise_type {
            std::cout << "        promise_type::promise_type:  " 
                      << "std::this_thread::get_id(): " 
                      << std::this_thread::get_id() << '\n';
            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() {

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(); });
    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.


Rainer D 6 P2 540x540Modernes C++ Mentoring

Be part of my mentoring programs:





Do you want to stay informed about my mentoring programs: Subscribe via E-Mail.


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.

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, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, 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, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, and Rob North.


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



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small


My special thanks to PVS-Studio PVC Logo


My special thanks to Tipi.build tipi.build logo


My special thanks to Take Up Code TakeUpCode 450 60



I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)


Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

  • C++ - The Core Language
  • C++ - The Standard Library
  • C++ - Compact
  • C++11 and C++14
  • Concurrency with Modern C++
  • Design Pattern and Architectural Pattern with C++
  • Embedded Programming with Modern C++
  • Generic Programming (Templates) with C++


  • Clean Code with Modern C++
  • C++20

Contact Me

Modernes C++,



+1 #1 Christof Franke 2021-03-17 13:15
What is the rationale for starting a new thread only to wait until this new thread is finished? It is far more efficient to call the thread function directly.

Stay Informed about my Mentoring



English Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Course: The All-in-One Guide to C++20

Course: Master Software Design Patterns and Architecture in C++

Subscribe to the newsletter (+ pdf bundle)

All tags

Blog archive

Source Code


Today 1360

Yesterday 6503

Week 27617

Month 7863

All 12086072

Currently are 228 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments