Tasks

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.

Based on the coroutines-based implementation of a simple future in my last post "Implementing Simple Futures with Coroutines", I want to go today one big step further. I analyze the workflow of the simple future and make it lazy.

Instead of return, a coroutine uses co_return returning its result. In this post, I want to implement a simple coroutine using co_return.

Sender/receiver workflows are quite common for threads. In such a workflow, the receiver is waiting for the sender's notification before it continues to work. There are various ways to implement these workflows. With C++11, you can use condition variables or promise/future pairs; with C++20, you can use atomics.

After the last post to executors, I can now finally write about the unified futures. I write in the post about the long past of the futures and end my detour from the C++ core guidelines.

Writing multithreading programs is hard, even harder if the program should be correct. The rules of the C++ Core Guidelines guide you to write correct programs. The rules of this post will deal with data races, sharing of data, tasks, and the infamous keyword volatile.

Tasks in the form of promises and futures have in C++11 an ambivalent reputation. On the one hand, they are a lot easier to use than threads or condition variables; on the other hand, they have a great deficiency. They can not be composed. C++20 will overcome this deficiency.

Until now, I've used two strategies for the summation of a std::vector. First, I did the whole math in one thread (Single Threaded: Summation of a vector); second multiple threads shared the same variable for the result (Multithreaded: Summation of a vector). In particular, the second strategy was extremely naive. In this post, I will apply my knowledge of both posts. My goal is that the thread will perform their summation as independently from each other as possible and therefore reduce the synchronization overhead. 

In case you use promise and future to synchronize threads, they have much in common with condition variables. But most of the time, tasks are the better choice.

The parent of a thread has to take care of their child. The parent can wait until his child is done or detach himself from his child. But that is not really new. But that will not hold for std::async. The big charm of std::async is that the parent has not taken care of his child.