汽车IVI中控OS Linux driver开发实操（二十二）：kernal的异步作业

Work queue

在许多情况下，需要异步流程执行上下文，而工作队列（wq）API是此类情况下最常用的机制。当需要这种异步执行上下文时，描述要执行哪个函数的工作项会被放入队列中。独立线程充当异步执行上下文。队列称为workqueue，线程称为worker。当工作队列上有工作项时，worker会一个接一个地执行与工作项关联的功能。当工作队列中没有剩余的工作项时，worker将处于空闲状态。当一个新的工作项排队时，worker将再次开始执行。

为什么使用并发管理工作队列？
在最初的wq实现中，多线程（MT）wq每个CPU有一个工作线程，单线程（ST）wq在系统范围内有一个工作者线程。单个MT wq需要保持与CPU数量大致相同的工人数量。多年来，内核增加了很多MT wq用户，随着CPU内核数量的不断增加，一些系统在启动时就饱和了默认的32k PID空间。

尽管MT wq浪费了大量资源，但提供的并发性水平并不令人满意。这种限制在ST和MT wq中都很常见，尽管在MT上不那么严重。每个wq都有自己的独立工人池。MT wq只能为每个CPU提供一个执行上下文，而ST wq则为整个系统提供一个。工作项必须竞争那些非常有限的执行上下文，导致各种问题，包括在单个执行上下文周围容易死锁。所提供的并发级别和资源使用之间的紧张关系也迫使其用户做出不必要的权衡，比如libata选择使用ST wq来轮询PIO，并接受不必要的限制，即没有两个轮询PIO可以同时进行。由于MT wq不能提供更好的并发性，需要更高并发级别的用户，如async或fscache，必须实现自己的线程池。

并发管理工作队列（cmwq）是wq的重新实现，重