如今雖不敢說協程已經是紅的發紫,但確實是越來越受到了大家的重視。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執行權,正如上面所說,此協程可能正在等待事件。當然如果調度算法足夠優秀的話,對稱協程也是可取的。
-
cpu
+關注
關注
68文章
10855瀏覽量
211594 -
程序
+關注
關注
117文章
3785瀏覽量
81005 -
函數
+關注
關注
3文章
4327瀏覽量
62573 -
C++
+關注
關注
22文章
2108瀏覽量
73623
發布評論請先 登錄
相關推薦
評論