3.3.1 保护共享数据的初始化过程
假设你有一个共享源，构建代价很昂贵，它可能会打开一个数据库连接或分配出很多的内
存。
延迟初始化(Lazy initialization)在单线程代码很常见——每一个操作都需要先对源进行检查，为了了解数据是否被初始化，然后在其使用前决定，数据是否需要初始化：
std::shared_ptr<some_resource> resource_ptr; void foo() { if(!resource_ptr) { resource_ptr.reset(new some_resource); // 1 } resource_ptr->do_something(); }
转为多线程代码时，只有①处需要保护，这样共享数据对于并发访问就是安全的，但是下面天真的转换会使得线程资源产生不必要的序列化。为了确定数据源已经初始化，每个线程必须等待互斥量。
清单 3.11 使用一个互斥量的延迟初始化(线程安全)过程
std::shared_ptr<some_resource> resource_ptr; std::mutex resource_mutex; void foo() { std::unique_lock<std::mutex> lk(resource_mutex); // 所有线程在 此序列化 if(!resource_ptr) { resource_ptr.reset(new some_resource); // 只有初始化过程需要保 护 } lk.unlock(); resource_ptr->do_something(); }
这段代码相当常见了，也足够表现出没必要的线程化问题，很多人能想出更好的一些的办法来做这件事，包括声名狼藉的“双重检查锁模式”：
void undefined_behaviour_with_double_checked_locking() { if(!resource_ptr) // 1 { std::lock_guard<std::mutex> lk(resource_mutex); if(!resource_ptr) // 2 { resource_ptr.reset(new some_resource); // 3 } } resource_ptr->do_something(); // 4 }
指针第一次读取数据不需要获取锁①，并且只有在指针为NULL时才需要获取锁。然后，当获取锁之后，指针会被再次检查一遍② (这就是双重检查的部分)，避免另一的线程在第一次检查后再做初始化，并且让当前线程获取锁。
这个模式为什么声名狼藉呢？因为这里有潜在的条件竞争。未被锁保护的读取操作①没有与其他线程里被锁保护的写入操作③进行同步，因此就会产生条件竞争，这个条件竞争不仅覆盖指针本身，还会影响到其指向的对象；即使一个线程知道另一个线程完成对指针进行写入，它可能没有看到新创建的some_resource实例，然后调用do_something()④后，得到不正确的结果。这个例子是在一种典型的条件竞争——数据竞争，C++标准中这就会被指定为“未定义行为”。这种竞争是可以避免的。阅读第5章时，那里有更多对内存模型的讨论，也包括数据竞争的构成。(译者注：著名的《C++和双重检查锁定模式(DCLP)的风险》可以作为补充材料供大家参考 英文版 中文版)
C++标准委员会也认为条件竞争的处理很重要，所以C++标准库提供
了 std::once_flag 和 std::call_once 来处理这种情况。比起锁住互斥量并显式的检查指针，每个线程只需要使用 std::call_once 就可以，在 std::call_once 的结束时，就能安全的知道指针已经被其他的线程初始化了。使用 std::call_once 比显式使用互斥量消耗的资源更少，特别是当初始化完成后。下面的例子展示了与清单3.11中的同样的操作，这里使用
了 std::call_once 。在这种情况下，初始化通过调用函数完成，这样的操作使用类中的函数操作符来实现同样很简单。如同大多数在标准库中的函数一样，或作为函数被调用，或作为参数被传递， std::call_once 可以和任何函数或可调用对象一起使用。
std::shared_ptr<some_resource> resource_ptr; std::once_flag resource_flag; // 1 void init_resource() { resource_ptr.reset(new some_resource); } void foo() { std::call_once(resource_flag,init_resource); // 可以完整的进行一 次初始化 resource_ptr->do_something(); }
这个例子中， std::once_flag ①和初始化好的数据都是命名空间区域的对象，但 std::call_once() 可仅作为延迟初始化的类型成员，如同下面的例子一样：
清单3.12 使用 std::call_once 作为类成员的延迟初始化(线程安全)
class X { private: connection_info connection_details; connection_handle connection; std::once_flag connection_init_flag; void open_connection() { connection=connection_manager.open(connection_details); } public: X(connection_info const& connection_details_): connection_details(connection_details_) {} void send_data(data_packet const& data) // 1 { std::call_once(connection_init_flag,&X::open_connection,this); // 2 connection.send_data(data); } data_packet receive_data() // 3 { std::call_once(connection_init_flag,&X::open_connection,this); // 2 return connection.receive_data(); } };
例子中第一次调用send_data()①或receive_data()③的线程完成初始化过程。使用成员函数open_connection()去初始化数据，也需要将this指针传进去。和其在在标准库中的函数一样，其接受可调用对象，比如 std::thread 的构造函数和 std::bind() ，通过向 std::call_once() ②传递一个额外的参数来完成这个操作。
值得注意的是， std::mutex 和 std::once_flag 的实例不能拷贝和移动，需要通过显式定义相应的成员函数，对这些类成员进行操作。
还有一种初始化过程中潜存着条件竞争：其中一个局部变量被声明为static类型，这种变量的在声明后就已经完成初始化；对于多线程调用的函数，这就意味着这里有条件竞争——抢着去定义这个变量。很多在不支持C++11标准的编译器上，在实践过程中，这样的条件竞争是确实存在的，因为在多线程中，每个线程都认为他们是第一个初始化这个变量线程；或一个线程对变量进行初始化，而另外一个线程要使用这个变量时，初始化过程还没完成。在C++11标准中，这些问题都被解决了：初始化及定义完全在一个线程中发生，并且没有其他线程可在初始化完成前对其进行处理，条件竞争终止于初始化阶段，这样比在之后再去处理好的多。
在只需要一个全局实例情况下，这里提供一个 std::call_once 的替代方案
class my_class; my_class& get_my_class_instance() { static my_class instance; // 线程安全的初始化过程 return instance; }
多线程可以安全的调用get_my_class_instance()①函数，不用为数据竞争而担心。
对于很少有更新的数据结构来说，只在初始化时保护数据。大多数情况下，这种数据结构是只读的，并且多线程对其并发的读取也是很愉快的，不过一旦数据结构需要更新，就会产生竞争。
3.3.2 保护不常更新的数据结构
试想，为了将域名解析为其相关IP地址，我们在缓存中的存放了一张DNS入口表。通常，给定DNS数目在很长的一段时间内保持不变。虽然，在用户访问不同网站时，新的入口可能会被添加到表中，但是这些数据可能在其生命周期内保持不变。所以定期检查缓存中入口的有效性，就变的十分重要了；但是，这也需要一次更新，也许这次更新只是对一些细节做了改动。
虽然更新频度很低，但更新也有可能发生，并且当这个可缓存被多个线程访问，这个缓存就需要处于更新状态时得到保护，这也为了确保每个线程读到都是有效数据。
没有使用专用数据结构时，这种方式是符合预期，并为并发更新和读取特别设计的(更多的例子在第6和第7章中介绍)。这样的更新要求线程独占数据结构的访问权，直到其完成更新操作。
当更新完成，数据结构对于并发多线程访问又会是安全的。使用 std::mutex 来保护数据结构，显的有些反应过度(因为在没有发生修改时，它将削减并发读取数据的可能性)。这里需要另一种不同的互斥量，这种互斥量常被称为“读者-作者锁”，因为其允许两种不同的使用方式：
- 一个“作者”线程独占访问和共享访问，让多个“读者”线程并发访问。
C++17标准库提供了两种非常好的互斥量—— std::shared_mutex 和 std::shared_timed_mutex 。C++14只提供了 std::shared_timed_mutex ，并且在C++11中并未提供任何互斥量类型。如果你还在用支持C++14标准之前的编译器，那你可以使用Boost库中实现的互斥量。 std::shared_mutex 和 std::shared_timed_mutex 的不同点在
于， std::shared_timed_mutex 支持更多的操作方式(参考4.3节)， std::shared_mutex 有更高的性能优势，从而不支持更多的操作。
你将在第8章中看到，这种锁的也不能包治百病，其性能依赖于参与其中的处理器数量，同样也与读者和作者线程的负载有关。为了确保增加复杂度后还能获得性能收益，目标系统上的代码性能就很重要。
比起使用 std::mutex 实例进行同步，不如使用 std::shared_mutex 来做同步。对于更新操作，可以使用 std::lock_guardstd::shared_mutex 和 std::unique_lockstd::shared_mutex 上锁。
作为 std::mutex 的替代方案，与 std::mutex 所做的一样，这就能保证更新线程的独占访问。
因为其他线程不需要去修改数据结构，所以其可以使用std::shared_lockstd::shared_mutex 获取访问权。这种RAII类型模板是在C++14中的新特性，这与使用 std::unique_lock 一样，除非多线程要在同时获取同一个 std::shared_mutex 上
有共享锁。唯一的限制：当任一线程拥有一个共享锁时，这个线程就会尝试获取一个独占
锁，直到其他线程放弃他们的锁；同样的，当任一线程拥有一个独占锁时，其他线程就无法获得共享锁或独占锁，直到第一个线程放弃其拥有的锁。
如同之前描述的那样，下面的代码清单展示了一个简单的DNS缓存，使用 std::map 持有缓存数据，使用 std::shared_mutex 进行保护。
清单3.13 使用 std::shared_mutex 对数据结构进行保护
#include <map> #include <string> #include <mutex> #include <shared_mutex> class dns_entry; class dns_cache { std::map<std::string,dns_entry> entries; mutable std::shared_mutex entry_mutex; public: dns_entry find_entry(std::string const& domain) const { std::shared_lock<std::shared_mutex> lk(entry_mutex); // 1 std::map<std::string,dns_entry>::const_iterator const it= entries.find(domain); return (it==entries.end())?dns_entry():it->second; } void update_or_add_entry(std::string const& domain, dns_entry const& dns_details) { std::lock_guard<std::shared_mutex> lk(entry_mutex); // 2 entries[domain]=dns_details; } };
清单3.13中，find_entry()使用 std::shared_lock<> 来保护共享和只读权限①；这就使得多线程可以同时调用find_entry()，且不会出错。另一方面，update_or_add_entry()使用 std::lock_guard<> 实例，当表格需要更新时②，为其提供独占访问权限；
update_or_add_entry()函数调用时，独占锁会阻止其他线程对数据结构进行修改，并且阻止线程调用find_entry()。
3.3.3 嵌套锁
当一个线程已经获取一个 std::mutex 时(已经上锁)，并对其再次上锁，这个操作就是错误
的，并且继续尝试这样做的话，就会产生未定义行为。然而，在某些情况下，一个线程尝试获取同一个互斥量多次，而没有对其进行一次释放是可以的。之所以可以，是因为C++标准库提供了 std::recursive_mutex 类。除了可以对同一线程的单个实例上获取多个锁，其他功能与 std::mutex 相同。互斥量锁住其他线程前，必须释放拥有的所有锁，所以当调用lock()三次后，也必须调用unlock()三次。正确使用 std::lock_guardstd::recursive_mutex 和 std::unique_lockstd::recursive_mutex 可以帮你处理这些问题。
大多数情况下，当需要嵌套锁时，就要对代码设计进行改动。嵌套锁一般用在可并发访问的类上，所以使用互斥量保护其成员数据。每个公共成员函数都会对互斥量上锁，然后完成对应的操作后再解锁互斥量。不过，有时成员函数会调用另一个成员函数，这种情况下，第二个成员函数也会试图锁住互斥量，这就会导致未定义行为的发生。“变通的”解决方案会将互斥量转为嵌套锁，第二个成员函数就能成功的进行上锁，并且函数能继续执行。
但是，不推荐这样的使用方式，因为过于草率，并且不合理。特别是，当锁被持有时，对应类的不变量通常正在被修改。这意味着，当不变量正在改变的时候，第二个成员函数还需要继续执行。一个比较好的方式是，从中提取出一个函数作为类的私有成员，并且让其他成员函数都对其进行调用，这个私有成员函数不会对互斥量进行上锁(在调用前必须获得锁)。然后，你仔细考虑一下，在这种情况调用新函数时，数据的状态。
总结
本章讨论了当两个线程间的共享数据发生恶性条件竞争时，将会带来多么严重的灾难，还讨论了如何使用 std::mutex 和如何避免这些问题。如你所见，虽然C++标准库提供了一写工具来避免这些(例如： std::lock() )，互斥量并不是灵丹妙药，也还有自己的问题(比如：死锁)。
还见识了一些用于避免死锁的先进技术，之后了解了锁的所有权转移，以及一些围绕如何选取适当粒度锁产生的问题。最后，在具体情况下讨论了其他数据保护的方案，例如: std::call_once() 和 std::shared_mutex 。
还有一个方面没有涉及到，那就是等待其他线程作为输入的情况。我们的线程安全栈，仅是在栈为空时，抛出一个异常，所以当一个线程要等待其他线程向栈压入一个值时(这是线程安全栈的主要用途之一)，它需要多次尝试去弹出一个值，当捕获抛出的异常时，再次进行尝试。
这种消耗资源的检查，没有任何意义。并且，不断的检查会影响系统中其他线程的运
行，这反而会妨碍程序的运行。我们需要一些方法让一个线程等待其他线程完成任务，但在等待过程中不占用CPU。第4章中，会去建立一些保护共享数据的工具，还会介绍一些线程同步的操作机制；第6章中会展示，如何构建更大型的可复用的数据类型。
