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

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

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

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

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

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

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

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

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

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

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

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

3、特別的：

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

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

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

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

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

庫開發(fā)

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

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

在此，我打個形象比喻：

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

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

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

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

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

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

實現(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é)程隊列的task，輪流調(diào)度，每個被調(diào)度的task被調(diào)度的機會相同；

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

4、調(diào)度器中記錄著協(xié)程隊列的開始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é)程休眠，實現(xiàn)sleepFor，sleepForEx操作，分別實現(xiàn)協(xié)程任務(wù)的毫秒和微秒級休眠；

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

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

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

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

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

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

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

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

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

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

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

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

先看測試效果：（后面會有源碼）

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

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

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

案例2：udp 廣播模式測試

再看看性能測試：

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

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

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

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

最后

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

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

代碼

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

實現(xiàn)文件

CLCoroutine.cpp