关于workqueue，我们还是有很多话要说。

想必大家对workqueue相关的函数(schedule_work 、queue_work、INIT_WORK、create_singlethread_workqueue 等)都不陌生。但说起差异，可能还有许多话需要坐下来慢慢讲。

对于workqueue，与之最为相关的两个东西便是work和queue。

work是用来绑定实际执行函数使用的结构体

queue是用来链接work使用的队列。

具体的结构体，可以自己到/kernel/include/linux/workqueue.h中自行查看，这里不再赘述。

我们想关注的重点在于：

1：系统中是否有default的workqueue供我们使用

2：我们能否创建自己的workqueue？如何创建？

Yes！你说对了。linux系统所提供的workqueue机制中，已经帮忙提供了一个默认的workqueue队列“system_wq”，并提供了一套函数来方便大家直接使用。

例子来了：

static struct work_struct work;

INIT_WORK(&work, run);

schedule_work(&work);

static void run(struct work_struct *work)

{

Do something here！！

}

就这么简单的，当然，你也可以用DECLARE_WORK来完成和INIT_WORK同样初始化work的工作。区别是DECLARE_WORK是预编译命令，而INIT_WORK可以在code中动态初始化。

那么除了调用schedule_work直接把work放到系统default的workqueue中外，我们还有什么办法可以初始化自己的workqueue，并且放入work呢？

我们看看函数schedule_work的定义，一切就真相大白了！

static inline bool schedule_work(struct work_struct *work)

{

return queue_work(system_wq, work);

}

哈哈，原来schedule_work是把传入的work直接放入了系统的default workqueue “system_wq”中而已。

自然，我们只需要调用queue_work函数来绑定workqueue和work就ok啦！

初始化work的方法和前面一样，只要调用DECLARE_WORK或INIT_WORK就好了。

那么我们如何去创建自己的workqueue呢？

答案是：

#define alloc_ordered_workqueue(fmt, flags, args…)               \

alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | (flags), 1, ##args)

#define create_workqueue(name)                              \

alloc_workqueue((name), WQ_MEM_RECLAIM, 1)

#define create_freezable_workqueue(name)                    \

alloc_workqueue((name), WQ_FREEZABLE | WQ_UNBOUND | WQ_MEM_RECLAIM, 1)

#define create_singlethread_workqueue(name)                    \

alloc_workqueue((name), WQ_UNBOUND | WQ_MEM_RECLAIM, 1)

我们只要调用如上几种方法的某一种，即可创建属于自己的workqueue了。kernel中最常见到的函数是create_singlethread_workqueue。

我们只要拿这个函数举个例子就美好了，栗子来了！

static struct workqueue_struct *time_sync_wq;

time_sync_wq = create_singlethread_workqueue(“timesync“); //timesync就是workqueue的名字

static DECLARE_WORK(etr_work, etr_work_fn);

queue_work(time_sync_wq, &etr_work);

这样一来，我们的work和自己的workqueue就绑在一起了。

个人认为，自己新建wq最大的好处：可以避免system_wq中被挂的work过多，或者由于某个被挂上去的work处理函数质量不高导致死锁，而导致挂在同一个queue上的我们自己work的handler因为无法被调度到而完蛋了。

当然，建太多自己的workqueue，必然会导致系统调度开销的变大，所以需要取舍。

至于DELAYED_WORK

#define INIT_DELAYED_WORK(_work, _func)                         \

__INIT_DELAYED_WORK(_work, _func, 0)

queue_delayed_work

schedule_delayed_work

都和前面类似，就不再赘述了。

补充下：

咱们可以调用cancel_delayed_work来把还未执行的work给取消掉。

基本上每次 cancel_delayed_work 之后您都得调用flush_scheduled_work() 这个函数 , 特别是对于内核模块 , 如果一个模块使用了工作队列机制 , 并且利用了系统的default队列 , 那么在卸载这个模块之前 , 您必须得调用这个函数 , 这叫做刷新一个工作队列 , 也就是说 , 该函数会一直等待 , 直到队列中所有对象都被执行以后才返回 ，从而避免队列调度错误。

函数cancel_delayed_work_sync的出现，让新的流程变得更加简单了，大家参照kernel中的代码，很容易知道应该怎么用。

最后别忘了调用destroy_workqueue等清尾的函数哦~~

问题来了：

如果我们在handler的执行过程中，同时再次调用调度函数queue_work，那么我们的handler会被执行多少次呢？(执行被调度的次数，还是就只执行一次呢？)

解答：

这个问题比较有意思，写了这个例子来验证答案(例子跑在android 4.4 code base中，不排除后续kernel函数被修改)

sample test code：

static struct workqueue_struct *test_wq;

static void try_to_test(struct work_struct *work){printk(“[bevis] :wq into \n”);

msleep(5*1000);  //5s

printk(“[bevis] :wq out \n”);

}

static DECLARE_WORK(mytest_work, try_to_test);

gsensor probe function end add :

test_wq =alloc_ordered_workqueue(“test_wq”, 0);//初始化一个单独的工作队列

int a = 0;

for(a=0 ; a<3 ; a++){

printk(“[bevis] : read func (%d) before \n”,a);

queue_work(test_wq, &mytest_work);//让这个队列开始被调度

printk(“[bevis] : read func (%d) msleep 2s \n”,a);

msleep(2*1000);

printk(“[bevis] : read func (%d) after \n”,a);

}

log如下：

10-16 14:10:41.940 I/KERNEL  (  109): [    6.954658] [bevis] : read func (0) before

10-16 14:10:41.940 I/KERNEL  (  109): [    6.954727] [bevis] : read func (0) msleep 2s

10-16 14:10:41.940 I/KERNEL  (  109): [    6.954742] [bevis] :wq into

10-16 14:10:43.950 I/KERNEL  (  109): [    8.960997] [bevis] : read func (0) after

10-16 14:10:43.950 I/KERNEL  (  109): [    8.961085] [bevis] : read func (1) before

10-16 14:10:43.950 I/KERNEL  (  109): [    8.961155] [bevis] : read func (1) msleep 2s

10-16 14:10:45.960 I/KERNEL  (  109): [   10.971954] [bevis] : read func (1) after

10-16 14:10:45.960 I/KERNEL  (  109): [   10.972076] [bevis] : read func (2) before

10-16 14:10:45.960 I/KERNEL  (  109): [   10.972132] [bevis] : read func (2) msleep 2s

10-16 14:10:46.950 I/KERNEL  (    6):  [   11.961884] [bevis] :wq out

10-16 14:10:46.950 I/KERNEL  (    6):  [   11.961953] [bevis] :wq into

10-16 14:10:47.970 I/KERNEL  (  109): [   12.982276] [bevis] : read func (2) after

10-16 14:10:51.960 I/KERNEL  (    6):  [   16.973719] [bevis] :wq out

看到了吧，虽然我们使用queue_work函数调度了三次handler，但实际上wq的handler只被执行了两次。

如果把probe函数的delay直接拿掉，你更加会发现，即使wq被调度三次，handler却实际上只跑了一次。

结论：

如果wq被调度的时候，wq中的这个handler正在执行过程中，则这次调度会被遗弃。只有handler执行完成并返回后，下次调度才会真正的生效。

kernel这么做的原因，我猜想应该是为了防止，档某个wq的handler在执行过程中因为资源无法获取而暂时阻塞时，

不会因为其他进程再次调度了该wq而导致出现线程实例的不断累加。

实际上，在绝大多数情况下，我们只需要一个handler实例来帮忙做事就够了，例如earlysuspend的处理函数中，只要userspace进行想睡眠，那就直接调度suspend wq的handler，而不必管再关心上次的suspend过程是否有阻塞。

这样一来，逻辑就清爽多了。

如需转载，请注明出处。