Real-World Concurrency閱讀筆記

文章名稱： Real-World Concurrency

連結： http://queue.acm.org/detail.cfm?id=1454462

由于文章是領域内高人多年經驗的總結，有很多地方了解不夠深刻，隻能先寫下自己的了解。

文章首先介紹了并發行的曆史:提高系統并發性的唯一目标就是提高性能。并發性提高性能的三種方式：減少、隐藏延遲；提高吞吐量。

接下來是一系列的建議：

建議1： 辨識系統的熱點和非熱點路徑，并差別對待。 對于非熱點路徑，不要花太多心思提高并發：效果不彰、容易出錯。關于容易出錯這一點，系統的非熱點路徑很多時候是很難實作并發和易出錯的代碼（如啟動、初始化）

建議2： 資料說話，直覺不一定可靠。擷取資料并不容易：搭建軟硬體環境。軟體環境中需要有強大的系統動态性能分析工具。

建議3： 仔細權衡對大鎖的處理。将全局鎖改造成per-cpu lock, lock哈希表，單結構體鎖貌似很酷，但有時通過減短持有大鎖的時間更為明智。

建議4： 讀寫鎖的陷阱。當出現讀多寫少的鎖時，直覺上傾向于改造成讀寫鎖，當鎖持有時間不是很長時間，這樣做是否能改進并發性（擴充性）值得商榷，仔細評估。

建議5： 采用per-cpu鎖。兩個建議：考慮到實作上會增加複雜度，采用per-cpu鎖也需要熱點分析資料的支援；保持以同樣的順序擷取鎖，避免死鎖。

建議6：權衡合适用廣播、何時用signal

建議7：學會事後分析。如利用coredump查找問題。

建議8：将系統設計成元件化（子產品化）的。子產品化和鎖/條件變量是可以共存的，實作的方式有兩種：将鎖/條件變量限制在子系統内部；無鎖化。

建議9：當mutex滿足要求時，不要使用semaphore。

建議10：采用memory retiring來實作per-chain哈希表鎖。當需要并行化對hash表的通路時，可以采用per-chain的鎖。

建議12：避免false sharing。

建議13：采用同步非阻塞函數監控競态條件。

建議14：如非必須，不用waitfree和lockfree技巧。

建議15： 時時保持一顆紅心兩種準備。很難知道目前解決的并發性問題是否是最後一個。

擷取更多幫主請關注小程式