协程(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