支撐執行緒池的運作主要靠兩個函式：pthread_cond_signal(&m_pthreadcond); 觸發
pthread_cond_wait(&m_pthreadcond, &m_pthreadmutex); 等待
《unix環境高階程式設計》 11章 執行緒，11.6.6: 條件變數：m_pthreadcond:
條件變數，是執行緒可用的另一種同步機制，條件變數給多個執行緒提供了乙個會合的場所，條件變數與互斥量一起使用時，允許執行緒以無競爭的方式等待特定的條件發生；
a)條件本身【while ( (pthreadpoolobj->m_msgrecvqueue.size() == 0) && m_shutdown == false)】 是由互斥量保護的。
執行緒在改變條件狀態之前必須首先鎖住互斥量，其他執行緒在獲取到互斥量之前不會覺察到這種改變，因為互斥量必須在鎖定以後才能計算條件；
c++11，也有條件變數的說法 my_cond.wait(…), my_cond.notify_one(…)
大家如果有興趣可以用c++11多執行緒開發技術實現 自己的跨平台的執行緒池**；
b)傳遞給pthread_cond_wait的互斥量m_pthreadmutex對條件【 while ( (pthreadpoolobj->m_msgrecvqueue.size() == 0) && m_shutdown == false)】進行保護的，
呼叫者把鎖住的互斥量傳遞給函式pthread_cond_wait，函式 然後自動把呼叫執行緒 放在 等待條件的 執行緒列表 上，對互斥量解鎖，
這就關閉了 條件檢查 和 執行緒進入休眠狀態等待條件改變 這兩個操作之間的時間通道，
這樣執行緒就不會錯過條件的任何變化。pthread_cond_wait返回時，互斥量再次被鎖定；
ccrc32類：主要目的是對收發的資料報進行乙個簡單的校驗，以確保資料報中的內容沒有被篡改過；
get_crc()：給你一段buffer，也就是一段記憶體，然後給你這段記憶體長度，該函式計算出乙個數字來(crc32值)返回來；
真正專案中要把csocekt類當成父類使用，具體業務邏輯**應該放在csocket的子類中；
threadrecvprocfunc()收到訊息之後的處理函式；
有很多人善於，樂於：抽象；把乙個乙個小功能封裝成乙個乙個類；往設計模式上套 進行所謂的物件導向程式設計；
最能體現物件導向的 多型【虛函式】；
寫程式：每個人有每個人的喜好；老師最喜歡的就是簡單粗暴有效的程式設計方式，完全不喜歡動不動就封裝乙個類的這種寫法；
a)類太多，別人理解起來就非常困難，另外類太多，對程式效率影響很大；
b)幾十萬，上百萬上**，裡邊很多部件需要靈活調整，經常變動，不穩定的部分，才需要抽象出來，用虛函式，通過設計模式來靈活解決；
不要亂用設計模式，不要亂封裝；
為了能夠根據客戶端傳送過來的訊息** 迅速定位到要執行的函式，我們就把客戶端傳送過來的 訊息**直接當做 乙個陣列的下標來用；
最終認識：咱們的伺服器開發工作【業務邏輯】，主要集中在三個檔案中：ngx_logiccomm.h，ngx_c_slogic.cxx，ngx_c_slogic.h
伺服器開發工作，公司 配備專門客戶端開發人員來開發客戶端工作；
c/s配合工作，配合指定通訊協議；協議的制定一般是 伺服器程式設計師來主導；
(1)確定通訊格式是 包頭+包體，包頭固定多少個位元組，這種規則是伺服器端 來制定並在開發乙個專案之前，要明確的 和客戶端交代好；
要求客戶端給伺服器傳送資料報時嚴格遵循這種格式；
(2)註冊，登入，都屬於具體的業務邏輯 命令；這種命令一般都是由伺服器牽頭來制定；
伺服器開發難度往往比客戶端大很多，責任也重很多；要求也高得多；
講清楚：伺服器端要負責通訊協議的制定工作，以免跟客戶端推諉扯皮
伺服器有能力站在客戶端的角度去制定各種通訊協議；
商量，共同指定協議和資料結構；共同制定協議；
伺服器端有責任把crc32演算法給到客戶端；
業務邏輯處理
功能的實現，都是依靠業務邏輯來完成的，記得看過不能完成業務邏輯的程式設計師都不會成長的，確實是的，最近在完成業務邏輯的時候，程式的業務判斷有很多的，所以開始接觸，設計模式，看到來一些設計模式，看結合專案，確實是可以根據設計模式來改寫的，so，懂得設計模式可以快速的，寫好的 的。關於函式同步和非同步之...
策略型業務邏輯處理選擇
目前常見的分層結構是包括展現層 業務邏輯層 持久層的。那麼在業務邏輯層中，是會有非常多的複雜的業務邏輯判斷的，例如 if a.geta type.a else if a.geta type.higher else 這些if else判斷是有非常多的弊端的 對於新的需求，很難做出變更 隨著更多條件的加...
專案實訓 千尋 核心業務邏輯 業務流程處理
本文將對核心業務流程進行分析，並討論其實現。1.業務流程分析 業務流程其實類似於 的訂單，邏輯上雖然比較容易理解，但是中間涉及多次相互確認，使得整個業務邏輯的處理變得相對麻煩起來。發單者發布需求 接單者承接需求 發單者篩選並確定人選 接單者確認並開始執行任務 接單者完成任務並提交 發單者確認任務完成...