Chapter 3：共享数据

本章主要介绍《C++并发编程实战》的第三章内容。

从整体上来看，所有线程之间共享数据的问题，都是修改数据导致的。

在线程间共享数据的时候，如果共享数据都是只读那并不会存在什么问题，但如果有同时读写的情况发生，那么麻烦很可能就在不远处了。

修改线程之间共享数据的最简单的潜在问题就是：破坏不变量
竞争条件（race condition）：指的是结果取决于两个或多个线程上的操作执行的相对顺序的一切事物。通常，在谈到并发的时候，race condition指的是有问题的竞争条件，因为良性的没什么意思。

避免有问题的竞争条件的方法：

• 最简单的方法是用保护机制封装数据结构，以确保只有实际执行修改的线程能够在不变量损坏的地方看到中间数据。从其他访问该数据结构的线程来看，这种修改要么还没开始，要么已经完成；
• 另一种方式是修改数据结构的设计及其不变量，从而令修改作为一系列不可分割的变更来完成，每个修改均保留其不变量。这通常被说为无锁编程，但难以尽善尽美；
• 另一种方式是将对数据结构的更新作为一个事务（transaction）来处理，就如同在一个事务内完成数据库的更新一样。

互斥元

C++标准提供的最基本的保护数据共享机制是互斥元（Mutex）。
线程库会确保一旦一个线程已经锁定了某个互斥元，所有其他试图锁定相同互斥元的线程必须等待，直到成功锁定了改互斥元的线程解锁此互斥元。
推荐使用实现了互斥元的RAII的std::lock_guard类模板（在其他库中都有相似名字的实现，所以说知识是共通的，但表现形式可能有不同）。
void fun(){
std::lock_guard guard(some_mutex);
...do something...
}

但，这样并不能确保数据完全受保护，还存在人为的疏漏导致数据可以在其它地方被修改。比如(参考书籍：Page_37)：

• 函数返回返回受保护数据的引用或指针
  return mopData;
• 受保护数据被传入到了可能会对数据进行非保护行为操作的函数中，或者是传入了一个函数指针到有锁的函数中，而该函数指针却可以修改数据
  std::lock_guard lock(m);
bad_function(data);

所以，在编写代码时候一定要注意函数的“出入”：不要将受保护数据的指针或引用传递到锁的范围之外，无论是通过从函数中将他们返回、将其存放在外部可见的内存。

RAII类模板

比如std::lock_guard，在构造时候锁定给定的互斥元，在析构时候将互斥元解锁，从而确保被锁定的或持有始终被正确解锁

自旋锁

锁的粒度

锁的粒度会影响系统的并发性能。通常要保持锁的粒度小、锁住时间短。

死锁

通常发生在需要2个或多个互斥元执行操作的时候。通常建议始终以相同的顺序锁定互斥元。比如总在互斥元B之前锁定互斥元A。但这也存在问题，比如两个相同的实例之间交换数据，将产生死锁。
幸运的是std::lock可以同时锁定两个或更多的互斥元而没有死锁的风险,如果std::lock已经成功获得了一个互斥元的锁，当它试图在另一个互斥元上获取锁的时候，如果发生了异常，前一个互斥元会自动释放，std::lock提供了关于锁定给定的互斥元的全有或者全无的语义。当然，如果在需要分别获取锁的情况下std::lock就无法派上用场了。

std::lock一次锁定多个锁

例子确保了在受保护的操作可能引发异常的情况下，函数退出时候能正确解锁互斥元。同时在std::lock进行锁定任何一个互斥元的过程中都有可能引发异常，但如果发生了这种情况std::lock会将已经锁定的自动释放。

避免死锁的方法

避免嵌套锁
在持有锁时候，避免调用用户提供的代码
以固定顺序获得锁
使用分层锁
使用unique_lock灵活锁定
在作用域间转移锁的所有权
保持锁的恰当粒度

活锁