一.状态机情景Phase1解决的是 “怎么把一个外部程序跑起来并拿到输出和退出结果” 但一旦 TaskForge 后面开始支持并发、排队、取消就会出现另一个问题 一个任务现在到底处于什么阶段 不能只用一句 正在执行 因为实际可能是 刚提交正在排队 已经获得执行机会 正在做执行前准备 已经进入执行流程 已经成功 已经失败 已经超时 已经取消提醒当前列出的任务状态是queued 排队中 ready 就绪 starting 开始处理中 running 执行流程中 success 成功 failed 失败 timeout 超时 cancelled 已取消这些是 TaskState也就是 TaskForge 自己定义的任务状态不是 Linux 内核里的进程状态。**比如TaskState::running不能理解成Linux 已经成功 exec 出 workload 了。TaskState::running 只是 TaskForge 自己内部的本子上写的一个状态它跟Linux 到底有没有真的把程序跑起来是两码事。顺序是这样的第1步把本子上的状态改成 running ← 先写本子 第2步调用run_process()← 才去真正启动进程 第3步run_process()里才 fork 第4步fork 出的 child 才 exec也就是TaskForge 打算开始执行这个任务了 / 已经开始走执行这段流程了至于底层进程成没成它不保证。二.atomic 和 CAS情景情景假设当前state是queuedstate 不是每个线程一份而是所有线程共享同一份。有两个线程同时操作它。 线程 A 想做 queued → ready 线程 B 想做 queued → cancelled如果线程 A 这样写if(statequeued){stateready;}可能发生线程 A 读取 state 看到 queued ↓ 此时线程被切走 线程 B 读取 queued 把 state 改成 cancelled ↓ 线程 A 回来 还按照刚才的旧认知 把 state 改成 ready也就是statequeued 就这一份 线程 A读 → 看到 queued 心里记住了 queued 线程 B读 → 看到 queued 改 → statecancelled 真的改了这份共享的 线程 A根据心里记的 queued→ 改 → stateready ↑ 把 B 刚改的 cancelled 覆盖了关键点state 确实只有一份B 改了 A 也能看到——但 A 没有重新去看A 用的是自己脑子里寄存器/局部变量里的旧副本。线程 A 读完 state 以后到它真正修改 state 之前中间还有一段时间。线程 B 可以在这个空档里先把状态改掉。结论atomic原子操作某一个操作不会被别的线程看到“做到一半”。例如autosstate.load();if(squeued){state.store(ready);}load() 可以是原子的。store() 也可以是原子的。但load ↓ 判断 ↓ store这三步之间别的线程还是可以插进来。引出CASCAS Compare And Swap比较并交换它的核心不是“先读再过一会儿改”而是把这句话变成一个原子操作“只有当真实状态现在仍然等于我预期的 queued才把它改成 ready。”“判断 state 是不是 queued” “把它改成 ready” 这两件事被合并成一个不可分割的动作来做中间不给任何线程插队的机会。CAS “你现在还是我刚才期待的那个状态吗是的话我才改不是的话我就不动。”与mutex的对照一个简单、独立、短小的状态值 → CAS 很合适 多个数据结构需要一起保持一致 → 往往需要 mutex 或别的同步设计TaskState 用 CAS是因为“预期状态仍成立才推进”正好适合原子比较交换但 CAS 只能保护这个状态值不能替代队列锁也不能自动保护多个关联字段。