workqueue 与异步执行
这页讲的是：有些工作不能现在做完，也不适合一直卡在原地等，于是 Linux 会把它们排进更合适的后台执行路径里。学这页的重点，是理解 workqueue 不是“线程池小技巧”，而是内核组织异步工作的重要方式。
这块是什么
workqueue 与异步执行，讲的是当某段工作不必立刻在当前上下文里完成，或者它更适合放到进程上下文慢慢做时，内核如何把这些工作登记、排队并在后面执行。它常被用来承接从中断或其他路径延后出来的任务。
可以把 workqueue 理解成“系统自己的后台待办队列”：先把事情记下来，安排到更能从容干活的时机和环境里完成。
它负责什么
承接延后工作
- 把当前不适合立刻做的事情先挂起来
- 让事件路径不被重活拖死
- 让中断或快路径只做最关键动作
- 把复杂处理转移到更从容的地方
提供更普通的执行环境
- 让后续工作处在更像“正常线程”的上下文
- 更适合处理较长逻辑
- 便于和睡眠、等待、资源获取等行为配合
- 把某些原本受限的事情放到能做的环境里
组织系统异步能力
- 给驱动和子系统提供统一异步机制
- 避免大家各自发明后台线程模型
- 让很多清理、重试、补做动作更可管理
- 让异步不是随意散落在代码里的技巧
为什么不能只靠“当场做完”
| 场景 | 如果硬要当场做完 | 为什么更适合异步 |
|---|
| 中断或快路径里来了一堆后续工作 | 会拉高关键路径延迟，让系统反应变钝。 | 先把事情挪走，保持前台路径更轻更稳。 |
| 后续工作本身更长 | 当前上下文会被拖住，影响其他任务推进。 | 放到后台慢慢做，更符合系统整体利益。 |
| 某些动作依赖更普通上下文 | 在受限环境里要么做不了，要么代价高。 | 换个执行环境，很多限制自然解除。 |
| 需要统一管理很多异步任务 | 每个子系统各搞一套，行为难预测，也难维护。 | 用统一机制更容易建立稳定心智模型。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| workqueue | 内核里组织后台工作执行的一套通用机制。 |
| work item | 被放进待办队列、等待后续执行的那份具体工作。 |
| 异步执行 | 不是现在阻塞着做完，而是把工作安排到后面继续做。 |
| 进程上下文 | 比中断上下文更从容、限制更少的一类执行环境。 |
| 延迟工作 | 不只是“晚一点做”，更是“在更合适条件下再做”。 |
为什么重要
- 它帮助你理解内核里“后台执行”到底是怎么被组织起来的。
- 很多驱动、清理路径、重试路径和延后补做动作，都会依赖这套机制。
- 理解 workqueue 后，你会更清楚为什么很多快路径代码显得很短，但真正工作并没有少。
- 它把异步执行从零散技巧变成系统性的组织能力。
常见误解
- 误解一：workqueue 只是某种实现细节。实际上它体现的是“哪些工作该换个环境做”的系统思路。
- 误解二：异步执行就是以后再说。实际上它是为了保持关键路径健康、并给后续工作正确上下文。
- 误解三：有了 workqueue 就不需要别的延后处理。实际上不同机制面对的是不同上下文和时效需求。
它不负责什么
- 它不替代软中断；前者更像后台处理平台，后者更像快速承接中断后续工作的一层。
- 它不定义业务逻辑本身，只负责把工作在更合适的地方执行。
- 它不自动解决并发问题，异步后任务之间的协调仍然要认真处理。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| Core API | workqueue 本身就是公共基础设施里最常见的一项。 |
| 中断下半部 | 很多事件路径会先快速承接，再把更长的工作继续转交给 workqueue。 |
| 驱动 | 驱动里常有初始化后续、错误恢复、资源清理等工作放到这里。 |
| 并发控制 | 工作被异步化后，时序关系更复杂，也更需要同步和生命周期管理。 |
读完这页后，你应该能回答
- 为什么内核需要 workqueue 这类统一的异步执行机制？
- 为什么有些工作“不是不能做”，而是“不适合现在这个上下文做”？
- 为什么异步执行会和中断、驱动、生命周期管理一起反复出现？
后面适合继续问：什么样的事情更适合 softirq，什么样的事情更适合 workqueue？为什么 workqueue 经常和对象生命周期问题绑在一起？异步执行为什么会让调试更难？