1. 项目概述为什么在拥抱C20协程前必须亲手“造轮子”如果你是一名C开发者最近肯定被C20协程Coroutines的各种文章和讨论刷屏了。co_await,co_yield这些新关键字听起来很酷各种库和框架也纷纷宣布支持仿佛不学协程就要落伍了。但当你兴冲冲地打开一篇教程准备用co_await写个异步网络请求时很可能被一堆陌生的概念砸晕promise_type、coroutine_handle、awaiter、suspend_always... 这些到底是什么编译器在背后到底做了什么魔法这就是我想和你聊的核心问题直接上手co_await就像直接开一辆自动挡跑车虽然能跑起来但你对引擎盖下的变速箱、传动轴一无所知。一旦车子抛锚程序崩溃或行为异常你连打开引擎盖的扳手都找不到。我见过太多开发者包括一些有经验的在遇到协程相关的编译错误或运行时死锁时完全束手无策因为对他们来说协程就是一个黑盒。所以这个“项目”的目的不是教你如何使用C20协程的语法糖而是带你回到起点在不依赖co_await关键字的情况下手动实现一个最简化的、但具备完整生命周期的协程机制。我们会从零开始用大约200行纯粹的C代码构建一个属于我们自己的“微型协程库”。这个过程会让你彻底明白一个函数如何能“暂停”和“恢复”暂停时它的局部变量去哪了恢复时上下文如何找回co_await到底在等什么只有亲手实现过一遍你再看C20标准中那些晦涩的std::coroutine_traits和std::coroutine_handle才会恍然大悟“哦原来标准库是在这个基础上做了更通用、更安全的封装和约定”。届时co_await对你而言将不再是一个魔法关键字而是一个你可以清晰预见其每一步行为的工具。当你的协程程序出现难以调试的问题时你拥有的将不是迷茫而是直指问题核心的洞察力。2. 核心需求解析一个协程到底需要什么在动手写代码之前我们必须把协程这个抽象的概念拆解成具体、可实现的需求。抛开所有华丽的术语一个最基本的协程需要解决以下三个核心问题2.1 状态保存与恢复函数的“时光机”普通函数调用是“一次性”的caller调用calleecallee从头执行到return栈帧销毁控制权交回caller。协程要求函数能在执行到一半时暂停suspend并且在未来的某个时刻从暂停的那一行代码精确地恢复resume执行。这带来的第一个需求就是我们需要一个独立于传统函数调用栈的“状态存储区”。当协程暂停时它的“执行现场”必须被完整保存下来。这个现场包括指令指针IP恢复时应该从哪条语句继续执行。局部变量和临时对象函数栈帧上的所有数据。寄存器状态某些架构下需要保存的CPU寄存器。在手动实现中我们无法像编译器那样直接操作指令指针。但我们可以通过状态机State Machine来模拟。我们将协程函数的执行流程划分成几个明确的“状态”用枚举值表示。每次恢复执行时我们用一个switch语句根据当前状态跳转到对应的代码块。这样局部变量就不能再是栈上的自动变量了因为它们需要在多次函数调用对应多次resume间保持存活。我们必须将它们提升为协程状态对象的成员变量。2.2 调度与控制权转移谁说了算普通函数调用控制流是明确的调用者发起被调者执行被调者返回控制权交还调用者。协程引入了“对称”或“非对称”的控制权转移概念。在我们的手动实现中我们采用最简单的非对称协程模型。这意味着有一个明确的“调用者”通常是主线程或调度器它拥有“恢复”协程的权力。协程自己只能“暂停”自己将控制权交还给调用者而不能主动去恢复另一个协程。因此我们的第二个需求是一个清晰的、用于协调“暂停”与“恢复”的接口。调用者需要有一个句柄Handle来代表这个协程通过这个句柄来查询状态是否已结束、恢复执行、以及最终销毁它。2.3 值的传递产出与返还协程不仅仅能暂停和恢复还需要在暂停时能“产出”Yield一个值给调用者或者在最终结束时“返还”Return一个值。co_yield和co_return就是干这个的。我们的第三个需求是设计一套数据传递通道。当协程暂停并让出控制权时它需要能把一个值“送出去”。当调用者恢复协程时有时也需要传递一个值“送进去”这是co_await表达式求值的一部分。在我们的简易实现中我们会先实现yield功能这要求我们的协程状态对象里有一个字段专门用来存放这次“产出”的值。总结一下我们要手动造的这个“轮子”其核心就是一个携带了状态机、局部变量存储和值传递通道的、可被外部反复调用的对象。下面我们就开始用代码把它构建出来。3. 手动实现协程从设计到编码我们将采用自顶向下的方式实现。首先定义协程的对外接口然后逐步填充内部状态机和数据流转逻辑。3.1 定义协程句柄与状态首先我们定义一个表示协程状态的枚举以及一个前向声明的协程类。// 协程的状态 enum class CoroutineStatus { SUSPENDED, // 已挂起等待恢复 RUNNING, // 正在执行 COMPLETED // 已执行完毕 }; // 协程类的提前声明 templatetypename YieldType class Coroutine;接下来定义协程的句柄。对于使用者来说他不需要知道协程内部的具体状态只需要通过这个句柄来操作协程。// 协程句柄提供给用户的接口 templatetypename YieldType class CoroutineHandle { public: // 恢复协程执行 bool resume() { if (coroutine_ coroutine_-status_ ! CoroutineStatus::COMPLETED) { return coroutine_-execute(); // 实际执行逻辑在Coroutine对象内部 } return false; // 无法恢复为空或已结束 } // 获取协程当前产出的值仅在协程挂起后调用有效 YieldType get_value() const { return coroutine_ ? coroutine_-yielded_value_ : YieldType{}; } // 检查协程是否已执行完毕 bool done() const { return !coroutine_ || coroutine_-status_ CoroutineStatus::COMPLETED; } private: // 句柄持有协程对象的共享指针管理其生命周期 std::shared_ptrCoroutineYieldType coroutine_; // 将Coroutine类声明为友元以便其可以创建句柄 templatetypename T friend class Coroutine; // 构造函数私有化只能由Coroutine类创建 explicit CoroutineHandle(std::shared_ptrCoroutineYieldType coroutine) : coroutine_(std::move(coroutine)) {} };这个句柄提供了最核心的三个操作resume()恢复执行、get_value()获取产出的值、done()判断是否结束。注意我们将构造函数设为私有并声明Coroutine为友元这意味着句柄只能由协程内部创建并返回给用户保证了协程对象生命周期管理的封装性。3.2 实现协程核心状态机现在我们实现真正的协程本体Coroutine。它将是一个模板类接受一个产出类型YieldType。// 协程本体实现状态机 templatetypename YieldType class Coroutine { public: // 协程函数类型它是一个可调用对象接受一个Coroutine作为参数用于yield using RoutineFunc std::functionvoid(Coroutine); // 工厂函数用于创建协程并返回其句柄 static CoroutineHandleYieldType create(RoutineFunc func) { auto coroutine std::make_sharedCoroutine(func); auto handle CoroutineHandleYieldType(coroutine); // 初始化为挂起状态等待第一次resume coroutine-status_ CoroutineStatus::SUSPENDED; coroutine-current_state_ 0; // 从状态0开始 return handle; } // 供协程函数内部调用的yield方法 void yield_value(YieldType value) { yielded_value_ std::move(value); status_ CoroutineStatus::SUSPENDED; // 设置状态为挂起 // 注意这里直接返回控制权交还给execute函数的调用者即句柄的resume } private: RoutineFunc func_; // 用户传入的协程函数 CoroutineStatus status_; // 当前状态 int current_state_; // 状态机当前状态编号 YieldType yielded_value_; // 本次挂起时产出的值 // 存储“局部变量”的地方 // 在实际中这里可能需要一个union或variant来存储不同类型的变量 // 为了简化我们假设协程函数只用到一个int类型的“局部变量” int local_variable_x_; // 构造函数私有化强制使用create工厂函数 Coroutine(RoutineFunc func) : func_(std::move(func)) {} // 执行协程逻辑的核心状态机 bool execute() { if (status_ CoroutineStatus::COMPLETED) { return false; } status_ CoroutineStatus::RUNNING; // 根据状态机当前状态跳转执行 switch (current_state_) { case 0: goto STATE_0; case 1: goto STATE_1; case 2: goto STATE_2; // ... 更多状态 default: goto FINAL; } STATE_0: // 模拟协程函数的第一段逻辑 local_variable_x_ 1; std::cout [Coroutine] State 0, x local_variable_x_ std::endl; yield_value(YieldType{10}); // 产出值10并挂起 current_state_ 1; // 记录下次恢复时应跳转到状态1 return true; // 本次执行以挂起结束 STATE_1: // 从上次yield的地方恢复local_variable_x_ 保持为1 local_variable_x_; std::cout [Coroutine] State 1, x local_variable_x_ std::endl; yield_value(YieldType{20}); // 产出值20并挂起 current_state_ 2; return true; STATE_2: local_variable_x_ * 2; std::cout [Coroutine] State 2, x local_variable_x_ std::endl; // 不再yield而是执行完毕 status_ CoroutineStatus::COMPLETED; current_state_ -1; return false; // 返回false表示协程已结束 FINAL: status_ CoroutineStatus::COMPLETED; return false; } // 将CoroutineHandle声明为友元使其能调用execute friend class CoroutineHandleYieldType; };这段代码是整个手动协程的核心它清晰地展示了一个状态机是如何工作的状态保存current_state_变量记录了协程执行到的位置。每次yield_value挂起前都会更新这个状态号。局部变量持久化原本在栈上的局部变量x被提升为类成员local_variable_x_。因此它在多次execute调用之间得以保持。控制流转移execute方法通过switch和goto语句这里用goto是为了清晰模拟跳转实际项目可能用函数指针或switch内嵌代码块跳转到上次暂停的位置继续执行。值传递yield_value方法将产出的值存入yielded_value_并将状态设为SUSPENDED。外部通过句柄的get_value()来获取它。注意这里使用了goto在现代C中需谨慎使用。这仅用于原理演示。一个更工程化的实现可能会将每个状态封装为一个独立的成员函数或lambda通过函数指针或std::function来调用。3.3 组装与测试看看它如何工作现在让我们写一个简单的main函数来使用这个手动协程。int main() { // 定义一个协程函数。注意它接受一个Coroutine参数用于yield。 auto routine [](Coroutineint co) { // 这个函数体并不会被直接执行 // 它只是描述了协程“应该”做什么实际执行路径由状态机控制。 // 真正的逻辑在Coroutine::execute的状态机里。 // 这里的内容可以看作是对状态机逻辑的“注释”或“设计文档”。 int x 1; std::cout Start, x x std::endl; co.yield_value(10); // 第一次挂起产出10 x; std::cout Resumed, x x std::endl; co.yield_value(20); // 第二次挂起产出20 x * 2; std::cout Resumed again, x x std::endl; // 结束 }; // 创建协程并获取句柄 auto handle Coroutineint::create(routine); // 第一次恢复执行从初始状态开始 std::cout Main: resuming coroutine first time... std::endl; handle.resume(); std::cout Main: got value: handle.get_value() std::endl; // 第二次恢复执行 std::cout \nMain: resuming coroutine second time... std::endl; handle.resume(); std::cout Main: got value: handle.get_value() std::endl; // 第三次恢复执行预期协程将结束 std::cout \nMain: resuming coroutine third time... std::endl; bool can_continue handle.resume(); std::cout Main: coroutine can continue? std::boolalpha can_continue std::endl; std::cout Main: is coroutine done? handle.done() std::endl; return 0; }运行这个程序你会看到如下输出Main: resuming coroutine first time... [Coroutine] State 0, x 1 Main: got value: 10 Main: resuming coroutine second time... [Coroutine] State 1, x 2 Main: got value: 20 Main: resuming coroutine third time... [Coroutine] State 2, x 4 Main: coroutine can continue? false Main: is coroutine done? true看我们成功了我们手动实现了一个可以暂停、恢复、产出值的协程。虽然它非常简陋但已经具备了协程最本质的特征。Coroutine::execute方法中的STATE_0,STATE_1,STATE_2就对应着用户协程函数中两个yield_value调用将执行流分割成的三个片段。4. 从手动实现反观C20协程现在让我们站在这个手动实现的“土制协程”的肩膀上去理解C20协程的“工业级实现”。你会发现概念是一一对应的只是标准库和编译器帮你做了大量自动化、类型安全的工作。4.1 编译器生成的“状态机”与“承诺对象”在我们手动实现中我们显式地编写了状态机switch/goto和保存局部变量的类成员。在C20中当你写一个包含co_await、co_yield或co_return的函数时编译器会自动帮你做这件事。自动状态机编译器将你的协程函数体根据挂起点co_await,co_yield切割成多个片段并生成一个类似我们execute方法的恢复逻辑。这个状态机是隐式的你无法直接看到但它确实存在。承诺对象Promise Object这对应着我们手动实现中的Coroutine类对象。编译器会生成一个“承诺类型”通过promise_type定义这个类型的对象负责管理协程状态类似我们的status_。存储局部变量编译器会将所有在挂起点之后可能还用到的局部变量从栈上“提升”到这个承诺对象的成员中。这比我们手动声明local_variable_x_要复杂得多因为编译器需要分析变量的生命周期。产出和返回值提供yield_value和return_value方法对应我们的yield_value方法。创建协程句柄提供get_return_object()方法用于创建返回给调用者的对象类似我们的CoroutineHandle。4.2co_await与等待器Awaiter这是我们手动实现中尚未涉及但却是C20协程最强大也最复杂的一部分。co_await expr不仅仅意味着“挂起”它还涉及“等待某个异步操作完成”。在我们的手动协程里yield是主动挂起并传出一个值。而co_await的语义是“我想等待expr的结果如果它没准备好我就挂起等它准备好了请带着结果唤醒我。”为了实现这个C20引入了等待器Awaiter的概念。一个可以被co_await的表达式必须产生一个符合特定接口的 Awaiter 对象。这个对象需要三个关键方法await_ready()询问“结果准备好了吗”。如果返回true协程就不挂起直接继续执行。await_suspend(coroutine_handle)如果结果没准备好协程要挂起。这个方法被调用并传入一个代表当前协程的句柄。Awaiter可以保存这个句柄等异步操作完成时再用这个句柄来恢复协程。这正是实现异步回调的关键await_resume()当协程恢复时无论是立即恢复还是被回调恢复调用此方法来获取co_await表达式最终的结果。举个例子当你co_await一个网络读操作时await_suspend里可能会发起一个异步I/O请求并将协程句柄注册为回调。当数据到达时操作系统触发回调回调函数中调用coroutine_handle.resume()协程就从co_await之后的那一行恢复了并通过await_resume()拿到读到的数据。在我们的手动实现中如果要加入类似功能我们需要在yield_value的基础上进行扩展让挂起时可以“注册一个回调”并且允许外部事件如定时器、I/O完成来触发resume。这会将我们的简易协程升级为一个“协作式任务”。4.3 协程句柄coroutine_handle我们手动实现的CoroutineHandle是一个简单的包装器。C20的std::coroutine_handle则要强大和通用得多。它是一个模板类coroutine_handlepromise_type与特定的承诺类型绑定。它提供了resume()、done()方法和我们的类似。它还提供了promise()方法用于获取其内部的承诺对象的引用允许你与协程内部状态进行更复杂的交互。最重要的是它可以被无损地转换为void特化的coroutine_handle从而可以存储在不关心承诺类型的容器或回调中这是实现通用调度器的基础。5. 手动实现带来的核心洞见与避坑指南通过亲手搭建这个简易协程你至少应该获得以下几点在直接使用co_await时难以体会的深刻理解5.1 协程的生命周期与内存管理洞见协程对象即编译器生成的承诺对象及其状态的生命周期可能长于创建它的那个函数调用。在我们的手动实现中我们使用了std::shared_ptr来管理Coroutine对象确保只要句柄还存在协程状态就活着。在C20中这同样重要。如果你不小心让协程帧即那个状态存储区在未完成时被销毁程序就会崩溃。避坑提示永远要注意协程句柄的生命周期。一个常见的错误是在某个回调中保存了coroutine_handle但这个回调对象本身可能先于协程结束而被销毁。使用coroutine_handle的from_promise或from_address时要格外小心所有权问题。对于异步操作考虑使用std::shared_ptr包装相关状态或使用已有成熟库如cppcoro, folly::coro提供的安全抽象。5.2 挂起点的不可预测性与线程安全洞见协程可以在任何co_await或co_yield点挂起。这意味着在挂起点之后访问协程外部的引用或指针可能是危险的因为外部对象的状态可能在协程挂起期间被其他代码修改。避坑提示在协程函数中如果通过引用或指针捕获了外部变量要极度警惕其生命周期和线程安全性。尽量通过值传递或者在协程开始时就将所需数据拷贝或移动到协程帧内编译器提升局部变量就是这个目的。如果必须共享请使用线程安全的智能指针或同步原语。5.3 调试的困难与思路洞见调试手动状态机时你可以清晰地设置断点观察current_state_变量的变化。但调试C20协程时你看到的调用栈可能是断裂的因为挂起和恢复破坏了传统的栈回溯。避坑提示给承诺类型起名在自定义promise_type时给它一个易读的类型名调试器中能看到。利用编译器的协程视图某些编译器如MSVC在调试时提供了“协程状态”视图可以查看挂起状态和局部变量。日志记录在承诺对象的构造函数、析构函数、initial_suspend、final_suspend以及await_suspend等关键点添加日志输出是追踪协程生命周期的有效手段。简化问题当遇到诡异的协程bug时尝试将其简化为一个最小可复现例子。思考“如果这是我手动实现的状态机这一步的状态转移对吗”5.4 性能考量的起点洞见我们手动实现中每次状态跳转都有一个switch开销并且局部变量被“装箱”到了堆上成员变量。C20协程同样有这些开销状态机跳转、堆内存分配协程帧、局部变量提升。避坑提示无堆分配优化如果编译器能在编译期确定协程帧的大小并且协程生命周期严格嵌套在调用者中它可能进行优化将协程帧分配在调用者的栈上避免堆分配。这通常要求协程类型是局部的并且其承诺类型提供了自定义的operator new/delete或使用了std::allocator。警惕过大的协程帧如果协程函数内有大型局部数组或对象它们会被提升到堆上可能造成一次不小的内存分配。对于性能敏感的场景需要仔细评估。co_await的代价即使await_ready()返回trueco_await表达式也有一系列函数调用await_ready,await_suspend,await_resume的开销。在超高性能的循环中这可能需要注意。6. 总结从理解到驾驭手动实现一个简易协程就像在学开车前先了解内燃机、离合器和变速箱的工作原理。它不会让你立刻成为赛车手但会让你在车子出现异响、换挡顿挫时知道问题可能出在哪里而不是只能呼叫拖车。当你再回到C20的co_await世界面对cppcoro::task或folly::coro::Task时你看到的将不再是一团魔法。你会清晰地认识到那个task对象就是你的“协程句柄”加上了一些方便的operator co_await。编译器在背后生成的那个复杂类型就是你手写的Coroutine类的通用化、类型安全升级版。当一个异步操作co_await一个socket.async_read时你能够在大脑中勾勒出await_suspend里如何将协程句柄注册到I/O完成端口以及数据到来时回调函数如何resume你的协程。这种深度的理解是高效使用和调试现代C异步编程模型的基石。它让你从语法的使用者转变为语义的掌控者。下次当你因为一个协程的悬空引用而调试到深夜时或许你会想起今天这个手动实现的状态机然后会心一笑因为你知道该从哪里开始检查了。 手动实现C++20协程核心机制：从状态机到异步编程的深度解析
1. 项目概述为什么在拥抱C20协程前必须亲手“造轮子”如果你是一名C开发者最近肯定被C20协程Coroutines的各种文章和讨论刷屏了。co_await,co_yield这些新关键字听起来很酷各种库和框架也纷纷宣布支持仿佛不学协程就要落伍了。但当你兴冲冲地打开一篇教程准备用co_await写个异步网络请求时很可能被一堆陌生的概念砸晕promise_type、coroutine_handle、awaiter、suspend_always... 这些到底是什么编译器在背后到底做了什么魔法这就是我想和你聊的核心问题直接上手co_await就像直接开一辆自动挡跑车虽然能跑起来但你对引擎盖下的变速箱、传动轴一无所知。一旦车子抛锚程序崩溃或行为异常你连打开引擎盖的扳手都找不到。我见过太多开发者包括一些有经验的在遇到协程相关的编译错误或运行时死锁时完全束手无策因为对他们来说协程就是一个黑盒。所以这个“项目”的目的不是教你如何使用C20协程的语法糖而是带你回到起点在不依赖co_await关键字的情况下手动实现一个最简化的、但具备完整生命周期的协程机制。我们会从零开始用大约200行纯粹的C代码构建一个属于我们自己的“微型协程库”。这个过程会让你彻底明白一个函数如何能“暂停”和“恢复”暂停时它的局部变量去哪了恢复时上下文如何找回co_await到底在等什么只有亲手实现过一遍你再看C20标准中那些晦涩的std::coroutine_traits和std::coroutine_handle才会恍然大悟“哦原来标准库是在这个基础上做了更通用、更安全的封装和约定”。届时co_await对你而言将不再是一个魔法关键字而是一个你可以清晰预见其每一步行为的工具。当你的协程程序出现难以调试的问题时你拥有的将不是迷茫而是直指问题核心的洞察力。2. 核心需求解析一个协程到底需要什么在动手写代码之前我们必须把协程这个抽象的概念拆解成具体、可实现的需求。抛开所有华丽的术语一个最基本的协程需要解决以下三个核心问题2.1 状态保存与恢复函数的“时光机”普通函数调用是“一次性”的caller调用calleecallee从头执行到return栈帧销毁控制权交回caller。协程要求函数能在执行到一半时暂停suspend并且在未来的某个时刻从暂停的那一行代码精确地恢复resume执行。这带来的第一个需求就是我们需要一个独立于传统函数调用栈的“状态存储区”。当协程暂停时它的“执行现场”必须被完整保存下来。这个现场包括指令指针IP恢复时应该从哪条语句继续执行。局部变量和临时对象函数栈帧上的所有数据。寄存器状态某些架构下需要保存的CPU寄存器。在手动实现中我们无法像编译器那样直接操作指令指针。但我们可以通过状态机State Machine来模拟。我们将协程函数的执行流程划分成几个明确的“状态”用枚举值表示。每次恢复执行时我们用一个switch语句根据当前状态跳转到对应的代码块。这样局部变量就不能再是栈上的自动变量了因为它们需要在多次函数调用对应多次resume间保持存活。我们必须将它们提升为协程状态对象的成员变量。2.2 调度与控制权转移谁说了算普通函数调用控制流是明确的调用者发起被调者执行被调者返回控制权交还调用者。协程引入了“对称”或“非对称”的控制权转移概念。在我们的手动实现中我们采用最简单的非对称协程模型。这意味着有一个明确的“调用者”通常是主线程或调度器它拥有“恢复”协程的权力。协程自己只能“暂停”自己将控制权交还给调用者而不能主动去恢复另一个协程。因此我们的第二个需求是一个清晰的、用于协调“暂停”与“恢复”的接口。调用者需要有一个句柄Handle来代表这个协程通过这个句柄来查询状态是否已结束、恢复执行、以及最终销毁它。2.3 值的传递产出与返还协程不仅仅能暂停和恢复还需要在暂停时能“产出”Yield一个值给调用者或者在最终结束时“返还”Return一个值。co_yield和co_return就是干这个的。我们的第三个需求是设计一套数据传递通道。当协程暂停并让出控制权时它需要能把一个值“送出去”。当调用者恢复协程时有时也需要传递一个值“送进去”这是co_await表达式求值的一部分。在我们的简易实现中我们会先实现yield功能这要求我们的协程状态对象里有一个字段专门用来存放这次“产出”的值。总结一下我们要手动造的这个“轮子”其核心就是一个携带了状态机、局部变量存储和值传递通道的、可被外部反复调用的对象。下面我们就开始用代码把它构建出来。3. 手动实现协程从设计到编码我们将采用自顶向下的方式实现。首先定义协程的对外接口然后逐步填充内部状态机和数据流转逻辑。3.1 定义协程句柄与状态首先我们定义一个表示协程状态的枚举以及一个前向声明的协程类。// 协程的状态 enum class CoroutineStatus { SUSPENDED, // 已挂起等待恢复 RUNNING, // 正在执行 COMPLETED // 已执行完毕 }; // 协程类的提前声明 templatetypename YieldType class Coroutine;接下来定义协程的句柄。对于使用者来说他不需要知道协程内部的具体状态只需要通过这个句柄来操作协程。// 协程句柄提供给用户的接口 templatetypename YieldType class CoroutineHandle { public: // 恢复协程执行 bool resume() { if (coroutine_ coroutine_-status_ ! CoroutineStatus::COMPLETED) { return coroutine_-execute(); // 实际执行逻辑在Coroutine对象内部 } return false; // 无法恢复为空或已结束 } // 获取协程当前产出的值仅在协程挂起后调用有效 YieldType get_value() const { return coroutine_ ? coroutine_-yielded_value_ : YieldType{}; } // 检查协程是否已执行完毕 bool done() const { return !coroutine_ || coroutine_-status_ CoroutineStatus::COMPLETED; } private: // 句柄持有协程对象的共享指针管理其生命周期 std::shared_ptrCoroutineYieldType coroutine_; // 将Coroutine类声明为友元以便其可以创建句柄 templatetypename T friend class Coroutine; // 构造函数私有化只能由Coroutine类创建 explicit CoroutineHandle(std::shared_ptrCoroutineYieldType coroutine) : coroutine_(std::move(coroutine)) {} };这个句柄提供了最核心的三个操作resume()恢复执行、get_value()获取产出的值、done()判断是否结束。注意我们将构造函数设为私有并声明Coroutine为友元这意味着句柄只能由协程内部创建并返回给用户保证了协程对象生命周期管理的封装性。3.2 实现协程核心状态机现在我们实现真正的协程本体Coroutine。它将是一个模板类接受一个产出类型YieldType。// 协程本体实现状态机 templatetypename YieldType class Coroutine { public: // 协程函数类型它是一个可调用对象接受一个Coroutine作为参数用于yield using RoutineFunc std::functionvoid(Coroutine); // 工厂函数用于创建协程并返回其句柄 static CoroutineHandleYieldType create(RoutineFunc func) { auto coroutine std::make_sharedCoroutine(func); auto handle CoroutineHandleYieldType(coroutine); // 初始化为挂起状态等待第一次resume coroutine-status_ CoroutineStatus::SUSPENDED; coroutine-current_state_ 0; // 从状态0开始 return handle; } // 供协程函数内部调用的yield方法 void yield_value(YieldType value) { yielded_value_ std::move(value); status_ CoroutineStatus::SUSPENDED; // 设置状态为挂起 // 注意这里直接返回控制权交还给execute函数的调用者即句柄的resume } private: RoutineFunc func_; // 用户传入的协程函数 CoroutineStatus status_; // 当前状态 int current_state_; // 状态机当前状态编号 YieldType yielded_value_; // 本次挂起时产出的值 // 存储“局部变量”的地方 // 在实际中这里可能需要一个union或variant来存储不同类型的变量 // 为了简化我们假设协程函数只用到一个int类型的“局部变量” int local_variable_x_; // 构造函数私有化强制使用create工厂函数 Coroutine(RoutineFunc func) : func_(std::move(func)) {} // 执行协程逻辑的核心状态机 bool execute() { if (status_ CoroutineStatus::COMPLETED) { return false; } status_ CoroutineStatus::RUNNING; // 根据状态机当前状态跳转执行 switch (current_state_) { case 0: goto STATE_0; case 1: goto STATE_1; case 2: goto STATE_2; // ... 更多状态 default: goto FINAL; } STATE_0: // 模拟协程函数的第一段逻辑 local_variable_x_ 1; std::cout [Coroutine] State 0, x local_variable_x_ std::endl; yield_value(YieldType{10}); // 产出值10并挂起 current_state_ 1; // 记录下次恢复时应跳转到状态1 return true; // 本次执行以挂起结束 STATE_1: // 从上次yield的地方恢复local_variable_x_ 保持为1 local_variable_x_; std::cout [Coroutine] State 1, x local_variable_x_ std::endl; yield_value(YieldType{20}); // 产出值20并挂起 current_state_ 2; return true; STATE_2: local_variable_x_ * 2; std::cout [Coroutine] State 2, x local_variable_x_ std::endl; // 不再yield而是执行完毕 status_ CoroutineStatus::COMPLETED; current_state_ -1; return false; // 返回false表示协程已结束 FINAL: status_ CoroutineStatus::COMPLETED; return false; } // 将CoroutineHandle声明为友元使其能调用execute friend class CoroutineHandleYieldType; };这段代码是整个手动协程的核心它清晰地展示了一个状态机是如何工作的状态保存current_state_变量记录了协程执行到的位置。每次yield_value挂起前都会更新这个状态号。局部变量持久化原本在栈上的局部变量x被提升为类成员local_variable_x_。因此它在多次execute调用之间得以保持。控制流转移execute方法通过switch和goto语句这里用goto是为了清晰模拟跳转实际项目可能用函数指针或switch内嵌代码块跳转到上次暂停的位置继续执行。值传递yield_value方法将产出的值存入yielded_value_并将状态设为SUSPENDED。外部通过句柄的get_value()来获取它。注意这里使用了goto在现代C中需谨慎使用。这仅用于原理演示。一个更工程化的实现可能会将每个状态封装为一个独立的成员函数或lambda通过函数指针或std::function来调用。3.3 组装与测试看看它如何工作现在让我们写一个简单的main函数来使用这个手动协程。int main() { // 定义一个协程函数。注意它接受一个Coroutine参数用于yield。 auto routine [](Coroutineint co) { // 这个函数体并不会被直接执行 // 它只是描述了协程“应该”做什么实际执行路径由状态机控制。 // 真正的逻辑在Coroutine::execute的状态机里。 // 这里的内容可以看作是对状态机逻辑的“注释”或“设计文档”。 int x 1; std::cout Start, x x std::endl; co.yield_value(10); // 第一次挂起产出10 x; std::cout Resumed, x x std::endl; co.yield_value(20); // 第二次挂起产出20 x * 2; std::cout Resumed again, x x std::endl; // 结束 }; // 创建协程并获取句柄 auto handle Coroutineint::create(routine); // 第一次恢复执行从初始状态开始 std::cout Main: resuming coroutine first time... std::endl; handle.resume(); std::cout Main: got value: handle.get_value() std::endl; // 第二次恢复执行 std::cout \nMain: resuming coroutine second time... std::endl; handle.resume(); std::cout Main: got value: handle.get_value() std::endl; // 第三次恢复执行预期协程将结束 std::cout \nMain: resuming coroutine third time... std::endl; bool can_continue handle.resume(); std::cout Main: coroutine can continue? std::boolalpha can_continue std::endl; std::cout Main: is coroutine done? handle.done() std::endl; return 0; }运行这个程序你会看到如下输出Main: resuming coroutine first time... [Coroutine] State 0, x 1 Main: got value: 10 Main: resuming coroutine second time... [Coroutine] State 1, x 2 Main: got value: 20 Main: resuming coroutine third time... [Coroutine] State 2, x 4 Main: coroutine can continue? false Main: is coroutine done? true看我们成功了我们手动实现了一个可以暂停、恢复、产出值的协程。虽然它非常简陋但已经具备了协程最本质的特征。Coroutine::execute方法中的STATE_0,STATE_1,STATE_2就对应着用户协程函数中两个yield_value调用将执行流分割成的三个片段。4. 从手动实现反观C20协程现在让我们站在这个手动实现的“土制协程”的肩膀上去理解C20协程的“工业级实现”。你会发现概念是一一对应的只是标准库和编译器帮你做了大量自动化、类型安全的工作。4.1 编译器生成的“状态机”与“承诺对象”在我们手动实现中我们显式地编写了状态机switch/goto和保存局部变量的类成员。在C20中当你写一个包含co_await、co_yield或co_return的函数时编译器会自动帮你做这件事。自动状态机编译器将你的协程函数体根据挂起点co_await,co_yield切割成多个片段并生成一个类似我们execute方法的恢复逻辑。这个状态机是隐式的你无法直接看到但它确实存在。承诺对象Promise Object这对应着我们手动实现中的Coroutine类对象。编译器会生成一个“承诺类型”通过promise_type定义这个类型的对象负责管理协程状态类似我们的status_。存储局部变量编译器会将所有在挂起点之后可能还用到的局部变量从栈上“提升”到这个承诺对象的成员中。这比我们手动声明local_variable_x_要复杂得多因为编译器需要分析变量的生命周期。产出和返回值提供yield_value和return_value方法对应我们的yield_value方法。创建协程句柄提供get_return_object()方法用于创建返回给调用者的对象类似我们的CoroutineHandle。4.2co_await与等待器Awaiter这是我们手动实现中尚未涉及但却是C20协程最强大也最复杂的一部分。co_await expr不仅仅意味着“挂起”它还涉及“等待某个异步操作完成”。在我们的手动协程里yield是主动挂起并传出一个值。而co_await的语义是“我想等待expr的结果如果它没准备好我就挂起等它准备好了请带着结果唤醒我。”为了实现这个C20引入了等待器Awaiter的概念。一个可以被co_await的表达式必须产生一个符合特定接口的 Awaiter 对象。这个对象需要三个关键方法await_ready()询问“结果准备好了吗”。如果返回true协程就不挂起直接继续执行。await_suspend(coroutine_handle)如果结果没准备好协程要挂起。这个方法被调用并传入一个代表当前协程的句柄。Awaiter可以保存这个句柄等异步操作完成时再用这个句柄来恢复协程。这正是实现异步回调的关键await_resume()当协程恢复时无论是立即恢复还是被回调恢复调用此方法来获取co_await表达式最终的结果。举个例子当你co_await一个网络读操作时await_suspend里可能会发起一个异步I/O请求并将协程句柄注册为回调。当数据到达时操作系统触发回调回调函数中调用coroutine_handle.resume()协程就从co_await之后的那一行恢复了并通过await_resume()拿到读到的数据。在我们的手动实现中如果要加入类似功能我们需要在yield_value的基础上进行扩展让挂起时可以“注册一个回调”并且允许外部事件如定时器、I/O完成来触发resume。这会将我们的简易协程升级为一个“协作式任务”。4.3 协程句柄coroutine_handle我们手动实现的CoroutineHandle是一个简单的包装器。C20的std::coroutine_handle则要强大和通用得多。它是一个模板类coroutine_handlepromise_type与特定的承诺类型绑定。它提供了resume()、done()方法和我们的类似。它还提供了promise()方法用于获取其内部的承诺对象的引用允许你与协程内部状态进行更复杂的交互。最重要的是它可以被无损地转换为void特化的coroutine_handle从而可以存储在不关心承诺类型的容器或回调中这是实现通用调度器的基础。5. 手动实现带来的核心洞见与避坑指南通过亲手搭建这个简易协程你至少应该获得以下几点在直接使用co_await时难以体会的深刻理解5.1 协程的生命周期与内存管理洞见协程对象即编译器生成的承诺对象及其状态的生命周期可能长于创建它的那个函数调用。在我们的手动实现中我们使用了std::shared_ptr来管理Coroutine对象确保只要句柄还存在协程状态就活着。在C20中这同样重要。如果你不小心让协程帧即那个状态存储区在未完成时被销毁程序就会崩溃。避坑提示永远要注意协程句柄的生命周期。一个常见的错误是在某个回调中保存了coroutine_handle但这个回调对象本身可能先于协程结束而被销毁。使用coroutine_handle的from_promise或from_address时要格外小心所有权问题。对于异步操作考虑使用std::shared_ptr包装相关状态或使用已有成熟库如cppcoro, folly::coro提供的安全抽象。5.2 挂起点的不可预测性与线程安全洞见协程可以在任何co_await或co_yield点挂起。这意味着在挂起点之后访问协程外部的引用或指针可能是危险的因为外部对象的状态可能在协程挂起期间被其他代码修改。避坑提示在协程函数中如果通过引用或指针捕获了外部变量要极度警惕其生命周期和线程安全性。尽量通过值传递或者在协程开始时就将所需数据拷贝或移动到协程帧内编译器提升局部变量就是这个目的。如果必须共享请使用线程安全的智能指针或同步原语。5.3 调试的困难与思路洞见调试手动状态机时你可以清晰地设置断点观察current_state_变量的变化。但调试C20协程时你看到的调用栈可能是断裂的因为挂起和恢复破坏了传统的栈回溯。避坑提示给承诺类型起名在自定义promise_type时给它一个易读的类型名调试器中能看到。利用编译器的协程视图某些编译器如MSVC在调试时提供了“协程状态”视图可以查看挂起状态和局部变量。日志记录在承诺对象的构造函数、析构函数、initial_suspend、final_suspend以及await_suspend等关键点添加日志输出是追踪协程生命周期的有效手段。简化问题当遇到诡异的协程bug时尝试将其简化为一个最小可复现例子。思考“如果这是我手动实现的状态机这一步的状态转移对吗”5.4 性能考量的起点洞见我们手动实现中每次状态跳转都有一个switch开销并且局部变量被“装箱”到了堆上成员变量。C20协程同样有这些开销状态机跳转、堆内存分配协程帧、局部变量提升。避坑提示无堆分配优化如果编译器能在编译期确定协程帧的大小并且协程生命周期严格嵌套在调用者中它可能进行优化将协程帧分配在调用者的栈上避免堆分配。这通常要求协程类型是局部的并且其承诺类型提供了自定义的operator new/delete或使用了std::allocator。警惕过大的协程帧如果协程函数内有大型局部数组或对象它们会被提升到堆上可能造成一次不小的内存分配。对于性能敏感的场景需要仔细评估。co_await的代价即使await_ready()返回trueco_await表达式也有一系列函数调用await_ready,await_suspend,await_resume的开销。在超高性能的循环中这可能需要注意。6. 总结从理解到驾驭手动实现一个简易协程就像在学开车前先了解内燃机、离合器和变速箱的工作原理。它不会让你立刻成为赛车手但会让你在车子出现异响、换挡顿挫时知道问题可能出在哪里而不是只能呼叫拖车。当你再回到C20的co_await世界面对cppcoro::task或folly::coro::Task时你看到的将不再是一团魔法。你会清晰地认识到那个task对象就是你的“协程句柄”加上了一些方便的operator co_await。编译器在背后生成的那个复杂类型就是你手写的Coroutine类的通用化、类型安全升级版。当一个异步操作co_await一个socket.async_read时你能够在大脑中勾勒出await_suspend里如何将协程句柄注册到I/O完成端口以及数据到来时回调函数如何resume你的协程。这种深度的理解是高效使用和调试现代C异步编程模型的基石。它让你从语法的使用者转变为语义的掌控者。下次当你因为一个协程的悬空引用而调试到深夜时或许你会想起今天这个手动实现的状态机然后会心一笑因为你知道该从哪里开始检查了。