幾個月一直懶得沒動筆寫寫部落格，最近開始動筆寫點什麼，今天就趁著加班出版本，橫下心決定把上次爛尾的文章給收了（上篇：
接上篇，我們已經通過分析核心**看到pthread_cond_signal和pthread_cond_wait會發生cs（context switch），本篇我將從實際測試資料出發，來看cs究竟會對我們的應用程式產生怎樣的影響。
一般我們可以通過工具vmstat, dstat, pidstat來觀察cs的切換情況。
vmstat, dstat只能觀察整個系統的切換情況，而pidstat可以更精確地觀察某個程序的上下文切換情況。
這裡我用了chaos庫中task_service的乙個測試用例來說明情況（chaos庫是我寫得乙個高效能併發網路庫，而task_service是乙個提供了多執行緒通訊的非同步訊息佇列）
這兩個檔案中，在post非同步訊息給task_service_t時，會根據標頭檔案中定義的巨集在編譯期控制呼叫pthread_cond_signal還是write(fd)，這是典型的生產者消費者模型
注意，通過系統呼叫write來通知task_service_t內部的執行緒會有以下幾種可能：
*) pipe
*) socketpair
*) eventfd
它們都是linux中的多程序/多執行緒通訊的常用手段
我們直接跑一下chaos/test/task_service 下的用例來分別看下不同機制的結果吧
cs/s
post cost
exec cost
pthread_cond_wat/pthread_cond_signal
600k
32,235,597 us
32,235,078 us
sleep
3003,987,928 us
3,996,383 us
pipe
50011,928,024 us
11,928,174 us
socket_pair
4000
16,532,314 us
16,532,461 us
eventfd
2005,136,712 us
5,303,645 us
boost::io_service
750k
26,355,836 us
26,355,708 us
好，讓我們乙個乙個來解讀
首先，使用了pthread的條件變數的chaos::task_service引起的cs非常之大，效率也是最慢，原因其實上篇已經講述，不管是pthread_cond_wait還是pthread_cond_signal，都會發生一次cs。
使用了sleep的chaos::task_service，效率是最高的，主要原因是在於生產者每次投遞時不需要系統呼叫進行notify，且cs也是很小的，但是這種模型在理論上沒有其他 wait/notify的模型要來的好，而且cs和整體的效率還和sleep的引數有關
pipe, socket_pair 和 eventfd 都是基於 write系統呼叫來notify消費者，eventfd是最新核心提供的機制，幾乎感受不到的cs讓其效率也遙遙領先其他的通訊機制
值得注意的是boost::io_service，我這裡的測試系統是linux，windows上的boost::io_service實現沒有測試，但其cs切換如此之高，卻整體效率比chaos::task_service使用pthread 條件變數的模型來得快一些，我想應該是由於其內部的佇列實現，畢竟目前chaos::task_service的佇列只是簡單的lock deque。
基於以上統計，我們可以看出基本是呈現cs越少，整體執行效率越高的趨勢
我們可以得出乙個比較淺顯的結論是，cs起碼會是影響我們程式效能的主要因素之一
當然，任何時候我都覺得測試資料只是眼前的測試資料，它只能告訴我們什麼東西值得我們去注意，而不是什麼東西一定是怎樣的，至少對於後台服務，cs應該是我們常常需要去考量效能的乙個因素
好了，就到這，希望對大家有幫助
ps. 加班寫文章思緒有些亂，前言不搭後語望包含，趕緊撤了～
程序上下文切換 殘酷的效能殺手（下）
幾個月一直懶得沒動筆寫寫部落格，最近開始動筆寫點什麼，今天就趁著加班出版本，橫下心決定把上次爛尾的文章給收了 上篇 接上篇，我們已經通過分析核心 看到pthread cond signal和pthread cond wait會發生cs context switch 本篇我將從實際測試資料出發，來看c...
程序上下文切換 殘酷的效能殺手
對於伺服器的優化，很多人都有自己的經驗和見解，但就我觀察，有兩點常常會被人忽視 上下文切換 和 cache line同步 問題，人們往往都會習慣性地把視線集中在盡力減少記憶體拷貝，減少io次數這樣的問題上，不可否認它們一樣重要，但乙個高效能伺服器需要更細緻地去考察這些問題，這個問題我將分成兩篇文章來...
程序上下文切換 殘酷的效能殺手
對於伺服器的優化，很多人都有自己的經驗和見解，但就我觀察，有兩點常常會被人忽視 上下文切換 和 cache line同步 問題，人們往往都會習慣性地把視線集中在盡力減少記憶體拷貝，減少io次數這樣的問題上，不可否認它們一樣重要，但乙個高效能伺服器需要更細緻地去考察這些問題，這個問題我將分成兩篇文章來...