Executing a Future in a Separate Thread with Coroutines

Contents[Show]

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

 

TimelineCpp20

Before I continue, I want to emphasize. 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 happened so far in this mini-series. Each post is base 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

// 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 ín the post "Lazy Futures with Coroutines in C++20". The main difference is the member function get (line 1). 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.

lazyFutureOnOtherThread

 

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

 

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

 

Where I to join the thread t after the call return coro.promise().result, the program would have undefined behavior. In the following implementation of the function get, I 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, it is highly likely that the client 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.

lazyFutureOnOtherThreadLateJoin

 
There are other possibilities to ensure that the thread is done before the return call.
 
  • std::jthread has its own 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 theory about coroutines.

promise_type

You may wonder that the coroutine such as MyFuture has always 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 which 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 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 undefined behaviour. Interestingly, the 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 of 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 my discussion of the new keyword co_return, I want to continue with co_yield. co_yield enables you to create infinite data streams. I show in my next post, how.

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, Marko, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, espkk, Wolfgang Gärtner, Louis St-Amour, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Tobi Heideman, Daniel Hufschläger, Red Trip, Alexander Schwarz, Tornike Porchxidze, Alessandro Pezzato, and Evangelos Denaxas.

 

Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, and Richard Sargeant.

My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small

 

Seminars

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

Bookable (Online)

German

Standard Seminars (English/German)

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

New

Contact Me

Modernes C++,

RainerGrimmSmall

Comments   

+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.
Quote

My Newest E-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

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code

Visitors

Today 1326

Yesterday 7507

Week 24457

Month 84086

All 6312558

Currently are 219 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments