【Linux】线程互斥 -- 互斥锁 | 死锁 | 线程安全

引入

我们写一个多线程同时访问一个全局变量的情况(抢票系统)，看看会出什么bug：

// 共享资源， 火车票
int tickets = 10000;
//新线程执行方法
void *getTicket(void *args)
{std::string username = static_cast<const char *>(args);while (true){if (tickets > 0){usleep(1254); // 1秒 = 1000毫秒 = 1000 000 微妙 = 10^9纳秒std::cout << username << " 正在进行抢票: " << tickets << std::endl;// 用这段时间来模拟真实的抢票要花费的时间tickets--;}else{break;}}return nullptr;
}
//主线程
//跟之前一样创建多个线程然后调用这个getTicket方法就行

假如创建4个线程同时抢票，总票数有10000张，每个线程抢到票以后减一，按照正常情况我们应该是抢票到0截至。

多个线程交叉执行本质：就是让调度器尽可能的频繁发生线程调度与切换
线程一般在什么时候发生切换呢？时间片到了，来了更高优先级的线程，线程等待的时候。
线程是在什么时候检测上面的问题呢？从内核态返回用户态的时候，线程要对调度状态进行检测，如果可以，就直接发生线程切换

实验结果：假如此时tickets = 1，第1号线程先判断了if (tickets > 0)然后进入语句中，结果被usleep阻塞了，这时候切换了另外的线程，此时tickets的值还未被1号进程更改，所以它同样也能进入语句中，就这样导致tickets--被执行了多次，然后就出现上述的负数结果。

对变量进行++，或者–，在C、C++上，看起来只有一条语句，但是汇编之后至少是三条语句:

1. 从内存读取数据到CPU寄存器中
2. 在寄存器中让CPU进行对应的算逻运算
3. 写回新的结果到内存中变量的位置

模拟一下线程1与线程2的更改切换逻辑：

我们定义的全局变量，在没有保护的时候，往往是不安全的，像上面多个线程在交替执行造成的数据安全问题，发生了数据不一致问题!

---

互斥

初识锁

• 临界资源：多个执行流进行安全访问的共享资源
• 临界区：我们把多个执行流中，访问临界资源的代码（往往是线程代码的很小的一部分）
• 互斥：想让多个线程串行访问共享资源，任何时刻，互斥保证有且只有一个执行流进入临界区，访问临界资源，通常对临界资源起保护作用
• 原子性：对一个资源进行访问的时候，要么不做，要么做完，该操作只有两态，不会被任何调度机制打断的操作。（只用一条汇编语句就能执行完的算是原子，当然还有别的情况之后再详细说明）

初步使用加锁解锁：

//定义为全局的锁，无需初始化和销毁，直接以这样的形式使用:
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
void *getTicket(void *args)
{std::string username = static_cast<const char *>(args);while (true){pthread_mutex_lock(&lock);if (tickets > 0){usleep(1254); // 1秒 = 1000毫秒 = 1000 000 微妙 = 10^9纳秒std::cout << username << " 正在进行抢票: " << tickets << std::endl;tickets--;pthread_mutex_unlock(&lock);}else{pthread_mutex_unlock(&lock);break;}}return nullptr;
}

运行现象：

我们可以很明显感受到，运行的速度变慢了，而且这里的线程4一直在抢票，别的线程没有机会

• 加锁和解锁的过程多个线程串行执行的，程序变慢了！
• 锁只规定互斥访问，没有规定必须让谁优先执行
• 锁就是真是的让多个执行流进行竞争的结果

线程解锁后，立马又申请锁，导致别的线程竞争不过，我们可以在每次循环末尾增加一段阻塞时间：

如何看待锁？

1. 锁本身就是一个共享资源（我们一份代码要使用锁，前提是我们能看到这个锁，这个资源），全局的变量是要被保护的，锁是用来保护全局的资源的，锁本身也是全局资源，锁的安全谁来保护呢？
2. pthread_mutex_lock、pthread_mutex_unlock:加锁的过程必须是安全的！加锁的过程其实是原子的！
3. 如果申请成功，就继续向后执行，如果申请暂时没有成功，执行流会阻塞！
4. 谁持有锁，谁进入临界区！

对锁的思考：

• 如果线程1，申请锁成功，进入临界资源，正在访问临界资源期间，其他线程在做什么？阻塞等待
• 如果线程1，申请锁成功，进入临界资源，正在访问临界资源期间，线程1可不可以被切换呢？绝对可以的。当持有锁的线程被切走的时候，是抱着锁被切走的，即便自己被切走了，其他线程依旧无法申请锁成功，也便无法向后执行，直到我最终释放这个锁!

所以，对于其他线程而言，有意义的锁的状态，无非两种：1.申请锁前2.释放锁后。站在其他线程的角度看待当前线程持有锁的过程，就是原子的！

未来我们在使用锁的时候，一定要尽量保证临界区的粒度(锁中间保护代码的多少)要非常小！

有人可能会想，加锁也未必安全，比如我让线程12加锁去访问公共资源，线程3不加锁去访问公共资源，这样的话公共资源依旧没有被保护起来。加锁是程序员行为，必须做到要加就都要加

---

互斥量mutex

• 大部分情况，线程使用的数据都是局部变量，变量的地址空间在线程栈空间内，这种情况，变量归属单个线程，其他线程无法获得这种变量。（这种说法其实不准确，如果硬要访问还是有可能做到）
• 但有时候，很多变量都需要在线程间共享，这样的变量称为共享变量，可以通过数据的共享，完成线程之间的交互。
• 多个线程并发的操作共享变量，会带来一些问题。

--操作并不是原子操作，而是对应三条汇编指令：

• load ：将共享变量ticket从内存加载到寄存器中
• update : 更新寄存器里面的值，执行-1操作
• store ：将新值，从寄存器写回共享变量ticket的内存地址

要解决以上问题，需要做到三点：

1. 代码必须要有互斥行为：当代码进入临界区执行时，不允许其他线程进入该临界区。
2. 如果多个线程同时要求执行临界区的代码，并且临界区没有线程在执行，那么只能允许一个线程进入该临界区。
3. 如果线程不在临界区中执行，那么该线程不能阻止其他线程进入临界区。
   要做到这三点，本质上就是需要一把锁。Linux上提供的这把锁叫互斥量
   

初始化互斥量有两种方法：

1. 静态分配:

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER

2. 动态分配:

int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrictattr);
参数：
mutex：要初始化的互斥量
attr：NULL

销毁互斥量需要注意：

• 使用 PTHREAD_MUTEX_INITIALIZER 初始化的互斥量不需要销毁
• 不要销毁一个已经加锁的互斥量
• 已经销毁的互斥量，要确保后面不会有线程再尝试加锁

int pthread_mutex_destroy(pthread_mutex_t *mutex)；

互斥量加锁和解锁：

int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);
返回值:成功返回0,失败返回错误码

调用 pthread_ lock 时，可能会遇到以下情况：

1. 互斥量处于未锁状态，该函数会将互斥量锁定，同时返回成功
2. 发起函数调用时，其他线程已经锁定互斥量，或者存在其他线程同时申请互斥量，但没有竞争到互斥量，那么pthread_ lock调用会陷入阻塞(执行流被挂起)，等待互斥量解锁。

---

锁原理解析

经过上面的例子，大家已经意识到单纯的 i++ 或者 ++i 都不是原子的，有可能会有数据一致性问题为了实现互斥锁操作，大多数体系结构都提供了swap或exchange指令，该指令的作用是把寄存器和内存单元的数据相交换，由于只有一条指令，保证了原子性，即使是多处理器平台，访问内存的总线周期也有先后，一个处理器上的交换指令执行时另一个处理器的交换指令只能等待总线周期。 现在我们把lock和unlock的伪代码改一下

加锁执行图：


接下来的代码就是判断，寄存器中的代码与数据是否符合。

在线程1执行后面的内容时，时刻都可能被切换，但是切换了线程2，寄存器的内容也会被切换掉，这样就算怎么执行，线程2寄存器中始终都是0。再切换回线程1，由上下文保护，寄存器内容切换回原来的数字1。

解锁：movb $1, mutex：就是将1重新给mutex

这个mutex原本的1就像是一个令牌，它有且只有一个，谁先抢到就能先运行

---

可重入VS线程安全

线程安全：多个线程并发同一段代码时，不会出现不同的结果。常见对全局变量或者静态变量进行操作，并且没有锁保护的情况下，会出现该问题。
重入：同一个函数被不同的执行流调用，当前一个流程还没有执行完，就有其他的执行流再次进入，我们称之为重入。一个函数在重入的情况下，运行结果不会出现任何不同或者任何问题，则该函数被称为可重入函数，否则，是不可重入函数。

常见的线程不安全的情况：

• 不保护共享变量的函数
• 函数状态随着被调用，状态发生变化的函数
• 返回指向静态变量指针的函数
• 调用线程不安全函数的函数

常见的线程安全的情况：

• 每个线程对全局变量或者静态变量只有读取的权限，而没有写入的权限，一般来说这些线程是安全的
• 类或者接口对于线程来说都是原子操作
• 多个线程之间的切换不会导致该接口的执行结果存在二义性

常见不可重入的情况：

• 调用了malloc/free函数，因为malloc函数是用全局链表来管理堆的
• 调用了标准I/O库函数，标准I/O库的很多实现都以不可重入的方式使用全局数据结构
• 可重入函数体内使用了静态的数据结构

常见可重入的情况：

• 不使用全局变量或静态变量
• 不使用用malloc或者new开辟出的空间
• 不调用不可重入函数
• 不返回静态或全局数据，所有数据都有函数的调用者提供
• 使用本地数据，或者通过制作全局数据的本地拷贝来保护全局数据

可重入与线程安全联系：

• 函数是可重入的，那就是线程安全的
• 函数是不可重入的，那就不能由多个线程使用，有可能引发线程安全问题
• 如果一个函数中有全局变量，那么这个函数既不是线程安全也不是可重入的。

可重入与线程安全区别：

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

STL中的容器是否是线程安全的?

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

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

---

死锁

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

感性认识死锁：小明与小红各自有5毛钱，它们一起去商店买棒棒糖，商店老板说它们的棒棒糖1块钱一个，小明对小红说能不能把她的5毛钱给他，这样他将能凑1块钱买棒棒糖，小红不乐意，她反问小明能不能把他的5毛钱给自己，这样她就能买棒棒糖，它们互相僵持，最后都没买到棒棒糖。他们之前出现的互相僵持的情况就是死锁

死锁四个必要条件：

1. 互斥条件：一个资源每次只能被一个执行流使用
2. 请求与保持条件：一个执行流因请求资源而阻塞时，对已获得的资源保持不放
3. 不剥夺条件：一个执行流已获得的资源，在末使用完之前，不能强行剥夺
4. 循环等待条件：若干执行流之间形成一种头尾相接的循环等待资源的关系

避免死锁方法：

• 破坏死锁的四个必要条件
• 加锁顺序一致
• 避免锁未释放的场景
• 资源一次性分配

避免死锁算法：死锁检测算法、银行家算法

---

如有错误或者不清楚的地方欢迎私信或者评论指出🚀🚀