在 C/C++ 语言之中，我们仍旧可以构建（基于协同程序的并行架构）程序，我们可以依赖于 boost、state-threads 等开源BCL基础类库来实现所需的一切。
但须知，在 C/C++ 语言之中构建协同程序较为原始，我们应当确保协同程序在切换时候有足够高效的性能，而不是去实现一个无意义的调度运行时程序来确保协同切换的正确性。
当然，某些人闲得无聊的确可以去实现这样的协同程序切换流程管理，我们需要先知道无论是 "stackless"、或者 "stackful" 类型的协同程序，从切换的流程上来说均为大同小异。
但本人极为反感，stackless 类型的协同程序，这包含：C#、golang、C++ 20 这一类提供 stackless，可以说，这就是伪协程。
这些 stackless 协程依赖于编译器在编译期间做极为复杂的代码展开。
以世界目前分为的流派，为两大类：
1、基于状态机的 IF Switch 切换
2、基于 Lambda 异步回调嵌套函数切换
基于编译器在编译期间对于协同程序流程的展开，这代来极为复杂的不可控制风险，这要求编译器需要经过无数深入且复杂的协同程序编译测试论证，但这并不保证编译器不会产生编译事故，这在 stackless 协同架构的程序较为常见的现象。
1、展开流程词不达意，即运行时结果与目的期望结果不同
2、过于复杂的协同程序切换流程展开，致编译器内部崩溃
3、过于缓慢的编译速度
4、内存管理出现故障或泄漏（在托管语言上，这一般为托管内存泄漏）
这四点是 stackless 协同程序，基于复杂的编译器展开代码，潜在会带来的不可控制风险，所以，即便在 C/C++ 之中，本人也不推荐适用 stackless 协同程序。
我们知道，在 C/C++ 语言之中，我们可以适用 boost 来实现 stackless 协同程序，并不需要一定适用 C++ 20。
同理，我也可以适用 boost 来实现 stackful 协同程序，本人推荐手动控制的 stackful，原因有以下几点。
1、可控
2、效能
这两点胜过任何其它花里胡哨，不切实际的特性，OK，关于跨平台的有栈协同程序，您可以参考本人的这篇博客。
C/C++ 11/14/17 有栈式协同程式的基础框架类库【关于】_c++11实现有栈对称协程库-CSDN博客
好的，进入正题，在 C/C++ 之中，手动控制协同程序切换，我们需要知晓以下几个重要知识点，无论是 stackless、还是 stackful 类型的协同程序。
1、在一个协同程序处理的流程之中，我们可以在每个断点（Yield）让出CPU之后，串化直接下一个协同程序，而不是还要画蛇添足，做一个类似 GoRuntime 的东西来管理流程。
2、在一个协同程序处理的流程之中，我们可以在每个断电（Yield）让出CPU之后，把该协程在另一个物理线程上面 Resume 恢复继续执行。
3、在一个协同程序处理的流程之中，不可以在该运行时，在其它线程上重复切换执行该协同程序，这会导致协程崩溃。
4、协同程序执行过程，依赖的数据结构可能发生变化，例如在 Yield 挂起等待 Resume 之中，其它线程或协同程序，可能释放了该数据结构持有的托管及非托管资源，所以在 Resume 恢复之后需要确保依赖数据结构的状态，否则会产生二义性。
5、协同程序在执行过程，线程CPU将被一直占有，直到该协同程序 Yield 挂起让出CPU，所以这会导致，当协同程序处理占用过多的CPU时间时，其它协同程序，若不被手动调度到其它线程上面驱动，那么在该线程驱动的其它协程被等待执行会变得异常缓慢
6、通常我们只建议在异步操作上面，适用协同程序，如网络IO、文件IO、管道IO等。
7、老生常谈的问题，需要确保协同程序之间同步问题，避免产生死锁的问题，有些菜的不得了的家伙，单线程都能整死锁，虽然死锁常见于多核编程的场景上面。
8、必要点，必须确保协同程序切换流程的准确一致性，例如：调用一个异步函数，等待它的回调函数通知完成，且 Yield 挂起当前协程，不可以在该异步函数之中仅仅只是判断下，就随意的return，而不保证回调被调用。
可以这么说，如果大家手下要有这样的小伙伴，被你发现，当天就让他直接走人了，如果不知道，尚且情有可原，提点过还犯这种想偷懒的低级错误，这几乎可以想象，平常工作态度就有很大的问题，在生产项目之中，这会带来多大不可控，不可预测、安全性的风险，在软件工程学的角度来说，这是绝对不允许的，有的懒可以偷，有的懒不能偷，没有那本专业技术书籍，让人们这么解决问题。