<p>如我們在14.6.1中所述，至少服務者應將分配給隊列的標識符寫到一個文件中以便 
</p>

<p>客戶讀取。 </p>

<p>這些作者列舉的消息隊列的其它優點是：（a）它們是可靠的（b）流是受到控制的 
</p>

<p>，（c）面向記錄，（d）可以用非先進先出方式處理。正如我們在12.4節中所見， 
</p>

<p>流也具有所有這些優點，雖然在向一個流發送數據之前，需要一個open，在結束時 
</p>

<p>需要一個close。圖14.15對這些不同形式的IPC的某些特征進行了比較。 
</p>

<p>圖14.15 不同形式IPC之間特征的比較 </p>

<p>（我們將在第十五章對Unix流和數據報套接口進行簡要說明。）表中的&quot;無連接&quot;， 
</p>

<p>我們指的是無需先調用某種形式的open，就能發送消息的能力。正如前述，因為需 
</p>

<p>要有某種技術以獲得隊列標識符，所以我們并不認為消息隊列具有無連接特性。因 
</p>

<p>為所有這些形式的IPC都限制用在單主機上，所以它們都是可靠的。當消息通過網 
</p>

<p>絡傳送時，丟失消息的可能性就要加以考慮。流控制的意思是：如果系統資源短缺 
</p>

<p>（緩存）或者如果接收進程不能再接收更多消息，則發送進程就要睡眠。當流控制 
</p>

<p>條件消失時，發送進程應自動地被喚醒。 </p>

<p>在圖14.15中我們沒有表示的一個特征是：IPC設施能否自動地為每個客戶自動地創 
</p>

<p>建一個到服務者的唯一連接。我們將在第十五章中說明，流以及Unix流套接口提供 
</p>

<p>這種能力。 </p>

<p>下面三節順次對三種形式的系統V IPC進行詳細說明。 </p>

<p>14.7消息隊列(Message Queues) </p>

<p>消息隊列是消息的鏈接表,存放在核內并由消息隊列標識符標識。我們將稱消 
</p>

<p>息隊列為&quot;隊列&quot;，其標識符為&quot;隊列ID&quot;。msgget創建一個新隊列或打開一個現存的 
</p>

<p>隊列。msgsnd將新消息添加到隊列尾端。每個消息包含有一個正長整型類型字段， 
</p>

<p>一個非負長度以及實際數據字節（對應于長度），所有這些都在將消息添加到隊列 
</p>

<p>時，傳送給msgsnd。用msgrcv從隊列中取消息。我們并不一定要以先進先出次序取 
</p>

<p>消息。我們可以按消息的類型字段取消息。 </p>

<p>每個隊列都有一個msqid_ds結構與其相關。此結構規定了隊列的當前狀態。 
</p>

<p>struct msqid_ds { </p>

<p>struct ipc_perm msg_perm ; 參見14.6.2 節 </p>

<p>struct msg *msg_first; 指向隊列中第一條消息的指針 </p>

<p>struct msg *msg_last; 指向隊列中最后一條消息的指針 </p>

<p>ulong msg_cbytest; 隊列中的當前字節號 </p>

<p>ulong msg_qnum; 隊列中的消息數 </p>

<p>ulong msg_qbytes; 隊列中的最大字節數 </p>

<p>pid_t msg_lspid; 最后msgsnd()的pid </p>

<p>pid_t msg_lrpid; 最后msgrcv()的pid </p>

<p>time_t msg_stime 最后msgsnd()時間 </p>

<p>time_t msg_rtime 最后msgrcv()時間 </p>

<p>time_t msg_ctime; 最后更改時間 </p>

<p>}; </p>

<p>兩個指針msgfirst和msglast分別指向相應消息在核內的存放位置，所以它們對用 
</p>

<p>戶進程而言是無價值的。結構的其他成員是自定義的。 </p>

<p>圖14.16列出了影響消息隊列的系統限制（14。6。3節）。 </p>

<p>圖14.6影響消息隊列的系統限制 </p>

<p>調用的第一個函數通常是msgget，其功能是打開一個現存隊列或創建一個新隊列 
</p>

<p>。 </p>

<p>#include &lt;sys/types.h&gt; </p>

<p>#include &lt;sys/ipc.h&gt; </p>

<p>#include &lt;sys/msg.h&gt; </p>

<p>int msgget(key_t key, int flag); </p>

<p>返回：若成功為消息隊列ID，出錯為-1 </p>

<p>在14.6節中，我們說明了將key變換成一個標識符的規則，并且討論是否創建一個 
</p>

<p>新隊列或訪一個現存隊列。當創建一個新隊列時，初始化msqid-ds結構的下列成員 
</p>

<p>: </p>

<p>&middot;ipc-perm結構按14.6.2節中所述進行初始化。該結構中mode按flag；中的相 
</p>

<p>應許可權位設置。這些許可權用圖14.14中的常數指定 </p>

<p>&middot; msg_qnum,msg_lspid、msg_lrpid、msg_stime和msg_rtime都設置為0。 </p>

<p>&middot; msg_ctime設置為當前時間。 </p>

<p>&middot; msg_gbytes設置為系統限制值。 </p>

<p>若執行成功，則返回非負隊列ID。此后，此值就可被用于其它三個消息隊列函數。 
</p>

<p>msgctl函數對隊列執行多種操作。它以及另外兩個與信號量和共享存儲有關的函數 
</p>

<p>(semctl和shmctl)是系統V IPC的類似于ioctl的函數（亦即垃圾桶函數）。 
</p>

<p>#include &lt;sys/types.h&gt; </p>

<p>#include &lt;sys/ipc.h&gt; </p>

<p>#include &lt;sys/msg.h&gt; </p>

<p>int msgctl(int msqid, int cmd, struct msqid_ds *buf); </p>

<p>返回：若成功為0，出錯為-1 </p>

<p>cmd參數指定對于由msqid規定的隊列要執行的命令： </p>

<p>IPC_STAT 取此隊列的msqid_ds結構，并將其存放在buf指向的結構中。 </p>

<p>IPC_SET 按由buf指向的結構中的值，設置與此隊列相關的結構中的下列四 
</p>

<p>個字段msg_perm.uid、msg_perm.gid、msg_perm;mode和msg_qbytes。此命令只能 </p>

<p>由下列兩種進程執行：一種進程是其有效用戶ID等于msg_perm. cuid或msg_per 
</p>

<p>m.uid;另一種進程是具有超級用戶特權的進程。只有超級用戶才能增加msg_qbyte 
</p>

<p>s的值 </p>

<p>IPC-RMID 
從系統中刪除該消息隊列以及仍在該隊列上的所有數據。這種刪除 </p>

<p>是立即生效的。仍在使用這一消息隊列的其它進程在它們下一次試圖對此隊列進行 
</p>

<p>操作時，將出錯返回，錯誤號為EIDRM。此命令只能由下列兩種進程執行：一種進 
</p>

<p>程是其有效用戶ID等于msg_perm.cuid或msg_perm.uid;另一種進程是具有超級用戶 
</p>

<p>特權的進程。 </p>

<p>我們將會看到這三條命令（IPC_STAT、IPC_SET和IPC_RMID）也用于信號量和共享 
</p>

<p>存儲。 </p>

<p>調用msgsnd將數據放到消息隊列上。 </p>

<p>#include &lt;sys/types.h&gt; </p>

<p>#include &lt;sys/ipc.h&gt; </p>

<p>#include &lt;sys/msg.h&gt; </p>

<p>int msgsnd(int msqid, const void *ptr, size_t nbytes, int flag); </p>

<p>返回：若成功為0，出錯為-1 </p>

<p>正如我們在前面提及的，每個消息都由三部分組成，它們是：正長整型類型字段、 
</p>

<p>非負長度（nbytes）以及實際數據字節（對應于長度）。消息總是放在隊列尾端。 
</p>

<p>Ptr指向一個長整型數，它包含了正整型消息類型，在其后立即跟隨了消息數據。 
</p>

<p>（若nbytes是0，則無消息數據。）若我們發送的最長消息是512字節，則可定義下 
</p>

<p>列結構： </p>

<p>struct mymesg { </p>

<p>long mtypes; 正的消息類型 </p>

<p>char mtext[512]; 消息數據，長度為nbytes </p>

<p>}; </p>

<p>于是，ptr就是一個指向mymesg結構的指針。接收者可以使用消息類型以非先進先 
</p>

<p>出的次序取消息。 </p>

<p>flag的值可以指定為IPC_NOWAIT。這類似于文件I/O的非阻塞I/O標志（見12. 
</p>

<p>2）。若消息隊列已滿（或者是隊列中的消息總數等于系統限制值，或隊列中的字 
</p>

<p>節總數等于系統限制值），則指定IPC_NOWAIT </p>

<p>使得msgsnd立即出錯返回，出錯號是EAGAIN。如若沒有指定IPC_NOWAIT，則進程阻 
</p>

<p>塞直到（a）有空間可以容納要發送的消息，（b）從系統中刪除了此隊列，或（c 
</p>

<p>）捕捉到一個信號，并從信號處理程序返回。在第二種情況，返回出錯號EIDRM（ 
</p>

<p>&quot;標志符被刪除&quot;），最后一種情況則返回出錯號EINTR。 </p>

<p>注意，對消息隊列刪除的處理是不很得體的。因為對每個消息隊列并沒有設置一個 
</p>

<p>引用計數器（對打開文件則有這種計數器），所以刪除一個隊列使得仍在使用這一 
</p>

<p>隊列的進程在下次對隊列進行操作時產生出錯返回。信號量機構也以同樣方式處理 
</p>

<p>其刪除。刪除一個文件則要等到使用該文件的最后一個進程關閉了它，才刪除文件 
</p>

<p>的內容。 </p>

<p>Msgrcv從隊列中取用消息 </p>

<p>#include &lt;sys/types.h&gt; </p>

<p>#include &lt;sys/ipc.h&gt; </p>

<p>#include &lt;sys/msg.h&gt; </p>

<p>int msgrcv(int msqid, void *ptr, size_t nbytes, long type, int flag); </p>

<p>返回：若成功為消息數據部分的長度，出錯為-1 </p>

<p>如同msgsnd中一樣，ptr參數指向一個長整型數（返回的消息類型存放在其中 
</p>

<p>），跟隨其后的是存放實際消息數據的緩存。nbytes說明數據緩存的長度。若返回 
</p>

<p>的消息大于nbytes，而且在flag中設置MSG_ </p>

<p>NOERROR，則該消息就被截短。（在這種情況下，不通知我們消息截短了。）如果 
</p>

<p>沒有設置這一標志，而消息又太長，則出錯返回，出錯號是EIBIG（消息仍留在隊 
</p>

<p>列中）。 </p>

<p>參數type使我們可以指定想要哪一種消息: </p>

<p>type== 返回隊列中的第一個消息。 </p>

<p>type&gt;0 返回隊列中消息類型為type的第一個消息。 </p>

<p>type&lt;0 返回隊列中消息類型值小于或等于type絕對值，而且在這種消息中，其 
</p>

<p>類型值又最小的消息。 </p>

<p>非0type用于以非先進先出次序讀消息。例如，若應用程序對消息賦優先權，那么 
</p>

<p>type就可以是優先權值。如果一個消息隊列由多個客戶和一個服務者使用，那么t 
</p>

<p>ype字段可以用來包含客戶進程ID。 </p>

<p>我們可以指定flag值為IPC_NOWAIT，使操作不阻塞。這造成如果沒有所指定類 
</p>

<p>型的消息，則ms </p>

<p>-grcv出錯返回，出錯號為ENOMSG。如果沒有指定IPC_NOWAIT，則進程阻塞直至（ 
</p>

<p>a）有了指定類型的消息，（b）從系統中刪除了此隊列（返回出錯號EIDRM），或 
</p>

<p>（c）捕捉到一個信號并從信號處理程序返回（返回出錯號EINTR）。 
</p>

<p>實例一消息隊列對流管道的時間比較 </p>

<p>如若需要在客戶和服務者之間的雙向數據流，我們可以使用消息隊列或流管道 
</p>

<p>。（我們在15.2介紹流管道，它與管道類似，但是是全雙工的。） </p>

<p>圖14.17顯示了在兩個不同系統上這兩種技術在時間方面的比較。測試程序先 
</p>

<p>創建IPC通道，調用fork，然后從父進程向子進程發送20mbytes數據。數據發送的 
</p>

<p>方式是：對于消息隊列，調用10，000次msgsnd，每個消息長度為20，000bytes； 
</p>

<p>對于流管道，調用10，000次write,每次寫20，000bytes。時間都以秒為單位。 
</p>

<p>圖14.17 消息隊列和流管道的時間比較 </p>

<p>在SPARC上，流管道是用Unix域套接口實現的。在SVR4之下，pipe函數提供流管道 
</p>

<p>（使用我們在12.4中所述的流機制）。 </p>

<p>從這些數字中可見，消息隊列原來的實施目的是提供比一般IPC更高速度的進 
</p>

<p>程通信方法，但現在與其它形式的IPC相比，在速度方面已經沒有什么差別了。（ 
</p>

<p>在原來實施消息隊列時，唯一的其它形式的IPC是半雙工管道。）當我們考慮到使 
</p>

<p>用消息隊列具有的問題時（14.6.4），我們得出的結論是，在新的應用程序中不應 
</p>

<p>當再使用它們。 </p>

<p>14.8 信號量（Semaphores） </p>

<p>信號量與我們已經介紹過的IPC機構（管道、FIFO以及消息列隊）不同。它是 
</p>

<p>一個計數器，用于多進程對共享數據對象的存取。為了獲得共享資源，進程需要執 
</p>

<p>行下列操作： </p>

<p>1. 測試控制該資源的信號量。 </p>

<p>2. 
若此信號量的值為正，則進程可以使用該資源。進程將信號量值減1，表示它使 
</p>

<p>用了一個資源單位。 </p>

<p>3. 若此信號量的值為0，則進程進入睡眠狀態，直至信號量值大于0。若進程被喚 
</p>

<p>醒后，它返回至步驟1。 </p>

<p>當進程不再使用由一個信息量控制的共享資源時，該信號量值增1。如果有進程正 
</p>

<p>在睡眠等待此信號量，則喚醒它們。 </p>

<p>　　為了正確地實現信息量，信號量值的測試及減1操作應當是原子操作。為此， 
</p>

<p>信號量通常是在核內實現的。 </p>

<p>常用的信號量形式被稱之為雙態信號量。它控制單個資源，其初試值為1。但 
</p>

<p>是，一般而言，信號量的初值可以是任一正值，該值說明有多少個共享資源單位可 
</p>

<p>供共享應用。 </p>

<p>不幸的是，系統V的信號量與此相比要復雜得多。三種特性造成了這種并非必要的 
</p>

<p>復雜性。 </p>

<p>1. 
一個信號量并非是一個非負值。代之以我們必需將一個信號量定義為含有一個 
</p>

<p>或多個信號量值的集合。當創建一個信號量時，我們要指定該集合中的各個值 
</p>

<p>2. 創建信息量（semget）與對其賦初值（semctl）分開。這是一個致命的弱點， 
</p>

<p>因為我們不能原子地創建一個信號量集合，并且對該集合中的所有值賦初值。 
</p>

<p>3. 即使沒有進程正在使用各種形式的系統V IPC它們仍然是存在的，所以不得不為 
</p>

<p>這種程序擔心，它在終止時并沒有釋放已經分配給它的信號量。將在下面說明的&quot; 
</p>

<p>undo&quot;功能就是假定要處理這種情況的。 </p>

<p>核為每個信號量設置了一個semid_ds結構。 </p>

<p>struct semid_ds { </p>

<p>struct ipc_perm sem_perm; 見14.6.2節 </p>

<p>struct sem *sem_base; 指向集中的第一個信號量 </p>

<p>ushort sem_nsems; 集中的信號量數 </p>

<p>time_t sem_otime; 最后semop()時間 </p>

<p>time_t sem_ctime; 最后更改時間 </p>

<p>}； </p>

<p>　　對用戶而言，sem_base指針是沒有價值的，它指向核內的sem結構數組，該數 
</p>

<p>組中包含了sem_nsems個元素每個元素，各對應于集合中的一