各种同步机制的分析比较---摘抄 留给本人自己看

管程

一、信号量的缺点

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

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

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

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

二、管程

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

1. 管程内部的共享变量
2. 管程内部的条件变量
3. 管程内部并行执行的进程
4. 对局部于管程内部的共享数据设置初始值的语句

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

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

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

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

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

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

三、管程中的条件变量

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

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

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

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

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

注意，条件变量与信号量不同，他并不是计数器，如果向一个条件变量发送信号，而这个条件变量上此时并没有等待进程，则这个信号就会丢失，也就是说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等价，但他们并不受竞争条件约束，而是通过异常机制实现对中断情况的处理

摘抄自http://hi.baidu.com/zeyu203/item/0a5c3683c73d8b8f4514cf2a

*******************************************************************************************

1、互斥锁（linux下实现了）

互斥锁的主要特点是互斥锁的释放必须由上锁的进(线)程释放，如果拥有锁的进(线)程不释放，那么其它的进(线)程永远也没有机会获得所需要的互斥锁。互斥锁主要用于线程之间的同步。

2、条件变量（linux实现了）

条件变量用来自动阻塞一个线程，直到某特殊情况发生为止。通常条件变量和互斥锁同时使用。

上文中提到，对于互斥锁而言，如果拥有锁的进(线)程不释放锁，其它进(线)程永远没机会获得锁，也就永远没有机会继续执行后续的逻辑。在实际环境下，一个线程A需要改变一个共享变量X的值，为了保证在修改的过程中X不会被其它的线程修改，线程A必须首先获得对X的锁。现在假如A已经获得锁了，由于业务逻辑的需要，只有当X的值小于0时，线程A才能执行后续的逻辑，于是线程A必须把互斥锁释放掉，然后继续“忙等”。如下面的伪代码所示：

// get x lock
while(x <= 0){
   // unlock x ;
   // wait some time
   // get x lock
}
// unlock x

这种方式是比较消耗系统的资源的，因为进程必须不停的主动获得锁、检查X条件、释放锁、再获得锁、再检查、再释放，一直到满足运行的条件的时候才可以。因此我们需要另外一种不同的同步方式，当线程X发现被锁定的变量不满足条件时会自动的释放锁并把自身置于等待状态，让出CPU的控制权给其它线程。其它线程此时就有机会去修改X的值，当修改完成后再通知那些由于条件不满足而陷入等待状态的线程。这是一种通知模型的同步方式，大大的节省了CPU的计算资源，减少了线程之间的竞争，而且提高了线程之间的系统工作的效率。这种同步方式就是条件变量。
坦率的说，从字面意思上来将，“条件变量”这四个字是不太容易理解的。我们可以把“条件变量”看做是一个对象，一个铃铛，一个会响的铃铛。当一个线程在获得互斥锁之后，由于被锁定的变量不满足继续运行的条件时，该线程就释放互斥锁并把自己挂到这个“铃铛”上。其它的线程在修改完变量后，它就摇摇“铃铛”，告诉那些挂着的线程：“你们等待的东西已经变化了，都醒醒看看现在的它是否满足你们的要求。”于是那些挂着的线程就知道自己醒来看自己是否能继续跑下去了。  

读写锁（linux实现了）

特殊的自旋锁

读写锁的出现能够有效的解决多进程并行读的问题。每一个需要读取的进程都申请读锁，这样大家互不干扰。当有进程需要写如数据时，首先申请写锁。如果在申请时发现有读(或者写)锁存在，则该写进程必须等待，一直等到所有的读(写)锁完全释放为止。读进程在读取之前首先申请读锁，如果所读数据被写锁锁定，则该读进程也必须等待读锁被释放位置。
很自然的，多个读锁是可以共存的，但写锁是完全互相排斥的。

信号量机制:
一个信号量只能置一次初值，以后只能对之进行p操作或v操作。
使用时对信号量的操作分散，而且难以控制，读写和维护都很困难。加重了程序员的编码负担；核心操作P-V分散在各用户程序的代码中，不易控制和管理；一旦错误，后果严重，且不易发现和纠正。
由此也可以看到，信号量机制必须有公共内存，不能用于分布式操作系统，这是它最大的弱点。

自旋锁:
旋锁是为了保护共享资源提出的一种锁机制。
调用者申请的资源如果被占用，即自旋锁被已经被别的执行单元保持，则调用者一直循环在那里看是否该自旋锁的保持着已经释放了锁
自旋锁是一种比较低级的保护数据结构和代码片段的原始方式，可能会引起以下两个问题;
（1）死锁
（2）过多地占用CPU资源

管程：【再细看】
优： 集中式同步进程——管程。其基本思想是将共享变量和对它们的操作集中在一个模块中，操作系统或并发程序就由这样的模块构成。这样模块之间联系清晰，便于维护和修改，易于保证正确性。
缺：如果一个分布式系统具有多个CPU，并且每个CPU拥有自己的私有内存，它们通过一个局域网相连，那么这些原语将失效。而管程在少数几种编程语言之外又无法使用，并且，这些原语均未提供机器间的信息交换方法。




 
会合：
进程直接进行相互作用


分布式系统:
由于在分布式操作系统中没有公共内存，因此参数全为值参，  
而且不可为指针。

 

原子操作 

(1)适合共享简单的数据类型：整型，比特性
(2)适合高效率的场合

关闭中断

不适合多CPU，屏蔽中断只对执行了屏蔽命令的那个cpu有效，若关闭了所有cpu中断代价太大。若屏蔽了中断，只能由用户打开中断，如果不打开就坏了