![\"retriever\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/05\/retriever.jpg\")
<\/p>\nIf you want to have fun with threads, you should share mutable data between them. To get no data race and, therefore, undefined behavior, you have to think about the synchronization of your threads.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
The three rules in this post may be quite obvious for the experienced multithreading developer but crucial for the novice in the multithreading domain. Here are they:<\/p>\n
lock()<\/code>\/unlock()<\/code><\/a><\/li>\n- CP.21: Use
std::lock()<\/code> or std::scoped_lock<\/code> to acquire multiple mutex<\/code>es<\/a><\/li>\n- CP.22: Never call unknown code while holding a lock (e.g., a callback)<\/a><\/li>\n<\/ul>\n
Let’s start with the most obvious rule.<\/p>\n
CP.20: Use RAII, never plain lock()<\/code>\/unlock()<\/code><\/a><\/h2>\nNo naked mutex!<\/strong> Put your mutex always in a lock. The lock will automatically release (unlock) the mutex if it goes out of scope. RAII stands for R<\/strong>esource A<\/strong>cquisition I<\/strong>s I<\/strong>nitialization and means that you bind a resource’s lifetime to a local variable’s lifetime. C++ automatically manages the lifetime of locals.
<\/strong><\/p>\nstd::lock_guard, std::unique_lock, std::shared_lock<\/span> (C++14), or std::std::scoped_lock<\/span> (C++17) implement this pattern but also the smart pointers std::unique_ptr<\/span>, and std::shared_ptr<\/span>. My previous post Garbage Collection – No Thanks<\/a> explains the details to RAII.<\/p>\nWhat does this mean for your multithreading code?<\/p>\n
\nstd::<\/span>mutex mtx;\r\n\r\nvoid<\/span> do_stuff<\/span>()\r\n{\r\n mtx.lock();\r\n \/\/ ... do stuff ... (1)<\/span>\r\n mtx.unlock();\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
It doesn’t matter if an exception occurs in (1) or you just forgot to unlock the mtx<\/span>; in both cases, you will get a deadlock if another thread wants to acquire (lock) the std::mutex mtx<\/span>. The rescue is quite apparent.<\/p>\n\nstd::<\/span>mutex mtx;\r\n\r\nvoid<\/span> do_stuff<\/span>()\r\n{\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lck {mtx};\r\n \/\/ ... do stuff ...<\/span>\r\n} \/\/ (1)<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
Put the mutex into a lock, and the mutex will automatically be unlocked at (1) because the lck<\/span> goes out of scope.<\/p>\n<\/p>\nCP.21: Use std::lock()<\/code> or std::scoped_lock<\/code> to acquire multiple mutex<\/code>es<\/a><\/h2>\nIf a thread needs more than one mutex, you must be extremely careful that you lock the mutexes in the same sequence. If not, a bad interleaving of threads may cause a deadlock. The following program causes a deadlock.<\/p>\n
\n\/\/ lockGuardDeadlock.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <chrono><\/span>\r\n#include <mutex><\/span>\r\n#include <thread><\/span>\r\n\r\nstruct<\/span> CriticalData{\r\n std::<\/span>mutex mut;\r\n};\r\n\r\nvoid<\/span> deadLock<\/span>(CriticalData&<\/span> a, CriticalData&<\/span> b){\r\n\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span>guard1(a.mut); \/\/ (2) <\/span>\r\n std::<\/span>cout <<<\/span> \"Thread: \"<\/span> <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> std::<\/span>endl;\r\n\r\n std::<\/span>this_thread::<\/span>sleep_for(std::<\/span>chrono::<\/span>milliseconds(1<\/span>));\r\n \r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span>guard2(b.mut); \/\/ (2)<\/span>\r\n std::<\/span>cout <<<\/span> \"Thread: \"<\/span> <<<\/span> std::<\/span>this_thread::<\/span>get_id() <<<\/span> std::<\/span>endl;\r\n \r\n \/\/ do something with a and b (critical region) (3)<\/span>\r\n}\r\n\r\nint<\/span> main<\/span>(){\r\n\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n CriticalData c1;\r\n CriticalData c2;\r\n\r\n std::<\/span>thread<\/span> t1([&<\/span>]{deadLock(c1, c2);}); \/\/ (1)<\/span>\r\n std::<\/span>thread<\/span> t2([&<\/span>]{deadLock(c2, c1);}); \/\/ (1)<\/span>\r\n\r\n t1.join();\r\n t2.join();\r\n\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Threads t1<\/span> and t2<\/span> need two resources CriticalData<\/span>, to perform their job (3). CriticalData<\/span> has its own mutex mut<\/span> to synchronize the access. Unfortunately, both invoke the function deadlock<\/span> with the arguments c1<\/span> and c2<\/span> in a different sequence (1). Now we have a race condition. If thread t1<\/span> can lock the first mutex a.mut<\/span> but not the second one b.mu<\/span>t because, in the meantime, thread t2<\/span> locks the second one, we will get a deadlock (2).<\/p>\n ![\"lockGuardDeadlock\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/05\/lockGuardDeadlock.png\")
<\/p>\n
The easiest way to solve the deadlock is to lock both mutexes atomically.<\/p>\n
With C++11, you can use a std::unique_lock<\/span> together with std::lock<\/span>. std::unique_lock<\/span>, you can defer the locking of its mutex. The function std::lock<\/span>, which can lock an arbitrary number of mutexes in an atomic way, does the locking finally.<\/p>\n\nvoid<\/span> deadLock<\/span>(CriticalData&<\/span> a, CriticalData&<\/span> b){\r\n std::<\/span>unique_lock<<\/span>mutex><\/span> guard1(a.mut, std::<\/span>defer_lock);\r\n std::<\/span>unique_lock<<\/span>mutex><\/span> guard2(b.mut, std::<\/span>defer_lock);\r\n std::<\/span>lock(guard1, guard2);\r\n \/\/ do something with a and b (critical region)<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
With C++17, a std::scoped_lock<\/span> can lock an arbitrary number of mutex in one atomic operation.<\/p>\n\nvoid<\/span> deadLock<\/span>(CriticalData&<\/span> a, CriticalData&<\/span> b){\r\n std::<\/span>scoped_lock(a.mut, b.mut);\r\n \/\/ do something with a and b (critical region<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
CP.22: Never call unknown code while holding a lock (e.g., a callback)<\/a><\/h2>\nWhy is this code snippet bad?<\/p>\n
\n
std::mutex m;
{<\/span>\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lockGuard(m);\r\n sharedVariable =<\/span> unknownFunction();\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
I can only speculate about the unknownFunction<\/span>. If unknownFunction<\/span><\/p>\n\n- tries to lock the mutex m<\/span>, that will be undefined behavior. Most of the time, you will get a deadlock.<\/li>\n
- starts a new thread that tries to lock the mutex m<\/span>, you will get a deadlock.<\/li>\n
- locks another mutex m2<\/span>, you may get a deadlock because you lock the two mutexes m<\/span> and m2<\/span> simultaneously. Now another thread may lock the same mutexes in a different sequence.<\/li>\n
- will not directly or indirectly try to lock the mutex m;<\/span> all seems fine. \u201cSeems\u201d because your coworker can modify the function, or the function is dynamically linked, and you get a different version. All bets are open to what may happen.<\/li>\n
- work as expected, you may have a performance problem because you don\u2019t know how long the function unknownFunction<\/span> would take. What is meant to be a multithreaded program may become a single-threaded program.<\/li>\n<\/ul>\n
To solve these issues, use a local variable:<\/p>\n
\nstd::mutex m;
auto<\/span> tempVar =<\/span> unknownFunction();\r\n<\/span>{\r\n std::<\/span>lock_guard<<\/span>std::<\/span>mutex><\/span> lockGuard(m);\r\n sharedVariable =<\/span> tempVar;\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
This additional indirection solves all issues. tempVar<\/span> is a local variable and can not be a victim of a data race. This means that you can invoke unknownFunction<\/span> without a synchronization mechanism. Additionally, the time for holding a lock is reduced to its bare minimum: assigning the value of tempVar<\/span> to sharedVariable<\/span>.<\/p>\nWhat’s next?<\/h2>\n
If you don’t call join or detach on your created thread child, the child will throw a std::terminate<\/span> exception in its destructor. std::terminate<\/code><\/span>calls per default std::abort<\/a><\/span>. To overcome this issue, the guidelines support library<\/a> has a gsl::joining_thread<\/span> which calls join at the end of its scope. I will have a closer look at gsl::joining_thread<\/span> in my next post<\/a>.<\/p>\n <\/p>\n
<\/p>\n
<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
If you want to have fun with threads, you should share mutable data between them. To get no data race and, therefore, undefined behavior, you have to think about the synchronization of your threads.<\/p>\n","protected":false},"author":21,"featured_media":5436,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[372],"tags":[430,433],"class_list":["post-5438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-modern-c","tag-lock","tag-mutex"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5438","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=5438"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5438\/revisions"}],"predecessor-version":[{"id":6827,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5438\/revisions\/6827"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5436"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}