我的Go並發之旅、01 並發哲學與並發原語

註:本文所有函數名為中文名,並不符合代碼規範,僅供讀者理解參考。

上下文

上下文(Context)代表了程序(也可以是進程,操作系統,機器)運行時的環境和狀態,聯繫程序整個生命周期與資源調用,是程序可以訪問到的所有資源的總和,資源可以是一個變量,也可以是一個對象的引用。

上下文切換

所謂的上下文切換(context switch),指的是發生進程調度(進程切換)時,內核(kernel)要把當前進程的狀態和數據保存起來以備以後使用,同時把之前保存的進程的相關狀態調出來,這樣新調度出來的進程才能運行。

原語

原語,一般是指由若干條指令組成的程序段,用來實現某個特定功能,在執行過程中不可被中斷。

計算機是一門人造科學,因此真正意義上的「原語」(Primitive)是不存在的。操作系統層面上的「原語」(比如 write 之類的系統調用)對程序員來講的確是不可分割的最小單位,但是這些系統調用本身還是用好幾句彙編語句組成的(對於 Linux 來說是 C 語言)。可能有人要說到了機器代碼這一級就不能再分了,但事實上一條機器指令也是由好幾個組合邏輯信號構成的。同樣的道理,控制信號也不過是無數電子在器件內部漂移的結果。

因此定義「原語」的前提是觀察者所處的位置上下文)。一旦規定了觀察者的位置和觀察的角度,比如就在操作系統的這層上,read,write,wait這些個系統調用自然就是最「原始」的詞彙,這也是為什麼「原語」會在操作系統中頻繁出現的緣故。

上下文也可以被定義為一個操作被認為是原子性的界限。

競爭條件

兩個或多個操作必須按正確的順序執行,而程序並未保證這個順序,就會發生競爭條件。

大多數情況下,競爭條件會出現在數據競爭中,一個並發操作嘗試讀取一個變量,而在某個不確定的時間,另一個並發操作視圖寫入同一個變量。因為開發人員總是用順序性的思維來思考問題,他們總假設某行代碼會先於另一行代碼執行。

func 競爭條件() {
	var data int
	go func() {
		data++
	}()
	if data == 0 {
		fmt.Println("Value", data)
	}
}

在這段代碼中會出現三種可能性,可以根據 go程(goroutine)、if判斷、打印輸出執行的順序判斷。

  • if、打印、go程 => Value 0
  • if、go程、打印 => Value 1
  • go程、if => 跳過打印,無輸出

僅僅幾行代碼就給程序帶來了巨大的不確定性。

有時,某些程序員會寫出一種看似解決了問題的「方案」,就是添加 time.Sleep,但是這種方案並不可靠!通過顯式休眠的方式只是在概率上增加了邏輯的正確性,但不會真正變成邏輯上的正確。休眠時間也會影響程序的運行效果!

原子性

某些東西被認為是原子的,或者具有原子性的時候,這意味着在它運行的環境中,它是不可分割或不可中斷的。在你所定義的上下文中,原子的東西將被完整的運行,在這種情況下不會同時發生任何事情。

在考慮原子性時,經常第一件需要做的事就是定義上下文或範圍,然後再考慮這些操作是否是原子性的。

當一個東西是原子的,說明它在並發環境中是安全的。而大多數語句不是原子的,更不用說函數、方法和程序了,所以為了構建邏輯正確的程序,需要我們做內存訪問同步,使用一系列操作來強制保持原子性。

內存訪問同步

臨界區:程序中需要獨佔訪問共享資源的部分。(可以理解成讀寫共享資源的代碼段)

正如前面的例子,保護程序臨界區的一個方法是在臨界區之間內存訪問做同步。具體做法是添加一個互斥鎖。

func 競爭條件_互斥鎖() {
	var lock sync.Mutex
	var data int
	go func() {
		lock.Lock()
		data++
		lock.Unlock()
	}()
	lock.Lock()
	if data == 0 {
		fmt.Println("Value", data)
	} else {
		fmt.Println("Value", data)
	}
	lock.Unlock()
}

如果你發現你的代碼中有臨界區,那就添加互斥鎖,保證各個臨界區對共享資源(data)的獨佔訪問權,從而對內存的訪問進行了同步。但這僅僅解決了數據競爭,沒有解決競爭條件 !這種方式同步對內存的訪問有性能上的問題。

死鎖

所有並發進程彼此等待。

活鎖

正在主動執行並發操作的程序,但無法向前推進程序狀態。

飢餓

在任何情況下,並發進程都無法獲得執行工作所需的所有資源

通常意味着有一個或多個貪婪的並發進程,不公平地阻止(貪婪地搶佔鎖,以完成整個工作循環(通常是不必要地擴大其持有共享鎖上的臨界區))一個或多個並發進程以儘可能有效地完成工作。

飢餓也可能產生於 CPU、內存、文件句柄、數據庫連接,任何必須共享的資源都是有可能產生飢餓的原因。

找到同步訪問內存的平衡點

同步訪問內存代價是昂貴的,所以將鎖擴展到臨界區外是有利的,但是會產生前面的飢餓問題。

需要在粗粒度和細粒度同步之間找到一個平衡點。

一般經驗是將內存訪問同步限制在關鍵部分,不擴展到臨界區外;直到同步成為性能問題,再擴展範圍。

給並發函數注釋

  • 誰負責並發,是調用者負責,還是函數自己負責。
  • 如何利用並發原語解決這個問題的。比如遞歸調用。
  • 誰負責同步,調用者負責內存訪問同步還是結構體內部處理。

函數可以採用純函數式方法,儘可能消除同步的問題。

函數最好返回一個只讀的channel,而不是傳入參數的指針,這樣更具有明確性。

並發與並行

並發屬於代碼,並行屬於一個運行中的程序的屬性。

並行的”同時”是同一時刻可以多個進程在運行(處於running),並發的”同時”是經過上下文快速切換,使得看上去多個進程同時都在運行的現象,是一種OS欺騙用戶的現象

實際上,當程序中寫下多進程或多線程代碼時,這意味着的是並發而不是並行。並發是因為多進程/多線程都是需要去完成的任務,不並行是因為並行與否由操作系統的調度器決定,可能會讓多個進程/線程被調度到同一個CPU核心上。只不過調度算法會盡量讓不同進程/線程使用不同的CPU核心,所以在實際使用中幾乎總是會並行,但卻不能以100%的角度去保證會並行。也就是說,並行與否程序員無法控制,只能讓操作系統決定

CSP

通信順序進程。一個進程的輸出應該直接流向另一個進程的輸入。

Go魅力

一般編程語言會把它們的抽象鏈結束在系統線程和內存訪問同步的層級

但是Go語言採取了不同的路線,使用goroutine和channel代替這些概念。goroutine把我們從必須按照並行的思考方式中解放出來,作為替代,他允許我們按照更為自然的等級對問題進行建模。Go語言的運行時自動地將goroutine映射到系統的線程上,並為我們管理它們之間的調度(智能分配OS線程)。

Go並發哲學

不要通過共享內存進行通信,通過通信來共享內存。在面對不同場景時,選擇不同的方式。

image-20220918010635068

數據所有權:並發程序安全就是保證同時只有一個並發上下文擁有數據的所有權,通過channel可以把數據傳遞給其他go程,解耦生產者和消費者。

追求簡潔,盡量使用channel,並且認為goroutine的使用是沒有成本的。

參考書籍

  • 《Go語言並發之道》Katherine CoxBuday

  • 《Go語言核心編程》李文塔

  • 《Go語言高級編程》柴樹彬、曹春輝

Tags: