StarMirror/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2024-03-22 13:30:58 +08:00
Code Issues Projects Releases Wiki Activity

Replace invalid uses of defer_lock in C.21 with adopt_lock

Browse Source
This commit is contained in:
Jonathan Wakely 2017-03-27 11:59:16 +01:00
parent 1b51c917d0
commit 85543a94e9
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
CppCoreGuidelines.md
View File

@ -12112,7 +12112,7 @@ Flag calls of member `lock()` and `unlock()`. ???
##### Reason ##### Reason
To avoid deadlocks on multiple `mutex`s To avoid deadlocks on multiple `mutex`es.
##### Example ##### Example
@ -12129,14 +12129,14 @@ This is asking for deadlock:
Instead, use `lock()`: Instead, use `lock()`:
// thread 1 // thread 1
lock_guard<mutex> lck1(m1, defer_lock);
lock_guard<mutex> lck2(m2, defer_lock);
lock(lck1, lck2); lock(lck1, lck2);
lock_guard<mutex> lck1(m1, adopt_lock);
lock_guard<mutex> lck2(m2, adopt_lock);
// thread 2 // thread 2
lock_guard<mutex> lck2(m2, defer_lock);
lock_guard<mutex> lck1(m1, defer_lock);
lock(lck2, lck1); lock(lck2, lck1);
lock_guard<mutex> lck2(m2, adopt_lock);
lock_guard<mutex> lck1(m1, adopt_lock);
or (better, but C++17 only): or (better, but C++17 only):
@ -12153,9 +12153,9 @@ Here, the writers of `thread1` and `thread2` are still not agreeing on the order
In real code, `mutex`es are rarely named to conveniently remind the programmer of an intended relation and intended order of acquisition. In real code, `mutex`es are rarely named to conveniently remind the programmer of an intended relation and intended order of acquisition.
In real code, `mutex`es are not always conveniently acquired on consecutive lines. In real code, `mutex`es are not always conveniently acquired on consecutive lines.
I'm really looking forward to be able to write plain In C++17 it's possible to write plain
lock_guard lck1(m1, defer_lock); lock_guard lck1(m1, adopt_lock);
and have the `mutex` type deduced. and have the `mutex` type deduced.