使用锁的层次结构
虽然，定义锁的顺序是一种特殊情况，但锁的层次的意义在于提供对运行时约定是否被坚持的检查。这个建议需要对你的应用进行分层，并且识别在给定层上所有可上锁的互斥量。当代码试图对一个互斥量上锁，在该层锁已被低层持有时，上锁是不允许的。你可以在运行时对其进行检查，通过分配层数到每个互斥量上，以及记录被每个线程上锁的互斥量。下面的代码列表中将展示两个线程如何使用分层互斥。
清单3.7 使用层次锁来避免死锁
hierarchical_mutex high_level_mutex(10000); // 1 hierarchical_mutex low_level_mutex(5000); // 2 hierarchical_mutex other_mutex(6000); // 3 int do_low_level_stuff(); int low_level_func() { std::lock_guard<hierarchical_mutex> lk(low_level_mutex); // 4 return do_low_level_stuff(); } void high_level_stuff(int some_param); void high_level_func() { std::lock_guard<hierarchical_mutex> lk(high_level_mutex); // 6 high_level_stuff(low_level_func()); // 5 } void thread_a() // 7 { high_level_func(); } void do_other_stuff(); void other_stuff() { high_level_func(); // 10 do_other_stuff(); } void thread_b() // 8 { std::lock_guard<hierarchical_mutex> lk(other_mutex); // 9 other_stuff(); }
这段代码有三个hierarchical_mutex实例(①，②和③)，其通过逐渐递减的层级数量进行构造。
根据已经定义好的机制，如你已将一个hierarchical_mutex实例进行上锁，那么你只能获取更低层级hierarchical_mutex实例上的锁，这就会对代码进行一些限制。
假设do_low_level_stuff不会对任何互斥量进行上锁，low_level_func为层级最低的函数，并且会对low_level_mutex④进行上锁。high_level_func调用low_level_func⑤的同时，也持有high_level_mutex⑥上的锁，这也没什么问题，因为high_level_mutex(①：10000)要比low_level_mutex(②：5000)更高级。
thread_a()⑦遵守规则，所以它运行的没问题。
另一方面，thread_b()⑧无视规则，因此在运行的时候肯定会失败。
首先，thread_b锁住了other_mutex⑨，这个互斥量的层级值只有6000③。这就意味着，中层级的数据已被保护。当other_stuff()调用high_level_func()⑧时，就违反了层级结构：
high_level_func()试图获取high_level_mutex，这个互斥量的层级值是10000，要比当前层级值6000大很多。因此hierarchical_mutex将会产生一个错误，可能会是抛出一个异常，或直接终止程序。在层级互斥量上产生死锁，是不可能的，因为互斥量本身会严格遵循约定顺序，进行上锁。这也意味，当多个互斥量在是在同一级上时，不能同时持有多个锁，所以“手递手”锁的方案需要每个互斥量在一条链上，并且每个互斥量都比其前一个有更低的层级值，这在某些情况下无法实现。
例子也展示了另一点， std::lock_guard<> 模板与用户定义的互斥量类型一起使用。虽然
hierarchical_mutex不是C++标准的一部分，但是它写起来很容易；一个简单的实现在列表3.8中展示出来。尽管它是一个用户定义类型，它可以用于 std::lock_guard<> 模板中，因为它的实现有三个成员函数为了满足互斥量操作：lock(), unlock() 和 try_lock()。虽然你还没见过try_lock()怎么使用，但是其使用起来很简单：当互斥量上的锁被一个线程持有，它将返回false，而不是等待调用的线程，直到能够获取互斥量上的锁为止。在 std::lock() 的内部实现中，try_lock()会作为避免死锁算法的一部分。列表3.8 简单的层级互斥量实现
class hierarchical_mutex { std::mutex internal_mutex; unsigned long const hierarchy_value; unsigned long previous_hierarchy_value; static thread_local unsigned long this_thread_hierarchy_value; // 1 void check_for_hierarchy_violation() { if(this_thread_hierarchy_value <= hierarchy_value) // 2 { throw std::logic_error(“mutex hierarchy violated”); } } void update_hierarchy_value() { previous_hierarchy_value=this_thread_hierarchy_value; // 3 this_thread_hierarchy_value=hierarchy_value; } public: explicit hierarchical_mutex(unsigned long value): hierarchy_value(value), previous_hierarchy_value(0) {} void lock() { check_for_hierarchy_violation(); internal_mutex.lock(); // 4 update_hierarchy_value(); // 5 } void unlock() { if(this_thread_hierarchy_value!=hierarchy_value) throw std::logic_error(“mutex hierarchy violated”); // 9 this_thread_hierarchy_value=previous_hierarchy_value; // 6 internal_mutex.unlock(); } bool try_lock() { check_for_hierarchy_violation(); if(!internal_mutex.try_lock()) // 7 return false; update_hierarchy_value(); return true; } }; thread_local unsigned long hierarchical_mutex::this_thread_hierarchy_value(ULONG_MAX); // 8
这里重点是使用了thread_local的值来代表当前线程的层级值：
- this_thread_hierarchy_value①。它被初始化为最大值⑧，所以最初所有线程都能被锁住。因为其声明中有thread_local，所以每个线程都有其拷贝副本，这样线程中变量状态完全独立，当从另一个线程进行读取时，变量的状态也完全独立。参见附录A，A.8节，有更多与thread_local相关的内容。
所以，第一次线程锁住一个hierarchical_mutex时，this_thread_hierarchy_value的值是
ULONG_MAX。由于其本身的性质，这个值会大于其他任何值，所以会通过
check_for_hierarchy_vilation()②的检查。在这种检查方式下，lock()代表内部互斥锁已被锁住④。一旦成功锁住，你可以更新层级值了⑤。
当你现在锁住另一个hierarchical_mutex时，还持有第一个锁，this_thread_hierarchy_value的值将会显示第一个互斥量的层级值。第二个互斥量的层级值必须小于已经持有互斥量检查函数②才能通过。
现在，最重要的是为当前线程存储之前的层级值，所以你可以调用unlock()⑥对层级值进行保存；否则，就锁不住任何互斥量(第二个互斥量的层级数高于第一个互斥量)，即使线程没有持有任何锁。因为保存了之前的层级值，只有当持有internal_mutex③，且在解锁内部互斥量⑥之前存储它的层级值，才能安全的将hierarchical_mutex自身进行存储。这是因为
hierarchical_mutex被内部互斥量的锁所保护着。为了避免无序解锁造成层次结构混乱，当解锁的互斥量不是最近上锁的那个互斥量，就需要抛出异常⑨。其他机制也能做到这点，但目前这个是最简单的。
try_lock()与lock()的功能相似，除了在调用internal_mutex的try_lock()⑦失败时，不能持有对应锁，所以不必更新层级值，并直接返回false。
虽然是运行时检测，但是它没有时间依赖性——不必去等待导致死锁出现的罕见条件。同
时，设计过程需要去拆分应用，互斥量在这种情况下可以消除导致死锁的可能性。这样的练习很有必要去做一下，即使你之后没有去做，代码也会在运行时进行检查。
超越锁的延伸扩展如我在本节开头提到的那样，死锁不仅仅会发生在锁之间；死锁也会发生在任何同步构造中(可能会产生一个等待循环)，因此这方面也需要有指导意见，例如：要去避免获取嵌套锁等待一个持有锁的线程是一个很糟糕的决定，因为线程为了能继续运行可能需要获取对应的锁。
类似的，如果去等待一个线程结束，它应该可以确定这个线程的层级，这样一个线程只需要等待比其层级低的线程结束即可。用一个简单的办法便可确定，以添加的线程是否在同一函数中被启动，如同在3.1.2节和3.3节中描述的那样。
代码已能规避死锁， std::lock() 和 std::lock_guard 可组成简单的锁，并覆盖大多数情况，但是有时需要更多的灵活性。在这种情况下，可以使用标准库提供的 std::unique_lock 模
板。
如 std::lock_guard ，这是一个参数化的互斥量模板类，并且它提供很多RAII类型锁用来管理 std::lock_guard 类型，可以让代码更加灵活。
3.2.6 std::unique_lock——灵活的锁
std::unqiue_lock 使用更为自由的不变量，这样 std::unique_lock 实例不会总与互斥量的数据类型相关，使用起来要比 std:lock_guard 更加灵活。首先，可将 std::adopt_lock 作为第二个参数传入构造函数，对互斥量进行管理；也可以将 std::defer_lock 作为第二个参数传递进去，表明互斥量应保持解锁状态。这样，就可以被 std::unique_lock 对象(不是互斥量)的
lock()函数所获取，或传递 std::unique_lock 对象到 std::lock() 中。清单3.6可以轻易的转换为清单3.9，使用 std::unique_lock 和 std::defer_lock ①，而
非 std::lock_guard 和 std::adopt_lock 。代码长度相同，几乎等价，唯一不同的就
是： std::unique_lock 会占用比较多的空间，并且比 std::lock_guard 稍慢一些。保证灵活性要付出代价，这个代价就是允许 std::unique_lock 实例不带互斥量：信息已被存储，且已被更新。
清单3.9 交换操作中 std::lock() 和 std::unique_lock 的使用
class some_big_object; void swap(some_big_object& lhs,some_big_object& rhs); class X { private: some_big_object some_detail; std::mutex m; public: X(some_big_object const& sd):some_detail(sd){} friend void swap(X& lhs, X& rhs) { if(&lhs==&rhs) return; std::unique_lock<std::mutex> lock_a(lhs.m,std::defer_lock); // 1 std::unique_lock<std::mutex> lock_b(rhs.m,std::defer_lock); // 1 std::defer_lock 留下未上锁的互斥量 std::lock(lock_a,lock_b); // 2 互斥量在这里上锁 swap(lhs.some_detail,rhs.some_detail); } };
列表3.9中，因为 std::unique_lock 支持lock(), try_lock()和unlock()成员函数，所以能
将 std::unique_lock 对象传递到 std::lock() ②。这些同名的成员函数在低层做着实际的工
作，并且仅更新 std::unique_lock 实例中的标志，来确定该实例是否拥有特定的互斥量，这个标志是为了确保unlock()在析构函数中被正确调用。如果实例拥有互斥量，那么析构函数必须调用unlock()；但当实例中没有互斥量时，析构函数就不能去调用unlock()。这个标志可以通过owns_lock()成员变量进行查询。除非你想将 std::unique_lock 的所有权进行转让，或是对其做一些其他的事情外，你最好使用C++17中提供的 std::scoped_lock (详见3.2.4节)。
如你期望的那样，这个标志被存储在某个地方。因此， std::unique_lock 对象的体积通常要比 std::lock_guard 对象大，当使用 std::unique_lock 替代 std::lock_guard ，因为会对标志进行适当的更新或检查，就会做些轻微的性能惩罚。当 std::lock_guard 已经能够满足你的需求时，还是建议你继续使用它。当需要更加灵活的锁时，最好选择 std::unique_lock ，因为它更适合于你的任务。你已经看到一个递延锁的例子，另外一种情况是锁的所有权需要从一个域转到另一个域。
3.2.7 不同域中互斥量所有权的传递
std::unique_lock 实例没有与自身相关的互斥量，一个互斥量的所有权可以通过移动操作，在不同的实例中进行传递。某些情况下，这种转移是自动发生的，例如：当函数返回一个实例；另些情况下，需要显式的调用 std::move() 来执行移动操作。从本质上来说，需要依赖于源值是否是左值——一个实际的值或是引用——或一个右值——一个临时类型。当源值是一个右值，为了避免转移所有权过程出错，就必须显式移动成左值。 std::unique_lock 是可移动，但不可赋值的类型。附录A，A.1.1节有更多与移动语句相关的信息。
一种使用可能是允许一个函数去锁住一个互斥量，并且将所有权移到调用者上，所以调用者可以在这个锁保护的范围内执行额外的动作。
下面的程序片段展示了：函数get_lock()锁住了互斥量，然后准备数据，返回锁的调用函数。
std::unique_lock<std::mutex> get_lock() { extern std::mutex some_mutex; std::unique_lock<std::mutex> lk(some_mutex); prepare_data(); return lk; // 1 } void process_data() { std::unique_lock<std::mutex> lk(get_lock()); // 2 do_something(); }
lk在函数中被声明为自动变量，它不需要调用 std::move() ，可以直接返回①(编译器负责调用移动构造函数)。process_data()函数直接转移 std::unique_lock 实例的所有权②，调用do_something()可使用的正确数据(数据没有受到其他线程的修改)。
通常这种模式会用于已锁的互斥量，其依赖于当前程序的状态，或依赖于传入返回类型
为 std::unique_lock 的函数(或以参数返回)。这样不会直接返回锁，不过网关类的一个数据成员可用来确认已经对保护数据的访问权限进行上锁。这种情况下，所有的访问都必须通过网关类：当你想要访问数据，需要获取网关类的实例(如同前面的例子，通过调用get_lock()之类函数)来获取锁。之后你就可以通过网关类的成员函数对数据进行访问。当完成访问，可以销毁这个网关类对象，将锁进行释放，让别的线程来访问保护数据。这样的一个网关类可能是可移动的(所以他可以从一个函数进行返回)，这种情况下锁对象的数据必须可移动。
std::unique_lock 的灵活性同样也允许实例在销毁之前放弃其拥有的锁。可以使用unlock()来做这件事，如同一个互斥量： std::unique_lock 的成员函数提供类似于锁定和解锁互斥量的功能。 std::unique_lock 实例在销毁前释放锁的能力，当锁没有必要在持有的时候，可以在特定的代码分支对其进行选择性的释放。这对于应用性能来说很重要，因为持有锁的时间增加会导致性能下降，其他线程会等待这个锁的释放，避免超越操作。
3.2.8 锁的粒度
3.2.3节中，已经对锁的粒度有所了解：锁的粒度是一个摆手术语(hand-waving term)，用来描述通过一个锁保护着的数据量大小。一个细粒度锁(a fine-grained lock)能够保护较小的数据量，一个粗粒度锁(a coarse-grained lock)能够保护较多的数据量。选择粒度对于锁来说很重要，为了保护对应的数据，保证锁有能力保护这些数据也很重要。我们都知道，在超市等待结账的时候，正在结账的顾客突然意识到他忘了拿蔓越莓酱，然后离开柜台去拿，并让其他的人都等待他回来；或者当收银员，准备收钱时，顾客才去翻钱包拿钱，这样的情况都会让等待的顾客很无奈。当每个人都检查了自己要拿的东西，且能随时为拿到的商品进行支付，那么的每件事都会进行的很顺利。
道理同样适用于线程：如果很多线程正在等待同一个资源(等待收银员对自己拿到的商品进行清点)，当有线程持有锁的时间过长，这就会增加等待的时间(别等到结账的时候，才想起来蔓越莓酱没拿)。可能的情况下，锁住互斥量的同时只能对共享数据进行访问；试图对锁外数据进行处理。特别是做一些费时的动作，比如：对文件的输入/输出操作进行上锁。文件输入/输出通常要比从内存中读或写同样长度的数据慢成百上千倍，所以除非锁已经打算去保护对文件的访问，要么执行输入/输出操作将会将延迟其他线程执行的时间，这没有必要(因为文件锁阻塞住了很多操作)，这样多线程带来的性能效益会被抵消。
std::unique_lock 在这种情况下工作正常，调用unlock()时，代码不需要再访问共享数据；而后当再次需要对共享数据进行访问时，就可以再调用lock()了。下面代码就是这样的一种情况：
void get_and_process_data() { std::unique_lock<std::mutex> my_lock(the_mutex); some_class data_to_process=get_next_data_chunk(); my_lock.unlock(); // 1 不要让锁住的互斥量越过process()函数的调用 result_type result=process(data_to_process); my_lock.lock(); // 2 为了写入数据，对互斥量再次上锁 write_result(data_to_process,result); }
不需要让锁住的互斥量越过对process()函数的调用，所以可以在函数调用①前对互斥量手动解锁，并且在之后对其再次上锁②。
这能表示只有一个互斥量保护整个数据结构时的情况，不仅会有更多对锁的竞争，也会增加持锁的时间。较多的操作步骤需要获取同一个互斥量上的锁，所以持有锁的时间会更长。成本上的双重打击也算是为向细粒度锁转移提供了双重激励和可能。
如同上面的例子，锁不仅是能锁住合适粒度的数据，还要控制锁的持有时间，以及哪些操作在执行的同时能够拥有锁。一般情况下，执行必要的操作时，尽可能将持有锁的时间缩减到最小。
这也就意味有一些浪费时间的操作，比如：获取另外一个锁(即使你知道这不会造成死锁)，或等待输入/输出操作完成时没有必要持有一个锁(除非绝对需要)。
清单3.6和3.9中，交换操作需要锁住两个互斥量，其明确要求并发访问两个对象。假设用来做比较的是一个简单的数据类型(比如：int类型)，将会有什么不同么？int的拷贝很廉价，所以可以很容易的进行数据复制，并且每个被比较的对象都持有该对象的锁，在比较之后进行数据拷贝。这就意味着，在最短时间内持有每个互斥量，并且你不会在持有一个锁的同时再去获取另一个。下面的清单中展示了一个在这样情景中的Y类，并且展示了一个相等比较运算符的等价实现。
列表3.10 比较操作符中一次锁住一个互斥量
class Y { private: int some_detail; mutable std::mutex m; int get_detail() const { std::lock_guard<std::mutex> lock_a(m); // 1 return some_detail; } public: Y(int sd):some_detail(sd){} friend bool operator==(Y const& lhs, Y const& rhs) { if(&lhs==&rhs) return true; int const lhs_value=lhs.get_detail(); // 2 int const rhs_value=rhs.get_detail(); // 3 return lhs_value==rhs_value; // 4 } };
例子中，比较操作符首先通过调用get_detail()成员函数检索要比较的值②③，函数在索引值时被一个锁保护着①。比较操作符会在之后比较索引出来的值④。注意：虽然这样能减少锁持有的时间，一个锁只持有一次(这样能消除死锁的可能性)，这里有一个微妙的语义操作同时对两个锁住的值进行比较。
列表3.10中，当操作符返回true时，那就意味着在这个时间点上的lhs.some_detail与在另一个时间点的rhs.some_detail相同。这两个值在读取之后，可能会被任意的方式所修改；两个值会在②和③处进行交换，这样就会失去比较的意义。等价比较可能会返回true，来表明这两个值时相等的，实际上这两个值相等的情况可能就发生在一瞬间。这样的变化要小心，语义操作是无法改变一个问题的比较方式：当你持有锁的时间没有达到整个操作时间，就会让自己处于条件竞争的状态。
有时，没有一个合适粒度级别，因为并不是所有对数据结构的访问都需要同一级的保护。这个例子中，就需要寻找一个合适的机制，去替换 std::mutex 。
[1] Tom Cargill, “Exception Handling: A False Sense of Security,” in C++ Report 6, no. 9
(November–December 1994). Also available at
http://www.informit.com/content/images/020163371x/supplements/Exception_Handling_Artic
le.html.
[2] Herb Sutter, Exceptional C++: 47 Engineering Puzzles, Programming Problems, and
Solutions (Addison Wesley Pro-fessional, 1999).
3.3 保护共享数据的其他方式
互斥量一种通用的机制，但其并非保护共享数据的唯一方式。有很多替代方式可以在特定情况下，对共享数据提供更加合适的保护。
一个特别极端(但十分常见)的情况就是，共享数据在并发访问和初始化时(都需要保护)，但是之后需要进行隐式同步。这可能是因为数据作为只读方式创建，所以没有同步问题；或者因为必要的保护作为对数据操作的一部分。任何情况下，数据初始化后锁住一个互斥量，纯粹是为了保护其初始化过程(这是没有必要的)，并且会给性能带来不必要的冲击。出于以上的原因，C++标准提供了一种纯粹保护共享数据初始化过程的机制。
