为了能够有效的控制多个进程之间的沟通过程，OS必须提供一定的同步机制保证进程之间不会自说自话而是有效的协同工作。比如在共享内存的通信方式中，两个或者多个进程都要对共享的内存进行数据写入，那么怎么才能保证一个进程在写入的过程中不被其它的进程打断，保证数据的完整性呢？又怎么保证读取进程在读取数据的过程中数据不会变动，保证读取出的数据是完整有效的呢？常用的同步方式有：
- 互斥锁
- 条件变量
- 读写锁
- 记录锁(文件锁)
互斥锁
所谓互斥，从字面上理解就是互相排斥。因此互斥锁从字面上理解就是一个进程拥有了这个锁，它将排斥其它所有的进程访问被锁住的东西，其它的进程如果需要锁就只能等待，等待拥有锁的进程把锁打开后才能继续运行。互斥锁的主要特点是互斥锁的释放必须由上锁的进(线)程释放，如果拥有锁的进(线)程不释放，那么其它的进(线)程永远也没有机会获得所需要的互斥锁。互斥锁主要用于线程之间的同步。
条件变量
上文中提到，对于互斥锁而言，如果拥有锁的进(线)程不释放锁，其它进(线)程永远没机会获得锁，也就永远没有机会继续执行后续的逻辑。在实际环境下，一个线程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的计算资源，减少了线程之间的竞争，而且提高了线程之间的系统工作的效率。这种同步方式就是条件变量。坦率的说，从字面意思上来将，“条件变量”这四个字是不太容易理解的。我们可以把“条件变量”看做是一个对象，一个铃铛，一个会响的铃铛。当一个线程在获得互斥锁之后，由于被锁定的变量不满足继续运行的条件时，该线程就释放互斥锁并把自己挂到这个“铃铛”上。其它的线程在修改完变量后，它就摇摇“铃铛”，告诉那些挂着的线程：“你们等待的东西已经变化了，都醒醒看看现在的它是否满足你们的要求。”于是那些挂着的线程就知道自己醒来看自己是否能继续跑下去了。
读写锁
互斥锁是排他性锁，条件变量出现后和互斥锁配合工作能够有效的节省系统资源并提高线程之间的协同工作效率。互斥锁的目的是为了独占，条件变量的目的是为了等待和通知。考虑一个文件有多个进程要读取其中的内容，但只有1个进程有写的需求。我们知道读文件的内容不会改变文件的内容，这样即使多个进程同时读相同的文件也没什么问题，大家都能和谐共存。当写进程需要写数据时，为了保证数据的一致性，所有读的进程就都不能读数据了，否则很可能出现读出去的数据一半是旧的，一半是新的状况，逻辑就乱掉了。
为了防止读数据的时候被写入新的数据，读进程必须对文件加上锁。现在假如我们有2个进程都同时读，如果我们使用上面的互斥锁和条件变量，当其中一个进程在读取数据的时候，另一个进程只能等待，因为它得不到锁。从性能上考虑，等待进程所花费的时间是完全的浪费，因为这个进程完全可以读文件内容而不会影响第一个，但是这个进程没有锁，所以它什么也做不了，只能等，等到花儿都谢了。所以呢，我们需要一种其它类型的同步方式来满足上面的需求，这就是读写锁。读写锁的出现能够有效的解决多进程并行读的问题。每一个需要读取的进程都申请读锁，这样大家互不干扰。当有进程需要写如数据时，首先申请写锁。如果在申请时发现有读(或者写)锁存在，则该写进程必须等待，一直等到所有的读(写)锁完全释放为止。读进程在读取之前首先申请读锁，如果所读数据被写锁锁定，则该读进程也必须等待读锁被释放位置。很自然的，多个读锁是可以共存的，但写锁是完全互相排斥的。
条件变量是另一种常用的变量。它也常常被保存为全局变量，并和互斥锁合作。
条件变量的另外一种解释
假设这样一个状况: 有100个工人，每人负责装修一个房间。当有10个房间装修完成的时候，老板就通知相应的十个工人一起去喝啤酒。
我们如何实现呢？老板让工人在装修好房间之后，去检查已经装修好的房间数。但多线程条件下，会有竞争条件的危险。也就是说，其他工人有可能会在该工人装修好房子和检查之间完成工作。采用下面方式解决：
/*mu: global mutex,
cond: global codition variable,
num: global int
*/
mutex_lock(mu)
num = num + 1; /*worker build the room*/
if (num <= 10) { /*worker is within the first 10 to finish*/
cond_wait(mu, cond); /*wait*/
printf("drink beer");
}else if (num = 11) {
/*workder is the 11th to finish*/
cond_broadcast(mu, cond); /*inform the other 9 to wake up*/}
mutex_unlock(mu);
上面使用了条件变量。条件变量除了要和互斥锁配合之外，还需要和另一个全局变量配合(这里的num, 也就是装修好的房间数)。这个全局变量用来构成各个条件。
具体思路如下。我们让工人在装修好房间(num = num + 1)之后，去检查已经装修好的房间数( num < 10 )。由于mu被锁上，所以不会有其他工人在此期间装修房间(改变num的值)。如果该工人是前十个完成的人，那么我们就调用cond_wait()函数。cond_wait()做两件事情，一个是释放mu，从而让别的工人可以建房。另一个是等待，直到cond的通知。这样的话，符合条件的线程就开始等待。
当有通知(第十个房间已经修建好)到达的时候，condwait()会再次锁上mu。线程的恢复运行，执行下一句prinft("drink beer") (喝啤酒！)。从这里开始，直到mutex_unlock()，就构成了另一个互斥锁结构。
那么，前面十个调用cond_wait()的线程如何得到的通知呢？我们注意到elif if，即修建好第11个房间的人，负责调用cond_broadcast()。这个函数会给所有调用cond_wait()的线程放送通知，以便让那些线程恢复运行。
条件变量特别适用于多个线程等待某个条件的发生。如果不使用条件变量，那么每个线程就需要不断尝试获得互斥锁并检查条件是否发生，这样大大浪费了系统的资源。
记录锁（文件锁）
为了增加并行性，我们可以在读写锁的基础上进一步细分被锁对象的粒度。比如一个文件中，读进程可能需要读取该文件的前1k个字节，写进程需要写该文件的最后1k个字节。我们可以对前1k个字节上读锁，对最后1k个自己上写锁，这样两个进程就可并发工作了。记录锁中的所谓“记录”其实是“内容”的概念。使用读写锁可以锁定一部分，而不是整个文件。文件锁可以认为是记录锁的一个特例，当使用记录锁锁定文件的所有内容时，此时的记录锁就可以称为文件锁了。
信号灯
一般意义下，信号灯是一个具有整数值的对象，它支持两种操作P()和V()。P()操作减少信号灯的值，如果新的信号灯的值小于0，则操作阻塞；V()操作增加信号灯的值，如果结果值大于或等于0，则唤醒一个等待的进程。通常用信号灯来做进程的同步和互斥。
最简单形式的信号灯就是内存中一个存储位置，它的取值可以由多个进程检验和设置。至少对于相关的进程来讲，对信号灯的检验和设置操作是不可中断的或者说是原子的：只要启动就不能终止。目前许多处理器提供检验和设置操作指令，如Intel处理器的sete等指令。检验和设置操作的结果是信号灯当前值与设置值的和，可以是正或者负。根据检验和设置操作的结果，一个进程可能必须睡眠直到信号灯的值被另一个进程改变。信号灯可以用于实现临界区（critical regions），就是重要的代码区，同一时刻只能有一个进程运行的代码区域。
比如，有许多协作的进程要从同一个数据文件中读写记录，并且希望对文件的访问必须严格地协调。那么，可以使用一个信号灯，将其初值设为1，用两个信号灯操作（P、V 操作），将进程中对文件操作的代码括起来。第一个信号灯操作检查并把信号灯的值减小，第二个操作检查并增加它。访问文件的第一个进程试图减小信号灯的值，如果它成功（事实上，它肯定成功），信号灯的取值将变为0，这个进程现在可以继续运行并使用数据文件。但是，如果此时另一个进程需要使用这个文件，它也试图减少信号灯的数值，它会失败，因为信号灯的值将要变成-1（但是，信号灯的值仍然保持为0，没有变成-1），这个进程会被挂起直到第一个进程处理完数据文件。当第一个进程处理完数据文件后，它会增加信号灯的值使其重新变为1。现在等待的进程会被唤醒，这次它减小信号灯的尝试会成功。
