One of the participants in my CppCon 2018 workshop asked me: "Can a std::thread be interrupted?". No, was my answer but this is not correct anymore. With C++20 we might get a std::jthread.

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.

A few weeks ago, one of the authors of the proposal to the futures in C++ Felix Petriconi wrote me an E-Mail. He said my article about std::future Extensions is quite dated. Honestly, he is right. The future of the futures changed mainly because of executors.

Task blocks use the well-known fork-join paradigm for the parallel execution of tasks.

Transactional memory is based on the idea of a transaction from the database theory. Transactional memory shall make the handling of threads a lot easier. That for two reasons. Data races and deadlocks disappear. Transactions are composable.

Coroutines are functions that can suspend and resume their execution while keeping their state. The evolution in C++20 goes one step further.

Latches and barriers are simple to thread synchronisation mechanism which enables it that some threads wait until a counter becomes zero. We will presumably in C++20 get latches and barriers in three variations: std::latch, std::barrier, and std::flex_barrier.

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.

C++20 will have atomic smart pointers. To be exactly, we will get a std::atomic_shared_ptr and a std::atomic_weak_ptr. But why? std::shared_ptr and std::weak_ptr are already thread-safe. Sort of. Let me dive into the details.

The idea is quite simple. The Standard Template has more than 100 algorithms for searching, counting, and manipulating ranges and their elements. With C++17, 69 of them are overloaded and a few new ones are added. The overloaded and new algorithms can be invoked with a so-called execution policy. By using the execution policy, you can specify whether the algorithm should run sequential, parallel, or parallel and vectorise.