Linux线程安全与死锁¶

线程安全与重入问题¶

线程安全：就是多个线程在访问共享资源时，能够正确地执行，不会相互干扰或破坏彼此的执行结果。一般而言，多个线程并发同一段只有局部变量的代码时，不会出现不同的结果。但是对全局变量或者静态变量进行操作，并且没有锁保护的情况下，容易出现该问题

重入：同一个函数被不同的执行流调用，当前一个流程还没有执行完，就有其他的执行流再次进入，称之为重入。一个函数在重入的情况下，运行结果不会出现任何不同或者任何问题，则该函数被称为可重入函数，否则，是不可重入函数

根据前面的知识，目前重入情况分为两种：

1. 多线程重入函数
2. 信号导致一个执行流多次重入函数

对比上面的4种情况可以发现，实际上最终结论为：函数是可重入的，那就是线程安全的，否则就是线程不安全的

可重入和线程安全也存在联系：可重入函数是线程安全函数的一种。线程安全不一定是可重入的，而可重入函数则一定是线程安全的。如果将对临界资源的访问加上锁，则这个函数是线程安全的，但如果这个重入函数若锁还未释放则会产生死锁，因此是不可重入的

但是，需要注意的是如果不考虑信号导致一个执行流重复进入函数这种重入情况，线程安全和重入在安全角度不作区分。但是线程安全侧重说明线程访问公共资源的安全情况，表现的是并发线程的特点可重入描述的是一个函数是否能被重复进入，表示的是函数的特点

死锁¶

死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态

以下面的例子为例，假设现在线程A,线程B必须同时持有锁1和锁2，才能进行后续资源的访问，如下图所示：

虽然申请一把锁的过程是原子性的，但是申请两把锁就不能保证是原子性的，如下图所示：

最后的结果如下图所示：

产生死锁的四个必须同时存在的条件如下：

1. 互斥条件：一个资源每次只能被一个执行流使用

2. 请求与保持条件：一个执行流因请求资源而阻塞时，对已获得的资源保持不放，示意图如下：

3. 不剥夺条件：一个执行流已获得的资源，在未使用完之前，不能强行剥夺，示意图如下：

   

4. 循环等待条件：若干执行流之间形成一种头尾相接的循环等待资源的关系，示意图如下：

   

避免死锁的方式就是破坏上述的四个条件之一即可

STL容器、智能指针与线程安全¶

STL容器是否线程安全¶

不是。原因是，STL的设计初衷是将性能挖掘到极致，而一旦涉及到加锁保证线程安全，会对性能造成巨大的影响。而且对于不同的容器，加锁方式的不同，性能可能也不同（例如hash表的锁表和锁桶）。因此STL默认不是线程安全，如果需要在多线程环境下使用，往往需要调用者自行保证线程安全

智能指针与线程安全¶

对于unique_ptr，由于只是在当前代码块范围内生效，因此不涉及线程安全问题。对于shared_ptr，多个对象需要共用一个引用计数变量，所以会存在线程安全问题。但是标准库实现的时候考虑到了这个问题，基于原子操作(CAS)的方式保证shared_ptr能够高效，原子的操作引用计数

其他锁¶

1. 悲观锁：在每次取数据时，总是担心数据会被其他线程修改，所以会在取数据前先加锁（读锁，写锁，行锁等），当其他线程想要访问数据时，被阻塞挂起。
2. 乐观锁：每次取数据时候，总是乐观的认为数据不会被其他线程修改，因此不上锁。但是在更新数据前，会判断其他数据在更新前有没有对数据进行修改。主要采用两种方式：版本号机制和CAS操作。
3. CAS操作：当需要更新数据时，判断当前内存值和之前取得的值是否相等。如果相等则用新值更新。若不等则失败，失败则重试，一般是一个自旋的过程，即不断重试
4. 自旋锁和读写锁，见对应锁补充部分