{"id":6078,"date":"2021-01-29T08:54:57","date_gmt":"2021-01-29T08:54:57","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/barriers-in-c-20\/"},"modified":"2023-06-26T09:33:28","modified_gmt":"2023-06-26T09:33:28","slug":"barriers-in-c-20","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/barriers-in-c-20\/","title":{"rendered":"Barriers and Atomic Smart Pointers in C++20"},"content":{"rendered":"

In my last post, I introduced latches in C++20. A latch enables its threads to wait until a counter becomes zero. Additionally to a latch, its big sibling barrier can be used more than once. Today, I write about barriers and present atomic smart pointers.<\/p>\n

<\/p>\n

 \"TimelineCpp20\"<\/p>\n

If you are not familiar with std::latch, read my last post: Latches in C++20<\/a>.<\/p>\n

std::barrier<\/code><\/h2>\n

There are two differences between a std::latch<\/code> and a std::barrier<\/code>. A std::latch<\/code> is useful for managing one task by multiple threads; a std::barrier<\/code> helps manage repeated tasks by multiple threads. Additionally, a std::barrier<\/code> enables you to execute a function in the so-called completion step. The completion step is the state when the counter becomes zero. Immediately after the counter becomes zero, the so-called completion step starts. In this completion step, a callable is invoked. The std::barrier<\/code> gets its callable in its constructor. A callable unit (short callable) behaves like a function. Not only are these named functions but also function objects or lambda expressions.<\/p>\n

The completion step performs the following steps:<\/p>\n

    \n
  1. All threads are blocked.<\/li>\n
  2. An arbitrary thread is unblocked and executes the callable.<\/li>\n
  3. If the completion step is done, all threads are unblocked.<\/li>\n<\/ol>\n

    The following table presents you with the interface of a std::barrier bar.<\/code><\/p>\n

    \"barrier\"<\/p>\n

     <\/p>\n

    The call bar.arrive_and_drop()<\/code> call means essentially that the counter is decremented by one for the next phase. The following program fullTimePartTimeWorkers.cpp<\/code> halves the number of workers in the second phase.<\/p>\n

    <\/p>\n

    \n
    \/\/ fullTimePartTimeWorkers.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <barrier><\/span>\r\n#include <mutex><\/span>\r\n#include <string><\/span>\r\n#include <thread><\/span>\r\n\r\nstd::<\/span>barrier workDone(6<\/span>);\r\nstd::<\/span>mutex coutMutex;\r\n\r\nvoid<\/span> synchronizedOut<\/span>(const<\/span> std::<\/span>string&<\/span> s) noexcept {\r\n    std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lo(coutMutex);\r\n    std::<\/span>cout <<<\/span> s;\r\n}\r\n\r\nclass<\/span> FullTimeWorker<\/span> {                                                   \/\/ (1)<\/span>\r\n public:<\/span>\r\n    FullTimeWorker(std::<\/span>string n):<\/span> name(n) { };\r\n  \r\n    void<\/span> operator<\/span>() () {\r\n        synchronizedOut(name +<\/span> \": \"<\/span> +<\/span> \"Morning work done!<\/span>\\n<\/span>\"<\/span>);\r\n        workDone.arrive_and_wait();  \/\/ Wait until morning work is done     (3)<\/span>\r\n        synchronizedOut(name +<\/span> \": \"<\/span> +<\/span> \"Afternoon work done!<\/span>\\n<\/span>\"<\/span>);\r\n        workDone.arrive_and_wait();  \/\/ Wait until afternoon work is done   (4)<\/span>\r\n        \r\n    }\r\n private:<\/span>\r\n    std::<\/span>string name;\r\n};\r\n  \r\nclass<\/span> PartTimeWorker<\/span> {                                                   \/\/ (2)<\/span>\r\n public:<\/span>\r\n    PartTimeWorker(std::<\/span>string n):<\/span> name(n) { };\r\n  \r\n    void<\/span> operator<\/span>() () {\r\n        synchronizedOut(name +<\/span> \": \"<\/span> +<\/span> \"Morning work done!<\/span>\\n<\/span>\"<\/span>);\r\n        workDone.arrive_and_drop();  \/\/ Wait until morning work is done  \/\/ (5)<\/span>\r\n    }\r\n private:<\/span>\r\n    std::<\/span>string name;\r\n};\r\n\r\nint<\/span> main<\/span>() {\r\n\r\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n\r\n    FullTimeWorker herb(\"  Herb\"<\/span>);\r\n    std::<\/span>thread<\/span> herbWork(herb);\r\n  \r\n    FullTimeWorker scott(\"    Scott\"<\/span>);\r\n    std::<\/span>thread<\/span> scottWork(scott);\r\n  \r\n    FullTimeWorker bjarne(\"      Bjarne\"<\/span>);\r\n    std::<\/span>thread<\/span> bjarneWork(bjarne);\r\n  \r\n    PartTimeWorker andrei(\"        Andrei\"<\/span>);\r\n    std::<\/span>thread<\/span> andreiWork(andrei);\r\n  \r\n    PartTimeWorker andrew(\"          Andrew\"<\/span>);\r\n    std::<\/span>thread<\/span> andrewWork(andrew);\r\n  \r\n    PartTimeWorker david(\"            David\"<\/span>);\r\n    std::<\/span>thread<\/span> davidWork(david);\r\n\r\n    herbWork.join();\r\n    scottWork.join();\r\n    bjarneWork.join();\r\n    andreiWork.join();\r\n    andrewWork.join();\r\n    davidWork.join();\r\n  \r\n}\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    This workflow consists of two kinds of workers: full-time workers (1) and part-time workers (2). The part-time worker works in the morning, and the full-time worker in the morning and the afternoon. Consequently, the full-time workers call workDone.arrive_and_wait()<\/code> (lines (3) and (4)) two times. On the contrary, part-time works call workDone.arrive_and_drop()<\/code> (5) only once. This workDone.arrive_and_drop()<\/code> call causes the part-time worker to skip the afternoon work. Accordingly, the counter has in the first phase (morning) the value 6, and in the second phase (afternoon) the value 3.<\/p>\n
    \"fullTimePartTimeWorkers\"<\/p>\n
    Now to something I missed in my posts on atomics.<\/p>\n<\/p>\n
    Atomic Smart Pointers<\/h2>\n
    A std::shared_ptr<\/code> consists of a control block and its resource. The control block is thread-safe, but access to the resource is not. This means modifying the reference counter is an atomic operation, and you have the guarantee that the resource is deleted exactly once. These are the guarantees std::shared_ptr<\/code> given you.<\/p>\n
    On the contrary, it is crucial that a std::shared_ptr<\/code> has well-defined multithreading semantics. At first glance, the use of a std::shared_ptr<\/code> does not appear to be a sensible choice for multithreaded code. It is, by definition, shared and mutable and is the ideal candidate for non-synchronized read and write operations and hence for undefined behavior. On the other hand, there is a guideline in modern C++: Don’t use raw pointers<\/strong>. Consequently, you should use smart pointers in multithreading programs when you want to model shared ownership.<\/p>\n
    The proposal N4162<\/a> for atomic smart pointers directly addresses the deficiencies of the current implementation. The deficiencies boil down to these three points: consistency, correctness, and performance.<\/p>\n