在分布式系統中(有多台物理機需要通訊), 執行在多台機器上的多個程序只有一種實用模型:message passing(訊息傳遞), 因為多個物理機基本上不能共享記憶體;
併發(concurrency);
執行緒同步的四項原則, 按重要性排列:
其次, 使用高階的併發程式設計構件, 如任務佇列(taskqueue), 生產者消費者佇列(producer-consumer queue), 閉鎖(countdownlatch)等;
最後不得已才使用底層同步原語(primitives)時, 只用非遞迴的互斥器和條件變數, 慎用讀寫鎖, 不要用訊號量;
除了使用atomic整數之外, 不要自己編寫lock-free**, 也不要用"核心級"同步原語; 不能憑空猜測'那種做法效能會更好', 比如spin lock(自旋鎖) vs mutex(互斥量);
互斥量(mutex)
只用非遞迴的mutex(即不可重入的mutex);
recursive mutex(可重入的互斥量)可能會隱藏**裡的一些問題:
不手工呼叫lock()和unlock()函式, 一切交給棧上的guard物件的構造和析構函式負責;
在每次構造guard物件時, 思考一路上(呼叫棧上)已經持有的鎖, 防止因加鎖順序不同而導致死鎖(deadlock);
不使用跨程序的mutex, 程序間通訊只用tcp sockets;
pthread_atfork()函式講解
gcc支援的無鎖化程式設計
死鎖(dead lock)
條件變數(condition variable)
條件變數只有一種使用方式, 幾乎不可能用錯:
對於signal/broadcast端:
條件變數是非常底層的同步原語, 很少直接使用一般都是用它來實現高層的同步措施, 如blockingqueue或countdownlatch(倒計時器);
互斥量和條件變數構成了多執行緒程式設計的全部必備同步原語, 用它們即可完成任何執行緒同步任務, 二者不能相互代替;
不要用讀寫鎖和訊號量
封裝mutexlock、mutexlockguard、condition類
執行緒安全的singleton實現
在實踐中, 用pthread_once就行(保證函式只執行一次);
用pthread_once_t來保證lazy-initialization的執行緒安全, 執行緒安全由pthread庫保證;
sleep不是同步原語
在程式的正常執行中, 如果需要等待一段已知的時間, 應該向event loop裡註冊乙個timer, 然後在timer的**函式裡接著幹活, 因為執行緒是個珍貴的共享資源, 不能輕易浪費(阻塞也是浪費);
如果等待某個事件發生, 那麼應該採用條件變數或io事件**, 不能用sleep來輪詢;
如果多執行緒的安全性和效率要靠**主動呼叫sleep來保證, 這顯然是設計出了問題;
等待某個事件發生, 正確的做法是用select等價物或condition, 抑或(更理想的)高層同步工具;
在使用者態做輪詢(polling)是低效的;
歸納與總結
unix的signal在多執行緒下的行為比較複雜, 一般要靠底層的網路庫(如reactor)加以遮蔽, 避免干擾上層應用程式的開發;
不能聽信傳言或是憑感覺優化;
真正影響鎖效能的不是鎖, 而是鎖爭用(lock condition);
在分布式系統中, 多機伸縮性(scale out)比單機效能優化更值得投入精力;
借shared_ptr實現copy-on-write
第二章學習筆記
在c 中，陣列下標從0開始，而不是1.c 不支援陣列的抽象，也不支援對整個陣列的操作。在c 中，物件可以靜態分配 即編譯器在處理程式源 時分配，也可以動態分配 即程式執行時，用執行時刻庫函式來分配。靜態與動態記憶體分配的兩個主要區別是 1 靜態物件是有名字的變數，可以直接對你進行操作。而動態物件是沒...
第二章學習筆記
ansi c 有翻譯和執行兩種環境，且不必在一台機器上，例如交叉編譯器 cross compiler 作業系統也是如此 freestanding environment 翻譯 將源 轉換為可執行機器指令 執行 實際執行 翻譯經過以下階段 形成的目標檔案字尾可能在不同系統下不同，如 o obj cc ...
Mudo C 網路庫第五章學習筆記
日誌通常用於故障診斷和追蹤 trace 也可用於效能分析 日誌通常是分布式系統中事故調查時的唯一線索,用來追尋蛛絲馬跡,查出原凶 關於程序,日誌通常要記錄 每條日誌都有時間戳,這樣就能完整追蹤分布式系統中乙個事件的來龍去脈 乙個日誌檔案可分為前端 frontend 和後端 backend 兩部分 對...