[Linux][多线程][二][线程互斥][互斥量][可重入VS线程安全][常见锁概念]-编程知识

1.线程互斥
- 1.互斥相关背景概念
- 2.多个线程并发的操作共享变量，会带来一些问题
- 3.互斥量mutex
2.互斥量的接口
- 1.初始化互斥量
- 2.销毁互斥量
- 3.加锁
- 4.解锁
- 5.使用 -- 改善上面代码
3.互斥量实现原理探究
- 1.加锁是如何保证原子性的？
- 2.如何保证锁是原子性的？
4.可重入VS线程安全
- 1.基本概念
- 2.常见的线程不安全的情况
- 3.常见的线程安全的情况
- 4.常见不可重入的情况
- 5.常见可重入的情况
- 6.可重入与线程安全联系
- 7.可重入与线程安全区别
5.常见锁概念
- 1.死锁
- 2.死锁的四个必要条件
- 3.避免死锁
- 4.避免死锁算法(了解)

1.线程互斥

1.互斥相关背景概念

临界资源：多线程执行流共享的资源
临界区：每个线程内部，访问临界资源的代码
互斥：任何时刻，互斥保证有且只有一个执行流进入临界区，访问临界资源，通常对临界资源起保护作用
原子性：不会被任何调度机制打断的操作，该操作只有两态，要么完成，要么未完成

2.多个线程并发的操作共享变量，会带来一些问题

如以下多线程抢票逻辑代码

int tickets = 10000;void *GetTickets(void *args)
{(void)args;while(true){if(tickets > 0){usleep(1000);printf("%p：%d\n", pthread_self(), tickets);tickets--;}else{break;}}return nullptr;
}int main()
{// 多线程抢票逻辑pthread_t t1, t2, t3;pthread_create(&t1, nullptr, GetTickets, nullptr);pthread_create(&t2, nullptr, GetTickets, nullptr);pthread_create(&t3, nullptr, GetTickets, nullptr);pthread_join(t1, nullptr);pthread_join(t2, nullptr);pthread_join(t3, nullptr);return 0;
}

结果：
出现负数原因分析
- if语句判断条件为真以后(判断也需要CPU参与)，代码可以并发的切换到其他线程
  - "同一时刻"有多个线程判断tickets时tickets的值是相同的
- usleep用于模拟漫长业务的过程，在这个漫长的业务过程中，可能有很多个线程会进入该代码段
- –tickets操作本身就不是一个原子操作
–tickets为什么不是一个原子操作?
- –操作并不是原子的，而是对应三条汇编指令，其中在执行任何一条指令时都有可能被切走
  - load**：**将共享变量tickets从内存加载到寄存器中
  - update**：**更新寄存器里面的值，执行-1操作
  - store**：**将新值，从寄存器写回共享变量ticket的内存地址
- 汇编代码对应如下

3.互斥量mutex

大部分情况，线程使用的数据都是局部变量，变量的地址空间在线程栈空间内
- 这种情况，变量归属单个线程，其他线程无法获得这种变量
但有时候，很多变量都需要在线程间共享，这样的变量称为共享变量，可以通过数据的共享，完成线程之间的交互
要解决上述问题，需要做到三点：
- 代码必须要有互斥行为：当代码进入临界区执行时，不允许其他线程进入该临界区
- 如果多个线程同时要求执行临界区的代码，并且临界区没有线程在执行，那么只能允许一个线程进入该临界区
- 如果线程不在临界区中执行，那么该线程不能阻止其他线程进入临界区
要做到这三点，本质上就是需要一把锁
- Linux上提供的这把锁叫互斥量

2.互斥量的接口

1.初始化互斥量

初始化互斥量有两种方法
- 静态分配
  - pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER
- 动态分配
  - 函数原型：int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict attr);
- 参数：
  - **mutex：**要初始化的互斥量
  - **attr：**初始化互斥量的属性，一般设置为nullptr即可
- **返回值：**成功返回0，失败返回错误码

2.销毁互斥量

函数原型：int pthread_mutex_destroy(pthread_mutex_t *mutex);
**参数：mutex：**需要销毁的互斥量
**返回值：**成功返回0，失败返回错误码
销毁互斥量需要注意：
- 使用PTHREAD_ MUTEX_ INITIALIZER初始化的互斥量不需要销毁
- 不要销毁一个已经加锁的互斥量
- 已经销毁的互斥量，要确保后面不会有线程再尝试加锁

3.加锁

函数原型：int pthread_mutex_lock(pthread_mutex_t *mutex);
**参数：mutex：**需要销毁的互斥量
**返回值：**成功返回0，失败返回错误码
可能会遇到以下情况：
- 互斥量处于未锁状态，该函数会将互斥量锁定，同时返回成功。
- 发起函数调用时，其他线程已经锁定互斥量，或者存在其他线程同时申请互斥量，但没有竞争到互斥量
  - 那么pthread_mutex_lock调用会陷入阻塞(执行流被挂起)，等待互斥量解锁
注意：加锁的时候，一定要保证加锁的粒度，越小越好

4.解锁

函数原型：int pthread_mutex_unlock(pthread_mutex_t *mutex);
**参数：mutex：**需要销毁的互斥量
**返回值：**成功返回0，失败返回错误码

5.使用 – 改善上面代码

#define THREAD_NUM 5int tickets = 10000;class ThreadData
{
public:ThreadData(const string &name, pthread_mutex_t *pm): _name(name), _pmtx(pm){}
public:string _name;pthread_mutex_t *_pmtx;
};void *GetTickets(void *args)
{ThreadData *td = (ThreadData *)args;while(true){int n = pthread_mutex_lock(td->_pmtx);assert(n == 0);if(tickets > 0){usleep(1000);printf("%s：%d\n", td->_name.c_str(), tickets);tickets--;n = pthread_mutex_unlock(td->_pmtx);assert(n == 0);}else{n = pthread_mutex_unlock(td->_pmtx);assert(n == 0);break;}}delete td;return nullptr;
}int main()
{pthread_mutex_t mtx;pthread_mutex_init(&mtx, nullptr);// 多线程抢票逻辑pthread_t t[THREAD_NUM];for (int i = 0; i < THREAD_NUM; i++){string name = "thread";name += to_string(i + 1);ThreadData *td = new ThreadData(name, &mtx);pthread_create(t + i, nullptr, GetTickets, (void *)td);}for (int i = 0; i < THREAD_NUM; i++){pthread_join(t[i], nullptr);}pthread_mutex_destroy(&mtx);return 0;
}

3.互斥量实现原理探究

对临界区进行保护，所有的执行线程都必须遵守这个规则(编码规则，加锁)
- 先加锁->访问临界区->再解锁
要访问临界资源的时候，需要先访问锁，前提就是所有线程要先看到锁，那么锁本身也是临界资源
- 锁本身要先保证自身安全
- 申请锁的过程，不能有中间状态，也就是两态
  - 加锁和解锁必须是原子的

1.加锁是如何保证原子性的？

请添加图片描述

当线程1看临界区没有锁，此时线程1就可以申请到锁
- 线程2,3此时申请不到就处于阻塞的状态
- 当线程1执行完后，解锁走了，线程2,3可以申请锁
线程2,3看到线程1就是要么线程1申请到锁，要么没有申请到锁，不会有其他的状态
- 所以加锁是原子的
注意：
- 有可能线程1在临界区被切走，但线程2,3也无法进入临界区进行资源访问
  - 因为此时线程1是拿着锁被切走的，锁没有被释放也就意味着其他线程无法申请到锁，也就无法进入临界区进行资源访问
- 其他想进入该临界区进行资源访问的线程，必须等该线程执行完临界区的代码并释放锁之后，才能申请锁，申请到锁之后才能进入临界区

2.如何保证锁是原子性的？

为了实现互斥锁操作，大多数体系结构都提供了swap或exchange指令
- 以一条汇编的方式，将CPU内寄存器和内存数据相交换
- 如果在汇编角度，只有一条汇编语句，就认为该汇编语句执行是原子的
- 即使是多处理器平台，访问内存的总线周期也有先后，一个处理器上的交换指令执行时另一个处理器的交换指令只能等待总线周期
执行流视角，如何看待CPU上面的寄存器？
- CPU内部的寄存器，本质叫做当前执行流的上下文
- 寄存器们，空间是被所有的执行流共享的
- 但是寄存器的内容，是被每一个执行流私有的
  - 即执行流的上下文
mutex的本质：通过一条汇编，将锁数据交换到自己的上下文中
申请锁
1. 先将al寄存器中的值置0
  - 该动作可以被多个线程同时执行，因为每个线程都有自己的一组寄存器(上下文信息)，执行该动作本质上是将自己的al寄存器清0
2. 然后交换al寄存器和mutex中的值
  - xchgb可以完成寄存器和内存单元之间数据的交换
  - 它使用一行汇编，原子性的完成共享的内存数据mutex交换到线程的上下文中，从而实现私有的过程
  - 交换的现象：内存 <–> al 做交换
  - 交换的本质：共享 <–> 私有
3. 最后判断al寄存器中的值是否大于0
  - 如果大于0则申请锁成功，就可以进入临界区访问临界资源
  - 反之申请锁失败需要被挂起等待，直到锁被释放后再次竞争申请锁
释放锁
1. 将内存中的mutex值置1。使下一个申请锁的线程在执行交换指令后能够得到1
2. 唤醒等待Mutex的线程。唤醒这些因为申请锁失败而被挂起的线程，让它们继续竞争申请锁
补充说明：
- 交换有个特征，内存的值mutex"1"只有一个，交换完就没了
  - 永远只能是拥有1的线程能够申请到锁，其他的完全不可能
  - 且拥有1的过程是—条汇编完成的，所以最终表现出来是原子的。
- 在申请锁时本质上就是哪一个线程先执行了交换指令，那么该线程就申请锁成功
  - 因为此时该线程的al寄存器中的值就是1了
  - 而交换指令就只是一条汇编指令，一个线程要么执行了交换指令，要么没有执行交换指令，所以申请锁的过程是原子的
- 在线程释放锁时没有将当前线程al寄存器中的值清0，这不会造成影响
  - 因为每次线程在申请锁时都会先将自己al寄存器中的值清0，再执行交换指令

4.可重入VS线程安全

1.基本概念

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

2.常见的线程不安全的情况

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

3.常见的线程安全的情况

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

4.常见不可重入的情况

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

5.常见可重入的情况

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

6.可重入与线程安全联系

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

7.可重入与线程安全区别

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

5.常见锁概念

1.死锁

死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所占用不会释放的资源而处于的一种永久等待状态
比如：
- 创建了两个线程，两把锁，线程1先申请A锁，线程2先申请B锁，申请完后，线程1又开始申请B锁，而线程2又开始申请A锁
- 此时就出现了线程1拿着A锁，线程2拿着B锁，他俩还互相想要对方的锁，但是他们要的锁已经被对方所拿走
- 此时就出现，线程1在申请B锁的时候申请不到，线程1抱着A锁挂起等待，线程2也不可能申请到A锁，线程2抱着B锁挂起等待
- 这就是典型的死锁问题
单执行流可能产生死锁吗？
- 会的，如果某一执行流连续申请了两次锁，那么此时该执行流就会被挂起
- 因为该执行流第一次申请锁的时候是申请成功的，但第二次申请锁时因为该锁已经被申请过了，于是申请失败导致被挂起直到该锁被释放时才会被唤醒，但是这个锁本来就在自己手上，自己现在处于被挂起的状态根本没有机会释放锁，所以该执行流将永远不会被唤醒，此时该执行流也就处于一种死锁的状态