多程序與多執行緒頭大啊 1.C++ 將程序執行在指定的CPU上 1.1.https://blog.csdn.net/w2014qian/article/details/51941549 2.多程序 2.1.管道通訊 2.1.1.程序start啟動程序 join阻塞程序等此程序執行完畢後再執行下一個程序 2.1.2.import multiprocessing 共享數值型 • import multiprocessing

def func(num): num.value=10.78 #子程序改變數值的值，主程序跟著改變

if name==“main”: num=multiprocessing.Value(“d”,10.0) # d表示數值,主程序與子程序共享這個value。（主程序與子程序都是用的同一個value） print(num.value)

p=multiprocessing.Process(target=func,args=(num,))
p.start()
p.join()

print(num.value)

共享陣列行 • import multiprocessing

def func(num): num[2]=9999 #子程序改變陣列，主程序跟著改變

if name==“main”: num=multiprocessing.Array(“i”,[1,2,3,4,5]) #主程序與子程序共享這個陣列 print(num[:])

p=multiprocessing.Process(target=func,args=(num,))
p.start() 
p.join()

print(num[:])
 

程序之間共享資料(dict,list)： • import multiprocessing

def func(mydict,mylist): mydict[“index1”]=“aaaaaa” #子程序改變dict,主程序跟著改變 mydict[“index2”]=“bbbbbb” mylist.append(11) #子程序改變List,主程序跟著改變 mylist.append(22) mylist.append(33)

if name==“main”: with multiprocessing.Manager() as MG: #重新命名 mydict=multiprocessing.Manager().dict() #主程序與子程序共享這個字典 mylist=multiprocessing.Manager().list(range(5)) #主程序與子程序共享這個List

    p=multiprocessing.Process(target=func,args=(mydict,mylist))
    p.start()
    p.join()

    print(mylist)
    print(mydict)

2.1.3.上個例子中，程序是搶佔式的佔用，所以，讀取記憶體共有資料的時候，可能在子程序未修改之前便讀取了，記憶體，所以，可能輸出會有問題，此處還會設計殭屍程序 2.1.4. 每個程序各自有不同的使用者地址空間,任何一個程序的全域性變數在另一個程序中都看不到，所以程序之間要交換資料必須通過核心,在核心中開闢一塊緩衝區,程序A把資料從使用者空間拷到核心緩衝區,程序B再從核心緩衝區把資料讀走,核心提供的這種機制稱為程序間通訊。  ：程序之間可以看到一份公共資源；而提供這份資源的形式或者提供者不同，造成了通訊方式不同，而 pipe就是提供這份公共資源的形式的一種。 2.1.5.上述的python其中的程序之間共享資料(dict,list)：程序通訊的是屬於管道通訊，其中有manage函式，但是這個函式我還不是很理解 在最後一個字典共享的時候，我們可以看出在0x記憶體地址申請出一段空間用以儲存共享的資料 • 管道又是如何實現程序間的通訊 • • 在linux下是fork程序，而在windows createpeocess，忘記函數了，尷尬 2.1.6.其中python共享陣列，沒仔細看，後來一看有RLOACK  所以我懷疑此程序是被預設加鎖了，不是真正的並行，但是還是會亂序執行 2.1.7.第一個自己分析把 2.1.8.寫一個加鎖的資料共享  import os import multiprocessing import time #多程序，併發，亂序併發執行 #多程序加鎖，挨個執行(不是併發)，仍然是亂序 def showdata(lock,i): with lock: time.sleep(2) print(i) if name==“main”: lock=multiprocessing.RLock() #建立鎖 for num in range(10): multiprocessing.Process(target=showdata,args=(lock,num)).start()

檔案對映(Memory-Mapped Files)能使程序把檔案內容當作程序地址區間一塊記憶體那樣來對待。因此，程序不必使用檔案I/O操作，只需簡單的指標操作就可讀取和修改檔案的內容。 　　Win32 API允許多個程序訪問同一檔案對映物件，各個程序在它自己的地址空間裡接收記憶體的指標。通過使用這些指標，不同程序就可以讀或修改檔案的內容，實現了對檔案中資料的共享。 　　應用程式有三種方法來使多個程序共享一個檔案對映物件。 　　(1)繼承：第一個程序建立檔案對映物件，它的子程序繼承該物件的控制代碼。 　　(2)命名檔案對映：第一個程序在建立檔案對映物件時可以給該物件指定一個名字(可與檔名不同)。第二個程序可通過這個名字開啟此檔案對映物件。另外，第一個程序也可以通過一些其它IPC機制(有名管道、郵件槽等)把名字傳給第二個程序。 　　(3)控制代碼複製：第一個程序建立檔案對映物件，然後通過其它IPC機制(有名管道、郵件槽等)把物件控制代碼傳遞給第二個程序。第二個程序複製該控制代碼就取得對該檔案對映物件的訪問許可權。 　　檔案對映是在多個程序間共享資料的非常有效方法，有較好的安全性。但檔案對映只能用於本地機器的程序之間，不能用於網路中，而開發者還必須控制程序間的同步。

4.3.2.2.2 共享記憶體

Win32 API中共享記憶體(Shared Memory)實際就是檔案對映的一種特殊情況。程序在建立檔案對映物件時用0xFFFFFFFF來代替檔案控制代碼(HANDLE)，就表示了對應的檔案對映物件是從作業系統頁面檔案訪問記憶體，其它程序開啟該檔案對映物件就可以訪問該記憶體塊。由於共享記憶體是用檔案對映實現的，所以它也有較好的安全性，也只能運行於同一計算機上的程序之間。

4.3.3.2.3 匿名管道

管道(Pipe)是一種具有兩個端點的通訊通道：有一端控制代碼的程序可以和有另一端控制代碼的程序通訊。管道可以是單向－一端是隻讀的，另一端點是隻寫的；也可以是雙向的一管道的兩端點既可讀也可寫。 　　匿名管道(Anonymous Pipe)是 在父程序和子程序之間，或同一父程序的兩個子程序之間傳輸資料的無名字的單向管道。通常由父程序建立管道，然後由要通訊的子程序繼承通道的讀端點控制代碼或寫 端點控制代碼，然後實現通訊。父程序還可以建立兩個或更多個繼承匿名管道讀和寫控制代碼的子程序。這些子程序可以使用管道直接通訊，不需要通過父程序。 　　匿名管道是單機上實現子程序標準I/O重定向的有效方法，它不能在網上使用，也不能用於兩個不相關的程序之間。

4.3.4.2.4 命名管道

命名管道(Named Pipe)是伺服器程序和一個或多個客戶程序之間通訊的單向或雙向管道。不同於匿名管道的是命名管道可以在不相關的程序之間和不同計算機之間使用，伺服器建立命名管道時給它指定一個名字，任何程序都可以通過該名字開啟管道的另一端，根據給定的許可權和伺服器程序通訊。 　　命名管道提供了相對簡單的程式設計介面，使通過網路傳輸資料並不比同一計算機上兩程序之間通訊更困難，不過如果要同時和多個程序通訊它就力不從心了。

4.3.5.2.5 郵件槽

件槽(Mailslots)提 供程序間單向通訊能力，任何程序都能建立郵件槽成為郵件槽伺服器。其它程序，稱為郵件槽客戶，可以通過郵件槽的名字給郵件槽伺服器程序傳送訊息。進來的消 息一直放在郵件槽中，直到伺服器程序讀取它為止。一個程序既可以是郵件槽伺服器也可以是郵件槽客戶，因此可建立多個郵件槽實現程序間的雙向通訊。 　　通過郵件槽可以給本地計算機上的郵件槽、其它計算機上的郵件槽或指定網路區域中所有計算機上有同樣名字的郵件槽傳送訊息。廣播通訊的訊息長度不能超過400位元組，非廣播訊息的長度則受郵件槽伺服器指定的最大訊息長度的限制。 　　郵件槽與命名管道相似，不過它傳輸資料是通過不可靠的資料報(如TCP/IP協議中的UDP包)完成的，一旦網路發生錯誤則無法保證訊息正確地接收，而命名管道傳輸資料則是建立在可靠連線基礎上的。不過郵件槽有簡化的程式設計介面和給指定網路區域內的所有計算機廣播訊息的能力，所以郵件槽不失為應用程式傳送和接收訊息的另一種選擇。

4.3.6.2.6 剪貼簿

剪貼簿(Clipped Board)實質是Win32 API中一組用來傳輸資料的函式和訊息，為Windows應用程式之間進行資料共享提供了一箇中介，Windows已建立的剪下(複製)－貼上的機制為不同應用程式之間共享不同格式資料提供了一條捷徑。當用戶在應用程式中執行剪下或複製操作時，應用程式把選取的資料用一種或多種格式放在剪貼簿上。然後任何其它應用程式都可以從剪貼簿上拾取資料，從給定格式中選擇適合自己的格式。 　　剪貼簿是一個非常鬆散的交換媒介，可以支援任何資料格式，每一格式由一無符號整數標識，對標準(預定義)剪貼簿格式，該值是Win32 API定義的常量；對非標準格式可以使用Register Clipboard Format函式註冊為新的剪貼簿格式。利用剪貼簿進行交換的資料只需在資料格式上一致或都可以轉化為某種格式就行。但剪貼簿只能在基於Windows的程式中使用，不能在網路上使用。

4.3.7.2.7 動態資料交換

動態資料交換(DDE)是使用共享記憶體在應用程式之間進行資料交換的一種程序間通訊形式。應用程式可以使用DDE進行一次性資料傳輸，也可以當出現新資料時，通過傳送更新值在應用程式間動態交換資料。 　　DDE和剪貼簿一樣既支援標準資料格式(如文字、點陣圖等)，又可以支援自己定義的資料格式。但它們的資料傳輸機制卻不同，一個明顯區別是剪貼簿操作幾乎總是用作對使用者指定操作的一次性應答－如從選單中選擇Paste命令。儘管DDE也可以由使用者啟動，但它繼續發揮作用一般不必使用者進一步干預。DDE有三種資料交換方式： 　　(1) 冷鏈：資料交換是一次性資料傳輸，與剪貼簿相同。 　　(2) 溫鏈：當資料交換時伺服器通知客戶，然後客戶必須請求新的資料。 　　(3) 熱鏈：當資料交換時伺服器自動給客戶傳送資料。 　　DDE交換可以發生在單機或網路中不同計算機的應用程式之間。開發者還可以定義定製的DDE資料格式進行應用程式之間特別目的IPC，它們有更緊密耦合的通訊要求。大多數基於Windows的應用程式都支援DDE。

4.3.8.2.8 物件連線與嵌入

應用程式利用物件連線與嵌入(OLE)技術管理複合文件(由多種資料格式組成的文件)，OLE提供使某應用程式更容易呼叫其它應用程式進行資料編輯的服務。例如，OLE支援的字處理器可以巢狀電子表格，當用戶要編輯電子表格時OLE庫可自動啟動電子表格編輯器。當用戶退出電子表格編輯器時，該表格已在原始字處理器文件中得到更新。在這裡電子表格編輯器變成了字處理器的擴充套件，而如果使用DDE，使用者要顯式地啟動電子表格編輯器。 　　同DDE技術相同，大多數基於Windows的應用程式都支援OLE技術。 4.3.9.2.9 動態連線庫

Win32動態連線庫(DLL)中的全域性資料可以被呼叫DLL的所有程序共享，這就又給程序間通訊開闢了一條新的途徑，當然訪問時要注意同步問題。 　　雖然可以通過DLL進行程序間資料共享，但從資料安全的角度考慮，我們並不提倡這種方法，使用帶有訪問許可權控制的共享記憶體的方法更好一些。

4.3.10.2.10 遠端過程呼叫

Win32 API提供的遠端過程呼叫(RPC)使應用程式可以使用遠端呼叫函式，這使在網路上用RPC進行程序通訊就像函式呼叫那樣簡單。RPC既可以在單機不同程序間使用也可以在網路中使用。 　　由於Win32 API提供的RPC服從OSF-DCE(Open Software Foundation Distributed Computing Environment)標準。所以通過Win32 API編寫的RPC應用程式能與其它作業系統上支援DEC的RPC應用程式通訊。使用RPC開發者可以建立高效能、緊密耦合的分散式應用程式。

4.3.11.2.11 NetBios函式

Win32 API提供NetBios函式用於處理低階網路控制，這主要是為IBM NetBios系統編寫與Windows的介面。除非那些有特殊低階網路功能要求的應用程式，其它應用程式最好不要使用NetBios函式來進行程序間通訊。

4.3.12.2.12 Sockets Windows Sockets規範是以U.C.Berkeley大學BSD UNIX中流行的Socket介面為範例定義的一套Windows下的網路程式設計介面。除了Berkeley Socket原有的庫函式以外，還擴充套件了一組針對Windows的函式，使程式設計師可以充分利用Windows的訊息機制進行程式設計。 　　現在通過Sockets實現程序通訊的網路應用越來越多，這主要的原因是Sockets的跨平臺性要比其它IPC機制好得多，另外WinSock 2.0不僅支援TCP/IP協議，而且還支援其它協議(如IPX)。Sockets的唯一缺點是它支援的是底層通訊操作，這使得在單機的程序間進行簡單資料傳遞不太方便，這時使用下面將介紹的WM_COPYDATA訊息將更合適些。

4.3.13.2.13 WM_COPYDATA訊息

WM_COPYDATA是一種非常強大卻鮮為人知的訊息。當一個應用向另一個應用傳送資料時，傳送方只需使用呼叫SendMessage函式，引數是目的視窗的控制代碼、傳遞資料的起始地址、WM_COPYDATA訊息。接收方只需像處理其它訊息那樣處理WM_COPY DATA訊息，這樣收發雙方就實現了資料共享。 　　WM_COPYDATA是一種非常簡單的方法，它在底層實際上是通過檔案對映來實現的。它的缺點是靈活性不高，並且它只能用於Windows平臺的單機環境下。 4.3.14.Win32 API為應用程式實現程序間通訊提供瞭如此多種選擇方案，那麼開發者如何進行選擇呢？通常在決定使用哪種IPC方法之前應考慮以下一些問題： 　　(1)應用程式是在網路環境下還是在單機環境下工作。 4.4.程序間通訊與應用程式間通訊及實現技術 4.4.1.摘 要 本文討論了程序間通訊與應用程式間通訊的含義及相應的實現技術，並對這些技術的原理、特性等進行了深入的分析和比較。 4.4.2.---- 關鍵詞 訊號 管道 訊息佇列 共享儲存段 訊號燈 遠端過程呼叫 Socket套接字 MQSeries 4.4.3.1 引言 — 程序間通訊的主要目的是實現同一計算機系統內部的相互協作的程序之間的資料共享與資訊交換，由於這些程序處於同一軟體和硬體環境下，利用作業系統提供的的程式設計介面，使用者可以方便地在程式中實現這種通訊；應用程式間通訊的主要目的是實現不同計算機系統中的相互協作的應用程式之間的資料共享與資訊交換，由於應用程式分別執行在不同計算機系統中，它們之間要通過網路之間的協議才能實現資料共享與資訊交換。程序間通訊和應用程式間通訊及相應的實現技術有許多相同之處，也各有自己的特色。即使是同一型別的通訊也有多種的實現方法，以適應不同情況的需要。

---- 為了充分認識和掌握這兩種通訊及相應的實現技術，本文將就以下幾個方面對這兩種通訊進行深入的討論：問題的由來、解決問題的策略和方法、每種方法的工作原理和實現、每種實現方法的特點和適用的範圍等。 4.4.4.2 程序間的通訊及其實現技術 ---- 使用者提交給計算機的任務最終都是通過一個個的程序來完成的。在一組併發程序中的任何兩個程序之間，如果都不存在公共變數，則稱該組程序為不相交的。在不相交的程序組中，每個程序都獨立於其它程序，它的執行環境與順序程式一樣，而且它的執行環境也不為別的程序所改變。執行的結果是確定的，不會發生與時間相關的錯誤。

---- 但是，在實際中，併發程序的各個程序之間並不是完全互相獨立的，它們之間往往存在著相互制約的關係。程序之間的相互制約關係表現為兩種方式： — （1） 間接相互制約：共享CPU

---- （2） 直接相互制約：競爭和協作 ---- 競爭——程序對共享資源的競爭。為保證程序互斥地訪問共享資源，各程序必須互斥地進入各自的臨界段。

---- 協作——程序之間交換資料。為完成一個共同任務而同時執行的一組程序稱為同組程序，它們之間必須交換資料，以達到協作完成任務的目的，交換資料可以通知對方可以做某事或者委託對方做某事。 ---- 共享CPU問題由作業系統的程序排程來實現，程序間的競爭和協作由程序間的通訊來完成。程序間的通訊一般由作業系統提供程式設計介面，由程式設計師在程式中實現。UNIX在這個方面可以說最具特色，它提供了一整套程序間的資料共享與資訊交換的處理方法——程序通訊機制（IPC）。因此，我們就以UNIX為例來分析程序間通訊的各種實現技術。 — 在UNIX中，檔案（File）、訊號（Signal）、無名管道（Unnamed Pipes）、有名管道（FIFOs）是傳統IPC功能；新的IPC功能包括訊息佇列（Message queues）、共享儲存段（Shared memory segment）和訊號燈（Semapores）。 ---- （1） 訊號 • ---- 訊號機制是UNIX為程序中斷處理而設定的。它只是一組預定義的值，因此不能用於資訊交換，僅用於程序中斷控制。例如在發生浮點錯、非法記憶體訪問、執行無效指令、某些按鍵（如ctrl-c、del等）等都會產生一個訊號，作業系統就會呼叫有關的系統呼叫或使用者定義的處理過程來處理。

---- 訊號處理的系統呼叫是signal，呼叫形式是：

---- signal(signalno,action)

---- 其中，signalno是規定訊號編號的值，action指明當特定的訊號發生時所執行的動作。 ---- （2） 無名管道和有名管道 • — 無名管道實際上是記憶體中的一個臨時儲存區，它由系統安全控制，並且獨立於建立它的程序的記憶體區。管道對資料採用先進先出方式管理，並嚴格按順序操作，例如不能對管道進行搜尋，管道中的資訊只能讀一次。

---- 無名管道只能用於兩個相互協作的程序之間的通訊，並且訪問無名管道的程序必須有共同的祖先。

---- 系統提供了許多標準管道庫函式，如：

pipe()——開啟一個可以讀寫的管道； close()——關閉相應的管道； read()——從管道中讀取字元； write()——向管道中寫入字元；

• ---- 有名管道的操作和無名管道類似，不同的地方在於使用有名管道的程序不需要具有共同的祖先，其它程序，只要知道該管道的名字，就可以訪問它。管道非常適合程序之間快速交換資訊。 ---- （3） 訊息佇列（MQ） • — 訊息佇列是記憶體中獨立於生成它的程序的一段儲存區，一旦建立訊息佇列，任何程序，只要具有正確的的訪問許可權，都可以訪問訊息佇列，訊息佇列非常適合於在程序間交換簡訊息。

---- 訊息佇列的每條訊息由型別編號來分類，這樣接收程序可以選擇讀取特定的訊息型別——這一點與管道不同。訊息佇列在建立後將一直存在，直到使用msgctl系統呼叫或iqcrm -q命令刪除它為止。

---- 系統提供了許多有關建立、使用和管理訊息佇列的系統呼叫，如：

---- int msgget(key,flag)——建立一個具有flag許可權的MQ及其相應的結構，並返回一個唯一的正整數msqid（MQ的識別符號）；

---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向佇列中傳送資訊；

---- int msgrcv(msqid,cmd,buf)——從佇列中接收資訊；

---- int msgctl(msqid,cmd,buf)——對MQ的控制操作； ---- （4） 共享儲存段（SM） • ---- 共享儲存段是主存的一部分，它由一個或多個獨立的程序共享。各程序的資料段與共享儲存段相關聯，對每個程序來說，共享儲存段有不同的虛擬地址。系統提供的有關SM的系統呼叫有：

---- int shmget(key,size,flag)——建立大小為size的SM段，其相應的資料結構名為key，並返回共享記憶體區的識別符號shmid；

---- char shmat(shmid,address,flag)——將當前程序資料段的地址賦給shmget所返回的名為shmid的SM段；

---- int shmdr(address)——從程序地址空間刪除SM段；

---- int shmctl (shmid,cmd,buf)——對SM的控制操作；

---- SM的大小隻受主存限制，SM段的訪問及程序間的資訊交換可以通過同步讀寫來完成。同步通常由訊號燈來實現。SM非常適合程序之間大量資料的共享。 ---- （5） 訊號燈 • ---- 在UNIX中，訊號燈是一組程序共享的資料結構，當幾個程序競爭同一資源時（檔案、共享記憶體或訊息佇列等），它們的操作便由訊號燈來同步，以防止互相干擾。

---- 訊號燈保證了某一時刻只有一個程序訪問某一臨界資源，所有請求該資源的其它程序都將被掛起，一旦該資源得到釋放，系統才允許其它程序訪問該資源。訊號燈通常配對使用，以便實現資源的加鎖和解鎖。

---- 程序間通訊的實現技術的特點是：作業系統提供實現機制和程式設計介面，由使用者在程式中實現，保證程序間可以進行快速的資訊交換和大量資料的共享。但是，上述方式主要適合在同一臺計算機系統內部的程序之間的通訊。 子主題 11 4.4.5.3 應用程式間的通訊及其實現技術 ---- 同進程之間的相互制約一樣，不同的應用程式之間也存在競爭和協作的關係。UNIX作業系統也提供一些可用於應用程式之間實現資料共享與資訊交換的程式設計介面，程式設計師可以通過自己程式設計來實現。如遠端過程呼叫和基於TCP/IP協議的套接字（Socket）程式設計。但是，相對普通程式設計師來說，它們涉及的技術比較深，程式設計也比較複雜，實現起來困難較大。

---- 於是，一種新的技術應運而生——通過將有關通訊的細節完全掩蓋在某個獨立軟體內部，即底層的通訊工作和相應的維護管理工作由該軟體內部來實現，使用者只需要將通訊任務提交給該軟體去完成，而不必理會它的具體工作過程——這就是所謂的中介軟體技術。

---- 我們在這裡分別討論這三種常用的應用程式間通訊的實現技術——遠端過程呼叫、會話程式設計技術和MQSeries訊息佇列技術。其中遠端過程呼叫和會話程式設計屬於比較低階的方式，程式設計師參與的程度較深，而MQSeries訊息佇列則屬於比較高階的方式，即中介軟體方式，程式設計師參與的程度較淺。 4.4.6.---- 4．1 遠端過程呼叫（RPC） ---- 遠端過程呼叫是按下述方式工作的：當一個應用程式A需要與遠端的另一個應用程式B交換資訊或要求B提供協助時，A將在本地產生一個請求，通過通訊鏈路，通知B接收資訊或提供相應的服務，B完成相關處理後將確認資訊或結果返回給A。

---- RPC機制強調通訊的兩個應用程式所處的環境和平臺中必須是相同的，而且必須同時處於執行狀態。做遠端呼叫時，兩者必須先建立連線，而且通訊鏈路質量對它的效果影響很大。

---- RPC的優點是應用程式採用呼叫/返回方式通訊，擁有很高的潛在效率，但需要應用程式間的緊密藕合，通訊線路必須在通訊期間一直保持良好的狀態，而且必須進行大量的底層通訊的程式設計工作。 ---- 4．2 會話程式設計 • ---- 會話程式設計類似於人們打電話，撥號——接通——說話——對方回答——掛機。基於TCP/IP協議的Socket程式設計就是一種典型的會話程式設計方式。它可適用於客戶/服務通訊方式，還能適用於點——點通訊方式。

---- 下面，我們分別介紹伺服器端和客戶端的具體任務。 • ---- （1） 伺服器端 • — 服務程序首先建立一個套介面，使用Socket（）呼叫；然後，將該套介面與本機的IP地址和某一空閒埠相關聯，使用Bind（）呼叫；這時，服務端就可以用Listen（）呼叫來偵聽來自客戶程式的資料；套介面一旦處於聽模式，服務程序將可以接收一個連線，並允許傳遞資料，使用Accept（）呼叫來完成；最後使用Read（）呼叫來讀入資料，同時，還可以用Write（）呼叫來向傳送程序寫回一些資料，如確認資訊或回顯資訊。 • 子主題 2 • 客戶端 • ---- 客戶程序也是首先建立一個套介面，使用Socket（）呼叫；然後，客戶程序就使用Connect（）呼叫試圖連線一個服務；連線成功之後，就可以利用Write（）呼叫向伺服器傳送資料，同時，還可以使用Read（）呼叫讀取伺服器寫回的資料。

---- 目前的網路一般都支援TCP/IP協議，UNIX和WINDOWS也都提供相應的程式設計介面，使用者可以隨心所欲地編制出合乎自己要求的通訊程式。現行大多數的應用程式間的通訊採取的就是這種方式。但是，這種Socket程式設計技術，要求程式設計師必須熟悉相關概念，自己設計控制流程，客戶和服務程序必須相互配合且必須都處於執行狀態，技術上有一定的難度。 ---- 4．3 MQSeries訊息佇列 • ---- 為了簡化應用程式間的通訊，使得通訊既具有較高的可靠性，又保證實現的簡單性，我們希望能有一種獨立的通訊軟體，應用程式只需將任務提交給該軟體，由該軟體自動去完成資訊的傳遞工作，這即是我們前面提到的中介軟體技術。IBM公司的MQSeries就是基於這種技術的商業化產品。

---- 應用程式A和B位於同一計算機，而應用程式C位於遠端的其它計算機系統中。當應用程式A需要和B通訊時，它通過呼叫MQSeries介面將訊息放入佇列Q1，應用程式B在適當的時候讀取該訊息，或訊息本身到達後喚醒應用程式B。當應用程式A需要和C通訊時，它通過相同的方式將訊息放入佇列Q2，應用程式C在適當的時候讀取該訊息。

---- 應用程式之間的訊息傳遞是通過佇列來實現的，是間接的。由於不存在直接連線，C關閉時A仍然能正常執行，不僅如此，當C不在執行時，訊息還可以觸發該程式。

---- MQSeries優點可以確保資訊是永久的、可恢復的；確保資訊成功傳送且僅有一次傳送，可以支援關鍵業務，如證券交易資訊的傳遞；確保資訊傳遞是保密的；同時，使用MQSeries，不需要應用程式和通訊介質以及遠端應用程式之間的耦合，也不需要應用程式同時執行。MQSeries是應用程式間通訊的首選技術。

---- MQSeries介面提供的呼叫主要有：

---- MQCONN——連線一個佇列管理器，以後它傳送和讀入的訊息的所有訊息都由這個佇列管理器管理；

---- MQOPEN——開啟該應用程式所連線的佇列；

---- MQPUT——將訊息寫入已開啟的佇列中；

---- MQGET——從該佇列中讀出訊息；

---- MQINQ——獲得關於佇列的屬性；

---- MQCLOSE——關閉佇列（對佇列執行完所有操作後）；

---- MQPUT1——它執行三個操作，先呼叫MQOPEN開啟佇列，然後呼叫MQPUT寫入一條訊息，最後呼叫MQCLOSE關閉佇列；

---- MQDISC——斷開和佇列管理器的連線（對佇列管理器的所有操作完成後）； ---- 4．4 三種實現技術的特性比較 • 表1清楚地列出了RPC、 Socket程式設計、MQSeries的不同特性。 • 比較專案 Socket程式設計 RPC MQSeries 屬性 會話 遠端呼叫 訊息佇列 型別 會話 呼叫/返回 佇列 程式設計介面 非阻塞 阻塞 非阻塞 通訊對方執行 是 是 否 應用程式型別 面向連線 面向連線 無連線 資料流模式 點-點，客戶機/伺服器 客戶機/伺服器 所有模式 邏輯路由 否 否 是 永久資料 否 否 是 • 表1 三種中介軟體的特性比較 結束語 • 4 結束語

---- 各種程序間通訊和應用程式間通訊的實現技術都具有自己的特點和使用範圍。管道、訊息佇列、共享記憶體等技術最適用於同一計算機系統內部的程序間通訊，以保證高效率。而遠端過程呼叫、Socket會話程式設計、MQSeries則最適用於遠端的應用程式之間通訊，可以簡化通訊的程式設計，當然也保證通訊的可靠性。尤其是MQSeries，它是一個比較完善的中介軟體產品，為許多的資訊系統所選用。如我公司的帳務系統與各金融系統的話費資訊的交換選擇的就是MQSeries。有時，在一個資訊系統裡面，既存在程序間通訊的需求，也存在應用程式間通訊的需求，這時就必須分別選擇兩種不同的實現技術。因此，在實際資訊系統建設的過程中，我們在選擇哪種實現技術時，應根據資訊系統的不同情況和不同需求，根據系統開發和維護的成本，選擇一種或是幾種實現技術，以求得整個系統的優化。 5.分支主題 5