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

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

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

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

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

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

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

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

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

總結幾點 （重要，不要混淆）：

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

2、代碼塊體中有co_await ，co_yield，co_return關鍵字，則為協程體代碼塊，運行到關鍵字位置會**“觸發協程掛起” ** ，此時原調用者代碼阻塞在resume函數位置，運行權重新回到調用者，此時resume會返回，調用者繼續執行；

3、特別的：

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

co_yield實現簡單掛起，簡單的立即放棄運行權，返回調用者，可恢復（異步應用場景相對較少，多用于循環生成器）；

co_return實現最后一次簡單掛起，立即放棄運行權，返回調用者，協程后續不再可恢復（應用于協程退出）；

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

5、協程管理類A，和可等待體B，他們沒有直接關系，是兩個不同的東西。可等待體B控制掛起時點的行為是局部的，協程控制A控制協程整體創建，運行，掛起，銷毀，異常捕獲等過程的行為是整體的；協程只對應有一個控制類A，但是內部可以有多次掛起操作，每次操作對應一個可等待對象；

庫開發

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

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

在此，我打個形象比喻：

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

要實現一個協程庫，他需要幾個東西：

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

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

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

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

實現思路

調度器：

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

2、調度算法采用簡單的等權重調度，也就是掛入協程隊列的task，輪流調度，每個被調度的task被調度的機會相同；

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

4、調度器中記錄著協程隊列的開始task和末尾task的handle，以便調度協程；

可等待體：

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

2、網絡套接字，tcp協議下異步listen，accept, send, recv 操作；

3、網絡套接字，udp協議下異步sendto, recvfrom 操作；

4、協程休眠，實現sleepFor，sleepForEx操作，分別實現協程任務的毫秒和微秒級休眠；

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

任務定義（task協程）：

1、task協程的promise_type中定義3個變量，

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

3、保存當前協程自身所屬調度器Scheduler的指針；

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

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

啟動協程調度：

1、實例化調度器 CoScheduler；

2、通過lambda表達方式定義task協程，并加入到調度器的協程隊列；

3、通過run方法啟動調度器調度運行各協程任務；

4、task協程中又可以動態嵌套生產新的task協程加入到調度隊列；

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

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

除調度協程外，協程隊列中會產生4個task，一個服務監聽器task，一個客戶端生成器task，服務端task，客戶端task

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

案例2：udp 廣播模式測試

再看看性能測試：

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

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

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

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

最后

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

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

代碼

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

實現文件

CLCoroutine.cpp