有棧協程與無棧協程

引言

關於協程是什麼這類基本概念我們不再多提，有興趣的朋友可以看看我寫的這篇文章《聊聊協程》。寫這篇文章的原因是當我對這個問題感到疑惑的時候發現CSDN上並沒有相關的文章，遂在有了一點理解以後想寫下一點對這個問題的看法，以幫助後來學習的朋友。

正文

如今雖不敢說協程已經是紅的發紫，但確實是越來越受到了大家的重視。Golang中的已經是隻有goroutine，以至於很多go程序員是隻知有協程，不知有線程了。就連C++這樣的“老頑固”也在最新的C++20中原生支持協程。更不用說很多活躍的語言如python，java等，也都是支持協程的。儘管這些協程可能名稱不同，甚至用法也不同，但它們都可以被劃分爲兩大類，一類是有(stackful) 協程，例如 goroutine，libco；一類是無棧 (stackless) 協程，例如C++的協程。

這裏我們想說的一點是所謂的有棧，無棧並不是說這個協程運行的時候有沒有棧，而是說協程之間是否存在調用棧（callbackStack）。其實仔細一想即可，但凡是個正在運行的程序，不管你是協程也好，線程也好，怎麼可能在運行的時候不使用棧空間呢，調用參數往哪擱，局部變量往哪擱。我們知道基本所有的主流語言在調用另外一個函數的時候都存在一個調用棧，我們來解釋一下調用棧這個詞：（圖片來源 維基百科）

這幅圖是有兩個棧幀的調用棧，我在這篇文章中對棧幀下過定義，即：函數的棧幀是指esp和ebp之間的一塊地址。拿上圖來說ebp存儲着Frame Pointer指向的地址，Return Address當然就是我們在執行完最新的棧幀以後下一步要執行的指令地址。esp當然就是當前指向棧頂的指針了。

有棧協程

很多地方又把協程稱爲subroutine，subroutine是什麼，就是函數。上古時期的計算機科學家們早就給出了概念，coroutine就是可以中斷並恢復執行的subroutine，從這個角度來看協程擁有調用棧並不是一個奇怪的事情。我們再來思考coroutine與subroutinue相比有什麼區別，你會發現區別僅有一個，就是coroutinue可以中斷並恢復，對應的操作就是yield/resume，這樣看來subroutinue不過是coroutinue的一個子集罷了。也就是說把協程當做一個特殊的函數調用，有棧協程就是我們理想中協程該有的模樣。

既然把其當做一個特殊的函數調用，對我們來說最嚴峻的挑戰就是如何像切換函數一樣去切換協程，難點在於除了像函數一樣切換出去，還要在某種條件滿足的時候切換回來，我們的做法可以是在協程內部存儲自身的上下文，並在需要切換的時候把上下文切換就可以了，我們知道上下文其實本質上就是寄存器，所以保存上下文實際上就是把寄存器的值保存下來，有兩種方法，一種是使用匯編，libco就使用了這種方法。還有一種是使用ucontext.h，這個封裝好的庫也可以幫我們完成相關工作。

彙編的話我們來看一看libco中對於32位機器的上下文切換操作是如何完成的：

	// 獲取第一個參數
    movl 4(%esp), %eax 
    // 參數的類型我們暫且理解爲一個擁有八個指針的數組，即regs
	| regs[7] |
	| regs[6] |
	| regs[5] |
	| regs[4] |
	| regs[3] |
	| regs[2] |
	| regs[1] |
	| regs[0] |
	--------------   <---EAX

    movl %esp,  28(%eax)  
    movl %ebp, 24(%eax)
    movl %esi, 20(%eax)
    movl %edi, 16(%eax)
    movl %edx, 12(%eax)
    movl %ecx, 8(%eax)
    movl %ebx, 4(%eax)
	// 想想看，這裏eax加偏移不就是對應了regs中的值嗎？這樣就把所有寄存器中的值保存在了參數中
 
	
	// ESP偏移八位就是第二個參數的偏移了，這樣我們就可以把第二個參數regs中的上下文切換到寄存器中了
    movl 8(%esp), %eax 
    movl 4(%eax), %ebx
    movl 8(%eax), %ecx
    movl 12(%eax), %edx  
    movl 16(%eax), %edi
    movl 20(%eax), %esi
    movl 24(%eax), %ebp
    movl 28(%eax), %esp

	ret
	// 這樣我們就完成了一次協程的切換

我們可以看到其實就是參數中傳入兩個協程的上下文結構，然後第一個參數執行保存上下文，然後把第二個參數的上下文存入寄存器，這樣就執行了兩個協程的切換。

當然我們上面提到了調用棧，那麼既然有調用棧，那麼肯定有一個執行的順序，即一定要把棧頂的協程全部運行完纔可以運行下一層的協程，這樣說可能比較抽象，我們舉一個簡單的例子：

主協程A中執行協程B，此時調用棧是在[A，B]和[A]之間切換，因爲B會主動讓出執行權，然後調用棧上此時就只有一個A了

B協程中執行C,D協程,此時調用棧是在[A，B，C]，[A，B]，[A，B，D]之間轉換的，

這樣看來我們總是隻能在調用棧頂的協程運行完以後才能去執行更低一層的協程，當然，這也是典型的非對稱協程，即協程之間有明顯的調用關係。

當然在我的描述中也可以看出有棧協程涉及到對於寄存器的保存和修改，也涉及到對每一個協程棧（實際運行的棧）的分配。對於寄存器來說，現代寄存器基本都是上百個字節的數據，還有每一個協程的棧，如果選擇了共享棧，又涉及到對棧上數據的拷貝，顯然在效率上來說相比無棧協程的確是有一些損失的。

無棧協程

那麼所謂的無棧協程是什麼呢？其實無棧協程的本質就是一個狀態機（state machine），它可以理解爲在另一個角度去看問題，即同一協程協程的切換本質不過是指令指針寄存器的改變。這裏推薦一篇文章，其內容是用C語言實現一個協程，其實就是一個無棧協程的實現。

我們來看一個使用libco的協程的例子，當然libco是一個有棧協程：

void* test(void* para){
	co_enable_hook_sys();
	int i = 0;
	poll(0, 0, 0. 1000); // 協程切換執行權，1000ms後返回
	i++;
	poll(0, 0, 0. 1000); // 協程切換執行權，1000ms後返回
	i--;
	return 0;
}

int main(){
	stCoRoutine_t* routine;
	co_create(&routine, NULL, test, 0);// 創建一個協程
	co_resume(routine); 
	co_eventloop( co_get_epoll_ct(),0,0 );
	return 0;
}

這段代碼實際的意義就是主協程跑一個協程去執行test函數，在test中我們需要兩次從協程中切換出去，這裏對應了兩個poll操作（hook機制，有興趣的朋友可以點擊這裏），hook後的poll所做的事情就是把當前協程的CPU執行權切換到調用棧的上一層，並在超時或註冊的fd就緒時返回（當然樣例這裏就只是超時了）。那麼無棧協程跑相同的代碼是怎麼樣的呢？其實就是翻譯成類似於以下代碼：

struct test_coroutine {
    int i;
    int __state = 0;
    void MoveNext() {
        switch(__state) {
        case 0:
            return frist();
        case 1:
            return second();
        case 2:
        	return third();
        }
    }
    void frist() {
        i = 0;
        __state = 1;
    }
    void second() {
        i++;
        _state = 2;
    }
    void third() {
    	i--;
    }
};

我們可以看到相比與有棧協程中的test函數，這裏把整個協程抽象成一個類，以原本需要執行切換的語句處爲界限，把函數劃分爲幾個部分，並在某一個部分執行完以後進行狀態轉移，在下一次調用此函數的時候就會執行下一部分，這樣的話我們就完全沒有必要像有棧協程那樣顯式的執行上下文切換了，我們只需要一個簡易的調度器來調度這些函數即可。

從執行時棧的角度來看，其實所有的協程共用的都是一個棧，即系統棧，也就也不必我們自行去給協程分配棧，因爲是函數調用，我們當然也不必去顯示的保存寄存器的值，而且相比有棧協程把局部變量放在新開的空間上，無棧協程直接使用系統棧使得CPU cache局部性更好，同時也使得無棧協程的中斷和函數返回幾乎沒有區別，這樣也可以凸顯出無棧協程的高效。

對稱協程與非對稱協程

其實對於“對稱”這個名詞，闡述的實際是協程之間的關係，用大白話來說就是對稱協程就是說協程之間人人平等，沒有誰調用誰一說，大家都是一樣的，而非對稱協程就是協程之間存在明顯的調用關係。

簡單來說就是這樣：

• 對稱協程 Symmetric Coroutine：任何一個協程都是相互獨立且平等的，調度權可以在任意協程之間轉移。
• 非對稱協程 Asymmetric Coroutine：協程出讓調度權的目標只能是它的調用者，即協程之間存在調用和被調用關係。

其實兩者的實現我覺得其實差異不大，非對稱協程其實就是擁有調用棧，而非對稱協程則是大家都平等，不需要調用棧，只需要一個數據結構存儲所有未執行完的協程即可。至於哪種更優？我覺得分情況，如果你使用協程的目的是爲了優化一些IO密集型應用，那麼協程切換出去的時候就是它等待事件到來的時候，此時你就算切換過去也沒有什麼意義，還不如等到事件到來的時候自動切換回去。

其實上面說的是有一些問題，因爲這個執行權的切換實際上是（調用者–被調用者）之間的切換，對稱就是它們之間都是平等的，就是假如A協程執行了B，C協程，那麼B協程可以切換回A，也可以切換回C。而非對稱只能是B切換回A，A切換回C，C再切換回A，以此類推。

這樣看起來顯然非對稱協程相比之下更爲符合我們的認知，因爲對稱協程目前我不知道如何選擇一個合適的協程來獲得CPU執行權，正如上面所說，此協程可能正在等待事件。當然如果調度算法足夠優秀的話，對稱協程也是可取的。

參考：

• 博文《有棧協程與無棧協程》
• 博文《使用ucontext 來手動切換上下文》
• 博文《c +±無棧協程與有棧協程有何不同？》
• 博文《使用 C 語言實現協程》
• 博文《什麼是coroutine》
• 博文《協程（一）快速理解協程的定義和分類》
• 博文《破解 Kotlin 協程 番外篇(2) - 協程的幾類常見的實現》