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

Abstract

(57)【要約】 オブジェクト指向ホスト・システムを提供することを目的とし、オブジェクト指向アプリケーションがネーティブ手続き型インタフェースをもつ手続き型オペレーティング・システムをオブジェクト指向方式でアクセスすることを可能にする装置が開示されている。装置はコンピュータと、コンピュータに置かれたメモリ・コンポーネントと、ホスト・システムに対するサポートを含んでいる。コード・ライブラリはメモリ・コンポーネントにストアされている。コード・ライブラリはオブジェクト指向クラス・ライブラリを実現するコンピュータ・プログラム・ロジックを含んでいる。オブジェクト指向クラス・ライブラリは、アプリケーションがオペレーティング・システムから提供されるサービスをオブジェクト指向方式でアクセスすることを可能にする、相互に関連づけられたオブジェクト指向クラスから構成されている。オブジェクト指向クラスは、オペレーティング・システムのネーティブ手続き型インタフェースと互換性をもつ手続き型関数コールを使用してオペレーティング・システムのサービスをアクセスするためのメソッドを含んでいる。コンピュータはアプリケーション内に置かれていて、クラス・ライブラリによって定義されたオブジェクト指向ステートメントを、オブジェクト指向ステートメントに対応するメソッドをクラス・ライブラリから取り出して実行することにより処理する。オブジェクト指向アプリケーションはマルチタスキングに対するサポートを含んでいる。

Description

【発明の詳細な説明】 オブジェクト指向ホスト・システム 本明細書の開示事項の一部には、著作権保護の対象となる内容が含まれている 。著作権所有者は、米国特許商標庁の特許ファイルまたは記録に記載されている 特許開示事項を第三者がファクシミリで複製することを妨げるものではないが、 その他の場合には、著作権に係る一切の権利を留保する。 発明の分野 本発明は、一般的には、オブジェクト指向コンピューティング環境に関し、よ り具体的には、ホスト・サポートを含む手続き型オペレーティング・システムの ためのオブジェクト指向インタフェースを提供するシステムおよび方法に関する 。 発明の背景 オブジェクト指向テクノロジ(object-oriented technology - OOT)は、オブジ ェクト指向分析(object-oriented analysis - OOA)、オブジェクト指向設計(obj ect-oriented design - OOD)、およびオブジェクト指向プログラミング(object- oriented programming - OOP)を含んでいるのが一般的であるが、ソフトウェア 開発において最も重要な新テクノロジの１つとしてそのの地位を確保しつつある 。OOTは、プログラマの生産性とプログラムの保守容易性を大幅に向上する能力 があることがすでに実証されている。OOTでは、データとそのデータに操作を加 えるプロシージャがオブジェクト(object)と呼ばれるパッケージに一体化されて いる環境を作ることにより、さらに、オブジェクトが明確に定義されたメッセー ジング経路(messagin gpath)を通してのみ相互に連絡し合うというルールを採用 することにより、従来の手続き向きプログラミング(procedure- oriented pogramming)がもっていた複雑さの多くを取り除いている。 以下では、OOTがもつ比較的重要な側面のいくつかを取り上げて簡単に説明す る。OOTをもっと詳しく解説したものとして、多くの文献が公表されている。そ のような文献として、Grady Booch著「オブジェクト指向設計とそのアプリケー ション」(Object Oriented Design With Applications)(Benjamin/Cummings Pub lishing Company，1991)とDonald G．Firesmith著「オブジェクト指向の要求事 項分析と論理設計」（Object-Oriented Requirements Analysis and Logical De sign)(John Wiley & Sons，Inc.，1993)がある。OOTの基本的コンポーネントは オブジェクトである。オブジェクトは一組のデータ（属性(attribute)とも呼ば れる）とそのデータに操作を加えることができる一組のオペレーション（メソッ ド(method)と呼ばれる）を含んでおり、これらによって特徴づけられている。一 般的に、オブジェクトのデータは、そのオブジェクトのメソッドを通してのみ変 更可能になっている。 オブジェクト内のメソッドは、メッセージをそのオブジェクトに渡すことによ り呼び出される(invoke)（このプロセスはメッセージ・パッシング(message pas sing)と呼ばれる）。メッセージはメソッド名と引数リスト(argument list)を特 定している。オブジェクトがメッセージを受け取ると、指定された名前のメソッ ドに関連するコードは、そのメソッドの仮パラメータ(formal parameter)が引数 リストの中の対応する値とバインド(bind - 結び付けること）されて実行される 。OOTにおけるメソッドとメッセージ・パッシングは、手続き向きソフトウェア 環境におけるプロシージャとプロシージャ・コールに類似している。しかし、プ ロシージャは受け渡されたパラメータを変更し、返す働きをするのに対し、メソ ッドは関連のオブジェクトの内部状態(internal state)を変更する働きをする（ そのオブジェクトに収められたデータを変更することにより）。データとメソッ ドの組合せをオブジェクトに収めることを、カプセル化(encapsulation)と呼ん でいる。カプセル化の最大の利点を１つだけ挙げるとすれば、それはどのオブジ ェクトの状態も、そのオブジェクトに関連する明確に定義されたメソッドだけに よって変更できることである。あるオブジェクトの作用(behavior)が、このよう に明確に定義されたロケーションとインタフェースに限 定されていると、そのオブジェクトにおける変更（つまり、コード変更）は、シ ステム内の他のオブジェクトやエレメントに及ぼす影響が最小になる。オブジェ クト指向設計とプログラミングでカプセル化を正しく行うと、その結果得られる コードは、従来の手法で書かれたコードよりもモジュール化され、保守が容易に なるという別の「派生的利点」が得られる。 オブジェクトがカプセル化されると、データ抽象化(data abstraction)とも呼 ばれている、もう１つ重要な派生的利点が得られる。抽象化とは、細部を取り除 きオブジェクトの作用を一般化することにより、複雑なアイデアや構造を理解し やすくすることである。ソフトウェア側からみたとき、抽象化は、多くの点でハ ード・コーディング(hard-coding)と対立している。ソフトウェア・ウィンドウ 操作(software windowing)を例に挙げて説明すると、グラフィック・ユーザ・イ ンタフェース(GUI)をベースとするプログラムの中でユーザのスクリーン上に現 れるすべてのウィンドウのすべての細部に対して、その状態と作用をすべてハー ド・コーディングしてプログラムに組み入れておく必要があるとすれば、プログ ラムとそこに含まれるウィンドウは共に、その柔軟性のほとんどすべてを失うこ とになる。オブジェクト指向システムでは、ウィンドウの概念をウィンドウ・オ ブジェクトに抽象化するので、プログラマは、特定のウィンドウをユニークなも のにする具体的側面だけを考えればよいようになっている。ドラッグし、移動す る能力といったように、すべてのウィンドウによって共有される作用(behavior) は、すべてのウィンドウ・オブジェクトによって共有することができる。 上記から導き出されたOOTのもう１つの基本的コンポーネントはクラス(class) である。クラスは一組のデータ属性と、そのデータ属性に操作を加えることが許 される一組のオペレーション（つまり、メソッド）とを含んでいる。各オブジェ クトはあるクラスのインスタンス(instance)である。カプセル化と抽象化の当然 の結果として、OOTは継承(inheritance)をサポートしている。クラス（サブクラ ス(subclass)と呼ばれる）は別のクラス（基底クラス(baseclass)、親クラス(pa rent class)などと呼ばれる）から派生(derive)することができる。この場合、 サブクラスは基底クラスのデータ属性とメソッドを継承する。サブク ラスは基底クラスのデータおよび／またはメソッドをオーバライド(override)す るコードや、新しいデータ属性とメソッドを追加するコードを追加することによ り基底クラスを特殊化することができる。以上のように、継承は、作成されるサ ブクラスの特殊化レベルが増加していくと、抽象化がさらに具体化していくメカ ニズムを表している。継承は、OOPから得られるプログラミング効率の向上に貢 献する主要要因となっている。継承を利用すると、開発者はアプリケーションを 作成するとき新たに書く必要のあるコーディング量を最小にすることができる。 特定のタスクで必要になる機能(functionality)の大部分は継承階層内のクラス から得られるので、プログラマはプログラム設計と作成をさい先よく始めること ができる。オブジェクト指向環境が潜在的にもつ１つの欠点は、類似している作 用を示さなければならないオブジェクトが増加していくが、これらのオブジェク トを１つのメッセージ名で使用して記述をしたいことである。オブジェクト指向 グラフィック環境を例にして説明する。DrawメッセージがRectangleオブジェク トヘ送られると、Rectangleオブジェクトはそのメッセージに応答して４辺をも つ形状を描画する。他方、Triangleオブジェクトは、そのメッセージに応答して ３辺をもつ形状を描画する。理想的なことは、Drawメッセージを送るオブジェク トが、メッセージの宛先となるオブジェクトのタイプについても、メッセージを 受け取るオブジェクトがその応答としてどのように描画するかについても、気づ かないでいることである。この理想が達成できれば、新しい種類の形状（例えば 、六角形）をあとで追加することが比較的簡単になり、Drawメッセージを送信す るコード全体を未変更のままにしておくことができる。 従来の手続き向き言語では、このような言語アプローチをとると、大混乱が起 こることになる。OOT環境では、多態(polymorphism)という考え方が採用されて いるので、これを支障なく行うことができる。その結果として、受信側オブジェ クトがメッセージをどのように理解するかを、送信側オブジェクトが全然知らな くても、なにかを行うように他のオブジェクトに対して包括的に指示するメソッ ドを書くことができる。ソフトウェア・プログラムは、それがオブジェクト指向 であるか、手続き向きであるか、ルール・ベースのものであるかに関係なく、ほ とんど常にオペレーティング・システムとやりとりして、オペレーティング・シ ステムが提供するサービスをアクセスしている。例えば、ソフトウェア・プログ ラムはオペレーティング・システムとやりとりして、メモリ内のデータをアクセ スしたり、プロセッサ障害(processor fault)に関する情報を受け取ったり、他 のプロセッサと通信したり、あるいはプロセスの実行をスケジュールしたりする ことが可能である。 従来のオペレーティング・システムは大部分が手続き向きであり、ネイティブ 手続き型インタフェース(native procedural interface)を備えている。その結 果、これらのオペレーティング・システムから提供されるサービスをアクセスで きるのは、それぞれの手続き型インタフェースによって定義されたプロシージャ の使用によってのみである。あるプログラムが、これらの手続き型オペレーティ ング・システムの１つが提供しているサービスをアクセスする必要が起こったと き、該当のオペレーティング・システムのプロシージャ・コールを行うステート メントがそのプログラムに含まれていなければならない。このことは、ソフトウ ェア・プログラムがオブジェクト指向であるか、手続き向きであるか、ルール・ ベースであるか、その他であるかに関係ない。従って、従来のオペレーティング ・システムでは、手続き向き環境でソフトウェアが開発され、実行されている。 オブジェクト指向プログラムが手続き向き環境で開発され、実行されると、OOT の利点のいくつかが失われることになる。これは事実である。その理由は、手続 き型オペレーティング・システムへのすべてのアクセスが、オペレーティング・ システムのネイティブ手続き型インタフェースに定義されているプロシージャ・ コールを使用して実現されなければならないからである。その結果、クラス、オ ブジェクト、およびその他のOOTの特徴を最大限に生かすことができなくなるの で、オブジェクト指向プログラムがもつモジュール性、保守容易性および再使用 可能性という利点のいくつかは失われることになる。 上記問題の１つの解決方法は、ネイティブ・オブジェクト指向インタフェース をもつオブジェクト指向オペレーティング・システムを開発することである。こ れが、最終的には、最良の解決方法となると思われるが、現時点では、主要な手 続き型オペレーティング・システムのすべてを修正するために必要な資源が膨大 になるので、実用的な解決ではない。また、これらの手続き型オペレーティン グ・システムをこのように修正すると、多数の手続き向きソフトウェア・プログ ラムが無駄になってしまう。そこで、なにが必要であるかというと、それはオブ ジェクト指向アプリケーションが、ネイティブ（native：本来）手続き型インタ フェースをもつ手続き型オペレーティング・システムと、オブジェクト指向方式 でやりとりできるようにするメカニズムである。 発明の概要 本発明は、ネイティブ手続き型インタフェースをもつ手続き型オペレーティン グ・システムを、オブジェクト指向アプリケーションがオブジェクト指向方式で アクセスできるようにするシステムおよび方法を提供することを目的としている 。システムはコンピュータとコンピュータ内のメモリ・コンポーネント（構成要 素）を装備している。コード・ライブラリ(code library)はメモリ・コンポーネ ントにストアされている。このコード・ライブラリは、オブジェクト指向クラス ・ライブラリを実現するコンピュータ・プログラム・ロジックを含んでいる。オ ブジェクト指向クラス・ライブラリは、オペレーティング・システムから提供さ れるサービスを、アプリケーションがオブジェクト指向方式でアクセスできるよ うにする、相互に関係をもつオブジェクト指向クラスから構成されている。オブ ジェクト指向クラスは、オペレーティング・システムのネイティブ手続き型イン タフェースと互換性のある手続き型関数コール(procedural function call)を使 用してオペレーティング・システムのサービスをアクセスするためのメソッドを 含んでいる。さらに、システムは、アプリケーションに含まれていてクラス・ラ イブラリによって定義されたオブジェクト指向ステートメントを、そのオブジェ クト指向ステートメントに対応するクラス・ライブラリ内のメソッドを実行する ことによって処理する手段も備えている。 好ましくは、クラス・ライブラリは次のものを含んでいる。 (1) スレッド・クラス(thread class)。これは、アプリケーションがオペレー ティング・システムのサービスをオブジェクト指向方式でアクセスして、スレッ ドに関する情報を作成し、管理し、取得することを可能にするものである。 (2) タスク・クラス(task class)。これは、アプリケーションがオペレーティ ング・システムのサービスをオブジェクト指向方式でアクセスして、タスクを参 照し、管理することを可能にするもので、タスクの各々は、それぞれがタスクに 関連づけられているスレッドの実行環境を表している。 (3) バーチャル（仮想）メモリ・クラス(virtual memory class)。これは、ア プリケーションがオペレーティング・システムのサービスをオブジェクト指向方 式でアクセスして、コンピュータ内のバーチャル・メモリをアクセスし、操作す ることを可能にするものである。 (4) プロセス間通信(interprocess communication - IPC)クラス。これは、ア プリケーションがオペレーティング・システムのサービスをオブジェクト指向方 式でアクセスして、そのアプリケーションが実行時(run-time)にコンピュータ中 の他のスレッドと通信できるようにするものである。 (5) 同期化クラス(synchronization class)。これは、アプリケーションがオ ペレーティング・システムのサービスをオブジェクト指向方式でアクセスして、 スレッドの実行を同期化することを可能にするものである。 (6) スケジューリング・クラス(scheduling class)。これは、アプリケーショ ンがオペレーティング・システムのサービスをオブジェクト指向方式でアクセス して、スレッドの実行をスケジュールすることを可能にするものである。 (7) 障害クラス(fault class)。これは、アプリケーションがオペレーティン グ・システムのサービスをオブジェクト指向方式でアクセスして、システムで定 義したプロセッサ障害とユーザが定義したプロセッサ障害を処理することを可能 にするものである。 (8) マシン・クラス(machine class)。これは、アプリケーションがオペレー ティング・システムのサービスをオブジェクト指向方式でアクセスして、ホスト とプロセッサ・セットを定義し、変更することを可能にするものである。 本発明のその他の特徴と利点については、本発明の種々実施例の構造とオペレ ーションと共に、添付図面を参照して以下で詳しく説明するが、これらは請求の 範囲にも記載されている。なお、図面において、同一または機能的に類似のエレ メントは、同一の参照符号を付けて示されている。 図面の簡単な説明 以下、添付図面を参照して本発明を説明する。図面において、 第１図は、本発明のラッパー(wrapper)が動作するコンピュータ・プラットフ ォーム(computer platform)を示すブロツク図である。 第２図は、本発明のオペレーションを示すハイレベル・フローチャートである 。 第３図は、本発明のオペレーションを示す詳細フローチャートである。 第４図は、本発明のオブジェクト指向クラス・ライブラリを収めているコード ・ライブラリを示すブロック図である。 第５図は、本発明のスレッド・クラスとタスク・クラスを示すクラス図である 。 第６図は、本発明のバーチャル・メモリ・クラスを示すクラス図である。 第７図から第９図までは、本発明のプロセス間通信クラスを示すクラス図であ る。 第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 f unction)を含んでおり、これらの関数はオペレーティング・システム102から提 供されるサービスをアクセスするためにコール（呼出し）されるものである。 さらに、コンピュータ・プラットフォーム102はデバイス・ドライバ(device d river)116を含んでいるが、マイクロ命令(microinstruction)コード（ファーム ウェアとも呼ばれる）を含んでいる場合もある。第１図に示すように、デバイス ・ドライバ116は必要とする関数を実行するとき、オペレーティング・システム1 14とやりとりすることができる。アプリケーション・プログラム130,132,134(あ とで詳しく説明する)は、好ましくは、オペレーティング・システム114を通して デバイス・ドライバ116とやりとりするが、別の方法としてデバイス・ドライバ1 16と直接にやりとりすることも可能である。ここで触れておきたいことは、オペ レーティング・システム114は、ディスク・オペレーティング・システム(DOS)や UNIXオペレーティング・システムのような、ほぼ全機能(full-function)のオペ レーティング・システムを表している場合があることである。なお、オペレーテ ィング・システム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は、オペレーティング・システム11 4が実現する環境がアプリケーション・プログラム130A,130B、および132が動作 するのに適した環境になっていければ、オペレーティング・システム114と直接 にやりとりすることができない。例えば、アプリケーション132がIBM PS/2環境 で動作するようになっていれば、アプリケーション132は、オペレーティング・ システム114がIBM PS/2オペレーティング・システム（またはコンパチブル）で なければ、オペレーティング・システム114と直接にやりとりすることができな い。また、アプリケーション・プログラム130Aと130Bがオブジェクト指向環境で 動作するようになっていれば、アプリケーション130A,130Bは、オペレーティン グ・システム114が手続き型インタフェースをもっているので、オペレーティン グ・システム114と直接にやりとりすることができない。第１図に示す例では、 アプリケーション134は、オペレーティング・システム114によって実現されたコ ンピューティング環境で動作するようになっているので、アプリケーション134 は図示のように、オペレーティング・システム114と直接に結ばれている。 ラッパー128は、オペレーティング・システム114にオブジェクト指向インタフ ェースを提供するメカニズムとなるものである。ラッパー128を通して、オブジ ェクト指向アプリケーション130A,130Bは、そのアプリケーションがランタイム すなわち実行時にコンピュータ・プラットフォーム102上で実行されているとき 、手続き型オペレーティング・システムをオブジェクト指向方式で直接にアク セスすることができる。ラッパー129は概念的にはラッパー128と類似している。 ラッパー129はオペレーティング・システム114のためのIBM PS/2インタフェース となるので、アプリケーション132は手続き型オペレーティング・システム114を PS/2方式で直接にアクセスすることができる（なお、アプリケーション132 はIB M PS/2環境で動作するようになっているものとする）。以下では、本発明の説明 は、ネイティブ手続き型インタフェースをもつ手続き型オペレーティング・シス テムとのオブジェクト指向インタフェースとなるラッパー128に限定して行うこ とにする。 ラッパー128は、好ましくは、RAM108にストアされるコード・ライブラリ110と して実現されている。コード・ライブラリ110は、データ記憶デバイス120および ／またはデータ記憶媒体122にストアしておくことも可能である。コード・ライ ブラリ110はオブジェクト指向クラス・ライブラリ402(第４図参照)を実現してい る。本発明によれば、オブジェクト指向クラス・ライブラリ402は、オブジェク ト指向アプリケーション（アプリケーション130Aと130Bのようなもの）がオペレ ーティング・システム114から提供されるサービスをオブジェクト指向方式でア クセスできるようにする、相互に関連をもつオブジェクト指向クラスを含んでい る。オブジェクト指向クラスは、オペレーティング・システム114のネイティブ 手続き型インタフェースと互換性のある手続き型関数を含んでいるメソッドを構 成している。オブジェクト指向クラス・ライブラリ402によって定義されている オブジェクト指向ステートメント（クラス・ライブラリ402のメソッドの１つま たは２つ以上を呼び出すオブジェクト指向ステートメントなど）はアプリケーシ ョン130に挿入可能とすると、アプリケーション130は、アプリケーション130が コンピュータ・プラットフォーム102上で実行時に実行されているとき、オペレ ーティング・システムのサービスをオブジェクト指向方式でアクセスすることが できる。オブジェクト指向クラス・ライブラリ402については、以下の別セクシ ョンで詳しく説明する。 コード・ライブラリ110は、好ましくは、オブジェクト指向クラス・ライブラ リ402を実現する、コンパイル済みで実行可能なコンピュータ・プログラム・ロ ジックを含んでいる。コード・ライブラリ110のコンピュータ・プログラム・ロ ジックはアプリケーション・プログラムとリンクされない。その代わりに、コー ド・ライブラリ110の関係する部分が実行時（ランタイム）にコピーされて、プ ロセスの実行可能アドレス空間(address space)に入れられる。これについては 、あとで詳しく説明する。コード・ライブラリ110のコンピュータ・プログラム ・ロジックはアプリケーション・プログラムとリンクされないので、コンピュー タ・プログラム・ロジックは、アプリケーション・プログラムを修正、再コンパ イルおよび／または再リンクしなくても、いつでも修正することができる（コー ド・ライブラリ110とのインタフェースが変更されない限り）。上述したように 、本発明は、以下では、Machマイクロカーネルと関連づけて説明されているが、 他のオペレーティング・システムをラップするために本発明を使用することも、 本発明の範囲に属することは勿論である。 Machマイクロカーネルを通して、ユーザはいくつかのサービスを利用すること ができるが、サービスは次のようなカテゴリに分類されている。すなわち、スレ ッド、タスク、バーチャル・メモリ、プロセス間通信(IPC)、スケジューリング 、同期化、障害処理、およびホスト／プロセッサ・セット処理である。本発明の クラス・ライブラリ402は、Machサービスのカテゴリ別に、相互に関連をもつク ラス群を含んでいる。第４図に示すように、クラス・ライブラリ402は次のもの を含んでいる。 (1) スレッド・クラス404。これは、アプリケーションがオペレーティング・ システムのサービスをオブジェクト指向方式でアクセスして、スレッドに関する 情報を作成し、管理し、取得することを可能にするものである。 (2) タスク・クラス406。これは、アプリケーションがオペレーティング・シ ステムのサービスをオブジェクト指向方式でアクセスして、タスクを参照し、管 理することを可能にするもので、タスクの各々は、それぞれがタスクに関連づけ られているスレッドの実行環境を表している。 (3) バーチャル・メモリ・クラス408。これは、アプリケーションがオペレー ティング・システムのサービスをオブジェクト指向方式でアクセスして、コンピ ュータ内のバーチャル・メモリをアクセスし、操作することを可能にするもので ある。 (4) IPCクラス。これは、アプリケーションがオペレーティング・システムの サービスをオブジェクト指向方式でアクセスして、そのアプリケーションがコン ピュータで実行されている実行時(run-time)中に他のスレッドと通信できるよう にするものである。 (5) 同期化クラス412。これは、アプリケーションがオペレーティング・シス テムのサービスをオブジェクト指向方式でアクセスして、スレッドの実行を同期 化することを可能にするものである。 (6) スケジューリング・クラス414。これは、アプリケーションがオペレーテ ィング・システムのサービスをオブジェクト指向方式でアクセスして、スレッド の実行をスケジュールすることを可能にするものである。 (7) 障害クラス416。これは、アプリケーションがオペレーティング・システ ムのサービスをオブジェクト指向方式でアクセスして、システムで定義したプロ セッサ障害とユーザが定義したプロセッサ障害を処理することを可能にするもの である。 (8) マシン・クラス418。これは、アプリケーションがオペレーティング・シ ステムのサービスをオブジェクト指向方式でアクセスして、ホストとプロセッサ ・セットを定義し、変更することを可能にするものである。 クラス・ライブラリ402には、将来Machから提供される他のサービス・カテゴ リ用の追加クラスを含めることも可能である。例えば、現在、セキュリティ・ク ラス(security class)がMach用に開発中である。従って、クラス・ライブラリ40 2にセキュリティ・クラス420も含めておけば、アプリケーションはオペレーティ ング・システムのセキュリティ・サービスをオブジェクト指向方式でアクセスす ることが可能になる。理解されるように、クラス・ライブラリ402に組み入れる クラスの正確な数とタイプは、基礎となるオペレーティング・システムのインプ リメンテーションによって決まる。 好適実施例のオペレーションの概要説明 以下では、本発明のハイレベル・オペレーション・フローチャート202を示し ている第２図を参照して、本発明のオペレーションの概要について説明する。本 発明は、オブジェクト指向アプリケーション130Aがコンピュータ・プラットフォ ーム102上で実行されることを前提に説明されている。フロートチャート202の事 実上の第１ステップであるステップ206で、アプリケーション130Aがコンピュー タ・プラットフォーム102上で実行されるとき、オペレーティング・システム114 から提供されるサービスをアクセスするオブジェクト指向ステートメントの位置 がアプリケーション130A中で認識される。オブジェクト指向ステートメントはオ ブジェクト指向クラス・ライブラリ402によって定義されている。例えば、オブ ジェクト指向ステートメントは、クラス・ライブラリ402のクラスの１つによっ て定義されたメソッドを参照することができる。このあとに続くステップでは、 ステートメントがコンピュータ・プラットフォーム102によってどのように実行 されるかについて説明する。 ステップ208で、オブジェクト指向ステートメントは、オペレーティング・シ ステム114のネイティブ手続き型インタフェースと互換性があり、しかも、オブ ジェクト指向ステートメントに対応する手続き型関数コールに変換される。ステ ップ208が実行されると、ステートメントは、ステートメントの中で参照された メソッドを実現している、コード・ライブラリ110からのコンピュータ・プログ ラム・ロジックに変換される。上述したように、メソッドは、オペレーティング ・システム114のネイティブ手続き型インタフェースと互換性のある手続き型関 数コールを少なくとも１つ含んでいる。ステップ210で、ステップ208からの手続 き型関数コールはコンピュータ・プラットフォーム102で実行されて、サービス がオペレーティング・システムからアプリケーション130Aのために提供される。 ステップ210は、ステップ208で述べたメソッドを実行することにより実行され、 これにより手続き型関数コールが呼び出される。 次に、本発明のオペレーションの詳細フローチャート302を示している第３図 を参照して、好適実施例のオペレーションを詳しく説明する。ここでも、本発明 はオブジェクト指向アプリケーション130Aがコンピュータ・プラットフォーム10 2上で実行されることを前提に説明されている。もっと具体的には、本発明は、 オブジェクト指向アプリケーション130Aの１つのオブジェクト指向ステート メントがコンピュータ・プラットフォーム102上で実行されることを前提に説明 されている。アプリケーション130Aは、オペレーティング・システムから提供さ れるサービスをアクセスするステートメントを含んでおり、これらのステートメ ントはクラス・ライブラリ402によって定義されているものとする（言い換えれ ば、プログラマはクラス・ライブラリ402への参照をもつアプリケーション130A を作成したものとする）。以下で詳しく説明するが、Machマイクロカーネルでの 実行可能エンティティ(executable entity)はスレッドと呼ばれている。また、M achマイクロカーネルでの処理編成エンティティ（processing organization ent ity）はタスクと呼ばれている。タスクは１つまたは２つ以上のスレッド（並行 実行が可能である）と、タスクのスレッドが実行されるバーチャル・メモリのブ ロックを表しているアドレス空間とを含んでいる。どの時点でも、複数のタスク がコンピュータ・プラットフォーム102上でアクティブ状態にあることが可能で ある。コンピュータ・プラットフォーム102上で実行されるとき、アプリケーシ ョン130Aはタスク全体（１つまたは複数のスレッドをもっている）を表している ことも、タスクの一部になっている少数のスレッドを表していることもある（後 者の場合には、タスクは他のスレッドをもつことになり、そのスレッドはアプリ ケーション130Aのオペレーションと関係がある場合と関係がない場合とがある） 。本発明の範囲には、アプリケーション130Aがタスク全体である場合も、タスク の少数のスレッドだけである場合も含まれる。 次に第３図を参照して説明する。ステップ308において、ステートメントの中 で参照されたメソッドを実現している、コード・ライブラリ 110からのコンピュ ータ・プログラム・ロジック（コンピュータ・コードとも呼ばれる）がアプリケ ーション130Aに関連するタスク・アドレス空間に存在するかどうかが判断される 。コンピュータ・プログラム・ロジックがタスク・アドレス空間に存在していれ ば、ステップ316が処理される（下述する）。コンピュータ・プログラム・ロジ ックがタスク・アドレス空間に存在しなければ、コンピュータ・プログラム・ロ ジックはステップ310,312および314でタスク・アドレス空間へ転送される。ステ ップ310では、コード・ライブラリ110に関連するライブラリ・サーバ（図示せず ）が既知のものかどうかが判断される。コード・ライブラリ110は、 ラッパー128に関係する複数のコード・ライブラリ（図示せず）を表している場 合があり、その場合には、コード・ライブラリの各々は、クラス・ライブラリ40 2のオブジェクト指向クラスの一つのコンピュータ・プログラム・ロジックを含 んでいる。この分野の専門家ならば理解されるように、ラッパー128とはまった く関係のない他のコード・ライブラリ（図示せず）が存在する場合もある。 コード・ライブラリと関連づけられているものとしてライブラリ・サーバがあ り、その各々は指定されたコード・ライブラリの資源を管理している。コード・ ライブラリのコンピュータ・プログラム・ロジックへのアクセスを望んでいる処 理エンティティはそのコード・ライブラリのライブラリ・サーバに対して要求を 行う。この要求には、例えば、必要とするコンピュータ・プログラム・ロジック の記述とそのコンピュータ・プログラム・ロジックを送るべき宛先アドレスを含 めることができる。ライブラリ・サーバは、必要とするコンピュータ・プログラ ム・ロジックをコード・ライブラリからアクセスし、必要とするコンピュータ・ プログラム・ロジックを宛先アドレスで指定されたメモリ・エリアヘ送ることに よって要求を処理する。ライブラリ・サーバの構造とオペレーションはこの分野 では公知である。このようにして、ステップ310で、関係するコンピュータ・プ ログラム・ロジックを収めているコード・ライブラリ110に関連するライブラリ ・サーバが既知であるかが判断される。ステップ310は、例えば、既知のライブ ラリ・サーバを示しているライブラリ・サーバ・テーブルとそのサーバのサービ スを受けるコード・ライブラリを参照することにより実行される。ライブラリ・ サーバが既知のものであれば、ステップ314が処理される（下述する）。そうで なければ、ステップ312が処理される。ステップ312では、コード・ライブラリ11 0に関連するライブラリ・サーバが識別される。ライブラリ・サーバのIDは、例 えば、処理されているオブジェクト指向ステートメントの内容から知ることがで きる。 コード・ライブラリ110に関連するライブラリ・サーバが識別されると、ある いはライブラリ・サーバが既知のものであれば、ステップ314が処理される。ス テップ314では、要求がライブラリ・サーバへ送られて、ステートメントの中で メソッド参照に関連するコンピュータ・プログラム・ロジックをタスク・アドレ ス空間にコピーするようにライブラリ・サーバに要求する。ステップ314が完了 すると、ライブラリ・サーバは、要求したコンピュータ・プログラム・ロジック をタスク・アドレス空間にコピーしている。好ましくは、コード・ライブラリ11 0は共有ライブラリになっている。つまり、コード・ライブラリ110は、複数のス レッドが同時にアクセスすることが可能になっている。しかし、好ましくは、コ ード・ライブラリ110のコンピュータ・プログラム・ロジックは、物理的には１ つの物理メモリ・エリアだけにストアされている。ライブラリ・サーバは、コン ピュータ・プログラム・ロジックをコード・ライブラリ110からタスク・アドレ ス空間に仮想的にコピーする。つまり、コンピュータ・プログラム・ロジックを 物理メモリのある部分から別の部分に物理的にコピーするのではなく、ライブラ リ・サーバは、関係するコンピュータ・プログラム・ロジックを収めている物理 メモリ・エリアを指すポインタをタスク・アドレス空間に入れる。ステップ316 で、オブジェクト指向ステートメントに関連するコンピュータ・プログラム・ロ ジックがコンピュータ・プラットフォーム102上で実行される。上述したように 、オブジェクト指向ステートメントがオペレーティング・システム114をアクセ スするような場合には、メソッドに関連するコンピュータ・プログラム・ロジッ クは、オペレーティング・システム114のネイティブ手続き型インタフェースと 互換性がある手続き型関数コールを少なくとも１つ含んでいる。従って、メソッ ドのコンピュータ・プログラム・ロジックを実行すると、手続き型関数コールが 呼び出されて実行され、これにより、オペレーティング・システム114からサー ビスがアプリケーション130Aに提供される。 上述したように、コンピュータ・プラットフォーム102でのステップ306,308,3 10,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 カーネルの原理」(Mach 3 Kernel Principles)(Open Software Foundation and Carnegie Mellon University，Draft Industrial Specification，September 19 92 and November 1992)、K.Loepere編集「Mach 3カーネル・インタフェース」(M ach 3 Kernel Interfaces)(Open Software Foundation and Carnegie Mellon Un iversity，Draft Industrial Specification，September 1992 and November 19 92)、K.Loepere編集「Mach 3サーバ・ライタのガイド」(Mach 3 Server Writer' s Guide)(Open Software Foundation and Carnegie Mellon University，Draft Industrial Specification，September 1992 and November 1992)、K.Loepere編 集「Mach 3サーバ・ライタのインタフェース」(Mach 3 Server Writer's Interf aces)(Open Software Foundation and Carnegie Mellon University，Draft Ind ustrial Specification，September 1992 and November 1992)、A Silbershatz 、J.Peterson、P.Galvin共著「オペレーティング・システムの概念」(Operating System Concepts)(Addison-Wesley，July 1992)、およびA.Tanenbaum著「最新 オペレーティング・システム」(Modern Operating Systems)(Prentice Hall，19 92)。 スレッド Machにおける実行可能エンティティはスレッド(thread)と呼ばれている。スレ ッドは、スレッドをシステムで実行可能にする側面をいくつかもってい る。スレッドはタスクに常に含まれており、タスクは、スレッドが利用できる主 要資源（例えば、アドレス空間）の大部分を表している。スレッドは実行状態(e xecution state)をもつており、これは基本的には、マシン・レジスタと、その コンテキストを構成する他のデータとが集まったものである。スレッドは常に７ つのスケジューリング状態の１つ、つまり、実行中、実行準備状態、あるいは何 らかの理由による停止の状態に置かれている。スレッドの目的は実行エンティテ ィを軽量化することにある。その目的は、プログラマがアプリケーションの中で 多数のスレッドを使用することを奨励し、もって、従来のオペレーティング・シ ステムに見られた以上の並行性(concurrency)をシステムに導入することにある 。スレッドは若干のコストが伴わないわけではないが、実際には最小コストで済 むので、Mach環境の代表的なアプリケーションやサーバはこの機能を活用するこ とができる。 しかし、スレッドには、関連づけられているいくつかのエレメントを有してい る。スレッドが置かれているタスクとアドレス空間は、実行状態と共に、すでに 説明したとおりである。各スレッドはスケジューリング・ポリシ(scheduling po licy)をもっている。スレッドがそこで実行されるプロセッサをスレッドにいつ 、どのような頻度で与えるかはこのポリシによって決まる。スケジューリング・ サービスは別のセクションで詳しく説明する。スレッドのスケジューリング・ポ リシと密に結び付いているのが、オプションのプロセッサ・セット(processor s et)の指定である。これをマルチプロセッサ・システムで使用すると、スレッド のプロセッサへの割当てを密に制御できるので、アプケーション・パフォーマン スを大幅に向上することができる。前述したように、アドレス空間（タスク）に は、０個または１個以上のスレッドを置いて並行に実行させることができる。カ ーネルは、アドレス空間内の、実際にはシステム全体内のスレッド間の関係につ いてはなにも想定していない。むしろ、カーネルはスレッドに関連するスケジュ ーリング・パラメータとシステム内の使用可能プロセッサ資源に従って、スレッ ドをスケジュールし、実行する。具体的には、スレッドがアドレス空間に置かれ るときの配置（例えば、階層）は無関係であり、また、スレッドがどのようにや りとりし合うかについても想定されていない。実行順序とスレッ ド間の調整を制御してなんらかの有用な目的を達成するために、Machにはいくつ かの同期化メカニズムが用意されている。最も単純な（最も粗い）メカニズムは スレッド・レベルの一時中止および再開(suspend and resume)オペレーションで ある。各スレッドは一時中止カウント(suspend count)をもち、これは、これら のオペレーションによってインクリメントされ、デクリメントされる。一時中止 カウントが正になっているスレッドは、カウントがゼロになるまでブロック（中 断）されたままである。 同期化オブジェクト（セマフォアまたはモニタと条件）を使用すると、もっと きめ細かな同期化が得られるので、様々なスタイルの同期化が使用できる。スレ ッドはプロセス間通信(IPC)を通してやりとりすることもできる。これらのサー ビスの各々は、別のセクションに詳しく説明されている。スレッドの作成、終了 およびその属性の取得と設定をサポートするものとして基本的オペレーションが ある。また、他にも、スレッドに対する制御オペレーションがいくつかあり、こ れは、意図するスレッドの制御ポートに対する送信権をもつスレッドが実行でき る。スレッドは明示的に終了させることができる。また、様々な待ち状態からイ ンタラプトされ、インタラプトしたとの通知と共に実行を再開させることも可能 である。スレッドを「ワイヤド」（wired−固定すること））にすることも可能 である。このことは、カーネル資源に対して特権があるとのマークがスレッドに 付いていること、つまり、空きメモリが不足したときスレッドが物理メモリを使 用できることを意味する。これは、スレッドがデフォルトのページアウト経路(p age-out path)にあるとき使用される。最後に、スレッドはいくつかの重要なIPC ポート（正確には、これらのポートに対する送信権または受信権）ももっており 、これらはある種の関数で使用される。具体的には、各スレッドはスレッド・セ ルフ・ポート (thread self port)をもっており、これはスレッドに対するある種 のオペレーションを自身で実行するために使用できる。スレッドは一組の障害ポ ート (fault ports)ももっており、これは、その実行中にスレッドにプロセッサ 障害が起こったとき使用される。特異なポートもあり、これは、スレッドの実行 状態のサンプルを収集して、デバッガやプログラム・プロファイラ(program pro filer)などの他のスレッドにモニタリングさせるために使用でき る。 タスク Machにおいて、資源を管理するための基本的編成エンティティはタスクと呼ば れる。タスクには、多数のオブジェクトと属性が関連づけられている。タスクは 基本的に３つのものからなっている。タスクは複数のスレッドを収めており、こ れらはシステム内の実行可能エンティティである。また、タスクはアドレス空間 (address space)ももっており、これは、そのスレッドをそこで実行できるバー チャル・メモリを表している。さらに、タスクはポート名スペース(port name s pace)をもっており、これは、スレッドがそこを通してシステム内の他のスレッ ドと通信できる有効なIPCポートを表している。タスク内のこれらの基本的オブ ジェクトの各々は、このとに続くセクションで詳しく説明されている。注意すべ きことは、タスクは、Machでは、それ自体が実行可能エンティティでないことで ある。しかし、タスクはスレッドを収容することができ、これらは実行可能エン ティティである。タスクには、上述した基本的エンティティのほかに、他のいく つかのエンティティが関連づけられている。これらのエンティティのいくつかは 、タスクに含まれるスレッドのためにカーネルが行う必要のあるスケジューリン グ判断と関係がある。スケジューリング・パラメータ(scheduling parameters) 、プロセッサ・セット(processor set)、およびホスト(host)情報は、いずれも タスクのスレッドのスケジューリングに貢献している。また、タスクは、ある種 の事前に定義された関数に使用される特異なプロセス間通信ポートもいくつかも っている。プロセス間通信のポートおよびその他の側面は別のセクションで詳し く説明されている。今の段階では、ポート資源は時間の経過と共にタスクに累積 されていくということを知っているだけで十分である。これらの資源の大部分は 、プログラマによって明示的に管理される。上述した特異なポートは、通常、シ ステム内のいくつかの重要な関数との接続を確立することに関係している。Mach には、各タスクのために３つの「特殊」ポート("special"port)が用意されてい る。最初のポートはタスク・セルフ・ポート(task self port)で あり、これはタスクに対してある種のオペレーションを実行するようにカーネル に要求するために使用できる。二番目の特殊ポートはブートストラップ・ポート (bootstrap port)であり、これは何にでも使用できるが（これはOS環境特有のも のである）、一般的には、他のサービスを探すために使用される。各タスクがも つ三番目の特殊ポートはホスト名ポート(host name port)であり、これは、タス クがそこで実行中のマシンに関するある種の情報をタスクが得るために使用され る。そのほかにも、Machには、タスクに含まれるスレッドがシステム内のある種 の上位レベル・サービスと通信できるようにする、いくつかの「登録」ポート(" registered"port)が各タスクのために用意されている（例えば、ネットワーク名 サービス、「サービス」サーバ、環境サーバ）。 ほかにも、２つの有用なポート・セットが各タスクのために存在する。これら のポートは障害処理とプログラム・ステート・サンプリングを行うために使用さ れるものである。タスクの障害ポート(fault port)は処理しようするタスクに含 まれるスレッドにプロセッサ障害が起こったときの共通場所となるものである。 障害処理は別のセクションに詳しく説明されている。PCサンプル・ポート(PC sa mple port)は、プロファイリング・ツールがタスク内のスレッドの実行状態を繰 返しモニタできるようにする。タスクでは多数のオペレーションが可能である。 タスクを作成し、終了させることができる。新しいタスクを作成するには、ある 既存タスクを新タスクのアドレス空間の初期内容のプロトタイプとして指定する 。タスクは終了させることも可能であり、タスクが終了すると、そこに含まれる スレッドのすべても終了する。タスクに含まれるスレッドを列挙して、スレッド に関する情報を抽出することができる。タスク（正確には、タスク内のスレッド ）の粗粒(coarsegrain)実行は、一時中止と再開オペレーションを通して制御す ることができる。各タスクは一時中止カウントをもち、このカウントは、一時中 止および再開オペレーションによってインクリメントされ、デクリメントされる 。タスク内のスレッドは、そのスレッドを含んでいるタスクの一時中止カウント がゼロであるかぎり実行可能である。一時中止カウントが正になると、タスク内 のすべてのスレッドはタスクがあとで再開されるまでブロック（中断）される。 最後に、タスクに関連する種々のパラメータと属性（例えば、スケ ジューリング優先順位）を照会して、希望の値に設定することが可能である。 バーチャル・メモリ Machは、そのバーチャル・メモリ(VM)サブシステムにおけるいくつかの機能を サポートしている。外部クライアント・インタフェース(external client inter face)と内部インプリメンテーション(internal implementation)はどちらも、他 の多くのオペレーティング・システムには見当たらない特徴を備えている。広義 の意味では、Machバーチャル・メモリ・システムはシステム内で実行されるタス クの各々のために、大きな疎密度(sparsely populated)バーチャル・アドレス空 間をサポートしている。クライアントには、アドレス空間の構成を管理するため の汎用サービスが提供される。VMシステムのいくつかの側面は、実際には、マイ クロカーネルの外側にあるコンポーネントによって実現されているので、ある種 のポリシ関数(policy function)を異種システム環境に合わせて柔軟に調整する ことができる。Mach VMシステムの内部アーキテクチャは、移植性(portability) を最大にするためにマシン独立モジュールとマシン依存モジュールに分割されて いる。新しいプロセッサ/MMUアーキテクチャへ移植することは、一般的には、小 さな問題であり、その問題とは、基本的ハードウェアMMU構造を取り扱ういくつ かの関数を実現することである。Machはすでにいくつかの異種プロセッサ・アー キテクチャに移植されており、カーネル全体と特にバーチャル・メモリ・システ ムに移植性があることが実証されている。Machタスクのアドレス空間はいくつか のバーチャル・メモリ領域(virtual memory region)を含んでいる。これらの領 域はバーチャル・アドレス空間の断片であり、タスクが使用するためにいろいろ な方法で割り振られている。これらは、メモリを合法的にアクセスできる唯一の ロケーションである。アドレス空間内の定義された領域外のアドレスへの参照は すべて、正しくないメモリ参照エラーとなる。バーチャル・メモリ領域には興味 のある属性がいくつかある。ページ境界合わせされた(page-aligned)開始アドレ スとサイズをもち、サイズはシステム・ページ・サイズの倍数になっていなけれ ばならない。領域内のページはすべて、アクセス保護が同一 になっている。これらのアクセス保護には読取り専用(read-only)、読み書き(re ad-write)または実行(execute)がある。また、領域内のページは同じ継承特性も もっており、これは新タスクが現タスクから作成されるとき使用できる。領域内 のページの継承特性は、新タスクが領域の読み書きコピーを継承すること、領域 のバーチャル・コピーを継承すること、または領域のどのコピーも継承しないこ とを示すようにセットすることができる。新アドレス空間内の領域の読み書きコ ピーは、領域を完全にマッピングしてタスク間で共有されるのに対し、バーチャ ル・コピーはコピー・オン・ライト(copy-on-write)でマッピングしたものであ り、基本的には、各タスクには領域の独自のコピーが与えられるが、領域を構成 するページを効率的なコピー・オン・ライトで共有している。 すべてのバーチャル・メモリ領域は、実際には、メモリ・オブジェクト(memor y object)と呼ばれる抽象エンティティをマッピングしたものである。メモリ・ オブジェクトは、ある種のバイト単位(byte-wise)方式でアドレスできるデータ が集まったものにすぎず、カーネルはデータについてはなにも想定していない。 これは、どこかの場所に明示的にストアできる、あるいは必要時になんらかの方 法で作ることができる、純粋なデータ断片と考えた方が好都合である。メモリ・ オブジェクトとして役立つものには、多種類のものがある。例を挙げると、よく 知られたものとして、ファイル、ROM、ディスク区画(disk partition)、フォン トなどがある。メモリ・オブジェクトには、オブジェクトが従わなければならな い事前定義のオペレーションやプロトコルはない。メモリ・オブジェクトに収め られたデータがアクセスできるのは、そのデータがマッピングを通してVM領域と 結び付けられたときだけである。メモリ・オブジェクトがある領域にマッピング されると、通常のメモリ読み書き（ロードとストア）オペレーションによってデ ータをアクセスすることができる。メモリ・オブジェクトは、一般的には、外部 メモリ・マネージャ (external memory manager)またはページャ(pager)と呼ばれ る特殊なタスクによって管理される。ページャは、システム内の他のタスクとま ったく同じようにマイクロカーネルの外で実行されるタスクである。これはユー ザ・モード・エンティティであり、その仕事はそれがサポートするメモリ・オブ ジェクトのデータに対するある種の要求を処理するこ とである。クライアント・タスク内のスレッドがある領域内のページを参照する と、カーネルは、関連のメモリ・オブジェクト内の対応するバイト・アドレスか らのデータをページに論理的に入れる。これを行うには、カーネルは実際には、 ページ・フォルト(page fault−ページ不在）のときはデータを取得する必要が 起こったとき、ページ置換のときはデータをページ・アウトする必要が起こった とき、ページャと共に明確に定義された（しかも煩わしい）プロトコルに従う。 このプロトコルは外部メモリ管理インタフェース(External Memory Management Interface - EMMI)とも呼ばれ、上記の他に、メモリ・オブジェクトがクライア ント・タスクによってマッピングされるときはオブジェクトの初期設定シーケン スを取り扱い、関連のメモリ領域がクライアント・タスクによって割当て解除(d eallocate)されるときは終了シーケンスを取り扱う。 ページャは、どのメモリ・オブジェクトが、種々のクライアント・タスクによ って使用中であるかに応じて、いくつでもシステムで稼働することができる。ペ ージャは、例えば、マウントされている種々のフィアル・システムと、所定の時 点で関連づけられるのが典型的である。また、ページャはある種のデータベース ・アプリケーションをサポートするために存在している場合もあるが、その場合 は、ファイル・システムがサポートする以上のオペレーションが必要になること もある。ページャは、標準外の方法で（例えば、記憶サブシステムからデータを 取り出すのではなく、計算によってデータを生成する場合など）そのクライアン トへデータを提供することを望んでいるある種のサーバのために存在する場合も ある。マイクロカーネルは、常に、デフォルト・ページャ(default pager)と呼 ばれる、ある種の特異なページャがシステムで稼働していることを期待している 。このデフォルト・ページャはスタック、ヒープなどの無名(anonymous)バーチ ャル・メモリと関連づけられたメモリ・オブジェクトの管理を担当する。この種 のメモリは一時的であり、クライアント・タスクが実行中のときだけ使用される 。上述したように、Mach VMシステムでの主要エンティティは領域、メモリ・オ ブジェクト、およびページャである。しかし、大部分のクライアントは、メモリ を範囲(range)でオペレーションすることによりバーチャル・メモリを取り扱う 。範囲は領域の一部にすることができるが、アドレス空間内の複数の連続領域 にスパンすることも可能である。Machに用意されているオペレーションによれば 、ユーザは新しい範囲のバーチャル・メモリをアドレス空間内に割り当てること ができ、必要時に範囲の割当てを解除することができる。もう１つ重要なオペレ ーションによれば、メモリ・オブジェクトを、上述したようにある範囲のバーチ ャル・メモリにマッピングすることができる。また、メモリ範囲の保護を変更し 、継承特性を変更し、ある範囲のページを物理メモリにワイヤ(wire−固定)（ま たはロック）できるオペレーションも用意されている。メモリ範囲を別のタスク から読み取ったり、別のタスクの範囲に読み込んだりすることも可能であるが、 タスクの制御ポートが使用できることが条件である。ほかにも、ユーザがメモリ 範囲の期待参照パターン(expected reference pattern)を指定できるようにする サービスも用意されている。これは、事情が変化したとき、ページ置換ポリシ(p age replacement policy)をどのような方法で適応させるかの助言としてカーネ ルが使用できる。さらに、ある範囲のメモリの内容を、そのメモリ範囲をバック するメモリ・オブジェクトと同期化（またはフラッシュ）させるためのサービス も用意されている。最後に、領域に関する情報を取得し、タスクのアドレス空間 に置かれている領域を中心に記載されているアドレス空間の内容を列挙できるサ ービスが用意されている。 プロセス間通信 Machには、そのプロセス通信機能の中心となっている４つの概念がある。それ は、ポート(port)、ポート・セット(port set)、ポート権(port right)、およびメッセージ (message)である。これらの概念の１つであるポート権は、Machでは 、システム内のある種の共通資源（スレッド、タスク、メモリ・オブジェクトな ど）を識別する手段としても使用されている。 ポート スレッドはポートを使用して相互に通信する。ポートは、基本的には、カーネ ル内部のメッセージ・キュー（待ち行列）であり、スレッドは正しい許可を得て いれば、そこにメッセージを追加したり、そこからメッセージを除去したりする ことができる。これらの「許可」(permission)はポート権と呼ばれる。ポート権 の他に、ポートに関連づけられる他の属性として、ポート上のキューに置くこと ができるメッセージ数の制限、ポートに送信できるメッセージの最大サイズの制 限、ポート権がいくつ存在するかのカウントなどがある。ポートはカーネル内だ けに存在し、ポートはポート権があるときだけ操作できる。 ポート権 スレッドはポートに対して送信権をもっていれば、そのポートのメッセージ・ キューにメッセージを追加することができる。同様に、スレッドはポートに対し て受信権をもっていれば、そのポートのメッセージ・キューからメッセージを移 動することができる。ポート権は、個別のスレッドではなく、タスクの資源と考 えられている。ポートに対する送信権はいくつでも可能である（多数の異なるタ スクが保有する）。しかるに、ポートに対する受信権は１つだけである。実際に は、ポートは受信権を割り当てると作成されるが、ポートが壊されるのは、受信 権の割当てが解除されたときだけである（明示的に、またはタスクが消滅したと きは黙示的に）。さらに、ポートの属性は受信権を通して操作される。複数のス レッド（同一または異なるタスクの）はポートへの送信を同時に行うことができ 、複数のスレッド（同一タスクの）はポートからの受信を同時に行うことができ る。ポート権は、ポートとの間でメッセージを送受信する許可(permission)また は機能(capability)として働くので、ポート権によって実現されるシステムのセ キュリティは低レベルになっている。ポートの「所有者」（owner）は受信権を 保持しているタスクである。別のタスクがポートの送信権を取得できるのは、（ 所有者から、あるいはそのポートの有効な送信権を保持するいずれかのタスクか ら）送信権が明示的に与えられた場合だけである。これは主に、送信権をメッセ ージに組み入れて、そのメッセージを別のタスクへ送ることにより行われる。あ るタスクに送信権を与えると、そのタスクには、必要なだけのメッセージを ポートへ送る許可が与えられる。一回送信権(send-once right)と呼ばれる、別 の種類のポート権がある。このポート権所持者は１つのメッセージだけをポート へ送ることができ、その時点で一回送信権は無効になり、再使用することができ ない。なお、ポートの受信権をメッセージに入れて別のタスクへ送ると、ポート の所有権を移転することができる。 タスクはポート権を作るか、あるいはポート権をメッセージで受け取ることに よりポート権を獲得する。受信権は明示的にだけ作ることができる（上述したよ うに、ポート割当てを行うことにより）。送信権は、既存の送信権または受信権 から明示的に作ることも、メッセージに入れて送信するとき黙示的に作ることも できる。一回送信権は、受信権だけから明示的にも黙示的にも作ることができる 。ある権利がメッセージで送信されるとき、送信側は、その権利がコピーされる か、移動されるか、あるいは送信オペレーションで作成された新権利であるかを 指定することができる。（受信権は、当然のことながら、移動しかできない）。 権利が移動されるときは、送信側はその権利を失い、受信側がその権利を取得す る。コピーされるときは、権利は送信側に残っているが、その権利のコピーが作 成されて受信側に渡される。作成されたときは、送信側は受信権を提供し、新し い送信権または一回送信権が作られて受信側に渡される。タスクがなんらかの方 法でポート権を獲得すると、Machはそれに名前を付ける。なお、名前が付けられ るのはポート自体ではなく、そのポート権である。（それにもかかわらず、Mach の作成者は、分かりやすいポート権名(port right name)ではなく、ポート名(po rt name)でポート権の名前を参照することを決定している。）この名前はスカラ ー値（Intelマシンでは32ビット）になっており、タスク内だけでユニークであ ることが保証され（このことは、複数のタスクは各々が、同一の数値からなるが 、完全に異なるポートに対するポート権を表しているポート名をもつことができ ることを意味する）、ランダムに選択されている。タスクによって保持される各 権利ごとに、必ずしも異なるポート名を割り当てる必要はない。一回送信権は常 に、各権利ごとに別の名前をもっている。しかし、同じポートを参照する受信権 と送信権は同じ名前をもっている。 ポート権には、いくつかの属性が関連づけられている。すなわち、権利のタイ プ(送信、一回送信、受信、ポート・セット、またはデッド名(deadname))、およ び上記権利のタイプ別の参照カウントである。あるタスクがポートの権利を獲得 し、そのポートの送信権または受信権をすでにもっているときは、関連のポート 名の参照カウントがインクリメントされる。ポート名は、その関連ポートが壊さ れるとデッド名(dead name)になる。つまり、その受信権が割当て解除されてい るポートの送信権または一回送信権を表している、すべてのポート名はデッド名 になる。タスクは、その権利の１つがデッドになったとき通知を要求することが できる。カーネルは、各ポートの送信権と受信権の数のカウントを、システム・ ワイドでとっている。受信権を保持するタスク（サーバなど）は、この数がゼロ に達して、そのポートに対する送信側（クライアント）が残っていないことを示 しているとき、通知メッセージを送ることを要求することができる。これは「送 信側が残っていない」(no more senders)通知と呼ばれる。要求には、通知を送 るべきポートに対する送信権が含まれていなければならない。 ポート・セット ポート・セットは、ポートの集合から同時に受信できるようにするものである 。つまり、受信権をポート・セットに追加しておくと、ポート・セットで受信が 行われるとき、セット内のポートの１つからメッセージを受信することができる 。メッセージを出したポートの受信権の名前は受信オペレーションによって報告 される。 メッセージ Mach IPCメッセージはヘッダ(header)とインライン・データ(in-line data)部 分からなっており、任意的に、いくつかのアウトオブライン・メモリ(out-of-li ne memory)領域とポート権(port right)を含んでいる。メッセージがポート権と アウトオブライン・メモリのどちらも含んでいないときは、そのメッセージは単 純 (simple)メッセージであると言われる。含んでいれば、それは複合 (complex)メッセージである。単純メッセージはメッセージ・ヘッダと、その直 後に続くインライン・データ部分とを含んでいる。メッセージ・ヘッダは宛先ポ ート送信権、応答を送ることができる任意の送信権（通常は、一回送信権）、お よびメッセージのデータ部分の長さを含んでいる。インライン・データは可変長 であり（ポート単位で指定された最大値の制約を受ける）、解釈されずにコピー される。複合メッセージはメッセージ・ヘッダ（フォーマットは単純メッセージ と同じ）と、そのあとに置かれた次のものとからなっている。つまり、アウトオ ブライン・メモリ領域の数のカウントと、これらの領域とポートのカーネルによ る処理を記述した後処理配列(disposition array)と、アウトオブライン記述子 とポート権を収めている配列である。 ポート権の後処理配列はポート権をどのように処理したいか、つまり、コピー するのか、作成するのか、ターゲット・タスクへ移動するのかを記述している。 アウトオブライン・メモリの後処理配列は、メッセージがキューに置かれたとき 割当てを解除するのかどうか、あるいはバーチャル・メモリcopy-on-rightメカ ニズムを通してメモリを受信側タスクのアドレス空間にコピーするのか、受信側 アドレス空間にマッピングするのかを、各メモリ範囲別に指定している。タスク がメッセージを受け取ると、ヘッダ、インライン・データ、および記述子配列が 、受信コールへのパラメータの中で指定されたアドレスにコピーされる。メッセ ージがアウトオブライン・データを含んでいれば、受信側タスクのアドレス空間 内のバーチャル・メモリはアウトオブライン・データを収容するようにカーネル によって自動的に割り当てられる。データの処理を終えたとき、これらのメモリ 領域の割当てを解除するのは受信側タスクの責任である。 メッセージ送信の意義 Mach IPCは基本的には非同期の性格をもっている。スレッドはメッセージをポ ートヘ送り、メッセージがポート上のキューに置かれると、送信側スレッドは実 行を続ける。ポートのキューに置かれたメッセージがなければ、ポートでの受信 はブロック(block)する。効率化のために、send/receiveが結合したコールが 用意されており、このコールは、メッセージを送信すると、特定の応答ポートで メッセージを待つことを即時にブロックする（同期モデルの実現）。すべてのメ ッセージ・オペレーションでタイムアウトを設定しておくと、メッセージが特定 の時間期間内に送信できないとき（または受信されるメッセージがないとき）オ ペレーションが途中で中止(abort)されることになる。sendコールは対応するポ ートがその最大メッセージ数まで達している送信権を使用すると、ブロックされ る。sendが一回送信権を使用していれば、メッセージは、ポートが一杯であって もキューに置かれることが保証される。メッセージの配達は信頼性があり、メッ セージは送信順に受信されることが保証される。なお、Machには、非同期モデル よりも同期モデルの場合に最適化する特殊ケース・コードがある。最高速のIPC ラウンドトリップ・タイムは、サーバがreceiveに続いてループに入って反復的s end/receiveを行い、クライアントがクライアント側のループに入って対応するs end/receiveを行うことによって達成される。 識別子としてのポート権 カーネルは、ポート権が偽造され得ないこと、メッセージが誤送または不正に 使用され得ないことを保証するので、ポート権は非常に信頼性があり、安全な識 別子(identifier)の働きをする。Machは、タスク、スレッド、メモリ・オブジェ クト、外部メモリ・マネージャ、システム特権オペレーションの実行許可、プロ セッサ割当てなどを含む、システム内のほとんどすべてを表すためにポート権を 使用することによってこれを利用する。さらに、カーネルは自らがメッセージを 送受信できるので（カーネルは自身を「特殊」タスクとして表している）、大部 分のカーネル・サービスは、システム・コールのトラップではなく、IPCメッセ ージを通してアクセスされる。その必要が起こった場合、サービスが比較的容易 にカーネルから移出(migrate)できたのはそのためである。 同期化 現在、Machは同期化機能を直接にサポートしていない。しかし、従来のオペレ ーティング・システムはルーチンとして同期化サービスを提供している。この種 の同期化サービスは、セマフォアとモニタと条件（下述する）といった、多数の 公知のメカニズムを採用している。セマフォア(semaphore)とは、資源への排他 的アクセスと共有アクセスを可能にする同期化メカニズムである。セマフォアは 獲得し、解放することができ（排他的モードまたは共有モードで）、獲得オペレ ーションでタイムアウト期限を任意的に指定することができる。セマフォアは、 セマフォアを保持しているスレッドが途中で終了したとき、セマフォアに関連す るカウンタが調整され、待ちに置かれていたスレッドは該当するとき、ブロック が解除される(unblock)という意味で任意的に回復可能である。 モニタ(monitor)と条件(condition)は、単純なセマフォアよりも相対的に統制 のとれた（しかもより安全な）スタイルの同期化を実現する同期化メカニズムで ある。モニタ・ロック（ミュテックス(mutex)とも呼ばれる）は、基本的には、 ある種のデータへの相互排他的アクセスを可能にするバイナリ・セマフォアであ る。条件変数は、プログラマが定義したある種のブール方程式がモニタのコンテ キスト内で真になるのを待ち、そのことを知らせるために使用することができる 。モニタ・ロックを保持するスレッドがある条件を待つ必要があるときは、モニ タ・ロックが手放され、そのスレッドはブロックされる。そのあとで、ロックを 保持する別のスレッドが条件が真であると通知すると、待ちに置かれていたスレ ッドはブロックが解除され、ロックを再獲得してから実行を続ける。スレッドは ある条件についてブロードキャスト・オペレーション(broadcast operation)を 行うこともでき、そのときはその条件を待っていたスレッドのすべてはブロック が解除される。条件待ちオペレーションで、スレッドが条件を待つ時間を制限す る任意のタイムアウトを設定することも可能である。 スケジューリング Machはマルチプロセッサ機能を備えているので、マルチプロセッサ環境でスレ ッドをスケジューリングすることができる。Machでは、プロセッサをグループ化 したプロセッサ・セットが定義されており、また、プロセッサ・セットと関連づ けることができるスケジューリング・ポリシが定義されている。Machには、タイ ムシェア (timeshare)と固定優先度(fixed priority)の、２つのスケジューリン グ・ポリシが用意されている。タイムシェア・ポリシは、スレッドによるCPU使 用の指数平均値(exponential average)に基づいている。このポリシは、スレッ ドとプロセッサの数に基づいて時間単位量を最適化することも試みている。固定 優先度ポリシは優先度を変更しないが、同じ優先度のスレッドでラウンドロビン ・スケジューリング(round-robin scheduling)を行う。スレッドはそのプロセッ サ・セットのデフォルト・スケジューリング・ポリシを使用することも、そのプ ロセッサ・セットで使用できるスケジューリング・ポリシのいずれかを明示的に 使用することもできる。プロセッサとスレッドには最大優先度を設定することが できる。Machでは、優先度値が低くなると、緊急度が大きくなる。 障害 Mach障害処理サービスの目的は、標準プロセッサ障害とユーザが定義したプロ セッサ障害の両方を処理する柔軟なメカニズムを提供することである。標準カー ネル機能であるスレッド、メッセージ、およびポートは障害処理メカニズムを提 供するために使用される。（Mach説明書では「例外」（exception）という用語 が使用されている個所で、本明細書では「障害」（fault）という用語が使用さ れている。本明細書でこのように用語を使い分けたのは、ハードウェア障害とC+ +言語の例外メカニズムとを区別するためである。）スレッドとタスクは、障害 ポート(fault port)をもっている。これらは継承ルールが異なり、その使い方が 若干異なっている。エラー処理はスレッド単位で行われることが期待され、デバ ッギングはタスク単位で取り扱われることが期待されている。タスクの障害ポー トは 親タスクから子タスクへ継承されるのに対し、スレッドの障害ポートは継承され ず、ハンドラがないことがデフォルトになっている。スレッドの障害ハンドラは タスクの障害ハンドラに優先している。スレッドが障害を引き起こすと、カーネ ルはスレッドをブロックし、障害メッセージを障害ポート経由でスレッドの障害 ハンドラへ送信する。ハンドラはメッセージを障害ポートから受け取るタスクで ある。メッセージは、障害、その障害を起こしたスレッドとタスクに関する情報 を含んでいる。ハンドラはその機能を障害のタイプに従って実行する。該当する 場合には、ハンドラは障害を起こしたスレッドの実行状態を取得し、変更するこ とができる。取り得るアクションとしては、障害をクリアすること、スレッドを 終了すること、障害をタスク・レベル・ハンドラへ引き渡すことがある。障害は タイプとデータによって識別される。Machでは、すべてのMachインプリメンテー ションでサポートされる、いくつかのマシン独立障害タイプが定義されている（ 例えば、不正アクセス、不正命令、ブレークポイントなど）。その他の障害タイ プはインプリメンテーション依存にすることができる（例えば、f-line、コプロ セッサ違反など）。 ホストとプロセッサ・セット Machでは、ホスト(host)という考え方を取り入れている。ホストとは、基本的 に、ホストがそこで実行されているコンピュータを抽象化したものである。種々 のオペレーションは、タスクがホストに対してもっている個々のポート権に応じ てホストで実行することができる。センシティブでない情報は、ホスト名ポート (host name port)に対して送信権を保持するタスクによって取得することができ る。そのような情報の例としては、カーネルのバージョンやシステム・クロック の値へのアクセス権を取得する権利がある。他の情報はほとんどすべてがセンシ ティブと扱われるので、その情報を取得または操作するには、よりハイレベルの 特権が必要である。このハイレベル特権は、タスクがホスト制御ポート(host co ntrol port)（ホスト特権ポート(host privilege port）とも呼ばれる）に対し て送信権を保持しているときは包含されている。この権利をもつと、タスクは カーネルに対して可能とされるほとんどすべてのことを行うことができ、そのた めに、IPCサービスがサポートしているシステムのセキュリティ面がバイパスさ れることになるので、この権利は非常に慎重に、しかも選択的にタスクに与えな ければならない。このハイレベル特権をもっていると種々のオペレーションを実 行することができる。そのようなオペレーションとしては、システム・クロック 設定値の変更、システムの総パフォーマンスおよび資源使用状況統計の取得、マ シンを再ブートすること、などがある。 また、Machには、プロセッサ(processor)とプロセッサ・セット（processor s et)という考え方も取り入れられている。これによると、タスクはそのスレッド をいつ、どのプロセッサで実行させるかを、より慎重に指定することができる。 プロセッサとプロセッサ・セットは、ホスト特権ポートを使用すると、列挙して 管理することができる。プロセッサはシステム内の特定のプロセッサを表し、プ ロセッサ・セットはプロセッサの集まりを表している。新プロセッサ・セットを 作成し、必要に応じてプロセッサを追加しあるいは除去するためのサービスが用 意されている。また、タスク全体または特定のスレッドをセットに割り当てるた めのサービスも用意されている。これらのサービスを通して、プログラマは、ア プリケーションを構成するスレッドとタスクをいつ実行させるかを制御すること ができる（粗粒制御）。これにより、プログラマは、ある種のスレッドをいつプ ロセッサ・セットで並列に実行させるかを指定することができる。これらの機能 を明示に使用しないタスクやスレッドに対しては、デフォルト割当てとしてシス テムのデフォルト・プロセッサ・セット(default processor set)が割り当てら れる。このプロセッサ・セットは、一般的に、他のセットで使用されていないシ ステム内のプロセッサを含んでいる。 セキュリティ Machは、上述したサービスのほかに、他のカテゴリのサービスを含んでいる場 合がある。例えば、Machはセキュリティに関係するサービスを含んでいる場合が ある。Machセキュリティ・サービスによれば、すべてのタスクはセキュリティ・ トークン (security token)をもっている。これはMachによって判読されないスカ ラー値になっている。ホスト・セキュリティ・ポート(host security port)と呼 ばれるポートがあり、これはブートストラップ・タスクに渡され、そこから信頼 できるセキュリティ・サーバへ受け渡される。タスクのセキュリティ・トークン は、ホスト・セキュリティ・ポートに対して送信権を所持しているタスクが設定 し、変更することができるが、タスクのセキュリティ・ポートの値を判断するた めには特別な許可は不要である（もちろん、タスクの制御ポートを保持している 場合は別である）。Mach IPCメッセージが受信された時点で、メッセージの送信 側のセキュリティ・トークンが、receive関数に対する出力パラメータの１つと して返される。ホスト・セキュリティ・ポートを保持するタスクはメッセージを 送信し、そのメッセージに別のセキュリティ・トークンを割り当てることができ るので、メッセージが別のタスクから送られてきたように見える。これらのサー ビスをシステムの上位層で使用して、様々なセキュリティの程度を実現すること ができる。 ラッパー・クラス・ライブラリ このセクションでは、Machマイクロカーネルから提供されるサービスのオブジ ェクト指向インタフェースについて、分野別に説明する。Machサービスへのこの オブジェクト指向インタフェースは、コード・ライブラリ110によって実現され たラッパー・クラス・ライブライ402を表している。ラッパー・クラス・ライブ ラリ402は、上述したように、スレッド・クラス404、タスク・クラス406、バー チャル・メモリ・クラス408、IPCクラス410、同期化クラス412、スケジューリン グ・クラス414、障害クラス416、およびマシン・クラス418を含んでいる。ラッ パー・クラス・ライブラリ402は、基礎となるオペレーティング・システム114か ら提供されるサービスに応じて、セキュリティ・クラス420などの追加のクラス を含んでいる場合もある。各分野は各クラスの目的と関数を詳しく説明している クラス図とテキストを使用して説明されている。選択したメソッドが示され、定 義されている（該当する場合には、メソッドのパラメータ・リス トも示されている）。従って、このセクションには、ラッパー・クラス・ライブ ラリ402のオペレーションの定義と説明が詳しく説明されている。ラッパー・ク ラス・ライブラリ402のメソッドのインプリメンテーションについては、別のセ クションで説明する。 クラス図は、クラス間の関係とカーディナリティ（cardinality）を表現する ための公知のBoochアイコンを用いて示されている。これらのBoochアイコンは便 宜上第17図に示されている。Boochアイコンは、前掲のGray Booch著「オブジェ クト指向設計とそのアプリケーション」に説明されている。ラッパー・クラス・ ライブラリ402は好ましくは、公知のC++プログラミング言語を使用して実現され ている。しかし、他のプログラミング言語を使用することも可能である。好まし くは、クラスの説明はSPI(System Programming Interface−システム・プログラ ミング・インタフェース)、API(Application Programming Interface−アプリケ ーション・プログラミング・インタフェース)、Internalおよび"Noose"メソッド に分類されており、当該コードを♯ifdefステートメントで囲んで（Nooseメソッ ドの場合はコメントで）示されている。SPIインタフェースは使用される特定コ ンピュータ・プラットフォームに特有のものである。ここでは、説明の便宜上、 ラッパー・クラス・ライブラリ402は、IBM MicroKernel（Machバージョン3.0に 準拠）またはコンパチブルに従って動作するコンピュータ・プラットフォームと 関連づけて示され、説明されている。この分野の専門家ならば理解されるように 、SPIクラスは、本明細書に開示されている教示事項に基づいて、他のコンピュ ータ・プラットフォームに合わせて変更することが可能である。 APIインタフェースは、システムが稼働するプラットフォームに関係なく、ラ ッパー・クラス・ライブラリ402に含まれている。Internalインタフェースは低 レベルのインプリメンテーションだけで使用されることを目的としている。Noos e メソッドが用意されているのは、ラッパー128と一緒に動作するアプリケーシ ョン130が、Mach114上で直接に動作するように書かれたアプリケーション134(ま たはサーバ)と通信できるようにするためであり、それだけである。Noose メソ ッドを使用すると、ラッパー128で設定された、意図するオブジェクト指向プロ グラミング・モデルの範囲外にあるように、生のMach機能をアクセス することができる。Nooseメソッドはあまり利用すべきではない。SPIとAPI（お そらくInternalも）クラスとメソッドがあれば、どうようなアプリケーション、 コンポーネント、またはサブシステムでも十分に実現することができる。 スレッド・クラス 第５図は、スレッド・クラス404とタスク・クラス406のクラス図501である。 スレッド・クラス404は、Mach114のタスキングとスレッディング機能とのオブジ ェクト指向インタフェースとなるものである。スレッド・クラス404のいくつか はハンドル(handle)クラス（その名前が示すとおり）であり、このことは対応す るカーネル・エンティティへの参照を表していることを意味する。ハンドル・ク ラスでのヌル・コンストラクタ(null constructor)は空のハンドル(empty handl e)オブジェクトを作成する。空のハンドル・オブジェクトは初期状態では、どの カーネル・エンティティにも対応していない。これは、ストリーミング、割当て 、またはコピー・オペレーションによって初期化しなければならない。空のハン ドルでメソッドをコールすると例外が引き起こされる。ハンドル・オブジェクト はいくつでもコピーできるが、各コピーは同じカーネル・エンティティを指して いる。ハンドル・オブジェクトを内部で参照カウントをとってあるので、カーネ ル・エンティティを表す最後のオブジェクトが壊されたときカーネル・エンティ ティを削除することができる。 TThreadHandleはシステム内のスレッド・エンティティを表す具象クラス(conc rete class)である。これには、スレッドを制御し、スレッドに関する情報を判 断するためのメソッドが用意されている。また、システムに新しいスレッドを作 る(spawn)ためのメカニズムも用意されている。制御オペレーションとしては、 キリング(killing−削除)、一時中止／再開、スレッドの死亡監視(death watch) などがある。TThreadHandleを構築してTThreadProgramオブジェクトに入れて渡 すと、新しいスレッドが現タスク上に作られる。新スレッドで最初に実行される コードはTThreadProgramオブジェクトのPrepare()とRun()メソッドである。TThr eadHandleを壊しても、それが表しているスレッドは壊されない。 TThreadHandleオブジェクトにはキャンセル・オペレーションもある。なお、各T ThreadHandleオブジェクトは、スレッドの制御ポートに対する送信権を含んでい る。この情報は、一般的には、インタフェースからエクスポートされないが、ポ ート権を含んでいるので、TThreadProgramがストリームできる対象のストリーム ・オブジェクトはTIPCMessageStreamだけである。他のTStreamオブジェクトに対 してストリームしようとすると、例外が引き起こされる。 TThreadHandleには、デバッガと実行時環境(runtime environment)で使用され るメソッドと、ラッパー128によって設定された環境の外で実行されるMachタス クとのやりとりをサポートするメソッドがいくつか用意されている。これらのメ ソッドには、スレッドの状態の取得と設定、別のタスク内に「空の」スレッドの 作成、スレッドの障害ポートの取得、スレッドの制御ポートへの権利の返却、ス レッド制御ポート送信権からのTThreadHandleハンドルの作成、などがある。 上述したように、ラッパー128は、アプリケーション130が動作するコンピュー ティング環境を設定する。簡略化のために、ラッパー128によって設定されるこ のコンピュータ環境をCEと呼ぶことにする。ラッパー128に対して、TThreadHand leは現タスク上にCE実行時(runtime)スレッドを作成する。スレッドは、TTaskHa ndleクラスまたはTTaskHandleサブクラスでCreateThreadメソッドを使用すると 、現タスクにではなく別のタスク上に作ることも可能である。（ただし、別のタ スクにスレッドを作成することは、一般的プログラミング・モデルとしては望ま しくない。）別のCEタスク上にCEタスクを作成するには、TCETaskHandle::Creat eThreadメソッドが使用される。そのために、実行すべきスレッドを記述してい るTThreadProgramにこのメソッドが渡される。非CEスレッド（つまり、ラッパー 128によって設定されたコンピューティング環境で実行されないスレッド）を作 成するには、CreateThreadメソッドがTTaskHandleの該当サブクラス（つまり、 他の非CEコンピューティング環境で実行するように作成されたTTaskHandleのサ ブクラス）で使用される。例えば、IBM OS2スレッドをOS2タスク上に作成するに は、TOS2TaskHandle::CreateThreadメソッドが使用できる。CEスレッドを非CEタ スクで実行することも、非CEスレッドをCEタスクで実 行することも不可能である。 TThreadHandleは、次のようなメソッドを含んでいる。 TThreadHandle(const TThreadProgram&copyThreadCode)：は、呼出し側タスク に新しいスレッドを作成する。TThreadProgramの内部コピーを作るが、これはス レッドが終了すると削除される。 TThreadHandle(TThreadProgram* adoptThreadCode)：は呼出し側タスクに新し いスレッドを作成する。adoptThreadCodeを採用するが、これはスレッドが終了 すると削除される。スレッドが所有していた資源も廃棄される。TThreadProgram のコピーは作られない。 TThreadHandle(EEexcution yourself)は呼出し側スレツドのためにスレッド・ ハンドルを作成する。 TStreamはTThreadHandleオブジェクトにストリーム・インされてTIPCMessageS treamに渡される。 CopyThreadSchedule()は、オブジェクトをスケジュールするために使用される Schedulingオブジェクト（例えば、TServerSchedule，TUIScheduleなど）を指す ポインタを返す。TThreadScheduleオブジェクト用にメモリを割り当てるが、こ れは呼出し側で廃棄する必要がある。 SetThreadSchedule(const TThreadSchedule& newSchedule)はスレツド内のス ケジューリング・オブジェクトをnewScheduleオブジェクトにセットする。これ より、スレッドをどのようにスケジュールするかを制御することができる。 GetScheduleState(TThreadHandle& theBlockedOnThread)を使用すると、この スレッドがブロックされているスレッド(theBlockedOnThread)の現状態を照会す ることができる。 CancelWaitAndPostException()constは、ブロックしているカーネル・コール をブロック解除(unblock)し、TKernelExceptionをスレッド(*this)に引き起こす 。 WaitForDeathOf()constは、スレッド(*this)が終了するまで、スレッド死亡(d eath)コールの監視を行う。CreateDeathInterest()はスレッド(*this)の死亡(de ath)に対して通知インタレスト(notification interest)を作成する。ス レッドの終了時に、指定されたTInterestは通知を受け取る。 TThreadProgramは、新スレッドを作成するために必要なすべての情報をカプセ ル化する抽象基底クラスである。これには、実行すべきコード、スケジューリン グ情報、およびスレッドのスタックが含まれる。これを使用するには、サブクラ ス化し、BeginメソッドとRunメソッドをオーバライドしたあとで、オブジェクト のインスタンスをTThreadHandleのコンストラクタに受け渡してスレッドを作成 しなければならない。Beginルーチンが用意されたのは、スタートアップ同期化 を容易にするためである。Beginは、TThreadHandleコンストラクタが完了する前 に新スレッドで実行される。RunルーチンはTThreadHandleコンストラクタが完了 したあと実行される。メソッドCopyThreadScheduleとGetStackSizeはデフォルト のスレッド・スケジュールとスタック・サイズを返す。デフォルトと異なる値を 得るには、これらのメソッドをオーバライドすれば、希望のスレッド・スケジュ ールおよび／またはスタック・サイズが返される。TThreadProgramは次のような メソッドを含んでいる。 TThreadProgram(const TText& taskDescription):TaskDescriptionからは、TT askHandle::GetTaskDescriptionメソッドを通してアクセスできるタスクのテキ スト記述が得られる。これは、オブジェクトがTTaskHandleコンストラクタに渡 されたときだけ効力をもっている。デフォルト・コンストラクタを代わりに使用 すれば、インタフェースはTTaskHandle::GetTaskDescriptionが返す固有名を合 成する。 GetStackSize()は、スレッド用にセットアップすべきスタックのサイズを返す 。「デフォルト」スタック・サイズが必要でなければ、このメソッドをオーバラ イドする。 GetStack(): スレッドのスタックをセットアップするために使用される。独自 のスタックを用意したい場合は、このメソッドをオーバライドする。 Run()は、スレッドで実行されるコードのエントリ・ポイント(entry point)を 表している。スレッドに実行させるコードを用意する場合は、このメソッドをオ ーバライドする。 タスク・クラス タスク・クラス406のクラス図は第５図に示されている。 TTaskHandleは、基本的Machタスクのすべての属性とオペレーションをカプセ ル化している具象基底クラス(concrete base class)である。これを使用すると 、システム上の任意のタスクを参照して制御することができる。しかし、TTaskH andleは実行時環境についてなにも知識をもっていないので、直接に使用してタ スクを作成することはできない。具体的な実行時知識をもつサブクラスを作成し て、タスクを作成できるようにする十分なプロトコルがプロテクト・メソッド(p rotected methods)を通して提供されるようになっている（下に示すTCETaskHand leはそのようなクラスの例である）。TTaskHandleオブジェクトは、IPCを通して のみストリーム化してTTPCMessageStreamsに出し入れして他のオブジェクトへ送 ることができ、これらはTCETaskHandleに関連するコレクション(collection)に 入って返される。TTaskHandleに関連するタスク制御オペレーションには、タス クの削除、タスクの一時中止と再開、タスクの死亡監視(death watch)などがあ る。通知メソッド(informational method)にはそのホストの取得、その登録ポー トの取得と設定、そのポートまたはバーチャル・メモリ領域の列挙、その障害ポ ートの取得、そのスレッドの取得などがある。TTaskHandleは、次のようなメソ ッドを含んでいる。 TTaskHandle(EEexecutionThread)は特定スレッドのタスク・ハンドルを作成す る。 Suspend()はタスク（つまり、タスクに含まれるすべてのスレッド）を一時中 止する。Resume()はタスク（つまり、タスクに含まれるすべてのスレッド）を再 開する。 Kill()はタスクを終了する。タスクに含まれるすべてのスレッドは終了する。 WaitForDeathOf()はタスクの死亡監視を行う。呼出し側スレッドはタスク(*th is)が終了するまでブロックしている。CreateDeathInterest()はタスクの死亡に 対して通知インタレストを作成する。TInterestオブジェクトに指定され ているスレッドはタスク(*this)が終了すると通知を受け取る。 AllocateMemory(size t howManyBytes,TMemorySurrogate& newRange)は、タス クのアドレス空間内の任意の個所からある範囲の（匿名）バーチャル・メモリを 割り当てる。必要とするサイズ（バイト数）はhowManyBytesに指定されている。 新しく割り当てられたメモリの開始アドレス（ページ境界合わせしたあとの）と 実際のサイズはnewRangeに入って返される。 AllocateReserveAddressMemory(const TMemorySurrogate& range，TMemorySur rogate& newRange)は、タスクのアドレス空間内の特定予約アドレスからある範 囲の（匿名）バーチャル・メモリを割り当てる。範囲引数は要求のアドレスとサ イズを指定している。newRangeは割り振られたメモリのページ境界合わせアドレ スとサイズを返す。 GetRemotePorts(TCollection<TRemotePortRightHandle>& thePortSet)は*this タスクのポート・リストを取得する。返されたCollectionの中のメモリの割当て を解除するのは呼出し側の責任である。 virtual void CreateFaultAssociationCollection(TCollection<FaultAssocia tion>& where)はこのタスク用に登録された障害ポートを返す。 TCETaskHandleはCE実行時システムと一緒に実行されるMachタスクを表してい るTTaskHandleのサブクラスである（すでに述べたように、CEはラッパー128によ って設定されたコンピューティング環境を表し、CEオブジェクト環境をセットア ップするために必要なすべての知識を具現化している）。これを使用すると、TT hreadProgramをそのコンストラクタに渡すことによって新しいタスクを作ること ができる。新タスクはシングル・スレッドと共に作成され、これはTECTaskHandl eコンストラクタに渡されたTThreadProgramオブジェクトによって記述されてい る。TCETaskHandleをTTaskHandleから作成できるようにするコンストラクタもあ る。非CE実行時タスクがTCETaskHandleでラップされていないことを確かめるた めに、このコンストラクタはCEローダ／ライブラリ・サーバ（つまり、CE環境で 動作しているローダ／ライブラリ・サーバ）に問い合わせて、ラップされるタス クがそこに登録されていることを確認する。これは（ユーザが 介入することなく）自動的に行われる。TCETaskHandleは次のようなメソッドを 含んでいる。 TECTaskHandle(const TThreadProgram& whatToRun)は新しいタスクと、特定コ ードを実行するスレッドとを作成する。新しいスレッドは'whatToRun'内のコー ドを実行する。 TCETaskHandle(EExecutionTask)は現在実行中のスレッドのタスクをラップす る。 TCETaskHandle(const TThreadProgram& whatToRun,const TOrderedCollection <TLibrarySearcher>& librarySearchers)は新しいタスクと、特定ライブラリ・ サーチを使用して特定コードを実行するスレッドを作成する。librarysearchers は名前を解決するために使用されるライブラリのリストを指定している。 TCETaskHandle(const TTaskHandle& aTask)は汎用タスク・オブジェクトからC Eタスク・オブジェクトを作成する。 AddLibrarySearcher(const TLibrarySearcher& newLibSearcher)はタスクのラ イブラリ・サーチャを追加する。ローダはnewLibrarySearcherを最初に使用して lib参照を解決する。つまり、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)をもっている。ここで注意すべきことは、メ モリ・クラスは実際のメモリ自体ではなく、メモリへの参照を含んでいることで ある。従って、メモリ・クラス・オブジェクトがコピーまたはストリーム化され るとき、オブジェクト内の参照だけがコピーされ、実際のメモリはコピーされな い。TMemorySurrogateクラスは、それが参照するメモリのコピーを行うための明 示のメソッドを含んでいる。 TMemorySurrogateは、バーチャル・アドレス空間内のある範囲の連続するメモ リを表すクラスである。これは、開始アドレスとサイズ（バイト数）をもってい る。TMemorySurrogateを使用すると、ある種のオペレーションが実行されるメモ リ範囲を指定することができる。これらは、タスクに関連するアドレス空間内の バーチャル・メモリを操作する、TTaskHandleのメソッドヘ引数として渡される のが普通である。このクラスは、特定のサイズをもつメモリ範囲を指定および／ または渡すために使用される。クラス自体はどのメモリも割り当てない。既存の メモリをカプセル化するだけである。このクラスで指定された実際のメモリ（引 数としてコンストラクタに）を渡すのは、呼出し側の責任である。このクラスは サブクラス化することはできない。 TChunkyMemoryは特定サイズのチャンク(chunk)でメモリを管理する抽象基底ク ラスである。メモリはチャンク（特定のchunkSizeの）単位で割り当てられるが 、それでもなお、ユーザにはメモリが一連のバイトとして見える。TChunkyMemor yは次のようなメソッドを含んでいる。 LocateChunk(size t where,TMemorySurrogate& theContainingRange)はチャン クのコレクションの中を調べて、メモリのアドレスとchunksizeをtheContaining Rangeに入れて返す。 CutBackTo(size t where)はカットして、"where"を収めているチャンクに戻す 。つまり、オフセットwhereにあるチャンクがリスト内の最後のチャンクとなる 。 AllocateMemoryChunk(TMemorySurrogate& theAllocateRange)はクライアント によってコールされて、メモリの新しいチャンクを必要に応じて割り当てる。割 り当てられた範囲を返す。 THeapChunkyMemoryはヒープ上のチャンク・メモリを管理する具象クラスであ る。 TVMChunkyMemoryはバーチャル・メモリを使用してチャンク・メモリを管理す る具象クラスである。 TMemoryRegionInfoはタスクのアドレス空間内のバーチャル・メモリ領域に関 して使用されるクラスである。メモリ属性情報（継承、保護など）を返す。また 、メモリの領域に関連するメモリ・オブジェクトへのアクセスと、メモリ領域に カプセル化されている実際のメモリ範囲へのアクセスを可能にする。TMemoryReg ionInfoの内側にネストされたものとして、任意のメモリ領域のすべてのメモリ 属性を定義するTMemoryAttributeBundleクラスがある。これは、すべてのメモリ 属性を取得／設定したとき（または変更を最小にしてメモリ属性を再使用したい とき）に使用すると便利である。TMemoryAttributeBundleはメモリ・オブジェク トをタスクのアドレス空間にマッピングすることを扱うためにクラスTTaskHandl eでも使用される。TMemoryRegionInfoは、次のようなメソッドを含んでいる。 EMemoryProtection｛kReadOnly,kReadWrite,kExecute｝はメモリの保護を特定 する。 EMemoryInheritance｛kDontInherit,kReadWriteInherit,kCopyInherit｝はメ モリの継承属性を特定する。 EMemoryBehavior｛kReferenceSequential,kReferenceReverseSequentail,kRef erenceRandom｝はメモリがどのような仕方で参照されるかを特定する。 EMemoryAttribute｛kCacheable,kMigrateable｝はメモリのマシン特有属性が どのような仕方で管理されるかを特定する。 EMemoryAdvice｛kWillUse,kWontUse｝はメモリがどのような使い方をされるか を特定する。 TMemoryObjectHandleはMachメモリ・オブジェクトの考え方を表している基底 クラスである。これは、バーチャル・メモリにマッピングできるデータの断片を 具現化している。TMemoryObjectHandlesをクライアントに提供するシステム・サ ーバは、ファイル、デバイス・パーティション(device partitions)などのメモ リ・オブジェクトをタイプ別に定義するために、TMemoryObjectHandleからサブ クラス化する。一般的バーチャル・メモリ・サービスのクライアントの場合は、 TMemoryObjectHandleと各種サブクラスの主要用途は、タスクのアドレス空間に マッピングできるデータに共通のタイプとプロトコルを提供することである。 TChunkyStreamは、メモリのチャンクによってバックされたランダム・アクセ ス・ストリームを具現化する具象クラス（TRandomAccessStreamから派生）であ る。チャンク・サイズは明示に指定することも、デフォルトを使用することも可 能である。チャンクを列挙することができる。このクラスはTMemoryクラスの共 通機能となるので、メモリを連続するものとして管理するオーバヘッドは発生し ない。TMemoryの他の機能が必要ならば、他のクラスの定義が可能である。 TContiguousMemorySystemは連続メモリ（クライアントが用意したもの）を使 用する具象クラスである。これはTRandomAccessStreamから派生しているので、 すべてのアクセス・オペレーション（Seek()など）はTContiguousMemoryStream オブジェクトに適用可能である。 プロセス間通信(IPC)クラス IPCクラス410はMach IPCメッセージの抽象化を表している。なお、すべてのメ ッセージング作用はメッセージ・クラスに対するものである。ポート権クラスは 基本的にメッセージをアドレスするためのものである。使用モデル(usage model)は好ましくは次のようになっている。TIPCMessageStreamはインスタンス 化(instantiate−インスタンス生成)され、オブジェクトはそこに対してストリ ームされ、TIPCMessageStream::Sendメソッドがコールされ、宛先送信権を表し ているオブジェクトが引数として渡される。メッセージを受信するには、TIPCMe ssageStreamがインスタンス化され、そのReceiveメソッドがコールされ、受信権 オブジェクトが引数として渡される。Receiveから戻ったとき、オブジェクトをT IPCMessageStreamオブジェクトからストリームすることができる。なお、TIPCMe ssageStreamオブジェクトは再使用可能(reusable)である。以下では、IPCメッセ ージ・クラスのクラス図702を示している第７図、IPCアウトオブライン・メモリ 領域クラスのクラス図802を示している第８図、およびIPCポート権クラスのクラ ス図902を示している第９図を参照して、IPC410について詳しく説明する。 メッセージ・クラス MIPCMessageは、Mach IPCメッセージを表している抽象基底クラスである。こ れは、ヘッダのフィールド、後処理配列(disposition array)、およびポートと アウトオブライン・メモリ配列をセットアップするためのすべてのメソッドを提 供する。また、メッセージ送受信に関するプロトコル全体も収めている。これは 子クラスに対する基本的プロトコルとなってインライン・メッセージ・データを セットアップする。クラスTIPCMessageStreamとTIPCPrimitiveMessageはこのク ラスから派生し、データをメッセージに追加するための公開(public)メソッドを 提供する。MIPCMessageは次のようなメソッドを含んでいる。 GetReplyPort(TPortSendSideHandle& replyPort)は受信側だけで有効である。 メッセージと一緒に送信されていれば、応答ポート・オブジェクトを返す。これ はメッセージが受信されたあと、これが初めてコールされたときだけ返される。 他の場合は、偽(FALSE)が返される。 TSecurityToken GetSenderSecurityToken()は受信側だけで有効である。この メッセージを送信したタスクのセキュリティ・トークンを返す。 SetSenderSecurityToken(const TSecurityToken& impostorSecurityToken,con st TPortSendRight& hostSecurityPort)は送信側だけで有効である。メッセージ が次回に送信されるとき、実際に送信を行うタスクのそれではなく、指定された セキュリティ・トークンを搬送する。次の送信のときだけ効力をもち、そのあと 実際の送信側のセキュリティ・トークン値に戻る。 IPCメッセージを送受信するためのメソッド（なおこれらのメソッドはすべて 任意のTTimeタイムアウト値をもっている。タイムアウトが必要でなければ、kPo sitiveInfinityを指定する。これらのメソッドはいずれも、msgヘッダ中の応答 ポートの既存値を置き換える。応答ポートの指定を可能にするこれらのメソッド では、応答ポート権の後処理はポート権自体と一緒に、MIPCMessage::TReplyPor tDispositionオブジェクトを通して渡される。後処理状態は送信が持続している 間だけ有効であるので、これが応答ポートをセットする唯一の方法である。後処 理がMOVEであるポート権のオブジェクトは、送信が行われると無効になる。）： Send(const TPortSendSideHandle& destinationPort,const TTime& timeout=k PositiveInfinity)は片方向の非同期送信である。 Send(const TPortSendSideHandle& destinationPort,const TReplyDispositio n& replyPort,const TTime& timeout=kPositiveInfinity)は、send(-once)応答 ポートが指定された非同期送信である。 Receive(const TPortReceiveSideHandle& sourcePort,const TTime& timeout= kPositiveInfinity)は「ブロックする」受信である。 SendAndReceive(const TPortSendSideHandle& sendPort,const TPortReceiveS ideHandle& receivePort,const TTime& timeout=kPositiveInfinity)はメッセー ジを送信し、ブロックして応答を受信する（応答ポートはreceivePortから作ら れた一回送信権である）。 SendAndReceive(const TPortSendSideHandle& sendPort,const TPortReceiveS ideHandle& receivePort,MIPCMessage& receiveMsg,const TTime& timeout=kPos itiveInfinity)はメッセージを送信し、ブロックして応答を受信する（応答ポー トはreceivePortから作られた一回送信権である）。受信されたメッセージは重 ね書きを防止するために新しいメッセージ・オブジェクトに入れられる。 ReplyAndReceive(const TPortSentSideHandle& replyToPort,const TPortRece iveSideHandle& receivePort,const TTime& timeout=kPositiveInfinity)：応答 を送り返し、ブロックして新しいメッセージを受信する。 ReplyAndReceive(const TPortSendSideHandle& replyToPort,const TPortRece iveSideHandle& receivePort,MIPCMessage& receiveMsg,const TTime& timeout= kPositiveInfinity)は応答を送り返し、中断して新しいメッセージを受信する。 ヘッダのポート権フィールドを取得／設定するためのサブクラスのメソッド（ リモート・ポートとローカル・ポート：SEND側では、REMOTE PORTは宛先ポート を指定し、LOCAL PORTは応答ポートを指定する。RECEIVE側では、REMOTE PORTは 応答ポート（応答すべき相手ポート）を指定し、LOCAL PORTは応答を送ったポー トを指定する。ポートが送信された（送信すべき）方法はDispositionに入って 返される。これは次の値をとることができる。 MACH MSG TYPE (MOVE RECEIVE,MOVE SEND,MOV SEND ONCE,COPY SEND,MAKE SEND ，MAKE SEND ONCE}) GetRemotePort: リモート・ポート権を受け渡し、後処理を指定する。 PORT RIGHTメソッドは次のとおりである。 MovePortRightDescriptor: 送信側はポート権を宛先へ譲渡する。Send、Send Once、およびReceive権で有効である。 CopyPortSendRightDescriptor: 送信側は宛先で送信権のコピーを作成する。 MakePortSendRightDescriptor: 新しい送信権が宛先で作成される。 MakePortSendOnceRightDescriptor: 新しい一回送信権が宛先で作成される。 TIPCMessageStreamはストリーム・ベースのIPCメッセージを抽象化したもので ある具象クラスである。これは、IPCオペレーションで使用することが望ましい クラスである。これはMIPCMessageDescriptorおよびTStreamから派生している。 メッセージを送信するには、TIPCMessageStreamのユーザは送信すべきデータを ストリーム・インする。このデータには、ポート権(TPortRightHandleの派生物) 、アウトオブライン・メモリ領域(TOutOfLineMemorySurrogate)、ポート権配列( TPortRightHandleArray)、これらのいずれかまたはすべてを収めているオブジェ クト、および必要とする他のオブジェクトまたはデータ・タイプが含まれる。TI PCMessageStreamは、メッセージ・ヘッダ内のポート権、ポート権配列、および アウトオブライン・メモリのために該当のデータ構造を自動的にセットアップし 、プレースホルダ(place holder)をストリームに入れるので、これらのエレメン トはメッセージからストリーム・アウトされてストリーム内の該当場所に置かれ ることになる。データがストリーム・インされると、メッセージはSendメソッド を使用して送信され、該当の宛先ポート権(TPortSenderHandle)と、任意的に、 応答ポートを提供する。メッセージを受信するには、Receiveメソッドがコール され、そこから受信されるポートの受信権(TPortReceiveHandle)を提供する。受 信したばかりのデータはTIPCMessageStreamからストリーム・アウトすることが できる。 TIPCMessageStreamは、send/receive結合オペレーションを行うための２つの メソッドも提供する。これらのメソッドは、共通に使用されるメッセージ伝送セ マンティクスを提供すること（およびMachマイクロカーネルで高速パス(fast-pa th)を利用すること）を目的としている。SendAndReceiveはクライアント側で同 期スタイルsendを行い、そのあとreceiveでブロックして応答メッセージをピッ クアップする。ReplyAndReceiveはサーバ側で（おそらく）応答メッセージのsen dを行い、その直後にreceiveでブロックして次の要求を待機する。どちらのコー ルの場合も、宛先ポートと受信ポートの指定が必要である。さらに、SendAndRec eiveメソッドは提供された受信権から該当の一回送信権を自動的に作 成し、それを応答ポートとして受け渡す。 TIPCPrimitiveMessageはMIPCMessageから派生し、Machメッセージ・システム とのより基本的な低レベル・インタフェースとなる具象クラスである。データは メッセージ・ヘッダとボディとの間でgetコールとsetコールを通して受け渡しさ れる。ストリーミング機能はない。これは、Mach IPCメッセージを表す具象クラ スである。インライン・データはTMessageSurrogateに入れて渡すことによりメ ッセージに加えられる。ポート権、配列、およびOOLdataは該当のメソッドを使 用して明示的に追加し抽出しなければならない。 TOutOfLineMemorySurrogateはIPCメッセージに組み入れられるアウトオブライ ン・メモリ範囲を表している。これはそのインプリメンテーションでTMemorySur rogateを使用し、TMemorySurrogateにすでに入つているstartAddressとlength情 報に後処理情報だけを追加する。このクラスは、メッセージの送信時に使用され る後処理情報を含んでいることを除けば、TMemorySurrogateと同じであり、範囲 に関連する記憶装置を表すことができる。このクラスは、ストリーミング演算子 、範囲をget/setするメソッド、および後処理情報をset/getするメソッドを含ん でいる。 ポート権 以下に説明するクラスは、Machポート権の有効なタイプすべてを表している。 これらのクラスはすべて、以下に説明する一般的作用(general behavior)を共有 する。一般的に、ポート権オブジェクトがインスタンス化されると、その権利の カーネルの参照カウントをインクリメントし、ポート権オブジェクトが壊される と、カーネルのポート権参照カウントをデクリメントする。なお、ポート権オブ ジェクトは「実」(real)カーネル・ポート権エンティティのハンドル(handle)で ある。これらはコピーが可能であり、その場合は、２つのオブジェクトが同じカ ーネル・ポート権エンティティを参照することになる。これらは内部で参照カウ ントがとられるで、あるポート権を参照するすべてのオブジェクトが削除される と、カーネルのポート権参照カウントはデクリメントされる。あるポート権が デッド名(dead name)になったとき（つまり、それが属していたポートが壊され たとき）、それを表すオブジェクトでメソッドを使用しようとすると、例外が引 き起こされる（参照カウントをセットするといったオペレーションはデッド名で も有効であるので、これらのオペレーションは除く）。 TPortRightHandleは、ポート権の考え方を表す抽象基底クラスである。これは 、ポート名の取得、デッド名通知の要求、ポート権がデッド名であるかどうかを 確かめるテストといった、各タイプのポート権に共通するプロトコル全体を収め ている。（ポート名はmuch port name t typeとして返され、オブジェクト・ラ ッパーを使用して書かれていないMachサーバとやりとりする手段となる。）また 、これは共通スーパクラス(common super class)ともなるので、すべてのタイプ のポートを表す汎用タイプを多態的に渡すことができる。TPortSenderHandleとT PortReceiverHandleはこれらのクラスから派生している。このクラスはストリー ミング・サポートのメソッド（このクラスとこれを含んでいるクラスは、TIPCMe ssageStreamクラスにだけストリーム・インまたはストリーム・アウトすること ができる。他のSTreamにストリーム・イン使用とすると、実行時に例外が引き起 こされる）、Getters/Setters、および通知を要求するメソッド（これは通知が 送られる一回送信権を提供しなければならない。受信権を渡す（参照によって） ことにより一回送信権をMAKE（作成）し、一回送信権をADOPTING（採用）するこ とにより一回送信権をMOVE（移動）する）を含んでいる。 TPortSenderHandleは、IPCメッセージを送信できるポート権を表している抽象 クラスである。例えば、これは、MIPCMessage::Sendが宛先ポートと応答ポート として受け取るタイプである。クラスTPortSendRightHandleとTPortSendOnceRig htHandleはこのクラスから派生している。このクラスはストリーミング・サポー トのメソッドとGetters/Settersとを含んでいる。 TPortSendRightHandleはポート送信権を表している。これは、送信権で実行で きるすべての代表的オペレーションをサポートしている。これは有効なTPortRec eiveRightHandleまたはTPortSendRightHandleをコンストラクタに渡すことによ り、あるいはそれをTIPCMessageStreamからストリーム・アウトすることにより 作成される。このクラスは、カーネル参照カウントに影響しないで空の TPortSendRightHandleオブジェクトを作成するメソッド、新しい送信権を現タス クに作成するコンストラクタ、ストリーミング・サポートのメソッド、およびGe tters/Settersを含んでいる。 TPortSendOnceRightHandleはポート一回送信権を表している。これは、一回送 信権で実行できるすべての代表的オペレーションをサポートしている。これは有 効なTPortReceiveRightHandleをコンストラクタに渡すことにより、あるいはそ れをTIPCMessageStreamからストリーム・アウトすることにより作成される。メ ッセージがこのクラスのオブジェクトへ送られると、一回送信権は無効になるの で、そのあとでこのオブジェクトへ送信しようとすると例外が引き起こされる。 さらに、このオブジェクトに無効のマークが付けられるので、このオブジェクト のメソッドを使用しようとすると、例外が引き起こされる（当然のことながら、 オブジェクトを初期化するメソッドは除く）。このクラスは、カーネル参照カウ ントに影響しないでTPortSendOnceRightHandleオブジェクトを作成するコンスト ラクタ、新しいSend Onceオブジェクトを現タスクに作成するコンストラクタ、 ストリーミング・サポートのメソッド、およびGetters/Settersを含んでいる。 TPortReceiveHandleは、IPCメッセージをそこから受信できるポート権を表し ている抽象クラスである。例えば、これはMIPCMessage::Receiveがそこから受信 するポートとして受け取るタイプである。クラスTPortRightReceiveHandleとTPo rtSetHandleはこのクラスから派生している。このクラスはストリーミング・サ ポートのメソッドとGetters/Settersを含んでいる。 TPortReceiveRightHandleはポート受信権を表している。これは、受信権で実 行できるすべての代表的オペレーションを表している。オペレーションとしては 送信側が残っていないとの通知の要求、ポートの最大メッセージ・サイズとキュ ー長さの設定と取得、その送信カウントの取得と設定などがある。TPortReceive RightHandleがインスタンス化されると（ヌルまたはコピー・コンストラクタに よる場合を除く）、ポートと受信権が作成される。コピー・コンストラクタは同 じ受信権を参照する別のオブジェクト(別名：alias)を作成する。これらのオブ ジェクトは内部で参照カウントがとられ、特定の受信権を参照する 最後のオブジェクトが壊されると、それが表している受信権（およびポート）も 壊されるので、そのポートに対する既存の権利はすべてデッド名になる。このク ラスはポート受信権を表している具象クラスである。定義により、実際のカーネ ル・ポート・エンティティは受信権が作成されると作成され、受信権が壊される と壊される。このクラスはハンドルであるので、受信権の作成と破壊は、必ずし もTPortReceiveRightHandleの作成と削除に結び付いているとは限らない。たと えば、デフォルト・コンストラクタは実際には受信権を作成しないで、空のオブ ジェクトだけを作成する。このクラスは、ポートを作成することなく、あるいは カーネル参照カウントに影響することなくTPortReceiveRightHandleオブジェク トを作成するコンストラクタ、新しい受信権とポートを作成するコンストラクタ 、未初期化オブジェクトを有効にするメソッド、プロセス内に受信権（従って、 ポートも）の作成、ストリーミング・サポート、受信権／ポート操作のメソッド 、Getters/Setters、および通知を要求するメソッドを含んでいる。 TPortSetHandleはポート・セットを表している。これはポート・セットに含ま れる受信権を表すTPortReceiveRightHandleオブジェクトを追加、除去、および 列挙するメソッド、その送信カウントを取得し設定するメソッドなどを含んでい る。TPortSetHandleがデフォルト・コンストラクタを使用してインスタンス化さ れていると、ポート・セットが作成される。コピー・コンスタクタを使用してイ ンスタンス化されていれば、同じポート・セットに対して別名(alias)が作成さ れる。特定のポート・セットを表す最後のオブジェクトが削除されると、そのポ ート・セットが壊される。このクラスはストリーム化することはできない。 TPortRightHandleArrayは、IPCメッセージでアウトオブライン記述子として送 信できるポート権の配列を表す具象クラスである。これは、どの種類のポート権 でも含むことができるので、ポート権の後処理（つまり、ポート権をどのような 方法でターゲット・タスクへ転送するか）は、配列内の各ポート権について指定 される。このクラスは、IPCメッセージでアウトオブライン記述として送信でき る（ポート権およびアウトオブライン・メモリと一緒に）ポート権の配列を実現 する。このクラスは、ストリーミング・サポートのメソッド、エレメント（要素 ）を配列に追加するメソッド(SEND SIDE)、およびエレメントを配列から除去 するメソッド(RECEIVE SIDE)を含んでいる。 TRemotePortRightHandleは、別のタスク内のポート権を参照するために使用さ れる具象クラスである。これは通常のポート権メソッドの大部分を含んでいない が、これは、これらのタイプの関数を実行するために使用されるのではなく、リ モート・ポート権の名前またはハンドルとして働くことだけを目的としているた めである。このクラスを構築しても、ポート権は作成されない。別のタスクにす でに存在するポート権を表すだけである。 待ちグループ MWaitableとTWaitGroupは、メッセージ・ディスパッチングの機能をもち、２ 種類以上のメッセージ・ソースを同時に待つことができるようにするクラスであ る。TWaitGroupは、MWaitableから派生したオブジェクトのコレクションをセッ トアップして、スレッドがWaitメソッドを使用してMWaitableオブジェクトのど れからでもメッセージを受信できるようにするクラスである。これは、受信した メッセージを自動的にディスパッチングする機能も備えている。Multi-Wait Ope rationsはメッセージを受信するためにタスクによって繰返しコールされる。こ れらはマルチスレッドに対して安全に保護されているので、２つ以上のスレッド がメッセージにサービスすることが可能である。このクラスはTWaitGroupのメン バを操作するメソッドを含んでいる。例えば、GetListOfWaitablesはこのグルー プ内のMWaitablesのリストを返す。MWaitableはポートを内部ハンドラ・メソッ ド(HandlerIPCMessage)と関連づける抽象基底クラスである。これは、受信権と 受信権をベースとする他のクラスをTWaitGroupクラスを通して収集して１つにま とめる働きをする共通基底クラスでもある。 TWaitablePortReceiveRightHandleは、TPortReceiveRightHandleとMWaitable の両方から派生したコンビニエンス(convenience)クラスである。これは抽象基 底クラスであり、そのサブクラスをTWaitGroupに追加すると、他のMWaitableサ ブクラスとの間でMachメッセージIPCのMulti-Waitとディスパッチングを行うこ とができる。 同期化クラス 第10図は、Machの同期化サービスを呼び出すために使用される同期化クラス41 2を示すクラス図1002である。上述したように、同期化クラス412はセマフォアト とモニタと条件を採用している。TSemaphoreは、カウンティング・セマフォア(c ounting semaphore)の一般サービスを提供するクラスである。セマフォアを獲得 するとき、他のいずれかのタスクがそのセマフォアをすでに獲得していると、呼 出し側スレッドはブロックする（例外は引き起こされない）。しかし、セマフォ アがなんらかの理由で無効であれば、例外が引き起こされる。このクラスは、次 のようなメソッドを含んでいる。 Acquire:セマフォアを排他モードで獲得する。 Acquire(const TTime& maximumWait):セマフォアをタイムアウト付の排他モー ドで獲得する。 AcquireShared():セマフォアを共有モードで獲得する。 AcquireShared(const TTime& maximumWait):セマフォアをタイムアウト付の共 有モードで獲得する。 Release():以前に獲得したセマフォアを解放する。 AnyThreadsWaiting():セマフォアが現在スレッドをその獲得待ちに置いていれ ば真(true)を返す。 TLocalSemaphoreは、排他モードまたは共有モードで獲得できるカウンティン グ・セマフォアを表すクラスである。主要オペレーションは獲得と解放である。 オプションのタイムアウト値を獲得オペレーションで指定すると、必要ならば待 ちで消費する時間を制限することができる。このクラスは「ローカル」セマフォ アを実現するが、使用できるのはタスク（アドレス空間）内だけであり、回復セ マンチツクス(recoverysemantics)はない。 TRecoverableSemaphoreHandleはTLocalSemaphoreと同じ作用をするが、セマフ ォアが「回復可能」であるとの追加の属性をもつセマフォアを表すクラスである 。回復可能とは、セマフォアを保持するスレッドが異常終了したとき、カウント が調整され、待ちに置かれていたスレッドが正しくブロック解除(unblock)さ れることである。このような各スレッドで例外が引き起こされ、セマフォアが回 復されたが、関連のユーザ・データの保全性が壊れた疑いがあることを知らせる 。なお、セマフォアを共有モードで獲得していたスレッドが異常終了したときは 、関連のデータは読取り専用モードだけでアクセスされたはずであり、まだ整合 状態にあるはずであるので、他のスレッドで例外を引き起こす必要はない。この クラスは次のようなメソッドを含んでいる。 GetCurrentHolders:セマフォアを保持している現スレッドのコレクションを返 す。 SetRecovered: セマフォアの状態を「回復(recovered)」にセットし、以前の 「壊れた(damaged)」状態を除去する。 Destroy:回復可能セマフォアをシステムから除去する。 TMonitorEntryはモニタと関連づけられたロック(mutexと呼ばれることもある) を表すクラスである。実際には、このクラスのコンストラクタによってモニタ・ ロックが獲得され、ローカル・スコープから出ると（これによりデストラクタが コールされる）モニタ・ロックが解放される。別のタスクがすでにモニタに入っ ていば、モニタに入ろうとするスレッドは、その前のスレッドがモニタから出る までTMonitorEntryコンストラクタでブロックされる。このクラスは演算子newと deleteを含んでおり、これらは非公開(private)であるので、TMonitorEntryはス タック上にだけ割り振られ、スコープに入ったり出たりすると、自動的に入った り出たりする（および関連のモニタ・ロックが獲得され解放される）。 TMonitorConditionはあるモニタと関連づけられた条件変数(condition variab le)を表すクラスである。主要オペレーションは待ち、通知、およびブロードキ ャストである。待ちオペレーションが行われると、現スレッドは条件が通知され るまで待ちに置かれ、スレッドがブロックされている間に、モニタ・ロックが解 放される。通知とブロードキャストはモニタ内部で実行中のスレッドによてコー ルされ、通知側（またはブロードキャスト側）スレッドがモニタから出たとき、 条件待ちに置かれていたスレッドの１つまたはすべてをブロック解除すべきこと を通知する。待ちに置かれたスレッドがブロック解除されると、モニ タ・ロックの再獲得を試み（ブロードキャストの場合は一度に１スレッド）、そ の時点でモニタでの実行を再開する。オプションのタイムアウト値を指定すると 、条件待ちに置かれる時間を制限することができる。構築と破壊を除き、TMonit orConditionのすべてのメソッドは、モニタ内からのみコールしなければならな い。 TMonitorLockは、モニタのロックを表すクラスである。これはTMonitorEntry とTMonitorConditionのコンスタラクタに渡され、どのモニタを獲得しようとし ているか、あるいは条件がどのモニタと関連づけられるかを通知する。 スケジューリング・クラス 第11図はスケジューリング・クラス414をクラス図1102であり、Machのスケジ ューリング・クラスを呼び出すために使用されるものである。 TThreadScheduleは、スレッドのスケジューリング作用を具現化する具象基底 クラスである。これはスレッドの実際の優先度、デフォルト優先度および最大優 先度を定義している。優先度値が低くなると、緊急度が大きくなる。各プロセッ サ・セットは使用可能になっているTThreadSchedulesとデフォルトのもののコレ クションをもっている。スレッドには、そのスレッドが実行されているプロセッ サ・セットで使用可能になっている、どのTThreadScheduleでも割り当てること が可能である。優先度はTThreadScheduleで定義された最大値にセットアップす ることが可能であるが、この機能を使用することは望ましくない。具体的スケジ ューリング・クラス(TIdleSchedule、TServerScheduleなど)はこのクラスを基底 として使用すると使用可能になる。しかし（このクラスには純粋仮想関数がない ので）、派生クラスは必要ならば、自由にこのクラスのオブジェクトを作成する ことができる（しかし、そのようにしないで済むであろう）。TThreadSchedule オブジェクト（多態を使用する）はスレッドのスケジューリング・ポリシを指定 するために使用される。以下に説明するサブクラスは該当の優先度と正しい範囲 を判断するために使用されるものである。 TIdleThreadScheduleは、システムがアイドル状態にあるとき実行させるス レッドのためのTThreadScheduleの具象サブクラスである。これらは、実行でき るものが他にシステムにないときだけ実行される。このカテゴリは、一般に、ア イドル・タイミング、保守、または診断スレッドのために使用される。 TServerScheduleは、サーバ・スレッドのためのTThreadScheduleの具象サブク ラスである。サーバ・スレッドは応答性が高くなければならない。これらは短時 間に実行されたあと、中断することが予想される。かなりの時間がかかるサービ スについては、異種のTThreadSchedule(TSupportSchedule)をもつヘルパ・タス ク(helper task)を使用すべきである。 TUserInterfaceScheduleは、応答性があって、アプリケーションのヒューマン ・インタフェースを扱うアプリケーション・タスクのためのTThreadScheduleの 具象サブクラスである。これらは短時間に実行されたあと、次のやりとりまでブ ロックするのが代表的である。 TApplicationScheduleは、アプリケーションの長い実行部分をサポートするス レッドで使用されるクラスである。このようなスレッドは実行時間がかなり長く なる。アプリケーションまたはウィンドウがアクティベートされると、関連タス ク内のスレッドは緊急度が大きくなるのでスレッドは応答性が高くなる。 TPseudoRealTimeThreadScheduleは、範囲内のレベルをセットすることにより 、タスクが固定優先度クラスで相対的緊急度を指定できるようにするクラスであ る。タスク・スケジュールは、許容されるレベルの数とデフォルト・ベース・レ ベルをイクスポートする。値がクラス範囲を超えるようなレベルが要求されると 、例外が引き起こされる。このクラスは次のようなメソッドを含んでいる。 SetLevel(PriorityLevelstheLevel):タスクのレベルをセットする。数が低く なると、緊急度が大きくなる。 ReturnNumberOfLevels(): このスケジューリング・オブジェクトの緊急度レベ ルの数を返す。 ReturnDefaultLevel(): このスケジューリング・オブジェクトのデフォルト緊 急度レベルを返す。 障害クラス 第12図、第13図、第14図、および第15図は障害クラス416のクラス図1202、図1 220、図1302、図1402、および図1502を示しており、これらのクラスはMachの障 害サービスを呼び出すために使用される。障害メッセージ（例えば、TIPCIdenti tyFaultMessage、TIPCIdentityFaultMessageなど）を表すクラスの場合は、各メ ッセージ・タイプごとにシングル・ポートを専用化する必要がある。つまり、障 害処理のために使用されるどのポートでも１つのタイプのメッセージだけが受信 されるようにしなければならない。好ましくは、障害クラス416は、オペレーテ ィング・システムがそこで実行される各プロセッサ106ごとにプロセッサ特有の クラス群を含んでいる。これとは別に、障害クラス414は、一般的にマルチプル ・プロセッサに適用される汎用クラスを含むことも可能である。本明細書には、 Motorola 68000特有のクラスが示されているが、これらは例示であって、これに 限定されるものではない。この分野の専門家ならば理解されるように、本明細書 に開示されている教示事項に基づいて、他のプロセッサ用にプロセッサ特有のク ラスを生成することも可能である。 TFaultTypeは障害を表す抽象基底クラスである。これをサブクラス化すると、 プロセッサ固有の障害値を得ることができる。これは障害をプロセッサと障害ID 別に指定する。以下に説明する３つのクラスはTFaultTypeのサブクラスである。 TMC680X0FaultTypeはMotorola 68Kプロセッサでの障害タイプを表している。 これは取り得る68Kタイプ値とCPU記述子を指定する。 TMC680X0BadAccessFaultTypeはMotorola 68Kプロセッサでの不正アクセス・タ イプを表している。 TMC680X0AddressFaultTypeはMotorola 68Kプロセッサでのアドレス・タイプ・ エラーを表している。 TFaultDesignationは、宛先、障害メッセージのフォーマット、タスクまたは スレッドで障害が起こってメッセージが送られるときの障害のタイプをカプセル 化しているクラスである。このクラスを使用すると、特定の障害タイプで要求さ れたタイプの障害メッセージを、送信権で指定されたポートへ送ることをタスク またはスレッド単位で指定することができる。 TFaultTypeSetは一組の障害タイプをカプセル化している。 TFaultDataは、プロセッサ状態のほかにカーネルから提供される障害データを カプセル化するクラスである。どの障害にも障害データがあるとは限らない。障 害データは障害メッセージに入れられ、スレッド状態から得ることができる。 TIPCFaultMessageは、障害が起こったスレッドに代わってカーネルから送られ てきた障害メッセージをカプセル化するクラスである。これは障害を受け取って それに応答するために使用される。障害メッセージと一緒に送られる可能性のあ る３種類のデータ用に３つのクラス（下述する）が用意されている。メッセージ には障害を起こしたタスクとスレッドのIDまたは障害を起こしたスレッドの状態 、あるいは両方の情報セットを含めることができる。 TIPCIdentityFaultMessageは、障害を起こしたスレッドのIDを含んでいる障害メ ッセージをカプセル化する。これは障害を受け取ってそれに応答するために使用 される。TIPCStateFaultMessageは、障害を起こしたスレッドのスレッド状態を 含んでいる障害メッセージをカプセル化する。これは障害を受け取ってそれに応 答するために使用される。TIPCStateAndIdentityFaultMessageは、障害を起こし たスレッドのスレッド状態とIDを含んでいる障害メッセージをカプセル化する。 これは障害を受け取ってそれに応答するために使用される。 TThreadStateはスレッドのCPU状態を表す抽象クラスである。サブクラスは実 際にはプロセッサ特有のフォームを定義している。クラスには情報はない。作業 はすべて派生クラスで行われる。CPU状態の照会はすべてTMC680X0Stateポインタ を返すが、このポインタは実行時に正しい派生クラス・オブジェクトにキャスト (cast)する必要がある。派生クラスは第12図、第13図、第14図および第15図に示 すサブクラスの多くがMotorola 68xxxプロセッサ系列に依存しているように、特 定のプロセッサに特有のものである。このようなサブクラスとしてはTMC680X0St ateがあり、これはスレッドの680x0 CPU状態を表す具象クラスである。他の例と しては、すべての68K状態で使用可能なCPU状態をカプセル化するTMC680X0CPUSta teと、すべての68K状態で使用可能な68K障害状態をカプセル化 するTMC680X0CPUFaultStateとがある。 ホストとプロセッサ・セット・クラス 第16図はマシン・クラス418を示すクラス図1602であり、これらのクラスはホ ストとプロセッサ・セット・クラスとも呼ばれる。マシン・クラス418はMachの マシンとマルチプロセッサ・サポートに関係するサービスを呼び出すために使用 される。 TPrivilegedHostHandleは、カーネルのホスト・オブジェクトに対する特権ポ ートを具現化する具象クラスである。特権ホスト・ポートはMachのプロセッサ管 理のルート(root)である。特権ホスト・ポートの所持者はシステム上のどのポー トへもアクセスすることができる。カーネルで行われる基本的特権メカニズムは 特権オペレーションを制御ポートを保持するタスクに制限することである。従っ て、システムの保全性はこの特権ホスト・ポートを保持することに左右される。 このクラスのオブジェクトは、ブート情報とホスト統計を取得すること、システ ムを再ブートすること、特権プロセッサ・セットを列挙すること、非CEエンティ ティと通信すること、プロセッサを列挙することができる。 THostHandleは、カーネルのホスト・オブジェクトに対する名前ポートを具現 化する非特権具象クラスである。このクラスのオブジェクトはある種のホスト情 報を返し、デフォルト・プロセッサ・セットを返すことができる。このクラスの オブジェクトは、ホストから情報（カーネル・バージョン、CPUの最大数、メモ リ・サイズ、CPUタイプなど）を得るとき使用すると便利であるが、そのために ホストが壊れることはない。ユーザには、高度の特権TPrivilegedHostHandleオ ブジェクトではなく、このクラスのオブジェクトがアクセスできるようにしてお くべきである。 TProcessorHandleはプロセッサを表す具象クラスである。プロセッサを始動さ せ、終了させること、プロセッサをTPrivilegedProcessorSetHandleに追加する こと、プロセッサが情報を返すこと、インプリメンテーション依存のコントロー ルをプロセッサに送ることができる。 TPrivilegedProcessorSetHandleはプロセッサ・セット制御ポートのプロトコ ルを提供する具象クラスである。このクラスのオブジェクトは、スケジューリン グ・ポリシを許可(enable)し、禁止(disable)すること、プロセッサ・セットの 最高優先度をセットすること、統計と情報を返すこと、タスクとスレッドを列挙 すること、スレッドとタスクをプロセッサ・セットに割り当てることができる。 このクラスのオブジェクトへのクライアントのアクセスは、個別的プロセッサと プロセッサ・セットを保護するために非常に制限しておかなければならない。 TProcessorSetHandleはプロセッサ・セットの名前ポートのプロトコルを提供 する具象クラスである。このクラスのオブジェクトはプロセッサ・セットに関す る基本情報（プロセッセ・セット内のプロセッサの数など）を返すことができる が、そのためにプロセッサ・セットが壊されることはない。 ラッパー・メソッドの実現方法 上述したように、MachおよびMach手続き型インタフェースは公知である。ラッ パー・クラス・ライブラリ402およびラッパー・クラス・ライブラリ402のメソッ ドのオペレーションの詳しい定義と説明は上述したとおりである。以下では、ラ ッパー・クラス・ライブラリ402によって定義されたメソッドの実現方法につい て、ラッパー・クラス・ライブラリ402から選択したメソッドを考慮することに より説明する。この分野の専門家ならば理解されるように、ラッパー・クラス・ ライブラリ402の他のメソッドは、Machの公知仕様、ラッパー・クラス・ライブ ラリ402に関して上述した説明、およびラッパー・メソッドの実現方法に関して 下述する説明に基づいて実現することが可能である。スレッド・クラス404のTTh readHandleからのkill()メソッドの実現方法は、以下の「コーディング例２」に 示されている。"examplel"と名づけたルーチンは以下の「コーディング例１」に 示されている。"example2"ルーチンはkill()メソッドを実行させるデコンポジシ ョン(decomposition)ステートメントを含んでいる。 上記において、 fThreadControlPortは、クラスが表すスレッドのMachスレッド制御ポートを収 めているTThreadHandleクラスのインスタンス変数である。 TKernekExceptionはカーネル・ルーチンにエラーが起こったとき引き起こされ るC++例外クラスである。 THROW、TRY、CATCH、およびENDTRYはC++言語の一部であり、C++例外を引き起 こし、それをキャッチできるようにする。 タスク・クラス406のTTaskHandleクラスからのsuspend()メソッドの実現方法 は、以下の「コーディング例４」に示されている。"example2"と名づけたルーチ ンは以下の「コーディング例３」に示されている。"example2"ルーチンは suspend()メソッドを実行させるデコンポジション・ステートメントを含んでい る。 上記において、 fThreadControlPortは、クラスが表すスレッドのMachスレッド制御ポートを収 めているTThreadHandleクラスのインスタンス変数である。 TKernekExceptionはカーネル・ルーチンにエラーが起こったとき引き起こされ るC++例外クラスである。 THROW、TRY、CATCH、およびENDTRYはC++言語の一部であり、C++例外を引き起 こし、それをキャッチできるようにする。 スケジューリング・クラス414のTPseudoRealTimeThreadScheduleクラスからの GetLevel()メソッドの実現方法は、以下の「コーディング例６」に示されている 。"example3"と名づけたルーチンは以下の「コーディング例５」に示されている 。"example3"ルーチンはGetLevel()メソッドを実行させるデコンポジション・ス テートメントを含んでいる。 上記において、 fThreadControlPortは、TPseudoRealTimeThreadScheduleクラスのインスタン ス変数である。これはクラスがスケジュールとなっているMachスレッド制御ポー トを収めている。 マシン・クラス418のTHostHandleクラスからのGetKernelVersion()メソッドの 実現方法は、以下の「コーディング例８」に示されている。"example4"と名づけ たルーチンは以下の「コーディング例７」に示されている。"example4"ルーチン はGetKernelVersion()メソッドを実行させるデコンポジション・ステートメント を含んでいる。 上記において、 fHostPortsは、クラスが表すホストのMachホスト制御ポートを収めているTHos tHandleクラスのインスタンス変数である。 IPCクラス410のTPortReceiveRightHandleクラスからのGetMakeSendCount()メ ソッドの実現方法は以下の「コーディング方法10」に示されている。 "example5"と名づけたルーチンは以下の「コーディング例９」に示されている。 "example5"ルーチンはGetMakeSendCount()メソッドを実行させるデコンポジショ ン・ステートメントを含んでいる。その名前が示すように、GetMakeSendCount() メソッドはMachをアクセスしてポートに関連する送信カウントを取り出す。GetM akeSendCount()メソッドはmach pot get attributesをコールするステートメン トを含んでおり、これはポートに関するステータス情報を返すMach手続き向きシ ステム・コールである。GetMakeSendCount()では、fTheTaksは関連タスクのタス ク制御ポートを収めているTPortReceiveRightHandleオブジェクトのインスタン ス変数であり、fThePortNameはTPortReceiveRightHandleオブジェクトによって 表されたポートのポート権名を収めているTPortReceiveRightHandleオブジェク トのインスタンス変数である。 本発明は上述した説明に基づいて種々態様に変更することが可能である。例え は、本発明の範囲には、手続き型アプリケーションがコンピュータで実行時に実 行されているとき、そのアプリケーションがネイティブ・オブジェクト指向イン タフェースをもつオブジェクト指向オペレーティング・システムを手続き型の方 式でアクセスすることを可能にするシステムおよび方法が含まれている。本発明 のこの実施例は、好ましくは、オペレーティング・システムから提供されるサー ビスをアクセスする手続き型ステートメントをアプリケーションの中に置き、そ の手続き型ステートメントをオペレーティング・システムのネイティブ・オブジ ェクト指向インタフェースと互換性をもち、手続き型ステートメントに対応する オブジェクト指向関数コール（つまり、メソッド）に変換することによって動作 する。オブジェクト指向関数コールがコンピュータで実行されると、オペレーテ ィング・システムはアプリケーションのためにサービスを提供する。本発明の種 々実施例について上述してきたが、これらは例示であって、これらに限定される ものではない。従って、本発明の範囲は上述した実施例のいずれによっても限定 されるものではなく、請求の範囲に明確化されている記載とその等価的記載に従 ってのみ判断すべきものである。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年８月２４日 【補正内容】 上記問題の１つの解決方法は、ネイティブ・オブジェクト指向インタフェース をもつオブジェクト指向オペレーティング・システムを開発することである。こ れが、最終的には、最良の解決方法となると思われるが、現時点では、主要な手 続き型オペレーティング・システムのすべてを修正するために必要な資源が膨大 になるので、実用的な解決ではない。また、これらの手続き型オペレーティング ・システムをこのように修正すると、多数の手続き向きソフトウェア・プログラ ムが無駄になってしまう。そこで、なにが必要であるかというと、それはオブジ ェクト指向アプリケーションが、ネイティブ（native：本来）手続き型インタフ ェースをもつ手続き型オペレーティング・システムと、オブジェクト指向方式で やりとりできるようにするメカニズムである。 Schmidt著“Systems Programming with C++ Wrappers: Encapsulating IPC Se rvices with Object-Oriented Interfaces”の記事に、ローカルおよびリモート のプロセス間通信(interprocess communication)サービス(IPC)をカプセル化す るためのオブジェクト指向インタフェースの使用についての記述がある。Schmid tは多くの開発者にとりIPCサービスの理解と使用が難しいと主張し、既存の手続 き型IPC・システム・コール・インタフェースの複雑さが少なくても問題の一部 分であるとしている。Schmidtは、共通使用パターン(common usage pattern)に 対するデフォルト値を用意することにより、かつ、よく起こる複数の関数をひと つの関数に結合して、カプセル化することにより、IPCサービスを呼出す複雑さ が減少すると示唆する。Schmidtはまた、インタフェースを特別な手続き型オペ レーション・システムのシステム・コールに、透明にマッピングすることによる ラッパー(wrapper)の使用が、ポータビリティを改善すると主張する。Schmidtは ホスト・システムに対するサポートを決して示唆や教示していない。特に、Schm idtは、複数のプロセッサのひとつの上で実行されるひとつかひとつより多いオ ブジェクト指向アプリケーションと、手続き型オペレーティング・システムとの インタフェースを管理するために割当てられた複数のプロセッサのひとつを有し 、ひとつのコンピュータ上でこれらの複数のプロセッサを管理する オブジェクト指向技術の使用を決して示唆や教示していない。Schmidtは、アプ リケーション・プログラムが、ブート情報とホスト統計を得たり、コンピュータ をブートしたり、ホスト・コンピュータの特権プロセッサ特性を定義することを 可能にするオブジェクト指向技術の使用について、決して示唆や教示をしていな い。また、Schmidtは、アプリケーション・プログラムが、スケジューリング・ ポリシーを許可したり禁止したり、複数のプロセッサのどれかに最高優先度をつ けたり、あるいはプロセッサのどれかひとつの上で実行するタスクとスレッドを 定義することを可能にするオブジェクト指向技術の使用について、決して示唆や 教示をしていない。Schmidtは、アプリケーション・プログラムに複数のプロセ ッサの各々に関連した情報を得ることを可能にするオブジェクト指向技術の使用 について、決して示唆や教示していない。さらに、Schmidtは、オブジェクト指 向ステートメントに対応する実行可能プログラム・ロジックをアプリケーション ・プログラムに挿入して、アプリケーション・プログラムの実行時(run-time)実 行中に、アプリケーション・プログラムがオブジェクト指向方法でオペレーティ ング・システム・サービスにアクセスさせることについて述べていない。したが って、必要なことは、アプリケーションの実行時(run-time)実行中に、オブジェ クト指向アプリケーションがネイティブ手続き型インタフェースをもつ手続き型 オペレーティング・システムとオブジェクト指向方法で対話するのを可能にし、 ホスト・システムに対するサポートを含み、オブジェクト指向ステートメントに 対応する実行可能プログラム・ロジックをアプリケーション・プログラムに挿入 する手段を含み、手続き型オペレーティング・システム・サービスへのオブジェ クト指向アクセスを可能にするメカニズムである。 発明の概要 本発明は、ネイティブ手続き型インタフェースをもつ手続き型オペレーティン グ・システムを、オブジェクト指向アプリケーションがオブジェクト指向方式で アクセスできるようにするシステムおよび方法を提供することを目的としている 。システムはホスト・システムをサポートするコンピュータとコンピュータ内 のメモリ・コンポーネント（構成要素）を装備している。コード・ライブラリ(c ode library)はメモリ・コンポーネントにストアされている。このコード・ライ ブラリは、オブジェクト指向クラス・ライブラリを実現するコンピュータ・プロ グラム・ロジックを含んでいる。オブジェクト指向クラス・ライブラリは、オペ レーティング・システムから提供されるサービスを、アプリケーションがオブジ ェクト指向方式でアクセスできるようにする、相互に関係をもつオブジェクト指 向クラスから構成されている。オブジェクト指向クラスは、オペレーティング・ システムのネイティブ手続き型インタフェースと互換性のある手続き型関数コー ル(procedural function call)を使用してオペレーティング・システムのサービ スをアクセスするためのメソッドを含んでいる。さらに、システムは、アプリケ ーションに含まれていてクラス・ライブラリによって定義されたオブジェクト指 向ステートメントを、そのオブジェクト指向ステートメントに対応するクラス・ ライブラリ内のメソッドを実行することによって処理する手段も備えている。 好ましくは、クラス・ライブラリは次のものを含んでいる。 (1) スレッド・クラス(thread class)。これは、アプリケーションがオペレー ティング・システムのサービスをオブジェクト指向方式でアクセスして、スレッ ドに関する情報を作成し、管理し、取得することを可能にするものである。 (2) タスク・クラス(taskclass)。これは、アプリケーションがオペレーティ ング・システムのサービスをオブジェクト指向方式でアクセスして、タスクを参 照し、管理することを可能にするもので、タスクの各々は、それぞれがタスクに 関連づけられているスレッドの実行環境を表している。 (3) バーチャル（仮想）メモリ・クラス(virtual memory class)。これは、ア プリケーションがオペレーティング・システムのサービスをオブジェクト指向方 式でアクセスして、コンピュータ内のバーチャル・メモリをアクセスし、操作す ることを可能にするものである。 請求の範囲 １．並列に動作する複数のプロセッサとメモリ・コンポーネント(108,122)を具 備するホスト・コンピュータ(102)を含み、オブジェクト指向ステートメントを 含むオブジェクト指向アプリケーション(130A,130B)に、手続き型オペレーティ ング・システムにより提供されるサービスを含む、前記ホスト・コンピュータと 前記複数のプロセッサをモニタし制御する前記手続き型オペレーティング・シス テムへのアクセスを可能にさせる装置において、 (a) 前記メモリ・コンポーネントにストアされたコード・ライブラリ(110)が 、 (b) 前記オブジェクト指向ステートメントに対応する実行可能プログラム・ロ ジックと、 (c) 前記実行可能プログラム・ロジック(202)をオブジェクト指向クラス・ラ イブラリ(402）にストアする手段と、 (d) 前記実行可能プログラム・ロジック(110,402)を使い、前記オブジェクト 指向アプリケーションを前記手続き型オペレーティング・システムヘインタフェ ースする手段と を具備し、 前記ホスト・コンピュータにある前記複数のプロセッサ(1614)のひとつは、前 記実行可能プログラム・ロジックを前記手続き型アプリケーションに挿入するこ とにより前記オブジェクト指向ステートメントを処理し、前記ホスト・コンピュ ータと前記複数のプロセッサをモニタし制御する前記サービス(208,314,316,161 4）を含む前記手続き型オペレーティング・システムをインタフェースすること を特徴とする装置。 ２．前記コード・ライブラリ(110)が、データとしての前記ホスト・コンピュー タ(102)の特権ポート(privilege port)と、前記特権ポートを使いホスト・コン ピュータ統計を得て前記ホスト・コンピュータの特権プロセッサの特性を定義す るメソッドとを含むオブジェクト指向のクラス(418,1608)を具備することを特徴 とする請求の範囲第１項に記載の装置。 ３．前記コード・ライブラリ(110)が、データとして前記複数のプロセッサ(106) の各々のポートをアクセスするプロトコルと、前記プロトコルを用いてスケジュ ーリング・ポリシーを許可および禁止し、前記複数のプロセッサのひとつに最高 優先度を設定し、前記複数のプロセッサのひとつで実行されるタスク(406)とス レッド(404)を定義するメソッドとを含むオブジェクト指向クラス(414,1106)を 具備することを特徴とする請求の範囲第１項に記載の装置。 ４．前記コード・ライブラリ(110)が、データとして前記複数のプロセッサ(106) の各々の名前ポートをアクセスするプロトコルと、前記名前ポートを使い前記複 数のプロセッサの各々に関連する情報を得るメソッドとを含むオブジェクト指向 クラス(406,1206)を具備することを特徴とする請求の範囲第１項に記載の装置。 ５．オブジェクト指向ステートメントを含むオブジェクト指向アプリケーション (130A,130B)とホスト・コンピュータ(102)に常駐する手続き型オペレーティング ・システムとのインタフェースを提供し、前記ホスト・コンピュータは、複数の プロセッサ(106)、メモリ・コンポーネント(108,122)および前記メモリ・コンポ ーネントにストアされたコード・ライブラリ(110)を有する方法において、 (a) 前記手続き型オペレーティング・システムが提供するサービスを必要とす るクラス(404,406,408,410,412,414,416,418,420)を含むオブジェクト指向クラ ス・ライブラリ(402)を実装し、 (b) アプリケーション実行時に(314)前記オブジェクト指向アプリケーション へ前記クラスを提供し、 (c) 前記手続き型オペレーティング・システム(110,402)へのインタフェース を提供するために、前記オブジェクト指向アプリケーションにコールされた前記 メソッドに対応する手続き型関数コールを呼び出して、前記アプリケーション・ プログラムによりコールされた前記クラスでメソッドを実行する ステップを具備し、 前記ホスト・コンピュータ(102)の前記複数のプロセッサ(1614)のひとつが、 前記実行可能プログラム・ロジックを前記オブジェクト指向アプリケーションに 挿入して前記オブジェクト指向ステートメントを処理し、前記ホスト・コンピュ ータと前記複数のプロセッサをモニタし制御する(208,314,316,1614)前記サービ スを含む前記手続き型オペレーティング・システムをインタフェースすることを 特徴とする方法。 ６．前記コード・ライブラリ(110)が、ホスト・コンピュータ統計を得て前記ホ スト・コンピュータの特権プロセッサ特性を定義するために使われる、前記ホス ト・コンピュータ(102)の特権ポートをデータとして含むオブジェクト指向クラ ス(418,1608)を具備することを特徴とする請求の範囲第５項に記載の方法。 ７．前記コード・ライブラリ(110)が、前記ホスト・コンピュータ(102)に関連し た情報を得て前記ホスト・コンピュータに含まれる前記複数のプロセッサ(106) のリストを得るメソッドを含む名前ポート・オブジェクトをデータとして含むオ ブジェクト指向クラス(406,1206)を具備することを特徴とする請求の範囲第６項 に記載の方法。 ８．前記コード・ライブラリ(110)が、スケジューリング・ポリシーを許可およ び禁止し、前記複数のプロセッサの各々に最高優先度を設定し、前記複数のプロ セッサの各々関連するタスク(406)とスレッド(404)を列挙し、タスクとスレッド を前記複数のプロセッサの各々に割当てる(1614)メソッドを含む前記複数のプロ セッサの各々(106)に対する制御ポート・オブジェクトを含むオブジェクト指向 クラス(414,1106)を具備することを特徴とする請求の範囲第７項に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ 【要約の続き】 る。コンピュータはアプリケーション内に置かれてい て、クラス・ライブラリによって定義されたオブジェク ト指向ステートメントを、オブジェクト指向ステートメ ントに対応するメソッドをクラス・ライブラリから取り 出して実行することにより処理する。オブジェクト指向 アプリケーションはマルチタスキングに対するサポート を含んでいる。

Claims (1)

1. 【特許請求の範囲】 １．オブジェクト指向アプリケーションがネーティブ手続き型インタフェースを もつ手続き型オペレーティング・システムをオブジェクト指向方式でアクセスす ることを可能にする装置であって、該装置は (a) コンピュータと、 (b) コンピュータに置かれたメモリ・コンポーネントと、 (c) メモリ・コンポーネントにストアされているコード・ライブラリであって 、該コード・ライブラリはオブジェクト指向クラス・ライブラリを実現するコン ピュータ・プログラム・ロジックを含んでおり、該オブジェクト指向クラス・ラ イブラリは、アプリケーションがオペレーティング・システムから提供されるサ ービスをオブジェクト指向方式でアクセスすることを可能にする、関連するオブ ジェクト指向クラスを含んでおり、該オブジェクト指向クラスは、オペレーティ ング・システムのネーティブ手続き型インタフェースと互換性のある手続き型関 数コールを使用してオペレーティング・システムのサービスをアクセスするため のメソッドを含んでいるものと、 (d) コンピュータに置かれた手段であって、アプリケーションに含まれていて クラス・ライブラリによって定義されたオブジェクト指向ステートメントを、該 オブジェクト指向ステートメントに対応するメソッドをコード・ライブラリから 取り出して実行することによって処理するための手段と、 (e) ホスト手段であって、ホストはコンピュータを抽象化したものを表してい るものとを備え、コンピュータは並列に動作する複数のプロセッサを装備し、プ ロセッサ・セットは各々が該プロセッサの１つまたは２つ以上を含んでいること を特徴とする装置。 ２．請求の範囲第１項に記載の装置において、オブジェクト指向クラス・ライブ ラリは、アプリケーションがオペレーティング・システムのサービスをオブジェ クト指向方式でアクセスして、ホストおよびプロセッサ・セットを定義し、変更 することを可能にするオブジェクト指向マシン・クラスを含んでいることを特徴 とする装置。 ３．請求の範囲第２項に記載の装置において、マシン・クラスは、ホストの特権 ポートをカプセル化しているオブジェクト指向クラスを含んでおり、該オブジェ クト指向クラスは、オブジェクト指向クラスのインスタンスへのアクセス権をも つオブジェクトがオペレーティング・システムの特権ポートを通してブート情報 とホスト統計を得ること、コンピュータをブートすること、特権プロセッサ・セ ットを列挙すること、およびプロセッサを列挙することを可能にするためのメソ ッドを含んでいることを特徴とする装置。 ４．請求の範囲第２項に記載の装置において、マシン・クラスは、ホストの名前 ポートをカプセル化しているオブジェクト指向クラスを含んでおり、該オブジェ クト指向クラスは、オブジェクト指向クラスのインスタンスへのアクセス権をも つオブジェクトがホストに関する限定情報を得ること、およびデフォルト・プロ セッサ・セットに割り当てられたプロセッサのリストを得ることを可能にするた めのメソッドを含んでいることを特徴とする装置。 ５．請求の範囲第２項に記載の装置において、マシン・クラスは、プロセッサ・ セットの制御ポートをアクセスするためのプロトコルを定義しているオブジェク ト指向クラスを含んでおり、該オブジェクト指向クラスは、オブジェクト指向ク ラスのインスタンスがスケジューリング・ポリシを許可したり、禁止したりする こと、プロセッサ・セットの最高優先度を設定すること、プロセッサ・セットに 関連するタスクとスレッドを列挙すること、タスクとスレッドをプロセッサ・セ ットに割り当てることを可能にするためのメソッドを含んでいることを特徴とす る装置。 ６．請求の範囲第２項に記載の装置において、マシン・クラスは、プロセッサ・ セットの名前ポートをアクセスするためのプロトコルを定義しているオブジェク ト指向クラスを含んでおり、該オブジェクト指向クラスは、オブジェクト指向ク ラスのインスタンスがプロセッサ・セットに関する限定情報を得ることを可能に するためのメソッドを含んでいることを特徴とする装置。 ７．ネーティブ手続き型インタフェースをもつ手続き型オペレーティング・シス テムとのオブジェクト指向インタフェースを提供する装置であって、該装置は、 (a) コンピュータと、 (b) コンピュータに置かれたメモリ・コンポーネントと、 (c) メモリ・コンポーネントにストアされているコード・ライブラリであって 、該コード・ライブラリはオブジェクト指向クラス・ライブラリを実現するコン ピュータ・プログラム・ロジックを含んでおり、該オブジェクト指向クラス・ラ イブラリはアプリケーションがオペレーティング・システムから提供されるサー ビスをオブジェクト指向方式でアクセスすることを可能にする、関連するオブジ ェクト指向クラスを含んでおり、該オブジェクト指向クラスは、オペレーティン グ・システムのネーティブ手続き型インタフェースと互換性のある手続き型関数 コールを使用してオペレーティング・システムのサービスをアクセスするための メソッドを含んでいるものにおいて、オブジェクト指向クラス・ライブラリによ って定義されたオブジェクト指向ステートメントは、アプリケーションがコンピ ュータでランタイムに実行されているときアプリケーションがオペレーティング ・システムのサービスをオブジェクト指向方式でアクセスすることを可能にする ためにアプリケーションの中に挿入可能であるものと、 (d) オブジェクト指向クラス・ライブラリに置かれた手段であって、アプリケ ーションがオペレーティング・システムのサービスをオブジェクト指向方式でア クセスして、ホストおよびプロセッサ・セットを定義し、変更することを可能に するオブジェクト指向マシン・クラスを含んでいるものと備えていることを特徴 とする装置。 ８．ネーティブ手続き型インタフェースをもつ手続き型オペレーティング・シス テムとのオブジェクト指向インタフェースを提供する装置であって、該装置 は、 (a) コンピュータと、 (b) コンピュータに置かれたメモリ・コンポーネントと、 (c) メモリ・コンポーネントにストアされているコード・ライブラリであって 、該コード・ライブラリはオブジェクト指向クラス・ライブラリを実現するコン ピュータ・プログラム・ロジックを含んでおり、該オブジェクト指向クラス・ラ イブラリはアプリケーションがオペレーティング・システムのマシン・サービス をオブジェクト指向方式でアクセスすることを可能にする、相互に関連をもつオ ブジェクト指向クラスを含んでおり、該オブジェクト指向クラスは、オペレーテ ィング・システムのネーティブ手続き型インタフェースと互換性のある手続き型 関数コールを使用してオペレーティング・システムのマシン・サービスをアクセ スするためのメソッドを含んでいるものにおいて、オブジェクト指向クラス・ラ イブラリによって定義されたオブジェクト指向ステートメントは、アプリケーシ ョンがコンピュータでランタイムに実行されているときアプリケーションがオペ レーティング・システムのマシン・サービスをオブジェクト指向方式でアクセス することを可能にするためにアプリケーションの中に挿入可能であるものとを備 えていることを特徴とする装置。 ９．請求の範囲第８項に記載の装置において、マシン・クラスはホストの特権ポ ートをカプセル化しているオブジェクト指向クラスを含んでおり、該オブジェク ト指向クラスは、オブジェクト指向クラスのインスタンスへのアクセス権をもつ オブジェクトがオペレーティング・システムの特権ポートを通してブート情報と ホスト統計を得ること、コンピュータをブートすること、特権プロセッサ・セッ トを列挙すること、およびプロセッサを列挙することを可能にするためのメソッ ドを含んでいることを特徴とする装置。 10．請求の範囲第８項に記載の装置において、マシン・クラスはホストの名前ポ ートをカプセル化しているオブジェクト指向クラスを含んでおり、該オブジェク ト指向クラスは、オブジェクト指向クラスのインスタンスへのアクセス権をも つオブジェクトがホストに関する限定情報を得ること、およびデフォルト・プロ セッサ・セットに割り当てられたプロセッサのリストを得ることを可能にするた めのメソッドを含んでいることを特徴とする装置。 11．請求の範囲第８項に記載の装置において、マシン・クラスはプロセッサ・セ ットの制御ポートをアクセスするためのプロトコルを定義しているオブジェクト 指向クラスを含んでおり、該オブジェクト指向クラスは、オブジェクト指向クラ スのインスタンスがスケジューリング・ポリシを許可したり、禁止したりするこ と、プロセッサ・セットの最高優先度を設定すること、プロセッサ・セットに関 連するタスクとスレッドを列挙すること、タスクとスレッドをプロセッサ・セッ トに割り当てることを可能にするためのメソッドを含んでいることを特徴とする 装置。 12．請求の範囲第８項に記載の装置において、マシン・クラスはプロセッサ・セ ットの名前ポートをアクセスするためのプロトコルを定義しているオブジェクト 指向クラスを含んでおり、該オブジェクト指向クラスは、オブジェクト指向クラ スのインスタンスがプロセッサ・セットに関する限定情報を得ることを可能にす るためのメソッドを含んでいることを特徴とする装置。 13．コンピュータに置かれたメモリ・コンポーネントと、メモリ・コンポーネン トにストアされたコード・ライブラリとを備えたコンピュータ上でオブジェクト 指向アプリケーションがネーティブ手続き型インタフェースをもつ手続き型オペ レーティング・システムをオブジェクト指向方式でアクセスすることを可能にす る方法であって、 (a) オブジェクト指向クラス・ライブラリを実現するステップであって、該オ ブジェクト指向クラス・ライブラリはアプリケーションがオペレーティング・シ ステムから提供されるサービスをオブジェクト指向方式でアクセスすることを可 能にする、関連するオブジェクト指向クラスを含んでおり、該オブジェクト指向 クラスはオペレーティング・システムのネーティブ手続き型インタフェースと互 換性をもつ手続き型関数コールを使用してオペレーティング・システムのサービ スをアクセスするためのメソッドを含んでいるものと、 (b) アプリケーションに入っていて、クラス・ライブラリによって定義された オブジェクト指向ステートメントを、オブジェクト指向ステートメントに対応す るメソッドをクラス・ライブラリから取り出して実行することによって処理する ステップと、 (c) コンピュータを抽象化したものをホストとして表現するステップとからな り、コンピュータは並列に動作する複数のプロセッサを含み、プロセッサ・セッ トは各々がプロセッサの１つまたは２つ以上を含んでいることを特徴とする方法 。 14．請求の範囲第13項に記載の方法において、アプリケーションがオペレーティ ング・システムのサービスをオブジェクト指向方式でアクセスして、ホストおよ びプロセッサ・セットを定義し、変更することを可能にするステップを含んでい ることを特徴とする方法。 15．請求の範囲第14項に記載の方法において、ホストの特権ポートをカプセル化 するステップを含んでいて、オブジェクト指向クラスは、オブジェクト指向クラ スのインスタンスへのアクセス権をもつオブジェクトがオペレーティング・シス テムの特権ポートを通してブート情報とホスト統計を得ること、特権プロセッサ ・セットを列挙すること、およびプロセッサを列挙することを可能にするメソッ ドを含んでいることを特徴とする方法。 16．請求の範囲第14項に記載の方法において、ホストの名前ポートをカプセル化 するステップを含んでいて、オブジェクト指向クラスは、オブジェクト指向クラ スのインスタンスへのアクセス権をもつオブジェクトがホストに関する限定情報 を得ること、およびデフォルト・プロセッサ・セットに割り当てられたプロセッ サのリストを得ることを可能にするメソッドを含んでいることを特徴とする方法 。 17．請求の範囲第14項に記載の方法において、プロセッサ・セットの制御ポート をアクセスするためのプロトコルを定義するステップを含んでいて、オブジェク ト指向クラスは、オブジェクト指向クラスのインスタンスがスケジューリング・ ポリシを許可したり、禁止したりすること、プロセッサ・セットの最高優先度を 設定すること、プロセッサ・セットに関連するタスクとスレッドを列挙すること 、およびタスクとスレッドをプロセッサ・セットに割り当てることを可能にする ためのメソッドを含んでいることを特徴とする方法。 18．請求の範囲第14項に記載の方法において、プロセッサ・セットの名前ポート をアクセスするためのプロトコルを定義するステップを含んでいて、オブジェク ト指向クラスはオブジェクト指向クラスのインスタンスがプロセッサ・セットに 関する限定情報を得ることを可能にするためのメソッドを含んでいることを特徴 とする方法。 19．ネーティブ手続き型インタフェースをもつ手続き型オペレーティング・シス テムとのオブジェクト指向インタフェースを、コンピュータに置かれたメモリ・ コンポーネントを備えたコンピュータ上で提供する方法であって、該方法は (a) オブジェクト指向クラス・ライブラリを実現するコンピュータ・プログラ ム・ロジックと共にコード・ライブラリをメモリ・コンポーネントにストアする ステップであって、オブジェクト指向クラス・ライブラリはオブジェクト指向ア プリケーションがオペレーティング・システムから提供されるサービスをオブジ ェクト指向方式でアクセスすることを可能にする、関連するオブジェクト指向ク ラスを含んでいるものと、 (b) オペレーテイング・システムのネーティブ手続き型インタフェースと互換 性をもつ手続き型関数コールを使用してオペレーティング・システムのサービス をアクセスするステップと、 (c) アプリケーションがコンピュータでランタイムに実行されているとき、ア プリケーションがオペレーティング・システムのサービスをオブジェクト指向方 式でアクセスすることを可能にするためにアプリケーションに挿入可能であるオ ブジェクト指向ステートメントをオブジェクト指向クラス・ライブラリによって 定義するステップと、 (d) アプリケーションがオペレーティング・システムのサービスをオブジェク ト指向方式でアクセスして、ホストおよびプロセッサ・セットを定義し、変更す ることを可能にするステップとからなることを特徴とする方法。 20．ネーティブ手続き型インタフェースをもつ手続き型オペレーティング・シス テムとのオブジェクト指向インタフェースを、コンピュータに置かれたメモリ・ コンポーネントを備えたコンピュータ上で提供する方法であって、 (a) コード・ライブラリをメモリ・コンポーネントにストアするステップと、 (b) オブジェクト指向クラス・ライブラリを実現するコンピュータ・プログラ ム・ロジックをメモリ・コンポーネントにストアするステップであって、オブジ ェクト指向クラス・ライブラリはオブジェクト指向アプリケーションがオペレー ティング・システムのマシン・サービスをオブジェクト指向方式でアクセスして 、ホストおよびプロセッサ・セットを定義し、変更することを可能にするオブジ ェクト指向マシン・サービスを含んでいるものと、 (c) オペレーティング・システムのネーティブ手続き型インタフェースと互換 性をもつ手続き型関数コールを使用してオペレーティング・システムのマシン・ サービスをアクセスするステップとからなり、オブジェクト指向クラス・ライブ ラリによって定義されたオブジェクト指向ステートメントは、アプリケーション がコンピュータでランタイムに実行されているとき、アプリケーションがオペレ ーティング・システムのマシン・サービスをオブジェクト指向方式でアクセスす ることを可能にするためにアプリケーションに挿入可能であることを特徴とする 方法。 21．請求の範囲第20項に記載の方法において、ホストの特権ポートをカプセル化 するステップを含んでいて、オブジェクト指向クラスは、オブジェクト指向クラ スのインスタンスへのアクセス権をもつオブジェクトがオペレーティング・シス テムの特権ポートを通してブート情報とホスト統計を得ること、特権プロセッサ ・セットを列挙すること、およびプロセッサを列挙することを可能にするメソッ ドを含んでいることを特徴とする方法。 22．請求の範囲第21項に記載の方法において、ホストの名前ポートをカプセル化 するステップを含んでいて、オブジェクト指向クラスは、オブジェクト指向クラ スのインスタンスへのアクセス権をもつオブジェクトがホストに関する限定情報 を得ること、およびデフォルト・プロセッサ・セットに割り当てられたプロセッ サのリストを得ることを可能にするメソッドを含んでいることを特徴とする方法 。 23．請求の範囲第22項に記載の方法において、プロセッサ・セットの制御ポート をアクセスするためのプロトコルを定義するステップを含んでいて、オブジェク ト指向クラスは、オブジェクト指向クラスのインスタンスがスケジューリング・ ポリシを許可したり、禁止したりすること、プロセッサ・セットの最高優先度を 設定すること、プロセッサ・セットに関連するタスクとスレッドを列挙すること 、およびタスクとスレッドをプロセッサ・セットに割り当てることを可能にする ためのメソッドを含んでいることを特徴とする方法。 24．請求の範囲第23項に記載の方法において、プロセッサ・セットの名前ポート をアクセスするためのプロトコルを定義するステップを含んでいて、オブジェク ト指向クラスはオブジェクト指向クラスのインスタンスがプロセッサ・セットに 関する限定情報を得ることを可能にするためのメソッドを含んでいることを特徴 とする方法。