tasklet vs 内核定时器
相同：始终在中断期间运行，始终会在调度他们的同一CPU上运行，而且都接收一个unsigned long参数
不同：不可以要求tasklet在某一给定的时间执行
tasklet对中断处理例程来说尤其有用。中断处理例程必须尽可能快的管理硬件中断，而大部分数据管理则可以安全的延迟到其后的时间。
实际上，与内核定时器类似，tasklet也会在“软件中断”上下文以原子模式执行。软件中断指打开硬件中断的同时执行某些异步任务的内核机制。
tasklet以数据结构形式存在，并在使用前必须初始化。调用特定的函数或者使用特定的宏来声明该结构，即可完成tasklet的初始化：
|
#include struct tasklet_struct{ /*......*/ void（*func）(unsigned long); unsigned long data; }; void tasklet_init(struct tasklet_struct *t,void (*func)(unsigned long),unsigned long data); #define DECLARE_TASKLET(name, func, data) \
|
tasklet特性：
1.一个tasklet可在稍后被禁止或者重新启用；只有启用的次数和禁止的次数相同时，tasklet才会被执行。
2.和定时器类似，tasklet可以自己注册自己。
3.tasklet可被调度以在通常的优先级或者高优先级执行。高优先级的tasklet总会优先执行。
4.如果系统负荷不重，则tasklet会立即执行，但始终不会晚于下一个定时器滴答
5.一个tasklet可以和其它tasklet并发，但对自身来讲是严格串行处理的，也就是说，同一tasklet永远不会在多个处理器上同时运行：tasklet始终会调度自己在同一CPU上运行；
工作队列表面来看，工作队列类似于tasklet：允许内核代码请求某个函数在将来的时间被调用。
但其实还是有很多不同：
1.tasklet在软中断上下文中运行，因此，所有的tasklet代码都是原子的。相反，工作队列函数在一个特殊的内核进程上下文中运行，因此他们有更好的灵活性
尤其是，工作队列可以休眠！
2.tasklet始终运行在被初始提交的统一处理器上，但这只是工作队列的默认方式
3.内核代码可以请求工作队列函数的执行延迟给定的时间间隔
4.tasklet 执行的很快, 短时期, 并且在原子态, 而工作队列函数可能是长周期且不需要是原子的，两个机制有它适合的情形。
两者的关键区别：tasklet会在很短的时间内很快执行，并且以原子模式执行，而工作队列函数可以具有更长的延迟并且不必原子化。两种机制有各自适合的情形。
2.工作队列
工作队列有 struct workqueue_struct 类型，在
|
struct workqueue_struct *create_workqueue(const char *name); |
每个工作队列有一个或多个专用的进程("内核线程"), 这些进程运行提交给这个队列的函数。 若使用 create_workqueue, 就得到一个工作队列它在系统的每个处理器上有一个专用的线程。在很多情况下，过多线程对系统性能有影响，如果单个线程就足够则使用 create_singlethread_workqueue 来创建工作队列。
提交一个任务给一个工作队列，在这里《LDD3》介绍的内核2.6.10和我用的新内核2.6.22.2已经有不同了，老接口已经不能用了，编译会出错。这里我只讲2.6.22.2的新接口，至于老的接口我想今后内核不会再有了。从这一点我们可以看出内核发展。
|
/*需要填充work_struct或delayed_work结构，可以在编译时完成, 宏如下: */ struct work_struct { |
在将来的某个时间, 这个工作函数将被传入给定的 data 值来调用。这个函数将在工作线程的上下文运行,
因此它可以睡眠 (你应当知道这个睡眠可能影响提交给同一个工作队列的其他任务) 工作函数不能访问用户空间，因为它在一个内核线程中运行,
完全没有对应的用户空间来访问。
取消一个挂起的工作队列入口项可以调用:
|
int cancel_delayed_work(struct delayed_work *work); |
如果这个入口在它开始执行前被取消，则返回非零。内核保证给定入口的执行不会在调用 cancel_delay_work 后被初始化. 如果 cancel_delay_work 返回 0, 但是, 这个入口可能已经运行在一个不同的处理器, 并且可能仍然在调用 cancel_delayed_work 后在运行. 要绝对确保工作函数没有在 cancel_delayed_work 返回 0 后在任何地方运行, 你必须跟随这个调用来调用:
|
void flush_workqueue(struct workqueue_struct *queue); |
在 flush_workqueue 返回后, 没有在这个调用前提交的函数在系统中任何地方运行。
而cancel_work_sync会取消相应的work，但是如果这个work已经在运行那么cancel_work_sync会阻塞，直到work完成并取消相应的work。
当用完一个工作队列，可以去掉它，使用:
|
void destroy_workqueue(struct workqueue_struct *queue); |
3.共享队列
在许多情况下, 设备驱动不需要它自己的工作队列。如果你只偶尔提交任务给队列, 简单地使用内核提供的共享的默认的队列可能更有效。若使用共享队列，就必须明白将和其他人共享它，这意味着不应当长时间独占队列(不能长时间睡眠), 并且可能要更长时间才能获得处理器。
使用的顺序：
（1） 建立 work_struct 或 delayed_work
|
static struct work_struct jiq_work; |
（2）提交工作
|
int schedule_work(&jiq_work);/*对于work_struct结构*/ /*返回值的定义和 queue_work 一样*/ |
若需取消一个已提交给工作队列入口项, 可以使用 cancel_delayed_work和cancel_work_sync， 但刷新共享队列需要一个特殊的函数:
|
void flush_scheduled_work(void); |
因为不知道谁可能使用这个队列，因此不可能知道 flush_schduled_work 返回需要多长时间。