One of the participants in my CppCon 2018 workshop asked me: "Can a std::thread be interrupted?". No, that 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 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 the 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 is 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 thread synchronization mechanisms, enabling some threads to 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 much easier to use than threads or condition variables; conversely, they have a significant deficiency. They can not be composed. C++20 will overcome this deficiency.

C++20 will have atomic smart pointers. To be exact, 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 are overloaded, and a few new ones are added. The overloaded and new algorithms can be invoked with a so-called execution policy. Using the execution policy, you can specify whether the algorithm should run sequentially, parallel, or parallel and vectorized.