新的問題
最常見的處理方式：超級類解決一切
我們知道，主線程是不需要建立的，而涉及到ui的開發中，總存在乙個主視窗的視窗類，這個視窗類中包含了所有的ui控制項，同時處理所有使用者操作的視窗訊息。
對於業務執行緒的處理，最常見的是在主視窗類中建立，同時，業務執行緒涉及到的業務邏輯處理類如網路互動、解碼和顯示等也全部放到主視窗類中。
主視窗類在包含了執行緒控制代碼、各種業務邏輯處理類後，終於從乙個ui類蛻變為無所不包的超級類了，因此，我把這種方法稱之為超級類法。
超級類法的優點
說缺點之前，先說優點。超級類的實現方式是程式設計師的第一感，或者說，程式設計師在剛剛開始接觸多執行緒概念時，能把乙個多執行緒的應用程式實現好還是非常不容易的，而超級類實現法的實現相對比較簡單，上手比較容易，這是超級類的最大優點。超級類法的第二個優點是超級類的使用好像很方便，因為超級類就是一切，它可以很容易的訪問到一切它想訪問的東西，這個優點對新手程式設計師也非常重要。總之，初看起來，超級類法似乎具備實現簡單和使用簡單這兩大極具**力的優點。
超級類法的缺點
隨著程式設計師水平的提高，當然，更重要的是隨著程式功能越加越多，超級類法的缺點終於開始逐步暴露了，表現出來的缺點是程式維護越來越困難，bug 似乎層出不窮，並且，從專案管理的角度，這個專案已經沒辦法移交給其他人了，如果要強行移交，新接手的程式設計師也會建議：我還是重做吧，這個程式太亂了，沒辦法維護。往專案加人也不行，新人似乎總融入不了這個專案，績效總是太差，新人自己也做得很沒意思，壓力很大。
超級類法的技術分析
超級類法的困境，我覺得是因為它打破了一些好的規則。
首先是打破了模組化原則，上面的例子，對於超級類而言，應該把它下面的類做一些重構，分成幾個大一些的模組，這樣，程式會更清晰。比如，把幾個業務邏輯類（網路、解碼、顯示）整合成乙個通道cchannel 類，這個類負責所有業務邏輯的處理。事實上，乙個經驗豐富的老鳥程式設計師做到這個是不難的，只要他始終堅持不斷的重構。
其次是容易打破執行緒間訪問保護原則，這是超級類法 bug 層出不窮的最大原因。由於超級類建立了所有執行緒，並且它又可以訪問到所有資料，因此，理論上要避免訪問不同步的問題，必須給所有資料都使用乙個互斥量進行保護。而這樣做確實很麻煩，因此，很多程式設計師的處理方式是經常訪問的資料用互斥量保護，對於那些不經常或者暫時還沒有被多個執行緒訪問的資料則能不保護就不保護了。正是這個原因，導致了程式的維護性極差，因為，第一，這種處理機制本身邏輯上有缺陷，第二，後面維護**的工程師並不知道這個所謂的「經常」的標準。
最後就是打破了命名規則。超級類功能超級強大，可是看到很多超級類的命名，一般還是被稱作主視窗類，這個命名是很不合適的，因為視窗類僅僅屬於ui模組的一部分，是ui模組的乙個子集，如果它還包含所有業務邏輯處理的話，則意味著所有業務邏輯都是ui模組的一部分，這顯然是荒謬的！而超級類不叫視窗類的話，也很難叫別的名字，或者說無論叫什麼名字都不貼切，根據命名原則，如果乙個類無法命名，則代表這個類的設計有問題，程式需要重新設計！
如何避免超級類
避免超級類的方法很簡單，就是在模組化的基礎上，把建立執行緒的工作放到業務邏輯類中去。這種內部包含執行緒的業務邏輯類我稱之為多執行緒業務類，它的實現將在下一節詳細說明。
C 多執行緒開發技巧 2
看個打破保護原則的例子 include include static dword winapi mythread lpvoidlpparam static int num 20 int main int argc,char argv handlehthread 4 inti for i 0 i 4 ...
C 多執行緒開發技巧 3
新的問題 保護原則的正確性已經驗證，但是在實現時，我們發現了兩個新問題。第乙個是剛才的實現中，似乎打破了我們以前說的對稱原則，仔細看 會發現在modify 函式中，mutex lock 被呼叫了一次，而mutex unlock 卻被呼叫了2次。這個問題雖然是個小問題，但是對於完美主義的我而言，卻是個...
c 多執行緒 原始碼5
c thread.join 方法阻塞呼叫執行緒，直到某個執行緒終止時為止 我們可以這麼理解 當newthread呼叫join方法的時候，mainthread就被停止執行，直到newthread執行緒執行完畢 using system using system.collections.generic ...