JPH10283205A - データ通信方法 - Google Patents

Abstract

(57)【要約】 【課題】 プログラマのために異なる環境に対して透明
性を提供する。 【解決手段】 オブジェクト指向オペレーティング・シ
ステム間あるいはオブジェクト間通信を行うデータ通信
方法において、異なる性質或いはインターフェースを持
った通信機構がそれぞれ固有に持つオブジェクト間通信
の同期及び並行性の制御を行うためのタグ（Tag）とし
てフューチャ（Future）、コンティネーション（Contin
uation）を扱い、このタグ（Tag）を通信メッセージと
共に通信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オブジェクト指向
オペレーティング・システム（ＯＳ）又はその他のオブ
ジェクト指向プログラミングシステムにおいてオブジェ
クト間のデータ通信方法に関する。

【０００２】

【従来の技術】最近のソフトウェア技術には、いわゆる
オブジェクト指向技術がある。オブジェクト指向技術を
適用したソフトウェアでは、ソフトウエア内部の各機能
はオブジェクトとしてモジュール化されている。ソフト
ウエア全体の機能を実現するために、各オブジェクトは
オブジェクト間通信を行なう。オブジェクト間通信では
送信内容をメッセージに詰めて配送する。

【０００３】オブジェクト間通信には同期方法やメッセ
ージの管理方法について、いろいろな方式が考えられ
る。これらの方式はアプリケーションからの要求に応じ
て決定される必要がある。そのため、いろいろな要求に
応えるためには、アプリケーションに応じた性質（意味
構造、セマンティクス）やそれに応じたインターフェー
ス（Application Programming Interface：ＡＰＩs）
を持ったオブジェクト間通信機構が必要になる。なお、
以下で扱うＡＰＩとは、ＯＳの機能を用いるインターフ
ェース或いはプログラミングシステムの機能としてのイ
ンターフェースを示す。

【０００４】ある性質やインターフェースを持ったオブ
ジェクト間通信機構が存在することを「環境」があると
呼ぶことにする。一つの機器やホストにはただ一つの環
境が実現されることもあるし、異なる複数の環境が同時
に実現されることもある。特に異なる環境に存在するオ
ブジェクト間の通信は相互の環境の協調動作を行わしめ
るという点から重要である。

【０００５】ここで、異なる環境に存在するオブジェク
トにメッセージを送る機能を提供する考え方として、本
質的に以下の二つがある。すなわち、 １．異なる環境に存在するオブジェクトにメッセージを
送るために、同じ環境に存在するオブジェクトにメッセ
ージを送るときとは異なるインターフェースや手続きを
提供するという考え方と、 ２．異なる環境に存在するオブジェクトにメッセージを
送るために、同じ環境に存在するオブジェクトにメッセ
ージを送るときと同じインターフェースや手続きを使う
ことができるという考え方とがある。

【０００６】前者の方法は、比較的容易に実現できる。
なぜなら、全ての環境をプログラマが意識しなくてもよ
い考え方なので、インターフェースや手続きの違いが環
境の違いによって各々異なる機能を提供することで吸収
させればよいからである。

【０００７】

【発明が解決しようとする課題】しかし、プログラマの
ためには異なる環境に対してプログラムコードが左右さ
れない、いわゆる透明性を提供した方がよい。

【０００８】そこで本発明は、上述した課題に鑑みてな
されたものであり、プログラマのために異なる環境に対
して透明性を提供することを可能にするデータ通信方法
を提供することを目的とするものである。

【０００９】

【課題を解決するための手段】本発明は、同一又は相違
ＯＳを問わずオブジェクト間通信が必要なソフトウエア
であって、ソフトウエア間が透明性をもって通信するこ
とを実現するタグと、それを適用したソフトウェアシス
テムを実現することにより、上述した課題を解決する。

【００１０】すなわち、本発明は、上記「タグ」を導入
することによって、異なる環境間で透明性のある通信機
構を実現したソフトウェア、またはその実現方式を提供
する。本発明によって、ある通信機構が固有に持つオブ
ジェクト間通信の同期や並行性の制御に必要な実体が環
境によって異なっている場合でも、異なる環境に存在し
ているオブジェクトが互いにその違いを意識することな
く、通信可能になる。

【００１１】

【発明の実施の形態】本発明の一実施の形態について、
図面を参照しながら説明する。

【００１２】本発明実施の形態のデータ通信方法は、異
なる複数の環境を実現できるソフトウェア・システムに
適用することを基本的な特徴の一つとしている。本発明
の実施の形態では「環境」のことを特にメタスペースと
呼んでいる。また、本発明の実施の形態におけるメタス
ペースでは、オブジェクト間通信機構以外の機能につい
ても異なる「環境」を提供できる。なお、上記異なる複
数の環境を実現できるソフトウェア・システムとして
は、例えば本件出願人が先に提案している特願平８−６
７８８１号の明細書及び図面に記載したデータ処理方法
及び装置を挙げることができる。このデータ処理方法
は、複数のオブジェクトで構成されるアプリケーション
プログラムと、複数のオブジェクトで構成される前記ア
プリケーションプログラムの動作を規定する実行環境
と、前記アプリケーションプログラムと前記実行環境の
間のインターフェースを規定するアプリケーションプロ
グラムインターフェースとを備えるサーバと、前記サー
バより前記アプリケーションプログラムをダウンロード
するクライアントとを備えるデータ処理システムにおけ
るデータ処理方法であって、前記サーバは前記クライア
ントに前記アプリケーションプログラムをダウンロード
するとき、前記クライアントがダウンロードする前記ア
プリケーションプログラムの実行環境を有するか否かを
検査し、その検査結果に対応して前記アプリケーション
プログラムを前記クライアントにダウンロードすること
を特徴とするものである。

【００１３】図１には、本発明実施の形態のデータ通信
方法が適用される装置構成の一例を示す。

【００１４】この図１の装置は、カセット内にビデオテ
ープを収納したビデオカセットを用いて信号の記録再生
を行うビデオカセットレコーダ（以下、ＶＣＲ装置と呼
ぶ）である。勿論ＶＣＲ装置以外のオーディオ・ビジュ
アル機器（いわゆるＡＶ機器）や事務機器等のその他の
装置、一般のコンピュータ装置にも本発明は適用可能で
ある。

【００１５】図１のＶＣＲ装置において、ＶＣＲ機能部
１４はビデオカセットを用いてデータの記録再生を行う
ビデオカセットレコーダとしての主要機能を備え、当該
ＶＣＲ機能部１４にてビデオカセットに記録／再生され
るデータは、バス／ＩＯブリッジ１５を介して装置の他
の構成に送られ、また端子２３を介して外部との入出力
が行われる。ＣＰＵ（中央処置ユニット）１２は、バス
／メモリブリッジ１３を介して各部を制御する制御部で
ある。ＲＡＭ（ランダム・アクセス・メモリ）１０は、
比較的小容量で構成され、ワークエリアを有する。ＲＯ
Ｍ（リード・オンリ・メモリ）１１は、基本的な機能に
関するプログラムを記憶していると共に、本発明で言う
ＯＳに係るプログラムも記憶されている。すなわち、上
記ＣＰＵ１２は、上記ＲＯＭ１１が記憶するプログラム
に基づいて各部を制御し、上記ＲＡＭ１０をワークエリ
アとして使用する。

【００１６】ＩＣカードドライブ１６は、カード状の筐
体内にＩＣ（集積回路）を備えた記憶媒体であるＩＣカ
ードが挿入されるスロットと、当該ＩＣカードに対する
データの書き込み／読み出しを行うＩＣカード駆動部と
を有する。フロッピィディスクドライブ１７は、フロッ
ピィディスが挿入されるスロットと、当該フロッピィデ
ィスクを回転駆動する回転駆動部と、フロッピィディス
クに対してデータの記録／再生を行うヘッド部とを有
し、各種データの記録やアプリケーションソフトのイン
ストールなどが行われる。ハードディスクドライブ１８
は、当該ハードディスクを回転駆動する回転駆動部と、
ハードディスクに対してデータの記録／再生を行うヘッ
ド部とを有する。バススロット１９は、拡張ボードを追
加する際の拡張端子である。シリアルポート２０は、モ
デム（ＭＯＤＥＭ）を介して外部との間でデータ通信を
行うための入出力部である。

【００１７】このＶＣＲ装置は、一般のＶＣＲの機能に
追加して、付加的なアプリケーションソフトを与えるこ
とができるようになっている。例えばユーザがバージョ
ンアップを図りたい（新しい機能をこのＶＣＲ装置に付
加したい）場合等は、ＩＣカードやフロッピディスク或
いはインターネット等のネットワーク回線を介して付加
的な機能ソフトをインストールできる。したがってユー
ザは、ＶＣＲ装置本体を買い換えることなく装置の機能
アップが行える。アプリケーションプログラムはプログ
ラマによって作成されてユーザに供給されるものであ
る。ここでこれらソフトウェアをいわゆるオブジェクト
指向型プログラミングソフトで構築する場合を考える。

【００１８】上記の例の場合、異なる複数の環境（メタ
スペース）間で通信が必要となる場合がある。

【００１９】例えば図２に示すように外部からＭＯＤＥ
Ｍ（モデム）、シリアルポートを介して通信されてきた
アプリケーションソフトと予めＶＣＲ装置内に存在する
アプリケーションソフトは異なる環境（メタスペース）
下にあり、それぞれは通信用ＯＳ（後述するメタスペー
ス（mLocal）、メタスペース（mDrive）等）、ＡＶ用Ｏ
ＳとＡＰＩ（後述するセンド（Send）、リプライ（Repl
y）等）により通信が行われるようになっている。

【００２０】先ず初めに、上記「異なる通信機構につい
て具体的な二つの例」を本発明のデータ通信方法にて実
現した例を使って述べる。この例では後述するフューチ
ャ（Future）と呼ぶ実体を使った通信セマンティクス
（性質、意味構造）を実現したメタスペース（mLocal）
と、コンティネーション（Continuation）と呼ぶ実体を
使った通信セマンティクスを実現したメタスペース（mD
rive）の例で示す。

【００２１】本実施の形態では、上記「異なる通信機構
の具体的な例」として、 ［メタスペース（mLocal）通信機構］ ［メタスペース（mDrive）通信機構］ ［メタスペース（mLocal）通信機構とメタスペース（mD
rive）通信機構の比較］ ［本発明方法における通信機構の実現方式］ ［フューチャ（Future）とメタスペース（mLoca）通信
機構の実現方式］ ［コンティネーション（Continuation）とメタスペース
（mDrive）通信機構の実現方式］ の順に説明する。

【００２２】次に、「タグを使った通信機構の基本的な
説明」を述べる。ここでもメタスペース（mLocal）とメ
タスペース（mDrive）を例に述べる。なお、メタスペー
ス（mLocal）、メタスペース（mDrive）は、１つのＯＳ
又はプログラミングシステムとして捉えることができ
る。本実施の形態では、上記「タグを使った通信機構の
基本的な説明」として、 ［オブジェクトＡ（メソッドＡ１（A::A1））がオブジ
ェクトＢ（メソッドＢ１（B::B1））にセンド及びウェ
イトフォー（Send+WaitFor）する場合］ ［オブジェクトＢ（メソッドＢ１（B::B1））がオブジ
ェクトＡ（メソッドＡ１（A::A1））にセンド（Send）
し、継続メソッドとしてオブジェクトＢ（メソッドＢ２
（B::B2））を指定した場合］ の順に説明する。

【００２３】その後、「タグを使った通信機構の本発明
方法での実現事例」についての詳細を述べる。本実施の
形態では、上記「タグを使った通信機構の本発明方法で
の実現事例」として、 ［フューチャ（Future）、コンティネーション（Contin
uation）、タグ（Tag）］ ［タグＩＤの管理方式と当該タグＩＤを配送するオブジ
ェクト（Deliverer）］ ［異なるメタスペース間通信の実際］ の順に説明する。

【００２４】最後に「他に考えられる些細な点で他に異
なる方式」について述べる。本実施の形態では、上記
「その他に考えられる実現方式」として、 ［タグＩＤでタグの型を認識する方式］ ［タグの管理方式］ の順に説明する。

【００２５】先ず、上記本発明方法における「異なる通
信機構の具体的な例」の場合の説明を行う。

【００２６】本章では、「異なる通信機構の具体的な
例」として、本発明のデータ通信方法におけるオブジェ
クト間通信の具体的な仕様と実現方式について述べる。
本章に続く本発明の具体的な事例では、本章で述べる二
つの異なる（通信機構を提供している）環境間でのオブ
ジェクト間通信の実現方式を説明する。

【００２７】［メタスペース（mLocal）通信機構］上記
メタスペース（mLocal）は上記フューチャ（Future）を
基本にした通信機構をサポートした環境（オブジェクト
間通信機構）である。このメタスペース（mLocal）はア
プリケーションを記述するためのものである。メタスペ
ース（mLocal）通信機構の仕様のうち、インターフェー
スについては後述する。

【００２８】ここでは、メタスペース（mLocal）通信機
構を使ったオブジェクト間通信の基本的を動作について
述べる。この通信機構の実現方式、説明で使用されるフ
ューチャ（Future）が持つ属性については後に述べる。

【００２９】図３と図４はメタスペース（mLocal）通信
機構を使ったオブジェクト間通信の基本的な動作を示し
ている。図３にはメタスペース（mLocal）通信機構にお
いて、ウェイトフォー（WaitFor）がリプライ（Reply）
よりも先に実行された場合を示し、図４にはメタスペー
ス（mLocal）通信機構においてリプライ（Reply）がウ
ェイトフォー（WaitFor）よりも先に実行された場合を
示している。これら図３、図４ともにＡ、Ｂはオブジェ
クト、A::A1、B::B1はそれぞれオブジェクトＡのメソッ
ドＡ１、オブジェクトＢのメソッドＢ１、縦の実線矢印
はメソッドの実行、縦の破線矢印はメソッドの待ち状
態、斜めの実線矢印はメッセージの配送を示している。
なお、上記ウェイトフォー（WaitFor）は、メタスペー
ス（mLocal）におけるＡＰＩ（Application Programmi
ng Interface）の一つであり、本実施の形態ではオブ
ジェクトＡがオブジェクトＢの結果を待つ場合に用いら
れる。当該ウェイトフォー（WaitFor）には、その引数
として後述するフューチャＩＤ（futureID）、上記リプ
ライ（Reply）から送られた返答メッセージ（&msg）及
びそのサイズ（sizeof(msg)）を備える。なお、上記リ
プライ（Reply）は、メタスペース（mLocal）における
ＡＰＩの一つであり、本実施の形態ではオブジェクトＢ
がオブジェクトＡの返答する場合に用いられる。当該リ
プライ（Reply）には、その引数としてメソッドＢ１の
実行結果として得られる返答メッセージ（msg）及びそ
のサイズ（sizeof(msg)）を備える。

【００３０】また図３、図４ともに、オブジェクトＡが
オブジェクトＢにメッセージを送信し、その返答を受け
取る例である。はじめにオブジェクトＡはオブジェクト
Ｂにセンド１（Send1）を使ってメッセージを送信す
る。メソッドＢ１（B::B1）はこれによって起動するメ
ソッドであり、図中msgは配送されるメッセージ（のポ
インタ）である。これによって、メソッドＢ１（B::B
1）が起動される。メソッドＡ１（A::A1）、メソッドＢ
１（B::B1）は並行に動作する。このとき、メソッドＡ
１（A::A1）のウェイトフォー（waitfor）とメソッドＢ
１（B::B1）のリプライ（Reply）のどちらが先に実行さ
れるかという保証はない。なお、センド（Send）とは、
メタスペース（mLocal）におけるＡＰＩの一つであり、
本実施の形態ではメイルの送信を行う場合に用いられ
る。当該センド（Send）には、その引数として宛先
（Ｂ）と選択メソッド（Ｂ１）、メッセージ（msg）及
びそのサイズ（sizeof(msg)）とフューチャＩＤ（futur
eID）とを備える。

【００３１】オブジェクトＡがオブジェクトＢにメッセ
ージ送信したとき、オブジェクトＡはフューチャＩＤ(f
utureID）を受け取る。このフューチャＩＤはＯＳ（オ
ペレーティング・システム）がメッセージを配送する際
にＯＳが内部的に生成する上記フューチャ（Future）と
呼ばれる実体に対応するＩＤである。ここで、生成とは
オブジェクトを構成する属性に必要なメモリの領域を確
保すること及び当該属性を初期化することを示す。図５
に示すように、アプリケーションソフトはＡＰＩによっ
てメイラ（例えば後述するメタオブジエクト（MLocalMa
iler））のオブジェクトや後述するスケジューラ（Sche
duler）のオブジェクトに通信を行うようになす。メイ
ラの実行がオブジェクト内の実行コードに基づいてＣＰ
Ｕによって行われ、ＣＰＵはフューチャ（Future）に必
要なメモリ領域をＯＳ領域内に確保する。フューチャＩ
Ｄ(futureID）はオブジェクトＡが後にこのメッセージ
の配送に対する返答を受け取るとき、どのメッセージ送
信に対する返答メッセージの受信なのかを識別するため
に使われる。

【００３２】図６はフューチャ（Future）の属性を示し
ている。この属性としては、フューチャ（Future）を生
成したオブジェクトを特定するためのＩＤ（ThreadID c
reator）、返答が済んでいるかどうかを調べるためのフ
ラグ（bool isReplyDone）、返答メッセージ（void* re
plyMessage）がある場合にはこれを保存しておくための
領域が定義されている。例えば図３、図４の例ならば、
ＩＤ（ThreadID creator）はオブジェクトＡが、返答メ
ッセージ（void* replyMessage）にはメッセージ（ms
g）が保存される。

【００３３】図３はウェイトフォー（Waitfor）がリプ
ライ（Reply）よりも先に実行された場合を示してお
り、この場合、ウェイトフォー（Waitfor）の引数とし
て上記フューチャＩＤ(futureID）を与える。このと
き、指定されたフューチャＩＤ(futureID）に対する返
答のための処理が行われていないので、メソッドＡ１
（A::A1）の実行は待ち状態になる。その間、メソッド
Ｂ１（B::B1）は処理を続け、返答のための手続きをす
るときリプライ（Reply）を実行する。リプライ（Repl
y）が実行されると、ＯＳがメソッドＢ１（B::B1）を起
動するときに生成したフューチャ（Future）の状態を観
察する。この場合、ＯＳはそのフューチャ（Future）に
対して待ち状態のメソッドがあることを知ることができ
るので、ここでメソッドＡ１（A::A1）を再び実行状態
に戻す。その後、メソッドＡ１（A::A1）、メソッドＢ
１（B::B1）は再び並行に動作する。

【００３４】一方、図４はリプライ（Reply）がウェイ
トフォー（Waitfor）よりも先に実行された場合を示し
ている。リプライ（Reply）が実行されたとき、ＯＳが
メソッドＢ１（B::B1）を起動するときに生成したフュ
ーチャ（Future）の状態を観察する。この場合、ＯＳは
そのフューチャ（Future）に対応したメッセージの送信
者（この場合はオブジェクトＡ）はまだ待ち状態にない
ことを知ることができるので、フューチャ（Future）に
返答済みである印を付ける。メソッドＢ１（B::B1）は
そのまま残り部分の実行を続ける。メソッドＡ１（A::A
1）がメソッドＢ１（B::B1）からの返答を必要としたと
き、メソッドＡ１（A::A1）はウェイトフォー（Waitfo
r）の引数としてフューチャＩＤ(futureID）を与える。
この場合、指定されたフューチャＩＤ(futureID）に対
する返答のための処理がすでに行われているので、メソ
ッドＡ１（A::A1）は実行を継続することができる。

【００３５】このように、フューチャ（Future）は並行
動作している二つのオブジェクトの同期を取るための仲
介的な役割を果たしている。メタスペース（mLocal）通
信機構の仕様では、メッセージの送信側はどのメッセー
ジに対する返答待ちかを明示的に示す必要があるので、
フューチャＩＤ(futureID）によってフューチャ（Futur
e）を特定する。メッセージの受信側はどの送信者に対
する返信なのかを意識する必要がないように定めている
ので、フューチャＩＤ(futureID）は明示的に現れてい
ない。

【００３６】［メタスペース（mDrive）通信機構］メタ
スペース（mDrive）はコンティネーション（Continuati
on）を基本にした通信機構をサポートした環境である。
このメタスペース（mDrive）はデバイスドライバを記述
するためのものである。

【００３７】ここでは、メタスペース（mDrive）通信機
構を使ったオブジェクト間通信の基本的な動作について
述べる。この通信機構の実現方式、説明で使用されるコ
ンティネーション（Continuation）が持つ属性や状態遷
移などの詳細は後述する。

【００３８】図７はメタスペース（mDrive）通信機構を
使ったオブジェクト間通信の基本的な動作を示してい
る。図３、図４と同様にＡ、Ｂはともにオブジェクト、
A::A1、A::A2及びB::B1はそれぞれのオブジェクトＡ、
ＢのメソッドＡ１、Ａ２、Ｂ１、縦の実線矢印はメソッ
ドの実行、斜めの実線矢印はメッセージの配送を示して
いる。

【００３９】オブジェクトＡはセンド（Send）を使って
オブジェクトＢにメッセージを送信する。図７の例では
オブジェクトＢのメソッドＢ１（B::B1）にメッセージ
（msg）を配送する。このとき、オブジェクトＡはセン
ド（Send）に対して５番目の引数として継続メソッド
（Ａ２）を、さらに６番目の引数として継続メッセージ
（contMsg）を与える。このときのメソッドＡ２（A::A
2）は、メソッドＡ１（A::A1）の処理が終了した後、メ
ソッドＢ１（B::B1）からの返答を受け取って処理を継
続するメソッドである。また、このときのメッセージ
（contMsg）は、継続メソッド（Ａ２）の処理を補助す
るためのメッセージで、メソッドＡ１（A::A1）が継続
メソッドＡ２（A::A2）に渡す内容を含んだメッセージ
である。

【００４０】ＯＳは継続メソッド、継続メッセージを含
む上記コンティネーション（Continuation）と呼ばれる
実体を内部に生成する。ここでのコンティネーション
（Continuation）の生成は前記図５での説明で述べたフ
ューチャ（Future）の例と同様、後述するメタオブジエ
クト（MDriveMailre）等のメイラオブジェクトの実行に
よりメモリ内にコンティネーション（Continuation）に
必要な領域を確保する。

【００４１】図８はコンティネーション（Continuatio
n）の属性を示している。ここにはコンティネーション
（Continuation）を生成したオブジェクトを特定するた
めのＩＤ（ThreadIDcreator）、継続メソッド（Selecto
rmethod）、継続メッセージ（void*message）を格納す
る領域が定義されている。このコンティネーション（Co
ntinuation）の属性は、図８に示されており、コンティ
ネーション（Continuation）を生成したオブジェクトを
特定するためのＩＤ（ThreadID creator）、選択される
継続メソッド（Selector Method）及び継続メッセージ
（void* Message）を保存する領域が定義されている。
図７の例ではセンド（Send）により、オブジェクトＡ、
メソッドＡ２、メッセージ（contMsg）が送られると、
ＯＳがコンティネーション（Continuation）を生成し、
ＩＤ（ThreadID creator）にはオブジェクトＡ、継続メ
ソッド（Selector Method）にはメソッドＡ２、及び継
続メッセージ（void* Message）にはメッセージ（contM
sg）が保存される。

【００４２】メソッドＢ１（B::B1）はメソッドＡ１
（A::A1）から配送されたメッセージの内容の他、その
コンティネーション（Continuation）を特定するための
ＩＤとしてＯＳにより生成されたコンティネーションＩ
Ｄ（ContID）を受け取る。図７の例では、contIDとして
受け取っている。このコンティネーションＩＤ（ContI
D）はキック（Kick）の引数として使われる。なお、キ
ック（Kick）とはメタスペース（mDrive）におけるＡＰ
Ｉの一つであり、本実施の形態ではコンティネーション
ＩＤ（ContID）をオブジェクトＡに与えることでコンテ
ィネーション（Continuation）の中味の情報を得る際に
用いられる。このキック（Kick）には、その引数として
上記コンティネーションＩＤ（ContID）を備える。メタ
スペース（mDrive）のオブジェクトはコンティネーショ
ン（Continuation）をキック（Kick）することで、コン
ティネーション（Continuation）に含まれる情報を意識
せずに継続メソッドを起動することができる。図７の例
では、メソッドＢ１（B::B1）は受け取ったコンティネ
ーションＩＤ（contID）をそれ自身がキック（Kick）
し、これによりメソッドＡ１（A::A1）が指定した継続
メソッドＡ２（A::A2）が起動され、メソッドＢ１の結
果と継続メッセージ（contMsg）が渡される。

【００４３】このように、コンティネーション（Contin
uation）は、メッセージを受信したオブジェクトが、誰
がメッセージを送信したのか、あるいはどこに返答を送
信すればよいのかを意識することなく、継続メソッドを
起動できる（そのときに、返答を送信することができ
る）。メタスペース（mDrive）通信機構の仕様では、コ
ンティネーションＩＤ（ContID）はＯＳがメッセージの
受信側にメッセージと共に配送するので、送信側にはコ
ンティネーションＩＤ（ContID）は現れない。

【００４４】［メタスペース（mLocal）通信機構とメタ
スペース（mDrive）通信機構の比較］メタスペース（mL
ocal）通信機構の仕様において、メソッドの実行の並行
性は、あるメソッドの開始から終了までの間にのみ存在
する。このセマンティクスは並行性は高くないが（メタ
スペース（mDrive）通信機構の仕様に比べて）、プログ
ラマが直感的に理解しやすい、記述しなければならない
コードの量を少なくし易いなどの利点がある。しかし、
この仕様では、割込みを使ったデバイスドライバのよう
な非同期な事象を効率的に記述することができない。

【００４５】メタスペース（mDrive）通信機構の仕様で
は、メソッドを一度終了した後の継続メソッドを指定す
ることができる。割込みのような非同期な事象に対応し
て返答を送信するとき、コンティネーション（Continua
tion）をキック（Kick）することによってあらかじめ指
定された継続メソッドを起動できる。そのため、デバイ
スドライバのような非同期な事象を効率的に記述するこ
とができる。これは並行性の高いプログラムを記述でき
るが（メタスペース（mLocal）通信機構の仕様に比べ
て）、プログラマが直感的に理解し難い、記述しなけれ
ばならないコードの量が多くなり易いなどの欠点があ
る。

【００４６】[本発明方法における通信機構の実現方
式］本発明方法では、メタスペースが提供する機能は、
メタスペースを構成するオブジェクトによって実現す
る。このようなオブジェクトを、メタスペースが提供す
る機能を使うオブジェクトに対して特にメタレベルオブ
ジェクト、またはメタオブジエクトと呼ぶ。一方、メタ
スペースが提供する機能を使うオブジェクトをベースレ
ベルオブジェクト、またはベースオブジェクトと呼ぶ。

【００４７】各メタスペースに共通な機能を提供するオ
ブジェクトとして（これから説明を進める各通信機構を
実現するための構成要素として）、例えばスケジューラ
（Scheduler）と呼ぶものを用いることができる。スケ
ジューラ（Scheduler）はオブジェクトの状態を管理す
るメタオブジェクトである。本実施の形態で必要になる
スケジューラ（Scheduler）の仕様は後述する。

【００４８】一方、メタスペース（mLocal）とメタスペ
ース（mDrive）の通信機構はそれぞれのメタスペースで
異なる機構なので、それを実現するための機能を提供す
るメタオブジエクトは、それぞれに定義することができ
る。ここでは、メタスペース（mLocal）通信機構にてメ
ッセージの配送を実現するメタオブジエクトをメタオブ
ジエクト（MLocalMailer）、メタスペース（mDrive）通
信機構にてメッセージの配送を実現するメタオブジエク
トをメタオブジエクト（MDriveMailer）と呼ぶ。

【００４９】メタスペース（mLocal）通信機構はメタオ
ブジエクト（MLocalMailer）、スケジューラ（Schedule
r）、そしてそれらの実行を支援する他のモジュールに
よって実現される。また、メタスペース（mDrive）通信
機構はメタオブジエクト（MDriveMailer）、スケジュー
ラ（Scheduler）、そしてそれらの実行を支援する他の
モジュールによって実現される。ここではメタオブジエ
クト（MLocalMailer）とスケジューラ（Scheduler）、
メタオブジエクト（MDriveMailer）とスケジューラ（Sc
heduler）の関係にシナリオを与え、各通信機構の実現
方式を示す。また、それぞれフューチャ（Future）とコ
ンティネーション（Continuation）の属性を与え、シナ
リオによってそれらの状態遷移を示す。

【００５０】［フューチャ（Future）とメタスペース
（mLocal）通信機構の実現方式］図９から図１２はメタ
オブジエクト（MLocalMailer）とスケジューラ（Schedu
ler）の関係をシナリオ（フローチャート）によって与
える。

【００５１】図９はメタスペース（mLocal）のセンド
（Send）の手続きを示している。

【００５２】この図９において、先ずメタスペース（mL
ocal）上のベースオブジェクトがセンド（Send）を実行
すると、メタスペース（mLocal）を構成する通信機構の
ためのメタオブジェクト（MLocalMailer）に処理が移る
と共にベースオブジェクトはステップＳＴ７のようにウ
ェイト（Wait）の状態となる。ここで、ベースオブジェ
クトからメタオブジエクトへ処理の状態が移ることを、
以下にＭ（Meta Computation）と表現する。

【００５３】このように処理が移ると、メタオブジエク
ト（MLocalMailer）は、ステップＳＴ１として、フュー
チャ（Future）を生成する。

【００５４】次に、ステップＳＴ２として、メッセージ
（ActiveMessage）を配送する宛て先のオブジェクトの
メッセージキュー（メッセージの並び）の状態を調べ
る。このとき、メッセージキューにメッセージがない場
合（ＦＡＬＳＥ、偽）には、そのオブジェクトは休眠状
態（スケジューラ（Scheduler）が管理している状態で
は休止（Dormant））なので、ステップＳＴ５として、
スケジューラ（Scheduler）にメイクレディ（MakeRead
y）を発行（issue）してオブジェクトを実行可能状態
（スケジューラ（Scheduler）が管理している状態では
レディ（Ready））にする。ここで簡単にメッセージキ
ューについて解説する。図１３に示すように、ＣＰＵは
オブジェクト内の１つのスレッドを実行する際、配送さ
れたメッセージを利用する。メッセージキューはメッセ
ージの並びを示し、メッセージキュー内のメッセージを
順次利用するように構成される。なお、メイクレディ
（MakeReady）はスケジューラ（Scheduler）にそのオブ
ジェクトが実行可能とするために用いられるＡＰＩであ
り、上記レディ（Ready）は実行可能状態を、上記ドー
マント（Dormant）はオブジェクトが休止状態であるこ
とを表す。上記ドーマント（Dormant）時は、オブジェ
クトが何も実行せずメッセージを受信できる状態を表
す。メイクレディ（MakeReady）には、引数としてベー
スオブジェクトを特定する（Thread of base）（この実
施の形態ではオブジェクトＢ）、宛先のメソッド（meth
od）、メッセージ(msg）を持つ。よって、この実施の形
態ではベースオブジェクトＢを指定してメソッドＢにメ
ッセージ（msg）を送るように管理する命令をスケジュ
ーラ（Scheduler）に送ることになる。

【００５５】一方、ステップＳＴ２において、メッセー
ジキューにメッセージがある場合（ＴＲＵＥ、真）に
は、すでにそのメッセージが宛て先のオブジェクトに配
送されて、そのオブジェクトが実行可能状態（レディ
（Ready））、オブジェクトが実行状態（ランニング（R
UNNING））なので、ステップＳＴ４として、メッセージ
キューの最後にそのメッセージを入れて終了する。この
とき、メッセージ送信に対応したフューチャ（Future）
を特定できるフューチャＩＤ(futureID）もあわせてメ
ッセージキューで管理する。なお、これらの状態につい
ては後述する図２８にて説明する。

【００５６】その後は、ステップＳＴ６で配送完了であ
ることを示す返り値サクセス（sSuccess）をメタメッセ
ージ（MetaMessage）に入れ、ベースオブジェクトに状
態遷移を戻す。その後ベースオブジェクトはステップＳ
Ｔ８のように実行或いは実行可能状態となる。ここで、
これ以降、メタオブジェクトからベースオブジェクトへ
状態遷移が戻ることをＲ（Resume）と表す。上記メタメ
ッセージ（MetaMessage）とは、メタスペース(mLocal）
上のベースオブジェクトがセンド（Send）をするとき、
当該センド（Send）に必要なパラメータ（引数）を持っ
たメッセージである。

【００５７】なお、上述したＭ（Meta Computation），
Ｒ（Resume）については、先に示した特願平８−６７８
８１号の明細書及び図面に詳しく示されている。

【００５８】図１０はメタオブジエクト（MLocalMaile
r）によるリプライ（Reply）に関する手続きを示してい
る。

【００５９】この図１０において、初めにステップＳＴ
１１として、メタオブジエクト（MLocalMailer）はどの
ベースオブジェクトがリプライ（Reply）してきたのか
を確認する。図３、図４の例で言えば、ベースオブジェ
クトＢがリプライ（Reply）を発行（issue）することが
確認される。なお、この確認として、本実施の形態では
ＡＰＩの例えば関数GetLast()を使うようにしている
が、ここではどのような方法でもよい。またこのときの
ベースオブジェクトはステップＳＴ２４のようにウェイ
ト（Wait）の状態となる。

【００６０】次に、ステップＳＴ１２からステップＳＴ
１４として、このベースオブジェクトを起動したときに
一緒に配送されたフューチャＩＤ(futureID）が特定す
るフューチャ（Future）が本当にメタスペース（mLoca
l）のフューチャ（Future）かどうか確認する。ステッ
プＳＴ１２，ＳＴ１４で偽と判断されたらエラーとし、
ステップＳＴ２２へ進む。ステップＳＴ１３が偽のとき
は、本実施の形態の主題であるタグを使った通信機構で
他のメタスペースと通信する場合に相当し、後述するメ
タオブジェクト（Deliverer）に処理を依頼する。

【００６１】ステップＳＴ１２からステップＳＴ１４に
おいて、そうであることが確認されたら、ステップＳＴ
１５として、そのフューチャ（Future）の属性（creato
r）の状態を調べる。このとき、属性（creator）はリプ
ライ（Reply）をしたベースオブジェクトにメッセージ
を送ったオブジェクトを含み、図３、図４の例で言えば
リプライ（Reply）をしたベースオブジェクトＢにメッ
セージを送ったオブジェクトはＡであり、領域（Thread
ID Creator）に保存されている。

【００６２】次に、ステップＳＴ１６として、そのオブ
ジェクトが待ち状態（ウェイト（Wait））になっている
かどうかを調べ、そのオブジェクトが待ち状態（ウェイ
ト（Wait））になっている場合は、ステップＳＴ１７の
ようにそのオブジェクトがウェイトフォー（WaitFor）
を実行している場合である。ウェイトフォー（WaitFo
r）の実行は前に図３、図４の説明で述べているよう
に、引数としてフューチャＩＤ（futureID）、返答メッ
セージ（&msg）、サイズ（sizeof(msg)）を有し、いま
扱っているフューチャＩＤ（futureID）とウェイトフォ
ー（WaitFor）に与えられたフューチャＩＤ（futureI
D）は等しく、リプライ（Reply）により送られたメッセ
ージ(msg）が引数（&msg）に与えられる。待ち状態のオ
ブジェクトは前記メイクレディ（MakeReady）によって
再び実行可能状態になる。つまり、図３、図４の例で
は、オブジェクトＡが実行可能状態に復帰する。

【００６３】なお、この場合の宛先のメソッドはウェイ
ト（wait）状態なので、指定は不要だからUNDEF（undef
ine）、メッセージ（msg）も不要なのでＮＵＬＬとされ
ている。

【００６４】一方、ステップＳＴ１６において、属性
（creator）が待ち状態でない場合は、まだウェイトフ
ォー（Waitfor）を実行していない。したがってこのと
き、メタオブジエクト（MLocalMailer）は、ステップＳ
Ｔ１９としてフューチャ（Future）の属性（isReplyDon
e）をセットし、リプライ完了のマークを入れる。さら
に必要に応じてステップＳＴ１８のようにメッセージ
（message）に返答メッセージを一時的に保存する。

【００６５】その後は、ステップＳＴ２０にてフューチ
ャ（Future）を削除し、さらにステップＳＴ２１では配
送完了の返り値サクセス（sSuccess）をメタメッセージ
（MetaMessage）に入れ、ステップＳＴ２２ではエラー
を示す返り値をメタメッセージ（MetaMessage）に入
れ、ステップＳＴ２３では配送完了の返り値サクセス
（sSuccess）をメタメッセージ（MetaMessage）に入れ
る。その後ベースオブジェクトはステップＳＴ２５のよ
うに実行或いは実行可能状態となる。

【００６６】図１１と図１２はウェイトフォー（WaitFo
r）の手順であり、図１１はリプライ（Reply）がウェイ
トフォー（WaitFor）よりも先に実行された場合（図４
の場合）、図１２はその逆（図３の場合）を示してい
る。これらは図１０の説明に対応している。なお、これ
以降、ベースオブジェクトの流れは図示を省略する。

【００６７】図１１において、初めにステップＳＴ３１
ではフューチャ（Future）の確認を行い、ステップＳＴ
３２ではフューチャ（Future）の属性（isReplyDone）
がセットされている（リプライ（Reply）が既に行われ
ている）かどうかの確認を行う。これらステップＳＴ３
１、ＳＴ３２にて共に真（ＴＲＵＥ）とされた時には、
ステップＳＴ３３にてフューチャ（Future）内にセット
された結果、メッセージをウェイトフォー（WaitFor）
のメッセージ（&msg）に入力し、その後は、ステップＳ
Ｔ３４にてフューチャ（Future）を削除し、さらにステ
ップＳＴ３５では配送完了のサクセス（sSuccess）をメ
タメッセージ（MetaMessage）に入れる。ステップＳＴ
３１で偽と判断されたら、ステップＳＴ３６ではエラー
コードをメタメッセージ（MetaMessage）に入れ、Ｒ（R
esume）を行う。なお、ステップＳＴ３２で偽と判断さ
れたら、図１２に示すステップＳＴ４３へ移行する。

【００６８】一方、図１２において、初めにステップＳ
Ｔ４１ではフューチャ（Future）の確認を行い、ステッ
プＳＴ４２ではフューチャ（Future）の属性（isReplyD
one）がセットされていないかどうかの確認を行う。こ
れらステップＳＴ４１、ＳＴ４２にて共に真（ＴＲＵ
Ｅ）とされた時には、ステップＳＴ４３にて待ち状態と
なされ、その後、ステップＳＴ４４ではサクセス（sSuc
cess）をメタメッセージ（MetaMessage）に入れ、ステ
ップＳＴ４５ではメタコール（MetaCall）から送られ
る。ステップＳＴ４１にて偽と判断されたらステップＳ
Ｔ４６にてエラーコードをメタメッセージ（MetaMessag
e）に入れ、Ｒ（Resume）を行う。ステップＳＴ４２に
て偽と判断されたら図１１のステップＳＴ３３へ移行す
る。なお、図１１、図１２の例は共にベースオブジェク
トがメタオブジエクト（MLocalMailer）にウェイトフォ
ー（WaitFor）を依頼し、Ｒ（Resume）されるまでウェ
イト（Wait）の状態となる（図示せず）。

【００６９】［コンティネーション（Continuation）と
メタスペース（mDrive）通信機構の実現方式］図１４か
ら図１８にはメタオブジエクト（MDriveMailer）とスケ
ジューラ（Scheduler）の関係をシナリオによって与え
る。メタオブジエクト（MDriveMailer）はデバイスドラ
イバのためのメタスペースなので、その手続きは前記メ
タオブジエクト（MLocalMailer）に比べてやや複雑であ
る。その一つに遅延実行テーブル（DelayedExecutionTa
ble）がある。メタオブジエクト（MDriveMailer）にお
いてセンド（Send）やキック（Kick）の手続きは、メタ
スペース(mDrive）上のオブジェクトがセンド（Send）
やキック（Kick）を依頼したときに、遅延実行テーブル
（DelayedExecutionTable）への登録だけが行われ、実
際のメッセージの配送は、メソッドの終了時（Exitする
とき）にまとめて行われる。

【００７０】図１４はメタオブジエクト（MDriveMaile
r）におけるセンド（Send）の手続きを示す。

【００７１】この図１４において、ステップＳＴ５１で
は、すでに述べたようにセンド（Send）の処理を遅延実
行テーブル（DelayedExecutionTable）に登録する。す
なわち、当該テーブルにメタメッセージ内の遅延実行用
引数を登録する。ここでは、メタスペース(mDrive）上
のベースオブジェクトがセンド（Send）をするとき、セ
ンド（Send）に必要なパラメータが入った実体としての
メタメッセージ（MetaMessage）が遅延実行テーブル（D
elayedExecutionTable）に登録される。その後、ステッ
プＳＴ５２ではサクセス（sSuccess）をメタメッセージ
（MetaMessage）に入れ、Ｒ（Resume）を行う。

【００７２】ここで、上述のメタメッセージ（MetaMess
age）の構成について簡単に説明する。

【００７３】メタメッセージ（MetaMessage）は図１９
に示すように、２つの領域に分かれ、メタコール（meta
call）のＡＰＩを実行するために必要な情報（例えば引
数）のための領域Ａとエラー用コードを納める領域Ｂと
を有する。なお、遅延実行テーブル（DelayedExecution
Table）は前記図５で示したフューチャ（Future）の生
成と同じく、メイラ(mailer）のオブジェクトがメモリ
内に当該テーブル用の領域を確保することで生成され
る。

【００７４】図１５は、メタオブジエクト（MDriveMail
er）におけるキック（Kick）の手続きである。

【００７５】この図１５において、ステップＳＴ６１で
は、図１４と同様にキック（Kick）の処理を遅延実行テ
ーブル（DelayedExecutionTable）に登録する。その後
は、ステップＳＴ６２にてサクセス（sSuccess）をメタ
メッセージ（MetaMessage）に入れ、Ｒ（Resume）を行
う。

【００７６】図１６はメタオブジエクト（MDriveMaile
r）の終了時（Exit）で、メタスペース(mDrive）上のベ
ースオブジェクトが処理を終了するときに呼び出される
手続きである。ここでは、遅延実行テーブル（DelayedE
xecutionTable）に登録された手続きを、処理の依頼さ
れた順序で実行し、最後にオブジェクトのメソッドの終
了手続きをする。

【００７７】この図１６のおいて、初めにステップＳＴ
７１として、終了（Exit）の手続きを依頼したベースオ
ブジェクトを特定する（例えば関数GetLast()を使って
特定する）。

【００７８】次に、ステップＳＴ７２にて当該ベースオ
ブジェクトが割込みによって起動されたかどうかを調べ
る。すなわち、終了（Exit）メソッドが起動された原因
がベースオブジェクトの割り込みによるものか判断す
る。割り込みで起動された場合、その割り込みの後に更
に別の割り込みがある可能性が考えられる。図２０に示
すように、ベースオブジェクトＩの実行中にベースオブ
ジェクトＩＩが割り込んだ場合、ステップＳＴ７３では
今回の終了（Exit）が当該ベースオブジェクトＩＩの割
り込みの終了（Exit）か否かを判断する。ステップＳＴ
７２、ステップＳＴ７３にて共に真（ＴＲＵＥ）である
と判断された場合は、ステップＳＴ７４にて上記別の割
り込みに戻る（Resume Interrupt）。ステップＳＴ７
２、ステップＳＴ７３で偽と判断されたら、ステップＳ
Ｔ７５のように、遅延実行テーブル（DelayedExecution
Table）に登録された手続きを処理する。この処理につ
いて、センド（Send）については後述する図１７、キッ
ク（Kick）については後述する図１８が示している。

【００７９】上記ステップＳＴ７５の遅延実行テーブル
（DelayedExecutionTable）のための処理を終えると、
ステップＳＴ７６にて再びそのベースオブジェクトが割
込みで起動されたかどうか調べる。このステップＳＴ７
６は、ステップＳＴ７２と実質的に同じである。ここ
で、もし割込みで起動されている場合は、ステップＳＴ
７７にて、そこから復帰するための手続き（ExitFromIn
terrupt（））を実行して最初の割り込みを終了する。
一方、割り込みで起動されていない場合は通常のオブジ
ェクト間通信で起動された場合である。この場合、それ
まで実行していたオブジェクトを休眠状態にするため
に、ステップＳＴ７８にて遅延実行テーブル（DelayedE
xecutionTable）を初期化し、スケジューラ（Schedule
r）に休止（MakeDormant）するようにメッセージを送
る。引数（Base Thread）はステップＳＴ７１で特定さ
れたベースオブジェクトである。さらに、ステップＳＴ
７９にて、そのベースオブジェクトのメッセージキュー
からそれまで実行していたメッセージを取り除く。

【００８０】ここでメッセージキューが空になった場合
はそれで終了である。もしもメッセージキューが空では
なかった場合には、次に配送されるべきメッセージを引
数にして、スケジューラ（Scheduler）に（再び、その
オブジェクトが引数で与えられるメッセージによって起
動されるように）メイクレディ（MakeReady）を発行（i
ssue）し、次のメッセージのためにそのオブジェクトを
実行可能状態（Ready）にする。

【００８１】次に、図１７と図１８には、遅延実行テー
ブル（DelayedExecutionTable）に登録された手続きの
一つを処理するシナリオを示す。当該テーブルに例えば
１０個が発行されれば１０回実行が行われる。メッセー
ジの有無によるスケジューラ（Scheduler）への依頼事
項はメタオブジエクト（MLocalMailer）の場合と同じで
ある。

【００８２】図１７におけるメタオブジエクト（MDrive
Mailer）のセンド（Send）の場合は、先ず、ステップＳ
Ｔ８１にてコンティネーション（Continuation）を生成
する。

【００８３】次のステップＳＴ８２にてメッセージの宛
先がメタスペース(mDrive）オブジェクトか判断する。
もし偽であれば、後述するメタオブジエクト（Delivere
r）に処理の依頼を行わない、タグ通信が行われる。ス
テップＳＴ８３ではメッセージ（ActiveMessage）を配
送する宛て先のオブジェクトのメッセージキューの状態
を調べる。このとき、メッセージキューにメッセージが
ない場合には、そのオブジェクトは休眠状態（スケジュ
ーラ（Scheduler）が管理している状態では休止（Dorma
nt））なので、ステップＳＴ８５として、スケジューラ
（Scheduler）にメイクレディ（MakeReady）を発行（is
sue）してオブジェクトを実行可能状態（スケジューラ
（Scheduler）が管理している状態ではレディ（Read
y））にする。

【００８４】一方、ステップＳＴ８２及びステップＳＴ
８３において、真の場合には、すでにそのメッセージが
宛て先のオブジェクトに配送されて、そのオブジェクト
が実行可能状態、実行状態（RUNNING）、または実行中
断状態（Suspend）なので、ステップＳＴ８４として、
メッセージキューの最後にそのメッセージを入れて終了
する。このとき、メッセージ送信に対応したコンティネ
ーション（Continuation）或いはそれを指し示すＴＩＤ
（後述する）もあわせてメッセージキューで管理する。

【００８５】図１８におけるメタオブジエクト（MDrive
Mailer）のキック（Kick）の場合は、ステップＳＴ９１
において、与えられたコンティネーション（Continuati
on）がメタオブジエクト（MDriveMailer）のコンティネ
ーション（Continuation）なのかどうかを確認する。ス
テップＳＴ９１が真の場合はステップＳＴ９２にてコン
ティネーション（Continuation）の存在を確認する。こ
のコンティネーションが確認されたら、ステップＳＴ９
３で当該コンティネーション（Continuation）を開き、
コンティネーション内の属性（宛先、メソッド、メッセ
ージ（msg））をチェックし、それに基づいてセンド（S
end）を行う。次のステップＳＴ９４にてメッセージの
確認を行い、ステップＳＴ９５では、メッセージキュー
の最後にそのメッセージを入れて終了する。このとき、
メッセージ送信に対応した後述するタグＩＤ(TID）もあ
わせてメッセージキューで管理する。

【００８６】一方、ステップＳＴ９２、ＳＴ９４にて、
そうでないとされた場合は、ステップＳＴ９６にてスケ
ジューラ（Scheduler）にメイクレディ（MakeReady）を
発行してオブジェクトを実行可能状態にする。なお、ス
テップＳＴ９４、ＳＴ９５、ＳＴ９６は、図１７のステ
ップＳＴ８３、ＳＴ８４、ＳＴ８５と同様の機能であ
る。ステップＳＴ９１で偽と判断されたら、後述するタ
グを使った通信機構で他のメタスペースと通信する場合
に相当し、メタオブジェクト（Deliverer）に処理の依
頼を行う。

【００８７】「タグを使った通信機構の基本的な説明」
オブジェクト間通信をするには、単純なメッセージ送信
の他に、返答を受け取ったり他のメソッドの実行と同期
をとることが必要になる。このとき、フューチャ（Futu
re）やコンティネーション（Continuatin）のようなも
のが必要になる。このような複数のオブジェクト間通信
（本実施の形態ではフューチャやコンティネーション
等）で必要とされる同期や並行性を制御するデータ構造
を本実施の形態ではタグと呼ぶ。ここでいうデータ構造
とは例えばＣ言語やＰＡＳＣＡＬでいうところのStruct
ureやＣ＋＋でいうClassのような構造を示す。このタグ
とは異なるデータ構造をある共通のデータ構造で関連付
けるものであり、この共通のデータ構造はこれらの異な
るデータ構造を区別するための識別子（属性：例えばEx
ecSpaceID mailer）を含むように構成される。さらに、
同種類のデータ構造間の区別を与えるための識別子（属
性：例えばlongword timeStamp）を有することでより多
くのデータ構造が管理できる。詳細は図２１の説明時に
行う。また、タグを識別するために必要なＩＤをタグＩ
Ｄ（TID）と呼ぶ。

【００８８】ここで、タグの属性としてタグの型が必要
になる。タグの型はそのタグがどの環境で使われるどの
ようをものかを特定できる必要がある。ただし、タグの
型はグローバルに認識ができるものである必要はない。
ある環境でそのタグの型を特定できなかった場合には、
そのタグの型を特定できる他の独立したオブジェクトに
問い合わせなどを行なうことでそれを解決することがで
きればよい。

【００８９】ここでは、メタスペース（mLocal）とメタ
スペース（mDrive）におけるフューチャ（Future）、コ
ンティネーション（Continuation）の例を使って、タグ
を使った異なるメタスペース間の通信について述べる。
本実施の形態の例では、メタスペース（mLocal）にオブ
ジェクトＡ、メタスペース(mDrive）にオブジェクトＢ
が存在し、それぞれ前述同様に、以下のようなメソッド
が定義されているとする。

【００９０】オブジェクトＡ メソッドＡ１（A::A1） オブジェクトＢ メソッドＢ１（B::B1） メソッドＢ２（B::B2） このとき、以下の二通りについて、タグを使った異なる
メタスペース間通信の基本的な動作について述べる。

【００９１】１．オブジェクトＡ（メソッドＡ１（A::A
1））がメソッドＢ１（B::B1）にセンド及びウェイトフ
ォー（Send＋WaitFor）する場合 ２．オブジェクトＢ（メソッドＢ１（B::B1））がメソ
ッドＡ１（A::A1）にセンド（Send）し、継続メソッド
としてメソッドＢ２（B::B2）を指定した場合 ［オブジェクトＡ（メソッドＡ１（A::A1））がメソッ
ドＢ１（B::B1）にセンド及びウェイトフォー（Send＋W
aitFor）する場合］メソッドＡ１（A::A1）はセンド（S
end）（オブジェクトＢ，メソッドＢ1，メッセージ（ma
g）,関数sizeof(msg)，フューチャＩＤ(futureID））を
実行する。このとき、実際にこの手続きを処理するメタ
オブジエクト（MLocalMailer）はフューチャ（Future）
を生成する。フューチャ（Future）は次の要件を満たし
ていればよい。すなわち、フューチャ（Future）がタグ
ＩＤで特定できるユニークな実体であること、タグの型
がメタスペース（mLocal）のフューチャ（Future）であ
ることを示すこと、及び図６で示したフューチャ（Futu
re）の属性を持っていること。

【００９２】メタオブジエクト（MLocalMailer）は、な
んらかの方法でメタオブジエクト（MDriveMailer）にメ
ッセージ（msg）をオブジェクトＢまで配送するように
依頼すると共に、メソッドＢ１（B::B1）を起動するよ
うに依頼をする。このとき、フューチャ（Future）を特
定することができるタグＩＤをあわせて配送する。ま
た、このときそのフューチャ（Future）を後に特定する
ことができるようにフューチャＩＤ(futureID）を受け
取る。ここではその型の変数をフューチャＩＤ(futureI
D）としている。このＩＤは、タグＩＤをメタスペース
（mLocal）の仕様にあわせてマップしたものであると考
えられる。

【００９３】オブジェクトＢは、そのメッセージ（ms
g）によってメソッドＢ１（B::B1）が起動されたとき、
そのメッセージがどこから配送されたかを知ることはで
きない（或いは知るべきではない）。これが透明性のあ
るオブジェクト間通信の実現で要求される。メソッドＢ
１（B::B1）は起動されるときに、コンティネーション
（Continuation）がメッセージ（msg）といっしょに配
送される。コンティネーション（Continuation）は型
（コンティネーションＩＤ（contID））として扱い、こ
こではその変数を（contID）とする。この変数（contI
D）は先のフューチャＩＤ(futureID）と同じタグを特定
していることになる。

【００９４】メソッドＢ１（B::B1）の実行が進むとキ
ック（Kick（contID））を実行する。このとき、メタオ
ブジエクト（MDriveMailer）はコンティネーションＩＤ
（変数contID）で特定できるタグの型をチェックする。
このとき、タグＩＤの管理方式の観点から、次の二つの
可能性がある。

【００９５】１．メタオブジエクト（MDriveMailer）が
コンティネーションＩＤ（contID）で特定できるタグの
型をメタスペース（mLocal）のフューチャ（Future）で
あるとわかる場合（タグＩＤの管理方式（1）） ２．メタオブジエクト（MDriveMailer）がコンティネー
ションＩＤ（contID）で特定できるタグの型を知ること
ができない場合（タグＩＤの管理方式（2）） 前者の場合、メタオブジエクト（MDriveMailer）はなん
らかの方法でメタオブジエクト（MLocalMailer）に直接
タグＩＤを配送することができる。メタオブジエクト
（MLocalMailer）はタグＩＤが配送されると、それはメ
タスペース（mLocal）上でリプライ（Reply()）が行わ
れるのとまったく同じように処理を進めることができ
る。すなわち、タグＩＤ（＝フューチャＩＤ(futureI
D））に対応したフューチャ（Future）に対して、図１
０で示したシナリオと同様にメソッドＡ１（A::A1）の
実行を再開させたり、返答メッセージをフューチャ（Fu
ture）に一時的に保存しておくことができる。

【００９６】後者の場合、タグＩＤをメタオブジエクト
（MLocalMailer）に配送する方法として、次の方法が考
えられる。

【００９７】１．タグの型を管理している別のオブジェ
クトがあり、そのオブジェクトはタグＩＤを与えるとそ
のタグＩＤの型を調べ、そのタグを処理できるＡＰＩと
してのメイラ（Mailer）を教えてくれるメソッドを用意
する。メタオブジエクト（MDriveMailer）はこのメソッ
ドを利用して、そのタグＩＤをメタオブジエクト（MLoc
alMailer）に配送すればよいことを知ることができ、直
接メタオブジエクト（MLocalMailer）にタグＩＤを配送
する方法（タグＩＤの管理方式（2A）） ２．タグの型を管理している別のオブジェクトがあり、
そのオブジェクトは与えられたタグＩＤを直接それに対
応したタグを処理できるメイラ（Mailer）に配送してく
れる方法（タグＩＤの管理方式（2B）） これらの場合も、最終的にはメタオブジエクト（MLocal
Mailer）にタグＩＤが配送され、図１０で示したシナリ
オと同様にメソッドＡ１（A::A1）の実行を再開させた
り、返答メッセージをフューチャ（Future）に一時的に
保存しておくことができる。

【００９８】[オブジェクトＢ（メソッドＢ１（B::B
1））がメソッドＡ１（A::A1）にセンド（Send）し、継
続メソッドとしてメソッドＢ２（B::B2）を指定した場
合］メソッドＢ１（B::B1）はセンド（オブジェクト
Ａ，メソッドＡ１，メッセージ（msg），関数（sizeof
(msg)），メソッドＢ２、メッセージ（contMsg））を実
行する。このとき、実際にこの手続きを処理するメタオ
ブジエクト（MDriveMailer）はコンティネーション（Co
ntinuation）を生成する。コンティネーション（Contin
uation）は次の用件を満たすことになる。

【００９９】コンティネーション（Continuation）がタ
グＩＤで特定できるユニークな実体であること、タグの
型がメタスペース（mDrive）のコンティネーション（Co
ntinuation）であることを示すこと、及び図８で示した
コンティネーション（Continuation）の属性を持ってい
ること。

【０１００】メタオブジエクト（MDriveMailer）を含む
ＯＳは、なんらかの方法でメタオブジエクト（MLocalMa
iler）にメッセージ（msg）をオブジェクトＡに配送
し、メソッドＡ１を起動するように依頼する。このと
き、コンティネーション（Continuation）を特定するこ
とができるタグＩＤをあわせて配送する。

【０１０１】メタスペース(mDrive）の通常のオブジェ
クト間通信では、このタグＩＤはコンティネーションＩ
Ｄ（ContID）として扱われるものになる。しかし、この
場合はメタオブジエクト（MLocalMailer）ではそれをコ
ンティネーションＩＤ（ContID）として扱う必要はな
く、タグＩＤとして扱う。そして、メタスペース（mLoc
al）の通常のオブジェクト間通信ではメッセージを配送
してあるメソッドを起動すると、それにフューチャ（Fu
ture）（またはフューチャＩＤ(futureID））が関係付
けられるのと同様に、メタオブジエクト（MDriveMaile
r）から配送されたタグＩＤが関係付けられる。

【０１０２】メソッドＡ１（A::A1）の実行が進むとリ
プライ（Reply()またはReply（ReplyMsg））を実行す
る。このとき、メタオブジエクト（MLocalMailer）はメ
ソッドＡ１（A::A1）を起動したときに関係付けられた
タグＩＤを調べ、タグＩＤが特定するタグの型をチェッ
クする。このとき、メタスペース（mLocal）上のオブジ
ェクトＡからメタスペース(mDrive）上のオブジェクト
Ｂに通信した場合と同様に、タグＩＤの管理方式の観点
から、次の二つの可能性がある。

【０１０３】１．メタオブジエクト（MLocalMailer）が
タグＩＤで特定できるタグの型をメタスペース(mDriv
e）のコンティネーション（Continuation）であるとわ
かる場合（タグＩＤの管理方式（１）） ２．メタオブジエクト（MLocalMailer）がタグＩＤで特
定できるタグの型を知ることができない場合（タグＩＤ
の管理方式（２）） いずれの場合においても、メタスペース（mLocal）上の
オブジェクトＡからメタスペース(mDrive）上のオブジ
ェクトＢに通信した場合と同様、なんらかの方法でメタ
オブジエクト（MDriveMailer）にタグＩＤを配送でき
る。メタオブジエクト（MDriveMailer）はタグＩＤを受
け取ると、図１８で示したシナリオと同様の手続きを行
なう。すなわち、はじめにタグＩＤに対応したコンティ
ネーション（Continuation）を開き（Open）し、継続メ
ソッドと継続メッセージを得る。そして、継続メソッド
を配送するべきオブジェクト（コンティネーション（Co
ntinuation）のクリエータ（creator））のメッセージ
キューの状態に応じて、スケジューラ（Scheduler）を
アクセスし、最終的にメソッドＢ２（B::B2）を起動す
る。

【０１０４】「タグを使った通信機構の本実施の形態で
の実現事例」本章では、本実施の形態において、タグを
使ってそれぞれメタスペース（mLocal）、メタスペース
(mDrive）に存在するオプジェクドが透明性を持って通
信することを可能にした実現方式について述べる。ここ
では異なる通信機構としてメタスペース（mLocal）通信
機構とメタスペース(mDrive）通信機構の二つのみが存
在することを仮定する。

【０１０５】［フューチャ（Future），コンティネーシ
ョン（Continuation）とタグ（Tag）］メタスペース（m
Local）におけるフューチャ（Future）、メタスペース
(mDrive）におけるコンティネーション（Continuatio
n）を、ＯＳではタグ（Tag）として扱うことが可能であ
る。このとき、ＯＳはタグ（Tag）がフューチャ（Futur
e）であるかコンティネーション（Continuation）であ
るかを識別する必要がある。それを識別するための型と
してＡＰＩのメイラ（Mailer）のＩＤを使う。タグの型
として使われるメイラＩＤ（MailerID）がメタオブジエ
クト（MLocalMailer）の場合にはフューチャ（Futur
e）、メタオブジエクト（MDriveMailer）の場合にはコ
ンティネーション（Continuation）であると認識するこ
とができる。

【０１０６】図２１はタグ（Tag）とフューチャ（Futur
e）、コンティネーション（Continuation）の関係、タ
グ（Tag）とタグＩＤ（TID）の関係をいわゆるＯＭＴ
（object modeling technique）法のオブジェクトモ
デル図で示している。クラスフューチャＣ１と、クラス
コンティネーションＣ２はクラスタグＣ３から派生した
サブクラスとして定義できる。タグ（Tag）はメイラ（M
ailer）を識別するＩＤとして実行場所ＩＤ（ExecSpace
ID）を使っている。この場合、実行場所ＩＤ（ExecSpac
eID）は、そのオブジェクトを示すＩＤと等価な意味で
使われている。タグ（Tag）はタグＩＤ（TID）というＩ
Ｄによって特定できる。タグ（Tag）に含まれるタイム
スタンプ（timeStamp）はタグ（Tag）をタグＩＤ（TI
D）を使って特定するとき時間軸に対してユニークであ
ることを保証するために使用される。フューチャ（Futu
re）およびコンティネーション（Continuation）を特定
することができれば、タイムスタンプ（timeStamp）は
必ずしも使われる必要はない。

【０１０７】メタスペース（mLocal）通信機構、メタス
ペース(mDrive）通信機構ではそれぞれフューチャ（Fut
ure）、コンティネーション（Continuation）を特定す
るためにフューチャＩＤ(futureID）、コンティネーシ
ョンＩＤ（ContID）が使われる。タグ（Tag）を導入し
た場合、ＯＳ内ではこれらはすべて共通に表記されるこ
とのできるタグＩＤ（TID）として特定することができ
る。

【０１０８】本実施の形態では、プログラマがメタスペ
ース（mLocal）やメタスペース(mDrive）を提供してい
るインターフェースをそのまま使用することができるよ
うに、インターフェースを定義しているへッダフアイル
（MLocal.h、MDrive.h）では型の再定義が行われてい
る。すなわち、メタスペース（mLocal）のへッダフアイ
ル（MLocal.h）ではフューチャＩＤ(futureID）をタグ
ＩＤに再定義する。これを例えばＣ言語やＣ＋＋の定義
方法で示すと、typedef TID futureID；となる。な
お、typedefは新しい型を定義（define）すると言う意
味である。メタスペース(mDrive）のヘッダファイル（M
Drive.h）のコンティネーションヘッダファイル（Cont.
h）ではコンティネーションＩＤ（ContID）をタグＩＤ
に再定義している。これも同様に示すと、typedef TID
ContID；となる。

【０１０９】［タグＩＤの管理方式と当該タグＩＤを配
送するオブジェクト（Deliverer）］本実施の形態で
は、前記タグＩＤの管理方式（2B）を適用している。異
なるメタスペース間の通信機構をサポートするメタオブ
ジェクトとして、Delivererを導入する。オブジェクト
（Deliverer）は主に二つのインターフェース（メソッ
ド或いはＡＰＩ）を持つ。

【０１１０】すなわち、その一つであるインターフェー
ス（sError DeliverObject）は、メッセージ（msg）を
指定されたオブジェクト（destination）（引数オブジ
ェクトＩＤ（ＯＩＤ）及び宛先メソッド（sel）で示さ
れる。）に配送し、最終的にオブジェクト（destinatio
n）のメソッド（method）が起動されるよう、オブジェ
クト（destination）が存在するメタスペースのメイラ
（Mailer）に依頼をする。このインターフェース（sErr
or DeliverObject）は更に、引数の一つとして配送され
るタグＩＤ（TID）を、オブジェクト（destination）が
返答する場合に使用する。

【０１１１】もう一方のインターフェース（sError Del
ivereTag）は、タグＩＤ（TID）を配送する。オブジェ
クト（deliverer）はタグＩＤ（TID）に対応したタグ
（Tag）の型を調べ、どのメイラ（Mailer）にタグＩＤ
（TID）を配送すればよいかを知る。必要に応じて、返
答メッセージ（replyMsg）も配送する。

【０１１２】相手先オブジェクト（Deliverer destinat
ion）が存在するメタスペースのメイラ（Mailer）を知
る方法としては、 １．オブジェクトの生成時にあらかじめオブジェクト
（deliverer）に登録をして、オブジェクト（delivere
r）がその内容を（テーブルなどを使って）管理する方
法 ２．オブジェクトから直接たどることができるデータ構
造に、そのオブジェクトが所属しているメタスペースま
たはメタスペースを識別できるなにかのＩＤを含めてお
く方法 が考えられる。本実施の形態では、後者の方法を使って
いる。

【０１１３】［異なるメタスペース間通信の実際］この
異なるメタスペース間通信では、以下の二つの異なるメ
タスペース間通信（異なるメタスペースに存在するオブ
ジェクト間通信）が考えられる。

【０１１４】Ａ．メタスペース（mLocal）オブジェクト
がメタスペース(mDrive）オブジェクトと通信する（或
いは通信して返答を受け取る）場合 Ｂ．メタスペース(mDrive）オブジェクトがメタスペー
ス（mLocal）オブジェクトに通信する（或いは通信して
返答を受け取る）場合 図２２と図２３は、オブジェクト（deliverer）を介し
て異なるメタスペース（メタスペース（mLocal）とメタ
スペース(mDrive））間通信を行なう場合の前者Ａを、
図２４と図２５は後者Ｂのシナリオを示している。

【０１１５】図２２において、メタオブジエクト（MLoc
alMailer）がベースオブジェクトのセンド（Send）の手
続きの依頼を受け付けてからフューチャ（Future）を生
成する処理（ステップＳＴ１０１）までは、図９と同様
である。但し、このフューチャ（Future）はタグのサブ
クラスとして生成される。

【０１１６】ここで、ステップＳＴ１０２では、メッセ
ージの配送先の確認を行い、メッセージの配送先がメタ
スペース（mLocal）オブジェクトではない場合、オブジ
ェクト（Deliverer）のメソッド（DeliverObject）にメ
ッセージを送る。

【０１１７】オブジェクト（Deliverer）はメソッド（D
eliverObject）の引数にてその配送先を知ることができ
るので、ステップＳＴ１０３のように、そのメイラ（MD
riveMailer）にさらに配送する。ステップＳＴ１０６以
降に示す、メタオブジエクト（MDriveMailer）がインタ
ーフェース（DeliverObject）を通じて配送依頼された
後の手続き（ステップＳＴ１０６、ＳＴ１０７、ＳＴ１
０８）は、前述した図１７のメタオブジエクト（MDrive
Mailer）が終了時（Exit）にセンド（Send）のために行
なう手続き（ステップＳＴ８３、ＳＴ８４、ＳＴ８５）
と同様である。但し、この場合はステップＳＴ１０７に
てメッセージキューにタグＩＤ(TID）を加えるようにな
っている。

【０１１８】図２３はメタスペース(mDrive）に配送さ
れたタグＩＤ（TID）がメタスペース(mDrive）ではコン
ティネーションＩＤ（ContID）として扱われて、これを
キック（Kick）した場合の手続きを示している。

【０１１９】この図２３において、メタオブジエクト
（MDriveMailer）は、ステップＳＴ１１１にて終了時
（Exit）のキック（Kick）のための処理時に指定された
コンティネーションＩＤ（ContID）がメタスペース(mDr
ive）のコンティネーション（Continuation）のもので
はないとわかる。そこでオブジェクト（Deliverer）の
タグ（DeliverTag）を使ってタグＩＤ（TID）を配送す
る。

【０１２０】オブジェクト（Deliverer）はステップＳ
Ｔ１１２にてタグＩＤ（TID）からタグ（Tag）を特定
し、その属性（ExecSpaceID meiler）から、そのタグ
（Tag）がメタオブジエクト（MLocalMailer）のもの
（メタスペース（mLocal）のフューチャ（Future））と
わかる。そこでメタオブジエクト（MLocalMailer）にそ
のタグＩＤ（TID）を配送する。

【０１２１】メタオブジエクト（MLocalMailer）がタグ
ＩＤ（TID）を受け取った後の手続きは、前述した図１
０のメタオブジエクト（MLocalMailer）のリプライ（Re
ply）と同様である（ステップＳＴ１３が真であった場
合以降ステップＳＴ１４、ＳＴ１５、ＳＴ１６、ＳＴ１
７、ＳＴ２０まで）。

【０１２２】一方、図２４、図２５はメタスペース(mDr
ive）からメタスペース（mLocal）にメッセージを送信
し、返答を受け取る場合のシナリオである。オブジェク
ト（Deliverer）の動作は図２２、図２３と同様であ
る。

【０１２３】すなわち、図２４の例では、メタオブジエ
クト（MDriveMailer）がベースオブジェクトのセンド
（Send）の手続きの依頼を受け付けてからコンティネー
ション（Continuation）を生成する処理（ステップＳＴ
１２１）は、図１７と同様である。

【０１２４】ここで、ステップＳＴ１２２では、メッセ
ージの配送先の確認を行い、メッセージの配送先がメタ
スペース（mDrive）オブジェクトではない場合、オブジ
ェクト（mMLocal）のメソッド（DeliverObject）にメッ
セージを送る。

【０１２５】オブジェクト（Deliver）はその配送先を
知ることができるので、ステップＳＴ１２３のように、
そのメイラ（MLocaMailer）にさらに配送する。ステッ
プＳＴ１２６、ＳＴ１２７、ＳＴ１２８に示す、メタオ
ブジエクト（MLocalMailer）がインターフェース（Deli
verObject）を通じて配送依頼された後の手続きは、前
述した図１８のメタオブジエクト（MDriveMailer）が終
了時（Exit）にセンド（Send）のために行なう手続き
（ステップＳＴ９４、ＳＴ９５、ＳＴ９６）と同様であ
る。

【０１２６】また、図２５において、メタオブジエクト
（MLocalMailer）は、ステップＳＴ１３１からステップ
ＳＴ１３４にて終了時（Exit）のキック（Kick）のため
の処理時に指定されたフューチャＩＤ（futureID）がメ
タスペース(mLocal）のフューチャ（Future）のもので
はないとわかる（図１０のステップＳＴ１１、ＳＴ１
２、ＳＴ１３と同様）。そこでオブジェクト（Delivere
r）のタグ（DeliverTag）を使ってタグＩＤ（TID）を配
送する（図１０のステップＳＴ１３の偽の場合と同
じ）。

【０１２７】オブジェクト（Deliver）はステップＳＴ
１３５にてタグＩＤ（TID）からタグ（Tag）を特定し、
その属性（ExecSpaceID meiler）から、そのタグ（Ta
g）がメタオブジエクト（MDriveMailer）のもの（メタ
スペース（mDrive）のコンティネーション（Continuati
on）とわかる。そこでメタオブジエクト（MDriveMaile
r）にそのタグＩＤ（TID）を配送する。

【０１２８】メタオブジエクト（MDriveMailer）がタグ
ＩＤ（TID）を受け取った後の手続き（ステップＳＴ１
３８以降）は、前述した図１８のメタオブジエクト（MD
riveMailer）の処理（ステップＳＴ９３、ＳＴ９４、Ｓ
Ｔ９５、ＳＴ９６）と同様である。

【０１２９】「その他に考えられる実現方式」本章では
これまでに説明した実施の形態での実現方式以外に考え
られる「タグを使った通信機構」の実現方式について述
べる。

【０１３０】［タグＩＤでタグの型を認識する方式］本
実施の形態では、タグ（Tag）の属性としてメイラ（Mai
ler）のＩＤを持っている。これによってタグ（Tag）の
型を識別した。つまり、タグＩＤ（TID）からタグ（Ta
g）を特定し、その属性からタグの型を認識した。別の
方法ではタグＩＤにタグの型を認識するための情報を付
加する方式である。いまタグＩＤが３２ビットで表わさ
れる整数値だとした場合、例えば下位２ビットをタグ
（Tag）の型のために使うという方式が考えられる。図
２６には、タグＩＤでタグの型を認証する方式の一例を
表す。すなわちこの図２６では、下位２ビットの組み合
わせが００のときにはメタスペース（mLocal）のフュー
チャ（Future）を表すものとし、下位２ビットの組み合
わせが０１のときにはメタスペース（mDrive）のコンテ
ィネーション（Continuation）を表すものとする。この
ようにタグの実体を用いずにタグＩＤ（TID）にみを発
生させて、このタグＩＤ（TID）にタグの属性を含めた
ＯＭＴを図２１に対して図２７として示す。なお、図２
７中の指示符号Ｃ１，Ｃ２は図２１と同じものである。
このようにすれば、タグを介することなくフューチャや
コンティネーションを対応付けることができる。この場
合は、タグの領域をメモリ内に確保する必要がないの
で、メモリ領域を削減できる利益がある。なお、本実施
の形態ではタグの下位２ビットを利用する例を述べた
が、１ビット或いは上位、中位の任意のビットを用いて
も良いことは勿論である。

【０１３１】［タグの管理方式］本実施の形態では、前
述したようにタグの管理方式（１）、（２Ａ）、（２
Ｂ）の可能性を示したが、いずれの方式もタグにはその
属性として型があり、メイラ（Mailer）はその型を調べ
ることで少なくともそのメイラ（Mailer）自身が処理で
きるタグかどうかを判断する方式について述べた。これ
らとは別に、タグの属性には型を持たせずに、ただその
メイラ（Mailer）が処理できるタグをメイラ（Mailer）
内部に情報として管理するという方式が考えられる。

【０１３２】この方式では、メイラ（Mailer）がフュー
チャ（Future）やコンティネーション（Continuation）
を生成したら、その情報をメイラ（Mailer）自身が持つ
テーブルなどに保存する。リプライ（Reply）やキック
（Kick）でタグを配送するとき、メイラ（Mailer）はそ
のテーブルを走査し、そのタグがそのメイラ（Mailer）
で処理できる場合は通常のリプライ（Reply）、キック
（Kick）の処理を行なう。そうでない場合は、タグの管
理方式（２Ａ）のように、どのメイラ（Mailer）にタグ
を配送すればよいか問い合わせたり、（２Ｂ）のように
他のオブジェクトに処理の続きを依頼することができ
る。

【０１３３】この場合、メイラ（Mailer）以外に（オブ
ジェクト（Deliverer）のような）タグＩＤとそれに対
応したタグを処理できるメイラ（Mailer）を知ることが
できるオブジェクトも、タグの属性としての型がない場
合には、テーブルなどでその対応を管理する必要があ
る。

【０１３４】図２８には、スケジューラ（Scheduler）
におけるスレッド（Thread）の状態遷移図を示し、以下
にスケジューラ（Scheduler）の仕様の例を示す。

【０１３５】各スレッド（Thread）は実行制御のために
各状態を呈する。スケジューラ（Scheduler）はこれら
スレッド（Thread）の状態変化を司り、優先順位のよう
な属性（attribute）に基づいて次にどのスレッドを実
行すべきかを決定する。

【０１３６】休止状態（Dormant）はそのスレッド（Thr
ead）に関して実行されるべきものが無いことを示す、
このときのメッセージ（message）は受信可能の状態に
ある。

【０１３７】実行可能状態（Ready）は、そのスレッド
（Thread）は実行可能状態にあることを示し、スケジュ
ーラ（Scheduler）内の実行可能状態のスレッド（Threa
d）のためのキュー（レディキュー（Rdady Queus））に
入れられる（enqueue）。スレッド（Thread）が実行可
能状態（Ready）のときそのスレッド（Thread）に対応
付けられたオブジェクトはＭ（Meta Computation）で呼
び起こされる。

【０１３８】実行状態（Running）はそのスレッド（Thr
ead）は実行中であることを示す。

【０１３９】待機状態（Wait）は、オブジェクトの実行
中断状態を示し、例えば前述のメタスペース（mLocal）
通信機能によってウェイトフォー（WaitFor）がリプラ
イ（Reply）よりも先に発行された場合に生ずる。

【０１４０】ここでインターフェース（ＡＰＩ）の例を
いくつか示す。

【０１４１】sError MakeReady(thread,sel,msg) このインターフェース（ＡＰＩ）はスレッド（Thread）
によりリンクされた宛先オブジェクトのセレクタ（se
l）で指定されるメソッドにメッセージ(msg）を送るた
めにメーラメタオブジェクト（例えば前述のメタオブジ
ェクト（MLocalMailer））により使用される。

【０１４２】スケジューラ（Scheduler）はスレッド（T
hread）の状態を休止状態（Dormant）から実行可能状態
（Ready）に遷移させ、上記レディキュー（Rdady Queu
s）内の列にそれを入れる（enqueue）。

【０１４３】宛先オブジェクトはスレッド（Thread）が
スケジュールされた時、すなわち上記スケジューラ（Sc
heduler）により実行可能状態（Ready）のスレッド（Th
read）が実行されるときに呼び起こされる。

【０１４４】なお、sErrorはインターフェースの実行結
果の状態を示し、メイクレディ（MakeReady）が正しく
動作した場合、それを示す返り値（sSuccess）を返す。
そうでない場合は各種のエラーを示す値を返す。

【０１４５】sError MakeReady(thread) このインターフェース（ＡＰＩ）はスレッド（Thread）
の実行を開始するためにメーラによって使用される。ス
ケジューラ（Scheduler）はスレッド（Thread）の状態
を待機状態（Wait）から実行可能状態（Ready）に変化
させ、レディキュー（Rdady Queus）内の列にそれを入
れる（enqueue）。このインターフェースは例えば前述
のメタスペース（mLocal）通信機能によってウェイトフ
ォー（WaitFor）を発行して待機状態（Wait）にあるオ
ブジェクトが、別のオブジェクトの発行したリプライ
（Reply）によって結果メッセージを受け取り、実行可
能状態にする必要があるときに使われる。

【０１４６】sError MakeWait(thread) このインターフェース（ＡＰＩ）はスレッド（Thread）
の実行を停止するために利用される。スケジューラ（Sc
heduler）はスレッド（Thread）を実行可能状態（Read
y）から待機状態（Wait）に遷移させ、レディキュー（R
dady Queus）内の列からそれを除く（dequeue）。な
お、上記各メーラはベースオブジェクトの実行停止のた
め、このインターフェースを呼び出す必要はない。なぜ
ならば、ベースオブジェクトが上述のＭ（Meta Computa
tion）を使ってメーラを呼び起こす時にその状態は待機
状態（Wait）に変化しているからである。

【０１４７】sError MakeDormant(thread) このインターフェース（ＡＰＩ）はスレッド（Thread）
の実行を終了するために上記メーラによって利用され
る。スケジューラ（Scheduler）はスレッド（Thread）
の状態を実行可能状態（Ready）から休止状態（Dorman
t）に変化させ、レディキュー（Rdady Queus）内の列か
らそれを除く（dequeue）。

【０１４８】なお、上記メーラ（mailer）からみたオブ
ジェクト（又はそれに関連付けられたスレッド）の状態
は、休止状態（Dormant）、実行可能状態（Ready）、待
機状態（Wait）の３つである。これは複数の実行可能状
態にあるオブジェクトのうち、どのオブジェクトをＣＰ
Ｕが処理している（Running）かどうか、メイラは知る
必要がないからである。

【０１４９】

【発明の効果】本発明によれば、異なる性質或いはイン
ターフェースを持った通信機構がそれぞれ固有に持つオ
ブジェクト間通信の同期及び並行性の制御を行うための
タグを導入することによって、異なる環境間のオブジェ
クト間通信を透明性をもって容易に実現することができ
る。

【図面の簡単な説明】

【図１】本発明実施の形態のデータ通信方法が適用され
るＶＣＲ装置の概略構成を示すブロック回路図である。

【図２】本実施の形態のＶＣＲ装置と通信用ＯＳ、ＡＶ
用ＯＳとＡＰＩにより通信が行われる様子の説明に用い
る図である。

【図３】メタスペース（mLocal）通信機構（ウェイトフ
ォー（WaitFor）がリプライ（Replay）よりも先に実行
された場合）の説明に用いる図である。

【図４】メタスペース（mLocal）通信機構（リプライ
（Replay）がウェイトフォー（WaitFor）よりも先に実
行された場合）の説明に用いる図である。

【図５】アプリケーションソフトがＡＰＩによってメイ
ラのオブジェクトやスケジューラのオブジェクトに通信
を行う様子の説明に用いる図である。

【図６】フューチャ（Future）の属性の説明に用いる図
である。

【図７】メタスペース（mDrive）通信機構の説明に用い
る図である。

【図８】コンティネーション（Continuation）の属性の
説明に用いる図である。

【図９】メタオブジエクト（MLocalMailer）とスケジュ
ーラ（Scheduler）の関係（メタスペース（mLocal）に
おけるセンド（Send）の実現）の手続きの流れを示す図
である。

【図１０】メタオブジエクト（MLocalMailer）とスケジ
ューラ（Scheduler）の関係（メタスペース（mLocal）
におけるリプライ（Replay）の実現）の手続きの流れを
示す図である。

【図１１】メタオブジエクト（MLocalMailer）とスケジ
ューラ（Scheduler）の関係（メタスペース（mLocal）
におけるウェイトフォー（WaitFor）でリプライ（Repla
y）がウェイトフォー（WaitFor）よりも先に実行された
場合）の手続きの流れを示す図である。

【図１２】メタオブジエクト（MLocalMailer）とスケジ
ューラ（Scheduler）の関係（メタスペース（mLocal）
におけるウェイトフォー（WaitFor）でウェイトフォー
（WaitFor）がリプライ（Replay）よりも先に実行され
た場合）の手続きの流れを示す図である。

【図１３】メッセージキューの説明に用いる図である。

【図１４】メタオブジエクト（MDriveMailer）における
センド（Send）の手続きの流れを示す図である。

【図１５】メタオブジエクト（MDriveMailer）における
キック（Kick）の手続きの流れを示す図である。

【図１６】メタオブジエクト（MDriveMailer）の終了時
（Exit）で、メタスペース(mDrive）上のベースオブジ
ェクトが処理を終了するときに呼び出される手続きの流
れを示す図である。

【図１７】遅延実行テーブル（DelayeExecutionTable）
に登録（メタオブジエクト（MDriveMailer）のセンド
（Send）の場合）された手続きを処理する流れを示す図
である。

【図１８】遅延実行テーブル（DelayeExecutionTable）
に登録（メタオブジエクト（MDriveMailer）のキック
（Kick）の場合）された手続きを処理する流れを示す図
である。

【図１９】メタメッセージ（MetaMessage）の構成の説
明に用いる図である。

【図２０】ベースオブジェクトＩの実行中にベースオブ
ジェクトＩＩが割り込んだ場合の動作説明に用いる図で
ある。

【図２１】タグ（Tag）とフューチャ（Future）、コン
ティネーション（Continuation）の関係、タグ（Tag）
とタグＩＤ（TID）の関係をＯＭＴ法のオブジェクトモ
デルで示す図である。

【図２２】オブジェクト（delivere）を介して異なるメ
タスペース間通信を行なう場合（メタスペース（mLoca
l）がメタスペース(mDrive）に通信する場合）の往路の
流れを示す図である。

【図２３】オブジェクト（delivere）を介して異なるメ
タスペース間通信を行なう場合（メタスペース（mLoca
l）がメタスペース(mDrive）に通信する場合）の復路の
流れを示す図である。

【図２４】オブジェクト（delivere）を介して異なるメ
タスペース間通信を行なう場合（メタスペース(mDriv
e）がメタスペース（mLocal）に通信する場合）の往路
の流れを示す図である。

【図２５】オブジェクト（delivere）を介して異なるメ
タスペース間通信を行なう場合（メタスペース(mDriv
e）がメタスペース（mLocal）に通信する場合）の復路
の流れを示す図である。

【図２６】タグｌＤでタグの型を認証する方式の一例を
表す図である。

【図２７】このタグＩＤ（TID）にタグの属性を含めた
ＯＭＴを示す図である。

【図２８】スレッド（Thread）の状態遷移図を示す。

【符号の説明】

mLocal，mDrive メタスペース、 MLocalMailer，MDri
veMailer メタオブジエクト

Claims (10)

【特許請求の範囲】
1. 【請求項１】 複数のオブジェクト間で通信を行うデー
   タ通信方法において、 異なる性質或いはインターフェースを持った通信機構を
   それぞれ固有に持つオブジェクト間の通信の同期及び並
   行性の制御を行うためのタグを生成し、 当該タグを通信メッセージと共に通信することを特徴と
   するデータ通信方法。
2. 【請求項２】 上記タグを生成する際、上記タグを識別
   するためのタグＩＤと当該タグの型を示す属性とを、少
   なくとも生成することを特徴とする請求項１記載のデー
   タ通信方法。
3. 【請求項３】 上記タグの型を管理するオブジェクトを
   有することを特徴とする請求項１記載のデータ通信方
   法。
4. 【請求項４】 上記タグの型を管理するオブジェクトを
   有することを特徴とする請求項２記載のデータ通信方
   法。
5. 【請求項５】 上記タグＩＤはオブジェクトによって上
   記通信メッセージと共に配送されることを特徴とする請
   求項２記載のデータ通信方法。
6. 【請求項６】 上記タグＩＤを配送するオブジェクト
   は、上記タグの型に基づいて配送先を決定することを特
   徴とする請求項５記載のデータ通信方法。
7. 【請求項７】 上記タグＩＤを配送するオブジェクト
   は、上記タグの型と配送先のテーブルを有することを特
   徴とする請求項６記載のデータ通信方法。
8. 【請求項８】 上記タグを識別するための情報と当該タ
   グの型を示す属性とを、少なくとも示すタグＩＤを生成
   することを特徴とする請求項１記載のデータ通信方法。
9. 【請求項９】 複数ビットにて形成される上記タグＩＤ
   の一部のビットを用いて上記タグの型を表すことを特徴
   とする請求項８記載のデータ通信方法。
10. 【請求項１０】 複数のオブジェクト間で通信を行うデ
    ータ通信方法において、 異なる性質或いは異なるインターフェースを持った通信
    機構をそれぞれ固有に持つ第１のオブジェクトと第２の
    オブジェクト間で通信を行う際、 上記第１のオブジェクトで生成される第１のデータ構造
    と上記第２のオブジェクトで生成される第２のデータ構
    造を区別するための識別子を有する第３のデータ構造を
    生成し、 当該第３のデータ構造に係るデータを通信メッセージと
    共に通信することを特徴とするデータ通信方法。