2直覺(jué)常常是錯(cuò)的，要靠數(shù)據(jù)說(shuō)話。

比如線程。切換到底有多大開(kāi)銷(xiāo)，普通 mutex 加鎖到底有多大代價(jià)，系統(tǒng)調(diào)用的開(kāi)銷(xiāo)如何，gettimeofday() 在 x86-64 Linux 是不是真的系統(tǒng)調(diào)用等等，都要靠數(shù)據(jù)說(shuō)話。

3.  知道什么時(shí)候把一個(gè)鎖拆成多個(gè)，并知道什么時(shí)候不必這樣做。

除了把全局鎖拆成多個(gè)鎖，另外一種常用的避免線程爭(zhēng)用 (contention) 的辦法是減少加鎖的范圍。比方說(shuō)從共享的數(shù)據(jù)結(jié)構(gòu)里移除 (remove and delete) 元素，其實(shí) delete 這一步可以放到鎖外面。

4. 警惕讀寫(xiě)鎖。

初學(xué)者常犯的一個(gè)錯(cuò)誤是，見(jiàn)到某個(gè)數(shù)據(jù)結(jié)構(gòu)頻繁讀而很少寫(xiě)，那么就把 mutex 替換為 rwlock。這不見(jiàn)得是正確的。

這條深得我心，muduo thread lib 目前就沒(méi)有提供讀寫(xiě)鎖的封裝。另外，這一條也能鑒別另一篇關(guān)于線程爭(zhēng)用的文章不靠譜。

5. 考慮用每個(gè) CPU 用一個(gè)鎖。

6. 知道什么時(shí)候用單個(gè)喚醒，什么時(shí)候用廣播喚醒。

notifyAll() 通常表示狀態(tài)變更，而 notify() 通常表示資源變得可用。濫用 notifyAll() 會(huì)導(dǎo)致驚群現(xiàn)象。

 muduo thread lib 的 ThreadPool 區(qū)分使用 notify() 和 notifyAll()，可作參考。

7. 學(xué)會(huì)驗(yàn)尸。

 在程序中只使用 Scoped locking 來(lái)加鎖的話，很容易從 call stack 查出死鎖。參考《多線程服務(wù)器的常用編程模型》第 6 節(jié) 線程間同步。

8. 設(shè)計(jì)系統(tǒng)，使之能擴(kuò)充。

 比方說(shuō)，把對(duì)對(duì)象的修改操作都挪到同一個(gè)線程，這樣就不必加鎖。參考 muduo 的 EventLoop::runInLoop()。

9. 如果 Mutex 就能解決問(wèn)題的話，不要使用信號(hào)量 semaphore。

muduo thread lib 有意識(shí)地不提供信號(hào)量的封裝。

10.考慮用內(nèi)存“退休”法來(lái)實(shí)現(xiàn)哈希表的按桶加鎖。

11. 知道什么是偽共享。

跟多 CPU 的 Cache 有關(guān)，值得了解。

12.  考慮使用非阻塞的加鎖來(lái)觀察線程爭(zhēng)用。

13. 在重新加鎖時(shí)，考慮使用版本號(hào)來(lái)檢測(cè)狀態(tài)變更。

14. 只在別無(wú)它法時(shí)才使用無(wú)鎖數(shù)據(jù)結(jié)構(gòu)。

15. 準(zhǔn)備接受成功的喜悅和失敗的痛苦。

更詳細(xì)的解釋請(qǐng)看原文。

Bryan Cantrill 是 dtrace 的主要作者，Jeff Bonwick 是 ZFS 和 Slab allocator 的發(fā)明者。

hanrui

<ul id="qoqaw"></ul>