再論-多線程間的通訊.

多線程編程需面臨的問題總結：

1）安全的資料共用（通訊）問題。

   同時一方寫，一方讀
   同時一個寫，多個讀
 
   。。。

為了保證資料能安全的共用，引出了線程間同步的問題。比如，我寫的時候，你不能讀之類的。
這就不可避免的用到了鎖。而一旦引入鎖，編程就變得複雜了起來。
所以，先人們想了很多種方法來避免使用鎖而實現資料通訊。
比如：對於一個寫，一方讀的問題，引入了環形緩衝區隊列（xEyeList）實現；

本質上，環形緩衝區隊列是通過把資料往緩衝區裡備份了一份來實現。同樣，我們也可以通過發送訊息的方式來實現線程間資料的通訊。事實上，有人直接利用windows內建的訊息通訊機制解決了複雜的線程間的資料通訊。
當然，我自己也實現了一個xEyeMsgQueue實作類別似的功能。

若利用鎖的方式，那麼《windows核心編程》裡面有個經典的例子，通過訊號量，實現了 “同時一個寫，多個讀”

2）線程固有的同步需求

由於把一項任務拆分到幾個線程裡面去做，就算沒有資料通訊，也面臨著線程之間同步的問題。比如只有A做了某件事後，B才能接著往下走。
不過，這裡的A做完某件事通知B這個過程本身，本質上也屬於線程間資料通訊的問題。

如果通過訊息的方式通知，那麼B在得到A的訊息通知之前，B還可以做一些別的事情。注意：這個時候，B的訊息佇列是仍然要運轉的，不然他怎麼知道收到了A的訊息？通常這是一種更進階的同步方式，當收到A的通知後，B才去做原本的A做完B才能做的事。如果既沒有別的事做，也沒有收到A的通知，那麼只好Sleep()，因為，空轉著就浪費了CPU。
這種方式實現的同步，我稱之為不會陷入睡眠的同步（通過訊息的同步），或進階的同步。

如果通過核心對象的方式通知，那麼B在得到A的訊息通知之前，B可以直接陷入被OS睡眠。當A完成事之後，設定核心變數狀態為已通知，則OS會自動喚醒線程B。

通過這種方式實現的同步，我稱之為陷入睡眠的同步，或低級的同步

（注意，在等待核心變數時，可以設定逾時，如果一段時間內還沒有收到A的通知，B也可以做別的事，等過一段時間再來檢查該核心變數，查看是否A做完該做的事。通過這種方式，也可以實現進階的同步，只是複雜了點）

3）線程的開銷需求限制
開啟一個線程，結束一個線程，多個線程間的切換，都是消耗OS較多的CPU資源的，所以，如何降低大量的開闢/關閉線程的需求？

線程池[2]的引入：線程池的核心是 Task + Thread pool[1], 通過把任務抽象為Task，原本一個Task需要開一個線程來著，現在在一個線程裡面死迴圈，不斷的執行線程的Task隊列裡的Task。當有執行Task的需求時，把Task構造好塞入某個線程的Task隊列裡即可。（塞得時候注意線程同步問題）

注意，線程池，僅僅是為了減低頻繁的建立、消耗線程的開銷，充分利用以後的線程引入的技術，所以，池中的線程會不可避免的會遇到所有多線程都必須面臨的安全資料訪問、線程同步的問題。切記！

 

有意思的是：
1）
線程池裡用的Task模型，和我的訊息模型很原理上基本一樣。應該說，是Task隊列是訊息佇列的進一步的發展。因為每一個Task除了可以攜帶參數外，也可以攜帶待執行的任務的代碼！
2）Task用到了 Command設計模式。任務的實現者，和任務的執行環境分離！

想起了 姚建輝老大的Task模型。呵呵就是這個理啊，我們來實現渲染的任務，然後塞到一個全域Task隊列裡，怎麼執行就不用管了，有人負責給你執行 呵呵。

 

[1]Chrome源碼剖析 【序】 && 【一】
http://www.cnblogs.com/duguguiyu/archive/2008/10/02/1303095.html
[2]線程池的介紹及簡單實現
http://www.ibm.com/developerworks/cn/java/l-threadPool/