簡介 越來越多的高性能套用需要通過高速網路實現互連以充分利用計算資源。這些套用在進行計算的同時,需要解決相互通信時的數據異構問題。這種異構環境會使套用在格線計算上的通信方法數激增。例如,不同的通信設施使用不同的網路接口、低層協定以及數據編碼方法,它們甚至有不同的服務質量需求。
Nexus通信庫通過支持多方法通信來解決這些問題。儘管P4和PVM通信庫也能在異構環境下使用不同的低層協定,但這些通信方法不可擴展,也不支持通信方法的動態發現或動態配置;而Nexus充分考慮了網路資源的異構性和套用的多樣性,支持自動配置機制,它允許使用資源資料庫中的信息,決定在不同情況下使用哪個啟動機制、網路接口與協定,支持多種底層通信協定,如
RPC 、
RSH 、
MPI 、P4、
PVM 和
MPL 等,並提供通信方法的動態發現與配置功能,從而極大地提高了通信的可靠性。
實現原理 Nexus系統按照如下五個基本概念來構建:節點(Node)、上下文(Context)、執行緒(Thread)通信起點和終點(Communication Start Point and End Point,SP&EP),以及RSR。一個套用的計算在一組節點上執行,由一組執行緒組成,每個執行緒都在一個稱為上下文的地址空間內運行。一個執行緒可以執行順序程式,這個程式可以讀寫在同一個上下文中執行的、與其他執行緒共享的數據。
節點 Nexus的最基本抽象就是節點。一個節點代表著一個實際的物理資源,因此,一個程式所分配的節點集合決定了該計算的全部有效處理能力。這裡,節點與機器名、處理機號是有區別的,它指的是一個實際的
處理機 ,或者是一個共享記憶體的多處理機,或者是多計算機中的某個計算機。
當一個程式開始運行時,首先建立一個初始的節點集合,在運行過程中,節點可以動態地添加或刪除。實際上,程式並不能夠在節點上直接執行,而是在映射到每個節點的上下文中運行。Nexus提供了一整套構建節點的方法,這些方法一般用於共享記憶體的多處理機,或者用於分散式記憶體的多計算機中。一個節點僅對應一個資源,而非特指某個通信協定或者是通信介質。這種命名策略一般並不能獨立的實現,但是,一旦命名策略的實現方式是獨立的,節點就可以被操作。
上下文 計算在稱為上下文的地址空間上執行。上下文是靠節點定位的。一個節點可以分配多個上下文,但上下文一旦產生,則不能把一個節點的上下文變成另一個節點的上下文。上下文可以動態生成或刪除。由於上下文並不像
UNIX 下的進程一樣提供保護機制,相比之下,代價會比後者少得多。一個上下文地址空間可以包括零個或多個數據段。這些數據段在上下文存在時可以被分配或者釋放,也可以在上下文被刪除時自動釋放。一個數據段是上下文的一部分,當生成上下文時,執行NexusBoot()例程(它用於初始化上下文,保證初始化完畢之前不能引用上下文),之後,直到對上下文進行遠程服務請求並同時生成新執行緒時,上下文才會被激活;而刪除上下文時,則執行NexusExit()例程。
Nexus中把上下文的生成與執行分開的策略是為滿足任務的並發性,上下文中所有的執行緒是等同的,而所有的計算也是同步執行的。
執行緒 在Nexus系統中,所謂執行緒,實際上是指對執行緒的控制。執行緒靠上下文定位,一個上下文可以分配多個執行緒,而計算可以在一個或多個執行緒中進行,因此,計算要靠上下文中的執行緒以及節點中的上下文去定位。同一上下文中的執行緒共享一個地址空間,並通過使用Nexus信號量和環境參數可以進行並發操作。但是,執行緒並不能去訪問別的上下文的地址空間。一個上下文能生成的執行緒數量受可利用的資源限制。執行緒的操作包括執行緒的生成和執行緒的終止等。
通信起點和終點 通信終點標明了上下文中可以請求遠程服務的位置,一個終點可以對應多個起點。起點可以在上下文間傳遞,這樣就可以提供全局的名字空間,而不是提供全局的共享記憶體,即允許在上下文中的任何地址上都產生全局名字,也可以請求與之對應的終點所標明了的遠程服務。
從通信起點到終點的GP用於連線在不同的上下文中所發生的遠程服務請求。每個GP有一個通信終點EP。也就是說,GP確定了一個目標,通信操作可以通過RSR指向這個目標。GP可以動態創建,一旦被創建,GP可以通過將自己包含在一個RSR中,在節點間相互通信。GP與其所指向的地址空間(上下文)的存儲器位置相關。這種與終點地址的相關性對於終點概念的實現並不是至關重要的。然而以這種相關性為前提的全局地址空間配合了不規則套用的需要,不規則套用很可能利用多執行緒。
遠程服務請求 上下文空間中執行緒可以通過調用遠程服務請求來訪問遠程上下文,一次RSR可以激活一個稱之為Handler(句柄)的函式(該Handler在上下文中有GP表明)。上下文中Handler被異步地執行,並不需“接收”操作。在Nexus中,RSR是一個函式,而不是遠程服務命令,因為命令是不會返回值的。
nexus_send_rsr(&buffer, //指明傳輸的緩衝器首址
&(nodes[n_nodes-1].startpoint), //指名通信的目標節點號
CREATE_LINK_HANDLER_ID, //指明目標節點運行函式
NEXUS_TRUE,
NEXUS _FALSE);
一個RSR的參數由包括一個處理函式的Handler、一個GP及要通信的數據Buffer確定,RSR驅動指定的處理函式在GP指定的上下文中執行。在上下文中,處理函式的執行是異步的。在上下文間通過RSR傳送數據是由一個緩衝區及打包和解包函式完成,這些函式在MPI和PVM中的類似函式功能相似。一個RSR請求按三個步驟來執行:
(1)RSR通過指定一個GP和處理函式的句柄進行初始化;
(2)在RSR被執行時,由在初始化時給定的GP確定執行通信時採用哪一種低級協定;
(3)處理程式在目標上下文以GP的本地地址部分和訊息緩衝區作為參數被調用。
軟體結構 右圖給出了基於Nexus實現多方法通信的軟體結構。
基於Nexus支持多方法通信的軟體結構 實現多方法通信的關鍵問題是如何表示通信方法,在一個特定進程中如何確定可以使用的通信方法的集合,以及通信方法信息是如何與通信起點相聯繫的。
通信模組和函式表 在Nexus中一種通信方法是通過一個通信模組來實現的。要訪問通信模組,必須通過一個標準接口,即函式表。函式表中包括初始化函式、查詢函式以及用來構建通信描述符和通信對象的函式等。在一個特定的執行程式中,可以用兩種方法確定具體需要哪些通信模組。首先,在建立通信庫時,已將一組模組定義成預設的配置參數,這些信息作為靜態的模組名表傳送給執行檔。此外,如果還需要其它的通信模組,可以通過命令行參數或函式調用來添加新的信息。系統通過在每一個需要的模組上調用一個查詢函式,將多個通信模組集成到一個計算問題中。
通信描述符和描述符表 通信描述符含有訪問上下文所需的信息。例如,當使用MPL在IBM SP2多計算機上的節點間進行通信時,需要一個節點號和一個全局唯一的會話標識符;而當使用TCP/IP在兩個節點間通信時,需要對方的主機名和連線埠號。一個通信描述符包含了使用某一特定方法與一個特定上下文通信時所需的所有信息。因此,一個上下文可以通過為每一個通信模組創建一個通信描述符來支持它的所有不同方法。通信描述符表就是對這些信息的簡明且易於進行通信的表示。
通信對象 通信對象代表了一個包含有關通信方法的活躍連線。例如,一個TCP連線的通信對象包含了用於TCP socket的檔案描述符。
起點 一個起點包含了終點信息、指向有關通信描述符表的指針以及通信對象。通信對象代表了當前在這個起點上使用的通信方法,而起點指向的描述符表則代表了遠程上下文所支持的所有通信方法。當起點在一個上下文中生成時,表示這個上下文所支持的方法的通信描述符表也就連線到了起點上。當利用這個起點與另一個上下文通信時,描述符表也隨起點被傳送。因此,接收了該起點的上下文也接收了用來與相應終點進行通信所需的信息。接著該上下文在描述符表說明的方法中選擇一種,構建一個通信對象,接下來的操作通過通信對象進行。
支持RSR的類型 在設計Nexus系統時,目標是非SPMD套用。這種套用中相對複雜的處理程式函式經常出現。另外,程式設計師和編譯器經常能夠識別像遠程存儲器操作這樣的處理程式請求,這種操作不能夠掛起執行。因此,Nexus支持兩種類型的RSR。
(1)執行緒RSR:在這種類型的RSR中,新執行緒的創建是為了執行處理程式。
(2)非執行緒RSR:在這種類型的RSR中,允許處理程式在一個預置的執行緒中執行。
如果程式設計師或者編譯器能夠保證一個處理程式不需要掛起就能中斷執行,它們就可以採用非執行緒RSR。非執行緒RSR是一種非常重要的最佳化,因為它可以避免創建一個新的執行緒;此外,如果並行計算機系統允許處理程式從訊息接口中直接讀取,非執行緒RSR還可避免對中間緩衝區的拷貝,這在不採用非執行緒RSR的情況下對於執行緒的安全執行是必要的。
支持體系 Nexus通信庫支持的計算機體系結構 機器型號
支持的作業系統版本
支持的執行緒庫
Homepage
HPUX 9. x
DCE Threads
IBM RS6000
AIX 3. 2x
DCE Threads
IBM SP2
AIX 3. 2x
DCE Threads
IBM RS6000
AIX 4. 1x
CThreads
SGI工作站
IRIX 5. x
QuickThreads
Sun工作站
SunOS 4. 1. x
pthreads
Sun工作站
Solaris 2. 3
SolarisThreads
Sun工作站
Solaris 2. 6
QuickThreads
PC/Sun工作站
Linux/FreeBSD/SunOS
MIT pthreads