preempt_spin_lock分析

这几天，主要做一些多线程网络服务器代码的优化事宜，用到了线程队列来逻辑处理到来的客户连接，也因此用到了锁机制。有意无意的查阅锁的效率问题，然后自然而然就查到了无锁算法效率较高的说法，最后就查到了linux内核的自旋锁上了。也就是__preempt_spin_lock函数上。这个函数自己第一眼看，看不明白，然后自己看了会才明白，所以记下，以后登录回顾。
本着我为人人，人人为我的AV精神，拿来分享，可能理解也不完全对，哪有不对的地方，大家积极指出，互相学习。
static inline void __preempt_spin_lock(spinlock_t *lock)
{
    .................
    do{
            preempt_enable();
            while(spin_is_locked(lock))
                cpu_relax();
            preempt_disable();
    }while(!__raw_spin_trylock(lock));
}
这段函数其实涉及到的东西挺多，我是一点一点挖出来的。
先说下这段代码的意思：
在获取自旋锁前，先允许抢占，这还没有获得锁呢，你禁止抢占就有点过分啦。然后判断这个锁在其它地方是不是已经被使用，如果使用就执行cpu_relax,这个函数可以认为是忙等待，也就是让cpu休息一会，然后再检测锁有没有被释放，还没有，则继续等待，如果释放了，那么往下继续，先禁止抢占，最后尝试加锁，返回0表示加锁成功，函数执行完毕，返回1表示加锁失败，继续循环等待直到加锁成功。
这段代码其实反映的就是自旋锁定义。一旦获得锁就会运行完毕，获得不了锁则占用某个cpu一直等待，直到获得锁。
这里面有几个点一一记下：
一   preempt_enable和preempt_disable
获得锁以后，临界区必须执行完毕，哪怕有高优先级任务，但是没有禁止中断，也就是说自旋锁获得期间中断是可以执行的，但是中断执行完，还是要回到这段代码的。如果这段代码的外围在加上禁止中断，那整个世界就安静了，趁这段得之不易的时间，抓紧干活吧。
二 cpu_relax是忙等待，这对于cpu来说，太浪费了，所以如果获得锁需要等待的时间很长的话，不适合自旋锁。
三 如果临界区执行时间长的话，也不建议采用自旋锁，因为自旋锁获得前禁止抢占，如果执行临界区代码时间很长，相当于独占cpu很长时间，其它任务就没有机会或者说分摊的执行时间少。
四 注意__raw_spin_trylock的返回值，一定要落实真否获得锁。

关于抢占内核和非抢占内核，个人感觉这个blog说的不错，特意拿来参考，推荐指数：5颗星。原地址：http://blog.csdn.net/sailor_8318/article/details/2870184

非抢占式内核

非抢占式内核是由任务主动放弃CPU的使用权。非抢占式调度法也称作合作型多任务，各个任务彼此合作共享一个CPU。异步事件还是由中断服务来处理。中断服务可以使一个高优先级的任务由挂起状态变为就绪状态。但中断服务以后控制权还是回到原来被中断了的那个任务，直到该任务主动放弃CPU的使用权时，那个高优先级的任务才能获得CPU的使用权。

非抢占式内核的优点有：

·中断响应快(与抢占式内核比较)；

·允许使用不可重入函数；

·几乎不需要使用信号量保护共享数据。运行的任务占有CPU，不必担心被别的任务抢占。这不是绝对的，在打印机的使用上，仍需要满足互斥条件。

非抢占式内核的缺点有：

·任务响应时间慢。高优先级的任务已经进入就绪态，但还不能运行，要等到当前运行着的任务释放CPU。

·非抢占式内核的任务级响应时间是不确定的，不知道什么时候最高优先级的任务才能拿到CPU的控制权，完全取决于应用程序什么时候释放CPU。

抢占式内核

使用抢占式内核可以保证系统响应时间。最高优先级的任务一旦就绪，总能得到CPU的使用权。当一个运行着的任务使一个比它优先级高的任务进入了就绪态，当前任务的CPU使用权就会被剥夺，或者说被挂起了，那个高优先级的任务立刻得到了CPU的控制权。如果是中断服务子程序使一个高优先级的任务进入就绪态，中断完成时，中断了的任务被挂起，优先级高的那个任务开始运行。

抢占式内核的优点有：

·使用抢占式内核，最高优先级的任务什么时候可以执行，可以得到CPU的使用权是可知的。使用抢占式内核使得任务级响应时间得以最优化。

抢占式内核的缺点有：

·不能直接使用不可重入型函数。调用不可重入函数时，要满足互斥条件，这点可以使用互斥型信号量来实现。如果调用不可重入型函数时，低优先级的任务CPU的使用权被高优先级任务剥夺，不可重入型函数中的数据有可能被破坏。

什么时候需要重新调度：

·时钟中断处理例程检查当前任务的时间片，当任务的时间片消耗完时，scheduler_tick()函数就会设置need_resched标志；

·信号量、等到队列、completion等机制唤醒时都是基于waitqueue的，而waitqueue的唤醒函数为，其调用将被唤醒的任务更改为就绪状态并设置need_resched标志。

·设置用户进程的nice值时，可能会使高优先级的任务进入就绪状态；

·改变任务的优先级时，可能会使高优先级的任务进入就绪状态；

·新建一个任务时，可能会使高优先级的任务进入就绪状态；

·对CPU(SMP)进行负载均衡时，当前任务可能需要放到另外一个CPU上运行；

    抢占发生的时机

·当一个中断处理例程退出，在返回到内核态时(kernel-space)。这是隐式的调用schedule()函数，当前任务没有主动放弃CPU使用权，而是被剥夺了CPU使用权。

·当kernel code从不可抢占状态变为可抢占状态时(preemptible again)。也就是preempt_count从正整数变为0时。这也是隐式的调用schedule()函数。

·一个任务在内核态中显式的调用schedule()函数。任务主动放弃CPU使用权。

·一个任务在内核态中被阻塞，导致需要调用schedule()函数。任务主动放弃CPU使用权。

   什么时候不允许抢占

有几种情况Linux内核不应该被抢占，除此之外，Linux内核在任意一点都可被抢占。这几种情况是：

·内核正进行中断处理。在Linux内核中进程不能抢占中断(中断只能被其他中断中止、抢占，进程不能中止、抢占中断)，在中断例程中不允许进行进程调度。进程调度函数schedule()会对此作出判断，如果是在中断中调用，会打印出错信息。

·内核正在进行中断上下文的Bottom Half(中断的下半部)处理。硬件中断返回前会执行软中断，此时仍然处于中断上下文中。

·内核的代码段正持有spinlock自旋锁、writelock/readlock读写锁等锁，处干这些锁的保护状态中。内核中的这些锁是为了在SMP系统中短时间内保证不同CPU上运行的进程并发执行的正确性。当持有这些锁时，内核不应该被抢占，否则由于抢占将导致其他CPU长期不能获得锁而死等。

·内核正在执行调度程序Scheduler。抢占的原因就是为了进行新的调度，没有理由将调度程序抢占掉再运行调度程序。

·内核正在对每个CPU“私有”的数据结构操作(Per-CPU date structures)。在SMP中，对于per-CPU数据结构未用spinlocks保护，因为这些数据结构隐含地被保护了(不同的CPU有不一样的per-CPU数据，其他CPU上运行的进程不会用到另一个CPU的per-CPU数据)。但是如果允许抢占，但一个进程被抢占后重新调度，有可能调度到其他的CPU上去，这时定义的Per-CPU变量就会有问题，这时应禁抢占。

spin_lock和raw_spin_lock的历史

这也是网上截来的，感觉挺好，留于此地，推荐指数：5颗星。原地址：http://blog.csdn.net/droidphone/article/details/7395983

在2.6.33之后的版本，内核加入了raw_spin_lock系列，使用方法和spin_lock系列一模一样。而且在内核的主线版本中，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，最好坚持上面三个原则。