Go語言CSP並發模型實現MPG

Golang調度機制

最近抽空研究、整理瞭一下Golang調度機制,學習瞭其他大牛的文章。把自己的理解寫下來。如有錯誤,請指正!!!

golang的goroutine機制有點像線程池:

一、go 內部有三個對象: P對象(processor) 代表上下文(或者可以認為是cpu),M(work thread)代表工作線程,G對象(goroutine).

二、正常情況下一個cpu對象啟一個工作線程對象,線程去檢查並執行goroutine對象。碰到goroutine對象阻塞的時候,會啟動一個新的工作線程,以充分利用cpu資源。所有有時候線程對象會比處理器對象多很多

我們用如下圖分別表示P、M、G

在單核情況下,所有goroutine運行在同一個線程(M0)中,每一個線程維護一個上下文(P),任何時刻,一個上下文中隻有一個goroutine,其他goroutine在runqueue中等待。一個goroutine運行完自己的時間片後,讓出上下文,自己回到runqueue中(如下圖左邊所示)。

當正在運行的G0阻塞的時候(可以需要IO),會再創建一個線程(M1),P轉到新的線程中去運行。

當M0返回時,它會嘗試從其他線程中“偷”一個上下文過來,如果沒有偷到,會把goroutine放到global runqueue中去,然後把自己放入線程緩存中。上下文會定時檢查global runqueue。

Go語言是為並發而生的語言,Go語言是為數不多的在語言層面實現並發的語言;也正是Go語言的並發特性,吸引瞭全球無數的開發者。

並發(concurrency)和並行(parallellism)

並發(concurrency):兩個或兩個以上的任務在一段時間內被執行。我們不必care這些任務在某一個時間點是否是同時執行,可能同時執行,也可能不是,我們隻關心在一段時間內,哪怕是很短的時間(一秒或者兩秒)是否執行解決瞭兩個或兩個以上任務。

並行(parallellism):兩個或兩個以上的任務在同一時刻被同時執行。

並發說的是邏輯上的概念,而並行,強調的是物理運行狀態。並發“包含”並行。

Go的CSP並發模型

Go實現瞭兩種並發形式。第一種是大傢普遍認知的:多線程共享內存。其實就是Java或者C++等語言中的多線程開發。另外一種是Go語言特有的,也是Go語言推薦的:CSP(communicating sequential processes)並發模型。

CSP並發模型是在1970年左右提出的概念,屬於比較新的概念,不同於傳統的多線程通過共享內存來通信,CSP講究的是“以通信的方式來共享內存”。

請記住下面這句話:

Do not communicate by sharing memory; instead, share memory by communicating.

“不要以共享內存的方式來通信,相反,要通過通信來共享內存。”

普通的線程並發模型,就是像Java、C++、或者Python,他們線程間通信都是通過共享內存的方式來進行的。非常典型的方式就是,在訪問共享數據(例如數組、Map、或者某個結構體或對象)的時候,通過鎖來訪問,因此,在很多時候,衍生出一種方便操作的數據結構,叫做“線程安全的數據結構”。例如Java提供的包”java.util.concurrent”中的數據結構。Go中也實現瞭傳統的線程並發模型。

Go的CSP並發模型,是通過goroutinechannel來實現的。

goroutine是Go語言中並發的執行單位。有點抽象,其實就是和傳統概念上的”線程“類似,可以理解為”線程“。

channel是Go語言中各個並發結構體(goroutine)之前的通信機制。 通俗的講,就是各個goroutine之間通信的”管道“,有點類似於Linux中的管道。

生成一個goroutine的方式非常的簡單:Go一下,就生成瞭。

go f();

通信機制channel也很方便,傳數據用channel <- data,取數據用<-channel

在通信過程中,傳數據channel <- data和取數據<-channel必然會成對出現,因為這邊傳,那邊取,兩個goroutine之間才會實現通信。

而且不管傳還是取,必阻塞,直到另外的goroutine傳或者取為止。

有兩個goroutine,其中一個發起瞭向channel中發起瞭傳值操作。(goroutine為矩形,channel為箭頭)

左邊的goroutine開始阻塞,等待有人接收。

這時候,右邊的goroutine發起瞭接收操作。

右邊的goroutine也開始阻塞,等待別人傳送。

這時候,兩邊goroutine都發現瞭對方,於是兩個goroutine開始一傳,一收。

這便是Golang CSP並發模型最基本的形式。

Go並發模型的實現原理

我們先從線程講起,無論語言層面何種並發模型,到瞭操作系統層面,一定是以線程的形態存在的。而操作系統根據資源訪問權限的不同,體系架構可分為用戶空間和內核空間;內核空間主要操作訪問CPU資源、I/O資源、內存資源等硬件資源,為上層應用程序提供最基本的基礎資源,用戶空間呢就是上層應用程序的固定活動空間,用戶空間不可以直接訪問資源,必須通過“系統調用”、“庫函數”或“Shell腳本”來調用內核空間提供的資源。

我們現在的計算機語言,可以狹義的認為是一種“軟件”,它們中所謂的“線程”,往往是用戶態的線程,和操作系統本身內核態的線程(簡稱KSE),還是有區別的。

線程模型的實現,可以分為以下幾種方式:

用戶級線程模型

如圖所示,多個用戶態的線程對應著一個內核線程,程序線程的創建、終止、切換或者同步等線程工作必須自身來完成。

內核級線程模型

這種模型直接調用操作系統的內核線程,所有線程的創建、終止、切換、同步等操作,都由內核來完成。C++就是這種。

兩級線程模型

這種模型是介於用戶級線程模型和內核級線程模型之間的一種線程模型。這種模型的實現非常復雜,和內核級線程模型類似,一個進程中可以對應多個內核級線程,但是進程中的線程不和內核線程一一對應;這種線程模型會先創建多個內核級線程,然後用自身的用戶級線程去對應創建的多個內核級線程,自身的用戶級線程需要本身程序去調度,內核級的線程交給操作系統內核去調度。

Go語言的線程模型就是一種特殊的兩級線程模型。暫且叫它“MPG”模型吧。

Go線程實現模型MPG

M指的是Machine,一個M直接關聯瞭一個內核線程。P指的是”processor”,代表瞭M所需的上下文環境,也是處理用戶級代碼邏輯的處理器。G指的是Goroutine,其實本質上也是一種輕量級的線程。

三者關系如下圖所示:

以上這個圖講的是兩個線程(內核線程)的情況。一個M會對應一個內核線程,一個M也會連接一個上下文P,一個上下文P相當於一個“處理器”,一個上下文連接一個或者多個Goroutine。P(Processor)的數量是在啟動時被設置為環境變量GOMAXPROCS的值,或者通過運行時調用函數runtime.GOMAXPROCS()進行設置。Processor數量固定意味著任意時刻隻有固定數量的線程在運行go代碼。Goroutine中就是我們要執行並發的代碼。圖中P正在執行的Goroutine為藍色的;處於待執行狀態的Goroutine為灰色的,灰色的Goroutine形成瞭一個隊列runqueues

三者關系的宏觀的圖為:

拋棄P(Processor)

你可能會想,為什麼一定需要一個上下文,我們能不能直接除去上下文,讓Goroutinerunqueues掛到M上呢?答案是不行,需要上下文的目的,是讓我們可以直接放開其他線程,當遇到內核線程阻塞的時候。

一個很簡單的例子就是系統調用sysall,一個線程肯定不能同時執行代碼和系統調用被阻塞,這個時候,此線程M需要放棄當前的上下文環境P,以便可以讓其他的Goroutine被調度執行。

如上圖左圖所示,M0中的G0執行瞭syscall,然後就創建瞭一個M1(也有可能本身就存在,沒創建),(轉向右圖)然後M0丟棄瞭P,等待syscall的返回值,M1接受瞭P,將·繼續執行Goroutine隊列中的其他Goroutine

當系統調用syscall結束後,M0會“偷”一個上下文,如果不成功,M0就把它的Gouroutine G0放到一個全局的runqueue中,然後自己放到線程池或者轉入休眠狀態。全局runqueue是各個P在運行完自己的本地的Goroutine runqueue後用來拉取新goroutine的地方。P也會周期性的檢查這個全局runqueue上的goroutine,否則,全局runqueue上的goroutines可能得不到執行而餓死。

均衡的分配工作

按照以上的說法,上下文P會定期的檢查全局的goroutine 隊列中的goroutine,以便自己在消費掉自身Goroutine隊列的時候有事可做。假如全局goroutine隊列中的goroutine也沒瞭呢?就從其他運行的中的P的runqueue裡偷。

每個P中的Goroutine不同導致他們運行的效率和時間也不同,在一個有很多P和M的環境中,不能讓一個P跑完自身的Goroutine就沒事可做瞭,因為或許其他的P有很長的goroutine隊列要跑,得需要均衡。該如何解決呢?

Go的做法倒也直接,從其他P中偷一半!

參考文獻:

The Go scheduler

《Go並發編程第一版》

以上就是Go語言CSP並發模型實現MPG的詳細內容,更多關於Go CSP並發模型MPG的資料請關註WalkonNet其它相關文章!

推薦閱讀: