一个设备驱动, 在许多情况下, 不需要它自己的工作队列. 如果你只偶尔提交任务给队列, 简单地使用内核提供的共享的, 缺省的队列可能更有效. 如果你使用这个队列, 但是, 你 必须明白你将和别的在共享它. 从另一个方面说, 这意味着你不应当长时间独占队列(无 长睡眠), 并且可能要更长时间它们轮到处理器.
jiq ("just in queue") 模块输出 2 个文件来演示共享队列的使用. 它们使用一个单个 work_struct structure, 这个结构这样建立:
static struct work_struct jiq_work;
/* this line is in jiq_init() */ INIT_WORK(&jiq_work, jiq_print_wq, &jiq_data);
当一个进程读 /proc/jiqwq, 这个模块不带延迟地初始化一系列通过共享的工作队列的路 线.
int schedule_work(struct work_struct *work);
注意, 当使用共享队列时使用了一个不同的函数; 它只要求 work_struct 结构作为一个 参数. 在 jiq 中的实际代码看来如此:
prepare_to_wait(&jiq_wait, &wait, TASK_INTERRUPTIBLE); schedule_work(&jiq_work);
schedule(); finish_wait(&jiq_wait, &wait);
这个实际的工作函数打印出一行就象 jit 模块所作的, 接着, 如果需要, 重新提交这个 work_structcture 到工作队列中. 在这是 jiq_print_wq 全部:
static void jiq_print_wq(void *ptr)
{
struct clientdata *data = (struct clientdata *) ptr;
if (! jiq_print (ptr)) return;
if (data->delay)
schedule_delayed_work(&jiq_work, data->delay);
else
}
schedule_work(&jiq_work);
如果用户在读被延后的设备 (/proc/jiqwqdelay), 这个工作函数重新提交它自己在延后 的模式, 使用 schedule_delayed_work:
int schedule_delayed_work(struct work_struct *work, unsigned long delay); 如果你看从这 2 个设备的输出, 它看来如:
% cat /proc/jiqwq
time delta preempt pid cpu command
|
1113043 |
0 |
0 |
7 |
1 |
events/1 |
|
1113043 |
0 |
0 |
7 |
1 |
events/1 |
|
1113043 |
0 |
0 |
7 |
1 |
events/1 |
|
1113043 |
0 |
0 |
7 |
1 |
events/1 |
|
1113043 |
0 |
0 |
7 |
1 |
events/1 |
% cat /proc/jiqwqdelay
time delta preempt pid cpu command 1122066 1 0 6 0 events/0
1122067 1 0 6 0 events/0
|
1122068 |
1 |
0 |
6 |
0 |
events/0 |
|
1122069 |
1 |
0 |
6 |
0 |
events/0 |
|
1122070 |
1 |
0 |
6 |
0 |
events/0 |
当 /proc/jiqwq 被读, 在每行的打印之间没有明显的延迟. 相反, 当 /proc/jiqwqdealy 被读时, 在每行之间有恰好一个 jiffy 的延时. 在每一种情况, 我们看到同样的进程名 子被打印; 它是实现共享队列的内核线程的名子. CPU 号被打印在斜线后面; 我们从不知 道当读 /proc 文件时哪个 CPU 会在运行, 但是这个工作函数之后将一直运行在同一个处 理器.
如果你需要取消一个已提交给工作队列的工作入口, 你可以使用 cancel_delayed_work, 如上面所述. 刷新共享队列需要一个不同的函数, 但是:
void flush_scheduled_work(void);
因为你不知道别人谁可能使用这个队列, 你从不真正知道 flush_schduled_work 返回可 能需要多长时间.