许多驱动程序需要将任务延迟到以后处理，但又不想借助中断。Linux 为此提供了三种方法：任务队列、tasklet（从内核 2.3.43 开始）和内核定时器。任务队列和 tasklet 的使用很灵活，可以或长或短地延迟任务到以后处理，在编写中断处理程序时非常有用，我们还将在第9章“Tasklet和底半部处理”一节中继续讨论。内核定时器则用来调度任务在未来某个指定时间执行，将在本章的“内核定时器”一节中讨论。

使用任务队列或tasklet的一个典型情形是，硬件不产生中断，但仍希望提供阻塞型的读取。此时需要对设备进行轮询，同时要小心地不使 CPU 负担过多无谓的操作。将读进程以固定的时间间隔唤醒（例如，使用 current->timeout 变量）并不是个很好的方法，因为每次轮询需要两次上下文切换（一次是切换到读进程中运行轮询代码，另一次是返回执行实际工作的某个进程），而且通常来讲，恰当的轮询机制应该在进程上下文之外实现。

类似的情形还有象不时地给简单的硬件设备提供输入。例如，有一个直接连接到并口的步进马达，要求该马达能一步步地移动，但马达每次只能移动一步。在这种情况下，由控制进程通知设备驱动程序进行移动，但实际上，移动是在 write 返回后，才在周期性的时间间隔内一步一步进行的。

快速完成这类不定操作的恰当方法是注册任务在未来执行。内核提供了对“任务队列”的支持，任务可以累积，而在运行队列时被“消耗”。我们可以声明自己的任务队列，并且在任意时刻触发它，或者也可以将任务注册到预定义的任务队列中去，由内核来运行（触发）它。

任务队列的本质

任务队列其实是一个任务链表，每个任务用一个函数指针和一个参数表示。任务运行时，它接受一个void * 类型的参数，返回值类型为 void，而指针参数可用来将一个数据结构传入函数，或者可以被忽略。队列本身是一个结构（即任务）链表，并由声明和操纵它们的内核模块所拥有。模块要全权负责这些数据结构的分配和释放，为此一般使用静态的数据结构。

队列元素由下面这个结构来描述，这段代码是直接从头文件 拷贝下来的：

struct tq_struct {

struct tq_struct *next; /* linked list of active bh's */

int sync; /* must be initialized to zero */

void (*routine)(void *); /* function to call */

void *data; /* argument to function */

};

第一个注释中的 bh 指的是底半部（bottom-half）。底半部是“中断处理程序的一半部”，我们将在第9章的“tasklet和底半部”一节中介绍中断时详细讨论。现在，我们只要知道底半部是驱动程序实现的一种机制就可以了，它用于处理异步任务，这些任务通常比较大，不适于在处理硬件中断时完成。本章并不要求你理解底半部处理，但必要时也会偶尔提及。

译注：在2.4版本的内核中，tq_struct的第一个成员变量已经有所不同，改为

struct list_head list; /* linked list of active bh's */

这是因为通用的双向链表 list_head在内核中大量采用，在很多情况下替代了数据结构中自行维护的链表。相应的task_queue的定义也改为

typedef struct list_head task_queue;

上面的数据结构中最重要的成员是routine和data。为了将随后执行的任务排队，必须先设置好结构的这些成员，并把 next 和 sync 两个字段清零。结构中的 sync 标志位由内核使用，以避免同一任务被插入多次，因为这会破坏 next 指针。一旦任务被排队，该数据结构就被认为由内核“拥有”了，不能再被修改，直到任务开始运行。

与任务队列有关的其他数据结构还有 task_queue，目前它实现为指向 tq_struct 结构的指针，之所以将这个指针(struct tq_struct* )定义成另一个数据结构（struct task_queue）是为了扩展的需要, 在需要的时候，task_queue结构中可以增加别的内容。

在使用之前，必须将 task_queue 指针初始化为 NULL。

下面汇总了所有可以在任务队列和 tq_struct 结构上执行的操作。

DECLARE_TASK_QUEUE(name);

这个宏用给定的名称 name 声明了一个任务队列，并把它初始化为空。

int queue_task(struct tq_struct *task, task_queue *list);

正如该函数的名字，它用于将任务排进队列中。如果队列中已有该任务，返回 0，否则返回非 0。

void run_task_queue(task_queue *list);

run_task_queue函数用于运行累积在队列上的任务。除非你要声明和维护自己的任务队列，否则不必调用本函数。

如前所述，一个任务队列，实际上是一个函数链表。当调用 run_task_queue 运行某个队列时，列表中的每一项都会被执行。在编写和任务队列有关的函数时，必须牢记内核是在什么时候调用run_task_queue的，而且当内核调用 run_task_queue 时，实际的上下文将限制能够进行的操作。也不应对队列中任务的运行顺序做任何假定，它们每个都是独立完成自己的任务的。

那么任务队列在什么时候运行呢？如果使用的是下面一节介绍的预定义的任务队列，则答案是“在内核轮到它那里时”。不同的队列在不同的时间运行，只要内核没有其他更紧要的任务，它们总是会运行的。

更重要的是，当对任务进行排队的进程运行时，任务队列几乎肯定是不会运行的，相反，它们是异步执行的。到现在为止，示例驱动例程中所有的事情都是在这个执行系统调用的进程上下文中完成的。但当任务队列运行时，这个进程可能正在睡眠，或正在另一个处理器上运行，甚至可能已经完全退出了。

这种异步执行类似于硬件中断发生时的情景（我们会在第9章详细讨论）。实际上，任务队列常常是作为“软件中断”的结果而运行的。在中断模式（或中断期间）下，代码的运行会受到许多限制。我们现在介绍这些限制，这些限制还会在本书后面多次出现。我们也会多次重复，中断模式下的这些规则必须遵守，否则系统会有大麻烦。

许多动作需要在进程上下文中才能执行。如果处于进程上下文之外（比如在中断模式下），则必须遵守如下规则：

• 不允许访问用户空间。因为没有进程上下文，也就没有办法访问与任何一个特定进程相关联的用户空间。
• current指针在中断模式下是无效的，不能使用。
• 不能执行睡眠或调度。中断模式代码不可以调用schedule或者sleep_on；也不能调用任何可能引起睡眠的函数。例如，调用kmalloc(...,GFP_KERNEL)就不符合本规则。信号量也不能用，因为可能引起睡眠。

内核代码可以通过调用函数in_interrupt( ) 来判断自己是否正运行于中断模式，该函数无需参数，如果处理器在中断期间运行就返回非0值。

当前的任务队列实现还有一个特性，队列中的一个任务可以将自己重新插回到它原先所在的队列。举个例子，定时器队列中的任务可以在运行时将自己插回到定时器队列中去，从而在下一个定时器滴答又再次被运行。这是通过调用 queue_task 把自己放回队列来实现的。由于在处理任务队列之前，是先用NULL指针替换队列的头指针，也就是将任务队列初始化了，另外，在执行队列中的任务之前，首先将任务从队列中移出来，这样在任务将本身插入任务队列的时候，它其实是将指针指向新的任务队列。结果就是，随着旧队列的执行，新的队列逐渐生成。

尽管一遍遍地重新调度同一个任务看起来似乎没什么意义，但有时这也有些用处。例如，步进马达每次移动一步直到目的地，它的驱动程序就可以通过让任务在定时器队列上不断地重新调度自己来实现。其他的例子还有 jiq 模块，该模块中的打印函数通过重新调度自己来产生输出――结果是利用定时器队列产生多次迭代。

预定义的任务队列

延迟任务执行的最简单方法是使用由内核维护的任务队列。这种队列有好几种，但驱动程序只能使用下面列出的其中三种。任务队列的定义在头文件 中，驱动程序代码需要包含该头文件。

调度器队列

调度器队列在预定义任务队列中比较独特，它运行在进程上下文中，这意味着该队列中的任务可以更多的事情。在Linux 2.4，该队列由一个专门的内核线程 keventd 管理，通过函数 schedule_task 访问。在较老的内核版本，没有用keventd，所以该队列（tq_scheduler）是直接操作的。

tq_timer

该队列由定时器处理程序（定时器嘀哒）运行。因为该处理程序（见函数do_timer）是在中断期间运行的，因此该队列中的所有任务也是在中断期间运行的。

tq_immediate

立即队列是在系统调用返回时或调度器运行时得到处理，以便尽可能快地运行该队列。该队列在中断期间得到处理。

还有其它的预定义队列，但驱动程序开发中通常不会涉及到它们。