协程库st(state threads library)原理解析

协程库state threads library(以下简称st)是一个基于setjmp/longjmp实现的C语言版用户线程库或协程库(user level thread)。基本介绍在这 http://state-threads.sourceforge.net/docs/st.html。这里有一个基本的协程例子 http://www.csl.mtu.edu/cs4411.ck/www/NOTES/non-local-goto/coroutine.html, 可以了解setjmp和longjmp的基本用法。如还有不懂,请自行查阅其他资料。

从中可以看出,IA(Internet Application)架构演化历史:

1.多进程MP

以Apache为代表的web server。创建进程服务新用户,开销过高。调度单位是进程。

2.多线程MT

创建新线程服务新用户,线程间上下文切换,锁竞争等等,增加了额外开销。调度单位是线程。

3.事件驱动状态机EDSM

基于IO复用机制,实现大量并发请求的处理。但程序是一体的,并不是基于线程,新程序需要从头开始。该模式下主要使用回调和状态参数来进行上下文切换,实际上是以一种非常艰难和痛苦的方式实现了类似线程和栈的思想。ESDM最大的问题是其“将线性思路分解成大量的回调所固有的复杂性”,导致程序难以实现,扩展和维护。

传统EDSM程序架构:

4.协程

调度单位减小到函数,上下文切换不需要内核参与,不存在系统调用。上下文切换开销降到最低,系统调用降到最低,没有锁竞争,没有信号处理。保留了程序对请求的线性处理逻辑,提高了程序的开发效率,可扩展性和可维护性。

基于st的ESDM程序模型:

基于setjmp和longjmp实现协程库基本步骤(下述线程指用户线程):

1.需要用jmpbuf变量保存每一个线程的运行时环境,称为线程上下文context。

2.为每个线程分配(malloc/mmap)一个stack,用于该线程运行时栈,该stack完全等效于普通系统线程的函数调用栈。该stack地址是在线程初始化时设置,所以不需要考虑setjmp时保存线程的栈上frames数据的问题。

3.通过调用setjmp初始化线程运行时上下文,将context数据存放到jmpbuf结构中。然后修改其中的栈指针sp指向上一步分配的stack。根据当前系统栈的增长方向,将sp设置为stack的最低或最高地址。

4.线程退出时,需要返回到一个安全的系统位置。即,需要有一个主线程main thread或idle thread来作为其他线程最终的退出跳转地址。需要为主线程保存一个jmpbuf。

5.设置过main thread的jmpbuf后,需要跳转到其他线程开始执行业务线程。

6.实现一个context交换函数,在多个线程之间进行跳转:保存自己的jmpbuf,longjmp到另一个线程的jmpbuf。

st基于setjmp和longjmp的具体实现:

线程初始化:

#define MD_INIT_CONTEXT(_thread, _sp, _main) \
  ST_BEGIN_MACRO                               if (MD_SETJMP((_thread)->context))             _main();                                   MD_GET_SP(_thread) = (long) (_sp);           ST_END_MACRO

很明显可以看到,setjmp(将jmpbuf存放到thread->context)之后,同时修改它的栈指针sp指向新分配的线程stack->sp地址。该sp指针用于该thread以后的栈frames数据存储。

线程切换:

#define _ST_SWITCH_CONTEXT(_thread)       \
    ST_BEGIN_MACRO                            ST_SWITCH_OUT_CB(_thread);                if (!MD_SETJMP((_thread)->context)) {       _st_vp_schedule();                      }                                         ST_DEBUG_ITERATE_THREADS();               ST_SWITCH_IN_CB(_thread);                 ST_END_MACRO

其中主要时MD_SETJMP保存当前context,然后调用_st_vp_schedule()从_ST_RUNQ上取第一个可运行的thread,并调用_ST_RESTORE_CONTEXT将该thread恢复运行。

线程恢复:

#define _ST_RESTORE_CONTEXT(_thread)   \
    ST_BEGIN_MACRO                         _ST_SET_CURRENT_THREAD(_thread);       MD_LONGJMP((_thread)->context, 1);     ST_END_MACRO

主线程primordial thread:

/*
 * Initialize this Virtual Processor
 */
int st_init(void)
{
  _st_thread_t *thread;

  if (_st_active_count) {
    /* Already initialized */
    return 0;
  }

  /* We can ignore return value here */
  st_set_eventsys(ST_EVENTSYS_DEFAULT);

  if (_st_io_init() < 0)
    return -1;

  memset(&_st_this_vp, 0, sizeof(_st_vp_t));

  ST_INIT_CLIST(&_ST_RUNQ);
  ST_INIT_CLIST(&_ST_IOQ);
  ST_INIT_CLIST(&_ST_ZOMBIEQ);
#ifdef DEBUG
  ST_INIT_CLIST(&_ST_THREADQ);
#endif

  if ((*_st_eventsys->init)() < 0)
    return -1;

  _st_this_vp.pagesize = getpagesize();
  _st_this_vp.last_clock = st_utime();

  /*
   * Create idle thread
   */
  _st_this_vp.idle_thread = st_thread_create(_st_idle_thread_start,
                         NULL, 0, 0);
  if (!_st_this_vp.idle_thread)
    return -1;
  _st_this_vp.idle_thread->flags = _ST_FL_IDLE_THREAD;
  _st_active_count--;
  _ST_DEL_RUNQ(_st_this_vp.idle_thread);

  /*
   * Initialize primordial thread
   */
  thread = (_st_thread_t *) calloc(1, sizeof(_st_thread_t) +
                   (ST_KEYS_MAX * sizeof(void *)));
  if (!thread)
    return -1;
  thread->private_data = (void **) (thread + 1);
  thread->state = _ST_ST_RUNNING;
  thread->flags = _ST_FL_PRIMORDIAL;
  _ST_SET_CURRENT_THREAD(thread);
  _st_active_count++;
#ifdef DEBUG
  _ST_ADD_THREADQ(thread);
#endif

  return 0;
}

在st_init里面,创建primordial thread。

st程序结构:

st底层基于event-driven select/poll/kqueue/epoll等IO复用机制。下面以epoll为例说明st底层事件管理机制。

st中有IOQ,ZOMBIEQ,RUNQ,SLEEPQ等几个队列,用来存储处于对应状态的threads。

  • RUNQ中存储的是可以被调度运行的threads,每次调用_st_vp_schedule即从该队列取出一个thread去运行。
  • IOQ存储处于IO等待状态的threads,当上层调用st_poll时,将该thread放入IOQ中;当底层epoll有IO事件到达时,将该thread从IOQ中移除,并放入RUNQ中。
  • 当thread退出时,放入ZOMBIEQ中。
  • 当st_poll传入超时参数>0或调用st_usleep和st_cond_timewait时,将thread加入SLEEPQ中。
时间: 2024-12-22 04:57:44

协程库st(state threads library)原理解析的相关文章

libco协程库上下文切换原理详解

缘起 libco 协程库在单个线程中实现了多个协程的创建和切换.按照我们通常的编程思路,单个线程中的程序执行流程通常是顺序的,调用函数同样也是 “调用——返回”,每次都是从函数的入口处开始执行.而libco 中的协程却实现了函数执行到一半时,切出此协程,之后可以回到函数切出的位置继续执行,即函数的执行可以被“拦腰斩断”,这种在函数任意位置 “切出——恢复” 的功能是如何实现的呢? 本文从libco 代码层面对协程的切换进行了剖析,希望能让初次接触 libco 的同学能快速了解其背后的运行机理.

转:一个C语言实现的类似协程库(StateThreads)

http://blog.csdn.net/win_lin/article/details/8242653 译文在后面. State Threads for Internet Applications Introduction State Threads is an application library which provides a foundation for writing fast and highly scalable Internet Applications on UNIX-li

ucontext-人人都可以实现的简单协程库

1.干货写在前面 协程是一种用户态的轻量级线程.本篇主要研究协程的C/C++的实现. 首先我们可以看看有哪些语言已经具备协程语义: 比较重量级的有C#.erlang.golang* 轻量级有python.lua.javascript.ruby 还有函数式的scala.scheme等. c/c++不直接支持协程语义,但有不少开源的协程库,如: Protothreads:一个"蝇量级" C 语言协程库 libco:来自腾讯的开源协程库libco介绍,官网 coroutine:云风的一个C语

C高级 跨平台协程库

1.0 协程库引言 协程对于上层语言还是比较常见的. 例如C# 中 yield retrun, lua 中 coroutine.yield 等来构建同步并发的程序. 本文就是探讨如何从底层实现开发级别的协程库. 在说协程之前, 简单温故一下进程和纤程关系. 进程拥有一个完整的虚拟地址空间,不依赖于线程而独立存在. 线程是进程的一部分,没有自己的地址空间, 与进程内的其他线程一起共享分配给该进程的所有资源.进程和纤程是1对多关系, 协程同线程关系也是类似. 一个线程中可以有多个协程. 协程同线程相

CPU的最小执行单位是线程,协程不需要qt支持...直接用现成的协程库就行了

协程也就在I/O操作上才有优势,Qt事件循环,本事很多I/O已经是异步了,利用好异步(虽然都说异步有点反人类思维).因为CPU的执行最小单位是线程,协程也只是在其之上又调度而已. 我的意思是利用好异步的优势.协程是程序级别的调度,对于CPU执行来说,没任何优势的. CPU的最小执行单位是线程,单线程里十万个协程,也就一个在工作,利用不了并行优势.对于高运算的程序,协程除了增加调度开销并没有优势的.对于I/O操作较多的程序才有用,因为I/O太慢.而对应I/O操作,异步相对与协程开销更小,效率也更高

Stackful 协程库 libgo(单机100万协程)

libgo 是一个使用 C++ 编写的协作式调度的stackful协程库, 同时也是一个强大的并行编程库. 设计之初是为高并发分布式Linux服务端程序开发提供底层框架支持,可以让链接进程序的同步的第三方库变为异步库,不影响逻辑的前提下提升其性能. 目前支持两个平台: Linux (GCC 4.8+) Windows (Win7.Win8.Win10 x86 and x64 使用VS2013/2015编译) 使用libgo编写并行程序,即可以像golang一样开发迅速且逻辑简洁,又有C++原生的

基于ASIO的协程库orchid简介

什么是orchid? orchid是一个构建于boost库基础上的C++库,类似于python下的gevent/eventlet,为用户提供基于协程的并发模型. 什么是协程: 协程,即协作式程序,其思想是,一系列互相依赖的协程间依次使用CPU,每次只有一个协程工作,而其他协程处于休眠状态.协程在控制离开时暂停执行,当控制再次进入时只能从离开的位置继续执行. 协程已经被证明是一种非常有用的程序组件,不仅被python.lua.ruby等脚本语言广泛采用,而且被新一代面向多核的编程语言如golang

轻量级协程库C语言实现

仿制云风的协程库的接口设计,我花了一个下午加晚上的时间重构了之前写的协程库,提供的接口现在和云风大大的协程接口一模一样,都是仿制lua的非对称协程.我们依旧没有用ucontext.h组件(用ucontext.h组件实现协程的文章铺天盖地,可以自行寻找,用longjmp实现就少很多,用内联汇编实现的就更少了),我们的协程库可以运行在兼容X86平台的操作系统上,各种unix-like操作系统,windows操作系统都可以,不过得用gcc或者clang或者与之兼容的mingw编译工具编译出32位的程序

协程库的一些笔记

因为协程的好处,所以协程库现在有好多libtask,boost::coroutine,libco...... libtask很不错,以后或许会用.  boost我个人基本很少用. 腾讯的libco自己用汇编实现了swapcontext函数,不明觉厉(libtask也有ASM).而且把epoll整合在了里面. 微信后台就用到了它.在chinaunix.net上的一个帖子中就说到了这个.不过暂不适合我. 还好云风实现过一个coroutine库,用的context系列函数,很精巧的封装,代码量很小,