3.2使用互斥量保护共享数据

3.2.1在C++中使用互斥量

在C++中， 通过实例化 srd::mutex 来创建一个互斥量， 通过调用成员函数lock()进行上锁，unlock()进行解锁。 不推荐实践中直接去调用成员函数， 因为调用成员函数就意味着，你必须记住在每个函数出口都要去调用unlock()也包括异常的情况。

C++标准为互斥量提供了一个RAII语法的模板类std::lack_guard，其会在构造时提供已锁的互斥量，并在析构的时候进行解锁，从而保证了一个已锁的互斥量总是被正确的解锁。

#include <list>
#include <mutex>
#include <algorithm>
std::list<int> some_list; // 1
std::mutex some_mutex; // 2
void add_to_list(int new_value)
{
    std::lock_guard<std::mutex> guard(some_mutex); // 3
    some_list.push_back(new_value);
} 
bool list_contains(int value_to_find)
{
    std::lock_guard<std::mutex> guard(some_mutex); // 4
    return std::find(some_list.begin(),some_list.end(),value_to_find) != some_
}

3.2.2精心组织代码来保护共享数据

切勿将受保护数据的指针或引用传递到互斥锁作用域之外， 无论是函数返回值， 还是存储在外部可见内存， 亦或是将他们以参数的形式传递到用户提供的函
数中去。

3.2.3发现接口内在的竞争条件

问题：假设有一个 stack<vector<int>> ， vector是一个动态容器， 所以当你拷贝一个vetcor， 标准库会从堆上分配很多内存来完成这次拷贝。 当这个系统处在重度负荷， 或有严重的资源限制的情况下， 这种内存分配就会失败，所以vector的拷贝构造函数可能回抛出一个std::bad_alloc异常。当pop()函数返回“弹出值”时，就会有一个潜在的问题：当这个值被返回到调用函数的时候， 栈才被改变；但当拷贝数据的时候， 调用函数抛出一个异常会怎么样？ 如果这种事情真的发生了， 要弹出的数据将会丢失；它的确从栈上移出了，但是拷贝失败了。
解决方法：

• std::stack 的设计人员将这个操作分为两部分：先获取顶部元素（top()） ， 然后从栈中移除（pop()）。这样的分割会制造条件竞争。
• 将变量的引用作为参数， 传入pop()函数中来获取想要的“弹出值”。缺陷是：需要提前构造一个堆中的类型的实力，用于接收目标值。

std::vector<int> result;
some_stack.pop(result);

• 无异常抛出的拷贝构造函数或移动构造函数
  尽管能在编译时， 使用 std::is_no_throw_copy_constructible 和std::is_nothrow_move_constructible 类型特征， 能让拷贝或移动构造函数不抛出异常， 但是这种方式的局限性太强。
• 返回弹出值的指针
  返回一个指向弹出元素的指针， 而不是直接返回值。 指针的优势是自由拷贝，并且不会产生异常。使std::shared_ptr是一个不错的选择。不仅是因其能避免内存泄露（因为当对象中指针销毁时， 对象也会被销毁） ， 而是因为标准库能够完全控制内存分配方案， 也就不需要new和delete操作。

3.2.4死锁

std::lock ——可以一次性锁住多个（两个以上） 的互斥量， 并且没有副作用（死锁风险） 。

避免死锁

• 避免嵌套死锁
  • 当已获得一个锁时，别再去获得第二个。当你需要获取多个锁， 使用一个 std::lock 来做这件事， 避免产生死锁。
• 使用固定顺序获取锁
• 使用锁的层次结构