天天看點

golang源碼剖析-Goroutine與排程器-2

轉自: 原文位址

此文文風優雅, 通俗易懂, 讓人了解起來比較容易, 很是不錯.

goroutine與排程器

我們都知道Go語言是原生支援語言級并發的,這個并發的最小邏輯單元就是goroutine。goroutine就是Go語言提供的一種使用者态線程,當然這種使用者态線程是跑在核心級線程之上的。當我們建立了很多的goroutine,并且它們都是跑在同一個核心線程之上的時候,就需要一個排程器來維護這些goroutine,確定所有的goroutine都使用cpu,并且是盡可能公平的使用cpu資源。

這個排程器的原理以及實作值得我們去深入研究一下。支撐整個排程器的主要有4個重要結構,分别是M、G、P、Sched,前三個定義在runtime.h中,Sched定義在proc.c中。

Sched結構就是排程器,它維護有存儲M和G的隊列以及排程器的一些狀态資訊等。

M代表核心級線程,一個M就是一個線程,goroutine就是跑在M之上的;M是一個很大的結構,裡面維護小對象記憶體cache(mcache)、目前執行的goroutine、随機數發生器等等非常多的資訊。

P全稱是Processor,處理器,它的主要用途就是用來執行goroutine的,是以它也維護了一個goroutine隊列,裡面存儲了所有需要它來執行的goroutine,這個P的角色可能有一點讓人迷惑,一開始容易和M沖突,後面重點聊一下它們的關系。

G就是goroutine實作的核心結構了,G維護了goroutine需要的棧、程式計數器以及它所在的M等資訊。

了解M、P、G三者的關系對了解整個排程器非常重要,我從網絡上找了一個圖來說明其三者關系:

golang源碼剖析-Goroutine與排程器-2

地鼠(gopher)用小車運着一堆待加工的磚。M就可以看作圖中的地鼠,P就是小車,G就是小車裡裝的磚。一圖勝千言啊,弄清楚了它們三者的關系,下面我們就開始重點聊地鼠是如何在搬運磚塊的。

啟動過程

在關心絕大多數程式的内部原理的時候,我們都試圖去弄明白其啟動初始化過程,弄明白這個過程對後續的深入分析至關重要。在asm_amd64.s檔案中的彙編代碼_rt0_amd64就是整個啟動過程,核心過程如下:

CALL    runtime·args(SB)
CALL    runtime·osinit(SB)
CALL    runtime·hashinit(SB)
CALL    runtime·schedinit(SB)

// create a new goroutine to start program
PUSHQ   $runtime·main·f(SB)        // entry
PUSHQ   $         // arg size
CALL    runtime·newproc(SB)
POPQ    AX
POPQ    AX

// start this M
CALL    runtime·mstart(SB)
           

啟動過程做了排程器初始化runtime·schedinit後,調用runtime·newproc建立出第一個goroutine,這個goroutine将執行的函數是runtime·main,這第一個goroutine也就是所謂的主goroutine。我們寫的最簡單的Go程式”hello,world”就是完全跑在這個goroutine裡,當然任何一個Go程式的入口都是從這個goroutine開始的。最後調用的runtime·mstart就是真正的執行上一步建立的主goroutine。

啟動過程中的排程器初始化runtime·schedinit函數主要根據使用者設定的GOMAXPROCS值來建立一批小車(P),不管GOMAXPROCS設定為多大,最多也隻能建立256個小車(P)。這些小車(p)初始建立好後都是閑置狀态,也就是還沒開始使用,是以它們都放置在排程器結構(Sched)的pidle字段維護的連結清單中存儲起來了,以備後續之需。

檢視runtime·main函數可以了解到主goroutine開始執行後,做的第一件事情是建立了一個新的核心線程(地鼠M),不過這個線程是一個特殊線程,它在整個運作期專門負責做特定的事情——系統監控(sysmon)。接下來就是進入Go程式的main函數開始Go程式的執行。

至此,Go程式就被啟動起來開始運作了。一個真正幹活的Go程式,一定建立有不少的goroutine,是以在Go程式開始運作後,就會向排程器添加goroutine,排程器就要負責維護好這些goroutine的正常執行。

建立goroutine(G)

在Go程式中,時常會有類似代碼:

go do_something()
           

go關鍵字就是用來建立一個goroutine的,後面的函數就是這個goroutine需要執行的代碼邏輯。go關鍵字對應到排程器的接口就是runtime·newproc。runtime·newproc幹的事情很簡單,就負責制造一塊磚(G),然後将這塊磚(G)放入目前這個地鼠(M)的小車(P)中。

每個新的goroutine都需要有一個自己的棧,G結構的sched字段維護了棧位址以及程式計數器等資訊,這是最基本的排程資訊,也就是說這個goroutine放棄cpu的時候需要儲存這些資訊,待下次重新獲得cpu的時候,需要将這些資訊裝載到對應的cpu寄存器中。

假設這個時候已經建立了大量的goroutne,就輪到排程器去維護這些goroutine了。

建立核心線程(M)
golang源碼剖析-Goroutine與排程器-2

Go程式中沒有語言級的關鍵字讓你去建立一個核心線程,你隻能建立goroutine,核心線程隻能由runtime根據實際情況去建立。runtime什麼時候建立線程?以地鼠運磚圖來講,磚(G)太多了,地鼠(M)又太少了,實在忙不過來,剛好還有空閑的小車(P)沒有使用,那就從别處再借些地鼠(M)過來直到把小車(p)用完為止。這裡有一個地鼠(M)不夠用,從别處借地鼠(M)的過程,這個過程就是建立一個核心線程(M)。建立M的接口函數是:

void newm(void (*fn)(void), P *p)
           

newm函數的核心行為就是調用clone系統調用建立一個核心線程,每個核心線程的開始執行位置都是runtime·mstart函數。參數p就是一輛空閑的小車(p)。

每個建立好的核心線程都從runtime·mstart函數開始執行了,它們将用配置設定給自己小車去搬磚了。

排程核心

newm接口隻是給新建立的M配置設定了一個空閑的P,也就是相當于告訴借來的地鼠(M)——“接下來的日子,你将使用1号小車搬磚,記住是1号小車;待會自己到停車場拿車。”,地鼠(M)去拿小車(P)這個過程就是acquirep。runtime·mstart在進入schedule之前會給目前M裝配上P,runtime·mstart函數中的代碼:

} else if(m != &runtime·m0) {
    acquirep(m->nextp);
    m->nextp = nil;
}
schedule();
           

if分支的内容就是為目前M裝配上P,nextp就是newm配置設定的空閑小車(P),隻是到這個時候才真正拿到手罷了。沒有P,M是無法執行goroutine的,就像地鼠沒有小車無法運磚一樣的道理。對應acquirep的動作是releasep,把M裝配的P給載掉;活幹完了,地鼠需要休息了,就把小車還到停車場,然後睡覺去。

地鼠(M)拿到屬于自己的小車(P)後,就進入工場開始幹活了,也就是上面的schedule調用。簡化schedule的代碼如下:

static void
schedule(void)
{
    G *gp;

    gp = runqget(m->p);
    if(gp == nil)
        gp = findrunnable();

    if (m->p->runqhead != m->p->runqtail &&
        runtime·atomicload(&runtime·sched.nmspinning) ==  &&
        runtime·atomicload(&runtime·sched.npidle) > )  // TODO: fast atomic
        wakep();

    execute(gp);
}
           

schedule函數被我簡化了太多,主要是我不喜歡貼大段大段的代碼,是以隻保留主幹代碼了。這裡涉及到4大步邏輯:

golang源碼剖析-Goroutine與排程器-2

runqget, 地鼠(M)試圖從自己的小車(P)取出一塊磚(G),當然結果可能失敗,也就是這個地鼠的小車已經空了,沒有磚了。

findrunnable, 如果地鼠自己的小車中沒有磚,那也不能閑着不幹活是吧,是以地鼠就會試圖跑去工場倉庫取一塊磚來處理;工場倉庫也可能沒磚啊,出現這種情況的時候,這個地鼠也沒有偷懶停下幹活,而是悄悄跑出去,随機盯上一個小夥伴(地鼠),然後從它的車裡試圖偷一半磚到自己車裡。如果多次嘗試偷磚都失敗了,那說明實在沒有磚可搬了,這個時候地鼠就會把小車還回停車場,然後睡覺休息了。如果地鼠睡覺了,下面的過程當然都停止了,地鼠睡覺也就是線程sleep了。

wakep, 到這個過程的時候,可憐的地鼠發現自己小車裡有好多磚啊,自己根本處理不過來;再回頭一看停車場居然有閑置的小車,立馬跑到宿舍一看,你妹,居然還有小夥伴在睡覺,直接給屁股一腳,“你妹,居然還在睡覺,老子都快累死了,趕緊起來幹活,分擔點工作。”,小夥伴醒了,拿上自己的小車,乖乖幹活去了。有時候,可憐的地鼠跑到宿舍卻發現沒有在睡覺的小夥伴,于是會很失望,最後隻好向工場老闆說——”停車場還有閑置的車啊,我快幹不動了,趕緊從别的工場借個地鼠來幫忙吧。”,最後工場老闆就搞來一個新的地鼠幹活了。

execute,地鼠拿着磚放入火種歡快的燒練起來。

注: “地鼠偷磚”叫work stealing,一種排程算法。

到這裡,貌似整個工場都正常的運轉起來了,無懈可擊的樣子。不對,還有一個疑點沒解決啊,假設地鼠的車裡有很多磚,它把一塊磚放入火爐中後,何時把它取出來,放入第二塊磚呢?難道要一直把第一塊磚燒練好,才取出來嗎?那估計後面的磚真的是等得花兒都要謝了。這裡就是要真正解決goroutine的排程,上下文切換問題。

排程點 當我們翻看channel的實作代碼可以發現,對channel讀寫操作的時候會觸發調用runtime·park函數。goroutine調用park後,這個goroutine就會被設定位waiting狀态,放棄cpu。被park的goroutine處于waiting狀态,并且這個goroutine不在小車(P)中,如果不對其調用runtime·ready,它是永遠不會再被執行的。除了channel操作外,定時器中,網絡poll等都有可能park goroutine。

除了park可以放棄cpu外,調用runtime·gosched函數也可以讓目前goroutine放棄cpu,但和park完全不同;gosched是将goroutine設定為runnable狀态,然後放入到排程器全局等待隊列(也就是上面提到的工場倉庫,這下就明白為何工場倉庫會有磚塊(G)了吧)。

除此之外,就輪到系統調用了,有些系統調用也會觸發重新排程。Go語言完全是自己封裝的系統調用,是以在封裝系統調用的時候,可以做不少手腳,也就是進入系統調用的時候執行entersyscall,退出後又執行exitsyscall函數。 也隻有封裝了entersyscall的系統調用才有可能觸發重新排程,它将改變小車(P)的狀态為syscall。還記一開始提到的sysmon線程嗎?這個系統監控線程會掃描所有的小車(P),發現一個小車(P)處于了syscall的狀态,就知道這個小車(P)遇到了goroutine在做系統調用,于是系統監控線程就會建立一個新的地鼠(M)去把這個處于syscall的小車給搶過來,開始幹活,這樣這個小車中的所有磚塊(G)就可以繞過之前系統調用的等待了。被搶走小車的地鼠等系統調用傳回後,發現自己的車沒,不能繼續幹活了,于是隻能把執行系統調用的goroutine放回到工場倉庫,自己睡覺去了。

從goroutine的排程點可以看出,排程器還是挺粗暴的,排程粒度有點過大,公平性也沒有想想的那麼好。總之,這個排程器還是比較簡單的。

現場處理 goroutine在cpu上換入換出,不斷上下文切換的時候,必須要保證的事情就是儲存現場和恢複現場,儲存現場就是在goroutine放棄cpu的時候,将相關寄存器的值給儲存到記憶體中;恢複現場就是在goroutine重新獲得cpu的時候,需要從記憶體把之前的寄存器資訊全部放回到相應寄存器中去。

goroutine在主動放棄cpu的時候(park/gosched),都會涉及到調用runtime·mcall函數,此函數也是彙編實作,主要将goroutine的棧位址和程式計數器儲存到G結構的sched字段中,mcall就完成了現場儲存。恢複現場的函數是runtime·gogocall,這個函數主要在execute中調用,就是在執行goroutine前,需要重新裝載相應的寄存器。

人也許總得有一點遺憾才完美