如何理解Go語言基于信號的搶占式調(diào)度

本篇內(nèi)容主要講解“如何理解Go語言基于信號的搶占式調(diào)度”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解Go語言基于信號的搶占式調(diào)度”吧!

識別事故的本質(zhì)，并且用一個非常簡單的示例展示出來，是功力的一種體現(xiàn)。那次事故的原因可以簡化成如下的 demo：

demo-1

我來簡單解釋一下上面這個程序。在主 goroutine 里，先用 GoMAXPROCS 函數(shù)拿到 CPU 的邏輯核心數(shù) threads。這意味著 Go  進程會創(chuàng)建 threads 個數(shù)的 P。接著，啟動了 threads 個數(shù)的 goroutine，每個 goroutine  都在執(zhí)行一個無限循環(huán)，并且這個無限循環(huán)只是簡單地執(zhí)行 x++。

接著，主 goroutine sleep 了 1 秒鐘;最后，打印 x 的值。

你可以自己思考一下，輸出會是什么?

如果你想出了答案，接著再看下面這個 demo：

demo-2

我也來解釋一下，在主 goroutine 里，只啟動了一個 goroutine(雖然程序里用了一個 for 循環(huán)，但其實只循環(huán)了一次，完全是為了和前面的  demo 看起來更協(xié)調(diào)一些)，同樣執(zhí)行了一個 x++ 的無限 for 循環(huán)。

和前一個 demo 的不同點在于，在主 goroutine 里，我們手動執(zhí)行了一次 GC;最后，打印 x 的值。

如果你能答對第一題，大概率也能答對第二題。

下面我就來揭曉答案。

其實我留了一個坑，我沒說用哪個版本的 Go 來運行代碼。所以，正確的答案是：

這個其實就是 Go 調(diào)度器的坑了。

假設(shè)在 demo-1 中，共有 4 個 P，于是創(chuàng)建了 4 個 goroutine。當主 goroutine 執(zhí)行 sleep 的時候，剛剛創(chuàng)建的 4 個  goroutine 馬上就把 4 個 P 霸占了，執(zhí)行死循環(huán)，而且竟然沒有進行函數(shù)調(diào)用，就只有一個簡單的賦值語句。Go 1.13  對這種情況是無能為力的，沒有任何辦法讓這些 goroutine 停下來，進程對外表現(xiàn)出“死機”。

demo-1 示意圖

由于 Go 1.14 實現(xiàn)了基于信號的搶占式調(diào)度，這些執(zhí)行無限循環(huán)的 goroutine 會被調(diào)度器“拿下”，P 就會空出來。所以當主 goroutine  sleep 時間到了之后，馬上就能獲得 P，并得以打印出 x 的值。至于 x 為什么輸出的是  0，不太好解釋，因為這是一種未定義(有數(shù)據(jù)競爭，正常情況下要加鎖)的行為，可能的一個原因是 CPU 的 cache 沒有來得及更新，不過不太好驗證。

理解了這個 demo，第二個 demo 其實是類似的道理：

demo-2 示意圖

當主 goroutine 主動觸發(fā) GC 時，需要把所有當前正在運行的 goroutine 停止下來，即 stw(stop the world)，但是  goroutine 正在執(zhí)行無限循環(huán)，沒法讓它停下來。當然，Go 1.14 還是可以搶占掉這個 goroutine，從而打印出 x 的值，也是 0。

Go 1.14 之前的版本，能否搶占一個正在執(zhí)行死循環(huán)的 goroutine 其實是有講究的：

能否被搶占，不是看有沒有調(diào)用函數(shù)，而是看函數(shù)的序言部分有沒有插入擴棧檢測指令。

如果沒有調(diào)用函數(shù)，肯定不會被搶占。

有些雖然也調(diào)用了函數(shù)，但其實不會插入檢測指令，這個時候也不會被搶占。

像前面的兩個 demo，不可能有機會在函數(shù)擴棧檢測期間主動放棄 CPU  使用權(quán)，從而完成搶占，因為沒有函數(shù)調(diào)用。具體的過程后面有機會再寫一篇文章詳細講，本文主要看基于信號的搶占式調(diào)度如何實現(xiàn)。

preemptone

一方面，Go 進程在啟動的時候，會開啟一個后臺線程 sysmon，監(jiān)控執(zhí)行時間過長的 goroutine，進而發(fā)出搶占。另一方面，GC 執(zhí)行 stw  時，會讓所有的 goroutine 都停止，其實就是搶占。這兩者都會調(diào)用 preemptone() 函數(shù)。

preemptone() 函數(shù)會沿著下面這條路徑：

preemptone->preemptM->signalM->tgkill

向正在運行的 goroutine 所綁定的的那個 M(也可以說是線程)發(fā)出 SIGURG 信號。

注冊 sighandler

每個 M 在初始化的時候都會設(shè)置信號處理函數(shù)：

initsig->setsig->sighandler

信號執(zhí)行過程

我們從“宏觀”層面看一下信號的執(zhí)行過程：

信號執(zhí)行過程

主程序(線程)正在“勤勤懇懇”地執(zhí)行指令：它已經(jīng)執(zhí)行完了指令 m，接著就要執(zhí)行指令 m+1 了……不幸在這個時候發(fā)生了，線程收到了一個信號，對應(yīng)圖中的  ①。

接著，內(nèi)核會接管執(zhí)行流，轉(zhuǎn)而去執(zhí)行預先設(shè)置好的信號處理器程序，對應(yīng)到 Go 里，就是執(zhí)行 sighandler，對應(yīng)圖中的 ② 和 ③。

最后，執(zhí)行流又交到線程手上，繼續(xù)執(zhí)行指令 m+1，對應(yīng)圖中的 ④。

這里其實涉及到了一些現(xiàn)場的保護和恢復，內(nèi)核都幫我們搞定了，我們不用操心。

dosigPreempt

當線程收到 SIGURG 信號的時候，就會去執(zhí)行 sighandler 函數(shù)，核心是 doSigPreempt 函數(shù)。

func sighandler(sig uint32, info *siginfo, ctxt unsafe.Pointer, gp *g) {     ...          if sig == sigPreempt && debug.asyncpreemptoff == 0 {   doSigPreempt(gp, c)  }    ... }

doSigPreempt 這個函數(shù)其實很短，一會兒就執(zhí)行完了。

func doSigPreempt(gp *g, ctxt *sigctxt) {  ...  if ok, newpc := isAsyncSafePoint(gp, ctxt.sigpc(), ctxt.sigsp(), ctxt.siglr()); ok {   // Adjust the PC and inject a call to asyncPreempt.   ctxt.pushCall(funcPC(asyncPreempt), newpc)  }  ... }

isAsyncSafePoint 函數(shù)會返回當前 goroutine 能否被搶占，以及從哪條指令開始搶占，返回的 newpc 表示安全的搶占地址。

接著，pushCall 調(diào)整了一下 SP，設(shè)置了幾個寄存器的值就返回了。按理說，返回之后，就會接著執(zhí)行指令 m+1 了，但那還怎么實現(xiàn)搶占呢?其實魔法都在  pushCall 這個函數(shù)里。

pushCall

在分析這個函數(shù)之前，我們需要先復習一下 Go 函數(shù)的調(diào)用規(guī)約，重點回顧一下 CALL 和 RET 指令就行了。

call 和 ret 指令

call 指令可以簡單地理解為 push ip + JMP。這個 ip 其實就是返回地址，也就是調(diào)用完子函數(shù)接下來該執(zhí)行啥指令的地址。所以 push ip  就是在 call 一個子函數(shù)之前，將返回地址壓入棧中，然后 JMP 到子函數(shù)的地址執(zhí)行。

ret 指令和 call 指令剛好相反，它將返回地址從棧上 pop 到 IP 寄存器，使得 CPU 從這個地址繼續(xù)執(zhí)行。

理解了 call 和 ret，我們再來分析 pushCall 函數(shù)：

func (c *sigctxt) pushCall(targetPC, resumePC uintptr) {  // Make it look like we called target at resumePC.  sp := uintptr(c.rsp())  sp -= sys.PtrSize  *(*uintptr)(unsafe.Pointer(sp)) = resumePC  c.set_rsp(uint64(sp))  c.set_rip(uint64(targetPC)) }

注意看這行注釋：

// Make it look like we called target at resumePC.

它清晰地說明了這個函數(shù)的作用：讓 CPU 誤以為是 resumePC 調(diào)用了 targetPC。而這個 resumePC 就是上一步調(diào)用  isAsyncSafePoint 函數(shù)返回的 newpc，它代表我們搶占 goroutine 的指令地址。

前兩行代碼將 SP 下移了 8 個字節(jié)，并且把 resumePC 入棧(注意，它其實是一個返回地址)，接著把 targetPC 設(shè)置到 ip 寄存器，sp  設(shè)置到 SP 寄存器。這使得從內(nèi)核返回到用戶態(tài)執(zhí)行時，不是從指令 m+1，而是直接從 targetPC 開始執(zhí)行，等到 targetPC 執(zhí)行完，才會返回到  resumePC 繼續(xù)執(zhí)行。整個過程就像是 resumePC 調(diào)用了 targetPC 一樣。而 targetPC 其實就是  funcPC(asyncPreempt)，也就是搶占函數(shù)。

于是我們可以看到，信號處理器程序 sighandler 只是將一個異步搶占函數(shù)給“安插”進來了，而真正的搶占過程則是在 asyncPreempt  函數(shù)中完成。

異步搶占

當執(zhí)行完 sighandler，執(zhí)行流再次回到線程。由于 sighandler 插入了一個 asyncPreempt 的函數(shù)調(diào)用，所以 goroutine  原本的任務(wù)就得不到推進，轉(zhuǎn)而執(zhí)行 asyncPreempt 去了：

asyncPreempt 調(diào)用鏈路

mcall(fn) 的作用是切到 g0 棧去執(zhí)行函數(shù) fn, fn 永不返回。在 mcall(gopreempt_m) 這里，fn 就是  gopreempt_m。

gopreempt_m 直接調(diào)用 goschedImpl：

goschedImpl

dropg

最精彩的部分就在 goschedImpl 函數(shù)。它首先將 goroutine 的狀態(tài)從 running 改成 runnable;接著調(diào) dropg 將 g  和 m 解綁;然后調(diào)用 globrunqput 將 goroutine 丟到全局可運行隊列，由于是全局可運行隊列，所以需要加鎖。最后，調(diào)用 schedule()  函數(shù)進入調(diào)度循環(huán)。關(guān)于調(diào)度循環(huán)，可以看這篇文章。

運行 schedule 函數(shù)用的是 g0 棧，它會去尋找其他可運行的 goroutine，包括從當前 P 本地可運行隊列獲取、從全局可運行隊列獲取、從其他  P 偷等方式找到下一個可運行的 goroutine 并執(zhí)行。

至此，這個線程就轉(zhuǎn)而去執(zhí)行其他的 goroutine，當前的 goroutine 也就被搶占了。

那被搶占的這個 goroutine 什么時候會再次得到執(zhí)行呢?

因為它已經(jīng)被丟到全局可運行隊列了，所以它的優(yōu)先級就會降低，得到調(diào)度的機會也就降低，但總還是有機會再次執(zhí)行的，并且它會從調(diào)用 mcall  的下一條指令接著執(zhí)行。

還記得 mcall 函數(shù)的作用嗎?它會切到 g0 棧執(zhí)行 gopreempt_m，自然它也會保存 goroutine 的執(zhí)行進度，其實就是  SP、BP、PC 寄存器的值，當 goroutine 再次被調(diào)度執(zhí)行時，就會從原來的執(zhí)行流斷點處繼續(xù)執(zhí)行下去。

到此，相信大家對“如何理解Go語言基于信號的搶占式調(diào)度”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！