为什么还需要工作队列？
工作队列（work queue）是另外一种将中断的部分工作推后的一种方式，它可以实现一些tasklet不能实现的工作，比如工作队列机制可以睡眠。这种差异的本质原因是，在工作队列机制中，将推后的工作交给一个称之为工作者线程（worker thread）的内核线程去完成（单核下一般会交给默认的线程events/0）。因此，在该机制中，当内核在执行中断的剩余工作时就处在进程上下文（process context）中。也就是说由工作队列所执行的中断代码会表现出进程的一些特性，最典型的就是可以重新调度甚至睡眠。
对于tasklet机制（中断处理程序也是如此），内核在执行时处于中断上下文（interrupt context）中。而中断上下文与进程毫无瓜葛，所以在中断上下文中就不能睡眠。
因此，选择tasklet还是工作队列来完成下半部分应该不难选择。当推后的那部分中断程序需要睡眠时，工作队列毫无疑问是你的最佳选择；否则，还是用tasklet吧。
中断上下文
在了解中断上下文时，先来回顾另一个熟悉概念：进程上下文（这个中文翻译真的不是很好理解，用“环境”比它好很多）。一般的进程运行在用户态，如果这个进程进行了系统调用，那么此时用户空间中的程序就进入了内核空间，并且称内核代表该进程运行于内核空间中。由于用户空间和内核空间具有不同的地址映射，并且用户空间的进程要传递很多变量、参数给内核，内核也要保存用户进程的一些寄存器、变量等，以便系统调用结束后回到用户空间继续执行。这样就产生了进程上下文。
所谓的进程上下文，就是一个进程在执行的时候，CPU的所有寄存器中的值、进程的状态以及堆栈中的内容。当内核需要切换到另一个进程时（上下文切换），它需要保存当前进程的所有状态，即保存当前进程的进程上下文，以便再次执行该进程时，能够恢复切换时的状态继续执行。上述所说的工作队列所要做的工作都交给工作者线程来处理，因此它可以表现出进程的一些特性，比如说可以睡眠等。
对于中断而言，是硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理，中断上下文就可以理解为硬件传递过来的这些参数和内核需要保存的一些环境，主要是被中断的进程的环境。因此处于中断上下文的tasklet不会有睡眠这样的特性。
工作队列的使用
内核中通过下述结构体来表示一个具体的工作：
3 | unsigned long pending; //这个工作是否正在等待处理 |
4 | struct list_head
entry; //链接所有工作的链表，形成工作队列 |
5 | void (*func)( void *); //处理函数 |
8 | struct timer_list
timer; //延迟的工作队列所用到的定时器 |
而这些工作（结构体）链接成的链表就是所谓的工作队列。工作者线程会在被唤醒时执行链表上的所有工作，当一个工作被执行完毕后，相应的work_struct结构体也会被删除。当这个工作链表上没有工作时，工作线程就会休眠。
通过如下宏可以创建一个要推后的完成的工作:
1 | DECLARE_WORK(name, void (*func)( void *), void *data); |
也可以通过下述宏动态创建一个工作:
1 | INIT_WORK( struct work_struct
*work, void (*func)( void *), void *data); |
与tasklet类似，每个工作都有具体的工作队列处理函数，原型如下:
1 | void work_handler( void *data) |
将工作队列机制对应到具体的中断程序中，即那些被推后的工作将会在func所指向的那个工作队列处理函数中被执行。
实现了工作队列处理函数后，就需要schedule_work函数对这个工作进行调度，就像这样：
这样work会马上就被调度，一旦工作线程被唤醒，这个工作就会被执行（因为其所在工作队列会被执行）。
中断下半部-tasklet
tasklet的实现
tasklet（小任务）机制是中断处理下半部分最常用的一种方法，其使用也是非常简单的。正如在前文中你所知道的那样，一个使用tasklet的中断程序首先会通过执行中断处理程序来快速完成上半部分的工作，接着通过调用tasklet使得下半部分的工作得以完成。可以看到，下半部分被上半部分所调用，至于下半部分何时执行则属于内核的工作。对应到我们此刻所说的tasklet就是，在中断处理程序中，除了完成对中断的响应等工作，还要调用tasklet，如下图示。
tasklet由tasklet_struct结构体来表示，每一个这样的结构体就表示一个tasklet。在<linux/interrupt.h>中可以看到如下的定义：
3 | struct tasklet_struct
*next; |
6 | void (*func)(unsigned long ); |
在这个结构体中，第一个成员代表链表中的下一个tasklet。第二个变量代表此刻tasklet的状态，一般为TASKLET_STATE_SCHED,表示此tasklet已被调度且正准备运行；此变量还可取TASKLET_STATE_RUN，表示正在运行，但只用在多处理器的情况下。count成员是一个引用计数器，只有当其值为0时候，tasklet才会被激活；否则被禁止，不能被执行。而接下来的func变量很明显是一个函数指针，它指向tasklet处理函数，这个处理函数的唯一参数为data。
使用tasklet
在使用tasklet前，必须首先创建一个tasklet_struct类型的变量。通常有两种方法：静态创建和动态创建。这样官方的说法仍然使我们不能理解这两种创建到底是怎么一回事。不够透过源码来分析倒是可以搞明白。
在<linux/interrupt.h>中的两个宏：
1 | 464#define
DECLARE_TASKLET(name, func, data) \ |
2 | 465struct
tasklet_struct name = { NULL, 0, ATOMIC_INIT(0), func, data } |
4 | 467#define
DECLARE_TASKLET_DISABLED(name, func, data) \ |
5 | 468struct
tasklet_struct name = { NULL, 0, ATOMIC_INIT(1), func, data } |
就是我们进行静态创建tasklet的两种方法。通过第一个宏创建的tasklet处于激活状态，再通过调度函数被挂起尽而被内核执行；而通过第二个宏创建的tasklet处于禁止状态。从两个宏的定义可以看到，所谓的静态创建就是直接定义个一个名为name的tasklet_struct类型的变量，并将宏中各个参数相应的赋值给这个name变量的各个成员。注意，两个宏在功能上差异就在于对name变量count成员的赋值上，具体原因在第一部分已经说明。也许你对ATOMIC_INIT这样的初始化方式感到疑惑，那么看完定义后，你就会一目了然：
1 | //在arch/x86/include/asm/atomic.h中 |
2 | 15#define
ATOMIC_INIT(i) { (i) } |
与静态创建相对的是动态创建，通过给tasklet_init函数传递一个事先定义的指针，来动态创建一个tasklet。这个函数源码如下。
1 | 470void
tasklet_init( struct tasklet_struct
*t, |
2 | 471 void (*func)(unsigned long ),
unsigned long data) |
6 | 475
atomic_set(&t->count, 0); |
相信你在阅读上面的代码是基本上没有什么难以理解的地方，不过这里还是要特别说明一下atomic_set函数：
1 | //在arch/x86/include/asm/atomic.h中 |
2 | 35static inline void atomic_set(atomic_t
*v, int i) |
首先tasklet_init当中，将&t->count传递给了此函数。也就是说将atomic_t类型的成员count的地址传递给了atomic_set函数。而我们在此函数中却要为count变量中的成员counter赋值。如果说我们当前要使用i，那么应该是如下的引用方法：t-》count.i。明白了吗？
ok，通过上述两种方法就可以创建一个tasklet了。同时，你应该注意到不管是上述那种创建方式都有func参数。透过上述分析的源码，我们可以看到func参数是一个函数指针，它指向的是这样的一个函数：
1 | void tasklet_handler(unsigned long data); |
如同上半部分的中断处理程序一样，这个函数需要我们自己来实现。
创建好之后，我们还要通过如下的方法对tasklet进行调度：
1 | tasklet_schedule(&my_tasklet) |
通过此函数的调用，我们的tasklet就会被挂起，等待机会被执行
