c++20出來有一段時(shí)間了。其中一大功能就是終于支持協(xié)程了（c++作為行業(yè)大哥大級(jí)別的語言，居然到C++20才開始支持協(xié)程，我也是無力吐槽了，讓多少人等了多少年，等了多少青春）但千呼萬喚他終于還是來了，c++標(biāo)準(zhǔn)委員會(huì)的謹(jǐn)慎態(tài)度也造就了c++20的給出來協(xié)程：“性能之優(yōu)秀”，“開發(fā)之靈活”和讓人勸退的“門檻之高”。

不過話說回來，c++從出身就注定了背負(fù)性能使命，他不是為簡單為應(yīng)用層維度開發(fā)的語言（如果應(yīng)用層你大可以用python java ruby lua等語言），他是一門可以開發(fā)其他語言的語言，所以追逐高性能和靈活性，舍棄矯情的低門檻，畢竟C++不是設(shè)計(jì)來給所有人用的語言。

之前用過python的協(xié)程，協(xié)程易用程度高，所以c++20到來也想嘗試c++狀態(tài)下的協(xié)程，但是接觸以后發(fā)現(xiàn)問題，c++20的協(xié)程狀態(tài)是：只有基礎(chǔ)設(shè)施，也就是實(shí)現(xiàn)了無棧協(xié)程的所有機(jī)制和功能，但沒有封裝到具體的應(yīng)用層標(biāo)準(zhǔn)庫STL。此時(shí)大部分人就只能干瞪眼了，由于復(fù)雜的協(xié)程運(yùn)作機(jī)制，沒有實(shí)現(xiàn)標(biāo)準(zhǔn)庫的情況下，說要用上協(xié)程你是在開玩笑，網(wǎng)上一致的意見c++20是半成品，要真的用上c++協(xié)程得等c++23協(xié)程標(biāo)準(zhǔn)庫完善后才行。

一貫本著不作死就不會(huì)死得態(tài)度，只會(huì)用庫不懂底層機(jī)制，那不是用c++的態(tài)度，所以深入學(xué)習(xí)c++20協(xié)程，半個(gè)月時(shí)間，寫了一個(gè)簡單的協(xié)程庫，在此過程中也對(duì)復(fù)雜的c++協(xié)程機(jī)制有了深入的了解。話說asio和cppcoro兩個(gè)庫已經(jīng)支持了c++20協(xié)程，但是我覺得還是龐大和復(fù)雜，對(duì)于想通過看庫源代碼學(xué)習(xí)c++協(xié)程的同學(xué)，我覺得還是算了，在不懂協(xié)程機(jī)理的情況下，你連看源代碼都看不懂好吧！！有人會(huì)說有源代碼了你都看不懂，你是吹牛。那還真不是，c++協(xié)程在語法上會(huì)有些顛覆你的三觀，我們來舉個(gè)例子：

有人說func是一個(gè)協(xié)程函數(shù)，main中的func運(yùn)行后會(huì)返回0，也就是 co是一個(gè)int變量值為0；

如果你按常規(guī)代碼理解，沒錯(cuò)。但是在c++協(xié)程的世界，他完全不是上面說的情況。

正確的情況是： func在這里是一個(gè)協(xié)程生成器（這個(gè)概念很重要，他不是函數(shù)）返回值co是一個(gè)協(xié)程管理類A關(guān)聯(lián)了具體協(xié)程執(zhí)行體后的協(xié)程實(shí)例的控制句柄（的包裝對(duì)象）。明確co不是協(xié)程實(shí)例（協(xié)程幀），是協(xié)程實(shí)例的控制句柄的包裝對(duì)象，在func(1)執(zhí)行之后他只是“動(dòng)態(tài)”生成了一個(gè)協(xié)程實(shí)例，并把控制句柄返回給用戶，但此時(shí)這個(gè)協(xié)程是掛起的，協(xié)程體{}代碼塊還沒有被執(zhí)行過，所以不存在返回值。這非常的繞，讓人難以理解（后面還有更難理解的）。

在三次co.hd.resume();調(diào)用后協(xié)程才被完全執(zhí)行完畢，此時(shí)a=1，b=0;

返回值保存在協(xié)程的實(shí)例（協(xié)程幀）中，通過協(xié)程管理類A的內(nèi)部流程控制函數(shù)管理著返回值（A的promise_type定義了所有的協(xié)程控制行為）。

總結(jié)幾點(diǎn) （重要，不要混淆）：

1、“協(xié)程管理類A是包含協(xié)程行為控制的類定義 ，A不是協(xié)程，形如 A func(int a, …){ … } 才是一個(gè)完整的協(xié)程定義”；所以A func1(){}; A func2(){}; A func3(){}; 都可以與同一個(gè)協(xié)程控制A綁定，但他們是3個(gè)不同的協(xié)程定義，只是協(xié)程控制行為都為A。好處是，你可以用一個(gè)std::vector< A > 保存下這3個(gè)不同的協(xié)程，他們的主協(xié)程體（功能實(shí)現(xiàn)）各不相同。要讓A為一個(gè)協(xié)程管理類，必須包含struct promise_type{}定義，和一個(gè)控制句柄對(duì)象std::coroutine_handle< promise_type > hd; 特別的，A可以不實(shí)現(xiàn)await_xxx接口，他可以不是可等待體。

2、代碼塊體中有co_await ，co_yield，co_return關(guān)鍵字，則為協(xié)程體代碼塊，運(yùn)行到關(guān)鍵字位置會(huì)**“觸發(fā)協(xié)程掛起” ** ，此時(shí)原調(diào)用者代碼阻塞在resume函數(shù)位置，運(yùn)行權(quán)重新回到調(diào)用者，此時(shí)resume會(huì)返回，調(diào)用者繼續(xù)執(zhí)行；

3、特別的：

co_await可以與可等待對(duì)象配合，形成更為復(fù)雜的協(xié)程掛起行為：一般異步IO操作，都是通過co_await + io可等待對(duì)象，完成異步操作后掛起協(xié)程，等待異步io完成后，再由**“調(diào)度器”**恢復(fù)協(xié)程繼續(xù)運(yùn)行，從而發(fā)揮異步的意義，形成io復(fù)雜度向cpu復(fù)雜度的轉(zhuǎn)移。因此，協(xié)程解決的是問題是“異步”而不是“并行”，要實(shí)現(xiàn)并行只能考慮多線程或多進(jìn)程，協(xié)程可以將單個(gè)線程cpu效率發(fā)揮到最大，而不會(huì)被io阻塞浪費(fèi)掉當(dāng)前線程的cpu算能，那問題來了，如果我們用 協(xié)程 + 多線程/多進(jìn)程 結(jié)合模式呢，那恭喜你，世界都將是你的；

co_yield實(shí)現(xiàn)簡單掛起，簡單的立即放棄運(yùn)行權(quán)，返回調(diào)用者，可恢復(fù)（異步應(yīng)用場景相對(duì)較少，多用于循環(huán)生成器）；

co_return實(shí)現(xiàn)最后一次簡單掛起，立即放棄運(yùn)行權(quán)，返回調(diào)用者，協(xié)程后續(xù)不再可恢復(fù)（應(yīng)用于協(xié)程退出）；

4、可等待體（類形如 struct B{ await_ready();await_suspend();await_resume(); } 實(shí)現(xiàn) 三個(gè)await_xxx接口的類B是一個(gè)可等待體定義），他的實(shí)例是一個(gè)可等待對(duì)象；其中await_suspend()在執(zhí)行后（不是執(zhí)行前），會(huì)觸發(fā)當(dāng)前協(xié)程掛起（記住，此處不是可等待對(duì)象掛起，是co_await 此可等待對(duì)象的當(dāng)前協(xié)程掛起，不能混淆，由于概念不清，我在這個(gè)位置耽誤了很久的時(shí)間）

5、協(xié)程管理類A，和可等待體B，他們沒有直接關(guān)系，是兩個(gè)不同的東西。可等待體B控制掛起時(shí)點(diǎn)的行為是局部的，協(xié)程控制A控制協(xié)程整體創(chuàng)建，運(yùn)行，掛起，銷毀，異常捕獲等過程的行為是整體的；協(xié)程只對(duì)應(yīng)有一個(gè)控制類A，但是內(nèi)部可以有多次掛起操作，每次操作對(duì)應(yīng)一個(gè)可等待對(duì)象；

庫開發(fā)

本文重點(diǎn)是庫實(shí)戰(zhàn)開發(fā)，關(guān)于協(xié)程框架中的 3大概念：協(xié)程定義類及promise_type{}，可等待體awaitable，協(xié)程控制句柄std::coroutine_handle< > ，此處不做介紹，自行了解。

但是要介紹一下協(xié)程調(diào)度的運(yùn)行邏輯，以此加深庫開發(fā)過程的理解。這個(gè)過程在多線程下面是由內(nèi)核管理的我們很少會(huì)了解，但是到了協(xié)程，你還要自己寫庫，那必須自己實(shí)現(xiàn)協(xié)程的調(diào)度算法和event loop模式

在此，我打個(gè)形象比喻：

現(xiàn)在一個(gè)家中有5個(gè)兒子，他們能力各不相同（工作者協(xié)程），還有一個(gè)媽媽（調(diào)度者協(xié)程），現(xiàn)在只有一臺(tái)電腦（單線程時(shí)間片），同一時(shí)刻，這臺(tái)電腦只能被老媽分給其中一個(gè)兒子來使用（協(xié)程搶占），其中一個(gè)兒子首先得到電腦開始工作（協(xié)程恢復(fù)），其他兒子只能等著無法工作（協(xié)程等待狀態(tài)），有電腦的兒子工作一會(huì)后此時(shí)他發(fā)送一封對(duì)外郵件（可等待對(duì)象）但要等待郵件回復(fù)后才能繼續(xù)工作（io等待完成），因?yàn)槠渌舜藭r(shí)還在等著用電腦而自己此時(shí)不具備繼續(xù)工作的條件，所以他識(shí)趣的放棄電腦的使用權(quán)，并把電腦交還給老媽（協(xié)程掛起等待，執(zhí)行權(quán)交還caller）并等著老媽下次再把電腦給他使用，老媽拿到電腦后（調(diào)度協(xié)程恢復(fù)執(zhí)行）檢查是否有回復(fù)郵件到來（調(diào)度協(xié)程檢查事件完成，對(duì)應(yīng)事件循環(huán)iocp/epoll），如果有了，老媽檢查這封回復(fù)郵件是回復(fù)給哪個(gè)兒子的，并叫來對(duì)應(yīng)的兒子（協(xié)程調(diào)度），把電腦交給他（協(xié)程恢復(fù)），得到電腦的兒子打開回復(fù)郵件拿到結(jié)果（await_resume() 返回異步io結(jié)果）繼續(xù)工作，…， 不斷循環(huán)。至此，完成一個(gè)協(xié)程完整調(diào)度流程。

要實(shí)現(xiàn)一個(gè)協(xié)程庫，他需要幾個(gè)東西：

1、實(shí)現(xiàn)具體的異步操作的可等待體（類似比喻中的發(fā)郵件操作，定義是否將電腦歸還，獲取回復(fù)后打開查詢結(jié)果等行為）；

2、協(xié)程控制類A（他是一個(gè)協(xié)程任務(wù)task），A的promise_type中應(yīng)該記錄協(xié)程的相關(guān)狀態(tài)，記錄掛起點(diǎn)的可等待對(duì)象的指針（很重要），可等待對(duì)象也可以充當(dāng)task和調(diào)度協(xié)程，信息交換的媒介，可等待對(duì)象指針通過 await_suspend() 過程傳遞給task的promise做記錄并保存。調(diào)度協(xié)程通過可等待對(duì)象指針在異步操作完成時(shí)將異步操作結(jié)果傳回給等待的task。

3、 如總結(jié)和比喻所說，最重要的，還需要一個(gè)“協(xié)程調(diào)度器”。第一、他有一個(gè)主調(diào)度協(xié)程，調(diào)度協(xié)程具有一系列的調(diào)度算法，他的工作就是監(jiān)測io異步完成事件的到來和分配執(zhí)行權(quán)給task，第二，他維護(hù)有一個(gè)task協(xié)程隊(duì)列（可以多種方法實(shí)現(xiàn)），隊(duì)列記錄著所有的協(xié)程實(shí)例的句柄，這個(gè)隊(duì)列是為了協(xié)程調(diào)度準(zhǔn)備的。

（注：之所以C++20無法直接使用的原因，其實(shí)就是，以上3個(gè)具體的工具沒有現(xiàn)成的庫，由于高度靈活，c++希望使用者自己實(shí)現(xiàn)以上組件，這讓用慣成品庫的我們非常難受，望而卻步，天天喊著等c++23的標(biāo)準(zhǔn)庫，但c++23也不能將所有的需求都囊括，遇到特殊需求還是要自己寫）

實(shí)現(xiàn)思路

調(diào)度器：

1 調(diào)度協(xié)程中的event loop本例是在Windows下采用的iocp模型（linux下可以使用epoll也很好改，原理一樣）

2、調(diào)度算法采用簡單的等權(quán)重調(diào)度，也就是掛入?yún)f(xié)程隊(duì)列的task，輪流調(diào)度，每個(gè)被調(diào)度的task被調(diào)度的機(jī)會(huì)相同；

3、完成事件標(biāo)記和task恢復(fù)，業(yè)務(wù)分開，這樣目的是使得通過co_yield簡單掛起的任務(wù)有重新執(zhí)行的機(jī)會(huì)（因?yàn)閏o_yeild不會(huì)在后續(xù)觸發(fā)完成事件）

4、調(diào)度器中記錄著協(xié)程隊(duì)列的開始task和末尾task的handle，以便調(diào)度協(xié)程；

可等待體：

1、文件file異步read，write操作；

2、網(wǎng)絡(luò)套接字，tcp協(xié)議下異步listen，accept, send, recv 操作；

3、網(wǎng)絡(luò)套接字，udp協(xié)議下異步sendto, recvfrom 操作；

4、協(xié)程休眠，實(shí)現(xiàn)sleepFor，sleepForEx操作，分別實(shí)現(xiàn)協(xié)程任務(wù)的毫秒和微秒級(jí)休眠；

5、在iocp模型下以上api都提供了重疊io操作，此時(shí)將api執(zhí)行成功的重疊io操作，將對(duì)應(yīng)的可等待體指針記錄到當(dāng)前協(xié)程變量中（promise_type中的變量），一旦完成事件到來，調(diào)度協(xié)程就會(huì)設(shè)置可等待對(duì)象的完成標(biāo)記狀態(tài)為true，調(diào)度協(xié)程只要在輪詢中逐個(gè)檢查task保存的可等待對(duì)象指針，檢查完成標(biāo)記是否為true，為true恢復(fù)執(zhí)行該協(xié)程，為false則跳過該協(xié)程，繼續(xù)輪詢 event loop;

任務(wù)定義（task協(xié)程）：

1、task協(xié)程的promise_type中定義3個(gè)變量，

2、保存當(dāng)前掛起的可等待提指針，如果當(dāng)前協(xié)程不是io掛起或者是沒有掛起，該指針應(yīng)該為null

3、保存當(dāng)前協(xié)程自身所屬調(diào)度器Scheduler的指針；

4、保存此刻協(xié)程隊(duì)列中的前一個(gè)協(xié)程task的handle和后一個(gè)協(xié)程task的handle；

5、若當(dāng)前task的可等待對(duì)象完成標(biāo)記為true，則調(diào)度協(xié)程會(huì)將該task的before task和behind task鏈接，將該task的handle移動(dòng)到協(xié)程隊(duì)列尾部，并且resume task，完成調(diào)度和恢復(fù)；

啟動(dòng)協(xié)程調(diào)度：

1、實(shí)例化調(diào)度器 CoScheduler；

2、通過lambda表達(dá)方式定義task協(xié)程，并加入到調(diào)度器的協(xié)程隊(duì)列；

3、通過run方法啟動(dòng)調(diào)度器調(diào)度運(yùn)行各協(xié)程任務(wù)；

4、task協(xié)程中又可以動(dòng)態(tài)嵌套生產(chǎn)新的task協(xié)程加入到調(diào)度隊(duì)列；

先看測試效果：（后面會(huì)有源碼）

案例1：tcp 服務(wù)器/客戶端模型測試

除調(diào)度協(xié)程外，協(xié)程隊(duì)列中會(huì)產(chǎn)生4個(gè)task，一個(gè)服務(wù)監(jiān)聽器task，一個(gè)客戶端生成器task，服務(wù)端task，客戶端task

多個(gè)協(xié)程任務(wù)的異步交替執(zhí)行，就是在一個(gè)協(xié)程遇到 可掛起的異步操作時(shí)，比如connect accept send recv等，把運(yùn)行權(quán)限歸還給調(diào)度器，當(dāng)完成事件到來，調(diào)度器又把執(zhí)行權(quán)返回給task，形成執(zhí)行權(quán)在調(diào)度器和task之間反復(fù)橫跳的情況，實(shí)現(xiàn)cpu的多任務(wù)復(fù)用；

案例2：udp 廣播模式測試

再看看性能測試：

同樣采用案例1和案例2的模型，但這次tcp采用100個(gè)server/client共200個(gè)task，udp采用20個(gè)braodcast/reciever共40個(gè)task來測試并發(fā)效果，做一下統(tǒng)計(jì)；效果如下

按server和client一次完整的send和recv，也就是4此tcp通信，記錄為一次有效通訊記錄，記為1times，

則結(jié)果顯示，在coro=200時(shí)候，單個(gè)線程平均每秒將完成3萬次有效通訊（雖然是自導(dǎo)自演，但是協(xié)程的功能完整實(shí)現(xiàn)了，性能可觀）

由于udp是單向非鏈接協(xié)議，速度會(huì)比tcp快得多，按一次sendto和recvfrom記為一次有效通訊，則在coro=40時(shí)候，單線程每秒有效通訊18萬次。

最后

c++協(xié)程理解之后并不是很難，并且只要api提供異步方案，都可以實(shí)現(xiàn)協(xié)程庫的封裝，比如mysql，redis等異步操作，后續(xù)都可以依葫蘆畫瓢，很快實(shí)現(xiàn)c++協(xié)程庫的開發(fā)。

本庫開發(fā)只是為記錄c++協(xié)程學(xué)習(xí)的經(jīng)歷，很多功能后續(xù)還需完善。目前支持在windows下的各位file socket sleep的異步操作，后續(xù)可擴(kuò)展支持linux的epoll模型。

代碼

頭文件CLCoroutine.h 其中的void test_coroutine_tcp_server()和void test_coroutine_udp_random_broadcast()就是案例1和案例2的測試代碼。

實(shí)現(xiàn)文件

CLCoroutine.cpp