Go 的搶佔式排程

lsj1342發表於2021-05-13
Go

Go 的搶佔式排程

我正在研究 Go 中 goroutine 的搶佔。如果您能指出文中任何錯誤並告知我，將感激不盡。

Go1.14 版本中的搶佔行為已經發生了變化。在 Go1.14 中，goroutine 是 “非同步搶佔” 的，如發行版本所述。這意味著什麼呢？

首先，讓我們看一個簡單的例子。思考下面的 Go 程式。

package main

import (
    "fmt"
)

func main() {
    go fmt.Println("hi")
    for {
    }
}

在主函式中，啟動了一個只輸出 “hi” 的 goroutine。此外，存在一個無限迴圈 for {}。

如果我們攜帶引數 GOMAXPROCS=1 執行程式時，將發生什麼呢？程式似乎在輸出 “hi” 後，由於無限迴圈而沒有任何反應。實際上，我使用 Go1.14 或更高版本執行該程式時（我使用 Go1.16 上執行了該程式（在 WSL2 上的 Ubuntu ）），它能按照預期工作。

有兩種方法可以阻止此程式執行。一種是使用 1.14 之前的 Go 版本執行它。另一種是執行它時攜帶引數 GODEBUG=asyncpreemptoff=1。

當我在本地計算機上嘗試時，它的工作方式如下。

$ GOMAXPROCS=1 GODEBUG=asyncpreemptoff=1 go run main.go
# it blocks here

程式沒有輸出 “hi” 。在描述為什麼會發生這種情況之前，讓我先說明幾種使該程式按預期方式執行的方法。

一種方法是在迴圈中新增以下程式碼。



*************** package main
*** 2,11 ****
--- 2,13 ----

  import (
      "fmt"
+     "runtime"
  )

  func main() {
      go fmt.Println("hi")
      for {
+         runtime.Gosched()
      }
  }

runtime.Gosched() 類似於 POSIX 的 sched_yield。sched_yield 強制當前執行緒放棄 CPU，以便其他執行緒可以執行。之所以命名為 Gosched，因為 Go 中是 goroutine，而不是執行緒（這是一個猜測）。換句話說，顯式呼叫 runtime.Gosched() 將強制對 goroutines 進行重新安排，並且我們期望將當前執行的 goroutine 切換到另一個。

另一種方法是使用 GOEXPERIMENT=preemptibleloops。它強制 Go 執行時在 “迴圈” 上進行搶佔。這種方式不需要更改程式碼。

協作式排程 vs 搶佔式排程

首先，有兩種主要的多工排程方法：“協作” 和 “搶佔”。協作式多工處理也稱為 “非搶佔”。在協作式多工處理中，程式的切換方式取決於程式本身。“協作” 一詞是指這樣一個事實：程式應設計為可互操作的，並且它們必須彼此 “協作”。在搶佔式多工處理中，程式的切換交給作業系統。排程是基於某種演算法的，例如基於優先順序，FCSV，輪詢等。

那麼現在，goroutine 的排程是協作式還是搶佔式的？至少在 Go1.13 之前，它是協作式的。

我沒有找到任何官方文件，但是我發現在以下情況會進行 goroutine 切換（並不詳盡）。

  • 等待讀取或寫入未緩衝的通道
  • 由於系統呼叫而等待
  • 由於 time.Sleep() 而等待
  • 等待互斥量釋放

此外，Go 會啟動一個執行緒，一直執行著 “sysmon” 函式，該函式實現了搶佔式排程（以及其他諸如使網路處理的等待狀態變為非阻塞狀態）的功能。sysmon 執行在 M（Machine，實際上是一個系統執行緒），且不需要 P（Processor）。術語 M，P 和 G 在類似這樣的各種文章中都有解釋。我建議您在需要時參考此類文章。

當 sysmon 發現 M 已執行同一個 G（Goroutine）10ms 以上時，它會將該 G 的內部引數 preempt 設定為 true。然後，在函式序言中，當 G 進行函式呼叫時，G 會檢查自己的 preempt 標誌，如果它為 true，則它將自己與 M 分離並推入 “全域性佇列”。現在，搶佔就成功完成。順便說一下，全域性佇列是與 “本地佇列” 不同的佇列，本地佇列是儲存 P 具有的 G。全域性佇列有以下幾個作用。

  • 儲存那些超過本地佇列容量（256）的 G
  • 儲存由於各種原因而等待的 G
  • 儲存由搶佔標誌分離的 G

這是 Go1.13 及其之前版本的實現。現在，您將瞭解為什麼上面的無限迴圈程式碼無法按預期工作。for{} 僅僅是一個死迴圈，所以如前所述它不會觸發 goroutine 切換。您可能會想，“sysmon 是否設定了搶佔標誌，因為它已經執行了 10ms 以上？” 然而，如果沒有函式呼叫，即使設定了搶佔標誌，也不會進行該標誌的檢查。如前所述，搶佔標誌的檢查發生在函式序言中，因此不執行任何操作的死迴圈不會發生搶佔。

是的，隨著 Go1.14 中引入 “非協作式搶佔”（非同步搶佔），這種行為已經改變。

“非同步搶佔” 是什麼意思？

讓我們總結到目前為止的要點；Go 具有一種稱為 “sysmon” 的機制，可以監視執行 10ms 以上的 goroutine 並在必要時強制搶佔。但是，由於它的工作方式，在 for{} 的情況下並不會發生搶佔。

Go1.14 引入非協作式搶佔，即搶佔式排程，是一種使用訊號的簡單有效的演算法。

首先，sysmon 仍然會檢測到執行了 10ms 以上的 G（goroutine）。然後，sysmon 向執行 G 的 P 傳送訊號（SIGURG）。Go 的訊號處理程式會呼叫 P 上的一個叫作 gsignal 的 goroutine 來處理該訊號，將其對映到 M 而不是 G，並使其檢查該訊號。gsignal 看到搶佔訊號，停止正在執行的 G。

由於此機制會顯式發出訊號，因此無需呼叫函式，就能將正在執行死迴圈的 goroutine 切換到另一個 goroutine。

通過使用訊號的非同步搶佔機制，上面的程式碼現在就可以按預期工作。GODEBUG=asyncpreemptoff=1 可用於禁用非同步搶佔。

順便說一句，他們選擇使用 SIGURG，是因為 SIGURG 不會干擾現有偵錯程式和其他訊號的使用，並且因為它不在 libc 中使用。(參考)

總結

不執行任何操作的無限迴圈不會將 CPU 傳遞給其他 goroutine，並不意味著 Go1.13 之前的機制是不好的。正如 @davecheney 所說，通常不認為這是一個特殊問題。起初，非同步搶佔不是為了解決無限迴圈問題引出的。

儘管非同步搶佔的引入使排程更具搶佔性，但也有必要在 GC 期間更加謹慎地處理 “不安全點”。在這方面對實現上的考慮也非常有趣。有興趣的讀者可以自己閱讀議題：非協作式 goroutine 搶佔。

參考

更多原創文章乾貨分享，請關注公眾號
  • Go 的搶佔式排程
  • 加微信實戰群請加微信(註明:實戰群)：gocnio

相關文章