From 85543a94e9e3d8841dcfdcb72bb659fe8e935a72 Mon Sep 17 00:00:00 2001
From: Jonathan Wakely <cxx@kayari.org>
Date: Mon, 27 Mar 2017 11:59:16 +0100
Subject: [PATCH] Replace invalid uses of defer_lock in C.21 with adopt_lock

---
 CppCoreGuidelines.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md
index fd69278..8c38c63 100644
--- a/CppCoreGuidelines.md
+++ b/CppCoreGuidelines.md
@@ -12112,7 +12112,7 @@ Flag calls of member `lock()` and `unlock()`.  ???
 
 ##### Reason
 
-To avoid deadlocks on multiple `mutex`s
+To avoid deadlocks on multiple `mutex`es.
 
 ##### Example
 
@@ -12129,14 +12129,14 @@ This is asking for deadlock:
 Instead, use `lock()`:
 
     // thread 1
-    lock_guard<mutex> lck1(m1, defer_lock);
-    lock_guard<mutex> lck2(m2, defer_lock);
     lock(lck1, lck2);
+    lock_guard<mutex> lck1(m1, adopt_lock);
+    lock_guard<mutex> lck2(m2, adopt_lock);
 
     // thread 2
-    lock_guard<mutex> lck2(m2, defer_lock);
-    lock_guard<mutex> lck1(m1, defer_lock);
     lock(lck2, lck1);
+    lock_guard<mutex> lck2(m2, adopt_lock);
+    lock_guard<mutex> lck1(m1, adopt_lock);
 
 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 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.