我们知道，临界区是指某个代码区间，在该区间中需要访问某些共享的数据对象，又或者是总线，硬件寄存器等，通常这段代码区间的范围要控制在尽可
能小的范围内。临界区内需要对这些数据对象和硬件对象的访问进行保护，保证在退出临界区前不会被临界区外的代码对这些对象进行修改。出现以下几种情形时，
我们需要使用临界区进行保护：

• (1)  在可以抢占（preemption）的系统中，两个线程同时访问同一个对象；
• (2)  线程和中断同时访问同一个对象；
• (3)  在多核系统中(SMP)，可能两个CPU可能同时访问同一个对象；

针对单处理器系统，对第一种情况，只要临时关闭系统抢占即可，我们可以使用以下方法：

1. preempt_disable();
2. .....
3. // 访问共享对象的代码
4. ......
5. preempt_enable();

1. local_irq_disable();
2. ......
3. // 访问共享对象的代码
4. ......
5. local_irq_enable();

实际上，在linux中，上面所说的三种情况都可以用自旋锁(spin_lock)解决。基本的自旋锁函数对是：

• spin_lock(spinlock_t *lock)；
• spin_unlock(spinlock_t *lock)；

对于单处理器系统，在不打开调试选项时，spinlock_t实际上是一个空结构，把上面两个函数展开后，实际上就只是调用
preempt_disable()和preempt_enable()，对于单处理器系统，关掉抢占后，其它线程不能被调度运行，所以并不需要做额外的
工作，除非中断的到来，不过内核提供了另外的变种函数来处理中断的问题。

对于多处理器系统，spinlock_t实际上等效于内存单元中的一个整数，内核保证spin_lock系列函数对该整数进行原子操作，除了调
用preempt_disable()和preempt_enable()防止线程被抢占外，还必须对spinlock_t上锁，这样，如果另一个CPU
的代码要使用该临界区对象，就必须进行自旋等待。

对于中断和普通线程都要访问的对象，内核提供了另外两套变种函数：

• spin_lock_irq(spinlock_t *lock)；
• spin_unlock_irq(spinlock_t *lock)；

和：

• spin_lock_irqsave(lock, flags)；
• spin_lock_irqrestore(lock, flags)；

我们可以按以下原则使用上面的三对变种函数（宏）：

• 如果只是在普通线程之间同时访问共享对象，使用spin_lock()/spin_unlock()；
• 如果是在中断和普通线程之间同时访问共享对象，并且确信退出临界区后要打开中断，使用spin_lock_irq()/spin_unlock_irq()；
• 如果是在中断和普通线程之间同时访问共享对象，并且退出临界区后要保持中断的状态，使用spin_lock_irqsave()/spin_unlock_irqrestore()；

其实变种还不止这几个，还有read_lock_xxx/write_lock_xxx、spin_lock_bh/spin_unlock_bh、spin_trylock_xxx等等。但常用的就上面几种。

在2.6.33之后的版本，内核加入了raw_spin_lock系列，使用方法和spin_lock系列一模一样，只是参数有
spinlock_t变为了raw_spinlock_t。而且在内核的主线版本中，spin_lock系列只是简单地调用了raw_spin_lock
系列的函数，但内核的代码却是有的地方使用spin_lock，有的地方使用raw_spin_lock。是不是很奇怪？要解答这个问题，我们要回到
2004年，MontaVista Software, Inc的开发人员在邮件列表中提出来一个Real-Time
Linux Kernel的模型，旨在提升Linux的实时性，之后Ingo
Molnar很快在他的一个项目中实现了这个模型，并最终产生了一个Real-Time preemption的patch。

该模型允许在临界区中被抢占，而且申请临界区的操作可以导致进程休眠等待，这将导致自旋锁的机制被修改，由原来的整数原子操作变更为信号量操
作。当时内核中已经有大约10000处使用了自旋锁的代码，直接修改spin_lock将会导致这个patch过于庞大，于是，他们决定只修改哪些真正不
允许抢占和休眠的地方，而这些地方只有100多处，这些地方改为使用raw_spin_lock，但是，因为原来的内核中已经有
raw_spin_lock这一名字空间，用于代表体系相关的原子操作的实现，于是linus本人建议：

• 把原来的raw_spin_lock改为arch_spin_lock；
• 把原来的spin_lock改为raw_spin_lock；
• 实现一个新的spin_lock；

写到这里不知大家明白了没？对于2.6.33和之后的版本，我的理解是：

• 尽可能使用spin_lock；
• 绝对不允许被抢占和休眠的地方，使用raw_spin_lock，否则使用spin_lock；
• 如果你的临界区足够小，使用raw_spin_lock；

对于没有打上Linux-RT（实时Linux）的patch的系统，spin_lock只是简单地调用raw_spin_lock，实际上他们是完全一
样的，如果打上这个patch之后，spin_lock会使用信号量完成临界区的保护工作，带来的好处是同一个CPU可以有多个临界区同时工作，而原有的
体系因为禁止抢占的原因，一旦进入临界区，其他临界区就无法运行，新的体系在允许使用同一个临界区的其他进程进行休眠等待，而不是强占着CPU进行自旋操
作。写这篇文章的时候，内核的版本已经是3.3了，主线版本还没有合并Linux-RT的内容，说不定哪天就会合并进来，也为了你的代码可以兼容
Linux-RT，最好坚持上面三个原则。