摘要：近几年来，协程在服务器中的解决方案开始涌现。本文主要阐述以汇编实现上下文切换的协程方案，并且说明其在异步开发模式中的应用。协程原理协程的实现，涉及两个内容协程调度上下文切换协程的调度协程调度的原理，往大了说，其实和线程进程的调度原理无异。
近几年来，协程在 C/C++ 服务器中的解决方案开始涌现。本文主要阐述以汇编实现上下文切换的协程方案，并且说明其在异步开发模式中的应用。
本文地址：https://segmentfault.com/a/1190000013070736
首先，我们来看一下 C/C++ 服务器开发的历史。
参考资料协程 - 维基百科，自由的百科全书
异步IO - 维基百科，自由的百科全书
基于 epoll 设计类似 libevent 的异步 I/O 库 - 接口
系统调用真正的效率瓶颈在哪里？
python协程是什么？——这个讨论页其实不单论 Python，其实大部分是从语言无关的角度回答了协程是什么
传统的 C/C++ 服务器设计框架 同步 I/O 框架长期以来，使用 C/C++ 编写服务器程序的时候，往往使用的是多进程模式：一个父进程负责 accept 传入连接，然后 fork 一个子进程处理；或者是一个父进程创建了一个 socket 之后，fork 出多个子进程同时执行 accept 和处理。
为什么说这是同步呢？因为这个设计思路，完全就是教科书般的、对于 socket 处理的思路。这个思路我在我关于 libev 的介绍文后的评论中也提及：
科班出身的软件专业往往会简单学到 socket, bind, connect, accept, read, write 等等一路下来的 API。正好，如果真的是按顺序这样调用下来，然后写了一个 server / client 的话，可以算是一种同步 I/O 的编程思路。
程序执行的每一步系统调用，都会阻塞住（直接的结果就是导致进程切换），等待远端机器的响应，并且直到数据到达之后，才会执行下一步。这就是典型的同步（阻塞） I/O。
上面的每步流程如果简单写下来的话，支撑不起高并发，因为阻塞的存在。为了解决这个问题，加入 fork，就可以实现对多个客户端的服务了。
同步开发模式同步 I/O 框架，使用的是同步开发模式。人的思维，是同步化的，先做什么后做什么，都是一条线式的流程。这样一条线从头到尾的开发模式，就是同步开发模式，非常符合人的思路习惯，便于设计、理解。
同步 I/O 的优势简单、一目了然——同步 I/O 框架中，使用同步开发模式，因此设计出来的程序代码简洁、明确。
bug 少——其实这上面已经讲了，程序简洁、明确、易于理解，也就容易 debug 了。
柔性高——一个服务以一个进程的模式存在，如果程序有 bug，崩溃了，也不会影响到其他的服务。此外，如果子进程是处理完连接就直接 exit 退出的话，那么几乎不用考虑内存泄露的问题——进程创建的所有资源都会被操作系统回收。
同步 I/O 的劣势效率低——fork 设计进程间切换，这是一个需要陷入内核的操作，耗时长，对于高并发场景，对服务器资源的利用效率很低。
进程间同步复杂——进程什么时候占用 CPU、什么时候被切换掉，这是无法预料的，因此进程间需要做好同步。多进程同步的 debug 是非常非常复杂的。
进程间通信复杂——这个没什么好说的，进程间通信，够写一本书了。这一点，在各任务之间还需要通信的场景中，反而加大了开发复杂度。
吐槽一下，本人进入工作后就见到的第一个服务器就是基于 libevent 设计的，并且整个团队都一直这么设计，以至于我曾经以为同步 I/O 根本没人用……
首先讲从技术层面的 “异步 I/O 框架” 是怎么回事。维基百科上对 “异步 IO” 的定义是：
发起IO请求的线程不等IO操作完成，就继续执行随后的代码，IO结果用其他方式通知发起IO请求的程序。
也就是说，某个进程 or 线程，需要告诉操作系统：我需要在某个文件描述符或句柄上 read 或 write，但是进程 or 线程并不等待 read 或 write ready，而是等到真正有数据可读或可写入数据的时候，再执行相应的操作。
其实 read / write 一早就在理论上对这样的操作提供了支持，那就是 O_NONBLOCK 标志。当对 socket 设置了该标志后，如果执行 read / write，资源暂时不可用的话，会返回响应的错误。此时，程序就可以跳过这个句柄，去查看下一个资源了。
但这个方案显然是不现实的，因为当客户端数量很大的时候，对所有的资源都需要进行轮询操作，这是对 CPU 时间的极大浪费，也极大地拉低了服务的响应速度。因此，操作系统需要提供定义的后半段：“通知”。
实现 “通知” 的办法，其实就是一个系统调用：select。其实 select 的效率很低，一般操作系统会提供替代。对于 Linux 而言，就是 epoll。关于异步 I/O 原理和编程，我的文章有很多了，可以点击这里查看。
从技术层面上，异步 I/O 框架有以下的优势：
效率高——判断那个资源上的事件 ready，至少是 O(NlogN) 的复杂度，效率极高
单线程多任务——单一一个线程就可以处理多个传入请求，达到伪并行的效果，没有进程/线程切换，大大提高了处理速度，优化了 CPU 使用率
同一线程中没有同步问题——同一线程的多任务如果需要相互通信，那么完全没有竞争和同步的问题
然而，单线程多任务其实也是很大的一个劣势——多个任务都在一个线程 / 进程中处理，如果程序有 bug，那么整个进程都会崩溃，这对服务器的开发质量要求很高。
异步开发模式异步 I/O 框架，大部分使用的就是异步开发模式。我们先不用这个词汇吧，换成大家比较熟悉的词。下面两个词，其实都可以解释什么叫异步开发模式：
基于事件驱动的开发模式
状态机编程
异步开发模式它是基于事件驱动的，当什么事件到来，就调用哪个回调进行处理——或者是回调判断发生了什么事件，再调用不同的函数处理。这与我们传统的思维不同，因此很大程度上，我们需要画状态机，才能很好地解释我们的软件逻辑。
其实，异步开发的世界中，满是各种回调以及回调的注册。如果我们不是相应的业务代码的开发者，那么走读代码时，看到一段函数执行完后，我们根本不知道这段函数的调用方是谁，从而也就无法跟踪判断下一段代码是什么。
这就给调试带来了极大的困难。其实即便是程序的开发者，如果文档不足的话，当时间长了之后，恐怕也会忘记自己当时的业务逻辑了吧……因此，异步开发模式对开发者的水平和团队编程风格的要求很高。
但是异步开发模式也有很大的优点，那就是状态机编程。这其实很好理解，对于那种逻辑并不是一整条简单的直线，而是有着非常多的分叉——有很多外部触发条件、并且会导致很多不同状态切换的程序而言，异步开发模式简直是福音。
比如电梯，一个正运行中的电梯，其执行逻辑很容易被某一楼层用户按下按钮这一动作中断。电梯需要对用户的操作进行及时的响应，以决定自己接下来应该采取什么操作。
一个电梯，至少有以下几个阶段，中断可能发生在电梯运行中的任何一个阶段：
电梯静止，门已经关闭
电梯静止，门已经打开
电梯静止，门正在打开
电梯静止，门正在关闭
电梯匀速运行
电梯加速运行
电梯减速运行
电梯故障异常
电梯检修
此外，中断的类型还可能是多种多样：
管理员直接下达指令操作
同楼层用户按下
不同楼层用户按下
如果使用同步开发模式，这样的逻辑简直是灾难！
协程前文我刻意将同步开发模式和同步 I/O、异步开发模式和异步 I/O 分开来说明。确实，开发模式和技术手段是两码事。在逻辑比较线性的（相比起上面 “电梯” 的例子）服务（特别是海量服务）而言，我们最理想的开发方案就是：
使用同步开发模式——最适合人脑的思维方式，同时也便于进行程序的调试和 debug
使用异步 I/O 技术——效率最高的底层实现
曾经我以为这两者的结合在 C/C++ 上是无法实现的，直到我换了东家之后才知道，原来可以这么玩——
协程简介协程，作为一种服务器组件，在多种高级语言中存在。相比起线程和进程而言，它的切换非常速度快（不用陷入内核态，没有系统调用），很适合在海量服务中使用。
但是在以 C/C++ 为主的中级语言服务器开发中，一直没有大规模引入。原因是，C/C++ 实在是太接近底层了，汇编后的目标文件，直接就是汇编语言代码；而汇编语言的下面，则直接就是虚拟内存了，能够对其施加影响的，只有操作着更加底层（硬件寄存器）的操作系统。
但是其他高级语言不同，比如 Java。Java 在原理上是解释型语言，但是从开发者的角度，其实和编译型语言无异，只是它把代码编译成了由 JVM 可以识别的程序罢了。这样，在真正执行的程序（二进制代码）和程序代码之间，JVM 可以提供一个中间层——以往由操作系统执行的任务调度和上下文切换，JVM 可以接管过来，在用户态中完成。这就是协程的实现。
协程原理协程的实现，涉及两个内容：
协程调度
上下文切换
C/C++ 协程的调度协程调度的原理，往大了说，其实和线程 / 进程的调度原理无异。这里分抢占和非抢占两种了。对于 C/C++ 而言。
要实现抢占式很难，而且也没太大必要，因为花了很大力气实现抢占式的协程调度，反而失去了前文提到的 “同一线程中没有同步问题” 这一优势了。
所以，针对 C/C++ 协程，最好的方式就是使用非抢占式调度，需要任务通过某些调用主动让出 CPU 使用权。再进一步具体化到服务器编程中，由于每一个合法的传入连接的优先级是相同的，因此只需要使用基于 epoll 的实现来进行简单调度就行了。
基于汇编实现的 C/C++ 协程的上下文切换上下文切换，是 C/C++ 协程的一大难题，这也是导致了 C/C++ 长期没有可用的、统一的协程库的原因。这一部分行文比较长，我还是放在下一篇文章里面讲吧。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/10431.html
摘要：限制协程应用的最大技术条件是上下文切换。既然本系列讲的是基于汇编的协程，那么这篇文章我们就来讲讲使用汇编来进行上下文切换的原理。切换上下文也称为保存现场和恢复现场。协程结束后，会返回到函数中。 在前一篇文章《基于汇编的 C/C++ 协程 - 背景知识》中提到一个用于 C/C++ 的协程所需要实现的两大功能： 协程调度 上下文切换 其中调度，其实在技术实现上与其他的线程、进程调度没有...
摘要：也就是现代操作系统的虚拟内存空间。有在两个进程之间切换状态的时候，需要把内存的映射关系调整过来，否则虚拟内存的地址是无法对应到正确的物理地址的。但是原理是非常类似的。协程与线程的区别在于，协程的是在完全在用户态，由语言的或者是库来完成的。 TL;DR 笔者最美好的记忆来自于早年在6502 cpu的cc800上写汇编的年代， 那个时代的计算机甚至没有操作系统，也没有实模式等保护机制。在...
摘要：在禁止场景中使用协程会出现各种莫名其妙的问题发生。限制了协程的应用范围。新版本基于汇编代码实现了全新的协程内核。实现了对所有语法的支持。稳定性和健壮性均已达到工业级的水准。完全可用于大型项目的生产环境中。 Swoole虽然在2016年就支持了协程特性，但由于底层是基于setjmp/longjmp实现的stackless方案。因此在某些场景下，如call_user_func、array_...
摘要：一次为了蹭讲座票的缘故集齐讲座票是毕业要求之一去听了一场机器学习汇报的讲座，感觉预测模型很有意思，回来以后就赶紧在网上寻找相关的内容，语言便进入了我的视野。 六...
摘要：所以子程序调用是通过栈实现的，子程序调用总是一个入口，一次返回，调用顺序是明确的。栈保存的数据，指令通过寄存器控制。所以需要多个栈来维护。由于栈是从高到底，此处的意思表示预留字节的栈空间。 我们先弄清如何进行协程的切换，程序可以在某个地方挂起，跳转到另外的流程中执行，并且可以重新在挂起处继续运行。那如何实现呢？ 我们先来看一个例子，有下面2个函数，如果在一个单线程中让输出结果依次是 f...
阅读 2602·2021-11-24 09:39
阅读 2659·2021-09-29 09:34
阅读 3541·2021-09-23 11:51
阅读 2769·2021-09-22 15:59
阅读 584·2021-09-09 11:37
阅读 1872·2021-09-08 09:45
阅读 2635·2021-09-04 16:45
阅读 1090·2019-08-30 15:54
