JP2986073B2 - プロセス間通信方法並びにプロセス間通信用のサブシステムおよびシステム - Google Patents

プロセス間通信方法並びにプロセス間通信用のサブシステムおよびシステム

Info

Publication number
JP2986073B2
JP2986073B2 JP7153354A JP15335495A JP2986073B2 JP 2986073 B2 JP2986073 B2 JP 2986073B2 JP 7153354 A JP7153354 A JP 7153354A JP 15335495 A JP15335495 A JP 15335495A JP 2986073 B2 JP2986073 B2 JP 2986073B2
Authority
JP
Japan
Prior art keywords
task
port
memory
processor
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP7153354A
Other languages
English (en)
Other versions
JPH08106441A (ja
Inventor
ジェームス・マイケル・マジー
ガイ・ジル・ソトマイヤー・ジュニア
クリストファー・ディーン・ヤングワース
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JPH08106441A publication Critical patent/JPH08106441A/ja
Application granted granted Critical
Publication of JP2986073B2 publication Critical patent/JP2986073B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)
  • Electrotherapy Devices (AREA)

Description

【発明の詳細な説明】
【０００１】
【産業上の利用分野】本明細書に開示する本発明は、一
般にデータ処理システムに関し、より具体的にはデータ
処理システム用のオペレーティング・システムの改良に
関する。
【０００２】ここに開示する本発明は、本出願と同日に
出願され、本出願人に譲渡され、参照により本発明の一
部となる、ガイ・ジー・ソトマイヤー（Guy G. Sotomay
or）Jr.、ジェームス・エム・マジー（James M. Mage
e）、およびフリーマン・エル・ローソン（Freeman L.
Rawson）IIIによる"METHOD AND APPARATUS FOR MANAGEM
ENT OF MAPPED AND UNMAPPED REGIONS OF MEMORY IN A
MICROKERNEL DATA PROCESSING SYSTEM"という名称の関
連米国特許出願第２６３７１０号（ＩＢＭ整理番号BC9-
94-053）に関連するものである。
【０００３】
【従来の技術】オペレーティング・システムは、コンピ
ュータ上で実行される最も重要なソフトウェアである。
すべての汎用コンピュータは、他のプログラムを実行す
るためのオペレーティング・システムを備えていなけれ
ばならない。通常、オペレーティング・システムは、キ
ーボードからの入力の認識、表示画面への出力の送出、
ディスク上のファイルおよびディレクトリの追跡、ディ
スク・ドライブおよびプリンタなどの周辺装置の制御の
ような基本的なタスクを実行する。より複雑なシステム
では、オペレーティング・システムの責任と能力がかな
り大きくなる。それにより、同時に動作する様々なプロ
グラムやユーザが互いに干渉しないことが重要になる。
また、一般にオペレーティング・システムは、セキュリ
ティも担当し、無許可ユーザがシステムにアクセスでき
ないようにする。
【０００４】オペレーティング・システムは、マルチユ
ーザ・オペレーティング・システム、マルチプロセッサ
・オペレーティング・システム、マルチタスク・オペレ
ーティング・システム、およびリアルタイム・オペレー
ティング・システムに分類することができる。マルチユ
ーザ・オペレーティング・システムとは、２人またはそ
れ以上のユーザが同時にプログラムを実行できるように
するものである。オペレーティング・システムによって
は、数百人または数千人のユーザによる同時実行が可能
なものもある。マルチプロセッシング・プログラムと
は、単一ユーザが２つまたはそれ以上のプログラムを同
時に実行できるようにするものである。この場合、実行
される各プログラムはプロセスと呼ばれる。ほとんどの
マルチプロセッシング・システムは複数のユーザをサポ
ートしている。マルチタスク・システムとは、単一プロ
セスが複数のタスクを実行できるようにするものであ
る。マルチタスクとマルチプロセッシングという用語は
意味がいくらか異なるが、一般的な用法では交換可能な
ものとして使用される場合が多い。マルチタスクとは、
複数のタスクを同時に実行できる能力であり、タスクと
はプログラムである。マルチタスクでは、１つの中央演
算処理装置（ＣＰＵ）だけが関与するが、プログラム間
の切替えを非常に迅速に行うため、すべてのプログラム
を同時に実行しているように見えるのである。マルチタ
スクには、プリエンプティブと協調方式の２通りの基本
タイプがある。プリエンプティブ・マルチタスクでは、
オペレーティング・システムが各プログラムにＣＰＵの
タイム・スライスを分配する。協調マルチタスクでは、
各プログラムは、ＣＰＵを必要とする間、ＣＰＵを制御
することができる。ただし、プログラムがＣＰＵを使用
していない場合、別のプログラムが一時的にＣＰＵを使
用できるようにすることも可能である。たとえば、ＯＳ
／２（登録商標）およびＵＮＩＸ（登録商標）はプリエ
ンプティブ・マルチタスク・オペレーティング・システ
ムであるが、マッキントッシュ（登録商標）のコンピュ
ータ用のMulti-Finder（登録商標）は協調マルチタスク
・オペレーティング・システムである。マルチプロセッ
シングとは、コンピュータ・システムが複数のプロセス
またはプログラムを同時にサポートできる能力を指す。
したがって、マルチプロセッシング・オペレーティング
・システムを使用すると、同時に複数のプログラムを実
行することができる。マルチプロセッシング・システム
では、オペレーティング・システムが競合プロセスに資
源を合理的に割り振らなければならないので、単一プロ
セス・システムよりかなり複雑になる。リアルタイム・
オペレーティング・システムは、入力に対して瞬時に応
答する。ＤＯＳおよびＵＮＩＸ（登録商標）などの汎用
オペレーティング・システムはリアルタイムではない。
【０００５】オペレーティング・システムは、その上で
アプリケーション・プログラムを実行することができる
ソフトウェア・プラットフォームを提供する。アプリケ
ーション・プログラムは、特定のオペレーティング・シ
ステム上で実行するように明確に作成しなければならな
い。したがって、オペレーティング・システムの選択に
よって、実行可能なアプリケーションがほとんど決まっ
てしまう。ＩＢＭ互換のパーソナル・コンピュータ用の
オペレーティング・システムの例としては、ＤＯＳ、Ｏ
Ｓ／２（登録商標）、ＡＩＸ（登録商標）、ＸＥＮＩＸ
（登録商標）などがある。
【０００６】通常、ユーザは、１組のコマンドによって
オペレーティング・システムと対話する。たとえば、Ｄ
ＯＳオペレーティング・システムには、ファイルをコピ
ーするためのＣＯＰＹやファイル名を変更するためのＲ
ＥＮＡＭＥなどのコマンドが含まれている。これらのコ
マンドは、コマンド・プロセッサまたはコマンド・イン
タプリタと呼ばれるオペレーティング・システムの一部
によって受け入れられ、実行される。
【０００７】パーソナル・コンピュータ用としては、Ｃ
Ｐ／Ｍ（登録商標）、ＤＯＳ、ＯＳ／２（登録商標）、
ＵＮＩＸ（登録商標）、ＸＥＮＩＸ（登録商標）、ＡＩ
Ｘ（登録商標）など、様々なオペレーティング・システ
ムが数多く存在する。ＣＰ／Ｍは小型コンピュータ用の
最初のオペレーティング・システムの１つである。当
初、ＣＰ／Ｍは広範囲のパーソナル・コンピュータ上で
使用されていたが、結局、ＤＯＳによって影が薄くなっ
てしまった。ＤＯＳは、すべてのＩＢＭ互換パーソナル
・コンピュータ上で実行され、単一ユーザ単一タスク・
オペレーティング・システムである。ＤＯＳの後継オペ
レーティング・システムであるＯＳ／２は、Ｉｎｔｅｌ
８０２８６以降のマイクロプロセッサを使用するＩＢＭ
互換パーソナル・コンピュータ上で実行される比較的強
力なオペレーティング・システムである。一般に、ＯＳ
／２は、ＤＯＳとの互換性があるが、多くの追加機能を
含んでおり、たとえば、マルチタスクであり、仮想メモ
リをサポートしている。ＵＮＩＸおよびＵＮＩＸ対応Ａ
ＩＸは、広範囲のパーソナル・コンピュータおよびワー
クステーション上で動作する。ＵＮＩＸおよびＡＩＸ
は、すでにワークステーション用の標準オペレーティン
グ・システムになっており、強力なマルチユーザ・マル
チプロセッシング・オペレーティング・システムであ
る。
【０００８】ＩＢＭのパーソナル・コンピュータが米国
で発売された１９８１年に、ＤＯＳは約１０キロバイト
の記憶域を占有していた。その時以降、パーソナル・コ
ンピュータはますます複雑になり、大規模なオペレーテ
ィング・システムを必要とするようになった。現在で
は、たとえば、ＩＢＭのパーソナル・コンピュータ用の
ＯＳ／２は、２２メガバイトもの記憶域を占有する場合
もある。時間の経過とともにパーソナル・コンピュータ
はさらに複雑かつ強力になっているが、システムに関連
する記憶装置に記憶容量の点で多大なペナルティを課さ
ずにオペレーティング・システムが引き続きサイズと複
雑さを拡大することができないことは明らかである。
【０００９】１９８０年代にカーネギー・メロン大学で
ＭＡＣＨプロジェクトが行われたのは、オペレーティン
グ・システムのサイズの成長率がこのように維持できな
くなったためである。この研究の目標は、コンピュータ
・プログラマが最新のハードウェア・アーキテクチャの
出現を利用しながら、カーネル・オペレーティング・シ
ステムの諸機能のサイズと数を低減できるような、新し
いオペレーティング・システムを開発することであっ
た。カーネルとは、ハードウェア資源の割振りなどの基
本機能を実行するオペレーティング・システムの一部で
ある。ＭＡＣＨカーネルの場合、システム用の基本ビル
ディング・ブロックとして、５つのプログラミング・ア
ブストラクションが確立された。これらは、その上で典
型的な複合操作をカーネル外部に構築することができる
有用なシステムを作成するのに必要な最小限のものとし
て選択された。カーネギー・メロンのＭＡＣＨカーネル
は、そのリリース３．０でサイズが低減され、ＭＡＣＨ
マイクロカーネルという完全機能オペレーティング・シ
ステムになっている。ＭＡＣＨマイクロカーネルは、タ
スク、スレッド、ポート、メッセージ、およびメモリ・
オブジェクトという基本要素を有する。
【００１０】タスクは、ＭＡＣＨマイクロカーネル内の
２つの個別構成要素に分割された従来のＵＮＩＸプロセ
スである。第１の構成要素はタスクであり、第１群の協
調エンティティ用のすべての資源を含んでいる。タスク
内の資源の例は、仮想メモリと通信ポートである。タス
クは、資源の受動的集合体なので、プロセッサ上では動
作しない。
【００１１】スレッドは、ＵＮＩＸプロセスの第２の構
成要素であり、能動的実行環境である。各タスクは、ス
レッドと呼ばれる１つまたは複数の同時実行計算をサポ
ートすることができる。たとえば、マルチスレッド・プ
ログラムでは、１つのスレッドを使用して科学計算を実
行し、別のスレッドでユーザ・インタフェースを監視す
ることができる。１つのＭＡＣＨタスクが、すべて同時
に実行される数多くの実行スレッドを有する場合もあ
る。ＭＡＣＨプログラミング・モデルの能力の多くは、
１つのタスク内のすべてのスレッドがそのタスクの資源
を共用するという事実に由来する。たとえば、すべての
スレッドは同一の仮想メモリ（ＶＭ）アドレス空間を有
する。しかし、タスク内の各スレッドはそれ専用の私用
実行状態を有する。この状態は、汎用レジスタなどの１
組のレジスタと、スタック・ポインタと、プログラム・
カウンタと、フレーム・ポインタとで構成される。
【００１２】ポートは、スレッド同士が互いに通信する
際に使用する通信チャネルである。ポートは１つの資源
であり、タスクによって所有される。スレッドは、タス
クに属すことによってポートへのアクセスが可能にな
る。協調プログラムを使用すると、１つのタスクからの
スレッドが別のタスクのポートにアクセスできる場合も
ある。重要な特徴は、それらがロケーション透過性であ
る点である。この機能により、プログラムを修正せずに
ネットワークによるサービスの分散が容易になる。
【００１３】メッセージは、各種のタスク内のスレッド
が互いに通信できるようにするためのものである。１つ
のメッセージには、クラスまたはタイプが与えられたデ
ータの集合体が含まれている。このデータは、数値また
はストリングなどのプログラム固有データから、あるタ
スクから別のタスクへのポートの転送能力などのＭＡＣ
Ｈ関連データにまで及ぶ可能性がある。
【００１４】メモリ・オブジェクトは、ユーザ・レベル
のプログラムに含まれる従来のオペレーティング・シス
テム機能を実行する能力をサポートするためのアブスト
ラクションであり、ＭＡＣＨマイクロカーネルの重要な
特徴の１つである。たとえば、ＭＡＣＨマイクロカーネ
ルは、ユーザ・レベル・プログラム内の仮想メモリ・ペ
ージング方式をサポートしている。メモリ・オブジェク
トとは、この能力をサポートするためのアブストラクシ
ョンである。
【００１５】上記の各種概念はいずれもＭＡＣＨマイク
ロカーネルのプログラミング・モデルにとって基本的な
ものであり、カーネル自体で使用されるものである。カ
ーネギー・メロン大学のＭＡＣＨマイクロカーネルの上
記の概念およびその他の特徴については、ジョーゼフ・
ボイキン（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）がある。
【００１７】ガイ・ジー・ソトマイヤー他による前述の
関連特許出願には、図１に示すマイクロカーネル・シス
テム１１５が記載されているが、これはオペレーティン
グ・システムの新しい基礎である。マイクロカーネル・
システム１１５は、純粋カーネルとして実施されたカー
ネル・サービスの簡略セットと、１組のユーザレベル・
サーバとして実施されたオペレーティング・システム・
パーソナリティを構築するためのサービスの拡張セット
とを提供する。マイクロカーネル・システム１１５は、
様々な従来のオペレーティング・システム機能を提供
し、オペレーティング・システム・パーソナリティとし
て明示された、多くのサーバ構成要素で構成されてい
る。マイクロカーネル・システム１１５では、タスク
（クライアント）が通信チャネルを介して送られるメッ
セージによって他のタスク（サーバ）の要求を行うこと
によりサービスにアクセスする、クライアント／サーバ
・システム構造を使用する。マイクロカーネル１２０が
提供するそれ専用のサービスは非常に少ない（たとえ
ば、ファイル・サービスは一切提供しない）ので、マイ
クロカーネル１２０のタスクは、必要なサービスを提供
する他の多くのタスクと通信しなければならない。この
ため、システム内の多くのクライアントとサーバとの間
で行わなければならないプロセス間通信をいかに高速か
つ効率よく管理するかについて問題が発生する。
【００１８】
【発明が解決しようとする課題】したがって、本発明の
一目的は、データ処理システム用の改良されたマイクロ
カーネル・アーキテクチャを提供することにある。
【００１９】本発明の他の目的は、先行技術で可能だっ
たものに比べ、そのプロセス間通信操作がさらに簡略化
された、データ処理システム用の改良されたマイクロカ
ーネル・アーキテクチャを提供することにある。
【００２０】本発明の他の目的は、より高速でより効率
の良いプロセス間通信機能を有する、データ処理システ
ム用の改良されたマイクロカーネル・アーキテクチャを
提供することにある。
【００２１】本発明の他の目的は、共用メモリ環境内の
タスク間および共通メモリを共用しない分散データ・プ
ロセッサ間でのメッセージの交換においてより高度のフ
レキシビリティを有する、データ処理システム用の改良
されたマイクロカーネル・アーキテクチャを提供するこ
とにある。
【００２２】
【課題を解決するための手段】上記およびその他の目
的、特徴、および利点は、本明細書に開示されたマイク
ロカーネル・データ処理システム用のケイパビリティ・
エンジンの方法および装置によって達成される。
【００２３】マイクロカーネル・アーキテクチャ・デー
タ処理システムにおけるプロセス間通信用の方法および
装置を開示する。このデータ処理システムは、共用メモ
リ・マルチプロセッシング・システムの場合もあれば、
ユニプロセッサ・システムの場合もある。マイクロカー
ネル・オペレーティング・システムは、データ処理シス
テムのメモリにロードされる。本発明によれば、マイク
ロカーネルは、メモリの各種領域をマッピングするため
のケイパビリティまたは権利を管理するケイパビリティ
・エンジン・モジュールを含んでいる。第１のタスク・
コンテナは、マイクロカーネルによってメモリ内に形成
され、第１の通信ポートと第１組のポート権とを定義す
る１組の属性を有し、メモリ・オブジェクトを指すポイ
ンタを有し、第１組のポート権は、メモリ・オブジェク
トにアクセスするケイパビリティを第１のタスク・コン
テナに授与する。第２のタスク・コンテナは、メモリ内
に形成され、第２の通信ポートと第２組のポート権とを
定義する１組の属性を有する。
【００２４】本発明によれば、ケイパビリティ・エンジ
ンは、第１のタスク・コンテナ用の第１組のポート権
と、第２のタスク・コンテナ用の第２組のポート権とを
登録する。次に、ケイパビリティ・エンジンは、第１組
のポート権と第２組のポート権とを比較して、第２のタ
スクがメモリ・オブジェクトへのアクセスの獲得を許可
されるかどうかを判定する。タスク・ポートの属性にな
りうるポート権は広範囲におよび、各種許可レベル、セ
キュリティ・レベル、優先順位レベル、プロセッサおよ
びその他の資源の可用性など、数多くのものがあり、ユ
ーザの想像力によってのみ制限される。ケイパビリティ
・エンジンは、これらの権利を分析し、第１のタスク・
コンテナから第２のタスク・コンテナへのポインタと第
１のポート権との転送を選択的に可能にし、メモリ・オ
ブジェクトにアクセスするケイパビリティを第２のタス
ク・コンテナに授与することができる。このようにし
て、ケイパビリティ・エンジンは、マイクロカーネル・
システム内の多くのクライアントとサーバとの間で行わ
なければならないプロセス間通信を高速かつ効率よく管
理する。
【００２５】本発明は、ユニプロセッサ、共用メモリ・
マルチプロセッサ、および分散プロセッサ・システム内
の複数のコンピュータに適用される。
【００２６】上記およびその他の目的および利点は、添
付図面を参照すればさらに十分理解されるはずである。
【００２７】
【実施例】
第Ａ部 マイクロカーネル・システム 第１節 マイクロカーネルの原理 図１は、マイクロカーネル・システム１１５の機能ブロ
ック図であり、マイクロカーネル１２０およびパーソナ
リティ・ニュートラル・サービス１４０が様々なハード
ウェア・プラットフォームで複数のオペレーティング・
システム・パーソナリティ１５０を実行する方法を示す
図である。
【００２８】図１に示すホスト・マルチプロセッサ１０
０は、バス１０４によって補助記憶装置１０６に接続さ
れたメモリ１０２を含み、補助記憶装置１０６は、たと
えば、ディスク・ドライブの場合もあれば、読取り専用
または読取り書込み光ディスク記憶装置、またはその他
の大容量記憶装置の場合もある。バス１０４には入出力
アダプタ１０８も接続され、入出力アダプタ１０８は、
キーボード、モニタ・ディスプレイ、通信アダプタ、ロ
ーカル・エリア・ネットワーク・アダプタ、モデム、マ
ルチメディア・インタフェース装置、またはその他の入
出力装置に接続することもできる。また、バス１０４に
は、第１のプロセッサＡ１１０と第２のプロセッサＢ１
１２も接続されている。図１に示す例は、対称的なマル
チプロセッサ構成の例であり、２つのユニプロセッサ１
１０および１１２が共通メモリ・アドレス空間１０２を
共用している。同様に適切な例として、単一プロセッサ
または複数プロセッサによる他の構成を示すことも可能
である。プロセッサは、たとえば、Ｉｎｔｅｌ３８６
（登録商標）ＣＰＵ、Ｉｎｔｅｌ４８６（登録商標）Ｃ
ＰＵ、Ｐｅｎｔｉｕｍ（登録商標）プロセッサ、Ｐｏｗ
ｅｒＰＣ（登録商標）プロセッサ、またはその他のユニ
プロセッサ・デバイスにすることができる。
【００２９】メモリ１０２はそこに格納されたマイクロ
カーネル・システム１１５を含み、マイクロカーネル・
システム１１５は、マイクロカーネル１２０と、パーソ
ナリティ・ニュートラル・サービス（ＰＮＳ）１４０
と、パーソナリティ・サーバ１５０とを含んでいる。マ
イクロカーネル・システム１１５は、メモリ１０２に格
納されているアプリケーション・プログラム１８０用の
オペレーティング・システムとして機能する。
【００３０】本発明の一目的は、ＵＮＩＸまたはＯＳ／
２のような従来のオペレーティング・システムのように
動作するオペレーティング・システムを提供することに
ある。すなわち、このオペレーティング・システムは、
ＯＳ／２またはＵＮＩＸ、あるいはその他の従来のオペ
レーティング・システムのパーソナリティを有するもの
になる。
【００３１】マイクロカーネル１２０には、ホスト・マ
ルチプロセッサ１００の最優先状態で実行されるシステ
ム・ソフトウェアの一部であってマシンの基本動作を制
御する小さいメッセージ引渡し核が収容されている。マ
イクロカーネル・システム１１５は、マイクロカーネル
１２０と、パーソナリティ・ニュートラル・サービス１
４０を提供する１組のサーバおよびデバイス・ドライバ
とを含んでいる。名前が示唆するように、パーソナリテ
ィ中立サーバおよびデバイス・ドライバは、ＵＮＩＸま
たはＯＳ／２のようないかなるパーソナリティにも依存
していない。これらはマイクロカーネル１２０に依存
し、相互に依存する。パーソナリティ・サーバ１５０
は、マイクロカーネル１２０のメッセージ引渡しサービ
スを使用してパーソナリティ・ニュートラル・サービス
１４０とやりとりする。たとえば、ＵＮＩＸ、ＯＳ／
２、または他のパーソナリティ・サーバは、パーソナリ
ティ中立ディスク・ドライバにメッセージを送信し、１
ブロック分のデータをディスクから読み取るようそれに
指示することができる。ディスク・ドライバはそのブロ
ックを読み取って、それをメッセージに入れて返す。メ
ッセージ・システムは、ポインタを操作することによっ
て大量のデータが迅速に転送されるように最適化されて
いるので、データそのものはコピーされない。
【００３２】マイクロカーネル１２０は、そのサイズ
と、アプリケーション・プログラムとして標準的なプロ
グラミング・サービスおよび機能をサポートできる能力
とにより、標準的なオペレーティング・システムより単
純になっている。マイクロカーネル・システム１１５
は、様々に構成される複数のモジュールに分解され、小
規模なシステムにそのモジュールを追加することによっ
てより大規模なシステムを構築できるようになってい
る。たとえば、各パーソナリティ中立サーバ１４０は、
論理的には別個のものなので、様々な構成が可能であ
る。各サーバは、アプリケーション・プログラムとして
動作し、アプリケーション・デバッガを使用してデバッ
グすることができる。また、各サーバは個別のタスクで
動作し、サーバのエラーはそのタスクに閉じ込められ
る。
【００３３】図１は、プロセス間通信モジュール（ＩＰ
Ｃ）１２２と、仮想メモリ・モジュール１２４と、タス
クおよびスレッド・モジュール１２６と、ホストおよび
プロセッサ・セット１２８と、入出力サポートおよび割
込み１３０と、マシン依存コード１２５とを含むマイク
ロカーネル１２０を示している。
【００３４】図１に示すパーソナリティ・ニュートラル
・サービス１４０は、マスタ・サーバと、初期設定と、
命名とを含む、複数パーソナリティ・サポート１４２を
含んでいる。サービス１４０はデフォルト・ページャ１
４４も含んでいる。また、サービス１４０は、複数パー
ソナリティ・サポートとデバイス・ドライバとを含む、
デバイス・サポート１４６も含んでいる。さらに、サー
ビス１４０は、ファイル・サーバと、ネットワーク・サ
ービスと、データベース・エンジンと、セキュリティと
を含む、その他のパーソナリティ中立プロダクト１４８
も含んでいる。
【００３５】パーソナリティ・サーバ１５０は、たとえ
ば、ＵＮＩＸパーソナリティなどにすることが可能な主
要パーソナリティ１５２である。このサーバは、ＵＮＩ
Ｘサーバであるはずの主要パーソナリティ・サーバ１５
４と、ＵＮＩＸ主要パーソナリティをサポートするはず
の他の主要パーソナリティ・サービス１５５とを含んで
いる。また、代替主要パーソナリティ１５６は、ＯＳ／
２などにすることができる。この代替パーソナリティ１
５６には、ＯＳ／２パーソナリティの特徴となるはずの
代替パーソナリティ・サーバ１５８と、ＯＳ／２用の他
の代替パーソナリティ・サービス１５９とが含まれてい
る。
【００３６】ＵＮＩＸ主要パーソナリティの例に関連し
て図１に示されている主要パーソナリティ・アプリケー
ション１８２は、ＵＮＩＸオペレーティング・システム
・パーソナリティ１５２上で動作するはずのＵＮＩＸタ
イプのアプリケーションである。図１に示す代替パーソ
ナリティ・アプリケーション１８６は、ＯＳ／２代替パ
ーソナリティ・オペレーティング・システム１５６上で
動作するＯＳ／２アプリケーションである。
【００３７】図１は、マイクロカーネル・システム１１
５によって、その実施態様が、プロセッサ・タイプごと
に完全に移植可能なコードと、それが実行される特定の
マシンのプロセッサのタイプに依存するコードとに慎重
に分割されていることを示している。また、このシステ
ムは、デバイスに依存するコードをデバイス・ドライバ
に分離しているが、デバイス・ドライバ・コードは、デ
バイスに依存しているものの、必ずしもプロセッサ・ア
ーキテクチャに依存しているわけではない。タスク当た
り複数のスレッドを使用すると、特定のマシンをマルチ
プロセッサにせずにマルチプロセッサの使用が可能にな
るようなアプリケーション環境が提供される。ユニプロ
セッサでは、各種のスレッドが様々な時期に実行され
る。複数プロセッサに必要なすべてのサポートがこの小
さく単純なマイクロカーネル１２０に凝集されている。
【００３８】この項では、マイクロカーネル・システム
１１５の構造の概要を示す。以降では、この構造の各構
成要素について詳しく説明し、マイクロカーネル・シス
テム１１５の各種サービスを使用して新しいプログラム
を構築するのに必要な技術について説明する。
【００３９】マイクロカーネル・システム１１５は、オ
ペレーティング・システム用の新しい基礎である。これ
は、オペレーティング・システム開発のための総合環境
に以下の特徴を提供するものである。 複数パーソナリティのサポート 拡張可能なメモリ管理 プロセス間通信 マルチスレッド マルチプロセッシング
【００４０】マイクロカーネル・システム１１５は、純
粋カーネルとして実施されたカーネル・サービスの簡略
セットと、１組のユーザレベル・サーバとして実施され
た、オペレーティング・システム・パーソナリティ構築
用のサービスの拡張セットとを提供する。
【００４１】マイクロカーネル・システム１１５の目的
には、以下のことが含まれる。複数のオペレーティング
・システム・パーソナリティが協調して機能できるよう
にすること デバイス・ドライバおよびファイル・システムなどの低
レベル・システム要素用の共通プログラミングを提供す
ること オペレーティング・システムとユーザ・アプリケーショ
ンの両方で並行処理を利用すること 散在している可能性のある大きいアドレス空間をフレキ
シブルなメモリ共用でサポートすること 透過ネットワーク資源アクセスを可能にすること ＯＳ／２およびＵＮＩＸなどの既存のソフトウェア環境
との互換性を維持すること 移植性（３２ビットおよび６４ビット・プラットフォー
ムへの）
【００４２】マイクロカーネル・システム１１５は、以
下の概念を基礎とする。多くの従来のオペレーティング
・システム機能（たとえば、ファイル・システムおよび
ネットワーク・アクセス）を実行するユーザ・モード・
タスク オペレーティング・システムを作成するためのユーザレ
ベルの実行時サービスの基本セット 単純かつ拡張可能な通信カーネル オブジェクト参照としての通信チャネルを備えたオブジ
ェクト基盤 同期および非同期プロセス間通信を使用するクライアン
ト／サーバ・プログラミング・モデル
【００４３】マイクロカーネル・システム１１５の基礎
は、単純かつ拡張可能な通信カーネルを提供することで
ある。また、マイクロカーネル・システム１１５の目的
の１つは、適正カーネルの最小限の機能によりユーザ空
間またはカーネル空間のいずれかでサービスのフレキシ
ブルな構成を可能にすることである。カーネルは、タス
ク間通信の他に、以下のものを含むサポートを提供しな
ければならない。 制御点の管理（スレッド） 資源割当て（タスク） タスク用のアドレス空間のサポート 物理メモリ、プロセッサ、割込み、ＤＭＡチャネル、ク
ロックなどの物理資源の管理
【００４４】ユーザ・モード・タスクは、資源の使用法
に関する各種方針を実現する。カーネルは、このような
方針を実施するための機構を提供するにすぎない。論理
的には、カーネルの上にパーソナリティ・ニュートラル
・サービス１４０（ＰＮＳ）層が存在する。ＰＮＳは、
ストリング機能などの基本構造体を含むＣ実行時環境
と、以下のものを含む１組のサーバとを提供する。 名前サーバ ― クライアントがサーバを見つけられる
ようにする マスタ・サーバ ― プログラムのロードおよび始動を
可能にする
【００４５】カーネル・アブストラクション マイクロカーネル・システム１１５の目標の１つは、カ
ーネル自体によって提供されるアブストラクションを最
小限にすることであって、このようなアブストラクショ
ンに関連するセマンティクスの点で最小にすることでは
ない。提供されるアブストラクションのそれぞれは、そ
れに関連する１組のセマンティクスと、残りのアブスト
ラクションとの対話の複合セットとを有する。このた
め、重要な考え方の識別が困難になる場合もある。主な
カーネル・アブストラクションは、以下の通りである。 タスク ― 資源割振り、大きいアクセス空間、および
ポート権の単位 スレッド ― 軽量（低オーバヘッド）のＣＰＵ使用状
況の単位 ポート ― 送信／受信ケイパビリティまたは権利によ
ってのみアクセス可能な通信チャネル メッセージ ― データ・オブジェクトの集合 メモリ・オブジェクト ― メモリ管理の内部単位 （タスク、スレッド、ポート、メッセージ、およびメモ
リ・オブジェクトの各概念の詳細については、第２節
「アーキテクチャ・モデル」を参照されたい。）
【００４６】タスクおよびスレッド マイクロカーネル・システム１１５は、従来のプロセス
の概念を提供するわけではない。というのは、すべての
オペレーティング・システム環境がプロセスに関連する
相当なセマンティクス（ユーザＩＤ、信号状態など）を
有するからである。これらの拡張セマンティクスを理解
したり提供することは、マイクロカーネルの目的ではな
い。
【００４７】多くのシステムはプロセスと制御の実行点
とを同一視しているが、システムによっては同一視して
いないものもある。
【００４８】マイクロカーネル１２０は、オペレーティ
ング・システム環境のプロセスとは別個に複数の制御点
をサポートする。マイクロカーネルは、以下の２通りの
概念を提供する。 タスク スレッド （タスクおよびスレッドの各概念の詳細については、第
２節「アーキテクチャ・モデル」を参照されたい。）
【００４９】メモリ管理 カーネルは何らかのメモリ管理を提供する。メモリはタ
スクに関連付けられている。メモリ・オブジェクトは、
タスクがメモリ管理を制御する際の手段である。マイク
ロカーネル・システム１１５は、散在している可能性の
ある大きい仮想アドレス空間をサポートするための各種
機構を提供する。それぞれのタスクは、カーネルによっ
て管理される関連のアドレス・マップを有し、そのタス
クのアドレス空間の仮想アドレスを物理アドレスに変換
する処理を制御する。仮想メモリ・システムの場合のよ
うに、所与のタスクのアドレス空間全体の内容は、物理
メモリに同時に完全に常駐するわけではなく、タスクの
仮想アドレス空間用のキャッシュとして物理メモリを使
用するための諸機構が存在していなければならない。従
来の仮想メモリ設計とは異なり、マイクロカーネル・シ
ステム１１５はキャッシュそのものをすべて実現するわ
けではない。これは、このような諸機構に関与できる能
力をユーザ・モード・タスクに与えるものである。ＰＮ
Ｓは、メモリ用のページング・サービスを提供するデフ
ォルト・ページャ１４４というユーザ・タスクを含んで
いる。
【００５０】マイクロカーネル・システム１１５の他の
資源とは異なり、仮想メモリはポートを使用して参照さ
れるわけではない。メモリは、特定のタスクのアドレス
空間内の索引として仮想アドレスを使用することによっ
てのみ、参照することができる。メモリと、タスクのア
ドレス空間を定義する関連のアドレス・マップは、部分
的に他のタスクと共用することができる。タスクは、そ
のアドレス空間内の新しいメモリ範囲を割り振り、その
割振りを解除し、その範囲に対する保護を変更すること
ができる。また、タスクは、その範囲の継承特性を指定
することもできる。新しいタスクは、その新しいタスク
用のアドレス空間を構築するためのベースとして既存の
タスクを指定することによって作成される。既存のタス
クの各メモリ範囲の継承属性によって、新しいタスクの
範囲が定義されているかどうか、ならびにその範囲が実
質的にコピーされているのかまたは既存のタスクと共用
されているのかが決まる。メモリに関する仮想コピー操
作のほとんどは、コピー・オン・ライト最適化によって
達成される。コピー・オン・ライト最適化は保護共用に
よって達成される。２つのタスクはコピー対象のメモリ
を共用するが、読取り専用アクセスの場合に限られる。
いずれかのタスクが範囲の一部を修正しようと試みる
と、その時点でその部分がコピーされる。このメモリ・
コピーの遅延評価は、マイクロカーネル・システム１１
５によって行われる重要なパフォーマンス最適化の１つ
であり、システムの通信／メモリ原理にとって重要なも
のである。
【００５１】所与のメモリ領域はメモリ・オブジェクト
によって支援される。メモリ・マネージャ・タスクは、
メモリにキャッシュされている間の一連のページのイメ
ージ（あるメモリ領域の物理メモリ内容）とキャッシュ
されていないときのその一連のページのイメージ（アブ
ストラクション・メモリ・オブジェクト）との関係を管
理する方針を提供する。ＰＮＳには、始めはゼロが充填
されて、システム・ページング空間と照らし合わせてペ
ージングされる基本的な非持続性メモリ・オブジェクト
を提供する、デフォルトのメモリ・マネージャまたはペ
ージャが用意されている。
【００５２】タスク間通信 マイクロカーネル・システム１１５は、通信チャネルを
介して送られるメッセージによって他のタスク（サー
バ）を要求することによってタスク（クライアント）が
サービスにアクセスする、クライアント／サーバ・シス
テム構造を使用する。マイクロカーネル１２０が提供す
るそれ専用のサービスは非常に少ない（たとえば、ファ
イル・サービスは一切提供しない）ので、マイクロカー
ネル１２０のタスクは、必要なサービスを提供する他の
数多くのタスクとやりとりしなければならない。プロセ
ス間通信（ＩＰＣ）機構の通信チャネルはポートと呼ば
れる。（ポートの詳細については、第２節「アーキテク
チャ・モデル」を参照されたい。）メッセージは、デー
タ、メモリ領域、およびポート権の集合である。ポート
権は、その権利を保有するタスクがそのポートを命名す
る際の名前である。ポートは、適切なポート権を保有す
る場合のみ、ポートを操作することができる。あるポー
トの受信権を保有できるのは１つのタスクに限られる。
このタスクは、ポート待ち行列からメッセージを受け取
る（読み取る）ことができる。複数のタスクはそのポー
トへの送信権を保有することができ、その送信権により
複数のタスクがメッセージを待ち行列に送信する（書き
込む）ことが可能になる。タスクは、１組のデータ要素
を収容するデータ構造を構築し、次に、保有する送信権
の対象となるポート上でメッセージ送信操作を実行する
ことによって、別のタスクとやりとりする。その後、そ
のポートへの受信権を保有するタスクがメッセージ受信
操作を実行する。ただし、このメッセージ転送は非同期
動作であることに留意されたい。メッセージは（おそら
くコピー・オン・ライト最適化により）受信タスクに論
理的にコピーされる。受信タスク内の複数のスレッド
は、所与のポートからのメッセージ受信を試みることが
できるが、所与のメッセージを受け取るのは１つのスレ
ッドに限られる。
【００５３】第２節 アーキテクチャ・モデル マイクロカーネル・システム１１５は、その主要責任と
して、フレームワーク内で命令を実行する制御点を用意
している。このような制御点はスレッドと呼ばれる。ス
レッドは仮想環境で実行される。カーネルによって提供
される仮想環境には、カーネルによって提供されるユー
ザ空間ＰＮＳおよびエミュレートされた命令（システム
・トラップ）分だけ増加した、ユーザ空間がアクセス可
能なハードウェア命令をすべて実行する仮想プロセッサ
が含まれる。この仮想プロセッサは、１組の仮想化レジ
スタと、本来ならマシンの物理メモリと同様の応答を行
う何らかの仮想メモリとにアクセスする。他のハードウ
ェア資源はいずれも、メモリ・アクセスとエミュレート
された命令との特別な組合せによってのみアクセスでき
る。ただし、カーネルによって提供されるすべての資源
が仮想化されていることに留意されたい。この項では、
スレッドから見た場合の仮想環境の最上位レベルの要素
について説明する。
【００５４】パーソナリティ・ニュートラル・サービス
（ＰＮＳ）の要素 マイクロカーネル・システム１１５のＰＮＳ１４０部分
は、基礎となるマイクロカーネル１２０上に構築された
各種サービスで構成されている。この部分は、カーネル
自体が依存している一部の機能ならびにプログラムの構
築用のユーザレベル・サービスの基本セットを提供す
る。これらのプログラムは、複数のオペレーティング・
システム・パーソナリティ・クライアントからの要求に
対応することができ、オペレーティング・システム・パ
ーソナリティそのものを構築するために使用される。さ
らに、標準的なＣで作成されたＰＮＳプログラムを構築
するためのＡＮＳＩ（米国規格協会）Ｃ実行時環境と、
ＰＯＳＩＸ（Portable Operating System Interface Fo
r Computer Environmetsの略）規格から取られた定義を
有するいくつかの補足機能とが存在する。ＰＮＳそのも
のを定義するライブラリの他に、適正マイクロカーネル
の一部である多くのライブラリがＰＮＳ内に存在する。
このようなライブラリは、マイクロカーネルがエクスポ
ートするインタフェースと、マイクロカーネル・システ
ム１１５のプロセス間通信機能とともに使用されるメッ
セージ・インタフェース・ジェネレータ（ＭＩＧ）用の
サポート論理とを表す。
【００５５】ＰＮＳ環境ライブラリの構造は、各サービ
スの実現内容の詳細をその呼出し側から隠蔽する。Ｃ実
行時ライブラリの１つのような一部のライブラリは、そ
の機能のすべてを呼出し側のアドレス空間にロードされ
るローカル・ルーチンとして実現するが、他のライブラ
リは、マイクロカーネルのＩＰＣシステムを呼び出して
サーバにメッセージを送信するスタブで構成されてい
る。このアーキテクチャにより、フレキシブルな機能実
現が可能になる。すなわち、サーバを他のサーバで置き
換えることができ、それを使用するプログラムのソース
に影響せずに複数のサービスを単一タスクに結合するこ
とができる。ＰＮＳ環境の重要要素は、それが完全なオ
ペレーティング・システムを構成しないという点であ
る。むしろ、ＰＮＳはパーソナリティの存在に依存す
る。システム・スタートアップ時に最初にロードされる
主要パーソナリティ１５２は、システム上にユーザ・イ
ンタフェースを提供し、そのクライアントとＰＮＳの諸
要素にサービスを提供する、オペレーティング・システ
ム・パーソナリティである。したがって、主要パーソナ
リティは「最後の手段」のサーバになる。主要パーソナ
リティは、ＰＮＳライブラリによって定義されている
が、別のサーバによって実現されないサービスをすべて
実現する。
【００５６】マイクロカーネル１２０は、ＰＮＳの一部
の要素にも依存する。このような場合としては、内部カ
ーネル動作を完了するためにパーソナリティ中立サーバ
にメッセージを送信する場合がある。たとえば、ページ
・フォルトを解決する際にマイクロカーネル１２０は、
デフォルト・ページャ１４４にメッセージを送信するこ
とができる。その場合、デフォルト・ページャ１４４
は、カーネルがハード・ディスクから要求しているペー
ジを読み込む。通常、ページ・フォルトはユーザ・タス
クのために解決されるが、カーネルはメッセージの送信
側になる。
【００５７】実行時 ＰＮＳ実行時は、その環境で実行されるプログラム用の
標準的なＣプログラミング環境をサポートするために使
用される１組のＡＮＳＩ ＣおよびＰＯＳＩＸライブラ
リを提供する。これらの機能は、典型的なＣ言語構造体
を含んでいる。すべてのシステムと同様、マイクロカー
ネル・システム１１５は、その主要責任として、フレー
ムワーク内で命令を実行する制御点を用意する。マイク
ロカーネル１２０では、制御点はスレッドと呼ばれてい
る。スレッドは仮想環境で実行される。マイクロカーネ
ル１２０によって提供される仮想環境は、カーネルによ
って提供されるエミュレートされた命令（システム・ト
ラップ）分だけ増加した、ユーザ空間がアクセス可能な
ハードウェア命令をすべて実行する仮想プロセッサで構
成される。この仮想プロセッサは、１組の仮想化レジス
タと、本来ならマシンの物理メモリと同様の応答を行う
何らかの仮想メモリとにアクセスする。他のハードウェ
ア資源はいずれも、メモリ・アクセスとエミュレートさ
れた命令との特別な組合せによってのみアクセスでき
る。ただし、マイクロカーネルによって提供されるすべ
ての資源が仮想化されていることに留意されたい。この
項では、マイクロカーネル・スレッドから見た仮想環境
の最上位レベルの要素について説明する。
【００５８】カーネルの要素 マイクロカーネル１２０は、以下のカーネル要素のリス
トに記載された各種要素で構成された環境を提供する。 スレッド： 制御の実行点。スレッドは軽量エンティテ
ィである。スレッドに関連する状態の多くは、その収容
タスクに関連付けられている。 タスク： ポート名空間、仮想アドレス空間、および１
組のスレッドの形式で資源に対する参照を保管するため
の容器。 セキュリティ・トークン： タスクから、アクセス妥当
性検査を実行するサーバに渡されるセキュリティ機能。 ポート： タスク間の単一方向通信チャネル。 ポート・セット： メッセージを受け取るときに単一ユ
ニットとして扱うことができる１組のポート。 ポート権： ポートにアクセスするための具体的な権利
を許可するもの。 ポート名空間： 特定のポート権を命名するためのポー
ト名の索引付き集合。 メッセージ： ２つのタスク間で渡されるデータ、メモ
リ領域、およびポート権の集合。 メッセージ待ち行列： 単一ポートに関連するメッセー
ジの待ち行列。 仮想アドレス空間： タスク内のスレッドによって参照
可能なメモリ・ページがまばらに所在する索引付き集
合。ページ範囲は、カーネルおよび外部メモリ・マネー
ジャによって実現される機構によってそれらに関連付け
られた任意の属性およびセマンティクスを有する場合も
ある。 アブストラクション・メモリ・オブジェクト： このオ
ブジェクトによって支援されるメモリ範囲の非常駐状態
を表すアブストラクション・オブジェクト。このオブジ
ェクトを実現するタスクは、メモリ・マネージャと呼ば
れる。アブストラクション・メモリ・オブジェクト・ポ
ートは、カーネルがメモリ・マネージャのアクションを
要求する際のポートである。 メモリ・オブジェクト見本： メモリ・オブジェクトの
クライアントに対してメモリ・マネージャが提供するメ
モリ・オブジェクトのアブストラクション表現。この見
本は、関連のアブストラクション・メモリ・オブジェク
トを命名し、クライアントに許可される潜在的なアクセ
ス・モードを限定する。 メモリ・キャッシュ・オブジェクト： アブストラクシ
ョン・メモリ・オブジェクトによって支援されるメモリ
範囲の常駐状態を収容するカーネル・オブジェクト。メ
モリ・マネージャがクライアントの可視メモリ・イメー
ジを操作する場合、その操作はこのオブジェクトによっ
て行われる。 プロセッサ： スレッドを実行できる物理プロセッサ。 プロセッサ・セット： それぞれがプロセッサ・セット
に割り当てられているスレッドの実行に使用可能な１組
のプロセッサ。 ホスト： 全体としてのマルチプロセッサ。 クロック： 時間の経過を表すもの。一定の周波数で増
加する時間値。
【００５９】上記の要素の多くは、スレッドによって直
接操作可能な、カーネルで実現された資源である。それ
ぞれの要素については、以下の各項で詳しく説明する。
ただし、一部の要素の定義は他の要素の定義に依存する
ので、詳細説明を理解できるように、重要概念の一部に
ついては簡単に説明する。
【００６０】スレッド スレッドは軽量エンティティである。スレッドは、作成
するのに費用がかからず、動作に要するオーバヘッドも
低い。スレッドはほとんど状態を持たない（たいていは
そのレジスタ状態である）。スレッドが所有するタスク
は、資源管理の責任を負う。マルチプロセッサ上では、
タスク内の複数のスレッドが並列に実行することが可能
である。並行処理が目標ではなくても、複数スレッドは
有利である。というのは、各スレッドは、単一スレッド
が複数のサービスを提供しようとする非同期プログラミ
ングの代わりに、同期プログラミング・スタイルを使用
することができるからである。
【００６１】スレッドには、以下の特徴が含まれる。 １．タスクまたは一連の命令実行における制御流れの点 ２．収容タスクのすべての要素へのアクセス ３．複数のスレッドが同一タスク内にあっても、他のス
レッドと並列実行すること ４．オーバヘッドが低い割に状態が最小であること
【００６２】スレッドは、基本計算エンティティであ
る。スレッドは、その仮想アドレス空間を定義する１つ
のタスクにのみ属す。アドレス空間の構造に影響するた
め、またはアドレス空間以外の資源を参照するために
は、スレッドは特別なトラップ命令を実行しなければな
らない。これにより、カーネルは、スレッドのために諸
操作を実行するか、またはスレッドのためにエージェン
トにメッセージを送信する。このようなトラップは、ス
レッドを収容するタスクに関連する資源を操作する。こ
れらのエンティティを操作するよう、すなわち、それら
を作成して削除し、その状態を左右するよう、カーネル
に要求することができる。カーネルは、資源（前述のも
のなど）およびサービスを提供する管理プログラムであ
る。また、タスクもサービスを提供し、アブストラクシ
ョン資源を実現することができる。カーネルは、サーバ
・タスク（実際は、そこで実行されるスレッド）がサー
ビスを提供することをクライアント・タスクが要求でき
るようにするための通信方法を提供する。このようにし
て、タスクは２重のアイデンティティを持つ。一方のア
イデンティティは、カーネルによって管理される資源の
アイデンティティであって、その資源管理プログラムは
カーネル内で実行される。もう一方のアイデンティティ
は、資源の供給側のアイデンティティであって、そのた
めの資源管理プログラムはタスクそのものになる。
【００６３】スレッドは以下の状態を持つ。 １．そのマシン状態（レジスタなど）。スレッドが実行
されるにつれて変化し、カーネル・スレッド・ポートの
保有側による変更も可能であるもの。 ２．スレッド固有ポート権の小規模セット。スレッドの
カーネル・ポートと、スレッドのために例外メッセージ
を送信するために使用されるポートとを識別するもの。 ３．中断カウント。スレッドが命令を実行しない場合は
ゼロ以外になる。 ４．資源スケジューリング・パラメータ。
【００６４】スレッドは、通常通り命令を実行すること
によって動作する。スレッドのために諸操作を実行する
ために、様々な特殊命令がカーネルにトラップされる。
このようなカーネル・トラップのうちで最も重要なもの
はmach_msg_trapである。このトラップにより、スレッ
ドはカーネルにメッセージを送信し、他のサーバは資源
に作用することができる。このトラップが直接呼び出さ
れることはほとんどなく、mach_msgライブラリ・ルーチ
ンを介して呼び出される。スレッドの実行中に発生する
「浮動小数点オーバーフロー」および「ページ非常駐」
などの例外条件は、ポートにメッセージを送信すること
によって処理される。使用するポートはその条件の性質
によって決まる。例外条件の結果は、スレッドの状態を
設定するか、または例外メッセージに対して応答する
か、あるいはその両方を実行することによって決定され
る。スレッドについては、以下の操作を実行することが
できる。 作成および破棄 中断および再開（中断カウントの操作） マシン状態操作特殊ポート（例外ポートなど）の操作 資源（スケジューリング）制御
【００６５】タスク タスクはシステム資源の集合である。このような資源
は、アドレス空間を除き、ポートによって参照される。
ポートに対する権利がそのように分散されていれば、こ
れらの資源を他のタスクと共用することができる。
【００６６】タスクは、マシン・アドレスによって参照
される、散在する可能性のある大きいアドレス空間を提
供する。この空間の各部は、継承または外部メモリ管理
によって共用することができる。ただし、タスクにはそ
れ専用の存続期間がないことに留意されたい。タスクに
は、命令を実行するスレッドが収容されている。「タス
クＹがＸを実行する」と言う場合、「タスクＹ内に収容
されているスレッドがＸを実行する」ことを意味する。
タスクは高価なエンティティである。１つのタスク内の
すべてのスレッドがあらゆるものを共用する。アクショ
ンは単純である場合が多いが、明示アクションがなけれ
ば、２つのタスクは何も共用しない。ポート受信権など
の一部の資源は、２つのタスク間で共用することができ
ない。タスクは、１組のスレッドを保管する容器と見な
すことができる。タスクは、その収容スレッドに適用さ
れるデフォルト値を収容している。最も重要なのは、そ
の収容スレッドが実行に要する要素、すなわち、ポート
名空間と仮想アドレス空間をタスクが収容している点で
ある。
【００６７】タスクに関連する状態は以下の通りであ
る。 １組の収容スレッド 関連の仮想アドレス空間 １組のポート権とそれに関連する１組のポート通知要求
を命名する、関連ポート名空間 タスクからメッセージとともに送信されるセキュリティ
・トークン タスクのカーネル・ポートと、収容スレッドのための例
外処理に使用するデフォルト・ポートと、他のサービス
を命名するためのブートストラップ・ポートとを識別す
る、タスク固有ポートの小規模セット 収容スレッドが命令を実行しない場合はゼロ以外にな
る、中断カウント スレッド用のデフォルト・スケジューリング・パラメー
タ 統計ＰＣサンプルを含む、様々な統計
【００６８】タスクは、新しいタスクが作成されるホス
トを指定し、継承によりそのアドレス空間の様々な部分
を供給することができる、プロトタイプ・タスクを指定
することによって作成される。
【００６９】タスクについては、以下の操作を実行する
ことができる。 作成および破棄 セキュリティ・トークンの設定 中断および再開 特殊ポートの操作 収容スレッドの操作 スケジューリング・パラメータの操作
【００７０】セキュリティ・ポート すべてのタスクは、カーネルの視点からは不透明のＩＤ
であるセキュリティ・トークンでタグが付けられてい
る。これは、タスクのアイデンティティとその他のセキ
ュリティ属性を符号化するものである。このセキュリテ
ィ・トークンは、タスクによって送られるすべてのメッ
セージに暗黙値として含まれている。トラステッド・サ
ーバは、アクセス仲介判断を行う際に使用するためのセ
ンダー側のアイデンティティの標識として、この送られ
たトークンを使用することができる。タスクは、その親
のセキュリティ・トークンを継承する。このトークン
は、偽造不能なアイデンティティの標識として使用され
るので、このトークンを変更するには特権が必要であ
る。この特権は、ホスト・セキュリティ・ポートを提示
することによって示される。
【００７１】予約値は、カーネルのアイデンティティを
示す。カーネルからのすべてのメッセージはカーネルの
アイデンティティを伝達する。ただし、例外メッセージ
は、例外タスクのアイデンティティを伝達する。
【００７２】ポート ポートは、サービスを要求するクライアントと、そのサ
ービスを提供するサーバとの間の単一方向の通信チャネ
ルである。１つのポートは、単一レシーバを有し、複数
のセンダーを有する可能性もある。ポートに関連する状
態は以下の通りである。 その関連メッセージ待ち行列 ポートに対する参照（権利）のカウント 仮想コピー・メモリの容量と、ポートを介してメッセー
ジ送信可能なポート権とに対して設定可能な限界値
【００７３】カーネル・サービスは、ポートを割り振る
ために存在する。仮想メモリ範囲以外のすべてのシステ
ム・エンティティはポートによって命名され、これらの
エンティティが作成されると、ポートも暗黙のうちに作
成される。カーネルは、要求に応じてポートが消滅する
と、通知メッセージを提供する。タスクの仮想アドレス
空間を除き、他のすべてのシステム資源は、ポートとし
て知られている所定のレベルの間接参照によってアクセ
スされる。ポートは、サービスを要求するクライアント
と、そのサービスを提供するサーバとの間の単一方向の
通信チャネルである。このようなサービス要求に対して
応答を行う場合は、第２のポートを使用しなければなら
ない。提供されるサービスは、ポートを介して送られる
メッセージを受け取る管理プログラムによって決定され
る。その結果、カーネル提供エンティティに関連するポ
ート用のレシーバがカーネルになる。タスク提供エンテ
ィティに関連するポート用のレシーバは、そのエンティ
ティを提供するタスクになる。タスク提供エンティティ
を命名するポートの場合、そのポート用のメッセージの
レシーバを別のタスクに変更することが可能である。単
一タスクが、それによってサポートされる資源を参照す
る複数のポートを有する可能性もある。所与のエンティ
ティは、それを表す複数のポートを有し、それぞれが許
される操作の様々なセットを暗示することができる。た
とえば、多くのエンティティは、名前ポートと、特権ポ
ートと呼ばれることもある制御ポートとを有する。この
制御ポートにアクセスすると、そのエンティティを操作
することができる。名前ポートへのアクセスは、たとえ
ば、情報を返すために、そのエンティティを命名するだ
けである。
【００７４】ポート用のシステム規模の名前空間は一切
ない。スレッドは、その収容タスクが把握しているポー
トにのみアクセスすることができる。タスクは、１組の
ポート権を保有し、そのそれぞれが（必ずしも別個では
ない）ポートを命名し、そのポートに許される権利を指
定する。ポート権は、メッセージに入れて伝送すること
ができる。これは、タスクがポート権を取得する方法で
ある。ポート権はポート名で命名され、そのポート名
は、その権利を保有するタスクのコンテキスト（ポート
名空間）内でのみ意味を持つカーネルによって選択され
た整数である。システム内のほとんどの操作は、操作さ
れるオブジェクト用の管理プログラムを命名するポート
にメッセージを送信することで構成される。本明細書で
は、これを以下の形式で示す。 object -> function これは、そのオブジェクトを命名するポートに（適切な
メッセージを送信することによって）その機能が呼び出
されることを意味する。ポート（権）にメッセージを送
信しなければならないので、この操作はオブジェクトを
基礎とする。スレッドをプロセッサ・セットにバインド
する場合など、操作によっては２つのオブジェクトが必
要になる。このような操作では、オブジェクト同士をカ
ンマで区切って示す。すべてのエンティティがポートに
よって命名されるわけではないので、これは純粋なオブ
ジェクト・モデルではない。２つの主要非ポート権命名
エンティティは、ポート名／権そのものと、メモリ範囲
である。事象オブジェクトもタスクのローカルＩＤによ
って命名される。メモリ範囲を操作するには、所有タス
クによって命名された収容仮想アドレス空間にメッセー
ジが送信される。ポート名／権と、多くの場合は関連ポ
ートとを操作するには、所有タスクによって命名された
収容ポート名空間にメッセージが送信される。オブジェ
クトのどの範囲または要素を操作するかを示すにはメッ
セージ内のパラメータとしてｉｄが必要であることを示
すために、ここでは以下の添字表記を使用する。 object [id] -> function また、特定の方法でオブジェクトを操作するための十分
な特権を示すにはメッセージ内のパラメータとして、ホ
スト制御ポートなどの特権ポートが必要であることを示
すために、ここでは以下のかっこ付き表記を使用する。 object (port) -> function
【００７５】ポート・セット ポート・セットは、メッセージを受け取るときに単一ユ
ニットとして扱うことができる１組のポートである。ma
ch_msg受信操作は、受信権またはポート・セットのいず
れかを命名するポート名に対して使用可能になる。ポー
ト・セットには、複数の受信権の集合が入っている。受
信操作がポート・セットに対して行われると、そのセッ
ト内のポートの１つからメッセージが受け取られる。受
け取ったメッセージは、そのメッセージの送信元である
メンバー・ポートを示す。ポート・セットのメンバーで
あるポートからメッセージを直接受け取ることはできな
い。ポート・セット内のポートに関する優先順位の概念
は存在しない。したがって、所与のメッセージの送信元
であるポート・セット内のポートに関するカーネルの選
択は一切制御されない。
【００７６】ポート・セットについてサポートされてい
る操作には、以下のものが含まれる。 作成および削除 メンバーシップの変更およびメンバーシップの照会
【００７７】ポート権 ポートは、ポート権の使用によってのみアクセスするこ
とができる。ポート権により、特定の方法で特定のポー
トにアクセスすることができる。ポート権としては、以
下の３通りのタイプがある。 受信権 ― 権利保有者が関連ポートからメッセージを
受信できるようにする。 送信権 ― 権利保有者が関連ポートにメッセージを送
信できるようにする。 単一送信権 ― 権利保有者が関連ポートに単一メッセ
ージを送信できるようにする。このポート権は、メッセ
ージ送信後に自然消滅する。
【００７８】ポート権は、mach_msg呼出しの様々なオプ
ションを使用してタスク間でコピーおよび移動すること
ができ、さらに明示コマンドによってもコピーおよび移
動することができる。メッセージ操作以外では、ポート
名空間のメンバーとしてのみポート権を操作することが
できる。また、他のシステム・エンティティを作成し、
明示ポート作成を明示的に使用すると、暗黙のうちにポ
ート権が作成される。
【００７９】ポートに対する送信権がそれ以上ない場
合、カーネルは、要求に応じて、ユーザの選択をポート
に通知する。また、単一送信権の破棄（それを使用して
メッセージを送信する場合を除く）により、対応するポ
ートに送られる単一送信通知が生成される。要求がある
と、カーネルは、受信権の破棄を通知する。
【００８０】ポート名空間 ポートおよびポート権は、任意のポートまたは権利を直
接操作できるようにするためのシステム規模の名前を持
っていない。ポートはポート権を介してのみ操作可能
で、ポート権はポート名空間内に収容されている場合の
み操作可能である。ポート権は、ポート名空間内の索引
であるポート名によって指定される。各タスクには、単
一のポート名空間が関連付けられている。
【００８１】ポート名空間の項目は、以下の４通りの値
を持つことができる。 MACH_PORT_NULL ― 関連ポート権がない。 MACH_PORT_DEAD ― この名前に権利が関連付けられて
いるが、その権利が参照するポートはすでに破棄されて
いる。 ポート権 ― ポートに関する単一送信権、送信権、ま
たは受信権。 ポート・セット名 ― 受信権のように機能するが、複
数のポートからの受信を可能にする名前。
【００８２】タスク内で新しい権利を獲得すると、新し
いポート名が生成される。ポート権は、そのポート名を
参照することによって操作されるので、ポート名そのも
のが操作されることもある。所与のポート名空間内の所
与のポートに対するすべての送信権と受信権は同じポー
ト名を有する。所与のポートに対する各単一送信権は、
他の単一送信権とは異なるポート名を有し、保有する送
信権または受信権に使用したポート名とも異なるポート
名を有する。ポート名についてサポートされている操作
としては、以下のものが含まれる。 作成（権利の作成時の暗黙作成）および破棄 関連タイプの照会 名前変更 名前が使用不能になるという通知（要求に応じて、カー
ネルが行う）
【００８３】ポート名空間はタスクにバインドされるの
で、その空間が所有するタスクによって作成および破棄
される。
【００８４】メッセージ メッセージは、２つのエンティティ間で引渡しされるデ
ータ、メモリ範囲、およびポート権の集合である。メッ
セージは、元々システム・オブジェクトであるわけでは
ない。しかし、メッセージは待ち行列化されるため、メ
ッセージ送信からその受信までの間、状態を保持するこ
とができるので、重要である。この状態は、以下のもの
で構成される。 純粋データ メモリ範囲のコピー ポート権 送信側のセキュリティ・トークン
【００８５】メッセージ待ち行列 ポートは、複数のメッセージからなる待ち行列で構成さ
れる。この待ち行列は、メッセージを伝送するメッセー
ジ操作（mach_msg）によってのみ操作される。待ち行列
に関連する状態は、待ち行列化されたメッセージからな
る順序付けされた集合であり、メッセージ数に関する設
定可能な限界である。
【００８６】仮想アドレス空間 仮想アドレス空間は、その仮想アドレス空間を所有する
タスク内で実行されるスレッドを参照できるようにする
ための有効仮想アドレスの集合を定義する。仮想アドレ
ス空間は、それ自身が所有するタスクによって命名され
る。
【００８７】仮想アドレス空間は、複数のページがまば
らに所在する索引付き集合で構成される。個々のページ
の属性は、所望通りに設定することができる。効率を高
めるため、カーネルは、同じ属性を有する複数のページ
からなるほぼ連続する集合を、内部メモリ領域にグルー
プ化する。カーネルは、所望通りにメモリ領域の分割ま
たは統合を自由に行うことができる。システム機構はメ
モリ領域のアイデンティティに敏感であるが、ほとんど
のユーザ・アクセスはそのような影響を受けず、自由に
メモリ領域に及ぶことができる。
【００８８】所与のメモリ範囲は、メモリ・マネージャ
の各種アクションにより、それに関連する個別のセマン
ティクスを持つことができる。仮想アドレス空間に新し
いメモリ範囲が設定されると、そのメモリ範囲のセマン
ティクスを提供するタスク（メモリ・マネージャ）に関
連付けられることによって、そのセマンティクスを表す
アブストラクション・メモリ・オブジェクトが、おそら
くデフォルトにより指定される。
【００８９】仮想アドレス空間は、タスクが作成される
と作成され、タスクが破棄されると破棄される。アドレ
ス空間の初期内容は、task_create呼出しへの様々なオ
プション、ならびにその呼出しに使用するプロトタイプ
・タスクのメモリ範囲の継承特性により決まる。仮想ア
ドレス空間でのほとんどの操作により、アドレス空間内
のメモリ範囲が命名される。このような操作としては、
以下のものが含まれる。 範囲の作成または割振りと、割振り解除 範囲のコピー 追出しを防止するためにページを物理メモリに「配線」
することを含む、特殊属性の設定 メモリ保護属性の設定 継承特性の設定 範囲の直接読取りおよび書込み 補助記憶装置への範囲の強制フラッシュ 範囲の予約（範囲内でのランダム割振りを防止する）
【００９０】アブストラクション・メモリ・オブジェク
ト マイクロカーネルでは、ユーザ・モード・タスクが仮想
アドレス空間の各部分の参照に関連するセマンティクス
を提供することができる。これは、このメモリ・オブジ
ェクトによって支援されるメモリ範囲の非常駐状態を表
すアブストラクション・メモリ・オブジェクトの指定を
可能にすることによって行われる。このメモリ・オブジ
ェクトを実現し、メモリ・オブジェクトを命名するポー
トに送られるメッセージに応答するタスクは、メモリ・
マネージャと呼ばれている。
【００９１】カーネルは、各種のメモリ・オブジェクト
の内容用の直接アクセス可能なキャッシュとしてメイン
・メモリを使用する。と考える必要がある。カーネル
は、アブストラクション・メモリ・オブジェクト・ポー
トにメッセージを送ることによって、このキャッシュを
維持し、このキャッシュをカーネルの所望通りに充填お
よびフラッシュするために、様々なメモリ・マネージャ
との非同期対話に関与する。アブストラクション・メモ
リ・オブジェクトに対する操作としては、以下のものが
含まれる。 初期設定 ページ読取り ページ書込み 強制およびフラッシュ動作との同期 ページにアクセスするための許可を求める要求 ページ・コピー 終了
【００９２】メモリ・オブジェクト見本 メモリ・オブジェクト用の補助記憶装置へのアクセスを
要求するために、カーネルはアブストラクション・メモ
リ・オブジェクト・ポートを使用する。この対話の保護
性のため、一般にメモリ・マネージャは、アブストラク
ション・メモリ・オブジェクト・ポートへのアクセスを
クライアントに許可しない。むしろ、クライアントは、
メモリ・オブジェクト見本へのアクセスが許可される。
メモリ・オブジェクト見本とは、メモリ・オブジェクト
のクライアント側の表現である。このようなポートに対
して許される操作は１つだけであり、それは関連メモリ
・オブジェクトをタスクのアドレス空間にマッピングす
ることである。このような要求を行うと、基礎となるア
ブストラクション・メモリ・オブジェクトを初期設定す
るためにマッピング・カーネルとメモリ・マネージャと
の間のプロトコルが開始される。その見本によって表さ
れるアブストラクション・メモリ・オブジェクト、なら
びにその見本によって許されるアクセス・モードの集合
をカーネルに通知するには、この特殊なプロトコルが使
用される。
【００９３】メモリ・キャッシュ・オブジェクト カーネルのメイン・メモリ・キャッシュのうち、所与の
アブストラクション・メモリ・オブジェクトに関連する
常駐ページが入っている部分は、メモリ・キャッシュ・
オブジェクトと呼ばれる。メモリ・オブジェクト用のメ
モリ・マネージャは、カーネルのメモリ・キャッシュ・
オブジェクトに対する送信権を保有する。このメモリ・
マネージャは、関連メモリ・キャッシュ・オブジェクト
にメッセージを送ることによって、そのアブストラクシ
ョン・メモリ・オブジェクトのアブストラクションを提
供するために、カーネルとの非同期対話に関与する。メ
モリ・キャッシュ・オブジェクトに対する操作として
は、以下のものが含まれる。 動作属性の設定 属性の戻り カーネルへのページ供給 カーネルが要求したページが使用不能であることを示す
表示 カーネルが要求したページをカーネルのデフォルト・ル
ールによって充填する必要があることを示す表示 オブジェクトの遅延コピーの強制完了 メモリ・マネージャに送られたページが処分されたこと
を示す表示 メモリ・ページへのアクセスの制限 パフォーマンス上のヒントの提供 終了
【００９４】プロセッサ スレッドを実行することができる各物理プロセッサは、
プロセッサ制御ポートによって命名される。実際の作業
を実行するという点で重要ではあるが、プロセッサ・セ
ットのメンバーとして以外にマイクロカーネル内のプロ
セッサはあまり重要ではない。１組のスレッドをスケジ
ュールするために使用されるプロセッサの共同管理用の
基礎を形成し、それに関連するスケジューリング属性を
有するのが、プロセッサ・セットである。プロセッサに
ついてサポートされている操作としては、以下のものが
含まれる。 プロセッサ・セットへの割当て 始動および停止などのマシン制御
【００９５】プロセッサ・セット プロセッサはプロセッサ・セットにグループ化される。
プロセッサ・セットは、そのプロセッサ・セットに割り
当てられたスレッドをスケジュールするために使用され
るプロセッサの共同管理を行う。プロセッサ・セット
は、１組のスレッドのスケジュール可能性を均等に制御
するための基礎として存在する。また、この概念は、シ
ステム内の所与の活動にプロセッサをおおざっぱに割り
振るための方法も提供する。プロセッサ・セットについ
てサポートされている操作としては、以下のものが含ま
れる。 作成および削除 プロセッサの割当て スレッドおよびタスクの割当て スケジューリング制御
【００９６】ホスト ネットワーク化したマイクロカーネル・システム内の各
マシン（ユニプロセッサまたはマルチプロセッサ）は、
マイクロカーネルについて独自のインスタンス化を実行
する。一般に、ホスト・マルチプロセッサ１００はクラ
イアント・タスクによって操作されることはない。しか
し、各ホストはそれ専用のマイクロカーネル１２０を所
持し、それぞれが専用のポート空間、物理メモリ、およ
びその他の資源を備えているので、実行中のホストは目
に見えるものになり、時には直接操作されることもあ
る。また、各ホストはそれ専用の統計を生成する。ホス
トの命名は、自由に分散され、ホストに関する情報を入
手するために使用可能な名前ポートと、しっかり保持さ
れホストを操作するために使用可能な制御ポートとによ
って行われる。ホストによってサポートされている操作
としては、以下のものが含まれる。 クロック操作 統計収集 リブート デフォルト・メモリ・マネージャの設定 プロセッサおよびプロセッサ・セットのリストの入手
【００９７】クロック クロックは、一定の周波数で時間値カウンタを増加する
ことによって、時間の経過を表す。マルチコンピュータ
内の各ホストまたはノードは、ハードウェアによってサ
ポートされる各種クロックおよびタイマ、ならびにこの
ようなタイマ上に構築されたアブストラクション・クロ
ックに基づいて、専用のクロック・セットを実現する。
所与のシステムによって実現されたクロック・セット
は、構成時に設定される。それぞれのクロックは、名前
ポートと、制御または特権ポートとによって命名され
る。制御ポートを使用すると、クロックの時刻と解像度
を設定することができる。名前ポートが与えられると、
タスクは以下の操作を実行することができる。 クロックの時刻と解像度の決定 時間値をマッピングするメモリ・オブジェクトの生成 所与の時刻までのスリープ（遅延） 所与の時刻での通知または警告の要求
【００９８】第３節 タスクおよびスレッド 本節では、スレッドおよびタスクのユーザ可視視点につ
いて論じる。スレッドは、マイクロカーネル・システム
１１５内の活動エンティティである。スレッドは、他の
資源にアクセスする際の仮想アドレス空間とポート名空
間をスレッドに提供するタスク内の制御点として機能す
る。
【００９９】スレッド スレッドは、基本的な計算エンティティである。スレッ
ドは、その仮想アドレス空間を定義する１つのタスクに
のみ属す。また、スレッドは、最小限の状態を有する軽
量エンティティである。スレッドは、ハードウェアによ
って指図された方法で実行され、スレッドのレジスタ値
に基づいてそのタスクのアドレス空間から命令を取り出
す。スレッドが直接実行することができるアクション
は、そのレジスタを操作し、そのメモリ空間での読取り
および書込みを行う命令を実行することだけである。た
だし、特権機械命令を実行しようと試みると、例外が発
生する。この例外については後述する。アドレス空間の
構造を左右するため、またはアドレス空間以外の資源を
参照するためには、スレッドは、スレッドのために操作
を実行するか、またはスレッドのために何らかのエージ
ェントにメッセージを送信するようカーネルに指示す
る、特殊トラップ命令を実行しなければならない。ま
た、障害またはその他の不当命令挙動が発生すると、カ
ーネルがその例外処理を呼び出す。
【０１００】図２は、スレッドに関連するクライアント
可視構造を示している。スレッド・オブジェクトは、カ
ーネル・スレッド・ポートに送られたメッセージ用のレ
シーバである。このスレッド・ポート用の送信権を保有
するランダム・タスクを除き、スレッド・ポートは、収
容プロセッサ・セットまたは収容タスクを介してそのス
レッドのスレッド自己ポートとしてもアクセス可能であ
る。
【０１０１】ここでは、ガイ・ジー・ソトマイヤー他に
よる"METHOD AND APPARATUS FOR MANAGEMENT OF MAPPED
AND UNMAPPED REGIONS OF MEMORY IN A MICROKERNEL D
ATAPROCESSING SYSTEM"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１０２】タスク タスクは、１組のスレッドを保管する容器と見なすこと
ができる。これは、その収容スレッドに適用されるデフ
ォルト値を収容している。最も重要なのは、その収容ス
レッドが実行する必要がある要素、すなわち、ポート名
空間と仮想アドレス空間を収容している点である。
【０１０３】図３は、クライアント可視タスク構造を示
している。タスク・オブジェクトは、カーネル・タスク
・ポートに送られたメッセージ用のレシーバである。こ
のタスク・ポート用の送信権を保有する可能性のあるラ
ンダム・タスクを除き、タスク・ポートは、そのタスク
のタスク自己ポート、収容済みスレッド、または収容プ
ロセッサ・セットから得ることができる。
【０１０４】ここでは、ガイ・ジー・ソトマイヤー他に
よる"METHOD AND APPARATUS FOR MANAGEMENT OF MAPPED
AND UNMAPPED REGIONS OF MEMORY IN A MICROKERNEL D
ATAPROCESSING SYSTEM"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１０５】第４節 ＩＰＣ その共用メモリを除き、マイクロカーネル・タスクは、
メッセージを送信し、応答を受信することによって純粋
にその環境と対話する。このようなメッセージはポート
を使用して送信される。ポートは、単一レシーバを有
し、複数のセンダーを有することができる通信チャネル
である。タスクは、それがメッセージを送信または受信
できる能力を指定する、これらのポートに対する権利を
保有する。
【０１０６】ポート ポートは、サービスを要求するクライアントと、そのサ
ービスを提供するサーバとの間の単一方向の通信チャネ
ルである。ポートは、単一レシーバを有し、複数のセン
ダーを有することができる。カーネルがサポートする資
源を表すポートは、レシーバとしてカーネルを有する。
タスクによって提供されるサービスを命名するポート
は、そのポートのレシーバとしてそのタスクを有する。
ポート権の項で論じるように、このレシーバ状態は必要
があれば変更することができる。
【０１０７】ポートに関連する状態は以下の通りであ
る。 関連メッセージ待ち行列 ポートに対する参照または権利のカウント ポート権および行外メモリ受信限界値 メッセージの順序番号 受信権から作成される送信権の数 収容ポート・セット 追加センダーなしポートの名前（指定されている場合）
【０１０８】図４は、典型的なポートを示す図であり、
一連の送信権と単一受信権を示している。関連メッセー
ジ待ち行列は、一連の順序づけられたメッセージを有す
る。そのメッセージの１つが詳細に示されているが、そ
の宛先ポート、応答ポート参照、メッセージで引き渡さ
れる送受信権、ならびに何らかの行外または仮想コピー
・メモリが示されている。
【０１０９】ポートそのものに影響する操作はあまりな
い。ほとんどの操作は、ポート権またはポート権を収容
するポート名空間に影響するか、またはメッセージ待ち
行列に影響する。他のシステム・エンティティが作成さ
れると、暗黙のうちにポートが作成される。また、mach
_reply_portもポートを作成する。ポートは、port_name
_space [port_name] -> mach_port_allocateおよびport
_name_space [port_name] -> mach_port_allocate_name
によって明示的に作成される。ポートを明示的に破棄す
ることはできない。ポートが破棄されるのは、受信権が
破棄された場合に限られる。
【０１１０】ポートの属性は作成時に割り当てられる。
ポート権の数に関する制限またはメッセージに入れて受
信可能な行外メモリの量など、一部の属性は、port_nam
e_space [port_name] -> mach_port_set_attributesで
変更することができる。このような属性は、port_name_
space [port_name] -> mach_port_get_attributesで入
手することができる。
【０１１１】ポートの存在は、関係するものすべてにと
って明らかに重要なものである。このため、ポートを使
用する多くのタスクは、ポートが消滅したときにメッセ
ージによる通知を必要とする可能性がある。このような
通知は、mach_msg (MACH_RCV_NOTIFY)のオプション、な
らびにport_name_space [port_name] -> mach_port_req
uest_notificationで要求する。その結果得られるデッ
ド名通知は、命名されたポートの破棄が原因でタスクの
ポート名がデッドになったことを示す。また、メッセー
ジは、現在デッドのポート用のタスクの名前を示す。
（これについては、ポート名空間の項で説明する。）
【０１１２】メッセージ メッセージは、２つのエンティティ間で引き渡されるデ
ータ、行外メモリ領域、およびポート権の集合である。
メッセージは、元々操作可能なシステム・オブジェクト
であるわけではない。しかし、メッセージは待ち行列化
されるため、メッセージ送信からその受信までの間、状
態を保持することができるので、重要である。純粋デー
タの他に、メッセージはポート権も収容することができ
る。この点は重要である。このため、タスクは、メッセ
ージに入れて受け取ることによって新しい権利を獲得す
る。
【０１１３】メッセージは、プロセス間通信（ＩＰＣ）
サブシステムが解析した制御セクションと、データ・セ
クションとで構成される。しかも、メッセージは、適正
メッセージ外にある、転送対象のデータ領域を指すこと
もある。このような領域は、ポート権（行外ポート配
列）を収容することができる。また、メッセージは、セ
ンダーのセキュリティ・トークンを伝達する。メッセー
ジの制御セクションは、ヘッダと、任意でメッセージ本
文および１つまたは複数のメッセージ記述子とで構成さ
れている。ヘッダは、メッセージの送信先であるポート
のポート名と、応答が要求されている場合に応答の送信
先であるポートの補助ポート名とを指定する。
【０１１４】メッセージ本文があるときは、その後にヘ
ッダが続き、そのメッセージ本文が後続の記述子の数を
宣言する。記述子がない場合は、メッセージは「複合」
と見なされず、データの明白な変換またはコピーがＩＰ
Ｃサブシステムに要求されないことを意味する。非「複
合」メッセージはメッセージ本文を含まない。各記述子
は、行外メモリ領域、ポート権、およびポート権配列な
どのカーネル操作データの１セクションを記述する。メ
ッセージ・データ・セクションに含まれるデータは、Ｉ
ＰＣサブシステムによって無名バイト配列として扱われ
る。メッセージのセンダーとレシーバは、データ形式に
関する共通認識を共用する必要がある。メッセージ・イ
ンタフェース・ジェネレータ（ＭＩＧ）生成ルーチンか
ら生成されたメッセージの場合、最初の８バイト分のデ
ータには、そのメッセージに含まれるデータについて可
能なマシン間変換のためのマシン符号化情報が入ってい
る。
【０１１５】単一ポート権用の記述子は、その権利、な
らびにコピーの作成ではなく権利の移動または異なるタ
イプの権利からの権利の生成のようなmach_msgによって
実行される特殊変換を命名する。「行外」ポート配列用
の記述子は、すべて同一タイプでなければならない１組
の権利用のＩＰＣ処理も指定するが、ポート名の配列の
アドレスとサイズを指定する。
【０１１６】行外データ記述子は、行外領域のサイズと
アドレスを指定する。この領域は、ページの先頭から始
まる必要はなく、整数分のページを含む必要もない。指
定されたデータだけが論理的に伝送される。記述子は、
メッセージを待ち行列化するという動作によって、vm_d
eallocateによる場合と同様に、メモリ範囲が送信側タ
スクから割り振り解除されるよう、指定することができ
る。センダーは、データの物理コピーを送信するか、仮
想コピーを送信するかを選択することができる。仮想コ
ピーを要求すると、カーネルはその仮想コピー、すなわ
ち、コピー・オン・ライト機構を使用して、大量のデー
タを効率よくコピーできるようになる。その結果、レシ
ーバは、センダーのメモリ・マネージャによって支援さ
れた仮想コピーを受け取ることがある。仮想コピー機構
を使用する可能性があるため、センダーとレシーバはど
ちらも、メモリへのアクセス時間の不確定さを経験する
可能性もある。物理コピーを選択すると、センダーおよ
びレシーバによるデータへの決定的なアクセスが保証さ
れる。行外データ領域またはメッセージ・データのいず
れの値もタイプされない。メッセージが送信される際の
ポートとメッセージ・データを把握しているメッセージ
のレシーバだけが、このようなデータ域を解釈し、おそ
らく変換することができる。
【０１１７】メッセージ・トレーラ メッセージを受け取ると、デフォルトにより末尾にトレ
ーラが付加される。一般にこのトレーラは、ＩＰＣサブ
システムによって追加され、物理的にメッセージに連続
する。トレーラには、メッセージ順序番号およびセンダ
ー・セキュリティ・トークンなどの様々な伝送関連フィ
ールドが入っている。
【０１１８】トレーラの形式とサイズは、mach_msgの受
信側オプションによって制御可能である。また、オプシ
ョンとして、センダーがトレーラを指定することも可能
である。
【０１１９】メッセージ待ち行列 ポートは、複数メッセージの待ち行列で構成される。待
ち行列は、メッセージを伝送するメッセージ操作（mach
_msg）によってのみ操作される。メッセージ待ち行列に
ついて制御可能な唯一の状態はそのサイズである。これ
は、port_name_space [port_name] -> mach_port_set_a
ttributesにその関連ポート用の受信権が与えられたと
きに設定することができる。メッセージ待ち行列が一杯
である場合は、それ以上メッセージを待ち行列に入れる
ことができない。その場合、呼出し側がブロックする。
【０１２０】ポートに送られたメッセージは確実に伝達
される。メッセージを受け取ると、それまでのすべての
メッセージが受信され、受信ポート上で待ち行列化され
た順序で受信されたことが保証される。
【０１２１】ポート権 ポート権は、特定の方法で特定のポートにアクセスする
ための権利を示すエンティティである。ポートへのアク
セスは、ポート権によってのみ行うことができる。この
ような場合のポート権としては、以下の３通りのタイプ
がある。 受信権 ― 権利保有者が関連ポートからメッセージを
受信できるようにする。 送信権 ― 権利保有者が関連ポートにメッセージを送
信できるようにする。 単一送信権 ― 権利保有者が関連ポートに単一メッセ
ージを送信できるようにする。この権利は、メッセージ
送信後に自然消滅する。
【０１２２】ポート権は、ロケーションとは無関係の、
ポートを識別するための確実な方法である。このような
権利はカーネル保護エンティティである。クライアント
がポート権を操作する場合は、その権利に関連して所有
するポート名のみ使用する。
【０１２３】基本操作 mach_msgは、権利を操作するための主な方法の１つであ
る。ポート権は、メッセージに入れてタスク間で移動す
ることができる。すなわち、センダーから削除したり、
レシーバに追加することができる。メッセージにオプシ
ョン・フラグを使用すると、mach_msgによって、既存の
送信権のコピーを作成したり、受信権から送信権または
単一送信権を生成することができる。また、port_name_
space [port_name] -> mach_port_extract_right（ター
ゲットがメッセージで権利を送信する場合と等価）およ
びport_name_space [port_name] -> mach_port_insert_
right（ターゲットがメッセージで権利を受信する場合
と等価）によって、権利を強制コピーしたり、強制移動
することもできる。メッセージ操作の他には、ポート名
空間のメンバーとしてのみ、ポート権を操作することが
できる。
【０１２４】図５は、ポート名空間に収容されている
か、またはメッセージに入れて伝送中の一連のポート権
を示している。ポート名空間にはポート・セットも示さ
れている。
【０１２５】他のシステム・エンティティが作成される
と、暗黙のうちにポート権が作成される。mach_reply_p
ortはポート権を作成する。ポート権は、port_name_spa
ce [port_name] -> mach_port_allocateおよびport_nam
e_space [port_name] -> mach_port_allocate_nameによ
って明示的に作成される。ポート権は、port_name_spac
e [port_name] -> mach_port_deallocateおよびport_na
me_space [port_name]-> mach_port_destroyによって破
棄される。また、port_name_space [port_name] -> mac
h_port_mod_refsなどのポート名空間操作の副産物とし
て、破棄を行うこともできる。
【０１２６】受信権が与えられると、port_name_space
[port_name] -> mach_port_get_attributesによって何
らかの状況情報を得ることができる。
【０１２７】追加センダーなし通知 システムは、各ポートごとに送信権および単一送信権の
数についてシステム規模のカウントを管理する。これに
は、宛先および応答ポート権など、メッセージに入れて
伝送中の権利が含まれる。ポートのレシーバは、そのポ
ートについてそれ以上送信権がないかどうかを確認し
て、そのポートがもはや有用ではないことを示す必要が
ある場合もある。この形式の通知は、port_name_space
[port_name] -> mach_port_request_notificationを使
用して要求することができる。この通知は、ポート名空
間の一部として説明した送信権作成カウントの概念によ
って決まる。別のタスクに受信権を移動すると、未解決
の追加センダーなし通知要求が取り消され、この取消し
を示すために単一送信通知が送られる。未解決の単一送
信権の数とは無関係に、既存の送信権の数がゼロになる
と、追加センダーなし通知が行われる。
【０１２８】単一送信権 単一送信権では、単一メッセージを送信することができ
る。このような権利は、受信権からのみ生成される。単
一送信権は、メッセージがそれから発生することを保証
するという特性を持つ。通常の場合、メッセージ内で宛
先ポートとしてそれを使用することによって、単一送信
権が使用される。そのメッセージが受信されると、権利
は黙って破棄される。単一送信権は、使用されるまで
は、それが宛先権として使用されていないときにタスク
間で移動することができる。メッセージを送信するため
に使用すること以外の方法でその権利が破棄されると、
単一送信通知がポートに送信される。単一送信権を使用
しないときにその権利を破棄できる方法の多くは、まっ
たく明白である。以下のように、不明瞭な場合が２通り
ある。
【０１２９】センダーなし通知のターゲットとして単一
送信権が指定され、要求されたセンダーなし通知の対象
となるポートが削除されるか、受信権が移動された。こ
の場合、発信予定のセンダーなし通知はないので、代わ
りに単一送信通知が生成される。
【０１３０】メッセージ受信を実行する過程で、メッセ
ージがポートから待ち行列解除されてからそれがタスク
に戻されるまでにタスクはその受信権を放棄する（以下
のメッセージ伝送の詳細を参照）。単一送信権により送
られるメッセージとポートとの間の関連の喪失を知らせ
る単一送信権通知が宛先ポートに送られる。
【０１３１】ポート名空間 ポートは命名されないが、ポート権は命名される。ポー
ト権の命名は、ポート名空間内に収容することによって
のみ、行うことができる。ポートは、ポート名空間内の
索引であるポート名によって指定される。それぞれのタ
スクは１つのポート名空間に関連付けられている。
【０１３２】ポート名空間の項目は、以下の４通りの値
を持つことができる。 MACH_PORT_NULL ― 関連ポート権なし。 MACH_PORT_DEAD ― この名前に権利が関連付けられた
が、その権利が参照するポートは現在デッドになってい
る。何が起こったかをクライアント・タスクが理解する
前にこの名前を再使用しないようにするために明示アク
ションが講じられるまで、ポート名はこの状態に維持さ
れる。 ポート権 ― ポートに関する単一送信権、送信権、ま
たは受信権。 ポート・セット名 ― 受信権のように作用するが、複
数ポートからの受信を可能にする名前。これについて
は、次の項で説明する。
【０１３３】ポート名空間に含まれるそれぞれの個別の
権利は、必ずしもポート名空間内の個別の名前を持って
いるわけではない。単一送信権は必ず個別の権利ごとに
別々の名前を使用する。同一ポートに対する受信権と送
信権は合体する。すなわち、ポート名空間が１つのポー
トについて３つの送信権を保有する場合、３つの権利す
べてについて単一名を持つことになる。ポート名は、単
一送信、送信、受信、ポート・セット、およびデッド名
など、その名前に関連するそれぞれのタイプの権利ごと
に、関連の参照カウントを持っている。ポート名空間が
受信権も保有する場合は、その受信権が送信権と同じ名
前を持つことになる。
【０１３４】その関連ポートが破棄されると、名前がデ
ッドになる。その結果、デッド名を保有するタスクはそ
の名前で受信権も保有することができなくなる。デッド
名は、その名前によって以前保持されていた送信参照の
数について、非ゼロの参照カウントだけを持つ。port_n
ame_space [port_name] -> mach_port_request_notific
ationを使用してその名前の１つがデッドになると、そ
れに送られるメッセージによってタスクに通知すること
ができる。この通知メッセージを受け取ると、その名前
を操作するスレッドとの競争を避けるために、そのデッ
ド名用の参照カウントが増加する。
【０１３５】タスクが権利を獲得すると、必ず上記の規
則に従ってそれにポート名が割り当てられる。権利の獲
得によって、その権利のタイプ用の名前の参照カウント
が増加する。参照カウントは、port_name_space [port_
name] -> mach_port_get_refsによって得ることができ
る。
【０１３６】port_name_space [port_name] -> mach_po
rt_destroyを使用してポート名を明示的に破棄し、すべ
ての参照を除去することができるが、一般にポート名
は、ユーザ参照カウントを修正することによって操作さ
れる。名前に関連する指定の権利タイプの参照カウント
は、port_name_space [port_name] -> mach_port_mod_r
efsによって修正される。port_name_space [port_name]
-> mach_port_deallocateはmach_port_mod_refsと似て
いるが、必ずカウントを１つ減らすもので、しかも送信
または単一送信参照カウントだけを減らすことになる。
このルーチンは、名前を修正するという決定を行ったた
めにデッドになったと思われるポート名の参照カウント
を操作するには有用である。実際に権利を移動させるma
ch_msgのオプションと、port_name_space [port_name]
-> mach_port_extract_rightも、名前の参照カウントを
減らすことができる。すべての参照カウントがゼロにな
ると、ポート名が解放される。
【０１３７】ポート名が解放され、その名前についてデ
ッド名通知が有効であれば、ポート削除完了通知が生成
される。デッド名通知要求が有効である名前は、以下の
３通りの状態のいずれか１つだけを取ることができる。 有効権利の命名 MACH_PORT_DEAD（その名前がデッドになったときにデッ
ド名通知が送られた場合） MACH_PORT_NULL（その名前がヌルになったときにポート
削除完了通知が送られた場合）
【０１３８】名前のタイプなど、名前に関する情報は、
port_name_space [port_name] -> mach_port_typeによ
って得ることができる。割り当てられた名前のリスト
は、port_name_space [port_name] -> mach_port_names
によって得られる。ある権利を認識するための名前は、
port_name_space [port_name] -> mach_port_renameに
よって変更することができる。受信権名が与えられる
と、port_name_space [port_name] -> mach_port_get_a
ttributesによって何らかの状況情報を得ることができ
る。
【０１３９】受信権を命名するポート名は、追加センダ
ーなし通知の処理に使用される、関連の送信権作成カウ
ントを有する。この送信権作成カウントは、（mach_msg
についてMACH_MSG_TYPE_MAKE_SENDタイプの記述子を指
定するポート権であるメッセージ要素によって）受信権
から送信権が作成された回数を示すカーネルのカウント
である。この送信権作成カウントは、ポートが作成され
るとゼロにセットされ、メッセージで受信権が伝送され
ると必ずゼロにリセットされる。また、このカウント
は、port_name_space [port_name] -> mach_port_set_m
scountによって変更することもできる。送信権作成カウ
ントは、追加センダーなし通知メッセージに含まれる。
ただし、センダーなし通知は、その通知が生成されたと
きの送信権の欠落を示すことに留意されたい。まだ未解
決の単一送信権が存在する可能性もある。いずれの単一
送信権もメッセージまたは単一送信通知を保証するの
で、タスクは単一送信権を容易に追跡することができ
る。受け取ったメッセージには、メッセージの送信元で
あるポートから取った順序番号がスタンプされる。ポー
ト・セットから受け取ったメッセージには、適切なメン
バー・ポートからの順序番号がスタンプされる。送信メ
ッセージ内に挿入された順序番号は上書きされる。新た
に作成されたポートはゼロの順序番号から始まり、その
ポートの受信権が移動されると必ずその順序番号がゼロ
にリセットされる。これは、port_name_space [port_na
me] -> mach_port_set_seqnoによって明示的にセットす
ることもできる。メッセージがポートから待ち行列解除
されると、そのメッセージには、ポートの順序番号がス
タンプされ、ポートの順序番号が増加する。待ち行列解
除操作と増加操作はアトミックなので、ポートからメッ
セージを受け取る複数スレッドは、msgh_seqnoフィール
ドを使用して、メッセージの元の順序を再構築すること
ができる。
【０１４０】ポート名空間はタスクにバインドされるの
で、その空間の所有タスクによって作成され、破棄され
る。
【０１４１】ポート・セット ポート・セットは、メッセージを受け取るときに単一ユ
ニットとして扱うことができる１組のポートである。受
信権またはポート・セットのいずれかを命名するポート
名に対して、mach_msg受信操作を使用することができ
る。ポート・セットには、受信権の集合が入っている。
ポート・セットに対して受信操作が実行されると、セッ
ト内のポートの１つから無作為にメッセージが受信され
る。ポート・セット上のメッセージの送達順序は不確定
であり、以下の２つの警告による実施を必要とする。 １）ポート・セットのいずれのメンバーでも、資源の停
止状態が発生してはならない。 ２）同一ポート上の他のメッセージに対する１つのメッ
セージの到着順序は保持される。
【０１４２】セット内のそれぞれの受信権は独自の名前
を持ち、セットも独自の名前を持つ。ポートセットに対
する受信では、そのメッセージを提供したポートを有す
る受信権の名前が報告される。受信権は１つのポート・
セットのみに属すことができる。ポート・セット内にあ
る受信権からタスクを直接受け取ることはできない。ポ
ート・セットは、port_name_space [port_name] -> mac
h_port_allocateまたはport_name_space [port_name] -
> mach_port_allocate_nameによって作成される。ま
た、ポート・セットは、port_name_space [port_name]
-> mach_port_destroyまたはport_name_space [port_na
me] -> mach_port_deallocateによって破棄される。
【０１４３】ポート・セットの操作は、port_name_spac
e [port_name] -> mach_port_move_memberによって行わ
れる。この呼出しは、セットにメンバーを追加したり、
セットからメンバーを除去したり、またはあるセットか
ら別のセットにメンバーを移動することができる。ポー
ト・セットのメンバーシップは、port_name_space [por
t_name] -> mach_port_get_set_statusによって見つけ
ることができる。
【０１４４】メッセージ伝送 mach_msgシステム呼出しは、マイクロカーネル・メッセ
ージの送信および受信を実行する。２つのタスク間で実
際にメッセージを転送する場合は、センダーは、送信オ
プションと適正ターゲット・ポートを指定したmach_msg
呼出しを行わなければならない。レシーバは、ターゲッ
ト・ポートでの受信を引き受ける受信オプションを指定
したmach_msg呼出しを行わなければならない。２つの呼
出しの順序は重要ではない。
【０１４５】送信操作では、メッセージをポートに待ち
行列化する。このメッセージは呼出し側のデータのコピ
ーを伝達する。呼出し側は、送信されたデータに影響せ
ずに送信操作が元に戻った後で、メッセージ・バッファ
と行外領域を自由に修正することができる。メッセージ
内に行外として指定されたデータは、センダー・オプシ
ョンおよびカーネルの機構選択に応じて、仮想コピーま
たは物理コピーとして引き渡される。カーネルは、その
領域を定義する１組のページの仮想メモリ・イメージを
構築する。「行外」ポート配列は、物理的にコピーさ
れ、宛先空間に適したポート名に変換される。カーネル
が仮想コピーを構築する場合は、最初のページの仮想コ
ピー内のデータより先行する部分と、最後のページの仮
想コピー内のデータに続く部分とをゼロにする。
【０１４６】以下のいずれかが起こらない限り、呼出し
側は、メッセージを待ち行列化できるようになるまでブ
ロックする。メッセージが単一送信権に送信される。こ
のようなメッセージは必ず強制的に待ち行列化される。
mach_msg操作が打ち切られる（thread_abort）。デフォ
ルトにより、mach_msgライブラリ・ルーチンは、中断さ
れた操作を再試行する。送信操作がそのタイムアウト値
を超過する。ポートが破棄される。
【０１４７】メッセージの送信は、２つのステップから
なるプロセスである。第１のステップは、メッセージの
カーネル・コピーの構築を含む。第２のステップは、メ
ッセージの待ち行列化を含む。無効なポート権またはデ
ータ・アドレスなどの障害が第１のステップで発生する
と、送信されるメッセージが失敗に終わってエラーが返
されるが、悪影響はない。送信タイムアウト値を超過す
るか、または中断（thread_abort）が行われると、第２
のステップでも障害が発生する場合がある。このような
障害が発生しても送信は失敗に終わるが、このような状
況ではカーネルは、擬似受信操作によって呼出し側にメ
ッセージの内容を返そうと試みる。この擬似受信操作に
よって、メッセージ内にのみ存在するポート権またはメ
モリ（たとえば、メッセージ内に移動された受信権また
は割振り解除フラグとともに送信される行外メモリ）の
紛失が防止される。
【０１４８】擬似受信操作は、通常の受信操作によく似
ている。擬似受信では、ポート権がメッセージ本文内に
入っている場合と同様にポート権をメッセージ・ヘッダ
に入れて処理する。擬似受信後、メッセージはいつでも
再送信可能な状態になる。ただし、メッセージを再送信
しない場合は、行外メモリ範囲がすでに移動され、一部
のポート権の名前がすでに変更されている可能性がある
ことに留意されたい。
【０１４９】受信操作は、メッセージをポートから待ち
行列解除する。受信側タスクは、メッセージに入れて伝
達されたポート権と行外メモリ範囲を獲得する。呼出し
側は、ヘッダと本文のコピー先になるバッファを提供し
なければならない。受信されたメッセージの形式は送信
されたときと同じである。メッセージがぴったりおさま
らない場合、そのメッセージは破棄される。オプション
（MACH_RCV_LARGE）を使用すると、呼出し側は、必要と
思われるバッファ・サイズとともに、代わりにエラーを
受け取ることができるので、適切なサイズのバッファを
指定してもう１回受信操作を試みることができる。
【０１５０】受け取ったメッセージには、ポート権と行
外メモリが入っている可能性がある。受け取ったポート
権とメモリは、何らかの方法で使用するか、割振り解除
する必要がある。ポート権または行外メモリの受信を妨
げる資源不足が発生すると、そのエンティティが破棄さ
れる。ポート権の受信は、ポート名空間の項で説明した
他の手段によるポート権の挿入と同じ規則に従う。ポー
ト権記述子は、受け取った権利のタイプを記述する。
【０１５１】伝送される行外領域ごとに、カーネルは、
メモリを突き止め、カーネルが物理コピーまたは仮想コ
ピーのいずれの送信を選択した（またはセンダーによっ
て指示された）かを示す記述子を、受け取ったメッセー
ジに入れて返す。物理コピーを送信すると、確定的な挙
動が保証される。デフォルトのメモリ・マネージャによ
って支援されているが、カーネルの仮想コピー最適化で
は、すでにメモリに入っているページ・イメージを使用
するか、センダーのメモリを支援したメモリ・マネージ
ャからページ・イメージを取り出す可能性もある。これ
により、受信側のタスクが任意のメモリ・マネージャに
支配される場合もあるが、大容量メモリの直接コピーよ
りパフォーマンスが大幅に改善される可能性がある。仮
想コピーの最適ケースは、センダーが割振り解除オプシ
ョンを使用した場合である。詳細については、仮想メモ
リ管理の項を参照されたい。
【０１５２】行外またはポート配列メモリ領域を受信す
るためのオプションは２つある。デフォルトであるオプ
ション１では、vm_allocateによる場合と同様に、受け
取った領域がレシーバのアドレス空間内の一時メモリと
して動的に割り振られる。カーネルが仮想コピーを伝送
した場合は、受け取ったデータが、センダーの配置と同
じ配置で１ページ内の割振り空間に現れる。他のいずれ
の場合も、割り振られたデータはページ境界の先頭から
始まる。いかなる状況においても、このオプションによ
るメッセージ受信が、仮想コピーそのものを誤って参照
することによってレシーバを停止させることはない。
【０１５３】オプション２では、vm_writeによる場合と
同様に、代替行外受信モードにより、行外領域が指定の
区域内のバイトに上書きされる。その領域が指定の区域
に収まらない場合、レシーバはエラーを受け取る。様々
な状況においては、データ伝送およびデータ配置の方法
に応じて、このオプションがページ操作を実行するか、
または実際にデータをコピーする可能性もある。この操
作は、おそらく、仮想コピーを支援するメモリ・マネー
ジャと対話し、任意でレシーバを停止させる可能性があ
る。
【０１５４】２つの受信モードの選択は、MACH_RCV_OVE
RWRITEオプションによって決まる。これが設定されてい
ないと、受け取ったすべての領域が動的に割り振られ
る。設定されている場合は、受信バッファは、送られた
メッセージ内の記述子リストと同じ形式の「分散」記述
子リストを記述するものと見なされる。カーネルはこの
リストを走査して、受け取った各領域をどのように処置
するかを判定する。送られた数の領域を処理するのに十
分な記述子が提供されない場合は、追加の領域が動的に
割り振られる。カーネルは、それぞれの行外記述子を調
べて、対応する領域の処置を決定する。仮想コピーの
「送信」オプションは動的割振りを暗示するもので、物
理コピーのオプションは、上書きされる領域を突き止め
るのに使用される記述子のアドレスおよびサイズ・フィ
ールドによる上書きを暗示する。サイズが不十分である
と、エラーが返される。
【０１５５】受信操作も、メッセージの待ち行列解除
と、レシーバでのコピーの作成という２つのステップか
らなるプロセスである。指定の受信タイムアウト値を超
過するか、受信が打ち切られる（thread_abort）と、そ
れが原因で第１のステップが失敗に終わる可能性があ
る。このような状況が発生しても、受信されたはずのメ
ッセージには影響しない。メッセージが破棄されるよう
な障害のほとんどは、第２のステップで発生する。
【０１５６】mach_msg呼出しの結果として要求可能な通
知がある。この通知は、mach_msgによって生成されるも
のではないが、MACH_RCV_NOTIFYオプションによって要
求される。このオプションを使用すると、mach_port_re
quest_notificationによる場合と同様に、受け取られる
応答ポート権について、自動的にデッド名通知が要求さ
れる。このオプションは、特定のクラスのＲＰＣ対話を
最適化したものである。応答ポート名に関するデッド名
通知では、適切な時期に要求側クライアントの消滅をメ
ッセージのレシーバに通知することができる。ただし、
応答権は通常、単一送信権なので、応答を送信するとそ
の権利を破棄することになり、代わりにポート削除完了
通知が生成される。この通知を取り消すための最適化
は、mach_msgのMACH_SEND_CANCELオプションによって提
供される。メッセージ操作は、メッセージ・ヘッダ内の
ポート権の操作の点ではアトミックである。
【０１５７】第５節 仮想メモリ管理 マイクロカーネルの仮想メモリ設計では、仮想メモリ・
システムをマシン依存部分とマシン非依存部分に階層化
する。マシン依存部分は、仮想メモリのページに関する
アクセス権の妥当性検査、無効化、および設定のための
単純なインタフェースを提供し、それにより、ハードウ
ェアのアドレス・マップを管理する。マシン非依存部分
は、論理アドレス・マップ（仮想アドレス空間のマッピ
ング）、このマップ内のメモリ範囲、および外部メモリ
管理インタフェースによるこれらの範囲用の補助記憶装
置へのインタフェース（メモリ・オブジェクト）をサポ
ートする。
【０１５８】仮想メモリ・システムは、適度な数のプロ
セッサからなる均等メモリ・アクセス・マルチプロセッ
サ用に設計されている。非均等メモリ・アクセスを提供
するか、または遠隔メモリ・アクセスを一切提供しない
アーキテクチャのサポートについては、現在、研究が行
われている。
【０１５９】マイクロカーネル仮想メモリ設計の特徴の
１つは、パフォーマンスの高さである。その多くは、こ
の設計が大規模疎アドレス空間、共用メモリ、および仮
想コピー・メモリ最適化を効率よくサポートしているこ
とによる。
【０１６０】最後に、仮想メモリ・システムでは、クラ
イアントがメモリ範囲用の補助記憶装置を提供すること
ができ、それにより、このような範囲に適用されるセマ
ンティクスが定義される。
【０１６１】ここでは、ガイ・ジー・ソトマイヤー他に
よる"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"という名称の前述の関連米国特
許出願を参照するが、この特許出願は、上記の点につい
てさらに詳述するために言及することにより本発明の一
部となる。
【０１６４】第Ｂ部 本発明の詳細な説明 図７は、ホスト・マルチプロセッサ・システム１００の
機能ブロック図であり、２つのプロセッサ１１０および
１１２上でスレッドを実行している状態でＩＰＣサブシ
ステム１２２とケイパビリティ・エンジン３００が２つ
のタスク２１０および２１０'間のプロセス間通信を管
理する場合を示している。データ処理システムは、図７
に示すような共用メモリ・マルチプロセッシング・シス
テムである場合もあれば、ユニプロセッサ・システムの
場合もある。マイクロカーネル１２０オペレーティング
・システムは、データ処理システム１００のメモリ１０
２にロードされる。本発明によれば、マイクロカーネル
は、メモリ１０２の諸領域をマッピングするためのケイ
パビリティまたは権利を管理する、ケイパビリティ・エ
ンジン・モジュール３００を含んでいる。このケイパビ
リティ・エンジン３００は、呼出しスケジューラ２３
２、メッセージ引渡しライブラリ２２０、一時データ・
モジュール４００、制御登録モジュール５００、非同期
応答モジュール６００、伝送制御分離モジュール７０
０、共用メモリ・サポート・メモリ８００、および高速
パス・モジュール９００を含む他の複数のモジュールと
ともに、ＩＰＣサブシステム１２２に含まれている。こ
れらのモジュールはすべて、ＩＰＣ１２２のプロセス間
通信操作に貢献するサービスを提供する。
【０１６５】マイクロカーネル１２０は、２つのタスク
・コンテナ２１０および２１０'と、それぞれのタスク
に属す２つのスレッド２４８および２４８'と、１つの
データ・オブジェクト２４２とを形成する。タスク
（Ａ）２１０は、データ・オブジェクト２４２をタスク
・コンテナ２１０にマッピングするポインタ２４０によ
って作成される。タスク・コンテナ２１０のポート権に
より、このコンテナは、データ・モジュールによって占
有されたアドレス空間を参照し、そこに入っているデー
タにアクセスするためにポインタ２４０を使用すること
ができる。したがって、ポインタ２４０によって参照さ
れるデータは、その実行中にスレッド２４８が利用でき
るようになる。スレッド２４８は、それ自身が順序付け
し、プロセッサＡ１１０によって処理される各種命令を
持っている。
【０１６６】タスク（Ｂ）２１０'も、第２のプロセッ
サＢ１１２に命令を送信する関連スレッド２４８'を持
っている。タスク（Ｂ）のポート権は、プロセッサ１１
２で実行するためにスレッド２４８'が使用できるよう
に、データ・オブジェクト２４２内のデータをそのアド
レス空間にマッピングできるようになるには不十分なも
のである。
【０１６７】ＩＰＣ１２２およびケイパビリティ・エン
ジン３００の動作を図示するため、タスク（Ｂ）に十分
なポート権を与えて、データ・オブジェクト２４２をそ
のアドレス空間にマッピングできるようにし、それによ
り、そのスレッド２４８'がプロセッサ１１２による操
作のためにデータを提供できるようにすることを要求す
るユーザ・プログラムの例を提示する。これは、タスク
２１０からＩＰＣ１２２のメッセージ引渡しライブラリ
２２０に送られ、ポート権とポインタ２４０をデータ・
オブジェクト２４２に提供するメッセージ２４４によっ
て達成される。メッセージ引渡しライブラリ２２０は、
タスク（Ｂ）のポート権を検査し、その可用性と、デー
タ・オブジェクト２４２にアクセスするためのタスク
（Ｂ）のケイパビリティの転送を許可するのに必要なそ
の他の条件とを検査するよう、ケイパビリティ・エンジ
ンに要求する。ケイパビリティ・エンジンは、ポート権
とその他の要因について適切な比較を行った後、呼出し
スケジューラ２３２上にその呼出しを待ち行列化し、送
信側タスク（Ａ）によって許諾されたポート権とポイン
タ２４０とを提供することによってそのケイパビリティ
を許可するメッセージ２４６を受け取るためにタスク
（Ｂ）が使用可能になるのを待つ。メッセージ引渡しラ
イブラリ２２０は、今後２つのタスク・コンテナ間で行
われるプロセス間通信を容易にするために、センダー・
タスク（Ａ）とレシーバ・タスク（Ｂ）の両方のポート
権のコピーを保護することができる。
【０１６８】要約すると、第１のタスク・コンテナ２１
０は、マイクロカーネル１２０によってメモリ１０２内
に形成され、第１の通信ポートと第１の組のポート権と
を定義する１組の属性を有し、メモリ・オブジェクト２
４２を指すポインタ２４０を有し、第１の組のポート権
が、第１のタスク・コンテナ２１０にメモリ・オブジェ
クト２４２にアクセスするためのケイパビリティを授与
する。また、第２のタスク・コンテナ２１０'は、メモ
リ１０２内に形成され、第２の通信ポートと第２の組の
ポート権とを定義する１組の属性を有する。
【０１６９】本発明によると、ケイパビリティ・エンジ
ン３００は、第１のタスク・コンテナ２１０用の第１の
組のポート権と、第２のタスク・コンテナ２１０'用の
第２の組のポート権とを登録する。次に、ケイパビリテ
ィ・エンジンは、第１の組のポート権と第２の組のポー
ト権とを比較して、第２のタスク２１０'がメモリ・オ
ブジェクト２４２へのアクセスの獲得を許可されるかど
うかを判定する。タスクのポート空間の属性になりうる
ポート権は広範囲におよび、各種許可レベル、セキュリ
ティ・レベル、優先順位レベル、プロセッサおよびその
他の資源の可用性など、数多くのものがあり、ユーザの
想像力によってのみ制限される。ケイパビリティ・エン
ジン３００は、これらの権利を分析し、第１のタスク・
コンテナ２１０から第２のタスク・コンテナ２１０'へ
のポインタ２４０と第１のポート権との転送を選択的に
可能にし、メモリ・オブジェクト２４２にアクセスする
ためのケイパビリティを第２のタスク・コンテナ２１
０'に授与することができる。このようにして、ケイパ
ビリティ・エンジン３００は、マイクロカーネル・シス
テム１１５内の多くのクライアントとサーバとの間で行
わなければならないプロセス間通信を高速かつ効率よく
管理する。
【０１７０】本発明は、ユニプロセッサ、共用メモリ・
マルチプロセッサ、および分散プロセッサ・システム内
の複数コンピュータに適用される。図８は、分散処理配
置で動作する２つのホスト・マルチプロセッサ・システ
ム１００および１００'の機能ブロック図であり、通信
リンク２５０を介して２つのホスト間でメッセージを交
換し、各ホスト・プロセッサ上のＩＰＣサブシステム１
２２とケイパビリティ・エンジン３００がタスク間のプ
ロセス間通信を管理する場合を示している。
【０１７１】図８では、ホスト１００のスレッド２４
８'が、入出力アダプタ・プロセッサ１０８で実行され
る命令を送出する。実行のためにスレッド２４８'によ
って送出された命令は、入出力プロセッサ１０８からホ
スト１００'の入出力プロセッサ１０８'に送られるメッ
セージの形式化に必要な命令を含むことができる。この
ようなメッセージは、前述のようにケイパビリティ・エ
ンジンの援助によってタスク（Ａ）２１０からタスク
（Ｂ）２１０'に送られるポート権およびポインタ２４
０に関する情報を含むことができる。ポート権とポイン
タ２４０の情報は、メッセージに入れて通信リンク２５
０を介して入出力プロセッサ１０８'に送られる。次
に、タスク２１１に関連するスレッド２４９が、入出力
プロセッサ１０８'内で実行され、ポート権とポインタ
２４０に関する情報をタスク２１１に転送する。前述の
１回目の転送と同様のもう１つのＩＰＣ転送をホスト１
００'で実行して、元々はホスト１００内のタスク
（Ａ）２１０に保持されていたポート権とポインタ２４
０をホスト１００'内のタスク２１１'に転送することが
できる。ホスト１００'内のタスク２１１'に属すスレッ
ド２４９'は、ホスト１００'のプロセッサ１１２'内で
命令を実行する。プロセッサ１１２'内でスレッド２４
９'によって実行されるプログラムが、ホスト１００の
データ・オブジェクト２４２内のデータにアクセスする
ためのコマンドを含んでいる場合は、その時点でタスク
２１１'のアドレス空間にマッピングされるか、そこに
格納されるポート権およびポインタ２４０によって、プ
ロセッサ１１２'がデータ・オブジェクト２４２にアク
セスできるようになる。次に、必要であれば、通信リン
ク２５０を介してデータ・オブジェクト２４２からのデ
ータを転送し、ホスト１００'内のデータ・オブジェク
ト２４３に格納することができる。これは、それ自身の
常駐メモリ内または別々のメモリを有する複数のプロセ
ッサによるプロセス間通信を容易にする際にケイパビリ
ティ・エンジンが果たすことができる役割の一例にすぎ
ない。
【０１７２】第１節 サブシステム・レベルの対話 ＩＰＣ１２２サブシステムと、ＶＭ、ポート、タスクお
よびスレッドとの関係 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 インタフェース・ジェネレータの
役割 メッセージ引渡しライブラリ２２０のＲＰＣ実施態様
は、コンパイル済みフロント・エンドを必要とせずにＲ
ＰＣをサポートするためのものであった。メッセージ引
渡しライブラリ２２０によって提示されるインタフェー
スにより、代理人ルーチンは、高価な実行時解釈を行わ
ずにＲＰＣをサポートすることができる。メッセージ引
渡しライブラリ２２０がコンパイルまたはその他の処理
を行ったフロント・エンドをサポートしないとは言えな
いものの、単純なメッセージ制御構造作成ルーチンによ
ってＲＰＣをサポートすることができる。
【０３１６】ＲＰＣインタフェースは様々なフロント・
エンドで動作すると完全に期待されている。後方互換の
ためにＭＩＧツールがメッセージ引渡しライブラリ２２
０に移植されている。これは、機能性の増大をサポート
するために拡張されたものである。ＭＩＧフロント・エ
ンドの移植によって、ＭＩＧインタフェースが明らかに
したように新しいＲＰＣが既存の機能性のスーパセット
であることが分かっている。既存のアプリケーション・
コード・ベースとの互換性を提供するために、他のフロ
ント・エンドを移植することもできる。
【０３１７】メッセージ引渡しライブラリ２２０がＲＰ
Ｃインタフェース全体をサポートするので、フロント・
エンドはコンテキストのない文法である必要はない。そ
れは、単なる有限状態の自動装置であってもよい。この
ため、フロント・エンドのコンパイラの設計とコードが
大幅に単純化される。しかし、別のモデルまたは拡張モ
デルが必要な場合は、メッセージ・バッファの内容をフ
ロント・エンドで操作することによってマシン上のパフ
ォーマンスが改善される箇所がいくつかある。
【０３１８】メッセージ引渡しライブラリ２２０は、状
況によっては２重間接ポインタを受け入れる（すなわ
ち、一部のマシンは、保護定義域境界での参照解除ポイ
ンタの箇所で非常に低速になる可能性がある）ので、お
そらく２倍のユーザ空間でポインタを参照解除し、それ
を直接データにする方が優れている場合もある。この場
合、クライアントへの直接データの書戻しを規定するメ
ッセージ・オプションが必要になるはずである。動的デ
ータ・フィールドであれば、静的データ・フィールドに
変換することができる。この場合は、そこに静的バッフ
ァ長が保管されているので、各パスによってメッセージ
制御構造を作成することが必要になるはずであるが、そ
れによって、個別のカウント・パラメータの必要性が除
去されるはずである。最後に、すべての直接パラメータ
を単一のデータ・フィールドに合体させて、メッセージ
引渡しライブラリ２２０で必要な解析時間を短縮するこ
とも可能である。
【０３１９】これらのオプションのいずれかによって、
ほとんどの場合に実際にパフォーマンスが向上するとは
予想されていないが、ＲＰＣインタフェースのフレキシ
ビリティを示すために述べられている。
【０３２０】ＲＰＣインタフェースは、サーバ・インタ
フェースをひとまとめにしたり、代理人機能テーブルと
メッセージ制御構造テーブルを作成するわけではない。
これを自動化することができるフロント・エンドを備え
ていると便利である。また、フロント・エンドは、デー
タ変換を実行するための適正箇所を証明する場合もあ
る。最も重要なのは、フロント・エンド・サポートと共
存要件とを調整し、遠隔およびローカルの代理人ライブ
ラリの生成をできるだけ自動化したものにする必要があ
る点である。
【０３２１】本発明の具体的な実施例について説明して
きたが、当業者は、本発明の精神および範囲を逸脱せず
にこの具体的な実施例の変更が可能であることに留意さ
れたい。
【０３２２】まとめとして、本発明の構成に関して以下
の事項を開示する。
【０３２３】（１）マイクロカーネル・アーキテクチャ
・データ処理システムにおけるプロセス間通信方法であ
って、ケイパビリティ・エンジン・モジュールを含むマ
イクロカーネルをデータ処理システムのメモリにロード
するステップと、第１の通信ポートと第１の組のポート
権とを定義する１組の属性を有し、さらにメモリ・オブ
ジェクトを指すポインタを有する第１のタスク・コンテ
ナを前記マイクロカーネルによって前記メモリ内に形成
するステップであって、前記メモリ・オブジェクトにア
クセスするために前記第１の組のポート権が前記第１の
タスク・コンテナにケイパビリティを授与するステップ
と、第２の通信ポートと第２の組のポート権とを定義す
る１組の属性を有する第２のタスク・コンテナを前記マ
イクロカーネルによって前記メモリ内に形成するステッ
プと、前記第１のタスク・コンテナ用の前記第１の組の
ポート権と前記第２のタスク・コンテナ用の前記第２の
組のポート権とを前記ケイパビリティ・エンジンに登録
するステップと、前記ケイパビリティ・エンジン内で前
記第１の組のポート権と前記第２の組のポート権とを比
較するステップと、前記メモリ・オブジェクトにアクセ
スするための前記ケイパビリティを前記第２のタスク・
コンテナに授与するために、前記第１のタスク・コンテ
ナから前記第２のタスク・コンテナへ前記ケイパビリテ
ィ・エンジンによって前記ポインタと前記第１のポート
権とを転送できるようにするステップとを含むプロセス
間通信方法。 （２）マイクロカーネル・オペレーティング・システム
を実行する共用メモリ・マルチプロセッサ・システムに
おけるプロセス間通信方法であって、第１のプロセッサ
と第２のプロセッサとを含むマルチプロセッサ・データ
処理システムの共用メモリにマイクロカーネルをロード
するステップであって、前記マイクロカーネルがケイパ
ビリティ・エンジン・モジュールを含むステップと、第
１の通信ポートと第１の組のポート権とを定義する１組
の属性を有し、さらにメモリ・オブジェクトを指すポイ
ンタを有する第１のタスク・コンテナを前記マイクロカ
ーネルによって前記メモリ内に形成するステップであっ
て、前記メモリ・オブジェクトにアクセスするために前
記第１の組のポート権が前記第１のタスク・コンテナに
ケイパビリティを授与し、前記第１のタスク・コンテナ
が前記第１のプロセッサ上で動作するスレッドを有する
ステップと、第２の通信ポートと第２の組のポート権と
を定義する１組の属性を有する第２のタスク・コンテナ
を前記マイクロカーネルによって前記メモリ内に形成す
るステップであって、前記第２のタスク・コンテナが前
記第２のプロセッサ上で動作するスレッドを有するステ
ップと、前記第１のタスク・コンテナ用の前記第１の組
のポート権と前記第２のタスク・コンテナ用の前記第２
の組のポート権とを前記ケイパビリティ・エンジンに登
録するステップと、前記ケイパビリティ・エンジン内で
前記第１の組のポート権と前記第２の組のポート権とを
比較するステップと、前記メモリ・オブジェクトにアク
セスするための前記ケイパビリティを前記第２のタスク
・コンテナに授与するために、前記第１のタスク・コン
テナから前記第２のタスク・コンテナへ前記ケイパビリ
ティ・エンジンによって前記ポインタと前記第１のポー
ト権とを転送できるようにし、それにより、前記第１の
プロセッサが前記第２のプロセッサと通信できるように
するステップとを含むプロセス間通信方法。 （３）それぞれがマイクロカーネル・オペレーティング
・システムを実行する第１のプロセッサと第２のプロセ
ッサとを含む分散プロセッサ・システムにおけるプロセ
ス間通信方法であって、分散データ処理システム内の第
１のプロセッサのメモリに第１のマイクロカーネルをロ
ードするステップであり、前記第１のマイクロカーネル
がケイパビリティ・エンジン・モジュールを含むステッ
プと、第１の通信ポートと第１の組のポート権とを定義
する１組の属性を有し、さらにメモリ・オブジェクトを
指すポインタを有する第１のタスク・コンテナを前記第
１のマイクロカーネルによって前記メモリ内に形成する
ステップであり、前記メモリ・オブジェクトにアクセス
するために前記第１の組のポート権が前記第１のタスク
・コンテナにケイパビリティを授与し、前記第１のタス
ク・コンテナが前記第１のプロセッサ上で動作するスレ
ッドを有するステップと、第２の通信ポートと第２の組
のポート権とを定義する１組の属性を有する第２のタス
ク・コンテナを前記第１のマイクロカーネルによって前
記メモリ内に形成するステップであり、前記第２のタス
ク・コンテナが入出力通信プロセッサ上で動作するスレ
ッドを有し、前記入出力プロセッサが第２のマイクロカ
ーネル・オペレーティング・システムを実行する第２の
データ・プロセッサに通信リンクによって結合されてい
るステップと、前記第１のタスク・コンテナ用の前記第
１の組のポート権と前記第２のタスク・コンテナ用の前
記第２の組のポート権とを前記ケイパビリティ・エンジ
ンに登録するステップと、前記ケイパビリティ・エンジ
ン内で前記第１の組のポート権と前記第２の組のポート
権とを比較するステップと、前記メモリ・オブジェクト
にアクセスするための前記ケイパビリティを前記第２の
タスク・コンテナに授与するために、前記第１のタスク
・コンテナから前記第２のタスク・コンテナへ前記ケイ
パビリティ・エンジンによって前記ポインタと前記第１
のポート権とを転送できるようにし、それにより、前記
第１のプロセッサが前記入出力通信プロセッサと通信で
きるようにするステップと、前記メモリ・オブジェクト
にアクセスするための前記ケイパビリティを前記第２の
プロセッサに授与するために、前記入出力通信プロセッ
サから前記第２のプロセッサへ前記ポインタと前記第１
のポート権とを転送するステップとを含むプロセス間通
信方法。 （４）マイクロカーネル・アーキテクチャ・データ処理
システムにおけるプロセス間通信用のサブシステムであ
って、データ処理システムのメモリ内のケイパビリティ
・エンジン・モジュールを含むマイクロカーネルと、前
記メモリ内にあって、第１の通信ポートと第１の組のポ
ート権とを定義する１組の属性を有し、さらにメモリ・
オブジェクトを指すポインタを有する第１のタスク・コ
ンテナであって、前記メモリ・オブジェクトにアクセス
するために前記第１の組のポート権が前記第１のタスク
・コンテナにケイパビリティを授与する第１のタスク・
コンテナと、前記メモリ内にあって、第２の通信ポート
と第２の組のポート権とを定義する１組の属性を有する
第２のタスク・コンテナとを含み、前記ケイパビリティ
・エンジンが、前記第１のタスク・コンテナ用の前記第
１の組のポート権と前記第２のタスク・コンテナ用の前
記第２の組のポート権とを登録し、前記ケイパビリティ
・エンジンが、前記第１の組のポート権と前記第２の組
のポート権とを比較し、前記ケイパビリティ・エンジン
が、前記メモリ・オブジェクトにアクセスするための前
記ケイパビリティを前記第２のタスク・コンテナに授与
するために、前記第１のタスク・コンテナから前記第２
のタスク・コンテナへ前記ポインタと前記第１のポート
権とを転送できるようにする、プロセス間通信用のサブ
システム。 （５）マイクロカーネル・オペレーティング・システム
を実行する共用メモリ・マルチプロセッサ・システムに
おけるプロセス間通信用のサブシステムであって、マル
チプロセッサ・システム内のメモリを共用する第１のプ
ロセッサおよび第２のプロセッサと、前記共用メモリ内
にあって、ケイパビリティ・エンジン・モジュールを含
むマイクロカーネルと、前記メモリ内にあって、第１の
通信ポートと第１の組のポート権とを定義する１組の属
性を有し、さらにメモリ・オブジェクトを指すポインタ
を有する第１のタスク・コンテナであって、前記メモリ
・オブジェクトにアクセスするために前記第１の組のポ
ート権が前記第１のタスク・コンテナにケイパビリティ
を授与し、前記第１のタスク・コンテナが前記第１のプ
ロセッサ上で動作するスレッドを有する第１のタスク・
コンテナと、前記メモリ内にあって、第２の通信ポート
と第２の組のポート権とを定義する１組の属性を有する
第２のタスク・コンテナであって、前記第２のタスク・
コンテナが前記第２のプロセッサ上で動作するスレッド
を有する第２のタスク・コンテナとを含み、前記ケイパ
ビリティ・エンジンが、前記第１のタスク・コンテナ用
の前記第１の組のポート権と前記第２のタスク・コンテ
ナ用の前記第２の組のポート権とを登録し、前記ケイパ
ビリティ・エンジンが、前記第１の組のポート権と前記
第２の組のポート権とを比較し、前記ケイパビリティ・
エンジンが、前記メモリ・オブジェクトにアクセスする
ための前記ケイパビリティを前記第２のタスク・コンテ
ナに授与するために、前記第１のタスク・コンテナから
前記第２のタスク・コンテナへ前記ポインタと前記第１
のポート権とを転送できるようにし、それにより、前記
第１のプロセッサが前記第２のプロセッサと通信できる
ようにする、プロセス間通信用のサブシステム。 （６）分散プロセッサ・システムにおけるプロセス間通
信用のサブシステムであって、通信リンクによって結合
され、それぞれがマイクロカーネル・オペレーティング
・システムを実行する第１のプロセッサおよび第２のプ
ロセッサと、前記第１のプロセッサのメモリ内にあっ
て、ケイパビリティ・エンジン・モジュールを含む第１
のマイクロカーネルと、前記メモリ内にあって、第１の
通信ポートと第１の組のポート権とを定義する１組の属
性を有し、さらにメモリ・オブジェクトを指すポインタ
を有する第１のタスク・コンテナであって、前記メモリ
・オブジェクトにアクセスするために前記第１の組のポ
ート権が前記第１のタスク・コンテナにケイパビリティ
を授与し、前記第１のタスク・コンテナが前記第１のプ
ロセッサ上で動作するスレッドを有する第１のタスク・
コンテナと、前記第１のプロセッサと前記メモリを共用
し、前記通信リンクによって前記第２のプロセッサと結
合されている入出力プロセッサと、前記メモリ内にあっ
て、第２の通信ポートと第２の組のポート権とを定義す
る１組の属性を有する第２のタスク・コンテナであっ
て、前記第２のタスク・コンテナが前記入出力通信プロ
セッサ上で動作するスレッドを有する第２のタスク・コ
ンテナとを含み、前記ケイパビリティ・エンジンが、前
記第１のタスク・コンテナ用の前記第１の組のポート権
と前記第２のタスク・コンテナ用の前記第２の組のポー
ト権とを登録し、前記ケイパビリティ・エンジンが、前
記第１の組のポート権と前記第２の組のポート権とを比
較し、前記ケイパビリティ・エンジンが、前記メモリ・
オブジェクトにアクセスするための前記ケイパビリティ
を前記第２のタスク・コンテナに授与するために、前記
第１のタスク・コンテナから前記第２のタスク・コンテ
ナへ前記ポインタと前記第１のポート権とを転送できる
ようにし、それにより、前記第１のプロセッサが前記入
出力通信プロセッサと通信できるようにし、前記第２の
プロセッサが、第２のマイクロカーネル・オペレーティ
ング・システムを実行し、前記入出力通信プロセッサ
が、前記メモリ・オブジェクトにアクセスするための前
記ケイパビリティを前記第２のプロセッサに授与するた
めに、前記第２のプロセッサに前記ポインタと前記第１
のポート権とを転送する、プロセス間通信用のサブシス
テム。 （７）マイクロカーネル・アーキテクチャにおけるプロ
セス間通信用のシステムであって、データ処理システム
内にあって、データおよびプログラム式命令を格納する
メモリ手段と、前記メモリ手段内にあって、前記メモリ
手段内の複数のタスク間の動作を調整するマイクロカー
ネル手段と、前記マイクロカーネル手段内にあって、前
記メモリ手段内の複数のタスク間のメッセージ引渡しを
調整するプロセス間通信手段と、前記メモリ手段内にあ
って、第１の通信ポートと第１の組のポート権とを定義
する１組の属性を有し、さらにメモリ・オブジェクトを
指すポインタを有する第１のタスクであって、前記メモ
リ・オブジェクトにアクセスするために前記第１の組の
ポート権が前記第１のタスクにケイパビリティを授与す
る第１のタスクと、前記メモリ手段内にあって、第２の
通信ポートと第２の組のポート権とを定義する１組の属
性を有する第２のタスクと、前記メモリ手段に結合さ
れ、前記プログラム式命令を実行するプロセッサ手段
と、前記メモリ手段内にあって前記第１のタスクに関連
し、前記プロセッサ手段内での実行のために前記プログ
ラム式命令を提供する第１のスレッドと、前記プロセス
間通信手段内にあって、前記第１のタスク用の前記第１
の組のポート権と前記第２のタスク用の前記第２の組の
ポート権とを登録するケイパビリティ・エンジン手段と
を含み、前記スレッドが、前記第２のタスクに前記ポイ
ンタを提供するために、前記第１のタスクから前記プロ
セス間通信手段にメッセージを提供し、前記ケイパビリ
ティ・エンジン手段が、前記第１の組のポート権と前記
第２の組のポート権とを比較し、前記ケイパビリティ・
エンジン手段が、前記メモリ・オブジェクトにアクセス
するための前記ケイパビリティを前記第２のタスクに授
与するために、前記第１のタスクから前記第２のタスク
へ前記ポインタと前記第１のポート権とを転送できるよ
うにする、プロセス間通信用のシステム。 （８）前記第１のタスクがアプリケーション・プログラ
ムを表すことを特徴とする、上記（７）に記載のマイク
ロカーネル・アーキテクチャにおけるプロセス間通信用
のシステム。 （９）前記第１のタスクがオペレーティング・システム
・パーソナリティ・プログラムを表すことを特徴とす
る、上記（７）に記載のマイクロカーネル・アーキテク
チャにおけるプロセス間通信用のシステム。 （１０）前記第１のタスクがパーソナリティ・ニュート
ラル・サービス・プログラムを表すことを特徴とする、
上記（７）に記載のマイクロカーネル・アーキテクチャ
におけるプロセス間通信用のシステム。 （１１）共用メモリ・マルチプロセッサにおけるプロセ
ス間通信用のシステムであって、データ処理システム内
にあって、データおよびプログラム式命令を格納するメ
モリ手段と、前記メモリ手段内にあって、前記メモリ手
段内の複数のタスク間の動作を調整するマイクロカーネ
ル手段と、前記マイクロカーネル手段内にあって、前記
メモリ手段内の複数のタスク間のメッセージ引渡しを調
整するプロセス間通信手段と、前記メモリ手段内にあっ
て、第１の通信ポートと第１の組のポート権とを定義す
る１組の属性を有し、さらにメモリ・オブジェクトを指
すポインタを有する第１のタスクであって、前記メモリ
・オブジェクトにアクセスするために前記第１の組のポ
ート権が前記第１のタスクにケイパビリティを授与する
第１のタスクと、前記メモリ手段に結合され、前記プロ
グラム式命令を実行する第１のプロセッサ手段と、前記
メモリ手段内にあって前記第１のタスクに関連し、前記
第１のプロセッサ手段内での実行のために前記プログラ
ム式命令を提供する第１のスレッドと、前記メモリ手段
内にあって、第２の通信ポートと第２の組のポート権と
を定義する１組の属性を有する第２のタスクと、前記メ
モリ手段に結合され、前記プログラム式命令を実行する
第２のプロセッサ手段と、前記メモリ手段内にあって前
記第２のタスクに関連し、前記第２のプロセッサ手段内
での実行のために前記プログラム式命令を提供する第２
のスレッドと、前記プロセス間通信手段内にあって、前
記第１のタスク用の前記第１の組のポート権と前記第２
のタスク用の前記第２の組のポート権とを登録するケイ
パビリティ・エンジン手段とを含み、前記第１のスレッ
ドが、前記第２のタスクに前記ポインタを提供するため
に、前記第１のタスクから前記プロセス間通信手段にメ
ッセージを提供し、前記ケイパビリティ・エンジン手段
が、前記第１の組のポート権と前記第２の組のポート権
とを比較し、前記ケイパビリティ・エンジン手段が、前
記メモリ・オブジェクトにアクセスするための前記ケイ
パビリティを前記第２のタスクに授与するために、前記
第１のタスクから前記第２のタスクへ前記ポインタと前
記第１のポート権とを転送できるようにする、プロセス
間通信用のシステム。 （１２）前記第１のタスクがアプリケーション・プログ
ラムを表すことを特徴とする、上記（１１）に記載の共
用メモリ・マルチプロセッサにおけるプロセス間通信用
のシステム。 （１３）前記第１のタスクがオペレーティング・システ
ム・パーソナリティ・プログラムを表すことを特徴とす
る、上記（１１）に記載の共用メモリ・マルチプロセッ
サにおけるプロセス間通信用のシステム。 （１４）前記第１のタスクがパーソナリティ・ニュート
ラル・サービス・プログラムを表すことを特徴とする、
上記（１１）に記載の共用メモリ・マルチプロセッサに
おけるプロセス間通信用のシステム。 （１５）分散プロセッサ・システムにおけるプロセス間
通信用のシステムであって、分散プロセッサ・システム
の第１のホスト・システム内にあって、データおよびプ
ログラム式命令を格納するメモリ手段と、前記メモリ手
段内にあって、前記メモリ手段内の複数のタスク間の動
作を調整するマイクロカーネル手段と、前記マイクロカ
ーネル手段内にあって、前記メモリ手段内の複数のタス
ク間のメッセージ引渡しを調整するプロセス間通信手段
と、前記メモリ手段内にあって、第１の通信ポートと第
１の組のポート権とを定義する１組の属性を有し、さら
にメモリ・オブジェクトを指すポインタを有する第１の
タスクであって、前記メモリ・オブジェクトにアクセス
するために前記第１の組のポート権が前記第１のタスク
にケイパビリティを授与する第１のタスクと、前記第１
のホスト・システム内にあって前記メモリ手段に結合さ
れ、前記プログラム式命令を実行する第１のプロセッサ
手段と、前記メモリ手段内にあって前記第１のタスクに
関連し、前記第１のプロセッサ手段内での実行のために
前記プログラム式命令を提供する第１のスレッドと、前
記メモリ手段内にあって、第２の通信ポートと第２の組
のポート権とを定義する１組の属性を有する第２のタス
クと、前記メモリ手段内にあって前記第２のタスクに関
連し、前記第１のプロセッサ手段内での実行のために前
記プログラム式命令を提供する第２のスレッドと、前記
プロセス間通信手段内にあって、前記第１のタスク用の
前記第１の組のポート権と前記第２のタスク用の前記第
２の組のポート権とを登録するケイパビリティ・エンジ
ン手段とを含み、前記第１のスレッドが、前記第２のタ
スクに前記ポインタを提供するために、前記第１のタス
クから前記プロセス間通信手段にメッセージを提供し、
前記ケイパビリティ・エンジン手段が、前記第１の組の
ポート権と前記第２の組のポート権とを比較し、前記ケ
イパビリティ・エンジン手段が、前記メモリ・オブジェ
クトにアクセスするための前記ケイパビリティを前記第
２のタスクに授与するために、前記第１のタスクから前
記第２のタスクへ前記ポインタと前記第１のポート権と
を転送できるようにし、前記第１のホスト・システム内
の前記第１のプロセッサを前記分散プロセッサ・システ
ムの第２のホスト・システムに結合する通信リンクと、
前記第２のホスト・システム内にあって、前記通信リン
クを介して前記第１のプロセッサ手段に結合された第２
のプロセッサ手段とをさらに含み、前記第２のスレッド
が、前記第２のプロセッサ手段に前記ポインタへの参照
を提供するために、前記第２のタスクから前記通信リン
クに前記ポインタへの前記参照を提供し、前記第２のプ
ロセッサ手段が、前記通信リンクを介して前記第１のプ
ロセッサ手段から前記ポインタへの前記参照を受信し
て、前記第２のプロセッサ手段が前記第１のホスト・シ
ステム内の前記メモリ・オブジェクトにアクセスできる
ようにする、プロセス間通信用のシステム。 （１６）前記第１のタスクがアプリケーション・プログ
ラムであることを特徴とする、上記（１５）に記載の分
散プロセッサ・システムにおけるプロセス間通信用のシ
ステム。 （１７）前記第１のタスクがオペレーティング・システ
ム・パーソナリティ・プログラムであることを特徴とす
る、上記（１５）に記載の分散プロセッサ・システムに
おけるプロセス間通信用のシステム。 （１８）前記第１のタスクがパーソナリティ・ニュート
ラル・サービス・プログラムであることを特徴とする、
上記（１５）に記載の分散プロセッサ・システムにおけ
るプロセス間通信用のシステム。 （１９）マイクロカーネル・アーキテクチャにおけるプ
ロセス間通信用のシステムであって、データ処理システ
ム内にあって、データおよびプログラム式命令を格納す
るメモリ手段と、前記メモリ手段内にあって、前記メモ
リ手段内の複数のタスク間のメッセージ引渡しを調整す
るプロセス間通信手段と、前記メモリ手段内にあって、
第１の通信ポートと第１の組のポート権とを定義する１
組の属性を有し、さらにメモリ・オブジェクトを指すポ
インタを有する第１のタスクであって、前記メモリ・オ
ブジェクトにアクセスするために前記第１の組のポート
権が前記第１のタスクにケイパビリティを授与する第１
のタスクと、前記メモリ手段内にあって、第２の通信ポ
ートと第２の組のポート権とを定義する１組の属性を有
する第２のタスクと、前記メモリ手段に結合され、前記
プログラム式命令を実行するプロセッサ手段と、前記メ
モリ手段内にあって前記第１のタスクに関連し、前記プ
ロセッサ手段内での実行のために前記プログラム式命令
を提供する第１のスレッドと、前記プロセス間通信手段
内にあって、前記第１のタスク用の前記第１の組のポー
ト権と前記第２のタスク用の前記第２の組のポート権と
を登録するケイパビリティ・エンジン手段とを含み、前
記スレッドが、前記第２のタスクに前記ポインタを提供
するために、前記第１のタスクから前記プロセス間通信
手段にメッセージを提供し、前記ケイパビリティ・エン
ジン手段が、前記第１の組のポート権と前記第２の組の
ポート権とを比較し、前記ケイパビリティ・エンジン手
段が、前記メモリ・オブジェクトにアクセスするための
前記ケイパビリティを前記第２のタスクに授与するため
に、前記第１のタスクから前記第２のタスクへ前記ポイ
ンタと前記第１のポート権とを転送できるようにする、
プロセス間通信用のシステム。 （２０）前記第１のタスクがアプリケーション・プログ
ラムを表すことを特徴とする、上記（１９）に記載のマ
イクロカーネル・アーキテクチャにおけるプロセス間通
信用のシステム。 （２１）前記第１のタスクがオペレーティング・システ
ム・パーソナリティ・プログラムを表すことを特徴とす
る、上記（１９）に記載のマイクロカーネル・アーキテ
クチャにおけるプロセス間通信用のシステム。 （２２）前記第１のタスクがパーソナリティ・ニュート
ラル・サービス・プログラムを表すことを特徴とする、
上記（１９）に記載のマイクロカーネル・アーキテクチ
ャにおけるプロセス間通信用のシステム。 （２３）前記メモリ手段に結合され、前記プログラム式
命令を実行する第２のプロセッサ手段と、前記メモリ手
段内にあって前記第２のタスクに関連し、前記第２のプ
ロセッサ手段内での実行のために前記プログラム式命令
を提供する第２のスレッドとをさらに含むことを特徴と
する、上記（１９）に記載のマイクロカーネル・アーキ
テクチャにおけるプロセス間通信用のシステム。 （２４）前記メモリ手段と前記プロセッサ手段が、分散
プロセッサ・システムの第１のホスト・システム内にあ
り、前記第１のホスト・システム内の前記プロセッサ手
段を前記分散プロセッサ・システムの第２のホスト・シ
ステムに結合する通信リンクと、前記第２のホスト・シ
ステム内にあって、前記通信リンクを介して前記第１の
ホスト・システム内の前記プロセッサ手段に結合され、
前記通信リンクを介して前記ポインタへの参照を交換す
る第２のプロセッサ手段とをさらに含むことを特徴とす
る、上記（１９）に記載のマイクロカーネル・アーキテ
クチャにおけるプロセス間通信用のシステム。
【０３２４】
【発明の効果】プロセス間通信のクライアントとサーバ
の間で高速かつ効率の良い通信を実現するマイクロカー
ネル・アーキテクチャを提供する。
【図面の簡単な説明】
【図１】マイクロカーネルおよびパーソナリティ・ニュ
ートラル・サービス１４０が様々なハードウェア・プラ
ットフォームで複数のオペレーティング・システム・パ
ーソナリティを実行する方法を示す図である。
【図２】スレッドに関連するクライアント可視構造を示
す図である。
【図３】クライアント可視タスク構造を示す図である。
【図４】典型的なポートを示す図であり、一連の送信権
と単一受信権を示す図である。
【図５】ポート名空間に収容されているか、またはメッ
セージに入れて伝送中の一連のポート権を示す図であ
る。
【図６】クライアント可視仮想メモリ構造を示す図であ
る。
【図７】ホスト・マルチプロセッサ・システムの機能ブ
ロック図であり、２つのプロセッサ上でスレッドを実行
している状態でＩＰＣサブシステムとケイパビリティ・
エンジンが２つのタスク間のプロセス間通信を管理する
場合を示す図である。
【図８】分散処理配置で動作する２つのホスト・マルチ
プロセッサ・システムの機能ブロック図である。
【図９】ＩＰＣによる単純なメッセージ転送を示す図で
ある。
【図１０】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１１】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１２】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１３】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１４】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１５】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１６】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１７】ケイパビリティ・エンジンとメッセージ引渡
しライブラリとを使用するメッセージ転送の例を示す図
である。
【図１８】メッセージ・レイアウトの概要を示す図であ
る。
【図１９】代理人ユーザ・レベル・ライブラリの典型的
な呼出しを示す図である。
【図２０】メッセージ制御構造を示す図である。
【図２１】メッセージ・ヘッダ構造を示す図である。
【図２２】トラステッド・クライアント／既知メッセー
ジＩＤの例を示す図である。
【図２３】非トラステッド・クライアント／既知メッセ
ージＩＤの例を示す図である。
【図２４】メッセージ形式登録を示す図である。
【図２５】上書きバッファ動作を示す図である。
【図２６】ＲＰＣ転送を示す図である。
【図２７】ケイパビリティ・エンジンによる待ち行列サ
ポートを示す図である。
【図２８】多重化サーバの基本実行ループを示す図であ
る。
【図２９】メッセージ引渡しライブラリの無名応答アル
ゴリズムを示す図である。
【図３０】共用領域の初期設定を示す図である。
【図３１】ＲＰＣ共通ケースでの共用領域の使用法を示
す図である。
【符号の説明】
１００ ホスト・マルチプロセッサ １０２ メモリ １０４ バス １０６ 補助記憶装置 １０８ 入出力アダプタ １１０ プロセッサＡ １１２ プロセッサＢ １１５ マイクロカーネル・システム １２０ マイクロカーネル １２２ ＩＰＣサブシステム １４０ パーソナリティ・ニュートラル・サービス １５０ パーソナリティ・サーバ １８０ アプリケーション・プログラム ２１０ タスク（Ａ） ２１０' タスク（Ｂ） ２２０ メッセージ引渡しライブラリ ２３２ 呼出しスケジューラ ２４２ データ・オブジェクト ２４４ メッセージ入力 ２４６ メッセージ出力 ２４８ スレッド ２４８' スレッド ３００ ケイパビリティ・エンジン ４００ 一時データ・モジュール ５００ 制御登録モジュール ６００ 非同期応答モジュール ７００ 伝送制御分離モジュール ８００ 共用メモリ・サポート ９００ 高速パス・モジュール
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ガイ・ジル・ソトマイヤー・ジュニア アメリカ合衆国33415 フロリダ州ウェ スト・パーム・ビーチ シャーウッド・ グレン・ウェイ 6042 アパートメント ３ (72)発明者 クリストファー・ディーン・ヤングワー ス アメリカ合衆国61874 イリノイ州サヴ ォイ ガルフビュー・コート ナンバー ３ (56)参考文献 特開 平３−257571（ＪＰ，Ａ) 米国特許4387427（ＵＳ，Ａ) ＰＲＯＣＥＥＤＩＮＧ ＯＦ ＴＨＥ ＣＯＭＰＵＴＥＲ ＳＣＯＩＥＴＹ ＳＹＭＰＯＳＩＵＭ ＯＮ ＲＥＳＥＡ ＲＣＨ ＩＮ ＳＥＣＵＲＩＴＹ ＡＮ Ｄ ＰＲＩＶＡＣＹ ＭＡＹ 24−26 1993 ｐ206−218

Claims (24)

    (57)【特許請求の範囲】
  1. 【請求項１】マイクロカーネル・アーキテクチャ・デー
    タ処理システムにおけるプロセス間通信方法であって、 ケイパビリティ・エンジン・モジュールを含むマイクロ
    カーネルをデータ処理システムのメモリにロードするス
    テップと、 第１の通信ポートと第１の組のポート権とを定義する１
    組の属性を有し、さらにメモリ・オブジェクトを指すポ
    インタを有する第１のタスク・コンテナを前記マイクロ
    カーネルによって前記メモリ内に形成するステップであ
    って、前記メモリ・オブジェクトにアクセスするために
    前記第１の組のポート権が前記第１のタスク・コンテナ
    にケイパビリティを授与するステップと、 第２の通信ポートと第２の組のポート権とを定義する１
    組の属性を有する第２のタスク・コンテナを前記マイク
    ロカーネルによって前記メモリ内に形成するステップ
    と、 前記第１のタスク・コンテナ用の前記第１の組のポート
    権と前記第２のタスク・コンテナ用の前記第２の組のポ
    ート権とを前記ケイパビリティ・エンジンに登録するス
    テップと、 前記ケイパビリティ・エンジン内で前記第１の組のポー
    ト権と前記第２の組のポート権とを比較するステップ
    と、 前記メモリ・オブジェクトにアクセスするための前記ケ
    イパビリティを前記第２のタスク・コンテナに授与する
    ために、前記第１のタスク・コンテナから前記第２のタ
    スク・コンテナへ前記ケイパビリティ・エンジンによっ
    て前記ポインタと前記第１のポート権とを転送できるよ
    うにするステップとを含むプロセス間通信方法。
  2. 【請求項２】マイクロカーネル・オペレーティング・シ
    ステムを実行する共用メモリ・マルチプロセッサ・シス
    テムにおけるプロセス間通信方法であって、 第１のプロセッサと第２のプロセッサとを含むマルチプ
    ロセッサ・データ処理システムの共用メモリにマイクロ
    カーネルをロードするステップであって、前記マイクロ
    カーネルがケイパビリティ・エンジン・モジュールを含
    むステップと、 第１の通信ポートと第１の組のポート権とを定義する１
    組の属性を有し、さらにメモリ・オブジェクトを指すポ
    インタを有する第１のタスク・コンテナを前記マイクロ
    カーネルによって前記メモリ内に形成するステップであ
    って、前記メモリ・オブジェクトにアクセスするために
    前記第１の組のポート権が前記第１のタスク・コンテナ
    にケイパビリティを授与し、前記第１のタスク・コンテ
    ナが前記第１のプロセッサ上で動作するスレッドを有す
    るステップと、 第２の通信ポートと第２の組のポート権とを定義する１
    組の属性を有する第２のタスク・コンテナを前記マイク
    ロカーネルによって前記メモリ内に形成するステップで
    あって、前記第２のタスク・コンテナが前記第２のプロ
    セッサ上で動作するスレッドを有するステップと、 前記第１のタスク・コンテナ用の前記第１の組のポート
    権と前記第２のタスク・コンテナ用の前記第２の組のポ
    ート権とを前記ケイパビリティ・エンジンに登録するス
    テップと、 前記ケイパビリティ・エンジン内で前記第１の組のポー
    ト権と前記第２の組のポート権とを比較するステップ
    と、 前記メモリ・オブジェクトにアクセスするための前記ケ
    イパビリティを前記第２のタスク・コンテナに授与する
    ために、前記第１のタスク・コンテナから前記第２のタ
    スク・コンテナへ前記ケイパビリティ・エンジンによっ
    て前記ポインタと前記第１のポート権とを転送できるよ
    うにし、それにより、前記第１のプロセッサが前記第２
    のプロセッサと通信できるようにするステップとを含む
    プロセス間通信方法。
  3. 【請求項３】それぞれがマイクロカーネル・オペレーテ
    ィング・システムを実行する第１のプロセッサと第２の
    プロセッサとを含む分散プロセッサ・システムにおける
    プロセス間通信方法であって、 分散データ処理システム内の第１のプロセッサのメモリ
    に第１のマイクロカーネルをロードするステップであ
    り、前記第１のマイクロカーネルがケイパビリティ・エ
    ンジン・モジュールを含むステップと、 第１の通信ポートと第１の組のポート権とを定義する１
    組の属性を有し、さらにメモリ・オブジェクトを指すポ
    インタを有する第１のタスク・コンテナを前記第１のマ
    イクロカーネルによって前記メモリ内に形成するステッ
    プであり、前記メモリ・オブジェクトにアクセスするた
    めに前記第１の組のポート権が前記第１のタスク・コン
    テナにケイパビリティを授与し、前記第１のタスク・コ
    ンテナが前記第１のプロセッサ上で動作するスレッドを
    有するステップと、 第２の通信ポートと第２の組のポート権とを定義する１
    組の属性を有する第２のタスク・コンテナを前記第１の
    マイクロカーネルによって前記メモリ内に形成するステ
    ップであり、前記第２のタスク・コンテナが入出力通信
    プロセッサ上で動作するスレッドを有し、前記入出力プ
    ロセッサが第２のマイクロカーネル・オペレーティング
    ・システムを実行する第２のデータ・プロセッサに通信
    リンクによって結合されているステップと、 前記第１のタスク・コンテナ用の前記第１の組のポート
    権と前記第２のタスク・コンテナ用の前記第２の組のポ
    ート権とを前記ケイパビリティ・エンジンに登録するス
    テップと、 前記ケイパビリティ・エンジン内で前記第１の組のポー
    ト権と前記第２の組のポート権とを比較するステップ
    と、 前記メモリ・オブジェクトにアクセスするための前記ケ
    イパビリティを前記第２のタスク・コンテナに授与する
    ために、前記第１のタスク・コンテナから前記第２のタ
    スク・コンテナへ前記ケイパビリティ・エンジンによっ
    て前記ポインタと前記第１のポート権とを転送できるよ
    うにし、それにより、前記第１のプロセッサが前記入出
    力通信プロセッサと通信できるようにするステップと、 前記メモリ・オブジェクトにアクセスするための前記ケ
    イパビリティを前記第２のプロセッサに授与するため
    に、前記入出力通信プロセッサから前記第２のプロセッ
    サへ前記ポインタと前記第１のポート権とを転送するス
    テップとを含むプロセス間通信方法。
  4. 【請求項４】マイクロカーネル・アーキテクチャ・デー
    タ処理システムにおけるプロセス間通信用のサブシステ
    ムであって、 データ処理システムのメモリ内のケイパビリティ・エン
    ジン・モジュールを含むマイクロカーネルと、 前記メモリ内にあって、第１の通信ポートと第１の組の
    ポート権とを定義する１組の属性を有し、さらにメモリ
    ・オブジェクトを指すポインタを有する第１のタスク・
    コンテナであって、前記メモリ・オブジェクトにアクセ
    スするために前記第１の組のポート権が前記第１のタス
    ク・コンテナにケイパビリティを授与する第１のタスク
    ・コンテナと、 前記メモリ内にあって、第２の通信ポートと第２の組の
    ポート権とを定義する１組の属性を有する第２のタスク
    ・コンテナとを含み、 前記ケイパビリティ・エンジンが、前記第１のタスク・
    コンテナ用の前記第１の組のポート権と前記第２のタス
    ク・コンテナ用の前記第２の組のポート権とを登録し、 前記ケイパビリティ・エンジンが、前記第１の組のポー
    ト権と前記第２の組のポート権とを比較し、 前記ケイパビリティ・エンジンが、前記メモリ・オブジ
    ェクトにアクセスするための前記ケイパビリティを前記
    第２のタスク・コンテナに授与するために、前記第１の
    タスク・コンテナから前記第２のタスク・コンテナへ前
    記ポインタと前記第１のポート権とを転送できるように
    する、プロセス間通信用のサブシステム。
  5. 【請求項５】マイクロカーネル・オペレーティング・シ
    ステムを実行する共用メモリ・マルチプロセッサ・シス
    テムにおけるプロセス間通信用のサブシステムであっ
    て、 マルチプロセッサ・システム内のメモリを共用する第１
    のプロセッサおよび第２のプロセッサと、 前記共用メモリ内にあって、ケイパビリティ・エンジン
    ・モジュールを含むマイクロカーネルと、 前記メモリ内にあって、第１の通信ポートと第１の組の
    ポート権とを定義する１組の属性を有し、さらにメモリ
    ・オブジェクトを指すポインタを有する第１のタスク・
    コンテナであって、前記メモリ・オブジェクトにアクセ
    スするために前記第１の組のポート権が前記第１のタス
    ク・コンテナにケイパビリティを授与し、前記第１のタ
    スク・コンテナが前記第１のプロセッサ上で動作するス
    レッドを有する第１のタスク・コンテナと、 前記メモリ内にあって、第２の通信ポートと第２の組の
    ポート権とを定義する１組の属性を有する第２のタスク
    ・コンテナであって、前記第２のタスク・コンテナが前
    記第２のプロセッサ上で動作するスレッドを有する第２
    のタスク・コンテナとを含み、 前記ケイパビリティ・エンジンが、前記第１のタスク・
    コンテナ用の前記第１の組のポート権と前記第２のタス
    ク・コンテナ用の前記第２の組のポート権とを登録し、 前記ケイパビリティ・エンジンが、前記第１の組のポー
    ト権と前記第２の組のポート権とを比較し、 前記ケイパビリティ・エンジンが、前記メモリ・オブジ
    ェクトにアクセスするための前記ケイパビリティを前記
    第２のタスク・コンテナに授与するために、前記第１の
    タスク・コンテナから前記第２のタスク・コンテナへ前
    記ポインタと前記第１のポート権とを転送できるように
    し、それにより、前記第１のプロセッサが前記第２のプ
    ロセッサと通信できるようにする、プロセス間通信用の
    サブシステム。
  6. 【請求項６】分散プロセッサ・システムにおけるプロセ
    ス間通信用のサブシステムであって、 通信リンクによって結合され、それぞれがマイクロカー
    ネル・オペレーティング・システムを実行する第１のプ
    ロセッサおよび第２のプロセッサと、 前記第１のプロセッサのメモリ内にあって、ケイパビリ
    ティ・エンジン・モジュールを含む第１のマイクロカー
    ネルと、 前記メモリ内にあって、第１の通信ポートと第１の組の
    ポート権とを定義する１組の属性を有し、さらにメモリ
    ・オブジェクトを指すポインタを有する第１のタスク・
    コンテナであって、前記メモリ・オブジェクトにアクセ
    スするために前記第１の組のポート権が前記第１のタス
    ク・コンテナにケイパビリティを授与し、前記第１のタ
    スク・コンテナが前記第１のプロセッサ上で動作するス
    レッドを有する第１のタスク・コンテナと、 前記第１のプロセッサと前記メモリを共用し、前記通信
    リンクによって前記第２のプロセッサと結合されている
    入出力プロセッサと、 前記メモリ内にあって、第２の通信ポートと第２の組の
    ポート権とを定義する１組の属性を有する第２のタスク
    ・コンテナであって、前記第２のタスク・コンテナが前
    記入出力通信プロセッサ上で動作するスレッドを有する
    第２のタスク・コンテナとを含み、 前記ケイパビリティ・エンジンが、前記第１のタスク・
    コンテナ用の前記第１の組のポート権と前記第２のタス
    ク・コンテナ用の前記第２の組のポート権とを登録し、 前記ケイパビリティ・エンジンが、前記第１の組のポー
    ト権と前記第２の組のポート権とを比較し、 前記ケイパビリティ・エンジンが、前記メモリ・オブジ
    ェクトにアクセスするための前記ケイパビリティを前記
    第２のタスク・コンテナに授与するために、前記第１の
    タスク・コンテナから前記第２のタスク・コンテナへ前
    記ポインタと前記第１のポート権とを転送できるように
    し、それにより、前記第１のプロセッサが前記入出力通
    信プロセッサと通信できるようにし、 前記第２のプロセッサが、第２のマイクロカーネル・オ
    ペレーティング・システムを実行し、 前記入出力通信プロセッサが、前記メモリ・オブジェク
    トにアクセスするための前記ケイパビリティを前記第２
    のプロセッサに授与するために、前記第２のプロセッサ
    に前記ポインタと前記第１のポート権とを転送する、プ
    ロセス間通信用のサブシステム。
  7. 【請求項７】マイクロカーネル・アーキテクチャにおけ
    るプロセス間通信用のシステムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、第１の通信ポートと第１の
    組のポート権とを定義する１組の属性を有し、さらにメ
    モリ・オブジェクトを指すポインタを有する第１のタス
    クであって、前記メモリ・オブジェクトにアクセスする
    ために前記第１の組のポート権が前記第１のタスクにケ
    イパビリティを授与する第１のタスクと、 前記メモリ手段内にあって、第２の通信ポートと第２の
    組のポート権とを定義する１組の属性を有する第２のタ
    スクと、 前記メモリ手段に結合され、前記プログラム式命令を実
    行するプロセッサ手段と、 前記メモリ手段内にあって前記第１のタスクに関連し、
    前記プロセッサ手段内での実行のために前記プログラム
    式命令を提供する第１のスレッドと、 前記プロセス間通信手段内にあって、前記第１のタスク
    用の前記第１の組のポート権と前記第２のタスク用の前
    記第２の組のポート権とを登録するケイパビリティ・エ
    ンジン手段とを含み、 前記スレッドが、前記第２のタスクに前記ポインタを提
    供するために、前記第１のタスクから前記プロセス間通
    信手段にメッセージを提供し、 前記ケイパビリティ・エンジン手段が、前記第１の組の
    ポート権と前記第２の組のポート権とを比較し、 前記ケイパビリティ・エンジン手段が、前記メモリ・オ
    ブジェクトにアクセスするための前記ケイパビリティを
    前記第２のタスクに授与するために、前記第１のタスク
    から前記第２のタスクへ前記ポインタと前記第１のポー
    ト権とを転送できるようにする、プロセス間通信用のシ
    ステム。
  8. 【請求項８】前記第１のタスクがアプリケーション・プ
    ログラムを表すことを特徴とする、請求項７に記載のマ
    イクロカーネル・アーキテクチャにおけるプロセス間通
    信用のシステム。
  9. 【請求項９】前記第１のタスクがオペレーティング・シ
    ステム・パーソナリティ・プログラムを表すことを特徴
    とする、請求項７に記載のマイクロカーネル・アーキテ
    クチャにおけるプロセス間通信用のシステム。
  10. 【請求項１０】前記第１のタスクがパーソナリティ・ニ
    ュートラル・サービス・プログラムを表すことを特徴と
    する、請求項７に記載のマイクロカーネル・アーキテク
    チャにおけるプロセス間通信用のシステム。
  11. 【請求項１１】共用メモリ・マルチプロセッサにおける
    プロセス間通信用のシステムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、第１の通信ポートと第１の
    組のポート権とを定義する１組の属性を有し、さらにメ
    モリ・オブジェクトを指すポインタを有する第１のタス
    クであって、前記メモリ・オブジェクトにアクセスする
    ために前記第１の組のポート権が前記第１のタスクにケ
    イパビリティを授与する第１のタスクと、 前記メモリ手段に結合され、前記プログラム式命令を実
    行する第１のプロセッサ手段と、 前記メモリ手段内にあって前記第１のタスクに関連し、
    前記第１のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第１のスレッドと、 前記メモリ手段内にあって、第２の通信ポートと第２の
    組のポート権とを定義する１組の属性を有する第２のタ
    スクと、 前記メモリ手段に結合され、前記プログラム式命令を実
    行する第２のプロセッサ手段と、 前記メモリ手段内にあって前記第２のタスクに関連し、
    前記第２のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第２のスレッドと、 前記プロセス間通信手段内にあって、前記第１のタスク
    用の前記第１の組のポート権と前記第２のタスク用の前
    記第２の組のポート権とを登録するケイパビリティ・エ
    ンジン手段とを含み、 前記第１のスレッドが、前記第２のタスクに前記ポイン
    タを提供するために、前記第１のタスクから前記プロセ
    ス間通信手段にメッセージを提供し、 前記ケイパビリティ・エンジン手段が、前記第１の組の
    ポート権と前記第２の組のポート権とを比較し、 前記ケイパビリティ・エンジン手段が、前記メモリ・オ
    ブジェクトにアクセスするための前記ケイパビリティを
    前記第２のタスクに授与するために、前記第１のタスク
    から前記第２のタスクへ前記ポインタと前記第１のポー
    ト権とを転送できるようにする、プロセス間通信用のシ
    ステム。
  12. 【請求項１２】前記第１のタスクがアプリケーション・
    プログラムを表すことを特徴とする、請求項１１に記載
    の共用メモリ・マルチプロセッサにおけるプロセス間通
    信用のシステム。
  13. 【請求項１３】前記第１のタスクがオペレーティング・
    システム・パーソナリティ・プログラムを表すことを特
    徴とする、請求項１１に記載の共用メモリ・マルチプロ
    セッサにおけるプロセス間通信用のシステム。
  14. 【請求項１４】前記第１のタスクがパーソナリティ・ニ
    ュートラル・サービス・プログラムを表すことを特徴と
    する、請求項１１に記載の共用メモリ・マルチプロセッ
    サにおけるプロセス間通信用のシステム。
  15. 【請求項１５】分散プロセッサ・システムにおけるプロ
    セス間通信用のシステムであって、 分散プロセッサ・システムの第１のホスト・システム内
    にあって、データおよびプログラム式命令を格納するメ
    モリ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間の動作を調整するマイクロカーネル手段と、 前記マイクロカーネル手段内にあって、前記メモリ手段
    内の複数のタスク間のメッセージ引渡しを調整するプロ
    セス間通信手段と、 前記メモリ手段内にあって、第１の通信ポートと第１の
    組のポート権とを定義する１組の属性を有し、さらにメ
    モリ・オブジェクトを指すポインタを有する第１のタス
    クであって、前記メモリ・オブジェクトにアクセスする
    ために前記第１の組のポート権が前記第１のタスクにケ
    イパビリティを授与する第１のタスクと、 前記第１のホスト・システム内にあって前記メモリ手段
    に結合され、前記プログラム式命令を実行する第１のプ
    ロセッサ手段と、 前記メモリ手段内にあって前記第１のタスクに関連し、
    前記第１のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第１のスレッドと、 前記メモリ手段内にあって、第２の通信ポートと第２の
    組のポート権とを定義する１組の属性を有する第２のタ
    スクと、 前記メモリ手段内にあって前記第２のタスクに関連し、
    前記第１のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第２のスレッドと、 前記プロセス間通信手段内にあって、前記第１のタスク
    用の前記第１の組のポート権と前記第２のタスク用の前
    記第２の組のポート権とを登録するケイパビリティ・エ
    ンジン手段とを含み、 前記第１のスレッドが、前記第２のタスクに前記ポイン
    タを提供するために、前記第１のタスクから前記プロセ
    ス間通信手段にメッセージを提供し、 前記ケイパビリティ・エンジン手段が、前記第１の組の
    ポート権と前記第２の組のポート権とを比較し、 前記ケイパビリティ・エンジン手段が、前記メモリ・オ
    ブジェクトにアクセスするための前記ケイパビリティを
    前記第２のタスクに授与するために、前記第１のタスク
    から前記第２のタスクへ前記ポインタと前記第１のポー
    ト権とを転送できるようにし、 前記第１のホスト・システム内の前記第１のプロセッサ
    を前記分散プロセッサ・システムの第２のホスト・シス
    テムに結合する通信リンクと、 前記第２のホスト・システム内にあって、前記通信リン
    クを介して前記第１のプロセッサ手段に結合された第２
    のプロセッサ手段とをさらに含み、 前記第２のスレッドが、前記第２のプロセッサ手段に前
    記ポインタへの参照を提供するために、前記第２のタス
    クから前記通信リンクに前記ポインタへの前記参照を提
    供し、 前記第２のプロセッサ手段が、前記通信リンクを介して
    前記第１のプロセッサ手段から前記ポインタへの前記参
    照を受信して、前記第２のプロセッサ手段が前記第１の
    ホスト・システム内の前記メモリ・オブジェクトにアク
    セスできるようにする、プロセス間通信用のシステム。
  16. 【請求項１６】前記第１のタスクがアプリケーション・
    プログラムであることを特徴とする、請求項１５に記載
    の分散プロセッサ・システムにおけるプロセス間通信用
    のシステム。
  17. 【請求項１７】前記第１のタスクがオペレーティング・
    システム・パーソナリティ・プログラムであることを特
    徴とする、請求項１５に記載の分散プロセッサ・システ
    ムにおけるプロセス間通信用のシステム。
  18. 【請求項１８】前記第１のタスクがパーソナリティ・ニ
    ュートラル・サービス・プログラムであることを特徴と
    する、請求項１５に記載の分散プロセッサ・システムに
    おけるプロセス間通信用のシステム。
  19. 【請求項１９】マイクロカーネル・アーキテクチャにお
    けるプロセス間通信用のシステムであって、 データ処理システム内にあって、データおよびプログラ
    ム式命令を格納するメモリ手段と、 前記メモリ手段内にあって、前記メモリ手段内の複数の
    タスク間のメッセージ引渡しを調整するプロセス間通信
    手段と、 前記メモリ手段内にあって、第１の通信ポートと第１の
    組のポート権とを定義する１組の属性を有し、さらにメ
    モリ・オブジェクトを指すポインタを有する第１のタス
    クであって、前記メモリ・オブジェクトにアクセスする
    ために前記第１の組のポート権が前記第１のタスクにケ
    イパビリティを授与する第１のタスクと、 前記メモリ手段内にあって、第２の通信ポートと第２の
    組のポート権とを定義する１組の属性を有する第２のタ
    スクと、 前記メモリ手段に結合され、前記プログラム式命令を実
    行するプロセッサ手段と、 前記メモリ手段内にあって前記第１のタスクに関連し、
    前記プロセッサ手段内での実行のために前記プログラム
    式命令を提供する第１のスレッドと、 前記プロセス間通信手段内にあって、前記第１のタスク
    用の前記第１の組のポート権と前記第２のタスク用の前
    記第２の組のポート権とを登録するケイパビリティ・エ
    ンジン手段とを含み、 前記スレッドが、前記第２のタスクに前記ポインタを提
    供するために、前記第１のタスクから前記プロセス間通
    信手段にメッセージを提供し、 前記ケイパビリティ・エンジン手段が、前記第１の組の
    ポート権と前記第２の組のポート権とを比較し、 前記ケイパビリティ・エンジン手段が、前記メモリ・オ
    ブジェクトにアクセスするための前記ケイパビリティを
    前記第２のタスクに授与するために、前記第１のタスク
    から前記第２のタスクへ前記ポインタと前記第１のポー
    ト権とを転送できるようにする、プロセス間通信用のシ
    ステム。
  20. 【請求項２０】前記第１のタスクがアプリケーション・
    プログラムを表すことを特徴とする、請求項１９に記載
    のマイクロカーネル・アーキテクチャにおけるプロセス
    間通信用のシステム。
  21. 【請求項２１】前記第１のタスクがオペレーティング・
    システム・パーソナリティ・プログラムを表すことを特
    徴とする、請求項１９に記載のマイクロカーネル・アー
    キテクチャにおけるプロセス間通信用のシステム。
  22. 【請求項２２】前記第１のタスクがパーソナリティ・ニ
    ュートラル・サービス・プログラムを表すことを特徴と
    する、請求項１９に記載のマイクロカーネル・アーキテ
    クチャにおけるプロセス間通信用のシステム。
  23. 【請求項２３】前記メモリ手段に結合され、前記プログ
    ラム式命令を実行する第２のプロセッサ手段と、 前記メモリ手段内にあって前記第２のタスクに関連し、
    前記第２のプロセッサ手段内での実行のために前記プロ
    グラム式命令を提供する第２のスレッドとをさらに含む
    ことを特徴とする、請求項１９に記載のマイクロカーネ
    ル・アーキテクチャにおけるプロセス間通信用のシステ
    ム。
  24. 【請求項２４】前記メモリ手段と前記プロセッサ手段
    が、分散プロセッサ・システムの第１のホスト・システ
    ム内にあり、 前記第１のホスト・システム内の前記プロセッサ手段を
    前記分散プロセッサ・システムの第２のホスト・システ
    ムに結合する通信リンクと、 前記第２のホスト・システム内にあって、前記通信リン
    クを介して前記第１のホスト・システム内の前記プロセ
    ッサ手段に結合され、前記通信リンクを介して前記ポイ
    ンタへの参照を交換する第２のプロセッサ手段とをさら
    に含むことを特徴とする、請求項１９に記載のマイクロ
    カーネル・アーキテクチャにおけるプロセス間通信用の
    システム。
JP7153354A 1994-09-28 1995-06-20 プロセス間通信方法並びにプロセス間通信用のサブシステムおよびシステム Expired - Lifetime JP2986073B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US26331394A 1994-09-28 1994-09-28
US263313 1994-09-28

Publications (2)

Publication Number Publication Date
JPH08106441A JPH08106441A (ja) 1996-04-23
JP2986073B2 true JP2986073B2 (ja) 1999-12-06

Family

ID=23001263

Family Applications (1)

Application Number Title Priority Date Filing Date
JP7153354A Expired - Lifetime JP2986073B2 (ja) 1994-09-28 1995-06-20 プロセス間通信方法並びにプロセス間通信用のサブシステムおよびシステム

Country Status (6)

Country Link
EP (1) EP0704796B1 (ja)
JP (1) JP2986073B2 (ja)
KR (1) KR960002042A (ja)
AT (1) ATE191978T1 (ja)
CA (1) CA2149476A1 (ja)
DE (1) DE69516350D1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998041927A1 (fr) * 1997-03-19 1998-09-24 Hitachi, Ltd. Calculateur parallele
KR100406532B1 (ko) * 1999-07-26 2003-11-20 주식회사 케이티 내장형 시스템을 위한 운영체제 구현 방법
SG118081A1 (en) * 2000-07-24 2006-01-27 Sony Corp Information processing method inter-task communication method and computer-excutable program for thesame
SG132507A1 (en) 2001-02-16 2007-06-28 Sony Corp Data processing method and its apparatus
JP2004334537A (ja) 2003-05-07 2004-11-25 Sony Corp プログラム処理システム及びプログラム処理方法、並びにコンピュータ・プログラム
US7516455B2 (en) * 2003-09-05 2009-04-07 Microsoft Corporation Probabilistic scheduling
US7167941B2 (en) * 2003-09-10 2007-01-23 Intel Corporation Multi-port device configuration
US7568628B2 (en) 2005-03-11 2009-08-04 Hand Held Products, Inc. Bar code reading device with global electronic shutter control
US7770799B2 (en) 2005-06-03 2010-08-10 Hand Held Products, Inc. Optical reader having reduced specular reflection read failures
CN102469035B (zh) * 2010-11-05 2016-01-20 腾讯科技（深圳）有限公司 跨进程通信的方法和装置
US10305834B2 (en) * 2016-06-20 2019-05-28 Huawei Technologies Co., Ltd. System and method for messaging between operating system containers
CN111881215B (zh) * 2020-07-30 2024-02-20 浪潮云信息技术股份公司 数据同步方法、装置及系统
CN113704258B (zh) * 2021-08-20 2023-12-26 辽宁振兴银行股份有限公司 一种基于MongoDB数据库存储交易报文的方法
CN117113378A (zh) * 2023-09-12 2023-11-24 腾云创威信息科技(威海)有限公司 基于权能的负载空间隔离方法及其系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4387427A (en) * 1978-12-21 1983-06-07 Intel Corporation Hardware scheduler/dispatcher for data processing system
DE69126223T2 (de) * 1990-02-14 1997-09-18 Fujitsu Ltd System zur Erstellung eines Übertragungsweges in einem eng gekoppelten Rechnersystem

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ＰＲＯＣＥＥＤＩＮＧ ＯＦ ＴＨＥ ＣＯＭＰＵＴＥＲ ＳＣＯＩＥＴＹ ＳＹＭＰＯＳＩＵＭ ＯＮ ＲＥＳＥＡＲＣＨ ＩＮ ＳＥＣＵＲＩＴＹ ＡＮＤ ＰＲＩＶＡＣＹ ＭＡＹ ２４−２６ １９９３ ｐ２０６−２１８

Also Published As

Publication number Publication date
EP0704796A2 (en) 1996-04-03
DE69516350D1 (de) 2000-05-25
ATE191978T1 (de) 2000-05-15
JPH08106441A (ja) 1996-04-23
EP0704796A3 (en) 1998-07-01
CA2149476A1 (en) 1995-12-22
KR960002042A (ko) 1996-01-26
EP0704796B1 (en) 2000-04-19

Similar Documents

Publication Publication Date Title
JP3570525B2 (ja) マイクロカーネル・アーキテクチャ・データ処理システム及びそのメモリ管理方法、オペレーティング・システム・パーソナリティ・プログラムを走行させる方法、アプリケーション・プログラムを走行させる方法
US5771383A (en) Shared memory support method and apparatus for a microkernel data processing system
JP4791461B2 (ja) ランタイムシステムにおけるオブジェクトを共有するためのプログラム、方法、装置
Golm et al. The JX Operating System.
Massalin Synthesis: an efficient implementation of fundamental operating system services
JP3095777B2 (ja) オブジェクト指向オペレーティング・システム
JP4837660B2 (ja) ランタイムシステムにおけるオブジェクトを共有するためのプログラム、方法、装置
JP4690437B2 (ja) ネットワークアプリケーションにおける通信方法、通信装置及びそのためのプログラム
JP3095776B2 (ja) オブジェクト指向ホスト・システム
US8028298B2 (en) Systems and methods for managing shared resources in a computer system
JP2986073B2 (ja) プロセス間通信方法並びにプロセス間通信用のサブシステムおよびシステム
JP2007538325A (ja) ランタイムシステムの共有プログラム、方法、装置
JPH0855035A (ja) マイクロカーネル・データ処理システム用の伝送制御の分離の方法および装置
JP2888420B2 (ja) マルチタスク・アーキテクチャにおけるプロセス間通信方法
Gabber et al. Pebble: A component-based operating system for embedded applications
JPH0822395A (ja) マイクロカーネル・アーキテクチャ・データ処理システムにおけるプロセス間通信方法およびシステム
EP0689137A2 (en) Message control structure registration method and apparatus for a microkernel data processing system
Condict et al. Optimizing performance of Mach-based systems by server co-location: A detailed design
Appavoo et al. Utilizing Linux kernel components in K42
Schatzberg Customization and reuse in datacenter operating systems
Buhr et al. µSystem annotated reference manual
Haeberlen Managing kernel memory resources from user level
Rotta et al. Global Architecture of MyThOS
Payne Operating Systems
Law A New Protection Model for Component-Based