一、信号量的缺点

信号量的使用一定要小心，如下图中解决生产者-消费者问题的程序：

如果在producer的执行函数中，将empty与mutex的down操作互换，如果此时mutex为0，将首先对mutex进行down操作，进程陷入阻塞，而同时，当consumer的执行函数执行到down(&mutex)的时候，由于mutex为0，因此，consumer线程也将进入阻塞，两个进程都将永远进入阻塞状态，这被称为“死锁”

这说明使用信号量时一定要非常小心，一处很小的错误将有可能导致很大的麻烦，因为竞争条件、死锁以及其他一些问题都是不可预测和不可再现的行为

为了更易于编写正确的程序，一种高级同步原语 -- 管程(monitor)诞生了

二、管程

一个管程是一个由过程、变量及数据结构等组成的一个集合，它们组成一个特殊的模块或软件包。

管程内部的共享变量

管程内部的条件变量

管程内部并行执行的进程

对局部于管程内部的共享数据设置初始值的语句

进程可以在任何需要的时候调用管程中的过程，但是他们不能在管程之外声明的过程中直接访问管程内的数据结构

但是，需要注意的是管程是语言概念，而C语言并不支持它

任意时刻，管程中只能有一个活跃的进程，这一特性是的管程能够有效地完成互斥，由编译器选择采取与其他过程调用不同的方法来处理对管程的调用

典型的处理方法是，当一个进程调用管程过程时，该过程中的前几条指令将检查在管程中是否有其他的活跃进程，如果有，调用进程将被挂起，知道另一个进程离开管程将其唤醒，如果没有，则该调用进程可以进入

进入管程时的互斥由编译器负责，但通常的做法是用一个互斥量或二元信号量，因为是有编译器而非程序员来安排互斥，所以出错的可能性要小得多

在任何一个时刻，写管程的人无需关心编译器是如何实现互斥的，他只需要知道将所有的临界区转换成管程过程即可，绝不会有两个进程同时执行临界区中的代码。

三、管程中的条件变量

管程提供了一种实现互斥的渐变途径，但是我们还需要一种办法使得进程在无法继续运行时被阻塞，解决这个问题的方法就是引入条件变量，以及相关的两个操作：wait和signal，当一个管程过程发现他无法继续运行时(如生产者发现缓冲区已满)，他会在某个条件变量上(如full)上执行wait操作，该操作导致调用进程自身阻塞，并将另一个等在管程外的进程调入管程，同时，一个进程也可以通过对伙伴正在等待的一个条件变量执行signal操作完成唤醒正在睡眠的伙伴进程，但是这个时候就有可能会出现两个活跃进程同时处在管程中的情况，这个情况有两种方案可以解决：

运行新唤醒的进程，挂起之前的进程

执行signal的进程立即退出管程，即规定signal只能作为管程过程的最后一条语句

让发信者继续运行直到发信者退出管程后才让被唤醒的进程运行

很明显，第一种方案更加简单，所以一般我们采取这一方案

注意，条件变量与信号量不同，他并不是计数器，如果向一个条件变量发送信号，而这个条件变量上此时并没有等待进程，则这个信号就会丢失，也就是说wait必须在signal之前执行

wait、signal与sleep、wakeup最大的区别是他们不存在严重的竞争条件，因为可能存在一种情况，即当一个进程正要去sleep而实际还没有sleep的时候，另一个进程企图唤醒他，从而造成了wakeup信号的丢失，而管程中不会存在这样的问题，因为在缓冲区满，生产者wait前，消费者进程根本不可能进入管程

四、代码示例

如图所示，是用管程实现生产者-消费者问题揭发框架的一个类似于pascal的伪代码

java支持用户级进程，只要将关键词synchronized加入到方法声明中，java就保证这个方法一旦被某个进程执行，就不允许其他进程执行它，因此我们可以通过这一特性实现管程的编程

这个例子其实并不难懂，由于有synchronized关键字，所以无论是producer要进行的insert方法还是consumer要进行的remove方法都只能让一个进程进入，因此他们不需要再担心竞争条件

java中并没有条件变量，反之，java提供了两个过程：wait和notify，与sleep和wakeup等价，但他们并不受竞争条件约束，而是通过异常机制实现对中断情况的处理