JP3095776B2 - オブジェクト指向ホスト・システム - Google Patents

Description

【発明の詳細な説明】 本明細書の開示事項の一部には、著作権保護の対象と
なる内容が含まれている。著作権所有者は、米国特許商
標庁の特許ファイルまたは記録に記載されている特許開
示事項を第三者がファクシミリで複製することを妨げる
ものではないが、その他の場合には、著作権に係る一切
の権利を留保する。

発明の分野 本発明は、一般的には、オブジェクト指向コンピュー
ティング環境に関し、より具体的には、ホスト・サポー
トを含む手続き型オペレーティング・システムのための
オブジェクト指向インタフェースを提供するシステムお
よび方法に関する。

発明の背景 オブジェクト指向テクノロジ（object−oriented tec
hnology−OOT）は、オブジェクト指向分析（object−or
iented analysis−OOA）、オブジェクト指向設計（obje
ct−oriented design−OOD）、およびオブジェクト指向
プログラミング（object−oriented programming−OO
P）を含んでいるのが一般的であるが、ソフトウェア開
発において最も重要な新テクノロジの１つとしてそのの
地位を確保しつつある。OOTは、プログラマの生産性と
プログラムの保守容易性を大幅に向上する能力があるこ
とがすでに実証されている。OOTでは、データとそのデ
ータに操作を加えるプロシージャがオブジェクト（obje
ct）と呼ばれるパッケージに一体化されている環境を作
ることにより、さらに、オブジェクトが明確に定義され
たメッセージング経路（messaging path）を通してのみ
相互に連絡し合うというルールを採用することにより、
従来の手続き向きプログラミング（procedureoriented
programming）がもっていた複雑さの多くを取り除いて
いる。

以下では、OOTがもつ比較的重要な側面のいくつかを
取り上げて簡単に説明する。OOTをもっと詳しく解説し
たものとして、多くの文献が公表されている。その文献
として、Grady Booch著「オブジェクト指向設計とその
アプリケーション（Object Oriented Design With Appl
ications）（Benjamin/Cummings Publishing Company,1
991）とDonald G.Firesmith著「オブジェクト指向の要
求事項分析と論理設計」（Object−Oriented Requireme
nts Analysis and Logical Design）（John Wiley ＆ S
ons,Inc.,1993）がある。OOTの基本的コンポーネントは
オブジェクトである。オブジェクトは一組のデータ（属
性）attribute）とも呼ばれる）とそのデータに操作を
加えることができる一組のオペレーション（メソッド
（method）と呼ばれる）を含んでおり、これらによって
特徴づけられている。一般的に、オブジェクトのデータ
は、そのオブジェクトのメソッドを通してのみ変更可能
になっている。

オブジェクト内のメソッドは、メッセージをそのオブ
ジェクトに渡すことにより呼び出される（invoke）（こ
のプロセスはメッセージ・パッシング（message passin
g）と呼ばれる）。メッセージはメソッド名と引数リス
ト（argument list）を特定している。オブジェクトが
メッセージを受け取ると、指定された名前のメソッドに
関連するコードは、そのメソッドの仮パラメータ（form
al parameter）が引数リストの中の対応する値とバイン
ド（bind−結び付けること）されて実行される。OOTに
おけるメソッドとメッセージ・パッシングは、手続き向
きソフトウェア環境におけるプロシージャとプロシージ
ャ・コールに類似している。しかし、プロシージャは受
け渡されたパラメータを変更し、返す働きをするのに対
し、メソッドは関連のオブジェクトの内部状態（intern
al state）を変更する働きをする（そのオブジェクトに
収められたデータを変更することにより）。データとメ
ソッドの組合せをオブジェクトに収めることを、カプセ
ル化（encapsulation）と呼んでいる。カプセル化の最
大の利点を１つだけ挙げるとすれば、それはどのオブジ
ェクトの状態も、そのオブジェクトに関連する明確に定
義されたメソッドだけによって変更できることである。
あるオブジェクトの作用（behavior）が、このように明
確に定義されたロケーションとインターフェースに限定
されていると、そのオブジェクトにおける変更（つま
り、コード変更）は、システム内の他のオブジェクトや
エレメントに及ぼす影響が最小になる。オブジェクト指
向設計とプログラミングでカプセル化を正しく行うと、
その結果得られるコードは、従来の手法で書かれたコー
ドよりもモジュール化され、保守が容易になるという別
の「派生的利点」が得られる。

オブジェクトがカプセル化されると、データ抽象化
（data abstraction）とも呼ばれている、もう１つ重要
な派生的利点が得られる。抽象化とは、細部を取り除き
オブジェクトの作用を一般化することにより、複雑なア
イデアや構造を理解しやすくすることである。ソフトウ
ェア側からみたとき、抽象化は、多くの点でハード・コ
ーディング（hard−coding）と対立している。ソフトウ
ェア・ウィンドウ操作（software windowing）を例に挙
げて説明すると、グラフィック・ユーザ・インタフェー
ス（GUI）をベースとするプログラムの中でユーザのス
クリーン上に現れるすべてのウィンドウのすべての細部
に対して、その状態と作用をすべてハード・コーディン
グしてプログラムに組み入れておく必要があるとすれ
ば、プログラムとそこに含まれるウィンドウは共に、そ
の柔軟性のほとんどすべてを失うことになる。オブジェ
クト指向システムでは、ウィンドウの概念をウィンドウ
・オブジェクトに抽象化するので、プログラマは、特定
のウィンドウをユニークなものにする具体的側面だけを
考えればよいようになっている。ドラッグし、移動する
能力といったように、すべてのウィンドウによって共有
される作用（behavior）は、すべてのウィンドウ・オブ
ジェクトによって共有することができる。

上記から導き出されたOOTのもう１つの基本的コンポ
ーネントはクラス（class）である。クラスは一組のデ
ータ属性と、そのデータ属性に操作を加えることが許さ
れる一組のオペレーション（つまり、メソッド）とを含
んでいる。各オブジェクトはあるクラスのインスタンス
（instance）である。カプセル化と抽象化の当然の結果
として、OOTは継承（inheritance）をサポートしてい
る。クラス（サブクラス（subclass）と呼ばれる）は別
のクラス（基底クラス（base class）、親クラス（pare
nt class）などと呼ばれる）から派生（derive）するこ
とができる。この場合、サブクラスは基底クラスのデー
タ属性とメソッドを継承する。サブクラスは基底クラス
のデータおよび／またはメソッドをオーバライド（over
ride）するコードや、新しいデータ属性とメソッドを追
加するコードを追加することにより基底クラスを特殊化
することができる。以上のように、継承は、作成される
サブクラスの特殊化レベルが増加していくと、抽象化が
さらに具体化していくメカニズムを表している。継承
は、OOPから得られるプログラミング効率の向上に貢献
する主要要因となっている。継承を利用すると、開発者
はアプリケーションを作成するとき新たに書く必要のあ
るコーディング量を最小にすることができる。特定のタ
スクで必要になる機能（functionality）の大部分は継
承階層内のクラスから得られるので、プログラマはプロ
グラム設計と作成をさい先よく始めることができる。オ
ブジェクト指向環境が潜在的にもう１つの欠点は、類似
している作用を示さなければならないオブジェクトが増
加していくが、これらのオブジェクトを１つのメッセー
ジ名で使用して記述をしたいことである。オブジェクト
指向グラフィック環境を例にして説明する。Drawメッセ
ージがRectangleオブジェクトへ送られると、Rectangle
オブジェクトはそのメッセージに応答して４辺をもつ形
状を描画する。他方、Triangleオブジェクトは、そのメ
ッセージに応答して３辺をもつ形状を描画する。理想的
なことは、Drawメッセージを送るオブジェクトが、メッ
セージの宛先となるオブジェクトのタイプについても、
メッセージを受け取るオブジェクトがその応答としてど
のように描画するかについても、気づかないでいること
である。この理想が達成できれば、新しい種類の形状
（例えば、六角形）をあとで追加することが比較的簡単
になり、Drawメッセージを送信するコード全体を未変更
のままにしておくことができる。

従来の手続き向き言語では、このような言語アプロー
チをとると、大混乱が起こることになる。OOT環境で
は、多態（polymorphism）という考え方が採用されてい
るので、これを支障なく行うことができる。その結果と
して、受信側オブジェクトがメッセージをどのように理
解するかを、送信側オブジェクトが全然知らなくても、
なにかを行うように他のオブジェクトに対して包括的に
指示するメソッドを書くことができる。ソフトウェア・
プログラムは、それがオブジェクト指向であるか、手続
き向きであるか、ルール・ベースのものであるかに関係
なく、ほとんど常にオペレーティング・システムとやり
とりして、オペレーティング・システムが提供するサー
ビスをアクセスしている。例えば、ソフトウェア・プロ
グラムはオペレーティング・システムとやりとりして、
メモリ内のデータをアクセスしたり、プロセッサ障害
（processor fault）に関する情報を受け取ったり、他
のプロセッサと通信したり、あるいはプロセスの実行を
スケジュールしたりすることが可能である。

従来のオペレーティング・システムは大部分が手続き
向きであり、ネイティブ手続き型インタフェース（nati
ve procedural interface）を備えている。その結果、
これらのオペレーティング・システムから提供されるサ
ービスをアクセスできるのは、それぞれの手続き型イン
タフェースによって定義されたプロシージャの使用によ
ってのみである。あるプログラムが、これらの手続き型
オペレーティング・システムの１つが提供しているサー
ビスをアクセスする必要が起こったとき、該当のオペレ
ーティング・システムのプロシージャ・コールを行うス
テートメントがそのプログラムに含まれていなければな
らない。このことは、ソフトウェア・プログラムがオブ
ジェクト指向であるか、手続き向きであるか、ルール・
ベースであるか、その他であるかに関係ない。従って、
従来のオペレーティング・システムでは、手続き向き環
境でソフトウェアが開発され、実行されている。オブジ
ェクト指向プログラムが手続き向き環境で開発され、実
行されると、OOTの利点のいくつかが失われることにな
る。これは事実である。その理由は、手続き型オペレー
ティング・システムへのすべてのアクセスが、オペレー
ティング・システムのネイティブ手続き型インタフェー
スに定義されているプロシージャ・コールを使用して実
現されなければならないからである。その結果、クラ
ス、オブジェクト、およびその他のOOTの特徴を最大限
に行かすことができなくなるので、オブジェクト指向プ
ログラムがもつモジュール性、保守容易性および再使用
可能性という利点のいくつかは失われることになる。

上記問題の１つの解決方法は、ネイティブ・オブジェ
クト指向インタフェースをもつオブジェクト指向オペレ
ーティング・システムを開発することである。これが、
最終的には、最良の解決方法となると思われるが、現時
点では、主要な手続き型オペレーティング・システムの
すべてを修正するために必要な資源が膨大になるので、
実用的な解決ではない。また、これらの手続き型オペレ
ーティング・システムをこのように修正すると、多数の
手続き向きソフトウェア・プログラムが無駄になってし
まう。そこで、なにが必要であるかというと、それはオ
ブジェクト指向アプリケーションが、ネイティブ（nati
ve:本来）手続き型インタフェースをもつ手続き型オペ
レーティング・システムと、オブジェクト指向方式でや
りとりできるようにするメカニズムである。

Schmidt著“Systems Programming with C＋＋ Wrappe
rs:Encapsulating IPC Services with Object−Oriente
d Interfaces"の記事に、ローカルおよびリモートのプ
ロセス間通信（interprocess communication）サービス
（IPC）をカプセル化するためのオブジェクト指向イン
タフェースの使用についての記述がある。Schmidtは多
くの開発者にとりIPCサービスの理解と使用が難しいと
主張し、既存の手続き型IPC・システム・ロール・イン
タフェースの複雑さが少なくても問題の一部分であると
している。Schmidtは、共通使用パターン（common usag
e pattern）に対するデフォルト値を用意することによ
り、かつ、よく起こる複数の関数をひとつの関数に結合
して、カプセル化することにより、IPCサービスを呼出
す複雑さが減少すると示唆する。Schmidtはまた、イン
タフェースを特別な手続き型オペレーション・システム
のシステム・コールに、透明にマッピングすることによ
るラッパー（wrapper）の使用が、ポータビリティを改
善すると主張する。Schmidtはホスト・システムに対す
るサポートを決して示唆や教示していない。特に、Schm
idtは、複数のプロセッサにひとつの上で実行されるひ
とつかひとつより多いオブジェクト指向アプリケーショ
ンと、手続き型オペレーティング・システムとのインタ
フェースを管理するために割当てられた複数のプロセッ
サのひとつを有し、ひとつのコンピュータ上でこれらの
複数のプロセッサを管理するオブジェクト指向技術の使
用を決して示唆や教示していない。Schmidtは、アプリ
ケーション・プログリャムが、ブート情報とホスト統計
を得たり、コンピュータをブートしたり、ホスト・コン
ピュータの特権プロセッサ特性を定義することを可能に
するオブジェクト指向技術の使用について、決して示唆
や教示をしていない。また、Schmidtは、アプリケーシ
ョン・プログラムが、スケジューリング・ポリシーを許
可したり禁止したり、複数のプロセッサのどれかに最高
優先度をつけたり、あるいはプロセッサのどれかひとつ
の上で実行するタスクとスレッドを定義することを可能
にするオブジェクト指向技術の使用について、決して示
唆や教示をしていない。Schmidtは、アプリケーション
・プログラムに複数のプロセッサの各々に関連した情報
を得ることを可能にするオブジェクト指向技術の使用に
ついて、決して示唆や教示していない。さらに、Schmid
tは、オブジェクト指向ステートメントに対応する実行
可能プログラム・ロジックをアプリケーション・プログ
ラムに挿入して、アプリケーション・プログラムの実行
時（run−time）実行中に、アプリケーション・プログ
ラムがオブジェクト指向方法でオペレーティング・シス
テム・サービスにアクセスさせることについて述べてい
ない。したがって、必要なことは、アプリケーションの
実行時（run−time）実行中に、オブジェクト指向アプ
リケーションがネイティブ手続き型インタフェースをも
つ手続き型オペレーティング・システムとオブジェクト
指向方法で対話するのを可能にし、ホスト・システムに
対するサポートを含み、オブジェクト指向ステートメン
トに対応する実行可能プログラム・ロジックをアプリケ
ーション・プログラムに挿入する手段を含み、手続き型
オペレーティング・システム・サービスへのオブジェク
ト指向アクセスを可能にするメカニズムである。

発明の概要 本発明は、ネイティブ手続き型インタフェースをもつ
手続き型オペレーティング・システムを、オブジェクト
指向アプリケーションがオブジェクト指向方式でアクセ
スできるようにするシステムおよび方法を提供すること
を目的としている。システムはホスト・システムをサポ
ートするコンピュータとコンピュータ内のメモリ・コン
ポーネント（構成要素）を装備している。コード・ライ
ブラリ（code library）はメモリ・コンポーネントにス
トアされている。このコード・ライブラリは、オブジェ
クト指向クラス・ライブラリを実現するコンピュータ・
プログラム・ロジックを含んでいる。オブジェクト指向
クラス・ライブラリは、オペレーティング・システムか
ら提供されるサービスを、アプリケーションがオブジェ
クト指向方式でアクセスできるようにする、相互に関係
をもつオブジェクト指向クラスから構成されている。オ
ブジェクト指向クラスは、オペレーティング・システム
のネイティブ手続き型インタフェースと互換性のある手
続き型関数コール（procedural function call）を使用
してオペレーティング・システムのサービスをアクセス
するためのメソッドを含んでいる。さらにシステムは、
アプリケーションに含まれていてクラス・ライブラリに
よって定義されたオブジェクト指向ステートメントを、
そのオブジェクト指向ステートメントに対応するクラス
・ライブラリ内のメソッドを実行することによって処理
する手段も備えている。

好ましくは、クラス・ライブラリは次のものを含んで
いる。

（１）スレッド・クラス（thread class）。これは、ア
プリケーションがオペレーティング・システムのサービ
スをオブジェクト指向方式でアクセスして、スレッドに
関する情報を作成し、管理し、取得することを可能にす
るものである。

（２）タスク・クラス（task class）。これは、アプリ
ケーションがオペレーティング・システムのサービスを
オブジェクト指向方式でアクセスして、タスクを参照
し、管理することを可能にするもので、タスクの各々
は、それぞれがタスクに関連づけられているスレッドの
実行環境を表している。

（３）バーチャル（仮想）メモリ・クラス（virtual me
mory class）。これは、アプリケーションがオペレーテ
ィング・システムのサービスをオブジェクト取指向方式
でアクセスして、コンピュータ内のバーチャル・メモリ
をアクセスし、操作することを可能にするものである。

（４）プロセス間通信（interprocess communication−
IPC）クラス。これは、アプリケーションがオペレーテ
ィング・システムのサービスをオブジェクト指向方式で
アクセスし、そのアプリケーションが実行時（run−tim
e）にコンピュータ中の他のスレッドと通信できるよう
にするものである。

（５）同期化クラス（synchronization class）。これ
は、アプリケーションがオペレーティング・システムの
サービスをオブジェクト指向方式でアクセスして、スレ
ッドの実行を同期化することを可能にするものである。

（６）スケジューリング・クラス（scheduling clas
s）。これは、アプリケーションがオペレーティング・
システムのサービスをオブジェクト指向方式でアクセス
して、スレッドの実行をスケジュールすることを可能に
するものである。

（７）障害クラス（fault class）。これは、アプリケ
ーションがオペレーティング・システムのサービスをオ
ブジェクト指向方式でアクセスして、システムで定義し
たプロセッサ障害とユーザが定義したプロセッサ障害を
処理することを可能にするものである。

（８）マシン・クラス（machine class）。これは、ア
プリケーションがオペレーティング・システムのサービ
スをオブジェクト指向方式でアクセスして、ホストとプ
ロセッサ・セットを定義し、変更することを可能にする
ものである。

本発明のその他の特徴と利点については、本発明の種
々実施例の構造とオペレーティングと共に、添付図面を
参照して以下で詳しく説明するが、これらは請求の範囲
にも記載されている。なお、図面において、同一または
機能的に類似のエレメントは、同一の参照符号を付けて
示されている。

図面の簡単な説明 以下、添付図面を参照して本発明を説明する。図面に
おいて、 第１図は、本発明のラッパー（wrapper）が動作する
コンピュータ・プラットフォーム（computer platfor
m）を示すブロック図である。

第２図は、本発明のオペレーションを示すハイレベル
・フローチャートである。

第３図は、本発明のオペレーションを示す詳細フロー
チャートである。

第４図は、本発明のオブジェクト指向クラス・ライブ
ラリを収めているコード・ライブラリを示すブロック図
である。

第５図は、本発明のスレッド・クラスとタスク・クラ
スを示すクラス図である。

第６図は、本発明のバーチャル・メモリ・クラスを示
すクラス図である。

第７図から第９図までは、本発明のプロセス間通信ク
ラスを示すクラス図である。

第10図は、本発明の同期化クラスを示すクラス図であ
る。

第11図は、本発明のスケジューリング・クラスを示す
クラス図である。

第12図は第15図では、本発明の障害クラスを示すクラ
ス図である。

第16図は、本発明のホストとプロセッサ・セット（マ
シン）クラスを示すクラス図である。

第17図は、クラス図におけるクラス相互間の関係とカ
ーディナリティを公知のアイコンで表して示す図であ
る。

好適実施例の詳細な説明 コンピューティング環境 本発明は、ネイティブ手続き型インタフェースをもつ
手続き型オペレーティング・システムとのオブジェクト
指向インタフェースを提供するシステムおよび方法を目
的としている。本発明は、手続き型オペレーティング・
システムをもつコンピュータ・プラットフォーム上でオ
ブジェクト指向ソフトウェア環境をエミュレートしてい
る。もっと具体的には、本発明は、オブジェクト指向ア
プリケーションが、そのアプリケーションが実行時にコ
ンピュータで実行されているとき、ネイティブ手続き型
インターフェースをもつ手続き型オペレーティング・シ
ステムをオブジェクト指向方式でアクセスすることを可
能にするシステムおよび方法を目的としている。本発明
は、好ましくは、アプリケーションが実行されるコンピ
ュータの実行時環境の一部になっている。本明細書にお
いて、本発明をオブジェクト指向ラッパー（wrapper）
と呼ぶことがあるが、これは、本発明が手続き型オペレ
ーティング・システムをオブジェクト指向ソフトウェア
層で包み込む（wrap）働きをして、オブジェクト指向ア
プリケーションがオペレーティング・システムをオブジ
ェクト指向方式でアクセスできるようにするからであ
る。

第１図は、本発明のラッパー128、129が動作するコン
ピュータ・プラットフォーム（computer platform）102
を示すブロック図である。なお、ここで触れておきたい
ことは、本発明の別実施例では、ラッパー128,129がコ
ンピュータ・プラットフォーム102と一体になって含ま
れていることである。コンピュータ・プラットフォーム
102は、ランダム・アクセス・メモリ（RAM）108および
中央演算処理ユニット（CPU）106などのハードウェア・
コンポーネント103を含んでいる。図中では、CPU106は
シングル・プロセッサと示されているが、好ましくは、
マルチプロセッサが並列に動作している。さらに、コン
ピュータ・プラットフォーム102には周辺デバイスが含
まれ、これらはハードウェア・コンポーネント103に接
続されている。これらの周辺デバイスは、１つまたは複
数の入力デバイス（キーボード、マウス、ライトペンな
ど）、データ記憶デバイス120（ハードディスク、フロ
ッピ・ディスクなど）、ディスプレイ124、およびプリ
ンタ126を含んでいる。データ記憶デバイス120は、使用
されるデータ記憶デバイスのタイプに応じて、取外し可
能データ記憶媒体（取外し可能ハードディスク、磁気テ
ープ・カートリッジ、フロッピ・ディスクなど）との間
でデータをやりとりすることができる。また、コンピュ
ータ・プラットフォーム102は、ネイティブ手続き型イ
ンタフェース（図示せず）をもつ手続き型オペレーティ
ング・システム114も含んでいる。この手続き型インタ
フェースは手続き型関数（procedural function）を含
んでおり、これらの関数はオペレーティング・システム
102から提供されるサービスをアクセスするためにコー
ル（呼出し）されるものである。

さらに、コンピュータ・プラットフォーム102はデバ
イス・ドライバ（device driver）116を含んでいるが、
マイクロ命令（microinstruction）コード（ファームウ
ェアとも呼ばれる）を含んでいる場合もある。第１図に
示すように、デバイス・ドライバ116は必要とする関数
を実行するとき、オペレーティング・システム114とや
りとりすることができる。アプリケーション・プログラ
ム130,132,134（あとで詳しく説明する）は、好ましく
は、オペレーティング・システム114を通してデバイス
・ドライバ116とやりとりするが、別の方法としてデバ
イス・ドライバ116と直接にやりとりすることも可能で
ある。ここで触れておきたいことは、オペレーティング
・システム114は、ディスク・オペレーティング・シス
テム（DOS）やUNIXオペレーティング・システムのよう
な、ほぼ全機能（fullfunction）のオペレーティング・
システムを表している場合があることである。なお、オ
ペレーティング・システム114は他のタイプのオペレー
ティング・システムを表すことも可能である。本発明の
目的上、要求されることは、オペレーティング・システ
ムがネイティブ手続き型インタフェースをもつ手続き型
オペレーティング・システムであることだけである。好
ましくは、オペレーティング・システム114は、CMUが開
発したMachマイクロカーネル（micro−kernel）（この
分野では公知である）のような、機能が限定された手続
き型オペレーティング・システムを表している。以下で
は、Machマイクロカーネルと関連づけて本発明を説明す
るが、これはあくまでも説明を分かりやすくするためで
ある。本発明の好適実施例では、コンピュータ・プラッ
トフォーム102はインターナショナル・ビジネス・マシ
ンズ（IBM）社コンピュータまたはIBMコンパチブル・コ
ンピュータになっている。本発明の別実施例では、コン
ピュータ・プラットフォーム102はアップル社コンピュ
ータになっている。

ラッパーの概要説明 種々のアプリケーション・プログラム130,132,134
は、好ましくは、コンピュータ・プラットフォーム102
上で並列に実行される。好ましくは、アプリケーション
・プログラム130,132,134は異種のオペレーティング・
システムで実行されるようになっている。例えば、アプ
リケーション・プログラム130Aと130Bはオブジェクト指
向環境で動作するようにすることができる。アプリケー
ション・プログラム132はMicrosoft Windows環境、IBM
PS/2環境、またはUnix環境で動作するようにすることが
できる。この分野の専門家ならば理解されるように、ア
プリケーション・プログラム130A,130B、および132は、
オペレーティング・システム114が実現する環境がアプ
リケーション・プログラム130A,130B、および132が動作
するのに適した環境になっていなければ、オペレーティ
ング・システム114と直接にやりとりすることができな
い。例えば、アプリケーション132がIBM PS/2環境で動
作するようになっていれば、アプリケーション132は、
オペレーティング・システム114がIBM PS/2オペレーテ
ィング・システム（またはコンパチブル）でなければ、
オペレーティング・システム114と直接にやりとりする
ことができない。また、アプリケーション・プログラム
130Aと130Bがオブジェクト指向環境で動作するようにな
っていれば、アプリケーション130A,130Bは、オペレー
ティング・システム114が手続き型インタフェースをも
っているので、オペレーティング・システム114と直接
にやりとりすることができない。第１図に示す例では、
アプリケーション134は、オペレーティング・システム1
14によって実現されたコンピューティング環境で動作す
るようになっているので、アプリケーション134は図示
のように、オペレーティング・システム114と直接に結
ばれている。

ラッパー128は、オペレーティング・システム114にオ
ブジェクト指向インタフェースを提供するメカニズムと
なるものである。ラッパー128を通して、オブジェクト
指向アプリケーション130A,130Bは、そのアプリケーシ
ョンがランタイムすなわち実行時にコンピュータ・プラ
ットフォーム102上で実行されているとき、手続き型オ
ペレーティング・システムをオブジェクト指向方式で直
接にアクセスすることができる。ラッパー129は概念的
にはラッパー128と類似している。ラッパー129はオペレ
ーティング・システム114のためのIBM PS/2インタフェ
ースとなるので、アプリケーション132は手続き型オペ
レーティング・システム114をPS/2方式で直接にアクセ
スすることができる（なお、アプリケーション132はIBM
PS/2環境で動作するようになっているものとする）。
以下では、本発明の説明は、ネイティブ手続き型インタ
フェースをもつ手続き型オペレーティング・システムと
のオブジェクト指向インタフェースとなるラッパー128
に限定して行うことにする。

ラッパー128は、好ましくは、RAM108にストアされる
コード・ライブラリ110として実現されている。コード
・ライブラリ110は、データ記憶デバイス120および／ま
たはデータ記憶媒体122にストアしておくことも可能で
ある。コード・ライブラリ110はオブジェクト指向クラ
ス・ライブラリー402（第４図参照）を実現している。
本発明によばれ、オブジェクト指向クラス・ライブラリ
402は、オブジェクト指向アプリケーション（アプリケ
ーション130Aと130Bのようなもの）がオペレーティング
・システム114から提供されるサービスをオブジェクト
指向方式でアクセスできるようにする。相互に関連をも
つオブジェクト指向クラスを含んでいる。オブジェクト
指向クラスは、オペレーティング・システム114のネイ
ティブ手続き型インタフェースと互換性のある手続き型
関数を含んでいるメソッドを構成している。オブジェク
ト指向クラス・ライブラリ402によって定義されている
オブジェクト指向ステートメント（クラス・ライブラリ
402のメソッドの１つまたは２つ以上を呼び出すオブジ
ェクト指向ステートメントなど）はアプリケーション13
0に挿入可能とすると、アプリケーション130は、アプリ
ケーション130がコンピュータ・プラットフォーム102上
で実行時に実行されているとき、オペレーティング・シ
ステムのサービスをオブジェクト指向方式でアクセスす
ることができる。オブジェクト指向クラス・ライブラリ
402については、以下の別セクションで詳しく説明す
る。

コード・ライブラリ110は、好ましくは、オブジェク
ト指向クラス・ライブラリ402を実現する、コンパイル
済みで実行可能なコンピュータ・プログラム・ロジック
を含んでいる。コード・ライブラリ110のコンピュータ
・プログラム・ロジックはアプリケーション・プログラ
ムとリンクされない。その代わりに、コード・ライブラ
リ110の関係する部分が実行時（ランタイム）にコピー
されて、プロセスの実行可能アドレス空間（address sp
ace）に入れられる。これについては、あとで詳しく説
明する。コード・ライブラリ110のコンピュータ・プロ
グラム・ロジックはアプリケーション・プログラムとリ
ンクされないので、コンピュータ・プログラム・ロジッ
クは、アプリケーション・プログラムを修正、再コンパ
イルおよび／または再リンクしなくても、いつでも修正
することができる（コード・ライブラリ110とのインタ
フェースが変更されない限り）。上述したように、本発
明は、以下では、Machマイクロカーネルと関連づけて説
明されているが、他のオペレーティング・システムをラ
ップするために本発明を使用することも、本発明の範囲
に属することは勿論である。

Machマイクロカーネルを通して、ユーザはいくつかの
サービスを利用することができるが、サービスは次のよ
うなカテゴリに分類されている。すなわち、スレッド、
タスク、バーチャル・メモリ、プロセス間通信（IP
C）、スケジューリング、同期化、障害処理、およびホ
スト／プロセッサ・セット処理である。本発明のクラス
・ライブラリ402は。Machサービスのカテゴリ別に、相
互に関連をもつクラス群を含んでいる。第４図に示すよ
うに、クラス・ライブラリ402は次のものを含んでい
る。

（１）スレッド・クラス404。これは、アプリケーショ
ンがオペレーティング・システムのサービスをオブジェ
クト指向方式でアクセスして、スレッドに関する情報を
作成し、管理し、取得することを可能にするものであ
る。

（２）タスク・クラス406。これは、アプリケーション
がオペレーティング・システムのサービスをオブジェク
ト指向方式でアクセスして、タスクを参照し、管理する
ことを可能にするもので、タスクの各々は、それぞれが
タスクに関連づけられているスレッドの実行環境を表し
ている。

（３）パーチャル・メモリ・クラス408。これは、アプ
リケーションがオペレーティング・システムのサービス
をオブジェクト指向方式でアクセスして、コンピュータ
内のバーチャル・メモリをアクセスし、操作することを
可能にするものである。

（４）IPCクラス。これは、アプリケーションがオペレ
ーティング・システムのサービスをオブジェクト指向方
式でアクセスして、そのアプリケーションがコンピュー
タで実行されている実行時（run−time）中に他のスレ
ッドと通信できるようにするものである。

（５）同期化クラス412。これは、アプリケーションが
オペレーティング・システムのサービスをオブジェクト
指向方式でアクセスして、スレッドの実行を同期化する
ことを可能にするものである。

（６）スケジューリング・クラス414。これは、アプリ
ケーションがオペレーティング・システムのサービスを
オブジェクト指向方式でアクセスして、スレッドの実行
をスケジュールすることを可能にするものである。

（７）障害クラス416。これは、アプリケーションがオ
ペレーティング・システムのサービスをオブジェクト指
向方式でアクセスして、システムで定義したプロセッサ
障害とユーザが定義したプロセッサ障害を処理すること
を可能にするものである。

（８）マシン・クラス418。これは、アプリケーション
がオペレーティング・システムのサービスをオブジェク
ト指向方式でアクセスして、ホストとプロセッサ・セッ
トを定義し、変更することを可能にするものである。

クラス・ライブラリ402には、将来Machから提供され
る他のサービス・カテゴリ用の追加クラスを含めること
も可能である。例えば、現在、セキュリティ・クラス
（security class）がMach用に開発中である。従って、
クラス・ライブラリ402にセキュリティ・クラス420も含
めておけば、アプリケーションはオペレーティング・シ
ステムのセキュリティ・サービスをオブジェクト指向方
式でアクセスすることが可能になる。理解されるよう
に、クラス・ライブラリ402に組み入れるクラスの正確
な数とタイプは、基礎となるオペレーティング・システ
ムのインプリメンテーションによって決まる。

好適実施例のオペレーションの概要説明 以下では、本発明のハイレベル・オペレーション・フ
ローチャート202を示している第２図を参照して、本発
明のオペレーションの概要について説明する。本発明
は、オブジェクト指向アプリケーション130Aがコンピュ
ータ・プラットフォーム102上で実行されることを前提
に説明されている。フロートチャート202の事実上の第
１ステップであるステップ206で、アプリケーション130
Aがコンピュータ・プラットフォーム102上で実行される
とき、オペレーティング・システム114から提供される
サービスをアクセスするオブジェクト指向ステートメン
トの位置がアプリケーション130A中で認識される。オブ
ジェクト指向ステートメントはオブジェクト指向クラス
・ライブラリ402によって定義されている。例えば、オ
ブジェクト指向ステートメントは、クラス・ライブラリ
402のクラスの１つによって定義されたメソッドを参照
することができる。このあとに続くステップでは、ステ
ートメントがコンピュータ・プラットフォーム102によ
ってどのように実行されるかについて説明する。

ステップ208で、オブジェクト指向ステートメント
は、オペレーティング・システム114のネイティブ手続
き型インタフェースと互換性があり、しかも、オブジェ
クト指向ステートメントに対応する手続き型関数コール
に変換される。ステップ208が実行されると、ステート
メントは、ステートメントの中で参照されたメソッドを
実現している、コード・ライブラリ110からのコンピュ
ータ・プログラム・ロジックに変換される。上述したよ
うに、メソッドは、オペレーティング・システム114の
ネイティブ手続き型インタフェースと互換性のある手続
き型関数コールを少なくとも１つ含んでいる。ステップ
210で、ステップ208からの手続き型関数コールはコンピ
ュータ・プラットフォーム102で実行されて、サービス
がオペレーティング・システムからアプリケーション13
0Aのために提供される。ステップ210は、ステップ208で
述べたメソッドを実行することにより実行され、これに
より手続き型関数コールが呼び出される。

次に、本発明のオペレーティングの詳細フローチャー
ト302を示している第３図を参照して、好適実施例のオ
ペレーティングを詳しく説明する。ここでも、本発明は
オブジェクト指向アプリケーション130Aがコンピュータ
・プラットフォーム102上で実行されることを前提に説
明されている。もっと具体的には、本発明は、オブジェ
クト指向アプリケーション130Aの１つのオブジェクト指
向ステートメントがコンピュータ・プラットフォーム10
2上で実行されることを前提に説明されている。アプリ
ケーション130Aは、オペレーティング・システムから提
供されるサービスをアクセスするステートメントを含ん
でおり、これらのステートメントはクラス・ライブラリ
402によって定義されているものとする（言い換えれ
ば、プログラマはクラス・ライブラリ402への参照をも
つアプリケーション130Aを作成したものとする）。以下
で詳しく説明するが、Machマイクロカーネルでの実行可
能エンティティ（executable entity）はスレッドと呼
ばれている。また、Machマイクロカーネルでの処理編成
エンティティ（processing organization entity）はタ
スクと呼ばれている。タスクは１つまたは２つ以上のス
レッド（並行実行が可能である）と、タスクのスレッド
が実行されるバーチャル・メモリのブロックを表してい
るアドレス空間とを含んでいる。どの時点でも、複数の
タスクがコンピュータ・プラットフォーム102上でアク
ティブ状態にあることが可能である。コンピュータ・プ
ラットフォーム102上で実行されるとき、アプリケーシ
ョン130Aはタスク全体（１つまたは複数のスレッドをも
っている）を表していることも、タスクの一部になって
いる少数のスレッドを表していることもある（後者の場
合には、タスクは他のスレッドをもつことになり、その
スレッドはアプリケーション130Aのオペレーティングと
関係がある場合と関係がない場合とがある）。本発明の
範囲には、アプリケーション130Aがタスク全体である場
合も、タスクの少数のスレッドだけである場合も含まれ
る。

次に第３図を参照して説明する。ステップ308におい
て、ステートメントの中で参照されたメソッドを実現し
ている、コード・ライブラリ110からのコンピュータ・
プログラム・ロジック（コンピュータ・コードとも呼ば
れる）がアプリケーション130Aに関連するタスク・アド
レス空間に存在するかどうかが判断されている。コンピ
ュータ・プログラム・ロジックがタスク・アドレス空間
に存在していれば、ステップ316が処理される（下述す
る）。コンピュータ・プログラム・ロジックがタスク・
アドレス空間に存在しなければ、コンピュータ・プログ
ラム・ロジックはステップ310,312および314でタスク・
アドレス空間へ転送される。ステップ310では、コード
・ライブラリ110に関連するライブラリ・サーバ（図示
せず）が既知のものかどうかが判断される。コード・ラ
イブラリ110は、ラッパー128に関係する複数のコード・
ライブラリ（図示せず）を表している場合があり、その
場合には、コード・ライブラリの各々は、クラス・ライ
ブラリ402のオブジェクト指向クラスの一つのコンピュ
ータ・プログラム・ロジックを含んでいる。この分野の
専門家ならば理解されるように、ラッパー128とはまっ
たく関係ない他のコード・ライブラリ（図示せず）が存
在する場合もある。

コード・ライブラリと関連づけられているものとして
ライブラリ・サーバがあり、その各々は指定されたコー
ド・ライブラリの資源を管理している。コード・ライブ
ラリのコンピュータ・プログラム・ロジックへのアクセ
スを望んでいる処理エンティティはそのコード・ライブ
ラリのライブラリ・サーバに対して要求を行う。この要
求には、例えば、必要とするコンピュータ・プログラム
・ロジックの記述とそのコンピュータ・プログラム・ロ
ジックを送るべき宛先アドレスを含めることができる。
ライブラリ・サーバは、必要とするコンピュータ・プロ
グラム・ロジックをコード・ライブラリからアクセス
し、必要とするコンピュータ・プログラム・ロジックを
宛先アドレスで指定されたメモリ・エリアへ送ることに
よって要求を処理する。ライブラリ・サーバの構造とオ
ペレーションはこの分野では公知である。このようにし
て、ステップ310で、関係するコンピュータ・プログラ
ム・ロジックを収めているコード・ライブラリ110に関
連するライブラリ・サーバが既知であるかが判断され
る。ステップ310は、例えば、既知のライブラリ・サー
バを示しているライブラリ・サーバテーブルとそのサー
バのサービスを受けるコード・ライブラリを参照するこ
とにより実行される。ライブラリ・サーバが既知のもの
であれば、ステップ314が処理される（下述する）。そ
うでなければ、ステップ312が処理される。ステップ312
では、コード・ライブラリ110に関連するライブラリ・
サーバが識別される。ライブラリ・サーバのIDは、例え
ば、処理されているオブジェクト指向ステートメントの
内容から知ることができる。

コード・ライブラリ110に関連するライブラリ・サー
バが識別されると、あるいはライブラリ・サーバが既知
のものであれば、ステップ314が処理される。ステップ3
14では、要求がライブラリ・サーバへ送られて、ステー
トメントの中でメソッド参照に関連するコンピュータ・
プログラム・ロジックをタスク・アドレス空間にコピー
するようにライブラリ・サーバに要求する。ステップ31
4が完了すると、ライブラリ・サーバは、要求したコン
ピュータ・プログラム・ロジックをタスク・アドレス空
間にコピーしている。好ましくは、コード・ライブラリ
110は共有ライブラリになっている。つまり、コード・
ライブラリ110は、複数のスレッドが同時にアクセスす
ることが可能になっている。しかし、好ましくは、コー
ド・ライブラリ110のコンピュータ・プログラム・ロジ
ックは、物理的には１つの物理メモリ・エリアだけにス
トアされている。ライブラリ・サーバは、コンピュータ
・プログラム・ロジックをコード・ライブラリ110から
タスク・アドレス空間に仮想的にコピーする。つまり、
コンピュータ・プログラム・ロジックを物理メモリのあ
る部分から別の部分に物理的にコピーするのではなく、
ライブラリ・サーバは、関係するコンピュータ・プログ
ラム・ロジックを収めている物理メモリ・エリアを指す
ポインタをタスク・アドレス空間に入れる。ステップ31
6で、オブジェクト指向ステートメントに関連するコン
ピュータ・プログラム・ロジックがコンピュータ・プラ
ットフォーム102上で実行される。上述したように、オ
ブジェクト指向ステートメントがオペレーティング・シ
ステム114をアクセスするような場合には、メソッドに
関連するコンピュータ・プログラム・ロジックは、オペ
レーティング・システム114のネイティブ手続き型イン
タフェースと互換性がある手続き型関数コールを少なく
とも１つ含んでいる。従って、メソッドのコンピュータ
・プログラム・ロジックを実行すると、手続き型関数コ
ールが呼び出されて実行され、これにより、オペレーテ
ィング・システム114からサービスがアプリケーション1
30Aに提供される。

上述したように、コンピュータ・プラットフォーム10
2でのステップ306,308,310,312および314の実行の大部
分は、コンピュータ・プラットフォーム102に設定され
ている実行時環境によるものである。この分野の専門家
ならば理解されるように、コンピュータ・プラットフォ
ーム102の実行時環境は、アプリケーション・プログラ
ム130Aをコンパイルする特定コンパイラの実行時規則に
よって定義されている。例えば、実行時規則は、オペレ
ーティング・システムのサービスをアクセスするステー
トメントが現れたとき、コード・ライブラリ110からの
対応するコードをタスク・アドレス空間へ転送して（関
連のライブラリ・サーバ経由）で実行することを指定す
ることができる。コンパイラの実行時規則は一般に公知
である。理解されるように、実行時規則は使用される特
定コンパイラに特有のものである。本発明で使用される
実行時規則と特定コンパイラで使用される実行時規則
は、この分野の専門家ならば、本発明書に記載されてい
る本発明の開示内容から、特に、第３図のフローチャー
ト302に開示されている内容から理解されるはずであ
る。上述したように、本発明のラッパー128はコード・
ライブラリ110として実現され、コード・ライブラリは
オブジェクト指向クラス・ライブラリ402を実現するコ
ンピュータ・プログラム・ロジックを含んでいる。別の
方法として、ラッパー128をハードウェア・メカニズム
として実現することも可能である。その場合は、基本的
に第３図のフローチャート302に従って動作して、アプ
リケーション・プログラムの中のオブジェクト指向ステ
ートメント（クラス・ライブラリ402によって定義され
ている）を、オペレーティング・システム114の手続き
型インタフェースと互換性のある手続き型関数コールに
変換することができる。また、ラッパー128をバックグ
ラウンド（背景）ソフトウェア・プロセスとして実現す
ることも可能である。その場合は、コンピュータ・プラ
ットフォーム102上で動作して、オペレーティング・シ
ステムへのすべてのアクセス（クラス・ライブラリ402
によって定義されたオブジェクト指向ステートメントに
よって行われた）を捕捉し、これらのアクセスをオペレ
ーティング・システム114の手続き型インタフェースと
互換性のある手続き型関数コールに変換することができ
る。ラッパー128のその他のインプリメンテーションは
この分野の専門家ならば、本明細書に記載されている本
発明の開示内容から理解されるはずである。

Machサービス このセクションでは、Machマイクロカーネルから提供
される抽象化とサービスの概要を説明する。サービスは
Machマイクロカーネルの主要分野別に説明されている。
上述したように、サービスには、スレッド、タスク、バ
ーチャル・メモリ、IPC、スケジューリング、同期化サ
ービス、ハードウェア障害、およびホスト／特権サービ
ス（マシン・サービスとも呼ばれる）がある。Machマイ
クロカーネルを詳しく解説した公知文献として、次のも
のがある。K.Loepere編集「Mach 3カーネルの原理」（M
ach 3 Kernel Principles）（Open Software Foundatio
n and Carnegie Mellon University,Draft Industrial
Specification,September 1992 and November 1992）、
K.Loepere編集「Mach 3カーネル・インタフェース」（M
ach 3 Kernel Interfaces）（Open Software Foundatio
n and Carnegie Mellon University,Draft Industrial
Specification,September 1992 and November 1992）、
K.Loepere編集「Mach 3サーバ・ライタのガイド」（Mac
h 3 Server Writer's Guide）（Open Software Foundat
ion and Carnegie Mellon University,Draft Industria
l Specification,September 1992 and November 199
2）、K.Loepere編集「Mach 3サーバ・ライタのインタフ
ェース」（Mach 3 Server Writer's Interfaces）（Ope
n Software Foundation and Carnegie Mellon Universi
ty,Draft Industrial Specification,September 1992 a
nd November 1992）、A Silbershatz、J.Peterson、P.G
alvin共著「オペレーティング・システムの概念」（Ope
rating System Concepts）（Addison−Wesley,July 199
2）、およびA.Tanenbaum著「最新オペレーティング・シ
ステム」（Modern Operating Systems）（Prentice Hal
l,1992）。

スレッド Machにおける実行可能エンティティはスレッド（thre
ad）と呼ばれている。スレッドは、スレッドをシステム
で実行可能にする側面をいくつかもっている。スレッド
はタスクに常に含まれており、タスクは、スレッドが利
用できる主要資源（例えば、アドレス空間）の大部分を
表している。スレッドは実行状態（execution state）
をもっており、これは基本的には、マシン・レジスタ
と、そのコンテキストを構成する他のデータとが集まっ
たものである。スレッドは常に７つのスケジューリング
状態の１つ、つまり、実行中、実行準備状態、あるいは
何らかの理由による停止の状態に置かれている。スレッ
ドの目的は実行エンティティを軽量化することにある。
その目的は、プログラマがアプリケーションの中で多数
のスレッドを使用することを奨励し、もって、従来のオ
ペレーティング・システムに見られた以上の並行性（co
ncurrency）をシステムに導入することにある。スレッ
ドは若干のコストが伴わないわけではないが、実際には
最小コストで済むので、Mach環境の代表的なアプリケー
ションやサーバはこの機能を活用することができる。

しかし、スレッドには、関連づけられているいくつか
のエレメントを有している。スレッドが置かれているタ
スクとアドレス空間は、実行状態と共に、すでに説明し
たとおりである。各スレッドはスケジューリング・ポリ
シ（scheduling policy）をもっている。スレッドがそ
こで実行されるプロセッサをスレッドにいつ、どのよう
な頻度で与えるかはこのポリシによって決まる。スケジ
ューリング・サービスは別のセクションで詳しく説明す
る。スレッドのスケジューリング・ポリシーと密に結び
付いているのが、オプションのプロセッサ・セット（pr
ocessor set）の指定である。これをマルチプロセッサ
・システムで使用すると、スレッドのプロセッサへの割
当てを密に制御できるので、アプリケーション・パフォ
ーマンスを大幅に向上することができる。前述したよう
に、アドレス空間（タスク）には、０個または１個以上
のスレッドを置いて並行に実行させることができる。カ
ーネルは、アドレス空間内の、実際にはシステム全体内
のスレッド間の関係についてはなにも想定していない。
むしろ、カーネルはスレッドに関連するスケジューリン
グ・パラメータとシステム内の使用可能プロセッサ資源
に従って、スレッドをスケジュールし、実行する。具体
的には、スレッドがアドレス空間に置かれるときの配置
（例えば、階層）は無関係であり、また、スレッドがど
のようにやりとりし合うかについても想定されていな
い。実行順序とスレッド間の調整を制御してなんらかの
有用な目的を達成するために、Machにはいくつかの同期
化メカニズムが用意されている。最も単純な（最も粗
い）メカニズムはスレッド・レベルの一時中止および再
会（suspend and resume）オペレーションである。各ス
レッドは一時中止カウント（suspend count）をもち、
これは、これらのオペレーションによってインクリメン
トされ、デクリメントされる。一時中止カウントが正に
なっているスレッドは、カウントがゼロになるまでブロ
ック（中断）されたままである。

同期化オブジェクト（セミャフォアまたはモニタと条
件）を使用すると、もっときめ細かな同期化が得られる
ので、様々なスタイルの同期化が使用できる。スレッド
はプロセス間通信（IPC）を通してやりとりすることも
できる。これらのサービスの各々は、別のセクションに
詳しく説明されている。スレッドの作成、終了およびそ
の属性の取得と設定をサポートするものとして基本的オ
ペレーションがある。また、他にも、スレッドに対する
制御オペレーションがいくつかあり、これは、意図する
スレッドの制御ポートに対する送信権をもつスレッドが
実行できる。スレッドは明示的に終了させることができ
る。また、様々な待ち状態からインタラプトされ、イン
タラプトしたとの通知と共に実行を再開させることも可
能である。スレッドを「ワイヤド」（wired−固定する
こと））にすることも可能である。このことは、カーネ
ル資源に対して特権があるとのマークがスレッドに付い
ていること、つまり、空きメモリが不足したときスレッ
ドが物理メモリを使用できることを意味する。これは、
スレッドがデフォルトのページアウト経路（page−out
path）にあるとき使用される。最後に、スレッドはいく
つかの重要なIPCポート（正確には、これらのポートに
対する送信権または受信権）ももっており、これらはあ
る種の関数で使用される。具体的には、各スレッドはス
レッド・セルフ・ポート（thread self port）をもって
おり、これはスレッドに対するある種のオペレーション
を自身で実行するために使用できる。スレッドは一組に
障害ポート（fault ports）ももっており、これは、そ
の実行中にスレッドにプロセッサ障害が起こったとき使
用される。特異なポートもあり、これは、スレッドの実
行状態のサンプルを収集して、デバッガやプログラム・
プロファイラ（program profiler）などの他のスレッド
にモニタリングさせるために使用できる。

タスク Machにおいて、資源を管理するための基本的編成エン
ティティはタスクと呼ばれる。タスクには、多数のオブ
ジェクトと属性が関連づけられている。タスクは基本的
に３つのものからなっている。タスクは複数のスレッド
を収めており、これらはシステム内の実行可能エンティ
ティである。また、タスクはアドレス空間（addres spa
ce）ももっており、これは、そのスレッドをそこで実行
できるバーチャル・メモリを表している。さらに、タス
クはポート名スペース（port name space）をもってお
り、これは、スレッドがそこを通してシステム内の他の
スレッドと通信できる有効なIPCポートを表している。
タスク内のこれらの基本的オブジェクトの各々は、この
とに続くセクションで詳しく説明されている。注意すべ
きことは、タスクは、Machでは、それ自体が実行可能エ
ンティティでないことである。しかし、タスクはスレッ
ドを収容することができ、これらは実行可能エンティテ
ィである。タスクには、上述した基本的エンティティの
ほかに、他のいくつかのエンティティが関連づけられて
いる。これらのエンティティのいくつかは、タスクに含
まれるスレッドのためにカーネルが行う必要のあるスケ
ジューリング判断と関係がある。スケジューリング・パ
ラメータ（scheduling parameters）、プロセッサ・セ
ット（processor set）、およびホスト（host）情報
は、いずれもタスクのスレッドのスケジューリングに貢
献している。また、タスクは、ある種の事前に定義され
た関数に使用される特異なプロセス間通信ポートもいく
つかもっている。プロセス間通信のポートおよびその他
の側面は別のセクションで詳しく説明されている。今の
段階では、ポート資源は時間の経過と共にタスクに累積
されていくということを知っているだけで十分である。
これらの資源の大部分は、プログラマによって明示的に
管理される。上述した特異なポートは、通常、システム
内のいくつかの重要な関数との接続を確立することに関
係している。Machには、各タスクのために３つの「特
殊」ポート（“special"port）が用意されている。最初
のポートはタスク・セルフ・ポート（task self port）
であり、これはタスクに対してある種のオペレーション
を実行するようにカーネルに要求するために使用でき
る。二番目の特殊ポートはブートストラップ・ポート
（bootstrap port）であり、これは何にでも使用できる
が（これはOS環境特有ものである）、一般的には、他の
サービスを探すために使用される。各タスクがもつ三番
目の特殊ポートはホスト名ポート（host namee port）
であり、これは、タスクがそこで実行中のマシンに関す
るある種の情報をタスクが得るために使用される。その
ほかにも、Machには、タスクに含まれるスレッドがシス
テム内のある種の上位レベル・サービスと通信できるよ
うにする、いくつかの「登録」ポート（“registered"p
ort）が各タスクのために用意されている（例えば、ネ
ットワーク名サービス、「サービス」サーバ、環境サー
バ）。

ほかにも、２つの有用なポート・セットが各タスクの
ために存在する。これらのポートは障害処理異とプログ
ラム・ステート・サンプリングを行うために使用される
ものである。タスクの障害ポート（fault port）は処理
しようとするタスクに含まれるスレッドにプロセッサ障
害が起こったときの共通場所となるものである。障害処
理は別のセクションに詳しく説明されている。PCサンプ
ル・ポート（PC sample port）は、プロファイリング・
ツールがタスク内のスレッドの実行状態を繰返しモニタ
できるようにする。タスクでは多数のオペレーションが
可能である。タスクを作成し、終了させることができ
る。新しいタスクを作成するには、ある既存タスクを新
タスクのアドレス空間の初期内容のプロトタイプとして
指定する。タスクは終了させることも可能であり、タス
クが終了すると、そこに含まれるスレッドのすべても終
了する。タスクに含まれるスレッドを列挙して、スレッ
ドに関する情報を抽出することができる。タスク（正確
には、タスク内のスレッド）の粗粒（coarse grain）実
行は、一時中止と再開オペレーションを通して制御する
ことができる。各タスクは一時中止カウントをもち、こ
のカウントは、一時中止および再開オペレーションによ
ってインクリメントされ、デクリメントされる。タスク
内のスレッドは、そのスレッドを含んでいるタスクの一
時中止カウントがゼロであるかぎり実行可能である。一
時中止カウントが正になると、タスク内のすべてのスレ
ッドはタスクがあとで再開されるまでブロック（中断）
される。最後に、タスクに関連する種々のパラメータと
属性（例えば、スケジューリング優先順位）を照会し
て、希望の値に設定することが可能である。

バーチャル・メモリ Machは、そのバーチャル・メモリ（VM）サブシステム
におけるいくつかの機能をサポートしている。外部クラ
イアント・インタフェース（external client interfac
e）と内部インプリメンテーション（internal implemen
tation）はどちらも、他の多くのオペレーティング・シ
ステムには見当たらない特徴を備えている。広義の意味
では、Machバーチャル・メモリ・システムはシステム内
で実行されるタスクの各々のために、大きな疎密度（sp
arsely populated）バーチャル・アドレス空間をサポー
トしている。クライアントには、アドレス空間の構成を
管理するための汎用サービスが提供される。VMシステム
のいくつかの側面は、実際には、マイクロカーネルの外
側にあるコンポーネントによって実現されているので、
ある種のポリシ関数（policy function）を異種システ
ム環境に合わせて柔軟に調整することができる。Mach V
Mシステムの内部アーキテクチャは、移植性（portabili
ty）を最大にするためにマシン独立モジュールとマシン
依存モジュールに分割されている。新しいプロセッサ/M
MUアーキテクチャへ移植することは、一般的には、小さ
な問題であり、その問題とは、基本的ハードウェアMMU
構造を取り扱ういくつかの関数を実現することである。
Machはすでにいくつかの異種プロセッサ・アーキテクチ
ャに移植されており、カーネル全体と特にバーチャル・
メモリ・システムに移植性があることが実証されてい
る。Machタスクのアドレス空間はいくつかのバーチャル
・メモリ領域（virtual memory region）を含んでい
る。これらの領域はバーチャル・アドレス空間の断片で
あり、タスクが使用するためにいろいろな方法で割り振
られている。これらは、メモリを合法的にアクセスでき
る唯一のロケーションである。アドレス空間内の定義さ
れた領域外のアドレスへの参照はすべて、正しくないメ
モリ参照エラーとなる。バーチャル・メモリ領域には興
味のある属性がいくつかある。ページ境界合わせされた
（pagealigned）開始アドレスとサイズをもち、サイズ
はシステム・ページ・サイズの倍数になっていなければ
ならない。領域内のページはすべて、アクセス保護が同
一になっている。これらのアクセス保護には読取り専用
（read−only）、書き込み（read−write）または実行
（execute）がある。また、領域内のページは同じ継承
特性ももっており、これは新タスクが現タスクから作成
されるとき使用できる。領域内のページの継承特性は、
新タスクが領域の書き込みコピーを継承すること、領域
のバーチャル・コピーを継承すること、または領域のど
のコピーも継承しないことを示すようにセットすること
ができる。新アドレス空間内の領域の読み書きコピー
は、領域を完全にマッピングしてタスク間で共有される
のに対し、バーチャル・コピーはコピー・オン・ライト
（copy−on−witer）でマッピングしたものであり、基
本的には、各タスクには領域の独自のコピーが与えられ
るが、領域を構成するページを効率的なコピー・オン・
ライトで共有している。

すべてのバーチャル・メモリ領域は、実際には、メモ
リ・オブジェクト（memory boject）と呼ばれる抽象エ
ンティティをマッピングしたものである。メモリ・オブ
ジェクトは、ある種のバイト単位（byte−wise）方式で
アドレスできるデータが集まったものにすぎず、カーネ
ルはデータについてはなにも想定していない。これは、
どこかの場所に明示的にストアできる、あるいは必要時
になんらかの方法で作ることができる、純粋なデータ断
片と考えた方が好都合である。メモリ・オブジェクトと
して役立つものには、多種類のものがある。例を挙げる
と、よく知られたものとして、ファイル、ROM、ディス
ク区画（dsik partition）、フォントなどがある。メモ
リ・オブジェクトには、オブジェクトが従わなければな
らない事前定義のオペレーションやプロトコルはない。
メモリ・オブジェクトに収められたデータがアクセスで
きるのは、そのデータがマッピングを通してVM領域と結
び付けられたときだけである。メモリ・オブジェクトが
ある領域にマッピングされると、通常のメモリ読み書き
（ロードとストア）オペレーションによってデータをア
クセスすることができる。メモリ・オブジェクトは、一
般的には、外部メモリ・マネージャ（external memory
manager）またはページャ（pager）と呼ばれる特殊なタ
スクによって管理される。パージャは、システム内の他
のタスクとまったく同じようにマイクロカーネルの外で
実行されるタスクである。これはユーザ・モード・エン
ティティであり、その仕事はそれがサポートするメモリ
・オブジェクトのデータに対するある種の要求を処理す
ることである。クライアント・タスク内のスレッドがあ
る領域内のページを参照すると、カーネルは、関連のメ
モリ・オブジェクト内の対応するバイト・アドレスから
のデータをページに論理的に入れる。これを行うには、
カーネルは実際には、ページ・フォルト（page fault−
ページ不在）のときはデータを取得する必要が起こった
とき、ページ置換のときはデータをページ・アウトする
必要が起こったとき、ページャと共に明確に定義された
（しかも煩わしい）プロトコルに従う。このプロトコル
は外部メモリ管理インタフェース（External Memory Ma
nagement interface−EMMI）とも呼ばれ、上記の他に、
メモリ・オブジェクトがクライアント・タスクによって
マッピングされるときはオブジェクトの初期設定シーケ
ンスを取り扱い、関連のメモリ領域がクライアント・タ
スクによって割当て解除（deallocate）されるときは終
了シーケンスを取り扱う。

ページャは、どのメモリ・オブジェクトが、種々のク
ライアント・タスクによって使用中であるかに応じて、
いくつでもシステムで稼働することができる。ページャ
は、例えば、マウントされている種々のフィアル・シス
テムと、所定の時点で関連づけられるのが典型的であ
る。また、ページャはある種のデータベース・アプリケ
ーションをサポートするために存在している場合もある
が、その場合は、ファイル・システムがサポートする以
上のオペレーションが必要になることもある。ページャ
は、標準外の方法で（例えば、記憶サブシステムからデ
ータを取り出すのではなく、計算によってデータを生成
する場合など）そのクライアントへデータを提供するこ
とを望んでいるある種のサーバのために存在する場合も
ある。マイクロカーネルは、常に、デフォルト・ページ
ャ（default pager）と呼ばれる、ある種の特異なペー
ジャがシステムで稼働していることを期待している。こ
のデフォルト・ページャはスタック、ヒープなどの無名
（anonymous）バーチャル・メモリと関連づけられたメ
モリ・オブジェクトの管理を担当する。この種のメモリ
は一時的であり、クライアント・タスクが実行中のとき
だけ使用される。上述したように、Mach VMシステムで
の主要エンティティは領域、メモリ・オブジェクト、お
よびページャである。しかし、大部分のクライアント
は、メモリを範囲（range）でオペレーションすること
によりバーチャル・メモリを取り扱う。範囲は領域の一
部にすることができるが、アドレス空間内の複数の連続
領域にスパンすることも可能である。Machに用意されて
いるオペレーションによれば、ユーザは新しい範囲のバ
ーチャル・メモリをアドレス空間内に割り当てることが
でき、必要時に範囲の割当てを解除することができる。
もう１つ重要なオペレーションによれば、メモリ・オブ
ジェクトを、上述したようにある範囲のバーチャル・メ
モリにマッピングすることができる。また、メモリ範囲
の保護を変更し、継承特性を変更し、ある範囲のページ
を物理メモリにワイヤ（wire−固定）（またはロック）
できるオペレーションも用意されている。メモリ範囲を
別のタスクから読み取ったり、別のタスクの範囲に読み
込んだりすることも可能であるが、タスクの制御ポート
が使用できることが条件できる。ほかにも、ユーザがメ
モリ範囲の期待参照パターン（expected reference pat
tern）を指定できるようにするサービスも用意されてい
る。これは、事情が変化したとき、ページ置換ポリシ
（page replacement policy）をどのような方法で適応
させるかの助言としてカーネルが使用できる。さらに、
ある範囲のメモリの内容を、そのメモリ範囲をバックす
るメモリ・オブジェクトと同期化（またはフラッシュ）
させるためのサービスも用意されている。最後に、領域
に関する情報を取得し、タスクのアドレス空間に置かれ
ている領域を中心に記載されているアドレス空間の内容
を列挙できるサービスが用意されている。

プロセス間通信 Machには、そのプロセス通信機能の中心となっている
４つの概念がある。それは、ポート（port）、ポート・
セット（port set）、ポート権（port right）、および
メッセージ（message）である。これらの概念の１つで
あるポート権は、Machでは、システム内のある種の共通
資源（スレッド、タスク、メモリ・オブジェクトなど）
を識別する手段としても使用されている。

ポート スレッドはポートを使用して相互に通信する。ポート
は、基本的には、カーネル内部のメッセージ・キュー
（待ち行列）であり、スレッドは正しい許可を得ていれ
ば、そこにメッセージを追加したり、そこからメッセー
ジを除去したりすることができる。これらの「許可」
（permission）はポート権と呼ばれる。ポート権の他
に、ポートに関連づけられる他の属性として、ポート上
のキューに置くことができるメッセージ数の制限、ポー
トに送信できるメッセージの最大サイズの制限、ポート
権がいくつ存在するかのカウントなどがある。ポートは
カーネル内だけに存在し、ポートはポート権があるとき
だけ操作できる。

ポート権 スレッドはポートに対して送信権をもっていれば、そ
のポートのメッセージ・キューにメッセージを追加する
ことができる。同様に、スレッドはポートに対して受信
権をもっていれば、そのポートのメッセージ・キューか
らメッセージを移動することができる。ポート権は、個
別のスレッドではなく、タスクの資源と考えられてい
る。ポートに対する送信権はいくつでも可能である（多
数の異なるタスクが保有する）。しかるに、ポートに対
する受信権は１つだけである。実際には、ポートは受信
権を割り当てると作成されるが、ポートが壊されるの
は、受信権の割当てが解除されたときだけである（明示
的に、またはタスクが消滅したときは黙示的に）。さら
に、ポートの属性は受信権を通して操作される。複数の
スレッド（同一または異なるタスクの）はポートへの送
信を同時に行うことができ、複数のスレッド（同一タス
クの）はポートからの受信を同時に行うことができる。
ポート権は、ポートとの間でメッセージを送受信する許
可（permission）または機能（capability）として働く
ので、ポート権によって実現されるシステムのセキュリ
ティは低レベルになっている。ポートの「所有者」（ow
ner）は受信権を保持しているタスクである。別のタス
クがポートの送信権を取得できるのは、（所有者から、
あるいはそのポートの有効な送信権を保持するいずれか
のタスクから）送信権が明示的に与えられた場合だけで
ある。かれは主に、送信権をメッセージに組み入れて、
そのメッセージを別のタスクへ送ることにより行われ
る。あるタスクに送信権を与えると、そのタスクには、
必要なだけのメッセージをポートへ送る許可が与えられ
る。一回送信権（send−once right）と呼ばれる、別の
種類のポート権がある。このポート権所持者は１つのメ
ッセージだけをポートへ送ることができ、その時点で一
回送信権は無効になり、再使用することができない。な
お、ポートの受信権をメッセージに入れて別のタスクへ
送ると、ポートの所有権を移転することができる。

タスクはポート権を作るか、あるいはポート権をメッ
セージで受け取ることによりポート権を獲得する。受信
権は明示的にだけ作ることができる（上述したように、
ポート割当てを行うことにより）。送信権は、既存の送
信権または受信権から明示的に作ることも、メッセージ
に入れて送信するとき黙示的に作ることもできる。一回
送信権は、受信権だけから明示的にも黙示的にも作るこ
とができる。ある権利がメッセージで送信されるとき、
送信側は、その権利がコピーされるか、移動されるか、
あるいは送信オペレーションで作成された新権利である
かを指定することができる。（受信権は、当然のことな
がら、移動しかできない）。権利が移動されるときは、
送信側はその権利を失い、受信側がその権利を取得す
る。コピーされるときは、権利は送信側に残っている
が、その権利のコピーが作成されて受信側に渡される。
作成されたときは、送信側は受信権を提供し、新しい送
信権または一回送信権が作られて受信側に渡される。タ
スクがなんらかの方法でポート権を獲得すると、Machは
それに名前を付ける。なお、名前が付けられるのはポー
ト自体ではなく、そのポート権である。（それにもかか
わらず、Machの作成者は、分かりやすいポート権名（po
rt right name）ではなく、ポート名（port name）でポ
ート権の名前を参照することを決定している。）この名
前はスカラー値（Intelマシンでは32ビット）になって
おり、タスク内だけでユニークであることが保証され
（このことは、複数のタスクは各々が、同一の数値から
なるが、完全に異なるポートに対するポート権を表して
いるポート名をもつことができることを意味する）、ラ
ンダムに選択されている。タスクによって保持される各
権利ごとに、必ずしも異なるポート名を割り当てる必要
はない。一回送信権は常に、各権利ごとに別の名前をも
っている。しかし、同じポートを参照する受信権と送信
権は同じ名前をもっている。

ポート権には、いくつかの属性が関連づけられてい
る。すなわち、権利のタイプ（送信、一回送信、受信、
ポート・セット、またはデッド名（dead name））、お
よび上記権利のタイプ別の参照カウントである。あるタ
スクがポートの権利を獲得し、そのポートの送信権また
は受信権をすでにもっているときは、関連のポート名の
参照カウントがインクリメントされる。ポート名は、そ
の関連ポートが壊されるとデッド名（dead name）にな
る。つまり、その受信権が割当て解除されているポート
の送信権または一回送信権を表している、すべてのポー
ト名はデッド名になる。タスクは、その権利の１つがデ
ッドになったとき通知を要求することができる。カーネ
ルは、各ポートの送信権と受信権の数のカウントを、シ
ステム・ワードでとっている。受信権を保持するタスク
（サーバなど）は、この数がゼロに達して、そのポート
に対する送信側（クライアント）が残っていないことを
示しているとき、通知メッセージを送ることを要求する
ことができる。これは「送信側が残っていない」（no m
ore senders）通知と呼ばれる。要求には、通知を送る
べきポートに対する送信権が含まれていなければならな
い。

ポート・セット ポート・セットは、ポートの集合から同時に受信でき
るようにするものである。つまり、受信権をポート・セ
ットに追加しておくと、ポート・セットで受信が行われ
るとき、セット内のポートの１つからメッセージを受信
することができる。メッセージを出したポートの受信権
の名前は受信オペレーションによって報告される。

メッセージ Mach IPCメッセージはヘッダ（header）とインライン
・データ（in−line data）部分からなっており、任意
的に、いくつかのアウトオブライン・メモリ（out−of
−line memory）領域とポート権（port right）を含ん
でいる。メッセージがポート権とアウトオブライン・メ
モリのどちらも含んでいないときは、そのメッセージは
単純（simple）メッセージであると言われる。含んでい
れば、それは複合（complex）メッセージである。単純
メッセージはメッセージ・ヘッダと、その直後に続くイ
ンライン・データ部分とを含んでいる。メッセージ・ヘ
ッダは宛先ポート送信権、応答を送ることができる任意
の送信権（通常は、一回送信権）、およびメッセージの
データ部分の長さを含んでいる。インライン・データは
可変長であり（ポート単位で指定された最大値の制約を
受ける）、解釈されずにコピーされる。複合メッセージ
はメッセージ・ヘッダ（フォーマットは単純メッセージ
と同じ）と、そのあとに置かれた次のものとからなって
いる。つまり、アウトオブライン・メモリ領域の数のカ
ウントと、これらの領域とポートのカーネルによる処理
を記述した後処理配列（disposition array）と、アウ
トオブライン記述子とポート権を収めている配列であ
る。

ポート権の後処理配列はポート権をどのように処理し
たいか、つまり、コピーするのか、作成するのか、ター
ゲット・タスクへ移動するのかを記述している。アウト
オブライン・メモリの後処理配列は、メッセージがキュ
ーに置かれたとき割当てを解除するのかどうか、あるい
はバーチャル・メモリcopy−on−rightメカニズムを通
してメモリを受信側タスクのアドレス空間にコピーする
のか、受信側アドレス空間にマッピングするのかを、各
メモリ範囲別に指定している。タスクがメッセージを受
け取ると、ヘッダ、インライン・データ、および記述子
配列が、受信コールへのパラメータの中で指定されたア
ドレスにコピーされる。メッセージがアウトオブライン
・データを含んでいれば、受信側タスクにアドレス空間
内のバーチャル・メモリはアウトオブライン・データを
収容するようにカーネルによって自動的に割り当てられ
る。データの処理を終えたとき、これらのメモリ領域の
割当てを解除するのは受信側タスクの責任である。

メッセージ送信の意義 Mach IPCは基本的には非同期の性格をもっている。
スレッドはメッセージをポートへ送り、メッセージがポ
ート上のキューに置かれると、送信側スレッドは実行を
続ける。ポートのキューに置かれたメッセージがなけれ
ば、ポートでの受信はブロック（block）する。効率化
のために、send/receiveが結合したコールが用意されて
おり、このコールは、メッセージを送信すると、特定の
応答ポートでメッセージを待つことを即時にブロックす
る（同期モデルの実現）。すべてのメッセージ・オペレ
ーションでタイムアウトを設定しておくと、メッセージ
が特定の時間期間内に送信できないとき（または受信さ
れるメッセージがないとき）オペレーションが途中で中
止（abort）されることになる。sendコールは対応する
ポートがその最大メッセージ数まで達している送信権を
使用すると、ブロックされる。sendが一回送信権を使用
していれば、メッセージは、ポートが一杯であってもキ
ューに置かれることが保証される。メッセージの配達は
信頼性があり、メッセージは送信順に受信されることが
保証される。なお、Machには、非同期モデルよりも同期
モデルの場合に最適化する特殊ケース・コードがある。
最高速のIPCラウンドトリップ・タイムは、サーバがrec
eiveに続いてループに入って反復的send/receiveを行
い、クライアントがクライアント側のループに入って対
応するsend/receiveを行うことによって達成される。

識別子としてのポート権 カーネルは、ポート権が偽造され得ないこと、メッセ
ージが誤送または不正に使用され得ないことを保証する
ので、ポート権は非常に信頼性があり、安全な識別子
（identifier）の働きをする。Machは、タスク、スレッ
ド、メモリ・オブジェクト、外部メモリ・マネージャ、
システム特権オペレーションの実行許可、プロセッサ割
当てなどを含む、システム内のほとんどすべてを表すた
めにポート権を使用することによってこれを利用する。
さらに、カーネルは自らがメッセージを送受信できるの
で（カーネルは自身を「特殊」タスクとして表してい
る）、大部分のカーネル・サービスは、システム・コー
ルのトラップではなく、IPCメッセージを対してアクセ
スされる。その必要が起こった場合、サービスが比較的
容易にカーネルから移出（migrate）できたのはそのた
めである。

同期化 現在、Mach同期化機能を直接にサポートしていない。
しかし、従来のオペレーティング・システムはルーチン
として同期化サービスを提供している。この種の同期化
サービスは、セマフォアとモニタと条件（下述する）と
いった、多数の公知のメカニズムを採用している、セマ
フォア（semaphore）とは、資源への排他的アクセスと
共有アクセスを可能にする同期化メカニズムである。セ
マフォアは獲得し、解放することができ（排他的モード
または共有モードで）、獲得オペレーションでタイムア
ウト期限を任意的に指定することができる。セマフォア
は、セマフォアを保持しているスレッドが途中で終了し
たとき、セマフォアに関連するカウンタが調整され、待
ちに置かれていたスレッドは該当するとき、ブロックが
解除される（unblock）という意味で任意的に回復可能
である。

モニタ（monitor）と条件（condition）は、単純なセ
マフォアよりも相対的に統制のとれた（しかもより安全
な）スタイルの同期化を実現するメカニズムである。モ
ニタ・ロック（ミュテックス（mutex）とも呼ばれる）
は、基本的には、ある種のデータへの相互排他的アクセ
スを可能にするバイナリ・セマフォアである。条件変数
は、プログラマが定義したある種のブール方程式がモニ
タのコンテキスト内で真になるのを待ち、そのことを知
らせるために使用することができる。モニタ・ロックを
保持するスレッドがある条件を持つ必要があるときは、
モニタ・ロックが手放され、そのスレッドはブロックさ
れる。そのあとで、ロックを保持する別のスレッドが条
件が真であると通知すると、待ちに置かれていたスレッ
ドはブロックが解除され、ロックを再獲得してから実行
を続ける。スレッドはある条件についてブロードキャス
ト・オペレーション（broadcast operation）を行うこ
ともでき、そのときはその条件を待っていたスレッドの
すべてはブロックが解除される。条件待ちオペレーショ
ンで、スレッドが条件を持つ時間を制限する任意のタイ
ムアウトを設定することも可能である。

スケジューリング Machはマルチプロセッサ機能を備えているので、マル
チプロセッサ環境でスレッドをスケジューリングするこ
とができる。Machでは、プロセッサをグループ化したプ
ロセッサ・セットが定義されており、また、プロセッサ
・セットと関連づけることができるスケジューリング・
ポリシが定義されている。Machには、タイムシェア（ti
meshare）と固定優先度（fixed priority）の、２つの
スケジューリング・ポリシが用意されている。タイムシ
ェア・ポリシは、スレッドによるCPU使用の指数平均値
（exponential average）に基づいている。このポリシ
は、スレッドとプロセッサの数に基づいて時間単位量を
最適化することも試みている。固定優先度ポリシは優先
度を変更しないが、同じ優先度のスレッドでラウンドロ
ビン・スケジューリング（round−robin scheduling）
を行う。スレッドはそのプロセッサ・セットのデフォル
ト・スケジューリング・ポリシを使用することも、その
プロセッサ・セットで使用できるスケジューリング・ポ
リシのいずれかを明示的に使用することもできる。プロ
セッサとスレッドには最大優先度を設定することができ
る。Machでは、優先度値が低くなると、緊急度が大きく
なる。

障害 Mach障害処理サービスの目的は、標準プロセッサ障害
とユーザが定義したプロセッサ障害の両方を処理する柔
軟なメカニズムを提供することである。標準カーネル機
能であるスレッド、メッセージ、およびポートは障害処
理メカニズムを提供するために使用される。（Mach説明
書では「例外」（exception）という用語が使用されて
いる個所で、本明細書では「障害」（fault）という用
語が使用されている。本明細書でこのような用語を使い
分けたのは、ハードウェア障害とＣ＋＋言語の例外メカ
ニズムとを区別するためである。）スレッドとタスク
は、障害ポート（fault port）をもっている。これらは
継承ルールが異なり、その使い方が若干異なっている。
エラー処理はスレッド単位で行われることが期待され、
デバッギングはタスク単位で取り扱われることが期待さ
れている。タスクの障害ポートは親タスクから子タスク
へ継承されるのに対し、スレッドの障害ポートは継承さ
れず、ハンドラがないことがデフォルトになっている。
スレッドの障害ハンドラはタスクの障害ハンドラに優先
している。スレッドが障害を引き起こすと、カーネルは
スレッドをブロックし、障害メッセージを障害ポート経
由でスレッドの障害ハンドラへ送信する。ハンドラはメ
ッセージを障害ポートから受け取るタスクである。メッ
セージは、障害、その障害を起こしたスレッドとタスク
に関する情報を含んでいる。ハンドラはその機能を障害
のタイプに従って実行する。該当する場合には、ハンド
ラは障害を起こしたスレッドの実行状態を取得し、変更
することができる。取り得るアクションとしては、障害
をクリアすること、スレッドを終了すること、障害をタ
スク・レベル・ハンドラへ引き渡すことがある。障害は
タイプとデータによって識別される。Machでは、すべて
のMachインプリメンテーションでサポートされる、いく
つかのマシン独立障害タイプが定義されている（例え
ば、不正アクセス、不正命令、ブレークポイントな
ど）。その他の障害タイプはインプリメンテーション依
存にすることができる。（例えば、ｆ−line、コプロセ
ッサ違反など）。

ホストとプロセッサ・セット Machでは、ホスト（host）という考え方を取り入れて
いる。ホストとは、基本的に、ホストがそこで実行され
ているコンピュータを抽象化したものである。種々のオ
ペレーションは、タスクがホストに対してもっている個
々のポート権に応じてホストで実行することができる。
センシティブでない情報は、ホスト名ポート（host nam
e port）に対して送信権を保持するタスクによって取得
することができる。そのような情報の例としては、カー
ネルのバージョンやシステム・クロックの値へのアクセ
ス権を取得する権利がある。他の情報はほとんどすべて
がセンシティブと扱われるので、その情報を取得または
操作するには、よりハイレベルの特権が必要である。こ
のハイレベル特権は、タスクがホスト制御ポート（host
control port）（ホスト特権ポート（host privilege
port）とも呼ばれる）に対して送信権を保持していると
きは包含されている。この権利をもつと、タスクはカー
ネルに対して可能とされるほとんどすべてのことを行う
ことができ、そのために、IPCサービスがサポートして
いるシステムのセキュリティ面がバイパスされることに
なるので、この権利は非常に慎重に、しかも選択的にタ
スクに与えなければならない。このハイレベル特権をも
っていると種々のオペレーションを実行することができ
る。そのようなオペレーションとしては、システム・ク
ロック設定値の変更、システムの総パフォーマンスおよ
び資源使用状況統計の取得、マシンを再ブートするこ
と、などがある。

また、Machには、プロセッサ（processor）とプロセ
ッサ・セット（processor set）という考え方も取り入
れられている。これによると、タスクはそのスレッドを
いつ、どのプロセッサで実行させるかを、より慎重に指
定することができる。プロセッサとプロセッサ・セット
は、ホスト特権ポートを使用すると、列挙して管理する
ことができる。プロセッサはシステム内の特定のプロセ
ッサを表し、プロセッサ・セットはプロセッサの集まり
を表している。新プロセッサ・セットを作成し、必要に
応じてプロセッサを追加しあるいは除去するためのサー
ビスが用意されている。また、タスク全体または特定の
スレッドをセットに割り当てるためのサービスも用意さ
れている。これらのサービスを通して、プログラマは、
アプリケーションを構成するスレッドとタスクをいつ実
行させるかを制御することができる（粗粒制御）。これ
により、プログラマは、ある種のスレッドをいつプロセ
ッサ・セットで並列に実行させるかを指定することがで
きる。これらの機能を明示に使用しないタスクやスレッ
ドに対しては、デフォルト割当てとしてシステムのデフ
ォルト・プロセッサ・セット（default processor se
t）が割り当てられる。このプロセッサ・セットは、一
般的に、他のセットで使用されていないシステム内のプ
ロセッサを含んでいる。

セキュリティ Machは、上述したサービスのほかに、他のカテゴリの
サービスを含んでいる場合がある。例えば、Machはセキ
ュリティに関係するサービスを含んでいる場合がある。
Machセキュリティ・サービスによれば、すべてのタスク
はセキュリティ・トークン（security token）をもって
いる。これはMachによって判読されないスカラー値にな
っている。ホスト・セキュリティ・ポート（host secur
ity port）と呼ばれるポートがあり、これはブートスト
ラップ・タスクに渡され、そこから信頼できるセキュリ
ティ・サーバへ受け渡される。タスクのセキュリティ・
トークンは、ホスト・セキュリティ・ポートに対して送
信権を所持しているタスクが設定し、変更することがで
きるが、タスクのセキュリティ・ポートの値を判断する
ためには特別な許可は不要である（もちろん、タスクの
制御ポートを保持している場合は別である）。Mach IPC
メッセージが受信された時点で、メッセージの送信側の
セキュリティ・トークンが、receive関数に対する出力
パラメータの１つとして返される。ホスト・セキュリテ
ィ・ポートを保持するタスクはメッセージを送信し、そ
のメッセージに別のセキュリティ・トークンを割り当て
ることができるので、メッセージが別のタスクから送ら
れてきたように見える。これらのサービスをシステムの
上位層で使用して、様々なセキュリティの程度を実現す
ることができる。

ラッパー・クラス・ライブラリ このセクションでは、Machマイクロカーネルから提供
されるサービスのオブジェクト指向インタフェースにつ
いて、分野別に説明する。Machサービスへのこのオブジ
ェクト指向インタフェースは、コード・ライブラリ110
によって実現されたラッパー・クラス・ライブラリ402
を表している。ラッパー・クラス・ライブラリ402は、
上述したように、スレッド・クラス404、タスク・クラ
ス406、バーチャル・メモリ・クラス408、IPCクラス41
0、同期化クラス412、スケジューリング・クラス414、
障害クラス416、およびマシン・クラス418を含んでい
る。ラッパー・クラス・ライブラリ402は、基礎となる
オペレーティング・システム114から提供されるサービ
スに応じて、セキュリティ・クラス420などの追加のク
ラスを含んでいる場合もある。各分野は各クラスの目的
と関数を詳しく説明しているクラス図とテキストを使用
して説明されている。選択されたメソッドが示され、定
義されている（該当する場合には、メソッドのパラメー
タ・リストも示されている）。従って、このセクション
には、ラッパー・クラス・ライブラリ402のオペレーシ
ョンの定義と説明が詳しく説明されている。ラッパー・
クラス・ライブラリ402のメソッドのインプリメンテー
ションについては、別のセクションで説明する。

クラス図は、クラス間の関係とカーディナリティ（ca
rdinality）を表現するための公知のBoochアイコンを用
いて示されている。これらのBoochアイコンは便宜上第1
7図に示されている。Boochアイコンは、前掲のGray Boo
ch著「オブジェクト指向設計とそのアプリケーション」
に説明されている。ラッパー・クラス・ライブラリ402
は好ましくは、公知のＣ＋＋プログラミング言語を使用
して実現されている。しかし、他のプログラミング言語
を使用することも可能である。好ましくは、クラスの説
明はSPI（System Programming Interface−システム・
プログラミング・インタフェース）、API（Application
Programming Interface−アプリケーション・プログラ
ミング・インタフェース）、Internalおよび“Noose"メ
ソッドに分類されており、当該コード＃ifdefステート
メントで囲んで（Nooseメソッドの場合はコメントで）
示されている。SPIインタフェースは使用される特定コ
ンピュータ・プラットフォームに特有のものである。こ
こでは、使用の便宜上、ラッパー・クラス・ライブラリ
402は、IBM MicroKernel（Machバージョン3.0に準拠）
またはコンパチブルに従って動作するコンピュータ・プ
ラットフォームと関連づけて示され、説明されている。
この分野の専門家ならば理解されるように、SPIクラス
は、本明細書に開示されている教示事項に基づいて、他
のコンピュータ・プラットフォームに合わせて変更する
ことが可能である。

APIインタフェースは、システムが稼働するプラット
フォームに関係なく、ラッパー・クラスライブラリ402
に含まれている。Internalインタフェースは低レベルの
インプリメンテーションだけで使用されることを目的と
している。Nooseメソッドが用意されているのは、ラッ
パー128と一緒に動作するアプリケーション130が、Mach
114上で直接に動作するように書かれたアプリケーショ
ン134（またはサーバ）と通信できるようにするためで
あり、それだけである。Nooseメソッドを使用すると、
ラッパー128で設定された、意図するオブジェクト意向
プログラミング・モデルの範囲外にあるように、生のMa
ch機能をアクセスすることができる。Nooseメソッドは
あまり利用すべきではない。SPIとAPI（おそらくIntern
alも）クラスとメソッドがあれば、どのようにアプリケ
ーション、コンポーネント、またはサブシステムでも十
分に実現することができる。

スレッド・クラス 第５図は、スレッド・クラス404とタスク・クラス406
のクラス図501である。スレッドクラス404は、Mach114
のタスキングとスレディング機能とのオブジェクト指向
インタフェースとなるものである。スレッド・クラス40
4のいくつかはハンドル（handle）クラス（その名前が
示すとおり）であり、このことは対応するカーネル・エ
ンティティへの参照を表していることを意味する。ハン
ドル・クラスでのヌル・コンストラクタ（null constru
ctor）は空のハンドル（empty handle）オブジェクトを
作成する。空のハンドル・オブジェクトは初期状態で
は、どのカーネル・エンティティにも対応していない。
これは、ストリーミング、割当て、またはコピー・オペ
レーションによって初期化しなければならない。空のハ
ンドルでメソッドをコールすると例外が引き起こされ
る。ハンドル・オブジェクトはいくつでもコピーできる
が、各コピーは同じカーネル・エンティティを指してい
る。ハンドル・オブジェクトを内部で参照カウントをと
ってあるので、カーネル・エンティティを表す最後のオ
ブジェクトが壊されたときカーネル・エンティティを削
除することができる。

TThreadHandleはシステム内のスレッド・エンティテ
ィを表す具象クラス（concrete class）である。これに
は、スレッドを制御し、スレッドに関する情報を判断す
るためのメソッドが用意されている。また、システムに
新しいスレッドを作る（spawn）ためのメカニズムも用
意されている。制御オペレーションとしては、キリング
（killing−削除）、一時中止／再開、スレッドの死亡
監視（death watch）などがある。TThreadHandleを構築
してTThreadProgramオブジェクトに入れて渡すと、新し
いスレッドが現タスク上に作られる。新スレッドで最初
に実行されるコードはTThreadProgramオブジェクトのPr
epare（）とRun（）メソッドである。TThreadHandleを
壊しても、それが表しているスレッドは壊されない。TT
hreadHandleオブジェクトにはキャンセル・オペレーシ
ョンもある。なお、各TThreadHandleオブジェクトは、
スレッドの制御ポートに対する送信権を含んでいる。こ
の情報は、一般的には、インタフェースからエクスポー
トされないが、ポート権を含んでいるので、TThreadPro
gramがストリームできる対象のストリーム・オブジェク
トはTIPCMessageStreamだけである。他のTStreamオブジ
ェクトに対してストリームしようとすると、例外が引き
起こされる。

TThreadHandleには、デバッガと実行時環境（runtime
environment）で使用されるメソッドと、ラッパー128
によって設定された環境の外で実行されるMachタスクと
のやりとりをサポートするメソッドがいくつか用意され
ている。これらのメソッドには、スレッドの状態の取得
と設定、別のタスク内に「空の」スレッドの作成、スレ
ッドの障害ポートの取得、スレッドの制御ポートへの権
利の返却、スレッド制御ポート送信権からのTThreadHan
dleハンドルの作成、などがある。

上述したように、ラッパー128は、アプリケーション1
30が動作するコンピューティング環境を設定する。簡略
化のために、ラッパー128によって設定されるこのコン
ピュータ環境をCEと呼ぶことにする。ラッパー128に対
して、TThreadHandleは現タスク上にCE実行時（runtim
e）スレッドを作成する。スレッドは、TTaskHandleクラ
スまたはTTaskHandleサブクラスでCreateThreadメソッ
ドを使用すると、現タスクにではなく別のタスク上に作
ることも可能である。（ただし、別のタスクにスレッド
を作成することは、一般的プログラミング・モデルとし
ては望ましくない。）別のCEタスク上にCEタスクを作成
するには、TCETaskHandle::CreateThreadメソッドが使
用される。そのために、実行すべきスレッドを記述して
いるTThreadProgramにこのメソッドが渡される。非CEス
レッド（つまり、ラッパー128によって設定されたコン
ピューティング環境で実行されないスレッド）を作成す
るには、CreateThreadメソッドがTTaskHandleの該当サ
ブクラス（つまり、他の非CEコンピューティング環境で
実行するように作成されたTTaskHandleのサブクラス）
で使用される。例えば、IBM OS2スレッドをOS2タスク上
に作成するには、TOS2TaskHandle::CreateThreadメソッ
ドが使用できる。CEスレッドを非CEタスクで実行するこ
とも、非CEスレッドをCEタスクで実行することも不可能
である。

TThreadHandleは、次のようなメソッドを含んでい
る。

TThreadHandle（const TThreadProgram＆copyThread
Code）：は、呼出し側タスクに新しいスレッドを作成す
る。TThreadProgramの内部コピーを作るが、これはスレ
ッドが終了すると削除される。

TThreadHandle（TThreadProgram＊adoptThreadCod
e）：は呼出し側タスクに新しいスレッドを作成する。a
doptThreadCodeを採用するが、これはスレッドが終了す
ると削除される。スレッドが所有していた資源も廃棄さ
れる。TThreadProgramのコピーは作られない。

TThreadHandle（EEexcution yourself）は呼出し側ス
レッドのためにスレッド・ハンドルを作成する。

TStreamはTThreadHandleオブジェクトにストリーム・
インされてTIPCMessageStreamに渡される。

CopyThreadSchedule（）は、オブジェクトをスケジュ
ールするために使用されるSchedulingオブジェクト（例
えば、TServerSchedule,TUIScheduleなど）を指すポイ
ンタを返す。TThreadScheduleオブジェクト用にメモリ
を割り当てるが、これは呼出し側で廃棄する必要があ
る。

SetThreadSchedule（const TThreadSchedule＆ newSc
hedule）はスレッド内のスケジューリング・オブジェク
トをnewScheduleオブジェクトにセットする。これよ
り、スレッドをどのようにスケジュールするかを制御す
ることができる。

GetScheduleState（TThreadHandle＆ theBlockedOnTh
read）を使用すると、このスレッドがブロックされてい
るスレッド（theBlockedOnThread）の現状態を照会する
ことができる。

CancelWaitAndPostException（）constは、ブロック
しているカーネル・コールをブロック解除し（unbloc
k）し、TKernelExceptionをスレッド（＊this）に引き
起こす。

WaitForDeathOf（）constは、スレッド（＊this）が
終了するまで、スレッド死亡（death）コールの監視を
行う。CreateDeathInterest（）はスレッド（＊this）
の死亡（death）に対して通知インタレスト（notificat
ion interest）を作成する。スレッドの終了時に、指定
されたTInterestは通知を受け取る。

TThreadProgramは、新スレッドを作成するために必要
なすべての情報をカプセル化する抽象基底クラスであ
る。これには、実行すべきコード、スケジューリング情
報、およびスレッドのスタックが含まれる。これを使用
するには、サブクラス化し、BeginメソッドとRunメソッ
ドをオーバライドしたあとで、オブジェクトのインスタ
ンスをTThreadHandleのコンストランクタに受け渡して
スレッドを作成しなければならない。Beginルーチンが
用意されたのは、スタートアップ同期化を容易にするた
めである。Beginは、TThreadHandleコンストラクタが完
了する前に新スレッドで実行される。RunルーチンはTTh
readHandleコンストラクタが完了したあと実行される。
メソッドCopyThredScheduleとGetStackSizeはデフォル
トのスレッド・スケジュールとスタック・サイズを返
す。デフォルトと異なる値を得るには、これらのメソッ
ドをオーバライドすれば、希望のスレッド・スケジュー
ルおよび／またはスタック・サイズが返される。TThrea
dProgramは次のようなメソッドを含んでいる。

TThreadProgram（const TText＆ taskDescription）:
TaskDescriptionからは、TTaskHandle::GetTaskDescrip
tionメソッドを通してアクセスできるタスクのテキスト
記述が得られる。これは、オブジェクトがTTaskHandle
コンストラクタに渡されたときだけ効力をもっている。
デフォルト・コンストラクタを代わりに使用すれば、イ
ンタフェースはTTaskHandle::GetTatskDescriptionが返
す固有名を合成する。

GetStackSize（）は、スレッド用にセットアップすべ
きスタックのサイズを返す。「デフォルト」スタック・
サイズが必要でなければ、このメソッドをオーバライド
する。

GetStack（）：スレッドのスタックをセットアップす
るために使用される。独自のスタックを用意したい場合
は、このメソッドをオーバライドする。

Run（）は、スレッドで実行されるコードのエントリ
・ポイント（entry point）を表している。スレッドに
実行させるコードを用意する場合は、このメソッドをオ
ーバライドする。

タスク・クラス タスク・クラス406のクラス図は第５図に示されてい
る。

TTaskHandleは、基本的Machタスクのすべての属性と
オペレーションをカプセル化している具象基底クラス
（concrete base class）である。これを使用すると、
システム上の任意のタスクを参照して制御することがで
きる。しかし、TTaskHandleは実行時環境についてなに
も知識をもっていないので、直接に使用してタスクを作
成することはできない。具体的な実行時知識をもつサブ
クラスを作成して、タスクを作成できるようにする十分
なプロトコルがプロテクト・メソッド（protected meth
ods）を通して提供されるようになっている（下に示すT
CETaskHandleはそのようなクラスの例である）。TTaskH
andleオブジェクトは、IPCを通してのみストリーム化し
てTTPCMessageStreamsに出し入れして他のオブジェクト
へ送ることができ、これらはTCETaskHandleに関連する
コレクション（collection）に入って返される。TTaskH
andleに関連するタスク制御オペレーションには、タス
クの削除、タスクの一時中止と再開、タスクの死亡監視
（death watch）などがある。通知メソッド（informati
onal method）にはそのホストの取得、その登録ポート
の取得と設定、そのポートまたはバーチャル・メモリ領
域の列挙、その障害ポートの取得、そのスレッドの取得
などがある。TTaskHandleは、次のようなメソッドを含
んでいる。

TTaskHandle（EEexecutionThread）は特定スレッドの
タスク・ハンドルを作成する。

Suspend（）はタスク（つまり、タスクに含まれるす
べてのスレッド）を一時中止する。Resume（）はタスク
（つまり、タスクに含まれるすべてのスレッド）を再開
する。

Kill（）はタスクを終了する。タスクに含まれるすべ
てのスレッドは終了する。

WaitForDeathOf（）はタスクの死亡監視を行う。呼出
し側スレッドはタスク（＊this）が終了するまでブロッ
クしている。CreateDeathInterest（）はタスクの死亡
に対して通知インタレストを作成する。TInterestオブ
ジェクトに指定されているスレッドはタスク（＊this）
が終了すると通知を受け取る。

AllocateMemory（size_t howManyBytes,TMemorySurro
gate＆ newRange）は、タスクのアドレス空間内の任意
の個所からある範囲の（匿名）バーチャル・メモリを割
り当てる。必要とするサイズ（バイト数）はhowManyByt
esに指定されている。新しく割り当てられたメモリの開
始アドレス（ページ境界合わせしたあとの）と実際のサ
イズはnewRangeに入って返される。

AllocateReserveAddressMemory（const TMemorySurro
gate＆ range,TMemorySurrogate＆ newRange）は、タス
クのアドレス空間内の特定予約アドレスからある範囲の
（匿名）バーチャル・メモリを割り当てる。範囲引数は
要求のアドレスとサイズを指定している。newRangeは割
り振られたメモリのページ境界合わせアドレスとサイズ
を返す。

GetRemotePorts（TCollection〈TRemotePortRightHan
dle〉＆ thePortSet）は＊thisタスクのポート・リスト
を取得する。返されたCollectionの中のメモリの割当て
を解除するのは呼出し側の責任である。

virtual void CreateFaultAssociationCollection（T
Collection〈FaultAssociation〉＆ where）はこのタス
ク用に登録された障害ポートを返す。

TCETaskHandleはCE実行時システムと一緒に実行され
るMachタスクを表しているTTaskHandleのサブクラスで
ある（すでに述べたように、CEはラッパー128によって
設定されたコンピューティング環境を表し、CEオブジェ
クト環境をセットアップするために必要なすべての知識
を具現化している）。これを使用すると、TThreadProgr
amをそのコンストラクタに渡すことによって新しいタス
クを作ることができる。新タスクはシングル・スレッド
と共に作成され、これはTECTaskHandleコンストラクタ
に渡されたTThreadProgramオブジェクトによって記述さ
れている。TCETaskHandlをTTaskHandleから作成できる
ようにコンストラクタもある。非CE実行時タスクがTCET
askHandleでラップされていないことを確かめるため
に、このコンストラクタはCEローダ／ライブラリ・サー
バ（つまり、CE環境で動作しているローダ／ライブラリ
・サーバ）に問い合わせて、ラップされるタスクがそこ
に登録されてることを確認する。これは（ユーザが介入
することなく）自動的に行われる。TCETaskHandleは次
のようなメソッドを含んでいる。

TECTaskHandle（const TThreadProgram＆ whatToRu
n）は新しいタスクと、特定コードを実行するスレッド
とを作成する。新しいスレッドは‘whatToRun'内のコー
ドを実行する。

TECTaskHandle（EExecutionTask）は現在実行中のス
レッドのタスクをラップする。

TECTaskHandle（const TThreadProgram＆ whatToRun,
const TOrderedCollection〈TLibrarySearcher〉＆ lib
rarySearchers）は新しいタスクと、特定ライブラリ・
サーチを使用して特定コードを実行するスレッドを作成
する。librarysearchersは名前を解決するために使用さ
れるライブラリのリストを指定している。

TECTaskHandle（const TTaskHandle＆ aTask）は汎用
タスク・オブジェクトからCEタスク・オブジェクトを作
成する。

AddLibrarySearcher（const TLibrarySearcher＆ new
LibSearcher）はタスクのライブラリ・サーチャを追加
する。ローダはnewLibrarySearcherを最初に使用してli
b参照を解決する。つまり、newLibrarySearcherは参照
を解決するために使用されるコレクションの先頭に置か
れる。

GetTaskDescription（TText＆ description）constは
タスクのストリング記述を返す。このストリングはルー
ト（root）スレッドの関連TThreadProgram（コンストラ
クタへ渡された）から取得される。ストリングはユニー
クになるように保証され、記述がTThreadProgramコンス
トラクタに渡されていなければ、インタフェースによっ
てストリングが合成される。

NotifyUponCreation（TInterest＊ notifyMe）は新し
いタスクがシステムに作成されるごとに、そのことを同
期して呼出し側に通知する。（＊this）タスク・オブジ
ェクトは関与しない。このコールを出したタスクがこの
通知を受け取る。

バーチャル・メモリ・クラス 第６図は、バーチャル・メモリ・クラス408のクラス
図601である。なお、TTaskHandleはタスクを表すクラス
である。TTaskHandleはタスク・クラス406のセクション
ですでに説明した通りである。バーチャル・メモリ・オ
ペレーションでは、TTaskHandleタイプのオブジェクト
は、オペレーションが行われるアドレス空間を指定する
ために使用される。Machで実行できるバーチャル・メモ
リ・オペレーションの大部分はTTaskHandleのメソッド
として表されている。バーチャル・メモリに働きかける
TTaskHandleの種々メソッドはTMemorySurrogateをパラ
メータとして受け取る。種々メソッドは、TTaskHandle
の個所に詳しく説明されている。いくつかのメモリ・ク
ラスはコピー・コンストラクタおよび／または割当て演
算子（assignment operator）をもっている。ここで注
意すべきことは、メモリ・クラスは実際のメモリ自体で
はなく、メモリへの参照を含んでいることである。従っ
て、メモリ・クラス・オブジェクトがコピーまたはスト
リーム化されるとき、オブジェクト内の参照だけがコピ
ーされ、実際のメモリはコピーされない。TMemorySurro
gateクラスは、それが参照するメモリのコピーを行うた
めの明示のメソッドを含んでいる。

TMemorySurrogateは、バーチャル・アドレス空間内の
ある範囲の連続するメモリを表すクラスである。これ
は、開始アドレスとサイズ（バイト数）をもっている。
TMemorySurrogateを使用すると、ある種のオペレーショ
ンが実行されるメモリ範囲を指定することができる。こ
れらは、タスクに関連するアドレス空間内のバーチャル
・メモリを操作する、TTaskHandleのメソッドへ引数と
して渡されるのが普通である。このクラスは、特定のサ
イズをもつメモリ範囲を指定および／または渡すために
使用される。クラス自体はどのメモリも割り当てない。
既存のメモリをカプセル化するだけである。このクラス
で指定された実際のメモリ（引数としてコンストラクタ
に）を渡すのは、呼出し側の責任である。このクラスは
サブクラス化することはできない。

TChunkyMemoryは特定サイズのチャンク（chunk）でメ
モリを管理する抽象基底クラスである。メモリはチャン
ク（特定のchunkSizeの）単位で割り当てられるが、そ
れでもなお、ユーザにはメモリが一連のバイトとして見
える。TChunkyMemoryは次のようなメソッドを含んでい
る。

LocateChunk（size_t where,TMemorySurrogate＆ the
ContainingRange）はチャンクのコレクションの中を調
べて、メモリのアドレスとchunksizeをtheContainingRa
ngeに入れて返す。

CutBackTo（size_t where）はカットして、“where"
を収めているチャンクに戻す。つまり、オフセットwher
eにあるチャンクがリスト内の最後のチャンクとなる。

AllocateMemoryChunk（TMemorySurrogate＆ theAlloc
ateRange）はクライアントによってコールされて、メモ
リの新しいチャンクを必要に応じて割り当てる。割り当
てられた範囲を返す。

THeapChunkyMemoryはヒープ上のチャンク・メモリを
管理する具象クラスである。

TVMChunkyMemoryはバーチャル・メモリを使用してチ
ャンク・メモリを管理する具象クラスである。

TMemoryRegionInfoはタスクのアドレス空間内のバー
チャル・メモリ領域に関して使用されるクラスである。
メモリ属性情報（継承、保護など）を返す。また、メモ
リの領域に関連するメモリ・オブジェクトへのアクセス
と、メモリ領域にカプセル化されている実際のメモリ範
囲へのアクセスを可能にする。TMemoryRegionInfoの内
側にネストされたものとして、任意のメモリ領域のすべ
てのメモリ属性を定義するTMemoryAttributeBundleクラ
スがある。これは、すべてのメモリ属性を取得／設定し
たとき（または変更を最小にしてメモリ属性を再使用し
たいとき）に使用すると便利である。TMemoryAttribute
Bundleはメモリ・オブジェクトをタスクのアドレス空間
にマッピングすることを扱うためにクラスTTaskHandle
でも使用される。TMemoryRegionInfoは、次のようなメ
ソッドを含んでいる。

EMemoryProtection｛kReadOnly,kReadWrite,kExecut
e｝はメモリの保護を特定する。

EMemoryInheritance｛kDontInherit,kReadWriteInher
it,kCopyInherit｝はメモリの継承属性を特定する。

EMemoryBehavior｛kReferenceSequential,kReference
ReverseSequentail,kReferenceRandom｝はメモリがどの
ような仕方で参照されるかを特定する。

EMemoryAttribute｛kCacheable,kMigrateable｝はメ
モリのマシン特有属性がどのような仕方で管理されるか
を特定する。

EMemoryAdvice｛kWillUse,kWontUse｝はメモリがどの
ような使い方をされるかを特定する。

TMemoryObjectHandleはMachメモリ・オブジェクトの
考え方を表している基底クラスである。これは、バーチ
ャル・メモリにマッピングできるデータの断片を具現化
している。TMemoryObjectHandlesをクライアントに提供
するシステム・サーバぱ、ファイル、デバイス、パーテ
ィション（device partitions）などのメモリ・オブジ
ェクトをタイプ別に定義するために、TMemoryObjectHan
dleからサブクラス化する。一般的バーチャル・メモリ
・サービスのクライアントの場合は、TMemoryObjectHan
dleと各種サブクラスの主要用途は、タスクのアドレス
空間にマッピングできるデータに共通のタイプとプロト
コルを提供することである。

TChunkyStreamは、メモリのチャンクによってバック
されたランダム・アクセス・ストリームを具現化する具
象クラス（TRandomAccessStreamから派生）である。チ
ャンク・サイズは明示に指定することも、デフォルトを
使用することも可能である。チャンクを列挙することが
できる。このクラスはTMemoryクラスの共通機能となる
ので、メモリを連続するものとして管理するオーバヘッ
ドは発生しない。TMemoryの他の機能が必要ならば、他
のクラスの定義が可能である。

TContiguousMemorySystemは連続メモリ（クライアン
トが用意したもの）を使用する具象クラスである。これ
はTRandomAccessStreamから派生しているので、すべて
のアクセス・オペレーション（Seek（）など）はTConti
guousMemoryStreamオブジェクトに適用可能である。

プロセス間通信（IPC）クラス IPCクラス410はMach IPCメッセージの抽象化を表して
いる。なお、すべてのメッセージング作用はメッセージ
・クラスに対するものである。ポート権クラスは基本的
にメッセージをアドレスするためのものである。使用モ
デル（usagemodel）は好ましくは次のようになってい
る。TIPCMessageStreamはインスタンス化（instantiate
−インスタンス生成）され、オブジェクトはそこに対し
てストリームされ、TIPCMessageStream:Sendメソッドが
コールされ、宛先送信権を表しているオブジェクトが引
数として渡される。メッセージを受信するには、TIPCMe
ssageStreamがインスタンス化され、そのReceiveメソッ
ドがコールされ、受信権オブジェクトが引数として渡さ
れる。Receiveから戻ったとき、オブジェクトをTIPCMes
sageStreamオブジェクトからストリームすることができ
る。なお、TIPCMessageStreamオブジェクトは再使用可
能（reusable）である。以下では、IPCメッセージ・ク
ラスのクラス図702を示している第７図、IPCアウトオブ
ライン・メモリ領域クラスのクラス図802を示している
第８図、およびIPCポート権クラスのクラス図902を示し
ている第９図を参照して、IPC410について詳しく説明す
る。

メッセージ・クラス MIPCMessageは、Mach IPCメッセージを表している抽
象基底クラスである。これは、ヘッダのフィールド、後
処理配列（disposition array）、およびポートとアウ
トオブライン・メモリ配列をセットアップするためのす
べてのメソッドを提供する。また、メッセージ送受信に
関するプロトコル全体も収めている。これは子クラスに
対する基本的プロトコルとなってインライン・メッセー
ジ・データをセットアップする。クラスTIPCMessageStr
eamとTIPCPrimitiveMessageはこのクラスから派生し、
データをメッセージに追加するための公開（public）メ
ソッドを提供する。MIPCMessageは次のようなメソッド
を含んでいる。

GetReplyPoyt（TPortSendSideHandle＆ replyPort）
は受信側だけで有効である。メッセージと一緒に送信さ
れていれば、応答ポート・オブジェクトを返す。これは
メッセージが受信されたあと、これが初めてコールされ
たときだけ返される。他の場合は、偽（FALSE）が返さ
れる。

TSecurityToken GetSenderSecurityToken（）は受信
側だけで有効である。このメッセージを送信したタスク
のセキュリティ・トークンを返す。

SetSenderSecurityToken（const TSecurityToken＆ i
mpostorSecurityToken,const TPortSendRight＆ hostSe
curityPort）は送信側だけで有効である。メッセージが
次回に送信されるとき、実際に送信を行うタスクのそれ
ではなく、指定されたセキュリティ・トークンを搬送す
る。次の送信のときだけ効力をもち、そのあと実際の送
信側のセキュリティ・トークン値を戻る。

IPCメッセージを送受信するためのメソッド（なおこ
れらのメソッドはすべて任意のTTimeタイムアウト値を
もっている。タイムアウトが必要でなければ、kPositiv
eInfinityを指定する。これらのメソッドはいずれも、m
sgヘッダ中の応答ポートの既存値を置き換える。応答ポ
ートの指定を可能にするこれらのメソッドでは、応答ポ
ート権の後処理はポート権自体と一緒に、MIPCMessag
e::TReplyPortDispositionオブジェクトを通して渡され
る。後処理状態は送信が持続している間だけ有効である
ので、これが応答ポートをセットする唯一の方法であ
る。後処理がMOVEであるポート権のオブジェクトは、送
信が行われると無効になる。）： Send（const TPortSendSideHandle＆ destinationPor
t,const TTime＆ timeout＝kPositiveInfinity）は片方
向の非同期送信である。

Send（const TPortSendSideHandle＆ destinationPor
t,const TReplyDisposition＆ replyPort,const TTime
＆ timeout＝kPositiveInfinity）は、send（−once）
応答ポートが指定された非同期送信である。

Receive（const TPortReceiveSideHandle＆ sourcePo
rt,const TTime＆ timeout＝kPositiveInfinity）は
「ブロックする」受信である。

SendAndReceive（const TPortSendSideHandle＆ send
Port,const TPortReceiveSideHandle＆ receivePort,co
nst TTime＆ timeout＝kPositiveInfinity）はメッセー
ジを送信し、ブロックして応答を受信する（応答ポート
はreceivePortから作られた一回送信権である）。

SendAndReceive（const TPortSendSideHandle＆ send
Port,const TPortReceiveSideHandle＆ receivePort,MI
PCMessage＆ receiveMsg,const TTime＆ timeout＝kPos
itiveInfinity）はメッセージを送信し、ブロックして
応答を受信する（応答ポートはreceivePortから作られ
た一回送信権である）。受信されたメッセージは重ね書
きを防止するために新しいメッセージ・オブジェクトに
入れられる。

ReplyAndReceive（const TPortSentSideHandle＆ rep
lyToPort,const TPortReceiveSideHandle＆ receivePor
t,const TTime＆ timeout＝kPositiveInfinity）：応答
を送り返し、ブロックして新しいメッセージを受信す
る。

ReplyAndReceive（const TPortSendSideHandle＆ rep
lyToPort,const TPortReceiveSideHandle＆ receivePor
t,MIPCMessage＆ receiveMsg,const TTime＆ timeout＝
kPositiveInfinity）は応答を送り返し、中断して新し
いメッセージを受信する。

ヘッダのポート権フィールドを取得／設定するための
サブクラスのメソッド（リモート・ポートとローカル・
ポート:SEND側では、REMOTE PORTは宛先ポートを指定
し、LOCAL PORTは応答ポートを指定する。RECEIVE側で
は、REMOTE PORTは応答ポート（応答すべき相手ポー
ト）を指定し、LOCAL PORTは応答を送ったポートを指定
する。ポートが送信された（送信すべき）方法はDispos
tionに入って返される。これは次の値をとることができ
る。

MACH_MSG_TYPE_（MOVE_RECEIVE,MOVE_SEND,MOVE_SEND_O
NCE,COPY_SEND,MAKE_SEND,MAKE_SEND_ONCE｝） GetRemotePort:リモート・ポート権を受け渡し、後処
理を指定する。

PORT RIGETメソッドは次のとおりである。

MovePortRightDescriptor:送信側はポート権を宛先へ
譲渡する。Send、SendOnce、およびReceive権で有効で
ある。

CopyPortSendRightDescriptor:送信側は宛先で送信権
のコピーを作成する。

MakePortSendRightDescriptor:新しい送信権が宛先で
作成される。

MakePortSendOnceRightDescriptor:新しい一回送信権
が宛先で作成される。

TIPCMessageStreamはストリーム・ベースのIPCメッセ
ージを抽象化したものである具象クラスである。これ
は、IPCオペレーションで使用することが望ましいクラ
スである。これはMIPCMessageDescriptorおよびTStream
から派生している。メッセージを送信するには、TIPCMe
ssageStreamのユーザは送信すべきデータをストリーム
・インする。このデータには、ポート権（TPortRightHa
ndleの派生物）、アウトオブライン・メモリ領域（TOut
OfLineMemorySurrogate）、ポート権配列（TPortRightH
andleArray）、これらのいずれかまたはすべてを収めて
いるオブジェクト、および必要とする他のオブジェクト
またはデータ・タイプが含まれる。TIPCMessageStream
は、メッセージ・ヘッダ内のポート権、ポート権配列、
およびアウトオブライン・メモリのために該当のデータ
構造を自動的にセットアップし、プレースホルダ（plac
e holder）をストリームに入れるので、これらのエレメ
ントはメッセージからストリーム・アウトされてストリ
ーム内の該当場所に置かれることになる。データがスト
リーム・インされると、メッセージはSendメソッドを使
用して送信され、該当の宛先ポート権（TPortSenderHan
dle）と、任意的に、応答ポートを提供する。メッセー
ジを受信するには、Receiveメソッドがコールされ、そ
こから受信されるポートの受信権（TPortReceiveHandl
e）を提供する。受信したばかりのデータはTIPCMessage
Streamからストリーム・アウトすることができる。

TIPCMessageStreamは、send/receive結合オペレーシ
ョンを行うための２つのメソッドも提供する。これらの
メソッドは、共通に使用されるメッセージ伝送セマンテ
ィクスを提供すること（およびMachマイクロカーネルで
高速パス（fastpath）を利用すること）を目的としてい
る。SendAndReceiveはクライアント側で同期スタイルse
ndを行い、そのあとreceiveでブロックして応答メッセ
ージをピックアップする。ReplyAndReceiveはサーバ側
で（おそらく）応答メッセージのsendを行い、その直後
にreceiveでブロックして次の要求を待機する。どちら
のコールの場合も、宛先ポートと受信ポートの指定が必
要である。さらに、SendAndReceiveメソッドは提供され
た受信権からの該当の一回送信権を自動的に作レッドの
終了時に、指定されたTInterestは通知を受け取る。

TIPCPrimitiveMessageはMIPCMessageから派生し、Mac
hメッセージ・システムとのより基本的な低レベル・イ
ンターフェースとなる具象クラスである。データはメッ
セージ・ヘッダとボディとの間getコールとsetコールを
通して受け渡しされる。ストリーミング機能はない。こ
れは、Mach IPCメッセージを表す具象クラスである。イ
ンライン・データはTMessageSurrogateに入れて渡すこ
とによりメッセージに加えられる。ポート権、配列、お
よびOOLdataは該当のメソッドを使用して明示的に追加
し抽出しなければならない。

TOutOfLineMemorySurrogateはIPCメッセージに組み入
れられるアウトオブライン・メモリ範囲を表している。
これはそのインプリメンテーションでTMemorySurrogate
を使用し、TMemorySurrogateにすでに入っているstartA
ddressとlength情報に後処理情報だけを追加する。この
クラスは、メッセージの送信時に使用される後処理情報
を含んでいることを除けば、TMemorySurrogateと同じで
あり、範囲に関連する記憶装置を表すことができる。こ
のクラスは、ストリーミング演算子、範囲をget/setす
るメソッド、および後処理情報をset/getするメソッド
を含んでいる。

ポート権 以下に説明するクラスは、Machポート権の有効なタイ
プすべてを表している。これらのクラスはすべて、以下
に説明する一般的作用（general behavior）を共有す
る。一般的に、ポート権オブジェクトがインスタンス化
されると、その権利のカーネルの参照カウントをインク
リメントし、ポート権オブジェクトが壊されると、カー
ネルのポート権参照カウントをデクリメントする。な
お、ポート権オブジェクトは「実」（real）カーネル・
ポート権エンティティのハンドル（handle）である。こ
れらはコピーが可能であり、その場合は、２つのオブジ
ェクトが同じカーネル・ポート権エンティティを参照す
ることになる。これらは内部で参照カウントがとられる
ので、あるポート権を参照するすべてのオブジェクトが
削除されると、カーネルのポート権参照カウントはデク
リメントされる。あるポート権がデッド名（dead nam
e）になったとき（つまり、それが属していたポートが
壊されたとき）、それを表すオブジェクトでメソッドを
使用しようとすると、例外が引き起こされる（参照カウ
ントをセットするといったオペレーションはデッド名で
も有効であるので、これらのオペレーションは除く）。

TPortRightHandleは、ポート権の考え方を表す抽象基
底クラスである。これは、ポート名の取得、デッド名通
知の要求、ポート権がデッド名であるかどうかを確かめ
るテストといった、各タイプのポート権に共通するプロ
トコル全体を収めている。（ポート名はmuch_port_name
_t typeとして返され、オブジェクト・ラッパーを使用
して書かれていないMachサーバとやりとりする手段とな
る。）また、これは共通スーパクラス（common super c
lass）ともなるので、すべてのタイプのポートを表す汎
用タイプを多態的に渡すことができる。TPortSenderHan
dleとTPortReceiverHandleはこれらのクラスから派生し
ている。このクラスはストリーミング・サポートのメソ
ッド（このクラスとこれを含んでいるクラスは、TIPCMe
ssageStreamクラスにだけストリーム・インまたはスト
リーム・アウトすることができる。他のSTreamにストリ
ーム・イン使用とすると、実行時に例外が引き起こされ
る）、Getters/Setters、および通知を要求するメソッ
ド（これは通知が送られる一回送信権を提供しなければ
ならない。受信権を渡す（参照によって）ことにより一
回送信権をMAKE（作成）し、一回送信権をADOPTING（採
用）することにより一回送信権をMOVE（移動）する）を
含んでいる。

TPortSenderHandleは、IPCメッセージを送信できるポ
ート権を表している抽象クラスである。例えば、これ
は、MIPCMessage::Sandが宛先ポートと応答ポートとし
て受け取るタイプである。クラスTPortSendRightHandle
とTPortSendOnceRightHandleはこのクラスから派生して
いる。このクラスはストリーミング・サポートのメソッ
ドとGetters/Settersとを含んでいる。

TPortSendRightHandleはポート送信権を表している。
これは、送信権で実行できるすべての代表的オペレーシ
ョンをサポートしている。これは有効なTPortReceiveRi
ghtHandleまたはTPortSendRightHandleをコンストラク
タに渡すことにより、あるいはそれをTIPCMessageStrea
mからストリーム・アウトすることにより作成される。
このクラスは、カーネル参照カウントに影響しないで空
のTPortSendRightHandleオブジェクトを作成するメソッ
ド、新しい送信権を現タスクに作成するコンストラク
タ、ストリーミング・サポートのメソッド、およびGett
ers/Settersを含んでいる。

TPortSendOnceRightHandleはポート一回送信権を表し
ている。これは、一回送信権で実行できるすべての代表
的オペレーションをサポートしている。これは有効なTP
ortReceiveRightHandleをコンストラクタに渡すことに
より、あるいはそれをTIPCMessageStreamからストリー
ム・アウトすることにより作成される。メッセージがこ
のクラスのオブジェクトへ送られると、一回送信権は無
効になるので、そのあとでこのオブジェクトへ送信しよ
うとすると例外が引き起こされる。さらに、このオブジ
ェクトに無効のマークが付けられるので、このオブジェ
クトのメソッドを使用しようとすると、例外が引き起こ
される（当然のことながら、オブジェクトを初期化する
メソッドは除く）。このクラスは、カーネル参照カウン
トに影響しないでTPortSendOnceRightHandleオブジェク
トを作成するコンストラクタ、新しいSend Onceオブジ
ェクトを現タスクに作成するコンストラクタ、ストリー
ミング・サポートのメソッド、およびGetters/Setters
を含んでいる。

TPortReceiveHandleは、IPCメッセージをそこから受
信できるポート権を表している抽象クラスである。例え
ば、これはMIPCMessage::Receiveがそこから受信するポ
ートとして受け取るタイプである。クラスTPortRightRe
ceiveHandleとTPortSetHandleはこのクラスから派生し
ている。このクラスはストリーミング・サポートのメソ
ッドとGetters/Settersを含んでいる。

TPortReceiveRightHandleはポート受信権を表してい
る。これは、受信権で実行できるすべての代表的オペレ
ーションを表している。オペレーションとしては送信側
が残っていないとの通知の要求、ポートの最大メッセー
ジ・サイズとキュー長さの設定と取得、その送信カウン
トの取得と設定などがある。TPortReceiveRightHandled
がインスタンス化されると（ヌルまたはコピー・コンス
トラクタによる場合を除く）、ポートと受信権が作成さ
れる。コピー・コンストラクタは同じ受信権を参照する
別のオブジェクト（別名:alias）を作成する。これらの
オブジェクトは内部で参照カウントがとられ、特定の受
信権を参照する最後のオブジェクトが壊されると、それ
が表している受信権（およびポート）も壊されるので、
そのポートに対する既存の権利はすべてデッド名にな
る。このクラスはポート受信権を表している具象クラス
である。定義により、実際のカーネル・ポート・エンテ
ィティは受信権が作成されると作成され、受信権が壊さ
れると壊される。このクラスはハンドルであるので、受
信権の作成と破壊は、必ずしもTPortReceiveRightHandl
eの作成と削除に結び付いているとは限らない。たとえ
ば、デフォルト・コンストラクタは実際には受信権を作
成しないで、空のオブジェクトだけを作成する。このク
ラスは、ポートを作成することなく、あるいはカーネル
参照カウントに影響することなくTPortReceiveRightHan
dleオブジェクトを作成するコンストラクタ、新しい受
信権とポートを作成するコンストラクタ、未初期化オブ
ジェクトを有効にするメソッド、プロセス内に受信権
（従って、ポートも）の作成、ストリーミング・サポー
ト、受信権／ポート操作のメソッド、Getters/Setter
s、および通知を要求するメソッドを含んでいる。

TPortSetHandleはポート・セットを表している。これ
はポート・セットに含まれる受信権を表すTPortReceive
RightHandleオブジェクトを追加、除去、および列挙す
るメソッド、その送信カウントを取得し設定するメソッ
ドなどを含んでいる。TPortSetHandleがデフォルト・コ
ンストラクタを使用してインスタンス化されていると、
ポート・セットが作成される。コピー・コンスタクタを
使用してインスタンス化されていれば、同じポート・セ
ットに対して別名（alias）が作成される。特定のポー
ト・セットを表す最後のオブジェクトが削除されると、
そのポート・セットが壊される。このクラスはストリー
ム化することはできない。

TPortRightHandleArrayは、IPCメッセージでアウトオ
ブライン記述子として送信できるポート権の配列を表す
具象クラスである。これは、どの種類のポート権でも含
むことができるので、ポート権の後処理（つまり、ポー
ト権をどのような方法でターゲット・タスクへ転送する
か）は、配列内の各ポート権について指定される。この
クラスは、IPCメッセージでアウトオブライン記述とし
送信できる（ポート権およびアウトオブライン・メモリ
と一緒に）ポート権の配列を実現できる。このクラス
は、ストリーミング・サポートのメソッド、エレメント
（要素）を配列に追加するメソッド（SEND SIDE）、お
よびエレメントを配列から除去するメソッド（RECEIVE
SIDE）を含んでいる。

TRemotePortRightHandleは、別のタスク内のポート権
を参照するために使用される具象クラスである。これは
通常のポート権メソッドの大部分を含んでいないが、こ
れは、これらのタイプの関数を実行するために使用され
るのではなく、リモート・ポート権の名前またはハンド
ルとして働くことだけを目的としているためである。こ
のクラスを構築しても、ポート権は作成されない。別の
タスクにすでに存在するポート権を表すだけである。

待ちグループ MWaitableとTWaitGroupは、メッセージ・ディスパッ
チングの機能をもち、２種類以上のメッセージ・ソース
を同時に待つことができるようにするクラスである。TW
aitGroupは、MWaitableから派生したオブジェクトのコ
レクションをセットアップして、スレッドがWaitメソッ
ドを使用してMWaitableオブジェクトのどれからでもメ
ッセージを受信できるようにするクラスである。これ
は、受信したメッセージを自動的にディスパッチングす
る機能も備えている。Multi−Wait Operationsはメッセ
ージを受信するためにタスクによって繰返しコールされ
る。これらはマルチスレッドに対して安全に保護されて
いるので、２つ以上のスレッドがメッセージにサービス
することが可能である。このクラスはTWaitGroupのメン
バを操作するメソッドを含んでいる。例えば、GetListO
fWaitablesはこのグループ内のMWaitablesのリストを返
す。MWaitableはポートを内部ハンドラ・メソッド（Han
dlerIPCMessage）と関連づける抽象基底クラスである。
これは、受信権と受信権をベースとする他のクラスをTW
aitGroupクラスを通して収集して１つにまとめる働きを
する共通基底クラスでもある。

TWaitablePortReceiveRightHandleは、TPortReceiveR
ightHandleとMWaitableの両方から派生したコンビニエ
ンス（convenience）クラスである。これは抽象基底ク
ラスであり、そのサブクラスをTWaitGroupに追加する
と、他のMWaitableサブクラスとの間でMachメッセージI
PCのMulti−Waitとディスパッチングを行うことができ
る。

同期化クラス 第10図は、Machの同期化サービスを呼び出すために使
用される同期化クラス412を示すクラス図1002である。
上述したように、同期化クラス412はセマフォアトとモ
ニタと条件を採用している。TSemaphoreは、カウンティ
ング・セマフォア（counting semaphore）の一般サービ
スを提供するクラスである。セマフォアを獲得すると
き、他のいずれかのタスクがそのセマフォアをすでに獲
得していると、呼出し側スレッドはブロックする（例外
は引き起こされない）。しかし、セマフォアがなんらか
の理由で無効であれば、例外が引き起こされる。このク
ラスは、次のようなメソッドを含んでいる。

Acquire:セマフォアを排他モードで獲得する。

Acquire（const TTime＆ maxiumWait）：セマフォア
をタイムアウト付の排他モードで獲得する。

AcquireShared（）：セマフォアを共有モードで獲得
する。

AcquireShared（const TTime＆ maximumWait）：セマ
フォアをタイムアウト付の共有モードで獲得する。

Release（）：以前に獲得したセマフォアを解放す
る。

AnyThreadsWaiting（）：セマフォアが現在スレッド
をその獲得待ちに置いていれば真（true）を返す。

TLocalSemaphoreは、排他モードまたは共有モードで
獲得できるカウンティング・セマフォアを表すクラスで
ある。主要オペレーションは獲得と解放である。オプシ
ョンのタイムアウト値を獲得オペレーションで指定する
と、必要ならば待ちで消費する時間を制限することがで
きる。このクラスは「ローカル」セマフォアを実現する
が、使用できるのはタスク（アドレス空間）内だけであ
り、回復セマンチックス（recovery semantics）はな
い。

TRecoverableSemaphoreHandleはTLocalSemaphoreと同
じ作用をするが、セマフォアが「回復可能」であるとの
追加の属性をもつセマフォアを表すクラスである。回復
可能とは、セマフォアを保持するスレッドが異常終了し
たとき、カウントが調整され、待ちに置かれていたスレ
ッドが正しくブロック解除（unblock）されることであ
る。このような各スレッドで例外が引き起こされ、セマ
フォアが回復されたが、関連のユーザ・データの保全性
が壊れた疑いがあることを知らせる。なお、セマフォア
を共有モードで獲得していたスレッドが異常終了したと
きは、関連のデータは読取り専用モードだけでアクセス
されたはずであり、まだ整合状態にあるはずであるの
で、他のスレッドで例外を引き起こす必要はない。この
クラスは次のようなメソッドを含んでいる。

GetCurrentHolders:セマフォアを保持している現スレ
ッドのコレクションを返す。

SetRecovered:セマフォアの状態を「回復（recovere
d）」にセットし、以前の「壊れた（damaged）」状態を
除去する。

Destroy:回復可能セマフォアをシステムから除去す
る。

TMonitorEntryはモニタと関連づけられたロック（mut
exと呼ばれることもある）を表すクラスである。実際に
は、このクラスのコンストラクタによってモニタ・ロッ
クが獲得され、ローカル・スコープから出ると（これに
よりデストラクタがコールされる）モニタ・ロックが解
放される。別のタスクがすでにモニタに入っていれば、
モニタに入ろうとするスレッドは、その前のスレッドが
モニタから出るまでTMonitorEntryコンストラクタでブ
ロックされる。このクラスは演算子newとdeleteを含ん
でおり、これらは非公開（private）であるので、TMoni
torEntryはスタック上にだけ割り振られ、スコープに入
ったり出たりすると、自動的に入ったり出たりする（お
よび関連のモニタ・ロックが獲得され解放される）。

TMonitorConditionはあるモニタと関連づけられた条
件変数（condition variable）を表すクラスである。主
要オペレーションは待ち、通知、およびブロードキャス
トである。待ちオペレーションが行われると、現スレッ
ドは条件が通知されるまで待ちに置かれ、スレッドがブ
ロックされている間に、モニタ・ロックが解放される。
通知とブロードキャストはモニタ内部で実行中のスレッ
ドによてコールされ、通知側（またはブロードキャスト
側）スレッドがモニタから出たとき、条件待ちに置かれ
ていたスレッドの１つまたはすべてをブロック解除すべ
きことを通知する。待ちに置かれたスレッドがブロック
解除されると、モニタ・ロックの再獲得を試み（ブロー
ドキャストの場合は一度に１スレッド）、その時点でモ
ニタでの実行を再開する。オプションのタイムアウト値
を指定すると、条件待ちに置かれる時間を制限すること
ができる。構築と破壊を除き、TMonitorConditionのす
べてのメソッドは、モニタ内からのみコールしなければ
ならない。

TMonitorLockは、モニタのロックを表すクラスであ
る。これはTMonitorEntryとTMonitorConditionのコンス
タラクタに渡され、どのモニタを獲得しようとしている
か、あるいは条件がどのモニタと関連づけられるかを通
知する。

スケジューリング・クラス 第11図はスケジューリング・クラス414をクラス図110
2であり、Machのスケジューリング・クラスを呼び出す
ために使用されたものである。

TThreadScheduleは、スレッドのスケジューリング作
用を具現化する具象基底クラスである。これはスレッド
の実際の優先度、デフォルト優先度および最大優先度を
定義している。優先度値が低くなると、緊急度が大きく
なる。各プロセッサ・セットは使用可能になっているTT
hreadSchedulesとデフォルトのもののコレクションをも
っている。スレッドには、そのスレッドが実行されてい
るプロセッサ・セットで使用可能になっている、どのTT
hreadScheduleでも割り当てることが可能である。優先
度はTThreadScheduleで定義された最大値にセットアッ
プすることが可能であるが、この機能を使用することは
望ましくない。具体的スケジューリング・クラス（TIdl
eSchedule、TServerScheduleなど）はこのクラスを基底
として使用すると使用可能になる。しかし（このクラス
には純粋仮想関数がないので）、派生クラスは必要なら
ば、自由にこのクラスのオブジェクトを作成することが
できる（しかし、そのようにしないで済むであろう）。
TThreadScheduleオブジェクト（多態を使用する）はス
レッドのスケジューリング・ポリシを指定するために使
用される。以下に説明するサブクラスは該当の優先度と
正しい範囲を判断するために使用されるものである。

TIdleThreadScheduleは、システムがアイドル状態に
あるとき実行させるスレッドのためのTThreadSchedule
の具象サブクラスである。これらは、実行できるものが
他にシステムにないときだけ実行される。このカテゴリ
は、一般に、アイドル・タイミング、保守、または診断
スレッドのために使用される。

TServerScheduleは、サーバ・スレッドのためのTThre
adScheduleの具象サブクラスである。サーバ・スレッド
は応答性が高くなければならない。これらは短時間に実
行されたあと、中断することが予想される。かなりの時
間がかかるサービスについては、異種のTThreadSchedul
e（TSupportSchedule）をもつヘルパ・タスク（helper
task）を使用すべきである。

TUserInterfaceScheduleは、応答性があって、アプリ
ケーションのヒューマン・インターフェースを扱うアプ
リケーション・タスクのためのTThreadScheduleの具象
サブクラスである。これらは短時間に実行されたあと、
次のやりとりまでブロックするのが代表的である。

TApplicationScheduleは、アプリケーションの長い実
行部分をサポートするスレッドで使用されるクラスであ
る。このようなスレッドは実行時間がかなり長くなる。
アプリケーションまたはウィンドウがアクティベートさ
れると、関連タスク内のスレッドは緊急度が大きくなる
のでスレッドは応答性が高くなる。

TPseudoRealTimeThreadScheduleは、範囲内のレベル
をセットすることにより、タスクが固定優先度クラスで
相対的緊急度を指定できるようにするクラスである。タ
スク・スケジュールは、許容されるレベルの数とデフォ
ルト・ベース・レベルをイクスポートする。値がクラス
範囲を超えるようなレベルが要求されると、例外が引き
起こされる。このクラスは次のようなメゾットを含んで
いる。

SetLevel（PriorityLevels theLevel）：タスクのレ
ベルをセットする。数が低くなると、緊急度が大きくな
る。

ReturnNumberOfLevels（）：このスケジューリング・
オブジェクトの緊急度レベルの数を返す。

ReturnDefaultLevel（）：このスケジューリング・オ
ブジェクトのデフォルト緊急度レベルを返す。

障害クラス 第12図、第13図、第14図、および第15図は障害クラス
416のクラス図1202、図1220、図1302、図1402、および
図1502を示しており、これらのクラスはMachの障害サー
ビスを呼び出すために使用される。障害メッセージ（例
えば、TIPCIdentityFauliMessage、TIPCIdentityFauliM
essageなど）を表すクラスの場合は、各メッセージ・タ
イプごとにシングル・ポートを専用化する必要がある。
つまり、障害処理のために使用されるどのポートでも１
つのタイプのメッセージだけが受信されるようにしなけ
ればならない。好ましくは、障害クラス416は、オペレ
ーティング・システムがそこで実行される各プロセッサ
106ごとにプロセッサ特有のクラス群を含んでいる。こ
れとは別に、障害クラス414は、一般的にマルチプル・
プロセッサに適用される汎用クラスを含むことも可能で
ある。本明細書には、Motorola68000特有のクラスが示
されているが、これらは例示であって、これに限定され
るものではない。この分野の専門家ならば理解されるよ
うに、本明細書に開示されている教示事項に基づいて、
他のプロセッサ用にプロセッサ特有のクラスを生成する
ことも可能である。

TFaultTypeは障害を表す抽象基底クラスである。これ
をサブクラス化すると、プロセッサ固有の障害値を得る
ことができる。これは障害をプロセッサと障害ID別に指
定する。以下に説明する３つのクラスはTFaultTypeのサ
ブクラスである。

TMC680X0FaultTypeはMotorola68Kプロセッサでの障害
タイプを表している。これは取り得る68Kタイプ値とCPU
記述子を指定する。

TMC680X0BadAccessFaultTypeはMotorola68Kプロセッ
サでの不正アクセス・タイプを表している。

TMC680X0AddressFaultTypeはMotorola68Kプロセッサ
での不正アドレス・タイプ・エラーを表している。

TFaultDesignationは、宛先、障害メッセージのフォ
ーマット、タスクまたはスレッドで障害が起こってメッ
セージが送られるときの障害のタイプをカプセル化して
いるクラスである。このクラスを使用すると、特定の障
害タイプで要求されたタイプの障害メッセージを、送信
権で指定されたポートへ送ることをタスクまたはスレッ
ド単位で指定することができる。

TFaultTypeSetは一組の障害タイプをカプセル化して
いる。

TFaultDataは、プロセッサ状態のほかにカーネルから
提供される障害データをカプセル化するクラスである。
どの障害にも障害データがあるとは限らない。障害デー
タは障害メッセージに入れられ、スレッド状態から得る
ことができる。

TIPCFaultMessageは、障害が起こったスレッドに代わ
ってカーネルから送られてきた障害メッセージをカプセ
ル化するクラスである。これは障害を受け取ってそれに
応答するために使用される。障害メッセージと一緒に送
られる可能性のある３種類のデータ用に３つのクラス
（下述する）が用意されている。メッセージには障害を
起こしたタスクとスレッドのIDまたは障害を起こしたス
レッドの状態、あるいは両方の情報セットを含めること
ができる。

TIPCIdentityFaultMessageは、障害を起こしたスレッ
ドのIDを含んでいる障害メッセージをカプセル化する。
これは障害を受け取ってそれに応答するために使用され
る。TIPCStateFaultMessageは、障害を起こしたスレッ
ドのスレッド状態を含んでいる障害メッセージをカプセ
ル化する。これは障害を受け取ってそれに応答するため
に使用される。TIPCStateAndIdentityFaultMessageは、
障害を起こしたスレッドのスレッド状態とIDを含んでい
る障害メッセージをカプセル化する。これは障害を受け
取ってそれに応答するために使用される。

TThreadStateはスレッドのCPU状態を表すクラスであ
る。サブクラスは実際にはプロセッサ特有のフォームを
定義している。クラスには情報はない。作業はすべて派
生クラスで行われる。CPU状態の照会はすべてTMC680X0S
tateポインタを返すが、このポインタは実行時に正しい
派生クラス・オブジェクトにキャスト（cast）する必要
がある。派生クラスは第12図、第13図、第14図および第
15図に示すサブクラスの多くがMotorola68xxxプロセッ
サ系列に依存しているように、特定のプロセッサに特有
のものである。このようなサブクラスとしてはTMC680X0
Stateがあり、これはスレッドの680x0 CPU状態を表す具
象クラスである。他の例としては、すべての68K状態で
使用可能なCPU状態をカプセル化するTMC68OXOCPUState
と、すべての68K状態で使用可能な68K障害状態をカプセ
ル化するTMC680X0CPUFaultStateとがある。

ホストとプロセッサ・セット・クラス 第16図はマシン・クラス418を示すクラス図1602であ
り、これらのクラスはホストとプロセッサ・セット・ク
ラスとも呼ばれる。マシン・クラス418はMachのマシン
とマルチプロセッサ・サポートに関係するサービスを呼
び出すために使用される。

TPrivilegedHostHandleは、カーネルのホスト・オブ
ジェクトに対する特権ポートを具現化する具象クラスで
ある。特権ホスト・ポートはMachのプロセッサ管理のル
ート（root）である。特権ホスト・ポートの所持者はシ
ステム上のどのポートへもアクセスすることができる。
カーネルで行われる基本的特権メカニズムは特権オペレ
ーションを制御ポートを保持するタスクに制限すること
である。従って、システムの保全性はこの特権ホスト・
ポートを保持することに左右される。このクラスのオブ
ジェクトは、ブート情報とホスト統計を取得すること、
システムを再ブートすること、特権プロセッサ・セット
を列挙すること、非CEエンティティと通信すること、プ
ロセッサを列挙することができる。

THostHandleは、カーネルのホスト・オブジェクトに
対する名前ポートを具現化する非特権具象クラスであ
る。このクラスのオブジェクトはある種のホスト情報を
返し、デフォルト・プロセッサ・セットを返すことがで
きる。このクラスのオブジェクトは、ホストから情報
（カーネル・バージョン、CPUの最大数、メモリ・サイ
ズ、CPUタイプなど）を得るとき使用すると便利である
が、そのためにホストが壊れることはない。ユーザに
は、高度の特権TPrivilegedHostHandleオブジェクトで
はなく、このクラスのオブジェクトがアクセスできるよ
うにしておくべきである。

TProcessorHandleはプロセッサを表す具象クラスであ
る。プロセッサを始動させ、終了させること、プロセッ
サをTPrivilegedProcessorSetHandleに追加すること、
プロセッサが情報を返すこと、インプリメンテーション
依存のコントロールをプロセッサに送ることができる。

TPrivilegedProcessorSetHandleはプロセッサ・セッ
ト制御ポートのプロトコルを提供する具象クラスであ
る。このクラスのオブジェクトは、スケジューリング・
ポリシを許可（enable）し、禁止（disable）するこ
と、プロセッサ・セットの最高優先度をセットするこ
と、統計と情報を返すこと、タスクとスレッドを列挙す
ること、スレッドとタスクをプロセッサ・セットに割り
当てることができる。このクラスのオブジェクトへのク
ライアントのアクセスは、個別的プロセッサとプロセッ
サ・セットを保護するために非常に制限しておかなけれ
ばならない。

TProcessorSetHandleはプロセッサ・セットの名前ポ
ートのプロトコルを提供する具象クラスである。このク
ラスのオブジェクトはプロセッサ・セットに関する基本
情報（プロセッサ・セット内のプロセッサの数など）を
返すことができるが、そのためにプロセッサ・セットが
壊されることはない。

ラッパー・メソッドの実現方法 上述したように、MachおよびMach手続き型インターフ
ェースは公知である。ラッパー・クラス・ライブラリ40
2およびラッパー・クラス・ライブラリ402のメソッドの
オペレーションの詳しい定義と説明は上述したとおりで
ある。以下では、ラッパー・クラス・ライブラリ402に
よって定義されたメソッドの実現方法について、ラッパ
ー・クラス・ライブラリ402から選択したソリッドを考
慮することにより説明する。この分野の専門家ならば理
解されるように、ラッパー・クラス・ライブラリ402の
他のメソッドは、Machの公知仕様、ラッパー・クラス・
ライブラリ402に関して上述した説明、およびラッパー
・メソッドの実現方法に関して下述する説明に基づいて
実現することが可能である。スレッド・クラス404のTTh
readHandleからのkill（）メソッドの実現方法は、以下
の「コーディング例２」に示されている。“example1"
と名づけたルーチンは以下の「コーディング例１」に示
されている。“example2"ルーチンはkill（）メソッド
を実行させるデコンポジション（decomposition）ステ
ートメントを含んでいる。

上記において、 fThreadControlPortは、クラスが表すスレッドのMach
スレッド制御ポートを収めているTThreadHandleクラス
のインスタンス変数である。

TKernekExceptionはカーネル・ルーチンにエラーが起
こったとき引き起こされるＣ＋＋例外クラスである。

THROW、TRY、CATCH、およびENDTRYはＣ＋＋言語の一
部であり、Ｃ＋＋例外を引き起こし、それをキャッチで
きるようにする。

タスク・クラス406のTTaskHandleクラスからのsuspen
d（）メソッドの実現方法は、以下の「コーディング例
４」に示されている。“example2"と名づけたルーチン
は以下の「コーディング例３」に示されている。“exam
ple2"ルーチンは 上記において、 fThreadControlPortは、クラスが表すスレッドのMach
スレッド制御ポートを収めているTThreandHandleクラス
のインスタンス変数である。

TKernekExcepitonはカーネル・ルーチンにエラーが起
こったとき引き起こされるＣ＋＋例外クラスである。

THROW、TRY、CATCH、およびENDTRYはＣ＋＋言語の一
部であり、Ｃ＋＋例外を引き起こし、それをキャッチで
きるようにする。

スケジューリング・クラス414のTPseudoRealTimeThre
adScheduleクラスからのGetLevel（）メソッドの実現方
法は、以下の「コーディング例６」に示されている。
“example3"と名づけたルーチンは以下の「コーディン
グ例５」に示されている。“example3"ルーチンはGetLe
vel（）メソッドを実行させるデコンポジション・ステ
ートメントを含んでいる。

上記において、 fThreadControlPortは、TPseudoRealTimeThreadSched
uleクラスのインスタンス変数である。これはクラスが
スケジュールとなっているMachスレッド制御ポートを収
めている。

マシン・クラス418のTHostHandleクラスからのGetKer
ne1Version（）メソッドの実現方法は、以下の「コーデ
ィング例８」に示されている。“example4"と名づけた
ルーチンは以下の「コーディング例７」に示されてい
る。“example4"ルーチンはGetKerne1Version（）メソ
ッドを実行させるデコンポジション・ステートメントを
含んでいる。

上記において、 fHostPortsは、クラスが表すホストのMachホスト制御
ポートを収めているTHostHandleクラスのインスタンス
変数である。

IPCクラス410のTPortReceiveRightHandleクラスから
のGetMakeSendCount（）メソッドの実現方法は以下の
「コーディング方法10」に示されている。“example5"
と名づけたルーチンは以下の「コーディング例９」に示
されている。“example5"ルーチンはGetMakeSendCount
（）メソッドを実行させるデコンポジション・ステート
メントを含んでいる。その名前が示すように、GetMakeS
endCount（）メソッドはMachをアクセスしてポートに関
連する送信カウントを取り出す。GetMakeSendCount（）
メソッドはmach_pot_get_attributesをコールするステ
ートメントを含んでおり、これはポートに関するステー
タス情報を返すMach手続き向きシステム・コールであ
る。GetMakeSendCount（）では、fTheTaksは関連タスク
のタスク制御ポートを収めているTPortReceiveRightHan
dleオブジェクトのインスタンス変数であり、fThePortN
ameはTPortReceiveRightHandleオブジェクトによって表
されたポートのポート権名を収めているTPortReceiveRi
ghtHandleオブジェクトのインスタンス変数である。

本発明は上述した説明に基づいて種々態様に変更する
ことが可能である。例えは、本発明の範囲には、手続き
型アプリケーションがコンピュータで実行時に実行され
ているとき、そのアプリケーションがネイティブ・オブ
ジェクト指向インタフェースをもつオブジェクト指向オ
ペレーティング・システムを手続き型の方式でアクセス
することを可能にするシステムおよび方法が含まれてい
る。本発明のこの実施例は、好ましくは、オペレーティ
ング・システムから提供されるサービスをアクセスする
手続き型ステートメントをアプリケーションの中に置
き、その手続き型ステートメントをオペレーティング・
システムのネイティブ・オブジェクト指向のインタフェ
ースと互換性をもち、手続き型ステートメントに対応す
るオブジェクト指向関数コール（つまり、メソッド）に
変換することによって動作する。オブジェクト指向関数
コールがコンピュータで実行されると、オペレーティン
グ・システムはアプリケーションのためにサービスを提
供する。本発明の種々実施例について上述してきたが、
これらは例示であって、これらに限定されるものではな
い。従って、本発明の範囲は上述した実施例のいずれに
よっても限定されるものではなく、請求の範囲に明確化
されている記載とその等価的記載に従ってのみ判断すべ
きものである。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ダタートリ，ケイシャフ アメリカ合衆国 95117 カリフォルニ ア州 サンノゼ フェルプス アヴェニ ュ 1225 (56)参考文献 特開 平７−175730（ＪＰ，Ａ) 情報処理学会第44回（平成４年前期) 全国大会講演論文集（４）、社団法人情 報処理学会発行（特許庁資料館平成４年 ３月31日受入）、Ｐ．11〜12. インターフェース1991年10月号、ＣＱ 出版社発行（平成３年10月１日）、Ｐ. 123〜189. (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/46 G06F 9/44 ＪＩＣＳＴファイル（ＪＯＩＳ) ＣＳＤＢ（日本国特許庁)

Claims (10)

(57)【特許請求の範囲】
1. 【請求項１】手続き型オペレーティング・システム（11
   4）の制御下にある並列に動作する複数のプロセッサを
   有するホスト・コンピュータ（102）を有するコンピュ
   ータ・プラットフォーム内の装置であって、前記プラッ
   トフォームは、前記手続き型オペレーティング・システ
   ムを格納するメモリ・コンポーネント（108、122）と、
   オブジェクト指向クラス内に前記手続き型オペレーティ
   ング・システムのインタフェースをカプセル化するラッ
   パーによってオペレーティング・システム・サービスを
   アクセスするためのオブジェクト指向ステートメントを
   含んだオブジェクト指向アプリケーションとを更に備
   え、前記装置は、 ａ）前記メモリ・コンポーネントにストアされ、ラッパ
   ー・クラス・ライブラリ（402）を含むコード・ライブ
   ラリ（110）であって、該ラッパー・クラス・ライブラ
   リ（402）は、前記手続き型オペレーティング・システ
   ムの前記サービスためのオブジェクト指向クラス・セッ
   ト（404、406、408）を含み、該クラスは、各々、コン
   パイル済みの実行可能なプログラム・ロジック（202）
   をメソッド・セットを有するコード・ライブラリ（11
   0）と、 ｂ）前記手続き型オペレーティング・システムのネイテ
   ィブ・インタフェースと互換性があり、前記コンパイル
   済みの実行可能なプログラム・ロジックによって実行さ
   れる手続き型関数コールを利用した前記手続き型オペレ
   ーティング・システムとの前記オブジェクト指向アプリ
   ケーションのインタフェースを提供する手段と、 ｃ）前記ホスト・コンピュータの前記複数プロセッサ
   （1614）の一つを、前記オブジェクト指向アプリケーシ
   ョンのアドレス空間内に前記コンパイル済みの実行可能
   なプログラム・ロジックの関連部分を前記アプリケーシ
   ョンのランタイムに挿入することにより前記オブジェク
   ト指向ステートメントを処理させて、前記手続き型オペ
   レーティング・システムをオブジェクト指向方式でアク
   セスすることを可能にする手段と を備えたことを特徴とする装置。
2. 【請求項２】請求項１に記載の装置において、前記手続
   き型オペレーティング・システムは、スレッドとタスク
   の作成および制御、仮想メモリのアクセスと操作、プロ
   セス間通信（IPC）、スケジューリング、同期化および
   ホストとプロセッサ・セットの制御と操作を含む様々な
   カテゴリーのサービスを提供するマイクロ・カーネルを
   有し、前記ラッパー・クラス・ライブラリ（402）は、
   前記サービス・カテゴリーの各々に対しオブジェクト指
   向クラス・セットを有し、前記クラスの各々は、関連カ
   テゴリーのサービスを実行するのに必要なメソッド・セ
   ットを備えたことを特徴とする装置。
3. 【請求項３】請求項１に記載の装置において、前記ラッ
   パー・クラス・ライブラリ（402）は、前記ホスト・コ
   ンピュータ（102）の特権ポートをセットアップし、制
   御するメソッドと、前記特権ポートを利用して、ホスト
   ・コンピュータ・ブート情報と統計を得ること、前記ホ
   スト・コンピュータをブートすること、特権化されたプ
   ロセッサ・セットを列挙すること、そのプロセッサを列
   挙および制御するためのメソッドとを含むオブジェクト
   指向クラス（418）を備えたことを特徴とする装置。
4. 【請求項４】請求項１に記載の装置において、ラッパー
   ・クラス・ライブラリ（402）はオブジェクト指向クラ
   ス（414、1106）を有し、該オブジェクト指向クラス（4
   14、1106）は、前記複数のプロセッサ（106）の各々の
   ポートをアクセスするプロトコルを有し、前記プロトコ
   ルを利用してスケジューリング・ポリシをイネーブルお
   よびディセーブルし、プロセッサ・セットに最高優先度
   を設定し、該複数のプロセッサの一つに実行するタスク
   およびスレッドを定義するためのメソッドを更に備えた
   ことを特徴とする装置。
5. 【請求項５】請求項１に記載の装置において、前記コー
   ド・ライブラリ（110）は、プロセッサ・セット（106）
   のネーム・ポートをアクセスするプロトコルと、前記ネ
   ーム・ポートを利用してプロセッサ・セットに関連し、
   前記プロトコルによって定義されるポート権に基づいた
   前記プロセッサ・セット内のプロセッサ数を得るメソッ
   ドとを備えたことを特徴とする装置。
6. 【請求項６】手続き型オペレーティング・システム（11
   4）の制御下にある並列に動作する複数のプロセッサを
   有するホスト・コンピュータ（102）を有し、前記手続
   き型オペレーティング・システムを格納するメモリ・コ
   ンポーネント（108、122）と、オブジェクト指向ステー
   トメントを有するオブジェクト指向アプリケーションと
   を更に含むプラットフォームを具備するコンピュータに
   おいて、前記オブジェクト指向アプリケーションが、オ
   ブジェクト指向クラス内に前記手続き型オペレーティン
   グ・システムのインタフェースをカプセル化するラッパ
   ーによってオペレーティング・システム・サービスをア
   クセスすることを可能にする方法であって、該方法は、 ａ）前記手続き型オペレーティング・システムの前記サ
   ービスのオブジェクト指向クラス・セット（404、406、
   408）を有し、該クラスの各々は、コンパイル済みの実
   行可能なプログラム・ロジック（202）のメソッド・セ
   ットを有するラッパー・クラス・ライブラリ（402）を
   含うむコード・ライブラリ（110）を前記メモリ・コン
   ポーネント中に作成するステップと、 ｂ）前記手続き型オペレーティング・システムのネイテ
   ィブ・インタフェースと互換性があり、前記コンパイル
   済みの実行可能なプログラム・ロジックによって実行さ
   れる手続き型関数コールを利用した前記手続き型オペレ
   ーティング・システムとの前記オブジェクト指向アプリ
   ケーションのインタフェースを提供するステップと、 ｃ）前記オブジェクト指向アプリケーションのアドレス
   空間内に前記コンパイル済みの実行可能なプログラム・
   ロジックの関連部分を前記アプリケーションのランタイ
   ムに挿入することにより、前記オブジェクト指向ステー
   トメントを処理する前記ホスト・コンピュータ中の前記
   複数プロセッサ（1614）の一つを、前記手続き型オペレ
   ーティング・システムにオブジェクト指向方式でアクセ
   スすることを可能にするステップと を備えることを特徴とする方法。
7. 【請求項７】請求項６に記載の方法において、前記手続
   き型オペレーティング・システムは、スレッドとタスク
   の作成および制御、仮想メモリのアクセスおよび操作、
   プロセス間通信（IPC）、スケジューリング、同期化お
   よびホストとプロセッサ・セットの制御と操作を含む様
   々なカテゴリーのサービスを提供するマイクロ・カーネ
   ルを有し、前記ステップ（ａ）は、前記ラッパー・クラ
   ス・ライブラリ（402）の中に、前期サービスのカテゴ
   リーの各々に対し、オブジェクト指向クラス・セットを
   作成するステップを含み、前期クラスの各々は、関連す
   るカテゴリーのサービスを実行するのに必要なメソッド
   ・セットを備えることを特徴とする方法。
8. 【請求項８】請求項６に記載の方法において、前記ラッ
   パー・クラス・ライブラリ（402）の中に、オブジェク
   ト指向クラス（418）を作成し、該オブジェクト指向ク
   ラス（418）は、前記ホスト・コンピュータ（102）の特
   権ポートをセットアップおよび制御するメソッドを有
   し、また前記特権ポートを利用してホスト・コンピュー
   タ・ブート情報と統計を得て前記ホスト・コンピュータ
   をブートし、特権化されたプロセッサ・セットを列挙
   し、そのプロセッサを列挙および制御するメソッドを更
   に備えることを特徴とする方法。
9. 【請求項９】請求項６に記載の方法において、前記ラッ
   パー・クラス・ライブラリ（402）中に、オブジェクト
   指向クラス（414、1106）を作成し、該オブジェクト指
   向クラスは、前記複数のプロセッサ（106）の各々のポ
   ートをアクセスするプロトコルを有し、更に、前記プロ
   トコルを利用してスケジューリング・ポリシをイネーブ
   ルおよびディセーブルし、プロセッサ・セットに最高優
   先度を設定し、前記複数のプロセッサの各々に関連する
   タスクとスレッドを列挙し、タスクとスレッドを割り当
   てるメソッドを備えることを特徴とする方法。
10. 【請求項１０】請求項６に記載の方法において、前記コ
    ード・ライブラリ（110）中に、オブジェクト指向クラ
    ス（414、1106）を作成し、該オブジェクト指向クラス
    （414、1106）は、プロセッサ・セット（106）のネーム
    ・ポートをアクセスするプロトコルを有し、前記ネーム
    ・ポートを利用してプロセッサ・セットに関連し、前記
    プロトコルによって定義されるポート権に基づいた前記
    プロセッサ・セット内のプロセッサ数を得るメソッドを
    更に備えることを特徴とする方法。