协程(coroutine)学习笔记

什么是协程(coroutine)

Wiki定义:

Coroutines are computer-program components that generalize subroutines for non-preemptive multitasking, by allowing multiple entry points for suspending and resuming execution at certain locations.

协程是一种特殊的子例程(subroutine),它可以从子例程的多个位置暂停,主动让出执行权限(所以是非抢占式的),并在恢复时接着执行。

子例程可以认为是一种特殊的协程,当子例程被调用时,它从头开始执行,到最后结束,中间不保存状态。子例程可以认为是没有调用yield的协程(没有主动让出执行权)。

协程 vs 线程

  • 线程是抢占式的,协程是非抢占式的。
  • 线程数量通常不可以太多,而协程的数量可以非常多。
  • 多个线程可以正常同时执行,而同一线程下的多个协程,则不可以同时执行。

Stackfull协程 vs stackless协程

Stackless类型不保存调用栈以及寄存器等信息,不属于真正的重入,因此一些局部变量都是无法使用的。

Stackfull是真正的基于栈的重入,可以从某个嵌套的调用点上恢复执行。Stackfull协程在切换的时候,需要把当前的栈保存起来,以便在恢复的时候再次恢复执行,而stackless的则不需要。

对称(symmetric) vs 非对称(asymmetric)

协程依控制转移机制分为对称与非对称,对称协程中所有的协程都只有一种控制转移语义,即将控制转移至其他协程,此中的协程在这种机制下都是对称的。而非对称协程中调用者协程与被调用协程处于不对称的地位,和函数调用一样,被调用协程挂起之后控制总是会转移到调用者协程。

协程优点

个人理解,协程的唯一优点
目前看来,协程最主要的优点,就是可以使用同步的方式写异步执行的代码,使得代码逻辑更加简洁和清晰。

但是协程实际上还是无法完全避免写异步回调,因为我们需要在异步API的基础上,结合协程库,开发出“同步”的API。

很多文章中提出,协程的性能更高,个人觉得这个结论有待商榷。协程由于常常是自己实现的,所以自己实现的代码质量对性能有很大影响。另外抛开业务模式去谈性能,也不是很合理。再者,很多人说线程的切换怎么样怎么样的,协程可以有成千上万个,线程成千上万个就怎么样的,我觉得也很不客观。因为实际上,我们实现的时候,线程数通常都是固定的,或者是跟CPU核数有一定关系的,比如CPU核数是8,那么线程数可以也是8,甚至可以做到线程和CPU绑定,那么这个线程切换本身就是一个小概率事件,甚至理论上如果没有别的线程在跑,我们的线程可以做到不切换,所以根本就没有切换性能这一说。

协程的应用场景

我觉得协程的应用场景可能对于一些非常底层的,例如内核驱动、存储、数据库这样的应用,未必是合适的。而对于一些比较上层的应用,例如即时通信软件,可能是比较合适的。

协程有什么风险?

  • 无论是自己实现,还是采用第三方的库,都存在bug的风险。
  • 多线程场景下的并发安全问题。
  • 新技术的接受问题。目前团队中大家都熟悉了异步代码的编写方式,对于性能要求比较高的场景,API一般都是给出异步的,结合trace机制后,代码也不难调试,性能也足够。切换成协程后,可能反而有一定的接受难度。
  • 我相信协程在使用过程中,还会出现一些其它让我们始料未及的问题。
  • 对于thread local storage(TLS)的场景,需要重新考虑。目前我们基于TLS做了很多优化,这些优化在协程场景下,是否还正确?是否还可用?可能需要重新评估。
  • Debug上可能会有难度。例如如果core dump发生了,进程里有几千个协程,每个协程执行的情况,可能很难看出来。
  • 其它未考虑到的风险

协程对于我们团队来说有没有必要?

鉴于以上对协程的优缺点的分析,我个人认为,协程对我们团队来说,的确是一个可选项,可以考虑在比较上层(性能要求不是非常严苛)的场景下使用,会在一定程度上加快开发的速度。但协程对于我们来说,远远达不到必选项的条件。

目前我们的大部分基础库都是采用异步的方式实现的,我们的大部分业务代码,也是异步的,也就是用到了各种回调。其实难度也并没有想象那么大,类似的代码写习惯了,其实也挺简单的。后端的业务流程,个人觉得,写异步代码的困难程度,并不是瓶颈所在。

Implement in C

Simon Tatham通过C语言的宏,实现了一种协程,参考这里。通过这个例子可以学习到协程的一些定义。不过上面的实现很难直接用在生产环境,一方面它会对已有的源码有一些冲突,需要对现有的代码进行重构。另一方面它在宏里有一些malloc的动作,生产环境中可能不一定允许有这样的操作。

基于ucontext的实现

风云主要直接使用了现成的ucontext族的接口,这个接口从调研来看,主要的缺点在于性能慢,因为用到了系统调用。另外这个版本用到的是共享栈的做法。

代码量非常少,比较直观,不过基本上没有做错误处理,商用的话,需要自己再改一下。代码托管在:https://github.com/cloudwu/coroutine/

C的另外一个实现:
http://xmailserver.org/libpcl.html

推荐阅读更多精彩内容