![\"fear](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/06\/fear-cat.jpg\")
<\/p>\nToday, I will finish the rules for concurrency and continue directly with lock-free programming. Yes, you have read it correctly: lock-free programming.<\/p>\n
<\/p>\n
<\/p>\n
Before I write about lock-free programming in particular, here are the three last rules to concurrency.<\/p>\n
lock_guard<\/code>s and unique_lock<\/code>s<\/a><\/li>\n- CP.50: Define a
mutex<\/code> together with the data it guards. Use synchronized_value<T><\/code> where possible<\/a><\/li>\n<\/ul>\nI make it short because these rules are quite obvious.<\/p>\n
CP.43: Minimize time spent in a critical section<\/a><\/h3>\nThe less time your lock a mutex, the more time other threads can run. Have a look at the notification of a condition variable. If you want to see the entire program, read my previous post C++ Core Guidelines: Be Aware of the Traps of Condition Variables<\/a>.<\/p>\n<\/p>\n
\nvoid<\/span> setDataReady<\/span>(){\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\r\n dataReady =<\/span> true<\/span>; \/\/ (1) <\/span>\r\n std::<\/span>cout <<<\/span> \"Data prepared\"<\/span> <<<\/span> std::<\/span>endl; \r\n condVar.notify_one(); \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
The Mutex mutex_<\/span> is locked at the beginning and unlocked at the end of the function. This is not necessary. Only the expression dataReady = true<\/span> (1) has to be protected.<\/p>\nFirst, std::cout<\/span> is thread-safe. The C++11 standard guarantees that each character is written in an atomic step and the correct sequence. Second, the notification condVar.notify_one()<\/span> is thread-safe.<\/p>\nHere is the improved version of the function setDataReady:<\/span><\/p>\n\nvoid<\/span> setDataReady<\/span>(){\r\n { \/\/ Don't remove because of the lifetime of the mutex (1)<\/span>\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck(mutex_);\r\n dataReady =<\/span> true<\/span>;\r\n } (2)<\/span>\r\n std::<\/span>cout <<<\/span> \"Data prepared\"<\/span> <<<\/span> std::<\/span>endl;\r\n condVar.notify_one(); <\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
When I teach this rule in my classes to concurrency, often a question arises: Should you document this artificial scope for limiting the lifetime of the std::lock_guard<\/span> and, therefore, the lifetime of the std::mutex <\/span>(line (1) and (2))? Most of my students, including me, add a comment to this artificial scope. If not, the maintainer of your code may not be aware that the curly braces in line (1) and line (2) are necessary for controlling the lifetime of the mutex. Ultimately, your maintainer will remove the artificial scope because it seems superfluous, and your code uses the first variant.<\/p>\n<\/p>\nCP.44: Remember to name your lock_guard<\/code>s and unique_lock<\/code>s<\/a><\/h3>\nI was a little astonished to read this rule. Here is an example from the guidelines:<\/p>\n
\nunique_lock<<\/span>mutex><\/span>(m1);\r\nlock_guard<<\/span>mutex><\/span> {m2};\r\nlock(m1, m2);\r\n<\/pre>\n<\/div>\n <\/p>\n
The unique_lock<\/span> and lock_guard<\/span> are just temporaries that are created and immediately destroyed. The std::lock_guard<\/span> or std::unique_lock<\/span> locks its mutex and its constructor and unlocks it in its destructor. This pattern is called RAII. Read the details here: Garbage Collection: No Thanks<\/a>.<\/p>\nMy small example shows only the conceptual behavior of a std::lock_guard. <\/span>Its big brother<\/span>std::unique_lock<\/span> supports more operations.<\/span><\/p>\n <\/p>\n
\n\/\/ myGuard.cpp<\/span>\r\n\r\n#include <mutex><\/span>\r\n#include <iostream><\/span>\r\n\r\ntemplate<\/span> <<\/span>typename<\/span> T><\/span>\r\nclass<\/span> MyGuard<\/span>{\r\n T&<\/span> myMutex;\r\n public:<\/span>\r\n MyGuard(T&<\/span> m):<\/span>myMutex(m){\r\n myMutex.lock();\r\n\t std::<\/span>cout <<<\/span> \"lock\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n ~<\/span>MyGuard(){\r\n\t myMutex.unlock();\r\n std::<\/span>cout <<<\/span> \"unlock\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n\t\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\t\r\n std::<\/span>mutex m;\r\n MyGuard<<\/span>std::<\/span>mutex><\/span> {m}; \/\/ (1)<\/span>\r\n std::<\/span>cout <<<\/span> \"CRITICAL SECTION\"<\/span> <<<\/span> std::<\/span>endl; \/\/ (2)<\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n} \/\/ (3)<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
MyGuard<\/span> calls lock and unlock in its constructor and its destructor. Because of the temporary, the call to the constructor and destructor happens in line (1). In particular, this means that the call of the destructor happens at line (1) and not, as usual, in line (3). Consequently, the critical section in line (2) is executed without synchronization.<\/p>\nThis execution of the program shows that the output of “unlock<\/span>” happens before the output of “CRITICAL SECTION<\/span>“.<\/p>\n ![\"myGuard\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/06\/myGuard.png\")
<\/p>\n
CP.50: Define a mutex<\/code> together with the data it guards. Use synchronized_value<T><\/code> where possible<\/a><\/h3>\nThe central idea is to put your mutex into the data you want to protect. With already standardized C++ it looks like this:<\/p>\n
\nstruct<\/span> Record {\r\n std::<\/span>mutex m; \/\/ take this mutex before accessing other members<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
With an upcoming standard, it may look like this because synchronized_value<T><\/span> is not part of the current C++ standard, but it may become part of an upcoming standard.<\/p>\n\nclass<\/span> MyClass<\/span> {\r\n struct<\/span> DataRecord {\r\n \/\/ ...<\/span>\r\n };\r\n synchronized_value<<\/span>DataRecord><\/span> data; \/\/ Protect the data with a mutex<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
According to proposal N4033<\/a> from Anthony Williams: “The basic idea is that synchronized_value<T><\/code> stores a value of type T<\/code> and a mutex. It then exposes a pointer interface, such that dereferencing the pointer yields a special wrapper type that holds a lock on the mutex, and that can be implicitly converted to T<\/code> for reading, and which forwards any values assigned to the assignment operator of the underlying T<\/code> for writing<\/em>.”<\/p>\nThis means that the operation on s in the following code snippet is thread-safe.<\/p>\n
\nsynchronized_value<<\/span>std::<\/span>string><\/span> s;\r\n\r\nstd::<\/span>string readValue()\r\n{\r\n return<\/span> *<\/span>s;\r\n}\r\n\r\nvoid<\/span> setValue(std::<\/span>string const<\/span>&<\/span> newVal)\r\n{\r\n *<\/span>s=<\/span>newVal;\r\n}\r\n \r\nvoid<\/span> appendToValue(std::<\/span>string const<\/span>&<\/span> extra)\r\n{\r\n s-><\/span>append(extra);\r\n}\r\n<\/pre>\n<\/div>\n<\/span><\/p>\nNow as announced, to something completely different: lock-free programming.<\/p>\n
Lock-free programming<\/h2>\n
First, let me state the most crucial meta-rule to lock-free programming.<\/p>\n
Don’t program lock-free<\/h3>\n
Sure, you don’t believe me, but based on my experience giving many concurrency classes and workshops, this is my<\/strong> first rule. Honestly, I agree with many of the most appreciated C++ experts worldwide. Here are the critical statements and cites from their talks:<\/p>\n\n- Herb Sutter<\/strong>: Lock-free programming is like playing with knives.<\/li>\n
- Anthony Williams<\/strong>: “Lock-free programming is about how to shoot yourself in the foot.<\/em>“<\/li>\n
- Tony Van Eerd<\/strong>: “Lock-free coding is the last thing you want to do<\/em>.”<\/li>\n
- Fedor Pikus<\/strong>: “Writing correct lock-free programs is even harder.<\/em>“<\/li>\n
- Harald B\u00f6hm<\/strong>: “The rules are not obvious.<\/em>“<\/li>\n<\/ul>\n
Here is a picture of the statements and cites:<\/p>\n
![\"lockFree\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/06\/lockFree.png\")
<\/p>\n
You still don’t believe me? With C++11, the memory order std::memory_order_consume<\/span> was defined. Seven years later, the official wording is: “The specification of release-consume ordering is being revised, and the use of memory_order_consume<\/code> is temporarily discouraged.<\/em>” (memory_order<\/a>)<\/p>\nIf you know what you do, think about the ABA<\/a> problem in the guidelines CP.100.<\/p>\nCP.100: Don\u2019t use lock-free programming unless you absolutely have to<\/a><\/h3>\nThe following code snippet from the C++ core guidelines has a bug.<\/p>\n
\nextern<\/span> atomic<<\/span>Link*><\/span> head; \/\/ the shared head of a linked list<\/span>\r\n\r\nLink*<\/span> nh =<\/span> new<\/span> Link(data, nullptr); \/\/ make a link ready for insertion<\/span>\r\nLink*<\/span> h =<\/span> head.load(); \/\/ read the shared head of the list<\/span>\r\n\r\ndo<\/span> {\r\n if<\/span> (h-><\/span>data <=<\/span> data) break<\/span>; \/\/ if so, insert elsewhere<\/span>\r\n nh-><\/span>next =<\/span> h; \/\/ next element is the previous head<\/span>\r\n} while<\/span> (!<\/span>head.compare_exchange_weak(h, nh)); \/\/ write nh to head or to h<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
Find the bug and write me an e-mail. I will mention the best problem analysis in my next post if you like your name.<\/p>\n
What’s next?<\/h2>\n