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

技術小牛人發表於2017-11-22
這本來是我和朋友之間的一個郵件討論,核心思想是在現在多工模型下,我們程式設計師應該如何看待鎖和佇列,以及如何看待多程式和多執行緒之間通訊的實做方案。
這個呢,在我的演講錄影《明日世界–雲端計算模型下的程式設計需求》中,講了一點,我這裡做個整理,發出來供大家參考。
一家之言哈,歡迎拍磚。
原文如下:
對於多工開發模型下,不同任務之間的通訊,我這麼多年,也摸索出自己的一點套路。

 

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

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

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

 

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

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

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

 

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

 

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

本文轉自 tonyxiaohome

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


相關文章