操作系统同步问题实战：小和尚打水与老和尚喝水的信号量解法

1. 从"小和尚打水"说起：这个同步问题到底在讲什么

第一次看到"小和尚打水、老和尚喝水"这个题目的时候，我脑子里第一反应是：这不就是个生产者-消费者模型换了个马甲吗？但真正动手写代码的时候才发现，这个场景比教科书上那个"缓冲区放数据"的例子要刁钻得多——它把容量约束、互斥访问、同步唤醒三件事揉在了一个故事里，而且加了一个"老和尚一次要喝三桶水"的设定，直接把问题复杂度拉高了一个档次。

先把场景翻译成人话。有一口井，井边最多只能站三个人同时打水（井的容量限制）；有一个水缸，水缸最多能装十桶水（缓冲区容量）；小和尚负责从井里打水倒进水缸，老和尚负责从水缸里舀水喝。小和尚打水的时候，井边人数有限制；往水缸倒水的时候，水缸不能满；老和尚喝水的时候，水缸不能空。更麻烦的是，老和尚喝水不是一桶一桶喝，而是一次要喝三桶——这就意味着老和尚取水这个动作本身需要满足"水缸里至少有三桶水"的条件。

这个问题的核心考点其实就三个：信号量的正确设置、P/V操作的顺序、以及多条件等待时的逻辑处理。我见过太多人（包括我自己第一次写的时候）栽在P操作顺序上，导致死锁；也见过有人把"老和尚喝三桶水"简单处理成循环三次P操作，结果出现老和尚喝到一半水不够了的尴尬局面。

这篇文章适合谁看？如果你正在学操作系统、正在被信号量PV操作折磨、或者面试前想快速复习经典同步问题，那这篇应该能帮到你。我会把整个解题过程从"读题"到"写出能跑的代码"完整拆一遍，包括我踩过的坑和调试时的一些小技巧。代码用C语言加POSIX信号量和线程来实现，因为这是最贴近实际、也最容易验证的方式。

2. 问题拆解与方案选型：为什么这么设计

2.1 场景中的角色与资源梳理

在动手写代码之前，我习惯先把场景里的"角色"和"资源"列清楚。这个习惯是从一次面试失败后养成的——当时面试官问我"你这个信号量是保护什么的"，我支支吾吾答不上来，因为写代码的时候根本没想清楚。

角色有三个：小和尚（生产者）、老和尚（消费者）、井和水缸（共享资源）。但仔细想想，井和水缸其实是两种不同性质的资源。井是"打水的地方"，同一时刻井边能站的人数有限；水缸是"存水的地方"，它的容量有限。这两个限制是独立的，不能混为一谈。

资源约束有四条：

• 井边最多站3个人（井的并发限制）
• 水缸最多装10桶水（缓冲区容量）
• 老和尚一次要喝3桶水（消费批量约束）
• 水缸的读写必须互斥（同一时刻不能又倒又舀）

把这四条理清楚之后，信号量的数量基本就确定了。我一开始想用两个信号量搞定，后来发现不行——井的限制和水缸的限制必须分开，否则会出现"小和尚在井边等着，但水缸已经满了"这种资源浪费的情况。

2.2 信号量方案的设计思路

信号量的选择上，我最终确定了五个：

前四个是经典生产者-消费者模型的标准配置，第五个是我为了解决"老和尚一次喝三桶"这个问题额外加的。为什么这么设计？因为如果老和尚直接用P(full)三次，会出现一个问题：假设水缸里现在有2桶水，老和尚P了两次之后发现不够第三桶，这时候他已经"占用"了两桶水的计数，但实际还没喝，其他小和尚看到full减少了可能会误判。用drink_ready这个信号量，语义就清晰多了——它表示的是"够喝一轮了"，而不是"有一桶水"。

这里有个设计上的取舍：你也可以用条件变量来实现"等够三桶再喝"，但条件变量需要配合互斥锁使用，代码会更复杂。用信号量的话，逻辑更直观，但需要额外维护一个计数器来跟踪当前水缸里的水量。我选信号量是因为它更符合这个题目的"教学"定位。

2.3 为什么不用管程或者条件变量

有人可能会问：为什么不用管程（Monitor）或者条件变量？这两种方案不是更现代吗？

确实，管程和条件变量在某些场景下更优雅，但在这个问题里，信号量的优势在于语义直接。P(empty)就是"等一个空位"，V(full)就是"多了一桶水"，这种一一对应的关系让代码的可读性很高。而且这个题目本身就是操作系统课程里讲信号量的经典案例，用信号量实现是最"正统"的解法。

条件变量的问题在于，它需要配合一个while循环来检查条件，而且唤醒的时候可能被虚假唤醒（spurious wakeup），需要额外的逻辑处理。对于初学者来说，信号量的P/V操作更容易理解，也更不容易出错。

3. 核心细节解析：P/V操作的顺序为什么这么重要

3.1 小和尚的P操作顺序：先井后缸

小和尚的流程是这样的：先到井边打水，然后往水缸里倒。对应的P操作顺序是：

P(well_sem); // 先申请井边的位置 打水; P(empty); // 再申请水缸的空位 P(mutex); // 互斥访问水缸 倒水; V(mutex); V(full); // 通知水缸多了一桶水 V(well_sem); // 释放井边的位置

这个顺序不能乱。如果先P(empty)再P(well_sem)，会出现什么情况？假设水缸满了（empty=0），小和尚会阻塞在P(empty)上，但他此时还占着井边的位置。如果所有小和尚都这样，井边就被占满了，但水缸还是满的，谁也动不了——这就是死锁。

我一开始就是栽在这个顺序上。当时觉得"先申请哪个不一样吗"，结果跑起来之后程序直接卡死，调试了半天才发现是P操作顺序的问题。这个坑很经典，面试的时候也经常被问到。

3.2 老和尚的P操作：先等够三桶再喝

老和尚的流程稍微复杂一点，因为他要一次喝三桶。我的实现是这样的：

P(drink_ready); // 等待够喝一轮的信号 P(mutex); // 互斥访问水缸 喝三桶水; V(mutex); V(empty); // 通知水缸空出了三个位置

这里的关键是drink_ready信号量的维护。小和尚每倒一桶水，full加1，同时检查full是否达到了3的倍数。如果是，就V(drink_ready)通知老和尚可以喝了。这个检查逻辑需要放在互斥区里，否则会出现竞态条件。

注意：drink_ready的初值是0，意味着老和尚一开始必须等小和尚倒够三桶水才能开始喝。这符合题目的设定——水缸一开始是空的。

3.3 互斥锁的粒度：保护什么，不保护什么

mutex这个互斥信号量保护的是水缸的读写操作，具体来说就是"倒水"和"喝水"这两个动作。但打水这个动作不需要保护，因为井边的人数已经由well_sem控制了。

这里有个容易犯的错误：把mutex的粒度设得太粗，比如把整个"打水+倒水"都包在互斥区里。这样做虽然不会出错，但会严重降低并发性能——小和尚在井边打水的时候，其他小和尚就不能倒水了，这显然不合理。

正确的做法是：mutex只保护水缸的访问，也就是P(mutex)和V(mutex)之间的代码只包含倒水或喝水的操作。打水的过程在互斥区外面，这样多个小和尚可以同时打水，只有倒水的时候才需要排队。

4. 完整代码实现与逐段解析

4.1 环境准备与头文件

我用的是Linux环境下的POSIX线程和信号量，需要包含以下头文件：

#include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <semaphore.h> #include <unistd.h> #include <time.h>

编译的时候需要链接pthread库：

gcc -o monk_water monk_water.c -lpthread

如果你用的是macOS，POSIX信号量的支持可能不太完整，建议在Linux环境下测试。Windows的话可以用WSL或者MinGW，但信号量的行为可能略有差异。

4.2 全局变量与信号量定义

#define WELL_CAPACITY 3 // 井边最多站3个人 #define JAR_CAPACITY 10 // 水缸最多装10桶水 #define DRINK_BATCH 3 // 老和尚一次喝3桶 sem_t well_sem; // 井边人数控制 sem_t empty; // 水缸空位 sem_t full; // 水缸已有水量 sem_t mutex; // 水缸互斥锁 sem_t drink_ready; // 可以喝水的信号 int jar_water = 0; // 当前水缸中的水量（用于调试和判断） pthread_mutex_t print_mutex; // 打印互斥，避免输出混乱

jar_water这个变量不是必须的，但加上它方便调试和打印状态。注意它的读写必须在mutex的保护下进行，否则会出现数据不一致。

4.3 小和尚线程函数

void* young_monk(void* arg) { int id = *(int*)arg; while (1) { // 模拟走到井边的时间 usleep(rand() % 1000000); P(well_sem); pthread_mutex_lock(&print_mutex); printf("小和尚%d：开始打水（井边人数：%d）\n", id, 3 - get_sem_value(&well_sem)); pthread_mutex_unlock(&print_mutex); // 模拟打水时间 usleep(rand() % 500000); P(empty); P(mutex); jar_water++; pthread_mutex_lock(&print_mutex); printf("小和尚%d：倒水，水缸当前水量：%d\n", id, jar_water); pthread_mutex_unlock(&print_mutex); // 检查是否够老和尚喝一轮 if (jar_water >= DRINK_BATCH && jar_water % DRINK_BATCH == 0) { V(drink_ready); } V(mutex); V(full); V(well_sem); // 模拟休息时间 usleep(rand() % 800000); } return NULL; }

这里有个细节：jar_water % DRINK_BATCH == 0这个判断。为什么不用jar_water == DRINK_BATCH？因为水缸可能被喝掉一部分之后又倒满，jar_water的值是动态变化的。用取模的方式可以确保每满三桶就通知一次。

但这里其实有个隐患：如果老和尚喝水的速度比小和尚倒水的速度快，jar_water可能会在3、6、9之间跳动，取模判断是没问题的。但如果出现jar_water从2直接跳到4的情况（比如两个小和尚几乎同时倒水），取模判断可能会漏掉一次通知。不过在这个场景下，mutex保证了倒水操作的原子性，所以jar_water每次只会加1，不会出现跳变。

4.4 老和尚线程函数

void* old_monk(void* arg) { int id = *(int*)arg; while (1) { P(drink_ready); P(mutex); pthread_mutex_lock(&print_mutex); printf("老和尚%d：开始喝水，水缸当前水量：%d\n", id, jar_water); pthread_mutex_unlock(&print_mutex); // 模拟喝水时间 usleep(rand() % 1500000); jar_water -= DRINK_BATCH; pthread_mutex_lock(&print_mutex); printf("老和尚%d：喝完水，水缸剩余水量：%d\n", id, jar_water); pthread_mutex_unlock(&print_mutex); V(mutex); // 释放三个空位 for (int i = 0; i < DRINK_BATCH; i++) { V(empty); } } return NULL; }

老和尚的代码里，V(empty)执行了三次，因为一次喝水释放了三个空位。这里也可以用循环，但直接写三次更直观。

注意：V(empty)必须在V(mutex)之后执行。如果先V(empty)再V(mutex)，可能会出现小和尚在水缸还没完全更新状态的时候就往里倒水，导致数据不一致。

4.5 主函数与线程创建

int main() { srand(time(NULL)); // 初始化信号量 sem_init(&well_sem, 0, WELL_CAPACITY); sem_init(&empty, 0, JAR_CAPACITY); sem_init(&full, 0, 0); sem_init(&mutex, 0, 1); sem_init(&drink_ready, 0, 0); pthread_mutex_init(&print_mutex, NULL); pthread_t young[5], old[2]; int young_ids[5] = {1, 2, 3, 4, 5}; int old_ids[2] = {1, 2}; // 创建小和尚线程 for (int i = 0; i < 5; i++) { pthread_create(&young[i], NULL, young_monk, &young_ids[i]); } // 创建老和尚线程 for (int i = 0; i < 2; i++) { pthread_create(&old[i], NULL, old_monk, &old_ids[i]); } // 等待线程结束（实际上不会结束，因为是死循环） for (int i = 0; i < 5; i++) { pthread_join(young[i], NULL); } for (int i = 0; i < 2; i++) { pthread_join(old[i], NULL); } // 清理资源 sem_destroy(&well_sem); sem_destroy(&empty); sem_destroy(&full); sem_destroy(&mutex); sem_destroy(&drink_ready); pthread_mutex_destroy(&print_mutex); return 0; }

主函数里创建了5个小和尚和2个老和尚。为什么是5和2？其实这个数量可以调整，但要注意：小和尚太多会导致井边排队严重，老和尚太多会导致水缸经常空。我试过3个小和尚和1个老和尚，运行很流畅；也试过10个小和尚和5个老和尚，输出会非常密集，但逻辑上没问题。

5. 调试过程中踩过的坑与排查技巧

5.1 死锁问题：P操作顺序错误

这是我遇到的第一个坑。最初的代码里，我把小和尚的P操作写成了：

P(empty); P(well_sem);

结果程序跑了几秒钟就卡死了。用gdb调试发现，所有小和尚都阻塞在P(empty)上，而empty的值是0，说明水缸满了。但水缸满了应该老和尚来喝啊？再看老和尚的线程，发现老和尚阻塞在P(drink_ready)上，而drink_ready的值是0，说明还没有够三桶水。

问题出在哪里？水缸满了（10桶），但drink_ready没有被触发，因为jar_water是10，10%3不等于0。也就是说，水缸里有10桶水，但老和尚需要3桶才能喝，而10桶水只能触发3次喝水（9桶），剩下1桶不够。这时候小和尚因为empty=0无法继续倒水，老和尚因为drink_ready=0无法喝水，双方僵持，死锁。

这个问题的根源在于：水缸容量10不是3的倍数。如果水缸容量是9或者12，就不会出现这个问题。但题目设定就是10，所以必须处理这个"余数"问题。

我的解决方案是：修改drink_ready的触发条件，不要求jar_water是3的倍数，而是要求jar_water >= 3。这样即使水缸里有10桶水，老和尚也可以喝三次（9桶），剩下1桶留着。修改后的代码：

if (jar_water >= DRINK_BATCH) { V(drink_ready); }

但这样又带来一个新问题：如果水缸里有4桶水，老和尚喝了一次之后剩1桶，这时候jar_water=1，不满足>=3，老和尚不会再喝。但小和尚继续倒水，倒到3桶的时候又会触发一次drink_ready。逻辑上是通的。

不过这里有个细节：V(drink_ready)可能会被多次执行。比如水缸里有6桶水，小和尚倒第4桶的时候触发一次，倒第5桶的时候又触发一次，倒第6桶的时候再触发一次。这样drink_ready的值会变成3，老和尚可以连续喝三次。这其实是对的——因为水缸里确实有6桶水，够喝两轮。但要注意，老和尚每次喝之前都要P(mutex)，所以不会出现两个老和尚同时喝水的情况。

5.2 输出混乱：打印互斥的必要性

第二个坑是输出混乱。多个线程同时printf的时候，输出会交织在一起，比如"小和尚1：开小和尚2：开始打水始打水"，完全看不清。解决办法是加一个print_mutex，在每次printf前后加锁解锁。

这个坑虽然小，但很影响调试体验。我建议一开始就把print_mutex加上，不要等到输出乱成一团再回头改。

5.3 信号量值的获取：POSIX没有直接接口

调试的时候我想打印信号量的当前值，发现POSIX的sem_t没有直接获取值的接口。sem_getvalue在某些平台上可用，但不是标准接口。我的做法是自己维护一个计数器，或者用sem_getvalue（Linux下可用）。

int get_sem_value(sem_t* sem) { int val; sem_getvalue(sem, &val); return val; }

注意：sem_getvalue返回的值在并发环境下可能不准确，因为获取值的瞬间可能被其他线程修改。所以它只适合调试，不适合用于逻辑判断。

5.4 常见问题速查表

6. 进一步优化与扩展思路

6.1 用条件变量重写

如果你想练习条件变量，可以把drink_ready换成条件变量：

pthread_cond_t drink_cond; pthread_mutex_t drink_mutex; int ready_count = 0; // 小和尚倒水后 pthread_mutex_lock(&drink_mutex); if (jar_water >= DRINK_BATCH) { pthread_cond_signal(&drink_cond); } pthread_mutex_unlock(&drink_mutex); // 老和尚等待 pthread_mutex_lock(&drink_mutex); while (jar_water < DRINK_BATCH) { pthread_cond_wait(&drink_cond, &drink_mutex); } pthread_mutex_unlock(&drink_mutex);

条件变量的好处是可以精确控制唤醒条件，但代码量会多一些。两种方案各有优劣，建议都实现一遍，加深理解。

6.2 增加优先级或公平性

当前的实现里，小和尚和老和尚的调度是随机的，可能会出现某个小和尚一直抢不到井边位置的情况。如果要实现公平调度，可以用信号量队列或者自己维护一个等待队列。不过对于这个题目来说，公平性不是核心考点，了解即可。

6.3 可视化运行状态

如果想更直观地看到水缸水量的变化，可以把每次倒水和喝水的操作记录到日志文件里，然后用脚本画成折线图。我用Python的matplotlib画过一次，能很清楚地看到水缸水量在0到10之间波动，老和尚喝水的时候会出现阶梯式下降。

这个扩展不是必须的，但对于理解同步问题的动态行为很有帮助。特别是当你调整小和尚和老和尚的数量比例时，水量曲线的形态会明显变化。

6.4 参数调优的实测数据

我做了几组对比实验，记录如下：

从数据可以看出，水缸容量和小和尚/老和尚的数量比例需要匹配。容量太小会导致小和尚等待，容量太大会导致老和尚等待。一般来说，容量设置在DRINK_BATCH * 2到DRINK_BATCH * 4之间比较合适。

7. 一些个人体会

这个题目我前前后后写了三遍。第一遍是照着课本的生产者-消费者模型改的，结果死锁；第二遍修正了P操作顺序，但没处理好"喝三桶"的逻辑，老和尚经常喝到一半没水了；第三遍才把drink_ready信号量加进去，终于跑通了。

最大的体会是：同步问题的难点不在于写出代码，而在于想清楚每个信号量到底代表什么。empty代表空位，full代表水量，drink_ready代表"够喝一轮"，每个信号量的语义必须清晰，否则代码写出来自己都看不懂。

另外，调试同步问题的时候，日志比断点好用。因为断点会暂停所有线程，破坏并发场景，而日志可以记录下线程的实际执行顺序。我习惯在每次P/V操作前后都加日志，虽然输出多，但排查问题的时候非常有用。

最后分享一个小技巧：如果你不确定P操作顺序对不对，可以画一个资源依赖图。把每个线程需要的资源画成节点，箭头表示"必须先获得A才能获得B"。如果图中有环，就说明有死锁风险。这个方法帮我省了很多调试时间。