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, 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. 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.
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.
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 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 member function is undefined behavior. 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.
hanks 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, Darshan Mody, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, espkk, Wolfgang Gärtner, Louis St-Amour, Stephan Roslen, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Avi Kohn, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Tobi Heideman, and Samuel Burch.
Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, and Richard Sargeant.
My special thanks to Embarcadero
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)
Deutsch
- Embedded Programmierung mit modernem C++: 12.04.2021 - 14.04.2021, Termingarantie
- Clean Code mit modernem C++: 22.06.2021 - 24.06.2021
- C++20: 10.08.2021 - 12.08.2021
English
- Workshop: Concepts in C++20: 22.03.2021 (17:00 - 21:00 CET)
- Workshop: Coroutines in C++20: 06.04.2021 (17:00 - 21:00 CEST)
Standard Seminars
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 Patterns and Architecture Patterns with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
New
Contact Me
- Tel.: +49 7472 917441
- Mobil: +49 152 31965939
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- English Seminar Page: www.ModernesCpp.net