{"id":5428,"date":"2018-04-21T04:17:06","date_gmt":"2018-04-21T04:17:06","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-rules-for-concurrency-and-parallelism\/"},"modified":"2023-06-26T11:52:23","modified_gmt":"2023-06-26T11:52:23","slug":"c-core-guidelines-rules-for-concurrency-and-parallelism","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-core-guidelines-rules-for-concurrency-and-parallelism\/","title":{"rendered":"C++ Core Guidelines: Rules for Concurrency and Parallelism"},"content":{"rendered":"

C++11 is the first C++ standard that deals with concurrency. The basic building block for concurrency is a thread; therefore, most rules are explicitly about threads. This changed dramatically with C++17.
<\/span><\/p>\n

 <\/p>\n

<\/p>\n

 \"timeline11<\/p>\n

 <\/p>\n

With C++17<\/strong> we got the Standard Template Library (STL) parallel algorithms. That means, most of the algorithms of the STL can be executed sequential, parallel, or vectorized. For the curious reader: I have already written two posts to the parallel STL. The post Parallel Algorithms of the Standard Template Librar<\/a>y explains the execution policy in which you can run an existing algorithm sequentially, parallel, or parallel and vectorize. C++17 also gave new algorithms meant to run in parallel or vectorized. Here are the details: C++17: New Parallel Algorithms of the Standard Template Library.<\/a>
<\/span><\/p>\n

The concurrency story in C++ goes on. With C++20, we can hope for extended futures, coroutines, transactions, and more. From the bird’s eye view, the concurrency facilities of C++11 and C++14 are only the implementation details on which the higher abstraction of C++17 and C++20 are based. Here is a series of posts about the concurrent future in C++20<\/a>.
<\/span><\/p>\n

Said that the rules are mainly about threads because neither GCC nor Clang or MSVC  has fully implemented the parallel algorithms of the STL. Best practices cannot be written to features that are not available (parallel STL) or even not standardized.  <\/p>\n

This is the first rule to remember when you read the rules. These rules are about available multithreading in C++11 and C++14. The second rule to keep in mind is that multithreading is very challenging. This means the rules want to give guidance to the novice and not to the experts in this domain. The rules of the memory model will follow in the future.<\/p>\n

Now, let’s start and dive into the first rule.<\/p>\n

CP.1: Assume that your code will run as part of a multi-threaded program<\/a><\/h2>\n

I was astonished when I read this rule the first time. Why should I optimize for the special case? To make it clear, this rule is mainly about code that is used in libraries, not in the application. And the experience shows that library code is often reused. This means you maybe optimize for the general case, which is fine.<\/p>\n

To make the point of the rule clear, here is a small example.<\/p>\n

 <\/p>\n

\n
double<\/span> cached_computation<\/span>(double<\/span> x)\r\n{\r\n    static<\/span> double<\/span> cached_x =<\/span> 0.0<\/span>;                       \/\/ (1)<\/span>\r\n    static<\/span> double<\/span> cached_result =<\/span> COMPUTATION_OF_ZERO;  \/\/ (2)<\/span>\r\n    double<\/span> result;\r\n\r\n    if<\/span> (cached_x ==<\/span> x)                                  \/\/ (1)<\/span>\r\n        return<\/span> cached_result;                           \/\/ (2)<\/span>\r\n    result =<\/span> computation(x);\r\n    cached_x =<\/span> x;                                       \/\/ (1)<\/span>\r\n    cached_result =<\/span> result;                             \/\/ (2)<\/span>\r\n    return<\/span> result;\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The function cached_computation<\/span> is fine if it runs in a single-threaded environment. This will not hold for a multithreading environment because the static variables cached_x<\/span> (1) and cached_result<\/span> (2) can be used simultaneously by many threads, and they are modified during their usage. The C++11 standard adds multithreading semantics to static variables with block scope such as cached_x and cached_result. Static variables with block scope are initialized in C++11 in a thread-safe way.<\/strong><\/p>\n
This is fine but will not help in our case. We will get a data race if we invoke cached_computation<\/span> simultaneously from many threads. The notion of a data race is essential in multithreading in C++; therefore, let me write about it. <\/p>\n
A data race<\/strong> is a situation, in which at least two threads access a shared variable simultaneously. At least one thread tries to modify the variable.<\/p>\n
The rest is quite simple. If you have a data race in your program, your program has undefined behavior. Undefined behavior means you can not reason anymore about your program because all can happen. I mean all. In my seminars, I often say: If your program has undefined behavior, it has catch-fire semantics. Even your computer can catch fire.<\/p>\n
If you read the definition of data race quite carefully, you will notice that a shared mutable state is necessary for having a data race. Here is a picture to make this observation quite obvious.<\/p>\n
 \"SharedMutable\"<\/p>\n
So, what can you do to get rid of the data race? Making the static variables cached_x<\/span> (1) and cached_result<\/span> (2) immutable (const<\/span>) makes no sense. This means both static should not be shared. Here are a few ways to achieve this.<\/p>\n
    \n
  1. Protect both static by their own lock.<\/li>\n
  2. Use one lock to protect the entire critical region.<\/li>\n
  3. Protect the call to the function cached_computation <\/span>by a lock. <\/span><\/span><\/li>\n
  4. Make both static thread_local<\/span><\/span>. tread_local<\/span> guarantees that each thread gets its variable cached_x<\/span> and cached_result<\/span>. Such as, a static variable is bound to the lifetime of the main thread, and a thread_loca<\/span>l variable is bound to the lifetime of its thread.<\/li>\n<\/ol>\n
    Here are variations 1, 2, 3, and 4.<\/p>\n
    \n
    std::<\/span>mutex m_x;\r\nstd::<\/span>mutex m_result;\r\ndouble<\/span> cached_computation<\/span>(double<\/span> x){                \/\/ (1)<\/span>\r\n    static<\/span> double<\/span> cached_x =<\/span> 0.0<\/span>;\r\n    static<\/span> double<\/span> cached_result =<\/span> COMPUTATION_OF_ZERO;\r\n\t\r\n    double<\/span> result;\r\n    {\r\n\tstd::<\/span>scoped_lock(m_x, m_result);\r\n        if<\/span> (cached_x ==<\/span> x) return<\/span> cached_result;\r\n    }\r\n    result =<\/span> computation(x);\r\n    {\r\n\tstd::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(m_x);\r\n        cached_x =<\/span> x;\r\n    }\r\n    { \r\n\tstd::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(m_result);  \r\n        cached_result =<\/span> result;\r\n    }\r\n    return<\/span> result;\r\n}\r\n\r\nstd::<\/span>mutex m;\r\ndouble<\/span> cached_computation<\/span>(double<\/span> x){                \/\/ (2)<\/span>\r\n    static<\/span> double<\/span> cached_x =<\/span> 0.0<\/span>;\r\n    static<\/span> double<\/span> cached_result =<\/span> COMPUTATION_OF_ZERO;\r\n    double<\/span> result;\r\n    {\r\n        std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(m);\r\n\tif<\/span> (cached_x ==<\/span> x) return<\/span> cached_result;\r\n\tresult =<\/span> computation(x);\r\n\tcached_x =<\/span> x;\r\n\tcached_result =<\/span> result;\r\n    }\r\n    return<\/span> result;\r\n}\r\n\r\nstd::<\/span>mutex cachedComputationMutex;                  \/\/ (3)<\/span>\r\n{\r\n    std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(cachedComputationMutex);\r\n    auto<\/span> cached =<\/span> cached_computation(3.33<\/span>);\r\n}\r\n\r\n\r\ndouble<\/span> cached_computation(double<\/span> x){                \/\/ (4)<\/span>\r\n    thread_local double<\/span> cached_x =<\/span> 0.0<\/span>;\r\n    thread_local double<\/span> cached_result =<\/span> COMPUTATION_OF_ZERO;\r\n    double<\/span> result;\r\n\r\n    if<\/span> (cached_x ==<\/span> x) return<\/span> cached_result;\r\n    result =<\/span> computation(x);\r\n    cached_x =<\/span> x;\r\n    cached_result =<\/span> result;\r\n    return<\/span> result;\r\n}\r\n<\/pre>\n<\/div>\n
     <\/p>\n
    First, the C++11 standard guarantees that static variables are initialized in a thread-safe way; therefore, I don’t have to protect their initialization in all programs.<\/p>\n
      \n
    1. This version is tricky because I have to acquire both locks in an atomic step. C++17 supports std::scoped_lock<\/span>, which can lock an arbitrary number of mutexes in an atomic step. In C++11, you have to use instead of a std::unqiue_lock<\/span> in combination with the function std::lock<\/span>.  My previous post Prefer Locks to Mutexes <\/a>provides you with more details. This solution has a race condition on cached_x<\/span> and cached_result<\/span> because they must be accessed atomically.<\/strong><\/li>\n
    2. Version 2 uses a more coarse-grained locking. Usually, you should not use coarse-grained locks such as in the version but instead use fine-grained locking, but in this use case, it may be fine.<\/li>\n
    3. This is the most coarse-grained solution because the entire function is locked. Of course, the downside is that the user of the function is responsible for the synchronization. In general, that is a bad idea.<\/li>\n
    4. Just make the static variables thread_loca<\/span>l, and you are done<\/span><\/span><\/span> <\/span><\/li>\n<\/ol>\n
      In the end, it is a question of performance and your users. Therefore try each variation, measure, and think about the people who should use and maintain your code.<\/p>\n
      What’s next?<\/h2>\n
      This post was just the starting point through a long journey of rules to concurrency in C++. In the next post<\/a>, I will take about threads and shared state.<\/p>\n
       <\/p>\n
       <\/p>\n
       <\/p>\n
       <\/p>\n
       <\/p>\n<\/p>\n
       <\/div>\n
       <\/div>\n","protected":false},"excerpt":{"rendered":"
      C++11 is the first C++ standard that deals with concurrency. The basic building block for concurrency is a thread; therefore, most rules are explicitly about threads. This changed dramatically with C++17.  <\/p>\n","protected":false},"author":21,"featured_media":5426,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[372],"tags":[430,487],"class_list":["post-5428","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-modern-c","tag-lock","tag-thread_local"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5428","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=5428"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5428\/revisions"}],"predecessor-version":[{"id":6830,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5428\/revisions\/6830"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5426"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5428"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5428"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5428"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}