一起分析Linux系统设计思想——05字符设备驱动之调度概念（同步异步等）

在学习资料满天飞的大环境下，知识变得非常零散，体系化的知识并不多，这就导致很多人每天都努力学习到感动自己，最终却收效甚微，甚至放弃学习。我的使命就是过滤掉大量的垃圾信息，将知识体系化，以短平快的方式直达问题本质，把大家从大海捞针的痛苦中解脱出来。

2.1 同步/异步

我们先定义一下什么叫做等待。等待就是什么都不做（比如睡觉 sleep，又称作睡眠等），或者做无意义的事（比如发呆 nop或查询，又称作忙等）。

同步一定意味着等待，但等待并不意味着同步。这取决于等待是否必须：如果是 必须的等待，那就意味着是同步；否则就是异步。

举个生活中的例子。比如你刚准备写一篇博客，但是突然感觉饿了，于是定了一份外卖。对于该场景可能会有如下两种情况：一种是你饿的实在不行了，两眼昏花，必须得等着外卖来了，吃了饭才能去写博客，于是乎你就躺床上去休息了，或者发一会儿呆，干等着外卖的到来；还有一种是你虽然饿了，但还是有精力和力气去写博客的，这时你就可以选择去写博客，等外卖小哥到了按门铃你再停下来去开，当然你也可以选择不干活干等着外卖。对于第一种情况就一定要使用同步机制，而对于第二种情况就必须要采用异步手段。

聪明的小伙伴已经发现了一些端倪：同步场景更严苛，异步场景更灵活。因为同步的本质是 严格顺序执行 ，而异步的本质是 并发执行 。

2.2 中断并不一定都是异步的

如下图所示，硬件中断只可以实现异步机制，但是软件中断既可以实现异步机制，也可以实现同步机制。

需要注意的是 睡眠 和 唤醒 单独拿出哪一个都不是严格意义上的中断，它们只是软件中断的两个步骤。

2.3 whole、split、主动、被动

2.3.1 whole模式

所谓 whole模式 就是所设计的一个功能完全在一个函数中实现，函数中途可以等待，恢复之后继续运行。

上文已经分析过等待分为两种，一种是睡眠，一种是轮循。睡眠是直接让出CPU，轮循是占用CPU做查询或无意义的事。

所以，whole模式又分为两种：whole-interrupt和whole-pool。

2.3.1.1 whole-interrupt模式

如下图所示就是whole-interrupt模式。看起来是不是很眼熟？这不就是中断示意图么~~

在C语言（或其他高级语言）代码上来看，Function A1是一个整体；Function A1在运行期间，上下文A会让出CPU处于睡眠（暂停），过一段时间后重新获得CPU继续执行。

根据上下文A让出CPU的方式又可以分为两种情况：

1. 如果上下文A 在确定的位置 主动 让出CPU则为——中断实现同步 。比如阻塞（由软件中断实现，软件中断就是操作系统调度最底层的机制）或异常（但是异常后不会返回，不属于本小节讨论的问题）。
2. 如果上下文A 在随机位置 被动 让出CPU则为——中断实现异步。

---

2.3.1.2 whole-poll模式

如下图所示是whole-poll模式的示意图，进入轮循是主动进入，退出轮循也是主动退出。

这个模式大家很熟了，就不多说了。但值得提的一点是大家千万不要认为轮循就一定是低效的，因为上下文切换也是需要时间的，这个时间并不一定比轮循短。因此，要具体问题具体分析，比如DPDK速度比较快的一个原因就是用了轮循模式。

2.3.2 split模式

所谓 split模式 就是所设计的一个功能分割在不同函数中实现（例如Function A1和Function A2）。上半部函数（A1）运行完之后该功能让出CPU，等待某一个时机或事件，条件满足后下半部函数（A2）继续运行。

如果上下文A是线程上下文，则该图表示事件/消息驱动模型—— split-event模型；如果上下文A是中断上下文，则该图表示中断上半部-下半部模型—— split-interrupt模型 。

2.3.3 两种模式对比

whole模式编程简单，但功能过于复杂时容易造成响应性能降低。因此，使用该模式时，线程内的事件对于实时性的要求不能过高。

split模式编程较复杂，但是应对复杂功能，响应性能较好，可以支持更细的调度粒度。因次，使用该模式可以在线程内设计多个事件，而不会严重影响实时性。

---

2.4 同步机制

并发必然引起同步需求。

同步需求有下述两个原因：

1. 间接同步需求：需要共享临界资源。该同步需求又称为 互斥 。
2. 直接同步需求：两个并发/并行实体需要合作完成一项任务。

下面我们只讨论第2种同步情况。互斥我们后续再单独讨论。

2.4.1 睡眠与唤醒

睡眠与唤醒机制属于 whole-interrupt-中断实现同步 模式。

使用该机制实现AB同步的思路是：A为了等待B，在指定位置主动放弃CPU使用权，进入睡眠。当然，A选择进入睡眠之前一定要将自己塞入一个事先准备好的睡眠队列，等待B来唤醒自己，继续执行。

2.4.2 轮循与退出

轮循与退出机制属于whole-poll 模式。

使用该机制实现AB同步的思路是：A为了等待B，在指定位置不停轮循B是否做完了某件事，一旦发现做完就主动退出循环，继续执行。

2.4.3 依靠消息流实现同步

消息流属于split模式。TCP的三次握手和四次挥手就属于split模式的典型应用。而且，TCP通信的建立本身就是一系列同步过程。单处理机机内的上下文之间当然也可以应用该机制实现同步。

2.4.4 同步机制的本质

同步机制的本质就是实现排队等待。

2.5 异步机制

2.5.1 用中断实现异步

通过前面的分析，实现异步机制可以使用硬件中断、软件中断（信号）。既可以使用 whole-interrupt-中断实现异步 模式，也可以使用 split-interrupt 模式。

需要说明一点，中断实现异步时中断在逻辑上分为两种情况，一种是 中断正常事务 ，一种是 中断非必须的等待。特别强调这一点是为了让大家严格区分唤醒和中断的含义——注意唤醒的是 必须的等待 ，唤醒不是严格意义上的中断 。

2.5.2 依靠消息实现异步

该种方式与中断相比更适合大型工程的分层解耦合设计，但是实时性相对中断要低。

2.5.2.1 中断与事件触发的异同

中断属于事件触发的一种。

狭义上的中断必须是：A.暂停当前所做的事；B.去做一件更重要的事；C.然后 迅速返回 执行当前所做的事。

而广义上的中断就仅仅是：A.停止当前所做的事；B.去做一件更重要的事。返不返回并不重要，比如 异常。

事件触发的流程就更短了，只保留了B过程。

2.5.2.2 依靠消息实现异步

消息是承载信息的事件。因此，天然携带事件触发的特性。

如果进程A绑定了一个消息队列，它会不断监听该消息队列中的消息。当然，监听的“同时”也会解析其他消息携带的信息并执行相关动作。此时，一个与其他消息 无关 的消息的 意外 到来就是一个异步事件。

注意，关键字 无关 和 意外 ，这是与用消息流实现同步机制的本质区别。

2.5.3 异步机制的本质

异步机制的本质就是实现插队（包含插在队尾的特殊情况）。

2.6 结语

概念分析虽然枯燥，但却十分重要。

下篇会给出一个实例，让这些概念鲜活起来~~~带你一起体会概念梳理清楚再写代码的通透感。

---

恭喜你又坚持看完了一篇博客，又进步了一点点！如果感觉还不错就点个赞再走吧，你的点赞和关注将是我持续输出的哒哒哒动力~~