{"id":5191,"date":"2017-02-16T18:43:10","date_gmt":"2017-02-16T18:43:10","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/multithreading-in-c-17-and-c-20\/"},"modified":"2023-06-26T12:22:35","modified_gmt":"2023-06-26T12:22:35","slug":"multithreading-in-c-17-and-c-20","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/multithreading-in-c-17-and-c-20\/","title":{"rendered":"Multithreading with C++17 and C++20"},"content":{"rendered":"

Forecasts about the future are difficult. In particular, when they are about C++20. Nevertheless, I will look into the crystal ball and write in the following posts about what we will get with C++17  and what we can hope for with C++20.<\/p>\n

<\/p>\n

 <\/p>\n

\"timelineCpp17andCpp20\"<\/p>\n

Since C++11, C++ faces the requirements of multicore architectures. The 2011 published standard defines how a program should behave in the presence of many threads. The multithreading capabilities of C++11 consist of two parts. On the one hand, there is the well-defined memory model; on the other hand, there is the standardized threading API.<\/p>\n

The well-defined memory model deals with the following questions.<\/p>\n

    \n
  1. What are atomic operations?<\/li>\n
  2. Which sequence of operations is guaranteed?<\/li>\n
  3. When are the memory effects of operations visible?<\/li>\n<\/ol>\n

    The standardized threading interface in C++11 consists of the following components.<\/p>\n

      \n
    1. Threads<\/li>\n
    2. Tasks<\/li>\n
    3. Thread-local data<\/li>\n
    4. Condition variables<\/li>\n<\/ol>\n

      If that is not too boring, read the posts about the memory model <\/a>and the standardized threading API<\/a>.<\/p>\n

      Wearing my multithreading glasses, C++14 has not have much to offer. C++14 added Reader-Writer Locks<\/a>.<\/p>\n

      The question, which arises, is: What has the C++ future to offer?<\/p>\n

       <\/p>\n

      \"timelineCpp17andCpp20<\/p>\n

      C++17<\/h2>\n

      With C++17, most of the algorithms of the Standard Template Library will be available in a parallel version. Therefore, you can invoke an algorithm with a so-called execution policy. This execution policy specifies if the algorithm runs sequential (std::seq)<\/span>, parallel (std::par<\/span>), or parallel and vectorized (std::par_unseq<\/span>).<\/p>\n

      \n
      <\/span><\/span>\r\nstd::vector<int<\/span>> vec ={3, 2, 1, 4, 5, 6, 10, 8, 9, 4};\r\n<\/span>\r\nstd::sort(vec.begin(), vec.end());                            \/\/ sequential as ever<\/span>\r\nstd::sort(std::execution::seq, vec.begin(), vec.end());       \/\/ sequential<\/span>\r\nstd::sort(std::execution::par, vec.begin(), vec.end());       \/\/ parallel<\/span>\r\nstd::sort(std::execution::par_unseq, vec.begin(), vec.end()); \/\/ parallel and vectorized<\/span>\r\n<\/pre>\n<\/div>\n
       <\/p>\n
      Therefore, the first and second variations of the sort algorithm run sequential, the third parallel, and the fourth parallel and vectorized.<\/p>\n
      C++20 offers totally new multithreading concepts. The key idea is that multithreading becomes a lot simpler and less error-prone.<\/p>\n<\/p>\n
      C++20<\/h2>\n
      Atomic smart pointer<\/h3>\n
      The atomic smart pointers std::shared_ptr<\/span> and std::weak_ptr<\/span> have a conceptual issue in multithreading programs. They share a mutable state. Therefore, they a prone to data races <\/a>and, therefore, undefined behavior. std::shared_ptr<\/span> and std::weak_ ptr<\/span> guarantee that the in- or decrementing of the reference counter is an atomic operation and the resource will be deleted exactly once. Still, both do not guarantee that the access to its resource is atomic. The new atomic smart pointers solve this issue.<\/p>\n
      \n
      std::atomic_shared_ptr\r\nstd::atomic_weak_ptr\r\n<\/pre>\n<\/div>\n
       <\/p>\n
      With tasks called promises and futures, we got a new multithreading concept in C++11. Although tasks have a lot to offer, they have a big drawbacks. Futures can not be composed in C++11.<\/p>\n
      std::future extensions<\/h3>\n
      That will not hold for futures in C++20. Therefore, a future becomes ready, when<\/p>\n