构建C协程之ucontext篇

原理简介

所谓 “ucontext” 机制是 GNU C 库提供的一组用于创建、保存、切换用户态执行“上下文”（context）的API，可以看作是 “setjmp/long_jmp” 的“升级版”，主要包括以下四个函数：

void makecontext(ucontext_t *ucp, void (*func)(), int argc, ...);int swapcontext(ucontext_t *oucp, ucontext_t *ucp);int getcontext(ucontext_t *ucp);int setcontext(const ucontext_t *ucp);

结构体 ucontext_t 和上述4个函数声明一起定义在系统头文件<ucontext.h> 中，该类型的具体实现与体系结构相关，但规范要求其至少要包含以下字段：

typedef struct ucontext {  struct ucontext *uc_link;    sigset_t       uc_sigmask;    stack_t         uc_stack;    mcontext_t uc_mcontext;    ...} ucontext_t;

其中 sigset_t 和 stack_t 定义在标准头文件 <signal.h> 中， uc_link 字段保存当前context结束后继续执行的context记录， uc_sigmask 记录该context运行阶段需要屏蔽的信号，uc_stack 是该context运行的栈信息， 最后一个字段uc_mcontext 则保存具体的程序执行上下文——如PC值、堆栈指针、寄存器值等信息——其实现方式依赖于底层运行的系统架构，是平台、硬件相关的。

下面具体来看每个函数的功能：

• int makecontext(ucontext_t *ucp, void (*func)(), int argc, ...) 该函数用以初始化一个ucontext_t类型的结构，也就是我们所说的用户执行上下文。函数指针func指明了该context的入口函数，argc指明入口参数个数，该值是可变的，但每个参数类型都是int型，这些参数紧随argc传入。 另外，在调用makecontext之前，一般还需要显式的指明其初始栈信息（栈指针SP及栈大小）和运行时的信号屏蔽掩码（signal mask）。 同时也可以指定uc_link字段，这样在func函数返回后，就会切换到uc_link指向的context继续执行。

• int setcontext(const ucontext_t *ucp) 该函数用来将当前程序执行线索切换到参数ucp所指向的上下文状态，在执行正确的情况下，该函数直接切入到新的执行状态，不再会返回。比如我们用上面介绍的makecontext初始化了一个新的上下文，并将入口指向某函数entry()，那么setcontext成功后就会马上运行entry()函数。

• int getcontext(ucontext_t *ucp) 该函数用来将当前执行状态上下文保存到一个ucontext_t结构中，若后续调用setcontext或swapcontext恢复该状态，则程序会沿着getcontext调用点之后继续执行，看起来好像刚从getcontext函数返回一样。 这个操作的功能和setjmp所起的作用类似，都是保存执行状态以便后续恢复执行，但需要重点指出的是：getcontext函数的返回值仅能表示本次操作是否执行正确，而不能用来区分是直接从getcontext操作返回，还是由于setcontext/swapcontex恢复状态导致的返回，这点与setjmp是不一样的。

• int swapcontext(ucontext_t *oucp, ucontext_t *ucp) 理论上，有了上面的3个函数，就可以满足需要了（后面讲的libgo就只用了这3个函数，而实际只需setcontext/getcontext就足矣了），但由于getcontext不能区分返回状态，因此编写上下文切换的代码时就需要保存额外的信息来进行判断，显得比较麻烦。 为了简化切换操作的实现，ucontext 机制里提供了swapcontext这个函数，用来“原子”地完成旧状态的保存和切换到新状态的工作（当然，这并非真正的原子操作，在多线程情况下也会引入一些调度方面的问题，后面会详细介绍）。 为了进一步理解swapcontext这个函数的设计目的，可以尝试利用getcontext/setcontext完成同样的功能，你需要怎样编写代码？ 同时，也不妨思考一下下面这段代码的执行结果（该例出自维基百科Setcontext 条目）：

#include <stdio.h>#include <ucontext.h>#include <unistd.h>int main(int argc, char *argv[]) {  ucontext_t context;  getcontext(&context);  puts("Hello world");  sleep(1);  setcontext(&context);  return 0;}

小结

可以看出，用ucontext机制实现一个“协程”系统并不困难。 实际上，每个运行上下文（ucontext_t）就直接对应于“协程”概念，对于协程的“创建”（Create）、“启动” （Spawn）、“挂起” （Suspend）、“切换” （Swap）等操作，很容易通过上面的4个API及其组合加以实现，需要的工作仅在于设计一组数据结构保存暂不运行的context结构，提供一些调度的策略即可。 这方面的开源实现有很多，其中最著名的就是Go的前身，libtask库。

对于将“协程”映射到多OS线程执行的情形，就要稍稍复杂一些，但主要的问题是集中在共享任务队列的实现、调度线程间的互斥等，至于“协程”的映射问题，与单线程情况没有太大的区别。 对于这方面的开源借鉴，当然首推Go的运行时 —— 但由于标准Go实现没有使用GNU C库，而是自行设计了包括C编译器在内的整套工具链，因而就没有直接采用ucontext机制（尽管其内部实现机制与ucontext原理类似）。

在下一篇中，会转而分析Go语言前端的运行时实现——libgo。libgo的调度器部分基本用C开发并由GCC编译，“goroutine”（Go语言中相对于“协程”的概念）也直接以“ucontext”机制实现，其代码对于分析C语言下“协程”系统实现方法而言，具有较高的参考价值。