在多執行緒中環境中，通常需要輔助線程和主線程通訊，一般輔助線程都是使用者執行緒，用createthread，或者afxbeginthread啟動。（推薦使用後者）
afxbeginthread(proc,null);
其中proc是函式名，其定義為：
uint proc(lpvoid lp)
通訊方式有兩種，一種是用全域性變數，第二種是採取訊息機制，在輔助線程中sendmessage乙個自定義訊息，通知介面執行緒去響應它！
有一段時間，我不理解為什麼要用訊息機制通知，通過afxgetmainwnd()得到主線程的物件指標，然後通過指標呼叫響應函式，不是很方便嗎？
正為自己的發現沾沾自喜，並以為能節省下乙個建立訊息列表而輕鬆許多是，發現自己的專案出了乙個大bug，執行到某個指標判斷時，程式報記憶體讀寫衝突，斷點就在
if（chakandlg!=null）那裡，理論上講，這根本沒執行什麼啊，為何就總是報記憶體出錯呢！
我實在找不到原因，然後就檢視這個語句所屬的函式，有什麼怪異，發現它是供給輔助線程，直接通過物件指標呼叫的，莫非問題出在這？
我總覺得不太可能，不過也只有這種可能了！然後我重新建立乙個訊息響應函式，自定義乙個訊息，通過在輔助線程中sendmessage乙個自定義訊息——！！！！！！！！
不再報記憶體讀寫錯誤了！
我暈，還真是這裡的原因！
想了很久，覺得唯一的解釋，就是介面執行緒要使用這個變數，然後輔助線程通過物件指標，也使用了這個變數，兩者於是有衝突？？？？不要在乙個執行緒中，去讀寫另乙個執行緒中的變數，即使兩個都是在讀？？
也姑且如此解釋了，不過通常情況下，通過物件指標呼叫函式，還是沒什麼問題的，不過最好的方案還是用訊息機制，這樣也不會打亂了介面主線程的步驟，防止出現意外！
執行緒中慎用exit
在程式設計過程中，出現 send connection reset by peer.原因是在資料傳輸過程中，伺服器端程式提前終止。罪魁禍首是乙個exit。如果程序中的任一線程呼叫了exit，exit或者 exit，那麼整個程序就會終止。單個執行緒可以通過下列三種方式退出，在不終止整個程序的情況下停止...
多執行緒中static物件
include class staticinit static staticinit getinstance void testfun static staticinit instance int main 如上面 對於單個執行緒來說，是安全的。但是對於多執行緒就不好說了，主要是涉及到static物...
多執行緒共享物件
鎖不僅僅是關於同步和互斥,也是關於記憶體可見的,為了保證執行緒能看到共享,變數的最新值,讀取和寫入執行緒都必須使用公共的鎖進行同步 volatile變數 它確保對乙個變數的更新和可預見的方式告訴其他執行緒,被宣告的變數在執行時會被監視,它是共享的,所以讀取乙個volatile型別的變數,會返回某個執...