＜Linux＞ 线程的同步与互斥

目录

前言：

一、资源共享问题

（一）多线程并发访问

（二）临界资源与临界区

[（三）"锁" 是什么](#（三）“锁” 是什么)

二、多线程抢票场景

（一）并发抢票

（二）并发访问问题原因

三、线程互斥

（一）互斥锁相关操作接口

[1. 互斥锁的创建及释放](#1. 互斥锁的创建及释放)

[2. 加锁解锁操作](#2. 加锁解锁操作)

[（二） 解决抢票问题](#（二） 解决抢票问题)

[1. 互斥锁细节](#1. 互斥锁细节)

（三）互斥锁的原理

[1. 加锁原理](#1. 加锁原理)

[2. 解锁原理](#2. 解锁原理)

（四）多线程封装

（五）互斥锁的封装

[1. RAII 风格](#1. RAII 风格)

（六）总结

[四、线程安全 VS 重入](#四、线程安全 VS 重入)

五、死锁

（一）概念

（二）死锁产生条件及如何避免

六、线程同步

（一）同步概念

（二）同步相关操作

[1. 条件变量的创建与销毁](#1. 条件变量的创建与销毁)

[2. 条件等待](#2. 条件等待)

[3. 条件唤醒](#3. 条件唤醒)

（三）简单同步demo

（四）总结

---

前言：

初学者在使用 多线程 并发执行任务时一定会遇到 并发访问的问题。最直观的感受就是每次运行得出的效果值大概率不一致，这种执行结果不一致的现象是非常致命，因为它具有随机性，即结果可能是理想的，也可能是不理想的，无法可靠的完成服务。

并发访问就是同时有多个请求请求同一服务。比如我和你现在都同时在请求CSDN的服务器提供搜索博客服务。大量的并发访问如果超出了服务器的承受能力的话，轻则导致服务器抛弃一部分请求，重则导致服务器资源耗尽，宕机。

有一种攻击叫分布式拒绝服务攻击（DDOS），就是利用这个。使得大量的垃圾请求阻塞服务器，使得服务器无法处理正常的请求从而耗尽资源。

一、资源共享问题

（一）多线程并发访问

比如存在全局变量 **g_val**以及两个线程 thread_A 和 thread_B，两个线程同时不断对 **g_val**做 减减 (--) 操作：

注意：用户的代码无法直接对内存中的 g_val 做修改，需要借助 CPU。

如果想要对 **g_val**进行修改，至少要分为三步：

1. 先将 **g_val**的值拷贝至寄存器中。
2. 在 CPU 内部通过运算寄存器完成计算。
3. 将寄存器中的值拷贝回内存。

假设 **g_val**初始值为 100 ，如果 **A**想要进行 g_val****--，就必须这样做：

也就是说，简单的一句 **g_val****--**语句实际上至少会被分成 三步。

单线程场景下步骤分得再细也没事，因为没有其他线程干扰它，但我们现在是在 多线程 场景中，存在 线程调度问题 ，假设此时 **A**在执行完第2步后被强行切走了，换成 **B**运行：

A的第3步还没有完成，内存中 g_val的值还没有被修改，但 A认为自己已经修改了（完成了第2步），在线程调度时，A的上下文及相关数据会被保存，A被切走后，B会被即刻调度入场，不断执行 **g_val --**操作。

假设 B的运气比较好，进行很多次 g_val -- 操作后都没有被切走：

当 B将 g_val 中的值修改为 10 后，就被操作系统切走了，此时轮到 A登场，A带着自己的之前的上下文数据，继续进行它的未尽事业（完成第3步操作），当然 B的上下文数据也会被保存：

此时尴尬的事情发生了：A****把 g_val 的值改成了 99，这对于 B****来说很不公平，倘若下次再从内存中读取 g_val 时，结果为 99，自己又得重新进行计算，但站在两个线程的角度来说，两者都没有错。

• thread_A: 将自己的上下文恢复后继续执行操作，合情合理
• thread_B: 按照要求不断对 g_val 进行操作，也是合情合理

错就错在 thread_A在错误的时机被切走了，保存了老旧的 g_val值（对于 thread_B来说），直接影响就是 g_val的值飘忽不定。倘若再出现一个线程 thread_C不断打印 g_val的值，那么将会看到 g_val值减为 10 后又突然变为 99的 "灵异现象"。

产出结论：多线程场景中对全局变量并发访问不是 100% 可靠的。

（二）临界资源与临界区

在多线程场景中，对于诸如 g_val这种可以被多线程看到的同一份资源称为 临界资源 ，涉及对 临界资源 进行操作的上下文代码区域称为 临界区：

int g_val = 100; // 临界资源

void *action(void *args)
{
    // ==== 临界区 ====
    while(g_val)
    {
        cout << "g_val: " << g_val << endl;
        g_val--;
    }
    // ==== 临界区 ====
    
    pthread_exit((void*)0);
}

临界资源 本质上就是 多线程共享资源 ，而 临界区 则是 涉及共享资源操作的代码区间。

（三）"锁" 是什么

临界资源 要想被安全的访问，就得确保 临界资源使用时的安全性。

在我们现实生活中，对于人类共享的资源都是有锁进行安全使用的。例如：公共厕所门、共享单车、共享电宝等等。对于公共厕所来说，卫生间只能供一人使用，为了确保如厕时的安全性，就需要给每个卫生间都加上一道门，并且加上一把锁。

对于 临界资源 访问时的安全问题，也可以通过 加锁 来保证，实现多线程间的 互斥访问 ，互斥锁 就是解决多线程并发访问问题的手段之一。

我们可以 在进入临界区之前加锁，出临界区之后解锁 ， 这样可以确保并发访问临界资源 时的绝对串行化，比如之前的 thread_A和 thread_B在并发访问 g_val时，如果进行了 加锁 ，在 thread_A被切走后，thread_B无法对 g_val进行操作，因为此时 锁 被 thread_A持有，thread_B只能阻塞式等待解锁 ，直到 thread_A解锁（意味着 thread_A的整个操作都完成了）。

因此，对于thread_A来说，在 加锁 环境中，只要接手了访问临界资源 g_val****的任务，要么完成、要么不完成，不会出现中间状态，像这种不会出现中间状态、结果可预期的特性称为 原子性 。

说白了 加锁 的本质就是为了实现 原子性。

注意：

• 加锁、解锁是比较耗费系统资源的，会在一定程序上降低程序的运行速度。
• 加锁后的代码是串行化执行的，势必会影响多线程场景中的运行速度。
• 所以为了尽可能的降低影响，加锁粒度要尽可能的细。

二、多线程抢票场景

（一）并发抢票

场景很简单：存在 1000 张票和 5 个线程，5 个线程同时抢票，直到票数为 0，程序结束后，可以看看每个线程分别抢到了几张票，以及最终的票数是否为 0。

共识：购票需要时间，抢票成功后也需要时间，这里通过 usleep 函数模拟耗费时间

#include <iostream>
#include <string>
#include <unistd.h>
#include <pthread.h>

using namespace std;

int tickets = 1000; // 临界资源

void *threadRoutine(void *args)
{
    int sum = 0;
    const char *name = static_cast<const char*>(args);
    while(true)
    {
        // 有票才能抢
        if(tickets > 0)
        {
            usleep(2000);
            sum++;
            --tickets;
        }
        else
        {
            break;
        }
        usleep(2000); // 模拟票到手后处理剩余动作所需时间
    }
    cout << name << " 抢票成功，票数为：" << sum << endl;
    delete name;
    return nullptr;
}

int main()
{
    pthread_t pt[5];
    for(int i = 0; i < 5; i++)
    {
        char *name = new char[64];
        snprintf(name, 64, "thread|%d", i);
        pthread_create(pt+i, nullptr, threadRoutine, (void*)name);
    }
    for(int i = 0; i < 5; i++)
        pthread_join(pt[i], nullptr);

    cout << "所有线程已退出，无抢票操作，剩余票数：" << tickets << endl;

    return 0;
}

理想状态下，最终票数为 0，5 个线程抢到的票数之和为 1000，但实际并非如此

最终剩余票数 -4，难道 12306 还倒欠了4 张票？这显然是不可能的，5 个线程抢到的票数之和为 1015，这就更奇怪了，总共 1000 张票还多出来 15 张？

显然多线程并发访问是绝对存在问题的。

（二）并发访问问题原因

这其实就是 thread_A和 thread_B****并发访问 g_val时遇到的问题。举个例子：假设 tickets = 500，thread|0 在抢票，准备完成第3步，将数据拷贝回内存时被切走了，thread|1 抢票后，tickets = 499；轮到 thread|0 回来时，它也是把 tickets 修改成了 499，这就意味着 thread|0 和 thread|1 之间有一个人白嫖了一张票（按理来说 tickets = 498 才对）。

解决办法：对于 票 这种 临界资源 ，可以通过 加锁 进行保护，即实现 线程间的互斥访问 ，确保多线程购票时的 原子性。

• 3 条汇编指令要么不执行，要么全部一起执行完

--tickets本质上是**3 条汇编指令** ，在任意一条执行过程中切走线程都会引发并发访问问题

三、线程互斥

互斥 通常指的是在多进程或多线程环境下，当一个进程或线程在访问共享资源或执行某段关键代码时，其他进程或线程不能同时访问该资源或执行该代码。互斥 -> 互斥排斥 ：事件 A 与事件 B 不会同时发生。

比如 多线程并发抢票场景中可以通过添加 互斥锁 的方式，来确保同一张票不会被多个线程同时抢到。

（一）互斥锁相关操作接口

1. 互斥锁的创建及释放

互斥锁 同样出自 原生线程库 ，类型为 pthread_mutex_t，互斥锁 在创建后需要进行 初始化。

pthread_mutex_t mtx; // 定义一把互斥锁
int pthread_mutex_init(pthread_mutex_t *restrict mutex, 
					   const pthread_mutexattr_t *restrict attr);

• 参数1 pthread_mutex_t* 表示想要初始化的锁，这里传的是地址，因为需要在初始化函数中对 互斥锁 进行初始化。
• 参数2**const pthread_mutexattr_t*** 表示初始化时 互斥锁 的相关属性设置，传递 nullptr 使用默认属性。

返回值：初始化成功返回 0 ，失败返回 error number

互斥锁 是一种向系统申请的资源，在 使用完毕后需要销毁

int pthread_mutex_destroy(pthread_mutex_t *mutex);

其中只有一个参数 pthread_mutex_t 表示想要销毁的互斥锁的地址。*

返回值：初始化成功返回 0 ，失败返回 error number

注意：

• 互斥锁是一种资源，一种线程依赖的资源，因此 [初始化互斥锁] 操作应该在线程创建之前完成，[销毁互斥锁] 操作应该在线程运行结束后执行；总结就是 使用前先创建，使用后需销毁。
• 对于多线程来说，应该让他们看到同一把锁，否则就没有意义。
• 不能重复销毁互斥锁 ，已经销毁的互斥锁不能再使用。

使用 pthread_mutex_init初始化 互斥锁 的方式称为 动态分配 ，需要手动初始化和销毁，除此之外还存在 静态分配 ，即在定义 互斥锁 时初始化为 PTHREAD_MUTEX_INITIALIZER

pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;

静态分配 的优点在于 无需手动初始化和手动销毁，锁的生命周期伴随程序 ，缺点就是定义的 互斥锁 必须为 全局互斥锁。

分配方式	操作	适用场景
动态分配	手动初始化/销毁	局部锁/全局锁
静态分配	自动初始化/销毁	全局锁

注意： 使用静态分配时，互斥锁必须定义为全局锁。

2. 加锁解锁操作

互斥锁 最重要的功能就是 加锁与解锁 操作

int pthread_mutex_lock(pthread_mutex_t *mutex);

int pthread_mutex_unlock(pthread_mutex_t *mutex);

参数 pthread_mutex_t* 表示想要对哪把互斥锁进行解锁。

返回值：初始化成功返回 0 ，失败返回 error number

使用 pthread_mutex_lock加锁时可能遇到的情况：

1. 当前互斥锁没有被别人持有，正常加锁，函数返回 0
2. 当前互斥锁被别人持有，加锁失败，当前线程被阻塞（执行流被挂起），无法向后运行，直到获得 [锁资源]

在 加锁 成功并完成对 临界资源 的访问后，就应该进行 解锁 ，将 [锁资源] 让出，供其他线程（执行流）进行 加锁。

注意： 如果不进行解锁操作，会导致后续线程无法申请到 [锁资源] 而永久等待，引发 死锁 问题

（二） 解决抢票问题

为了方便所有线程看到同一把 锁 ，可以给线程信息创建一个类 TData，其中包括 name 和 pmtx

#include <iostream>
#include <string>
#include <unistd.h>
#include <pthread.h>

using namespace std;

int tickets = 1000; // 临界资源

class TData
{
public:
    TData(const string &name, pthread_mutex_t *pmtx)
        :_name(name), _pmtx(pmtx)
    {}
public:
    string _name;
    pthread_mutex_t *_pmtx;
};

void *threadRoutine(void *args)
{
    int sum = 0;
    TData *td = static_cast<TData*>(args);
    while(true)
    {
        // 进入临界区，加锁
        pthread_mutex_lock(td->_pmtx);

        // 有票才能抢
        if(tickets > 0)
        {
            usleep(2000);
            sum++;
            --tickets;

            // 出了临界区，解锁
            pthread_mutex_unlock(td->_pmtx);
        }
        else
        {
            // 没有票也是得解锁
            pthread_mutex_unlock(td->_pmtx);
            break;
        }

        // pthread_mutex_unlock(td->_pmtx);
        // 错误位置：不能只在这里解锁，没有票的时候会直接break了,锁就没有释放了

        usleep(2000); // 模拟票到手后处理剩余动作所需时间
    }

    // 屏幕也是文件，也是共享资源，加锁可以有效防止打印结果错行
    pthread_mutex_lock(td->_pmtx);
    cout << td->_name << " 抢票成功，票数为：" << sum << endl;
    pthread_mutex_unlock(td->_pmtx);

    delete td;
    return nullptr;
}

int main()
{
    // 创建一把锁
    pthread_mutex_t mtx;
    // 线程创建前，初始化互斥锁
    pthread_mutex_init(&mtx, nullptr);

    pthread_t pt[5];
    for(int i = 0; i < 5; i++)
    {
        char *name = new char[64];
        snprintf(name, 64, "thread|%d", i);
        TData *td = new TData(name, &mtx);

        pthread_create(pt+i, nullptr, threadRoutine, td);
    }
    for(int i = 0; i < 5; i++)
        pthread_join(pt[i], nullptr);

    cout << "所有线程已退出，无抢票操作，剩余票数：" << tickets << endl;

    // 线程退出，销毁互斥锁
    pthread_mutex_destroy(&mtx);

    return 0;
}

此时无论运行多少次程序，结果都没有问题：最终的剩余票数都是 0，并且所有线程抢到的票数之和为 1000

假设某个线程在解锁后，没有后续动作，那么它会再次加锁，继续干自己的事，如此重复形成竞争锁，该线程独享一段时间的资源

• 解决方法：解锁后让当前线程执行其他动作，也可以选择休眠一段时间，确保 [锁资源] 能尽可能均匀的分发给其他线程

1. 互斥锁细节

细节1： 凡是访问同一个临界资源的线程，都要进行加锁保护，而且必须加同一把锁，这是规则，必须遵守。

比如在上面的代码中，5 个并发线程看到的是同一把 互斥锁 ，只有看到同一把 互斥锁 才能确保线程间 互斥

---

细节2： 每一个线程访问临界区资源之前都要加锁，本质上是给临界区加锁

并且建议加锁时，粒度要尽可能的细，因为加锁后区域的代码是串行化执行的，代码量少一些可以提高多线程并发时的效率

---

细节3： 线程在访问临界区前，需要先加锁 -> 所有线程都要看到同一把锁 -> 锁本身也是临界资源 -> 锁如何保证自己的安全？

加锁 是为了保护 临界资源 的安全，但 锁 本身也是 临界资源 ，这就像是一个 先有鸡还是先有蛋的问题 ，锁 的设计者也考虑到了这个问题，于是对于 锁 这种 临界资源 进行了特殊化处理：加锁 和 解锁 操作都是原子的，不存在中间状态，也就不需要保护了。

---

细节4： 临界区本身是一行代码，或者一批代码

1. 线程在执行临界区内的代码时可以被调度吗？
2. 如果被调度切换后，对于锁及临界资源有影响吗？

首先，线程在执行临界区内的代码时，是允许被调度的，比如线程 1 在持有 [锁资源] 后结束运行，是完全可行的（证明可以被调度）；其次，线程在持有锁的情况下被调度是没有影响的，不会扰乱原有的加锁次序。

简单举例说明：

假设你的学校里有一个 顶级 VIP 自习室 ，一次只允许一个人使用。作为学校里的公共资源，这个 顶级 VIP 自习室 开放给所有学生使用。

使用规则：

• 一次只允许一个人使用
• 自习室的门上装有一把锁，优先到达自习室的可以获取钥匙并进入自习室
• 自习室内无限制，允许一直自习，直到自愿退出，退出后需要把钥匙交给下一个想要自习的同学

假设某天早上 6:00 张三就到达了 顶级 VIP 自习室 ，并成功获取钥匙，解锁后进入了自习室自习；之后陆陆续续有同学来到了 顶级 VIP 自习室 门口，因为他们都没有钥匙，只能默默等待张三或上一个进入自习室的人交接钥匙：

此时的张三不就是持有 [锁资源] ，并且在进行 临界资源 访问的 线程（执行流） 吗？其他线程（执行流）无法进入 临界区 ，只有等待张三 解锁（交出 [锁资源] / 钥匙） 。

假如张三此时想上厕所，并且不想失去钥匙，那么此时他就会带着钥匙去上厕所，即便自习室空无一人，但其他同学也无法进入自习室！

交接钥匙的本质是让出 自习室 的访问权，这不就是 线程解锁后离开临界区，其他线程加锁并进入临界区吗。

综上就可以借助 张三与顶级 VIP 自习室 的故事理解 线程持有锁时的各种状态。

---

细节5： 互斥会给其他线程带来影响

当某个线程持有 [锁资源] 时，对于其他线程的有意义的状态：

1. 锁被我申请了（其他线程无法获取）
2. 锁被我释放了（其他线程可以获取锁）

在这两种状态的划分下，确保了多线程并发访问时的 原子性

---

细节6： 加锁与解锁配套出现，并且这两个对于锁的操作本身就是原子的

至于如何确保 加锁和解锁 时的原子性，可以接着往下看。

（三）互斥锁的原理

在如今，大多数 CPU的体系结构（比如ARM、X86、AMD 等）都提供了 swap或者 exchange指令，这种指令可以把 寄存器 和 内存单元 的数据 直接交换 ，由于这种指令只有一条语句，可以保证指令执行时的 原子性。

即便是在多处理器环境下（总线只有一套），访问内存的周期也有先后，一个处理器上的交换指令执行时另一个处理器的交换指令只能等待总线周期，即 swap****和 exchange****指令在多处理器环境下也是原子的。

首先看一段伪汇编代码（加锁相关的），本质上就是 **pthread_mutex_lock()**函数

lock:
	movb $0, %al
	xchgb %al, mutex
	if(al寄存器里的内容 > 0){
		return 0;
	} else
		挂起等待;
	goto lock;

其中 movb表示赋值，al为一个寄存器，xchgb就是支持原子操作的 exchange交换语句

共识：计算机中的硬件，如 CPU 中的寄存器只有一份，被所有线程共享，但其中的内容随线程，不同线程的内容可能不同，也就是我们常说的上下文数据。

• 寄存器 != 寄存器中的内容（执行流的上下文）

1. 加锁原理

当线程 thread_A首次加锁时，整体流程如下：

①将 0 赋值给 al寄存器，这里假设 mutex默认值为**1** （其他不为 0 的整数也行）

movb $0, %al

②将 al寄存器中的值与 mutex的值交换（原子操作）

xchgb %al, mutex

③判断当前 al寄存器中的值是否 >0

if(al寄存器里的内容 > 0){
		return 0;
	} else
		挂起等待;

④此时线程 **thread_A**就可以快快乐乐的访问 临界区 代码了，如果此时线程 **thread_A被切走了（并没有出临界区，[锁资源] 也没有释放 ），OS**会保存 **thread_A**的上下文数据，并让线程 **thread_B**入场：

⑤首先将 al寄存器中的值赋为**0**

movb $0, %al

⑥其次将 al 寄存器中的值与 mutex的值交换（原子操作）

mutex****作为内存中的值，被所有线程共享，因此 thread_B 看到的 mutex****是被 thread_A 修改后的值。

显然此时交换了个寂寞，最后判断 al 寄存器中的值是否 >0

if(al寄存器里的内容 > 0){
	return 0;
} else
	挂起等待;

此时的 thread_B因为没有**[锁资源]** 而被拒绝进入 临界区 ，不止是 thread_B， 后续再多线程（除了 thread_A） 都无法进入 临界区。

不难看出，此时 thread_A的上下文数据中，al = 1 正是解开 临界区 的 钥匙 ，其他线程是无法获取的，因为 钥匙只能有一份

而汇编代码中 xchgb %al, mutex的本质就是 加锁 ，当 mutex不为 0 时，表示钥匙可用 ，可以进行 加锁 ；并且因为 xchgb %al, mutex只有一条汇编指令，足以确保加锁 过程是原子性 的

2. 解锁原理

现在再来看看 解锁 操作吧，本质上就是执行 pthread_mutex_unloc k**()** 函数

unlock:
	movb $1, mutex
	唤醒等待 [锁资源] 的线程;
	return

让 **thread_A**登场，并进行 解锁

将 mutex 中的值赋为 1

movb $1, mutex

既然 **thread_A**都走到了 解锁 这一步，证明它已经不需要再访问 临界资源 了，可以让其他线程去访问，也就是 唤醒其他等待 [锁资源] 的线程 ，然后 return 0走出 临界区

唤醒等待 [锁资源] 的线程;
return 0;

现在 [锁资源] 跑到 thread_B 手里了，并没有新增或丢失，再如此重复，就是 加锁 / 解锁 的原理

至于各种被线程执行某条汇编指令时被切出的情况，都可以不会影响整体 加锁 情况。

注意：

• 加锁是一个让不让你通过的策略
• 交换指令 swap 或 exchange 是原子的，确保 锁 这个临界资源不会出现问题
• 未获取到 [锁资源] 的线程会被阻塞至 pthread_mutex_lock() 处

（四）多线程封装

现在 互斥 相关内容已经学习的差不多了，可以着手编写一个小组件：Demo版线程库

目标：对 原生线程库 提供的接口进行封装，进一步提高对线程相关接口的熟练程度。

既然是封装，那必然离不开类，这里的类成员包括：

• 线程 ID
• 线程名 name
• 线程状态 status
• 线程回调函数 fun_t
• 传递给回调函数的参数 args

大体框架如下：

class Thread
{
public:
    // 状态表
    typedef enum
    {
        NEW = 0,
        RUNNING,
        EXITED
    }ThreadStatus;
    typedef void (*func_t)(void*);
private:
    pthread_t _tid; // 线程ID
    string name; // 线程名
    func_t _func; // 线程回调函数
    ThreadStatus _status; // 线程状态
    void *_args; // 回调函数的参数，可以设置成模板
};

首先完成 构造函数 ，初始化时只需要传递 编号、函数、参数 就行了

Thread(int num, func_t func = nullptr,  void *args = nullptr)
        :_tid(0), _func(func), _status(NEW), _args(args)
    {
        // 根据ID写入名字
        char name[128];
        snprintf(name, sizeof(name), "thread-%d", num);
        _name = name;
    }

其次完成各种获取具体信息的接口：

    // 获取线程ID
    pthread_t getID() { return _tid; }

    // 获取线程名
    string getName() { return _name; }

    // 获取线程状态
    int getStatus() { return _status; }

接下来就是处理 **线程启动，**及回调函数

    // 启动线程
    void run()
    {
        int n = pthread_create(&_tid, nullptr, runHelper, nullptr/*需考虑*/);
        if(n != 0)
        {
            cerr << "create thread fail" << endl;
            exit(1);
        }
        _status = RUNNING;// 线程跑起来状态为运行中
    }

    // 回调函数
    static void *runHelper(void *args)
    {
        _func(_args);
    }

此时这里出现问题了，pthread_create 无法使用 runHelper 进行回调

参数类型不匹配

原因在于：类中的函数（方法）默认有一个隐藏的 this 指针，指向当前对象，显然此时 runHelper 中的参数列表无法匹配。

解决方法：有几种解决方法，这里选一个比较简单粗暴的，直接把 runHelper 函数定义为 static 静态函数，这样他就会失去隐藏的 this 指针。

不过此时又出现了一个新问题：失去 this 指针后就无法访问类内成员了，也就无法进行回调了！

既然他想要 this 指针，那我们直接利用 pthread_create的参数4 进行传递就好了：

    // 启动线程
    void run()
    {
        int n = pthread_create(&_tid, nullptr, runHelper, this/*需考虑*/);
        if(n != 0)
        {
            cerr << "create thread fail" << endl;
            exit(1);
        }
        _status = RUNNING;// 线程跑起来状态为运行中
    }

    // 回调函数
    static void *runHelper(void *args)
    {
        Thread *ts = static_cast<Thread*>(args);// 强转对象指针

        ts->_func(ts->_args);// 回调用户传进来的 func 即可
        return nullptr;
    }

最后完成 线程等待

    // 线程等待
    void join()
    {
        int n = pthread_join(_tid, nullptr);
        if(n != 0)
        {
            cerr << "join thread fail" << endl;
            exit(1);
        }
        _status = EXITED;// 线程等待成功后状态为退出
    }

现在使用自己封装的 Demo版线程库，简单编写多线程程序

#include "Thread.hpp"

void threadRoutine(void *args)
{
    string message = static_cast<const char*>(args);
    int cnt = 3;
    while(cnt--)
    {
        cout << cnt << " | thread created, " << message << endl;
        sleep(1);
    }
}
int main()
{
    Thread t1(1, threadRoutine, (void*)"good morning");
    cout << "thread ID: " << t1.getID() << " | thread name: " 
    << t1.getName() << " | thread status: " << t1.getStatus() << endl;
    t1.run();
    cout << "thread ID: " << t1.getID() << " | thread name: " 
    << t1.getName() << " | thread status: " << t1.getStatus() << endl;
    t1.join();
    cout << "thread ID: " << t1.getID() << " | thread name: " 
    << t1.getName() << " | thread status: " << t1.getStatus() << endl;

    return 0;
}

运行结果如下，可以看出线程的状态从 0 至 2 ，即 创建 -> 运行 -> 退出

（五）互斥锁的封装

原生线程库 提供的 互斥锁 相关代码比较简单，也比较好用，但有一个很麻烦的地方：就是每次都得手动加锁、解锁，如果忘记解锁，还会导致其他线程陷入无限阻塞的状态。

因此我们对锁进行封装，实现一个简单易用的 小组件。

封装思路：利用创建对象时调用构造函数，对象生命周期结束时调用析构函数的特点，融入 加锁、解锁 操作即可。

非常简单，直接创建一个 **LockGuard**类

#pragma once

#include <pthread.h>

class LockGuard
{
public:
    LockGuard(pthread_mutex_t *pmtx)
        :_pmtx(pmtx)
    {
        // 加锁
        pthread_mutex_lock(_pmtx);
    }

    ~LockGuard()
    {
        // 解锁
        pthread_mutex_unlock(_pmtx);
    }
private:
    pthread_mutex_t *_pmtx;
};

现在把 Demo版线程库 和 Demo版互斥锁 融入 多线程抢票 程序中：

#include "Thread.hpp"
#include "Mutex.hpp"

pthread_mutex_t mtx;
int tickets = 1000;

void threadRoutine(void *args)
{
    int sum = 0;
    const char *name = static_cast<const char*>(args);
    while(true)
    {
        // 进入临界区加锁
        {
            // 自动加锁，解锁
            LockGuard guard(&mtx);

            if(tickets > 0)
            {
                usleep(2000);
                sum++;
                tickets--;
            }
            else
            {
                break;
            }
        }
        usleep(2000);
    }

    {
        LockGuard guard(&mtx);
        cout << "线程 " << name << " 抢票完毕，最终抢到的票数 " << sum << endl;
    }
}
int main()
{
    pthread_mutex_init(&mtx, nullptr);

    Thread t1(1, threadRoutine, (void*)"thread-1");
    Thread t2(2, threadRoutine, (void*)"thread-2");
    Thread t3(3, threadRoutine, (void*)"thread-3");
    // 启动
    t1.run();
    t2.run();
    t3.run();

    // 等待
    t1.join();
    t2.join();
    t3.join();

    // 线程退出后，销毁互斥锁
    pthread_mutex_destroy(&mtx);

    cout << "剩余票数: " << tickets << endl;
    
    return 0;
}

1. RAII 风格

像这种 获取资源即初始化 的风格称为 **RAII**风格，由 C++ 之父 本贾尼·斯特劳斯特卢普 提出，非常巧妙的运用了 类和对象 的特性，实现半自动化操作。

（六）总结

在计算机科学中，"互斥"主要涉及到并发控制和资源管理 的概念。具体地，**互斥通常指的是在多进程或多线程环境下，当一个进程或线程在访问共享资源或执行某段关键代码时，其他进程或线程不能同时访问该资源或执行该代码。**这种机制确保了资源的一致性和完整性，防止了数据竞争和不一致的状态。

在计算机术语中，互斥通常通过**"互斥锁"** （Mutex）或**"锁"** （Lock）来实现。当一个进程或线程需要访问共享资源时，它会先尝试获取锁。如果锁当前没有被其他进程或线程持有，那么它就可以成功获取锁并访问资源。在访问完资源后，它会释放锁，以便其他进程或线程可以获取锁并访问资源。

这种互斥机制对于保证数据完整性和程序正确性至关重要，特别是在并发环境下，多个进程或线程可能同时尝试访问或修改共享资源时。

此外，在并发编程中，互斥还涉及到**临界区（critical section）**的概念。临界区是一段代码，当一个线程进入临界区执行时，其他线程不能同时进入临界区执行。这确保了同一时间只有一个线程可以访问或修改共享资源，从而防止了数据不一致和其他并发问题。

总的来说，在计算机科学中，**"互斥"**是一个重要的概念，用于确保并发环境下资源的正确访问和程序的正确执行。

四、线程安全 VS 重入

概念

• 线程安全：多线程并发访问同一段代码时，不会出现不同的结果，此时就是线程安全的；但如果在没有加锁保护的情况下访问全局变量或静态变量，导致出现不同的结果，此时线程就是不安全的。
• 重入：同一个函数被多个线程（执行流）调用，当前一个执行流还没有执行完函数时，其他执行流可以进入该函数，这种行为称之为 重入；在发生重入时，函数运行结果不会出现问题，称该函数为 可重入函数，否则称为 不可重入函数。

常见线程不安全的情况

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

常见线程安全的情况

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

---

常见不可重入的情况

• 调用了 malloc / free 函数，因为这些都是 C语言 提供的接口，通过全局链表进行管理
• 调用了标准 I/O 库函数，其中很多实现都是以不可重入的方式来使用全局数据结构
• 可重入函数体内使用了静态的数据结构

常见可重入的情况

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

---

重入与线程安全的联系

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

重入与线程安全的区别

• 可重入函数是线程安全函数的一种
• 线程安全不一定是可重入的，反过来可重入函数一定是线程安全的
• 如果对于临界资源的访问加上锁，则这个函数是线程安全的；但如果这个重入函数中没有被释放会引发死锁，因此是不可被重入的。

一句话总结：是否可重入只是函数的一种特征，没有好坏之分，但线程不安全是需要规避的

五、死锁

（一）概念

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

例如，设存在两个线程SetThread和GetThread，SetThread持有了资源ObjectA 并请求资源ObjectB ，而GetThread持有了资源ObjectB并请求资源ObjectA。如果这两个资源的获取是互斥的，并且两个线程都不释放各自持有的资源，那么它们就会无限期地等待对方释放资源，从而形成死锁。

简单举个例子：

两个小朋各持 五毛钱 去商店买东西，俩人同时看中了一包 辣条 ，但这包 辣条 售价 一块钱，两个小朋友都想买了自己吃，但彼此的钱都不够，双方互不谦让，此时局面就会僵持不下。

两个小朋友：两个不同的线程

辣条：临界资源

售价：访问临界资源需要的锁资源数量，这里需要两把锁

两个小朋友各自手里的钱：一把锁资源

僵持不下的场面：形成死锁，导致程序无法继续运行

所以死锁就是 多个线程都因锁资源的等待而被同时挂起，导致程序陷入 死循环。

只有一把锁会造成死锁吗？

• 在只有一把锁的情况下，可能会出现阻塞 （Block）状态，即一个线程持有锁时，其他线程无法获取该锁而处于等待状态。
• 有一种特殊情况可能导致看似由一把锁造成的死锁。这通常发生在编程错误中，例如程序员在应该释放锁的时候，错误地再次申请了同一把锁，导致该线程自己被自己阻塞，形成了死锁。但这实际上是由于编程错误造成的，而非锁本身的特性导致的。

（二）死锁产生条件及如何避免

死锁产生的四个必要条件：

1. 互斥 ：**至少有一个资源必须处于非共享状态，即一次只能被一个进程或线程占用。**这表示如果一个资源被一个进程占用，那么其他进程就不能使用这个资源，直到第一个进程释放它。
2. 请求与保持 （或称为占有且等待 ）：**进程或线程至少需要持有一个资源，并且在等待其他资源时不释放已占有的资源。**这表示一个进程或线程在持有至少一个资源的同时，还在请求其他被其他进程或线程持有的资源。
3. 不可剥夺 （或称为非抢占 ）：**已分配给进程或线程的资源不能被强制性地剥夺，只能由持有资源的进程或线程主动释放。**这意味着资源不能被其他进程或线程强行拿走，除非资源的持有者自愿释放它。
4. 循环等待 ：存在一个进程或线程的资源申请序列，使得每个进程或线程都在等待下一个进程或线程所持有的资源。 这构成了一个闭环，每个进程或线程都在等待其他某个进程或线程释放资源，从而导致了死锁。

只有四个条件都满足了，才会引发 死锁 问题。

如何避免 死锁 问题？

核心思想：破坏四个必要条件的其中一个或多个

方法1：不加锁

不加锁的本质是不保证 互斥，即破坏条件1。

---

方法2：尝试主动释放锁

比如进入 临界区 访问临界资源 ，需要两把锁，thread_A和 thread_B各自持有一把锁，并且都在尝试申请第二把锁，但如果此时 thread_A****放弃申请，主动把锁释放，这样就能打破 死锁 的局面，主打的就是一个牺牲自己造福他人。

可以借助 pthread_mutex_trylock函数实现这种方案

int pthread_mutex_trylock(pthread_mutex_t *mutex);

这个函数就是尝试申请锁，如果长时间申请不到锁，就会把自己当前持有的锁释放，然后放弃加锁，给其他想要加锁的线程一个机会。

---

方法3：按照顺序申请锁

按照顺序申请锁 -> 按照顺序释放锁 -> 就不会出现环路等待的情况

当需要访问多个资源时，尽量保持一致的加锁顺序。这样可以避免循环等待的情况，因为每个线程或进程都会以相同的顺序请求锁。

---

方法4：控制线程统一释放锁

首先要明白：**锁不一定要由申请锁的线程释放，其他线程也可以释放锁。**通常情况下，锁是由申请锁的线程释放的，但特殊机制或框架可能允许其他线程释放锁。

这是由释放锁的机制决定的，直接向 mutex 赋值而非交换，意味着其他线程也能解锁

unlock:
	movb $1, mutex
	唤醒等待 [锁资源] 的线程;
	return

比如在下面这个程序中，主线程就释放了次线程申请的锁，打破了 死锁 的局面：

// 全局互斥锁，无需手动初始化和销毁
pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;

void *threadRoutine(void *args)
{
    cout << "我是次线程，开始运行" << endl;

    // 申请锁
    pthread_mutex_lock(&mtx);
    cout << "次线程申请到了一把锁" << endl;

    // 在不释放锁定情况相下，再次申请锁，陷入 死锁 状态
    pthread_mutex_lock(&mtx);
    cout << "次线程又申请到了一把锁" << endl;

    pthread_mutex_unlock(&mtx);
}

int main()
{
    pthread_t t;
    pthread_create(&t, nullptr, threadRoutine, nullptr);

    // 等待次线程先运行3秒
    sleep(3);
    cout << "等待3秒..." << endl;

    // 主线程帮忙释放锁
    pthread_mutex_unlock(&mtx);
    cout << "我是主线程，我已帮次线程释放了一把锁" << endl;

    // 等待次线程后续动作
    sleep(3);

    pthread_join(t, nullptr);
    cout << "线程等待成功" << endl;

    return 0;
}

最终程序运行后，可以看到 主线程成功帮次线程释放了锁资源：

因此，我们可以设计一个 控制线程 ，专门掌管所有的锁资源，如果识别到发生了 死锁 问题，就释放所有的锁，让线程重新竞争。

注意：通常情况下，每个线程或进程只能释放自己持有的锁。如果一个线程持有一个锁，其他线程是无法直接释放这个锁的。这是因为锁通常与特定的线程或进程相关联，以确保资源的独占性和安全性。

常见的避免 死锁 问题的算法：死锁检测算法、银行家算法。

六、线程同步

（一）同步概念

同步：在保证数据安全的前提下，让线程能够按照某种特定的顺序访问临界资源，从而有效避免 饥饿问题。

有了加锁以后我们多线程访问临界资源导致数据不一致性的问题确实得到了解决，但是单纯的加锁是会存在某些问题的，如果个别线程的竞争力特别强，每次都能够申请到锁，但申请到锁之后由于条件不满足于是什么也不做，所以在我们看来这个线程就一直在申请锁和释放锁，这就可能导致其他线程长时间竞争不到锁，引起饥饿问题。

如何正确理解 饥饿问题：

话说张三在早上 6:00 抢到了自习室的钥匙，并开开心心的进入了自习室自习

此时自习室外人声鼎沸，显然有很多人都在等待张三交出钥匙，但张三不急，慢悠悠的自习到了中午 12:00，此时张三有些饿了，想出去吃个饭，吃饭就意味着张三需要把钥匙归还（这是规定）。

张三刚把钥匙放到门上，扭头就发现了大批的同学正在等待钥匙，张三心想：要是我就这样把钥匙归还了，那等我吃完饭回来岂不是也需要等待。

于是法外狂徒张三决定放弃吃饭，强忍着饥饿再次拿起钥匙进入了自习室自习；刚进入自习室没几分钟，肚子就饿的咕咕叫，于是张三就又想出去吃饭，刚出门归还了钥匙，扭头看见大批同学就感觉很亏，一咬牙就又拿起钥匙进入了自习室，就这样张三反复横跳 ，直到下午 6:00 都还没吃上午饭，不仅自己没吃上午饭、没好好自习，还导致其他同学无法自习！

张三错了吗？张三没错，十分符合自习室的规定，只是 不合理。 因为张三这种不合理的行为，导致 自习室 资源被浪费了，在外等待的同学也失去了自习，陷入 饥饿状态 ，活生生被张三 "饿惨了"。

为此校方更新了 自习室 的规则：

• 所有自习完的同学在归还钥匙之后，不能立即再次申请
• 在外面等待钥匙的同学必须排队，遵守规则

规则更新之后，就不会出现这种 饥饿问题 了，所以解决 饥饿问题 的关键是：在安全的规则下，使多线程访问资源具有一定的顺序性。

即通过 线程同步 解决 饥饿问题

---

原生线程库 中提供了 条件变量 这种方式来实现 线程同步

逻辑链：通过条件变量 -> 实现线程同步 -> 解决饥饿问题

条件变量：当一个线程互斥的访问某个变量时，它可能发现在其他线程改变状态之前，什么也做不了。 例如一个线程访问队列时，发现队列为空，它只能等待，直到其它线程将一个节点添加到队列中这个线程才被唤醒，这种情况就需要用到条件变量。

其本质就是：衡量访问资源的状态。一旦共享资源的状态发生变化，使得等待的线程或进程可以安全地访问它时，条件变量就会被触发，唤醒等待的线程或进程。这样，线程或进程就可以继续执行，并安全地访问共享资源。

竞态条件：**两个或更多进程或线程在并发执行时，其最终的结果依赖于这些进程或线程执行的精确时序。当程序的运行结果因执行顺序的改变而受到影响时，就发生了竞态条件。**竞态条件可能会导致超出预期的情况，因此在编程中通常需要避免这种情况。

可以把 条件变量 看作一个结构体，其中包含一个 队列 结构，用来存储正在排队等候的线程信息，当条件满足时，就会取 队头 线程进行操作，操作完成后重新进入 队尾

队列是保证顺序性的重要工具

（二）同步相关操作

1. 条件变量的创建与销毁

作为出自 原生线程库 的 条件变量 ，使用接口与 互斥锁 风格差不多，比如 条件变量 的类型为 pthread_cond_t，同样在创建后需要初始化，在使用结束后需要销毁

#include <pthread.h>

pthread_cond_t cond; // 定义一个条件变量
int pthread_cond_init(pthread_cond_t *restrict cond,
      const pthread_condattr_t *restrict attr);

int pthread_cond_destroy(pthread_cond_t *cond);

参数1 pthread_cond_t* 表示想要初始化的条件变量

参数2 const pthread_condattr_t* 表示初始化时的相关属性，设置为 nullptr 表示使用默认属性

返回值：成功返回 0 ，失败返回**error number**

注：同互斥锁一样，条件变量支持静态分配，即在创建全局条件变量时，定义为 PTHREAD_COND_INITIALIZER，表示自动初始化、自动销毁

pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

注意： 这种定义方式只支持全局条件变量。

2. 条件等待

原生线程库 中提供了 pthread_cond_wait函数用于等待

#include <pthread.h>

int pthread_cond_wait(pthread_cond_t *restrict cond,
       pthread_mutex_t *restrict mutex);

参数1 pthread_cond_t* 想要加入等待的条件变量。

参数2 pthread_cond_t* 互斥锁，用于辅助条件变量。

返回值：成功返回 0 ，失败返回**error number**

参数2值得详细说一说，首先要明白 条件变量是需要配合互斥锁使用的，需要在获取 [锁资源] 之后，在通过条件变量判断条件是否满足。

传递互斥锁的理由：

1. 条件变量也是临界资源，需要保护。
2. 当条件不满足时（没有被唤醒），当前持有锁的线程就会被挂起，其他线程还在等待锁资源呢，为了避免死锁问题，条件变量需要具备自动释放锁的能力。

当某个线程被唤醒时，条件变量释放锁，该线程会获取锁资源，并进入 条件等待 状态。

3. 条件唤醒

条件变量 中的线程是需要被唤醒的，否则它也不知道何时对 队头线程 进行判断，可以使用 pthread_cond_signal或者 pthread_cond_broadcast函数进行唤醒

#include <pthread.h>

int pthread_cond_signal(pthread_cond_t *cond);

int pthread_cond_broadcast(pthread_cond_t *cond);

使用 pthread_cond_signal 一次只会唤醒一个线程，即队头线程。 如果想唤醒全部线程 ，可以使用 pthread_cond_broadcast 。**broadcast**就是广播的意思，也就是挨个通知该 条件变量 中的所有线程访问 临界资源

pthread_cond_t* 表示想要从哪个条件变量中唤醒线程

返回值：成功返回 0 ，失败返回**error number**

（三）简单同步demo

接下来简单使用一下 线程同步 相关接口

目标：创建 5 个次线程，等待条件满足，主线程负责唤醒

这里演示 单个唤醒 与 广播 两种方式，先来看看 单个唤醒 相关代码

#include <iostream>
#include <unistd.h>
#include <pthread.h>

using namespace std;

// 互斥锁和条件变量都定义为自动初始化和释放
pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

int num = 5; // 五个线程

void *Active(void *args)
{
    const char *name = static_cast<const char*>(args);

    while(true)
    {
        // 加锁
        pthread_mutex_lock(&mtx);

        // 等待条件满足
        pthread_cond_wait(&cond, &mtx);
        cout << "thread " << name << " 正在运行" << endl;

        // 解锁
        pthread_mutex_unlock(&mtx);
    }
    delete[] name;
    return nullptr;
}

int main()
{
    pthread_t pt[num];
    for(int i = 0; i < num; i++)
    {
        char *name = new char[32];
        snprintf(name, 32, "thread-%d", i);
        pthread_create(pt+i, nullptr, Active, (void*)name);
    }

    // 等待所以次线程就位
    sleep(3);

    // 主线程唤醒次线程
    while(true)
    {
        cout << "Main thread wake up another thread..." << endl;
        pthread_cond_signal(&cond); // 单个
        // pthread_cond_broadcast(&cond); // 广播

        sleep(1);
    }

    for(int i = 0; i < num; i++)
        pthread_join(pt[i], nullptr);

    return 0;
}

可以看到，在 单个唤醒 模式下，一次只会有一个线程苏醒，并且得益于 条件变量，线程苏醒的顺序都是一样的：

可以将唤醒方式换成 广播

pthread_cond_broadcast(&cond); // 广播

现在就变成一次唤醒一批线程了，并且顺序仍然不会改变

（四）总结

同步 用于确保多个并发执行的线程、进程或设备按照预期的顺序和规则进行操作 。它的主要目的是维护数据的一致性和避免竞态条件 （Race Conditions）。这些同步机制用于协调不同线程或进程之间的操作，确保它们对共享资源的访问是互斥的，从而避免数据冲突和不一致，确保在并发环境中资源的正确访问和数据的完整性。