多工環境下任務間通訊模型

這本來是我和朋友之間的一個郵件討論，核心思想是在現在多工模型下，我們程式設計師應該如何看待鎖和佇列，以及如何看待多程式和多執行緒之間通訊的實做方案。

這個呢，在我的演講錄影《明日世界–雲端計算模型下的程式設計需求》中，講了一點，我這裡做個整理，發出來供大家參考。

一家之言哈，歡迎拍磚。

原文如下：

對於多工開發模型下，不同任務之間的通訊，我這麼多年，也摸索出自己的一點套路。

 

程式間通訊，一般建議就用socket方式，TCP、UDP都可以，主要原因，是我把一個功能性程式看做一個服務，既然是服務，就應該保持最大部署靈活性，大量採用共享記憶體區，訊號量等方式同步，勢必造成這些程式必須部署到一臺機器上，就不好做未來的負載均衡了。因此，我建立npi概念，以網路地址定位資訊來標定程式的訪問方式，目的就是為了保持部署靈活性。

即：一個程式被視為伺服器叢集中的一個服務，該服務的被訪問是以網路介面提供標準訪問能力，可以部署在任何一臺伺服器上，只要呼叫者能以合適的方式查詢到該服務的IP地址和埠，即可根據協議，請求服務並獲得結果。

因此，近年來我已經摒棄了Unix和Windows等作業系統建議的所有程式共享方案，同時，也摒棄了COM介面。我認為，未來的雲端計算訪問模型，我這種方式會更加靈活和實用一點。

 

而執行緒間同步，我將其簡化為兩大類同步需求：

1、同步轉非同步，即本來是一個執行緒希望呼叫另外一個執行緒的工作，但不方便立即執行，因為容易崩潰，於是需要同步轉非同步。此時，我建議的模型是“佇列+守候執行緒”方式，這個其實也正是Windows視窗的工作機制。當然，基於資源鎖概念，這個佇列作為被動資源，當然需要做成多執行緒安全的。

2、非同步轉同步，一個資源，被多個執行緒呼叫，比如一個socket，多個收發執行緒需要去呼叫，此時建議用鎖模型，即通過同一把資源鎖，將該socket所有功能方法均予以保護，之後，該socket可以稱之為多執行緒安全socket，以後任意多的執行緒去呼叫，均為安全呼叫。

 

以上算是我抽象了多工開發之後總結的一點對鎖和佇列的看法。

 

嗯，歡迎大家討論和批評哈。

本文轉自 tonyxiaohome

 51CTO部落格，原文連結：http://blog.51cto.com/tonyxiaohome/273759 ，如需轉載請自行聯絡原作者