Linux-多线程安全

目录

Linux分离线程

Joinable（默认状态）：

Detached（分离状态）：

Linux线程互斥

深入理解原子操作

互斥量mutex

互斥量的接口

互斥量实现原理探究

可重入VS线程安全

概念

常见的线程不安全的情况

常见的线程安全的情况

常见的不可重入的情况

常见的可重入的情况

可重入与线程安全联系

可重入与线程安全区别

常见锁概念

死锁

死锁的四个必要条件

避免死锁

用现实例子类比

Linux线程同步

同步概念与竞态条件

条件变量

条件变量函数

为什么pthread_cond_wait需要互斥量

错误的设计

条件变量使用规范

---

Linux分离线程

Joinable（默认状态）：

• 新创建的线程默认是joinable的。

• 这种线程在终止后，其资源（如线程ID、栈内存、退出状态等）不会自动释放，必须由其他线程通过调用 pthread_join() 来回收。

• pthread_join() 会阻塞调用线程，直到目标线程终止，并获取其返回值（通过 pthread_exit 或 return）。

Detached（分离状态）：

• 通过 pthread_detach() 可以将线程设为分离状态。

• 分离状态的线程终止时，系统会自动回收其资源，无需其他线程调用 pthread_join()。

• 分离线程无法被其他线程连接（pthread_join() 会失败）。

• 在默认情况下，新建的线程是joinable（可连接）的，线程退出后，需要对其进行pthread_join的，否则无法释放资源，从而造成系统泄露。
• 如果不关心线程的返回值，join是一种负担，这个时候，我们可以告诉系统，当线程退出时，自动释放线程资源。

其中设置设置当线程退出时，自动释放线程资源的函数原型如下：

int pthread_detach(pthread_t thread);

参数说明：

• thread：被分离线程的ID。

返回值说明：

• 线程分离成功返回0，失败返回错误码。

可以是线程组内其他线程对目标线程进行分离，也可以时线程自己分离：

pthread_detach(pthread_self());

joinable和分离式冲突的，一个线程不能既是joinable又是分离的。

其分离的本质上是：再分离还是线程，还共享资源，只是别人不管你了。

对于joinable和分离式冲突，不妨用下面的代码进行验证，我们先用主线程创建一个线程，其传参数thread 1，然后再其线程内自己分离，后在主线程打印其线程的退出信息：

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

using namespace std;

void *thread_run(void *arg)
{
    pthread_detach(pthread_self());
    printf("%s\n",(char*)arg);
    return nullptr;
}

int main()
{
    pthread_t tid;
    if(pthread_create(&tid, NULL, thread_run, (void *)"thread1 run...") != 0){
        printf("create thread error\n");
        return 1;
    }

    // 同样也可以这样设置分离
    // pthread_detach(tid);
    
    int ret = 0;
    sleep(1);

    if(pthread_join(tid, NULL) == 0){
        printf("pthread wait success\n");
        ret = 0;
    }
    else{
        printf("pthread wait failed\n");
        ret = 1;
    }
    return ret;
}

如图，可以看到运行效果：

Linux线程互斥

进程线程间的互斥相关背景概念

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

临界资源和临界区

进程之间如果要进行通信，其根本就是，我们需要先创建第三方资源，让不同的进程看到同一份资源，由于这份第三方资源可以由操作系统中的不同模块提供，于是进程间通信的方式有很多种。其中，进程间通信中我们提供的第三方资源就叫做临界资源，访问第三方资源的代码就叫做临界区。

而多线程中的大部分资源都是共享的，线程之间通信不需要花费太多，不需要我们额外提供第三方资源。

例如，我们创建一个全局的变量count，再创建一个线程，其线程内每秒对count++，主线程内循环每秒打印count。

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

using namespace std;

int count = 0;

void *thread_run(void *arg)
{
	while (1)
    {
		count++;
		sleep(1);
	}
	pthread_exit((void*)0);
}

int main()
{
    pthread_t tid;
    pthread_create(&tid, NULL, thread_run, NULL);
    while (1)
    {
		printf("count: %d\n", count);
		sleep(1);
	}
	pthread_join(tid, NULL);

    return 0;
}

运行结果如下：

此时可以看到对于主线程与创建的新线程，其二者在理论上就利用了临界资源和临界区实现了简易的通信。其中的count就属于临界资源，被多个执行流所共享，而主线程的printf与新线程中的count++就在临界区。

互斥和原子性

在多线程情况下，如果这多个执行流都自顾自的对临界资源进行操作，又或者说自顾自的打印，那么此时就可能导致数据不一致，数据错乱的问题。

解决该问题的方案就叫做互斥，互斥的作用就是，保证在任何时候有且只有一个执行流进入临界区对临界资源进行访问。

原子性就是源于原子的特点而为名，指的是不可被分割的操作，该操作不会被任何调度机制打断，该操作只有两态，要么完成，要么未完成，并没有执行中一说。

就比如下面我们设想一个场景，你是一名电影院的老板，在某一天你要安排用2号影厅放一场电影，2号影厅共有100个座位。所以最多可以卖100张票。

现在使用多线程进行模拟下抢票系统，我们先创建五个线程，用全局变量统计剩余票数，这五个线程每隔0.1秒都进行票数减减进行抢票，知道抢完，这五个线程自动退出。

#include <iostream>

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

using namespace std;

int count = 100;

void *thread_run(void *arg)
{
    const char* name = (char*)arg;
	while (1)
    {
		if (tickets > 0)
        {
			sleep(0.1);
			printf("[%s] get a ticket, left: %d\n", name, --count);
		}
		else
        {
			break;
		}
	}
	printf("%s quit!\n", name);
	pthread_exit((void*)0);

}

int main()
{
    pthread_t tid[5];
    for(int i = 0; i < 5; i++)
    {
        char* buffer = (char*)malloc(64);
        sprintf(buffer, "thread %d", i);
        pthread_create(&tid[i], NULL, thread_run, (void *)buffer);
    }

    for(int i = 0; i < 5; i++)
    {
	    pthread_join(tid[i], NULL);
    }


    return 0;
}

运行结果显然不符合我们的预期，因为其中出现了剩余票数为负数的情况。

该代码中记录剩余票数的变量tickets就是临界资源，因为它被多个执行流同时访问，而判断tickets是否大于0、打印剩余票数以及--tickets这些代码就是临界区，因为这些代码对临界资源进行了访问。

剩余票数出现负数的原因：

• if语句判断条件为真以后，代码可以并发的切换到其他线程。
• usleep用于模拟漫长业务的过程，在这个漫长的业务过程中，可能有很多个线程会进入该代码段。
• --ticket操作本身就不是一个原子操作。

这里先给出答案，相信看到这里，你肯定会有一堆疑问，但还请保留，下面会从0开始一点一点全部解释，会先从C语言慢慢回顾。

深入理解原子操作

我们先写一个简单的C语言代码：

#include <stdio.h>

int main()
{
	int count = 100;
	count--;
	return 0;
}

即便是这么简单的count++，其转为反汇编，可以看到也是由好几条汇编指令组成

其中这三条汇编指令的意思分别是：

1. mov eax, dword ptr [count] -- load

   • 将变量 count 的值从内存加载到寄存器 eax 中。

   • dword ptr [count] 表示从内存地址 count 处读取一个双字（4字节）的数据。

2. dec eax -- update

   • 对寄存器 eax 中的值进行减1 操作。

   • 这是直接对寄存器内容的简单递增。

3. mov dword ptr [count], eax -- store

   • 将寄存器 eax 中递增后的值存回内存中的变量 count。

   • 这样，count 的值就完成了减 1 的更新。

这三条指令共同完成了以下高级语言代码的功能：count--;

用图来表示就是如下：

即便count--，需要分三步才可以完成。

假设我们有一个全局变量 int count = 100，两个线程同时执行 count--。在单线程环境下，这没有任何问题，但在多线程情况下，事情就变得复杂了。

每个 count-- 操作实际上会被编译成三条机器指令：

1. 从内存读取count值到寄存器

2. 对寄存器中的值减1

3. 将结果写回内存

现在考虑两个线程同时执行这个操作的情况：

线程A执行：

1. 读取count=100到寄存器

2. 寄存器值减1，变成99

   此时线程被中断，线程B开始执行：

3. 读取count=100到寄存器（因为线程A还没写回）

4. 寄存器值减1，变成99

5. 把99写回内存

   然后线程A恢复执行：

6. 把99写回内存

最终，虽然两个线程都执行了count--，但count只从100减到了99，而不是预期的98。这就是典型的竞态条件问题。

更糟糕的是，如果线程A的第三步被延迟很久，而其他线程已经做了很多次count--，比如已经把count减到了50，这时线程A才执行第三步，就会把count从50错误地覆盖成99，导致其他线程的所有操作都被覆盖。这样显然是非常不合理的！！！

注意：

• 当线程A被切走时，寄存器中的100叫做线程A的上下文信息，因此需要被保存起来，之后线程A就被挂起了，并不会直接丢弃。
• 寄存器不等于寄存器的内容。
• 线程在执行的时候，将共享数据加载到CPU寄存器的本质：把数据的内容变为自己的上下文。以拷贝的方式，给自己单独拿了一份。
• CPU数据交换的核心本质是：将内存中的数据加载到CPU寄存器中，并在线程切换时正确保存和恢复这些寄存器的状态（即线程的硬件上下文）。

因此对一个变量进行--操作并不是原子的，虽然--count看起来就是一行代码，但这行代码被编译器编译后本质上是三行汇编。同理，对一个变量进行++也需要对应的三个步骤，即++操作也不是原子操作。

互斥量mutex

所以为了解决诸如上面的问题，就需要引入互斥量来解决。

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

所以要解决上述抢票系统的问题，需要做到三点：

• 代码必须有互斥行为：当代码进入临界区执行时，不允许其他线程进入该临界区。
• 如果多个线程同时要求执行临界区的代码，并且此时临界区没有线程在执行，那么只能允许一个线程进入该临界区。
• 如果线程不在临界区中执行，那么该线程不能阻止其他线程进入临界区。

要做到这三点，本质上就是需要一把锁，Linux上提供的这把锁叫互斥量。

互斥量的接口

初始化互斥量

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

方法一：静态分配 -- 设置全局锁

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER

方法二：动态分配

其函数叫做pthread_mutex_init，该函数的函数原型如下：

int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict attr);

参数说明：

• mutex：需要初始化的互斥量。
• attr：初始化互斥量的属性，一般设置为NULL即可。

返回值说明：

• 互斥量初始化成功返回0，失败返回错误码。

销毁互斥量

销毁互斥量的函数叫做pthread_mutex_destroy，该函数的函数原型如下：

int pthread_mutex_destroy(pthread_mutex_t *mutex);

参数说明：

• mutex：需要销毁的互斥量。

返回值说明：

• 互斥量销毁成功返回0，失败返回错误码。

销毁互斥量需要注意：

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

互斥量加锁

互斥量加锁的函数叫做pthread_mutex_lock，该函数的函数原型如下：

int pthread_mutex_lock(pthread_mutex_t *mutex);

参数说明：

• mutex：需要加锁的互斥量。

返回值说明：

• 互斥量加锁成功返回0，失败返回错误码。

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

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

互斥量解锁

互斥量解锁的函数叫做pthread_mutex_unlock，该函数的函数原型如下：

int pthread_mutex_unlock(pthread_mutex_t *mutex);

参数说明：

• mutex：需要解锁的互斥量。

返回值说明：

• 互斥量解锁成功返回0，失败返回错误码。

使用互斥量对上面的抢票系统进行改进：

在上述的抢票系统中引入互斥量，每一个线程要进入临界区之前都必须先申请锁，只有申请到锁的线程才可以进入临界区对临界资源进行访问，并且当线程出临界区的时候需要释放锁，这样就保证了在同一时间内只有一个线程进入临界区。

#include <iostream>

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

using namespace std;

int tickets = 100;
pthread_mutex_t mutex;

void *thread_run(void *arg)
{
    const char* name = (char*)arg;
	while (1)
    {
        pthread_mutex_lock(&mutex);
		if (tickets > 0)
        {
			sleep(0.1);
			printf("[%s] get a ticket, left: %d\n", name, --tickets);
            pthread_mutex_unlock(&mutex);
		}
		else
        {
            pthread_mutex_unlock(&mutex);
			break;
		}
	}
	printf("%s quit!\n", name);
	pthread_exit((void*)0);

}

int main()
{
    pthread_mutex_init(&mutex, NULL);
    pthread_t tid[5];
    for(int i = 0; i < 5; i++)
    {
        char* buffer = (char*)malloc(64);
        sprintf(buffer, "thread %d", i);
        pthread_create(&tid[i], NULL, thread_run, (void *)buffer);
    }

    for(int i = 0; i < 5; i++)
    {
	    pthread_join(tid[i], NULL);
    }

    pthread_mutex_destroy(&mutex);
    return 0;
}

此时再运行代码，抢票过程中就不会出现票数剩余为负数的情况了。

注意：

• 在大部分情况下，加锁本身都是有损于性能的事，它让多执行流由并行执行变为了串行执行，这几乎是不可避免的。
• 我们应该在合适的位置进行加锁和解锁，这样能尽可能减少加锁带来的性能开销成本。
• 进行临界资源的保护，是所有执行流都应该遵守的标准，这时程序员在编码时需要注意的。

互斥量实现原理探究

加锁后的原子性体现在哪里？

引入互斥量后，当一个线程申请到锁进入临界区时，在其他线程看来该线程只有两种状态，要么没有申请锁，要么锁已经释放了，因为只有这两种状态对其他线程才是有意义的。那么申请到锁的线程所有的操作都是类"原子性"的操作。

例如，图中线程4进入临界区后，在线程1、2、3、5看来，线程4要么没有申请锁，要么就是已经释放了锁。对他们来说只有这两种状态，也只有这两种状态有意义，此时线程1、2、3、5是出于阻塞状态。此时对于线程1、2、3、5来说线程4的所有操作都是"原子性"的。

临界区内的线程可能进行线程切换吗？

临界区内的线程完全可能进行线程切换，但即便被切换走了，其他线程还是无法正常进入临界区的，因为即便临界区的线程被切走，但其还是拿着锁被切走的，锁没有被释放，那么也就意味着其他线程无法申请锁，也就无法进入临界区了。

锁是否需要被保护？

我们说被多个执行流共享的资源叫做临界资源，访问临界资源的代码叫做临界区。所有线程在进入临界区之前都要竞争式的申请锁。正常情况下锁只有一个，那么也仅有一个线程拿着锁。所以锁也是被多个执行流所共享的资源，也是属于临界资源。

既然是临界资源，那么锁也要被保护起来，但锁的设计目的就是为了保护临界资源的，现在又说锁是临界资源，又要被保护，那么谁来保护锁呢？

实际上，锁是自己保护自己的，我们只需要保证申请锁的过程是原子的，那么锁就是安全的。

如何保证申请锁的过程是原子的？

• 上面我们已经说明了--和++操作不是原子操作，可能会导致数据不一致问题。
• 为了实现互斥锁操作，大多数体系结构都提供了swap或exchange指令，该指令的作用就是把寄存器和内存单元的数据相交换。
• 由于只有一条指令，保证了原子性，即使是多处理器平台，访问内存的总线周期也有先后，一个处理器上的交换指令执行时，另一个处理器的交换指令只能等待总线周期。

下面我们看一下lock与unlock的伪代码了解一下

我们可以认为mutex的初始值为1，al是计算机中的一个寄存器，当线程申请锁时，需要执行以下步骤：

1. 先将al寄存器中的值清0。该动作可以被多个线程同时执行，因为每个线程都有自己的一组寄存器（上下文信息），执行该动作本质上是将自己的al寄存器清0。
2. 然后交换al寄存器和mutex中的值。xchgb是体系结构提供的交换指令，该指令可以完成寄存器和内存单元之间数据的交换。
3. 最后判断al寄存器中的值是否大于0。若大于0则申请锁成功，此时就可以进入临界区访问对应的临界资源；否则申请锁失败需要被挂起等待，直到锁被释放后再次竞争申请锁。

当线程释放锁时，需要执行以下步骤：

1. 将内存中的mutex置回1。使得下一个申请锁的线程在执行交换指令后能够得到1，形象地说就是"将锁的钥匙放回去"。
2. 唤醒等待Mutex的线程。唤醒这些因为申请锁失败而被挂起的线程，让它们继续竞争申请锁。

注意：

• 在申请锁时本质上就是哪一个线程先执行了交换指令，那么该线程就申请锁成功，因为此时该线程的al寄存器中的值就是1了。而交换指令就只是一条汇编指令，一个线程要么执行了交换指令，要么没有执行交换指令，所以申请锁的过程是原子的。
• 在线程释放锁时没有将当前线程al寄存器中的值清0，这不会造成影响，因为每次线程在申请锁时都会先将自己al寄存器中的值清0，再执行交换指令。
• CPU内的所有寄存器并不是被所有的线程共享的，部分寄存器是每个线程都独立拥有的，但内存中的数据是各个线程共享的。申请锁实际就是，把内存中的mutex通过交换指令，原子性的交换到自己的al寄存器中。

可重入VS线程安全

概念

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

注意： 线程安全讨论的是线程执行代码时是否安全，重入讨论的是函数被重入进入。

常见的线程不安全的情况

• 不保护共享变量的函数。

• 函数状态随着被调用，状态发生变化的函数。

• 返回指向静态变量指针的函数。

常见的线程安全的情况

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

• 调用线程不安全函数的函数。

常见的不可重入的情况

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

常见的可重入的情况

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

可重入与线程安全联系

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

可重入与线程安全区别

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

常见锁概念

死锁

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

死锁的四个必要条件

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

注意： 这是死锁的四个必要条件，也就是说只有同时满足了这四个条件才可能产生死锁。

避免死锁

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

满足一个即可。

除此之外，还有一些避免死锁的算法，比如死锁检测算法和银行家算法。

简单来说死锁就是：持有锁并请求其他锁。

死锁的本质：是多个线程因循环等待资源 而永久阻塞。避免死锁的关键是破坏四大条件中的至少一个（尤其是"占有并等待"和"循环等待"）。

用现实例子类比

假设两个程序员（线程）和两把钥匙（锁）：

1. 程序员A拿了钥匙1，想要钥匙2；

2. 程序员B拿了钥匙2，想要钥匙1；

3. 两人都不愿先归还自己的钥匙，导致永久僵持------这就是死锁。

Linux线程同步

在开始之前我们先用一个生活中的小场景模拟一下同步，用于加深一下对线程同步的理解。

你是一名大学生，你经常去你们学校的图书馆，你们学校的图书馆有VIP室，该VIP室单位时间内只能允许一个人进入学习，在里面你不受任何人打扰，并且当没人进入VIP室时，会有一个锁将其锁起来，钥匙就在旁边的挂着。当有人进去的时候，就需要拿钥匙将其打开锁，并需要将钥匙放进自己口袋，将锁在VIP室内锁上。

在周六的一天，你起的特别早，早早的就占到了VIP室，你就在里面学了3个小时，就准备出去休息一下，你就将锁上锁，钥匙挂起来了，此时排在首位的同学就拿着钥匙进入了VIP室，你回来后发现，哎呦，怎么这么多人排队。顿时你就觉得我就出去了十分钟，难不成要等好几个小时才可以进入么？这显得我太吃亏了。

所以第二天你依旧起了一个大早，早早的就占到了VIP室，但这次你学聪明了，你出去的时候不讲钥匙放回，并且把锁锁上了，这样在排队的同学看来你已经拿着锁，无法进入VIP室，然后你休息了10分钟，回来又继续进入VIP室学习。就这样你学了一整天，晚上才回宿舍，对别的同学来说是饥饿的，一天到头都没有进入VIP室。

在这个过程中，周六的我们是出去后，如果还想进入VIP室，是要重新排队的，并且按照常理来说还是排在队尾的。但周日的我们是始终霸占着锁的，别人是无法进入VIP室的。

在上面的场景中与计算机概念的对应关系就是：

图书馆VIP室场景	计算机多线程概念
VIP室	临界区（Critical Section）（共享资源，如全局变量）
钥匙	锁（Lock/Mutex）
学生	线程（Thread）
排队的学生	阻塞（Blocked）的线程
钥匙挂在外面的钩子	锁的可用状态（Unlocked）
学生把钥匙放进自己口袋	获取锁（Lock）
学生离开时带走钥匙	持有锁不释放
学生归还钥匙	释放锁（Unlock）

周六的策略：每次出去都归还钥匙

• 行为：

  • 进入VIP室时拿钥匙（获取锁）。

  • 离开时归还钥匙（释放锁）。

  • 回来时重新排队（可能排到队尾）。

• 对应线程同步问题：

  • 类似于公平锁（Fair Lock），每个线程按顺序获取锁。

  • 问题：如果频繁进出（频繁释放锁），可能导致饥饿（Starvation）（自己很难再抢到锁）。

周日的策略：一直霸占钥匙不归还

• 行为：

  • 进入VIP室时拿钥匙（获取锁）。

  • 离开时不归还钥匙（仍然持有锁）。

  • 回来时直接进入（无需排队）。

• 对应线程同步问题：

  • 类似于自旋锁（Spinlock） 或非公平锁（Non-Fair Lock）：

    • 线程持有锁期间，即使暂时不用，也不释放。

    • 其他线程必须等待（忙等待或阻塞）。

  • 优点：减少锁竞争开销（适合短期临界区）。

  • 缺点：可能导致其他线程饥饿（长时间无法获取锁）。

从上面的案例我们可以更加的理解锁，并且还引出了排队让其以特定顺序去申请锁，其中此就是同步。

同步概念与竞态条件

同步： 在保证数据安全的前提下，让线程能够按照某种特定的顺序访问临界资源，从而有效避免饥饿问题，这就叫做同步。
竞态条件： 因为时序问题，而导致程序异常，我们称之为竞态条件。本质是 多个执行流（线程/进程）对共享资源的访问顺序不确定，导致结果依赖于执行的时序。

• 首先需要明确的是，单纯的加锁是会存在某些问题的，如果个别线程的竞争力特别强，每次都能够申请到锁，但申请到锁之后什么也不做，所以在我们看来这个线程就一直在申请锁和释放锁，这就可能导致其他线程长时间竞争不到锁，引起饥饿问题。
• 单纯的加锁是没有错的，它能够保证在同一时间只有一个线程进入临界区，但它没有高效的让每一个线程使用这份临界资源。

就好比我们在讲互斥的时候对抢票代码的修改，虽然保证了票数不会抢到负数的情况，但是细心的可以发现其运行效果大部分的票是thread_3抢到了，别的线程几乎没有抢到。此时我们就称thread_3的竞争能力大于别的线程。

• 所以我们现在添加一条规则，当一个线程释放锁后不会立刻再次申请锁，而是让该线程必须排到这个锁的资源等待队列的最后。
• 或者说再做一些别的事情。我们首先设定该线程做一些别的事情，后面再让其竞争排队。
• 增加这个规则之后，下一个获取到锁的资源的线程就一定是在资源等待队列首部的线程，如果有十个线程，此时我们就能够让这十个线程按照某种次序进行临界资源的访问。

那么我们就对前面的代码进行修改，让释放锁的线程先做一些别的事情，而不是立刻再次申请锁。

运行起来后，可以发现并不会是仅有一个线程再一直霸占锁，而是按照某种顺序依次申请到锁。注意：我们这里的设定让线程释放锁后做一些别的事情并不会让线程以某种特定的顺序去申请锁，而是让其竞争的申请锁，还是有很大的区别的。

条件变量

条件变量是利用线程间共享的全局变量进行同步的一种机制，条件变量是用来描述某种资源是否就绪的一种数据化描述。

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

条件变量函数

初始化条件变量

初始化条件变量的函数叫做pthread_cond_init，该函数的函数原型如下：

int pthread_cond_init(pthread_cond_t *restrict cond, const pthread_condattr_t *restrict attr);

参数说明：

• cond：需要初始化的条件变量。
• attr：初始化条件变量的属性，一般设置为NULL即可。

返回值说明：

• 条件变量初始化成功返回0，失败返回错误码。

调用pthread_cond_init函数初始化条件变量叫做动态分配，除此之外，我们还可以用下面这种方式初始化条件变量，该方式叫做静态分配：

但这个很少用到，大多还是动态分配。

pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

销毁条件变量

销毁条件变量的函数叫做pthread_cond_destroy，该函数的函数原型如下：

int pthread_cond_destroy(pthread_cond_t *cond);

参数说明：

• cond：需要销毁的条件变量。

返回值说明：

• 条件变量销毁成功返回0，失败返回错误码。

销毁条件变量需要注意：

• 使用PTHREAD_COND_INITIALIZER初始化的条件变量不需要销毁。

等待条件变量满足

等待条件变量满足的函数叫做pthread_cond_wait，该函数的函数原型如下：

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

参数说明：

• cond：需要等待的条件变量。
• mutex：当前线程所处临界区对应的互斥锁。

返回值说明：

• 函数调用成功返回0，失败返回错误码。

唤醒等待

唤醒等待的函数有以下两个：

int pthread_cond_broadcast(pthread_cond_t *cond);
int pthread_cond_signal(pthread_cond_t *cond);

区别：

• pthread_cond_signal函数用于唤醒等待队列中首个线程。
• pthread_cond_broadcast函数用于唤醒等待队列中的全部线程。

参数说明：

• cond：唤醒在cond条件变量下等待的线程。

返回值说明：

• 函数调用成功返回0，失败返回错误码。

使用案例：

同样我们还是对上面的抢票系统进行修改，使其按照特定的顺序依次去申请锁去抢票，并且这个顺序始终不变。

我们设定为：所有线程启动后等待条件变量，主线程按回车广播信号，所有线程被唤醒，竞争锁，获得锁的线程检查票数并处理，票数为0时所有线程退出。

#include <iostream>

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

using namespace std;

int tickets = 100;
pthread_mutex_t mutex;
pthread_cond_t cond;

void *thread_run(void *arg)
{
    const char* name = (char*)arg;
	while (1)
    {
        pthread_mutex_lock(&mutex);
        while(tickets <= 0)  // 使用while而不是if
        {
            pthread_cond_wait(&cond, &mutex);
        }
        
        if (tickets > 0)
        {
            usleep(100000);  // 0.1秒
            printf("[%s] get a ticket, left: %d\n", name, --tickets);
        }
        else
        {
            pthread_mutex_unlock(&mutex);
            break;
        }
        pthread_mutex_unlock(&mutex);
        usleep(3000);
	}
	printf("%s quit!\n", name);
	pthread_exit((void*)0);

}

int main()
{
    pthread_mutex_init(&mutex, NULL);
    pthread_cond_init(&cond, NULL);
    pthread_t tid[5];
    for(int i = 0; i < 5; i++)
    {
        char* buffer = (char*)malloc(64);
        sprintf(buffer, "thread %d", i);
        pthread_create(&tid[i], NULL, thread_run, (void *)buffer);
    }

    while (tickets > 0)
    {
        getchar();
        pthread_cond_broadcast(&cond);
    }

    for(int i = 0; i < 5; i++)
    {
	    pthread_join(tid[i], NULL);
    }

    pthread_mutex_destroy(&mutex);
    pthread_cond_destroy(&cond);
    
    return 0;
}

运行效果如下：

亦或是下面的使用案例：

我们用主线程创建两个新线程，r1线程进入等待状态，r2线程每隔1秒发送一次信号，每次r1收到信号后打印"活动"。

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

using namespace std;

pthread_mutex_t mutex;
pthread_cond_t cond;

void *r1(void *arg)
{
    while (1)
    {
        pthread_cond_wait(&cond, &mutex);
        printf("活动\n");
    }
}

void *r2(void *arg)
{
    while (1) 
    {
        pthread_cond_signal(&cond);
        sleep(1);
    }
}

int main()
{
	pthread_t t1, t2;
	pthread_mutex_init(&mutex, nullptr);
	pthread_cond_init(&cond, nullptr);
	
	pthread_create(&t1, nullptr, r1, (void*)"thread 1");
	pthread_create(&t2, nullptr, r2, (void*)"thread 2");
	

	pthread_mutex_destroy(&mutex);
	pthread_cond_destroy(&cond);
	return 0;
}

为什么pthread_cond_wait需要互斥量

• 条件等待是线程间同步的一种手段，如果只有一个线程，条件不满足，一直等下去都不会满足，所以必须要有一个线程通过某些操作，改变共享变量，使原先不满足的条件变得满足，并且友好的通知等待在条件变量上的线程。
• 条件不会无缘无故的突然变得满足了，必然会牵扯到共享数据的变化，所以一定要用互斥锁来保护，没有互斥锁就无法安全的获取和修改共享数据。

错误的设计

按照上面的说法，我们设计出如下的代码：先上锁，发现条件不满足，解锁，然后等待在条件变量上不就行了，如下代码:

//错误的设计
pthread_mutex_lock(&mutex);
while (condition_is_false){
	pthread_mutex_unlock(&mutex);
	//解锁之后，等待之前，条件可能已经满足，信号已经发出，但是该信号可能被错过
	pthread_cond_wait(&cond);
	pthread_mutex_lock(&mutex);
}
pthread_mutex_unlock(&mutex);

但这是不可行的。

• 由于解锁和等待不是原子操作。调用解锁之后， pthread_cond_wait 之前，如果已经有其他线程获取到互斥量，摒弃条件满足，发送了信号，那么 pthread_cond_wait 将错过这个信号，可能会导致线程永远阻塞在这个 pthread_cond_wait 。所以解锁和等待必须是一个原子操作。
• int pthread_cond_wait(pthread_cond_ t *cond,pthread_mutex_ t * mutex); 进入该函数后，会去看条件量等于0不？等于，就把互斥量变成1，直到cond_ wait返回，把条件量改成1，把互斥量恢复成原样。

所以

• 当线程进入临界区时需要先加锁，然后判断内部资源的情况，若不满足当前线程的执行条件，则需要在该条件变量下进行等待，但此时该线程是拿着锁被挂起的，也就意味着这个锁再也不会被释放了，此时就会发生死锁问题。
• 所以在调用pthread_cond_wait函数时，还需要将对应的互斥锁传入，此时当线程因为某些条件不满足需要在该条件变量下进行等待时，就会自动释放该互斥锁。
• 当该线程被唤醒时，该线程会接着执行临界区内的代码，此时便要求该线程必须立马获得对应的互斥锁，因此当某一个线程被唤醒时，实际会自动获得对应的互斥锁。

条件变量使用规范

等待条件变量的代码

pthread_mutex_lock(&mutex);
while (条件为假)
	pthread_cond_wait(&cond, &mutex);
修改条件
pthread_mutex_unlock(&mutex);

唤醒等待线程的代码

pthread_mutex_lock(&mutex);
设置条件为真
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);