【IT168 技术文档】

    内核任务之间的并发关系

    上述内核任务很多情况是可以交错执行的——记住，一个下半部实际上可能在任何时候执行，所以很有可能产生竞争（都要访问同一个数据结构时，就产生了竞争）。下面分析这些内核任务之间有哪些可能的并发行为。

    可以抽象出，程序（用户态和内核态一样）并发执行的总原因无非是正在运行中的程序被其它程序抢占，所以我们必须看看内核任务之间的抢占关系：

    n 中断处理程序可以抢占内核中的所有程序（当没有锁保护时），包括软中断，tasklet，bottom half和系统的调用、内核线程，甚至也包括硬中断处理程序。也就是说中断处理程序可以和这些所有的内核任务并发执行，如果被抢占的程序和中断处理程序都要访问同一个资源，就必然有可能产生竞争。

    n 软件中断也可以抢占内核中的所有任务，所以内核代码（比如，系统调用、内核线程等）中有数据和软中断共享，就会有竞争——除此外硬件中断处理程序也有可能被软中断打断，条件是硬中断被其它硬中断打断，软中断随即便获得了执行机会，因为软中断是跟在硬中断后执行的。此外要注意的是，软中断即使是同种类型的也可以并发地运行在不同处理器上，所以它们之间共享数据都会产生竞争。（如果在同一个处理器上,软中断之间是不能相互抢占的）。

    n 同类的tasklet不可能同时运行，所以对于同类tasklet之间是串行运行的，他们不会产生并发；但两个不同种类的tasklet有可能在不同处理器上并发运行，如果之间有数据共享就会产生竞争（在同一个处理器上运行的tasklet不发生相互抢占的情况）。

    n Bottom half 无论是否是同类的，即使在不同处理器上也都不能并发执行，它是绝对串行化的，所以它们之间永远不能产生竞争。任务列队属性基本同BH。

    n 系统调用和内核线程这种运行在进程上下文中的内核任务可能和各种内核任务并发，除了上面提到的中断（软，硬）来抢占它而产生并发外，它也有可能自发性地主动睡眠（比如在一些阻塞性的操作中），放弃处理器，重新调度其它任务，所以系统调用和内核线程除会与软硬中断（半底等）发生竞争，也会与其他（包括自己）系统调用与内核线程发生竞争。我们尤其要注意这种情况。

    注意：tasklet和bottom half是建立在软中断之上的，所以它们也都遵从软中断的调度规则——都可以打断进程上下文中的内核代码（系统调用），都可被硬中断打断——这些情况下都可能产生并发。

    内核同步措施

    为了避免并发，防止竞争。内核提供了一组同步方法来提供对共享数据的保护。 我们的重点不是介绍这些方法的详细用法，而是强调为什么使用这些方法和它们之间的差别。

    Linux使用的同步机制可以说从2.0到2.6以来不断发展完善。从最初的原子操作，到后来的信号量，从大内核锁到今天的自旋锁。这些同步机制的发展伴随 Linux从单处理器到对称多处理器的过度；伴随着从非抢占内核到抢占内核的过度。锁机制越来越有效，也越来越复杂。

    目前来说内核中原子操作多用来做计数使用，其它情况最常用的是两重锁以及它们的变种，一个是自旋锁，另一个是信号量。我们下面就来着重介绍一下这两种锁机制。

    自旋锁

    自旋锁是专为防止多处理器并发而引入的一种锁，它在内核中大量应用于中断处理等部分（对于单处理器来说，防止中断处理中的并发可简单采用关闭中断的方式，不需要自旋锁）。

    自旋锁最多只能被一个内核任务持有，如果一个内核任务试图请求一个已被争用（已经被持有）的自旋锁，那么这个任务就会一直进行忙循环——旋转——等待锁重新可用。要是锁未被争用，请求它的内核任务便能立刻得到它并且继续进行。自旋锁可以在任何时刻防止多于一个的内核任务同时进入临界区，因此这种锁可有效地避免多处理器上并发运行的内核任务竞争共享资源。

    事实上，自旋锁的初衷就是：在短期间内进行轻量级的锁定。一个被争用的自旋锁使得请求它的线程在等待锁重新可用的期间进行自旋（特别浪费处理器时间），所以自旋锁不应该被持有时间过长。如果需要长时间锁定的话, 最好使用信号量。

    自旋锁的基本形式如下：

spin_lock(&mr_lock);
/**//*临界区*/
spin_unlock(&mr_lock);

    因为自旋锁在同一时刻只能被最多一个内核任务持有，所以一个时刻只有一个线程允许存在于临界区中。这点很好地满足了对称多处理机器需要的锁定服务。在单处理器上，自旋锁仅仅当作一个设置内核抢占的开关。如果内核抢占也不存在，那么自旋锁会在编译时被完全剔除出内核。

    自旋锁在内核中有许多变种，如对bottom half 而言，可以使用spin_lock_bh()用来获得特定锁并且关闭半底执行。相反的操作由spin_unlock_bh()来执行；如果临界区的访问逻辑可以被清晰的分为读和写这种模式，那么可以使用读者/写者自旋锁，调用形式为：

    读者的代码路径：

read_lock(&mr_rwlock);
/**//*只读临界区*/
read_unlock(&mr_rwlock);

    写者的代码路径：

write_lock(&mr_rwlock);
/**//*读写临界区*/
write_unlock(&mr_rwlock);

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

    死锁：假设有一个或多个内核任务和一个或多个资源，每个内核都在等待其中的一个资源，但所有的资源都已经被占用了。这便会发生所有内核任务都在相互等待，但它们永远不会释放已经占有的资源，于是任何内核任务都无法获得所需要的资源，无法继续运行，这便意味着死锁发生了。自死琐是说自己占有了某个资源，然后自己又申请自己已占有的资源，显然不可能再获得该资源，因此就自缚手脚了。

    信号量

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

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

    信号量基本使用形式为：

static DECLARE_MUTEX(mr_sem);//声明互斥信号量
…
if(down_interruptible(&mr_sem))
/**//*可被中断的睡眠，当信号来到，睡眠的任务被唤醒 */
/**//*临界区…*/
up(&mr_sem);

    同自旋锁一样，信号量在内核中也有许多变种，比如读者－写者信号量等，这里不再做介绍了。

    信号量和自旋锁区别

    虽然听起来两者之间的使用条件复杂，其实在实际使用中信号量和自旋锁并不易混淆。注意以下原则。

    如果代码需要睡眠——这往往是发生在和用户空间同步时——使用信号量是唯一的选择。由于不受睡眠的限制，使用信号量通常来说更加简单一些。如果需要在自旋锁和信号量中作选择，应该取决于锁被持有的时间长短。理想情况是所有的锁都应该尽可能短的被持有，但是如果锁的持有时间较长的话，使用信号量是更好的选择。另外，信号量不同于自旋锁，它不会关闭内核抢占，所以持有信号量的代码可以被抢占。这意味者信号量不会对影响调度反应时间带来负面影响。

    自旋锁对信号量

    需求：建议的加锁方法

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

    短期锁定：优先使用自旋锁

    长期加锁：优先使用信号量

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

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

    引自 《Linux内核开发》

    防止并发的方式除了上面提到的外还有很多，我们不详细介绍了。说了这么多,希望大家认识到，并发控制在内核编程中是个特别难缠的问题，要驾御它必须清楚地认识到内核中各种任务的调度时机与特点，并且在开发初期就应特别小心保护共享数据（一切共享数据、一切能被别人看到的数据都要注意保护），别等到开发完成才去亡羊补牢。

    并发控制实例

    我们下面给出一个多内核任务访问共享资源的具体例子，其中会用到上面提到的各种同步方法，希望能给大家一个形象的记忆。

    该例子的具体场景描述如下。

    我们主要的共享资源是链表（mine）,操作它的内核任务有三种：一个是100个内核线程（sharelist），它们负责从表头将新节点（struct my_struct）插入链表。二是定时器任务(qt_task)，它负责每个时钟滴答时从链表头删除一个节点。三是系统调用（由rmmod命令调用的share_exit），它负责销毁链表并卸载模块。

    我们利用模块（sharelist.o）实现上述场景。加载模块时会建立定时器任务列队，并将要执行的任务(task.rounting=qt_task)插入定时器队列（tq_timer），然后反复调度执行（但别不停地执行）。与此同时利用系统中的keventd内核线程（它的目的是执行任务队列,由schedule_task激活，PID=2），创建100个内核线程(创建函数kernel_thread)执行插入链表的工作（由sharelist完成）——但当链表长度超过100时，则从链表尾删除节点。最后当你需要卸载模块时，调用share_exit函数销毁整个链表，并做一些诸如销毁我们建立的内核进程的收尾工作。

    下面我们具体看看在程序中该如何保护我们的链表。上述场景中存在的内核并发包括——内核线程之间的并发、内核任务与定时器任务的并发。要知道内核线程执行在进程上下文中，而定时器任务属于下半部分，执行在中断上下文中。在这两部分交错执行中进行保护则需要采用自旋锁。我们例子中使用了spin_lock_bh()锁在内核线程的执行路径中对链表进行保护；在下半部分,由于任务队列是串行执行并且不能被内核任务或系统调用打断，所以不必加锁。另外在卸载模块时，删除链表中仍然存在系统调用与下半部分的并发可能，因此也需要按上述方式加锁。

    除了对共享链表访问使用自旋锁以外，还有两个需要同步的地方，一是计数（count），该变量属于原子类型，用于记录链表接点的id。另外一个是利用信号量同步内核创建线程，调度keventd后执行被堵塞住(down)，等内核线程实际启动后, 才可继续执行（up）。

    结束

    并发的发生随处都有，但是由它引起的错误可并非每次都有，因为并发过程中引起错误的地方往往就一两步，因此交错执行这一两步要靠“运气”，出错的几率有时很小。但是一旦发生后果都是灾难性的，比如宕机，破坏数据完整性等。所以我们对并发绝不能掉以轻心，必须拿出“把纸老虎当真老虎的”决心来对待一切内核代码中可能的并发，即便在单处理器上编程也需要考虑到移植到多处理器的情况，总之一切都要谨慎小心。