|
1. Know your cold paths from your hot paths. 弄清楚代碼里的熱門執行路徑和冷門執行路徑。
對冷門路徑,用粗粒度的鎖即可。對熱門路徑——也就是那些必須高度并發才能實現所期望的高吞吐量的代碼,應該更加小心,加鎖的策略必須簡單明了且細粒度。
2. Intuition is frequently wrong—be data intensive. 直覺常常是錯的,要靠數據說話。
【陳碩】比如線程切換到底有多大開銷,普通 mutex 加鎖到底有多大代價,系統調用的開銷如何,gettimeofday() 在 x86-64 Linux 是不是真的系統調用等等,都要靠數據說話。
3. Know when—and when not—to break up a lock. 知道什么時候把一個鎖拆成多個,并知道什么時候不必這樣做。
除了把全局鎖拆成多個鎖,另外一種常用的避免線程爭用 (contention) 的辦法是減少加鎖的范圍。比方說從共享的數據結構里移除(remove and delete)元素,其實 delete 這一步可以放到鎖外面。
4. Be wary of readers/writer locks. 警惕讀寫鎖。
初學者常犯的一個錯誤是,見到某個數據結構頻繁讀而很少寫,那么就把 mutex 替換為 rwlock。這不見得是正確的。【陳碩】這條深得我心,muduo thread lib 目前就沒有提供讀寫鎖的封裝。另外,這一條也能鑒別另一篇關于線程爭用的文章不靠譜。
5. Consider per-CPU locking. 考慮用每個 CPU 用一個鎖。
6. Know when to broadcast—and when to signal. 知道什么時候用單個喚醒,什么時候用廣播喚醒。
notifyAll() 通常表示狀態變更,而 notify() 通常表示資源變得可用。濫用 notifyAll() 會導致驚群現象。【陳碩】 muduo thread lib 的 ThreadPool 區分使用 notify() 和 notifyAll(),可作參考。
7. Learn to debug postmortem. 學會驗尸。
【陳碩】 在程序中只使用 Scoped locking 來加鎖的話,很容易從 call stack 查出死鎖。參考《多線程服務器的常用編程模型》第 6 節 線程間同步。
8. Design your systems to be composable. 設計系統,使之能擴充。
【陳碩】 比方說,把對對象的修改操作都挪到同一個線程,這樣就不必加鎖。參考 muduo 的 EventLoop::runInLoop()。
9. Don’t use a semaphore where a mutex would suffice. 如果 Mutex 就能解決問題的話,不要使用信號量 semaphore。
【陳碩】muduo thread lib 有意識地不提供信號量的封裝。
10. Consider memory retiring to implement per-chain hash-table locks. 考慮用內存“退休”法來實現哈希表的按桶加鎖。
11. Be aware of false sharing. 知道什么是偽共享。
跟多 CPU 的 Cache 有關,值得了解。
12. Consider using nonblocking synchronization routines to monitor contention. 考慮使用非阻塞的加鎖來觀察線程爭用。
13. When reacquiring locks, consider using generation counts to detect state change. 在重新加鎖時,考慮使用版本號來檢測狀態變更。
14. Use wait- and lock-free structures only if you absolutely must. 只在別無它法時才使用無鎖數據結構。
15. Prepare for the thrill of victory—and the agony of defeat. 準備接受成功的喜悅和失敗的痛苦。
更詳細的解釋請看原文。Bryan Cantrill 是 dtrace 的主要作者,Jeff Bonwick 是 ZFS 和 Slab allocator 的發明者。
it知識庫:并發編程的 15 條建議(譯),轉載需保留來源!
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。