一、信号量的缺点
信号量的使用一定要小心，如下图中解决生产者-消费者问题的程序：
如果在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等价，但他们并不受竞争条件约束，而是通过异常机制实现对中断情况的处理