我的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並發哲學
不要通過共享記憶體進行通訊,通過通訊來共享記憶體。在面對不同場景時,選擇不同的方式。
數據所有權:並發程式安全就是保證同時只有一個並發上下文擁有數據的所有權,通過channel可以把數據傳遞給其他go程,解耦生產者和消費者。
追求簡潔,盡量使用channel,並且認為goroutine的使用是沒有成本的。
參考書籍
-
《Go語言並發之道》Katherine CoxBuday
-
《Go語言核心編程》李文塔
-
《Go語言高級編程》柴樹彬、曹春輝