goroutine背後的系統知識[轉]

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

Go語言從誕生到普及已經三年了，先行者大都是Web開發的背景，也有了一些普及型的書籍，可系統開發背景的人在學習這些書籍的時候，總有語焉不詳的感覺，網上也有若干流傳甚廣的文章，可其中或多或少總有些與事實不符的技術描述。希望這篇文章能為比較缺少系統編程背景的Web開發人員介紹一下goroutine背後的系統知識。

1. 作業系統與運行庫
2. 並發與並行 (Concurrency and Parallelism)
3. 線程的調度
4. 並發編程架構
5. goroutine

1. 作業系統與運行庫

對於普通的電腦使用者來說，能理解應用程式是運行在作業系統之上就足夠了，可對於開發人員，我們還需要瞭解我們寫的程式是如何在作業系統之上運行起來的，作業系統如何為應用程式提供服務，這樣我們才能分清楚哪些服務是作業系統提供的，而哪些服務是由我們所使用的語言的運行庫提供的。

除了記憶體管理、檔案管理、進程管理、外設管理等等內部模組以外，作業系統還提供了許多外部介面供應用程式使用，這些介面就是所謂的“系統調用”。從DOS時代開始，系統調用就是通過非強制中斷的形式來提供，也就是著名的 INT 21，程式把需要調用的功能編號放入AH寄存器，把參數放入其他指定的寄存器，然後調用 INT 21，中斷返回後，程式從指定的寄存器(通常是AL)裡取得傳回值。這樣的做法一直到奔騰2也就是P6出來之前都沒有變，譬如windows通過 INT 2E 提供系統調用，Linux則是 INT 80，只不過後來的寄存器比以前大一些，而且可能再多一層跳轉表查詢。後來，Intel和AMD分別提供了效率更高的SYSENTER/SYSEXIT和SYSCALL/SYSRET指令來代替之前的中斷方式，略過了耗時的特權層級檢查以及寄存器壓棧出棧的操作，直接完成從 RING 3 程式碼片段到 RING 0 程式碼片段的轉換。

系統調用都提供什麼功能呢？用作業系統的名字加上對應的中斷編號到Google上一查就可以得到完整的列表 (Windows, Linux)，這個列表就是作業系統和應用程式之間溝通的協議，如果需要超出此協議的功能，我們就只能在自己的代碼裡去實現，譬如，對於記憶體管理，作業系統只提供進程層級的記憶體段的管理，譬如Windows的virtualmemory系列，或是Linux的brk，作業系統不會去在乎應用程式如何為建立對象分配記憶體，或是如何做記憶體回收，這些都需要應用程式自己去實現。如果超出此協議的功能無法自己實現，那我們就說該作業系統不支援該功能，舉個例子，Linux在2.6之前是不支援多線程的，無論如何在程式裡類比，我們都無法做出多個可以同時啟動並執行並符合POSIX 1003.1c語義標準的調度單元。

可是，我們寫程式並不需要去調用中斷或是SYSCALL指令，這是因為作業系統提供了一層封裝，在Windows上，它是NTDLL.DLL，也就是常說的Native API，我們不但不需要去直接調用INT 2E或SYSCALL，準確的說，我們不能直接去調用INT 2E或SYSCALL，因為Windows並沒有公開其調用規範，直接使用INT 2E或SYSCALL無法保證未來的相容性。在Linux上則沒有這個問題，系統調用的列表都是公開的，而且Linus非常看重相容性，不會去做任何更改，glibc裡甚至專門提供了syscall(2)來方便使用者直接用編號調用，不過，為瞭解決glibc和核心之間不同版本相容性帶來的麻煩，以及為了提高某些調用的效率(譬如_NR gettimeofday)，Linux上還是對部分系統調用做了一層封裝，就是VDSO (早期叫linux-gate.so)。

可是，我們寫程式也很少直接調用NTDLL或者VDSO，而是通過更上一層的封裝，這一層處理了參數準備和傳回值格式轉換、以及出錯處理和錯誤碼轉換，這就是我們所使用語言的運行庫，對於C語言，Linux上是glibc，Windows上是kernel32(或調用msvcrt)，對於其他語言，譬如Java，則是JRE，這些“其他語言”的運行庫通常最終還是調用glibc或kernel32。

“運行庫”這個詞其實不止包括用於和編譯後的目標執行程式進行連結的庫檔案，也包括了指令碼語言或位元組碼解釋型語言的運行環境，譬如Python，C#的CLR，Java的JRE。

對系統調用的封裝只是運行庫的很小一部分功能，運行庫通常還提供了諸如字串處理、數學計算、常用資料結構容器等等不需要作業系統支援的功能，同時，運行庫也會對作業系統支援的功能提供更易用更進階的封裝，譬如帶緩衝和格式的IO、線程池。

所以，在我們說“某某語言新增了某某功能”的時候，通常是這麼幾種可能：

• 支援新的語義或文法，從而便於我們描述和解決問題。譬如Java的泛型、Annotation、lambda運算式。
• 提供了新的工具或類庫，減少了我們開發的代碼量。譬如Python 2.7的argparse
• 對系統調用有了更良好更全面的封裝，使我們可以做到以前在這個語言環境裡做不到或很難做到的事情。譬如Java NIO

但任何一門語言，包括其運行庫和運行環境，都不可能創造出作業系統不支援的功能，Go語言也是這樣，不管它的特性描述看起來多麼炫麗，那必然都是其他語言也可以做到的，只不過Go提供了更方便更清晰的語義和支援，提高了開發的效率。

2. 並發與並行 (Concurrency and Parallelism)

並發是指程式的邏輯結構。非並發的程式就是一根竹竿捅到底，只有一個邏輯控制流程，也就是順序執行的(Sequential)程式，在任何時刻，程式只會處在這個邏輯控制流程的某個位置。而如果某個程式有多個獨立的邏輯控制流程，也就是可以同時處理(deal)多件事情，我們就說這個程式是並發的。這裡的“同時”，並不一定要是真正在時鐘的某一時刻(那是運行狀態而不是邏輯結構)，而是指：如果把這些邏輯控制流程畫成時序流程圖，它們在時間軸上是可以重疊的。

並行是指程式的運行狀態。如果一個程式在某一時刻被多個CPU流水線同時進行處理，那麼我們就說這個程式是以並行的形式在運行。（嚴格意義上講，我們不能說某程式是“並行”的，因為“並行”不是描述程式本身，而是描述程式的運行狀態，但這篇小文裡就不那麼咬文嚼字，以下說到“並行”的時候，就是指代“以並行的形式運行”）顯然，並行一定是需要硬體支援的。

而且不難理解：

• 並發是並行的必要條件，如果一個程式本身就不是並發的，也就是只有一個邏輯控制流程，那麼我們不可能讓其被平行處理。
• 並發不是並行的充分條件，一個並發的程式，如果只被一個CPU流水線進行處理(通過分時)，那麼它就不是並行的。
• 並發只是更符合現實問題本質的表達方式，並發的最初目的是簡化代碼邏輯，而不是使程式啟動並執行更快；

這幾段略微抽象，我們可以用一個最簡單的例子來把這些概念執行個體化：用C語言寫一個最簡單的HelloWorld，它就是非並發的，如果我們建立多個線程，每個線程裡列印一個HelloWorld，那麼這個程式就是並發的，如果這個程式運行在老式的單核CPU上，那麼這個並發程式還不是並行的，如果我們用多核多CPU且支援多任務的作業系統來運行它，那麼這個並發程式就是並行的。

還有一個略微複雜的例子，更能說明並發不一定可以並行，而且並發不是為了效率，就是Go語言例子裡計算素數的sieve.go。我們從小到大針對每一個因子啟動一個程式碼片段，如果當前驗證的數能被當前因子除盡，則該數不是素數，如果不能，則把該數發送給下一個因子的程式碼片段，直到最後一個因子也無法除盡，則該數為素數，我們再啟動一個它的程式碼片段，用於驗證更大的數字。這是符合我們計算素數的邏輯的，而且每個因子的代碼處理片段都是相同的，所以程式非常的簡潔，但它無法被並行，因為每個片段都依賴於前一個片段的處理結果和輸出。

並發可以通過以下方式做到：

1. 顯式地定義並觸發多個程式碼片段，也就是邏輯控制流程，由應用程式或作業系統對它們進行調度。它們可以是獨立無關的，也可以是相互依賴需要互動的，譬如上面提到的素數計算，其實它也是個經典的生產者和消費者的問題：兩個邏輯控制流程A和B，A產生輸出，當有了輸出後，B取得A的輸出進行處理。線程只是實現並發的其中一個手段，除此之外，運行庫或是應用程式本身也有多種手段來實現並發，這是下節的主要內容。

2. 隱式地放置多個程式碼片段，在系統事件發生時觸發執行相應的程式碼片段，也就是事件驅動的方式，譬如某個連接埠或管道接收到了資料(多路IO的情況下)，再譬如進程接收到了某個訊號(signal)。

並行可以在四個層面上做到：

1. 多台機器。自然我們就有了多個CPU流水線，譬如Hadoop叢集裡的MapReduce任務。
2. 多CPU。不管是真的多顆CPU還是多核還是超執行緒，總之我們有了多個CPU流水線。
3. 單CPU核裡的ILP(Instruction-level parallelism)，指令級並行。通過複雜的製造工藝和對指令的解析以及分支預測和亂序執行，現在的CPU可以在單個刻度內執行多條指令，從而，即使是非並發的程式，也可能是以並行的形式執行。
4. 單指令多資料(Single instruction, multiple data. SIMD)，為了多媒體資料的處理，現在的CPU的指令集支援單條指令對多條資料進行操作。

其中，1牽涉到分散式處理，包括資料的分布和任務的同步等等，而且是基於網路的。3和4通常是編譯器和CPU的開發人員需要考慮的。這裡我們說的並行主要針對第2種：單台機器內的多核CPU並行。

關於並發與並行的問題，Go語言的作者Rob Pike專門就此寫過一個投影片：

http://talks.golang.org/2012/waza.slide

在CMU那本著名的《Computer Systems: A Programmer’s Perspective》裡的這張圖也非常直觀清晰：

3. 線程的調度

上一節主要說的是並發和並行的概念，而線程是最直觀的並發的實現，這一節我們主要說作業系統如何讓多個線程並發的執行，當然在多CPU的時候，也就是並行的執行。我們不討論進程，進程的意義是“隔離的執行環境”，而不是“單獨的執行序列”。

我們首先需要理解IA-32 CPU的指令控制方式，這樣才能理解如何在多個指令序列(也就是邏輯控制流程)之間進行切換。CPU通過CS:EIP寄存器的值確定下一條指令的位置，但是CPU並不允許直接使用MOV指令來更改EIP的值，必須通過JMP系列指令、CALL/RET指令、或INT中斷指令來實現代碼的跳轉；在指令序列間切換的時候，除了更改EIP之外，我們還要保證代碼可能會使用到的各個寄存器的值，尤其是棧指標SS:ESP，以及EFLAGS標誌位等，都能夠恢複到目標指令序列上次執行到這個位置時候的狀態。

線程是作業系統對外提供的服務，應用程式可以通過系統調用讓作業系統啟動線程，並負責隨後的線程調度和切換。我們先考慮單顆單核CPU，作業系統核心與應用程式其實是也是在共用同一個CPU，當EIP在應用程式程式碼片段的時候，核心並沒有控制權，核心並不是一個進程或線程，核心只是以實模式啟動並執行，程式碼片段許可權為RING 0的記憶體中的程式，只有當產生中斷或是應用程式呼叫系統調用的時候，控制權才轉移到核心，在核心裡，所有代碼都在同一個地址空間，為了給不同的線程提供服務，核心會為每一個線程建立一個核心堆棧，這是線程切換的關鍵。通常，核心會在時鐘中斷裡或系統調用返回前(考慮到效能，通常是在不頻繁發生的系統調用返回前)，對整個系統的線程進行調度，計算當前線程的剩餘時間片，如果需要切換，就在“可運行”的線程隊列裡計算優先順序，選出目標線程後，則儲存當前線程的運行環境，並恢複目標線程的運行環境，其中最重要的，就是切換堆棧指標ESP，然後再把EIP指向目標線程上次被移出CPU時的指令。Linux核心在實現線程切換時，耍了個花槍，它並不是直接JMP，而是先把ESP切換為目標線程的核心棧，把目標線程的代碼地址壓棧，然後JMP到switch_to()，相當於偽造了一個CALL switch_to()指令，然後，在__switch_to()的最後使用RET指令返回，這樣就把棧裡的目標線程的代碼地址放入了EIP，接下來CPU就開始執行目標線程的代碼了，其實也就是上次停在switch_to這個宏展開的地方。

這裡需要補充幾點：(1) 雖然IA-32提供了TSS (Task State Segment)，試圖簡化作業系統進行線程調度的流程，但由於其效率低下，而且並不是通用標準，不利於移植，所以主流作業系統都沒有去利用TSS。更嚴格的說，其實還是用了TSS，因為只有通過TSS才能把堆棧切換到核心堆棧指標SS0:ESP0，但除此之外的TSS的功能就完全沒有被使用了。(2) 線程從使用者態進入核心的時候，相關的寄存器以及使用者態程式碼片段的EIP已經儲存了一次，所以，在上面所說的核心態線程切換時，需要儲存和恢複的內容並不多。(3) 以上描述的都是搶佔式(preemptively)的調度方式，核心以及其中的硬體驅動也會在等待外部資源可用的時候主動調用schedule()，使用者態的代碼也可以通過sched_yield()系統調用主動發起調度，讓出CPU。

現在我們一台普通的PC或服務裡通常都有多顆CPU (physical package)，每顆CPU又有多個核 (processor core)，每個核又可以支援超執行緒 (two logical processors for each core)，也就是邏輯處理器。每個邏輯處理器都有自己的一套完整的寄存器，其中包括了CS:EIP和SS:ESP，從而，以作業系統和應用的角度來看，每個邏輯處理器都是一個單獨的流水線。在多處理器的情況下，線程切換的原理和流程其實和單一處理器時是基本一致的，核心代碼只有一份，當某個CPU上發生時鐘中斷或是系統調用時，該CPU的CS:EIP和控制權又回到了核心，核心根據調度策略的結果進行線程切換。但在這個時候，如果我們的程式用線程實現了並發，那麼作業系統可以使我們的程式在多個CPU上實現並行。

這裡也需要補充兩點：(1) 多核的情境裡，各個核之間並不是完全對等的，譬如在同一個核上的兩個超執行緒是共用L1/L2緩衝的；在有NUMA支援的情境裡，每個核訪問記憶體不同地區的延遲是不一樣的；所以，多核情境裡的線程調度又引入了“調度域”(scheduling domains)的概念，但這不影響我們理解線程切換機制。(2) 多核的情境下，中斷髮給哪個CPU？非強制中斷(包括除以0，缺頁異常，INT指令)自然是在觸發該中斷的CPU上產生，而硬中斷則又分兩種情況，一種是每個CPU自己產生的中斷，譬如時鐘，這是每個CPU處理自己的，還有一種是外部中斷，譬如IO，可以通過APIC來指定其送給哪個CPU；因為發送器只能控制當前的CPU，所以，如果IO中斷沒有進行均勻的分配的話，那麼和IO相關的線程就只能在某些CPU上運行，導致CPU負載不均，進而影響整個系統的效率。

4. 並發編程架構

以上大概介紹了一個用多線程來實現並發的程式是如何被作業系統調度以及並存執行(在有多個邏輯處理器時)，同時大家也可以看到，程式碼片段或者說邏輯控制流程的調度和切換其實並不神秘，理論上，我們也可以不依賴作業系統和其提供的線程，在自己程式的程式碼片段裡定義多個片段，然後在我們自己程式裡對其進行調度和切換。

為了描述方便，我們接下來把“程式碼片段”稱為“任務”。

和核心的實作類別似，只是我們不需要考慮中斷和系統調用，那麼，我們的程式本質上就是一個迴圈，這個迴圈本身就是發送器schedule()，我們需要維護一個任務的列表，根據我們定義的策略，先進先出或是有優先順序等等，每次從列表裡挑選出一個任務，然後恢複各個寄存器的值，並且JMP到該任務上次被暫停地方，所有這些需要儲存的資訊都可以作為該任務的屬性，存放在工作清單裡。

看起來很簡單啊，可是我們還需要解決幾個問題：

(1) 我們運行在使用者態，是沒有中斷或系統調用這樣的機制來打斷代碼執行的，那麼，一旦我們的schedule()代碼把控制權交給了任務的代碼，我們下次的調度在什麼時候發生？答案是，不會發生，只有靠任務主動調用schedule()，我們才有機會進行調度，所以，這裡的任務不能像線程一樣依賴核心調度從而毫無顧忌的執行，我們的任務裡一定要顯式的調用schedule()，這就是所謂的協作式(cooperative)調度。(雖然我們可以通過註冊訊號處理函數來類比核心裡的時鐘中斷並取得控制權，可問題在於，訊號處理函數是由核心調用的，在其結束的時候，核心重新獲得控制權，隨後返回使用者態並繼續沿著訊號發生時被中斷的代碼路徑執行，從而我們無法在訊號處理函數內進行任務切換)

(2) 堆棧。和核心調度線程的原理一樣，我們也需要為每個任務單獨分配堆棧，並且把其堆棧資訊儲存在任務屬性裡，在任務切換時也儲存或恢複當前的SS:ESP。任務堆棧的空間可以是在當前線程的堆棧上分配，也可以是在堆上分配，但通常是在堆上分配比較好：幾乎沒有大小或任務總數的限制、堆棧大小可以動態擴充(gcc有split stack，但太複雜了)、便於把任務切換到其他線程。

到這裡，我們大概知道了如何構造一個並發的編程架構，可如何讓任務可以並行的在多個邏輯處理器上執行呢？只有核心才有調度CPU的許可權，所以，我們還是必須通過系統調用建立線程，才可以實現並行。在多執行緒多任務的時候，我們還需要考慮幾個問題：

(1) 如果某個任務發起了一個系統調用，譬如長時間等待IO，那當前線程就被核心放入了等待調度的隊列，豈不是讓其他任務都沒有機會執行？

在單線程的情況下，我們只有一個解決辦法，就是使用非阻塞的IO系統調用，並讓出CPU，然後在schedule()裡統一進行輪詢，有資料時切換回該fd對應的任務；效率略低的做法是不進行統一輪詢，讓各個任務在輪到自己執行時再次用非阻塞方式進行IO，直到有資料可用。

如果我們採用多線程來構造我們整個的程式，那麼我們可以封裝系統調用的介面，當某個任務進入系統調用時，我們就把當前線程留給它(暫時)獨享，並開啟新的線程來處理其他任務。

(2) 任務同步。譬如我們上節提到的生產者和消費者的例子，如何讓消費者在資料還沒有被生產出來的時候進入等待，並且在資料可用時觸發消費者繼續執行呢？

在單線程的情況下，我們可以定義一個結構，其中有變數用於存放互動資料本身，以及資料的當前可用狀態，以及負責讀寫此資料的兩個任務的編號。然後我們的並發編程架構再提供read和write方法供任務調用，在read方法裡，我們迴圈檢查資料是否可用，如果資料還不可用，我們就調用schedule()讓出CPU進入等待；在write方法裡，我們往結構裡寫入資料，更改資料可用狀態，然後返回；在schedule()裡，我們檢查資料可用狀態，如果可用，則啟用需要讀取此資料的任務，該任務繼續迴圈檢測資料是否可用，發現可用，讀取，更改狀態為不可用，返回。代碼的簡單邏輯如下：

struct chan {    bool ready,    int data};int read (struct chan *c) {    while (1) {        if (c->ready) {            c->ready = false;            return c->data;        } else {            schedule();        }    }}void write (struct chan *c, int i) {    while (1) {        if (c->ready) {            schedule();         } else {            c->data = i;            c->ready = true;            schedule(); // optional            return;        }    }}

很顯然，如果是多線程的話，我們需要通過線程庫或系統調用提供的同步機制來保護對這個結構體內資料的訪問。

以上就是最簡化的一個並發架構的設計考慮，在我們實際開發工作中遇到的並發架構可能由於語言和運行庫的不同而有所不同，在功能和易用性上也可能各有取捨，但底層的原理都是殊途同歸。

譬如，glic裡的getcontext/setcontext/swapcontext系列庫函數可以方便的用來儲存和恢複任務執行狀態；Windows提供了Fiber系列的SDK API；這二者都不是系統調用，getcontext和setcontext的man page雖然是在section 2，但那隻是SVR4時的曆史遺留問題，其實現代碼是在glibc而不是kernel；CreateFiber是在kernel32裡提供的，NTDLL裡並沒有對應的NtCreateFiber。

在其他語言裡，我們所謂的“任務”更多時候被稱為“協程”，也就是Coroutine。譬如C++裡最常用的是Boost.Coroutine；Java因為有一層位元組碼解釋，比較麻煩，但也有支援協程的JVM補丁，或是動態修改位元組碼以支援協程的項目；PHP和Python的generator和yield其實已經是協程的支援，在此之上可以封裝出更通用的協程介面和調度；另外還有原生支援協程的Erlang等，筆者不懂，就不說了，具體可參見Wikipedia的頁面：http://en.wikipedia.org/wiki/Coroutine

由於儲存和恢複任務執行狀態需要訪問CPU寄存器，所以相關的運行庫也都會列出所支援的CPU列表。

從作業系統層面提供協程以及其並行調度的，好像只有OS X和iOS的Grand Central Dispatch，其大部分功能也是在運行庫裡實現的。

5. goroutine

Go語言通過goroutine提供了目前為止所有(我所瞭解的)語言裡對於並發編程的最清晰最直接的支援，Go語言的文檔裡對其特性也描述的非常全面甚至超過了，在這裡，基於我們上面的系統知識介紹，列舉一下goroutine的特性，算是小結：

• goroutine是Go語言運行庫的功能，不是作業系統提供的功能，goroutine不是用線程實現的。具體可參見Go語言源碼裡的pkg/runtime/proc.c

• goroutine就是一段代碼，一個函數入口，以及在堆上為其分配的一個堆棧。所以它非常廉價，我們可以很輕鬆的建立上萬個goroutine，但它們並不是被作業系統所調度執行

• 除了被系統調用阻塞的線程外，Go運行庫最多會啟動$GOMAXPROCS個線程來運行goroutine

• goroutine是協作式調度的，如果goroutine會執行很長時間，而且不是通過等待讀取或寫入channel的資料來同步的話，就需要主動調用Gosched()來讓出CPU

• 和所有其他並發架構裡的協程一樣，goroutine裡所謂“無鎖”的優點只在單線程下有效，如果$GOMAXPROCS > 1並且協程間需要通訊，Go運行庫會負責加鎖保護資料，這也是為什麼sieve.go這樣的例子在多CPU多線程時反而更慢的原因

• Web等服務端程式要處理的請求從本質上來講是平行處理的問題，每個請求基本獨立，互不依賴，幾乎沒有資料互動，這不是一個並發編程的模型，而並發編程架構只是解決了其語義表述的複雜性，並不是從根本上提高處理的效率，也許是並發串連和並發編程的英文都是concurrent吧，很容易產生“並發編程架構和coroutine可以高效處理大量並發串連”的誤解。

• Go語言運行庫封裝了非同步IO，所以可以寫出貌似並發數很多的服務端，可即使我們通過調整$GOMAXPROCS來充分利用多核CPU平行處理，其效率也不如我們利用IO事件驅動設計的、按照事務類型劃分好合適比例的線程池。在回應時間上，協作式調度是硬傷。

• goroutine最大的價值是其實現了並發協程和實際並存執行的線程的映射以及動態擴充，隨著其運行庫的不斷髮展和完善，其效能一定會越來越好，尤其是在CPU核心數越來越多的未來，終有一天我們會為了代碼的簡潔和可維護性而放棄那一點點效能的差別。

by http://www.sizeofvoid.net/