建立 Thread 的成本遠低於 Process 的成本,執行 Context switch 時的效能也有顯著的差異。既然並行程式這麼好,為什麼大學資工系的教授不一開始就教、甚至是到畢業都沒學到呢?很顯然的,當執行緒一多時,如果開發者的頭腦不夠清楚便會產出各式各樣的問題以及臭蟲,本篇文章整理了一些並行程式的眉眉角角,歡迎大家閱讀。
Race condition 用來描述一個系統或者 Process 的輸出依賴於不受控制的事件出現順序或者出現時機。
像是: 有多個 Process 嘗試存取同一個記憶體位置,如果沒有處理好,就有可能發生無法預期的執行結果,這種情況容易發生在錯誤的後端程式、資料庫、檔案系統設計或是其他採用多執行緒設計的程式。
考慮以下程式碼:
上面的範例使用 POSIX Thread 創建 10 個執行緒,其程式目的是希望能夠接連印出 0 - 9 的數字。
實際上,其執行結果與預期行為大有不同!程式執行後,印出的結果會在不同數字間跳動,其原因在查看 pthread_create()
的定義後便能輕鬆找出:
我們可以看到,傳遞到子執行緒的參數必須是 void 指標,也就代表,我們並不是傳遞實體數字給子執行緒,是只交給他參數的記憶體位址而已。
也因為這樣,當作業系統在各執行緒間反覆切換時各個子執行緒就會同時操作同一個記憶體的資料,無法確保執行緒的執行順序,這個情況就是 Race condition ,中文又稱競爭危害。
在 SystemProgramming 的教材中也提供了問題的解法,其解題思維就是避免多個執行緒同時存取相同的記憶體。
首先,先定義一個結構:
定義好後,進行記憶體分配:
做到這一步,就已經為即將創建的 10 個子執行緒保留好位置了,接著我們可以將相關參數傳給 pthread_create()
做執行緒的創建工作:
在介紹 Mutex lock 與 Condition variable 之前,我們要先了解他的應用場景。
Critical sections 代表某程式區段只能在同一時間被一個執行緒處理,如果有多個執行緒同時執行了這段程式碼,可能會有超出預期的錯誤行為出現。
取自 CS:APP Concurrent Programming, Page 40-56 。
考慮以下程式碼:
該程式碼若是在單一執行緒上工作,並不會出現問題。
不過!如果使用 POSIX Thread 創建多個執行緒處理 countgold()
時,由於多個執行緒同時存取同一個記憶體的資料 (在這個範例中為 sum
),便會造成前面提到的競爭危害 (Race condition)。
要避免 Race condition ,我們只需要預防 Critical sections 在多個執行緒同時執行,我們先標示出程式中的 Critical sections :
問題的解決辦法就是: 在存取 sum 變數行為的前面加上一道鎖,任何執行緒訪問他之前都需要將鎖上鎖,等到操作完再由上鎖的執行緒做解鎖。
知道了鎖的需求以及應用面後,我們就可以來認識 Mutex lock 啦!
使用 Mutex lock 前須詳閱公開說明書,互斥鎖有以下特性:
pthread_mutex_t
使用 PTHREAD_MUTEX_INITIALIZER 初始化時,必須確保鎖是全域變數!
掌握 Mutex lock 後,我們將上面的範例稍做修改:
上面的範例會確保執行緒執行完 10000000 次的迴圈才做解鎖,當然,我們也可以換個做法:
這樣的做法同樣能預防競爭危害,不過執行時間會更長。
使用 mutex lock 時,多個執行緒仍然會因為作業系統排程不斷的做 Context switch ,概念有點像是:
不只如此,程式設計者需要確保多個執行緒嘗試上的是同一個鎖!
在上面範例中,執行緒 1 以及 2 都各自上了鎖,兩者同時開心的對 sum 變數執行操作,競爭危害的狀況一樣發生在該程式身上。
Condition variables 通常會跟 Mutex 搭配使用。
解釋:
pthread_cond_wait()
解鎖並進入 waiting queue 。pthread_cond_signal()
更改 Condition variable 的狀態。修改程式碼之前,需要知道 pthread_cond_wait()
被呼叫後會有以下行為:
pthread_cond_signal()
。了解 API 的行為後,考慮以下程式碼:
使用 Condition variables 改寫: