3.1 信号量是什么？#

• 本质：一个 计数器，用来表示临界资源中 资源的数量（有多少份可用资源）。

• 理解信号量：类比电影院售票。

  • 电影院放映厅是一个临界资源。

  • 座位有 100 个 → 信号量初始值为 100。

  • 买票 → 申请信号量（预订一个座位）。

  • 实际含义：信号量是对资源的 预订机制！想访问临界资源中的一小块，必须先申请信号量。

3.2 信号量的核心工作方式#

• 所有进程/线程 在访问临界资源的一小块之前，必须先申请信号量。

• 申请信号量的本质：对资源的预订。

• 信号量的作用：

  • 避免多个执行流访问同一个位置。

  • 控制同时访问资源的执行流数量（避免投入过多）。

3.3 信号量的操作：P/V 操作#

• P 操作（申请资源）：计数器减 1。如果计数器 < 0，则阻塞等待。

• V 操作（释放资源）：计数器加 1。唤醒等待队列中的线程。

• 原子性要求：信号量本身也是共享资源，所以 P/V 操作必须原子完成。

3.4 二元信号量与互斥#

• 二元信号量：信号量的值只有 0 或 1。

• 二元信号量就是 互斥锁！用于实现互斥。

3.5 信号量的内部结构#

1
struct sem {
2
    int count;                 // 计数器
3
    struct task_struct *waitqueue;  // 等待队列
4
    // 还有用于保护自身的锁（原子操作）
5
};

3.6 多元信号量#

4.1 无锁版本#

1
int ticket = 1000;
2

3
void *route(void *arg) {
4
    char *id = (char *)arg;
5
    while (1) {
6
        if (ticket > 0) {          // 1. 判断
7
            usleep(1000);          // 模拟抢票耗时
8
            printf("%s sells ticket:%d\n", id, ticket); // 2. 输出
9
            ticket--;              // 3. 票数减1
10
        } else {
11
            break;
12
        }
13
    }
14
    return nullptr;
15
}

现象：可能出现负数票（如 sells ticket: -1, -2）。

原因分析：

• ticket-- 不是原子操作。C语言的一条语句，编译成汇编通常是三条指令：

1
0xFF00: mov  ebx, [ticket]   ; 载入内存到寄存器
2
0xFF02: dec  ebx             ; 减少1
3
0xFF04: mov  [ticket], ebx   ; 写回内存

• 线程切换可能发生在任意一条汇编指令之间。

• 例如：

  • 线程A：载入 ticket=100 → 计算得99 → 还未写回时被切走。

  • 线程B：载入 ticket=100 → 计算得99 → 写回 ticket=99。

  • 线程A恢复：写回 ticket=99（覆盖了B的结果，但只减了一次，实际应减两次）。

  • 最终可能导致 ticket 减成负数（判断时 >0，但多个线程同时通过判断后各自减，造成超卖）。

结论：多线程并发访问共享变量，若操作非原子，则数据不一致。

4.2 加锁版本#

1
int ticket = 10000;
2
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;   // 全局静态初始化
3

4
void *route(void *arg) {
5
    char *id = (char *)arg;
6
    while (1) {
7
        pthread_mutex_lock(&lock);    // 加锁
8
        if (ticket > 0) {
9
            usleep(1000);
10
            printf("%s sells ticket:%d\n", id, ticket);
11
            ticket--;
12
            pthread_mutex_unlock(&lock); // 解锁
13
        } else {
14
            pthread_mutex_unlock(&lock);
15
            break;
16
        }
17
    }
18
    return nullptr;
19
}

效果：同一时刻只有一个线程能进入临界区，保证 ticket 操作的正确性。

5.1 基本接口#

1
#include <pthread.h>
2

3
int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *attr);
4
int pthread_mutex_destroy(pthread_mutex_t *mutex);
5
int pthread_mutex_lock(pthread_mutex_t *mutex);       // 阻塞加锁
6
int pthread_mutex_trylock(pthread_mutex_t *mutex);    // 非阻塞加锁
7
int pthread_mutex_unlock(pthread_mutex_t *mutex);

5.2 静态初始化#

1
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
2
// 不需要手动 destroy，程序结束自动释放

5.3 锁的本质#

• 锁本身也是临界资源（所有线程都能看到它）。

• 申请锁的过程必须是原子的（因为多个线程同时竞争锁）。

• 成功申请到锁的线程继续运行，访问临界区。

• 失败的线程：阻塞挂起，等待锁释放。

5.4 锁提供的能力#

• 将 临界区代码的执行从并行变为串行。

• 持有锁的线程在执行临界区期间，即使被切换走（时间片到、IO等），其他线程也无法进入临界区，因为锁还未释放。

• 对于其他线程来说，临界区的执行是 原子的（要么没开始，要么已完全结束）。

5.5 锁的底层原理（软件实现）#

硬件基础：大多数体系结构提供 swap 或 exchange 指令，可以原子地交换寄存器和内存单元的数据。

伪代码实现：

1
// 锁变量 mutex，1 表示未锁，0 表示已锁
2
lock:
3
    movb $0, %al
4
    xchgb %al, mutex      // 原子交换：al <-> mutex
5
    if (al寄存器的内容 > 0) {
6
        return 0;         // 成功获得锁
7
    } else {
8
        挂起等待;
9
        goto lock;
10
    }
11

12
unlock:
13
    movb $1, mutex        // 释放锁
14
    唤醒等待 mutex 的线程;
15
    return 0;

理解：

• 每个线程有自己的寄存器上下文（私有）。

• xchg 交换时，内存 mutex 的值被交换到线程的 %al 寄存器中。

• 如果 mutex 原值为 1（未锁），交换后 mutex 变为 0，%al 得到 1，表示获得锁。

• 如果 mutex 原值为 0（已锁），交换后 %al 为 0，表示锁被他人持有。

• 因为交换是原子的，所以不会有两个线程同时得到锁。

5.6 硬件级实现#

• 更底层：关闭时钟中断 → 单条指令执行期间不会被中断，保证了原子性。

5.7 如果有一个线程不遵守加锁规则会怎样？#

• 后果：它可以直接访问临界资源而不加锁，导致数据不一致。

• 结论：所有线程必须遵守同一套加锁/解锁规则，否则保护无效。

5.8 加锁之后，在临界区内部允许线程切换吗？切换了会怎么样？#

• 允许切换。

• 切换了不会出问题：因为当前线程 持有锁 被切换走，锁没有被释放。其他线程在申请锁时会失败（阻塞），无法进入临界区。

• 直到持有锁的线程恢复执行，完成临界区代码并解锁，其他线程才能竞争锁。

• 对外部观察者：临界区的执行是 原子的（要么完全没执行，要么执行完毕）。

5.9 锁的粒度与性能#

• 加锁粒度太大：临界区包含大量非必要代码，并发性能下降（串行化过多）。

• 加锁粒度太小：临界区没有完整保护共享资源，可能出现数据不一致。

• 正确做法：只保护对临界资源访问的最小必要代码段。

5.10 进程间的互斥#

• 共享内存（shm） 可实现进程间共享数据。

• 若需进程间互斥，可将 pthread_mutex_t 放在共享内存中，并设置进程共享属性。

• 锁的语义与线程间互斥一致。

1
// 伪代码示例
2
pthread_mutex_t *mutex = (pthread_mutex_t *)shmat(...);
3
pthread_mutexattr_t attr;
4
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
5
pthread_mutex_init(mutex, &attr);

5.11 数据不一致问题的根源总结#

解决根本手段：将临界区代码串行化（加锁），保证操作的原子性。

6.1 纯互斥的问题#

回顾之前的“超级自习室”例子（互斥锁）：

• 一个人进入自习室（获得锁），出来（释放锁）。

• 但可能出现 高频申请钥匙却不做有效动作 的情况：

  • 某线程：申请锁 → 检查条件不满足 → 立即释放锁 → 立刻又申请锁 → 循环。

• 导致 其他人得不到钥匙（锁） → 其他线程饥饿问题。

6.2 互斥没错，但不高效、不公平#

• 纯互斥 在功能上没错，能保证数据安全。

• 但存在两个问题：

  1. 不高效：线程可能频繁申请/释放锁，却没有实际工作。

  2. 不公平：某些线程可能长时间无法获得锁（饥饿）。

6.3 改进思路（管理员规则）#

在保证自习室安全的前提下，让所有执行流 按照一定的顺序访问临界资源。

• 规则示例：

  • 不能立即申请第二次（退出的人必须排队到队尾）。

  • 外部线程排队，释放锁的人自动排到队列尾部。

这就是线程同步的雏形：让线程有序访问临界资源，避免饥饿。

7.1 为什么需要条件变量？#

• 当一个线程互斥地访问某个变量时，它可能发现：在其它线程改变状态之前，它什么也做不了。

• 例如：线程访问一个队列，发现队列为空 → 它只能等待，直到其它线程添加一个节点到队列中。

• 条件变量 就是用来解决这种“等待某个条件成立”的场景。

7.2 同步概念与竞态条件#

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

• 竞态条件：多个线程并发访问共享数据，最终结果依赖于线程执行的时序（通常是不期望的结果）。

7.3 条件变量的直观理解#

• 放苹果的人：生产者，往篮子里放苹果。

• 队列：存放苹果的篮子（临界资源）。

• 条件变量：用于通知“篮子不空”或“篮子不满”的信号机制。

8.1 初始化和销毁#

1
#include <pthread.h>
2

3
int pthread_cond_destroy(pthread_cond_t *cond);
4
int pthread_cond_init(pthread_cond_t *restrict cond,
5
                      const pthread_condattr_t *restrict attr);
6

7
// 静态初始化（全局或static变量）
8
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;

8.2 等待条件变量#

1
int pthread_cond_wait(pthread_cond_t *restrict cond,
2
                      pthread_mutex_t *restrict mutex);
3
int pthread_cond_timedwait(pthread_cond_t *restrict cond,
4
                           pthread_mutex_t *restrict mutex,
5
                           const struct timespec *restrict abstime);

理解：

• pthread_cond_wait 必须在持有锁的情况下调用。

• 调用时，它会 原子性地 做两件事：

  1. 释放锁（让其他线程可以修改条件）。

  2. 阻塞等待条件变量。

• 当被唤醒后，它会 重新获取锁，然后返回。

• 为什么必须传入互斥锁？ 因为条件判断（如 queue == empty）本身就是访问临界资源，必须在锁保护下进行。如果条件不满足，线程需要休眠，但休眠前必须释放锁，否则会死锁。pthread_cond_wait 将这个“释放锁+休眠”操作做成原子的。

8.3 唤醒条件变量#

1
int pthread_cond_signal(pthread_cond_t *cond);   // 唤醒一个等待线程
2
int pthread_cond_broadcast(pthread_cond_t *cond); // 唤醒所有等待线程

• signal：至少唤醒一个（通常是一个）等待该条件的线程。

• broadcast：唤醒所有等待线程。

8.4 典型使用模式#

1
// 等待线程
2
pthread_mutex_lock(&mutex);
3
while (condition_is_false) {        // 用 while，不是 if（防止虚假唤醒）
4
    pthread_cond_wait(&cond, &mutex);
5
}
6
// 条件满足，执行操作
7
pthread_mutex_unlock(&mutex);
8

9
// 唤醒线程（修改条件后）
10
pthread_mutex_lock(&mutex);
11
// 修改条件（如添加数据）
12
condition_is_true = 1;
13
pthread_cond_signal(&cond);         // 唤醒等待者
14
pthread_mutex_unlock(&mutex);

9.1 模型描述#

经典的多线程通信模型。

• 生产者：生成数据的线程（如工厂生产商品）。

• 消费者：处理数据的线程（如用户消费商品）。

• 交易场所：存放数据的缓冲区（如超市、队列、内存空间）。

9.2 “321”原则（快速记忆）#

9.3 三种关系说明#

• 生产者 vs 生产者：互斥关系。多个生产者不能同时向交易场所放入数据（会冲突）。

• 消费者 vs 消费者：互斥关系。多个消费者不能同时从交易场所取出数据（会冲突）。

• 生产者 vs 消费者：

  • 互斥：不能同时访问交易场所（如放入和取出同时发生会混乱）。

  • 同步：当交易场所为空时，消费者必须等待生产者；当交易场所满时，生产者必须等待消费者。

9.4 为什么需要生产者消费者模型？好处#

效率提升的本质：生产者线程生产数据（如从网络接收、计算）和消费者线程处理数据（如写入磁盘、发送）可以 并发执行，而交易场所只是临时中转。

10.1 阻塞队列定义#

一种常用于实现生产者消费者模型的数据结构。

• 普通队列 + 容量上限。

• 当队列空：消费者线程从队列取元素会被阻塞，直到有元素放入。

• 当队列满：生产者线程往队列放元素会被阻塞，直到有元素被取出。

• 操作基于不同线程，阻塞是线程调度层面的。

10.2 为什么等待必须在临界区内进行？#

理解：

等待是需要等，什么条件才会等呢？票数为0，等待之前，就要对资源的数量进行判定。 判定本身就是访问临界资源！判断一定是在临界区内部的。当前线程是持有锁的！ 判定结果，也一定在临界资源内部。所以，条件不满足要休眠，一定是在临界区内休眠的！

• 条件变量的 wait 操作 必须在锁的保护下调用。

• 因为条件判断（如 queue->size == 0）本身就是对临界资源的访问。

• 如果不在临界区内休眠，就会出现：判断完条件后、休眠前，条件被其他线程改变，导致永远休眠（丢失唤醒）。

10.3 阻塞队列伪代码（单生产者单消费者）#

1
// 交易场所：阻塞队列
2
typedef struct {
3
    int *buffer;
4
    int capacity;
5
    int front, rear, count;
6
    pthread_mutex_t mutex;
7
    pthread_cond_t not_full;   // 条件：队列不满
8
    pthread_cond_t not_empty;  // 条件：队列不空
9
} block_queue_t;
10

11
// 生产者：放入数据
12
void enqueue(block_queue_t *q, int data) {
13
    pthread_mutex_lock(&q->mutex);
14
    while (q->count == q->capacity) {      // 队列满，等待
15
        pthread_cond_wait(&q->not_full, &q->mutex);
16
    }
17
    // 放入数据
18
    q->buffer[q->rear] = data;
19
    q->rear = (q->rear + 1) % q->capacity;
20
    q->count++;
21
    pthread_cond_signal(&q->not_empty);    // 唤醒等待的消费者
22
    pthread_mutex_unlock(&q->mutex);
23
}
24

25
// 消费者：取出数据
26
int dequeue(block_queue_t *q) {
27
    pthread_mutex_lock(&q->mutex);
28
    while (q->count == 0) {                // 队列空，等待
29
        pthread_cond_wait(&q->not_empty, &q->mutex);
30
    }
31
    // 取出数据
32
    int data = q->buffer[q->front];
33
    q->front = (q->front + 1) % q->capacity;
34
    q->count--;
35
    pthread_cond_signal(&q->not_full);     // 唤醒等待的生产者
36
    pthread_mutex_unlock(&q->mutex);
37
    return data;
38
}

10.4 用 while 不用 if？#

• 虚假唤醒：条件变量可能在没有被 signal/broadcast 的情况下醒来（某些实现或信号导致）。

• 使用 while 可以重新检查条件，确保条件真正满足。