JPH0855035A - マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置 - Google Patents

マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置

Info

Publication number
JPH0855035A
JPH0855035A JP18180795A JP18180795A JPH0855035A JP H0855035 A JPH0855035 A JP H0855035A JP 18180795 A JP18180795 A JP 18180795A JP 18180795 A JP18180795 A JP 18180795A JP H0855035 A JPH0855035 A JP H0855035A
Authority
JP
Japan
Prior art keywords
message
task
data
memory
processor
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.)
Pending
Application number
JP18180795A
Other languages
English (en)
Inventor
Aziza Bushra Faruqi
アズィーザ・ブシュラ・ファルーキー
Joseph William Green
ジョーゼフ・ウィリアム・グリーン
Christopher Dean Youngworth
クリストファー・ディーン・ヤングワース
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 JPH0855035A publication Critical patent/JPH0855035A/ja
Pending 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
    • 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/547—Remote procedure calls [RPC]; Web services

Landscapes

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

Abstract

(57)【要約】 【目的】 タスク間における制御情報およびデータのや
りとりに関するメッセージ引渡し操作を管理する、マイ
クロカーネルのプロセス間通信サブシステム（ＩＰＣ）
を提供する。 【構成】 メッセージの伝送制御情報は、１回だけ解析
され、送信側タスクからＩＰＣサブシステムへ、次にＩ
ＰＣサブシステムから宛先タスクへと、その順次パス内
で多くても１回だけコピーされる。たとえば、プロセッ
サ資源の枯渇、タイムアウトの期限切れ、またはポート
権の不足のためにメッセージを伝送できない場合、メッ
セージのデータ部分の打切り転送の際にプロセッサ時間
が浪費されない。このようにして、使用中のマルチタス
ク・システム内のプロセス間通信に順序と予測可能性を
もたらすためにすべてのメッセージがＩＰＣサブシステ
ムと対話する必要があり、システムのパフォーマンスが
最大化される。

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本明細書に開示する本発明は、一
般にデータ処理システムに関し、より具体的にはデータ
処理システム用のオペレーティング・システムの改良に
関する。
【０００２】ここに開示する本発明は、１９９４年６月
２２日に出願され、本出願人に譲渡され、参照により本
発明の一部となる、ガイ・ジー・ソトマイヤー（Guy G.
Sotomayor）Jr.、ジェームス・エム・マジー（James
M. Magee）、およびフリーマン・エル・ローソン（Free
man L. Rawson）IIIによる"METHOD AND APPARATUS FOR
MANAGEMENT OF MAPPED AND UNMAPPED REGIONS OF MEMOR
Y IN A MICROKERNEL DATA PROCESSING SYSTEM"という名
称の関連米国特許出願第２６３７１０号（ＩＢＭ整理番
号BC9-94-053）に関連するものである。
【０００３】ここに開示する本発明は、１９９４年９月
２８日に出願され、本出願人に譲渡され、参照により本
発明の一部となるジェームズ・エム・マジー（James M.
Magee）他による"CAPABILITY ENGINE METHOD AND APPA
RATUS FOR A MICROKERNEL DATA PROCESSING SYSTEM"と
いう名称の関連米国特許出願第２６３３１３号（ＩＢＭ
整理番号BC9-94-071）にも関連するものである。
【０００４】ここに開示する本発明は、１９９４年６月
２２日に出願され、本出願人に譲渡され、参照により本
発明の一部となる、ジェームズ・エム・マジー他の"TEM
PORARY DATA METHOD AND APPARATUS FOR A MICROKERNEL
DATA PROCESSING SYSTEM"という名称の関連米国特許出
願第２６３３１３号（ＩＢＭ整理番号BC9-94-076）にも
関連するものである。
【０００５】ここに開示する本発明は、１９９４年６月
２２日に出願され、本出願人に譲渡され、参照により本
発明の一部となるジェームズ・エム・マジー（James M.
Magee）他の"MESSAGE CONTROL STRUCTURE REGISTRATIO
N METHOD AND APPARATUS FORA MICROKERNEL DATA PROCE
SSING SYSTEM"という名称の関連米国特許出願第２６３
７０３号（ＩＢＭ整理番号BC9-94-077）にも関連するも
のである。
【０００６】ここに開示する本発明は、１９９４年６月
２２日に出願され、本出願人に譲渡され、参照により本
発明の一部となる、ジェームズ・エム・マジー他の"ANO
NYMOUS REPLY PORT METHOD AND APPARATUS FOR A MICRO
KERNEL DATA PROCESSING SYSTEM"という名称の関連米国
特許出願第２６３７０９号（ＩＢＭ整理番号BC9-94-08
0）にも関連するものである。
【０００７】ここに開示する本発明は、１９９４年９月
９日に出願され、本出願人に譲渡され、参照により本発
明の一部となる、ラーム・ケー・グプタ（Ram K. Gupt
a）、ラヴィ・シュリニヴァサン（Ravi Srinivasan）、
デニス・アッカーマン（Dennis Ackerman）、およびヒ
マンシュ・デサイ（Himanshu Desai）による"PAGE TABL
E ENTRY MANAGEMENT METHOD AND APPARATUS FOR A MICR
OKERNEL DATA PROCESSING SYSTEM"という名称の関連米
国特許出願第３０３８０５号（ＩＢＭ整理番号BC9-94-0
73）にも関連するものである。
【０００８】ここに開示する本発明は、１９９４年９月
９日に出願され、本出願人に譲渡され、参照により本発
明の一部となる、ラーム・ケー・グプタ他の"EXCEPTION
HANDLING METHOD AND APPARATUS FOR A MICROKERNEL D
ATA PROCESSING SYSTEM"という名称の関連米国特許出願
第３０３７９６号（ＩＢＭ整理番号BC9-94-072）にも関
連するものである。
【０００９】ここに開示する本発明は、１９９４年９月
９日に出願され、本出願人に譲渡され、参照により本発
明の一部となる、ハルデープ・シン（Hardeep Sing
h）、ガイ・ソトマイヤー（Guy Sotomayor）、ギャリー
・バートン（Gary Barton）、フリーマン・ローソン（F
reeman Rawson）、チン＝ユン・チャオ（Ching-Yun Cha
o）およびチャールズ・ユン（Charles Jung）の"BACKIN
G STORE MANAGEMENT METHOD AND APPARATUS FOR A MICR
OKERNEL DATA PROCESSING SYSTEM"という名称の関連米
国特許出願第３０３８５１号（ＩＢＭ整理番号BC9-94-0
87）にも関連するものである。
【００１０】ここに開示する本発明は、１９９４年９月
１９日に出願され、本出願人に譲渡され、参照により本
発明の一部となる、チン＝ユン・チャオ他の"MASTER SE
RVERPROGRAM LOADING METHOD AND APPARATUS FOR A MIC
ROKERNEL DATA PROCESSINGSYSTEM"という名称の関連米
国特許出願第３０８１８９号（ＩＢＭ整理番号BC9-94-0
74）にも関連するものである。
【００１１】
【従来の技術】オペレーティング・システムは、コンピ
ュータ上で実行される最も重要なソフトウェアである。
すべての汎用コンピュータは、他のプログラムを実行す
るためのオペレーティング・システムを備えていなけれ
ばならない。通常、オペレーティング・システムは、キ
ーボードからの入力の認識、表示画面への出力の送出、
ディスク上のファイルおよびディレクトリの追跡、ディ
スク・ドライブおよびプリンタなどの周辺装置の制御の
ような基本的なタスクを実行する。より複雑なシステム
では、オペレーティング・システムの責任と能力がかな
り大きくなる。それにより、同時に動作する様々なプロ
グラムやユーザが互いに干渉しないことが重要になる。
また、一般にオペレーティング・システムは、セキュリ
ティも担当し、無許可ユーザがシステムにアクセスでき
ないようにする。
【００１２】オペレーティング・システムは、マルチユ
ーザ・オペレーティング・システム、マルチプロセッサ
・オペレーティング・システム、マルチタスク・オペレ
ーティング・システム、およびリアルタイム・オペレー
ティング・システムに分類することができる。マルチユ
ーザ・オペレーティング・システムとは、２人またはそ
れ以上のユーザが同時にプログラムを実行できるように
するものである。オペレーティング・システムによって
は、数百人または数千人のユーザによる同時実行が可能
なものもある。マルチプロセッシング・プログラムと
は、単一ユーザが２つまたはそれ以上のプログラムを同
時に実行できるようにするものである。この場合、実行
される各プログラムはプロセスと呼ばれる。ほとんどの
マルチプロセッシング・システムは複数のユーザをサポ
ートしている。マルチタスク・システムとは、単一プロ
セスが複数のタスクを実行できるようにするものであ
る。マルチタスクとマルチプロセッシングという用語は
意味がいくらか異なるが、一般的な用法では交換可能な
ものとして使用される場合が多い。マルチタスクとは、
複数のタスクを同時に実行できる能力であり、タスクと
はプログラムである。マルチタスクでは、１つの中央演
算処理装置（ＣＰＵ）だけが関与するが、プログラム間
の切替えを非常に迅速に行うため、すべてのプログラム
を同時に実行しているように見えるのである。マルチタ
スクには、プリエンプティブと協調方式の２通りの基本
タイプがある。プリエンプティブ・マルチタスクでは、
オペレーティング・システムが各プログラムにＣＰＵの
タイム・スライスを分配する。協調マルチタスクでは、
各プログラムは、ＣＰＵを必要とする間、ＣＰＵを制御
することができる。ただし、プログラムがＣＰＵを使用
していない場合、別のプログラムが一時的にＣＰＵを使
用できるようにすることも可能である。たとえば、ＯＳ
／２（登録商標）およびＵＮＩＸ（登録商標）はプリエ
ンプティブ・マルチタスク・オペレーティング・システ
ムであるが、マッキントッシュ（登録商標）のコンピュ
ータ用の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）がある。
【００２５】ガイ・ジー・ソトマイヤー他による前述の
関連特許出願には、図１に示すマイクロカーネル・シス
テム１１５が記載されているが、これはオペレーティン
グ・システムの新しい基礎である。マイクロカーネル・
システム１１５は、純粋カーネルとして実施されたカー
ネル・サービスの簡略セットと、１組のユーザレベル・
サーバとして実施されたオペレーティング・システム・
パーソナリティを構築するためのサービスの拡張セット
とを提供する。マイクロカーネル・システム１１５は、
様々な従来のオペレーティング・システム機能を提供
し、オペレーティング・システム・パーソナリティとし
て明示された、多くのサーバ構成要素で構成されてい
る。マイクロカーネル・システム１１５では、タスク
（クライアント）が通信チャネルを介して送られるメッ
セージによって他のタスク（サーバ）の要求を行うこと
によりサービスにアクセスする、クライアント／サーバ
・システム構造を使用する。マイクロカーネル１２０が
提供するそれ専用のサービスは非常に少ない（たとえ
ば、ファイル・サービスは一切提供しない）ので、マイ
クロカーネル１２０のタスクは、必要なサービスを提供
する他の多くのタスクと通信しなければならない。この
ため、システム内の多くのクライアントとサーバとの間
で行わなければならないプロセス間通信をいかに高速か
つ効率よく管理するかについて問題が発生する。
【００２６】
【発明が解決しようとする課題】したがって、本発明の
一目的は、データ処理システム用の改良されたマイクロ
カーネル・アーキテクチャを提供することにある。
【００２７】本発明の他の目的は、先行技術で可能だっ
たものに比べ、そのプロセス間通信操作がさらに簡略化
された、データ処理システム用の改良されたマイクロカ
ーネル・アーキテクチャを提供することにある。
【００２８】本発明の他の目的は、より高速でより効率
の良いプロセス間通信機能を有する、データ処理システ
ム用の改良されたマイクロカーネル・アーキテクチャを
提供することにある。
【００２９】本発明の他の目的は、共用メモリ環境内の
タスク間および共通メモリを共用しない分散データ・プ
ロセッサ間でのメッセージの交換においてより高度のフ
レキシビリティを有する、データ処理システム用の改良
されたマイクロカーネル・アーキテクチャを提供するこ
とにある。
【００３０】
【課題を解決するための手段】上記およびその他の目
的、特徴、および利点は、本明細書に開示されたマイク
ロカーネル・データ処理システム用の伝送制御の分離の
方法および装置によって達成される。
【００３１】適度に複雑なマルチタスク・アプリケーシ
ョンでも、ユーザの目的を達成するために多くのタスク
とスレッドが互いに対話している。あるタスクから別の
タスクへメッセージの形で情報をやりとりするため、ユ
ーザは、マイクロカーネル向けの送信側タスクのプログ
ラム・コードにおいてプロシージャ呼出し命令を提供す
る。このプロシージャ呼出しは、宛先タスクのポートの
名前、メッセージの名前、メッセージのタイプ（双方向
同期ＲＰＣ：Remote Procedure Call、単方向非同期Ｉ
ＰＣ：Interprocessor Communication、非同期送信／受
信など）、およびその他の情報を伴っている。また、こ
の呼出しは宛先ポートを伴う場合もあれば、そのポート
がオプションとして任意選択のヘッダ・フィールドによ
って提供される場合もある。このため、システムは、最
も単純なローカル・プロシージャ呼出しならびにオブジ
ェクトのサブクラス化に基づく呼出しをサポートするこ
とができる。プロシージャ呼出しは、伝送方法を選択す
る許可をマイクロカーネルに与え、あるいはデータの物
理コピーを宛先タスクに提供することを要求するなど、
メッセージに関するオプションを指定するためにユーザ
が提供したパラメータ値を含んでいる。実行時にプロシ
ージャ呼出しが実行されると、送信側タスクのためにメ
ッセージが形成され、宛先タスクに伝送されて、所望の
情報を伝送することになる。
【００３２】マイクロカーネルのプロセス間通信サブシ
ステム（ＩＰＣ）は、タスク間における制御情報および
データのやりとりに関するメッセージ引渡し操作を管理
する。送信側タスクから宛先である受信側タスクに送ら
れるあらゆるメッセージは、その伝送を管理するために
ＩＰＣサブシステムを使用しなければならない。すべて
のメッセージがＩＰＣサブシステムと対話しなければな
らないという要件により、使用中のマルチタスク・シス
テムにおけるプロセス間通信に順序と予測可能性がもた
らされる。しかし、この要件は、システムのパフォーマ
ンスに悪影響を及ぼす可能性もある。
【００３３】本発明に従ってメッセージのデータ部分か
ら伝送制御情報を分離すると、メッセージ引渡しプロセ
スのパフォーマンスを２つのタスク間で伝送されるメッ
セージの相対的な複雑さに連係することができる。伝送
制御情報には、宛先タスクのポート名、メッセージの名
前、およびメッセージのタイプなど、全体的なメッセー
ジ・ヘッダ情報が含まれる。また、伝送制御情報には、
セキュリティ・トークンの指定またはトレーラ・セグメ
ントの要件など、伝送操作自体の任意選択機能を指定す
る伝送制御構造（ＴＣＳ：Transmission Control Struc
ture）も含まれる。本発明によれば、任意選択の伝送制
御フィールドを含めることを必要としないメッセージ
は、これらを負担しなくなる。センダーとプロセス間通
信サブシステムとの間のメッセージ・パスでのみ任意選
択の伝送制御情報を必要とするメッセージは、プロセス
間通信サブシステムからレシーバへのメッセージ・パス
で余分なフィールドを伝達する必要がなくなる。
【００３４】伝送制御情報には、直接データ値の数と長
さおよびデータ・オブジェクトを指すアドレス・ポイン
タの存在など、データ形式の特徴を指定するメッセージ
制御構造（ＭＣＳ：Message Central Structure）も含
まれる。また、伝送制御情報には、プロシージャ呼出し
内のパラメータも含まれる。
【００３５】さらに、本発明によれば、メッセージの伝
送制御情報は、１回だけ解析され、送信側タスクからＩ
ＰＣサブシステムへ、次にＩＰＣサブシステムから宛先
タスクへと、その順次経路中で多くても１回だけコピー
される。
【００３６】さらに、本発明によれば、送信側タスクか
ら宛先タスクへのメッセージのデータ部分の伝送は、Ｉ
ＰＣサブシステムが伝送制御情報全体を解析し、送信側
タスクがこのメッセージを宛先タスクに送信する権利を
有するように設定し、伝送制御情報に対して必要な修正
または追加を行い、宛先タスクの受信ポートにメッセー
ジを待ち行列化する間、遅延される。たとえば、プロセ
ッサ資源の枯渇、タイムアウトの期限切れ、またはポー
ト権の不足のためにメッセージを伝送できない場合、メ
ッセージのデータ部分の打切り転送の際にプロセッサ時
間が浪費されない。非同期メッセージまたはホストの外
部で伝送されるメッセージを除き、伝送制御情報の個別
の連続コピーを作成する必要はない。ＩＰＣサブシステ
ムによるこのメッセージ・セットアップの間隔中、メッ
セージのデータ部分は送信側タスクの送信データ・バッ
ファに常駐する。このデータ部分は、直接データである
場合もあれば、宛先タスクが使用可能なデータを含むメ
モリ・オブジェクトを指すアドレス・ポインタである場
合もある。
【００３７】さらに、本発明によれば、ＩＰＣサブシス
テムは、メッセージ伝送の近道を提供することができ
る。伝送制御情報または送信側タスクがポインタによっ
て参照するオブジェクト内に格納されているデータある
いはその両方を、受信側バッファまたは宛先タスクに属
す他のメモリ・オブジェクトにコピーする必要はない。
むしろ、ＩＰＣサブシステムは、伝送する必要がある情
報を指すポインタをコピーできるだけである。ＩＰＣサ
ブシステムは、システム内のタスク、スレッド、および
オブジェクト用のアドレス空間を記録するメッセージ引
渡しライブラリを管理する。ＩＰＣサブシステムは、受
信側タスク用のポインタを、伝送制御情報およびメッセ
ージにおいて送信側タスクが参照するオブジェクト内に
格納されているデータに自動的に変換する。
【００３８】送信側タスク用のプログラム命令の残りと
ともにプロシージャ呼出し命令がコンパイルされると、
コンパイラは、プロシージャ呼出しがタスクのスレッド
によって実行されるたびに呼び出される、そのタスク用
のヘッダ・テンプレートを形成する。ヘッダ・テンプレ
ートは、送信側タスクに関連するタスク・ライブラリに
格納することができる。送信側タスクは、プロシージャ
呼出しの実行準備の際にユーザのプログラムによって公
式化されたときに伝送制御情報の作業コピーを格納する
ために送信側タスクとそのスレッドが使用する伝送制御
バッファを有する。全体として１つのメッセージを生成
し、それぞれの構成要素が、たとえば、ヘッダ、ＴＣ
Ｓ、ＭＣＳ、またはプロシージャ呼出しパラメータの作
業コピーをそれぞれ格納する、複数の非連続構成要素バ
ッファが存在する可能性がある。送信側タスクの伝送制
御バッファには、たとえば、宛先タスクのポート名、メ
ッセージの名前、およびメッセージのタイプなどの値
が、タスクおよびそのスレッドの実行プログラムによっ
て生成されたときに格納される。ヘッダ・テンプレート
には、送信側タスクの伝送制御バッファを指すアドレス
・ポインタが含まれる。タスクとそのスレッドがプロシ
ージャ呼出し命令を実行すると、ヘッダ・テンプレート
がＩＰＣサブシステムに提供される。ＩＰＣサブシステ
ムは、ヘッダ・テンプレート内のポインタを使用して、
伝送制御バッファの内容の読取りを開始する。ヘッダ・
テンプレートは、送信側タスク、宛先ポートの名前、お
よび送信する必要があるメッセージのタイプを識別す
る。ＩＰＣサブシステムは、ヘッダ・テンプレートおよ
び送信側タスクの伝送制御バッファ内のポインタに従っ
て、呼出しを確立するための十分な伝送制御情報を蓄積
する。これは伝送制御情報の解析が必要な唯一の時期で
あり、ＩＰＣサブシステムがメッセージ伝送の確立を完
了できるようにするために伝送制御情報を再コピーする
必要は一切ない。
【００３９】このようにして、本発明は、使用中のマル
チタスク・システム内のプロセス間通信に順序と予測可
能性をもたらすためにすべてのメッセージがＩＰＣサブ
システムと対話できるようにするものであり、さらにシ
ステムのパフォーマンスを最大限にするものである。
【００４０】クライアント・タスクまたはサーバ・タス
クあるいはその両方は、アプリケーション・プログラ
ム、オペレーティング・システム・パーソナリティ・プ
ログラム、パーソナリティ・ニュートラル・サービス・
プログラム、またはマイクロカーネル自体の一部にする
ことができる。上記の各タイプのプログラムには、その
プログラムの目的を実行するためのタスクとそのスレッ
ドを作成しなければならない。このようなタスクは、マ
イクロカーネル・システムで並行実行される他のタスク
と通信しなければならない。このようなタスクは、ホス
ト・マルチプロセッサ内の他のアプリケーション・プロ
グラムで並行実行される他のタスクと通信しなければな
らない。さらに、このようなタスクは、分散処理ネット
ワーク内の各種ホスト・マルチプロセッサ・システム上
で並行実行される他のタスクとも通信しなければならな
い。このようなタスクの１つから別のタスクへの各通信
は、本発明による制御登録によって提供される効率を利
用することができる。
【００４１】このようにして、本発明は、マイクロカー
ネル・システム内の多くのクライアントとサーバとの間
で行わなければならないプロセス間通信を高速かつ効率
よく管理する。本発明は、ユニプロセッサ、共用メモリ
・マルチプロセッサ、および分散プロセッサ・システム
内の複数のコンピュータに適用される。
【００４２】上記およびその他の目的および利点は、添
付図面を参照すればさらに十分理解されるはずである。
【００４３】
【実施例】
第Ａ部 マイクロカーネル・システム 第１節 マイクロカーネルの原理 図１は、マイクロカーネル・システム１１５の機能ブロ
ック図であり、マイクロカーネル１２０およびパーソナ
リティ・ニュートラル・サービス１４０が様々なハード
ウェア・プラットフォームで複数のオペレーティング・
システム・パーソナリティ１５０を実行する方法を示す
図である。
【００４４】図１に示すホスト・マルチプロセッサ１０
０は、バス１０４によって補助記憶装置１０６に接続さ
れたメモリ１０２を含み、補助記憶装置１０６は、たと
えば、ディスク・ドライブの場合もあれば、読取り専用
または読取り書込み光ディスク記憶装置、またはその他
の大容量記憶装置の場合もある。バス１０４には入出力
アダプタ１０８も接続され、入出力アダプタ１０８は、
キーボード、モニタ・ディスプレイ、通信アダプタ、ロ
ーカル・エリア・ネットワーク・アダプタ、モデム、マ
ルチメディア・インタフェース装置、またはその他の入
出力装置に接続することもできる。また、バス１０４に
は、第１のプロセッサＡ１１０と第２のプロセッサＢ１
１２も接続されている。図１に示す例は、対称的なマル
チプロセッサ構成の例であり、２つのユニプロセッサ１
１０および１１２が共通メモリ・アドレス空間１０２を
共用している。同様に適切な例として、単一プロセッサ
または複数プロセッサによる他の構成を示すことも可能
である。プロセッサは、たとえば、Ｉｎｔｅｌ３８６
（登録商標）ＣＰＵ、Ｉｎｔｅｌ４８６（登録商標）Ｃ
ＰＵ、Ｐｅｎｔｉｕｍ（登録商標）プロセッサ、Ｐｏｗ
ｅｒＰＣ（登録商標）プロセッサ、またはその他のユニ
プロセッサ・デバイスにすることができる。
【００４５】メモリ１０２はそこに格納されたマイクロ
カーネル・システム１１５を含み、マイクロカーネル・
システム１１５は、マイクロカーネル１２０と、パーソ
ナリティ・ニュートラル・サービス（ＰＮＳ）１４０
と、パーソナリティ・サーバ１５０とを含んでいる。マ
イクロカーネル・システム１１５は、メモリ１０２に格
納されているアプリケーション・プログラム１８０用の
オペレーティング・システムとして機能する。
【００４６】本発明の一目的は、ＵＮＩＸまたはＯＳ／
２のような従来のオペレーティング・システムのように
動作するオペレーティング・システムを提供することに
ある。それは、既存のオペレーティング・システム・パ
ーソナリティの高性能エミュレーションを可能にするた
めの機能上の基礎を提供することである。すなわち、こ
のオペレーティング・システムは、ＯＳ／２またはＵＮ
ＩＸ、あるいはその他の従来のオペレーティング・シス
テムのパーソナリティを有するものになる。
【００４７】マイクロカーネル１２０には、ホスト・マ
ルチプロセッサ１００の最優先状態で実行されるシステ
ム・ソフトウェアの一部であってマシンの基本動作を制
御する小さいメッセージ引渡し核が収容されている。マ
イクロカーネル・システム１１５は、マイクロカーネル
１２０と、パーソナリティ・ニュートラル・サービス１
４０を提供する１組のサーバおよびデバイス・ドライバ
とを含んでいる。名前が示唆するように、パーソナリテ
ィ・ニュートラル・サーバ（Personality Neutral Serv
er）およびデバイス・ドライバは、ＵＮＩＸまたはＯＳ
／２のようないかなるパーソナリティにも依存していな
い。これらはマイクロカーネル１２０に依存し、相互に
依存する。パーソナリティ・サーバ１５０は、マイクロ
カーネル１２０のメッセージ引渡しサービスを使用して
パーソナリティ・ニュートラル・サービス１４０とやり
とりする。たとえば、ＵＮＩＸ、ＯＳ／２、または他の
パーソナリティ・サーバは、パーソナリティ・ニュート
ラル・ディスク・ドライバにメッセージを送信し、１ブ
ロック分のデータをディスクから読み取るようそれに指
示することができる。ディスク・ドライバはそのブロッ
クを読み取って、それをメッセージに入れて返す。メッ
セージ・システムは、ポインタを操作することによって
大量のデータが迅速に転送されるように最適化されてい
るので、データそのものはコピーされない。
【００４８】マイクロカーネル１２０は、そのサイズ
と、アプリケーション・プログラムとして標準的なプロ
グラミング・サービスおよび機能をサポートできる能力
とにより、標準的なオペレーティング・システムより単
純になっている。マイクロカーネル・システム１１５
は、様々に構成される複数のモジュールに分解され、小
規模なシステムにそのモジュールを追加することによっ
てより大規模なシステムを構築できるようになってい
る。たとえば、各パーソナリティ・ニュートラル・サー
バ１４０は、論理的には別個のものなので、様々な構成
が可能である。各サーバは、アプリケーション・プログ
ラムとして動作し、アプリケーション・デバッガを使用
してデバッグすることができる。また、各サーバは個別
のタスクで動作し、サーバのエラーはそのタスクに閉じ
込められる。
【００４９】図１は、プロセス間通信モジュール（ＩＰ
Ｃ）１２２と、仮想メモリ・モジュール１２４と、タス
クおよびスレッド・モジュール１２６と、ホストおよび
プロセッサ・セット１２８と、入出力サポートおよび割
込み１３０と、マシン依存コード１２５とを含むマイク
ロカーネル１２０を示している。
【００５０】図１に示すパーソナリティ・ニュートラル
・サービス１４０は、マスタ・サーバと、初期設定と、
命名とを含む、複数パーソナリティ・サポート１４２を
含んでいる。サービス１４０はデフォルト・ページャ１
４４も含んでいる。また、サービス１４０は、複数パー
ソナリティ・サポートとデバイス・ドライバとを含む、
デバイス・サポート１４６も含んでいる。さらに、サー
ビス１４０は、ファイル・サーバと、ネットワーク・サ
ービスと、データベース・エンジンと、セキュリティと
を含む、その他のパーソナリティ・ニュートラル・プロ
ダクト１４８も含んでいる。
【００５１】パーソナリティ・サーバ１５０は、たとえ
ば、ＵＮＩＸパーソナリティなどにすることが可能な主
要パーソナリティ１５２である。このサーバは、ＵＮＩ
Ｘサーバであるはずの主要パーソナリティ・サーバ１５
４と、ＵＮＩＸ主要パーソナリティをサポートするはず
の他の主要パーソナリティ・サービス１５５とを含んで
いる。また、代替主要パーソナリティ１５６は、ＯＳ／
２などにすることができる。この代替パーソナリティ１
５６には、ＯＳ／２パーソナリティの特徴となるはずの
代替パーソナリティ・サーバ１５８と、ＯＳ／２用の他
の代替パーソナリティ・サービス１５９とが含まれてい
る。
【００５２】ＵＮＩＸ主要パーソナリティの例に関連し
て図１に示されている主要パーソナリティ・アプリケー
ション１８２は、ＵＮＩＸオペレーティング・システム
・パーソナリティ１５２上で動作するはずのＵＮＩＸタ
イプのアプリケーションである。図１に示す代替パーソ
ナリティ・アプリケーション１８６は、ＯＳ／２代替パ
ーソナリティ・オペレーティング・システム１５６上で
動作するＯＳ／２アプリケーションである。
【００５３】図１は、マイクロカーネル・システム１１
５によって、その実施態様が、プロセッサ・タイプごと
に完全に移植可能なコードと、それが実行される特定の
マシンのプロセッサのタイプに依存するコードとに慎重
に分割されていることを示している。また、このシステ
ムは、デバイスに依存するコードをデバイス・ドライバ
に分離しているが、デバイス・ドライバ・コードは、デ
バイスに依存しているものの、必ずしもプロセッサ・ア
ーキテクチャに依存しているわけではない。タスク当た
り複数のスレッドを使用すると、特定のマシンをマルチ
プロセッサにせずにマルチプロセッサの使用が可能にな
るようなアプリケーション環境が提供される。ユニプロ
セッサでは、各種のスレッドが様々な時期に実行され
る。複数プロセッサに必要なすべてのサポートがこの小
さく単純なマイクロカーネル１２０に凝集されている。
【００５４】この項では、マイクロカーネル・システム
１１５の構造の概要を示す。以降では、この構造の各構
成要素について詳しく説明し、マイクロカーネル・シス
テム１１５の各種サービスを使用して新しいプログラム
を構築するのに必要な技術について説明する。
【００５５】マイクロカーネル・システム１１５は、オ
ペレーティング・システム用の新しい基礎である。これ
は、オペレーティング・システム開発のための総合環境
に以下の特徴を提供するものである。 複数パーソナリティのサポート 拡張可能なメモリ管理 プロセス間通信 マルチスレッド マルチプロセッシング
【００５６】マイクロカーネル・システム１１５は、純
粋カーネルとして実施されたカーネル・サービスの簡略
セットと、１組のユーザレベル・サーバとして実施され
た、オペレーティング・システム・パーソナリティ構築
用のサービスの拡張セットとを提供する。マイクロカー
ネル・システム１１５の目的には、以下のことが含まれ
る。 複数のオペレーティング・システム・パーソナリティが
協調して機能できるようにすること デバイス・ドライバおよびファイル・システムなどの低
レベル・システム要素用の共通プログラミングを提供す
ること オペレーティング・システムとユーザ・アプリケーショ
ンの両方で並行処理を利用すること 散在している可能性のある大きいアドレス空間をフレキ
シブルなメモリ共用でサポートすること 透過ネットワーク資源アクセスを可能にすること ＯＳ／２およびＵＮＩＸなどの既存のソフトウェア環境
との互換性を維持すること 移植性（３２ビットおよび６４ビット・プラットフォー
ムへの）
【００５７】マイクロカーネル・システム１１５は、以
下の概念を基礎とする。多くの従来のオペレーティング
・システム機能（たとえば、ファイル・システムおよび
ネットワーク・アクセス）を実行するユーザ・モード・
タスク オペレーティング・システムを作成するためのユーザレ
ベルの実行時サービスの基本セット 単純かつ拡張可能な通信カーネル オブジェクト参照としての通信チャネルを備えたオブジ
ェクト基盤 同期および非同期プロセス間通信を使用するクライアン
ト／サーバ・プログラミング・モデル
【００５８】マイクロカーネル・システム１１５の基礎
は、単純かつ拡張可能な通信カーネルを提供することで
ある。また、マイクロカーネル・システム１１５の目的
の１つは、適正カーネルの最小限の機能によりユーザ空
間またはカーネル空間のいずれかでサービスのフレキシ
ブルな構成を可能にすることである。カーネルは、タス
ク間通信の他に、以下のものを含むサポートを提供しな
ければならない。 制御点の管理（スレッド） 資源割当て（タスク） タスク用のアドレス空間のサポート 物理メモリ、プロセッサ、割込み、ＤＭＡチャネル、ク
ロックなどの物理資源の管理
【００５９】ユーザ・モード・タスクは、資源の使用法
に関する各種方針を実現する。カーネルは、このような
方針を実施するための機構を提供するにすぎない。論理
的には、カーネルの上にパーソナリティ・ニュートラル
・サービス１４０（ＰＮＳ）層が存在する。ＰＮＳは、
ストリング機能などの基本構造体を含むＣ実行時環境
と、以下のものを含む１組のサーバとを提供する。 名前サーバ ― クライアントがサーバを見つけられる
ようにする マスタ・サーバ ― プログラムのロードおよび始動を
可能にする
【００６０】カーネル・アブストラクション マイクロカーネル・システム１１５の目標の１つは、カ
ーネル自体によって提供されるアブストラクションを最
小限にすることであって、このようなアブストラクショ
ンに関連するセマンティクスの点で最小にすることでは
ない。提供されるアブストラクションのそれぞれは、そ
れに関連する１組のセマンティクスと、残りのアブスト
ラクションとの対話の複合セットとを有する。このた
め、重要な考え方の識別が困難になる場合もある。主な
カーネル・アブストラクションは、以下の通りである。 タスク ― 資源割振り、大きいアクセス空間、および
ポート権の単位 スレッド ― 軽量（低オーバヘッド）のＣＰＵ使用状
況の単位 ポート ― 送信／受信ケイパビリティまたは権利によ
ってのみアクセス可能な通信チャネル メッセージ ― データ・オブジェクトの集合 メモリ・オブジェクト ― メモリ管理の内部単位 （タスク、スレッド、ポート、メッセージ、およびメモ
リ・オブジェクトの各概念の詳細については、第２節
「アーキテクチャ・モデル」を参照されたい。）
【００６１】タスクおよびスレッド マイクロカーネル・システム１１５は、従来のプロセス
の概念を提供するわけではない。というのは、すべての
オペレーティング・システム環境がプロセスに関連する
相当なセマンティクス（ユーザＩＤ、信号状態など）を
有するからである。これらの拡張セマンティクスを理解
したり提供することは、マイクロカーネルの目的ではな
い。
【００６２】多くのシステムはプロセスと制御の実行点
とを同一視しているが、システムによっては同一視して
いないものもある。
【００６３】マイクロカーネル１２０は、オペレーティ
ング・システム環境のプロセスとは別個に複数の制御点
をサポートする。マイクロカーネルは、以下の２通りの
概念を提供する。 タスク スレッド （タスクおよびスレッドの各概念の詳細については、第
２節「アーキテクチャ・モデル」を参照されたい。）
【００６４】メモリ管理 カーネルは何らかのメモリ管理を提供する。メモリはタ
スクに関連付けられている。メモリ・オブジェクトは、
タスクがメモリ管理を制御する際の手段である。マイク
ロカーネル・システム１１５は、散在している可能性の
ある大きい仮想アドレス空間をサポートするための各種
機構を提供する。それぞれのタスクは、カーネルによっ
て管理される関連のアドレス・マップを有し、そのタス
クのアドレス空間の仮想アドレスを物理アドレスに変換
する処理を制御する。仮想メモリ・システムの場合のよ
うに、所与のタスクのアドレス空間全体の内容は、物理
メモリに同時に完全に常駐するわけではなく、タスクの
仮想アドレス空間用のキャッシュとして物理メモリを使
用するための諸機構が存在していなければならない。従
来の仮想メモリ設計とは異なり、マイクロカーネル・シ
ステム１１５はキャッシュそのものをすべて実現するわ
けではない。これは、このような諸機構に関与できる能
力をユーザ・モード・タスクに与えるものである。ＰＮ
Ｓは、メモリ用のページング・サービスを提供するデフ
ォルト・ページャ１４４というユーザ・タスクを含んで
いる。
【００６５】マイクロカーネル・システム１１５の他の
資源とは異なり、仮想メモリはポートを使用して参照さ
れるわけではない。メモリは、特定のタスクのアドレス
空間内の索引として仮想アドレスを使用することによっ
てのみ、参照することができる。メモリと、タスクのア
ドレス空間を定義する関連のアドレス・マップは、部分
的に他のタスクと共用することができる。タスクは、そ
のアドレス空間内の新しいメモリ範囲を割り振り、その
割振りを解除し、その範囲に対する保護を変更すること
ができる。また、タスクは、その範囲の継承特性を指定
することもできる。新しいタスクは、その新しいタスク
用のアドレス空間を構築するためのベースとして既存の
タスクを指定することによって作成される。既存のタス
クの各メモリ範囲の継承属性によって、新しいタスクの
範囲が定義されているかどうか、ならびにその範囲が実
質的にコピーされているのかまたは既存のタスクと共用
されているのかが決まる。メモリに関する仮想コピー操
作のほとんどは、コピー・オン・ライト最適化によって
達成される。コピー・オン・ライト最適化は保護共用に
よって達成される。２つのタスクはコピー対象のメモリ
を共用するが、読取り専用アクセスの場合に限られる。
いずれかのタスクが範囲の一部を修正しようと試みる
と、その時点でその部分がコピーされる。このメモリ・
コピーの遅延評価は、マイクロカーネル・システム１１
５によって行われる重要なパフォーマンス最適化の１つ
であり、システムの通信／メモリ原理にとって重要なも
のである。
【００６６】所与のメモリ領域はメモリ・オブジェクト
によって支援される。メモリ・マネージャ（manager）
・タスクは、メモリにキャッシュされている間の一連の
ページのイメージ（あるメモリ領域の物理メモリ内容）
とキャッシュされていないときのその一連のページのイ
メージ（アブストラクション・メモリ・オブジェクト）
との関係を管理する方針を提供する。ＰＮＳには、始め
はゼロが充填されて、システム・ページング空間と照ら
し合わせてページングされる基本的な非持続性メモリ・
オブジェクトを提供する、デフォルトのメモリ・マネー
ジャまたはページャが用意されている。
【００６７】タスク間通信 マイクロカーネル・システム１１５は、通信チャネルを
介して送られるメッセージによって他のタスク（サー
バ）を要求することによってタスク（クライアント）が
サービスにアクセスする、クライアント／サーバ・シス
テム構造を使用する。マイクロカーネル１２０が提供す
るそれ専用のサービスは非常に少ない（たとえば、ファ
イル・サービスは一切提供しない）ので、マイクロカー
ネル１２０のタスクは、必要なサービスを提供する他の
数多くのタスクとやりとりしなければならない。プロセ
ス間通信（ＩＰＣ）機構の通信チャネルはポートと呼ば
れる。（ポートの詳細については、第２節「アーキテク
チャ・モデル」を参照されたい。）メッセージは、デー
タ、メモリ領域、およびポート権の集合である。ポート
権は、その権利を保有するタスクがそのポートを命名す
る際の名前である。ポート権は、タスクによって所有さ
れている場合、そのタスクに固有でしかもタスク内のス
レッドがその権利を使用する際の関連ハンドルを有す
る。ポートは、適切なポート権を保有する場合のみ、ポ
ートを操作することができる。あるポートの受信権を保
有できるのは１つのタスクに限られる。このタスクは、
ポート待ち行列からメッセージを受け取る（読み取る）
ことができる。複数のタスクはそのポートへの送信権を
保有することができ、その送信権により複数のタスクが
メッセージを待ち行列に送信する（書き込む）ことが可
能になる。タスクは、１組のデータ要素を収容するデー
タ構造を構築し、次に、保有する送信権の対象となるポ
ート上でメッセージ送信操作を実行することによって、
別のタスクとやりとりする。その後、そのポートへの受
信権を保有するタスクがメッセージ受信操作を実行す
る。
【００６８】ただし、このメッセージ転送は非同期動作
であることに留意されたい。メッセージは（おそらくコ
ピー・オン・ライト最適化により）受信タスクに論理的
にコピーされる。メッセージは、送信点のセンダーの空
間から受信点でコピーされる。この転送が非同期の場合
は、センダーとレシーバが同時に使用できなくなり、レ
シーバが使用可能になるのを待つために明示メッセージ
の作成とその待ち行列化が必要になる状況が発生する。
受信タスク内の複数のスレッドは、所与のポートからの
メッセージ受信を試みることができるが、所与のメッセ
ージを受け取るのは１つのスレッドに限られる。
【００６９】第２節 アーキテクチャ・モデル マイクロカーネル・システム１１５は、その主要責任と
して、フレームワーク内で命令を実行する制御点を用意
している。このような制御点はスレッドと呼ばれる。ス
レッドは仮想環境で実行される。カーネルによって提供
される仮想環境には、カーネルによって提供されるユー
ザ空間ＰＮＳおよびエミュレートされた命令（システム
・トラップ）分だけ増加した、ユーザ空間がアクセス可
能なハードウェア命令をすべて実行する仮想プロセッサ
が含まれる。この仮想プロセッサは、１組の仮想化レジ
スタと、本来ならマシンの物理メモリと同様の応答を行
う何らかの仮想メモリとにアクセスする。他のハードウ
ェア資源はいずれも、メモリ・アクセスとエミュレート
された命令との特別な組合せによってのみアクセスでき
る。ただし、カーネルによって提供されるすべての資源
が仮想化されていることに留意されたい。この項では、
スレッドから見た場合の仮想環境の最上位レベルの要素
について説明する。
【００７０】パーソナリティ・ニュートラル・サービス
（ＰＮＳ）の要素 マイクロカーネル・システム１１５のＰＮＳ１４０部分
は、基礎となるマイクロカーネル１２０上に構築された
各種サービスで構成されている。この部分は、カーネル
自体が依存している一部の機能ならびにプログラムの構
築用のユーザレベル・サービスの基本セットを提供す
る。これらのプログラムは、複数のオペレーティング・
システム・パーソナリティ・クライアントからの要求に
対応することができ、オペレーティング・システム・パ
ーソナリティそのものを構築するために使用される。さ
らに、標準的なＣで作成されたＰＮＳプログラムを構築
するためのＡＮＳＩ（米国規格協会）Ｃ実行時環境と、
ＰＯＳＩＸ（Portable Operating System Interface Fo
r Computer Environmetsの略）規格から取られた定義を
有するいくつかの補足機能とが存在する。ＰＮＳそのも
のを定義するライブラリの他に、適正マイクロカーネル
の一部である多くのライブラリがＰＮＳ内に存在する。
このようなライブラリは、マイクロカーネルがエクスポ
ートするインタフェースと、マイクロカーネル・システ
ム１１５のプロセス間通信機能とともに使用されるメッ
セージ・インタフェース・ジェネレータ（ＭＩＧ）用の
サポート論理とを表す。メッセージ・インタフェース・
ジェネレータは、カーネルの一部ではないが、カーネル
へのmk_msg呼出しを生成するユーティリティである。
【００７１】ＰＮＳ環境ライブラリの構造は、各サービ
スの実現内容の詳細をその呼出し側から隠蔽する。Ｃ実
行時ライブラリの１つのような一部のライブラリは、そ
の機能のすべてを呼出し側のアドレス空間にロードされ
るローカル・ルーチンとして実現するが、他のライブラ
リは、マイクロカーネルのＩＰＣシステムを呼び出して
サーバにメッセージを送信するスタブで構成されてい
る。このアーキテクチャにより、フレキシブルな機能実
現が可能になる。すなわち、サーバを他のサーバで置き
換えることができ、それを使用するプログラムのソース
に影響せずに複数のサービスを単一タスクに結合するこ
とができる。ＰＮＳ環境の重要要素は、それが完全なオ
ペレーティング・システムを構成しないという点であ
る。むしろ、ＰＮＳはパーソナリティの存在に依存す
る。システム・スタートアップ時に最初にロードされる
主要パーソナリティ１５２は、システム上にユーザ・イ
ンタフェースを提供し、そのクライアントとＰＮＳの諸
要素にサービスを提供する、オペレーティング・システ
ム・パーソナリティである。したがって、主要パーソナ
リティは「最後の手段」のサーバになる。主要パーソナ
リティは、ＰＮＳライブラリによって定義されている
が、別のサーバによって実現されないサービスをすべて
実現する。
【００７２】マイクロカーネル１２０は、ＰＮＳの一部
の要素にも依存する。このような場合としては、内部カ
ーネル動作を完了するためにパーソナリティ・ニュート
ラル・サーバにメッセージを送信する場合がある。たと
えば、ページ・フォルトを解決する際にマイクロカーネ
ル１２０は、デフォルト・ページャ１４４にメッセージ
を送信することができる。その場合、デフォルト・ペー
ジャ１４４は、カーネルがハード・ディスクから要求し
ているページを読み込む。通常、ページ・フォルトはユ
ーザ・タスクのために解決されるが、カーネルはメッセ
ージの送信側になる。
【００７３】実行時 ＰＮＳ実行時は、その環境で実行されるプログラム用の
標準的なＣプログラミング環境をサポートするために使
用される１組のＡＮＳＩ ＣおよびＰＯＳＩＸライブラ
リを提供する。これらの機能は、典型的なＣ言語構造体
を含んでいる。すべてのシステムと同様、マイクロカー
ネル・システム１１５は、その主要責任として、フレー
ムワーク内で命令を実行する制御点を用意する。マイク
ロカーネル１２０では、制御点はスレッドと呼ばれてい
る。スレッドは仮想環境で実行される。マイクロカーネ
ル１２０によって提供される仮想環境は、カーネルによ
って提供されるエミュレートされた命令（システム・ト
ラップ）分だけ増加した、ユーザ空間がアクセス可能な
ハードウェア命令をすべて実行する仮想プロセッサで構
成される。この仮想プロセッサは、１組の仮想化レジス
タと、本来ならマシンの物理メモリと同様の応答を行う
何らかの仮想メモリとにアクセスする。他のハードウェ
ア資源はいずれも、メモリ・アクセスとエミュレートさ
れた命令との特別な組合せによってのみアクセスでき
る。ただし、マイクロカーネルによって提供されるすべ
ての資源が仮想化されていることに留意されたい。この
項では、マイクロカーネル・スレッドから見た仮想環境
の最上位レベルの要素について説明する。
【００７４】カーネルの要素 マイクロカーネル１２０は、以下のカーネル要素のリス
トに記載された各種要素で構成された環境を提供する。 スレッド： 制御の実行点。スレッドは軽量エンティテ
ィである。スレッドに関連する状態の多くは、その収容
タスクに関連付けられている。 タスク： ポート名空間、仮想アドレス空間、および１
組のスレッドの形式で資源に対する参照を保管するため
の容器。 セキュリティ・トークン： タスクから、アクセス妥当
性検査を実行するサーバに渡されるセキュリティ機能。 ポート： タスク間の単一方向通信チャネル。 ポート・セット： メッセージを受け取るときに単一ユ
ニットとして扱うことができる１組のポート。 ポート権： ポートにアクセスするための具体的な権利
を許可するもの。 ポート名空間： 特定のポート権を命名するためのポー
ト名の索引付き集合。 メッセージ： ２つのタスク間で渡されるデータ、メモ
リ領域、およびポート権の集合。 メッセージ待ち行列： 単一ポートに関連するメッセー
ジの待ち行列。 仮想アドレス空間： タスク内のスレッドによって参照
可能なメモリ・ページがまばらに所在する索引付き集
合。ページ範囲は、カーネルおよび外部メモリ・マネー
ジャによって実現される機構によってそれらに関連付け
られた任意の属性およびセマンティクスを有する場合も
ある。 アブストラクション・メモリ・オブジェクト： このオ
ブジェクトによって支援されるメモリ範囲の非常駐状態
を表すアブストラクション・オブジェクト。このオブジ
ェクトを実現するタスクは、メモリ・マネージャと呼ば
れる。アブストラクション・メモリ・オブジェクト・ポ
ートは、カーネルがメモリ・マネージャのアクションを
要求する際のポートである。 メモリ・オブジェクト・レプリゼンタティブ（memory o
bject representative）： メモリ・オブジェクトのク
ライアントに対してメモリ・マネージャが提供するメモ
リ・オブジェクトのアブストラクション表現。このレプ
リゼンタティブは、関連のアブストラクション・メモリ
・オブジェクトを命名し、クライアントに許可される潜
在的なアクセス・モードを限定する。 メモリ・キャッシュ・オブジェクト： アブストラクシ
ョン・メモリ・オブジェクトによって支援されるメモリ
範囲の常駐状態を収容するカーネル・オブジェクト。メ
モリ・マネージャがクライアントの可視メモリ・イメー
ジを操作する場合、その操作はこのオブジェクトによっ
て行われる。 プロセッサ： スレッドを実行できる物理プロセッサ。 プロセッサ・セット： それぞれがプロセッサ・セット
に割り当てられているスレッドの実行に使用可能な１組
のプロセッサ。 ホスト： 全体としてのマルチプロセッサ。 クロック： 時間の経過を表すもの。一定の周波数で増
加する時間値。
【００７５】上記の要素の多くは、スレッドによって直
接操作可能な、カーネルで実現された資源である。それ
ぞれの要素については、以下の各項で詳しく説明する。
ただし、一部の要素の定義は他の要素の定義に依存する
ので、詳細説明を理解できるように、重要概念の一部に
ついては簡単に説明する。
【００７６】スレッド スレッドは軽量エンティティである。スレッドは、作成
するのに費用がかからず、動作に要するオーバヘッドも
低い。スレッドはほとんど状態を持たない（たいていは
そのレジスタ状態である）。スレッドが所有するタスク
は、資源管理の責任を負う。マルチプロセッサ上では、
タスク内の複数のスレッドが並列に実行することが可能
である。並行処理が目標ではなくても、複数スレッドは
有利である。というのは、各スレッドは、単一スレッド
が複数のサービスを提供しようとする非同期プログラミ
ングの代わりに、同期プログラミング・スタイルを使用
することができるからである。
【００７７】スレッドには、以下の特徴が含まれる。 １．タスクまたは一連の命令実行における制御流れの点 ２．収容タスクのすべての要素へのアクセス ３．複数のスレッドが同一タスク内にあっても、他のス
レッドと並列実行すること ４．オーバヘッドが低い割に状態が最小であること
【００７８】スレッドは、基本計算エンティティであ
る。スレッドは、その仮想アドレス空間を定義する１つ
のタスクにのみ属す。アドレス空間の構造に影響するた
め、またはアドレス空間以外の資源を参照するために
は、スレッドは特別なトラップ命令を実行しなければな
らない。これにより、カーネルは、スレッドのために諸
操作を実行するか、またはスレッドのためにエージェン
トにメッセージを送信する。このようなトラップは、ス
レッドを収容するタスクに関連する資源を操作する。こ
れらのエンティティを操作するよう、すなわち、それら
を作成して削除し、その状態を左右するよう、カーネル
に要求することができる。カーネルは、資源（前述のも
のなど）およびサービスを提供する管理プログラムであ
る。また、タスクもサービスを提供し、アブストラクシ
ョン資源を実現することができる。カーネルは、サーバ
・タスク（実際は、そこで実行されるスレッド）がサー
ビスを提供することをクライアント・タスクが要求でき
るようにするための通信方法を提供する。このようにし
て、タスクは２重のアイデンティティを持つ。一方のア
イデンティティは、カーネルによって管理される資源の
アイデンティティであって、その資源管理プログラムは
カーネル内で実行される。もう一方のアイデンティティ
は、資源の供給側のアイデンティティであって、そのた
めの資源管理プログラムはタスクそのものになる。
【００７９】スレッドは以下の状態を持つ。 １．そのマシン状態（レジスタなど）。スレッドが実行
されるにつれて変化し、カーネル・スレッド・ポートの
保有側による変更も可能であるもの。 ２．スレッド固有ポート権の小規模セット。スレッドの
カーネル・ポートと、スレッドのために例外メッセージ
を送信するために使用されるポートとを識別するもの。 ３．中断カウント。スレッドが命令を実行しない場合は
ゼロ以外になる。 ４．資源スケジューリング・パラメータ。
【００８０】スレッドは、通常通り命令を実行すること
によって動作する。スレッドのために諸操作を実行する
ために、様々な特殊命令がカーネルにトラップされる。
このようなカーネル・トラップのうちで最も重要なもの
は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呼出しへの様々なオ
プション、ならびに新しいタスクのクローン作成の元に
なるプロトタイプ・タスクのメモリ範囲の継承特性によ
り決まる。
【０１０８】仮想アドレス空間でのほとんどの操作によ
り、アドレス空間内のメモリ範囲が命名される。このよ
うな操作としては、以下のものが含まれる。 範囲の作成または割振りと、割振り解除 範囲のコピー 追出しを防止するためにページを物理メモリに「配線」
することを含む、特殊属性の設定 メモリ保護属性の設定 継承特性の設定 範囲の直接読取りおよび書込み 補助記憶装置への範囲の強制フラッシュ 範囲の予約（範囲内でのランダム割振りを防止する）
【０１０９】アブストラクション・メモリ・オブジェク
ト マイクロカーネルでは、ユーザ・モード・タスクが仮想
アドレス空間の各部分の参照に関連するセマンティクス
を提供することができる。これは、このメモリ・オブジ
ェクトによって支援されるメモリ範囲の非常駐状態を表
すアブストラクション・メモリ・オブジェクトの指定を
可能にすることによって行われる。このメモリ・オブジ
ェクトを実現し、メモリ・オブジェクトを命名するポー
トに送られるメッセージに応答するタスクは、メモリ・
マネージャと呼ばれている。カーネルは、各種のメモリ
・オブジェクトの内容用の直接アクセス可能なキャッシ
ュとしてメイン・メモリを使用する。と考える必要があ
る。カーネルは、アブストラクション・メモリ・オブジ
ェクト・ポートにメッセージを送ることによって、この
キャッシュを維持し、このキャッシュをカーネルの所望
通りに充填およびフラッシュするために、様々なメモリ
・マネージャとの非同期対話に関与する。アブストラク
ション・メモリ・オブジェクトに対する操作としては、
以下のものが含まれる。 初期設定 ページ読取り ページ書込み 強制およびフラッシュ動作との同期 ページにアクセスするための許可を求める要求 ページ・コピー 終了
【０１１０】メモリ・オブジェクト・レプリゼンタティ
ブ（memory object representative） メモリ・オブジェクト用の補助記憶装置へのアクセスを
要求するために、カーネルはアブストラクション・メモ
リ・オブジェクト・ポートを使用する。この対話の保護
性のため、一般にメモリ・マネージャは、アブストラク
ション・メモリ・オブジェクト・ポートへのアクセスを
クライアントに許可しない。むしろ、クライアントは、
メモリ・オブジェクト・レプリゼンタティブへのアクセ
スが許可される。メモリ・オブジェクト・レプリゼンタ
ティブとは、メモリ・オブジェクトのクライアント側の
表現である。このようなポートに対して許される操作は
１つだけであり、それは関連メモリ・オブジェクトをタ
スクのアドレス空間にマッピングすることである。この
ような要求を行うと、基礎となるアブストラクション・
メモリ・オブジェクトを初期設定するためにマッピング
・カーネルとメモリ・マネージャとの間のプロトコルが
開始される。そのレプリゼンタティブによって表される
アブストラクション・メモリ・オブジェクト、ならびに
そのレプリゼンタティブによって許されるアクセス・モ
ードの集合をカーネルに通知するには、この特殊なプロ
トコルが使用される。
【０１１１】メモリ・キャッシュ・オブジェクト カーネルのメイン・メモリ・キャッシュのうち、所与の
アブストラクション・メモリ・オブジェクトに関連する
常駐ページが入っている部分は、メモリ・キャッシュ・
オブジェクトと呼ばれる。メモリ・オブジェクト用のメ
モリ・マネージャは、カーネルのメモリ・キャッシュ・
オブジェクトに対する送信権を保有する。このメモリ・
マネージャは、関連メモリ・キャッシュ・オブジェクト
にメッセージを送ることによって、そのアブストラクシ
ョン・メモリ・オブジェクトのアブストラクションを提
供するために、カーネルとの非同期対話に関与する。
【０１１２】メモリ・キャッシュ・オブジェクトに対す
る操作としては、以下のものが含まれる。 動作属性の設定 属性の戻り カーネルへのページ供給 カーネルが要求したページが使用不能であることを示す
表示 カーネルが要求したページをカーネルのデフォルト・ル
ールによって充填する必要があることを示す表示 オブジェクトの遅延コピーの強制完了 メモリ・マネージャに送られたページが処分されたこと
を示す表示 メモリ・ページへのアクセスの制限 パフォーマンス上のヒントの提供 終了
【０１１３】プロセッサ スレッドを実行することができる各物理プロセッサは、
プロセッサ制御ポートによって命名される。実際の作業
を実行するという点で重要ではあるが、プロセッサ・セ
ットのメンバーとして以外にマイクロカーネル内のプロ
セッサはあまり重要ではない。１組のスレッドをスケジ
ュールするために使用されるプロセッサの共同管理用の
基礎を形成し、それに関連するスケジューリング属性を
有するのが、プロセッサ・セットである。プロセッサに
ついてサポートされている操作としては、以下のものが
含まれる。 プロセッサ・セットへの割当て 始動および停止などのマシン制御
【０１１４】プロセッサ・セット プロセッサはプロセッサ・セットにグループ化される。
プロセッサ・セットは、そのプロセッサ・セットに割り
当てられたスレッドをスケジュールするために使用され
るプロセッサの共同管理を行う。プロセッサ・セット
は、１組のスレッドのスケジュール可能性を均等に制御
するための基礎として存在する。また、この概念は、シ
ステム内の所与の活動にプロセッサをおおざっぱに割り
振るための方法も提供する。プロセッサ・セットの特徴
は、その上で実行されるスレッドのスケジューリングに
関する均一性である。スレッドは、その環境のエミュレ
ーションまたは移行を行わずに、あるプロセッサ・セッ
トまたは別のプロセッサ・セット上で実行することがで
きる。プロセッサ・セットについてサポートされている
操作としては、以下のものが含まれる。 作成および削除 プロセッサの割当て スレッドおよびタスクの割当て スケジューリング制御
【０１１５】ホスト ネットワーク化したマイクロカーネル・システム内の各
マシン（ユニプロセッサまたはマルチプロセッサ）は、
マイクロカーネルについて独自のインスタンス化を実行
する。一般に、ホスト・マルチプロセッサ１００はクラ
イアント・タスクによって操作されることはない。しか
し、各ホストはそれ専用のマイクロカーネル１２０を所
持し、それぞれが専用のポート空間、物理メモリ、およ
びその他の資源を備えているので、実行中のホストは目
に見えるものになり、時には直接操作されることもあ
る。また、各ホストはそれ専用の統計を生成する。ホス
トの命名は、自由に分散され、ホストに関する情報を入
手するために使用可能な名前ポートと、しっかり保持さ
れホストを操作するために使用可能な制御ポートとによ
って行われる。ホストによってサポートされている操作
としては、以下のものが含まれる。 クロック操作 統計収集 リブート デフォルト・メモリ・マネージャの設定 プロセッサおよびプロセッサ・セットのリストの入手
【０１１６】クロック クロックは、一定の周波数で時間値カウンタを増加する
ことによって、時間の経過を表す。マルチコンピュータ
内の各ホストまたはノードは、ハードウェアによってサ
ポートされる各種クロックおよびタイマ、ならびにこの
ようなタイマ上に構築されたアブストラクション・クロ
ックに基づいて、専用のクロック・セットを実現する。
所与のシステムによって実現されたクロック・セット
は、構成時に設定される。
【０１１７】それぞれのクロックは、名前ポートと、制
御または特権ポートとによって命名される。制御ポート
を使用すると、クロックの時刻と解像度を設定すること
ができる。名前ポートが与えられると、タスクは以下の
操作を実行することができる。 クロックの時刻と解像度の決定 時間値をマッピングするメモリ・オブジェクトの生成 所与の時刻までのスリープ（遅延） 所与の時刻での通知または警告の要求
【０１１８】第３節 タスクおよびスレッド 本節では、スレッドおよびタスクのユーザ可視視点につ
いて論じる。スレッドは、マイクロカーネル・システム
１１５内の活動エンティティである。スレッドは、他の
資源にアクセスする際の仮想アドレス空間とポート名空
間をスレッドに提供するタスク内の制御点として機能す
る。
【０１１９】スレッド スレッドは、基本的な計算エンティティである。スレッ
ドは、その仮想アドレス空間を定義する１つのタスクに
のみ属す。また、スレッドは、最小限の状態を有する軽
量エンティティである。スレッドは、ハードウェアによ
って指図された方法で実行され、スレッドのレジスタ値
に基づいてそのタスクのアドレス空間から命令を取り出
す。スレッドが直接実行することができるアクション
は、そのレジスタを操作し、そのメモリ空間での読取り
および書込みを行う命令を実行することだけである。た
だし、特権機械命令を実行しようと試みると、例外が発
生する。この例外については後述する。アドレス空間の
構造を左右するため、またはアドレス空間以外の資源を
参照するためには、スレッドは、スレッドのために操作
を実行するか、またはスレッドのために何らかのエージ
ェントにメッセージを送信するようカーネルに指示す
る、特殊トラップ命令を実行しなければならない。ま
た、障害またはその他の不当命令挙動が発生すると、カ
ーネルがその例外処理を呼び出す。
【０１２０】図２は、スレッドに関連するクライアント
可視構造を示している。スレッド・オブジェクトは、カ
ーネル・スレッド・ポートに送られたメッセージ用のレ
シーバである。このスレッド・ポート用の送信権を保有
するランダム・タスクを除き、スレッド・ポートは、収
容プロセッサ・セットまたは収容タスクを介してそのス
レッドのスレッド自己ポートとしてもアクセス可能であ
る。
【０１２１】ここでは、ガイ・ジー・ソトマイヤー他に
よる"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"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１３９】第Ｂ部 本発明の詳細な説明 図７は、マルチタスク・マルチプロセッシング・アプリ
ケーションで複数のタスクおよびスレッドを実行してい
るホスト・マルチプロセッサ１００の例である。ＩＰＣ
サブシステム１２２は、そのメッセージ引渡しライブラ
リ２２０および伝送制御モジュール７００とともに、２
つのプロセッサ１１０および１１２上でスレッドを実行
している３つのタスク２１０、２１０"、２１０'間のプ
ロセス間通信を管理する。データ処理システムは、図７
に示すような共用メモリ・マルチプロセッシング・シス
テムである場合もあれば、図１５に示すような分散処理
システムの場合もあり、ユニプロセッサ・システムの場
合もある。
【０１４０】メモリ１０２は、３つのタスクとともに示
されている。第１のタスク２１０は、それ自体の仮想ア
ドレス空間１０２Ａを定義するものであり、その範囲内
でそのスレッド２４８が動作する。第２のタスク２１
０"は、それ自体の仮想アドレス空間１０２Ｃを定義す
るものであり、その範囲内でそのスレッドが動作する。
第３のタスク２１０'は、それ自体の仮想アドレス空間
１０２Ｂを定義するものであり、その範囲内でそのスレ
ッド２４８'が動作する。送信メッセージ・バッファ７
５２はタスク２１０に対応し、受信メッセージ・バッフ
ァ７５４はタスク２１０"に対応し、送信メッセージ・
バッファ７５６はタスク２１０"に対応する。受信メッ
セージ・バッファ７５８はタスク２１０'に対応する。
また、メモリ１０２内には、Ｙデータ・オブジェクト７
１０、Ｚデータ・オブジェクト７１２、ＥＢＣＤＩＣデ
ータ・オブジェクト７１４、およびＡＳＣＩＩデータ・
オブジェクト７１６も存在する。
【０１４１】このマルチタスク・アプリケーションで
は、ユーザの目的を達成するために多くのタスクおよび
スレッドが互いに対話している。図７には、第１のタス
クＴ（Ａ）２１０と第２のタスクＴ（Ｃ）２１０"との
間の通信用として、伝送制御情報パス７０２／７０４と
データ・パス７２９という２つの経路が示されている。
伝送制御情報パスは、第１のタスク２１０からＩＰＣサ
ブシステム１２２への第１の経路構成要素７０２（詳細
は図８に示す）と、ＩＰＣサブシステム１２２から第２
のタスクＴ（Ｃ）２１０"への第２の経路構成要素７０
４（詳細は図９に示す）とで構成されている。データ・
パス７２９は、第１のタスク２１０の送信データ・バッ
ファ７５２から第２のタスク２１０"の受信メッセージ
・バッファ７５４に達している。
【０１４２】あるタスク２１０から別のタスク２１０"
へメッセージの形で情報をやりとりするため、ユーザ
は、マイクロカーネル１２０向けの送信タスク２１０の
プログラム・コードでmk_msgというプロシージャ呼出し
命令を提供する。このプロシージャ呼出しmk_msgは、宛
先タスク２１０"のポート５０７の名前（ＰＯＲＴ Ｎ
ＡＭＥ"）、メッセージの名前（ＡＬＰＨＡ）、メッセ
ージのタイプ（双方向同期ＲＰＣ）、およびその他の情
報を伴う。また、プロシージャ呼出しmk_msgは、伝送方
法を選択できるようにマイクロカーネル１２０に許可を
与えるか、または宛先タスク２１０"にデータの物理コ
ピーを提供することを要求するなど、メッセージに関す
るオプションを指定するためにユーザが提供したパラメ
ータ値を含んでいる。実行時にプロシージャ呼出しmk_m
sgが実行されると、送信側タスク２１０のためにメッセ
ージが形成され、宛先タスク２１０"に伝送されて、所
望の情報を伝送することになる。
【０１４３】図７は、ＩＰＣサブシステム１２２を介し
て第２のタスク２１０"に第１のメッセージＭＳＧ＿１
を伝送する第１のタスク２１０を示している。マイクロ
カーネル１２０のプロセス間通信サブシステム（ＩＰＣ
サブシステム）１２２は、タスク２１０と２１０"など
の間の制御情報およびデータのやりとりのためのメッセ
ージ引渡し操作を管理する。送信側タスク２１０から宛
先である受信側タスク２１０"に送られるすべてのメッ
セージは、ＩＰＣサブシステム１２２を使用してその伝
送を管理しなければならない。すべてのメッセージがＩ
ＰＣサブシステム１２２と対話しなければならないとい
う要件によって、ホスト１００などの使用中のマルチタ
スク・システム内のプロセス間通信に順序と予測可能性
がもたらされる。
【０１４４】図８は、本発明によりメッセージＭＳＧ＿
１のデータ部分７２０から伝送制御情報７０２を分離す
ることによって、メッセージ引渡しプロセスのパフォー
マンスを２つのタスク２１０および２１０"間で転送さ
れるメッセージの相対的な複雑さに連係できるようにす
る方法を示している。伝送制御情報７０２には、宛先タ
スクのポート名７２８、メッセージの名前７３２、およ
びメッセージのタイプ７２６など、全体的なメッセージ
・ヘッダ情報７１７が含まれる。また、伝送制御情報に
は、セキュリティ・トークンの指定７１９、タスクによ
る特殊ハードウェア・データの提供７３０、またはトレ
ーラ・セグメントの要件など、伝送操作自体の任意選択
機能を指定する伝送制御構造（ＴＣＳ）７２４も含まれ
る。伝送制御情報には、直接データ値の数と長さおよび
データ・オブジェクトを指すアドレス・ポインタの存在
７３４など、データ形式の特徴を指定するメッセージ制
御構造（ＭＣＳ）７２２と、送信データ・バッファ７５
２を指すポインタ７３５も含まれる。また、伝送制御情
報には、プロシージャ呼出しmk_msgからのパラメータ７
３７も含まれる。
【０１４５】伝送制御構造（ＴＣＳ）の記述子は、ヘッ
ダ内の任意選択のヘッダ・フィールドの形式を記述す
る。ＴＣＳは、メッセージ制御構造（ＭＣＳ）と同様、
呼出し間で変化することがなく、そのため、連続してＭ
ＣＳとともに常駐する。ヘッダは、呼出しごとの動的構
造なので、連続していない。これは、ＴＣＳ／ＭＣＳ構
造とパラメータ・バッファを指し示すものである。メッ
セージがＲＰＣかＩＰＣか、また、サーバ側からのもの
かクライアント側からのものかなどの基本伝送情報は常
に存在し、ヘッダの基本部分で検出することができる。
【０１４６】ＴＣＳは、大きい１組の機能オプションと
良好なパフォーマンスとをサポートする必要性から発生
した論理構造である。すべてのメッセージについて、Ｎ
ＤＲの指定、トレーラの提供、タイムアウト指定の提
供、または呼出しごとのヘッダにおける任意選択の宛先
ポートの提供が必要であるわけではない。ＴＣＳの任意
選択の内容がない場合は、固定ヘッダが呼出しごとに上
記のフィールドをすべて保持していなければならないは
ずである。あるいは、それらがメッセージのパラメータ
・セクションの一部になり、ＭＣＳによって記述される
はずである。これは、ＲＰＣメッセージの透過性に違反
するか、またはアプリケーションの引数をライブラリ生
成のパラメータ・バッファにマーシャルする必要がある
かのいずれかになり、その結果、不必要なコピー操作が
行われる恐れがある。
【０１４７】ＭＣＳは、ポートを変換し、被参照パラメ
ータを処理してローカル・プロシージャ呼出しのセマン
ティクスをエミュレートするために、メッセージ引渡し
ライブラリ２２０によって使用される。ＴＣＳとそれが
記述する情報は、主に、mk_msg呼出しの呼出し側と伝送
制御モジュール７００との間の通信である。ＮＤＲオー
バライド、トレーラ情報など、センダーから発生するＴ
ＣＳ情報は、レシーバの任意選択ヘッダに現れる場合も
あるが、最初に伝送制御モジュール７００を通過しなけ
ればならない。一般に、レシーバが要求したＴＣＳ内の
情報だけがレシーバによって受信される。レシーバが一
定のサイズ以下のトレーラの送達を要求した場合、任意
選択ヘッダ・セクションで適切な最大サイズが使用可能
になり、ＴＣＳ記述子がそれを記述する。センダーがト
レーラを送信しない場合は、ヘッダ内のそのフィールド
が存続するが、トレーラ・カウントはゼロになる。セン
ダーが１００バイト以下のトレーラを送信する場合は、
適切なカウントともにトレーラがヘッダ内に現れる。セ
ンダーが１００バイトを上回るトレーラを送信する場合
は、データが切り捨てられ、戻り状況は「トレーラが大
きすぎる」ことを反映したものになる。
【０１４８】送信側タスク２１０用のプログラム命令の
残りとともにプロシージャ呼出し命令mk_msgがコンパイ
ルされると、コンパイラは、図１２に示すタスク２１０
用のヘッダ・テンプレート７４０を形成する。プロシー
ジャ呼出しmk_msgがタスク２１０のスレッド２４８によ
って実行され、その実行がパス７２３を介してタスク・
ライブラリ２１０Ｈに通知されると、実行時に必ずヘッ
ダ・テンプレート７４０が呼び出される。ヘッダ・テン
プレート７４０は、送信側タスク２１０に関連するタス
ク・ライブラリ２１０Ｈに格納することができる。タス
ク・ヘッダ・ライブラリ２１０Ｈは、タスク２１０によ
って使用されるメッセージ・ヘッダ用としてすでにいく
つかのヘッダ・テンプレートを格納している可能性があ
る。ヘッダ・テンプレートは、タスク２１０内のプログ
ラムのコンパイル時にアセンブルされる。
【０１４９】送信側タスク２１０は、たとえば、４つの
構成要素バッファ７１３Ａ、７１３Ｂ、７１３Ｃ、およ
び７１３Ｄで構成される伝送制御バッファを有する。こ
れらのバッファは、プロシージャ呼出しmk_msgの実行準
備の際に様々な時点でユーザのプログラムによって公式
化されたときに伝送制御情報７０２の作業コピーを格納
するために送信側タスク２１０とそのスレッド２４８に
よって使用される。また、これらのバッファは、全体と
して伝送制御バッファとして機能する複数の非連続構成
要素バッファ７１３Ａ、７１３Ｂ、７１３Ｃ、および７
１３Ｄにすることができる。たとえば、バッファ７１３
Ａは、メッセージＩＤ、メッセージ・タイプ、および宛
先タスクなど、伝送制御全体のヘッダ情報７１７の作業
コピーを格納することができる。バッファ７１３Ａ内の
データ用のバイト・カウント値は、ヘッダ７４０に含め
るか、またはバッファ７１３Ａ自体の先頭に含めること
ができる。バッファ７１３Ｂは、伝送制御構造ＴＣＳ
７２４の作業コピーを格納することができる。バッファ
７１３Ｂ内のデータ用のバイト・カウント値７２５は、
ヘッダ７４０に含めるか、またはバッファ７１３Ｂ自体
の先頭に含めることができる。バッファ７１３Ｃは、メ
ッセージ制御構造７２２の作業コピーを格納することが
できる。バッファ７１３Ｃ内のデータ用のバイト・カウ
ント値７３５は、ヘッダ７４０に含めるか、またはバッ
ファ７１３Ｃ自体の先頭に含めることができる。バッフ
ァ７１３Ｄは、mk_msgパラメータ７３７の作業コピーを
格納することができる。バッファ７１３Ｄ内のデータ用
のバイト・カウント値は、ヘッダ７４０に含めるか、ま
たはバッファ７１３Ｄ自体の先頭に含めることができ
る。送信側タスク２１０のプログラムが伝送制御バッフ
ァ７１３Ａ、７１３Ｂ、７１３Ｃ、および７１３Ｄ内の
伝送制御情報７０２を準備している間に、送信側タスク
２１０は、送信データ・バッファ７５２内にパス７２７
を介してデータ７２０も準備している。
【０１５０】ユーザ・レベルのメッセージの各種構成要
素の再パッケージ化を回避することによって、システム
は、メッセージの構成要素を明示メッセージ構造に再コ
ピーするという余分な作業を回避する。メッセージ・ヘ
ッダは、ＭＣＳ、ＴＣＳ、およびメッセージ・パラメー
タ用の非連続バッファ７１３Ａ、７１３Ｂ、７１３Ｃ、
および７１３Ｄを指し示す。これらのバッファの内容は
様々な時点に作成されたものである。これらを１つのメ
ッセージ構造内に連続化する唯一の方法は、これらを再
コピーすることであるが、それはシステムが回避しよう
とする操作である。センダーとレシーバの両方を同時に
使用可能にすること（並置という）により、明示メッセ
ージ構造を形成する必要がまったくなくなる。プロセス
間通信サブシステム１２２は、送信側タスクの仮想アド
レス空間内のメッセージ・ポインタを受信側タスクの仮
想アドレス空間内の対応するポインタに変換し、変換し
たポインタを受信側タスクに提供する。変換されたポイ
ンタは、受信側タスクが必要とするＭＣＳ、パラメー
タ、およびＴＣＳ（ある場合）用の制御バッファ７１３
Ａ、７１３Ｂ、７１３Ｃ、および７１３Ｄを指し示す。
また、変換されたポインタは、送信側タスクが受信側タ
スクに使用可能なものにする必要がある被参照データ用
のデータ・オブジェクト７１０、７１２なども指し示
す。本発明の目的は、メッセージ引渡しプロセスで再コ
ピーしなければならない情報の量を最小限にすることで
ある。
【０１５１】宛先タスク２１０"のポート名、メッセー
ジの名前、およびメッセージのタイプなどの値は、タス
ク２１０とそのスレッド２４８の実行プログラムによっ
て生成されたときに、送信側タスク２１０の伝送制御バ
ッファ７１３Ａに格納される。
【０１５２】ヘッダ・テンプレート７４０は、マイクロ
カーネル１２０へのmk_msg呼出しを行う送信側タスク２
１０のアイデンティティ７４２を含んでいる。ヘッダ・
テンプレート７４０の全体的なヘッダ部分７１７は、送
信側タスク２１０の伝送制御バッファ７１３Ａを指すア
ドレス・ポインタ７１７'を含んでいる。タスク２１０
とそのスレッド２４８がプロシージャ呼出し命令mk_msg
を実行すると、ヘッダ・テンプレート７４０がＩＰＣサ
ブシステム１２２に提供される。これは、ＩＰＣサブシ
ステム１２２がmk_msgプロシージャ呼出しに対する応答
としてヘッダ・テンプレート７４０の内容を読み取れる
ようにするために、メッセージ引渡しライブラリ２２０
にヘッダ・テンプレート７４０を指すポインタを保管す
ることによって達成することができる。ヘッダ・テンプ
レート項目７４２は、マイクロカーネル１２０へのmk_m
sg呼出しを送信したものとして送信側タスク２１０を識
別する。ＩＰＣサブシステム１２２は、ヘッダ・テンプ
レート７４０内のポインタ７１７'を使用して、伝送制
御バッファ７１３Ａの内容の読取りを開始する。ポイン
タ７１７'は、メッセージの名前、宛先ポートの名前、
および送信する必要があるメッセージのタイプを示すバ
ッファ７１３Ａを指し示す。ＩＰＣサブシステム１２２
は、送信側タスクの伝送制御バッファ７１３Ａ、７１３
Ｂ、７１３Ｃ、および７１３Ｄをそれぞれ指し示すヘッ
ダ・テンプレート７４０内のポインタ７１７'、７２
４'、７２２'、および７３７'に従って、呼出しを確立
するのに十分な伝送制御情報を蓄積する。本発明によれ
ば、これは伝送制御情報７０２の追跡が必要になる唯一
の時期であり、ＩＰＣサブシステム１２２がメッセージ
伝送操作の確立を完了できるようにするために伝送制御
情報７０２を再コピーする必要は一切ない。メッセージ
引渡し操作のパフォーマンスを最大限にするため、メッ
セージの伝送制御情報が１回だけ解析され、送信側タス
ク２１０からＩＰＣサブシステム１２２へ、次にＩＰＣ
サブシステム１２２から宛先タスク２１０"へと、その
順次パス内で多くても１回だけコピーされる。
【０１５３】図１３は、図８のタスク２１０などの送信
側タスクからＩＰＣサブシステム１２２へのメッセージ
伝送における諸ステップを示す流れ図である。これは、
図１０の送信側タスク２１０"からＩＰＣサブシステム
１２２へのメッセージ伝送の諸ステップにも適用され
る。このプロセスは、マイクロカーネル１２０とそのメ
ッセージ引渡しライブラリ２２０およびその伝送制御モ
ジュール７００を備えたプロセス間通信サブシステム１
２２とが常駐しているメモリ１０２を含むホスト１００
などのデータ・プロセッサで実行される。
【０１５４】ステップ７６０は、データ７２０を第２の
タスク２１０"が使用できるようにするメッセージを送
信するためのメッセージ引渡しプロシージャ呼出しmk_m
sgを含む第１のタスク２１０用のプログラムをメモリ１
０２にロードすることによって開始される。このプログ
ラムは、アプリケーション・プログラム１８０、オペレ
ーティング・システム・パーソナリティ・プログラム１
５０、パーソナリティ・ニュートラル・サービス・プロ
グラム１４０、または図１に示すようなマイクロカーネ
ル１２０の構成要素の１つのいずれかにすることができ
る。
【０１５５】次にステップ７６２は、図８に示すよう
に、第１のタスク２１０、送信データ・バッファ７５
２、および伝送制御バッファ７１３Ａをメモリ１０２内
に形成する。これらは、コンパイル時にプログラムによ
って提供され、実行時にメモリ内に構築されるオブジェ
クトである。
【０１５６】次にステップ７６４は、図８および図１２
に示すように、伝送制御バッファ７１３Ａを指すポイン
タ７１７'を含む第１のタスク用のヘッダ・テンプレー
ト７４０を形成する。これも、コンパイル時にプログラ
ムによって提供され、実行時にメモリ内に構築されるオ
ブジェクトである。
【０１５７】次にステップ７６６は、プロセッサ１１０
内でプログラムからの命令を実行するために、図７に示
すように第１のタスク２１０に関連するスレッド２４８
をメモリ１０２内に形成する。これも、コンパイル時に
プログラムによって提供され、実行時にメモリ内に構築
されるオブジェクトである。
【０１５８】次にステップ７６８は、プロセッサ１１０
によってスレッド２４８内の第１の命令を実行して、図
８に示すように、データ値７２０を送信データ・バッフ
ァ７５２にロードし、制御値７０４を伝送制御バッファ
７１３Ａにロードする。
【０１５９】次にステップ７７０は、プロセッサ１１０
によってスレッド２４８内のプロシージャ呼出しmk_msg
を実行して、図８に示すように、プロセス間通信サブシ
ステム１２２の伝送制御モジュール７００がヘッダ・テ
ンプレート７４０を使用できるようにする。
【０１６０】次にステップ７７２は、図８および図９に
示すように、ヘッダ・テンプレート７４０によって指し
示される伝送制御バッファ７１３Ａ内の伝送制御情報７
０２を使用して、プロセス間通信サブシステム１２２の
伝送制御モジュール７００とともに送信データ・バッフ
ァ７５２から第２のタスク２１０"へのデータ値７２０
の伝送を確立する。
【０１６１】さらに本発明によれば、パス７２９を経由
する送信側タスク２１０から宛先タスク２１０"へのメ
ッセージのデータ部分７２０の伝送は、ＩＰＣサブシス
テム１２２が伝送制御情報７０２全体を解析し、送信側
タスク２１０が宛先タスク２１０"にこのメッセージを
送信する権利を有するように確立し、伝送制御情報７０
２に対して必要な修正または追加を行い、宛先タスク２
１０"の受信側ポート５０７に図９に示す代用伝送制御
情報７０４を待ち行列化する間、遅延される。プロセッ
サ１１０で資源枯渇が発生しているか、またはタイムア
ウトが時間切れになったか、またはポート権の不足など
のために、メッセージを伝送できない場合は、メッセー
ジのデータ部分７２０の打切り転送の際にプロセッサ１
１０の時間が浪費されない。非同期メッセージまたはホ
スト１００の外部で伝送されるメッセージを除き、伝送
制御情報７０２の個別の連続コピーを作成する必要は一
切ない。ＩＰＣサブシステム１２２によるこのメッセー
ジ・セットアップの間隔では、メッセージのデータ部分
７２０が送信側タスク２１０の送信データ・バッファ７
５２に常駐する。このデータ部分７２０は、直接データ
である場合もあれば、宛先タスク２１０"が使用できる
ようになっているデータなどを含むメモリ・オブジェク
ト７１０を指すアドレス・ポインタである場合もある。
【０１６２】さらに本発明によれば、ＩＰＣサブシステ
ム１２２は、メッセージ伝送の近道を提供することがで
きる。伝送制御情報７０２または送信側タスク２１０が
ポインタによって参照するオブジェクト７１０内に格納
されているデータ７２０あるいはその両方を、受信側バ
ッファ７５４または宛先タスク２１０"に属す他のメモ
リ・オブジェクトにコピーする必要はない。むしろ、Ｉ
ＰＣサブシステム１２２は、伝送する必要がある被参照
データを指すポインタをコピーできるだけである。ＩＰ
Ｃサブシステム１２２は、システム内のタスク、スレッ
ド、およびオブジェクト用のアドレス空間を記録する、
図７に示すメッセージ引渡しライブラリ２２０を管理す
る。
【０１６３】図１４は、送信側タスクから受信側タスク
にメッセージを送信する際の諸ステップを示す流れ図で
あり、プロセス間通信サブシステム１２２で実行される
ステップを中心に示している。 ステップ７８０： アプリケーションがパラメータ・バ
ッファを作成する。 ステップ７８２： 実行スレッドがユーザ・レベルのラ
イブラリ・ルーチン（ＭＩＧ生成ルーチン）に入る。 ステップ７８４： ＭＩＧ生成ルーチンがヘッダを作成
し、そのヘッダ内のフィールドに対してＴＣＳ／ＭＣＳ
バッファに入るようそのバッファを指し示す。このルー
チンは、ヘッダ内の別のフィールドに対してパラメータ
・バッファに入るようそのバッファを指し示す。次に、
ＭＫ＿ＭＳＧを呼び出す。 ステップ７８６： メッセージ引渡しライブラリ２２０
が初期伝送検査を行う。 ステップ７８７： ＩＰＣサブシステム１２２がメッセ
ージ・タイプ（ＲＰＣ、ＩＰＣ、送信／受信など）を決
定する。 ステップ７８８： ＩＰＣサブシステム１２２が宛先を
決定する。 ステップ７８９： ＩＰＣサブシステム１２２がタイム
アウト要求を実施する。 ステップ７９０： ＩＰＣサブシステム１２２がメッセ
ージと宛先を接続する（レシーバが使用可能な場合）。 ステップ７９１： メッセージ引渡しライブラリ２２０
がＭＣＳを解析して、被参照データとポート権を宛先に
移動する。 ステップ７９２： ＴＣＳで送信中の情報に注が付けら
れる。 ステップ７９３： レシーバに送信されるＴＣＳが解析
され、任意選択のヘッダで情報がレシーバに送信され
る。 ステップ７９４： 制御および新しいメッセージがレシ
ーバに送信される。パラメータ・バッファはセンダーの
バッファからのＭＣＳによって記述される。
【０１６４】図７は、ＩＰＣサブシステム１２２を介し
て第３のタスク２１０'に第２のメッセージＭＳＧ＿３
を伝送する第２のタスク２１０"を示している。ＭＳＧ
＿３用の伝送制御情報７０６は図１０に示され、ＭＳＧ
＿４用の代用伝送制御情報７０８は図１１に示されてい
る。送信側タスク２１０"と宛先タスク２１０'がそれぞ
れ別々のアドレス空間１０２Ａおよび１０２Ｂ内にある
ときに、ＩＰＣサブシステム１２２は、図１１の伝送制
御情報７０８と、送信側タスク２１０"がポインタによ
って参照するオブジェクト７１２内に格納されているデ
ータとのコピーを自動的に行う。
【０１６５】本発明によれば、ＩＰＣサブシステム１２
２は、すべてのメッセージ引渡しの場合に、ＩＰＣサブ
システム１２２が第２のタスク２１０"に渡されるメッ
セージをセットアップできるようにするために、第１の
タスク２１０がＩＰＣサブシステム１２２に提供するこ
とを希望する伝送制御情報のバッファ７１３Ａ、７１３
Ｂ、７１３Ｃ、および７１３Ｄを参照するポインタを引
き渡すことによって、不必要なコピー操作を回避する。
送信側タスク２１０と受信側タスク２１０"について
は、ＩＰＣサブシステム１２２は、制御情報のバッファ
７１３Ａ、７１３Ｂ、７１３Ｃ、および７１３Ｄを参照
するポインタを受信側タスク２１０"に引き渡す権利を
有する。メッセージ引渡しライブラリ２２０は、タス
ク、スレッド、およびオブジェクトと、タスクの各種仮
想アドレス空間の記録を管理する。プロセス間通信サブ
システム１２２は、送信側タスクの仮想アドレス空間か
らのポインタを、受信側タスクの仮想アドレス空間用の
変換済みポインタに変換する。アドレス・ポインタによ
って参照されるオブジェクト７１４および７１６内の被
参照データであって、メッセージ転送の一部として受信
側タスク２１０"が使用可能なデータについては、ＩＰ
Ｃサブシステム１２２は、送信データ・バッファ７５２
を参照するポインタを第２のタスク２１０"の受信メッ
セージ・バッファ７５４に変換するだけである。
【０１６６】このようにして、本発明は、マルチタスク
・システム１００内のプロセス間通信に順序と予測可能
性をもたらすためにすべてのメッセージがＩＰＣサブシ
ステム１２２と対話できるようにするものであり、さら
にシステムのパフォーマンスを最大限にするものであ
る。
【０１６７】ＩＰＣサブシステム１２２によるメッセー
ジ転送の確立では、メッセージ引渡しライブラリ２２０
を使用して各種オブジェクトを突き止め、メモリ１０２
のアドレス空間に入っているその属性を識別し、ケイパ
ビリティ・エンジン３００を使用して送信側タスク２１
０が宛先タスクのポート５０７にこのメッセージを送信
するのに十分なポート権を有するかどうかを判定し、呼
出しスケジューラ２３２を使用して宛先タスクのポート
５０７にメッセージを待ち行列化する。図８に示すよう
な送信側タスク２１０からＩＰＣサブシステム１２２へ
の伝送制御情報７０２は、宛先タスク２１０"とそのス
レッドがデータ部分７２０に対してそれぞれのプログラ
ム式操作を実行するのに必要なものを上回る情報を含ん
でいる。このため、ＩＰＣサブシステム１２２の伝送制
御モジュール７００は、図８の伝送制御情報７０２から
伝送制御構造７２４などの余分な情報を取り除き、オブ
ジェクト７１４または７１６内のハードウェア・データ
を指すポインタ７３０などの必要な情報を追加して、図
９に示す代用伝送制御情報７０４を形成する。その後、
図９に示す代用伝送制御情報７０４は、宛先タスク２１
０"の受信バッファ７５４が使用できるようになる。パ
ス７２９は受信バッファ７５４にデータ７２０を提供
し、代用伝送制御情報７０４用のパスは受信バッファ７
５４にそれを提供する。パス７３９は、データ７２０と
代用伝送制御情報７０４を宛先タスク２１０"が使用で
きるようにする。
【０１６８】制御バッファ７１３Ｂでアセンブルされた
伝送制御情報７０２の伝送制御部分７２４内のパラメー
タの値の一部は、送信側タスク２１０／スレッド２４８
によるアセンブリの間、ブランクのままになる。これら
のパラメータ値は、NDR_recordを指すポインタ値７３０
のように、プロセス間通信サブシステム１２２の伝送制
御モジュール７００によって提供される。このNDR_reco
rdは、データのコード・ページがメッセージを実行中の
ホスト・マシン１００のコード・ページと一致しない場
合などに、メッセージのメッセージ本文７２０内に含ま
れるデータを変換するために使用される。送信中のデー
タが実行スレッドを実行中の本来のマシン・タイプと一
致しない場合、ＮＤＲデータがセンダーによって提供さ
れることもある。送信側タスク２１０／スレッド２４８
で実行中のプログラム命令は、ホスト１００用のデフォ
ルト・コード・ページ（NDR_request）を指定すること
ができる。これに対して、伝送制御モジュール７００
は、メッセージ引渡しライブラリ２２０とともに、オブ
ジェクト７１６内のデフォルトのNDR_recordを指すポイ
ンタ７３０の値を、宛先タスク２１０"の受信バッファ
７５４に提供される伝送制御情報７０４の伝送制御構造
７２４に書き込む。
【０１６９】図９に示す代用伝送制御情報７０４は、デ
ータ部分７２０の形式を提供するメッセージ制御構造７
２２を含んでいる。メッセージ転送が許可される可能性
があるとＩＰＣサブシステムが判定し、宛先タスク２１
０"のポート５０７に呼出しを待ち行列化してしまう
と、送信側タスク２１０の送信データ・バッファ７５２
内のデータ部分７２０を宛先タスク２１０"の受信バッ
ファ７５４が使用できるようにすることができる。図９
に示す代用伝送制御情報７０４とデータ部分７２０は、
ＩＰＣ１２２によって宛先タスク２１０"の受信バッフ
ァ７５４にコピーすることができる。あるいは、送信側
タスク２１０とそのスレッドで実行中のプログラムがそ
の伝送制御バッファ７１３Ａ、７１３Ｂ、７１３Ｃ、ま
たは７１３Ｄに情報を保持することを許可する場合は、
ＩＰＣサブシステム１２２によって受信バッファ７５４
に格納されている第１のポインタによって、制御バッフ
ァ内に保持されている代用伝送制御情報７０４を指し示
すことができる。送信側タスクが宛先タスクからの応答
を待つので、これは同期ＲＰＣメッセージが伝送される
場合である可能性がある。このため、コピー操作は最小
限になる。同様に、送信側タスクで実行中のプログラム
がその送信データ・バッファ７５２に情報を保持するこ
とを許可する場合は、ＩＰＣサブシステム１２２によっ
て受信バッファ７５４に格納されている第２のポインタ
によって、バッファ７５２内に保持されているデータ７
２０を指し示すことができる。この場合も、送信側タス
クが宛先タスクからの応答を待つので、これは同期ＲＰ
Ｃメッセージが伝送される場合である可能性がある。こ
のため、コピー操作はさらに最小限になる。受信バッフ
ァ７５４内にある伝送制御情報７０４と受信バッファ７
５４内にあるデータ部分７２０は、プログラムによって
予想される形式に構成され、宛先タスク２１０"とその
スレッドで実行中のプログラムが必要とする情報であ
る。
【０１７０】ＩＰＣサブシステム１２２の伝送制御モジ
ュール７００は、図１０および図１１の伝送制御情報７
０６および７０８と、送信側タスク２１０"がポインタ
によって参照したオブジェクト７１２および７１６内に
格納されているデータとを、自動的に宛先タスク２１
０'が使用できるようにする。
【０１７１】図８〜図１１に示す例は、第１のタスク２
１０から第２のタスク２１０"への第１のＲＰＣメッセ
ージと、第２のタスク２１０"から第３のタスク２１０'
への第２のＩＰＣメッセージという２つのメッセージの
例である。この例は、それがＲＰＣメッセージで第２の
タスク２１０"への送信を希望するＥＢＣＤＩＣ形式の
データを処理する第１のタスク２１０の例である。第２
のタスク２１０"から第１のタスク２１０へ予想される
応答は、第２のタスク２１０"とそのスレッドがその計
算を完了し、その結果をＡＳＣＩＩ形式で第３のタスク
２１０'へ送信する準備ができていることを示す肯定応
答になるはずである。第２のタスク２１０"から第３の
タスク２１０'へのメッセージは、非同期単方向ＩＰＣ
メッセージ・タイプである。
【０１７２】メッセージからのＥＢＣＤＩＣデータにつ
いて第２のタスク２１０"で操作するには、オブジェク
ト７１４からのＥＢＣＤＩＣコード・ページが必要にな
る。第２のタスク２１０"の例では、データ・オブジェ
クト７１０からの定数ＹにＸ１とＸ２をそれぞれ追加し
て、ＡＳＣＩＩ形式の結果７３６、７３６'、および７
３６"を出力する。この例は、ＥＢＣＤＩＣ形式の英小
文字からＡＳＣＩＩ形式の英大文字への変換になる可能
性がある。ＡＳＣＩＩ形式の結果データは、第２のタス
ク２１０"がそのＲＰＣ応答を第１のタスク２１０に送
信して、それがＡＳＣＩＩ変換を完了したことを肯定応
答した後で、ＩＰＣメッセージ・タイプ７２０'で第３
のタスク２１０'に出力されるはずである。
【０１７３】図１０は、プロセス間通信サブシステム１
２２にそれを送信するための準備の際に第２の送信側タ
スク２１０"による形成の後に現れるはずの伝送制御情
報７０６を示している。送信側タスク２１０"は、Ｙオ
ブジェクト７１０を使用してメッセージ・データ７３６
に対する操作の実行を完了している。図１０の制御バッ
ファ７１３Ａ、７１３Ｂ、７１３Ｃ、および７１３Ｄ
は、タスク２１０"に属し、単方向非同期メッセージ・
タイプを意味するメッセージ・タイプ７２６"＝ＩＰＣ"
などの制御情報７０６を使用してタスク２１０"によっ
て準備されている。図１０のタスク・ヘッダ・ライブラ
リ２１０"Ｈは、呼出し側タスクとしてのタスク２１０"
のアイデンティティとともに、図１２に示すようなヘッ
ダ・テンプレート７４０を格納する。パス７２３を介し
てmk_msg信号がタスク２１０"から図１０のタスク・ヘ
ッダ・ライブラリ２１０"Ｈに送信されると、ヘッダ・
テンプレート７４０がタスク２１０"の制御バッファを
指すポインタとともにＩＰＣサブシステム１２２に提供
され、ＩＰＣサブシステム１２２に図１０の伝送制御情
報７０６を提供する。タスク２１０"は、送信データ・
バッファ７５６へのパス７２７を介してデータ７２０'
を準備しているので、ＩＰＣサブシステム１２２がメッ
セージ転送の確立を完了すると、パス７３１を介してそ
のデータがタスク２１０'の受信バッファ７５８で使用
可能になる。
【０１７４】図１１は、プロセス間通信サブシステム１
２２によって処理された後で現れる代用伝送制御情報７
０８を示している。この代用伝送制御情報７０８は、メ
ッセージ名"Ｂｅｔａ"７３２と、ハードウェア・データ
・ポインタ７３０"＝ｄｅｆａｕｌｔ"とを含んでいる。
タスク２１０"の送信バッファ７５６からのデータ・パ
ス７３１により、データ７２０'がタスク２１０'の受信
バッファ７５８で使用可能になる。受信バッファ７５８
からタスク２１０'へのパス７３９'により、代用伝送制
御情報７０８とデータ７２０'の両方がタスク２１０'で
使用可能になる。宛先タスク２１０'は、Ｚオブジェク
ト７１２とＡＳＣＩＩオブジェクト７１６とを使用し
て、ＡＳＣＩＩメッセージ・データ７３６、７３６'、
および７３６"に対する操作を実行する。
【０１７５】メッセージ本文７２０から伝送制御情報７
０２を分離すると、プロセス間通信サブシステム１２２
と伝送制御モジュール７００を使用するすべての形態の
メッセージ転送の効率と速度を高めることができる。
【０１７６】クライアント・タスク２１０またはサーバ
・タスク２１０'あるいはその両方は、アプリケーショ
ン・プログラム１８０、オペレーティング・システム・
パーソナリティ・プログラム１５０、パーソナリティ・
ニュートラル・サービス・プログラム１４０、またはマ
イクロカーネル１２０自体の一部にすることができる。
上記の各タイプのプログラムには、そのプログラムの目
的を実行するためのタスクとそのスレッドを作成しなけ
ればならない。このようなタスクは、マイクロカーネル
・システム１１５で並行実行される他のタスクと通信し
なければならない。このようなタスクは、ホスト・マル
チプロセッサ１００内の他のアプリケーション・プログ
ラム１８０で並行実行される他のタスクと通信しなけれ
ばならない。さらに、このようなタスクは、図１５に示
す分散処理ネットワーク内のように、各種ホスト・マル
チプロセッサ・システム１００'上で並行実行される他
のタスクとも通信しなければならない。このようなタス
クの１つから別のタスクへの各通信は、本発明による制
御登録によって提供される効率を利用することができ
る。
【０１７７】図１５は、分散処理配置で動作する２つの
ホスト・マルチプロセッサ・システムの機能ブロック図
であり、通信リンクを介して２つのホスト間でメッセー
ジを交換し、各ホスト・プロセッサ上のＩＰＣサブシス
テム１２２と伝送制御モジュール７００がタスク間のプ
ロセス間通信を管理する場合を示している。ホスト１０
０は、分散処理アプリケーションについて前述したよう
に、ホスト１００'内のタスク２１１'に転送されるメッ
セージをホスト１００'とそのタスク２１１に送信する
ことができる。
【０１７８】マイクロカーネルは、メモリ１０２の諸領
域をマッピングするためのケイパビリティまたは権利を
管理する、ケイパビリティ・エンジン・モジュール３０
０も含んでいる。このケイパビリティ・エンジン３００
は、呼出しスケジューラ２３２、メッセージ引渡しライ
ブラリ２２０、一時データ・モジュール４００、制御登
録モジュール５００、無名応答モジュール６００、伝送
制御分離モジュール７００、共用メモリ・サポート・モ
ジュール８００、および高速パス・モジュール９００を
含む他の複数のモジュールとともに、ＩＰＣサブシステ
ム１２２に含まれている。これらのモジュールはすべ
て、ＩＰＣ１２２のプロセス間通信操作に貢献するサー
ビスを提供する。
【０１７９】ケイパビリティ・エンジン３００、一時デ
ータ・モジュール４００、メッセージ制御構造登録モジ
ュール５００、および無名応答モジュール６００の詳細
については、前述の関連特許出願を参照することができ
る。ジェームズ・エム・マジー他の"CAPABILITY ENGINE
METHOD AND APPARATUS FOR A MICROKERNEL DATA PROCE
SSING SYSTEM"という名称の関連米国特許出願を参照さ
れたい。また、ジェームズ・エム・マジー他の"TEMPORA
RY DATA METHOD AND APPARATUS FOR A MICROKERNEL DAT
A PROCESSING SYSTEM"という名称の関連米国特許出願も
参照されたい。ジェームズ・エム・マジー他の"MESSAGE
CONTROL STRUCTURE REGISTRATION METHOD AND APPARAT
US FOR A MICROKERNEL DATA PROCESSING SYSTEM"という
名称の関連米国特許出願も参照されたい。また、ジェー
ムズ・エム・マジー他の"ANONYMOUS REPLY PORT METHOD
AND APPARATUS FOR A MICROKERNEL DATA PROCESSING S
YSTEM"という名称の関連米国特許出願も参照されたい。
【０１８０】本発明は、ユニプロセッサ、共用メモリ・
マルチプロセッサ、および分散プロセッサ・システム内
の複数コンピュータに適用される。図１５は、分散処理
配置で動作する２つのホスト・マルチプロセッサ・シス
テム１００および１００'の機能ブロック図であり、通
信リンク２５０を介して２つのホスト間でメッセージを
交換し、各ホスト・プロセッサ上のＩＰＣサブシステム
１２２と伝送制御モジュール７００がタスク間のプロセ
ス間通信を管理する場合を示している。
【０１８１】図１５では、ホスト１００のスレッド２４
８'が、入出力アダプタ・プロセッサ１０８で実行され
る処理要求を送出する。実行のためにスレッド２４８'
によって送出された命令は、入出力プロセッサ１０８か
らホスト１００'の入出力プロセッサ１０８'に送られる
メッセージの形式化に必要な命令を含むことができる。
このようなメッセージは、前述のようにＩＰＣ１２２の
援助によってクライアントのタスク（Ａ）２１０からタ
スク（Ｂ）２１０'に送られるサーバ・タスク２１１ま
たは２１１'に関するメッセージになりうる。このメッ
セージは、通信リンク２５０を介して入出力プロセッサ
１０８'に送られる。次に、タスク２１１に関連するス
レッド２４９が、入出力プロセッサ１０８'内で実行さ
れ、ポート権とポインタ２４０に関する情報をタスク２
１１に転送する。前述の１回目の転送と同様のもう１つ
のＩＰＣ転送をホスト１００'で実行して、元々はホス
ト１００内のタスク（Ａ）から発生したメッセージから
の情報をホスト１００'内のタスク２１１'に転送するこ
とができる。ホスト１００'内のタスク２１１'に属すス
レッド２４９'は、ホスト１００'のプロセッサ１１２'
内で命令を実行し、ホスト１００内のタスク２１０から
受け取るメッセージに含まれる情報を操作することがで
きる。これは、伝送制御モジュール７００が常駐するそ
れ専用のメモリ１０２内でまたは個別のメモリ１０２'
を有するプロセッサ１１２'とともに、プロセス間通信
を容易にする際に果たすことができる役割の唯一の例で
ある。
【０１８２】第１節 サブシステム・レベルの対話 ＩＰＣ１２２サブシステムと、ＶＭ、ポート、タスクお
よびスレッドとの関係 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 同期および非同期の単方向および双
方向プロセス間通信 ＩＰＣメッセージ・タイプのセットは、ＲＰＣの大きく
しかもほぼ完全なサブセットである。ＩＰＣメッセージ
・タイプは、ケイパビリティ、直接データ、および被参
照データ型の大部分をサポートする。ＩＰＣデータ型に
よってサポートされていない唯一の被参照データ型は、
要求と応答とのセマンティクス上のリンクおよび合体し
たメッセージ制御構造のためにＲＰＣに存在する、Serv
er_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_Temporaryのように、ＩＰＣメッセージ・タイプ
の非持続メモリは、ヘッダ、メッセージ制御構造（要求
された場合）、およびメッセージ本文に続いて、受信バ
ッファ内に置かれる。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_shu
ttleクローンの場合の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)発明者 クリストファー・ディーン・ヤングワース アメリカ合衆国61874−0363 イリノイ州 サヴォイ ガルフビュー・コート ナンバ ー３

Claims (51)

    【特許請求の範囲】
  1. 【請求項１】マイクロカーネル・アーキテクチャにおけ
    るプロセス間通信用のシステムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記データ処理システム内の前記メモリ手段に結合さ
    れ、信号を転送するデータ・バス手段と、 前記データ・バス手段により前記メモリ手段に結合さ
    れ、前記プログラム式命令を実行するプロセッサ手段
    と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、メッセージ制御情報を格納
    する制御バッファと、メッセージ・データ情報を格納す
    るデータ・バッファとを有し、さらに前記プロセッサ手
    段内で命令を実行する第１のスレッドを有し、宛先ポー
    トに送信する第１のメッセージを形成する第１のタスク
    と、 前記メモリ手段内にあって、前記宛先ポートを定義する
    １組の属性を有し、さらに前記プロセッサ手段内で命令
    を実行する第２のスレッドを有する第２のタスクと、 前記プロセス間通信手段内にあって、それを再コピーせ
    ずに前記制御バッファで前記メッセージ制御情報を解釈
    し、それに対する応答として、前記第２のタスクが前記
    メッセージ・データを使用できるようにする伝送制御手
    段とを含む、システム。
  2. 【請求項２】前記第１のタスクがアプリケーション・プ
    ログラムを表すことを特徴とする、請求項１に記載のマ
    イクロカーネル・アーキテクチャにおけるプロセス間通
    信用のシステム。
  3. 【請求項３】前記第１のタスクがオペレーティング・シ
    ステム・パーソナリティ・プログラムを表すことを特徴
    とする、請求項１に記載のマイクロカーネル・アーキテ
    クチャにおけるプロセス間通信用のシステム。
  4. 【請求項４】前記第１のタスクがパーソナリティ・ニュ
    ートラル・サービス・プログラムを表すことを特徴とす
    る、請求項１に記載のマイクロカーネル・アーキテクチ
    ャにおけるプロセス間通信用のシステム。
  5. 【請求項５】共用メモリ・マルチプロセッサにおけるプ
    ロセス間通信用のシステムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記データ処理システム内の前記メモリ手段に結合さ
    れ、信号を転送するデータ・バス手段と、 前記データ・バス手段により前記メモリ手段に結合さ
    れ、前記プログラム式命令を実行する第１のプロセッサ
    手段と、 前記データ・バス手段により前記メモリ手段に結合さ
    れ、前記プログラム式命令を実行する第２のプロセッサ
    手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、メッセージ制御情報を格納
    する制御バッファと、メッセージ・データ情報を格納す
    るデータ・バッファとを有し、さらに前記プロセッサ手
    段内で命令を実行する第１のスレッドを有し、宛先ポー
    トに送信する第１のメッセージを形成する第１のタスク
    と、 前記メモリ手段内にあって、前記宛先ポートを定義する
    １組の属性を有し、さらに前記プロセッサ手段内で命令
    を実行する第２のスレッドを有する第２のタスクと、 前記プロセス間通信手段内にあって、それを再コピーせ
    ずに前記制御バッファで前記メッセージ制御情報を解釈
    し、それに対する応答として、前記第２のタスクが前記
    メッセージ・データを使用できるようにする伝送制御手
    段とを含む、システム。
  6. 【請求項６】前記第１のタスクがアプリケーション・プ
    ログラムを表すことを特徴とする、請求項５に記載の共
    用メモリ・マルチプロセッサにおけるプロセス間通信用
    のシステム。
  7. 【請求項７】前記第１のタスクがオペレーティング・シ
    ステム・パーソナリティ・プログラムを表すことを特徴
    とする、請求項５に記載の共用メモリ・マルチプロセッ
    サにおけるプロセス間通信用のシステム。
  8. 【請求項８】前記第１のタスクがパーソナリティ・ニュ
    ートラル・サービス・プログラムを表すことを特徴とす
    る、請求項５に記載の共用メモリ・マルチプロセッサに
    おけるプロセス間通信用のシステム。
  9. 【請求項９】分散プロセッサ・システムにおけるプロセ
    ス間通信用のシステムであって、 分散プロセッサ・システムの第１のホスト・システム内
    にあって、データおよびプログラム式命令を格納するメ
    モリ手段と、 前記データ処理システム内の前記メモリ手段に結合さ
    れ、信号を転送するデータ・バス手段と、 前記データ・バス手段により前記メモリ手段に結合さ
    れ、前記プログラム式命令を実行する第１のプロセッサ
    手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、メッセージ制御情報を格納
    する制御バッファと、メッセージ・データ情報を格納す
    るデータ・バッファとを有し、さらに前記第１のプロセ
    ッサ手段内で命令を実行する第１のスレッドを有し、宛
    先ポートに送信する第１のメッセージを形成する第１の
    タスクと、 前記メモリ手段内にあって、前記宛先ポートを定義する
    １組の属性を有し、さらに前記第１のプロセッサ手段内
    で命令を実行する第２のスレッドを有する第２のタスク
    と、 前記プロセス間通信手段内にあって、それを再コピーせ
    ずに前記制御バッファで前記メッセージ制御情報を解釈
    し、それに対する応答として、前記第２のタスクが前記
    メッセージ・データを使用できるようにする伝送制御手
    段と、 前記第１のホスト・システム内の前記第１のプロセッサ
    を前記分散プロセッサ・システムの第２のホスト・シス
    テムに結合する通信リンクと、 前記第２のホスト・システム内にあって、前記通信リン
    クを介して前記第１のプロセッサ手段に結合された第２
    のプロセッサ手段とをさらに含み、 前記第１のタスクが、前記第２のプロセッサ手段に前記
    メッセージを送信するために、前記通信リンクに前記メ
    ッセージを提供する、システム。
  10. 【請求項１０】前記第１のタスクがアプリケーション・
    プログラムであることを特徴とする、請求項９に記載の
    分散プロセッサ・システムにおけるプロセス間通信用の
    システム。
  11. 【請求項１１】前記第１のタスクがオペレーティング・
    システム・パーソナリティ・プログラムであることを特
    徴とする、請求項９に記載の分散プロセッサ・システム
    におけるプロセス間通信用のシステム。
  12. 【請求項１２】前記第１のタスクがパーソナリティ・ニ
    ュートラル・サービス・プログラムであることを特徴と
    する、請求項９に記載の分散プロセッサ・システムにお
    けるプロセス間通信用のシステム。
  13. 【請求項１３】マイクロカーネル・アーキテクチャにお
    けるプロセス間通信用のシステムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間のメッセージ引渡しを調整するプロセス間通信
    手段と、 前記メモリ手段に結合され、前記プログラム式命令を実
    行するプロセッサ手段と、 前記メモリ手段内にあって、メッセージ制御情報を格納
    する制御バッファと、メッセージ・データ情報を格納す
    るデータ・バッファとを有し、さらに前記プロセッサ手
    段内で命令を実行する第１のスレッドを有し、宛先ポー
    トに送信する第１のメッセージを形成する第１のタスク
    と、 前記メモリ手段内にあって、前記宛先ポートを定義する
    １組の属性を有し、さらに前記プロセッサ手段内で命令
    を実行する第２のスレッドを有する第２のタスクと、 前記プロセス間通信手段内にあって、それを再コピーせ
    ずに前記制御バッファで前記メッセージ制御情報を解釈
    し、それに対する応答として、前記第２のタスクが前記
    メッセージ・データを使用できるようにする伝送制御手
    段とを含む、システム。
  14. 【請求項１４】前記第１のタスクがアプリケーション・
    プログラムを表すことを特徴とする、請求項１３に記載
    のマイクロカーネル・アーキテクチャにおけるプロセス
    間通信用のシステム。
  15. 【請求項１５】前記第１のタスクがオペレーティング・
    システム・パーソナリティ・プログラムを表すことを特
    徴とする、請求項１３に記載のマイクロカーネル・アー
    キテクチャにおけるプロセス間通信用のシステム。
  16. 【請求項１６】前記第１のタスクがパーソナリティ・ニ
    ュートラル・サービス・プログラムを表すことを特徴と
    する、請求項１３に記載のマイクロカーネル・アーキテ
    クチャにおけるプロセス間通信用のシステム。
  17. 【請求項１７】前記メモリ手段に結合され、前記プログ
    ラム式命令を実行する第２のプロセッサ手段と、 前記メモリ手段内にあって前記第２のタスクに関連し、
    前記第２のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第３のスレッドとをさらに含む
    ことを特徴とする、請求項１３に記載のマイクロカーネ
    ル・アーキテクチャにおけるプロセス間通信用のシステ
    ム。
  18. 【請求項１８】前記メモリ手段と前記プロセッサ手段
    が、分散プロセッサ・システムの第１のホスト・システ
    ム内にあり、 前記第１のホスト・システム内の前記プロセッサ手段を
    前記分散プロセッサ・システムの第２のホスト・システ
    ムに結合する通信リンクと、 前記第２のホスト・システム内にあって、前記通信リン
    クを介して前記第１のホスト・システム内の前記プロセ
    ッサ手段に結合され、前記通信リンクを介して前記メッ
    セージを交換する第２のプロセッサ手段とをさらに含む
    ことを特徴とする、請求項１３に記載のマイクロカーネ
    ル・アーキテクチャにおけるプロセス間通信用のシステ
    ム。
  19. 【請求項１９】マイクロカーネル・アーキテクチャにお
    けるプロセス間通信方法であって、 データ処理システムのメモリ手段にデータおよびプログ
    ラム式命令を格納するステップと、 前記メモリ手段に結合されたプロセッサ手段内で前記プ
    ログラム式命令を実行するステップと、 プロセス間通信手段において、前記メモリ手段内の複数
    のタスク間のメッセージ引渡しを調整するステップと、 メッセージ制御情報を格納する制御バッファと、メッセ
    ージ・データ情報を格納するデータ・バッファとを有
    し、さらに前記プロセッサ手段内で命令を実行する第１
    のスレッドを有し、宛先ポートに送信する第１のメッセ
    ージを形成する第１のタスクを前記メモリ手段に格納す
    るステップと、 前記宛先ポートを定義する１組の属性を有し、さらに前
    記プロセッサ手段内で命令を実行する第２のスレッドを
    有する第２のタスクを前記メモリ手段に格納するステッ
    プと、 前記プロセス間通信手段内の伝送制御手段により、それ
    を再コピーせずに前記制御バッファで前記メッセージ制
    御情報を解釈し、それに対する応答として、前記第２の
    タスクが前記メッセージ・データを使用できるようにす
    るステップとを含む方法。
  20. 【請求項２０】前記第１のタスクがアプリケーション・
    プログラムを表すことを特徴とする、請求項１９に記載
    のマイクロカーネル・アーキテクチャにおけるプロセス
    間通信方法。
  21. 【請求項２１】前記第１のタスクがオペレーティング・
    システム・パーソナリティ・プログラムを表すことを特
    徴とする、請求項１９に記載のマイクロカーネル・アー
    キテクチャにおけるプロセス間通信方法。
  22. 【請求項２２】前記第１のタスクがパーソナリティ・ニ
    ュートラル・サービス・プログラムを表すことを特徴と
    する、請求項１９に記載のマイクロカーネル・アーキテ
    クチャにおけるプロセス間通信方法。
  23. 【請求項２３】アプリケーション・プログラムがマイク
    ロカーネル・アーキテクチャ内の別のタスクとのプロセ
    ス間通信を要求する方法であって、 データ処理システムのメモリ手段にデータおよびプログ
    ラム式命令を格納するステップと、 前記メモリ手段に結合されたプロセッサ手段内で前記プ
    ログラム式命令を実行するステップと、 プロセス間通信手段において、前記メモリ手段内の複数
    のタスク間のメッセージ引渡しを調整するステップと、 メッセージ制御情報を格納する制御バッファと、メッセ
    ージ・データ情報を格納するデータ・バッファとを有
    し、さらに前記プロセッサ手段内で命令を実行する第１
    のスレッドを有し、宛先ポートに送信する第１のメッセ
    ージを形成する第１のアプリケーション・プログラム・
    タスクを前記メモリ手段に格納するステップと、 前記宛先ポートを定義する１組の属性を有し、さらに前
    記プロセッサ手段内で命令を実行する第２のスレッドを
    有する第２のアプリケーション・プログラム・タスクを
    前記メモリ手段に格納するステップと、 前記プロセス間通信手段内の伝送制御手段により、それ
    を再コピーせずに前記制御バッファで前記メッセージ制
    御情報を解釈し、それに対する応答として、前記第２の
    タスクが前記メッセージ・データを使用できるようにす
    るステップとを含む方法。
  24. 【請求項２４】オペレーティング・システム・パーソナ
    リティ・プログラムがマイクロカーネル・アーキテクチ
    ャ内の別のタスクとのプロセス間通信を要求する方法で
    あって、 データ処理システムのメモリ手段にデータおよびプログ
    ラム式命令を格納するステップと、 前記メモリ手段に結合されたプロセッサ手段内で前記プ
    ログラム式命令を実行するステップと、 プロセス間通信手段において、前記メモリ手段内の複数
    のタスク間のメッセージ引渡しを調整するステップと、 メッセージ制御情報を格納する制御バッファと、メッセ
    ージ・データ情報を格納するデータ・バッファとを有
    し、さらに前記プロセッサ手段内で命令を実行する第１
    のスレッドを有し、宛先ポートに送信する第１のメッセ
    ージを形成する第１のオペレーティング・システム・パ
    ーソナリティ・タスクを前記メモリ手段に格納するステ
    ップと、 前記宛先ポートを定義する１組の属性を有し、さらに前
    記プロセッサ手段内で命令を実行する第２のスレッドを
    有する第２のオペレーティング・システム・パーソナリ
    ティ・タスクを前記メモリ手段に格納するステップと、 前記プロセス間通信手段内の伝送制御手段により、それ
    を再コピーせずに前記制御バッファで前記メッセージ制
    御情報を解釈し、それに対する応答として、前記第２の
    タスクが前記メッセージ・データを使用できるようにす
    るステップとを含む方法。
  25. 【請求項２５】パーソナリティ・ニュートラル・サービ
    ス・プログラムがマイクロカーネル・アーキテクチャ内
    の別のタスクとのプロセス間通信を要求する方法であっ
    て、 データ処理システムのメモリ手段にデータおよびプログ
    ラム式命令を格納するステップと、 前記メモリ手段に結合されたプロセッサ手段内で前記プ
    ログラム式命令を実行するステップと、 プロセス間通信手段において、前記メモリ手段内の複数
    のタスク間のメッセージ引渡しを調整するステップと、 メッセージ制御情報を格納する制御バッファと、メッセ
    ージ・データ情報を格納するデータ・バッファとを有
    し、さらに前記プロセッサ手段内で命令を実行する第１
    のスレッドを有し、宛先ポートに送信する第１のメッセ
    ージを形成する第１のパーソナリティ・ニュートラル・
    サービス・プログラム・タスクを前記メモリ手段に格納
    するステップと、 前記宛先ポートを定義する１組の属性を有し、さらに前
    記プロセッサ手段内で命令を実行する第２のスレッドを
    有する第２のパーソナリティ・ニュートラル・サービス
    ・プログラム・タスクを前記メモリ手段に格納するステ
    ップと、 前記プロセス間通信手段内の伝送制御手段により、それ
    を再コピーせずに前記制御バッファで前記メッセージ制
    御情報を解釈し、それに対する応答として、前記第２の
    タスクが前記メッセージ・データを使用できるようにす
    るステップとを含む方法。
  26. 【請求項２６】アプリケーション・プログラムがマイク
    ロカーネル・アーキテクチャ内の別のタスクとのプロセ
    ス間通信を要求するシステムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記メモリ手段内にあって、実行されるアプリケーショ
    ン・プログラム命令を提供するアプリケーション・プロ
    グラム手段と、 前記メモリ手段に結合され、前記プログラム式命令を実
    行するプロセッサ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、メッセージ制御情報を格納
    する制御バッファと、メッセージ・データ情報を格納す
    るデータ・バッファとを有し、さらに前記プロセッサ手
    段内で命令を実行する第１のスレッドを有し、宛先ポー
    トに送信する第１のメッセージを形成する第１のタスク
    と、 前記メモリ手段内にあって、前記宛先ポートを定義する
    １組の属性を有し、さらに前記プロセッサ手段内で命令
    を実行する第２のスレッドを有する第２のタスクと、 前記プロセス間通信手段内にあって、それを再コピーせ
    ずに前記制御バッファで前記メッセージ制御情報を解釈
    し、それに対する応答として、前記第２のタスクが前記
    メッセージ・データを使用できるようにする伝送制御手
    段とを含む、システム。
  27. 【請求項２７】前記メモリ手段に結合され、前記プログ
    ラム式命令を実行する第２のプロセッサ手段と、 前記メモリ手段内にあって前記第２のタスクに関連し、
    前記第２のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第３のスレッドとをさらに含む
    ことを特徴とする、請求項２６に記載のアプリケーショ
    ン・プログラムがマイクロカーネル・アーキテクチャ内
    の別のタスクとのプロセス間通信を要求するシステム。
  28. 【請求項２８】前記メモリ手段と前記プロセッサ手段
    が、分散プロセッサ・システムの第１のホスト・システ
    ム内にあり、 前記第１のホスト・システム内の前記プロセッサ手段を
    前記分散プロセッサ・システムの第２のホスト・システ
    ムに結合する通信リンクと、 前記第２のホスト・システム内にあって、前記通信リン
    クを介して前記第１のホスト・システム内の前記プロセ
    ッサ手段に結合され、前記通信リンクを介して前記メッ
    セージを交換する第２のプロセッサ手段とをさらに含む
    ことを特徴とする、請求項２６に記載のアプリケーショ
    ン・プログラムがマイクロカーネル・アーキテクチャ内
    の別のタスクとのプロセス間通信を要求するシステム。
  29. 【請求項２９】オペレーティング・システム・パーソナ
    リティ・プログラムがマイクロカーネル・アーキテクチ
    ャ内の別のタスクとのプロセス間通信を要求するシステ
    ムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記メモリ手段内にあって、実行されるオペレーティン
    グ・システム・パーソナリティ・プログラム命令を提供
    するオペレーティング・システム・パーソナリティ・プ
    ログラム手段と、 前記メモリ手段に結合され、前記プログラム式命令を実
    行するプロセッサ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、メッセージ制御情報を格納
    する制御バッファと、メッセージ・データ情報を格納す
    るデータ・バッファとを有し、さらに前記プロセッサ手
    段内で命令を実行する第１のスレッドを有し、宛先ポー
    トに送信する第１のメッセージを形成する第１のタスク
    と、 前記メモリ手段内にあって、前記宛先ポートを定義する
    １組の属性を有し、さらに前記プロセッサ手段内で命令
    を実行する第２のスレッドを有する第２のタスクと、 前記プロセス間通信手段内にあって、それを再コピーせ
    ずに前記制御バッファで前記メッセージ制御情報を解釈
    し、それに対する応答として、前記第２のタスクが前記
    メッセージ・データを使用できるようにする伝送制御手
    段とを含む、システム。
  30. 【請求項３０】前記メモリ手段に結合され、前記プログ
    ラム式命令を実行する第２のプロセッサ手段と、 前記メモリ手段内にあって前記第２のタスクに関連し、
    前記第２のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第３のスレッドとをさらに含む
    ことを特徴とする、請求項２６に記載のオペレーティン
    グ・システム・パーソナリティ・プログラムがマイクロ
    カーネル・アーキテクチャ内の別のタスクとのプロセス
    間通信を要求するシステム。
  31. 【請求項３１】前記メモリ手段と前記プロセッサ手段
    が、分散プロセッサ・システムの第１のホスト・システ
    ム内にあり、 前記第１のホスト・システム内の前記プロセッサ手段を
    前記分散プロセッサ・システムの第２のホスト・システ
    ムに結合する通信リンクと、 前記第２のホスト・システム内にあって、前記通信リン
    クを介して前記第１のホスト・システム内の前記プロセ
    ッサ手段に結合され、前記通信リンクを介して前記メッ
    セージを交換する第２のプロセッサ手段とをさらに含む
    ことを特徴とする、請求項２６に記載のオペレーティン
    グ・システム・パーソナリティ・プログラムがマイクロ
    カーネル・アーキテクチャ内の別のタスクとのプロセス
    間通信を要求するシステム。
  32. 【請求項３２】パーソナリティ・ニュートラル・サービ
    ス・プログラムがマイクロカーネル・アーキテクチャ内
    の別のタスクとのプロセス間通信を要求するシステムで
    あって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記メモリ手段内にあって、実行されるパーソナリティ
    ・ニュートラル・サービス・プログラム命令を提供する
    パーソナリティ・ニュートラル・サービス・プログラム
    手段と、 前記メモリ手段に結合され、前記プログラム式命令を実
    行するプロセッサ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間のメッセージ引渡しを調整するプロセス間通信
    手段と、 前記メモリ手段内にあって、メッセージ制御情報を格納
    する制御バッファと、メッセージ・データ情報を格納す
    るデータ・バッファとを有し、さらに前記プロセッサ手
    段内で命令を実行する第１のスレッドを有し、宛先ポー
    トに送信する第１のメッセージを形成する第１のタスク
    と、 前記メモリ手段内にあって、前記宛先ポートを定義する
    １組の属性を有し、さらに前記プロセッサ手段内で命令
    を実行する第２のスレッドを有する第２のタスクと、 前記プロセス間通信手段内にあって、それを再コピーせ
    ずに前記制御バッファで前記メッセージ制御情報を解釈
    し、それに対する応答として、前記第２のタスクが前記
    メッセージ・データを使用できるようにする伝送制御手
    段とを含む、システム。
  33. 【請求項３３】前記メモリ手段に結合され、前記プログ
    ラム式命令を実行する第２のプロセッサ手段と、 前記メモリ手段内にあって前記第２のタスクに関連し、
    前記第２のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第３のスレッドとをさらに含む
    ことを特徴とする、請求項３２に記載のパーソナリティ
    ・ニュートラル・サービス・プログラムがマイクロカー
    ネル・アーキテクチャ内の別のタスクとのプロセス間通
    信を要求するシステム。
  34. 【請求項３４】前記メモリ手段と前記プロセッサ手段
    が、分散プロセッサ・システムの第１のホスト・システ
    ム内にあり、 前記第１のホスト・システム内の前記プロセッサ手段を
    前記分散プロセッサ・システムの第２のホスト・システ
    ムに結合する通信リンクと、 前記第２のホスト・システム内にあって、前記通信リン
    クを介して前記第１のホスト・システム内の前記プロセ
    ッサ手段に結合され、前記通信リンクを介して前記メッ
    セージを交換する第２のプロセッサ手段とをさらに含む
    ことを特徴とする、請求項３２に記載のパーソナリティ
    ・ニュートラル・サービス・プログラムがマイクロカー
    ネル・アーキテクチャ内の別のタスクとのプロセス間通
    信を要求するシステム。
  35. 【請求項３５】マイクロカーネル・アーキテクチャ・デ
    ータ処理システムにおけるプロセス間通信方法であっ
    て、 第２のタスクがデータを使用できるようにするメッセー
    ジを送信するためのメッセージ引渡しプロシージャ呼出
    しを含む、第１のタスク用のプログラムをメモリにロー
    ドするステップと、 第１のタスクと、送信データ・バッファと、伝送制御バ
    ッファとをメモリ内に形成するステップと、 伝送制御バッファを指すポインタを含む、第１のタスク
    用のヘッダ・テンプレートを形成するステップと、 プロセッサ内でプログラムからの命令を実行するため
    に、第１のタスクに関連するスレッドをメモリ内に形成
    するステップと、 プロセッサによりスレッド内の第１の命令を実行して、
    データ値を送信データ・バッファにロードし、制御値を
    伝送制御バッファにロードするステップと、 プロセッサによりスレッド内のプロシージャ呼出しを実
    行して、プロセス間通信サブシステムがヘッダ・テンプ
    レートを使用できるようにするステップと、 ヘッダ・テンプレートによって指し示される伝送制御バ
    ッファ内の制御値を使用して、プロセス間通信サブシス
    テムにより、送信データ・バッファから第２のタスクへ
    のデータ値の伝送を確立するステップとを含む方法。
  36. 【請求項３６】送信データ・バッファから受信側の第２
    のタスクに間接データ用のポインタを転送するステップ
    をさらに含むことを特徴とする、請求項３５に記載のプ
    ロセス間通信方法。
  37. 【請求項３７】プログラムがアプリケーション・プログ
    ラムであることを特徴とする、請求項３５に記載のプロ
    セス間通信方法。
  38. 【請求項３８】プログラムがオペレーティング・システ
    ム・パーソナリティ・プログラムであることを特徴とす
    る、請求項３５に記載のプロセス間通信方法。
  39. 【請求項３９】プログラムがパーソナリティ・ニュート
    ラル・サービス・プログラムであることを特徴とする、
    請求項３５に記載のプロセス間通信方法。
  40. 【請求項４０】プログラムがマイクロカーネル・プログ
    ラムの構成要素の１つであることを特徴とする、請求項
    ３５に記載のプロセス間通信方法。
  41. 【請求項４１】マイクロカーネル・アーキテクチャ・デ
    ータ処理システムにおけるプロセス間通信システムであ
    って、 データ処理システム内にあって、情報を格納するメモリ
    と、 前記メモリ内の第１のタスク用のプログラムであって、
    第２のタスクがデータを使用できるようにするメッセー
    ジを送信するためのメッセージ引渡しプロシージャ呼出
    しを含むプログラムと、 メモリ内の第１のタスク、送信データ・バッファ、およ
    び伝送制御バッファと、 伝送制御バッファを指すポインタを含む、第１のタスク
    用のヘッダ・テンプレートと、 第１のタスクのスレッドに関連するプロセッサ手段であ
    って、プログラムからの命令を実行するプロセッサ手段
    とを含み、 前記プロセッサ手段が、スレッド内の第１の命令を実行
    して、データ値を送信データ・バッファにロードし、制
    御値を伝送制御バッファにロードし、 前記プロセッサ手段が、スレッド内のプロシージャ呼出
    しを実行して、プロセス間通信サブシステムがヘッダ・
    テンプレートを使用できるようにし、 前記プロセス間通信サブシステムが、ヘッダ・テンプレ
    ートによって指し示される伝送制御バッファ内の制御値
    を使用して、送信データ・バッファから第２のタスクへ
    のデータ値の伝送を確立することを特徴とするシステ
    ム。
  42. 【請求項４２】前記プロセス間通信サブシステムが、送
    信データ・バッファから受信側の第２のタスクに間接デ
    ータ用のポインタを転送することをさらに含むことを特
    徴とする、請求項４１に記載のプロセス間通信システ
    ム。
  43. 【請求項４３】プログラムがアプリケーション・プログ
    ラムであることを特徴とする、請求項４１に記載のプロ
    セス間通信システム。
  44. 【請求項４４】プログラムがオペレーティング・システ
    ム・パーソナリティ・プログラムであることを特徴とす
    る、請求項４１に記載のプロセス間通信システム。
  45. 【請求項４５】プログラムがパーソナリティ・ニュート
    ラル・サービス・プログラムであることを特徴とする、
    請求項４１に記載のプロセス間通信システム。
  46. 【請求項４６】プログラムがマイクロカーネル・プログ
    ラムの構成要素の１つであることを特徴とする、請求項
    ４１に記載のプロセス間通信システム。
  47. 【請求項４７】マイクロカーネル・アーキテクチャ・デ
    ータ処理システムにおけるプロセス間通信システムであ
    って、 データ処理システム内にあって、情報を格納するメモリ
    手段と、 第２のタスクがデータを使用できるようにするメッセー
    ジを送信するためのメッセージ引渡しプロシージャ呼出
    しを含む、前記メモリ手段内の第１のタスク用のプログ
    ラムと、 前記メモリ手段内の第１のタスク、送信データ・バッフ
    ァ、および伝送制御バッファと、 前記伝送制御バッファを指すポインタを含む、前記第１
    のタスク用のヘッダ・テンプレートと、 データ処理システム内の前記メモリ手段に結合され、信
    号を転送するデータ・バス手段と、 前記データ・バス手段により前記メモリ手段に結合さ
    れ、前記第１のタスクのスレッドに関連し、前記プログ
    ラムからの命令を実行するプロセッサ手段とを含み、 前記プロセッサ手段が、スレッド内の第１の命令を実行
    して、データ値を前記送信データ・バッファにロード
    し、制御値を前記伝送制御バッファにロードし、 前記メモリ手段内にあって、メッセージ転送を管理する
    プロセス間通信サブシステムをさらに含み、 前記プロセッサ手段が、スレッドによりプロシージャ呼
    出しを実行して、前記プロセス間通信サブシステムが前
    記ヘッダ・テンプレートを使用できるようにし、 前記プロセス間通信サブシステムが、前記ヘッダ・テン
    プレートによって指し示される前記伝送制御バッファ内
    の制御値を使用して、前記送信データ・バッファから前
    記第２のタスクへのデータ値の伝送を確立することを特
    徴とするシステム。
  48. 【請求項４８】前記プログラムがアプリケーション・プ
    ログラムであることを特徴とする、請求項４７に記載の
    プロセス間通信システム。
  49. 【請求項４９】前記プログラムがオペレーティング・シ
    ステム・パーソナリティ・プログラムであることを特徴
    とする、請求項４７に記載のプロセス間通信システム。
  50. 【請求項５０】前記プログラムがパーソナリティ・ニュ
    ートラル・サービス・プログラムであることを特徴とす
    る、請求項４７に記載のプロセス間通信システム。
  51. 【請求項５１】前記プログラムがマイクロカーネル・プ
    ログラムの構成要素の１つであることを特徴とする、請
    求項４７に記載のプロセス間通信システム。
JP18180795A 1994-07-27 1995-07-18 マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置 Pending JPH0855035A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US28121794A 1994-07-27 1994-07-27
US281217 1994-07-27

Publications (1)

Publication Number Publication Date
JPH0855035A true JPH0855035A (ja) 1996-02-27

Family

ID=23076423

Family Applications (1)

Application Number Title Priority Date Filing Date
JP18180795A Pending JPH0855035A (ja) 1994-07-27 1995-07-18 マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置

Country Status (3)

Country Link
EP (1) EP0695993A2 (ja)
JP (1) JPH0855035A (ja)
CA (1) CA2149445A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09269925A (ja) * 1996-04-02 1997-10-14 Nri & Ncc Co Ltd 負荷制御を行う大規模クライアントサーバーシステム

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5913061A (en) * 1997-01-08 1999-06-15 Crossroads Software, Inc. Modular application collaboration
US6094688A (en) 1997-01-08 2000-07-25 Crossworlds Software, Inc. Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources
SG118081A1 (en) 2000-07-24 2006-01-27 Sony Corp Information processing method inter-task communication method and computer-excutable program for thesame
US8019901B2 (en) * 2000-09-29 2011-09-13 Alacritech, Inc. Intelligent network storage interface system
US6886041B2 (en) * 2001-10-05 2005-04-26 Bea Systems, Inc. System for application server messaging with multiple dispatch pools
US7003570B2 (en) 2001-10-05 2006-02-21 Bea Systems, Inc. System for integrating java servlets with asynchronous messages
DE10244459A1 (de) * 2002-09-24 2004-04-01 Siemens Ag Rechner- und/oder Software-Architektur unter Verwendung von Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik
US8224884B2 (en) 2007-07-06 2012-07-17 XMOS Ltd. Processor communication tokens
RU2568292C2 (ru) 2013-12-27 2015-11-20 Закрытое акционерное общество "Лаборатория Касперского" Система и способ выбора синхронного или асинхронного межпроцессного взаимодействия
US11392409B2 (en) 2017-06-28 2022-07-19 Apple Inc. Asynchronous kernel
CN110928700B (zh) * 2018-09-20 2023-04-07 北京君正集成电路股份有限公司 多进程通讯方法和装置
CN111427417B (zh) * 2020-03-19 2023-08-22 珠海豹趣科技有限公司 一种时间获取方法、装置及电子设备
CN111506442B (zh) * 2020-04-16 2023-05-09 艾普阳科技（深圳）有限公司 一种本地过程调用方法、装置、设备及介质
CN112463545A (zh) * 2020-12-22 2021-03-09 上海金卓科技有限公司 一种操作***的检测方法及装置
CN116244099B (zh) * 2023-05-11 2023-09-08 深圳比特微电子科技有限公司 嵌入式***内进程通讯方法、装置、电子设备和存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09269925A (ja) * 1996-04-02 1997-10-14 Nri & Ncc Co Ltd 負荷制御を行う大規模クライアントサーバーシステム

Also Published As

Publication number Publication date
CA2149445A1 (en) 1996-01-28
EP0695993A2 (en) 1996-02-07

Similar Documents

Publication Publication Date Title
EP0689693B1 (en) Object-oriented operating system
JP4791461B2 (ja) ランタイムシステムにおけるオブジェクトを共有するためのプログラム、方法、装置
JP4837660B2 (ja) ランタイムシステムにおけるオブジェクトを共有するためのプログラム、方法、装置
EP0700538B1 (en) Object-oriented host system
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
US7424704B2 (en) Object-oriented operating system
US5519867A (en) Object-oriented multitasking system
CA2443839C (en) System, method, and article of manufacture for using a replaceable component to select a replaceable quality of service capable network communication channel component
JP2007538325A (ja) ランタイムシステムの共有プログラム、方法、装置
JPH05216692A (ja) プログラム実行を管理する方法およびシステム
JPH0855035A (ja) マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置
JP2986073B2 (ja) プロセス間通信方法並びにプロセス間通信用のサブシステムおよびシステム
JP2888420B2 (ja) マルチタスク・アーキテクチャにおけるプロセス間通信方法
JPH0855037A (ja) プロセス間通信方法およびプロセス間通信用のシステム
JPH0822395A (ja) マイクロカーネル・アーキテクチャ・データ処理システムにおけるプロセス間通信方法およびシステム
Abrossimov et al. CHORUS, a New Technology for Building UNIX Systems
Qin A Study of Location-Transparent Load Sharing in Distributed Systems