写到第30000行的时候我心里其实没底。“云藏山鹰代数信息系统”这个名字听起来太像民科项目了但我确实没有开玩笑——这是一个从零开始写的、试图把“代数作用”和“结构化并发”塞进同一个小型虚拟机的语言运行时。今天这篇是“神游核心代码段30000-30408”的试读第2篇上一篇聊了整体模块划分这次直接进代码把这408行里最核心的调度逻辑拆开讲。这篇文章适合两类人看一类是对自研编程语言、解释器、虚拟机和协程调度器感兴趣但一直没找到合适切口下手的开发者另一类是平时写业务代码但想理解“状态机 事件驱动 栈切换”这套底层玩意到底在解决什么问题的朋友。我会尽量把术语拽回地面但也不会回避代码里的细节。1. 从命名说起为什么叫“意气实体”和“神游思想之琴”1.1 先给这套术语祛魅第一次看到这个项目名的人大概率会产生两种反应要么觉得这是某个玄幻小说的设定集要么觉得作者在故弄玄虚。其实这两个名字被吐槽过很多次但我最终没有改因为它们非常准确地描述了系统里两个不可见但极其关键的部分。先交代背景云藏山鹰代数信息系统下文我直接叫“云藏系统”是一个实验性质的语言运行时。它的核心不是传统的对象和类而是一套叫做“意气实体”的执行单元。你可以把意气实体理解成协程、纤程或者绿色线程的混合体但它比这些多了一层东西每个实体都携带一份“意气”——这是一份可量化的执行上下文包括它的栈帧、剩余执行预算、等待原因、归属关系以及一组代数作用的处理记录。“神游思想之琴”就更玄了。在云藏系统里实体从挂起到恢复的过程不是简单地把一个线程切换回来而是把当前计算状态保存在一个叫“思想之琴”的结构里。这把“琴”由若干条“弦”组成每条弦其实是一段连续的 continuation 栈。实体在神游过程中会在不同的弦之间跳转、复制、合并。名字虽然诗意本质是 continuation 和栈管理的运行时结构。我后来想通了如果当初直接把这些结构命名为“协程控制块”和“续延栈”项目会少吸引很多好奇的人但也会少掉很多记忆点。术语可以中二设计必须严谨。1.2 为什么是“代数”而不是“对象”云藏系统里所有对外可见的副作用——等待一个事件、抛出一个错误、修改共享状态、跳转到另一个实体——都被建模为“代数作用”。这个概念和代数效应algebraic effects一脉相承程序里有一个perform操作它不等于函数调用也不等于异常抛出它更像是在说“我要触发一个效果但这个效果怎么处理由外层的 handler 决定”。举个例子。在普通语言里你要让一个任务等待某个资源通常会调用阻塞函数或异步 API控制流被硬编码在调用链里。在云藏系统里实体只需执行一个perform(Spirit.Wait)运行时会找到离它最近的代数作用处理器决定是立即继续、挂起等待、还是把实体迁移到另一个处理器上。这就是“代数信息系统”这个名字里“代数”二字的来源效果可以被组合、替换、重排就像代数表达式里的项一样。神游核心代码段30000-30408负责的正是把这些代数作用翻译成虚拟机底层的状态迁移和栈操作。看懂它就基本看懂了这个语言真正的执行模型。2. 神游核心代码段30000-30408的整体骨架2.1 这段代码在整份源码里的位置在工程的源码目录里这段代码位于src/vm/roam/roam_core.c行号从30000到30408。之前的30000行大多是语法树、类型检查、中间表示生成器的内容但从这里开始进入了一个完全不同的区域解释器的“心脏”。我的阅读习惯是拿到一段陌生代码不急着逐行看而是先找出三样东西——状态机、核心数据结构、循环入口。这段代码正好把这三样都浓缩在一起非常适合作试读素材。2.2 核心状态机七个状态和四张表神游核心使用了一个非常古典但可靠的设计显式状态机。实体一共七个状态状态含义触发方式IDLE实体已创建但尚未进入就绪池创建完成时READY可以被调度器选中执行从等待/挂起中恢复RUNNING当前正在某个物理线程上执行调度器分配时间片WAITING等待外部事件或资源执行 Wait 类代数作用SUSPENDED主动让出执行权等待显式恢复执行 Yield 类代数作用MIGRATING正在从一个调度域迁移到另一个执行 Roam 类代数作用DEAD执行完毕或异常终止正常返回 / 未捕获错误配合这几个状态核心代码里维护着四张运行时表实体哈希表以实体 ID 为键O(1) 定位任何一个实体。多级就绪队列每个优先级一个队列避免所有实体挤在一起。琴弦等待表记录每条弦上挂起的实体以及它们等待的事件类型。触发队列存放外部系统定时器、IO 完成回调、信号投递进来的唤醒事件。这四张表在代码段里并不是一次性定义完的。30000-30080 附近定义的是实体和状态枚举30081-30160 附近定义的是队列和等待表的操作而真正的调度主循环出现在 30160 行之后。这里我强烈建议读者先把状态迁移图在脑子里画出来再看调度循环——因为switch分支和表的操作几乎是一一对应的。2.3 调度主循环的入口逻辑我把经过精简和注释的调度主循环摘出来它位于代码段的中间位置。这段伪代码忠实还原了原始逻辑的结构只是为了便于阅读去掉了一些宏和锁细节// roam_core.c:30166 - 神游调度主循环 static int roam_scheduler_loop(vm_t *vm) { for (;;) { entity_t *ent dequeue_ready(vm); if (!ent) { // 没有就绪实体处理触发队列或进入休眠 if (drain_trigger_queue(vm) 0) { vm_wait_for_event(vm); } continue; } // 保证实体不被重复调度 if (ent-state ! READY) { requeue_misplaced(vm, ent); continue; } ent-state RUNNING; int result entity_step(vm, ent, ent-soul_budget); if (result STEP_FINISHED) { finish_entity(vm, ent); // 正常结束 } else if (result STEP_SUSPENDED) { suspend_entity(vm, ent); // 保存琴弦 入等待表 } else if (result STEP_MIGRATING) { migrate_entity(vm, ent); // 进入转移队列 } // 出错情况会在 entity_step 内部处理 } }这段代码体现了整个神游核心的第一原则调度器只负责“选谁跑”而“跑到哪里停”完全由实体内部的代数作用决定。实体跑着跑着发现要等一个文件描述符就返回STEP_SUSPENDED发现自己应该到另一个 CPU 核上的调度域执行就返回STEP_MIGRATING。调度器不需要理解业务语义只需要按照状态迁移完成收尾工作。这也是整个代码段能够保持408行规模不膨胀的原因。如果你用传统线程模型实现同样功能这个位置至少会多出一堆同步锁和条件变量的分支处理逻辑而在这里同步机制被收敛进了四个表的操作里。3. 逐段精读从30000到30408里最有分量的三个机制3.1 实体步进与“意气预算”soul_budget云藏系统不使用传统的时间片抢占而是给每个实体分配一个“意气预算”单位叫soul。每次调度器选中一个实体会赋予它一份预算默认64实体每执行一条中间表示指令会消耗1到3不等的预算。预算耗尽后实体即便没遇到等待事件也会被强制让出处理器。这样设计不是为了标新立异而是为了解决两个实际痛点。第一传统时间片依赖定时器中断在纯内嵌的虚拟机上实现成本高、精度粗预算机制可以在解释器主循环里以指令粒度实现精度高且可测试。第二预算可以被代数作用 handler 修改这意味着某个实体在“爆发”时可以获得额外预算而不是像操作系统线程那样固定时间片。对应代码段里有一个关键函数我摘出它的核心// roam_core.c:30040 - 单步推进一个实体 static inline int entity_step(vm_t *vm, entity_t *ent, int budget) { int consumed 0; while (consumed budget ent-state RUNNING) { int cost step_one_instruction(vm, ent); if (cost 0) { // 发生等待或跃迁不再继续执行 return ent-state RUNNING ? STEP_SUSPENDED : ent-state; } consumed cost; } if (consumed budget) { requeue_ready(vm, ent); } return STEP_OK; }注意这里有个容易忽略的细节cost 0的情况。不是说指令执行出错而是指执行这条指令时实体主动产生了神游作用。比如perform(Spirit.Wait)会让step_one_instruction返回一个负值告诉实体步进器“你需要挂起了”。如果不这样设计代数作用就只能通过抛异常或回调来传递那整个语言就失去意义了。你可能会问预算耗尽的实体被重新放回就绪队列会不会导致它一直霸占 CPU答案是大部分场景不会。因为实体从等待中恢复时优先级往往会被降低而且预算是累计在实体身上的不是每次重置。一个长期“假装执行一点点然后让出”的恶意实体会被系统检测到让出频率异常自动下调优先级。3.2 神游跃迁的三种触发方式神游核心之所以叫“神游”是因为实体可以在不改变代码位置的情况下从一个执行上下文跳到另一个执行上下文。代码段里定义了三种触发方式它们对应不同的状态迁移路径第一种是显式跃迁。实体通过perform(Spirit.Roam, target)明确要求迁移到另一个调度域比如一个计算密集实体希望转移到负载更低的 CPU 核。这个操作会直接把实体状态置为MIGRATING并把目标地址记录在实体的“神游标记”字段里。第二种是隐式共振。当实体执行到一个带有 handler 的代数作用时如果 handler 不在当前实体栈内而在另一个实体的上下文里运行时就会自动触发共振迁移。这个机制被用来实现跨实体的异常传递和请求转发代码里对应strand_resonate函数——它会在琴弦等待表里搜索一个能处理该效果的弦然后把当前实体挂到那条弦上。第三种是外部唤醒。文件描述符可读、定时器到期、另一个实体主动写入触发队列都会走wakeup_strand路径。这个路径会修改等待表中的记录并把目标实体放入就绪队列。三种触发方式在代码段里对应三条不同的入队路径但最终都会汇聚到同一个函数requeue_ready(vm, ent)。这个汇聚点是整个神游核心最微妙的地方稍后讲踩坑的时候会专门提到。3.3 思想之琴的保存与恢复实体从运行状态挂起时它的调用栈怎么保存这是整个代码段里最重的部分。传统协程会在堆上分配一块固定栈切出时保存寄存器切回时恢复寄存器。云藏系统不同它把栈抽象成了“琴弦”——每一根弦都是一个可以独立增长、被复制、被合并的连续栈段。代码段30020到30070区域核心是一个叫strand_snapshot的函数。它的任务是把实体当前的执行栈复制成一个不可变的快照并挂到琴弦等待表上。这里最值得关注的是它的写时复制策略初始快照不复制整块栈只复制栈顶的一小部分控制帧只有当另一个实体尝试修改同一个栈段时才会触发真正的深拷贝。// roam_core.c:30058 - 保存琴弦快照 static strand_t *strand_snapshot(vm_t *vm, entity_t *ent) { stack_seg_t *seg ent-stack_top; strand_t *s strand_pool_acquire(vm); // 从池里取一根空弦 s-frames seg-frames; s-frame_count seg-count; s-shared true; // 初始状态允许共享 // 如果栈顶帧引用了可变缓冲区则立即复制 for (int i 0; i seg-count; i) { frame_t *f seg-frames[i]; if (f-has_var_buf) { memcpy(s-owned_buffers[i], f-var_buf, f-var_buf_size); f-var_buf s-owned_buffers[i]; s-shared false; } } return s; }这个机制的巧妙之处在于绝大多数实体挂起时它的栈数据并不会有任何外部修改。因此快照可以放心共享成本几乎为零。只有出现真正的数据竞争时才会付出深拷贝的代价。这和操作系统的“写时复制”页表是同一个思路只不过对象从内存页换成了续延栈帧。恢复过程更复杂实体被唤醒后运行时会尝试复用已经存在的琴弦对象而不是重新分配。它会先比较快照的版本号和当前琴弦的版本号如果一致直接跳转到快照记录的程序计数器即可如果不一致说明栈已经被另一个实体修改过需要沿着快照重建。这段逻辑在30400行附近几乎就是整个代码段的尾声。我在读这段时最大的感受是写时复制真正解决了“实体挂起后栈被外部篡改”的问题代价是代码里充满了版本号比较少写一个ver字段都会引发灾难。4. 这408行跑起来之后我踩过的三个坑代码写出来和跑起来是两回事。神游核心这段代码在开发过程中给我贡献了最多失眠夜下面这三个坑后来都写进了项目日志里随便哪个都值得后来者警惕。4.1 琴弦复用导致的状态串扰最开始实现琴弦池的时候我沿用了传统对象池思路实体挂起时把栈快照放进池里恢复时再取出来。结果一次压力测试里出现了一个诡异的现象一个实体醒来后总是从别人上次挂起的位置继续执行程序计数器完全错乱。排查了半天发现问题出在池化复用上。实体A挂起后栈顶快照被放进池子实体B被创建正好拿到了这根琴弦B运行了一段时间后挂起把新快照写进去然后A被唤醒重新拿到这根弦按自己的版本号去恢复却发现栈顶是B的帧。解决办法是给每根琴弦增加一个不可变的所有者标记实体恢复时强制校验owner_id必须匹配。如果拿到的弦已经被别人写过就放弃复用、重新分配。现在的代码段里30405附近的strand_claim函数就是为此加的。这个坑让我意识到对象池复用不是免费的午餐尤其是对象内部存在语义较重的状态时回收前必须做彻底的失效处理。4.2 意气预算耗尽后的“假死”与饥饿预算机制刚上线时系统出现了另一个问题某些实体明明就绪却迟迟得不到执行看起来像死锁。后来通过日志发现这些实体全部处于“每轮只消耗1个预算就让出”的状态。这类实体的特征很典型它们在一个循环里等待某个状态变化但每次检查都走了一个高消耗的分支。比如检查共享标志位时为了支持跨实体效果每次都要触发一次轻量级神游操作消耗被记成了1。实体每轮预算64可它只需要跑一次检查就主动让出剩下63个预算完全没有利用。更麻烦的是这些实体被放回就绪队列后经常排在普通实体后面而它们下次被选中时又把预算消耗得很少。随着这种实体增多调度器逐渐被“空转实体”占满普通实体长时间得不到执行。解决方案不是取消预算机制而是引入一个“让出惩罚”计数器实体每次在预算耗尽前主动让出就扣减下一次获得的预算连续让出次数越多扣得越多。同时如果实体连续三轮都消耗不足单轮预算的10%调度器会把它判定为“可压缩实体”把它迁移到低优先级的后台队列。这套机制跑了一周后饥饿问题基本消失。预算机制最终被保留但它必须和“信用调节”配合否则就是饿死系统的元凶。4.3 状态迁移期间触发外部信号第三个坑和迁移状态有关也是我花时间最长的。现象是同一个实体偶尔会同时出现在两个就绪队列里等到它被调度时栈和上下文已经错乱得无法挽救。追根溯源问题出在MIGRATING状态上。实体在迁移过程中先把自己的状态置为MIGRATING然后去目标调度域登记。如果这时候有一个外部唤醒事件到达唤醒逻辑看到实体不在“可唤醒状态”就直接把它塞进了目标调度域的就绪队列。而迁移逻辑完成后又会做一次入队操作。两条路径一叠加实体就“分裂”了。修复办法是在实体结构里增加一个pending_event位图。所有外部信号不直接修改实体状态而是先写入位图状态迁移完成时统一检查位图并决定是否立刻入队。这个改动让数据竞争窗口彻底消失了。现在代码段里的触发队列操作严格遵循“先标位、后入队”的顺序任何绕过位图直接修改实体状态的路径都被视为 bug。这也解释了为什么整个调度循环里到处有pending_event的按位检查——每一个都是踩坑后补上的保险。5. 试读这段代码的正确姿势5.1 建议按“创建-步进-唤醒-迁移”四条主线读如果你是第一次接触这段神游核心我建议不要从第30000行开始顺序往下读而是按四条主线分别追溯。第一条线是实体创建。从entity_create开始看一个实体出生后如何进入 READY 状态如何被赋予初始意气预算。第二条线是步进执行从entity_step进入看正常的指令消耗如何变成预算消耗、如何触发等待。第三条线是唤醒从wakeup_strand和drain_trigger_queue倒着读看外部事件如何进入系统内部。第四条线是迁移把MIGRATING相关的所有分支串起来这条最薄但对理解整个状态机很有帮助。读的时候带着三个问题状态从哪来状态到哪去哪个函数会在入队前修改实体状态回答完这三个问题你就掌握了这段代码的全部主线。剩下的细节都是在这些主线上打的补丁。5.2 这些设计在普通项目里的投影有人可能觉得这套东西太底层跟日常业务开发没什么关系。在我看来云藏系统里至少有两个思路可以直接投影到普通后端项目里。第一个是“预算”思想。很多系统的并发控制靠信号量和线程池大小但真正稳定的做法是给每个任务定义单位时间的最大消耗量。就像实体有soul_budget一样业务任务也可以有“积分”每个子调用消耗若干积分积分耗尽就排队。这种做法比单纯设超时时间可控得多因为它能在任务内部进行节流而不是等到超时才开始补救。第二个是“状态迁移时先标位后入队”的并发原则。几乎所有分布式系统里都有类似困扰一个节点在处理请求的中途另一个事件到了到底该不该立即处理云藏给出的答案是不要立即处理先记下来等当前状态机进入稳定点再处理。这就是事件驱动的本质——事件是状态迁移的燃料不是状态本身。业务代码里那些偶发的“双重处理”问题多数都是因为绕过了这一步。我自己的体会是读这种代码不能只抱着“学习语法”的心态要把它当成一份工程决策记录。每一个状态、每一张表、每一个补丁背后都是作者踩过的坑。神游核心代码段30000-30408看上去只有408行但它值得你慢慢读上好几个晚上——读完后你会对“并发到底意味着什么”有完全不同的理解。
写到第30000行的时候我心里其实没底。“云藏山鹰代数信息系统”这个名字听起来太像民科项目了但我确实没有开玩笑——这是一个从零开始写的、试图把“代数作用”和“结构化并发”塞进同一个小型虚拟机的语言运行时。今天这篇是“神游核心代码段30000-30408”的试读第2篇上一篇聊了整体模块划分这次直接进代码把这408行里最核心的调度逻辑拆开讲。这篇文章适合两类人看一类是对自研编程语言、解释器、虚拟机和协程调度器感兴趣但一直没找到合适切口下手的开发者另一类是平时写业务代码但想理解“状态机 事件驱动 栈切换”这套底层玩意到底在解决什么问题的朋友。我会尽量把术语拽回地面但也不会回避代码里的细节。1. 从命名说起为什么叫“意气实体”和“神游思想之琴”1.1 先给这套术语祛魅第一次看到这个项目名的人大概率会产生两种反应要么觉得这是某个玄幻小说的设定集要么觉得作者在故弄玄虚。其实这两个名字被吐槽过很多次但我最终没有改因为它们非常准确地描述了系统里两个不可见但极其关键的部分。先交代背景云藏山鹰代数信息系统下文我直接叫“云藏系统”是一个实验性质的语言运行时。它的核心不是传统的对象和类而是一套叫做“意气实体”的执行单元。你可以把意气实体理解成协程、纤程或者绿色线程的混合体但它比这些多了一层东西每个实体都携带一份“意气”——这是一份可量化的执行上下文包括它的栈帧、剩余执行预算、等待原因、归属关系以及一组代数作用的处理记录。“神游思想之琴”就更玄了。在云藏系统里实体从挂起到恢复的过程不是简单地把一个线程切换回来而是把当前计算状态保存在一个叫“思想之琴”的结构里。这把“琴”由若干条“弦”组成每条弦其实是一段连续的 continuation 栈。实体在神游过程中会在不同的弦之间跳转、复制、合并。名字虽然诗意本质是 continuation 和栈管理的运行时结构。我后来想通了如果当初直接把这些结构命名为“协程控制块”和“续延栈”项目会少吸引很多好奇的人但也会少掉很多记忆点。术语可以中二设计必须严谨。1.2 为什么是“代数”而不是“对象”云藏系统里所有对外可见的副作用——等待一个事件、抛出一个错误、修改共享状态、跳转到另一个实体——都被建模为“代数作用”。这个概念和代数效应algebraic effects一脉相承程序里有一个perform操作它不等于函数调用也不等于异常抛出它更像是在说“我要触发一个效果但这个效果怎么处理由外层的 handler 决定”。举个例子。在普通语言里你要让一个任务等待某个资源通常会调用阻塞函数或异步 API控制流被硬编码在调用链里。在云藏系统里实体只需执行一个perform(Spirit.Wait)运行时会找到离它最近的代数作用处理器决定是立即继续、挂起等待、还是把实体迁移到另一个处理器上。这就是“代数信息系统”这个名字里“代数”二字的来源效果可以被组合、替换、重排就像代数表达式里的项一样。神游核心代码段30000-30408负责的正是把这些代数作用翻译成虚拟机底层的状态迁移和栈操作。看懂它就基本看懂了这个语言真正的执行模型。2. 神游核心代码段30000-30408的整体骨架2.1 这段代码在整份源码里的位置在工程的源码目录里这段代码位于src/vm/roam/roam_core.c行号从30000到30408。之前的30000行大多是语法树、类型检查、中间表示生成器的内容但从这里开始进入了一个完全不同的区域解释器的“心脏”。我的阅读习惯是拿到一段陌生代码不急着逐行看而是先找出三样东西——状态机、核心数据结构、循环入口。这段代码正好把这三样都浓缩在一起非常适合作试读素材。2.2 核心状态机七个状态和四张表神游核心使用了一个非常古典但可靠的设计显式状态机。实体一共七个状态状态含义触发方式IDLE实体已创建但尚未进入就绪池创建完成时READY可以被调度器选中执行从等待/挂起中恢复RUNNING当前正在某个物理线程上执行调度器分配时间片WAITING等待外部事件或资源执行 Wait 类代数作用SUSPENDED主动让出执行权等待显式恢复执行 Yield 类代数作用MIGRATING正在从一个调度域迁移到另一个执行 Roam 类代数作用DEAD执行完毕或异常终止正常返回 / 未捕获错误配合这几个状态核心代码里维护着四张运行时表实体哈希表以实体 ID 为键O(1) 定位任何一个实体。多级就绪队列每个优先级一个队列避免所有实体挤在一起。琴弦等待表记录每条弦上挂起的实体以及它们等待的事件类型。触发队列存放外部系统定时器、IO 完成回调、信号投递进来的唤醒事件。这四张表在代码段里并不是一次性定义完的。30000-30080 附近定义的是实体和状态枚举30081-30160 附近定义的是队列和等待表的操作而真正的调度主循环出现在 30160 行之后。这里我强烈建议读者先把状态迁移图在脑子里画出来再看调度循环——因为switch分支和表的操作几乎是一一对应的。2.3 调度主循环的入口逻辑我把经过精简和注释的调度主循环摘出来它位于代码段的中间位置。这段伪代码忠实还原了原始逻辑的结构只是为了便于阅读去掉了一些宏和锁细节// roam_core.c:30166 - 神游调度主循环 static int roam_scheduler_loop(vm_t *vm) { for (;;) { entity_t *ent dequeue_ready(vm); if (!ent) { // 没有就绪实体处理触发队列或进入休眠 if (drain_trigger_queue(vm) 0) { vm_wait_for_event(vm); } continue; } // 保证实体不被重复调度 if (ent-state ! READY) { requeue_misplaced(vm, ent); continue; } ent-state RUNNING; int result entity_step(vm, ent, ent-soul_budget); if (result STEP_FINISHED) { finish_entity(vm, ent); // 正常结束 } else if (result STEP_SUSPENDED) { suspend_entity(vm, ent); // 保存琴弦 入等待表 } else if (result STEP_MIGRATING) { migrate_entity(vm, ent); // 进入转移队列 } // 出错情况会在 entity_step 内部处理 } }这段代码体现了整个神游核心的第一原则调度器只负责“选谁跑”而“跑到哪里停”完全由实体内部的代数作用决定。实体跑着跑着发现要等一个文件描述符就返回STEP_SUSPENDED发现自己应该到另一个 CPU 核上的调度域执行就返回STEP_MIGRATING。调度器不需要理解业务语义只需要按照状态迁移完成收尾工作。这也是整个代码段能够保持408行规模不膨胀的原因。如果你用传统线程模型实现同样功能这个位置至少会多出一堆同步锁和条件变量的分支处理逻辑而在这里同步机制被收敛进了四个表的操作里。3. 逐段精读从30000到30408里最有分量的三个机制3.1 实体步进与“意气预算”soul_budget云藏系统不使用传统的时间片抢占而是给每个实体分配一个“意气预算”单位叫soul。每次调度器选中一个实体会赋予它一份预算默认64实体每执行一条中间表示指令会消耗1到3不等的预算。预算耗尽后实体即便没遇到等待事件也会被强制让出处理器。这样设计不是为了标新立异而是为了解决两个实际痛点。第一传统时间片依赖定时器中断在纯内嵌的虚拟机上实现成本高、精度粗预算机制可以在解释器主循环里以指令粒度实现精度高且可测试。第二预算可以被代数作用 handler 修改这意味着某个实体在“爆发”时可以获得额外预算而不是像操作系统线程那样固定时间片。对应代码段里有一个关键函数我摘出它的核心// roam_core.c:30040 - 单步推进一个实体 static inline int entity_step(vm_t *vm, entity_t *ent, int budget) { int consumed 0; while (consumed budget ent-state RUNNING) { int cost step_one_instruction(vm, ent); if (cost 0) { // 发生等待或跃迁不再继续执行 return ent-state RUNNING ? STEP_SUSPENDED : ent-state; } consumed cost; } if (consumed budget) { requeue_ready(vm, ent); } return STEP_OK; }注意这里有个容易忽略的细节cost 0的情况。不是说指令执行出错而是指执行这条指令时实体主动产生了神游作用。比如perform(Spirit.Wait)会让step_one_instruction返回一个负值告诉实体步进器“你需要挂起了”。如果不这样设计代数作用就只能通过抛异常或回调来传递那整个语言就失去意义了。你可能会问预算耗尽的实体被重新放回就绪队列会不会导致它一直霸占 CPU答案是大部分场景不会。因为实体从等待中恢复时优先级往往会被降低而且预算是累计在实体身上的不是每次重置。一个长期“假装执行一点点然后让出”的恶意实体会被系统检测到让出频率异常自动下调优先级。3.2 神游跃迁的三种触发方式神游核心之所以叫“神游”是因为实体可以在不改变代码位置的情况下从一个执行上下文跳到另一个执行上下文。代码段里定义了三种触发方式它们对应不同的状态迁移路径第一种是显式跃迁。实体通过perform(Spirit.Roam, target)明确要求迁移到另一个调度域比如一个计算密集实体希望转移到负载更低的 CPU 核。这个操作会直接把实体状态置为MIGRATING并把目标地址记录在实体的“神游标记”字段里。第二种是隐式共振。当实体执行到一个带有 handler 的代数作用时如果 handler 不在当前实体栈内而在另一个实体的上下文里运行时就会自动触发共振迁移。这个机制被用来实现跨实体的异常传递和请求转发代码里对应strand_resonate函数——它会在琴弦等待表里搜索一个能处理该效果的弦然后把当前实体挂到那条弦上。第三种是外部唤醒。文件描述符可读、定时器到期、另一个实体主动写入触发队列都会走wakeup_strand路径。这个路径会修改等待表中的记录并把目标实体放入就绪队列。三种触发方式在代码段里对应三条不同的入队路径但最终都会汇聚到同一个函数requeue_ready(vm, ent)。这个汇聚点是整个神游核心最微妙的地方稍后讲踩坑的时候会专门提到。3.3 思想之琴的保存与恢复实体从运行状态挂起时它的调用栈怎么保存这是整个代码段里最重的部分。传统协程会在堆上分配一块固定栈切出时保存寄存器切回时恢复寄存器。云藏系统不同它把栈抽象成了“琴弦”——每一根弦都是一个可以独立增长、被复制、被合并的连续栈段。代码段30020到30070区域核心是一个叫strand_snapshot的函数。它的任务是把实体当前的执行栈复制成一个不可变的快照并挂到琴弦等待表上。这里最值得关注的是它的写时复制策略初始快照不复制整块栈只复制栈顶的一小部分控制帧只有当另一个实体尝试修改同一个栈段时才会触发真正的深拷贝。// roam_core.c:30058 - 保存琴弦快照 static strand_t *strand_snapshot(vm_t *vm, entity_t *ent) { stack_seg_t *seg ent-stack_top; strand_t *s strand_pool_acquire(vm); // 从池里取一根空弦 s-frames seg-frames; s-frame_count seg-count; s-shared true; // 初始状态允许共享 // 如果栈顶帧引用了可变缓冲区则立即复制 for (int i 0; i seg-count; i) { frame_t *f seg-frames[i]; if (f-has_var_buf) { memcpy(s-owned_buffers[i], f-var_buf, f-var_buf_size); f-var_buf s-owned_buffers[i]; s-shared false; } } return s; }这个机制的巧妙之处在于绝大多数实体挂起时它的栈数据并不会有任何外部修改。因此快照可以放心共享成本几乎为零。只有出现真正的数据竞争时才会付出深拷贝的代价。这和操作系统的“写时复制”页表是同一个思路只不过对象从内存页换成了续延栈帧。恢复过程更复杂实体被唤醒后运行时会尝试复用已经存在的琴弦对象而不是重新分配。它会先比较快照的版本号和当前琴弦的版本号如果一致直接跳转到快照记录的程序计数器即可如果不一致说明栈已经被另一个实体修改过需要沿着快照重建。这段逻辑在30400行附近几乎就是整个代码段的尾声。我在读这段时最大的感受是写时复制真正解决了“实体挂起后栈被外部篡改”的问题代价是代码里充满了版本号比较少写一个ver字段都会引发灾难。4. 这408行跑起来之后我踩过的三个坑代码写出来和跑起来是两回事。神游核心这段代码在开发过程中给我贡献了最多失眠夜下面这三个坑后来都写进了项目日志里随便哪个都值得后来者警惕。4.1 琴弦复用导致的状态串扰最开始实现琴弦池的时候我沿用了传统对象池思路实体挂起时把栈快照放进池里恢复时再取出来。结果一次压力测试里出现了一个诡异的现象一个实体醒来后总是从别人上次挂起的位置继续执行程序计数器完全错乱。排查了半天发现问题出在池化复用上。实体A挂起后栈顶快照被放进池子实体B被创建正好拿到了这根琴弦B运行了一段时间后挂起把新快照写进去然后A被唤醒重新拿到这根弦按自己的版本号去恢复却发现栈顶是B的帧。解决办法是给每根琴弦增加一个不可变的所有者标记实体恢复时强制校验owner_id必须匹配。如果拿到的弦已经被别人写过就放弃复用、重新分配。现在的代码段里30405附近的strand_claim函数就是为此加的。这个坑让我意识到对象池复用不是免费的午餐尤其是对象内部存在语义较重的状态时回收前必须做彻底的失效处理。4.2 意气预算耗尽后的“假死”与饥饿预算机制刚上线时系统出现了另一个问题某些实体明明就绪却迟迟得不到执行看起来像死锁。后来通过日志发现这些实体全部处于“每轮只消耗1个预算就让出”的状态。这类实体的特征很典型它们在一个循环里等待某个状态变化但每次检查都走了一个高消耗的分支。比如检查共享标志位时为了支持跨实体效果每次都要触发一次轻量级神游操作消耗被记成了1。实体每轮预算64可它只需要跑一次检查就主动让出剩下63个预算完全没有利用。更麻烦的是这些实体被放回就绪队列后经常排在普通实体后面而它们下次被选中时又把预算消耗得很少。随着这种实体增多调度器逐渐被“空转实体”占满普通实体长时间得不到执行。解决方案不是取消预算机制而是引入一个“让出惩罚”计数器实体每次在预算耗尽前主动让出就扣减下一次获得的预算连续让出次数越多扣得越多。同时如果实体连续三轮都消耗不足单轮预算的10%调度器会把它判定为“可压缩实体”把它迁移到低优先级的后台队列。这套机制跑了一周后饥饿问题基本消失。预算机制最终被保留但它必须和“信用调节”配合否则就是饿死系统的元凶。4.3 状态迁移期间触发外部信号第三个坑和迁移状态有关也是我花时间最长的。现象是同一个实体偶尔会同时出现在两个就绪队列里等到它被调度时栈和上下文已经错乱得无法挽救。追根溯源问题出在MIGRATING状态上。实体在迁移过程中先把自己的状态置为MIGRATING然后去目标调度域登记。如果这时候有一个外部唤醒事件到达唤醒逻辑看到实体不在“可唤醒状态”就直接把它塞进了目标调度域的就绪队列。而迁移逻辑完成后又会做一次入队操作。两条路径一叠加实体就“分裂”了。修复办法是在实体结构里增加一个pending_event位图。所有外部信号不直接修改实体状态而是先写入位图状态迁移完成时统一检查位图并决定是否立刻入队。这个改动让数据竞争窗口彻底消失了。现在代码段里的触发队列操作严格遵循“先标位、后入队”的顺序任何绕过位图直接修改实体状态的路径都被视为 bug。这也解释了为什么整个调度循环里到处有pending_event的按位检查——每一个都是踩坑后补上的保险。5. 试读这段代码的正确姿势5.1 建议按“创建-步进-唤醒-迁移”四条主线读如果你是第一次接触这段神游核心我建议不要从第30000行开始顺序往下读而是按四条主线分别追溯。第一条线是实体创建。从entity_create开始看一个实体出生后如何进入 READY 状态如何被赋予初始意气预算。第二条线是步进执行从entity_step进入看正常的指令消耗如何变成预算消耗、如何触发等待。第三条线是唤醒从wakeup_strand和drain_trigger_queue倒着读看外部事件如何进入系统内部。第四条线是迁移把MIGRATING相关的所有分支串起来这条最薄但对理解整个状态机很有帮助。读的时候带着三个问题状态从哪来状态到哪去哪个函数会在入队前修改实体状态回答完这三个问题你就掌握了这段代码的全部主线。剩下的细节都是在这些主线上打的补丁。5.2 这些设计在普通项目里的投影有人可能觉得这套东西太底层跟日常业务开发没什么关系。在我看来云藏系统里至少有两个思路可以直接投影到普通后端项目里。第一个是“预算”思想。很多系统的并发控制靠信号量和线程池大小但真正稳定的做法是给每个任务定义单位时间的最大消耗量。就像实体有soul_budget一样业务任务也可以有“积分”每个子调用消耗若干积分积分耗尽就排队。这种做法比单纯设超时时间可控得多因为它能在任务内部进行节流而不是等到超时才开始补救。第二个是“状态迁移时先标位后入队”的并发原则。几乎所有分布式系统里都有类似困扰一个节点在处理请求的中途另一个事件到了到底该不该立即处理云藏给出的答案是不要立即处理先记下来等当前状态机进入稳定点再处理。这就是事件驱动的本质——事件是状态迁移的燃料不是状态本身。业务代码里那些偶发的“双重处理”问题多数都是因为绕过了这一步。我自己的体会是读这种代码不能只抱着“学习语法”的心态要把它当成一份工程决策记录。每一个状态、每一张表、每一个补丁背后都是作者踩过的坑。神游核心代码段30000-30408看上去只有408行但它值得你慢慢读上好几个晚上——读完后你会对“并发到底意味着什么”有完全不同的理解。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
