1.如下**所示：
#include #include#include
#include
pthread_mutex_t count_lock;
pthread_cond_t count_ready;
intcount;
void *decrement_count(void *arg)
count = 0
; pthread_mutex_unlock(&count_lock);
}pthread_exit(null);
}void *increment_count(void *arg)
pthread_exit(null);
}int
main()
g++ -g thread-cond.cpp -lpthread -o test 編譯出test程式。
然後執行，可見程式
decrement:waiting
decrement:waiting
decrement:count = 1
decrement:waiting
decrement:count = 0
exit count:0
如果把tid1,tid2,tid3表示為每個執行緒獲得互斥鎖，那麼這種情況的發生說明tid1和tid3順序獲得鎖執行了(順序也可能為tid3和tid1).
單從pthread_cond_signal函式的定義上看，如果嚴格的只發乙個"訊號"給指定乙個執行緒，這種情況是絕對不可能發生的。
因為函式中pthread_cond_wait的返回代表了此執行緒接受到「訊號」（pthread_cond_wait執行包括1.解鎖2.wait3.獲得鎖4.返回）
只有乙個原因能解釋：pthread_cond_signal一次喚醒了2個wait執行緒，第1個獲得鎖的執行緒把count置為0，第2個執行緒發現count=0直接exit，
pthread_cond_signal發生了驚群現象。
while (count == 0)pthread_cond_wait(&count_ready, &count_lock);
在wait返回後加乙個while來判斷「條件」是否滿足要求。
accpet驚群和epoll驚群現象
epoll的驚群現象解決。想一想nginx解決的應該時epoll的驚群問題具體 網上有就不貼出。得到鎖的可以將accpet放進自己的epoll中然後。沒有得到的移出去 在思考這個問題之前，我們應該以前對前面所講幾點有所了解，即先弄清楚問題的背景，並能自己復現出來，而不僅僅只是看書或部落格，然後再來看...
epoll 群驚現象
遇到問題 手頭原來有乙個單程序的linux epoll伺服器程式，近來希望將它改寫成多程序版本，主要原因有 在服務高峰期間 併發的 網路請求非常海量，目前的單程序版本的程式有點吃不消 單程序時只有乙個迴圈先後處理epoll wait 到的事件，使得某些不幸排隊靠後的socket fd的事件處理不及時...
accept驚群研究
一 驚群的定義 驚群是多程序多執行緒程式設計中的乙個常見問題，就是當多個程序和執行緒在同時阻塞等待同乙個事件時，如果這個事件發生，會喚醒所有的程序，但最終只可能有乙個程序 執行緒對該事件進行處理，其他程序 執行緒會在失敗後重新休眠，這種效能浪費就是驚群。二 accept驚群 在使用多程序處理客戶端 ...