{"id":5196,"date":"2017-02-20T17:14:20","date_gmt":"2017-02-20T17:14:20","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/atomic-smart-pointers\/"},"modified":"2023-06-26T12:22:17","modified_gmt":"2023-06-26T12:22:17","slug":"atomic-smart-pointers","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/atomic-smart-pointers\/","title":{"rendered":"Atomic Smart Pointers"},"content":{"rendered":"

C++20 will have atomic smart pointers. To be exact, we will get a std::atomic_shared_ptr<\/span> and a std::atomic_weak_ptr<\/span>. But why? std::shared_pt<\/span>r and std::weak_ptr<\/span> are already thread-safe. Sort of. Let me dive into the details.<\/p>\n

<\/p>\n

 <\/p>\n

Before I start, I want to make a short detour. This detour should only emphasize how important it is that the std::shared_ptr<\/span> has well-defined multithreading semantics, and you know and use it. From the multithreading point of view, std::shared_ptr<\/span> is this kind of data structure you will not use in multithreading programs. They are, by definition, shared and mutable; therefore they are the ideal candidates for data races and hence for undefined behavior. On the other hand, there is a guideline in modern C++: Don’t touch memory. That means, using smart pointers in multithreading programs.  <\/p>\n<\/p>\n

Half thread-safe<\/h2>\n

I often have the question in my C++ seminars: Are smart pointers thread-safe? My defined answer is yes and no. Why? A std::shared_ptr<\/span> consists of a control block and its resource. Yes, the control block is thread-safe; but no, the access to the resource is not thread-safe. That means, modifying the reference counter is an atomic operation and you have the guarantee that the resource will be deleted exactly once. These are all guarantees a std::shared_ptr<\/span> gives you.<\/p>\n

The assertion that a std::shared_ptr<\/span> provides is described by Boost.<\/a><\/p>\n

    \n
  1. A shared_pt<\/span>r instance can be “read” (accessed using only const operations) simultaneously by multiple threads.<\/li>\n
  2. Different shared_ptr<\/span> instances can be “written to” (accessed using mutable operations such as operator= or reset) simultaneously by multiple threads (even when these instances are copies and share the same reference count underneath.)<\/li>\n<\/ol>\n

    To make the two statements clear, let me show a simple example. When you copy a std::shared_ptr<\/span> in a thread, all is fine.<\/p>\n

    \n
    std::shared_ptr<int<\/span>> ptr = std::make_shared<int<\/span>>(2011);\r\n\r\nfor<\/span> (auto<\/span> i= 0; i<10; i++){\r\n   std::thread<\/span>([ptr]{                           (1)\r\n     std::shared_ptr<int<\/span>> localPtr(ptr);        (2)\r\n     localPtr= std::make_shared<int>(2014);     (3)\r\n    }).detach(); \r\n}\r\n<\/pre>\n<\/div>\n
    At first to (2). By using copy construction for the std::shared_ptr localPtr<\/span>, only the control block is used. That is thread-safe. (3) is a little bit more interesting.  localPtr<\/span>  (3) <\/span>is set to a new  std::shared_ptr.<\/span> This is from the multithreading point of view, no problem: Die lambda-function <\/span>(1) binds ptr<\/span> by copy. Therefore, the modification of localPtr<\/span> takes place on a copy.<\/span><\/p>\n
    The story will change dramatically if I take the std::shared_ptr<\/span> by reference.<\/p>\n
    \n
    std::shared_ptr<int<\/span>> ptr = std::make_shared<int<\/span>>(2011);  \r\n<\/span><\/span>\r\nfor<\/span> (auto<\/span> i= 0; i<10; i++){\r\n   std::thread<\/span>([&ptr]{                         (1)\r\n     ptr= std::make_shared<int<\/span>>(2014);         (2)\r\n   }).detach(); \r\n}\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    The lambda function binds the std::shared_ptr<\/span> ptr<\/span> by reference (1). Therefore assignment (2) is a race condition on the resource, and the program has undefined behavior.<\/p>\n
    Admittedly that was not so easy to get. std::shared_ptr<\/span> requires special attention in a multithreading environment. They are very special. They are the only non-atomic data types in C+ for which atomic operations exist.<\/p>\n
    Atomic Operations for std::shared_ptr<\/h2>\n
    There are specializations for the atomic operations load,<\/span> store,<\/span> compare<\/span> and exchange<\/span> for a std::shared_ptr<\/span>.  By using the explicit<\/span> variant, you can even specify the memory model.<\/span> Here are the free atomic operations for std::shared_ptr.<\/span><\/p>\n
    \n
    std::atomic_is_lock_free(std::shared_ptr)\r\nstd::atomic_load(std::shared_ptr)\r\nstd::atomic_load_explicit(std::shared_ptr)\r\nstd::atomic_store(std::shared_ptr)\r\nstd::atomic_store_explicit(std::shared_ptr)\r\nstd::atomic_exchange(std::shared_ptr)\r\nstd::atomic_exchange_explicit(std::shared_ptr)\r\nstd::atomic_compare_exchange_weak(std::shared_ptr)\r\nstd::atomic_compare_exchange_strong(std::shared_ptr)\r\nstd::atomic_compare_exchange_weak_explicit(std::shared_ptr)\r\nstd::atomic_compare_exchange_strong_explicit(std::shared_ptr)\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    For the details, have a look at cppreference.com.<\/a> Now it is quite easy to modify a by reference bounded std::shared_ptr<\/span> in a thread-safe way.<\/p>\n
    \n
    std::shared_ptr<int<\/span>> ptr = std::make_shared<int<\/span>>(2011);\r\n\r\nfor<\/span> (auto<\/span> i =0;i<10;i++){\r\n   std::thread<\/span>([&ptr]{ \r\n     auto<\/span> localPtr= std::make_shared<int<\/span>>(2014);\r\n     std::atomic_store(&ptr, localPtr);            (1)\r\n   }).detach(); \r\n}\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    The update of the std::shared_ptr ptr<\/span> (1) is thread-safe. All is well? NO<\/strong>. Finally, we come to the new atomic smart pointers.<\/p>\n
    Atomic smart pointers<\/h2>\n
    The proposal <\/span>N4162<\/a> for atomic smart pointers directly addresses the deficiencies of the current implementation. The deficiencies boil down to three points consistency, correctness, and performance. Here is an overview of the three points. For the details, you have to read the proposal.<\/p>\n
    Consistency: <\/strong> The atomic operations for the std::shared_ptr<\/span> are the only ones for a non-atomic data type.<\/p>\n
    Correctness:<\/strong> Using free atomic operations is error-prone because the right usage is based on discipline. It’s quite easy to forget to use an atomic operation – such as in the last example: I use prt= localPtr<\/span> instead of std::atomic_store(&ptr, localPtr)<\/span>. The result is undefined behavior because of a data race. If we have instead used an atomic smart pointer, the compiler will not allow it. <\/p>\n
    Performance:<\/strong> The std::atomic_shared_ptr<\/span> and std::atomic_weak_ptr<\/span> have a significant advantage over the free atomic_*<\/span> functions. They are designed for the particular use case multithreading and can have a std::atomic_flag<\/span> as a kind of cheap Spinlock<\/a>. (You can read the details about s <\/span><\/span>spinlocks and std::atomic_flag<\/span> in the post The Atomic Flag<\/a>). It makes of course, not so much sense to put for a possible multithreading use cases an std::atomic_flag<\/span> in each std::shared_ptr<\/span> or std::weak_ptr<\/span> to make them thread-safe. <\/span>But that would be the consequence if both have a spinlock for the multithreading use case, and we would have no atomic smart pointers. That means std::shared_ptr<\/span> and std::weak_ptr<\/span> would have been optimized for the particular use case.<\/p>\n
    For me, the correct argument is the most important one. Why? The answer lies in the proposal. The proposal presents a thread-safe singly-linked list that supports insertion, deletion, and finding of elements. This singly-linked list is implemented in a lock-free way.<\/p>\n
    A thread-safe singly-linked list<\/h3>\n
     <\/p>\n
    \n
    template<\/span><typename<\/span> T> class<\/span> concurrent_stack<\/span> {\r\n    struct<\/span> Node { T t; shared_ptr<Node> next; };\r\n    atomic_<\/span>shared_ptr<Node> head;\r\n          \/\/ in C++11: remove \u201catomic_\u201d and remember to use the special\r\n          \/\/ functions every time you touch the variable<\/span>\r\n    concurrent_stack( concurrent_stack &) =delete<\/span>;\r\n    void<\/span> operator<\/span>=(concurrent_stack&) =delete<\/span>;\r\n\r\npublic:\r\n    concurrent_stack() =default<\/span>;\r\n    ~concurrent_stack() =default<\/span>;\r\n    class<\/span> reference<\/span> {\r\n        shared_ptr<Node> p;\r\n    public:\r\n       reference(shared_ptr<Node> p_) : p{p_} { }\r\n       T& operator<\/span>* () { return<\/span> p->t; }\r\n       T* operator<\/span>->() { return<\/span> &p->t; }\r\n    };\r\n\r\n    auto<\/span> find( T t ) const<\/span> {\r\n        auto<\/span> p = head.load();  \/\/ in C++11: atomic_load(&head)<\/span>\r\n        while<\/span>( p && p->t != t )\r\n            p = p->next;\r\n        return<\/span> reference(move(p));\r\n    }\r\n    auto<\/span> front() const<\/span> {\r\n       return<\/span> reference(head); \/\/ in C++11: atomic_load(&head)<\/span>\r\n    }\r\n    void<\/span> push_front( T t ) {\r\n      auto<\/span> p = make_shared<Node>();\r\n      p->t = t;\r\n      p->next = head;         \/\/ in C++11: atomic_load(&head)<\/span>\r\n      while<\/span>( !head.compare_exchange_weak(p->next, p) ){ }\r\n      \/\/ in C++11: atomic_compare_exchange_weak(&head, &p->next, p);<\/span>\r\n    }\r\n    void<\/span> pop_front() {\r\n       auto<\/span> p = head.load();\r\n       while<\/span>( p && !head.compare_exchange_weak(p, p->next) ){ }\r\n       \/\/ in C++11: atomic_compare_exchange_weak(&head, &p, p->next);<\/span>\r\n    }\r\n};\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    All changes necessary to compile the program with a C++11 compiler are in red. The implementation of atomic smart pointers is a lot easier and hence less error-prone. C++20 does not permit it to use a non-atomic operation on a std::atomic_shared_ptr<\/span>.<\/p>\n
    What’s next?<\/h2>\n
    C++11 got tasks like promises and futures an advanced multithreading concept. Although they offer a lot more threads, they have a significant shortcoming. C++11 futures can not be composed. Extended futures in C++20 will overcome this shortcoming. How? Read the next post<\/a>.<\/p>\n
     <\/p>\n
     <\/p>\n
     <\/p>\n
     <\/p>\n<\/p>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    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.<\/p>\n","protected":false},"author":21,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[367],"tags":[434,399],"class_list":["post-5196","post","type-post","status-publish","format-standard","hentry","category-multithreading-c-17-and-c-20","tag-atomics","tag-smart-pointers"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5196","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=5196"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5196\/revisions"}],"predecessor-version":[{"id":6885,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5196\/revisions\/6885"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5196"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5196"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5196"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}