オペレーティングシステム 4: プロセス通信の種類と実装

低効率: プロデューサは一度に 1 つのプロダクト (メッセージ) のみをバッファプールに入れることができ、コンシューマは一度に 1 つのメッセージしかバッファプールから取得できません。// データが少なくなる
通信はユーザーに対して不透明です。OS はプロセス間の通信用に共有メモリのみを提供します。プロセス間の通信に必要な共有データ構造の設定、データの送信、排他制御、プロセスの同期などはプログラマが行う必要があり、ユーザーにとっては非常に不便であることは明らかです。//処理が面倒

プロセス間で大量のデータを転送する必要がある場合は、 OS が提供する高度な通信ツールを使用する必要があります。このツールの主な機能は次のとおりです。

大量のデータを効率的に転送します。ユーザーは高度な通信コマンド (プリミティブ) を直接使用して、大量のデータを効率的に転送できます。// 大量のデータ
使いやすい。OS は、プロセス通信の実装の具体的な詳細を隠し、高度な通信を実装するための一連のコマンド (プリミティブ) をユーザーに提供します。これは、ユーザーがプロセス間の通信を実装するために便利かつ直接使用できるものです。言い換えれば、通信プロセスはユーザーにとって透過的です。これにより、通信プログラミングの複雑さが大幅に軽減されます。//使い方は簡単

1. プロセス通信の種類

OSの発展に伴い、プロセス間の通信機構も発展しており、初期の低レベルなプロセス通信機構から、大量のデータを送信できる上位レベルの通信ツール機構へと発展しました。現在、高度な通信メカニズムは、共有メモリシステム、パイプ通信システム、メッセージパッシングシステム、およびクライアントサーバーシステムの 4 つの大きなカテゴリに分類できます。

(1) 共有メモリシステム（Shared-Memory System）

共有メモリシステムでは、通信プロセスは、プロセスが通信できる特定のデータ構造または共有メモリ領域を共有します。したがって、次の 2 つのタイプに分類できます。//共有ストレージ

共有データ構造に基づく通信。この通信方法では、プロデューサー・コンシューマー問題における境界バッファなど、プロセス間の情報交換を実現するために、すべてのプロセスが特定のデータ構造を共有する必要があります。オペレーティングシステムは共有メモリのみを提供し、プログラマは共通のデータ構造を設定し、プロセス間の同期を処理する責任を負います。この通信方式は比較的少量のデータの転送にのみ適しており、通信効率が低く、下位通信に属します。//データ量が少ない -> 共有メモリを使用する
共有記憶領域をベースとした通信方式。大量のデータを送信するために、メモリ上に共有記憶領域が指定され、プロセスは共有領域に読み書きすることで情報を交換し、通信を実現します。データの形式や位置、さらにはアクセス制御もプロセスが担当します。 OSではなくプロセスです。このタイプの通信は、高度な通信に属します。通信する前に、通信する必要のあるプロセスが共有ストレージ領域のパーティションをシステムに適用し、それを独自のアドレス空間にアタッチして、その中のデータを通常どおり読み書きできるようにします。完了または不要になった場合は、必要に応じて共有ストレージに戻します。//データ量が多い -> メモリを使用する

(2) パイプライン（パイプ）通信方式

いわゆる「パイプライン」とは、読み込み処理と書き込み処理を接続して通信を実現するための共有ファイルのことで、パイプファイルとも呼ばれます。

パイプ (共有ファイル) に入力を提供する送信プロセス (つまり、書き込みプロセス) は、大量のデータを文字ストリームの形式でパイプに送信します。受信プロセス (つまり、読み取りプロセス) は、パイプの出力を受け入れ、パイプからデータを受け取ります (読み取ります)。送信プロセスと受信プロセスがパイプラインを利用して通信するため、パイプライン通信とも呼ばれます。//パイプライン通信の原理

この方法は最初に UNIX システムに導入され、大量のデータを効率的に転送できるため、その後他の多くのオペレーティングシステムに導入されました。2 者間の通信を調整するには、パイプラインメカニズムが次の 3 つの調整機能を提供する必要があります。

相互排他:つまり、1 つのプロセスがパイプ上で読み取り/書き込み操作を実行しているとき、他の (別の) プロセスは待機する必要があります。
同期:書き込み (入力) プロセスが一定量のデータ (4KB など) をパイプに書き込むと、プロセスはスリープ状態になり、読み取り (出力) プロセスがデータを取得してウェイクアップするまで待機します。読み取りプロセスが空のパイプを読み取るときも、書き込みプロセスがウェイクアップする前に、書き込みプロセスがパイプにデータを書き込むまでスリープして待機する必要があります。
相手の存在を確認：相手の存在が確認された場合のみ通信を行うことができます。

(3) メッセージパッシングシステム

この仕組みでは、プロセスは共有の記憶領域やデータ構造を使用する必要はなく、フォーマットされたメッセージ（メッセージ）の単位で通信データをカプセル化し、オペレーティングシステム（本来は言語）が提供する一連の通信コマンドを使用します。、プロセス間でメッセージを渡し、プロセス間のデータ交換を完了します。// 通信プリミティブを使用する

この方法は、通信実装の詳細を隠し、通信プロセスをユーザーに透過的にし、通信プログラム設計の複雑さとエラー率を軽減し、最も広く使用されているプロセス間通信メカニズムとなっています。例: コンピュータネットワークでは、メッセージはメッセージとも呼ばれます。マイクロカーネルオペレーティングシステムでは、マイクロカーネルとサーバー間の通信には例外なくメッセージパッシングメカニズムが採用されています。マルチプロセッサシステム、分散システム、およびコンピュータネットワークがサポートされています。したがって、これらの分野では最も重要なコミュニケーションツールとなっています。

メッセージパッシングシステムに基づく通信方式は高度な通信方式に属します。実装方式の違いにより、さらに 2 つのカテゴリに分類できます。

直接通信モード:送信プロセスが OS によって提供される送信プリミティブを使用して、ターゲットプロセスにメッセージを直接送信することを意味します。
間接通信モード:プロセス間の通信を完了するために中間エンティティ (メールボックスと呼ばれる) を共有することによってメッセージを送受信する送受信プロセスを指します。

(4) クライアント・サーバー方式（クライアント・サーバー方式）

前述の共有メモリ、メッセージパッシングなどの技術も、異なるコンピュータプロセス間の双方向通信を実現するために使用できますが、ネットワークのさまざまな応用分野では、クライアントサーバーシステムの通信メカニズムが現在の主流の通信となっています。実装メカニズム、その主な実装メソッドは、ソケット、リモートプロシージャコール、およびリモートメソッドコールの3 つのカテゴリに分類されます。// 主流の通信メカニズム

4.1 - ソケット

ソケットは、1970 年代にカリフォルニア大学ケリー校の UNIX バージョンに由来し、UNIX オペレーティングシステムでのネットワーク通信インターフェイスです。当初、ソケットは同じホスト上の複数のアプリケーション間の通信 (つまり、プロセス間通信) のために設計されており、主に複数のプロセスのペアが同時に通信する場合のポートと物理回線の多重化の問題を解決するために設計されました。//ポートを区別し、多重化する

ソケットは、通信先のアドレス、通信に使用されるポート番号、通信ネットワークのトランスポート層プロトコル、プロセスのネットワークアドレス、クライアントに提供されるさまざまなシステムコールなどを含む、通信識別タイプのデータ構造です。またはサーバープログラム (またはAPI 関数) などは、プロセス通信およびネットワーク通信の基本コンポーネントです。//アドレス + ポート + プロトコル

ソケットはクライアント/サーバーモデル用に設計されており、通常、ソケットには次の 2 つのタイプがあります。

ファイルベース: 通信プロセスはすべて同じマシンの環境で実行され、ソケットはローカルファイルシステムによってサポートされ、ソケットは特殊ファイルに関連付けられ、通信当事者は特殊ファイルの読み取りと書き込みによって通信を実現します。ファイル、その原理は上記のパイプラインと似ています。// パイプライン

ネットワークベース: このタイプは通常、非対称通信方法を使用します。つまり、送信者が受信者名を提供する必要があります。通信当事者のプロセスは異なるホストのネットワーク環境で実行され、受信プロセス (またはサーバー側) に属するソケットと送信プロセス (またはクライアント側) に属するソケットのペアが割り当てられます。

一般に、送信プロセスが接続リクエストを送信すると、ランダムにソケットが適用され、ホストはそのポートにポートを割り当て、ソケットにバインドし、他のプロセスには割り当てません。受信プロセスには、グローバルに認識されるソケットと指定されたポートがあり(たとえば、FTP サーバーはポート 21 をリッスンし、Web サーバーはポート 80 をリッスンします)、リスニングポートを介してクライアント要求を待ちます。したがって、どのプロセスも接続要求と情報要求をそれに送信して、プロセス間の通信接続の確立を容易にすることができます。受信プロセスはリクエストを受信すると、送信プロセスからの接続を受け入れて接続を完了します。つまり、ホスト間で送信されたデータが通信プロセスに正確に送信され、プロセス間通信が実現されます。通信が終了すると、システムが受信プロセスを閉じます。ソケットが切断されました。//ソケットの仕組み

ソケットの利点は、同じコンピュータ内のプロセス通信だけでなく、ネットワーク環境内の異なるコンピュータ間のプロセス通信にも適していることです。各ソケットには一意のソケット番号 (ソケット識別子とも呼ばれます) があるため、システム内のすべての接続は、さまざまなアプリケーションプロセスまたはネットワーク接続の通信を簡単に区別できるため、ソケットとポートの接続の一意のペアを保持します。 2 つの通信当事者間の論理リンクの一意性により、データ送信の同時サービスが容易になり、通信機能と実装の詳細が隠蔽され、処理に統一インターフェイスが採用されます。//ソケットを使用する利点

4.2 - リモートプロシージャコールとリモートメソッドコール

RPC (Remote Procedure Call) は、ネットワークを介して接続されたシステムの通信プロトコルです。このプロトコルを使用すると、あるホスト (ローカル) システム上で実行されているプロセスが別のホスト (リモート) システム上のプロセスを呼び出すことができ、プログラマーには追加のプログラミングを行わなくても通常のプロシージャコールのように見えます。関連するソフトウェアがオブジェクト指向プログラミングを使用している場合、リモートプロシージャコールはリモートメソッドコールとも呼ばれます。//リモートプロシージャとリモートメソッド呼び出しは同じものです

リモートプロシージャコールの処理を担当する 2 つのプロセスがあります。1 つはローカルクライアントプロセス、もう 1 つはリモートサーバープロセスです。これら 2 つのプロセスは通常ネットワークデーモンと呼ばれ、主にネットワーク間のメッセージ送信を担当します。両方のプロセスはブロックされています、メッセージを待っています。

リモートプロシージャコールをローカルプロシージャコールと同じように見せるため、つまり、RPC の透過性を実現して、呼び出し元が呼び出しプロセスが他のホストで実行されていると感じないようにするために、RPC はの概念を導入します。スタブ: ローカルクライアント上で独立して実行できる各リモートプロセスには、クライアントスタブ(クライアント頑固) があります。ローカルプロセスがリモートプロセスを呼び出すと、実際にはプロセスに関連付けられたスタブが呼び出されます。同様に、各リモートプロセスが実行されるサーバー側でも同様です。プロセスが特定されます。対応する実際の実行可能プロセスには、それに関連付けられたサーバースタブ(スタブ) もあります。ローカルクライアントスタブと対応するリモートサーバースタブも、通常はブロック状態にあり、メッセージを待っています。//リモートプロシージャコールの原理

上の図に示すように、リモートプロシージャコールの主な手順は次のとおりです。//マイクロサービスの現在の通信基盤

ローカルプロシージャの呼び出し元は、通常の方法でリモートプロシージャにローカルに関連付けられたクライアントスタブを呼び出し、対応するパラメータを渡し、制御をクライアントスタブに渡します。
クライアントスタブが実行され、プロセス名や呼び出しパラメータなどの情報を含むメッセージの確立が完了し、制御権がローカルクライアントプロセスに転送されます。
ローカルクライアントプロセスはサーバーとのメッセージングを完了し、メッセージをリモートサーバープロセスに送信します。
リモートサーバープロセスはメッセージを受信した後に実行に移り、その中のリモートプロセス名に従って対応するサーバースタブを見つけて、そのスタブにメッセージを転送します。
サーバースタブはメッセージを受信すると、ブロッキング状態から実行状態に変化し、メッセージを解凍してプロシージャ呼び出しのパラメーターを抽出し、サーバー上の関連するプロシージャを通常の方法で呼び出します。
サーバー側のリモートプロシージャの実行が完了したら、結果をそれに関連付けられたサーバースタブに返します。
サーバースタブは実行の制御を取得し、結果をメッセージとしてパッケージ化し、リモートサーバープロセスに制御を渡します。
リモートサーバープロセスはメッセージをクライアントに送り返します。
ローカルクライアントプロセスはメッセージを受信すると、プロセス名に従って関連するクライアントスタブにメッセージを保存し、制御をクライアントスタブに渡します。
クライアントスタブはメッセージから結果を取得し、それをローカル呼び出し元プロセスに返し、制御の移行を完了します。

このようにして、ネイティブ呼び出し元は制御を取り戻し、実行を継続するために必要なデータを取得します。明らかに、上記のステップの主な機能は、クライアントプロセスのローカル呼び出しをクライアントスタブに変換し、それからサーバープロセスのローカル呼び出しに変換することです。クライアントとサーバーにとって、それらの中間ステップは表示されません。したがって、プロセス全体の呼び出し元は、プロセスの実行がローカルではなくリモートであることに気づきません。

2. メッセージパッシング通信の実装

プロセス間で通信する場合、ソースプロセスはターゲットプロセスに直接または間接的にメッセージを送信できるため、プロセス通信は直接通信方法と間接通信方法に分けることができます。一般的なダイレクトメッセージングシステムとメールボックス通信では、それぞれこれら 2 つの通信方式が使用されます。

(1) ダイレクトメッセージシステム

ダイレクトメッセージパッシングシステムでは、送信プロセスがOSが提供する送信コマンド（原始言語）を利用して対象プロセスに直接メッセージを送信するダイレクト通信方式が採用されています。

1.1 - 直接通信のプリミティブ

対称アドレッシングモード:このモードでは、送信プロセスと受信プロセスの両方が明示的な方法で相手の識別子を提供する必要があります。一般に、システムは次の 2 つの通信コマンド (プリミティブ) を提供します。

send(receiver，message); 发送一个消息给接收进程
receive(sender，message); 接收Sender发来的消息

たとえば、プリミティブ Send(P2, m1) はメッセージ m1 を受信プロセス P2 に送信することを意味し、プリミティブ Receive(P1, m1) は P1 によって送信されたメッセージ m1 を受信することを意味します。

対称アドレス指定の欠点は、プロセス名を変更すると、他のすべてのプロセスの定義をチェックする必要が生じる場合があり、新しい名前に変更するには、プロセスの古い名前への参照をすべて見つける必要があることです。明らかに、このような方法はプロセス定義のモジュール化には役に立ちません。//プロセス変更の方が面倒

非対称アドレッシングモード:場合によっては、受信プロセスが複数の送信プロセスと通信する必要があり、送信プロセスを事前に指定することができません。たとえば、印刷サービスを提供するために使用されるプロセスは、任意のプロセスから「印刷要求」メッセージを受信できます。このようなアプリケーションの場合、受信プロセスのプリミティブでは、送信プロセスに名前を付ける必要はなくなり、送信元プロセスを表すパラメータ、つまり通信完了後の戻り値を入力するだけで済みます。送信プロセスは受信プロセスに名前を付ける必要があります。

このメソッドの送信および受信プリミティブは次のように表現できます。//受信では送信者のプロセス名を事前に知る必要がなくなりました。

send(P，message); 发送一个消息给进程 P
receive(id,message); 接收来自任何进程的消息，id变量可设置为进行通信的发送方进程id或名字。

1.2 - メッセージの形式

メッセージ配信システムで送信されるメッセージは、特定のメッセージ形式を持つ必要があります。

スタンドアロンシステム環境では、送信プロセスと受信プロセスが同じマシン上にあり、同じ環境にあるため、メッセージのフォーマットは比較的単純であり、比較的短い固定長のメッセージフォーマットを使用してメッセージのメッセージを削減できます。メッセージの処理と保存のオーバーヘッド。この方法をオフィスオートメーションシステムで使用すると、ユーザーにメモ形式の高速コミュニケーションを提供できます。

ただし、固定長メッセージ方式は、より長いメッセージを送信する必要があるユーザーにとっては不便です。この目的のために、可変長メッセージ形式を使用できます。つまり、プロセスによって送信されるメッセージの長さは可変です。可変長メッセージの場合、システムは処理と保存に関してより多くのオーバーヘッドを支払う可能性がありますが、その利点はユーザーにとって使いやすいことです。

1.3 - プロセスの同期方法

プロセス間で通信する場合、プロセス間の通信を調整するためのプロセス同期メカニズムも必要です。送信プロセスであっても受信プロセスであっても、メッセージの送信または受信が終了した後、プロセスは送信 (または受信) を続行するかブロックするかの 2 つの可能性があります。//実行またはブロック

このことから、次の 3 つの状況が考えられます。

送信プロセスはブロックされ、受信プロセスはブロックされます。この状況は主に、送信プロセスと受信プロセスの間にバッファがない場合に、プロセス間の厳密な同期のために使用されます。
送信プロセスはブロックされませんが、受信プロセスはブロックされます。これは、プロセス同期の最も広く使用されている方法です。通常、送信プロセスはブロックされないため、1 つ以上のメッセージをできるだけ早く複数のターゲットに送信できますが、受信プロセスは通常ブロックされた状態にあり、送信プロセスがメッセージを送信するまで起動されません。
送信プロセスも受信プロセスもブロックしません。これは、プロセス同期のより一般的な形式でもあります。通常、送信プロセスと受信プロセスは両方ともそれぞれの業務でビジー状態であり、実行の継続を妨げるイベントが発生した場合にのみ、自身をブロックして待機します。

1.4 - 通信リンク

送信プロセスと受信プロセスの間で通信を行うには、両者の間に通信リンクを確立する必要があります。通信リンクを確立するには 2 つの方法があります。

1 つ目の方法は、送信プロセスが明示的な「接続確立」コマンド (原始言語) を使用して、通信前に通信リンクを確立するようにシステムに要求し、リンクが使い果たされた後にリンクを切断するというものです。この方式は主にコンピュータネットワークで使用されます。//通信網
2 番目の方法は、送信プロセスがリンクの確立を明示的に要求する必要はなく、システムが提供する送信コマンド (原始言語) を使用するだけでよく、システムが自動的にリンクを確立します。この方法は主にスタンドアロンシステムで使用されます。//スタンドアロン

さまざまな通信方法に応じて、リンクは 2 つのタイプに分類できます。

送信プロセスから受信プロセスへのメッセージの送信、またはその逆のみを許可する一方向の通信リンク。
プロセス A がプロセス B にメッセージを送信し、プロセス B がプロセス A にメッセージを同時に送信できるようにする双方向通信リンク。

(2) メールボックス通信

メールボックス通信は間接的な通信方法です。つまり、プロセス間の通信は、何らかの中間エンティティ (共有データ構造など) を介して完了する必要があります。このエンティティはランダムアクセスメモリのパブリックバッファ上に確立され、送信プロセスによってターゲットプロセスに送信されたメッセージを一時的に保存するために使用され、受信プロセスは送信プロセスによって自分自身に送信されたメッセージをこのエンティティから取り出すことができます。この中間エンティティは通常、メールボックス (複数可) と呼ばれ、各メールボックスには一意の識別子があります。メッセージはメールボックスに安全に保管され、承認された対象ユーザーのみがいつでもメッセージを読むことができます。したがって、メールボックス通信方式を用いることで、リアルタイム通信と非リアルタイム通信の両方を実現することができる。// メッセージキュー

2.1 - メールボックスの構造

メールボックスはデータ構造として定義されます。論理的には、次の 2 つの部分に分けることができます。

メールボックスヘッダー: メールボックス ID、メールボックスの所有者、メールボックスのパスワード、メールボックス内のスペースの数など、メールボックスに関する説明情報を保存するために使用されます。
メールボックス本体: メッセージ (またはメッセージヘッダー) を格納できる複数のメールボックスボックスで構成され、メールボックスボックスの数と各ボックスのサイズはメールボックスの作成時に決定されます。

メッセージ配信の観点から見ると、最も単純なケースは一方向の配信です。メッセージ配信は双方向にすることもできます。双方向通信リンクの通信方式を下図に示します。

2.2 - メールボックス通信プリミティブ

システムは、メールボックス通信用のプリミティブをいくつか提供しており、次の用途に使用されます。

メールボックスの作成と削除。プロセスでは、メールボックス作成プリミティブを使用して、新しいメールボックスを作成できます。作成プロセスでは、メールボックス名とメールボックス属性 (パブリック、プライベート、または共有) を指定する必要があります。共有メールボックスの場合は、共有者の名前も指定する必要があります。プロセスがメールボックスを読み取る必要がなくなった場合は、メールボックス取り消しプリミティブを使用して元に戻すことができます。
メッセージの送受信。プロセスが通信にメールボックスを使用する必要がある場合、プロセスは共有メールボックスを使用し、システムによって提供される次の通信プリミティブを使用して通信する必要があります。

Send(mailbox，message)；将一个消息发送到指定邮箱
Receive(mailbox，message)；从指定邮箱中接收一个消息

3.3 - メールボックスの種類

メールボックスはオペレーティングシステムまたはユーザープロセスによって作成でき、作成者がメールボックスの所有者になります。したがって、メールボックスは次の 3 つのカテゴリに分類できます。

私設メールボックス。ユーザープロセスは、プロセスの一部として自分自身用の新しいメールボックスを作成できます。メールボックスの所有者はメールボックスからメッセージを読み取る権利を持ち、他のユーザーは自分が作成したメッセージのみをメールボックスに送信できます。このプライベートメールボックスは、一方向の通信リンクを持つメールボックスを使用して実現できます。メールボックスを所有するプロセスが終了すると、メールボックスも一緒に消えます。//ユーザーの作成
公衆メールボックス。オペレーティングシステムによって作成され、システム内のすべての承認されたプロセスが利用できるようになります。承認プロセスは、このメールボックスにメッセージを送信することも、自分宛てのメッセージをメールボックスから読み取ることもできます。明らかに、パブリックメールボックスは、双方向通信リンクを備えたメールボックスによって実現される必要があります。通常、パブリックメールボックスはシステムの存続期間全体にわたって存在します。// オペレーティングシステムの作成
共有メールボックス。プロセスによって作成され、作成時または作成後に共有可能であることを示し、共有プロセスの名前を示す必要があります。メールボックスの所有者と共有者の両方が、自分に送信されたメッセージをメールボックスから削除する権利を持っています。//ユーザーの作成

メールボックスを使用して通信する場合、送信プロセスと受信プロセスの間には次の 4 つの関係があります。

1対1の関係。送信プロセスと受信プロセスは、この 2 つのプロセス専用の通信リンクを確立できるため、2 つのプロセス間の対話が他のプロセスによって妨げられることはありません。
多対 1 の関係。サービスを提供するプロセスが複数のユーザープロセスと対話できるようにします。これは、クライアント/サーバー対話 (クライアント/サーバー対話) とも呼ばれます。
1 対多の関係。送信プロセスは複数の受信プロセスと対話できるため、送信プロセスはブロードキャストによって受信者 (複数) にメッセージを送信できます。
多対多の関係。パブリックメールボックスを確立して、複数のプロセスがメッセージをメールボックスに投稿したり、メールボックスから独自のメッセージを取得したりすることができます。

3. ダイレクトメッセージシステムの例

メッセージバッファキューの通信メカニズムは、米国の Hansan によって最初に提案され、RC 4000 システムに実装され、その後ローカルプロセス間の通信に広く使用されました。この通信メカニズムでは、送信プロセスは Send プリミティブを使用してメッセージを受信プロセスに直接送信し、受信プロセスは Receive プリミティブを使用してメッセージを受信します。メッセージバッファキューの図:

(1) メッセージバッファキュー通信機構のデータ構造

メッセージバッファ。メッセージバッファキュー通信モードでは、使用される主なデータ構造はメッセージバッファです。それは次のように説明できます。

type struct message_buffer {
    int sender;                         //发送者进程标识符
    int size;                           //消息长度
    char text;                          //消息正文
    struct message buffer next;         //指向下一个消息缓冲区的指针
}

PCB 内の通信に関連するデータ項目。オペレーティングシステムでメッセージバッファキューの通信メカニズムが採用されている場合、プロセスのメッセージバッファキューを設定することに加えて、メッセージキューを操作するには、メッセージキューのキューヘッドポインタをプロセスの PCB に追加する必要があります。同期相互排除セマフォミューテックスとリソースセマフォ sm を実装します。

PCB に追加する必要があるデータ項目は次のように記述できます。

type struct processcontrol_block {
    ...
    struct message_buffer mq;        //消息队列队首指针
    semaphore mutex;                 //消息队列互斥信号量
    semaphore sm;                    //消息队列资源信号量
    ...
} PCB;

(2) 送信プリミティブ

送信プロセスは、送信プリミティブを使用してメッセージを送信する前に、次の図に示すように、まず独自のメモリ空間に送信領域 a を設定し、送信するメッセージテキスト、送信プロセス識別子、メッセージを入力する必要があります。長さとその他の情報を指定してから、send プリミティブを呼び出して、メッセージをターゲットプロセスに送信します。// 送信エリアを設定する

送信プリミティブは、まず送信領域aに設定されたメッセージ長a.sizeに従ってバッファiを申請し、送信領域aの情報をバッファiにコピーします。受信プロセスのメッセージキュー mq に i をハングするには、まず受信プロセスの内部識別子 j を取得してから、i を j.mq にハングする必要があります。このキューは重要なリソースであるため、事前に実行する必要があります。および挿入操作の後、待機およびシグナル操作を実行します。// バッファを申請し、受信プロセスの識別子も取得する必要があります

送信プリミティブは次のように記述できます。

void send(receiver，a) {        //1-发送区：receiver为接收进程标识符，a为发送区首址;

    getbuf(a.size,i);           //2-缓冲区：根据a.size申请缓冲区;

    copy(i.sender，a.sender);   //3-缓冲区复制操作：将发送区a中的信息复制到消息缓冲区i中;
    i.size=a.size;
    copy(i.text，a.text);
    i.next=0;

    getid(PCBset，receiver.j);  //4-获取接收者标识：获得接收进程内部的标识符;

    wait(j.mutex);
    insert(&j.mq，i);           //5-消息插入：将消息缓冲区插入接受进程的消息队列;
    signal(j.mutex);

    signal(j.sm);               //6-唤醒数据消费：资源信号量+1
}

(3) 受信プリミティブ

受信プロセスは受信プリミティブ accept(b) を呼び出し、自身のメッセージバッファキュー mq から最初のメッセージバッファ i を取り出し、その中のデータを b から始まる指定されたメッセージ受信領域にコピーします。受信プリミティブは次のように説明されます。

void receive(b) {
    j = internal name;          //j为接收进程内部的标识符;

    wait(j.sm);                 //如果资源为空，此时将阻塞

    wait(j.mutex);              //使用同步原语操作j.mq
    remove(j.mq, i);            //将消息队列中第一个消息移出;
    signal(j.mutex);

    copy(b.sender, i.sender);   //缓冲区->接收区，将消息缓冲区i中的信息复制到接收区b:
    b.size =i.size;
    copy(b.text, i.text);
    releasebuf(i);              //释放消息缓冲区;
}

ここまでで全文は終わりです。愛があるから最後まで技術を貫いてください。