JP2888420B2 - マルチタスク・アーキテクチャにおけるプロセス間通信方法 - Google Patents

マルチタスク・アーキテクチャにおけるプロセス間通信方法

Info

Publication number
JP2888420B2
JP2888420B2 JP7154172A JP15417295A JP2888420B2 JP 2888420 B2 JP2888420 B2 JP 2888420B2 JP 7154172 A JP7154172 A JP 7154172A JP 15417295 A JP15417295 A JP 15417295A JP 2888420 B2 JP2888420 B2 JP 2888420B2
Authority
JP
Japan
Prior art keywords
message
port
server
task
thread
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP7154172A
Other languages
English (en)
Other versions
JPH0816411A (ja
Inventor
アズィーザ・ブシュラ・ファルーキー
ジョーゼフ・ウィリアム・グリーン
ジェームズ・マイケル・マジー
クリストファー・ディーン・ヤングワース
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JPH0816411A publication Critical patent/JPH0816411A/ja
Application granted granted Critical
Publication of JP2888420B2 publication Critical patent/JP2888420B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本明細書に開示する本発明は、一
般にデータ処理システムに関し、より具体的にはデータ
処理システム用のオペレーティング・システムの改良に
関する。
【０００２】ここに開示する本発明は、本出願と同日に
出願され、本出願人に譲渡され、参照により本発明の一
部となる、ガイ・ジー・ソトマイヤー（Guy G. Sotomay
or）Jr.、ジェームス・エム・マジー（James M. Mage
e）、およびフリーマン・エル・ローソン（Freeman L.
Rawson）IIIによる"METHOD AND APPARATUS FOR MANAGEM
ENT OF MAPPED AND UNMAPPED REGIONS OF MEMORY IN A
MICROKERNEL DATA PROCESSING SYSTEM"という名称の関
連米国特許出願第２６３７１０号（ＩＢＭ整理番号BC9-
94-053）に関連するものである。
【０００３】ここに開示する本発明は、本出願と同日に
出願され、本出願人に譲渡され、参照により本発明の一
部となるジェームズ・エム・マジー（James M. Magee）
他による"CAPABILITY ENGINE METHOD AND APPARATUS FO
R A MICROKERNEL DATA PROCESSING SYSTEM"という名称
の関連米国特許出願第２６３３１３号（ＩＢＭ整理番号
BC9-94-071）にも関連するものである。
【０００４】ここに開示する本発明は、本出願と同日に
出願され、本出願人に譲渡され、参照により本発明の一
部となる、ジェームズ・エム・マジー他の"TEMPORARY D
ATAMETHOD AND APPARATUS FOR A MICROKERNEL DATA PRO
CESSING SYSTEM"という名称の関連米国特許出願第２６
３３１３号（ＩＢＭ整理番号BC9-94-076）にも関連する
ものである。
【０００５】ここに開示されている本発明は、本出願と
同日に出願され、本出願人に譲渡され、参照により本発
明の一部となる、ジェームズ・エム・マジー（James M.
Magee）他の"MESSAGE CONTROL STRUCTURE REGISTRATIO
N METHOD AND APPARATUS FORA MICROKERNEL DATA PROCE
SSING SYSTEM"という名称の関連米国特許出願第２６３
７０３号（ＩＢＭ整理番号BC9-94-077）にも関連するも
のである。
【０００６】
【従来の技術】オペレーティング・システムは、コンピ
ュータ上で実行される最も重要なソフトウェアである。
すべての汎用コンピュータは、他のプログラムを実行す
るためのオペレーティング・システムを備えていなけれ
ばならない。通常、オペレーティング・システムは、キ
ーボードからの入力の認識、表示画面への出力の送出、
ディスク上のファイルおよびディレクトリの追跡、ディ
スク・ドライブおよびプリンタなどの周辺装置の制御の
ような基本的なタスクを実行する。より複雑なシステム
では、オペレーティング・システムの責任と能力がかな
り大きくなる。それにより、同時に動作する様々なプロ
グラムやユーザが互いに干渉しないことが重要になる。
また、一般にオペレーティング・システムは、セキュリ
ティも担当し、無許可ユーザがシステムにアクセスでき
ないようにする。
【０００７】オペレーティング・システムは、マルチユ
ーザ・オペレーティング・システム、マルチプロセッサ
・オペレーティング・システム、マルチタスク・オペレ
ーティング・システム、およびリアルタイム・オペレー
ティング・システムに分類することができる。マルチユ
ーザ・オペレーティング・システムとは、２人またはそ
れ以上のユーザが同時にプログラムを実行できるように
するものである。オペレーティング・システムによって
は、数百人または数千人のユーザによる同時実行が可能
なものもある。マルチプロセッシング・プログラムと
は、単一ユーザが２つまたはそれ以上のプログラムを同
時に実行できるようにするものである。この場合、実行
される各プログラムはプロセスと呼ばれる。ほとんどの
マルチプロセッシング・システムは複数のユーザをサポ
ートしている。マルチタスク・システムとは、単一プロ
セスが複数のタスクを実行できるようにするものであ
る。マルチタスクとマルチプロセッシングという用語は
意味がいくらか異なるが、一般的な用法では交換可能な
ものとして使用される場合が多い。マルチタスクとは、
複数のタスクを同時に実行できる能力であり、タスクと
はプログラムである。マルチタスクでは、１つの中央演
算処理装置（ＣＰＵ）だけが関与するが、プログラム間
の切替えを非常に迅速に行うため、すべてのプログラム
を同時に実行しているように見えるのである。マルチタ
スクには、プリエンプティブと協調方式の２通りの基本
タイプがある。プリエンプティブ・マルチタスクでは、
オペレーティング・システムが各プログラムにＣＰＵの
タイム・スライスを分配する。協調マルチタスクでは、
各プログラムは、ＣＰＵを必要とする間、ＣＰＵを制御
することができる。ただし、プログラムがＣＰＵを使用
していない場合、別のプログラムが一時的にＣＰＵを使
用できるようにすることも可能である。たとえば、ＯＳ
／２（登録商標）およびＵＮＩＸ（登録商標）はプリエ
ンプティブ・マルチタスク・オペレーティング・システ
ムであるが、マッキントッシュ（登録商標）のコンピュ
ータ用のMulti-Finder（登録商標）は協調マルチタスク
・オペレーティング・システムである。マルチプロセッ
シングとは、コンピュータ・システムが複数のプロセス
またはプログラムを同時にサポートできる能力を指す。
したがって、マルチプロセッシング・オペレーティング
・システムを使用すると、同時に複数のプログラムを実
行することができる。マルチプロセッシング・システム
では、オペレーティング・システムが競合プロセスに資
源を合理的に割り振らなければならないので、単一プロ
セス・システムよりかなり複雑になる。リアルタイム・
オペレーティング・システムは、入力に対して瞬時に応
答する。ＤＯＳ（登録商標）およびＵＮＩＸ（登録商
標）などの汎用オペレーティング・システムはリアルタ
イムではない。
【０００８】オペレーティング・システムは、その上で
アプリケーション・プログラムを実行することができる
ソフトウェア・プラットフォームを提供する。アプリケ
ーション・プログラムは、特定のオペレーティング・シ
ステム上で実行するように明確に作成しなければならな
い。したがって、オペレーティング・システムの選択に
よって、実行可能なアプリケーションがほとんど決まっ
てしまう。ＩＢＭ互換のパーソナル・コンピュータ用の
オペレーティング・システムの例としては、ＤＯＳ（登
録商標）、ＯＳ／２（登録商標）、ＡＩＸ（登録商
標）、ＸＥＮＩＸ（登録商標）などがある。
【０００９】通常、ユーザは、１組のコマンドによって
オペレーティング・システムと対話する。たとえば、Ｄ
ＯＳオペレーティング・システムには、ファイルをコピ
ーするためのＣＯＰＹやファイル名を変更するためのＲ
ＥＮＡＭＥなどのコマンドが含まれている。これらのコ
マンドは、コマンド・プロセッサまたはコマンド・イン
タプリタと呼ばれるオペレーティング・システムの一部
によって受け入れられ、実行される。
【００１０】パーソナル・コンピュータ用としては、Ｃ
Ｐ／Ｍ（登録商標）、ＤＯＳ（登録商標）、ＯＳ／２
（登録商標）、ＵＮＩＸ（登録商標）、ＸＥＮＩＸ（登
録商標）、ＡＩＸ（登録商標）など、様々なオペレーテ
ィング・システムが数多く存在する。ＣＰ／Ｍは小型コ
ンピュータ用の最初のオペレーティング・システムの１
つである。当初、ＣＰ／Ｍは広範囲のパーソナル・コン
ピュータ上で使用されていたが、結局、ＤＯＳによって
影が薄くなってしまった。ＤＯＳは、すべてのＩＢＭ互
換パーソナル・コンピュータ上で実行され、単一ユーザ
単一タスク・オペレーティング・システムである。ＤＯ
Ｓの後継オペレーティング・システムであるＯＳ／２
は、Ｉｎｔｅｌ８０２８６以降のマイクロプロセッサを
使用するＩＢＭ互換パーソナル・コンピュータ上で実行
される比較的強力なオペレーティング・システムであ
る。一般に、ＯＳ／２は、ＤＯＳとの互換性があるが、
多くの追加機能を含んでおり、たとえば、マルチタスク
であり、仮想メモリをサポートしている。ＵＮＩＸおよ
びＵＮＩＸ対応ＡＩＸは、広範囲のパーソナル・コンピ
ュータおよびワークステーション上で動作する。ＵＮＩ
ＸおよびＡＩＸは、すでにワークステーション用の標準
オペレーティング・システムになっており、強力なマル
チユーザ・マルチプロセッシング・オペレーティング・
システムである。
【００１１】ＩＢＭのパーソナル・コンピュータが米国
で発売された１９８１年に、ＤＯＳは約１０キロバイト
の記憶域を占有していた。その時以降、パーソナル・コ
ンピュータはますます複雑になり、大規模なオペレーテ
ィング・システムを必要とするようになった。現在で
は、たとえば、ＩＢＭのパーソナル・コンピュータ用の
ＯＳ／２は、２２メガバイトもの記憶域を占有する場合
もある。時間の経過とともにパーソナル・コンピュータ
はさらに複雑かつ強力になっているが、システムに関連
する記憶装置に記憶容量の点で多大なペナルティを課さ
ずにオペレーティング・システムが引き続きサイズと複
雑さを拡大することができないことは明らかである。
【００１２】１９８０年代にカーネギー・メロン大学で
ＭＡＣＨプロジェクトが行われたのは、オペレーティン
グ・システムのサイズの成長率がこのように維持できな
くなったためである。この研究の目標は、コンピュータ
・プログラマが最新のハードウェア・アーキテクチャの
出現を利用しながら、カーネル・オペレーティング・シ
ステムの諸機能のサイズと数を低減できるような、新し
いオペレーティング・システムを開発することであっ
た。カーネルとは、ハードウェア資源の割振りなどの基
本機能を実行するオペレーティング・システムの一部で
ある。ＭＡＣＨカーネルの場合、システム用の基本ビル
ディング・ブロックとして、５つのプログラミング・ア
ブストラクション（Programming abstraction）が確立
された。これらは、その上で典型的な複合操作をカーネ
ル外部に構築することができる有用なシステムを作成す
るのに必要な最小限のものとして選択された。カーネギ
ー・メロンのＭＡＣＨカーネルは、そのリリース３．０
でサイズが低減され、ＭＡＣＨマイクロカーネルという
完全機能オペレーティング・システムになっている。Ｍ
ＡＣＨマイクロカーネルは、タスク、スレッド、ポー
ト、メッセージ、およびメモリ・オブジェクトという基
本要素を有する。
【００１３】タスクは、ＭＡＣＨマイクロカーネル内の
２つの個別構成要素に分割された従来のＵＮＩＸプロセ
スである。第１の構成要素はタスクであり、第１群の協
調エンティティ用のすべての資源を含んでいる。タスク
内の資源の例は、仮想メモリと通信ポートである。タス
クは、資源の受動的集合体なので、プロセッサ上では動
作しない。
【００１４】スレッドは、ＵＮＩＸプロセスの第２の構
成要素であり、能動的実行環境である。各タスクは、ス
レッドと呼ばれる１つまたは複数の同時実行計算をサポ
ートすることができる。たとえば、マルチスレッド・プ
ログラムでは、１つのスレッドを使用して科学計算を実
行し、別のスレッドでユーザ・インタフェースを監視す
ることができる。１つのＭＡＣＨタスクが、すべて同時
に実行される数多くの実行スレッドを有する場合もあ
る。ＭＡＣＨプログラミング・モデルの能力の多くは、
１つのタスク内のすべてのスレッドがそのタスクの資源
を共用するという事実に由来する。たとえば、すべての
スレッドは同一の仮想メモリ（ＶＭ）アドレス空間を有
する。しかし、タスク内の各スレッドはそれ専用の私用
実行状態を有する。この状態は、汎用レジスタなどの１
組のレジスタと、スタック・ポインタと、プログラム・
カウンタと、フレーム・ポインタとで構成される。
【００１５】ポートは、スレッド同士が互いに通信する
際に使用する通信チャネルである。ポートは１つの資源
であり、タスクによって所有される。スレッドは、タス
クに属すことによってポートへのアクセスが可能にな
る。協調プログラムを使用すると、１つのタスクからの
スレッドが別のタスクのポートにアクセスできる場合も
ある。重要な特徴は、それらがロケーション透過性であ
る点である。この機能により、プログラムを修正せずに
ネットワークによるサービスの分散が容易になる。
【００１６】メッセージは、各種のタスク内のスレッド
が互いに通信できるようにするためのものである。１つ
のメッセージには、クラスまたはタイプが与えられたデ
ータの集合体が含まれている。このデータは、数値また
はストリングなどのプログラム固有データから、あるタ
スクから別のタスクへのポートの転送能力などのＭＡＣ
Ｈ関連データにまで及ぶ可能性がある。
【００１７】メモリ・オブジェクトは、ユーザ・レベル
のプログラムに含まれる従来のオペレーティング・シス
テム機能を実行する能力をサポートするためのアブスト
ラクションであり、ＭＡＣＨマイクロカーネルの重要な
特徴の１つである。たとえば、ＭＡＣＨマイクロカーネ
ルは、ユーザ・レベル・プログラム内の仮想メモリ・ペ
ージング方式をサポートしている。メモリ・オブジェク
トとは、この能力をサポートするためのアブストラクシ
ョンである。
【００１８】上記の各種概念はいずれもＭＡＣＨマイク
ロカーネルのプログラミング・モデルにとって基本的な
ものであり、カーネル自体で使用されるものである。カ
ーネギー・メロン大学のＭＡＣＨマイクロカーネルの上
記の概念およびその他の特徴については、ジョーゼフ・
ボイキン（Joseph Boykin）他著"Programming UnderMAC
H"（Addison Wessely Publishing Company, Incorporat
ed, 1993）に記載されている。
【００１９】ＵＮＩＸパーソナリティをサポートするた
めのマイクロカーネルの使用についての詳しい考察は、
マイク・アセッタ（Mike Accetta）他の論文"MACH: A N
ew Kernel Foundation for UNIX Development"（Procee
dings of the Summer 1986 USENIX Conference, Atlant
a, Georgia）に記載されている。また、この主題に関す
るもう１つの技術論文としては、デーヴィッド・ゴルブ
（David Golub）他の"UNIX as an Application Progra
m"（Proceedings of the Summer 1990 USENIX Conferen
ce, Anaheim, California）がある。
【００２０】ガイ・ジー・ソトマイヤー他による前述の
関連特許出願には、図１に示すマイクロカーネル・シス
テム１１５が記載されているが、これはオペレーティン
グ・システムの新しい基礎である。マイクロカーネル・
システム１１５は、純粋カーネルとして実施されたカー
ネル・サービスの簡略セットと、１組のユーザレベル・
サーバとして実施されたオペレーティング・システム・
パーソナリティを構築するためのサービスの拡張セット
とを提供する。マイクロカーネル・システム１１５は、
様々な従来のオペレーティング・システム機能を提供
し、オペレーティング・システム・パーソナリティとし
て明示された、多くのサーバ構成要素で構成されてい
る。マイクロカーネル・システム１１５では、タスク
（クライアント）が通信チャネルを介して送られるメッ
セージによって他のタスク（サーバ）の要求を行うこと
によりサービスにアクセスする、クライアント／サーバ
・システム構造を使用する。マイクロカーネル１２０が
提供するそれ専用のサービスは非常に少ない（たとえ
ば、ファイル・サービスは一切提供しない）ので、マイ
クロカーネル１２０のタスクは、必要なサービスを提供
する他の多くのタスクと通信しなければならない。この
ため、システム内の多くのクライアントとサーバとの間
で行わなければならないプロセス間通信をいかに高速か
つ効率よく管理するかについて問題が発生する。
【００２１】
【発明が解決しようとする課題】したがって、本発明の
一目的は、データ処理システム用の改良されたマイクロ
カーネル・アーキテクチャを提供することにある。
【００２２】本発明の他の目的は、先行技術で可能だっ
たものに比べ、そのプロセス間通信操作がさらに簡略化
された、データ処理システム用の改良されたマイクロカ
ーネル・アーキテクチャを提供することにある。
【００２３】本発明の他の目的は、より高速でより効率
の良いプロセス間通信機能を有する、データ処理システ
ム用の改良されたマイクロカーネル・アーキテクチャを
提供することにある。
【００２４】
【００２５】
【課題を解決するための手段】上記およびその他の目
的、特徴、および利点は、本明細書に開示されたマイク
ロカーネル・データ処理システム用の無名応答ポートの
方法および装置によって達成される。
【００２６】プロセス間通信（ＩＰＣ）データ・タイプ
・メッセージは、媒介物としてプロセス間通信サブシス
テムを使用する、クライアントである送信側タスクとサ
ーバである宛先タスクとの間の単方向メッセージであ
る。クライアントである送信側タスクがサーバである宛
先タスクに転送するためにプロセス間通信サブシステム
にＩＰＣデータ・タイプ・メッセージを送信してしまう
と、クライアントである送信側タスクは、追加メッセー
ジの送信を待ち受けたり、そのスレッドの媒介により他
の動作に従事したりする必要がない。
【００２７】遠隔プロシージャ呼出し（ＲＰＣ）データ
・タイプ・メッセージは、媒介物としてプロセス間通信
サブシステムを使用する、クライアントである送信側タ
スクとサーバである宛先タスクとの間の双方向メッセー
ジである。クライアントである送信側タスクがサーバで
ある宛先タスクに転送するためにプロセス間通信サブシ
ステムにＲＰＣデータ・タイプ・メッセージを送信した
後、クライアントである送信側タスクは、サーバである
宛先タスクがそのメッセージに応答するまで待たなけれ
ばならない。クライアントである送信側タスクは、サー
バである宛先タスクからの応答を待っている間、どのタ
スクに対しても他のメッセージを自由に送信することは
できない。
【００２８】この問題は、プロセス間通信サブシステム
に無名応答ポート機構を設けることによって、本発明に
より解決される。クライアントである送信側タスクは、
その双方向メッセージを送信／受信メッセージとして公
式化（形式化）することができる。送信／受信メッセー
ジは、サーバである宛先タスクと応答ポートのアイデン
ティティとを指名するフィールドを含んでいる。本発明
によれば、クライアントである送信側タスクは、無名応
答ポートをサーバである宛先タスクからの応答のための
指定ポートとして受け入れることを示す指示を、応答ポ
ート・フィールドに入れる。この指定により、プロセス
間通信サブシステムは、サーバである宛先タスクから見
たときに、メッセージの見かけ上のセンダーになる。ク
ライアントである送信側タスクは、双方向メッセージの
送信に対する応答としてサーバである宛先タスクからの
応答を待つ必要がなくなる。
【００２９】プロセス間通信サブシステムは、クライア
ントである送信側タスクからメッセージを受け取ると、
代用メッセージを公式化する。プロセス間通信サブシス
テムは、無名応答ポートのテーブルに項目を作成し、セ
ンダーのメッセージと宛先の応答によって表される双方
向トランザクションにトランザクション名を割り当て
る。このテーブル項目は、クライアントである送信側タ
スクのポートの名前も含んでいるが、任意でサーバであ
る宛先タスクのポートの名前を含むこともできる。本発
明によれば、次にプロセス間通信サブシステムは、応答
ポートを識別する代用メッセージのフィールドにトラン
ザクション名を入れる。その後、代用メッセージは、プ
ロセス間通信サブシステムによってサーバである宛先タ
スクのポートに転送される。
【００３０】クライアントである送信側タスクがサーバ
である宛先タスクからの応答を待っている間、クライア
ントである送信側タスクは、他のメッセージを送受信し
たり、そのスレッドで他の動作を実行することができ
る。
【００３１】サーバである宛先タスクは、応答メッセー
ジを送信する準備ができると、そのトランザクション名
を応答メッセージの宛先として識別する。応答メッセー
ジは、単方向メッセージであり、プロセス間通信サブシ
ステムによって受信される。トランザクション名を応答
メッセージの宛先として識別したことに対する応答とし
て、プロセス間通信サブシステムは応答メッセージを無
名応答ポートに渡し、この無名応答ポートがそのテーブ
ル内のトランザクション名を探索し、元のクライアント
である送信側タスクのポートの名前を返す。次にプロセ
ス間通信サブシステムは、代用応答メッセージを公式化
し、それに宛先として元のクライアントである送信側タ
スクのポート名を入れる。次にプロセス間通信サブシス
テムは、元のクライアントである送信側タスクに代用応
答メッセージを転送する。このようにして、元のクライ
アントである送信側タスクは双方向通信を完了し、応答
を待つ間にアイドル状態を維持する必要がない。
【００３２】クライアント・タスクまたはサーバ・タス
クあるいはその両方は、アプリケーション・プログラ
ム、オペレーティング・システム・パーソナリティ・プ
ログラム、パーソナリティ・ニュートラル・サービス・
プログラム、またはマイクロカーネル自体の一部にする
ことができる。上記の各タイプのプログラムには、その
プログラムの目的を実行するためのタスクとそのスレッ
ドを作成しなければならない。このようなタスクは、マ
イクロカーネル・システムで並行実行される他のタスク
と通信しなければならない。このようなタスクは、ホス
ト・マルチプロセッサ内の他のアプリケーション・プロ
グラムで並行実行される他のタスクと通信しなければな
らない。さらに、このようなタスクは、分散処理ネット
ワーク内の各種ホスト・マルチプロセッサ・システム上
で並行実行される他のタスクとも通信しなければならな
い。このようなタスクの１つから別のタスクへの各通信
は、本発明による制御登録によって提供される効率を利
用することができる。
【００３３】このようにして、本発明は、マイクロカー
ネル・システム内の多くのクライアントとサーバとの間
で行わなければならないプロセス間通信を高速かつ効率
よく管理する。本発明は、ユニプロセッサ、共用メモリ
・マルチプロセッサ、および分散プロセッサ・システム
内の複数のコンピュータに適用される。
【００３４】上記およびその他の目的および利点は、添
付図面を参照すればさらに十分理解されるはずである。
【００３５】
【実施例】
第Ａ部 マイクロカーネル・システム 第１節 マイクロカーネルの原理 図１は、マイクロカーネル・システム１１５の機能ブロ
ック図であり、マイクロカーネル１２０およびパーソナ
リティ・ニュートラル・サービス１４０が様々なハード
ウェア・プラットフォームで複数のオペレーティング・
システム・パーソナリティ１５０を実行する方法を示す
図である。
【００３６】図１に示すホスト・マルチプロセッサ１０
０は、バス１０４によって補助記憶装置１０６に接続さ
れたメモリ１０２を含み、補助記憶装置１０６は、たと
えば、ディスク・ドライブの場合もあれば、読取り専用
または読取り書込み光ディスク記憶装置、またはその他
の大容量記憶装置の場合もある。バス１０４には入出力
アダプタ１０８も接続され、入出力アダプタ１０８は、
キーボード、モニタ・ディスプレイ、通信アダプタ、ロ
ーカル・エリア・ネットワーク・アダプタ、モデム、マ
ルチメディア・インタフェース装置、またはその他の入
出力装置に接続することもできる。また、バス１０４に
は、第１のプロセッサＡ１１０と第２のプロセッサＢ１
１２も接続されている。図１に示す例は、対称的なマル
チプロセッサ構成の例であり、２つのユニプロセッサ１
１０および１１２が共通メモリ・アドレス空間１０２を
共用している。同様に適切な例として、単一プロセッサ
または複数プロセッサによる他の構成を示すことも可能
である。プロセッサは、たとえば、Ｉｎｔｅｌ３８６
（登録商標）ＣＰＵ、Ｉｎｔｅｌ４８６（登録商標）Ｃ
ＰＵ、Ｐｅｎｔｉｕｍ（登録商標）プロセッサ、Ｐｏｗ
ｅｒＰＣ（登録商標）プロセッサ、またはその他のユニ
プロセッサ・デバイスにすることができる。
【００３７】メモリ１０２はそこに格納されたマイクロ
カーネル・システム１１５を含み、マイクロカーネル・
システム１１５は、マイクロカーネル１２０と、パーソ
ナリティ・ニュートラル・サービス（ＰＮＳ）１４０
と、パーソナリティ・サーバ１５０とを含んでいる。マ
イクロカーネル・システム１１５は、メモリ１０２に格
納されているアプリケーション・プログラム１８０用の
オペレーティング・システムとして機能する。
【００３８】本発明の一目的は、ＵＮＩＸまたはＯＳ／
２のような従来のオペレーティング・システムのように
動作するオペレーティング・システムを提供することに
ある。すなわち、このオペレーティング・システムは、
ＯＳ／２またはＵＮＩＸ、あるいはその他の従来のオペ
レーティング・システムのパーソナリティを有するもの
になる。
【００３９】マイクロカーネル１２０には、ホスト・マ
ルチプロセッサ１００の最優先状態で実行されるシステ
ム・ソフトウェアの一部であってマシンの基本動作を制
御する小さいメッセージ引渡し核が収容されている。マ
イクロカーネル・システム１１５は、マイクロカーネル
１２０と、パーソナリティ・ニュートラル・サービス１
４０を提供する１組のサーバおよびデバイス・ドライバ
とを含んでいる。名前が示唆するように、パーソナリテ
ィ・ニュートラル・サーバ（Personality Neutral Serv
er）およびデバイス・ドライバは、ＵＮＩＸまたはＯＳ
／２のようないかなるパーソナリティにも依存していな
い。これらはマイクロカーネル１２０に依存し、相互に
依存する。パーソナリティ・サーバ１５０は、マイクロ
カーネル１２０のメッセージ引渡しサービスを使用して
パーソナリティ・ニュートラル・サービス１４０とやり
とりする。たとえば、ＵＮＩＸ、ＯＳ／２、または他の
パーソナリティ・サーバは、パーソナリティ・ニュート
ラル・ディスク・ドライバにメッセージを送信し、１ブ
ロック分のデータをディスクから読み取るようそれに指
示することができる。ディスク・ドライバはそのブロッ
クを読み取って、それをメッセージに入れて返す。メッ
セージ・システムは、ポインタを操作することによって
大量のデータが迅速に転送されるように最適化されてい
るので、データそのものはコピーされない。
【００４０】マイクロカーネル１２０は、そのサイズ
と、アプリケーション・プログラムとして標準的なプロ
グラミング・サービスおよび機能をサポートできる能力
とにより、標準的なオペレーティング・システムより単
純になっている。マイクロカーネル・システム１１５
は、様々に構成される複数のモジュールに分解され、小
規模なシステムにそのモジュールを追加することによっ
てより大規模なシステムを構築できるようになってい
る。たとえば、各パーソナリティ・ニュートラル・サー
バ１４０は、論理的には別個のものなので、様々な構成
が可能である。各サーバは、アプリケーション・プログ
ラムとして動作し、アプリケーション・デバッガを使用
してデバッグすることができる。また、各サーバは個別
のタスクで動作し、サーバのエラーはそのタスクに閉じ
込められる。
【００４１】図１は、プロセス間通信モジュール（ＩＰ
Ｃ）１２２と、仮想メモリ・モジュール１２４と、タス
クおよびスレッド・モジュール１２６と、ホストおよび
プロセッサ・セット１２８と、入出力サポートおよび割
込み１３０と、マシン依存コード１２５とを含むマイク
ロカーネル１２０を示している。
【００４２】図１に示すパーソナリティ・ニュートラル
・サービス１４０は、マスタ・サーバと、初期設定と、
命名とを含む、複数パーソナリティ・サポート１４２を
含んでいる。サービス１４０はデフォルト・ページャ１
４４も含んでいる。また、サービス１４０は、複数パー
ソナリティ・サポートとデバイス・ドライバとを含む、
デバイス・サポート１４６も含んでいる。さらに、サー
ビス１４０は、ファイル・サーバと、ネットワーク・サ
ービスと、データベース・エンジンと、セキュリティと
を含む、その他のパーソナリティ・ニュートラル・プロ
ダクト１４８も含んでいる。
【００４３】パーソナリティ・サーバ１５０は、たとえ
ば、ＵＮＩＸパーソナリティなどにすることが可能な主
要パーソナリティ１５２である。このサーバは、ＵＮＩ
Ｘサーバであるはずの主要パーソナリティ・サーバ１５
４と、ＵＮＩＸ主要パーソナリティをサポートするはず
の他の主要パーソナリティ・サービス１５５とを含んで
いる。また、代替主要パーソナリティ１５６は、ＯＳ／
２などにすることができる。この代替パーソナリティ１
５６には、ＯＳ／２パーソナリティの特徴となるはずの
代替パーソナリティ・サーバ１５８と、ＯＳ／２用の他
の代替パーソナリティ・サービス１５９とが含まれてい
る。
【００４４】ＵＮＩＸ主要パーソナリティの例に関連し
て図１に示されている主要パーソナリティ・アプリケー
ション１８２は、ＵＮＩＸオペレーティング・システム
・パーソナリティ１５２上で動作するはずのＵＮＩＸタ
イプのアプリケーションである。図１に示す代替パーソ
ナリティ・アプリケーション１８６は、ＯＳ／２代替パ
ーソナリティ・オペレーティング・システム１５６上で
動作するＯＳ／２アプリケーションである。
【００４５】図１は、マイクロカーネル・システム１１
５によって、その実施態様が、プロセッサ・タイプごと
に完全に移植可能なコードと、それが実行される特定の
マシンのプロセッサのタイプに依存するコードとに慎重
に分割されていることを示している。また、このシステ
ムは、デバイスに依存するコードをデバイス・ドライバ
に分離しているが、デバイス・ドライバ・コードは、デ
バイスに依存しているものの、必ずしもプロセッサ・ア
ーキテクチャに依存しているわけではない。タスク当た
り複数のスレッドを使用すると、特定のマシンをマルチ
プロセッサにせずにマルチプロセッサの使用が可能にな
るようなアプリケーション環境が提供される。ユニプロ
セッサでは、各種のスレッドが様々な時期に実行され
る。複数プロセッサに必要なすべてのサポートがこの小
さく単純なマイクロカーネル１２０に凝集されている。
【００４６】この項では、マイクロカーネル・システム
１１５の構造の概要を示す。以降では、この構造の各構
成要素について詳しく説明し、マイクロカーネル・シス
テム１１５の各種サービスを使用して新しいプログラム
を構築するのに必要な技術について説明する。
【００４７】マイクロカーネル・システム１１５は、オ
ペレーティング・システム用の新しい基礎である。これ
は、オペレーティング・システム開発のための総合環境
に以下の特徴を提供するものである。 複数パーソナリティのサポート 拡張可能なメモリ管理 プロセス間通信 マルチスレッド マルチプロセッシング
【００４８】マイクロカーネル・システム１１５は、純
粋カーネルとして実施されたカーネル・サービスの簡略
セットと、１組のユーザレベル・サーバとして実施され
た、オペレーティング・システム・パーソナリティ構築
用のサービスの拡張セットとを提供する。
【００４９】マイクロカーネル・システム１１５の目的
には、以下のことが含まれる。 複数のオペレーティング・システム・パーソナリティが
協調して機能できるようにすること デバイス・ドライバおよびファイル・システムなどの低
レベル・システム要素用の共通プログラミングを提供す
ること オペレーティング・システムとユーザ・アプリケーショ
ンの両方で並行処理を利用すること 散在している可能性のある大きいアドレス空間をフレキ
シブルなメモリ共用でサポートすること 透過ネットワーク資源アクセスを可能にすること ＯＳ／２およびＵＮＩＸなどの既存のソフトウェア環境
との互換性を維持すること 移植性（３２ビットおよび６４ビット・プラットフォー
ムへの）
【００５０】マイクロカーネル・システム１１５は、以
下の概念を基礎とする。 多くの従来のオペレーティング・システム機能（たとえ
ば、ファイル・システムおよびネットワーク・アクセ
ス）を実行するユーザ・モード・タスク オペレーティング・システムを作成するためのユーザレ
ベルの実行時サービスの基本セット 単純かつ拡張可能な通信カーネル オブジェクト参照としての通信チャネルを備えたオブジ
ェクト基盤 同期および非同期プロセス間通信を使用するクライアン
ト／サーバ・プログラミング・モデル
【００５１】マイクロカーネル・システム１１５の基礎
は、単純かつ拡張可能な通信カーネルを提供することで
ある。また、マイクロカーネル・システム１１５の目的
の１つは、適正カーネルの最小限の機能によりユーザ空
間またはカーネル空間のいずれかでサービスのフレキシ
ブルな構成を可能にすることである。カーネルは、タス
ク間通信の他に、以下のものを含むサポートを提供しな
ければならない。 制御点の管理（スレッド） 資源割当て（タスク） タスク用のアドレス空間のサポート 物理メモリ、プロセッサ、割込み、ＤＭＡチャネル、ク
ロックなどの物理資源の管理
【００５２】ユーザ・モード・タスクは、資源の使用法
に関する各種方針を実現する。カーネルは、このような
方針を実施するための機構を提供するにすぎない。論理
的には、カーネルの上にパーソナリティ・ニュートラル
・サービス１４０（ＰＮＳ）層が存在する。ＰＮＳは、
ストリング機能などの基本構造体を含むＣ実行時環境
と、以下のものを含む１組のサーバとを提供する。 名前サーバ ― クライアントがサーバを見つけられる
ようにする マスタ・サーバ ― プログラムのロードおよび始動を
可能にする
【００５３】カーネル・アブストラクション マイクロカーネル・システム１１５の目標の１つは、カ
ーネル自体によって提供されるアブストラクションを最
小限にすることであって、このようなアブストラクショ
ンに関連するセマンティクスの点で最小にすることでは
ない。提供されるアブストラクションのそれぞれは、そ
れに関連する１組のセマンティクスと、残りのアブスト
ラクションとの対話の複合セットとを有する。このた
め、重要な考え方の識別が困難になる場合もある。主な
カーネル・アブストラクションは、以下の通りである。 タスク ― 資源割振り、大きいアクセス空間、および
ポート権の単位 スレッド ― 軽量（低オーバヘッド）のＣＰＵ使用状
況の単位 ポート ― 送信／受信ケイパビリティまたは権利によ
ってのみアクセス可能な通信チャネル メッセージ ― データ・オブジェクトの集合 メモリ・オブジェクト ― メモリ管理の内部単位 （タスク、スレッド、ポート、メッセージ、およびメモ
リ・オブジェクトの各概念の詳細については、第２節
「アーキテクチャ・モデル」を参照されたい。）
【００５４】タスクおよびスレッド マイクロカーネル・システム１１５は、従来のプロセス
の概念を提供するわけではない。というのは、すべての
オペレーティング・システム環境がプロセスに関連する
相当なセマンティクス（ユーザＩＤ、信号状態など）を
有するからである。これらの拡張セマンティクスを理解
したり提供することは、マイクロカーネルの目的ではな
い。
【００５５】多くのシステムはプロセスと制御の実行点
とを同一視しているが、システムによっては同一視して
いないものもある。
【００５６】マイクロカーネル１２０は、オペレーティ
ング・システム環境のプロセスとは別個に複数の制御点
をサポートする。マイクロカーネルは、以下の２通りの
概念を提供する。 タスク スレッド （タスクおよびスレッドの各概念の詳細については、第
２節「アーキテクチャ・モデル」を参照されたい。）
【００５７】メモリ管理 カーネルは何らかのメモリ管理を提供する。メモリはタ
スクに関連付けられている。メモリ・オブジェクトは、
タスクがメモリ管理を制御する際の手段である。マイク
ロカーネル・システム１１５は、散在している可能性の
ある大きい仮想アドレス空間をサポートするための各種
機構を提供する。それぞれのタスクは、カーネルによっ
て管理される関連のアドレス・マップを有し、そのタス
クのアドレス空間の仮想アドレスを物理アドレスに変換
する処理を制御する。仮想メモリ・システムの場合のよ
うに、所与のタスクのアドレス空間全体の内容は、物理
メモリに同時に完全に常駐するわけではなく、タスクの
仮想アドレス空間用のキャッシュとして物理メモリを使
用するための諸機構が存在していなければならない。従
来の仮想メモリ設計とは異なり、マイクロカーネル・シ
ステム１１５はキャッシュそのものをすべて実現するわ
けではない。これは、このような諸機構に関与できる能
力をユーザ・モード・タスクに与えるものである。ＰＮ
Ｓは、メモリ用のページング・サービスを提供するデフ
ォルト・ページャ１４４というユーザ・タスクを含んで
いる。
【００５８】マイクロカーネル・システム１１５の他の
資源とは異なり、仮想メモリはポートを使用して参照さ
れるわけではない。メモリは、特定のタスクのアドレス
空間内の索引として仮想アドレスを使用することによっ
てのみ、参照することができる。メモリと、タスクのア
ドレス空間を定義する関連のアドレス・マップは、部分
的に他のタスクと共用することができる。タスクは、そ
のアドレス空間内の新しいメモリ範囲を割り振り、その
割振りを解除し、その範囲に対する保護を変更すること
ができる。また、タスクは、その範囲の継承特性を指定
することもできる。新しいタスクは、その新しいタスク
用のアドレス空間を構築するためのベースとして既存の
タスクを指定することによって作成される。既存のタス
クの各メモリ範囲の継承属性によって、新しいタスクの
範囲が定義されているかどうか、ならびにその範囲が実
質的にコピーされているのかまたは既存のタスクと共用
されているのかが決まる。メモリに関する仮想コピー操
作のほとんどは、コピー・オン・ライト最適化によって
達成される。コピー・オン・ライト最適化は保護共用に
よって達成される。２つのタスクはコピー対象のメモリ
を共用するが、読取り専用アクセスの場合に限られる。
いずれかのタスクが範囲の一部を修正しようと試みる
と、その時点でその部分がコピーされる。このメモリ・
コピーの遅延評価は、マイクロカーネル・システム１１
５によって行われる重要なパフォーマンス最適化の１つ
であり、システムの通信／メモリ原理にとって重要なも
のである。
【００５９】所与のメモリ領域はメモリ・オブジェクト
によって支援される。メモリ・マネージャ（manager）
・タスクは、メモリにキャッシュされている間の一連の
ページのイメージ（あるメモリ領域の物理メモリ内容）
とキャッシュされていないときのその一連のページのイ
メージ（アブストラクション・メモリ・オブジェクト）
との関係を管理する方針を提供する。ＰＮＳには、始め
はゼロが充填されて、システム・ページング空間と照ら
し合わせてページングされる基本的な非持続性メモリ・
オブジェクトを提供する、デフォルトのメモリ・マネー
ジャまたはページャが用意されている。
【００６０】タスク間通信 マイクロカーネル・システム１１５は、通信チャネルを
介して送られるメッセージによって他のタスク（サー
バ）を要求することによってタスク（クライアント）が
サービスにアクセスする、クライアント／サーバ・シス
テム構造を使用する。マイクロカーネル１２０が提供す
るそれ専用のサービスは非常に少ない（たとえば、ファ
イル・サービスは一切提供しない）ので、マイクロカー
ネル１２０のタスクは、必要なサービスを提供する他の
数多くのタスクとやりとりしなければならない。プロセ
ス間通信（ＩＰＣ）機構の通信チャネルはポートと呼ば
れる。（ポートの詳細については、第２節「アーキテク
チャ・モデル」を参照されたい。）メッセージは、デー
タ、メモリ領域、およびポート権の集合である。ポート
権は、その権利を保有するタスクがそのポートを命名す
る際の名前である。ポートは、適切なポート権を保有す
る場合のみ、ポートを操作することができる。あるポー
トの受信権を保有できるのは１つのタスクに限られる。
このタスクは、ポート待ち行列からメッセージを受け取
る（読み取る）ことができる。複数のタスクはそのポー
トへの送信権を保有することができ、その送信権により
複数のタスクがメッセージを待ち行列に送信する（書き
込む）ことが可能になる。タスクは、１組のデータ要素
を収容するデータ構造を構築し、次に、保有する送信権
の対象となるポート上でメッセージ送信操作を実行する
ことによって、別のタスクとやりとりする。その後、そ
のポートへの受信権を保有するタスクがメッセージ受信
操作を実行する。ただし、このメッセージ転送は非同期
動作であることに留意されたい。メッセージは（おそら
くコピー・オン・ライト最適化により）受信タスクに論
理的にコピーされる。受信タスク内の複数のスレッド
は、所与のポートからのメッセージ受信を試みることが
できるが、所与のメッセージを受け取るのは１つのスレ
ッドに限られる。
【００６１】第２節 アーキテクチャ・モデル マイクロカーネル・システム１１５は、その主要責任と
して、フレームワーク内で命令を実行する制御点を用意
している。このような制御点はスレッドと呼ばれる。ス
レッドは仮想環境で実行される。カーネルによって提供
される仮想環境には、カーネルによって提供されるユー
ザ空間ＰＮＳおよびエミュレートされた命令（システム
・トラップ）分だけ増加した、ユーザ空間がアクセス可
能なハードウェア命令をすべて実行する仮想プロセッサ
が含まれる。この仮想プロセッサは、１組の仮想化レジ
スタと、本来ならマシンの物理メモリと同様の応答を行
う何らかの仮想メモリとにアクセスする。他のハードウ
ェア資源はいずれも、メモリ・アクセスとエミュレート
された命令との特別な組合せによってのみアクセスでき
る。ただし、カーネルによって提供されるすべての資源
が仮想化されていることに留意されたい。この項では、
スレッドから見た場合の仮想環境の最上位レベルの要素
について説明する。
【００６２】パーソナリティ・ニュートラル・サービス
（ＰＮＳ）の要素 マイクロカーネル・システム１１５のＰＮＳ１４０部分
は、基礎となるマイクロカーネル１２０上に構築された
各種サービスで構成されている。この部分は、カーネル
自体が依存している一部の機能ならびにプログラムの構
築用のユーザレベル・サービスの基本セットを提供す
る。これらのプログラムは、複数のオペレーティング・
システム・パーソナリティ・クライアントからの要求に
対応することができ、オペレーティング・システム・パ
ーソナリティそのものを構築するために使用される。さ
らに、標準的なＣで作成されたＰＮＳプログラムを構築
するためのＡＮＳＩ（米国規格協会）Ｃ実行時環境と、
ＰＯＳＩＸ（Portable Operating System Interface Fo
r Computer Environmetsの略）規格から取られた定義を
有するいくつかの補足機能とが存在する。ＰＮＳそのも
のを定義するライブラリの他に、適正マイクロカーネル
の一部である多くのライブラリがＰＮＳ内に存在する。
このようなライブラリは、マイクロカーネルがエクスポ
ートするインタフェースと、マイクロカーネル・システ
ム１１５のプロセス間通信機能とともに使用されるメッ
セージ・インタフェース・ジェネレータ（ＭＩＧ）用の
サポート論理とを表す。
【００６３】ＰＮＳ環境ライブラリの構造は、各サービ
スの実現内容の詳細をその呼出し側から隠蔽する。Ｃ実
行時ライブラリの１つのような一部のライブラリは、そ
の機能のすべてを呼出し側のアドレス空間にロードされ
るローカル・ルーチンとして実現するが、他のライブラ
リは、マイクロカーネルのＩＰＣシステムを呼び出して
サーバにメッセージを送信するスタブで構成されてい
る。このアーキテクチャにより、フレキシブルな機能実
現が可能になる。すなわち、サーバを他のサーバで置き
換えることができ、それを使用するプログラムのソース
に影響せずに複数のサービスを単一タスクに結合するこ
とができる。ＰＮＳ環境の重要要素は、それが完全なオ
ペレーティング・システムを構成しないという点であ
る。むしろ、ＰＮＳはパーソナリティの存在に依存す
る。システム・スタートアップ時に最初にロードされる
主要パーソナリティ１５２は、システム上にユーザ・イ
ンタフェースを提供し、そのクライアントとＰＮＳの諸
要素にサービスを提供する、オペレーティング・システ
ム・パーソナリティである。したがって、主要パーソナ
リティは「最後の手段」のサーバになる。主要パーソナ
リティは、ＰＮＳライブラリによって定義されている
が、別のサーバによって実現されないサービスをすべて
実現する。
【００６４】マイクロカーネル１２０は、ＰＮＳの一部
の要素にも依存する。このような場合としては、内部カ
ーネル動作を完了するためにパーソナリティ・ニュート
ラル・サーバにメッセージを送信する場合がある。たと
えば、ページ・フォルトを解決する際にマイクロカーネ
ル１２０は、デフォルト・ページャ１４４にメッセージ
を送信することができる。その場合、デフォルト・ペー
ジャ１４４は、カーネルがハード・ディスクから要求し
ているページを読み込む。通常、ページ・フォルトはユ
ーザ・タスクのために解決されるが、カーネルはメッセ
ージの送信側になる。
【００６５】実行時 ＰＮＳ実行時は、その環境で実行されるプログラム用の
標準的なＣプログラミング環境をサポートするために使
用される１組のＡＮＳＩ ＣおよびＰＯＳＩＸライブラ
リを提供する。これらの機能は、典型的なＣ言語構造体
を含んでいる。すべてのシステムと同様、マイクロカー
ネル・システム１１５は、その主要責任として、フレー
ムワーク内で命令を実行する制御点を用意する。マイク
ロカーネル１２０では、制御点はスレッドと呼ばれてい
る。スレッドは仮想環境で実行される。マイクロカーネ
ル１２０によって提供される仮想環境は、カーネルによ
って提供されるエミュレートされた命令（システム・ト
ラップ）分だけ増加した、ユーザ空間がアクセス可能な
ハードウェア命令をすべて実行する仮想プロセッサで構
成される。この仮想プロセッサは、１組の仮想化レジス
タと、本来ならマシンの物理メモリと同様の応答を行う
何らかの仮想メモリとにアクセスする。他のハードウェ
ア資源はいずれも、メモリ・アクセスとエミュレートさ
れた命令との特別な組合せによってのみアクセスでき
る。ただし、マイクロカーネルによって提供されるすべ
ての資源が仮想化されていることに留意されたい。この
項では、マイクロカーネル・スレッドから見た仮想環境
の最上位レベルの要素について説明する。
【００６６】カーネルの要素 マイクロカーネル１２０は、以下のカーネル要素のリス
トに記載された各種要素で構成された環境を提供する。 スレッド： 制御の実行点。スレッドは軽量エンティテ
ィである。スレッドに関連する状態の多くは、その収容
タスクに関連付けられている。 タスク： ポート名空間、仮想アドレス空間、および１
組のスレッドの形式で資源に対する参照を保管するため
の容器。 セキュリティ・トークン： タスクから、アクセス妥当
性検査を実行するサーバに渡されるセキュリティ機能。 ポート： タスク間の単一方向通信チャネル。 ポート・セット： メッセージを受け取るときに単一ユ
ニットとして扱うことができる１組のポート。 ポート権： ポートにアクセスするための具体的な権利
を許可するもの。 ポート名空間： 特定のポート権を命名するためのポー
ト名の索引付き集合。 メッセージ： ２つのタスク間で渡されるデータ、メモ
リ領域、およびポート権の集合。 メッセージ待ち行列： 単一ポートに関連するメッセー
ジの待ち行列。 仮想アドレス空間： タスク内のスレッドによって参照
可能なメモリ・ページがまばらに所在する索引付き集
合。ページ範囲は、カーネルおよび外部メモリ・マネー
ジャによって実現される機構によってそれらに関連付け
られた任意の属性およびセマンティクスを有する場合も
ある。 アブストラクション・メモリ・オブジェクト： このオ
ブジェクトによって支援されるメモリ範囲の非常駐状態
を表すアブストラクション・オブジェクト。このオブジ
ェクトを実現するタスクは、メモリ・マネージャと呼ば
れる。アブストラクション・メモリ・オブジェクト・ポ
ートは、カーネルがメモリ・マネージャのアクションを
要求する際のポートである。 メモリ・オブジェクト見本： メモリ・オブジェクトの
クライアントに対してメモリ・マネージャが提供するメ
モリ・オブジェクトのアブストラクション表現。この見
本は、関連のアブストラクション・メモリ・オブジェク
トを命名し、クライアントに許可される潜在的なアクセ
ス・モードを限定する。 メモリ・キャッシュ・オブジェクト： アブストラクシ
ョン・メモリ・オブジェクトによって支援されるメモリ
範囲の常駐状態を収容するカーネル・オブジェクト。メ
モリ・マネージャがクライアントの可視メモリ・イメー
ジを操作する場合、その操作はこのオブジェクトによっ
て行われる。 プロセッサ： スレッドを実行できる物理プロセッサ。 プロセッサ・セット： それぞれがプロセッサ・セット
に割り当てられているスレッドの実行に使用可能な１組
のプロセッサ。 ホスト： 全体としてのマルチプロセッサ。 クロック： 時間の経過を表すもの。一定の周波数で増
加する時間値。
【００６７】上記の要素の多くは、スレッドによって直
接操作可能な、カーネルで実現された資源である。それ
ぞれの要素については、以下の各項で詳しく説明する。
ただし、一部の要素の定義は他の要素の定義に依存する
ので、詳細説明を理解できるように、重要概念の一部に
ついては簡単に説明する。
【００６８】スレッド スレッドは軽量エンティティである。スレッドは、作成
するのに費用がかからず、動作に要するオーバヘッドも
低い。スレッドはほとんど状態を持たない（たいていは
そのレジスタ状態である）。スレッドが所有するタスク
は、資源管理の責任を負う。マルチプロセッサ上では、
タスク内の複数のスレッドが並列に実行することが可能
である。並行処理が目標ではなくても、複数スレッドは
有利である。というのは、各スレッドは、単一スレッド
が複数のサービスを提供しようとする非同期プログラミ
ングの代わりに、同期プログラミング・スタイルを使用
することができるからである。
【００６９】スレッドには、以下の特徴が含まれる。 １．タスクまたは一連の命令実行における制御流れの点 ２．収容タスクのすべての要素へのアクセス ３．複数のスレッドが同一タスク内にあっても、他のス
レッドと並列実行すること ４．オーバヘッドが低い割に状態が最小であること
【００７０】スレッドは、基本計算エンティティであ
る。スレッドは、その仮想アドレス空間を定義する１つ
のタスクにのみ属す。アドレス空間の構造に影響するた
め、またはアドレス空間以外の資源を参照するために
は、スレッドは特別なトラップ命令を実行しなければな
らない。これにより、カーネルは、スレッドのために諸
操作を実行するか、またはスレッドのためにエージェン
トにメッセージを送信する。このようなトラップは、ス
レッドを収容するタスクに関連する資源を操作する。こ
れらのエンティティを操作するよう、すなわち、それら
を作成して削除し、その状態を左右するよう、カーネル
に要求することができる。カーネルは、資源（前述のも
のなど）およびサービスを提供する管理プログラムであ
る。また、タスクもサービスを提供し、アブストラクシ
ョン資源を実現することができる。カーネルは、サーバ
・タスク（実際は、そこで実行されるスレッド）がサー
ビスを提供することをクライアント・タスクが要求でき
るようにするための通信方法を提供する。このようにし
て、タスクは２重のアイデンティティを持つ。一方のア
イデンティティは、カーネルによって管理される資源の
アイデンティティであって、その資源管理プログラムは
カーネル内で実行される。もう一方のアイデンティティ
は、資源の供給側のアイデンティティであって、そのた
めの資源管理プログラムはタスクそのものになる。
【００７１】スレッドは以下の状態を持つ。 １．そのマシン状態（レジスタなど）。スレッドが実行
されるにつれて変化し、カーネル・スレッド・ポートの
保有側による変更も可能であるもの。 ２．スレッド固有ポート権の小規模セット。スレッドの
カーネル・ポートと、スレッドのために例外メッセージ
を送信するために使用されるポートとを識別するもの。 ３．中断カウント。スレッドが命令を実行しない場合は
ゼロ以外になる。 ４．資源スケジューリング・パラメータ。
【００７２】スレッドは、通常通り命令を実行すること
によって動作する。スレッドのために諸操作を実行する
ために、様々な特殊命令がカーネルにトラップされる。
このようなカーネル・トラップのうちで最も重要なもの
はmach_msg_trapである。このトラップにより、スレッ
ドはカーネルにメッセージを送信し、他のサーバは資源
に作用することができる。このトラップが直接呼び出さ
れることはほとんどなく、mach_msgライブラリ・ルーチ
ンを介して呼び出される。スレッドの実行中に発生する
「浮動小数点オーバーフロー」および「ページ非常駐」
などの例外条件は、ポートにメッセージを送信すること
によって処理される。使用するポートはその条件の性質
によって決まる。例外条件の結果は、スレッドの状態を
設定するか、または例外メッセージに対して応答する
か、あるいはその両方を実行することによって決定され
る。スレッドについては、以下の操作を実行することが
できる。 作成および破棄 中断および再開（中断カウントの操作） マシン状態操作特殊ポート（例外ポートなど）の操作 資源（スケジューリング）制御
【００７３】タスク タスクはシステム資源の集合である。このような資源
は、アドレス空間を除き、ポートによって参照される。
ポートに対する権利がそのように分散されていれば、こ
れらの資源を他のタスクと共用することができる。
【００７４】タスクは、マシン・アドレスによって参照
される、散在する可能性のある大きいアドレス空間を提
供する。この空間の各部は、継承または外部メモリ管理
によって共用することができる。ただし、タスクにはそ
れ専用の存続期間がないことに留意されたい。タスクに
は、命令を実行するスレッドが収容されている。「タス
クＹがＸを実行する」と言う場合、「タスクＹ内に収容
されているスレッドがＸを実行する」ことを意味する。
タスクは高価なエンティティである。１つのタスク内の
すべてのスレッドがあらゆるものを共用する。アクショ
ンは単純である場合が多いが、明示アクションがなけれ
ば、２つのタスクは何も共用しない。ポート受信権など
の一部の資源は、２つのタスク間で共用することができ
ない。タスクは、１組のスレッドを保管する容器と見な
すことができる。タスクは、その収容スレッドに適用さ
れるデフォルト値を収容している。最も重要なのは、そ
の収容スレッドが実行に要する要素、すなわち、ポート
名空間と仮想アドレス空間をタスクが収容している点で
ある。
【００７５】タスクに関連する状態は以下の通りであ
る。 １組の収容スレッド 関連の仮想アドレス空間 １組のポート権とそれに関連する１組のポート通知要求
を命名する、関連ポート名空間 タスクからメッセージとともに送信されるセキュリティ
・トークン タスクのカーネル・ポートと、収容スレッドのための例
外処理に使用するデフォルト・ポートと、他のサービス
を命名するためのブートストラップ・ポートとを識別す
る、タスク固有ポートの小規模セット 収容スレッドが命令を実行しない場合はゼロ以外にな
る、中断カウント スレッド用のデフォルト・スケジューリング・パラメー
タ 統計ＰＣサンプルを含む、様々な統計
【００７６】タスクは、新しいタスクが作成されるホス
トを指定し、継承によりそのアドレス空間の様々な部分
を供給することができる、プロトタイプ・タスクを指定
することによって作成される。
【００７７】タスクについては、以下の操作を実行する
ことができる。 作成および破棄 セキュリティ・トークンの設定 中断および再開 特殊ポートの操作 収容スレッドの操作 スケジューリング・パラメータの操作
【００７８】セキュリティ・ポート すべてのタスクは、カーネルの視点からは不透明のＩＤ
であるセキュリティ・トークンでタグが付けられてい
る。これは、タスクのアイデンティティとその他のセキ
ュリティ属性を符号化するものである。このセキュリテ
ィ・トークンは、タスクによって送られるすべてのメッ
セージに暗黙値として含まれている。トラステッド・サ
ーバは、アクセス仲介判断を行う際に使用するためのセ
ンダー側のアイデンティティの標識として、この送られ
たトークンを使用することができる。タスクは、その親
のセキュリティ・トークンを継承する。このトークン
は、偽造不能なアイデンティティの標識として使用され
るので、このトークンを変更するには特権が必要であ
る。この特権は、ホスト・セキュリティ・ポートを提示
することによって示される。
【００７９】予約値は、カーネルのアイデンティティを
示す。カーネルからのすべてのメッセージはカーネルの
アイデンティティを伝達する。ただし、例外メッセージ
は、例外タスクのアイデンティティを伝達する。
【００８０】ポート ポートは、サービスを要求するクライアントと、そのサ
ービスを提供するサーバとの間の単一方向の通信チャネ
ルである。１つのポートは、単一レシーバを有し、複数
のセンダーを有する可能性もある。ポートに関連する状
態は以下の通りである。 その関連メッセージ待ち行列 ポートに対する参照（権利）のカウント 仮想コピー・メモリの容量と、ポートを介してメッセー
ジ送信可能なポート権とに対して設定可能な限界値
【００８１】カーネル・サービスは、ポートを割り振る
ために存在する。仮想メモリ範囲以外のすべてのシステ
ム・エンティティはポートによって命名され、これらの
エンティティが作成されると、ポートも暗黙のうちに作
成される。
【００８２】カーネルは、要求に応じてポートが消滅す
ると、通知メッセージを提供する。タスクの仮想アドレ
ス空間を除き、他のすべてのシステム資源は、ポートと
して知られている所定のレベルの間接参照によってアク
セスされる。ポートは、サービスを要求するクライアン
トと、そのサービスを提供するサーバとの間の単一方向
の通信チャネルである。このようなサービス要求に対し
て応答を行う場合は、第２のポートを使用しなければな
らない。提供されるサービスは、ポートを介して送られ
るメッセージを受け取る管理プログラムによって決定さ
れる。その結果、カーネル提供エンティティに関連する
ポート用のレシーバがカーネルになる。タスク提供エン
ティティに関連するポート用のレシーバは、そのエンテ
ィティを提供するタスクになる。タスク提供エンティテ
ィを命名するポートの場合、そのポート用のメッセージ
のレシーバを別のタスクに変更することが可能である。
単一タスクが、それによってサポートされる資源を参照
する複数のポートを有する可能性もある。所与のエンテ
ィティは、それを表す複数のポートを有し、それぞれが
許される操作の様々なセットを暗示することができる。
たとえば、多くのエンティティは、名前ポートと、特権
ポートと呼ばれることもある制御ポートとを有する。こ
の制御ポートにアクセスすると、そのエンティティを操
作することができる。名前ポートへのアクセスは、たと
えば、情報を返すために、そのエンティティを命名する
だけである。
【００８３】ポート用のシステム規模の名前空間は一切
ない。スレッドは、その収容タスクが把握しているポー
トにのみアクセスすることができる。タスクは、１組の
ポート権を保有し、そのそれぞれが（必ずしも別個では
ない）ポートを命名し、そのポートに許される権利を指
定する。ポート権は、メッセージに入れて伝送すること
ができる。これは、タスクがポート権を取得する方法で
ある。ポート権はポート名で命名され、そのポート名
は、その権利を保有するタスクのコンテキスト（ポート
名空間）内でのみ意味を持つカーネルによって選択され
た整数である。システム内のほとんどの操作は、操作さ
れるオブジェクト用の管理プログラムを命名するポート
にメッセージを送信することで構成される。本明細書で
は、これを以下の形式で示す。 object -> function これは、そのオブジェクトを命名するポートに（適切な
メッセージを送信することによって）その機能が呼び出
されることを意味する。ポート（権）にメッセージを送
信しなければならないので、この操作はオブジェクトを
基礎とする。スレッドをプロセッサ・セットにバインド
する場合など、操作によっては２つのオブジェクトが必
要になる。このような操作では、オブジェクト同士をカ
ンマで区切って示す。すべてのエンティティがポートに
よって命名されるわけではないので、これは純粋なオブ
ジェクト・モデルではない。２つの主要非ポート権命名
エンティティは、ポート名／権そのものと、メモリ範囲
である。事象オブジェクトもタスクのローカルＩＤによ
って命名される。メモリ範囲を操作するには、所有タス
クによって命名された収容仮想アドレス空間にメッセー
ジが送信される。ポート名／権と、多くの場合は関連ポ
ートとを操作するには、所有タスクによって命名された
収容ポート名空間にメッセージが送信される。オブジェ
クトのどの範囲または要素を操作するかを示すにはメッ
セージ内のパラメータとしてｉｄが必要であることを示
すために、ここでは以下の添字表記を使用する。 object [id] -> function また、特定の方法でオブジェクトを操作するための十分
な特権を示すにはメッセージ内のパラメータとして、ホ
スト制御ポートなどの特権ポートが必要であることを示
すために、ここでは以下のかっこ付き表記を使用する。 object (port) -> function
【００８４】ポート・セット ポート・セットは、メッセージを受け取るときに単一ユ
ニットとして扱うことができる１組のポートである。ma
ch_msg受信操作は、受信権またはポート・セットのいず
れかを命名するポート名に対して使用可能になる。ポー
ト・セットには、複数の受信権の集合が入っている。受
信操作がポート・セットに対して行われると、そのセッ
ト内のポートの１つからメッセージが受け取られる。受
け取ったメッセージは、そのメッセージの送信元である
メンバー・ポートを示す。ポート・セットのメンバーで
あるポートからメッセージを直接受け取ることはできな
い。ポート・セット内のポートに関する優先順位の概念
は存在しない。したがって、所与のメッセージの送信元
であるポート・セット内のポートに関するカーネルの選
択は一切制御されない。
【００８５】ポート・セットについてサポートされてい
る操作には、以下のものが含まれる。 作成および削除 メンバーシップの変更およびメンバーシップの照会
【００８６】ポート権 ポートは、ポート権の使用によってのみアクセスするこ
とができる。ポート権により、特定の方法で特定のポー
トにアクセスすることができる。ポート権としては、以
下の３通りのタイプがある。 受信権 ― 権利保有者が関連ポートからメッセージを
受信できるようにする。 送信権 ― 権利保有者が関連ポートにメッセージを送
信できるようにする。 単一送信権 ― 権利保有者が関連ポートに単一メッセ
ージを送信できるようにする。このポート権は、メッセ
ージ送信後に自然消滅する。
【００８７】ポート権は、mach_msg呼出しの様々なオプ
ションを使用してタスク間でコピーおよび移動すること
ができ、さらに明示コマンドによってもコピーおよび移
動することができる。メッセージ操作以外では、ポート
名空間のメンバーとしてのみポート権を操作することが
できる。また、他のシステム・エンティティを作成し、
明示ポート作成を明示的に使用すると、暗黙のうちにポ
ート権が作成される。
【００８８】ポートに対する送信権がそれ以上ない場
合、カーネルは、要求に応じて、ユーザの選択をポート
に通知する。また、単一送信権の破棄（それを使用して
メッセージを送信する場合を除く）により、対応するポ
ートに送られる単一送信通知が生成される。要求がある
と、カーネルは、受信権の破棄を通知する。
【００８９】ポート名空間 ポートおよびポート権は、任意のポートまたは権利を直
接操作できるようにするためのシステム規模の名前を持
っていない。ポートはポート権を介してのみ操作可能
で、ポート権はポート名空間内に収容されている場合の
み操作可能である。ポート権は、ポート名空間内の索引
であるポート名によって指定される。各タスクには、単
一のポート名空間が関連付けられている。
【００９０】ポート名空間の項目は、以下の４通りの値
を持つことができる。 MACH_PORT_NULL ― 関連ポート権がない。 MACH_PORT_DEAD ― この名前に権利が関連付けられて
いるが、その権利が参照するポートはすでに破棄されて
いる。 ポート権 ― ポートに関する単一送信権、送信権、ま
たは受信権。 ポート・セット名 ― 受信権のように機能するが、複
数のポートからの受信を可能にする名前。
【００９１】タスク内で新しい権利を獲得すると、新し
いポート名が生成される。ポート権は、そのポート名を
参照することによって操作されるので、ポート名そのも
のが操作されることもある。所与のポート名空間内の所
与のポートに対するすべての送信権と受信権は同じポー
ト名を有する。所与のポートに対する各単一送信権は、
他の単一送信権とは異なるポート名を有し、保有する送
信権または受信権に使用したポート名とも異なるポート
名を有する。ポート名についてサポートされている操作
としては、以下のものが含まれる。 作成（権利の作成時の暗黙作成）および破棄 関連タイプの照会 名前変更 名前が使用不能になるという通知（要求に応じて、カー
ネルが行う）
【００９２】ポート名空間はタスクにバインドされるの
で、その空間が所有するタスクによって作成および破棄
される。
【００９３】メッセージ メッセージは、２つのエンティティ間で引渡しされるデ
ータ、メモリ範囲、およびポート権の集合である。メッ
セージは、元々システム・オブジェクトであるわけでは
ない。しかし、メッセージは待ち行列化されるため、メ
ッセージ送信からその受信までの間、状態を保持するこ
とができるので、重要である。この状態は、以下のもの
で構成される。 純粋データ メモリ範囲のコピー ポート権 送信側のセキュリティ・トークン
【００９４】メッセージ待ち行列 ポートは、複数のメッセージからなる待ち行列で構成さ
れる。この待ち行列は、メッセージを伝送するメッセー
ジ操作（mach_msg）によってのみ操作される。待ち行列
に関連する状態は、待ち行列化されたメッセージからな
る順序付けされた集合であり、メッセージ数に関する設
定可能な限界である。
【００９５】仮想アドレス空間 仮想アドレス空間は、その仮想アドレス空間を所有する
タスク内で実行されるスレッドを参照できるようにする
ための有効仮想アドレスの集合を定義する。仮想アドレ
ス空間は、それ自身が所有するタスクによって命名され
る。
【００９６】仮想アドレス空間は、複数のページがまば
らに所在する索引付き集合で構成される。個々のページ
の属性は、所望通りに設定することができる。効率を高
めるため、カーネルは、同じ属性を有する複数のページ
からなるほぼ連続する集合を、内部メモリ領域にグルー
プ化する。カーネルは、所望通りにメモリ領域の分割ま
たは統合を自由に行うことができる。システム機構はメ
モリ領域のアイデンティティに敏感であるが、ほとんど
のユーザ・アクセスはそのような影響を受けず、自由に
メモリ領域に及ぶことができる。
【００９７】所与のメモリ範囲は、メモリ・マネージャ
の各種アクションにより、それに関連する個別のセマン
ティクスを持つことができる。仮想アドレス空間に新し
いメモリ範囲が設定されると、そのメモリ範囲のセマン
ティクスを提供するタスク（メモリ・マネージャ）に関
連付けられることによって、そのセマンティクスを表す
アブストラクション・メモリ・オブジェクトが、おそら
くデフォルトにより指定される。
【００９８】仮想アドレス空間は、タスクが作成される
と作成され、タスクが破棄されると破棄される。アドレ
ス空間の初期内容は、task_create呼出しへの様々なオ
プション、ならびにその呼出しに使用するプロトタイプ
・タスクのメモリ範囲の継承特性により決まる。
【００９９】仮想アドレス空間でのほとんどの操作によ
り、アドレス空間内のメモリ範囲が命名される。このよ
うな操作としては、以下のものが含まれる。 範囲の作成または割振りと、割振り解除 範囲のコピー 追出しを防止するためにページを物理メモリに「配線」
することを含む、特殊属性の設定 メモリ保護属性の設定 継承特性の設定 範囲の直接読取りおよび書込み 補助記憶装置への範囲の強制フラッシュ 範囲の予約（範囲内でのランダム割振りを防止する）
【０１００】アブストラクション・メモリ・オブジェク
ト マイクロカーネルでは、ユーザ・モード・タスクが仮想
アドレス空間の各部分の参照に関連するセマンティクス
を提供することができる。これは、このメモリ・オブジ
ェクトによって支援されるメモリ範囲の非常駐状態を表
すアブストラクション・メモリ・オブジェクトの指定を
可能にすることによって行われる。このメモリ・オブジ
ェクトを実現し、メモリ・オブジェクトを命名するポー
トに送られるメッセージに応答するタスクは、メモリ・
マネージャと呼ばれている。
【０１０１】カーネルは、各種のメモリ・オブジェクト
の内容用の直接アクセス可能なキャッシュとしてメイン
・メモリを使用する。と考える必要がある。カーネル
は、アブストラクション・メモリ・オブジェクト・ポー
トにメッセージを送ることによって、このキャッシュを
維持し、このキャッシュをカーネルの所望通りに充填お
よびフラッシュするために、様々なメモリ・マネージャ
との非同期対話に関与する。アブストラクション・メモ
リ・オブジェクトに対する操作としては、以下のものが
含まれる。 初期設定 ページ読取り ページ書込み 強制およびフラッシュ動作との同期 ページにアクセスするための許可を求める要求 ページ・コピー 終了
【０１０２】メモリ・オブジェクト見本 メモリ・オブジェクト用の補助記憶装置へのアクセスを
要求するために、カーネルはアブストラクション・メモ
リ・オブジェクト・ポートを使用する。この対話の保護
性のため、一般にメモリ・マネージャは、アブストラク
ション・メモリ・オブジェクト・ポートへのアクセスを
クライアントに許可しない。むしろ、クライアントは、
メモリ・オブジェクト見本へのアクセスが許可される。
メモリ・オブジェクト見本とは、メモリ・オブジェクト
のクライアント側の表現である。このようなポートに対
して許される操作は１つだけであり、それは関連メモリ
・オブジェクトをタスクのアドレス空間にマッピングす
ることである。このような要求を行うと、基礎となるア
ブストラクション・メモリ・オブジェクトを初期設定す
るためにマッピング・カーネルとメモリ・マネージャと
の間のプロトコルが開始される。その見本によって表さ
れるアブストラクション・メモリ・オブジェクト、なら
びにその見本によって許されるアクセス・モードの集合
をカーネルに通知するには、この特殊なプロトコルが使
用される。
【０１０３】メモリ・キャッシュ・オブジェクト カーネルのメイン・メモリ・キャッシュのうち、所与の
アブストラクション・メモリ・オブジェクトに関連する
常駐ページが入っている部分は、メモリ・キャッシュ・
オブジェクトと呼ばれる。メモリ・オブジェクト用のメ
モリ・マネージャは、カーネルのメモリ・キャッシュ・
オブジェクトに対する送信権を保有する。このメモリ・
マネージャは、関連メモリ・キャッシュ・オブジェクト
にメッセージを送ることによって、そのアブストラクシ
ョン・メモリ・オブジェクトのアブストラクションを提
供するために、カーネルとの非同期対話に関与する。メ
モリ・キャッシュ・オブジェクトに対する操作として
は、以下のものが含まれる。 動作属性の設定 属性の戻り カーネルへのページ供給 カーネルが要求したページが使用不能であることを示す
表示 カーネルが要求したページをカーネルのデフォルト・ル
ールによって充填する必要があることを示す表示 オブジェクトの遅延コピーの強制完了 メモリ・マネージャに送られたページが処分されたこと
を示す表示 メモリ・ページへのアクセスの制限 パフォーマンス上のヒントの提供 終了
【０１０４】プロセッサ スレッドを実行することができる各物理プロセッサは、
プロセッサ制御ポートによって命名される。実際の作業
を実行するという点で重要ではあるが、プロセッサ・セ
ットのメンバーとして以外にマイクロカーネル内のプロ
セッサはあまり重要ではない。１組のスレッドをスケジ
ュールするために使用されるプロセッサの共同管理用の
基礎を形成し、それに関連するスケジューリング属性を
有するのが、プロセッサ・セットである。プロセッサに
ついてサポートされている操作としては、以下のものが
含まれる。 プロセッサ・セットへの割当て 始動および停止などのマシン制御
【０１０５】プロセッサ・セット プロセッサはプロセッサ・セットにグループ化される。
プロセッサ・セットは、そのプロセッサ・セットに割り
当てられたスレッドをスケジュールするために使用され
るプロセッサの共同管理を行う。プロセッサ・セット
は、１組のスレッドのスケジュール可能性を均等に制御
するための基礎として存在する。また、この概念は、シ
ステム内の所与の活動にプロセッサをおおざっぱに割り
振るための方法も提供する。プロセッサ・セットについ
てサポートされている操作としては、以下のものが含ま
れる。 作成および削除 プロセッサの割当て スレッドおよびタスクの割当て スケジューリング制御
【０１０６】ホスト ネットワーク化したマイクロカーネル・システム内の各
マシン（ユニプロセッサまたはマルチプロセッサ）は、
マイクロカーネルについて独自のインスタンス化を実行
する。一般に、ホスト・マルチプロセッサ１００はクラ
イアント・タスクによって操作されることはない。しか
し、各ホストはそれ専用のマイクロカーネル１２０を所
持し、それぞれが専用のポート空間、物理メモリ、およ
びその他の資源を備えているので、実行中のホストは目
に見えるものになり、時には直接操作されることもあ
る。また、各ホストはそれ専用の統計を生成する。ホス
トの命名は、自由に分散され、ホストに関する情報を入
手するために使用可能な名前ポートと、しっかり保持さ
れホストを操作するために使用可能な制御ポートとによ
って行われる。ホストによってサポートされている操作
としては、以下のものが含まれる。 クロック操作 統計収集 リブート デフォルト・メモリ・マネージャの設定 プロセッサおよびプロセッサ・セットのリストの入手
【０１０７】クロック クロックは、一定の周波数で時間値カウンタを増加する
ことによって、時間の経過を表す。マルチコンピュータ
内の各ホストまたはノードは、ハードウェアによってサ
ポートされる各種クロックおよびタイマ、ならびにこの
ようなタイマ上に構築されたアブストラクション・クロ
ックに基づいて、専用のクロック・セットを実現する。
所与のシステムによって実現されたクロック・セット
は、構成時に設定される。それぞれのクロックは、名前
ポートと、制御または特権ポートとによって命名され
る。制御ポートを使用すると、クロックの時刻と解像度
を設定することができる。名前ポートが与えられると、
タスクは以下の操作を実行することができる。 クロックの時刻と解像度の決定 時間値をマッピングするメモリ・オブジェクトの生成 所与の時刻までのスリープ（遅延） 所与の時刻での通知または警告の要求
【０１０８】第３節 タスクおよびスレッド 本節では、スレッドおよびタスクのユーザ可視視点につ
いて論じる。スレッドは、マイクロカーネル・システム
１１５内の活動エンティティである。スレッドは、他の
資源にアクセスする際の仮想アドレス空間とポート名空
間をスレッドに提供するタスク内の制御点として機能す
る。
【０１０９】スレッド スレッドは、基本的な計算エンティティである。スレッ
ドは、その仮想アドレス空間を定義する１つのタスクに
のみ属す。また、スレッドは、最小限の状態を有する軽
量エンティティである。スレッドは、ハードウェアによ
って指図された方法で実行され、スレッドのレジスタ値
に基づいてそのタスクのアドレス空間から命令を取り出
す。スレッドが直接実行することができるアクション
は、そのレジスタを操作し、そのメモリ空間での読取り
および書込みを行う命令を実行することだけである。た
だし、特権機械命令を実行しようと試みると、例外が発
生する。この例外については後述する。アドレス空間の
構造を左右するため、またはアドレス空間以外の資源を
参照するためには、スレッドは、スレッドのために操作
を実行するか、またはスレッドのために何らかのエージ
ェントにメッセージを送信するようカーネルに指示す
る、特殊トラップ命令を実行しなければならない。ま
た、障害またはその他の不当命令挙動が発生すると、カ
ーネルがその例外処理を呼び出す。
【０１１０】図２は、スレッドに関連するクライアント
可視構造を示している。スレッド・オブジェクトは、カ
ーネル・スレッド・ポートに送られたメッセージ用のレ
シーバである。このスレッド・ポート用の送信権を保有
するランダム・タスクを除き、スレッド・ポートは、収
容プロセッサ・セットまたは収容タスクを介してそのス
レッドのスレッド自己ポートとしてもアクセス可能であ
る。
【０１１１】ここでは、ガイ・ジー・ソトマイヤー他に
よる"METHOD AND APPARATUS FOR MANAGEMENT OF MAPPED
AND UNMAPPED REGIONS OF MEMORY IN A MICROKERNEL D
ATAPROCESSING SYSTEM"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１１２】タスク タスクは、１組のスレッドを保管する容器と見なすこと
ができる。これは、その収容スレッドに適用されるデフ
ォルト値を収容している。最も重要なのは、その収容ス
レッドが実行する必要がある要素、すなわち、ポート名
空間と仮想アドレス空間を収容している点である。
【０１１３】図３は、クライアント可視タスク構造を示
している。タスク・オブジェクトは、カーネル・タスク
・ポートに送られたメッセージ用のレシーバである。こ
のタスク・ポート用の送信権を保有する可能性のあるラ
ンダム・タスクを除き、タスク・ポートは、そのタスク
のタスク自己ポート、収容済みスレッド、または収容プ
ロセッサ・セットから得ることができる。
【０１１４】ここでは、ガイ・ジー・ソトマイヤー他に
よる"METHOD AND APPARATUS FOR MANAGEMENT OF MAPPED
AND UNMAPPED REGIONS OF MEMORY IN A MICROKERNEL D
ATAPROCESSING SYSTEM"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１１５】第４節 ＩＰＣ その共用メモリを除き、マイクロカーネル・タスクは、
メッセージを送信し、応答を受信することによって純粋
にその環境と対話する。このようなメッセージはポート
を使用して送信される。ポートは、単一レシーバを有
し、複数のセンダーを有することができる通信チャネル
である。タスクは、それがメッセージを送信または受信
できる能力を指定する、これらのポートに対する権利を
保有する。
【０１１６】ポート ポートは、サービスを要求するクライアントと、そのサ
ービスを提供するサーバとの間の単一方向の通信チャネ
ルである。ポートは、単一レシーバを有し、複数のセン
ダーを有することができる。カーネルがサポートする資
源を表すポートは、レシーバとしてカーネルを有する。
タスクによって提供されるサービスを命名するポート
は、そのポートのレシーバとしてそのタスクを有する。
ポート権の項で論じるように、このレシーバ状態は必要
があれば変更することができる。
【０１１７】ポートに関連する状態は以下の通りであ
る。 関連メッセージ待ち行列 ポートに対する参照または権利のカウント ポート権および行外メモリ受信限界値 メッセージの順序番号 受信権から作成される送信権の数 収容ポート・セット 追加センダーなしポートの名前（指定されている場合）
【０１１８】図４は、典型的なポートを示す図であり、
一連の送信権と単一受信権を示している。関連メッセー
ジ待ち行列は、一連の順序づけられたメッセージを有す
る。そのメッセージの１つが詳細に示されているが、そ
の宛先ポート、応答ポート参照、メッセージで引き渡さ
れる送受信権、ならびに何らかの行外または仮想コピー
・メモリが示されている。
【０１１９】ここでは、ガイ・ジー・ソトマイヤー（Gu
y G. Sotomayor）およびフリーマン・エル・ローソン
（Freeman L. Rawson）III他の"METHOD AND APPARATUS
FOR MANAGEMENT OF MAPPED AND UNMAPPED REGIONS OF M
EMORY IN A MICROKERNEL DATAPROCESSING SYSTEM"とい
う名称の前述の関連米国特許出願を参照するが、この特
許出願は、上記の点についてさらに詳述するために参照
により本発明の一部となる。
【０１２０】図５は、ポート名空間に収容されている
か、またはメッセージに入れて伝送中の一連のポート権
を示している。ポート名空間にはポート・セットも示さ
れている。
【０１２１】ここでは、ガイ・ジー・ソトマイヤー他
の"METHOD AND APPARATUS FOR MANAGEMENT OF MAPPED A
ND UNMAPPED REGIONS OF MEMORY IN A MICROKERNEL DAT
A PROCESSING SYSTEM"という名称の前述の関連米国特許
出願を参照するが、この特許出願は、上記の点について
さらに詳述するために参照により本発明の一部となる。
【０１２２】第５節 仮想メモリ管理 マイクロカーネルの仮想メモリ設計では、仮想メモリ・
システムをマシン依存部分とマシン非依存部分に階層化
する。マシン依存部分は、仮想メモリのページに関する
アクセス権の妥当性検査、無効化、および設定のための
単純なインタフェースを提供し、それにより、ハードウ
ェアのアドレス・マップを管理する。マシン非依存部分
は、論理アドレス・マップ（仮想アドレス空間のマッピ
ング）、このマップ内のメモリ範囲、および外部メモリ
管理インタフェースによるこれらの範囲用の補助記憶装
置へのインタフェース（メモリ・オブジェクト）をサポ
ートする。
【０１２３】仮想メモリ・システムは、適度な数のプロ
セッサからなる均等メモリ・アクセス・マルチプロセッ
サ用に設計されている。非均等メモリ・アクセスを提供
するか、または遠隔メモリ・アクセスを一切提供しない
アーキテクチャのサポートについては、現在、研究が行
われている。
【０１２４】マイクロカーネル仮想メモリ設計の特徴の
１つは、パフォーマンスの高さである。その多くは、こ
の設計が大規模疎アドレス空間、共用メモリ、および仮
想コピー・メモリ最適化を効率よくサポートしているこ
とによる。最後に、仮想メモリ・システムでは、クライ
アントがメモリ範囲用の補助記憶装置を提供することが
でき、それにより、このような範囲に適用されるセマン
ティクスが定義される。
【０１２５】ここでは、ガイ・ジー・ソトマイヤー他に
よる"METHOD AND APPARATUS FOR MANAGEMENT OF MAPPED
AND UNMAPPED REGIONS OF MEMORY IN A MICROKERNEL D
ATAPROCESSING SYSTEM"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１２６】図６は、クライアント可視仮想メモリ構造
を示している。３つのメモリ範囲があり、そのうちの２
つは同一の支援アブストラクション・メモリ・オブジェ
クトを有するが、おそらく継承または保護属性は異なっ
ている。読取りアクセスおよび読取り／書込みアクセス
を表す２つのメモリ・オブジェクト見本と、メモリ・マ
ネージャ・タスクとともに、メモリ・キャッシュ／アブ
ストラクション・メモリ・オブジェクト対の１つが詳細
に示されている。予約済みであるが、まだ割り振られて
いない領域は示されていない。この領域には、予約フラ
グと継承属性のみでマークが付けられるはずである。他
の属性は一切適用されない。
【０１２７】ここでは、ガイ・ジー・ソトマイヤー他に
よる"METHOD AND APPARATUS FOR MANAGEMENT OF MAPPED
AND UNMAPPED REGIONS OF MEMORY IN A MICROKERNEL D
ATAPROCESSING SYSTEM"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１２８】第Ｂ部 本発明の詳細な説明 図７は、ホスト・マルチプロセッサ・システム１００の
機能ブロック図であり、２つのプロセッサ１１０および
１１２上でスレッドを実行している状態でＩＰＣサブシ
ステム１２２と制御登録モジュール５００が２つのタス
ク２１０および２１０'間のプロセス間通信を管理する
場合を示している。データ処理システムは、図７に示す
ような共用メモリ・マルチプロセッシング・システムで
ある場合もあれば、図１２に示すような分散処理システ
ムの場合もあり、ユニプロセッサ・システムの場合もあ
る。マイクロカーネル１２０オペレーティング・システ
ムは、データ処理システム１００のメモリ１０２にロー
ドされる。図７、８、９に示すようにマイクロカーネル
１２０のＩＰＣサブシステム１２２には、メッセージ引
渡しライブラリ２２０と、制御登録モジュール５００
と、メッセージ制御構造（ＭＣＳ：Message Control St
ructure）登録テーブル５０２と、ＭＣＳ形式検査モジ
ュール５３２とが含まれている。
【０１２９】図１０は、無名応答ポート６００を使用す
る双方向メッセージ転送時の、ＩＰＣサブシステム１２
２と無名応答ポート６００を備えたホスト・マルチプロ
セッサ・システムの機能ブロック図である。図１１は、
元のクライアント・メッセージ６１０とＩＰＣサブシス
テム１２２によって公式化された代用メッセージ６１
２、ならびに応答メッセージ６１４とＩＰＣサブシステ
ム１２２によって公式化された代用応答メッセージ６１
６の内容の例を示している。
【０１３０】プロセス間通信（ＩＰＣ）データ・タイプ
・メッセージは、媒介物としてプロセス間通信サブシス
テム１２２を使用する、クライアントである送信側タス
ク２１０とサーバである宛先タスク２１０'との間の単
方向メッセージである。クライアントである送信側タス
ク２１０がサーバである宛先タスク２１０'に転送する
ためにプロセス間通信サブシステム１２２にＩＰＣデー
タ・タイプ・メッセージを送信してしまうと、クライア
ントである送信側タスク２１０は、追加メッセージの送
信を待ち受けたり、そのスレッドの媒介により他の動作
に従事したりする必要がない。
【０１３１】遠隔プロシージャ呼出し（ＲＰＣ）データ
・タイプ・メッセージは、媒介物としてプロセス間通信
サブシステム１２２を使用する、クライアントである送
信側タスク２１０とサーバである宛先タスク２１０'と
の間の双方向メッセージである。クライアントである送
信側タスク２１０がサーバである宛先タスク２１０'に
転送するためにプロセス間通信サブシステム１２２にＲ
ＰＣデータ・タイプ・メッセージを送信した後、クライ
アントである送信側タスク２１０は、サーバである宛先
タスク２１０'がそのメッセージに応答するまで待たな
ければならない。クライアントである送信側タスク２１
０は、サーバである宛先タスク２１０'からの応答を待
っている間、どのタスクに対しても他のメッセージを自
由に送信することはできない。
【０１３２】この問題は、プロセス間通信サブシステム
１２２に無名応答ポート６００機構を設けることによっ
て、本発明により解決される。クライアントである送信
側タスク２１０は、その双方向メッセージ６１０を送信
／受信メッセージとして公式化することができる。送信
／受信メッセージ６１０は、サーバである宛先タスク２
１０'と応答ポートのアイデンティティとを指名するフ
ィールドを含んでいる。本発明によれば、クライアント
である送信側タスク２１０は、無名応答ポート６００を
サーバである宛先タスク２１０'からの応答のための指
定ポートとして受け入れることを示す指示を、応答ポー
ト・フィールドに入れる。この指定により、プロセス間
通信サブシステム１２２は、サーバである宛先タスク２
１０'から見たときに、メッセージの見かけ上のセンダ
ーになる。クライアントである送信側タスク２１０は、
双方向メッセージ６１０の送信に対する応答としてサー
バである宛先タスク２１０'からの応答を待つ必要がな
くなる。
【０１３３】プロセス間通信サブシステム１２２は、ク
ライアントである送信側タスク２１０からメッセージ６
１０を受け取ると、代用メッセージ６１２を公式化す
る。プロセス間通信サブシステム１２２は、無名応答ポ
ート６００のテーブルに項目６０２を作成し、センダー
のメッセージ６１０と宛先の応答６１４によって表され
る双方向トランザクションにトランザクション名を割り
当てる。このテーブル項目６０２は、クライアントであ
る送信側タスク２１０のポートの名前も含んでいるが、
任意でサーバである宛先タスク２１０'のポートの名前
を含むこともできる。本発明によれば、次にプロセス間
通信サブシステム１２２は、応答ポートを識別する代用
メッセージ６１２のフィールドにトランザクション名を
入れる。その後、代用メッセージ６１２は、プロセス間
通信サブシステム１２２によってサーバである宛先タス
ク２１０'のポートに転送される。
【０１３４】クライアントである送信側タスク２１０が
サーバである宛先タスク２１０'からの応答を待ってい
る間、クライアントである送信側タスク２１０は、他の
メッセージを送受信したり、そのスレッドで他の動作を
実行することができる。
【０１３５】サーバである宛先タスク２１０'は、応答
メッセージ６１４を送信する準備ができると、そのトラ
ンザクション名を応答メッセージ６１４の宛先として識
別する。応答メッセージ６１４は、単方向メッセージで
あり、プロセス間通信サブシステム１２２によって受信
される。トランザクション名を応答メッセージ６１４の
宛先として識別したことに対する応答として、プロセス
間通信サブシステム１２２は応答メッセージ６１４を無
名応答ポート６００に渡し、この無名応答ポート６００
がそのテーブル内のトランザクション名を探索し、元の
クライアントである送信側タスク２１０のポートの名前
を返す。次にプロセス間通信サブシステム１２２は、代
用応答メッセージ６１６を公式化し、それに宛先として
元のクライアントである送信側タスク２１０のポート名
を入れる。次にプロセス間通信サブシステム１２２は、
元のクライアントである送信側タスク２１０に代用応答
メッセージ６１６を転送する。このようにして、元のク
ライアントである送信側タスク２１０は双方向通信を完
了し、応答を待つ間にアイドル状態を維持する必要がな
い。
【０１３６】ホスト・マルチプロセッサ１００と、マイ
クロカーネル１２０のＩＰＣサブシステム１２２内の無
名応答ポート６００とを示す図１０について説明する。
【０１３７】本発明によれば、図１０に示す無名応答ポ
ート６００はテーブルを含み、そのテーブル内の各項目
６０２は、双方向トランザクションのアイデンティテ
ィ、クライアントであるセンダー・タスクのアイデンテ
ィティ、およびサーバである受信側タスクのアイデンテ
ィティを含んでいる。タスク（Ａ）２１０がタスク
（Ｂ）２１０'にメッセージを送信する予定で、タスク
（Ａ）が応答を予想している場合、タスク（Ａ）は、そ
の待ち時間をより有効に利用することができ、送信／受
信タイプ・メッセージ６１０をＩＰＣサブシステム１２
２に送信することになる。図１１を参照すると、メッセ
ージ６１０の各種フィールドの例が分かるが、そのメッ
セージ６１０は、宛先がタスク（Ｂ）であり、メッセー
ジのタイプが送信／受信であり、メッセージのセンダー
がタスク（Ａ）であることを示している。本発明によれ
ば、タスク（Ａ）は、タスク（Ｂ）からの応答メッセー
ジ用の応答宛先として無名応答ポート６００を受け入れ
ることを指定している。メッセージ６１０は、メッセー
ジ"ＭＳＧ＿１"の本文も含んでいる。
【０１３８】図１０に示すように、メッセージ６１０は
ＩＰＣサブシステム１２２に送られる。送信側タスク
（Ａ）が宛先タスク（Ｂ）からの応答用として無名応答
ポートを受け入れることがメッセージ６１０の応答部分
によって示されているので、メッセージ引渡しライブラ
リ２２０はこのメッセージ６１０を無名応答ポート６０
０に引き渡す。図１０の無名応答ポート６１０は、その
テーブルに項目６０２を作成し、トランザクションとし
てトランザクション"ＡＮＯＮ＿１"の名前をリスト表示
する。項目６０２は、クライアントが送信側タスク
（Ａ）であり、サーバが受信側タスク（Ｂ）であること
もリスト表示する。
【０１３９】次にＩＰＣサブシステム１２２は、本発明
により、宛先タスク（Ｂ）のタスク・ポート５０６にメ
ッセージ６１２を転送する。メッセージ６１２の例は図
１１に示されているが、同図では、宛先がタスク（Ｂ）
として示され、メッセージ・タイプが送信／受信であ
り、センダーがタスク（Ａ）であることが分かる。本発
明によれば、応答は、無名応答ポート６００内の項目６
０２のアイデンティティである"ＡＮＯＮ＿１"として指
定されている。また、メッセージ"ＭＳＧ＿１"の本文も
タスク（Ｂ）に送られるメッセージ６１２に含まれてい
る。
【０１４０】本発明によれば、タスク（Ａ）は、タスク
（Ｂ）からの応答用の応答宛先として無名応答ポート６
００を受け入れるという指定とともにそのメッセージ６
１０を送信すると決定したので、タスク（Ａ）は、非同
期あるいはタスク（Ｂ）からの応答の時期または期間と
は無関係に動作することができる。
【０１４１】その間、タスク（Ｂ）は、タスク（Ｂ）向
けのすべてのサーバ機能をそのスレッド２４８'に実行
させる。その機能とタスク（Ｂ）の実行が終わると、タ
スク（Ｂ）は、サーバとしてＩＰＣサブシステム１２２
にその応答メッセージ６１４を送信する。
【０１４２】図１１に示すメッセージ６１４は、宛先
が"ＡＮＯＮ＿１"であることを示している。これは、タ
スク（Ｂ）からのメッセージ６１４が無名応答ポート６
００宛であることを意味する。メッセージ６１４のタイ
プは単方向メッセージであり、センダーはタスク（Ｂ）
であると示されている。メッセージ部分６１４の応答指
定部分はブランクのままであり、メッセージ"ＭＳＧ＿
２"の本文もメッセージ６１４に含まれている。
【０１４３】図１０のＩＰＣサブシステム１２２では、
宛先が"ＡＮＯＮ＿１"であると示されているので、応答
メッセージ６１４がメッセージ引渡しライブラリ２２０
によって無名応答ポート６００に渡される。無名応答ポ
ート６００のテーブルでは、トランザクション・アイデ
ンティティ"ＡＮＯＮ＿１"用の項目６０２が検出され
る。クライアントのアイデンティティは無名応答ポート
６００のテーブルから抽出され、クライアントはそのテ
ーブルでタスク（Ａ）と指名される。
【０１４４】本発明によれば、ＩＰＣサブシステム１２
２は、次にタスク（Ａ）に転送されるメッセージ６１６
を公式化する。図１１で分かるように、メッセージ６１
６の例の宛先はタスク（Ａ）であり、メッセージのタイ
プは単方向メッセージであり、センダーはタスク（Ｂ）
であり、応答フィールドはブランクのままになり、メッ
セージ"ＭＳＧ＿２"の本文はメッセージ６１６に含まれ
る。メッセージ６１６はクライアント・タスク（Ａ）の
タスク・ポート５０５に転送される。
【０１４５】このようにして、タスク（Ａ）２１０など
のクライアント・タスクは、別のタスクであるサーバ・
タスク（Ｂ）２１０'との双方向メッセージ交換に従事
することができるが、サーバ・タスク（Ｂ）がタスク
（Ａ）からのメッセージに対する応答を準備している
間、中断状態で待機する必要はない。
【０１４６】図７、図８、および図９に戻って説明する
と、マイクロカーネル・システム１１５またはアプリケ
ーション・プログラム１８０で並行実行中の多数のタス
クのそれぞれは、互いにやりとりする必要がある。
【０１４７】あるタスクから別のタスクに送られるメッ
セージは、制御部分およびメッセージ本文における各種
フィールドの位置に関して図２５に示すような所定の形
式を持つことになる。すべてのメッセージに一定の形式
を課すことも可能であるが、考えられる広範囲のフィー
ルド・カテゴリに対応するには、静的形式は新しいタイ
プのフィールドに対応できないほど大きくしかも拡張不
能でなければならないはずである。制御部分およびメッ
セージ本文の形式が可変であると、フレキシビリティや
変更が可能になる。しかし、受信側タスクがメッセージ
を暗号解読できるようにするには、タスクにその形式を
通知しなければならない。また、複合メッセージの制御
構造の形式記述は、メッセージ全体のかなりの部分を占
める可能性がある。２つのタスク間で同一形式のメッセ
ージを繰り返しやりとりするには、それぞれのメッセー
ジに同一の形式記述が存在すると、余分なオーバヘッド
がかなり発生する。
【０１４８】この問題は、あるタスクから別のタスクに
送られるメッセージのメッセージ制御構造に関して、図
７、図８、図９、および図２８に示す制御登録機能５０
０を提供することによって解決される。図７を参照して
説明すると、サーバとして動作しているときに、クライ
アントとして動作している他のタスク２１０からメッセ
ージの受信を希望する各タスク２１０'は、受信すると
予想されるメッセージ制御構造をプロセス間通信サブシ
ステム１２２に登録することができる。
【０１４９】図７のサーバ・タスク２１０'は、メッセ
ージ制御構造用の特定の形式を持つメッセージの受信を
予期している。この形式の登録を入手するため、サーバ
・タスク２１０'は、そのタスク・ポート５０６からプ
ロセス間通信サブシステム１２２のメッセージ引渡しラ
イブラリ２２０に登録要求５１０を送るが、その要求に
はサーバ・タスク２１０'のポート名と、登録を希望す
るメッセージ制御構造形式とが入っている。あるいは、
サーバ・タスク２１０'は、メッセージ制御構造形式の
記述そのものではなく、その記述を指すアドレス・ポイ
ンタを送信することもできる。
【０１５０】これに対して、プロセス間通信サブシステ
ム１２２は、登録ＩＤ番号、たとえば、図８の"Ａ１２
３"を発行し、ポート名"Ｂ"とメッセージ制御構造の形
式"ＸＹＺ"とともにその番号をメッセージ制御構造テー
ブル５０２の項目５０２'に格納する。そのテーブル５
０２に格納されているか、またはテーブル５０２内のポ
インタによって指し示されるメッセージ制御構造形式記
述"ＸＹＺ"は、同じ登録ＩＤの使用を意図するクライア
ントからのメッセージを妥当性検査するためにプロセス
間通信サブシステム１２２が後で使用するテンプレート
である。メッセージ制御構造登録テーブル５０２は、マ
イクロカーネル１２０内部に位置するかまたはメモリ１
０２のアドレス空間内の他の場所に位置することがで
き、マイクロカーネル１２０からアクセスすることがで
きる。プロセス間通信サブシステム１２２は、図７の５
１２において、メッセージ制御構造用として新たに発行
した登録ＩＤ番号"Ａ１２３"をサーバ・タスク２１０'
に返し、そこで図８に示すようにそのＩＤ番号が５１４
で格納される。
【０１５１】図８を参照して説明すると、サーバ・タス
ク２１０'へのメッセージ送信を希望する場合、クライ
アント・タスク２１０は、制御登録機能を使用するとい
う便宜を利用することができる。これを実行するため、
クライアントは、メッセージ制御構造用のサーバの登録
ＩＤのコピーを要求しなければならない。クライアント
・タスク２１０は、図８の５２０でサーバ・タスク２１
０'に転送するために、たとえば、図８の５１６にある
ようなメッセージ制御構造用のそれ専用の推奨形式"ｘ
ｙｚ"を図８の５１８でプロセス間通信サブシステム１
２２に送信する。サーバ・タスク２１０'は、クライア
ントから提示された形式"ｘｙｚ"がメッセージ制御構造
用のサーバの登録形式"ＸＹＺ"と互換性があるかどうか
を判断しなければならない。サーバ・タスク２１０'
は、図８の５０４にあるその登録形式"ＸＹＺ"からのわ
ずかな逸脱を受け入れるためのサーバ・タスク２１０'
の能力を考慮に入れて、互換性検査を実行するスレッド
５２２を有する。サーバの検査スレッド５２２は、クラ
イアントから受け取った提示形式"ｘｙｚ"を拒否するこ
とができ、その結果、サーバ・タスク２１０'は、要求
側のクライアント・タスク２１０にその登録ＩＤ"Ａ１
２３"のコピーを出すことを拒否する。あるいは、サー
バの検査タスク５２２は、サーバ・タスク２１０'がわ
ずかな逸脱に対応できる場合、そのような逸脱があって
もクライアントからの提示形式"ｘｙｚ"を受け入れるこ
とができる。これに対して、サーバ・タスク２１０'
は、図８の５２６で要求側のクライアント・タスク２１
０のポート５０５に転送して戻すために、図８の５２４
でそれ専用のメッセージ制御構造形式"ＸＹＺ"の登録Ｉ
Ｄ"Ａ１２３"をプロセス間通信サブシステム１２２に返
す。このＩＤ"Ａ１２３"は、図９の５０８でクライアン
ト・タスク２１０に格納される。
【０１５２】図９を参照して説明すると、その後、サー
バ・タスク２１０'へのメッセージ送信を希望する場
合、クライアント・タスク２１０は、メッセージに冗長
な形式記述を添える必要がなくなる。クライアント・タ
スク２１０とそのスレッド２４８は、単にメッセージの
本文を形式化し、５０８でサーバ・タスク２１０'の登
録ＩＤ"Ａ１２３"と、そのメッセージがサーバ・タスク
２１０'向けであることを示す表示を添えて図９の５３
０でプロセス間通信サブシステム１２２に正しくメッセ
ージを転送するのに十分な追加ヘッダ情報とをヘッダに
含めるだけである。プロセス間通信サブシステム１２２
は、クライアント・タスク２１０から５３０で受け取っ
たメッセージを検査して、受け取ったメッセージのメッ
セージ制御構造形式"ｘｙｚ"が受け取ったメッセージ内
に含まれる登録ＩＤ"Ａ１２３"に対応するメッセージ制
御構造テンプレート"ＸＹＺ"に十分一致することを確認
する。プロセス間通信システム１２２の検査モジュール
５３２が実行する検査は、受け取ったメッセージ内の所
定の複数のフィールドと、メッセージ制御構造テンプレ
ート内の対応するフィールドとの突合せを含むことがで
きる。プロセス間通信サブシステム１２２による検査が
正常に終わると、そのスレッド２４８'による処理のた
めに、図９の５３４でサーバ・タスク２１０'のポート
５０６にメッセージが転送される。
【０１５３】クライアント・タスク２１０またはサーバ
・タスク２１０'あるいはその両方は、アプリケーショ
ン・プログラム１８０、オペレーティング・システム・
パーソナリティ・プログラム１５０、パーソナリティ・
ニュートラル・サービス・プログラム１４０、またはマ
イクロカーネル１２０自体の一部にすることができる。
上記の各タイプのプログラムには、そのプログラムの目
的を実行するためのタスクとそのスレッドを作成しなけ
ればならない。このようなタスクは、マイクロカーネル
・システム１１５で並行実行される他のタスクと通信し
なければならない。このようなタスクは、ホスト・マル
チプロセッサ１００内の他のアプリケーション・プログ
ラム１８０で並行実行される他のタスクと通信しなけれ
ばならない。さらに、このようなタスクは、図１２に示
す分散処理ネットワーク内のように、各種ホスト・マル
チプロセッサ・システム１００'上で並行実行される他
のタスクとも通信しなければならない。このようなタス
クの１つから別のタスクへの各通信は、本発明による制
御登録によって提供される効率を利用することができ
る。
【０１５４】図１２は、分散処理配置で動作する２つの
ホスト・マルチプロセッサ・システムの機能ブロック図
であり、通信リンクを介して２つのホスト間でメッセー
ジを交換し、各ホスト・プロセッサ上のＩＰＣサブシス
テム１２２と制御登録モジュール５００がタスク間のプ
ロセス間通信を管理する場合を示している。ホスト１０
０は、分散処理アプリケーションについて前述したよう
に、ホスト１００'内の制御登録モジュール５００によ
り、ホスト１００'内のタスク２１１'に転送されるメッ
セージをホスト１００'とそのタスク２１１に送信する
ことができる。
【０１５５】マイクロカーネルは、メモリ１０２の諸領
域をマッピングするためのケイパビリティまたは権利を
管理する、ケイパビリティ・エンジン・モジュール３０
０も含んでいる。このケイパビリティ・エンジン３００
は、呼出しスケジューラ２３２、メッセージ引渡しライ
ブラリ２２０、一時データ・モジュール４００、制御登
録モジュール５００、無名応答モジュール６００、伝送
制御分離モジュール７００、共用メモリ・サポート・モ
ジュール８００、および高速パス・モジュール９００を
含む他の複数のモジュールとともに、ＩＰＣサブシステ
ム１２２に含まれている。これらのモジュールはすべ
て、ＩＰＣ１２２のプロセス間通信操作に貢献するサー
ビスを提供する。
【０１５６】ケイパビリティ・エンジン３００と一時デ
ータ・モジュール４００の詳細については、前述の関連
特許出願を参照することができる。ジェームズ・エム・
マジー他の"CAPABILITY ENGINE METHOD AND APPARATUS
FOR A MICROKERNEL DATA PROCESSING SYSTEM"という名
称の関連米国特許出願を参照されたい。また、ジェーム
ズ・エム・マジー他の"TEMPORARY DATA METHOD AND APP
ARATUS FOR A MICROKERNEL DATA PROCESSING SYSTEM"と
いう名称の関連米国特許出願も参照されたい。
【０１５７】本発明は、ユニプロセッサ、共用メモリ・
マルチプロセッサ、および分散プロセッサ・システム内
の複数コンピュータに適用される。図１２は、分散処理
配置で動作する２つのホスト・マルチプロセッサ・シス
テム１００および１００'の機能ブロック図であり、通
信リンク２５０を介して２つのホスト間でメッセージを
交換し、各ホスト・プロセッサ上のＩＰＣサブシステム
１２２と制御登録モジュール５００および無名応答モジ
ュール６００がタスク間のプロセス間通信を管理する場
合を示している。
【０１５８】図１２では、ホスト１００のスレッド２４
８'が、入出力アダプタ・プロセッサ１０８で実行され
る命令を送出する。実行のためにスレッド２４８'によ
って送出された命令は、入出力プロセッサ１０８からホ
スト１００'の入出力プロセッサ１０８'に送られるメッ
セージの形式化に必要な命令を含むことができる。この
ようなメッセージは、前述のようにＩＰＣ１２２の援助
によってクライアントのタスク（Ａ）２１０からタスク
（Ｂ）２１０'に送られるサーバ・タスク２１１または
２１１'に関する登録ＩＤを含むことができる。登録Ｉ
Ｄ情報は、メッセージに入れて通信リンク２５０を介し
て入出力プロセッサ１０８'に送られる。次に、タスク
２１１に関連するスレッド２４９が、入出力プロセッサ
１０８'内で実行され、ポート権とポインタ２４０に関
する情報をタスク２１１に転送する。前述の１回目の転
送と同様のもう１つのＩＰＣ転送をホスト１００'で実
行して、元々はホスト１００内のタスク（Ａ）から発生
したメッセージとともに登録ＩＤをホスト１００'内の
タスク２１１'に転送することができる。ホスト１００'
内のタスク２１１'に属すスレッド２４９'は、ホスト１
００'のプロセッサ１１２'内で命令を実行し、ホスト１
００内のタスク２１０から受け取るメッセージに含まれ
る情報を操作することができる。これは、制御登録モジ
ュール５００が常駐するそれ専用のメモリ１０２内でま
たは個別のメモリ１０２'を有するプロセッサ１１２'と
ともに、プロセス間通信を容易にする際に果たすことが
できる役割の唯一の例である。
【０１５９】第１節 サブシステム・レベルの対話 ＩＰＣ１２２サブシステムと、ＶＭ、ポート、タスクお
よびスレッドとの関係 1.1 単純なＩＰＣ１２２ マイクロカーネル１２０の他のすべてのサブシステムの
場合と同様、ＩＰＣ１２２とその対等機能との間の対話
／インタフェースを定義する必要がある。これにより、
ＩＰＣ１２２の活動が分離され、形式定義のジョブが容
易になるので有用である。この種の形式定義では、サブ
システム全体を置き換えて、システム・カストマイズの
強力なツールを提供することも可能になる。その最も単
純な形式のＩＰＣ１２２は、ポート、タスク、スレッ
ド、およびスケジューリング・オブジェクトと対話す
る。また、ＩＰＣ１２２は、一時ローカル記憶用のゾー
ン・サブシステムとも協力しなければならない。図１３
は、単純なメッセージの転送と、ＩＰＣ１２２と他のサ
ブシステムとの高レベルの対話を示している。
【０１６０】諸活動の高レベルの概要 メッセージ→ＩＰＣ１２２サブシステム →ゾーン： 一時記憶域の獲得 →ポート・サブシステム： （ケイパビリティ・エンジ
ン） ポート・オブジェクトの変換（タスク） ポート権の転送を含む、ポートへのメッセージのプッシ
ュ レシーバ用のポートの検査 スケジューラ： レシーバのスケジュール（スレッド） レシーバ→ＩＰＣ１２２サブシステム →ポート・サブシステム： （ケイパビリティ・エンジ
ン） ポートでのスリープ化 メッセージによる覚醒 →ゾーン： ポート権の転送を含む、メッセージのコピ
ー後の一時記憶域の解放
【０１６１】ＩＰＣ１２２サブシステムとその対等機能
とのインタフェースの単純性を保持し、今後の開発者が
より高度なメッセージ引渡しシステムを作成するための
基本サービスを提供するよう努力する間、ＩＰＣ１２２
は主要データ型として直接データとポートのみに作用す
るという考え方が保持されてきた。ケイパビリティ・エ
ンジン３００は、この基本ＩＰＣ１２２を実施したもの
である。ポートとのすべての対話は、ケイパビリティ・
エンジン３００を介して行わなければならない。ケイパ
ビリティ・エンジン３００は、アドレス範囲に関するケ
イパビリティを作成し、仮想アドレス空間にケイパビリ
ティをマッピングし、メッセージを待ち行列化し、レシ
ーバ・スレッドを待ち行列化し、レシーバ・スレッドと
メッセージの明示待ち行列解除を可能にするための各種
呼出しを提供する。（待ち行列化の呼出しはケイパビリ
ティ・エンジン３００インタフェースを介して行われる
が、待ち行列化の機構および方針は、ケイパビリティ・
エンジン３００に属さない。）また、ケイパビリティ・
エンジン３００は、同期または非同期のスタンドアロン
・メッセージ引渡しシステムとしても動作することがで
きる。
【０１６２】非同期の場合、メッセージが待ち行列化さ
れていると、レシーバ・スレッド呼出しはメッセージと
ともに元に戻る。あるいは、レシーバがブロックされて
メッセージを待っており、メッセージが別のスレッドか
ら送られてくる場合、ケイパビリティ・エンジン３００
は、受信スレッドをブロック解除し、メッセージととも
にそのスレッドを返す。ＳＶＣ呼出しが行われると、ケ
イパビリティ・エンジン３００は基本ＳＶＣまたは同期
インタフェースとして動作する場合もある。この場合、
ケイパビリティ・エンジン３００は、受信側タスクが交
換に必要な資源をセットアップしたかどうかを検査で確
認する。セットアップした場合には、ケイパビリティ・
エンジン３００は、ターゲット・ポートの受信権の所有
者と一致するようにアドレス空間を変更し、レシーバ資
源を関連付け、元に戻る。資源が使用不能の場合は、セ
ンダー・スレッドがブロックする。実行エンティティ
は、それ自身が同じ活動化環境（多くの場合、これは、
ほとんど同じカーネル・スタックを意味する）で呼出し
からコード内の同じ箇所に戻っているが、おそらく別の
アドレス空間で動作していることを検出することにな
る。
【０１６３】待ち行列化機構とスケジューリングの方針
は、ポート・オブジェクトに関連付けられており、ケイ
パビリティ・エンジン３００に特有のものではない。ケ
イパビリティ・エンジン３００が呼び出す特定のスケジ
ューリングおよび待ち行列化の方針は、ケイパビリティ
・エンジン３００への呼出しによってポートごとに変更
することができる。ケイパビリティ・エンジン３００上
の送信および受信用の呼出しとしては２組の呼出しがあ
る。一方の組の呼出しでは、メッセージ・フィールドの
内容がケイパビリティ・エンジン３００にとって不透明
になる。もう一方の組の呼出しでは、ケイパビリティ・
エンジン３００がメッセージに含まれるすべての着信ケ
イパビリティをレシーバの空間内の権利に変換する。第
２の組の呼出しを使用すると、ケイパビリティ・エンジ
ン３００は、基本非同期スタンドアロン・メッセージ引
渡しユーティリティとして動作することができる。
【０１６４】1.1.1 ケイパビリティ サブシステムの観点から見ると、ＩＰＣ１２２サブシス
テムによって実際に扱われる唯一のデータ型は、直接デ
ータとポート権である。これは、ケイパビリティとして
のポート権の用法を探求するまでは意外なことと思われ
るかもしれない。ポート権は、タスクのアドレス空間の
一部分またはエクステント・メモリ領域をマッピングす
る権利を引き渡す手段として使用することができる。こ
のため、作成ケイパビリティ呼出しおよびマップ・ケイ
パビリティ呼出しによって少量のデータを直接引き渡す
が大量のデータを転送する手段としてポートを作成する
ような、メッセージ引渡しシステムを作成することも可
能である。このポートは、タスクのマッピング済みアド
レス空間の一部を記述するトークンまたはハンドルにな
る。この方法は、実行可能であるが、タスク内のスレッ
ドがケイパビリティ・エンジン３００の呼出しを行っ
て、そのアドレス空間の特定領域用のケイパビリティを
返し、これをターゲット・タスクに引き渡し、ターゲッ
ト・タスク内のスレッドによってそのケイパビリティを
ターゲット・タスクの仮想アドレス空間にマッピングさ
せることが必要になるはずなので、ある程度の非効率と
いう欠点がある。にもかかわらず、その単純性と機能
性、要するにその基本特性により、このケイパビリティ
は、本発明のメッセージ引渡しアーキテクチャを構築す
る元になる完全な基本要素を提供する。
【０１６５】ケイパビリティは、メモリ領域をマッピン
グする権利として定義することができる。マッピングさ
れる領域は、別のタスクのアドレス空間の一部であって
もよく、その場合、ケイパビリティは共用メモリ資源に
なるか、またはエクステント・メモリ領域になる可能性
がある。エクステント・メモリ領域の場合、ケイパビリ
ティは、このメモリ領域上の唯一のハンドルである。ポ
ート権は、送信または単一送信になる可能性がある。こ
のようにして、共用領域の発信元は、その領域の無許可
追加共用を抑止する場合もあれば、その共用領域が提示
されたタスクがポートの基本要素copy_sendにより共用
領域アクセスを他のアドレス空間まで拡張できるように
する場合もある。共用およびsend_onceはcreate_capabi
lity呼出しのオプションである。send_onceオプション
はエクステント・メモリ領域ならびに共用領域ケイパビ
リティについて使用可能であるが、それはレシーバの使
用を制限するものなので恩恵はない。レシーバは、ケイ
パビリティを受信してマッピングすると、同一メモリ領
域上に新しいケイパビリティを自由に作成することがで
きる。send_once権ではなく、送信権を使用すること
は、複数共用ケイパビリティの基礎であり、２進共用を
確立するための代替方法を表している。
【０１６６】1.2 メッセージ引渡しライブラリ ケイパビリティ・エンジン３００で実施される単純なメ
ッセージ引渡しは、完全に機能するものであるが、従来
のメッセージ引渡しモデルで得られる多くのパフォーマ
ンス最適化を利用する機会をもたらすものではない。ケ
イパビリティ・エンジン３００によって提供される適正
レベルの機能により、ターゲット・タスクの監視プログ
ラム空間に共存メッセージ・パッケージを配置すること
ができる。このライブラリは、必要なときにケイパビリ
ティ・エンジン３００へのローカル呼出しを行うことが
できるはずである。ＩＰＣ１２２パッケージが常駐する
空間は、各タスクにマッピングされたカーネル空間の一
部ではなく、むしろ、タスクごとに特権ユーティリティ
によってマッピングされた空間領域である。タスクはそ
のパーソナリティにより、次にパーソナリティはパーソ
ナリティ・ニュートラル・サービスにより、タスクのア
ドレス空間の各部分を監視プログラム・モードのライブ
ラリ・リポジトリとして割り振れるようになるはずであ
る。また、これらは、システム規模の共存ユーティリテ
ィによりカーネル・サービスにとってローカルと思われ
るこの空間にトラステッド共用ライブラリをダウンロー
ドできるようになるはずである。このため、単一システ
ムで任意の数のカストマイズ・メッセージ引渡しフロン
ト・エンジンが使用可能になる可能性がある。アプリケ
ーションは、基礎となるケイパビリティ・エンジン３０
０ではなく、メッセージ引渡しライブラリ２２０を呼び
出すはずである。
【０１６７】ケイパビリティ転送構造は強力である可能
性があるが、従来のメッセージ引渡しでは、不必要に高
価である。ＩＰＣ１２２ライブラリ（以下、ＩＰＣ１２
２という）は、基礎となる論理データ型としてこのケイ
パビリティをサポートし続けるが、可能なときは、新し
いデータ型により、ケイパビリティの明示的作成と変換
を回避する。この新しいタイプは、厳密にＩＰＣ１２２
内部にあるので２次的なものであるが、被参照データ型
と呼ばれる。この被参照データ型も、その機能がケイパ
ビリティ・サブシステムとケイパビリティ転送呼出しと
の組合せとして記述できるという意味では、２次データ
型である。一例として、タスクＡが２ページ分のデータ
をタスクＢに送信する必要があるとする。タスクＡは、
この２ページに対応するそのアドレス空間の領域用の明
示ケイパビリティを直接獲得するためにケイパビリティ
・エンジン３００を呼び出し、このケイパビリティを基
本ケイパビリティ呼出しによりもう一度タスクＢに引き
渡す可能性があり、タスクＢはケイパビリティ・マップ
呼出しを行う可能性がある。これに対して、本発明で
は、本発明の被参照データ型と直接データ・サイズ・フ
ィールドを使用してデータを送信することができる。後
で示すように、多くのメッセージ引渡しパラダイムで
は、明示ケイパビリティが作成されず、タスクＡのアド
レス空間に関連するデータを引き渡すためにケイパビリ
ティ・サブシステムが呼び出されないので、本発明では
健全なパフォーマンスの向上が得られる。
【０１６８】被参照データ型は、ユーザのアドレス空間
内の位置を指すポインタであり、直接データ・サイズ変
数または特定のインタフェース定義によって示された暗
黙サイズが付随する。（後者の場合、サイズはメッセー
ジ制御構造を介してカーネルに伝送されるはずであ
る。）被参照領域を扱うには、ＩＰＣ１２２は、ケイパ
ビリティを直接マッピングするためにレシーバが本来は
呼び出さなければならない同種のケイパビリティ・イン
タフェースまたはパフォーマンス主導可変部を使用する
必要がある。この可変部は、センダーとレシーバの両方
の同期が取られたときに明示メッセージ作成ステップを
スキップする機会から発生する。このような可変部は、
構成要素レベルでは透過のＩＰＣ１２２ライブラリの内
部最適化を表す。同期が行われる条件と、それによって
作成される機会については本明細書において後で探求す
るが、一般に同期は、すべてのＲＰＣケースと、ほとん
どの送信／受信ＩＰＣ１２２のケースと、同期送信ＩＰ
Ｃ１２２とに存在し、さらにセンダーより先にレシーバ
がメッセージ引渡し点に到着するような一般的なＩＰＣ
１２２のケースにも存在する。センダーとレシーバの並
置は一般的なので、パフォーマンス強化のためにそれに
よって提供される機会によって重要な考慮事項になる。
【０１６９】被参照データ型交換をケイパビリティの転
送とほぼ等価にするためには、明示ケイパビリティ・マ
ッピング呼出しによって得られるマッピングの選択を保
持する必要がある。レシーバはメッセージ受信後にケイ
パビリティを調べ、それをマッピングしないと決定する
可能性があるので、このフレキシビリティは、レシーバ
の資源に重大な影響を及ぼす可能性がある。新しいＩＰ
Ｃ１２２サブシステムでは、センダー側の被参照最適化
をレシーバの被参照最適化から分離することによってこ
れを達成している。被参照によって送られるデータは、
ケイパビリティとしてまたはマップ済み被参照フィール
ドとして受け取ることができる。これに対して、ケイパ
ビリティとして送られたデータは、それ自体としてまた
は被参照フィールドとして受け取ることができる。ケイ
パビリティ・サブシステムのマッピングの機能性を一致
させるためには、レシーバが「任意の場所での割振り」
を行えるようにし、割振りが行われる特定のアドレスを
選択できるようにする必要がある。ＩＰＣ１２２サブシ
ステムはこれを許諾し、さらに連続割振り区域（これ
は、連続領域へのケイパビリティの順次マッピングを模
倣したものである）ならびにその個々の配置への被参照
領域の収集も可能にする。
【０１７０】当然のことながら、ＩＰＣ１２２サブシス
テムは、ケイパビリティ・エンジン３００の機能を使用
してメモリ・オブジェクト・ケイパビリティを作成し操
作しなければならないが、従来のＩＰＣ１２２の機能を
より単純な構成要素に分解することは、サブシステム・
レベルの対話およびアーキテクチャの形式化における重
要な前進ステップである。単純なメッセージ引渡しモデ
ルと、被参照データ型を含むモデルとの機能等価の証明
を厳密に形式化すると、以下のような結果になる。１：
被参照とケイパビリティとの変換は完了し（範囲／定義
域の点ではクローズ）、センダーおよびレシーバに関し
て完全に独立している。２：依然として全範囲の受信側
用フレキシビリティを許諾するケイパビリティが得られ
る。３：ケイパビリティに関するケイパビリティ呼出し
の分解済みセットとして得られない被参照データのマッ
ピングにはいかなる機能も存在しない。
【０１７１】ただし、現在定義されている新しいメッセ
ージ引渡しパラダイムは、タスクのアドレス空間のマッ
プなし部分へのデータの制御配置に対応しておらず、マ
ップ済み部分への制御配置のみ対応していることに留意
されたい。マップなし配置は、ターゲット・ケイパビリ
ティでのケイパビリティ呼出しを介して単純なモデルに
よってサポートされる。着信被参照データのターゲット
になる領域を最初にマッピングすることによって模倣で
きるので、現在、このオプションを被参照ケースに含め
る計画はない。前述の通り、ケイパビリティの引渡しは
メッセージ引渡し機能によってサポートされているの
で、形式モデルの観点からはすべてのvm_mapの組合せを
模倣する必要はない。被参照データについてサポートさ
れているケースは、純粋にパフォーマンスの観点から、
または従来のＲＰＣまたはＩＰＣ１２２モデルをサポー
トする場合に意味をなす。
【０１７２】第２節 バッファおよびアドレス空間資源
の分散 被参照データ・サブクラス 被参照データ・クラスの作成後は、位置の決定と割振り
のモーメントがきわめて重要な課題になる。ケイパビリ
ティの場合、アプリケーションは、ターゲット呼出しに
おけるターゲット・パラメータの具体的な使い方を知る
ことによってデータの位置を決定する。当然のことなが
ら、このような具体的な知識は、ＩＰＣ１２２サブシス
テムには使用できない。被参照パラメータで使用するた
めにバッファ処置の知識をＩＰＣ１２２サブシステムに
連絡するには、パラメータ・タイプのサブセットを理解
し、形式化しなければならない。被参照データ・クラス
の適正サブセットである個別のデータ・クラスは、位置
または割振りに関する特定の制限によって決まる。特定
の被参照パラメータがこのような新しいデータ・クラス
のどれに属すかをレシーバが連絡できるようにするた
め、ＩＰＣ１２２インタフェースに関する準備が行われ
ている。これらのサブクラスは、被参照バッファに収容
されているデータを使用する方法によって決まる。すな
わち、状態なしサーバは、応答メッセージが返された後
では呼出しに関連するデータを必要としない。データの
一時性により、関連の割振り済みアドレス空間の再使用
が可能になり、したがって、一時サーバの存在が可能に
なる。もう１つの例では、媒介物または代理人として動
作しているレシーバは、データ領域にアクセスする必要
がなく、このため、このような領域をその空間にマッピ
ングする必要がない可能性がある。このようなレシーバ
は、ケイパビリティ選択を選ぶ可能性がある。新しいメ
ッセージ引渡しモデルにより、このグループにさらに基
礎クラスが追加されることが明らかになる可能性があ
る。しかし、新しい項目は、１群の被参照例を取ってお
くレシーバまたは送受信対（共用メモリの場合と同様）
による特定の反復可能なデータ処理によって決まる集合
に制限する必要がある。これは、以下に概要を示すすべ
ての現行サブクラスの基礎である。ケイパビリティとそ
の明示マッピングによって引き渡されるものを上回る機
能性をメッセージ引渡しライブラリ２２０に持ち込んで
はならない。追加機能のロール・インに基づくパフォー
マンス最適化を伴う新しいメッセージ引渡しパラダイム
が必要な場合は、別個の新しいライブラリを作成する必
要がある。このライブラリは、メッセージ引渡しライブ
ラリ２２０からインタフェースと実行パスの概念を自由
に借りることができるが、そうする義務があるわけでは
ない。このようなライブラリは、ケイパビリティ・エン
ジン３００上でＩＰＣ１２２ライブラリの対等機能とし
て機能するはずである。対等機能間のメッセージの互換
性が想定されていない恐れがあるが、新しいライブラリ
・アーキテクチャによって互換性を維持する努力を行う
必要があるはずである。
【０１７３】2.1 一時データ４００ ＲＰＣ（遠隔プロシージャ呼出し）転送、多くの送受信
対ＩＰＣ１２２（プロセス間通信）呼出し、および一部
の見かけ上非同期のＩＰＣ１２２呼出しでは、レシーバ
は、受信される被参照データ・パラメータの一部が必要
なのは短時間にすぎないことを前もって把握する。この
時間は何らかのトランザクションによって拘束される。
このトランザクションは、システムに（ＲＰＣにより）
知られている場合もあれば、アプリケーション（非同期
ＩＰＣ１２２転送で使用中の場合）だけに知られている
場合もある。ＩＰＣ１２２インタフェースにより、レシ
ーバは、パラメータ・レベル・フラグをセットすること
によってデータの一時性をＩＰＣ１２２サブシステムに
知らせる。ＩＰＣ１２２の実現により一時データ４００
にいくつかの特性がもたらされ、一時データは境界とは
無関係に始まる可能性があり、インスタンスごとにレシ
ーバによって提供されるメモリ領域で他のサーバ一時パ
ラメータとともにまとめて連結されると判断されてい
る。レシーバは、その後の呼出しにバッファを再利用す
ると完全に予想されているが、この再使用の正確な性質
はレシーバに任されている。
【０１７４】2.2 永続データ これは、被参照データ用のデフォルト・クラスである。
すなわち、共用データや一時データなどではない。この
クラスに入る項目には、サブシステムがバッファ処置最
適化の基礎として使用できる使用上の特別な制約が一切
ない。その結果、レシーバによる具体的な命令を使用せ
ずに（詳細については、3.2.4.3項を参照）、今後の転
送または長期常駐の際に最も便利になるようにデータが
配置される。さらに、デフォルト挙動が従来のＣＭＵベ
ースのメッセージ引渡しセマンティクスと互換性を維持
している必要がある。このようなセマンティクスには、
ターゲット・アドレス空間の事前マップ解除領域にデー
タを配置することが含まれていた。デフォルトの永続デ
ータ処理は以下の通りである。１：それぞれのバッファ
をページ境界から始める。このため、マップ解除および
再マップにより今後の領域除去および転送が可能にな
る。パフォーマンスが達成されると見なされることもあ
るが、データが非ページ境界上に現れ、他のバッファの
各部がこれらのページの各部を共用している場合には、
この方法は厄介なものになるはずである。しかも、資源
のマッピングとマップ解除は、人工物と残余を伴う恐れ
がある。２：データ領域がページ方式ではない場合、最
後のページの未使用部分は後続パラメータによって使用
されない。この場合も、今後のマッピングとマップ解除
を容易にするためである。３：永続データ・パラメータ
は上書きオプションの対象となる。これは、従来のＣＭ
Ｕメッセージ引渡しシステムとの互換性を提供するもの
で、個々のパラメータの呼出し固有（または、デマルチ
プレクシング・システムの場合はサーバ固有である方が
一般的である）の処置の方法を示すものである。
【０１７５】2.3 共用データ 共用データ・クラスは、センダーおよびレシーバによる
特定のセットアップと初期設定を必要とする。セットア
ップ・フェーズでは、センダーは、明示的にそのマップ
済みアドレス空間の一部を共用領域としてレシーバが使
用できるようにしなければならず、レシーバは、明白に
この領域を共用領域として受け入れ、それをレシーバ専
用のアドレス空間の一部に振り向けなければならない。
したがって、その空間に関連するアプリケーションに関
する明示的な知識がなければ、共用データ領域が任意の
空間に入ることはできず、これとは反対に、ローカル・
スレッドに関する明示的な知識がなければ、任意の空間
領域を別のタスクと共用することはできない。共用デー
タ・サポートは、物理的に共用されている区域の任意の
部分が現在使用可能になっていること（データでいっぱ
い、データが消去されたなど）を、あるタスクが別のタ
スクに通知できるようにする、かなり恵まれたパッケー
ジである。ＩＰＣ１２２の統合共用メモリ・サポート８
００を共用メモリ空間およびセマフォアの特定の随時使
用から分離しているものは、２つの当事者が共通バッフ
ァを共用しない状況におけるパラダイムのサポートであ
る。アプリケーション・コードは、非ローカルにするこ
とができ、それでも共用パラダイムを使用することがで
きる。システム・インテグレータがパフォーマンス上の
考慮点に気付かなければならないのは明らかであるが、
このような考慮点が妥当なものであると判断された場合
は、非ローカルのクライアントまたはサーバも可能であ
る。さらに、使用可能になっている空間部分を記述する
ために形式的な言語が確立されているので、これは、Ｉ
ＰＣ１２２サブシステムに把握されている。特殊なハー
ドウェアを使用する反射メモリ技法は、アプリケーショ
ン・レベルの２つの当事者にとって透過な方法で使用す
ることができる。
【０１７６】2.4 サーバ割振り資源 その名前が暗示するように、このバッファ・サブクラス
はＲＰＣに特有のものである。ＲＰＣでは、トランザク
ション全体、すなわち、送受信が単一のメッセージ制御
構造に記述される。クライアント向けのデータ用に必要
になるバッファ領域は、デフォルトにより、要求（クラ
イアントのメッセージ送信）時に発生する。これは、重
要クラスのプロシージャ呼出し（呼出し側が呼び出され
たプロシージャから期待するデータ用のバッファ空間を
提供する際に使用する呼出し）に予想セマンティクスを
提供するために必要である。バッファがサーバによって
提供される場合には、ＩＰＣ１２２サブシステムによる
バッファ割振りを抑制する必要がある。可能な共存のう
ち最も単純なものを可能にするためには、server_alloc
atedオプションの使用により、ＩＰＣ１２２レベルのバ
ッファ割振りを抑制することが必要になる。必ずバッフ
ァを期待し、ローカル呼出し用のライブラリ・ルーチン
によってこのバッファを作成させるサーバ側を受け入れ
るつもりでも、パフォーマンスに関連する抑制理由がま
だ存在する。サーバは、クライアントが見たがっている
データのコピーをすでに持っている可能性がある。serv
er_allocateオプションを完全にサポートするというこ
とは、サーバがクライアント送信パラメータを設定して
このデータを直接指し示せるようになっていることを意
味し、これは、明らかにローカル対話では選り抜きの方
法である。サーバが着信バッファを必ず受け入れなけれ
ばならない場合、ローカル・ケースでは問題が発生する
恐れがある。中間ライブラリ・ルーチンは強制的にバッ
ファを割り振るはずで、サーバはその永続ソースからこ
のバッファにデータをコピーしなければならないはずで
ある。同様のシナリオは遠隔ケースでも発生し、それに
よってトランザクションの速度が低下するが、パフォー
マンス上の影響は少ない。
【０１７７】2.5 センダー（サーバ）割振り解除 センダー割振り解除バッファ・サブクラスは、ＩＰＣ１
２２と、ＲＰＣのクライアント側に存在する。その特徴
は、関連データがレシーバに連絡された後でパラメータ
に関連するメモリ資源の割振り解除をセンダー側が希望
することである。割振り解除オプションが存在すると、
ＩＰＣ１２２サブシステムのユーザは、本来不必要なＶ
Ｍサブシステムへの呼出しを回避することができる。
【０１７８】メッセージ引渡しが明示的に行われるよう
な環境になっている多くの場合、可能なパフォーマンス
・プロファイルのうちの最善のものはバッファの再使用
に基づいたものになると主張することができる。しか
し、バッファの再使用は、メッセージ引渡しが明示的に
行われる場合でも必ずしも実際的ではない。空間にマッ
ピングされ、操作され、送信されるデータについては、
おそらくＩＰＣ１２２センダー割振り解除によって十分
対応できる。
【０１７９】ＲＰＣでは、呼出しパラメータの１つによ
って指し示されたバッファの割振り解除を呼び出された
プロシージャが行うことを呼出し側が期待するような場
合をサポートする必要がある。server_deallocが使用で
きない場合に、遠隔ケースでこの挙動をサポートするに
は、アプリケーションに戻る前に送信から戻った時点で
クライアント側スタブによって明示的にバッファを割振
り解除することが必要になるはずである。ＲＰＣは、se
rver_deallocというサーバ側の同様のオプションもサポ
ートする。server_deallocは、サーバがクライアントに
返すデータに関連するバッファ、サーバがデータを受け
取るバッファ、または両方の機能に対応するバッファに
ついて使用することができる。サーバ送信の場合には、
serv_dealloc挙動はsend deallocのミラーになる。クラ
イアント送信の場合には、server_dealloc機能は、serv
er_deallocに関連するサーバが永続バッファの規則に従
うように動作しているように見える。このため、サーバ
内での後続呼出しの操作がより容易になる。さらに、サ
ーバがその応答を行ったときに割振り解除されるバッフ
ァは、応答データに関連するバッファになり、必ずしも
要求に応じて割り振られたものにはならない。
【０１８０】2.6 伝送情報 通常のヘッダ・フィールドとともに、メッセージ引渡し
モデルは、任意選択のパラメータにより進行中の転送に
関する拡張情報を収集する機会を提供する。このような
任意選択のパラメータは、ほとんど直接データである
が、直接データでない場合は、一時サブクラスのメンバ
ーであると見なされる。すべての直接データと被参照ポ
インタは通常のヘッダ情報の後に続く。拡張フィールド
内のデータは、ほとんどＩＰＣ１２２サブシステムとの
直接通信である。サブシステムに対する要求が行われた
場合、トランザクションのもう一方の当事者から提供さ
れる情報は、カーネルが送信する情報に影響する可能性
がある。この例としては、ＮＤＲとSTATUSがある。（Ｎ
ＤＲは基礎となるハードウェア・レベルのデータ形式の
記述であり、STATUSはエンドポイント・ルーチンの機能
状況である。詳細については、第３節を参照。）トレー
ラなどの他のフィールドは、セクション全体がセンダー
・スタブとレシーバ・スタブとの対等通信に引き渡され
ている可能性がある。
【０１８１】ヘッダは、任意選択の伝送制御情報の直接
データ部分とともに、ＩＰＣ１２２呼出しの被参照パラ
メータとして送信される。呼出しから戻ると、ヘッダな
どは、送られたときに使用したのと同じバッファ内に連
続して返される。オーバランの場合には、「オーバラン
時割振り」オプションが設定されていれば、データはＩ
ＰＣ１２２サブシステムが割り振ったバッファ内に現れ
る可能性がある。拡張伝送制御情報に関連する非直接デ
ータは、一時サーバとして送られる。これは、そのデー
タが、ヘッダおよび拡張直接制御情報が現れるのと同じ
バッファに現れるが、それに連続していない可能性があ
ることを意味する。
【０１８２】2.7 メモリ・ケイパビリティ メモリ・ケイパビリティは他のポート権とは区別しなけ
ればならない。というのは、ＩＰＣ１２２サブシステム
は、レシーバが希望する場合にそれらをマッピングでき
なければならないからである。しかも、ＩＰＣ１２２サ
ブシステムは、被参照記述からメモリ・ケイパビリティ
を作成できなければならない。ＩＰＣ１２２は、クライ
アントが被参照データを送信し、レシーバがケイパビリ
ティとして引き渡される情報を要求する場合をサポート
しなければならない。メモリ・ケイパビリティは、デー
タのスナップショット転送またはセンダーとレシーバと
の間で共用されるメモリ・バッファを表す場合がある。
共用ケイパビリティをサーバに引き渡すには、サーバが
前もって用意する必要はない。サーバは、ケイパビリテ
ィの共用設定を検出できるようになり、そのマッピング
に関して適当と判断したアクションを行う。
【０１８３】第３節 メッセージ引渡しの概要、主要副
構成要素 3.1 実行構造の概要 ケイパビリティ・エンジン３００は、基本ＳＶＣおよび
厳密非同期メッセージ引渡しインタフェースを生成す
る。ケイパビリティ・エンジン３００の基本メッセージ
・サービス上でＲＰＣ、より複雑なＩＰＣ１２２、受動
サーバなどをエミュレートするのは簡単なはずである
が、パフォーマンスの点で負担しなければならない重大
なペナルティが発生する恐れがある。このため、ＩＰＣ
１２２ライブラリでは、ケイパビリティ・エンジン３０
０の不透明メッセージ転送オプションを使用することを
決定する。さらに、ＲＰＣおよび双方向ＩＰＣ１２２で
は、メッセージ引渡しライブラリ２２０が、ＳＶＣ呼出
しによってブロック化レシーバを除去し、レシーバの有
無を検査する必要性を取り除き、それを待ち行列解除し
て、スレッドの引渡しを行うことを決定する。レシーバ
が待機していない場合は、ケイパビリティ・ブロック化
センダー待ち行列呼出しによる場合と同様に、センダー
がブロックされ、待ち行列化され、明示メッセージは作
成されない。明示ケイパビリティを作成せずにほとんど
の被参照転送を行えるので、これは非常に重要である。
このようなデータ転送は、ケイパビリティ・エンジン３
００と協議せずに行うことができる。以下に２組の図を
示すが、一方はメッセージ引渡しライブラリ２２０とケ
イパビリティ・エンジン３００による同期メッセージ転
送を示し、もう一方は非同期メッセージ転送を示す。受
信スレッドが最初にメッセージ・ポートに到着する場合
は、非同期処理が同期ケースとしての挙動を示す。同期
ケースでは、応答用の実行パスの概要が明示的に示され
ない。これは、非同期ケースの例２のインスタンス（受
信待機を伴う送信）であるからである。
【０１８４】図１４の例１は、待機中のレシーバが存在
しないポートにメッセージを送る場合のパスの概要を示
している。ＲＰＣの場合、アプリケーションはライブラ
リ・スタブ（図示せず）を呼び出し、そのスタブがその
呼出し側のためにローカル・プロシージャ呼出しをエミ
ュレートする。このスタブは、呼出し固有のメッセージ
の個々の断片をアセンブルし、メッセージ引渡しライブ
ラリ２２０にトラップする。メッセージ引渡しライブラ
リ２２０は、監視プログラム・モードで存在するが、ケ
イパビリティ・エンジン３００に対して、ＳＶＣである
ローカル呼出しを行う。ケイパビリティ・エンジン３０
０は、機能呼出しによりレシーバ待ち行列を検査する。
呼び出される機能は、ケイパビリティ・エンジン３００
によって設定される可能性のあるポート・オブジェクト
のフィールドによって決まる。これにより、待ち行列化
機構をカストマイズすることができる。上記の例では、
メッセージを受け取るために待機しているものは何もな
いので、メッセージ引渡しライブラリ２２０は継続（必
要な場合）をセットアップし、それをＳＶＣ呼出しで送
信する。この呼出しには、スレッド・ブロックではな
く、スレッド引渡しについてのみ継続を使用するための
オプションもある。このようなオプションに基づくケイ
パビリティ・エンジン３００は、継続の有無にかかわら
ず、センダーをブロックする。ケイパビリティ・エンジ
ン３００は、カストマイズ可能な待ち行列化プロシージ
ャをもう一度呼び出す。
【０１８５】図１５の例２では、もう一度着信送信メッ
セージを受け取るが、今回はケイパビリティ・エンジン
３００による待機中のサーバの有無を確認するチェック
が成功する。適正サーバがスレッド引渡しのターゲット
になる。カストマイズ可能な待ち行列呼出しによりこの
場合、ケイパビリティ・エンジン３００は、センダーと
レシーバの両方を有し、スレッド引渡しを続行すること
ができる。スレッド引渡しから戻ると、メッセージ引渡
しライブラリ２２０は、メッセージの直接転送に移るこ
とができる。ただし、いかなるときもメッセージの形式
または内容がケイパビリティ・エンジン３００に公表さ
れていないことに留意されたい。このため、メッセージ
引渡しライブラリ２２０には、メッセージの形式と内容
を選択する際に完全なフレキシビリティが与えられる。
今後のライブラリによって、有用と思われるデータ変換
構造のある種のバッファ割振りがこのモデルに移される
可能性がある。メッセージ引渡しライブラリ２２０は、
サーバとレシーバとの間での直接データおよび被参照デ
ータの直接移動に移行する。ケイパビリティ・エンジン
３００への呼出しが必要になるデータの種類は、ポート
およびケイパビリティの変換のみである。これには、ケ
イパビリティおよびポートの直接転送だけでなく、ケイ
パビリティのマッピング（サーバは着信ケイパビリティ
のマッピングを要求する）またはマップ解除（サーバは
着信被参照バッファをケイパビリティとして受け取るこ
とを要求する）も含まれる。この場合も、ケイパビリテ
ィ・エンジン３００の介入なしでスケジューリングが行
われる。センダーまたはクライアントはすでにブロック
されているので、クライアントが明示応答ポートに対応
するようになるまでは、ケイパビリティ・エンジン３０
０への別の呼出しを行う必要がない。（サーバが無名応
答を受け入れない場合は、現在メッセージを受け取って
いるエンティティによって、応答の無保証が返され
る。）サーバがレシーバのスケジューリング特性を伴う
場合は、スケジューラが呼び出される。
【０１８６】図１６の例３では、受信側から見た場合を
示す。レシーバは到着するが、待機中のセンダーが存在
しないと判断するだけである。レシーバはケイパビリテ
ィ・エンジン３００によりブロックする。ケイパビリテ
ィ・エンジン３００は、ポート・オブジェクト固有の待
ち行列化機能を呼び出す。当然のことながら、ライブラ
リは、ブロックの処置、すなわち、継続時にブロックす
るかどうかを決定する。ライブラリおよびカスタム待ち
行列機能の責任は、レシーバがブロック中であるときに
送信が到着しないように保証すること、またはブロック
が行われた後にセンダーの有無をもう一度検査すること
である。
【０１８７】図１７の例４は、例２と同じであるが、レ
シーバの視点から見たものである。ユーザ・レベル（非
監視プログラム・モード）では、メッセージは、直接つ
ぎあわされる（ＩＰＣ１２２送信／受信）か、ＲＰＣの
ターゲット・エンドポイントを支援するように設計され
たサーバ・ループで作成される（プロシージャ呼出しト
ランザクションで被呼側へのローカル呼出しをエミュレ
ートする）。いずれの場合も、監視プログラム・レベル
のメッセージ引渡しライブラリ２２０へのトラッピング
が行われる。センダーを獲得するためのケイパビリティ
・エンジン３００の呼出しが成功した後、メッセージ引
渡しライブラリ２２０は、それ自体がセンダーとレシー
バを備えていることを検出する。このライブラリは、例
２のようにメッセージの転送に移行するが、スレッド引
渡しを実行する必要はない。スレッドがクライアントの
スケジューリング特性を伴うことになっている場合は、
スケジューラが呼び出される。この場合もクライアント
はブロックする。例２のように、ケイパビリティ・エン
ジン３００は、応答ポートが明示的である場合のみ呼び
出される。
【０１８８】同期ケースの場合と同様に、メッセージ引
渡しライブラリ２２０は、レシーバの有無の検査から開
始するが、レシーバが検出されないときは、図１８のイ
ンタフェースの非同期性により、ライブラリは形式的な
メッセージを作成するという高価な仕事に従事しなけれ
ばならない。直接データは変換せずにコピーされ、ポー
ト権はその処置に応じて生成されてメッセージ内に配置
され、ケイパビリティはすべての被参照パラメータ用と
して作成され、ケイパビリティ権はその処置に応じてプ
ッシュされる。このような活動のいずれも、ケイパビリ
ティ・エンジン３００の直接サポートが必要である。メ
ッセージは、ケイパビリティ・エンジン３００への呼出
しによって待ち行列化される。この待ち行列機能は、ポ
ート・オブジェクトに関連付けられ、ケイパビリティ・
エンジン３００への呼出しによってカストマイズ可能で
ある。メッセージに関する優先順位情報は、メッセージ
に入れて引き渡してもよく、カストマイズした待ち行列
機能によって認識することができる。
【０１８９】図１９のこのケースでは、非同期モデルが
同期モデルと同様の挙動を示す。明示メッセージを作成
する必要がないので、非同期ケースの例２と例３との組
合せのパフォーマンスは、非同期の例１と例４との組合
せによって表されるものより大幅に改善される。非同期
の例２と同期の例２との唯一の違いは、非同期ケースで
保留応答が欠落している点である。応答に対応する必要
がなく、センダーは自由に戻ることができる。
【０１９０】図２０の例３は、同期ケースの例３と同一
である。例３の挙動を経験することによって、センダー
が送信時に例２の挙動を経験すると判断される。これ
は、非同期モデルのパフォーマンスを意識しているユー
ザが、可能な限り、レシーバが先にポートに到着するよ
うに努力しなければならないことを意味する。
【０１９１】図２１の例４では、ポート固有の送信待ち
行列を呼び出し、待ち行列機能固有の基準に基づいて適
切なメッセージを回復する。メッセージは、変換せずに
レシーバに転送可能な直接データで構成される。また、
メッセージはポートおよびケイパビリティを含むことも
できる。ポートおよびケイパビリティはケイパビリティ
・エンジン３００への呼出しによって変換しなければな
らない。小さい被参照フィールドは、明示メッセージの
作成時にケイパビリティ作成のオーバヘッドを回避する
ためにメッセージ引渡しライブラリ２２０によって隠蔽
される場合もある。この場合も、レシーバはそのフィー
ルドをケイパビリティとして受け取ることを選択できる
が、被参照バッファとして受け取る場合は、ケイパビリ
ティ・エンジン３００を呼び出す必要がなくなる。
【０１９２】3.2 メッセージ構造 メッセージ引渡しライブラリ２２０に関連するメッセー
ジ構造には、メッセージ引渡しインタフェース内で予期
される機能要素が入っている。当然のことながら、この
構造には、上記で概要を示したバッファ処置ならびに基
本データ型のための備えがある。ただし、ヘッダに常駐
する、伝送制御全体に関連するフィールドがメッセージ
構造の残りの部分に連続している必要がないという点
で、メッセージ構造は他の多くのシステムとは異なって
いる。メッセージ構造は、分離可能な４つのエンティテ
ィを識別する。ヘッダはそのうちの２つを指し示し、メ
ッセージ・パラメータ自体は残りの２つを指し示す。４
つのエンティティとは、１：ヘッダ、２：メッセージ制
御構造（特定の呼出しに関連する特定のパラメータに関
する情報が入っている）、３：メッセージ（呼び出しに
関連する直接データ、被参照ポインタ、ポート、および
明示ケイパビリティ）、４：被参照領域である。
【０１９３】領域の連続化に関する制約は一切ない。す
べての領域を連続形式にする際にある程度のパフォーマ
ンス上の利点が得られる場合もあるが、その領域が別々
の時点に形成される場合は、連続化するためにそれらを
再コピーする必要はない。図２２は、メッセージ・レイ
アウトの概要を示す図である。
【０１９４】メッセージ・パラメータ情報は、メッセー
ジ・バッファ内の各パラメータを個別に記述する。この
記述により、パラメータのデータ型、サイズ（固定サイ
ズとして直接、またはカウント・パラメータを指すポイ
ンタを介して間接に）、および被参照の場合のデータに
関連するバッファの処置が完全に定義される。
【０１９５】メッセージ引渡しライブラリ２２０の設計
フェーズでは、実施態様によって発揮されるパフォーマ
ンスが関連データ構造のレイアウトに大きく左右される
可能性があるという事実に留意した。これは、メッセー
ジ制御構造のパラメータ記述子の全ビットのレイアウ
ト、ならびにより大きいレベルでの制御情報、メッセー
ジ情報、および伝送情報の分離に影響してきた。さら
に、重要な使用モードの多くでは、基礎構造に関連する
情報が様々な時点かつ様々な箇所で生成されることが認
識された。メッセージ構造の設計全体にこれを反映する
ことが唯一の良好なプログラミング形式だった。さらに
分析を進めたときに、このように良好な形式を承諾した
結果、重大なパフォーマンス上の利益が得られることが
分かった。
【０１９６】3.2.1 ターゲット・エンドポイント・メ
ッセージ・データの分離 エンドポイント・アプリケーションがメッセージの引渡
しを認識し、それに直接関与しているアプリケーション
環境では、メッセージ・データを分離する有用性が限ら
れている。渡されるデータが大きい場合、過剰バイト・
コピーを回避するために広範囲の被参照データ型が使用
できる。しかし、実際のメッセージ引渡しトラップを実
行するためにエンドポイント・アプリケーションが代理
人ライブラリ・ルーチンを呼び出すような、大きく興味
深い一連のメッセージ引渡しの使い方がある。このよう
な使い方としては、ＲＰＣの定義域全体と、何らかの興
味深いＩＰＣ１２２のケースが含まれる。エンドポイン
ト・アプリケーションが、代理人ユーザ・レベルのメッ
セージ引渡しライブラリ２２０ルーチンを呼び出すとい
う動作においてかなり大きいパラメータのコピーを作成
する場合、データをメッセージ・ヘッダに連続させるた
めにそのデータを再コピーするだけでなく、そのコピー
を使用できることは、好ましいはずである。この場合
も、メッセージが小さいか、または代理人サービスがシ
ステム・スタック変換を把握していない場合には、代理
人は必ずメッセージ・データ・コピーに戻ることができ
る。
【０１９７】代理人に送られるパラメータのアドレスを
把握し、そのパラメータが連続し、既知の順序になって
いると想定することによって、代理人は、図２３に示す
ように、パラメータ・ブロックのアドレスをメッセージ
・ヘッドのアドレスとして渡すことができる。これを支
援するものとして、これまでに概要を示した被参照サブ
タイプに余分なタイプ、すなわち、被参照パラメータを
指すポインタが追加された。これは、その呼出し側の範
囲内で呼び出された機能によって引数を直接変更するこ
とを範囲規則の違反と見なすＣ言語などの言語では、デ
ータ構造に変更したポインタを返す手段として非常に一
般的である。
【０１９８】3.2.2 静的メッセージ制御情報の分離 基礎構造に分離されたメッセージの個々の断片のうち、
おそらく最も重要なものはメッセージ制御構造である。
メッセージ制御情報の分離によって認識されるパフォー
マンス上の利益は、サポートされるメッセージ引渡しの
範囲全体で重要なものになる可能性がある。メッセージ
制御構造に含まれる情報がエンドポイントの観点からト
ランザクションを完全に定義することを強調する必要が
ある。（これに対する例外と見なすことができる受信側
のオーバライドについては、3.2.4.3項で説明する。）
ヘッダに含まれるメッセージ呼出しに関する情報は、メ
ッセージ・サービスの呼出し側とメッセージ引渡しライ
ブラリ２２０との対話である。ヘッダおよびその任意選
択の伝送制御フィールドによって２つのエンドポイント
間で情報を引き渡すことができるが、送信側でオプショ
ンを設定するために受信側でオプションを設定する必要
はなく、その逆も同様である。図２４は、メッセージ制
御構造の高レベル・スケッチである。
【０１９９】１次記述子は、メッセージのパラメータと
の間に１対１のマップ式全射写像関係を有する。すなわ
ち、第１の記述子が第１のパラメータに対応し、第２の
記述子が第２のパラメータに対応し、以下同様になる。
さらに、１次記述子は連続している必要がある。このた
め、メッセージ制御構造の記述子セクションの先頭から
の単純なオフセットによって第３のパラメータに対応す
る記述子を見つけることができる。１次記述子は、特定
のパラメータに必要なすべての状態情報を収容できるほ
ど大きくない場合もある。このような場合には、１次記
述子の１つのフィールドが、２次記述子の先頭に対応す
るメッセージ制御構造内のオフセットを指し示す。２次
記述子は、サイズが様々であり、１次記述子の後に現れ
るが、特定の順序はない。
【０２００】圧縮され、慎重に考慮された構造内でメッ
セージ形式を完全に定義することは、インタフェース定
義の観点から重要である。サーバは、クライアントによ
って送信されたメッセージ制御構造の単純な２進比較検
査によって、サーバが予期するメッセージ形式と、セン
ダーが提供したものとの一致を検査することができる。
一致が検出されると、サーバは、そのメッセージ内のポ
インタがポインタになり、ポートがポートになるという
保証を受けることになる。当然のことながら、これは、
関連データに対してセマンティクス上の意味を保証する
わけではないが、ポート権用のランダム・ポインタおよ
びランダム値からサーバを保護することを意味する。サ
ーバがこのように保証されるのは、メッセージ制御構造
（およびサーバ提供のオーバライド）がメッセージ・パ
ラメータ形式用として唯一の判定基準を保持しているか
らである。
【０２０１】さらにメッセージ制御構造を特殊にしてい
るのは、実行前にそれが定義される点である。不必要な
作業を回避するため、代理人は、ＢＳＳまたはその他の
記憶域内のエンティティの指すヘッダ・ベースのメッセ
ージ制御構造ポインタを指し示し、その結果、代理人機
能が呼び出されるたびに一時ローカル記憶域にその構造
を作成する必要を回避することができる。このようなメ
ッセージ制御構造の事前定義は、別の理由から重要であ
る。事前スクリーニングされたメッセージ制御構造に基
づいてメッセージの転送を可能にする規則をセットアッ
プすることができる。センダーは、登録ラベルを提供す
るだけでよい。これにより、メッセージ制御情報の送信
だけでなく、非トラステッド送信用のセンダーとレシー
バとの実行時比較も回避される。
【０２０２】メッセージ制御構造の分離は別の意味で有
用であった。すなわち、その使用の中止が容易になっ
た。メッセージが直接データのみを伝達する場合、メッ
セージ引渡しレベルの変換またはいかなる種類の介入も
必要ではない。このようなメッセージは「単純」メッセ
ージと呼ばれてきた。単純メッセージは、単方向または
双方向のＲＰＣまたはＩＰＣモデルのいずれかにするこ
とができる。互換性のある形式かどうかのテストをサー
バが必要とする場合は、単純メッセージでもメッセージ
制御構造を必要とすることがある。ただし、このような
ケースは非常に限られているはずである。サーバが特定
のメッセージを予期しているか、または１群のメッセー
ジＩＤを認識する場合は、間違った形式の単純メッセー
ジなので、単に不要情報データを含むものとは異なる挙
動を一切示さない。サーバがメッセージ制御構造を必要
とする可能性のある唯一のケースは、メッセージＩＤに
よって区別されない可変単純データ形式を含むメッセー
ジ上である。データが自己定義でない限り、レシーバ
は、メッセージ制御構造を調べてパラメータ境界を見つ
けなければならないはずである。単純メッセージの場
合、センダーは、メッセージ引渡しライブラリ２２０に
メッセージ制御構造を提供する必要がなく、メッセージ
引渡しライブラリ２２０はレシーバにそれを提供しな
い。レシーバがメッセージ制御構造を必要とする転送の
場合は、単純オプションをオフにする必要がある。
【０２０３】メッセージ制御構造は、送信中にすべての
パラメータを定義するためにセットアップされている。
これは、事前定義されていないメッセージを受け入れる
レシーバにとっては重要である。すべてのパラメータの
定義がないと、サーバは、着信メッセージを解析できな
いはずである。これまで、すべての直接データを単一フ
ィールドであると宣言することによってメッセージ引渡
しのパフォーマンスを改善する努力が行われてきた。新
しいメッセージ制御構造上のプロトタイプ・コードによ
る実験によれば、直接データ・フィールドによる解析は
パフォーマンス上の影響がほとんどないことが分かって
いる。（直接データを解析するためのループは、パラメ
ータ処置フィールドの１つのビットを検査することと、
それが直接データであると認識したときに次のパラメー
タを指し示すためにメッセージ・データ構造内のオフセ
ットにカウント・フィールド値を追加することで構成さ
れている。次のパラメータ記述子へのバンプとループ検
査だけが追加アクションである。）このような証拠があ
っても、オーバヘッドは不要であると主張する人がいる
ものである。万一、何らかのメッセージが直接データの
合体から恩恵を受けるような場合には、このような合体
を代理人ライブラリ・レベルで実行することができる。
代理人は、メッセージ・フィールドを再配置して、すべ
ての直接データ・フィールドをひとまとめにし、転送用
の１つのフィールドとしてそれにラベルを付けることが
できる。このため、メッセージ引渡しライブラリ２２０
は、現実のものか認識上のものかは問わず、パフォーマ
ンス上のいかなる妥協も行わずにすべてのパラメータを
識別するという便宜をそのモデル内に保持することがで
きる。
【０２０４】3.2.3 伝送制御情報の分離７００ メッセージ構造の伝送制御情報サブセクションは、ヘッ
ダと、任意選択の１群の伝送変数とで構成される。この
サブセクションに含まれる情報の特徴は次の２点であ
る。第一に、メッセージ引渡しライブラリ２２０の呼出
し側によって直接提示されるのは情報である点である。
第二に、その起点または最終用途が何であれ、そのフィ
ールドと、多くの場合はデータとが、メッセージ引渡し
ライブラリ２２０の呼出し側およびそのライブラリ自体
によって解析され、解釈される点である。メッセージの
残りの部分からメッセージ制御情報を分離することの動
機づけは、メッセージ・データおよび静的制御情報の分
離の場合と同じである。メッセージの伝送部分で検出さ
れたフィールドの集合は、メッセージ引渡しモデル（Ｉ
ＰＣ１２２、ＲＰＣ代理人）とは無関係に、同時に同じ
ルーチンによって作成され、操作される。このため、不
必要なコピーが行われないことが保証される。さらに、
伝送セクションのために厳密に実施される対話ポイント
はメッセージ引渡しライブラリ２２０になる。これによ
り、メッセージ・バッファ形式だけでなくメッセージ形
式を決定するセンダー／レシーバの対話を探すための１
つの場所としての、メッセージ制御セクションの非常に
重要な役割が保たれる。センダーが影響する可能性があ
るのは、メッセージ制御構造によってレシーバに送達さ
れたメッセージの形式だけである。メッセージ・バッフ
ァの形式は、メッセージ制御構造と上書きバッファによ
って完全に決まる。（上書きバッファを使用すると、レ
シーバは、ケイパビリティおよび被参照領域の最終処置
についてローカル・オーバライドを実行することができ
る。詳細については、3.2.4.3項を参照されたい。）呼
出しからメッセージ引渡しライブラリ２２０に返される
ヘッダの形式は、呼出し時に伝送制御セクションで選択
したオプションによって決まる。このため、受信呼出し
が行われたときのレシーバの伝送制御セクション要求を
反映するヘッダ形式を持つメッセージが、レシーバに返
される。一方、メッセージ・バッファ形式は、被参照お
よびケイパビリティの処置がサーバによる上書きバッフ
ァの使い方の影響を受けている場合を予想して、センダ
ーによって送られるデータと、センダーのメッセージ制
御構造が示すものとを反映することになる。
【０２０５】呼出し側は、メッセージ転送の特定の態様
を把握または左右したい場合、伝送制御セクションを介
してライブラリと対話する。データは伝送セクションを
介してセンダーからレシーバに引き渡すことができる
が、このデータはメッセージ引渡しライブラリ２２０に
よって解釈される。センダーからレシーバへの通信の場
合、遠隔当事者のアクションとは無関係に、形式の観点
から受入れ可能なデフォルト挙動が必ず存在するような
インタフェースが定義される。このため、遠隔当事者が
選択した伝送制御オプションは、ローカル・メッセージ
の形式に一切影響しない。これは、受け取ったメッセー
ジの形式、すなわち、STATUS、Trailer_Request、およ
びMessage_Control_Structure要求にセンダーが影響し
うる場合にメッセージ制御構造をメッセージ形式決定の
唯一の発生源として維持する際に重要である。
【０２０６】メッセージ引渡しライブラリ２２０とレシ
ーバとの直接対話の単純な例は、ＮＤＲ要求で示すこと
ができる。メッセージが送信されると、センダーは、ND
R_Supplyパラメータを含めるというオプションを使用で
きる。これは、メッセージ・データの基礎となる基本デ
ータ型がホスト・マシンと一致しない場合のみ、行われ
る。メッセージが送達されたときにNDR_Requestオプシ
ョンがアクティブであれば、デフォルトにより、メッセ
ージ引渡しライブラリ２２０はホスト・マシンのＮＤＲ
情報を引き渡す。センダーがNDR_Supplyを選んだ場合
は、メッセージ引渡しライブラリ２２０は、センダーが
提供した情報を引き渡す。
【０２０７】伝送制御システムのもう１つの重要な能力
は、それがセンダーとレシーバとの間で非解釈データを
引き渡すことができる点である。このようなデータは、
トレーラによってエンドポイント・メッセージ・バッフ
ァを変更せずに代理人から代理人に引き渡すことができ
る。トレーラには、順序番号とセキュリティ・トークン
を含む所与の固定フィールドが存在するが、これ以外
は、オープン・データ・フィールドである。トレーラの
サイズが事前合意によって固定され、センダーがデータ
を送信し、レシーバがそれを要求する場合、トレーラ
は、直接データの任意選択ヘッダ域に到着することもあ
る。トレーラ内のデータの量が呼出しごとに変化する場
合は、レシーバがtrailer_requestの被参照バージョン
を要求することもできる。（trailer_requestの直接デ
ータ・バージョンはカウント・パラメータを含み、レシ
ーバが送信するカウントは受信される最大値になり、そ
れ以上の着信データは切り捨てられる。このカウント変
数は、最大値までの返送されるデータの量を反映するよ
うにメッセージ引渡しライブラリ２２０によって変更さ
れる。一時データ４００バッファに設けられた空間まで
のサイズを受信するには、レシーバは被参照バージョン
を使用しなければならない。）いずれの場合も、センダ
ーがトレーラを提供しないと、受け取ったトレーラには
要求された定義済みフィールドのみが収容されることに
なる。何も要求されない場合は、サイズがゼロになる可
能性がある。定義済みトレーラ・フィールドを超える区
域は、送信されたときにメッセージ引渡しライブラリ２
２０によってレシーバに引き渡される。レシーバがトレ
ーラ情報を得るために決定した方法は、センダーに一切
影響しない。センダーは、直接または参照によりその情
報を自由に送信することができる。
【０２０８】メッセージ引渡しライブラリ２２０の呼出
し側は、呼出しの準備を行うときにヘッダ構造をセット
アップする。このヘッダ構造はバッファ内に位置する
が、このバッファは、返されたヘッダ情報だけでなく、
呼出し側が要求した伝送オプションに関連する直接デー
タを受け入れるだけの大きさでなければならない。ま
た、これは、要求された直接データ（被参照オブジェク
ト）用の空間も含んでいる。これは、伝送制御パラメー
タに関連する被参照領域が一時サーバと見なされること
を暗示している。後で詳述するように、ＲＰＣ内のサー
バまたは双方向ＩＰＣ１２２のターゲットがメッセージ
引渡しライブラリ２２０を呼び出す場合、ヘッダが位置
するバッファは、上記で概要を示したすべての伝送制御
情報だけでなく、サーバ一時データ４００も受け入れる
ように準備しておかなければならない。返されるバッフ
ァの形式は、先頭がヘッダで、次に直接任意選択制御情
報が続き、次に伝送制御情報に関連するものを含むサー
バ一時フィールドが続く。
【０２０９】図２５は、伝送制御構造の概要を示す図で
ある。ヘッダの固定部分は、メッセージ引渡しの種類、
すなわち、送信、受信、送受信、ＲＰＣ、ＩＰＣ１２
２、双方向メッセージの応答ポートの種類を決定する。
ヘッダの任意選択部分は、任意選択の伝送フラグ・フィ
ールドによって決まる。任意選択フィールドはそれぞれ
１ビットに対応する。このようなフィールドは、存在す
るときには必ず順序通りに現れなければならない。被参
照である任意選択伝送フィールドの場合は、一時バッフ
ァ・アドレス域を指し示すために、そのパラメータ用の
任意選択フィールド項目のサブフィールドの１つが使用
される。もう１つのサブフィールドは、間接バッファの
サイズをバイト数で記述する。
【０２１０】3.2.4 センダーとレシーバの制御情報間
の関係 すべてのメッセージ引渡しシステムは、センダーとレシ
ーバのメッセージ形式と識別を調整するという問題を処
理しなければならない。メッセージ形式の問題はメッセ
ージ引渡しパラダイムの外部でセンダーおよびレシーバ
によって解決されると想定して、その問題を無視するシ
ステムもある。また、それが何であるか、ならびにそれ
を受け入れるべきかどうかを判定するためにレシーバが
解析しなければならない、一部または完全定義済みのメ
ッセージを受け渡すシステムもある。どちらの観点もそ
れぞれ利点がある。完全トラステッド・メッセージを送
信する組込みシステムでは、プロセッサに総称メッセー
ジ解析の責任を負わせる必要はほとんどない。これに対
して、汎用メッセージ引渡しオペレーティング・システ
ムでは、レシーバがメッセージ形式を検査しなければな
らない場合に、センダーとレシーバとの非トラステッド
通信の必要性が実際に発生する。汎用メッセージ引渡し
でも、メッセージを解析してその形式を判定する総称受
信サーバを使用する。メッセージ制御情報の分離によっ
て、メッセージ引渡しライブラリ２２０は、両方のパラ
ダイムを効率よくサポートすることができる。
【０２１１】単純メッセージの場合を除き、メッセージ
引渡しライブラリ２２０に対して送信メッセージ呼出し
を行うときに、センダーはメッセージ制御構造を提供し
なければならない。この規則は、サーバ入力がまったく
得られそうもない非同期メッセージの場合には絶対に必
要である。同期ケースでは絶対に必要というわけではな
いが、それによって規律が得られる。センダーからのメ
ッセージ制御構造の提供を要求することによって、レシ
ーバはいつでも着信メッセージ形式の検査を選択するこ
とができる。さらに、非トラステッド・クライアントか
ら送達される無意味なメッセージの数が減少する可能性
がある。クライアントがメッセージを送信し、その解析
のためにサーバのメッセージ制御構造をあてにした場
合、間違ったメッセージが費やす時間の一部は、検知で
きない程度に不正確にクライアントのメッセージ・パラ
メータを解釈する能力に基づいていた。その場合、非ト
ラステッド・クライアントはサーバに不要情報データを
送信するはずである。クライアントがメッセージ制御構
造を送信しなければならない場合、サーバは、非トラス
テッド・クライアントのメッセージ制御構造を検査し、
不要情報データの受信を回避する。（当然のことなが
ら、クライアントは、いつでも故意に不要情報データを
送信することができる。）また、センダーにメッセージ
制御構造を送信させると、意図せずにクライアントに損
害を及ぼす可能性も低減される。クライアントがサーバ
のメッセージ制御情報パラダイムで間違ったポートにメ
ッセージを送信し、そのメッセージが意図せずに続くこ
とになっている場合、クライアントはマップ解除と上書
きに大量トラック分のデータを取られる可能性がある。
すなわち、クライアントは、２つの直接パラメータがあ
ることを予期して、サーバにメッセージを送信する可能
性がある。サーバは、第１のパラメータが被参照であ
り、さらに、クライアントが送信した後で関連バッファ
が除去されると確信している。この場合、送信したばか
りのクライアントのデータが有効アドレスのように見え
ると、クライアントは、意図せずにそのアドレス空間の
一部をマップ解除することになる。
【０２１２】図２６は、容認された規約のクライアント
提供メッセージ制御情報を伴わない、メッセージ制御構
造の使い方の２つの例を示している。
【０２１３】メッセージ引渡しライブラリ２２０は、す
べての非直接データ・パラメータを変換するためにセン
ダー提供のメッセージ制御構造を調べる。しかし、サー
バは、唯一の形式を持つメッセージを期待するか、また
はデマルチプレクシング・サーバの場合はメッセージＩ
Ｄによって形式が決まるメッセージを期待している。こ
のため、サーバは、メッセージ制御構造を要求せず、そ
の想定に基づいて動作する。このようなサーバは、故意
にまたは意図せずに間違った形式のメッセージを送信す
るクライアントによって損害を受ける可能性がある。
【０２１４】クライアントのメッセージ制御構造の受信
により、サーバは、自由に着信メッセージの形式を予想
と照らし合わせることができる。サーバがデマルチプレ
クシングの場合は、まずメッセージＩＤを検査して、こ
の特定の着信エンティティが１組の制御構造のどれと一
致しなければならないかを判定する。形式が未知の場合
は、図２７に示すようにメッセージ・データを解析する
ためにメッセージ制御構造を調べる。サーバが別のサー
バの媒介物として動作しているときは、この最後のシナ
リオが最も可能性の高いものになる。通信サーバを実現
するためにメッセージ引渡しインタフェースを使用する
ことは、メッセージ引渡しライブラリ２２０の能力を示
す良い例になりうる。通信ノードが２つの場合は、統合
共用メモリデータ型を使用することができる。これらの
ノードが共通メモリ（またはハードウェアがサポートす
るミラーリング・メモリ）を共用する場合は、明白なメ
モリ・コピーを使用せずに転送を行うことができる。共
用しない場合は、通信コードを調整せずに自動的にデー
タの転送が行われる。
【０２１５】3.2.4.1 完全定義済み送受信互換性検査 サーバとクライアントがメッセージ形式を決定した場合
またはデマルチプレックス・サーバの場合でも、一連の
メッセージＩＤによって形式が削り取られた。サーバ
は、クライアントが正しいことを実行し、適切なメッセ
ージを送信すると確信できない場合もある。実際にメッ
セージ形式を検査することは、歴史的には面倒なことだ
った。インタフェースの変更や緻密さの欠落によって、
検査に穴が残ることが多かった。しかも、検査が複雑に
なればなるほど、費用がかかる。メッセージ引渡しメッ
セージのアーキテクチャによって、このような困難がほ
ぼ解消される。メッセージ・バッファで検出されたデー
タ型を記述するのに必要な情報は、メッセージ制御構造
で検出することができる。さらに、メッセージ制御構造
のうち、着信パラメータの定義に関連する部分には、他
の情報が一切入っていない。このため、サーバが格納し
たメッセージ制御テンプレートと着信クライアント・メ
ッセージ制御構造との２進比較が可能になる。メッセー
ジ・バッファ情報の抽出は、平均パラメータが８バイト
で完全に記述されるようになっている。したがって、４
パラメータのインタフェース用のメッセージ・バッファ
のレイアウトは、３２バイトを１バイトずつ比較するこ
とによって検査される可能性がある。転送制御プロトコ
ルに関連するもののような、インタフェースの他の部分
が他の場所に記述されるという事実は、バイト比較プロ
トコル検査の伝送オプションに不必要な制約が設けられ
ないことを意味する。
【０２１６】メッセージ制御構造は、要求と応答の両方
についてバッファおよびバッファ処置を記述するものな
ので、この場合、ＲＰＣシステムに留意する必要はな
い。サーバが、異なるローカル・バッファ処置オプショ
ンを選択するクライアントをサポートする必要が生じる
と思われるのは、非常に妥当なことである。例として、
どちらも共通サーバとの対話を必要とする２つのクライ
アントについて考察する。これらのクライアントはとも
に、被参照フィールドをサーバに送信することを必要と
している。一方は送信後にバッファの除去を望み、もう
一方はその保持を希望している。どちらのクライアント
もトラステッドではないという理由だけでサーバが一方
のクライアントを拒否するとしたら、厄介なことになる
はずである。パラメータ処置の全ビットは、このケース
を処理できるように設定されている。クライアント・バ
ッファ処置に関連するビットのフィールドが用意されて
いる（フラグ・ワードのビット２３〜１８。メッセージ
制御構造の詳細については、付録Ａを参照されたい）。
２進検査の前にテンプレート内のこれらのビットとクラ
イアントが導出したメッセージ制御構造にマスクをかけ
ることによって、サーバは非トラステッド・モードで両
方のクライアントに対応することができる。
【０２１７】上記の例によって、もう１つの重要な点が
明らかになる。送受信互換性の検査は、任意選択である
だけでなく、ユーザ・レベルでもある点である。ユーザ
・レベルのlibmkライブラリ・サポートは、呼出し可能
マクロとしてＲＰＣメッセージ制御構造用のクライアン
ト・オプション・マスク・オーバライドと、１バイトず
つの２進検査を含むことになるが、サーバは、それが適
当と判断したものであれば、どのような部分検査も自由
に形成することができる。たとえば、一時としてバッフ
ァを送信するクライアントならびに永続としてバッファ
を送信するクライアントを、deallocフラグ・セットに
よって許可することができる。（データ型については、
2.1項および2.4項を参照されたい。）
【０２１８】3.2.4.2 制御情報登録５００ メッセージ制御情報の抽出と、制御構造を必要としない
単純メッセージの存在、送信側検査のフレキシビリテ
ィ、およびそれを無視するためのオプションは、いずれ
も機能上およびパフォーマンス上、重大な意味を持って
いる。しかし、非検査トラステッド・ケースにほぼ匹敵
するパフォーマンスを非トラステッド・クライアントに
もたらすような、パフォーマンス最適化の機会がもう１
つある。しかも、それは、複合メッセージでも呼出しご
とにメッセージ引渡しライブラリ２２０の空間にメッセ
ージ制御構造をコピーしないようにすることによって、
トラステッドと非トラステッドの両方の速度を改善す
る。この方法は、メッセージ制御構造登録５００を伴う
ものである。
【０２１９】登録への関与を希望するサーバは、サーバ
の１組のインタフェースに関連するメッセージ制御構造
を求める登録呼出しを行う。登録呼出しパラメータは、
メッセージ制御構造と、関連ポートと、返される登録Ｉ
Ｄ用のプレースホルダである。メッセージ制御構造は、
ポートの持続期間の間、そのポートに登録された状態に
なる。このため、その登録ＩＤを獲得するセンダーは、
ポートの持続期間の間、そのＩＤが有効であることが保
証される。登録サービスによるメッセージの送信を希望
するクライアントは、メッセージ制御構造を送信し、お
そらくメッセージＩＤを含み、関連登録番号を要求す
る、単純な呼出しでサーバに連絡する。サーバは好みの
検査を自由に実行することができるが、実際には絶対的
な互換性が必要になる。たとえば、サーバがクライアン
トのローカル・バッファ処置の違いを検出し、とにかく
登録ＩＤを返す場合には、クライアントはその登録ＩＤ
の使用時に損害を受ける恐れがある。サーバは、その特
定のメッセージＩＤと正確に一致しないか、またはその
ＩＤ用の追加のメッセージ制御構造を登録するような登
録要求を見捨てる場合もある。その場合、サーバには、
その特定のメッセージＩＤ用の両方の登録番号、サーバ
のテンプレート登録番号、および登録されたクライアン
トを検査する責任があるはずである。サーバは、今後の
登録要求と照らし合わせるために手元のクライアント・
メッセージ制御構造のコピーを保管する必要もある。ク
ライアントは、登録番号の発行を拒否されても、自由に
非登録転送を試みることができる。
【０２２０】長期間持続するサーバのメッセージ制御構
造の登録は、トラステッドと非トラステッド両方のクラ
イアント／サーバ対のために間違いなく表示される。し
かし、非トラステッドの場合には、メッセージ制御構造
をサーバにコピーして、呼出しごとに形式の互換性を検
査する必要が除去されるので、上記の点が最も重要にな
る。登録サーバは、登録センダーおよび非登録センダー
の両方と一緒に機能する。このため、センダーが１〜２
回だけレシーバと対話する予定であれば、メッセージ制
御構造登録ＩＤを取り出すために余分な呼出しを行うこ
とは価値があるとは見なされない可能性がある。
【０２２１】図２８は、センダーによるメッセージの登
録と使用を示す図である。クライアントが新たに獲得し
た登録番号で送信を試みると、メッセージ引渡しライブ
ラリ２２０は、ポート関連待ち行列を検査して、メッセ
ージ制御構造が適切かどうかを確認する。メッセージ制
御構造はメッセージ引渡しライブラリ２２０にとってロ
ーカルなので、制御構造のコピーは回避される。さら
に、ＲＰＣでは、クライアントが応答を待っている間は
メッセージ制御構造を手元に保管する必要があり、進行
中の転送ごとに制御構造が１つずつ保管される。登録の
場合、登録番号だけを格納すればよい。メッセージ引渡
しライブラリ２２０は、２つの重要な理由でクライアン
トがサーバから登録情報を要求しなければならないよう
にセットアップされる。第一に、それによって、メッセ
ージ引渡しライブラリ２２０で管理しなければならない
コードが低減される。第二に、サーバは、どれが登録済
みメッセージ形式と一致するか、どれが一致しないかを
判定する際の完全なフレキシビリティを維持している。
上書きオプションと応答上書きを使用すると、広範囲の
着信メッセージ形式を互換性あるものにすることができ
る。これを分類し、適当と判断した１組の形式をサポー
トすることは、個々のサーバの責任である。
【０２２２】3.2.4.3 上書きバッファ メッセージ獲得時に自分の空間での永続データの配置と
ケイパビリティの受取りを左右したいと希望するレシー
バは、上書きバッファを提供しなければならない。上書
きバッファによって左右されるデータの型は、１：永続
データ（ただし、永続被参照の選択にはサーバdealloc
のケースも含まれることに留意されたい）と、２：ケイ
パビリティがある。上書きバッファにより、メモリのマ
ップ式区域にケイパビリティを書き込むよう要求するこ
とが可能である。あるいは、着信永続被参照バッファが
ケイパビリティに変換される。
【０２２３】上書きバッファは、伝送制御構造のオプシ
ョンにより提供される。このため、当然のことながら、
上書きバッファはローカルの呼出し側にのみ影響する。
上書きには追加機能がある。上書きバッファは、列挙ま
たは索引付けされるケイパビリティと被参照永続領域を
検出されたものと見なす。着信メッセージを走査する
と、最初に検出されたケイパビリティまたは永続被参照
領域が受信上書きバッファ内の最初の記述子の影響を受
け、２番目に検出されたものが２番目の影響を受け、以
下同様に処理される。他のタイプの介入パラメータは一
切影響しない。この場合の唯一の例外は、レシーバが収
集オプションを選択するときである。この場合、複数の
被参照領域からのデータまたはケイパビリティに関連す
るデータがまとめて連結され、上書き記述子が指定した
位置からメモリに書き込まれる。任意の数の記述子をこ
のように連結することができるので、数を厳密にするオ
プションまたは"upto"が用意されている。厳密ケースで
は、収集記述子域を満たすために指定の数の領域を正確
に検出しなければならず、それができなければエラーが
返される。"upto"のケースでは、記述子に指定された領
域の数が着信メッセージで使用可能な領域の数より大き
い場合、メッセージが進行する。上書き領域の記述子が
メッセージ内で検出される領域の原因になっている場合
は、その記述子が無視される。上書き記述子が原因で、
永続被参照パラメータおよびケイパビリティ・パラメー
タの数がメッセージに現れるものより少ない場合も同様
である。上書き構造によって列挙されたものを上回るパ
ラメータは、上書きオプションが行使されなかった場合
と同様の挙動を示す。
【０２２４】収集の使用は、永続領域とケイパビリティ
の実際のサイズおよび数が分かるように、サーバによる
送信メッセージ制御情報の要求を必要とする場合が多
い。また、動的被参照領域に関連する直接カウント・フ
ィールドを検出するために、制御構造も調べなければな
らない。
【０２２５】ＲＰＣの場合には、その形式でクライアン
トが予期している応答用のメッセージ・バッファをサー
バが構築することが必要である。当然のことながら、双
方向ＩＰＣ１２２では、送信と受信の形式間にはプロト
コル・リンクがないので、これが必ずあてはまる。図２
９は、上書きの使用例である。
【０２２６】3.2.4.4 応答上書き制御情報 サーバが上書きオプションを使用して被参照領域上のデ
ータの配置をリダイレクトする場合、ポストが確実に行
われるよう注意しなければならず、それができなければ
応答処理が適している。ＲＰＣスタイル・インタフェー
スは、server-deallocオプションを使用して被参照領域
を割振り解除するよう、十分セットアップされているは
ずである。サーバは、過去の応答送達の持続を希望する
領域に被参照データをリダイレクトした場合、変更した
メッセージ制御構造を返さなければならない。サーバ側
の応答側制御構造を検出すると、メッセージ引渡しライ
ブラリ２２０は、サーバ側のバッファ処置オーバライド
を求めてそれを走査する。ＲＰＣの場合にクライアント
が返送を期待するメッセージは、当然のことながら、ク
ライアント形式になっている。適切なメッセージ・バッ
ファをまとめることは、サーバの責任である。サーバに
情報を渡しただけのバッファについてserver-deallocオ
プションが設定されたフィールドでヌル・バッファを返
送することは可能であったはずである。しかし、両方向
にまたはクライアントにだけデータを送信するために使
用されるバッファにとって、この応答では不十分だっ
た。
【０２２７】第４節 メッセージ引渡しモデル ケイパビリティ・エンジン３００は、単純な汎用メッセ
ージ引渡しサービスを作成するように定義されている。
これは、すべての転送を直接データまたはケイパビリテ
ィのいずれかとして形式化することによって、それを実
行してきた。ＭＡＣＨのようなポート・ベースのメッセ
ージ引渡しシステムでは、このようなポートを使用し
て、任意の転送にアクセス権を渡すことができる。メッ
セージ引渡しライブラリ２２０は、ケイパビリティ・エ
ンジン３００の機能を備えているが、ケイパビリティ・
エンジン３００パラダイムで明示的に実行しなければな
らないマッピング変換を行い、形式的なケイパビリティ
を作成せずにその転送を表すための言語を作成すること
によって、パフォーマンス・レベルを高めようと努めて
きた。転送の２つのエンドポイントがともにメッセージ
引渡しライブラリ２２０を使用する場合、センダーの空
間のマップ式区域をメッセージに記述することができ、
それを書き込むかまたはマッピングする箇所をレシーバ
のために記述することができる。
【０２２８】依然として、非同期メッセージにはケイパ
ビリティの作成が必要である。というのは、センダーが
戻る前に送信データを捕捉しなければならず、レシーバ
はまだ把握されていないか、データ受信の準備が整って
いないからである。これに対して、同期インタフェース
では、被参照データ型用の中間ケイパビリティを作成す
る必要はない。というのは、センダーは保留応答を待た
なければならず、クライアントの同期点は送信からの戻
りではなく、応答からの戻りであるからである。このた
め、メッセージ引渡しライブラリ２２０は、メッセージ
作成の前にクライアントを待ち、レシーバが使用可能な
ときだけ続行できるようになり、転送は、中間メッセー
ジを使用せずにタスク空間からタスク空間に移行するこ
とができる。したがって、メッセージ引渡しライブラリ
２２０も転送のタイプ（非同期対同期）を形式化しなけ
ればならないことは明らかである。
【０２２９】さらに、実際には２種類の同期転送があ
り、一方では応答のセマンティクス上の意味が送信に直
接結合され、もう一方では２つの結合が解除されること
を認識することができる。メッセージ引渡しライブラリ
２２０は、広範囲のメッセージ引渡しモデルをサポート
するように設計された。データ転送のためのその基本機
能はケイパビリティ・エンジン３００のものと同じであ
る。しかし、ライブラリの機能には、一般的な形式の遠
隔プロシージャ呼出しとプロセス間通信の非階層化サポ
ートを容易にするためのツールも含まれている。
【０２３０】4.1 遠隔プロシージャ呼出し 遠隔プロシージャ呼出しすなわちＲＰＣは、実際にはメ
ッセージ引渡しライブラリ２２０の機能とは区別するこ
とができ、一連の制約事項によってその機能からより大
きいクロスが切り取られている。そのうちのいくつかを
以下に示す。 １：メッセージがそのターゲットに送達されるまで、送
信が呼出しからメッセージ引渡しライブラリ２２０に戻
らない。 ２：同一形式のメッセージが送信および受信される範囲
で、ＲＰＣの送信および受信部分のデータがセマンティ
クス上、リンクされる。 ａ）着信メッセージと発信メッセージが同一形式を共用
する。 ３：ＲＰＣシステムは、代理人として動作できなければ
ならない。このシステムは、ローカル・プロシージャの
代わりに動作することによって、そのプロシージャの呼
出しをシミュレートできなければならない。このシステ
ムは、遠隔プロシージャが位置するタスク空間に関連デ
ータを転送し、遠隔プロシージャの処理を待ち、その結
果を呼出し側の空間に返し、最後にバッファ除去または
サポートされるそのクラスのプロシージャ呼出しの作成
のようなすべての派生的変更を行わなければならない。
【０２３１】３番目のポイントは制約事項のように思え
ないかもしれないが、実際には代理人の概念によってメ
ッセージの基礎構造として伝送情報を分離することが説
明される。ある意味ではそうではないが、代理人の場
合、メッセージ・バッファ内のパラメータは、厳密に最
初の呼出し側によって送られるものである。多くの言語
では、これによって何らかの制約事項が発生する。たと
えば、Ｃでは、すべての直接変数が固定長なので、直接
変数に入れてデータを返すことができない。これによ
り、ＲＰＣサブシステムはパフォーマンスの強化を行う
ことができる。実際、特定の使い方に基づくパフォーマ
ンス強化の機会は、ＲＰＣのサポートを形式化する理由
になり、それを区別する制約事項によって追加の最適化
が可能になる。
【０２３２】制約事項２は、実際には、疎対応答がクラ
イアントの予想と一致しないことを見つけるためにの
み、呼出しを開始するクライアントがその呼出しを開始
し、関連サーバを再始動不能な方法で活動化しようとし
ても成功しないことを、メッセージ引渡しシステムが保
証したものである。要求と応答とのセマンティクス上の
リンクは、メッセージ制御構造と登録サービスにとって
意味を持つ。要求メッセージと応答メッセージは同一形
式でなければならないので、メッセージ制御構造に送信
と受信両方の情報を含め、２つの構造を送信するのでは
なく制御情報を合体することは、最も自然なことであ
る。合体したかどうかにかかわらず、ＲＰＣの開始時に
クライアントが操作全体を宣言しなければならないとい
う事実は、メッセージの検査に影響する。上書きオプシ
ョンを使用するサーバは、より広範囲の着信クライアン
ト・メッセージを受け入れることができるが、クライア
ントが異なる遠隔バッファ処置情報を送信するのでその
メッセージ制御構造検査を調整しなければならない場合
もある。また、制約事項２でも登録の追加オプションが
説明される。おそらく複数のメッセージ制御構造形式を
受け入れて登録しなければならない必要性は、クライア
ント／サーバ関係の非対称性に起因する。サーバはクラ
イアントのメッセージ制御構造を登録する。正確に同一
形式のメッセージを送信するが、別々の方法で応答デー
タを受け取りたいと希望する２つのクライアントが存在
する場合、サーバは、両方をサポートするために２つの
メッセージ制御構造を登録しなければならない。
【０２３３】制約事項１の意味については、第３項で詳
細に考察した。同期メッセージ引渡しを採用した結果、
データおよび資源転送のＣＰＵオーバヘッドが低下する
だけでなく、カーネル・レベルの資源使用率も低下し、
それがより予測しやすくなる。
【０２３４】図３０は、ＲＰＣ転送を示す図である。サ
ーバが活発に応答を予想している間に、メッセージ制御
構造はメッセージ引渡しライブラリ２２０に保管され
る。メッセージが複雑であるが、大量の直接データで完
成されていた場合、サーバは、サイズがゼロの直接デー
タ・フィールドとともにオーバライド・メッセージ制御
構造を送信することによって、応答時にこのデータを返
送するのを回避することができる。メッセージ引渡しラ
イブラリ２２０は、サーバから送られたメッセージ内の
被参照、ケイパビリティ、およびその他のポート・フィ
ールドを検出するためにオーバライド・メッセージ制御
構造を使用し、クライアント・バッファを充填するか、
クライアントの２重間接ポインタを更新するか、いずれ
か適切な方を実行することになる。当然のことながら、
クライアント・メッセージ・バッファがクライアントに
書き戻されることはない。
【０２３５】4.1.1 代替スケジューリングおよびスレ
ッド化モデル ＲＰＣサポートには、スケジューリングに関して２つの
主要モデルがある。すなわち、能動サーバ・モデルと受
動サーバ・モデルである。能動モデルの場合、クライア
ントの要求に関連するスケジューリング情報は、サーバ
・スレッドのスケジューリング情報である。また、受動
モデルの場合は、クライアントのスケジューリング情報
である。能動モデルでは、サーバを監視して、スレッド
をターゲット・ポートでのメッセージの受取りに直接コ
ミットさせることができる。その場合、クライアント
は、このポートにメッセージを送り、応答待機をブロッ
クする。サーバは、メッセージを出して非監視プログラ
ム・モードに戻り、その処理に移行し、処理が完了する
と応答を出して元に戻る。受動モデルでは、ポートの所
有者としてのサーバが、スレッド本体の準備を行う（着
信カーネル・レベル・スレッドのために状態と１組の資
源を用意する）。クライアントは、ターゲット・サーバ
の空間に入るときほど多くのメッセージを送信するわけ
ではなく、従来のカーネル・レベル・サービス呼出しに
関連する類の制約事項がある。すなわち、ターゲットの
強制ポイントで実行を開始し、事前に定義した線に沿っ
て着信パラメータを処理する。
【０２３６】ＲＰＣの場合、サーバがそれ自体のために
動作している間にクライアントがブロックすることが保
証されると、実際の受動またはスレッド移行モデルをユ
ーザ・レベルに公表する必要がなく、受動モデルの諸要
素をサポートする際に非常に有用である。第一に、サー
バは、カーネル・レベルのクライアント・スレッドに関
連するすべてのカーネル・レベル一時資源を借りること
ができる。スレッド・スタックと他の一時ゾーン空間が
良い例である。クライアントは転送用のメッセージを準
備し、サーバは、その準備の結果を保管するバッファを
借りることができるようになる。このため、２つのモデ
ルには区別可能なパフォーマンス上の差は見られない。
実際、転送がスレッド移行として認識可能かどうかは、
カーネル・レベルでの実際の実現より、カーネル・レベ
ルの資源の命名との関係の方が強い。一例を挙げると、
最新の論文では、スレッド・ポートなどのスレッド・レ
ベル・マーカを適正スレッドではなくスレッド本体に関
連付けるために、スレッドへの呼出しが変換された。こ
のため、スレッドの移行に関連する部分であるスレッド
・シャトルが効率よく無名になる。このような効果は別
の方法でも達成できたはずである。能動スレッドのパラ
ダイム内にとどまると、別々のオプションとしてスレッ
ド移行の特性を列挙することができる。当然のことなが
ら、最も重要なのはスケジューリングである。能動ケー
スのサーバ・スレッドがクライアントのスケジューリン
グ特性を継承し、スレッドのカーネル要素が無名の場
合、受動モデルと能動モデルは、パフォーマンスおよび
機能の面で等価に近くなる。
【０２３７】能動モデルでは、実行可能な実際のスレッ
ドはサーバ側に作成される。これは、他の活動に使用さ
れる場合もあれば、使用されない場合もあるが、いずれ
にしても最終的にはスリープ状態になり、受信を待つ。
ポートがカーネル・レベル資源である受動ＲＰＣポート
の場合、スケジュール可能なエンティティでも破棄され
ることがある。（喪失状態用のポート・レベル・スケジ
ューリング情報テンプレートが打切りに使用できる状態
になっている必要があると思われる。）クライアントが
メッセージとともにポートに到着すると、クライアント
はそのカーネル一時資源とそのスケジュール可能エンテ
ィティ（シャトルの方が効率がよい）をサーバ・スレッ
ド（ここでは、スレッド本体の方が効率がよい）に貸し
付ける。クライアント・エンティティ（ここでは、スレ
ッド本体の方が効率がよい）はブロックされるか、応答
ポート上でスリープ状態になる。
【０２３８】受動スレッド・モデルをユーザ・レベルに
公表すると、いくつかの利点が得られる。より容易なス
レッド本体資源管理がその１つであることは確かであ
る。能動モデル・ユーザが"thread_body"をある待機ポ
ートから別の待機ポートに移動させたいと希望する場
合、そのユーザは打切りを実行しなければならない。ス
レッド本体用の実際の資源待ち行列をアプリケーション
・レベルに公表すると、ユーザは、単純なポインタ操作
によって資源を移動できるはずである。さらに、公表し
た場合、スレッド本体の作成および破棄の費用が安くな
る。このため、きわめて動的なサーバ・ケースにわずか
な利点がもたらされる可能性がある。また、公表した場
合には、インタフェースの正確な性質に応じて、受信ポ
ート間の資源プールへの対応も可能になる。別々のポー
トに共通スレッド本体資源を引き上げさせる。この方法
は、スレッド資源をサブセット化することができるが、
等価プール機能のほとんどをポート・セットによってサ
ポートできるという点で、port_setsよりいくらかフレ
キシブルであると思われる。したがって、能動インタフ
ェースによって受動モデル（そのモデルが無名カーネル
資源を使用する場合）の機能性とパフォーマンスをサポ
ートすることが可能である。非同期メッセージの世界は
これよりいくらか難しくなる。一方向送信に関する場
合、能動モデルと受動モデルとの等価性を維持すること
はほとんど不可能である。
【０２３９】呼出しの深さと移行スレッドのパスに関す
る状態情報が利用可能であることを要求するユーザ・レ
ベル・モデルは、当然のことながら、移行スレッド・モ
デルの公表を強要するはずである。シャトルはもはや無
名ではなくなり、進行中の呼出しの再帰的深さとパスに
関する情報を伝達するはずである。しかし、メッセージ
引渡しライブラリ２２０がサポートする状態に関するこ
のような直接的な要件だけが、移行スレッドの公表の必
要性を強要すると予想される。合理的な打切りセマンテ
ィクスでも、このような直接公表を行わずにサポート可
能になると思われる。4.1.9項を参照されたい。
【０２４０】4.1.2 クライアント／サーバの並置 クライアント／サーバの並置の特徴は、クライアントの
送信とサーバの受信との同期にある。ＲＰＣの場合、受
信すべきメッセージが発生する前にサーバが受信ポート
に到着すると、サーバがブロックする。レシーバより先
にクライアントが到着する場合は、レシーバが到着する
までクライアントがブロックする。実質的にこれは、メ
ッセージ転送を目的とするクライアントとサーバ両方の
空間への同期アクセスを保証するものである。クライア
ント／サーバの並置は非同期通信の特定の状況で達成す
ることができるが、ＲＰＣの場合のようにいつでも保証
されるわけではない。待機レシーバが存在しないポート
上で非同期送信を試みる場合、メッセージ引渡しライブ
ラリ２２０はメッセージを生成し、センダーが続行でき
るようにしなければならない。
【０２４１】同期トランザクションにおいて、レシーバ
がデータ・スナップショットを獲得するまでセンダーが
続行できないことを保証できるという能力は、実際のメ
ッセージを作成する必要がないことを意味する。これに
より、費用のかかるケイパビリティ変換、メッセージ作
成、メッセージ解析、および解放操作が最小限になる。
メッセージが作成されると、すべての被参照タイプが実
質的にケイパビリティに戻る。被参照区域に関連するメ
モリ領域はコピー（１つの形式または別の形式、コピー
・オン・ライト、コピー・マップなどは本明細書の範囲
を超えるものである）し、メッセージ外に指し示す必要
がある。これにより、ケイパビリティが効率よく作成さ
れる。このケイパビリティは無名なので、ターゲット空
間のマッピング・コストが節約されるが、依然としてか
なり高価である。
【０２４２】明示メッセージを作成しなければならない
場合でも、被参照タイプによりレシーバは特定の呼出し
を行わずに着信データをマッピングしたり書き込むこと
ができるので、パフォーマンスの点で被参照タイプの方
がケイパビリティより優れている。しかも、小さい被参
照フィールドの中には、直接データへの一次変換によっ
てケイパビリティの変換を回避できるものもある。これ
は特に、server_temporaryの例の場合に起こりそうなこ
とである。
【０２４３】クライアント／サーバの同期を確保する
と、カーネル・レベル資源の必要性が低減され、残りの
資源の必要性もより予測しやすくなる。非同期の世界で
は、待ち行列内に待機状態で残っているメッセージが多
すぎると、資源の過剰利用によるシステム・ロックアッ
プが起こりうる。一例は容易に構成できる。たとえば、
スレッドＡがスレッドＢにメッセージを送信するが、Ｂ
は前の要求（おそらくＡからのもの）の処理に使用中で
あるとする。この要求を処理するため、Ｂは他の複数の
タスクにメッセージを通知しなければならない。それぞ
れのメッセージは大量の空間を必要とする。次に、後続
タスクのそれぞれがメッセージを通知しなければならな
い。システム設計者は、その要求を実行するのに十分な
資源があることを確認してあるが、スレッドＢ上の追加
の待機要求が使用する記憶域を考慮していなかった。シ
ステムは、停止するか、または失敗に終わり、スレッド
Ｂに対応するために３次スレッドが作成を必要とするメ
ッセージを作成することができない。このような特定の
問題は克服することができ、実際には、問題を管理しよ
うと努力する際にメモリ限界などをポートに課すことが
できる。しかしながら、非同期のメッセージ作成によ
り、資源の枯渇を回避するためにアプリケーション・レ
ベルのアテンションを必要とする資源利用問題が発生す
ることは明らかである。複数のパーソナリティと様々な
アプリケーションを含む複合システムでは、汎用ユーザ
・レベルの管理が不可能になる可能性がある。開始前に
必要なすべての記憶域を予約するためにマルチレベルの
操作を必要とする解決策を構築できるはずであるが、こ
の種のトランザクション処理はそれ自体の問題を抱えて
おり、当然のことながら、本質的に同期的な性質のもの
である。クライアント／サーバの同期により、システム
内のスレッドごとに必要なカーネル資源を少数バイトに
低減することができる。当然のことながら、アプリケー
ション固有の資源の管理は、依然として潜在的に困難な
問題であることに変わりはないが、ＲＰＣのカーネル・
レベル資源管理は、現存する任意の時間にシステムが持
ちうるスレッドの数の制御だけで構成される可能性があ
る。
【０２４４】4.1.3 ＲＰＣ固有のメッセージ制御情報
の課題 ＲＰＣ呼出しに関連するメッセージ制御構造は、メッセ
ージの要求部分と応答部分の両方を指す。送信と受信を
セマンティクス上リンクすることがＲＰＣの本質である
という事実に加え、この配置は、メッセージ・バッファ
に関して便利であることが分かっている。
【０２４５】ＲＰＣのメッセージ・ライブラリ・バージ
ョンでは、メッセージ・バッファ形式と、多くの場合は
バッファ内容とが、応答時に変化しない。メッセージ・
バッファは、ＲＰＣの元の呼出し側によって送信された
パラメータを表す。（Ｃを含む）多くの言語では、呼出
し側がパラメータを直接変更することができない。これ
は、本発明のＲＰＣの実施態様では、メッセージ・バッ
ファをクライアント側にコピーして戻す必要がないこと
を意味する。応答時に形式が同じであることを全体的に
要求すると、メッセージ・バッファに関するメッセージ
制御構造記述が２つではなく、必ず１つになる可能性が
ある。１つのメッセージ制御構造で送信と受信の両方を
記述させるということは、もう１つの有用な制御情報圧
縮を意味する。パラメータ当たり必要な記述子は、２つ
ではなく、１つだけである。被参照変数の場合に受信側
および送信側のバッファ記述に関連する情報は別々に保
管され、送信側と受信側の明細の分解が便利なものにな
る。
【０２４６】要求と応答との情報の合体には２つの欠点
がある。第１の欠点は、サーバがオーバライド・オプシ
ョンを使用して呼出しに関連するローカル・バッファの
処置を変更するときにクライアント・インタフェースの
互換性を検査するという問題である。この場合、着信メ
ッセージの１つまたは複数のパラメータに関連する遠隔
バッファ処置ビットが有効ではなくなる。この問題は、
サーバ・バッファ処置に関連するすべてのビットをフィ
ールドに収集することによって克服されてきた。サーバ
は、パラメータ・フラグ・フィールドの比較の前にマス
キング操作を追加することを除き、バイトごとの同一比
較によって着信メッセージ制御構造を検査することがで
きる。サーバは、オーバライドのタイプと範囲に基づい
て互換性検査を完全に制御しており、着信メッセージの
パラメータの全部または一部でマスクを使用することが
できる。第２の欠点は、server_deallocオプション周辺
に集中している。server_deallocに関する場合、特別な
注意が必要になるが、サーバは、このオプションの有無
を検査し、このオプションが発生した場合は応答時にオ
ーバライドを返送せざるを得なくなる場合もある。クラ
イアントがパラメータ上にserver_deallocを指定してメ
ッセージを送信し続ける場合に、サーバがserver_deall
ocのオーバライドが必要なオーバライドを実行し続ける
という意味で、これは最適状態に及ばない。サーバは継
続的に応答メッセージ制御構造を送信し、メッセージ引
渡しライブラリ２２０は呼出しごとにそれを調べなけれ
ばならない。最悪のシナリオでは、サーバは、毎回、着
信メッセージ制御構造を検査し、deallocについて特殊
検査を実行するはずである。これは、仮定上の非合体概
念に関する大きな欠点ではない。というのは、その場
合、サーバは応答ごとにメッセージ制御構造を送信しな
ければならないからである。しかし、それは、サーバ側
でのユーザ・レベルの余分な検査と、メッセージ引渡し
ライブラリ２２０レベルの相互比較を必要とする。当然
のことながら、これは、server deallocを含まないメッ
セージ制御構造をクライアントに送信させることによっ
て、または登録を介して回避することができる。サーバ
は、server_deallocオプションを含まないメッセージ制
御構造を登録し、このための登録ＩＤをクライアントに
返すことを選択することができる。
【０２４７】4.1.4 サポートされるプロシージャ呼出
しのサブクラス 確かに、プロシージャ呼出しをエミュレートする場合、
全範囲のローカル・プロシージャ呼出しの挙動をサポー
トすることは単純に可能であるわけではない。所与の事
柄は除外される。呼出しのパラメータに関連しないが、
直接アクセスにより呼出し側および被呼側がアクセス可
能なグローバル変数に対する副作用は一切発生しない。
内部範囲トリックもない。呼び出されたプロシージャ
は、その変数がパラメータとして現れない限り、呼出し
側プロシージャのローカル変数またはその先祖の１つと
して宣言されている変数について作用することができな
い。
【０２４８】しかし、このような明らかな副作用の例以
外に、本発明でサポートしていない完全に有効な呼出し
の大規模セットが存在する。そのうちの最大のものは、
多重間接度＞２である。これをサポートすることは可能
であるが、間接度が２を上回る変数をサポートすること
はその手間に値しないと判断された。２重間接を使用す
ると、被呼側がポインタ値を変更することができ、配列
の戻しが可能になるので、２重間接が承認された。
【０２４９】上記の制約事項にかかわらず、ＲＰＣによ
ってサポートされるプロシージャ呼出しのサブセットは
大規模である。元の呼出し側のパラメータ上に構築され
た非解釈メッセージ・バッファと、ＲＰＣの透過使用の
両方を可能にすることが、設計目標だった。クライアン
トは、その呼出し上の最初のパラメータとして宛先ポー
トを送信する必要はない。メッセージ引渡しライブラリ
２２０は、その伝送データ・セクションで宛先ポートを
送信できる能力を持っている。この場合、ライブラリ・
スワップまたはライブラリ分解パスの変更によって、サ
ブクラス化を実行できるはずである。さらに、クライア
ントは、その機能呼出しでデータおよびポインタを返せ
るようになっている。メッセージ引渡しライブラリ２２
０は、伝送状況用の任意選択の個別状況戻しにより、こ
れをサポートする。最も重要なのは、呼び出された機能
が取りうる広範囲のアクションをサポートするため、バ
ッファ処置クラスがセットアップされていることであ
る。クライアントは、呼び出されたプロシージャがデー
タを調べた後でバッファを除去するか、データの返送先
になるバッファを割り振るものと完全に予想することが
できる。サポートされるセマンティクスの範囲は、第２
項で定義したバッファ・サブクラスによって決まる。直
接サポート以外に、クライアント側の代理人ルーチンは
ローカル・セマンティクスをサポートすることができ
る。すなわち、バッファを割り振るときにサーバが特定
のヒープ・ソースを使用するとクライアントが予想して
いた場合、代理人は、ローカル呼出しを使用してこのよ
うなバッファを割り振り、ＲＰＣ呼出しを変更してこの
バッファへの書込みを反映する可能性がある。当然のこ
とながら、これにより、代理人がメッセージ・バッファ
の再書込みを行い、パフォーマンスに何らかの影響があ
るはずである。
【０２５０】このような広範囲のクラスのプロシージャ
呼出しのサポートは、共存に向けてパスを緩和するため
に設計された。（呼出し側と被呼側が、パフォーマンス
の損失を発生せずに１つのパラダイムに書き込めるよう
にし、遠隔およびローカルの両方で実行できるようにす
る。）ローカル・ケースは最もパフォーマンスに敏感だ
った。可能な最善のパフォーマンスを獲得するため、パ
ラダイムは見かけ上できるだけローカル・プロシージャ
呼出しに近くなる必要があった。これは達成されたの
で、実際に呼出しはローカル呼出しにすることができ、
場合（クライアントが宛先ポートを送信しない場合）に
よってはローカル呼出しになる。この項の最初の２つの
段落に記載した制約事項とともに、以下に列挙した特性
リストにより、サポートされている１組のプロシージャ
呼出しの特性が示される。メッセージ引渡し環境で機能
するために作成されなかったとしても、これらのオプシ
ョンをあえて超えないようなプロシージャがサポートさ
れる。 １．機能戻り値は、フルワードまたは構造を指すポイン
タになる可能性がある。 ２．被参照データ・フィールドのサイズは、動的である
可能性がある。 ３．被呼側は、呼出し側によって送られたバッファを削
除することができる。 ４．被呼側は、２重間接ポインタの設定によってバッフ
ァを作成し、それをクライアントに提供することができ
る。 ５．被呼側は、クライアントによって提供されたバッフ
ァへの書込みを行うことができ、そのバッファが十分な
大きさでなければ、以下のいずれかを行う。 ａ．エラーを返す。 ｂ．データを切り捨てる。 ｃ．新しいバッファを獲得し、それを指す２重間接ポイ
ンタを指し示す。 ６．被呼側は、様々な呼出し側パラメータに関連するデ
ータを単一のプール・バッファにプッシュすることがで
きる。 ７．被呼側は、様々な呼出し側パラメータに関連するデ
ータを複数のプール・バッファにプッシュすることがで
きる。
【０２５１】配列として送信される場合、ポートには何
らかの制約事項がある。当然のことながら、配列を指す
ポインタは２重間接以外のものにすることができず、配
列内のすべてのポートは同一処置を持っていなければな
らない。ポートはメッセージ引渡しにとって特別なデー
タ型であるので、これらの制約事項はデータ型に関する
制約事項と見なす方が適切である可能性もある。
【０２５２】4.1.5 伝送制御情報構成要素のＲＰＣ固
有の使い方 ＲＰＣは、他のメッセージ引渡しモデルと同じように伝
送制御情報の副構成要素を使用する。ＲＰＣは、ＮＤＲ
状態のデフォルトを変更することができ、トレーラを介
して代理人同士の間で情報をやりとりすることができ
る。しかし、ＲＰＣには、そのクライアント用のメッセ
ージ引渡しの透過性をサポートするために満足しなけれ
ばならない追加の必要事項がいくつかある。２つの主要
オプションはSTATUSとDESTINATION PORTである。ＲＰＣ
サブシステムは、遠隔機能呼出し時のポインタとデータ
の戻しをサポートしている。メッセージ引渡しライブラ
リ２２０のデフォルト挙動は、ＣＭＵのmachメッセージ
引渡しサービスが行った程度にプロシージャ戻り状況と
伝送状況を結合することである。機能戻りコード情報を
分離するために、クライアント側の代理人はSTATUS戻り
オプションを要求しなければならない。
【０２５３】次に、機能戻り状況が任意選択のヘッダ域
内のフィールドに入る。伝送状況は通常の方法で返され
る。これにより、メッセージ・バッファが保持され、元
の呼出し側のパラメータが行ったのと同じように見える
ようになる。伝送セクションの宛先ポート・オーバライ
ドにより、代理人は、メッセージ・バッファを変更せず
にメッセージの宛先を決定することができる。この場合
も、透過プロシージャ呼出しのエミュレーションのサポ
ートにより、可能な最高速のユーザ・レベル・インタフ
ェースの２重概念をサポートすることになっている。た
とえば、双方向ＩＰＣ１２２が宛先ポート概念を呼出し
側から隠蔽する必要が生じる可能性は低いと思われる
が、このオプションはすべての代理人が使用できる状態
を維持する。非ＲＰＣ使用の場合と同様、トレーラは、
そのセキュリティ・トークン、順序番号、スケジューリ
ング情報、および可能な経路指定情報に有用であること
が分かるようになる。
【０２５４】4.1.6 クライアント待ち行列をプラグ接
続可能にする、優先順位ベースの待ち行列化 ケイパビリティ・エンジン３００は、着信メッセージの
待ち行列化と待ち行列解除のための総称インタフェース
を有する。実際に呼び出されるルーチンは、ターゲット
・ポートのポート構造内のフィールドによって決まる。
ケイパビリティ・エンジン３００は、このフィールドを
調べ、それが指し示すプロシージャを呼び出す。また、
ケイパビリティ・エンジン３００は、このフィールドを
変更するために呼び出されるインタフェースも持ってい
る。適正待ち行列化を日の順にセットアップすることに
より、待ち行列化コードは、ブロックされたスレッドま
たはメッセージ内のフィールドに関連するスケジュール
可能エンティティを検査し、それに応じてスレッド／メ
ッセージを待ち行列化または待ち行列解除することがで
きる。これは、メッセージ引渡しライブラリ２２０とケ
イパビリティ・エンジン３００による複数の待ち行列化
方法のサポートを支援する基本的な考え方である。ケイ
パビリティ・センダー待ち行列化呼出しは、パラメータ
としてカーネル・オブジェクトを指定して（ＳＶＣによ
るかまたは直接）行われる。メッセージとスレッド構造
の両方の最初の部分はカーネル・オブジェクトである。
待ち行列化プロシージャ自体は、自己定義データ構造
（カーネル・オブジェクト）内のタイプ・フィールドを
介してカーネル・オブジェクトのタイプを決定し、それ
に応じて処理を続行する。
【０２５５】当然のことながら、ＲＰＣはメッセージを
待ち行列化しないので、待ち行列化コード内のメッセー
ジ固有の機能性は未使用になるはずである。メッセージ
構造内で予想されるスケジューリング情報の配置ならび
にメッセージとブロック化スレッドの２重待ち行列化の
詳細については、前述した。ケイパビリティ・エンジン
３００のクライアント待ち行列化機能はＲＰＣの場合に
直接呼び出されるとは思われず、むしろ、サーバ資源の
不足（能動スレッドまたは受動スレッドの本体の概念）
を検出するＳＶＣ呼出しがケイパビリティ・エンジン３
００を起動して、待ち行列化機構を呼び出すものと予想
される。
【０２５６】ポートはケイパビリティ呼出しによっての
みアクセス可能なので、図３１では、ケイパビリティ・
エンジン３００の内部にポートが示されている。
【０２５７】4.1.7 メッセージ・サーバ空間のサポー
ト、メッセージＩＤのデマルチプレクシング １組としてまとめて説明すると有利になるように、一連
の機能が共通の特徴を十分持っているか、または単一目
的に寄与する場合がよくある。さらに、このような複数
の機能が同一の資源および情報ベースを共用する場合、
その組のメンバーを物理的に分割しないことが重要であ
る。これをサポートし、ポートの浪費を避けるよう努力
する間に、ＣＭＵのmach_msgモデルからポート・レベル
のデマルチプレクシングが繰り越された。（これは互換
性のためにも必要である。）
【０２５８】メッセージＩＤはヘッダ内のフィールドと
して現れ、単一ポートに関連する一連のインタフェース
のうちのメッセージのインタフェースと形式を決定す
る。メッセージＩＤは、メッセージ引渡しライブラリ２
２０の基本要素ではない。というのは、そのライブラリ
はメッセージ処理の決定の際にメッセージＩＤの値を使
用しないからである。したがって、それをオプションと
してトレーラに所属させることも可能である。しかし、
１つのポート、１つの方法、またはより一般的で解釈的
なＩＰＣ１２２とそのためにその後発生する解析コスト
とに比べ、ＲＰＣのデマルチプレクシングの方が好まし
いことは、ＣＭＵのmach_msgによる圧倒的な経験であっ
た。１組の一定のインタフェースの場合、実際にメッセ
ージＩＤは、解釈ＩＰＣ１２２とそのためにその後発生
する解析コストとを最適化したものである。１組の一定
のインタフェースの場合、実際にメッセージＩＤは、解
釈ＩＰＣ１２２を最適化したものである。同時にそれは
より高速でより強力である。規則により、メッセージＩ
Ｄは、セマンティクス情報ならびに形式情報を伝送す
る。（この場合、解釈ＩＰＣ１２２は、メッセージ形式
が前もって分かっておらず、メッセージ制御構造を調べ
なければならないことを意味するものと定義する。）
【０２５９】デマルチプレクシング・モデルでは、ユー
ザ・レベル・サーバは、メッセージをポートに乗せ、ポ
ートからメッセージを回復する１次プロシージャで構成
される。このプロシージャは、何らかの一般処理（大き
すぎるメッセージの処理、再始動処理、バッファ処理な
ど）を実行し、次にサーバ側の代理人を呼び出す。呼び
出される代理人は、メッセージ引渡しＩＤによって決ま
る。このサーバ側の代理人は、個別機能レベル固有のセ
ットアップと検査を実行する。
【０２６０】汎用サーバ・ループは、１カ所での個別メ
ッセージ処理に関わるようになる。メッセージＩＤによ
って索引が付けられたテーブルにより、メッセージ制御
構造がそのループで使用可能になる。バイトごとの検査
コードは汎用である。機能固有なのは、関係するデータ
だけである。さらに、サーバ側のオプションの変更は必
ずサーバ全体に及ぶ。サーバ側の形式検査に対して行う
必要がある調整に最も適した場所は、汎用サーバ機能で
ある。また、サーバ側のスタブが自動的に生成される傾
向があることも真実である。このため、サーバ側のスタ
ブは、受信側のバッファ処置カストマイズのターゲット
としての利便性が低下する。図３２に示す、典型的なメ
ッセージ受信／送信の実行の流れの概要は、以下の通り
である。
【０２６１】・１次サーバ機能がメッセージを受信す
る。 ・１次サーバ機能が状況、すなわち、メッセージが大き
すぎるかどうかを検査し、適切な高レベル処理を実行す
る。 ・登録されている場合、１次サーバが索引テーブルを検
査し、登録ＩＤをメッセージＩＤに関係づける。 ・登録されておらず、クライアントがトラステッドでは
ない場合、１次サーバ機能は、メッセージＩＤを使用し
てメッセージ制御構造テンプレートを獲得し、着信（明
らかに要求された）センダー・メッセージ制御構造と照
らし合わせて検査する。 ・１次サーバ機能がメッセージＩＤをテーブルへのオフ
セットとして使用して、適切な代理人機能を獲得する。
１次サーバが代理人機能を呼び出す。 ・代理人機能が着信データに関する必要な変換をすべて
行う。これらの変換は、機能／アプリケーション固有で
あり、自動代理人生成ツールでのサポートを除き、メッ
セージ引渡しアーキテクチャの外部にある。 ・代理人機能がターゲットであるエンドポイント（被呼
側）を呼び出す。 ・代理人機能が、データ変換を含む機能固有の終結処置
を実行する。代理人機能が戻る。 ・１次サーバ機能がヘッダ・フィールドを再加工し、別
のバッファが使用されない限り、ヘッダのサイズを大き
くできないようにする。（受信バッファ内のヘッダの下
には、応答時に送信されるサーバ一時データ４００が存
在する場合もある。）１次サーバは、任意で応答メッセ
ージ制御構造を含み（まれである）、そのサイズを低減
するために代理人が返したメッセージを再加工する（ま
れである）。（このようなカストマイズは、プロダクト
内で直接サポートされる場合もあれば、サポートされな
い場合もあり、手作業によるサーバ・ループとデータ構
造のカストマイズはアプリケーション作成者に任される
こともある。） ・１次サーバ機能がsend/rcvによってメッセージ引渡し
ライブラリ２２０を呼び出す。供給されるヘッダは応答
構造を指している。（メッセージ・バッファは、応答時
に供給されるデータを含む一時フィールドと永続フィー
ルドを指している。）ヘッダは受信バッファの先頭にあ
る。受信バッファは、着信メッセージ・ヘッダのいずれ
かとその一時データ４００を収容できるだけの大きさで
あり、あるいは特大オプションの１つが検出されること
もある。
【０２６２】4.1.7.1 動的メッセージ・サーバ空間 動的リンクおよび共存のサポートは非常に強力である。
これにより、ターゲット空間へのルーチンのダウンロー
ドとリンクが可能になる。適切な実施態様を使用する
と、ダウンロードした機能がローカル・プロシージャ呼
出しに接続して、追加のオーバヘッドなしにおそらくロ
ーカル・プロシージャ呼出しとして実行することがで
き、クライアントの代理人、サーバ、およびサーバ代理
人ルーチンが効率よく迂回される。機能呼出しがメッセ
ージ引渡しに気付いている場合、ローカル・ケースで
は、呼出し側と被呼側との間に代理人を挿入することが
必要になるが、遠隔呼出しと対比させると、この代理人
の複雑さとオーバヘッドが大幅に低減される。
【０２６３】共存は、サーバの遠隔セットアップもサポ
ートする。これをサポートするため、共存は単純なダウ
ンロードおよびリンク機能を超えるものでなければなら
ない。先在サーバの場合、外部ソースからのダウンロー
ドとリンクを使用して、サーバ代理人の１つまたは複数
とそのエンドポイント・ルーチンを変更できるはずであ
る。しかし、これを実行するには、遠隔エンティティは
代理人の名前、おそらく、エンドポイントの名前を把握
し、汎用書込み許可、すなわち、ターゲット・タスク用
のタスク・ポートを持つ必要があるはずである。ある程
度の保護によってこの機能性をサポートするためにだ
け、１組の複雑なユーザ・レベル・ユーティリティを作
成しなければならないはずである。これらのユーティリ
ティはトラステッドになり、ターゲット・タスクはその
タスク・ポートをそのユーティリティに委任するはずで
ある。機能のダウンロードを希望する他のタスクは、こ
れらのユーティリティによりダウンロード・ターゲット
と通信しなければならないはずである。
【０２６４】複雑なアプリケーション・レベルのツール
が容認されたとしても、実際にはこのレベルの機能性で
は十分ではない。追加の機能では、ターゲットと、遠隔
ダウンロードを試みるタスクとの間の高レベルの通信が
必要である。呼出し側は、共存の定義済み概念の外部に
ある何らかの方法を使用せずに、サーバを始動したり、
または既存サーバに新しいメッセージＩＤを追加するこ
とができない。
【０２６５】単純かつ簡単な方法でこのような概念をサ
ポートするには、動的サーバ・モデルのサポートが必要
である。動的サーバとして使用可能になることを希望す
るタスクは、サーバ作成、操作、および遮断の一連のル
ーチンを使用可能にするポートを作成してエクスポート
しなければならない。複数のサーバのためのサーバであ
る。このサーバ／サーバは、サーバ・ライブラリによっ
て提示された呼出しをエクスポートする。デフォルトの
サーバ・ループは、単なる共用ライブラリ・ルーチンで
はない。server_create呼出しは、サーバのスレッドな
しインスタンスを作成し、ハンドルを返す。このハンド
ルは、サーバ・インスタンスの任意選択の態様の変更、
サーバ・スレッドの追加または削除、代理人およびその
結果によるエンドポイントの関連付け、受信バッファの
追加または削除、あるいはサーバ・インスタンスの遮断
および終結処置のために後続の呼出しが使用する。基本
的なco_residentユーティリティを使用して指定のコー
ドをターゲット・タスクにダウンロードした後、遠隔呼
出し側は、サーバ／サーバ・ポートにserver_createメ
ッセージを送信し、応答時にハンドルを受信するはずで
ある。呼出し側は、呼出し時に１組の代理人を供給した
か、または後続の呼出しによりその代理人を充填する可
能性がある。呼出し側には、サーバ・パッケージによっ
てエクスポートされた呼出しの１つではない追加の呼出
しが用意されている。余分な呼出しは、スレッドを作成
し、次にそのスレッドをターゲット・サーバ・インスタ
ンスに関連付けるようスレッド自体に指示するために必
要である。受動モデルでは、単にスレッド本体資源をレ
シーバに提供することが可能であるが、能動モデルで
は、ターゲット・スレッドによる呼出しを介してサーバ
がスレッドを獲得する。このようにルーチンを構築させ
ると有利である。ターゲット・サーバ・タスクは、自由
に後処理を調整するか、またはその固有の要求のために
スレッド状態または資源をカストマイズすることができ
る。サーバ・インスタンスの概念のため、そのスレッド
がサーバを出てもサーバは持続する。このため、例外条
件により、スレッドがそのrun_server呼出しから戻るこ
ともある。この場合、タスクは例外処理をカストマイズ
することができる。次に、スレッドをサーバ・ループに
戻すことができる。スレッドが返される例外が単純なre
turn_server_threadである場合、スレッドは、そのスレ
ッド自体をサーバに再度関連付けるか、他の無関係なタ
スクを実行するか、または自己終了することができる。
【０２６６】4.1.8 無名応答サポート メッセージ引渡しライブラリ２２０では、データ、バッ
ファ処置、およびメッセージ・バッファ形式に関する要
求と応答との間で確立されたセマンティクス上のリンク
が、その要求と応答を実行するために必要な実行パスと
資源から分離される。メッセージ制御構造内の１組の個
別のフィールド、ポート上のオプション、およびタスク
そのものにおけるスレッド・サポート・オプションによ
り、その要求と応答を実行するために使用される資源が
明示的に操作される。最も単純かつ高速のケースでは、
明示応答ポートは不要である。クライアントは単にブロ
ックされて遠隔プロシージャ呼出しの完了を待ち、サー
バまたはそのサーバの１つのスレッドは、呼出しの期間
中、遠隔プロシージャ呼出しを完了してその結果を返す
ことに専念する。この単純なケースでは、実際に被参照
データ転送を最適化するために同じ技法を使用する機会
がメッセージ引渡しライブラリ２２０に提供され、非同
期および明示受信の際に発生する明示ポート待機が迂回
される。この場合、メッセージ引渡しライブラリ２２０
は、待機とサーバの空間への送信権または単一送信権の
マッピングの両方のためにケイパビリティ・エンジン３
００に連絡するという犠牲を回避することができる。し
かし、スループットまたは伝送制御の理由から、より高
いフレキシビリティが必要になる場合もある。
【０２６７】このフレキシビリティのため、状況によっ
ては、応答ターゲットを追跡するためにサーバ側または
クライアント側のいずれかに明示応答ポートが必要にな
る。まれなことではあるが、クライアントは、中間メッ
セージの送達に対応できるようにするため、明示応答ポ
ートの宣言を必要とする場合もある。この場合、代理人
ルーチンは、明示応答ポートで受信を実行することによ
り、これらの中間メッセージを受信し、それを処理し、
応答待機を再確立することができるはずである。この挙
動の例は、thread_abort_notifyに対する受信側の処理
で見ることができる。
【０２６８】アプリケーション環境の中には、サービス
呼出し時のみ非同期の信号送出を受け入れるものがあ
る。システムが厳密に非同期ではなくても、制限時間内
に非同期信号を受信する必要がある場合もある。これ
は、ターゲット・コードによってサービス呼出しが行わ
れる頻度によってある程度まで決定することができ、タ
ーゲットは、ローカル・コードの実行が十分短い間隔で
実際のサービス呼出しを含まないときにヌル・サービス
呼出しを実行する。しかし、このようなサービス呼出し
時の遅延は、システムが許容できる長さを上回る可能性
もある。この場合、送信時のブロック（または要求）、
受信時のブロック（または応答）、およびおそらくアプ
リケーション・サーバ・ルーチンへの帯域外打切り信号
によるサーバ処理からターゲットを打ち切ることが可能
でなければならない。クライアント側の代理人がそれを
処理するためにセットアップされた場合、信号による送
信側の打切りは簡単である。クライアントは、abort_no
tify信号によって気づき、それを処理し、必要であれ
ば、ＲＰＣを再始動する。しかし、サーバがすでにその
要求を処理している場合は、クライアントは応答を待っ
ており、この期間中にthread_abort_notify信号を受け
取るためには、クライアントは明示応答ポートによって
ＲＰＣを請け負っておかなければならない。このため、
メッセージ引渡しライブラリ２２０は、クライアントに
abort_notifyメッセージを送信することができ、クライ
アントはその応答待機を再確立することができる。クラ
イアントが明示応答ポートを供給しなかった場合は、メ
ッセージ引渡しシステムは、abort_notify状態を保留
し、サーバから戻ってくる応答とともにそれを含めるこ
とになる。
【０２６９】サーバ側の明示応答ポートを回避するた
め、サーバは、応答を送り返すスレッドがその要求に関
連付けられたものと同じになることを保証できなければ
ならない。このため、応答を待っているクライアント
は、サーバ・スレッド構造に関連する構造に登録するこ
とができる。それはユーザ・レベルのスレッド化パッケ
ージを必要とし、その結果、何らかの形式のユーザ・レ
ベルのスレッド多重化を必要とする場合があるので、サ
ーバはこれを保証できなくてもよい。このような多重化
は、スループット、リアルタイム、または何らかの形式
の明示シリアル化をサポートしようと努力する際に行わ
れる場合が多い。
【０２７０】無名応答ポート最適化のシームレス・サポ
ートでは、応答ポートに関するクライアントの決定がサ
ーバから隠蔽され、その逆の隠蔽も行われることが必要
である。メッセージ引渡しライブラリ２２０は、図３３
に示すアルゴリズムによってこれを達成する。このアル
ゴリズムは、メッセージ引渡しシステムがクライアント
の送信とサーバの受信の両方を並置状態で有する時点か
ら始まる。当然のことながら、これは必ずＲＰＣにおい
て達成される。
【０２７１】当然、ケース１が最善のパフォーマンスを
示す。しかし、ポート権を作成してそれをサーバの空間
内に入れる必要がないので、ケース３の方がケース２ま
たは４より優れたパフォーマンスを示すはずである。名
目上、ケース３はケース４より優れたパフォーマンスを
示す可能性があるが、それは、無名ポートが軽量業務で
あって、通常のポート・タイプの状態およびセットアッ
プを必要としないからである。
【０２７２】要求から戻ると、サーバ・スレッドのデー
タ構造は未解決の応答がないかどうか検査される。これ
は、上記のケース１とケース３に現れる。これがケース
３の例である場合、ポート構造の第２のフィールドはク
ライアント応答ポートを指し示す。ポート上でブロック
されている場合、クライアントは除去される。クライア
ントがブロックされていない場合は、サーバがセンダー
としてポート上で待機させられる。クライアントが使用
可能なときは、応答が送達され、クライアント・スレッ
ドが戻り、サーバの資源またはスレッドは自由に別のメ
ッセージを乗せることができる。
【０２７３】サーバのスレッド構造がクライアントを指
していない場合は、サーバ・メッセージ呼出しの遠隔ポ
ート・フィールドに明示ポートが入っていなければなら
ず、それ以外の場合は、サーバにエラーが返される。ク
ライアント・スレッドは、そこにあれば、このポートか
ら取り出され、転送が続行される。それがポート上にな
ければ、サーバ・スレッドがその待機をブロックする。
【０２７４】4.1.9 ＡＢＯＲＴのサポート 打切りのサポートは、１つの機能ではなく３つの機能で
あるという事実によってさらに複雑になっている複合課
題である。標準のthread_abortは、発信メッセージを打
ち切るか、または再始動の可能性とは無関係に待機す
る。このため、その使い方は、スレッド終了または少な
くともスレッドを使用する実行ストリームの終了のよう
な急激な状況に限られる。打切りの第２の形式はthread
_abort_safelyであり、おそらくthread_abort_checkpoi
ntと呼ばれるか、より適切な他の名前を持っているはず
である。thread_abort_safelyの本当の目的は、信号を
安全に出すことができる状態にターゲット・スレッドを
すばやく変更することである。この信号は非同期なの
で、その機構は同期実行ストリームが検出できるもので
あってはならない。したがって、thread_abort_safely
が再始動可能であることは避けられないことである。打
切りの第３の形式であるthread_abort_notifyは、threa
d_abort_safelyと同様、信号送出に使用される。thread
_abort_safelyとは異なり、thread_abort_notifyは、メ
ッセージ引渡し呼出しの戻り状況によってターゲット・
スレッドの実行ストリームにその信号を直接伝達する。
その目的は、ユーザ・レベル信号処理ルーチンを呼び出
して戻ることができるようにするためのカーネル呼出し
からの即時再始動可能な戻りを保証することではない。
スレッドがユーザ・レベルで動作している場合、スレッ
ドは通知状態を通知し、その時節を待つ。thread_abort
_notifyは、再始動可能な方法で打ち切られたかまたは
その他の場合にメッセージ引渡し呼出しから戻るとき
に、信号伝達のみ実行することができる。
【０２７５】３種類の打切りの目的は、それぞれの実施
態様に影響するほど異なっているので、それぞれ個別に
考察する。
【０２７６】4.1.9.1 thread_abort スレッドが実行可能な待機としては、カーネル・ベース
のものと外部サーバ・ベースのものの２種類がある。打
切りの呼出し側がスレッドの再始動可能性を気にしない
場合、待機スレッドを覚醒する際に最も重要な考慮事項
は、サーバまたはカーネルの資源と状態である。サーバ
／カーネルが未定義状態でまたは孤立資源とともに放置
されていない限り、スレッドは、thread_aborted宣言に
より、いつでもユーザ・レベルに戻ることができる。カ
ーネルでは、資源を同時に終結処理するか、あまり望ま
しくはないが、世話人を作成することが可能であるはず
である。事実、新しいモジュール性の高いマイクロカー
ネル１２０アーキテクチャでは、メッセージ引渡しの送
受信時の待機以外にカーネル待機が発生しない可能性が
ある。いずれの場合も、カーネル資源回復の正確な処置
は、メッセージ引渡しに関する論文の範囲を超えてい
る。しかし、サーバ・ケースでは、メッセージ引渡しシ
ステムが直接関与する。
【０２７７】ＲＰＣでは、打切り機能によって、要求開
始までの待機がブロックされるか、応答待機がブロック
されたスレッドが検出される場合がある。スレッドが要
求時にブロックされている場合、打切りは単純かつ再始
動可能であり、request_aborted状況とともにスレッド
を戻す。サーバはまだ要求に気付いていないので、回復
アクションは一切不要である。スレッドが応答を待って
いる場合は、状況がかなり複雑になる。
【０２７８】thread_abortの場合は、現在は無用なわず
かな作業を完了させるのではなく、できるだけ早くサー
バを停止しようという試みが行われる可能性がある。サ
ーバを打ち切るための最初の試みはポートを介して行わ
れる。ポート構造のフィールドの１つは、abort_notify
機能を指し示す。サーバが打ち切られたクライアントの
ために作業の早期終了をサポートしたいと希望する場合
は、この方法を選択することができる。メッセージ引渡
しライブラリ２２０は、ポートと関連メッセージの順序
番号とを含むメッセージを打切り通知ポートに渡す。
（メッセージはポート・セットで送達されている可能性
があるので、ポートが必要である。）いずれの場合も、
応答が送り返されたときにメッセージが破棄され、サー
バ応答装置が解放されるように、応答を待っているポー
トの状態が変更される。ポートが最初に破棄されると、
サーバは、応答ポート用のデッド名を検出するだけにな
り、応答を破棄して続行するように動作する可能性があ
る。
【０２７９】受信ポートの打切り通知フィールドがまだ
記入されていないことをメッセージ引渡しライブラリ２
２０が検出すると、そのライブラリは、サーバが無名応
答ポートを要求したのかどうかを検査して確認する。そ
れを要求した場合、サーバは、特定のサーバ・スレッド
と要求との間に切断不能リンクがあることを保証してい
る。サーバの無名応答ケースでは、メッセージ引渡しラ
イブラリ２２０がサーバ・スレッドでthread_abort_saf
elyを実行し、処理中のメッセージが重要ではなくなっ
たことを示す信号を送信する。無名応答ポートがある場
合は、それが破棄される。クライアントが明示応答ポー
トを送信した場合は、応答メッセージが破棄され、その
応答が送信された場合と同様にサーバ応答装置が解放さ
れるように、応答ポートの状態が設定される。
【０２８０】クライアントは、thread_abort状況によっ
てそのメッセージ引渡し呼出しから戻る。この状況は、
そのメッセージが打ち切られ、関連の資源とデータが失
われたことをクライアントに示すものである。あまり洗
練されていないthread_abort_safelyの使用を希望する
システムでは、メッセージ引渡しを試みる前にクライア
ントがそのデータを検査する場合に、再試行を達成する
ことができる。サーバの状態は、サーバが複数の呼出し
間で状態を維持する場合のみ重要である。この場合、サ
ーバがクライアント打切りの通知を受け取り、適切なア
クションを取ることを設計者が保証しなければならな
い。
【０２８１】リアルタイムの観点からは、サーバがクラ
イアントのスケジューリング特性を獲得した場合に資源
の適正スケジューリングにとって危険な状態が発生す
る。スケジューリングの観点からは、これは、実際上、
打切りの経験後にクライアント・エンティティがサーバ
空間で動作するというサーバ受動モデルである。クライ
アント・スレッドは、実際上、サーバ内で一時的に動作
するものおよびクライアント内で動作するものによって
クローンとして作成される。クライアントの優先順位が
十分高い場合、サーバ・スレッドは（打切り／信号シナ
リオでは）、信号の終了を検出する前に完了するよう動
作する可能性がある。打切り通知ポートが存在しないサ
ーバ明示応答ケースでは、サーバにクライアントの打切
りを通知する試みは行われない。
【０２８２】サーバがシステム設計者により、クライア
ント打切り通知を適切な時期に送達することを保証でき
るのは、打切り通知ポートの場合のみである。サーバ打
切り通知ポート上の能動スレッドに高い優先順位が与え
られている場合、またはメッセージ引渡しライブラリ２
２０によって割り当てられる受動スケジューリング・パ
ラメータが高優先順位のものである場合には、それが先
にスケジューリングされ、クライアント・メッセージ処
理を優先使用することができる。その場合、サーバは、
それが早期終了しなければならないことをクライアント
・メッセージ処理スレッドによって連絡するように、ユ
ーザ・レベルの状態を設定することができる。
【０２８３】4.1.9.2 thread_abort_safely thread_abortとは異なり、thread_abort_safelyの目的
は、進行中の実行ストリームを論理的に打ち切ることで
はなく、単にそれを中断することである。thread_abort
_safelyは、非同期信号を送達するためにユーザ・レベ
ル・ルーチンを実行することができる状態にターゲット
・スレッドを変更する必要がある。この場合、それは、
同期実行ストリームにとって透過な方法で回復しなけれ
ばならない。ＣＭＵのmach_msgでは、スレッドの打切り
の結果、thread_abort_sendまたはthread_abort_rcvを
伴うmach_msg呼出しに戻る。これらの呼出しは再始動可
能であったが、再始動の有無を検査し、再始動を実行す
るには、小さい解釈ループと余分なプロシージャ呼出し
が必要であった。
【０２８４】メッセージ・ライブラリには、メッセージ
引渡し呼出しに組み込まれるユーザ・レベルの再試行が
ない。thread_abort_safelyとthread_signalは、例外メ
ッセージを送達するために戻りスタックが設定されるよ
うに協同し、例外ルーチンが戻ると、カーネルへのトラ
ップ・バックが発生する。例外トラップからの戻りは、
スレッド構造を検査し、どの待ち行列が待機中かを判定
し、それを元の場所に戻す。thread_abort_sendおよびt
hread_abort_rcvをユーザ・レベルに戻すために互換性
オプションを用意することは現在計画されていない。絶
対に必要であれば、それを戻すことができるが、活動状
態のときは、その結果、以下に概要を示す方法で回避さ
れる人工物と非効率がスケジューリングされる。要求と
応答は、それぞれの待ち行列から切り取らなければなら
ないはずで、クライアントは要求待ち行列内のその位置
を失い、ポート待ち行列と対話するためにケイパビリテ
ィ・エンジン３００への高価な呼出しが必要になる。
【０２８５】上記のthread_abortケースと同様に、要求
待機からメッセージを打ち切る場合、thread_abort_saf
elyは検出不能である。また、応答待機からの打切りの
場合にも検出不能である。実際には、クライアント・ス
レッドが要求または応答待機のいずれかから効果的に除
去されるわけではない。クライアントがthread_abort_s
afelyを検出したときに、要求を実行するのに必要な資
源はそのまま待ち行列上に残っている。能動サーバの場
合、サーバ・スレッドは、進行中のthread_abort_safel
yの間にも自由にこの要求を拾い上げることができる。
受動サーバ・モデルの場合、他の指示がない限り（以下
のリアルタイムの考慮事項を参照）、シャトルのクロー
ンが作成され、サーバがその要求を処理する。それを調
べるもう１つの方法は、thread_abort_safelyが検出さ
れたときのものである。ＲＰＣはクライアントのスレッ
ド本体から分離される。このthread_bodyは、シャトル
が付与されており、例外メッセージ・ルーチンを実行す
るよう指示される。例外メッセージ・ルーチンが戻る
と、それはカーネルに戻る。次に、メッセージ引渡しラ
イブラリ２２０は、シャトルを除去し、ＲＰＣへのクラ
イアント・スレッド接続を再確立する。その間、クライ
アント空間での応答資源の配置を含む、ＲＰＣ全体が行
われた可能性もある。能動モデルに関する正確な推論が
あるが、ただし、スケジューリング上の困難を伴わな
い。
【０２８６】thread_abort_safely呼出し中でもＲＰＣ
によってリンクが維持され、スレッドが終了用にスケジ
ューリングされていれば、おそらくthread_abortによ
り、ＲＰＣが到達可能になり、応答ポートおよび送信要
求は4.1.9.1項で前述したような挙動を示す。サーバ資
源は、ゾンビ化した応答ポートに永続的に固定されない
ことが保証される。
【０２８７】thread_abort_safelyに関してリアルタイ
ムの問題を考察する方法がいくつかある。非同期信号送
出プロセスは本来はスケジュール可能な事象であると論
じることは可能である。例外メッセージ・ポートは、そ
の信号のターゲットとなるスレッドに関連するスケジュ
ーリング情報とは別に、スケジューリング優先順位を伴
うはずである。このモデルでは、進行中のＲＰＣに関し
て一切アクションを取る必要がない。しかし、信号をタ
ーゲット・スレッド自体によって行われる行為と見なす
と、少なくとも受動サーバ・ケースではＲＰＣのスケジ
ューリング情報を調整する必要がある。ＲＰＣの要求が
考慮されていなかった場合には、スケジューリング情報
を変更して中断を反映することができる。当然のことな
がら、これは、処理される待ち行列化要求の順序に影響
する場合がある。要求がすでに進行中で、クライアント
の打切り通知ポートが活動状態である場合、メッセージ
・サービスは、要求を中断する必要があることを示すメ
ッセージをサーバに送信することができる。クライアン
トの通知ポートが活動状態ではなく、サーバが無名応答
を使用している場合には、サーバ・スレッドが中断され
る可能性がある。他の手法は完了時間に影響するので、
最初の非介入手法が最も広範囲の関心を集めると想定す
ると、これは、thread_abort_safelyを同期実行パスに
とって透過なものにしようとする試みと矛盾する。
【０２８８】4.1.9.3 thread_abort_notify 前述のように、thread_abort_notifyの主な目的は、メ
ッセージ引渡し呼出しから戻ったときにメッセージ引渡
しサービスの呼出し側に情報のない信号を送達すること
である。適切な時期に信号を送達しようと努力する間
に、呼出しが打ち切られる可能性があるが、その方法は
再始動可能なものだけである。thread_abort_notify
は、メッセージ引渡し要求からの戻り状況の一部として
信号を送達するだけである。このため、メッセージ待ち
行列上で待機していないかまたはユーザ・レベルにある
スレッドにthread_abort_notifyが送られた場合、その
スレッドはnotify_signal状態になり、アクションは、
通知を送達できる状態にそれが達するまで遅延される。
【０２８９】実際にこの通知方法は打切りを伴うので、
上記のthread_abort_safelyの場合のようにＲＰＣでの
完了時間異常を回避することは不可能である。これは、
同期実行ストリームに信号を公表する必要性の直接の結
果である。というのは、abort_notifyが同期実行ストリ
ームにとって可視であり、主流の機能ではないからであ
る。thread_abort_notifyを無視するためのオプション
は、メッセージ・ヘッダに含まれている。
【０２９０】thread_abort_notifyが、要求待ち行列上
でブロックされたスレッドによって検出されると、その
結果、要求は待ち行列から除去され、クライアントはth
read_abort_notify_sendメッセージを受け取る。人工物
は一切なく、サーバは要求にまったく気付かなかったの
で、クライアントは、それに向けられた通知信号の処理
に基づいて、ＲＰＣの再試行を行うかどうかを自由に選
択できる。
【０２９１】thread_abort_notifyが応答待機を打ち切
ると、クライアント・スレッドは、応答待機待ち行列か
ら外され、thread_abort_notify_receiveの状況ととも
に返される。その場合、クライアントは、自由に通知を
処理し、応答ポートでの受信を行ってＲＰＣを続行する
ことができる。クライアントが明示応答ポートを使って
その要求を行った場合を除き、thread_abort_notifyは
応答待機を打ち切ることはない。これが行われた理由
は、無名応答を待っている間にクライアントを戻すには
クライアントが応答ポートで受信を行う代わりに特殊ト
ラップによって戻る必要があったか、または無名応答ポ
ートに対する受信権がクライアントの空間内に入ってい
なければならなかったためである。
【０２９２】クライアントが実際に明示応答を供給する
場合、システム設計者は、特に受動サーバ・モデルの場
合に関連ＲＰＣに関するサーバの要求処理のスケジュー
リングを左右するために何らかのアクションを取らざる
を得ないと感じることがある。このケースは、同期コー
ド・パスが活動化されるという点で、thread_abort_saf
elyとは異なる。このコードは、自由に起動して何でも
実行することができ、その戻りを遅らせて応答をいつま
でも待つ。それはthread_abort_safelyの個別の信号処
理コード・パスによるので、システムをこの挙動から保
護することは不可能である。このため、応答時の打切り
は、センダーが無名応答ポート・オプションを使用して
いない限り、メッセージ引渡しライブラリ２２０でも抑
止される。そのオプションを使用している場合は、サー
バ・スレッドに対して信号が送出される可能性があり、
あるいはクライアントの打切りメッセージ（通知風のも
の）をサーバに送信できるようにクライアントの打切り
通知ポートが活動状態になる。
【０２９３】4.1.10 共用メモリ・サポート８００ 共用メモリ領域は、２つの手段によってメッセージ引渡
しライブラリ２２０を介して確立することができる。２
つの手段とは、１：共用領域を確立するためにサーバ側
に突合せ上書きを指定した明示共用メモリ被参照パラメ
ータ、または２：共用ケイパビリティの引渡しである。
どちらの方法でも領域が確立されるが、最初の方法は、
ＲＰＣにより適していると考えられるので、この項では
この方法についてのみ詳細に説明する。共用ケイパビリ
ティの引渡しは、サーバへの強制力が低い。サーバは、
自由にこのケイパビリティを別のタスクに送信すること
ができるので、書込みが単一送信ではなく送信権だった
場合、サーバは共用領域を他のものと共用する可能性が
ある。これにより、複数の当事者間の共通バッファが作
成される。サーバは、マッピング呼出しの際に元の権利
を消費する前に第三者に渡されるメッセージでこのケイ
パビリティのコピー送信を行うことによって、これを実
行する。メッセージ受信でのデータの転送はメッセージ
の送信によって行われるが、ＲＰＣについては同報通信
が定義されていないので、メッセージ・バッファが充填
されたかまたは解放されたという明白な信号を受け取る
のは、ターゲット・サーバだけになる。共用領域ではケ
イパビリティを確立できないので、明示共用メモリ・セ
ットアップのケースでは、同報通信からの保護が得られ
る。
【０２９４】サーバの大多数は状態なしである。すなわ
ち、関連応答の送達を超える要求に関連するデータから
明確に獲得した情報を保持していない。（当然のことな
がら、これは、使用頻度および資源要件に関する確率情
報を含んでいない。）状態なしサーバが優勢であるた
め、ＲＰＣにおける共用メモリ使用の諸ケースは、クラ
イアントが要求で制御を渡し、応答で制御を回復するこ
とにきわめて有利になると予想される。クライアント
は、要求で情報を渡すか、または応答でそれを回復する
か、あるいはその両方を行うことができる。図３４は、
共用メモリを確立するために行われる諸ステップと、デ
ータをやりとりするためのプロトコルとの概要を示す図
である。
【０２９５】共用メモリ領域の確立は、ローカル空間内
の共用領域のサイズと位置に関する情報と、遠隔タスク
におけるその領域の所在に関する詳細を保管するため
に、メッセージ引渡しライブラリ２２０がデータ構造を
作成することを含んでいる。この情報は、両当事者のタ
スク構造に付加される。１つの最終警告：複数マッピン
グは、２つ以上のタスク間の領域のマッピングであり、
その結果、各共用領域を通過するごとに解析しなければ
ならない共用データ構造の連係リストが作成される。同
報通信に対する明白な必要性がない限り、このような事
態は回避すべきである。
【０２９６】センダーとレシーバ両方の活発なサポート
と知識がなければ、共用メモリ領域を作成することがで
きないことは、留意すべき重要なことである。センダー
とレシーバはどちらも、それぞれの空間内の共用領域の
サイズと位置に気付くようになる。このため、特定のク
ライアントが十分承認されていないとサーバが判断した
場合、サーバはクライアントが指示した共用の受入れを
拒否することができる。共用領域も、一方の当事者がそ
れを確立し、共用するためにそれを捧げるという意味で
指向性である。能動サーバ・ケースでは、クライアント
によって提供された共用メモリのある領域の補助ページ
ャをサーバが承認できないということがよくあるので、
これは重要である。関連ページャが非活動状態なので、
メモリ障害が発生したときにサーバを停止させる可能性
がある。この場合、領域を提供するのはサーバでなけれ
ばならない。当然のことながら、その領域はサーバが承
認するページャによって支援される。リアルタイムに関
する考慮事項により、クライアント・ページャの問題に
もかかわらず、クライアントが指示した共用が受動サー
バ・モデルでの選り抜きの方法になる可能性がある。受
動モデルは、クライアントの実行スレッドがサーバ空間
に入ったと断言する。この場合、クライアントが承認し
ない可能性があるのはサーバ・ページャである。クライ
アント要求に関連するスレッドが不適当なページャのた
めに停止する場合、呼出しに関連するスレッド本体資源
は、他の資源に関するブロック要求での優先順位の逆転
を防止するために使用したのと同じ機構により、再利用
することができる。
【０２９７】メッセージ制御構造を使用すると、クライ
アントは共用バッファを静的（そのサイズがメッセージ
制御構造に記述される）または動的（呼出しの別のパラ
メータがサイズ提示に対応する）に送信することができ
る。上書きオプションは、マップ式メモリの指定の領域
に上書き領域を指示する能力をレシーバに与えるか、ま
たは事前にマッピングされていないメモリに上書き領域
を配置できるようにするものである。
【０２９８】図３５では、メッセージ引渡しライブラリ
２２０はサーバ側の上書きバッファを調べない。すなわ
ち、ライブラリは、共用領域の初期設定時にセットアッ
プされたタスク固有の状態情報を検査することによっ
て、クライアント領域が実際にサーバによって共用され
ているのかどうかを検査して確認する。クライアント領
域が共用されている場合、ライブラリは物理共用かどう
かを検査して確認し、物理共用の場合は、サイズと変換
後のアドレスを渡すだけである。物理共用ではない場合
は、データの明示コピーを実行する。共用されていない
場合は、クライアントにエラーを返す。
【０２９９】メッセージ引渡しライブラリ２２０は、共
用メモリ領域の使用に関しては非常にフレキシブルであ
る。どちらの当事者もその領域のデータを送信すること
ができる。また、どちらの当事者も呼出しを開始するこ
とができる。すなわち、クライアントの空間内でサーバ
を呼び出したクライアントがサーバ・タスク空間内に存
在した場合、メッセージ引渡しライブラリ２２０はそれ
をサポートするはずである。さらに、共用領域の全部ま
たは一部が転送に関与する可能性がある。クライアント
は、共用領域内のどのアドレスでも転送を開始すること
ができ、共用領域に含まれる最後のアドレスまでのどの
アドレスでも終了することができる。メッセージは、別
々のパラメータで同一共用領域から得た複数の区域を含
んでもよい。複数の共用領域からのデータは同一メッセ
ージで渡すことができる。
【０３００】4.1.11 単方向メッセージのサポート ＲＰＣシステムの単方向メッセージ・サポートは、矛盾
語法という印象を与えがちである。しかし、特にサーバ
側で単方向メッセージのサポートが必要になる条件がい
くつかある。能動サーバ・パラダイムでは、サーバ・ス
レッドは通常、次のメッセージを続けて受信することに
よって応答を実行する。これは、定常状態条件の場合に
は優れたものであるが、それを開始する方法が問題であ
る。単方向受信によってサーバを始動するというのがそ
の答えである。スレッド資源はスリープ状態になり、最
初のメッセージの到着を待つ。
【０３０１】サーバは、特定のメッセージがブロックさ
れて資源を待っている間に後続メッセージを処理するこ
とを便利であると判断する場合もある。さらに、サーバ
は、ブロックされたメッセージに関連するスレッド資源
の使用を希望する場合もある。明示応答ポートの場合に
は、サーバはこれを実行することができる。次のメッセ
ージを獲得するために、応答せずに受信を実行しなけれ
ばならなくなる。ブロックされたメッセージが最終的に
再活動化されると、サーバは、応答を始めるために単方
向送信を行わなければならないと判断する。
【０３０２】この場合も、このような単方向メッセージ
に関連するＲＰＣセマンティクスがある。メッセージ制
御構造情報は、応答とともに送信される場合、ＲＰＣの
合体形式になっていなければならない。応答と要求のい
ずれの場合も、基本的に転送は、4.1.3項に概要を示し
たクライアント側のメッセージ制御構造の制御下にあ
る。
【０３０３】単方向ＲＰＣ送信はクライアント側ではサ
ポートされないので、thread_abort_notifyがなけれ
ば、クライアントのone_wayＲＰＣ受信をサポートする
必要はないはずである。thread_abort_notifyの場合に
クライアントが応答待機から打ち切られると、thread_a
bort_notify_receive信号がクライアントに返される。
この場合、クライアントは応答待機を明示的に再確立し
なければならない。クライアントに直接信号としてthre
ad_abort_sendとthread_abort_rcvを返すために前のthr
ead_abort_safelyオプションのサポートが必要になった
場合、応答待機を明示的に再確立するための要件も検出
される。（これは、前のインタフェースとの互換性を維
持するために必要になる可能性がある。）thread_abort
_notifyの場合のように、クライアント・コードが応答
待機を明示的に再確立することが必要になるはずであ
る。
【０３０４】4.1.12 インタフェース・ジェネレータの
役割 メッセージ引渡しライブラリ２２０のＲＰＣ実施態様
は、コンパイル済みフロント・エンドを必要とせずにＲ
ＰＣをサポートするためのものであった。メッセージ引
渡しライブラリ２２０によって提示されるインタフェー
スにより、代理人ルーチンは、高価な実行時解釈を行わ
ずにＲＰＣをサポートすることができる。メッセージ引
渡しライブラリ２２０がコンパイルまたはその他の処理
を行ったフロント・エンドをサポートしないとは言えな
いものの、単純なメッセージ制御構造作成ルーチンによ
ってＲＰＣをサポートすることができる。
【０３０５】ＲＰＣインタフェースは様々なフロント・
エンドで動作すると完全に期待されている。後方互換の
ためにＭＩＧツールがメッセージ引渡しライブラリ２２
０に移植されている。これは、機能性の増大をサポート
するために拡張されたものである。ＭＩＧフロント・エ
ンドの移植によって、ＭＩＧインタフェースが明らかに
したように新しいＲＰＣが既存の機能性のスーパセット
であることが分かっている。既存のアプリケーション・
コード・ベースとの互換性を提供するために、他のフロ
ント・エンドを移植することもできる。
【０３０６】メッセージ引渡しライブラリ２２０がＲＰ
Ｃインタフェース全体をサポートするので、フロント・
エンドはコンテキストのない文法である必要はない。そ
れは、単なる有限状態の自動装置であってもよい。この
ため、フロント・エンドのコンパイラの設計とコードが
大幅に単純化される。しかし、別のモデルまたは拡張モ
デルが必要な場合は、メッセージ・バッファの内容をフ
ロント・エンドで操作することによってマシン上のパフ
ォーマンスが改善される箇所がいくつかある。
【０３０７】メッセージ引渡しライブラリ２２０は、状
況によっては２重間接ポインタを受け入れる（すなわ
ち、一部のマシンは、保護定義域境界での参照解除ポイ
ンタの箇所で非常に低速になる可能性がある）ので、お
そらく２倍のユーザ空間でポインタを参照解除し、それ
を直接データにする方が優れている場合もある。この場
合、クライアントへの直接データの書戻しを規定するメ
ッセージ・オプションが必要になるはずである。動的デ
ータ・フィールドであれば、静的データ・フィールドに
変換することができる。この場合は、そこに静的バッフ
ァ長が保管されているので、各パスによってメッセージ
制御構造を作成することが必要になるはずであるが、そ
れによって、個別のカウント・パラメータの必要性が除
去されるはずである。最後に、すべての直接パラメータ
を単一の直接データ・フィールドに合体させて、メッセ
ージ引渡しライブラリ２２０で必要な解析時間を短縮す
ることも可能である。
【０３０８】これらのオプションのいずれかによって、
ほとんどの場合に実際にパフォーマンスが向上するとは
予想されていないが、ＲＰＣインタフェースのフレキシ
ビリティを示すために述べられている。ＲＰＣインタフ
ェースは、サーバ・インタフェースをひとまとめにした
り、代理人機能テーブルとメッセージ制御構造テーブル
を作成するわけではない。これを自動化することができ
るフロント・エンドを備えていると便利である。また、
フロント・エンドは、データ変換を実行するための適正
箇所を証明する場合もある。最も重要なのは、フロント
・エンド・サポートと共存要件とを調整し、遠隔および
ローカルの代理人ライブラリの生成をできるだけ自動化
したものにする必要がある点である。
【０３０９】4.2 同期および非同期の単方向および双
方向プロセス間通信 ＩＰＣデータ型のセットは、ＲＰＣの大きくしかもほぼ
完全なサブセットである。ＩＰＣデータ型は、ケイパビ
リティ、直接データ、および被参照データ型の大部分を
サポートする。ＩＰＣデータ型によってサポートされて
いない唯一の被参照データ型は、要求と応答とのセマン
ティクス上のリンクおよび合体したメッセージ制御構造
のためにＲＰＣに存在する、Server_Allocateである。
（要求および応答のメッセージ形式とバッファ処置に関
して合体されている。）4.2.3項に概要を示すように、
ＩＰＣデータ型用のメッセージ制御構造はＲＰＣのもの
と同じ形式であるが、双方向メッセージの場合でも転送
の送信部分にしか関係しない。したがって、パラメータ
記述子は送信情報のみ含んでいる。ＩＮ／ＯＵＴまたは
ＩＮ記述子が存在しないので、応答バッファ処置に関連
するフィールドは無視される。図３６は、単純なＩＰＣ
メッセージ引渡しの概要である。
【０３１０】ヘッダ、メッセージ制御構造、およびメッ
セージは連続ユニットとして示されている。というの
は、多数のＩＰＣデータ型では、アプリケーション自体
がメッセージを認識し、メッセージを作成するので、代
理人が存在しないからである。したがって、これらのフ
ィールドを連続配置すると便利な場合が多くなる。非代
理人使用の場合でも、ＩＰＣデータ型サーバがこのよう
な任意選択の伝送情報の受信を希望する場合があるの
で、伝送領域を任意選択の伝送情報の発信に使用するこ
とができる。（メッセージ・バッファ内でのフィールド
配置のために伝送情報セクションをしない場合は、当然
のことながら、センダーはいつでもこれらのフィールド
を確認することになる。）伝送情報を受信する場合は、
メッセージ制御構造のメッセージ・バッファ記述子が受
信時にメッセージ・バッファの形式に影響することはな
いので、呼出し側は伝送セクションを使用しなければな
らない。
【０３１１】待機中のレシーバが検出されない場合、メ
ッセージ引渡しライブラリ２２０はメッセージを作成す
る。これには、以下の処理の一部または全部が含まれる
可能性がある。 ・すでに実行されていない場合は、メッセージ構造のコ
ピーイン。メッセージは待ち行列解除されるまではセン
ダーまたはレシーバの空間に常駐しないので、メッセー
ジ待ち行列のためのカーネル・アドレス空間バージョン
を作成しなければならない。 ・被参照sender-deallocオプションが選択された場合
は、センダー・バッファの割振り解除。 ・move_send処置によるメッセージにおけるポート用の
センダーのポート空間の更新。メモリ・ケイパビリティ
の移動を含む。 ・ケイパビリティ・エンジンへの呼出しによる、エクス
テント・メモリ領域の作成と、その後の無名ケイパビリ
ティの作成。（あるいは、小さい被参照フィールドをメ
ッセージの直接データ部分にコピーする。） ・送信されたすべてのポート権をメッセージ内の裸のポ
ート権（空間を持たない権利）に変更する。 ・拡張ケイパビリティを反映するためにメッセージ・バ
ッファのフィールドを更新する。センダーが意図した通
りにレシーバがバッファを獲得するように、元のバッフ
ァ・タイプを追跡する。 ・非ローカル共用領域の即時更新： メッセージ提示
は、センダーの観点からの同期点を表す。この結果、実
際の共用メモリとエミュレートしたケースとの間にわず
かな挙動の違いが発生する可能性があるが、センダーが
個別の同期事象を検出するまでバッファの変更を止めな
い限りこの挙動は定義されないので、このような違いは
問題にならない。レシーバがそのメッセージを受信し、
共用領域のデータを処理し終えるまで、この同期事象は
発生しない。
【０３１２】レシーバは、メッセージの到着前または到
着後に受信を試みる場合がある。到着前の場合は、レシ
ーバがブロックし、メッセージを待つ。到着後の場合
は、メッセージが待ち行列解除され、無名ケイパビリテ
ィに関連するデータがマッピングされ、ケイパビリティ
とポート権がレシーバの空間に移され、図３７に示すよ
うに、メッセージ・バッファ、メッセージ制御構造（要
求された場合）、およびサーバ一時データが受信バッフ
ァに移される。
【０３１３】ＲＰＣケースのように、メッセージ引渡し
ライブラリ２２０は、レシーバの要求により伝送プロト
コル拡張をセットアップする。レシーバは、自由に上書
きバッファとして送信し、被参照データの配置を左右
し、ケイパビリティから被参照フィールドへの変換およ
びその逆の変換を行うことができる。
【０３１４】メッセージ引渡しライブラリ２２０によっ
て定義されるＩＰＣデータ型のクラスには、同期単方
向、同期双方向、非同期単方向、および非同期双方向の
各メッセージが含まれる。ＲＰＣの要求と応答の場合の
ように送信とレシーバがセマンティクス上リンクされな
いので、ＩＰＣの同期双方向クラスとＲＰＣとを区別す
ることができる。受信の形式は、送信の形式とは異なる
可能性があり、おそらく異なるものになるので、センダ
ーは送信時に受信の形式情報を供給しない。ＩＰＣデー
タ型はメッセージ周辺に集中しているが、機能呼出しに
例示されているように、ＲＰＣは通信周辺に集中してい
る。また、ＩＰＣは代理人機能を使用することができる
が、そのようにする可能性は低く、ＲＰＣの場合のよう
にメッセージ引渡しモデルがアプリケーションから隠蔽
されることはない。このため、メッセージ・バッファ内
のパラメータの１つとして宛先ポートを見つける可能性
がかなり高いと思われる。
【０３１５】前述の図は、非同期単方向ＩＰＣデータ型
を示している。メッセージが１つのエンティティによっ
て送信され、待ち行列上に置かれ、別のエンティティに
よって受信されるので、非同期単方向はＩＰＣデータ型
の最も基本的な形式である。ＩＰＣデータ型の残りの３
つのサブクラスは、非同期呼出しの組合せとして表すこ
とができ、パフォーマンスとより広範囲の資源制御上の
考慮事項についてのみ、メッセージ引渡しライブラリ２
２０によって直接サポートされる。同期双方向は、両当
事者が許される待ち行列長ゼロを使用して送受信対を実
行することによって模倣することが可能である。当然の
ことながら、一方の当事者は、対になっていない受信に
よって業務に取りかからなければならないはずである。
非同期双方向は、アプリケーション・レベルでの同じ送
受信対によって模倣することが可能である。しかし、セ
ンダーが待機中のレシーバを検出しなかった場合には、
メッセージの待ち行列化が可能なはずである。単方向同
期は、受信がデータを含まない送受信対または関連メッ
セージ待ち行列長がゼロである送信に分解することが可
能である。
【０３１６】4.2.1 単方向メッセージ 単方向の同期および非同期両方のメッセージ引渡しは、
遠隔当事者へのメッセージの送達を伴う。しかし、同期
ケースでは、レシーバが実際にメッセージを受信するま
でセンダーがブロックされる。このモデルは、メッセー
ジ待ち行列長をゼロに設定することによってサポートさ
れる。同期ケースは、通常の非同期単方向メッセージと
の差はわずかなので、実施態様の観点からはまったく平
凡であると思われるが、強制同期によって明示メッセー
ジ作成の回避が可能になる。このため、同期単方向ＩＰ
Ｃデータ型は、ＲＰＣと同じ最適化および定義済み資源
使用を享受することができる。図３８は、同期単方向メ
ッセージ引渡しを示す図である。非同期単方向送信は、
レシーバが待機を検出するとこれと同様の挙動を示し、
レシーバが継続的に使用可能な状態に維持されていると
パフォーマンスの向上が得られる。
【０３１７】同期送信の最適化は、明示メッセージ作成
を回避することである。したがって、この場合も、被参
照データ型に関するケイパビリティの明示作成を回避す
るために3.1項に概要を示した方法を使用する機会が得
られる。また、一時メッセージ構造のためのメッセージ
・ライブラリ・レベルのアドレス空間資源の使用も回避
することができる。ＲＰＣの項で概要を示したこの用法
は、メッセージ内の直接データの量と待ち行列化したメ
ッセージの数に直接依存するので、予測しにくいもので
ある。したがって、同期送信を使用するシステムでは、
メッセージ作成回避が使用できると、システム・レベル
の資源管理の際にかなり有利になる。
【０３１８】同期ケースと非同期ケースのどちらでも、
server_temporaryの用法はセンダーとレシーバとの間の
アプリケーション・レベルの規則の影響を受け、レシー
バがたとえばある量の空間を提供していることを知り、
あるいは検出されるメッセージ形式を列挙されたセット
に限定する。レシーバが着信メッセージに関してほとん
ど知識がなく、センダーのメッセージ制御構造を要求し
なければならないような総称メッセージ引渡しでは、Ｉ
ＰＣデータ型が使用されることが非常に多くなると予想
される。メッセージ・デマルチプレクシングおよび単一
使用レシーバがサポートされ、便宜とパフォーマンス上
の利点を提供する。事情が許すときは、これらを使用す
る必要がある。
【０３１９】4.2.2 双方向メッセージ 最も単純なレベルでは、別々の送信と受信ではなく単一
の送受信呼出しの実行が可能なので、双方向挙動をエミ
ュレートする単方向メッセージより、双方向メッセージ
の方が有利である。メッセージ引渡しライブラリ２２０
が単一呼出し上に複数のコマンドを組み合わせる他の最
適化と同様、メッセージ引渡しライブラリ２２０が上記
の２通りの単方向基本送信間の初期の関係に気付かなけ
ればならないときに、一連のサブクラスが発生する。双
方向メッセージ例のケースは、以下の通りである。 １．当事者１は送信と受信を実行し、当事者２は送信と
受信を実行し、ともに非同期である。（非同期双方向に
よってサポートされる。） ２．当事者１は送信と受信を実行し、当事者２は受信を
実行し、データを処理してから送信を実行する。（同期
および非同期双方向によってサポートされる。ＲＰＣケ
ースのように、当事者２は単独受信によって処理に取り
かかる。） ３．当事者１は送信と受信を実行し、当事者２は受信を
実行するが、送信は別のスレッドによって行われる。
（非同期および同期双方向によってサポートされるが、
サーバは無名応答ポート・オプションを使用することが
できない。） ４．上記３と同じであるが、着信データと発信データが
リンクされない。（非同期のみで、同期双方向は応答を
待つはずである。ローカルの呼出し側は、それが送信す
るデータが処理されている間、遠隔データを処理する機
会を逸するはずである。）
【０３２０】双方向ＩＰＣデータ型サポートはパフォー
マンス上の最適化の１つであることは、強調する必要が
ある。双方向が受け入れられない場合でも、機能上の完
全さを確保して、単方向メッセージが使用される可能性
がある。しかも、単方向メッセージと双方向メッセージ
は完全に互換性がある。上記のいずれの場合も、当事者
１または当事者２は、相手方が変更を検出できずに単方
向メッセージを代用することが可能である。ただし、上
記のクラスの一部は、同期と非同期両方の双方向によっ
てサポートされているが、それにもかかわらず、列挙さ
れていることに留意されたい。上記の列挙されたサブク
ラスが存在することによって、前述の単純呼出しの組合
せを上回るパフォーマンスの最適化が可能になる。
【０３２１】送信とレシーバが独立し、セマンティクス
上リンクされていないので、２種類のＩＰＣデータ型の
双方向メッセージとＲＰＣとを区別することができる。
送信と受信のメッセージ形式は異なる場合があり、セン
ダーは、応答形式情報を提供する必要がない。このリン
ク解除に従って、応答ポートに関するフレキシビリティ
が向上する。無名応答は双方向ＩＰＣデータ型でサポー
トされるが、同期双方向の場合のみであって、非同期ケ
ースでフラグが現れると、無名応答が受信の実行パスを
送信の実行パスにリンクするので、非同期双方向が同期
として扱われる。（初期センダーの場合は暗黙のうちに
行われ、初期レシーバの場合は当然、明示的に行われ
る。）また、ＩＰＣデータ型は、遠隔当事者に権利を引
き渡さずに受信を行うポートを示す方法としてヘッダの
応答ポート・フィールドを使用できるような、双方向メ
ッセージ引渡しもサポートする。呼出し側は、ヘッダの
応答フィールドにポートを提供するが、ローカル（応
答）ポート処置フィールドはブランクのままにすること
によって、これを達成する。これにより、あらゆるメッ
セージ・トランザクションにおいて、明示的な権利引渡
しより優れたパフォーマンスが得られる。これは、遠隔
当事者が返送用のポートをすでに把握し、権利に関する
コピー送信を実行するような場合に使用することができ
る。当然のことながら、ＩＰＣデータ型は、初期双方向
メッセージ起動者用の受信ポートとして、ならびにヘッ
ダのローカルまたは応答ポート処置情報フィールドに指
定された送信権または単一送信権のソースとして機能す
る応答ポートの標準的なケースをサポートする。
【０３２２】4.2.2.1 同期双方向ＩＰＣデータ型 同期双方向送信は、ＲＰＣのような要求と応答とのシス
テム・レベルのセマンティクス上のリンクが送信／受信
同期の問題から分離されているため、パフォーマンス上
の利点が得られる。同期双方向送信のＩＰＣデータ型リ
ンクでは、呼出し側によって送信されるメッセージ制御
構造がトランザクションの送信部分のみを記述すること
になる。この場合も、遠隔当事者がデータを返す前にデ
ータを操作するか、または遠隔当事者がデータを受け取
るまでデータの送達を希望しないというユーザの理解に
基づいて、遠隔レシーバが待機していないときにメッセ
ージ引渡しライブラリ２２０はその送信時に自由にロー
カル当事者（初期センダー）をブロックすることができ
る。これにより、メッセージ引渡しライブラリ２２０
は、明示メッセージ作成と、そのパフォーマンスおよび
資源コストを省くことができる。
【０３２３】ＲＰＣの場合と同様、センダーは、自由に
無名応答を宣言することができ、トランザクションの送
信部分に基づく遠隔当事者からの応答を待つことを意味
する。また、レシーバは、受信を受け持つスレッドが
（実行の点でのみ）リンクされた応答を実行することを
保証することによって、無名応答をサポートする場合も
ある。したがって、同期双方向ＩＰＣデータ型は、ＲＰ
Ｃが享受するもう１つのパフォーマンス上の利点を得
る。
【０３２４】同期双方向ＩＰＣデータ型は、トランザク
ションの両当事者が対称的な対等機能であるという点で
ＲＰＣとは異なっている。このため、アプリケーション
が当事者２から当事者１への直接データの返送を必要と
する場合、ＩＰＣデータ型に利点がもたらされる。ＲＰ
Ｃトランザクションでは、サーバから返されるメッセー
ジ・バッファ・データを間接データとして戻さなければ
ならないが、ＩＰＣデータ型トランザクションは、変更
した直接データを自由に戻すことができる。さらに、Ｉ
ＰＣタイプは、リンク解除された送信（応答に相関す
る）と一致するデータおよびパラメータだけを返送する
ことになる。応答の各種フィールド用の余分なパラメー
タを要求に含める必要はなく、要求に使用する各種フィ
ールドは応答に現れない。パフォーマンス上の利点は小
さいが、双方向同期ＩＰＣデータ型モデルに無償で盛り
込まれる。
【０３２５】4.2.2.2 非同期双方向ＩＰＣデータ型 非同期と同期の双方向メッセージ間の違いは、遠隔レシ
ーバがまだ待機していない場合に送信時に双方向メッセ
ージがブロックしないことである。メッセージは作成さ
れ、非同期双方向起動者は受信を試みる。これは、送信
と受信がセマンティクス上リンクされていないようなア
プリケーションの非同期受信特性に対応するものであ
る。すなわち、遠隔当事者はローカルの双方向起動者に
送信するデータを持っているので、ローカル・スレッド
がアクセスするポート上にそのデータをダンプする。そ
の場合、ローカル・スレッドは、遠隔当事者用のデータ
によって双方向ＩＰＣデータ型を引き受ける。遠隔当事
者は受信待機中のスレッドを持つことができないが、ロ
ーカル・スレッドはそのデータを拾い上げ、ＩＰＣ１２
２から戻り、処理を続行することができる。
【０３２６】4.2.3 メッセージ制御情報の詳細 ＩＰＣデータ型のメッセージ制御構造の形式は、ＲＰＣ
のものと同じである。しかし、ＩＰＣデータ型には送信
専用の制約があるため、一般に、ＲＰＣを予期している
ポートにＩＰＣデータ型を送信することは不可能にな
る。これは、メッセージ引渡しライブラリ２２０によっ
て禁止されているわけではないが、ＩＰＣデータ型とＲ
ＰＣとに重複するメッセージのサブセットは無関係であ
る。レシーバは、着信メッセージが要求かまたは送信さ
れたＩＰＣデータ型かを示す明示表示を入手する。レシ
ーバがこの表示を検査する場合、そのスポット上のメッ
セージを拒否するか、またはメッセージ制御構造のパラ
メータ記述子を検査したときに不一致を検出する可能性
がある。特定のサーバがＩＰＣデータ型とＲＰＣメッセ
ージの両方を受け入れることをアプリケーション作成者
が希望することも考えられる。その場合、ポートはある
種の中間コレクション・ポイントになりうるので、この
理由により、メッセージ引渡しライブラリ２２０は不一
致の拒否を回避する。ＲＰＣの場合と同様、メッセージ
・バッファのすべてのフィールドが直接データで、メッ
セージ引渡しライブラリ２２０による変換を必要としな
い場合、そのメッセージは単純であると宣言され、明示
メッセージ制御構造なしで転送が行われる可能性があ
る。当然のことながら、レシーバは着信データを解析す
るために明示メッセージ制御構造を必要とする可能性が
あるので、クライアントはＲＰＣおよびＩＰＣデータ型
のどちらのケースでもそれを必ず供給しなければならな
い。
【０３２７】ＩＰＣデータ型はほとんどの場合に代理人
を使用せず、代理人を使用するときでもエンドポイント
がメッセージを認識する可能性があることが予想され
る。これは、ありそうもない特殊伝送状況フィールドを
使用する。状況戻りを使用してエンドポイント機能戻り
状況を引き渡し、ローカル機能のエミュレーションなら
びにプロシージャ呼出しを可能にする。また、ＩＰＣデ
ータ型の双方向トランザクションの当事者１と２からの
送信の対称性により、ＩＰＣデータ型は、ＲＰＣで検出
された直接データの引渡しの有用性の制限を受けない。
このため、代理人使用の軽視により、２重間接の使用が
低くなると予想される。
【０３２８】4.2.3.1 送信専用情報 ＩＰＣデータ型に使用するメッセージ制御構造は、ＲＰ
Ｃに使用するものと同じであるが、応答に関連する記述
子の各種フィールドはゼロでなければならない。これ
は、転送がＩＰＣデータ型の双方向であっても、メッセ
ージ制御構造がメッセージ・バッファの形式と、転送の
送信部分に関するバッファ処置情報のみを記述するから
である。具体的には、ＩＮ／ＯＵＴまたはＩＮパラメー
タが一切なく、応答バッファ処置オプションもない。そ
れでもセンダーは着信メッセージ・パラメータに関する
バッファ処置に影響するが、受信の正確な形式が送信に
よって決定されないので、より総称的な上書きバッファ
を使用しなければならない。メッセージ制御構造が受信
時のメッセージ・バッファ形式に一切影響しないという
事実は、ＩＰＣデータ型ユーザが実行時に自由に形式を
混合することができることを意味する。このようにその
形式を採用できる機会は、送信データと受信データとの
間にセマンティクス上のリンクが存在しないアプリケー
ションでは非常に有用である。というのは、それによっ
て、これらのアプリケーションが応答対の形式に対する
制約を受けずに送信／受信実行パスのパフォーマンス上
の最適化（4.4.2項を参照）を使用できるようになるか
らである。送信と受信がセマンティクス上リンクされて
いる場合にも利点がある。（メッセージ引渡しライブラ
リ２２０がＩＰＣデータ型の送信と受信のセマンティク
スおよび形式をリンクしないという事実があっても、そ
れによってアプリケーションがそのようなリンクを行え
なくなるわけではないことに留意されたい。）ＩＰＣデ
ータ型アプリケーションが様々な形式の応答メッセージ
によって特定のメッセージ・タイプに応答することが必
要になる場合もある。ＩＰＣデータ型のメッセージ制御
構造の送信専用性により、この領域での完全なフレキシ
ビリティがアプリケーションに与えられる。
【０３２９】メッセージ制御構造の送信専用モデルは、
ＲＰＣで見られた応答オーバライドも不必要なものにす
る。サーバがメッセージ引渡しライブラリ２２０にメッ
セージ制御構造を送信する唯一の理由は、サーバ側のバ
ッファ処置オプションのオーバライドを実行するためで
ある（具体的にはserver_dealloc、4.1.3項を参照）。
ＲＰＣケースでオーバライドされるものはクライアント
が供給する応答情報なので、ＩＰＣデータ型ではこのよ
うな状況が存在しない。ＩＰＣデータ型の場合、応答
（実際は対称相互送信）は初期送信プロセスの完全対称
反映に含まれるメッセージ制御構造によって完全に決ま
る。ＲＰＣでオーバライドを使用する主な理由は、上書
き構造によって要求に対するサーバ側のバッファ処置が
初期カストマイズされることである。上書き構造には、
着信被参照変数の配置およびクラスをケイパビリティと
して変更するか、またはその逆の変更を行うサーバ固有
の要求が含まれる。これは、複数の被参照変数を連続メ
モリまたは特定の個別位置に書き込むことを要求する場
合もある。詳細については、3.2.4.3項を参照された
い。上書きバッファの機能は、着信メッセージのデフォ
ルト・バッファ処置特性を受信側でオーバライドするこ
とに限定される。このため、その機能とＩＰＣデータ型
での使用法はＲＰＣの場合と同じになる。
【０３３０】受信は、ＩＰＣデータ型のセンダーを承認
しない場合、メッセージ制御構造を要求して、それをテ
ンプレートと照らし合わせなければならない。相互非承
認送信では、これは、当事者１と当事者２の両方がそれ
ぞれの送信においてメッセージ制御構造を供給し、受信
時にセンダーのメッセージ制御構造を要求することを意
味する。これは、メッセージの形式がメッセージＩＤに
固定または拘束されないような総称レシーバにも該当す
る。双方向ＩＰＣの場合に検査を２回行う必要があると
いうことは、ＲＰＣより不利である。
【０３３１】代理人使用に対する関心が低く、エンドポ
イントがメッセージを認識する可能性が高いため、ＩＰ
Ｃデータ型の双方向アプリケーションは、伝送オプショ
ンをメッセージ・バッファに入れる傾向が強くなる可能
性があるが、メッセージ制御構造は受信に一切影響しな
いので、情報オプションの要求をメッセージ・バッファ
に入れることはできない。
【０３３２】4.2.3.2 登録 すべてのメッセージが単方向として登録される点を除
き、ＩＰＣデータ型でメッセージ制御構造を登録し使用
する方法は、ＲＰＣの場合と同じである。双方向ＩＰＣ
データ型の場合でも、転送の各当事者は、送信側のメッ
セージ制御構造または登録値のいずれかを供給しなけれ
ばならない。（登録プロセスの詳細については、3.2.4.
3項を参照されたい。）
【０３３３】一般登録の項から想起されるように、クラ
イアント（またはセンダー）は、メッセージ制御構造の
コピーをサーバ（レシーバ）に送信し、関連の登録ハン
ドルを要求しなければならない。サーバは、１）要求を
拒否する、２）項目と既存のテンプレートとの突合せ後
にそれを承諾する、３）着信要求と既存のテンプレート
とを突き合わせ、そのセマンティクスが既存のテンプレ
ートに関する登録を戻すのに十分なほど近いものである
と判断する、または４）着信メッセージ制御構造のロー
カル・コピーを作成し、それを新しいテンプレートとし
てメッセージ引渡しシステムに登録し、新しい登録番号
を呼出し側に戻すという４通りのいずれかを自由に行う
ことができる。
【０３３４】メッセージはポートに登録され、その登録
は不変なので、ポートの存続期間中、変更することも取
り消すこともできない。したがって、メッセージ引渡し
サブシステムは、テンプレートのコピーを保管し、メッ
セージ送信時にそれを参照することができるようにな
る。ＩＰＣデータ型では、双方向送信の両当事者がそれ
ぞれの送信を相手方に登録することができる。この機会
は完全に対称的であるが、両方に登録する必要はない。
一方の当事者だけが登録をサポートする場合は、双方向
送信によって一方から登録ハンドルが送信され、もう一
方から従来のメッセージ制御構造が送信される。トラン
ザクションの両当事者が登録をサポートする場合は、当
事者１と当事者２にそれぞれ関連する２つのポートのそ
れぞれに、登録されたメッセージ制御構造からなるそれ
ぞれの独立リストが含まれる。
【０３３５】ＩＰＣ双方向では送信と受信のセマンティ
クスが分離されているので、送信側の無名応答操作が困
難になる。登録によってメッセージ制御構造がターゲッ
ト・ポートにリンクされるので、呼出し側はどちらもそ
の受信用のメッセージを登録することができず、遠隔当
事者が登録された送信を実行し、それが行う受信が無名
になる双方向メッセージの引受けに移行するものと予想
する。遠隔当事者は、登録を使用してそのメッセージを
送信することができなくなる。考えられる最善のパフォ
ーマンスをもたらす推奨手法では、呼出し側がその受信
に明示受信ポートを使用するが、その場合でも遠隔当事
者からの無名双方向を受け入れることになる。これは、
双方向送信対の両端から行うことができる。図３９は、
この方法の概要を示している。
【０３３６】図３９の図は、最適双方向送信を示してい
る。両当事者は、両者が遠隔当事者からの無名ポートを
受け入れることを示すビットをセットする。これは、両
者が送信メッセージを検出し、遠隔当事者が応答を予期
しているときに、メッセージを受け入れる当事者が無名
ポートで送信することを意味する。この場合、ローカル
当事者にとって無名に見えるポートが実際にシステムに
明示され、実際は適正メッセージ制御構造が登録される
ターゲット・ポートであることを両当事者が前もって理
解しておく必要がある。
【０３３７】上記の転送はスレッドＡによって開始され
る。初期送信では、宛先ポートが明示される。スレッド
Ａは、明示受信ポートも宣言するが、遠隔当事者が送信
／受信を試みた場合はそれ（スレッドＡ）が無名応答を
受け入れることを宣言するビットをセットする。このビ
ットをセットすることにより、スレッドＡは、それが対
になっている送信時に応答し、別のスレッドに業務を渡
さないことを宣言する。
【０３３８】スレッドＢは、初期受信から取りかからな
ければならない。他の状況では、スレッドＡが非同期双
方向を送信中であれば、スレッドＢが送信／受信から取
りかかるはずである。上記の場合にはこれは推奨できな
い。というのは、その結果、不必要な明示メッセージ作
成が行われると思われるだけでなく、より重要なこと
に、非同期双方向の結果、不適切な送信状況が返される
可能性があるからである。先に受信を経験せずに送信を
試みると、スレッド固有の状況が待機中の遠隔当事者を
反映しなくなる。無名受信は、送信とその後の受信から
なる順序づけられた対に依存しているので、無名受信と
非同期双方向との間には互換性がない。
【０３３９】さらに、スレッドＢは、明示応答ポートを
セットし、遠隔当事者からの無名ポートを受け入れるこ
とを示すビットをセットする。
【０３４０】上記のパフォーマンスはＩＰＣデータ型に
とって最適である。というのは、ポートＡとＢの両方
が、それぞれの受信を行うポートにそれぞれのメッセー
ジ制御構造を登録してあり、レシーバのポート空間に応
答用の送信権をプッシュする必要がないからである。
【０３４１】スレッドＡは、登録ＩＤ Ｘを使用してメ
ッセージを送信する。システムは、適切なメッセージ制
御構造を探索するためにＸを使用してスレッドＢにメッ
セージを送信し、その明示受信待ち行列にスレッドＡを
乗せるが、スレッドＢがメッセージを受け取る場合、遠
隔当事者から無名ポートを受け入れることに同意したと
いう事実は、スレッドＡがスリープ状態になっている明
示ポートに対する権利をスレッドＢに与える必要がない
ことを意味する。アプリケーションは、スレッドＡ用の
ローカル・ポート処置ビットをゼロにセットすることに
よって、この権利の引渡しを抑制する。メッセージをス
レッドＡに返すことによってスレッドＢが応答すると、
メッセージ引渡しライブラリ２２０はスレッドＡがスレ
ッドＢに関連するスレッド構造になっていると判断し、
スレッドＡを探索したときに、それがそのポート上でス
リープ状態になっていると判断する。その後、メッセー
ジ引渡しサブシステムは、スレッドＢによって送られた
登録ＩＤを使用して、スレッドＡがスリープ状態になっ
ているポートに関連するポート固有のメッセージ登録テ
ーブルへの索引付けを行う。スレッドＢはその送信を記
述するために登録ＩＤ Ｙを使用し、索引Ｙで検出され
たメッセージ制御構造を使用してメッセージを解析し、
スレッドＡにそのメッセージが与えられる。
【０３４２】両当事者はそれぞれの送信時に登録を使用
するので、明示送信権を送信の宛先に移動させずにすべ
ての受信を実行することができる。定常状態の場合、ス
レッドＡとスレッドＢは絶対的に対称的なので、両当事
者ともに明示ポートで受信し、それぞれのヘッダ内のロ
ーカル・ポート処置をゼロにセットし、登録を使用し、
送信／受信を実行する。
【０３４３】4.2.3.3 双方向送信／受信の例の混合と
突合せ 4.2.3.2項に概要を示したように、ＩＰＣデータ型双方
向では、送信／受信におけるＲＰＣにほぼ匹敵するパフ
ォーマンスを達成することができるが、双方向を行うだ
けでなく、ＲＰＣに近いパフォーマンスでそれを実行す
るためにプログラマがセットアップする際の複雑さは相
当なものになる。ＩＰＣデータ型の見返りは、送信およ
び受信時に対になったメッセージの関連付けの絶対的な
自由という形で現れる。送信に基づく受信の形式には一
切制約がない。図４０は、自由関連付けでメッセージを
送信する２当事者の例である。図４０の図は、異なるタ
スク空間で実行される２つのスレッドで構成された双方
向トランシーバを示している。
【０３４４】どちらのタスクにも、第三者ソースからそ
れぞれのアドレス空間にメッセージが送られてきてい
る。また、どちらのタスクにも、それぞれの空間から第
三者宛先に送られるメッセージがある。メッセージ形式
は様々であり、ＡとＢとを接続するパイプの一端に提示
されるメッセージともう一方の端部に提示されるメッセ
ージとの間に一定の関係はない。この例は、ＲＰＣにお
ける等価物がない場合にＩＰＣデータ型を利用できる主
な使い方の１つを表している。
【０３４５】4.2.3.4 上書きオプション 上書きオプションのＩＰＣデータ型サポートは、ＲＰＣ
のものと同じである。というのは、被参照データの配置
および被参照データからケイパビリティへの任意選択の
変換またはケイパビリティから被参照領域への変換に関
する受信側オプションに関与するのは上書きバッファの
みであるからである。
【０３４６】ＩＰＣデータ型では、双方向送信で両当事
者が使用できるという点で上書きバッファの使い方が異
なっている。双方向ＩＰＣデータ型は、２回の単方向メ
ッセージ引渡しを対称的に組み合わせたものであり、２
回の受信のそれぞれは、レシーバがどのように被参照お
よびケイパビリティ・パラメータを受け入れたいと希望
しているかに関するセンダーの想定をオーバライドする
資格がある。ＩＰＣデータ型において送信と受信とがセ
マンティクス上リンクされているため、２回目の受信時
の上書きバッファがパラメータ応答固有の被参照および
ケイパビリティ処理によって特別なクライアント・パラ
メータを置き換えてしまう。上書きは、要求が応答によ
って決まるように２回目の送信の形式が最初の送信によ
って決まらないという事実に基づいて着信データの処置
に影響するより一般的な方法である。２回目の送信の形
式は、デマルチプレックス受信の場合には複数のうちの
１つになり、本当の総称受信の場合には実行可能な形式
になる可能性がある。
【０３４７】4.2.4 双方向用の無名受信ポート・オプ
ション これまでに確立されているように、送信時のメッセージ
と受信時のメッセージとのセマンティクス上のリンクを
分離しても、システムがサポートする送信と受信との間
の実行パス・リンクが妨げられるわけではない。このよ
うなリンクは、受信したデータを受け入れるスレッドが
対になった送信を実行するスレッドになるという保証に
よりアプリケーション・レベルのレシーバが送信／受信
のリンクを確認することに基づいている。送受信対内の
リンクを維持することは、ＩＰＣデータ型における無名
受信の基礎である。
【０３４８】ＩＰＣデータ型メッセージの無名受信には
２つの制約事項がある。第一に、送受信対の順序付けを
頼りにしているので、非同期双方向の場合には受信側で
の無名受信を実行することができない。これは、送信時
に経験したような無名受信の使用、すなわち、双方向を
実行する際の明示受信ポートの供給障害を妨げるもので
はない。２つ目の制約事項は登録の使用に関するもので
ある。いずれの当事者も、送信側の無名オプションによ
って作成された無名ポートを待たず、登録ＩＤによって
メッセージの形式が示されるメッセージを受け取らな
い。図３９および4.2.3.2項を参照されたい。送信側の
無名応答ポート・サポートは、送信／受信を要求するオ
プションになり、明示応答ポートを供給しないように定
義されているので、送信のターゲットが応答ポートを必
要とするときはメッセージ引渡しライブラリ２２０が無
名ポートを作成することになる。
【０３４９】送信と受信両方のオプションを使用すると
パフォーマンスがいくらか改善されるが、送信側オプシ
ョンの最も重要な使い方は、対になった送信／受信の公
表を回避することによってクライアントが本当のプロシ
ージャ呼出しモデルと一致できるようにするＲＰＣであ
る。すなわち、遠隔プロシージャ呼出しのモデルが非ロ
ーカル・プロシージャを呼び出してその結果を返して戻
るときに、クライアントは明示応答ポートを作成する必
要がない。
【０３５０】4.2.5 サポートされるデータ型 アプリケーションとメッセージ引渡しライブラリ２２０
のＩＰＣデータ型態様との間の言語を送信専用情報に限
定することは、すでに分かっているように、単方向メッ
セージ送信としてのＩＰＣデータ型モデルと一致したも
のである。この限定は、基本データ型ケイパビリティお
よびマッピング決定のプロダクトまたは組合せとして現
れたデータ型のいくつかに影響を及ぼす。
【０３５１】4.2.5.1 ポートおよび被参照領域 すべての直接データの場合と同様、送信専用状況に限定
されるので、ＩＰＣデータ型では直接データとしてのポ
ートの扱い方が異なるわけではない。直接データを両方
向に送信できるようにするために後でＲＰＣを拡張する
場合でも、応答時に送られるポートは、メッセージ制御
構造内に新しいデータ型または追加状況を必要としな
い。いずれかの方向（要求または応答）にポートを送る
場合には、そのポート用のパラメータ・スポットが作成
される。両方向に送るわけではない場合には、ポートが
渡されない方向用のポート・パラメータに対応する箇所
のメッセージ・バッファ内にPORT_NULL値が置かれる。
【０３５２】被参照データとしてのポートすなわちポー
ト配列は、被参照タイプの１つに対応するバッファに収
容することができる。被参照タイプはＯＵＴパラメータ
に限定される。ＩＮ／ＯＵＴおよびＩＮパラメータは一
切存在しなくなる。しかも、Server_Allocateクラスは
存在しない。Server_Allocateクラスの理由は、サーバ
がクライアント用のデータを入れるバッファ記述を指定
したパラメータが存在することであり、インタフェース
の作成者は、要求時にメッセージ引渡しライブラリ２２
０がサーバにバッファを提供することを望まない。これ
は、パフォーマンスのため、ならびにＲＰＣでサポート
されるプロシージャ呼出しのサブセットを増大するため
に行われる。いずれの場合も、それは、要求時に応答が
把握されていることの直接の結果である。
【０３５３】Server_Deallocateは、Sender_Deallocate
という形でのみデータ型として存続する。要求時に供給
されず、応答において操作されることもなくなる。現在
ではそのアクションは、送信に関連するバッファでの直
接アクションに限定されている。Sender_Deallocate
は、ＩＰＣデータ型と、ＲＰＣのクライアント側に存在
する。
【０３５４】ＯＵＴクラスのみに限定されることを除
き、永続データは変わらない。
【０３５５】4.2.5.2 非持続メッセージ・データ 非持続メッセージ・データは、そのメッセージに関連す
るデータの処理以後は持続しないか、または少なくとも
後続メッセージのためにもう１回受信を行う必要性を上
回るほど必要とされなくなる、被参照によって渡される
データとして特徴づけることができる。ＲＰＣでは、こ
のサブクラスの被参照サポートはServer_Temporaryと呼
ばれる。このサブクラスのデータは、クライアントへの
応答で使用される可能性があるが、応答後は無用になる
ように定義されているので、それに関連する空間を再使
用することができる。
【０３５６】ＩＰＣデータ型の非持続メッセージ・デー
タはＲＰＣのServer_Temporaryと同じ機構を共用し、そ
の状況および最終的な取扱いは同様である。Server_Tem
poraryのように、ＩＰＣデータ型の非持続メモリは、ヘ
ッダ、メッセージ制御構造（要求された場合）、および
メッセージ本文に続いて、受信バッファ内に置かれる。
Server_Temporaryまたは非持続メモリ・データは前述の
３つの構造の後に続かなければならないという制約以外
は、これらは残りの空間に任意の順序で現れる可能性が
ある。Server_Temporaryと非持続データ型との主な違い
は、データが無効になる時期である。Server_Temporary
の場合は、応答時にそのデータを使用することができ
る。非持続の場合は、関連送信が処理されるとただちに
データはその重要性を失う。その後、ＩＰＣデータ型
は、送信の処理後ただちにバッファに関して希望する処
置を自由に実行することができる。ＲＰＣは、応答の送
信が完了するまで受信バッファを維持しなければならな
い。（これは、送信が応答として機能するその後の送信
／受信時にＲＰＣが受信バッファを使用することを妨げ
るものではない。）応答データがクライアントに書き戻
されるまで、受信とその後の受信バッファの上書きは行
われない。
【０３５７】4.2.5.3 共用メモリ・サポート ＲＰＣによってサポートされる共用メモリは、プロシー
ジャ呼出しにおける被参照パラメータ引渡しをパフォー
マンス上最適化したものである。このパラメータは、あ
らゆる点で転送時の通常のパラメータのように見える
が、このパラメータに関連する物理メモリが実際はクラ
イアントサーバとの間で共用される可能性があることを
メッセージ引渡しライブラリ２２０は認識している。こ
のため、少なくともインタフェース・プロトコル・レベ
ルでは、依然として共用メモリがアプリケーションにと
って透過のままになる。共用領域をセットアップするに
は諸ステップが必要であることは明らかである。しか
し、これは、個別のサービスで行われる可能性があり、
エンドポイントのサーバおよびクライアント・コードを
共用固有のプロトコル上の考慮事項から解放することが
できる。情報をやりとりする際にアプリケーション・コ
ードによってそのコード自体がこのバッファまたはその
一部分の使用に限定されると、そのコードは共用メモリ
・サポートの必要性を満足することになる。
【０３５８】統合共用メモリの機能性に関しては、ＲＰ
Ｃモデルはいくらか限定的であることが分かっている。
ＲＰＣは、３者以上の当事者間で行われる転送用に定義
されているわけではない。このため、4.1.10項に概要を
示した明示被参照手段によりＲＰＣの共用領域をセット
アップすることを推奨する。初期設定時には、クライア
ントは共用オプションをオンにして被参照ポインタを送
信する。サーバは、被参照共用領域を受け入れること
と、任意でそれを必要とする場所を示すような上書きを
セットアップする。このような共用領域は、２当事者間
でのみ共用することができる。共用領域に関する共用ケ
イパビリティの作成を試みると、エラーが返される。
【０３５９】ＲＰＣは、共用ケイパビリティによりセッ
トアップされた共用領域に作用することができるが、送
信共用ケイパビリティは所有者によってクローンが作成
され、複数の共用領域は別々のタスクにセットアップさ
れる可能性があるので、ＲＰＣについてはこれは推奨で
きない。ＲＰＣの場合でも、共用メモリのエミュレーシ
ョンに従って、共用領域をマッピングするタスクのリス
トが走査され、一部のメンバーが物理メモリを共用しな
い場合は、そのメンバーが更新される。しかし、呼出し
のターゲット・サーバである唯一のエンティティに対し
てメッセージが送信される。
【０３６０】ＩＰＣデータ型のセマンティクスは、ＲＰ
Ｃのように共用メモリ領域のセマンティクスを制限しな
い。当事者間でのみ共用されることが保証されている領
域のセットアップを希望する当事者にとって、共用メモ
リ領域初期設定の被参照形式は依然として重要である
が、複数当事者ケイパビリティ・ベースの共用メモリ・
サポートはメッセージ引渡しの基本要素によってもサポ
ートされる。
【０３６１】4.2.5.3.1 同報通信サポート 共用ケイパビリティによる共用メモリ領域初期設定は、
メッセージ引渡しライブラリ２２０が複数のアドレス空
間同士の複数方向共通領域所有権をセットアップするた
めの手段である。メッセージ引渡しライブラリ２２０に
共用空間を公表する目的は、共通物理メモリを共用しな
いタスク間の共用領域をエミュレートすることであるの
で、これは、同報通信の基本形と見なすことができる。
【０３６２】共用メモリの双方向概念のみをサポートす
るのであれば、メッセージの宛先に関連するポートは、
メッセージ引渡しライブラリ２２０の共用メモリ・サポ
ートのアクションの対象とするのに十分なはずである。
その場合、それがローカルであるかどうかを確認するた
めに宛先が検査される。それがローカルであって、宛先
空間が共用領域のマッピングを収容していれば、レシー
バの空間内の相関アドレスを反映するように被参照ポイ
ンタが更新されるはずである。宛先が共通メモリ資源を
共用しない場合は、「共用データ領域」を含む転送に関
連するデータがメッセージ収集され、ＮＯＲＭＡという
代理人ポートの概念のようなものによって転送されるは
ずである。モデルの観点からは、非ローカル処理が実際
は共用オプション・ビットを無視することにすぎないこ
とに留意することは重要である。代理人ポートＮＯＲＭ
Ａは、共用メモリに関して何も知る必要がなく、単に
「共用」領域からのデータを含むメッセージを送達する
だけである。遠隔端のメッセージ引渡しライブラリ２２
０のコードが、そのデータを「共用」領域に入れること
になる。
【０３６３】転送が複数方向になる場合、メッセージの
宛先ポートは十分なものにならない。このため、遠隔当
事者が受信権（または代理人ポート）を所有しているポ
ートが共用メモリ領域のマッピング項目に関連付けられ
る。このポートの所有者は、共用領域内のデータの転送
に関してそのポート上でメッセージを受け取る準備がで
きていなければならない。そのポートは共用ケイパビリ
ティのマッピング時に提供されるか、または被参照セッ
トアップ方法の場合には、受信領域をマッピングしたメ
ッセージをレシーバが受け取ったポートになる。図４１
は、共用メモリ領域メンバーシップ・リストを示す図で
ある。
【０３６４】ＲＰＣスタイルの転送または２当事者間の
一般的なトランザクションでは、宛先ポートが変換さ
れ、メンバーシップ・リスト内の項目のタスクＩＤフィ
ールドと照らし合わせて検査される。メンバーシップ・
リストは、被参照共用パラメータに関連するアドレス上
でハッシュ機能によって検出される。一致が見つからな
いと、メッセージはエラーとともに送信側に返される。
一致が見つかると、オフセットおよびサイズ変数が検査
され、メッセージに記載された領域が共用領域内に入る
場合、遠隔空間内の適切な領域を指すように被参照ポイ
ンタが調整され、転送が続行される。タスクＩＤがＮＯ
ＲＭＡ種の代理人ポートであると判明すると、特殊なＮ
ＯＲＭＡコードは、メッセージを作成し、遠隔当事者へ
の共用データを含むデータを送信する。
【０３６５】ＩＰＣデータ型用にサポートされる複数方
向としては、明示メッセージとメモリ更新専用の２つの
バージョンがある。どちらも、基本単方向非同期メッセ
ージ引渡しに限定される。どちらの形でも、呼出し側か
ら送られるメッセージは、直接データと、共用領域の一
部分と一致する単一被参照パラメータだけを含む可能性
がある。適切なメンバーシップ・リストを見つけるた
め、被参照パラメータによって指し示されるローカル・
アドレスが使用される。明示メッセージ・オプションで
は、リスト上で検出された各要素ごとにメッセージが作
成され、そのメンバーによってマッピングされたデータ
領域が完全オーバラップでなければ、切捨てが行われ
る。タスクＩＤが非ローカル（代理人）であると検出さ
れた場合、「共用」データを含むメッセージが作成さ
れ、代理人ポートに送られる。ＮＯＲＭＡコードは、キ
ックインして、このメッセージを遠隔当事者に送信す
る。メモリ更新専用オプションでは、メンバーシップ・
リストが走査され、ＮＯＲＭＡパイプのもう一方の端部
のメッセージ引渡しライブラリ２２０がメモリ更新メッ
セージとして認識する特殊メッセージが送信される。メ
モリ更新メッセージは、通常のメッセージ順序でポート
に送達される。しかし、メッセージ引渡しライブラリ２
２０は待ち行列化する前にそれを操作する。したがっ
て、メモリ更新メッセージは、同一ソースからの後続メ
ッセージより後に到着することができないが、そのソー
スからのメッセージが遠隔当事者によって読み取られる
前に到着する可能性がある。メモリ更新専用を使用する
には、データ・レベルの同期フラグとバッファ監視、ま
たはそれ以外の外部形式の同期が必要である。
【０３６６】共用複数方向がセットアップされ、その既
存メンバーの１つが共通メモリ資源を共用しない場合、
メンバーシップを拡張するにはメンバーシップ・リスト
の同期が必要になる。新しいメンバーを追加するとき
は、メッセージ引渡しライブラリ２２０がメンバーシッ
プ・リストを走査する。共通メモリを共用しないと判定
されたメンバーは、リストされたそのポート上で送られ
た特殊メッセージを持っている。そのメッセージは、Ｎ
ＯＲＭＡ代理人を介して送信することができ、遠隔端で
メッセージ引渡しライブラリ２２０によって代行受信さ
れる。共用メモリ更新メッセージとメンバーシップ更新
メッセージは、ターゲット・ポートの順序番号カウント
を増やさない。
【０３６７】4.2.5.4 メモリ領域ケイパビリティ ケイパビリティは、ポートとして実現され、他のポート
と同じ転送機構の対象となる。直接ポートの場合は、Ｒ
ＰＣとＩＰＣデータ型との扱いに違いはない。被参照バ
ージョンすなわちport_arraysの場合は、ポートのよう
なケイパビリティが被参照サブクラスの処理の対象とな
る。4.2.5.1項を参照されたい。ＩＰＣデータ型では、
受信側のケイパビリティに関するマッピング・オプショ
ンはＲＰＣで使用できるものと同じである。ＲＰＣサー
バ受信ケースおよびＩＰＣデータ型では、レシーバは、
上書きバッファを介して自分の希望を連絡する。クライ
アントは、メッセージ制御構造を介して自分の指示を知
らせる。合体メッセージ制御構造での応答側処理に関連
するオプションは、上書きバッファで使用できるものと
同じである。
【０３６８】4.2.6 優先順位ベースのメッセージ待ち
行列化 ポート上でメッセージを待ち行列化するための呼出し
は、ケイパビリティ・エンジンを通過しなければならな
い。ケイパビリティ・エンジンは、エクスポートされた
呼出しにより待ち行列化プロシージャをポートに関連付
ける。これにより、待ち行列化機構のカストマイズが可
能になる。ＩＰＣデータ型とＲＰＣのいずれでもプラグ
接続可能な待ち行列を使用する。しかし、ＩＰＣデータ
型の場合、通常、待ち行列機構の複雑さが増す。ＲＰＣ
とは異なり、ＩＰＣデータ型では、ブロックされた実行
スレッドとメッセージの両方を待ち行列化できなければ
ならない。この待ち行列はいつでもメッセージとブロッ
クされたスレッドの両方の例を含んでいる可能性があ
る。その条件は、同期および非同期のＩＰＣデータ型の
混合によって生成される。たとえば、あるセンダーが非
同期単方向メッセージを送信し、別の当事者が、レシー
バが待機していないポートに同期単方向メッセージを送
信した場合が挙げられる。
【０３６９】スケジューリングのサポートでは、プラグ
接続可能な待ち行列機構が重要になる。ＲＰＣの場合で
も、スケジューリング情報は、スケジューリング方針コ
ードを変換してそれと調和することができる待ち行列化
機構を提供するためにパーソナリティ・コードが必要に
なるほど十分非公式なものになる可能性がある。この方
針コードは実行スレッドに関連付けられる。ＩＰＣデー
タ型の場合は、実行方針によってメッセージにタグを付
ける方法を請け負わなければならない。エンドポイント
・ルーチンをこの活動からシールドするため、このよう
な情報をヘッダのトレーラ・フィールドに入れることを
推奨する。これは、ヘッダを充填するコードがスケジュ
ーリング・ルーチンと、ポートに関連するプラグ接続可
能な待ち行列化ルーチンとに調和しなければならないこ
とを意味する。待ち行列化ルーチンは、一方でメッセー
ジを待ち行列化して、供給されるスケジューリング情報
を基礎としてそれを配置し、もう一方でブロックされた
スレッドを待ち行列化して、別の場所からそれと互換性
のあるスケジューリング情報を引き出せるように準備が
できていなければならない。このルーチンは、そのスケ
ジューリング情報に基づいてそれらの優先順位を適切に
決定しなければならない。
【０３７０】遠隔スレッドのスケジューリング情報また
はそのメッセージまたはローカル・スレッドのスケジュ
ーリング優先順位を使用して遠隔プロセスを実行すると
いう選択は、プラグ接続可能な待ち行列の外部で行われ
る。待ち行列のジョブは単純なものとして保持され、カ
ストマイズ可能なスケジューリング方針によって決定さ
れた通り、最も優先順位が高い待機メッセージを最初に
送達する。しかし、良い方法がある。待ち行列コード自
体が、待ち行列化側の要求の優先順位で実行される。よ
り優先順位が高いタスクが送信のターゲット内または他
の場所で実行されている場合、待ち行列化行為が待機さ
せられる可能性がある。このため、高優先順位で実行さ
れる能動サーバは、優先順位が低いエンティティ用の要
求を処理するために中間優先順位のタスクをブロックす
ることができる。しかし、これはパーソナリティ・レベ
ルのシステム設計の問題なので、待ち行列プロシージャ
に直接影響するわけではない。残念ながら、受動サーバ
では、着信要求の優先順位の方がターゲットで現在実行
中のタスクより高い場合、優先順位の逆転を回避するた
めのアクションを講じるのは、プラグ接続可能な待ち行
列コードの責任である。このプラグ接続可能な待ち行列
コードは、ターゲットで進行中の操作の優先順位を上げ
る場合もあれば、ターゲット・サーバで関連の高優先順
位コール・バックを呼び出す場合もあり、ターゲット内
のサーバ・レベル・コードによる具体的な調整が可能に
なる。
【０３７１】ＩＰＣデータ型サーバは、性質上、能動で
ある（専用のスケジューリング方針によって動作する）
可能性が高いが、非同期メッセージを受け取る受動サー
バは不合理ではない。呼出し側アプリケーションにとっ
て、非移行性モデルのスケジューリング特性は、新しい
実行エンティティのフォークやthread_shuttleクローン
の場合のexecに類似しているはずである。または、移行
性thread_shuttle引渡しの場合のexecそのものになるは
ずである。
【０３７２】4.2.7 明示スレッド移行 ＲＰＣでは、スレッド移行の問題をアプリケーションに
とって十分透過なものにすることができる。スレッド移
行を公表する問題は、マイクロカーネルへのスレッド呼
出しによるのではなく、スレッド本体資源を直接操作す
る場合に考えられる価値に向けられた。この直接操作
は、ユーザ・レベルのスレッド化パッケージの場合には
非常に便利なものであることが分かるはずであるが、そ
れを使用せずにクライアントとサーバとの間でカーネル
・レベルのスレッド資源をシャトルのように引き渡すこ
とも可能である。
【０３７３】ＲＰＣではスレッド移行機構の大部分をア
プリケーション・レベルのインタフェースから隠蔽する
ことができる理由は、クライアントとサーバとの間にリ
ンクが確立している点と、送信／受信トランザクション
全体の期間中、それが存続するという事実である。打切
り（詳細については、4.1.9項を参照）の場合を除き、
サーバがその要求を操作している間、クライアントは中
断したままになる。これにより、目に見える人工物を使
わずにカーネル・レベルのスレッド資源をサーバに引き
渡すことが可能になる。サーバは要求を処理し、クライ
アントは応答メッセージが送られたときにそのシャトル
を戻す。要求処理の期間中、クライアントからサーバに
スケジューリング情報が転送される受動モデルは、その
データを処理しようと努力する間に空間から空間へ移動
する移動実行エンティティのモデルに従って、単純かつ
予測可能な挙動を示す。ＲＰＣとして動作する唯一のＩ
ＰＣデータ型転送スタイルは、双方向同期送信である。
他の形態はいずれも、選択されたモデルが明示スレッド
移行であるときに、人工物を表示する。また、他の形態
はいずれも、様々なレベルのアプリケーション・レベル
のスレッド本体サポートを必要とする。
【０３７４】4.2.7.1 送信／受信 すでに述べたように、スレッド移行や能動モデル対受動
モデルに関しては、同期双方向ＩＰＣデータ型はまった
くＲＰＣとして動作する。しかし、非同期双方向は異な
る挙動を示す。一例としては、遠隔当事者がポート上で
使用可能なメッセージを持っている場合、ローカル当事
者はその受信を実行するはずであり、遠隔当事者とロー
カル当事者の両方が同期動作するものと考えられる。こ
の例では、メッセージ引渡しシステムが遠隔当事者側で
受信を実行するためにシャトルのクローンを作成し、ロ
ーカル当事者がそのシャトルによってその受信ポートで
メッセージを拾い上げ、処理し続けていた。このモデル
では、２当事者内のメッセージ作成および処理を取り囲
む確率要素とそれらのスケジューリング優先順位に主に
基づいて新しいシャトルが現れ、送信が行われ、受信す
べきものがないときにそのシャトルが消失する。
【０３７５】資源に対するシステムの挙動は、全体的に
シャトルが不足している場合を除き、移行性ケースと非
移行性ケースとの間で大幅に異なる可能性はない。非移
行性資源インスタンスでは、シャトル資源はレシーバに
結合されたままになる。しかし、受動モデルの影響を受
けた場合、各種要素のスケジューリング挙動は大幅に異
なる可能性がある。
【０３７６】能動モデルでは、取り入れられたすべての
メッセージはレシーバのスケジューリング特性を帯びる
はずである。実際には、レシーバは、対応すべき複数の
スレッドを持つか、または対応すべきシャトルと対にす
べき一定数のスレッド本体を持つはずである。システム
は、同期実行するおそらくすべてのスレッドを持つよう
に設計されていると想定され、通常通り動作する。モデ
ルが受動モデルであって、スケジューリング情報がセン
ダーから転送される場合は、サーバのスレッドが高優先
順位のスケジューリング情報によって支配される可能性
がある。これと同時に元のセンダーのスレッドが同期動
作した結果、優先順位が低いタスクについて予期せぬ遅
延が発生する可能性がある。この点を考慮に入れるため
に、アプリケーションは、おそらくスレッド・フォーク
用にセットアップされた同一引用機構により監視され制
御されたメッセージを送信できる能力を持っていなけれ
ばならない。これは、アプリケーションの観点から見た
システムの認知挙動に深く影響することになる。
【０３７７】4.2.7.2 送信 移行の資源およびスケジューリングの問題に関しては、
単方向同期送信と単方向非同期送信は同じ挙動を示す。
単方向同期ＩＰＣデータ型のみで検出された遅延と同期
事象がメッセージ作成に影響する。依然として、メッセ
ージ処理とその後の呼出し側の処理を同期継続させるこ
とが、呼出しの目的である。
【０３７８】それでもなおスケジューリング情報がメッ
セージによって渡される非移行性モデルでは、単方向Ｉ
ＰＣデータ型がスレッド・フォークに非常によく似てい
るように見える。遠隔メッセージ処理の期間中、遠隔ス
レッドとローカルの呼出し側は呼出し側のスケジューリ
ング優先順位で動作することになる。リアルタイムに敏
感なシステムにおける上記の非同期双方向ＩＰＣデータ
型の場合のように、単方向ＩＰＣデータ型呼出しを監視
し、割振りを行う必要が生じる。
【０３７９】サポートされている場合、移行性モデルの
単方向ＩＰＣデータ型では明示スレッド本体の管理が必
要になる。送信行為はセンダーのシャトルを提供するた
めの規則によって行われるので、すべての双方向モデル
では移行行為を隠蔽することができる。受信行為はその
パトロンのシャトルを解放し、呼出し側はメッセージが
到着したときにセンダーのシャトルを受け取る。このた
め、対になった送受信を使用して、非明示スレッド本体
を追跡することができる。受信ポートではスレッド本体
だけがブロックされるが、これは呼出し側にとって透過
なものである。というのは、メッセージが到着するとセ
ンダーのシャトルを受け取り、呼出し側が受信を行った
ときにスレッド本体を持っていたからである。問題が発
生するのは、対になっていない送信のみである。メッセ
ージ引渡しライブラリ２２０がセンダーのスレッド本体
をレシーバに与えた後、メッセージ引渡しライブラリ２
２０は送信スレッド本体を乗せるべきポートを持たなく
なる。
【０３８０】スレッド本体を明示的に取り扱うことがで
きる方法がいくつかある。一例としては、本体構造に関
連する制御情報の一部分がメッセージ引渡しライブラリ
２２０からアクセス可能になるような方法をセットアッ
プすることが可能である。この場合、メッセージ引渡し
ライブラリ２２０は、この状態を変更することによりス
レッド本体構造のリリースを信号で知らせるはずであ
る。アプリケーションの都合のよいときに、リンクされ
たスレッド本体のリストを走査し、解放されたスレッド
本体を再生することができる。
【０３８１】明示スレッド本体管理がサポートされない
と判断された場合は、単独送信が非移行性として扱われ
る可能性があり、その結果、スレッド・シャトルのクロ
ーン化が行われ、単方向ＩＰＣデータ型用の送信から戻
る。
【０３８２】4.2.7.3 受信 移行性受信と非移行性受信は、アプリケーションにはほ
ぼ同じに見える可能性がある。非移行性の場合は、カー
ネルの観点からスレッド本体とシャトルが一緒に結合さ
れる。受信を行うスレッドは、そのままメッセージを待
つ。移行性の場合は、従来通りスレッドが受信を行う
が、カーネル・レベルのスレッド資源は解放される。メ
ッセージが現れると、送信に関連するカーネル・レベル
の資源または資源プールからの資源が受信スレッドに関
連付けられ、その資源がその受信から元に戻る。打切り
が発生した場合は、プールからの資源が供給される。Ｃ
ＭＵの古いスレッド引渡しコードは、センダーおよびレ
シーバ間で透過的に共用可能なカーネル・レベルの資源
の例として、カーネル・スタックを提示する。しかし、
その基礎となる要件として、資源は無名かつ交換可能な
ままでなければならない。
【０３８３】カーネル・レベルの資源に関連する属性に
係わる操作は、それらが移行性として扱われたときに人
工物を残す。スケジューリング属性がこの一例である。
受動モデルを選択した場合、スケジューリング情報はセ
ンダーからレシーバに渡される。このため、レシーバ
は、着信メッセージに関連するスケジューリング属性に
よってそのメッセージを処理することになる。これは、
メッセージについては十分機能するが、レシーバのスレ
ッドはそのスケジューリング・アイデンティティを失っ
てしまう。スレッドが、受け取って処理したばかりのメ
ッセージに関連しない機能の実行を希望する場合、メッ
セージ関連のスケジューリング特性を使用してこれを実
行するか、またはスケジューリング情報を明示的に変更
しなければならない。スケジューリング・テンプレート
を受信ポートに関連付けて、打ち切られた受信が所定の
スケジューリング優先順位で動作できるようにする場合
もあるが、これは、そのポートを受信に使用する可能性
のある複数のスレッドの様々なスケジューリング特性を
反映しなくなる。
【０３８４】4.2.8 明示メッセージ送出と資源の使用
法 4.2.1項および4.2.2項で述べたように、所与の形態のＩ
ＰＣデータ型では、非同期特性を満足し、今後発生する
センダーでの通知メッセージ・コードとレシーバでのメ
ッセージ処理コードの両方を同期処理する機会に対応す
るために、明示メッセージの作成が必要になる。このよ
うなメッセージの作成は、処理の点で高価であるだけで
なく、境界を示しにくいメモリおよびカーネル・アドレ
ス空間資源の使用に至る。
【０３８５】メッセージが作成されるときは、センダー
が処理の続行を希望しており、ポート権の移動および作
成と同時にデータの「スナップショット」を取る必要が
あると判断されている。エクステント・ポート権（ポー
ト名空間に関連しない権利）の問題はカーネル・レベル
の資源に影響せず、一般に、被参照領域に必要なメモリ
容量、ケイパビリティ、および明示メッセージ構造が影
響する。
【０３８６】メッセージ・ヘッダ、メッセージ制御構造
（登録を使用しない場合）、およびメッセージ・バッフ
ァ（直接メッセージ・データおよび被参照ポインタを含
む）用のメモリを獲得しなければならない。このメモリ
は、便宜およびパフォーマンスのために配線式である場
合が多い。メモリが配線式ではないシステムでも、適正
カーネルのアドレス空間からメモリが取られる。大量の
直接データを含む多数の待ち行列化されたメッセージに
より、カーネルが仮想アドレス空間を使い果たす可能性
がある。被参照領域はそれほど悪いものではないが、依
然としてカーネル・レベルの資源の枯渇を意味する。セ
ンダーのアドレス空間内の領域を被参照バッファとして
送信する場合、メッセージ引渡しライブラリ２２０は、
ケイパビリティ・エンジンを呼び出してケイパビリティ
を作成しなければならない。このケイパビリティ構造
と、シャドウ・オブジェクトのようなサポート構造は、
カーネル・アドレス空間に保管しなければならない。
【０３８７】その場合、ＩＰＣデータ型でのカーネル資
源の使用法を監視して制御するには、ある種の割振りモ
ニタが必要である。たとえば、待ち行列化されたメッセ
ージの数、直接データの量に関する明示スレッドの割振
り、被参照パラメータのサイズと数、ポートの数、なら
びにシステム内の活動ポートの総数の制御である。カー
ネル資源の不足や厳格な割振りのためにブロックされて
いることに気付いている非同期モデル内のエンティティ
の場合、デッドロックの回避または回復という巨大な作
業と比較してみるまでは、これは脅威的だと思われる。
【０３８８】カーネル資源の使用法に関しては、ＲＰＣ
はＩＰＣデータ型より圧倒的に有利である。明示メッセ
ージが作成されないので、メッセージ転送は、理論上、
一時的にも数バイトを上回るカーネル・メモリを消費す
る可能性がない。メッセージ、メッセージ制御構造、お
よびヘッダは、呼出し側の空間内に表示され、レシーバ
の空間内に構築される可能性がある。実際には、少なく
ともヘッダをカーネル空間にコピーした方が便利である
が、メッセージ全体、メッセージ制御構造であってもす
べてコピーインである。カーネル・レベル資源の使用法
は、システム内のスレッドの数に最大メッセージ制御構
造およびメッセージのサイズをかけたものを上回ること
はできない。データがページ可能になるように選択され
た場合、相当多数のスレッドにとって最悪のケースで
も、カーネル仮想記憶域の量は依然として管理可能な状
態に維持される。
【０３８９】4.2.8.1 送信／受信の並置と最適化 明示メッセージ作成の回避を可能にするのは、レシーバ
の待機が保証されていることである。これは、ＲＰＣの
場合と、同期形態のＩＰＣデータ型、すなわち、双方向
同期と単方向同期のＩＰＣデータ型の場合に行うことが
できる。その場合もセンダーがポートに到着してレシー
バが待機しているのを検出すると、非同期ＩＰＣデータ
型での明示メッセージ作成をスキップすることが可能で
ある。メッセージ作成ステップはスキップされ、メッセ
ージはセンダーからレシーバ空間に直接移される。明示
メッセージ作成を回避する機会は非同期ＩＰＣデータ型
の全体的なパフォーマンスを改善するが、サーバがほと
んどの時間休止している実行状態からサーバがメッセー
ジのバックログを操作している実行状態にシステムが移
行するときに、本来予想されるものより早くシステム・
パフォーマンスが劣化することに留意されたい。
【０３９０】4.2.9 メッセージＩＤでデマルチプレッ
クスされたレシーバ空間のサポートメッセージのデマル
チプレクシングはメッセージ引渡しライブラリ２２０上
のアプリケーション空間で行われるが、メッセージ引渡
しライブラリ２２０は、メッセージＩＤフィールドがヘ
ッダ内に供給される程度までデマルチプレクシング・サ
ーバを認識している。ＲＰＣの場合のように、ヘッダ内
のＩＤをサポートすることにより、列挙された１組のメ
ッセージ形式が予想される解釈レシーバの最適形態が可
能になる。メッセージＩＤの詳細については、4.1.7項
を参照されたい。
【０３９１】メッセージ制御構造の場合のように、ＩＰ
Ｃデータ型のメッセージＩＤは送信だけに頼っている。
これは、双方向ＩＰＣデータ型でのメッセージＩＤの送
達が対称的であり、それぞれの当事者がそれ専用の送信
転送を記述し、双方向メッセージの２回の送信が対称的
にリンクされないことを意味する。ＩＤの意味は、セン
ダーとレシーバとの事前合意によって決まる。
【０３９２】4.2.9.1 動的メッセージ・レシーバ空間
のサポート 列挙された複数のメッセージ形式で動作するサーバで
は、１つまたは複数の形式の処理をカストマイズする
か、新しい形式のサポートを追加すると、良好であるこ
とが多い。これを実行するための機構はメッセージ引渡
しライブラリ２２０上に存在するが、メッセージＩＤに
結合されているので、ここでは拡張機能として説明する
方が論理的である。メッセージ引渡しライブラリは、メ
ッセージＩＤのカストマイズとの競合を回避するように
設計されている。登録は、サーバまたはレシーバによっ
て行われ、登録ＩＤにより索引が付けられる。このた
め、ポートの存続期間中、登録情報が存在しても、レシ
ーバは特定のＩＤのメッセージ形式を置き換えることが
できるようになる。
【０３９３】
【０３９４】
【０３９５】
【０３９６】
【発明の効果】クライアントである送信側タスクは、無
名応答ポートをサーバである宛先タスクからの応答のた
めの指定ポートとして受け入れることを示す指示を、応
答ポート・フィールドに入れる。これにより、クライア
ントである送信側タスクは、双方向メッセージの送信に
対する応答としてサーバである宛先タスクからの応答を
待つ必要がなくなる。
【図面の簡単な説明】
【図１】マイクロカーネルおよびパーソナリティ・ニュ
ートラル・サービス１４０が様々なハードウェア・プラ
ットフォームで複数のオペレーティング・システム・パ
ーソナリティを実行する方法を示す図である。
【図２】スレッドに関連するクライアント可視構造を示
す図である。
【図３】クライアント可視タスク構造を示す図である。
【図４】典型的なポートを示す図であり、一連の送信権
と単一受信権を示す図である。
【図５】ポート名空間に収容されているか、またはメッ
セージに入れて伝送中の一連のポート権を示す図であ
る。
【図６】クライアント可視仮想メモリ構造を示す図であ
る。
【図７】サーバ・タスクがそのメッセージ制御構造の登
録を要求する第１のステージにおけるＩＰＣサブシステ
ム・無名応答ポート・制御登録モジュールとを含む、ホ
スト・マルチプロセッサ・システムの機能ブロック図で
ある。
【図８】クライアントがサーバにメッセージを送信でき
るようにするためにクライアント・タスクがサーバのメ
ッセージ制御構造登録ＩＤのコピーを要求する第２のス
テージにおけるＩＰＣサブシステムと無名応答ポートと
制御登録モジュールとを含む、ホスト・マルチプロセッ
サ・システムの機能ブロック図である。
【図９】クライアントがサーバにメッセージを送信でき
るようにするためにクライアント・タスクがサーバのメ
ッセージ制御構造登録ＩＤを使用する第３のステージに
おけるＩＰＣサブシステムと無名応答ポートと制御登録
モジュールとを含む、ホスト・マルチプロセッサ・シス
テムの機能ブロック図である。
【図１０】無名応答ポートを使用する双方向メッセージ
転送時の、ＩＰＣサブシステムと無名応答ポートを備え
たホスト・マルチプロセッサ・システムの機能ブロック
図である。
【図１１】元のクライアント・メッセージと無名応答ポ
ートによって公式化された代用メッセージ、ならびに応
答メッセージと無名応答ポートによって公式化された代
用応答メッセージの内容の例を示す図である。
【図１２】分散処理配置で動作する２つのホスト・マル
チプロセッサ・システムの機能ブロック図であり、通信
リンクを介して２つのホスト間でメッセージを交換し、
各ホスト・プロセッサ上のＩＰＣサブシステムと制御登
録モジュールがタスク間のプロセス間通信を管理する場
合を示す図である。
【図１３】ＩＰＣによる単純なメッセージ転送を示す図
である。
【図１４】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１５】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１６】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１７】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１８】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１９】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図２０】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図２１】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図２２】メッセージ・レイアウトの概要を示す図であ
る。
【図２３】代理人ユーザ・レベル・ライブラリの典型的
な呼出しを示す図である。
【図２４】メッセージ制御構造を示す図である。
【図２５】メッセージ・ヘッダ構造を示す図である。
【図２６】トラステッド・クライアント／既知メッセー
ジＩＤの例を示す図である。
【図２７】非トラステッド・クライアント／既知メッセ
ージＩＤの例を示す図である。
【図２８】メッセージ形式登録を示す図である。
【図２９】上書きバッファ動作を示す図である。
【図３０】ＲＰＣ転送を示す図である。
【図３１】ケイパビリティ・エンジンによる待ち行列サ
ポートを示す図である。
【図３２】多重化サーバの基本実行ループを示す図であ
る。
【図３３】メッセージ引渡しライブラリの無名応答アル
ゴリズムを示す図である。
【図３４】共用領域の初期設定を示す図である。
【図３５】ＲＰＣ共通ケースでの共用領域の使用法を示
す図である。
【図３６】基本ＩＰＣメッセージ引渡しの概要を示す図
である。
【図３７】基本ＩＰＣメッセージ受信試行のメッセージ
待機を示す図である。
【図３８】基本ＩＰＣメッセージ送信のレシーバ待機と
同期送信を示す図である。
【図３９】最適双方向送信を示す図である。
【図４０】異なるタスク空間で実行される２つのスレッ
ドで構成された双方向トランシーバを示す図である。
【図４１】共用メモリ領域メンバーシップ・リストを示
す図である。
【符号の説明】
１００ ホスト・マルチプロセッサ １０２ メモリ １０４ バス １０６ 補助記憶装置 １０８ 入出力アダプタ １１０ プロセッサＡ １１２ プロセッサＢ １２０ マイクロカーネル １２２ ＩＰＣサブシステム ２１０ タスクＴ（Ａ） ２１０' タスクＴ（Ｂ） ２２０ メッセージ引渡しライブラリ ２４８ スレッド ２４８' スレッド ５０５ タスク・ポート ５０６ タスク・ポート ５２２ スレッド ６００ 無名応答ポート ６０２ 項目 ６１０ クライアント・メッセージ ６１２ 転送されたクライアント・メッセージ ６１４ サーバ応答メッセージ ６１６ 転送されたサーバ応答
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジョーゼフ・ウィリアム・グリーン アメリカ合衆国33431−6588 フロリダ 州ボカ・ラトン ノアウッド・テラス 301 ナンバー・エヌ129 (72)発明者 ジェームズ・マイケル・マジー アメリカ合衆国33463 フロリダ州レイ ク・ワース キャナル・ドライブ 5310 (72)発明者 クリストファー・ディーン・ヤングワー ス アメリカ合衆国61874 イリノイ州サヴ ォイ ガルフビュー・コート ナンバー ３ (56)参考文献 特開 平５−81210（ＪＰ，Ａ) 特開 平２−98745（ＪＰ，Ａ) 特開 平４−14162（ＪＰ，Ａ) 特開 平６−224938（ＪＰ，Ａ) 特開 平７−200448（ＪＰ，Ａ) 乾、菅原・共著、「分散ＯＳ Ｍａｃ ｈがわかる本」、日刊工業新聞社・発行 （1992年初版）、Ｐ．14〜17及びＰ．48 〜55 (58)調査した分野(Int.Cl.6，ＤＢ名) G06F 9/46 G06F 13/00 G06F 15/00 G06F 15/16 H04L 11/20 ＣＳＤＢ（日本国特許庁)

Claims (2)

    (57)【特許請求の範囲】
  1. 【請求項１】マルチタスク・アーキテクチャにおけるプ
    ロセス間通信方法であって、 データ処理システムのメモリ手段内にデータおよびプロ
    グラム式命令を格納するステップと、 前記メモリ手段に結合されたプロセッサ手段内で前記プ
    ログラム式命令を実行するステップと、 前記メモリ手段内のプロセス間通信手段により、前記メ
    モリ手段内の複数のタスク間のメッセージ引渡しを調整
    するステップと、前記メモリ手段内の第１のタスクにより、前記第１のタ
    スクの応答ポートを指定し且つ前記プロセス間通信手段
    内にある無名応答ポートを前記メモリ手段内にある第２
    のタスクからの応答のための指定ポートとして受け入れ
    ることを示す無名応答ポート・オプションを指定するオ
    リジナルの双方向性送信／受信メッセージを形成 するス
    テップと、前記オリジナルの双方向性送信／受信メッセージを前記
    プロセス間通信手段に送信するステップと、 前記オリジナルの双方向性送信／受信メッセージを受信
    した前記プロセス間通信手段により、前記第１のタスク
    の前記応答ポートの代わりに前記無名応答ポートを指定
    する代用の双方向性送信／受信メッセージを形成するス
    テップと、 前記代用の双方向性送信／受信メッセージを前記第２の
    タスクの宛先ポートに送信するステップと、 前記代用の双方向性送信／受信メッセージを受信した前
    記第２のタスクにより 、前記無名応答ポートを宛先とし
    て指定するオリジナルの単方向性応答メッセージを形成
    するステップと、 前記オリジナルの単方向性応答メッセージを前記プロセ
    ス間通信手段に送信するステップと、 前記オリジナルの単方向性応答メッセージを受信した前
    記プロセス間通信手段により、前記無名応答ポートの代
    わりに前記第１のタスクの前記応答ポートを指定する代
    用の単方向性応答メッセージを形成するステップと、 前記代用の単方向性応答メッセージを前記第１のタスク
    の前記応答ポートに送信 するステップとを含む、前記プ
    ロセス間通信方法。
  2. 【請求項２】前記第２のタスクがアプリケーション・プ
    ログラムを表すことを特徴とする、請求項１記載のプロ
    セス間通信方法。
JP7154172A 1994-06-22 1995-06-21 マルチタスク・アーキテクチャにおけるプロセス間通信方法 Expired - Lifetime JP2888420B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US26370994A 1994-06-22 1994-06-22
US263709 1994-06-22

Publications (2)

Publication Number Publication Date
JPH0816411A JPH0816411A (ja) 1996-01-19
JP2888420B2 true JP2888420B2 (ja) 1999-05-10

Family

ID=23002933

Family Applications (1)

Application Number Title Priority Date Filing Date
JP7154172A Expired - Lifetime JP2888420B2 (ja) 1994-06-22 1995-06-21 マルチタスク・アーキテクチャにおけるプロセス間通信方法

Country Status (2)

Country Link
EP (1) EP0689139A3 (ja)
JP (1) JP2888420B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3573386B2 (ja) * 1996-04-02 2004-10-06 株式会社野村総合研究所 負荷制御を行う大規模クライアントサーバーシステム
JP2001202013A (ja) * 2000-01-21 2001-07-27 Nec Corp 匿名参加権限管理システム
US8019901B2 (en) * 2000-09-29 2011-09-13 Alacritech, Inc. Intelligent network storage interface system
US8032900B2 (en) 2006-08-02 2011-10-04 Microsoft Corporation Conducting client-server inter-process communication
FR2940695B1 (fr) * 2008-12-30 2012-04-20 Eads Secure Networks Serveur passerelle a micronoyau
CN107783845B (zh) * 2016-08-25 2021-04-13 阿里巴巴集团控股有限公司 消息传输***、方法和装置
JP6876235B2 (ja) 2016-09-27 2021-05-26 富士フイルムビジネスイノベーション株式会社 電子装置及び画像処理装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0366583B1 (en) * 1988-10-24 1995-08-30 International Business Machines Corporation Method of exchanging data between programs in a data processing system
US5230051A (en) * 1990-09-04 1993-07-20 Hewlett-Packard Company Distributed messaging system and method
DE69130154T2 (de) * 1990-12-14 1999-05-20 Sun Microsystems Inc Verfahren und Gerät zur Nachrichtenvermittlung zwischen Prozessen

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
乾、菅原・共著、「分散ＯＳ Ｍａｃｈがわかる本」、日刊工業新聞社・発行（１９９２年初版）、Ｐ．１４〜１７及びＰ．４８〜５５

Also Published As

Publication number Publication date
EP0689139A2 (en) 1995-12-27
JPH0816411A (ja) 1996-01-19
EP0689139A3 (en) 1997-09-10

Similar Documents

Publication Publication Date Title
JP3095777B2 (ja) オブジェクト指向オペレーティング・システム
JP3095776B2 (ja) オブジェクト指向ホスト・システム
US5771383A (en) Shared memory support method and apparatus for a microkernel data processing system
JP3570525B2 (ja) マイクロカーネル・アーキテクチャ・データ処理システム及びそのメモリ管理方法、オペレーティング・システム・パーソナリティ・プログラムを走行させる方法、アプリケーション・プログラムを走行させる方法
JP4791461B2 (ja) ランタイムシステムにおけるオブジェクトを共有するためのプログラム、方法、装置
JP4837660B2 (ja) ランタイムシステムにおけるオブジェクトを共有するためのプログラム、方法、装置
US5473777A (en) Wrapper for enabling an object otented application to maintain virtual memory using procedural function calls
US5404529A (en) Object-oriented interprocess communication system interface for a procedural operating system
JP4690437B2 (ja) ネットワークアプリケーションにおける通信方法、通信装置及びそのためのプログラム
JPH05216692A (ja) プログラム実行を管理する方法およびシステム
JP2986073B2 (ja) プロセス間通信方法並びにプロセス間通信用のサブシステムおよびシステム
JPH0855035A (ja) マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置
JP2888420B2 (ja) マルチタスク・アーキテクチャにおけるプロセス間通信方法
JPH0855037A (ja) プロセス間通信方法およびプロセス間通信用のシステム
JPH0822395A (ja) マイクロカーネル・アーキテクチャ・データ処理システムにおけるプロセス間通信方法およびシステム
Condict et al. Optimizing performance of Mach-based systems by server co-location: A detailed design
Appavoo et al. Utilizing Linux kernel components in K42
Wang Rhodes: A Next-Generation OS based on Resource Governance Model
Schatzberg Customization and reuse in datacenter operating systems
Qin A Study of Location-Transparent Load Sharing in Distributed Systems
Abrossimov et al. CHORUS, a New Technology for Building UNIX Systems
Rotta et al. Global Architecture of MyThOS
Naseer A process migration subsystem for distributed applications: Design and implementation