各种同步锁的区别

这两天经常有同事在问spinlock和semaphore的相关问题，什么时候该用spinlock？什么时候该用semaphore？什么时候该用spinlock_irq？什么时候该用spinlock_irqsave？的确，对于初涉内核开发的人员来说，spinlock和semaphore的应用是一个比较大的疑问。这里，我来谈谈我对这两个概念的想法吧。

Spinlock的实现机制可以描述如下：CPU首先将内存总线lock住，然后检测内存中的lock数据，如果数据为真，那么表示资源被人占用，无法获取。然后CPU会自璇检测该lock数据，直到数据不为真之后，lock该数据返回。在Linux中spinlock核心代码采用汇编语言实现，可以参考__raw_spin_lock函数。在2.6.25版本之后，Linux为了解决在多CPU平台上的不公平竞争，引入了排队自璇锁的算法。

说到这里，需要讲一下的是，spinlock在up平台上为空函数的说法。这个说法不是很严格，实际上在非强占的up平台上，spinlock的实现为空函数，在可抢占的up平台上，spinlock需要将抢占给disable掉，也就是说在spinlock的临界区，Linux无法抢占。在多CPU平台上，spinlock是有效的。

Semaphore的实现机制可以描述如下：CPU首先会检测信号量是否可获取，如果无法获取该信号量，那么就会导致一次上下文调度操作。从实现机制上来看，semaphore操作效率比较低，而spinlock的效率相对较高，但是这种效率的高低与应用相关，如果临界区操作的时间过长，那么采用spinlock会浪费大量的CPU时间，还不如做几次上下文调度释放CPU资源呢。所以，spinlock的应用有一个原则，那就是临界区操作尽可能的短，让CPU不要自璇太多的时间，这一点从spinlock的实现代码上也可以看出一些端倪，Linux开发人员着这个地方花费了好多心计。

从上面的机制描述，我想可以总结出如下几点：

1、 不允许睡眠的上下文需要采用spinlock，可以睡眠的上下文可以采用semaphore。在中断上下文中访问的竞争资源一定采用spinlock。

2、 临界区操作较长的应用建议采用semaphore，临界区很短的操作建议采用spinlock。

3、 需要关中断的场合需要调用spinlock_irq或者spinlock_irqsave，不明确当前中断状态的地方需要调用spinlock_irqsave，否则调用spinlock_irq。一个资源既在中断上下文中访问，又在用户上下文中访问，那么需要关中断，如果仅仅在用户上下文中被访问，那么无需关中断。

简单的说，自旋锁在内核中主要用来防止多处理器中并发访问临界区，防止内核抢占造成的竞争。另外自旋锁不允许任务睡眠(持有自旋锁的任务睡眠会造成自死锁——因为睡眠有可能造成持有锁的内核任务被重新调度，而再次申请自己已持有的锁)，它能够在中断上下文中使用

Linux中的信号量是一种睡眠锁。如果有一个任务试图获得一个已被持有的信号量时，信号量会将其推入等待队列，然后让其睡眠。这时处理器获得自由去执行其它代码。当持有信号量的进程将信号量释放后，在等待队列中的一个任务将被唤醒，从而便可以获得这个信号量。

信号量的睡眠特性，使得信号量适用于锁会被长时间持有的情况；只能在进程上下文中使用，因为中断上下文中是不能被调度的；另外当代码持有信号量时，不可以再持有自旋锁

自旋锁对信号量

需求 建议的加锁方法

低开销加锁 优先使用自旋锁

短期锁定 优先使用自旋锁

长期加锁
优先使用信号量

中断上下文中加锁 使用自旋锁

持有锁是需要睡眠、 调度 使用信号量

Mutex是一把钥匙，一个人拿了就可进入一个房间，出来的时候把钥匙交给队列的第一个。一般的用法是用于串行化对criticalsection代码的访问，保证这段代码不会被并行的运行。

Semaphore是一件可以容纳N人的房间，如果人不满就可以进去，如果人满了，就要等待有人出来。对于N=1的情况，称为binarysemaphore。一般的用法是，用于限制对于某一资源的同时访问

四种进程或线程同步互斥的控制方法

1、临界区:通过对多线程的串行化来访问公共资源或一段代码，速度快，适合控制数据访问。 只能用来同步本进程内的线程，而不可用来同步多个进程中的线程

2、互斥量:为协调共同对一个共享资源的单独访问而设计的。 因为使用互斥不仅仅能够在同一应用程序不同线程中实现资源的安全共享，而且可以在不同应用程序的线程之间实现对资源的安全共享

3、信号量:为控制一个具有有限数量用户资源而设计。 信号允许多个线程同时使用共享资源

4、事 件:用来通知线程有一些事件已发生，从而启动后继任务的开始。