CSP communicating sequential processes並行模型

前言

https://www.jb51.net/article/228730.htm

請記住下面這句話：

DO NOT COMMUNICATE BY SHARING MEMORY; INSTEAD, SHARE MEMORY BY COMMUNICATING.

“不要以共用記憶體的方式來通訊，相反，要通過通訊來共用記憶體。”

普通的執行緒並行模型，就是像Java、C++、或者Python，他們執行緒間通訊都是通過共用記憶體的方式來進行的。非常典型的方式就是，在存取共用資料（例如陣列、Map、或者某個結構體或物件）的時候，通過鎖來存取，因此，在很多時候，衍生出一種方便操作的資料結構，叫做“執行緒安全的資料結構”。例如Java提供的包”java.util.concurrent”中的資料結構。Go中也實現了傳統的執行緒並行模型。

Go的CSP並行模型，是通過goroutine和channel來實現的。

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

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

生成一個goroutine的方式非常的簡單：Go一下，就生成了。

go f();

通訊機制channel也很方便，傳資料用channel <- data，取資料用<-channel。

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

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

範例如下：

package main
import "fmt"
func main() {
   messages := make(chan string)
   go func() { messages <- "ping" }()
   msg := <-messages
   fmt.Println(msg)
}

注意 main()本身也是執行了一個goroutine。

messages:= make(chan int) 這樣就宣告了一個阻塞式的無緩衝的通道

chan 是關鍵字 代表我要建立一個通道

GO並行模型的實現原理

我們先從執行緒講起，無論語言層面何種並行模型，到了作業系統層面，一定是以執行緒的形態存在的。而作業系統根據資源存取許可權的不同，體系架構可分為使用者空間和核心空間；核心空間主要操作存取CPU資源、I/O資源、記憶體資源等硬體資源，為上層應用程式提供最基本的基礎資源，使用者空間呢就是上層應用程式的固定活動空間，使用者空間不可以直接存取資源，必須通過“系統呼叫”、“庫函數”或“Shell指令碼”來呼叫核心空間提供的資源。

我們現在的計算機語言，可以狹義的認為是一種“軟體”，它們中所謂的“執行緒”，往往是使用者態的執行緒，和作業系統本身核心態的執行緒（簡稱KSE），還是有區別的。

執行緒模型的實現，可以分為以下幾種方式：

使用者級執行緒模型

如圖所示，多個使用者態的執行緒對應著一個核心執行緒，程式執行緒的建立、終止、切換或者同步等執行緒工作必須自身來完成。它可以做快速的上下文切換。缺點是不能有效利用多核CPU。

核心級執行緒模型

這種模型直接呼叫作業系統的核心執行緒，所有執行緒的建立、終止、切換、同步等操作，都由核心來完成。一個使用者態的執行緒對應一個系統執行緒，它可以利用多核機制，但上下文切換需要消耗額外的資源。C++就是這種。

兩級執行緒模型

這種模型是介於使用者級執行緒模型和核心級執行緒模型之間的一種執行緒模型。這種模型的實現非常複雜，和核心級執行緒模型類似，一個程序中可以對應多個核心級執行緒，但是程序中的執行緒不和核心執行緒一一對應；這種執行緒模型會先建立多個核心級執行緒，然後用自身的使用者級執行緒去對應建立的多個核心級執行緒，自身的使用者級執行緒需要本身程式去排程，核心級的執行緒交給作業系統核心去排程。

M個使用者執行緒對應N個系統執行緒，缺點增加了排程器的實現難度。

Go語言的執行緒模型就是一種特殊的兩級執行緒模型（GPM排程模型）。

Go執行緒實現模型MPG

M指的是Machine，一個M直接關聯了一個核心執行緒。由作業系統管理。

P指的是”processor”，代表了M所需的上下文環境，也是處理使用者級程式碼邏輯的處理器。它負責銜接M和G的排程上下文，將等待執行的G與M對接。

G指的是Goroutine，其實本質上也是一種輕量級的執行緒。包括了呼叫棧，重要的排程資訊，例如channel等。

P的數量由環境變數中的GOMAXPROCS決定，通常來說它是和核心數對應，例如在4Core的伺服器上回啟動4個執行緒。G會有很多個，每個P會將Goroutine從一個就緒的佇列中做Pop操作，為了減小鎖的競爭，通常情況下每個P會負責一個佇列。

三者關係如下圖所示：

以上這個圖講的是兩個執行緒(核心執行緒)的情況。一個M會對應一個核心執行緒，一個M也會連線一個上下文P，一個上下文P相當於一個“處理器”，一個上下文連線一個或者多個Goroutine。為了執行goroutine，執行緒必須儲存上下文。

上下文P(Processor)的數量在啟動時設定為GOMAXPROCS環境變數的值或通過執行時函數GOMAXPROCS()。通常情況下，在程式執行期間不會更改。上下文數量固定意味著只有固定數量的執行緒在任何時候執行Go程式碼。我們可以使用它來調整Go程序到個人計算機的呼叫，例如4核PC在4個執行緒上執行Go程式碼。

圖中P正在執行的Goroutine為藍色的；處於待執行狀態的Goroutine為灰色的，灰色的Goroutine形成了一個佇列runqueues。

Go語言裡，啟動一個goroutine很容易：go function 就行，所以每有一個go語句被執行，runqueue佇列就在其末尾加入一個goroutine，一旦上下文執行goroutine直到排程點，它會從其runqueue中彈出goroutine，設定堆疊和指令指標並開始執行goroutine。

拋棄P(Processor)

你可能會想，為什麼一定需要一個上下文，我們能不能直接除去上下文，讓Goroutine的runqueues掛到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中偷一半！

Goroutine 小結

優點：

1、開銷小

POSIX的thread API雖然能夠提供豐富的API，例如設定自己的CPU親和性，申請資源等等，執行緒在得到了很多與程序相同的控制權的同時，開銷也非常的大，在Goroutine中則不需這些額外的開銷，所以一個Golang的程式中可以支援10w級別的Goroutine。

每個 goroutine (協程) 預設佔用記憶體遠比 Java 、C 的執行緒少（goroutine：2KB ，執行緒：8MB）

2、排程效能好

在Golang的程式中，作業系統級別的執行緒排程，通常不會做出合適的排程決策。例如在GC時，記憶體必須要達到一個一致的狀態。在Goroutine機制裡，Golang可以控制Goroutine的排程，從而在一個合適的時間進行GC。

在應用層模擬的執行緒，它避免了上下文切換的額外耗費，兼顧了多執行緒的優點。簡化了高並行程式的複雜度。

缺點：

協程排程機制無法實現公平排程。

以上就是CSP communicating sequential processes並行模型的詳細內容，更多關於CSP並行模型的資料請關注it145.com其它相關文章！