基于汇编的 C/C++ 协程 - 背景知识

近几年来,协程在 C/C++ 服务器中的解决方案开始涌现。本文主要阐述以汇编实现上下文切换的协程方案,并且说明其在异步开发模式中的应用。

本文对阅读者的知识储备有前提要求,那就是需要理解进程、线程、上下文切换等概念,并且了解在线程切换时,操作系统做了那些关键操作。

首先,我们来看一下 C/C++ 服务器开发的历史。

本文章采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。

原文发布于:https://segmentfault.com/a/1190000013070736,也是作者本人的专栏。


参考资料


传统的 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 的优势

  1. 简单、一目了然——同步 I/O 框架中,使用同步开发模式,因此设计出来的程序代码简洁、明确。
  2. bug 少——其实这上面已经讲了,程序简洁、明确、易于理解,也就容易 debug 了。
  3. 柔性高——一个服务以一个进程的模式存在,如果程序有 bug,崩溃了,也不会影响到其他的服务。此外,如果子进程是处理完连接就直接 exit 退出的话,那么几乎不用考虑内存泄露的问题——进程创建的所有资源都会被操作系统回收。

同步 I/O 的劣势

  1. 效率低——fork 设计进程间切换,这是一个需要陷入内核的操作,耗时长,对于高并发场景,对服务器资源的利用效率很低。
  2. 进程间同步复杂——进程什么时候占用 CPU、什么时候被切换掉,这是无法预料的,因此进程间需要做好同步。多进程同步的 debug 是非常非常复杂的。
  3. 进程间通信复杂——这个没什么好说的,进程间通信,够写一本书了。这一点,在各任务之间还需要通信的场景中,反而加大了开发复杂度。

吐槽一下,本人进入工作后就见到的第一个服务器就是基于 libevent 设计的,并且整个团队都一直这么开发,以至于我曾经以为同步 I/O 根本没人用……


异步 I/O 框架

首先讲从技术层面的 “异步 I/O 框架” 是怎么回事。维基百科上对 “异步 IO” 的定义是:

  • 发起IO请求的线程不等IO操作完成,就继续执行随后的代码,IO结果用其他方式通知发起IO请求的程序。

也就是说,某个进程 or 线程,需要告诉操作系统:我需要在某个文件描述符或句柄上 readwrite,但是进程 or 线程并不等待 readwrite ready,而是等到真正有数据可读或可写入数据的时候,再执行相应的操作。

其实 read / write 一早就在理论上对这样的操作提供了支持,那就是 O_NONBLOCK 标志。当对 socket 设置了该标志后,如果执行 read / write,资源暂时不可用的话,会返回响应的错误。此时,程序就可以跳过这个句柄,去查看下一个资源了。

但这个方案显然是不现实的,因为当客户端数量很大的时候,对所有的资源都需要进行轮询操作,这是对 CPU 时间的极大浪费,也极大地拉低了服务的响应速度。因此,操作系统需要提供定义的后半段:“通知”。

实现 “通知” 的办法,其实就是一个系统调用:select。其实 select 的效率很低,一般操作系统会提供替代。对于 Linux 而言,就是 epoll。关于异步 I/O 原理和编程,我的文章有很多了,可以点击这里查看。

从技术层面上,异步 I/O 框架有以下的优势:

  • 效率高——判断那个资源上的事件 ready,至少是 O(NlogN) 的复杂度,效率极高
  • 单线程多任务——单一一个线程就可以处理多个传入请求,达到伪并行的效果,没有进程/线程切换,大大提高了处理速度,优化了 CPU 使用率
  • 同一线程中没有同步问题——同一线程的多任务如果需要相互通信,那么完全没有竞争和同步的问题

然而,单线程多任务其实也是很大的一个劣势——多个任务都在一个线程 / 进程中处理,如果程序有 bug,那么整个进程都会崩溃,这对服务器的开发质量要求很高。

异步开发模式

异步 I/O 框架,大部分使用的就是异步开发模式。我们先不用这个词汇吧,换成大家比较熟悉的词。下面两个词,其实都可以解释什么叫异步开发模式:

  1. 基于事件驱动的开发模式
  2. 状态机编程

异步开发模式它是基于事件驱动的,当什么事件到来,就调用哪个回调进行处理——或者是回调判断发生了什么事件,再调用不同的函数处理。这与我们传统的思维不同,因此很大程度上,我们需要画状态机,才能很好地解释我们的软件逻辑。

异步开发模式的缺点

其实,异步开发的世界中,满是各种回调以及回调的注册。如果我们不是相应的业务代码的开发者,那么走读代码时,看到一段函数执行完后,我们根本不知道这段函数的调用方是谁,从而也就无法跟踪判断下一段代码是什么。

这就给调试带来了极大的困难。其实即便是程序的开发者,如果文档不足的话,当时间长了之后,恐怕也会忘记自己当时的业务逻辑了吧……因此,异步开发模式对开发者的水平和团队编程风格的要求很高。

异步开发模式的优点

但是异步开发模式也有很大的优点,那就是状态机编程。这其实很好理解,对于那种逻辑并不是一整条简单的直线,而是有着非常多的分叉——有很多外部触发条件、并且会导致很多不同状态切换的程序而言,异步开发模式简直是福音。

示例

比如电梯,一个正运行中的电梯,其执行逻辑很容易被某一楼层用户按下按钮这一动作中断。电梯需要对用户的操作进行及时的响应,以决定自己接下来应该采取什么操作。

一个电梯,至少有以下几个阶段,中断可能发生在电梯运行中的任何一个阶段:

  • 电梯静止,门已经关闭
  • 电梯静止,门已经打开
  • 电梯静止,门正在打开
  • 电梯静止,门正在关闭
  • 电梯匀速运行
  • 电梯加速运行
  • 电梯减速运行
  • 电梯故障异常
  • 电梯检修

此外,中断的类型还可能是多种多样:

  • 管理员直接下达指令操作
  • 同楼层用户按下
  • 不同楼层用户按下

如果使用同步开发模式,这样的逻辑简直是灾难!


协程

前文我刻意将同步开发模式和同步 I/O、异步开发模式和异步 I/O 分开来说明。确实,开发模式和技术手段是两码事。在逻辑比较线性的(相比起上面 “电梯” 的例子)服务(特别是海量服务)而言,我们最理想的开发方案就是:

  1. 使用同步开发模式——最适合人脑的思维方式,同时也便于进行程序的调试和 debug
  2. 使用异步 I/O 技术——效率最高的底层实现

曾经我以为这两者的结合在 C/C++ 上是无法实现的,直到我换了东家之后才知道,原来可以这么玩——


协程简介

协程,作为一种服务器组件,在多种高级语言中存在。相比起线程和进程而言,它的切换非常速度快(不用陷入内核态,没有系统调用),很适合在海量服务中使用。

但是在以 C/C++ 为主的中级语言服务器开发中,一直没有大规模引入。原因是,C/C++ 实在是太接近底层了,汇编后的目标文件,直接就是汇编语言代码;而汇编语言的下面,则直接就是虚拟内存了,能够对其施加影响的,只有操作着更加底层(硬件寄存器)的操作系统。

但是其他高级语言不同,比如 Java。Java 在原理上是解释型语言,但是从开发者的角度,其实和编译型语言无异,只是它把代码编译成了由 JVM 可以识别的程序罢了。这样,在真正执行的程序(二进制代码)和程序代码之间,JVM 可以提供一个中间层——以往由操作系统执行的任务调度和上下文切换,JVM 可以接管过来,在用户态中完成。这就是协程的实现。


协程原理

协程的实现,涉及两个内容:

  1. 协程调度
  2. 上下文切换

C/C++ 协程的调度

协程调度的原理,往大了说,其实和线程 / 进程的调度原理无异。这里分抢占和非抢占两种了。对于 C/C++ 而言。

要实现抢占式很难,而且也没太大必要,因为花了很大力气实现抢占式的协程调度,反而失去了前文提到的 “同一线程中没有同步问题” 这一优势了。

所以,针对 C/C++ 协程,最好的方式就是使用非抢占式调度,需要任务通过某些调用主动让出 CPU 使用权。再进一步具体化到服务器编程中,由于每一个合法的传入连接的优先级是相同的,因此只需要使用基于 epoll 的实现来进行简单调度就行了。

基于汇编实现的 C/C++ 协程的上下文切换

上下文切换,是 C/C++ 协程的一大难题,这也是导致了 C/C++ 长期没有可用的、统一的协程库的原因。这一部分行文比较长,我还是放在下一篇文章里面讲吧。


本文章采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。

原文发布于:https://segmentfault.com/a/1190000013070736,也是作者本人的专栏。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

自动化沙箱打造之“关于XShell我有话说”

最近XShell很是火了一把,每个安全厂商都在发通告,都在分析,反正就是百花齐放,在这里我想做一个总结,从前些时间的勒索软件到今天的xshell,其实我们可以看...

34660
来自专栏EAWorld

全网首发:逐一解读云原生应用开发“12-Factors”

作者自序: 12原则的提出已有五年之久,可惜业界一直缺乏一篇对其进行简明解读的指导性文章,所以我决定写这样一篇文章。在微服务模式的大背景下,力求对12原则的来龙...

35980
来自专栏架构师之路

服务读写分离架构,绝不推荐

缘起 在《服务读写分离(读服务,写服务),是否可行?》中,对背景做了交代,互联网架构设计上,数据库可以读写分离,服务能否读写分离呢? 下面是两种常见的“服务读写...

508110
来自专栏纯洁的微笑

电商平台备战促销季的运维秘诀——高可用服务层

13520
来自专栏后端技术探索

纯干货--秒杀系统架构分析与实战

(1)查询商品;(2)创建订单;(3)扣减库存;(4)更新订单;(5)付款;(6)卖家发货

40940
来自专栏FreeBuf

利用HTTP参数污染方式绕过谷歌reCAPTCHA验证机制

今年初,我上报了一个谷歌reCAPTCHA验证码绕过漏洞,该漏洞在于能用一种HTTP参数污染的不安全方式,让Web页面上的reCAPTCHA构造一个针对 /re...

57830
来自专栏北京马哥教育

大型网站的灵魂——性能

Via: http://blog.jobbole.com/84433/ 前言 在前一篇随笔《大型网站系统架构的演化》中,介绍了大型网站的演化过程,期间穿插了一...

37260
来自专栏顾宇的研习笔记

AWS 上的生产环境架构优化案例

在AWS 上的生产环境性能分析案例一文中,记录了我对客户应用生产环境的一次性能分析。接下来,我们要根据所发现的性能问题进行架构优化,以提升可用性和性能。同时,这...

19110
来自专栏机器学习算法与Python学习

Python中常用的一些架构

在各种语言平台中,python涌现的web框架恐怕是最多的,是一个百花齐放的世界,各种micro-framework、framework不可胜数;猜想原因应该是...

67040
来自专栏jerryteng的专栏

如何利用最低配的腾讯云快速搭建高并发在线服务

这里是作为开发用,我们就选择一个普通的服务器,我也是很不好意思的申请了相关的学生机,那我们就用学生机来搭建一个高并发的在线服务。这个机器配置很低,我还进行了降级...

1.2K100

扫码关注云+社区

领取腾讯云代金券