JPH10283205A - データ通信方法 - Google Patents
データ通信方法Info
- Publication number
- JPH10283205A JPH10283205A JP9092446A JP9244697A JPH10283205A JP H10283205 A JPH10283205 A JP H10283205A JP 9092446 A JP9092446 A JP 9092446A JP 9244697 A JP9244697 A JP 9244697A JP H10283205 A JPH10283205 A JP H10283205A
- Authority
- JP
- Japan
- Prior art keywords
- tag
- message
- metaspace
- future
- meta
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Abstract
性を提供する。 【解決手段】 オブジェクト指向オペレーティング・シ
ステム間あるいはオブジェクト間通信を行うデータ通信
方法において、異なる性質或いはインターフェースを持
った通信機構がそれぞれ固有に持つオブジェクト間通信
の同期及び並行性の制御を行うためのタグ(Tag)とし
てフューチャ(Future)、コンティネーション(Contin
uation)を扱い、このタグ(Tag)を通信メッセージと
共に通信する。
Description
オペレーティング・システム(OS)又はその他のオブ
ジェクト指向プログラミングシステムにおいてオブジェ
クト間のデータ通信方法に関する。
オブジェクト指向技術がある。オブジェクト指向技術を
適用したソフトウェアでは、ソフトウエア内部の各機能
はオブジェクトとしてモジュール化されている。ソフト
ウエア全体の機能を実現するために、各オブジェクトは
オブジェクト間通信を行なう。オブジェクト間通信では
送信内容をメッセージに詰めて配送する。
ージの管理方法について、いろいろな方式が考えられ
る。これらの方式はアプリケーションからの要求に応じ
て決定される必要がある。そのため、いろいろな要求に
応えるためには、アプリケーションに応じた性質(意味
構造、セマンティクス)やそれに応じたインターフェー
ス(Application Programming Interface:APIs)
を持ったオブジェクト間通信機構が必要になる。なお、
以下で扱うAPIとは、OSの機能を用いるインターフ
ェース或いはプログラミングシステムの機能としてのイ
ンターフェースを示す。
ジェクト間通信機構が存在することを「環境」があると
呼ぶことにする。一つの機器やホストにはただ一つの環
境が実現されることもあるし、異なる複数の環境が同時
に実現されることもある。特に異なる環境に存在するオ
ブジェクト間の通信は相互の環境の協調動作を行わしめ
るという点から重要である。
トにメッセージを送る機能を提供する考え方として、本
質的に以下の二つがある。すなわち、 1.異なる環境に存在するオブジェクトにメッセージを
送るために、同じ環境に存在するオブジェクトにメッセ
ージを送るときとは異なるインターフェースや手続きを
提供するという考え方と、 2.異なる環境に存在するオブジェクトにメッセージを
送るために、同じ環境に存在するオブジェクトにメッセ
ージを送るときと同じインターフェースや手続きを使う
ことができるという考え方とがある。
なぜなら、全ての環境をプログラマが意識しなくてもよ
い考え方なので、インターフェースや手続きの違いが環
境の違いによって各々異なる機能を提供することで吸収
させればよいからである。
ためには異なる環境に対してプログラムコードが左右さ
れない、いわゆる透明性を提供した方がよい。
されたものであり、プログラマのために異なる環境に対
して透明性を提供することを可能にするデータ通信方法
を提供することを目的とするものである。
OSを問わずオブジェクト間通信が必要なソフトウエア
であって、ソフトウエア間が透明性をもって通信するこ
とを実現するタグと、それを適用したソフトウェアシス
テムを実現することにより、上述した課題を解決する。
することによって、異なる環境間で透明性のある通信機
構を実現したソフトウェア、またはその実現方式を提供
する。本発明によって、ある通信機構が固有に持つオブ
ジェクト間通信の同期や並行性の制御に必要な実体が環
境によって異なっている場合でも、異なる環境に存在し
ているオブジェクトが互いにその違いを意識することな
く、通信可能になる。
図面を参照しながら説明する。
なる複数の環境を実現できるソフトウェア・システムに
適用することを基本的な特徴の一つとしている。本発明
の実施の形態では「環境」のことを特にメタスペースと
呼んでいる。また、本発明の実施の形態におけるメタス
ペースでは、オブジェクト間通信機構以外の機能につい
ても異なる「環境」を提供できる。なお、上記異なる複
数の環境を実現できるソフトウェア・システムとして
は、例えば本件出願人が先に提案している特願平8−6
7881号の明細書及び図面に記載したデータ処理方法
及び装置を挙げることができる。このデータ処理方法
は、複数のオブジェクトで構成されるアプリケーション
プログラムと、複数のオブジェクトで構成される前記ア
プリケーションプログラムの動作を規定する実行環境
と、前記アプリケーションプログラムと前記実行環境の
間のインターフェースを規定するアプリケーションプロ
グラムインターフェースとを備えるサーバと、前記サー
バより前記アプリケーションプログラムをダウンロード
するクライアントとを備えるデータ処理システムにおけ
るデータ処理方法であって、前記サーバは前記クライア
ントに前記アプリケーションプログラムをダウンロード
するとき、前記クライアントがダウンロードする前記ア
プリケーションプログラムの実行環境を有するか否かを
検査し、その検査結果に対応して前記アプリケーション
プログラムを前記クライアントにダウンロードすること
を特徴とするものである。
方法が適用される装置構成の一例を示す。
ープを収納したビデオカセットを用いて信号の記録再生
を行うビデオカセットレコーダ(以下、VCR装置と呼
ぶ)である。勿論VCR装置以外のオーディオ・ビジュ
アル機器(いわゆるAV機器)や事務機器等のその他の
装置、一般のコンピュータ装置にも本発明は適用可能で
ある。
14はビデオカセットを用いてデータの記録再生を行う
ビデオカセットレコーダとしての主要機能を備え、当該
VCR機能部14にてビデオカセットに記録/再生され
るデータは、バス/IOブリッジ15を介して装置の他
の構成に送られ、また端子23を介して外部との入出力
が行われる。CPU(中央処置ユニット)12は、バス
/メモリブリッジ13を介して各部を制御する制御部で
ある。RAM(ランダム・アクセス・メモリ)10は、
比較的小容量で構成され、ワークエリアを有する。RO
M(リード・オンリ・メモリ)11は、基本的な機能に
関するプログラムを記憶していると共に、本発明で言う
OSに係るプログラムも記憶されている。すなわち、上
記CPU12は、上記ROM11が記憶するプログラム
に基づいて各部を制御し、上記RAM10をワークエリ
アとして使用する。
体内にIC(集積回路)を備えた記憶媒体であるICカ
ードが挿入されるスロットと、当該ICカードに対する
データの書き込み/読み出しを行うICカード駆動部と
を有する。フロッピィディスクドライブ17は、フロッ
ピィディスが挿入されるスロットと、当該フロッピィデ
ィスクを回転駆動する回転駆動部と、フロッピィディス
クに対してデータの記録/再生を行うヘッド部とを有
し、各種データの記録やアプリケーションソフトのイン
ストールなどが行われる。ハードディスクドライブ18
は、当該ハードディスクを回転駆動する回転駆動部と、
ハードディスクに対してデータの記録/再生を行うヘッ
ド部とを有する。バススロット19は、拡張ボードを追
加する際の拡張端子である。シリアルポート20は、モ
デム(MODEM)を介して外部との間でデータ通信を
行うための入出力部である。
追加して、付加的なアプリケーションソフトを与えるこ
とができるようになっている。例えばユーザがバージョ
ンアップを図りたい(新しい機能をこのVCR装置に付
加したい)場合等は、ICカードやフロッピディスク或
いはインターネット等のネットワーク回線を介して付加
的な機能ソフトをインストールできる。したがってユー
ザは、VCR装置本体を買い換えることなく装置の機能
アップが行える。アプリケーションプログラムはプログ
ラマによって作成されてユーザに供給されるものであ
る。ここでこれらソフトウェアをいわゆるオブジェクト
指向型プログラミングソフトで構築する場合を考える。
スペース)間で通信が必要となる場合がある。
M(モデム)、シリアルポートを介して通信されてきた
アプリケーションソフトと予めVCR装置内に存在する
アプリケーションソフトは異なる環境(メタスペース)
下にあり、それぞれは通信用OS(後述するメタスペー
ス(mLocal)、メタスペース(mDrive)等)、AV用O
SとAPI(後述するセンド(Send)、リプライ(Repl
y)等)により通信が行われるようになっている。
て具体的な二つの例」を本発明のデータ通信方法にて実
現した例を使って述べる。この例では後述するフューチ
ャ(Future)と呼ぶ実体を使った通信セマンティクス
(性質、意味構造)を実現したメタスペース(mLocal)
と、コンティネーション(Continuation)と呼ぶ実体を
使った通信セマンティクスを実現したメタスペース(mD
rive)の例で示す。
の具体的な例」として、 [メタスペース(mLocal)通信機構] [メタスペース(mDrive)通信機構] [メタスペース(mLocal)通信機構とメタスペース(mD
rive)通信機構の比較] [本発明方法における通信機構の実現方式] [フューチャ(Future)とメタスペース(mLoca)通信
機構の実現方式] [コンティネーション(Continuation)とメタスペース
(mDrive)通信機構の実現方式] の順に説明する。
説明」を述べる。ここでもメタスペース(mLocal)とメ
タスペース(mDrive)を例に述べる。なお、メタスペー
ス(mLocal)、メタスペース(mDrive)は、1つのOS
又はプログラミングシステムとして捉えることができ
る。本実施の形態では、上記「タグを使った通信機構の
基本的な説明」として、 [オブジェクトA(メソッドA1(A::A1))がオブジ
ェクトB(メソッドB1(B::B1))にセンド及びウェ
イトフォー(Send+WaitFor)する場合] [オブジェクトB(メソッドB1(B::B1))がオブジ
ェクトA(メソッドA1(A::A1))にセンド(Send)
し、継続メソッドとしてオブジェクトB(メソッドB2
(B::B2))を指定した場合] の順に説明する。
方法での実現事例」についての詳細を述べる。本実施の
形態では、上記「タグを使った通信機構の本発明方法で
の実現事例」として、 [フューチャ(Future)、コンティネーション(Contin
uation)、タグ(Tag)] [タグIDの管理方式と当該タグIDを配送するオブジ
ェクト(Deliverer)] [異なるメタスペース間通信の実際] の順に説明する。
なる方式」について述べる。本実施の形態では、上記
「その他に考えられる実現方式」として、 [タグIDでタグの型を認識する方式] [タグの管理方式] の順に説明する。
信機構の具体的な例」の場合の説明を行う。
例」として、本発明のデータ通信方法におけるオブジェ
クト間通信の具体的な仕様と実現方式について述べる。
本章に続く本発明の具体的な事例では、本章で述べる二
つの異なる(通信機構を提供している)環境間でのオブ
ジェクト間通信の実現方式を説明する。
メタスペース(mLocal)は上記フューチャ(Future)を
基本にした通信機構をサポートした環境(オブジェクト
間通信機構)である。このメタスペース(mLocal)はア
プリケーションを記述するためのものである。メタスペ
ース(mLocal)通信機構の仕様のうち、インターフェー
スについては後述する。
構を使ったオブジェクト間通信の基本的を動作について
述べる。この通信機構の実現方式、説明で使用されるフ
ューチャ(Future)が持つ属性については後に述べる。
機構を使ったオブジェクト間通信の基本的な動作を示し
ている。図3にはメタスペース(mLocal)通信機構にお
いて、ウェイトフォー(WaitFor)がリプライ(Reply)
よりも先に実行された場合を示し、図4にはメタスペー
ス(mLocal)通信機構においてリプライ(Reply)がウ
ェイトフォー(WaitFor)よりも先に実行された場合を
示している。これら図3、図4ともにA、Bはオブジェ
クト、A::A1、B::B1はそれぞれオブジェクトAのメソッ
ドA1、オブジェクトBのメソッドB1、縦の実線矢印
はメソッドの実行、縦の破線矢印はメソッドの待ち状
態、斜めの実線矢印はメッセージの配送を示している。
なお、上記ウェイトフォー(WaitFor)は、メタスペー
ス(mLocal)におけるAPI(Application Programmi
ng Interface)の一つであり、本実施の形態ではオブ
ジェクトAがオブジェクトBの結果を待つ場合に用いら
れる。当該ウェイトフォー(WaitFor)には、その引数
として後述するフューチャID(futureID)、上記リプ
ライ(Reply)から送られた返答メッセージ(&msg)及
びそのサイズ(sizeof(msg))を備える。なお、上記リ
プライ(Reply)は、メタスペース(mLocal)における
APIの一つであり、本実施の形態ではオブジェクトB
がオブジェクトAの返答する場合に用いられる。当該リ
プライ(Reply)には、その引数としてメソッドB1の
実行結果として得られる返答メッセージ(msg)及びそ
のサイズ(sizeof(msg))を備える。
オブジェクトBにメッセージを送信し、その返答を受け
取る例である。はじめにオブジェクトAはオブジェクト
Bにセンド1(Send1)を使ってメッセージを送信す
る。メソッドB1(B::B1)はこれによって起動するメ
ソッドであり、図中msgは配送されるメッセージ(のポ
インタ)である。これによって、メソッドB1(B::B
1)が起動される。メソッドA1(A::A1)、メソッドB
1(B::B1)は並行に動作する。このとき、メソッドA
1(A::A1)のウェイトフォー(waitfor)とメソッドB
1(B::B1)のリプライ(Reply)のどちらが先に実行さ
れるかという保証はない。なお、センド(Send)とは、
メタスペース(mLocal)におけるAPIの一つであり、
本実施の形態ではメイルの送信を行う場合に用いられ
る。当該センド(Send)には、その引数として宛先
(B)と選択メソッド(B1)、メッセージ(msg)及
びそのサイズ(sizeof(msg))とフューチャID(futur
eID)とを備える。
ージ送信したとき、オブジェクトAはフューチャID(f
utureID)を受け取る。このフューチャIDはOS(オ
ペレーティング・システム)がメッセージを配送する際
にOSが内部的に生成する上記フューチャ(Future)と
呼ばれる実体に対応するIDである。ここで、生成とは
オブジェクトを構成する属性に必要なメモリの領域を確
保すること及び当該属性を初期化することを示す。図5
に示すように、アプリケーションソフトはAPIによっ
てメイラ(例えば後述するメタオブジエクト(MLocalMa
iler))のオブジェクトや後述するスケジューラ(Sche
duler)のオブジェクトに通信を行うようになす。メイ
ラの実行がオブジェクト内の実行コードに基づいてCP
Uによって行われ、CPUはフューチャ(Future)に必
要なメモリ領域をOS領域内に確保する。フューチャI
D(futureID)はオブジェクトAが後にこのメッセージ
の配送に対する返答を受け取るとき、どのメッセージ送
信に対する返答メッセージの受信なのかを識別するため
に使われる。
ている。この属性としては、フューチャ(Future)を生
成したオブジェクトを特定するためのID(ThreadID c
reator)、返答が済んでいるかどうかを調べるためのフ
ラグ(bool isReplyDone)、返答メッセージ(void* re
plyMessage)がある場合にはこれを保存しておくための
領域が定義されている。例えば図3、図4の例ならば、
ID(ThreadID creator)はオブジェクトAが、返答メ
ッセージ(void* replyMessage)にはメッセージ(ms
g)が保存される。
ライ(Reply)よりも先に実行された場合を示してお
り、この場合、ウェイトフォー(Waitfor)の引数とし
て上記フューチャID(futureID)を与える。このと
き、指定されたフューチャID(futureID)に対する返
答のための処理が行われていないので、メソッドA1
(A::A1)の実行は待ち状態になる。その間、メソッド
B1(B::B1)は処理を続け、返答のための手続きをす
るときリプライ(Reply)を実行する。リプライ(Repl
y)が実行されると、OSがメソッドB1(B::B1)を起
動するときに生成したフューチャ(Future)の状態を観
察する。この場合、OSはそのフューチャ(Future)に
対して待ち状態のメソッドがあることを知ることができ
るので、ここでメソッドA1(A::A1)を再び実行状態
に戻す。その後、メソッドA1(A::A1)、メソッドB
1(B::B1)は再び並行に動作する。
トフォー(Waitfor)よりも先に実行された場合を示し
ている。リプライ(Reply)が実行されたとき、OSが
メソッドB1(B::B1)を起動するときに生成したフュ
ーチャ(Future)の状態を観察する。この場合、OSは
そのフューチャ(Future)に対応したメッセージの送信
者(この場合はオブジェクトA)はまだ待ち状態にない
ことを知ることができるので、フューチャ(Future)に
返答済みである印を付ける。メソッドB1(B::B1)は
そのまま残り部分の実行を続ける。メソッドA1(A::A
1)がメソッドB1(B::B1)からの返答を必要としたと
き、メソッドA1(A::A1)はウェイトフォー(Waitfo
r)の引数としてフューチャID(futureID)を与える。
この場合、指定されたフューチャID(futureID)に対
する返答のための処理がすでに行われているので、メソ
ッドA1(A::A1)は実行を継続することができる。
動作している二つのオブジェクトの同期を取るための仲
介的な役割を果たしている。メタスペース(mLocal)通
信機構の仕様では、メッセージの送信側はどのメッセー
ジに対する返答待ちかを明示的に示す必要があるので、
フューチャID(futureID)によってフューチャ(Futur
e)を特定する。メッセージの受信側はどの送信者に対
する返信なのかを意識する必要がないように定めている
ので、フューチャID(futureID)は明示的に現れてい
ない。
スペース(mDrive)はコンティネーション(Continuati
on)を基本にした通信機構をサポートした環境である。
このメタスペース(mDrive)はデバイスドライバを記述
するためのものである。
構を使ったオブジェクト間通信の基本的な動作について
述べる。この通信機構の実現方式、説明で使用されるコ
ンティネーション(Continuation)が持つ属性や状態遷
移などの詳細は後述する。
使ったオブジェクト間通信の基本的な動作を示してい
る。図3、図4と同様にA、Bはともにオブジェクト、
A::A1、A::A2及びB::B1はそれぞれのオブジェクトA、
BのメソッドA1、A2、B1、縦の実線矢印はメソッ
ドの実行、斜めの実線矢印はメッセージの配送を示して
いる。
オブジェクトBにメッセージを送信する。図7の例では
オブジェクトBのメソッドB1(B::B1)にメッセージ
(msg)を配送する。このとき、オブジェクトAはセン
ド(Send)に対して5番目の引数として継続メソッド
(A2)を、さらに6番目の引数として継続メッセージ
(contMsg)を与える。このときのメソッドA2(A::A
2)は、メソッドA1(A::A1)の処理が終了した後、メ
ソッドB1(B::B1)からの返答を受け取って処理を継
続するメソッドである。また、このときのメッセージ
(contMsg)は、継続メソッド(A2)の処理を補助す
るためのメッセージで、メソッドA1(A::A1)が継続
メソッドA2(A::A2)に渡す内容を含んだメッセージ
である。
む上記コンティネーション(Continuation)と呼ばれる
実体を内部に生成する。ここでのコンティネーション
(Continuation)の生成は前記図5での説明で述べたフ
ューチャ(Future)の例と同様、後述するメタオブジエ
クト(MDriveMailre)等のメイラオブジェクトの実行に
よりメモリ内にコンティネーション(Continuation)に
必要な領域を確保する。
n)の属性を示している。ここにはコンティネーション
(Continuation)を生成したオブジェクトを特定するた
めのID(ThreadIDcreator)、継続メソッド(Selecto
rmethod)、継続メッセージ(void*message)を格納す
る領域が定義されている。このコンティネーション(Co
ntinuation)の属性は、図8に示されており、コンティ
ネーション(Continuation)を生成したオブジェクトを
特定するためのID(ThreadID creator)、選択される
継続メソッド(Selector Method)及び継続メッセージ
(void* Message)を保存する領域が定義されている。
図7の例ではセンド(Send)により、オブジェクトA、
メソッドA2、メッセージ(contMsg)が送られると、
OSがコンティネーション(Continuation)を生成し、
ID(ThreadID creator)にはオブジェクトA、継続メ
ソッド(Selector Method)にはメソッドA2、及び継
続メッセージ(void* Message)にはメッセージ(contM
sg)が保存される。
(A::A1)から配送されたメッセージの内容の他、その
コンティネーション(Continuation)を特定するための
IDとしてOSにより生成されたコンティネーションI
D(ContID)を受け取る。図7の例では、contIDとして
受け取っている。このコンティネーションID(ContI
D)はキック(Kick)の引数として使われる。なお、キ
ック(Kick)とはメタスペース(mDrive)におけるAP
Iの一つであり、本実施の形態ではコンティネーション
ID(ContID)をオブジェクトAに与えることでコンテ
ィネーション(Continuation)の中味の情報を得る際に
用いられる。このキック(Kick)には、その引数として
上記コンティネーションID(ContID)を備える。メタ
スペース(mDrive)のオブジェクトはコンティネーショ
ン(Continuation)をキック(Kick)することで、コン
ティネーション(Continuation)に含まれる情報を意識
せずに継続メソッドを起動することができる。図7の例
では、メソッドB1(B::B1)は受け取ったコンティネ
ーションID(contID)をそれ自身がキック(Kick)
し、これによりメソッドA1(A::A1)が指定した継続
メソッドA2(A::A2)が起動され、メソッドB1の結
果と継続メッセージ(contMsg)が渡される。
uation)は、メッセージを受信したオブジェクトが、誰
がメッセージを送信したのか、あるいはどこに返答を送
信すればよいのかを意識することなく、継続メソッドを
起動できる(そのときに、返答を送信することができ
る)。メタスペース(mDrive)通信機構の仕様では、コ
ンティネーションID(ContID)はOSがメッセージの
受信側にメッセージと共に配送するので、送信側にはコ
ンティネーションID(ContID)は現れない。
スペース(mDrive)通信機構の比較]メタスペース(mL
ocal)通信機構の仕様において、メソッドの実行の並行
性は、あるメソッドの開始から終了までの間にのみ存在
する。このセマンティクスは並行性は高くないが(メタ
スペース(mDrive)通信機構の仕様に比べて)、プログ
ラマが直感的に理解しやすい、記述しなければならない
コードの量を少なくし易いなどの利点がある。しかし、
この仕様では、割込みを使ったデバイスドライバのよう
な非同期な事象を効率的に記述することができない。
は、メソッドを一度終了した後の継続メソッドを指定す
ることができる。割込みのような非同期な事象に対応し
て返答を送信するとき、コンティネーション(Continua
tion)をキック(Kick)することによってあらかじめ指
定された継続メソッドを起動できる。そのため、デバイ
スドライバのような非同期な事象を効率的に記述するこ
とができる。これは並行性の高いプログラムを記述でき
るが(メタスペース(mLocal)通信機構の仕様に比べ
て)、プログラマが直感的に理解し難い、記述しなけれ
ばならないコードの量が多くなり易いなどの欠点があ
る。
式]本発明方法では、メタスペースが提供する機能は、
メタスペースを構成するオブジェクトによって実現す
る。このようなオブジェクトを、メタスペースが提供す
る機能を使うオブジェクトに対して特にメタレベルオブ
ジェクト、またはメタオブジエクトと呼ぶ。一方、メタ
スペースが提供する機能を使うオブジェクトをベースレ
ベルオブジェクト、またはベースオブジェクトと呼ぶ。
ブジェクトとして(これから説明を進める各通信機構を
実現するための構成要素として)、例えばスケジューラ
(Scheduler)と呼ぶものを用いることができる。スケ
ジューラ(Scheduler)はオブジェクトの状態を管理す
るメタオブジェクトである。本実施の形態で必要になる
スケジューラ(Scheduler)の仕様は後述する。
ース(mDrive)の通信機構はそれぞれのメタスペースで
異なる機構なので、それを実現するための機能を提供す
るメタオブジエクトは、それぞれに定義することができ
る。ここでは、メタスペース(mLocal)通信機構にてメ
ッセージの配送を実現するメタオブジエクトをメタオブ
ジエクト(MLocalMailer)、メタスペース(mDrive)通
信機構にてメッセージの配送を実現するメタオブジエク
トをメタオブジエクト(MDriveMailer)と呼ぶ。
ブジエクト(MLocalMailer)、スケジューラ(Schedule
r)、そしてそれらの実行を支援する他のモジュールに
よって実現される。また、メタスペース(mDrive)通信
機構はメタオブジエクト(MDriveMailer)、スケジュー
ラ(Scheduler)、そしてそれらの実行を支援する他の
モジュールによって実現される。ここではメタオブジエ
クト(MLocalMailer)とスケジューラ(Scheduler)、
メタオブジエクト(MDriveMailer)とスケジューラ(Sc
heduler)の関係にシナリオを与え、各通信機構の実現
方式を示す。また、それぞれフューチャ(Future)とコ
ンティネーション(Continuation)の属性を与え、シナ
リオによってそれらの状態遷移を示す。
(mLocal)通信機構の実現方式]図9から図12はメタ
オブジエクト(MLocalMailer)とスケジューラ(Schedu
ler)の関係をシナリオ(フローチャート)によって与
える。
(Send)の手続きを示している。
ocal)上のベースオブジェクトがセンド(Send)を実行
すると、メタスペース(mLocal)を構成する通信機構の
ためのメタオブジェクト(MLocalMailer)に処理が移る
と共にベースオブジェクトはステップST7のようにウ
ェイト(Wait)の状態となる。ここで、ベースオブジェ
クトからメタオブジエクトへ処理の状態が移ることを、
以下にM(Meta Computation)と表現する。
ト(MLocalMailer)は、ステップST1として、フュー
チャ(Future)を生成する。
(ActiveMessage)を配送する宛て先のオブジェクトの
メッセージキュー(メッセージの並び)の状態を調べ
る。このとき、メッセージキューにメッセージがない場
合(FALSE、偽)には、そのオブジェクトは休眠状
態(スケジューラ(Scheduler)が管理している状態で
は休止(Dormant))なので、ステップST5として、
スケジューラ(Scheduler)にメイクレディ(MakeRead
y)を発行(issue)してオブジェクトを実行可能状態
(スケジューラ(Scheduler)が管理している状態では
レディ(Ready))にする。ここで簡単にメッセージキ
ューについて解説する。図13に示すように、CPUは
オブジェクト内の1つのスレッドを実行する際、配送さ
れたメッセージを利用する。メッセージキューはメッセ
ージの並びを示し、メッセージキュー内のメッセージを
順次利用するように構成される。なお、メイクレディ
(MakeReady)はスケジューラ(Scheduler)にそのオブ
ジェクトが実行可能とするために用いられるAPIであ
り、上記レディ(Ready)は実行可能状態を、上記ドー
マント(Dormant)はオブジェクトが休止状態であるこ
とを表す。上記ドーマント(Dormant)時は、オブジェ
クトが何も実行せずメッセージを受信できる状態を表
す。メイクレディ(MakeReady)には、引数としてベー
スオブジェクトを特定する(Thread of base)(この実
施の形態ではオブジェクトB)、宛先のメソッド(meth
od)、メッセージ(msg)を持つ。よって、この実施の形
態ではベースオブジェクトBを指定してメソッドBにメ
ッセージ(msg)を送るように管理する命令をスケジュ
ーラ(Scheduler)に送ることになる。
ジキューにメッセージがある場合(TRUE、真)に
は、すでにそのメッセージが宛て先のオブジェクトに配
送されて、そのオブジェクトが実行可能状態(レディ
(Ready))、オブジェクトが実行状態(ランニング(R
UNNING))なので、ステップST4として、メッセージ
キューの最後にそのメッセージを入れて終了する。この
とき、メッセージ送信に対応したフューチャ(Future)
を特定できるフューチャID(futureID)もあわせてメ
ッセージキューで管理する。なお、これらの状態につい
ては後述する図28にて説明する。
ることを示す返り値サクセス(sSuccess)をメタメッセ
ージ(MetaMessage)に入れ、ベースオブジェクトに状
態遷移を戻す。その後ベースオブジェクトはステップS
T8のように実行或いは実行可能状態となる。ここで、
これ以降、メタオブジェクトからベースオブジェクトへ
状態遷移が戻ることをR(Resume)と表す。上記メタメ
ッセージ(MetaMessage)とは、メタスペース(mLocal)
上のベースオブジェクトがセンド(Send)をするとき、
当該センド(Send)に必要なパラメータ(引数)を持っ
たメッセージである。
R(Resume)については、先に示した特願平8−678
81号の明細書及び図面に詳しく示されている。
r)によるリプライ(Reply)に関する手続きを示してい
る。
11として、メタオブジエクト(MLocalMailer)はどの
ベースオブジェクトがリプライ(Reply)してきたのか
を確認する。図3、図4の例で言えば、ベースオブジェ
クトBがリプライ(Reply)を発行(issue)することが
確認される。なお、この確認として、本実施の形態では
APIの例えば関数GetLast()を使うようにしている
が、ここではどのような方法でもよい。またこのときの
ベースオブジェクトはステップST24のようにウェイ
ト(Wait)の状態となる。
14として、このベースオブジェクトを起動したときに
一緒に配送されたフューチャID(futureID)が特定す
るフューチャ(Future)が本当にメタスペース(mLoca
l)のフューチャ(Future)かどうか確認する。ステッ
プST12,ST14で偽と判断されたらエラーとし、
ステップST22へ進む。ステップST13が偽のとき
は、本実施の形態の主題であるタグを使った通信機構で
他のメタスペースと通信する場合に相当し、後述するメ
タオブジェクト(Deliverer)に処理を依頼する。
おいて、そうであることが確認されたら、ステップST
15として、そのフューチャ(Future)の属性(creato
r)の状態を調べる。このとき、属性(creator)はリプ
ライ(Reply)をしたベースオブジェクトにメッセージ
を送ったオブジェクトを含み、図3、図4の例で言えば
リプライ(Reply)をしたベースオブジェクトBにメッ
セージを送ったオブジェクトはAであり、領域(Thread
ID Creator)に保存されている。
ジェクトが待ち状態(ウェイト(Wait))になっている
かどうかを調べ、そのオブジェクトが待ち状態(ウェイ
ト(Wait))になっている場合は、ステップST17の
ようにそのオブジェクトがウェイトフォー(WaitFor)
を実行している場合である。ウェイトフォー(WaitFo
r)の実行は前に図3、図4の説明で述べているよう
に、引数としてフューチャID(futureID)、返答メッ
セージ(&msg)、サイズ(sizeof(msg))を有し、いま
扱っているフューチャID(futureID)とウェイトフォ
ー(WaitFor)に与えられたフューチャID(futureI
D)は等しく、リプライ(Reply)により送られたメッセ
ージ(msg)が引数(&msg)に与えられる。待ち状態のオ
ブジェクトは前記メイクレディ(MakeReady)によって
再び実行可能状態になる。つまり、図3、図4の例で
は、オブジェクトAが実行可能状態に復帰する。
ト(wait)状態なので、指定は不要だからUNDEF(undef
ine)、メッセージ(msg)も不要なのでNULLとされ
ている。
(creator)が待ち状態でない場合は、まだウェイトフ
ォー(Waitfor)を実行していない。したがってこのと
き、メタオブジエクト(MLocalMailer)は、ステップS
T19としてフューチャ(Future)の属性(isReplyDon
e)をセットし、リプライ完了のマークを入れる。さら
に必要に応じてステップST18のようにメッセージ
(message)に返答メッセージを一時的に保存する。
ャ(Future)を削除し、さらにステップST21では配
送完了の返り値サクセス(sSuccess)をメタメッセージ
(MetaMessage)に入れ、ステップST22ではエラー
を示す返り値をメタメッセージ(MetaMessage)に入
れ、ステップST23では配送完了の返り値サクセス
(sSuccess)をメタメッセージ(MetaMessage)に入れ
る。その後ベースオブジェクトはステップST25のよ
うに実行或いは実行可能状態となる。
r)の手順であり、図11はリプライ(Reply)がウェイ
トフォー(WaitFor)よりも先に実行された場合(図4
の場合)、図12はその逆(図3の場合)を示してい
る。これらは図10の説明に対応している。なお、これ
以降、ベースオブジェクトの流れは図示を省略する。
ではフューチャ(Future)の確認を行い、ステップST
32ではフューチャ(Future)の属性(isReplyDone)
がセットされている(リプライ(Reply)が既に行われ
ている)かどうかの確認を行う。これらステップST3
1、ST32にて共に真(TRUE)とされた時には、
ステップST33にてフューチャ(Future)内にセット
された結果、メッセージをウェイトフォー(WaitFor)
のメッセージ(&msg)に入力し、その後は、ステップS
T34にてフューチャ(Future)を削除し、さらにステ
ップST35では配送完了のサクセス(sSuccess)をメ
タメッセージ(MetaMessage)に入れる。ステップST
31で偽と判断されたら、ステップST36ではエラー
コードをメタメッセージ(MetaMessage)に入れ、R(R
esume)を行う。なお、ステップST32で偽と判断さ
れたら、図12に示すステップST43へ移行する。
T41ではフューチャ(Future)の確認を行い、ステッ
プST42ではフューチャ(Future)の属性(isReplyD
one)がセットされていないかどうかの確認を行う。こ
れらステップST41、ST42にて共に真(TRU
E)とされた時には、ステップST43にて待ち状態と
なされ、その後、ステップST44ではサクセス(sSuc
cess)をメタメッセージ(MetaMessage)に入れ、ステ
ップST45ではメタコール(MetaCall)から送られ
る。ステップST41にて偽と判断されたらステップS
T46にてエラーコードをメタメッセージ(MetaMessag
e)に入れ、R(Resume)を行う。ステップST42に
て偽と判断されたら図11のステップST33へ移行す
る。なお、図11、図12の例は共にベースオブジェク
トがメタオブジエクト(MLocalMailer)にウェイトフォ
ー(WaitFor)を依頼し、R(Resume)されるまでウェ
イト(Wait)の状態となる(図示せず)。
メタスペース(mDrive)通信機構の実現方式]図14か
ら図18にはメタオブジエクト(MDriveMailer)とスケ
ジューラ(Scheduler)の関係をシナリオによって与え
る。メタオブジエクト(MDriveMailer)はデバイスドラ
イバのためのメタスペースなので、その手続きは前記メ
タオブジエクト(MLocalMailer)に比べてやや複雑であ
る。その一つに遅延実行テーブル(DelayedExecutionTa
ble)がある。メタオブジエクト(MDriveMailer)にお
いてセンド(Send)やキック(Kick)の手続きは、メタ
スペース(mDrive)上のオブジェクトがセンド(Send)
やキック(Kick)を依頼したときに、遅延実行テーブル
(DelayedExecutionTable)への登録だけが行われ、実
際のメッセージの配送は、メソッドの終了時(Exitする
とき)にまとめて行われる。
r)におけるセンド(Send)の手続きを示す。
は、すでに述べたようにセンド(Send)の処理を遅延実
行テーブル(DelayedExecutionTable)に登録する。す
なわち、当該テーブルにメタメッセージ内の遅延実行用
引数を登録する。ここでは、メタスペース(mDrive)上
のベースオブジェクトがセンド(Send)をするとき、セ
ンド(Send)に必要なパラメータが入った実体としての
メタメッセージ(MetaMessage)が遅延実行テーブル(D
elayedExecutionTable)に登録される。その後、ステッ
プST52ではサクセス(sSuccess)をメタメッセージ
(MetaMessage)に入れ、R(Resume)を行う。
age)の構成について簡単に説明する。
に示すように、2つの領域に分かれ、メタコール(meta
call)のAPIを実行するために必要な情報(例えば引
数)のための領域Aとエラー用コードを納める領域Bと
を有する。なお、遅延実行テーブル(DelayedExecution
Table)は前記図5で示したフューチャ(Future)の生
成と同じく、メイラ(mailer)のオブジェクトがメモリ
内に当該テーブル用の領域を確保することで生成され
る。
er)におけるキック(Kick)の手続きである。
は、図14と同様にキック(Kick)の処理を遅延実行テ
ーブル(DelayedExecutionTable)に登録する。その後
は、ステップST62にてサクセス(sSuccess)をメタ
メッセージ(MetaMessage)に入れ、R(Resume)を行
う。
r)の終了時(Exit)で、メタスペース(mDrive)上のベ
ースオブジェクトが処理を終了するときに呼び出される
手続きである。ここでは、遅延実行テーブル(DelayedE
xecutionTable)に登録された手続きを、処理の依頼さ
れた順序で実行し、最後にオブジェクトのメソッドの終
了手続きをする。
71として、終了(Exit)の手続きを依頼したベースオ
ブジェクトを特定する(例えば関数GetLast()を使って
特定する)。
ブジェクトが割込みによって起動されたかどうかを調べ
る。すなわち、終了(Exit)メソッドが起動された原因
がベースオブジェクトの割り込みによるものか判断す
る。割り込みで起動された場合、その割り込みの後に更
に別の割り込みがある可能性が考えられる。図20に示
すように、ベースオブジェクトIの実行中にベースオブ
ジェクトIIが割り込んだ場合、ステップST73では
今回の終了(Exit)が当該ベースオブジェクトIIの割
り込みの終了(Exit)か否かを判断する。ステップST
72、ステップST73にて共に真(TRUE)である
と判断された場合は、ステップST74にて上記別の割
り込みに戻る(Resume Interrupt)。ステップST7
2、ステップST73で偽と判断されたら、ステップS
T75のように、遅延実行テーブル(DelayedExecution
Table)に登録された手続きを処理する。この処理につ
いて、センド(Send)については後述する図17、キッ
ク(Kick)については後述する図18が示している。
(DelayedExecutionTable)のための処理を終えると、
ステップST76にて再びそのベースオブジェクトが割
込みで起動されたかどうか調べる。このステップST7
6は、ステップST72と実質的に同じである。ここ
で、もし割込みで起動されている場合は、ステップST
77にて、そこから復帰するための手続き(ExitFromIn
terrupt())を実行して最初の割り込みを終了する。
一方、割り込みで起動されていない場合は通常のオブジ
ェクト間通信で起動された場合である。この場合、それ
まで実行していたオブジェクトを休眠状態にするため
に、ステップST78にて遅延実行テーブル(DelayedE
xecutionTable)を初期化し、スケジューラ(Schedule
r)に休止(MakeDormant)するようにメッセージを送
る。引数(Base Thread)はステップST71で特定さ
れたベースオブジェクトである。さらに、ステップST
79にて、そのベースオブジェクトのメッセージキュー
からそれまで実行していたメッセージを取り除く。
はそれで終了である。もしもメッセージキューが空では
なかった場合には、次に配送されるべきメッセージを引
数にして、スケジューラ(Scheduler)に(再び、その
オブジェクトが引数で与えられるメッセージによって起
動されるように)メイクレディ(MakeReady)を発行(i
ssue)し、次のメッセージのためにそのオブジェクトを
実行可能状態(Ready)にする。
ブル(DelayedExecutionTable)に登録された手続きの
一つを処理するシナリオを示す。当該テーブルに例えば
10個が発行されれば10回実行が行われる。メッセー
ジの有無によるスケジューラ(Scheduler)への依頼事
項はメタオブジエクト(MLocalMailer)の場合と同じで
ある。
Mailer)のセンド(Send)の場合は、先ず、ステップS
T81にてコンティネーション(Continuation)を生成
する。
先がメタスペース(mDrive)オブジェクトか判断する。
もし偽であれば、後述するメタオブジエクト(Delivere
r)に処理の依頼を行わない、タグ通信が行われる。ス
テップST83ではメッセージ(ActiveMessage)を配
送する宛て先のオブジェクトのメッセージキューの状態
を調べる。このとき、メッセージキューにメッセージが
ない場合には、そのオブジェクトは休眠状態(スケジュ
ーラ(Scheduler)が管理している状態では休止(Dorma
nt))なので、ステップST85として、スケジューラ
(Scheduler)にメイクレディ(MakeReady)を発行(is
sue)してオブジェクトを実行可能状態(スケジューラ
(Scheduler)が管理している状態ではレディ(Read
y))にする。
83において、真の場合には、すでにそのメッセージが
宛て先のオブジェクトに配送されて、そのオブジェクト
が実行可能状態、実行状態(RUNNING)、または実行中
断状態(Suspend)なので、ステップST84として、
メッセージキューの最後にそのメッセージを入れて終了
する。このとき、メッセージ送信に対応したコンティネ
ーション(Continuation)或いはそれを指し示すTID
(後述する)もあわせてメッセージキューで管理する。
Mailer)のキック(Kick)の場合は、ステップST91
において、与えられたコンティネーション(Continuati
on)がメタオブジエクト(MDriveMailer)のコンティネ
ーション(Continuation)なのかどうかを確認する。ス
テップST91が真の場合はステップST92にてコン
ティネーション(Continuation)の存在を確認する。こ
のコンティネーションが確認されたら、ステップST9
3で当該コンティネーション(Continuation)を開き、
コンティネーション内の属性(宛先、メソッド、メッセ
ージ(msg))をチェックし、それに基づいてセンド(S
end)を行う。次のステップST94にてメッセージの
確認を行い、ステップST95では、メッセージキュー
の最後にそのメッセージを入れて終了する。このとき、
メッセージ送信に対応した後述するタグID(TID)もあ
わせてメッセージキューで管理する。
そうでないとされた場合は、ステップST96にてスケ
ジューラ(Scheduler)にメイクレディ(MakeReady)を
発行してオブジェクトを実行可能状態にする。なお、ス
テップST94、ST95、ST96は、図17のステ
ップST83、ST84、ST85と同様の機能であ
る。ステップST91で偽と判断されたら、後述するタ
グを使った通信機構で他のメタスペースと通信する場合
に相当し、メタオブジェクト(Deliverer)に処理の依
頼を行う。
オブジェクト間通信をするには、単純なメッセージ送信
の他に、返答を受け取ったり他のメソッドの実行と同期
をとることが必要になる。このとき、フューチャ(Futu
re)やコンティネーション(Continuatin)のようなも
のが必要になる。このような複数のオブジェクト間通信
(本実施の形態ではフューチャやコンティネーション
等)で必要とされる同期や並行性を制御するデータ構造
を本実施の形態ではタグと呼ぶ。ここでいうデータ構造
とは例えばC言語やPASCALでいうところのStruct
ureやC++でいうClassのような構造を示す。このタグ
とは異なるデータ構造をある共通のデータ構造で関連付
けるものであり、この共通のデータ構造はこれらの異な
るデータ構造を区別するための識別子(属性:例えばEx
ecSpaceID mailer)を含むように構成される。さらに、
同種類のデータ構造間の区別を与えるための識別子(属
性:例えばlongword timeStamp)を有することでより多
くのデータ構造が管理できる。詳細は図21の説明時に
行う。また、タグを識別するために必要なIDをタグI
D(TID)と呼ぶ。
になる。タグの型はそのタグがどの環境で使われるどの
ようをものかを特定できる必要がある。ただし、タグの
型はグローバルに認識ができるものである必要はない。
ある環境でそのタグの型を特定できなかった場合には、
そのタグの型を特定できる他の独立したオブジェクトに
問い合わせなどを行なうことでそれを解決することがで
きればよい。
スペース(mDrive)におけるフューチャ(Future)、コ
ンティネーション(Continuation)の例を使って、タグ
を使った異なるメタスペース間の通信について述べる。
本実施の形態の例では、メタスペース(mLocal)にオブ
ジェクトA、メタスペース(mDrive)にオブジェクトB
が存在し、それぞれ前述同様に、以下のようなメソッド
が定義されているとする。
メタスペース間通信の基本的な動作について述べる。
1))がメソッドB1(B::B1)にセンド及びウェイトフ
ォー(Send+WaitFor)する場合 2.オブジェクトB(メソッドB1(B::B1))がメソ
ッドA1(A::A1)にセンド(Send)し、継続メソッド
としてメソッドB2(B::B2)を指定した場合 [オブジェクトA(メソッドA1(A::A1))がメソッ
ドB1(B::B1)にセンド及びウェイトフォー(Send+W
aitFor)する場合]メソッドA1(A::A1)はセンド(S
end)(オブジェクトB,メソッドB1,メッセージ(ma
g),関数sizeof(msg),フューチャID(futureID))を
実行する。このとき、実際にこの手続きを処理するメタ
オブジエクト(MLocalMailer)はフューチャ(Future)
を生成する。フューチャ(Future)は次の要件を満たし
ていればよい。すなわち、フューチャ(Future)がタグ
IDで特定できるユニークな実体であること、タグの型
がメタスペース(mLocal)のフューチャ(Future)であ
ることを示すこと、及び図6で示したフューチャ(Futu
re)の属性を持っていること。
んらかの方法でメタオブジエクト(MDriveMailer)にメ
ッセージ(msg)をオブジェクトBまで配送するように
依頼すると共に、メソッドB1(B::B1)を起動するよ
うに依頼をする。このとき、フューチャ(Future)を特
定することができるタグIDをあわせて配送する。ま
た、このときそのフューチャ(Future)を後に特定する
ことができるようにフューチャID(futureID)を受け
取る。ここではその型の変数をフューチャID(futureI
D)としている。このIDは、タグIDをメタスペース
(mLocal)の仕様にあわせてマップしたものであると考
えられる。
g)によってメソッドB1(B::B1)が起動されたとき、
そのメッセージがどこから配送されたかを知ることはで
きない(或いは知るべきではない)。これが透明性のあ
るオブジェクト間通信の実現で要求される。メソッドB
1(B::B1)は起動されるときに、コンティネーション
(Continuation)がメッセージ(msg)といっしょに配
送される。コンティネーション(Continuation)は型
(コンティネーションID(contID))として扱い、こ
こではその変数を(contID)とする。この変数(contI
D)は先のフューチャID(futureID)と同じタグを特定
していることになる。
ック(Kick(contID))を実行する。このとき、メタオ
ブジエクト(MDriveMailer)はコンティネーションID
(変数contID)で特定できるタグの型をチェックする。
このとき、タグIDの管理方式の観点から、次の二つの
可能性がある。
コンティネーションID(contID)で特定できるタグの
型をメタスペース(mLocal)のフューチャ(Future)で
あるとわかる場合(タグIDの管理方式(1)) 2.メタオブジエクト(MDriveMailer)がコンティネー
ションID(contID)で特定できるタグの型を知ること
ができない場合(タグIDの管理方式(2)) 前者の場合、メタオブジエクト(MDriveMailer)はなん
らかの方法でメタオブジエクト(MLocalMailer)に直接
タグIDを配送することができる。メタオブジエクト
(MLocalMailer)はタグIDが配送されると、それはメ
タスペース(mLocal)上でリプライ(Reply())が行わ
れるのとまったく同じように処理を進めることができ
る。すなわち、タグID(=フューチャID(futureI
D))に対応したフューチャ(Future)に対して、図1
0で示したシナリオと同様にメソッドA1(A::A1)の
実行を再開させたり、返答メッセージをフューチャ(Fu
ture)に一時的に保存しておくことができる。
(MLocalMailer)に配送する方法として、次の方法が考
えられる。
クトがあり、そのオブジェクトはタグIDを与えるとそ
のタグIDの型を調べ、そのタグを処理できるAPIと
してのメイラ(Mailer)を教えてくれるメソッドを用意
する。メタオブジエクト(MDriveMailer)はこのメソッ
ドを利用して、そのタグIDをメタオブジエクト(MLoc
alMailer)に配送すればよいことを知ることができ、直
接メタオブジエクト(MLocalMailer)にタグIDを配送
する方法(タグIDの管理方式(2A)) 2.タグの型を管理している別のオブジェクトがあり、
そのオブジェクトは与えられたタグIDを直接それに対
応したタグを処理できるメイラ(Mailer)に配送してく
れる方法(タグIDの管理方式(2B)) これらの場合も、最終的にはメタオブジエクト(MLocal
Mailer)にタグIDが配送され、図10で示したシナリ
オと同様にメソッドA1(A::A1)の実行を再開させた
り、返答メッセージをフューチャ(Future)に一時的に
保存しておくことができる。
1))がメソッドA1(A::A1)にセンド(Send)し、継
続メソッドとしてメソッドB2(B::B2)を指定した場
合]メソッドB1(B::B1)はセンド(オブジェクト
A,メソッドA1,メッセージ(msg),関数(sizeof
(msg)),メソッドB2、メッセージ(contMsg))を実
行する。このとき、実際にこの手続きを処理するメタオ
ブジエクト(MDriveMailer)はコンティネーション(Co
ntinuation)を生成する。コンティネーション(Contin
uation)は次の用件を満たすことになる。
グIDで特定できるユニークな実体であること、タグの
型がメタスペース(mDrive)のコンティネーション(Co
ntinuation)であることを示すこと、及び図8で示した
コンティネーション(Continuation)の属性を持ってい
ること。
OSは、なんらかの方法でメタオブジエクト(MLocalMa
iler)にメッセージ(msg)をオブジェクトAに配送
し、メソッドA1を起動するように依頼する。このと
き、コンティネーション(Continuation)を特定するこ
とができるタグIDをあわせて配送する。
クト間通信では、このタグIDはコンティネーションI
D(ContID)として扱われるものになる。しかし、この
場合はメタオブジエクト(MLocalMailer)ではそれをコ
ンティネーションID(ContID)として扱う必要はな
く、タグIDとして扱う。そして、メタスペース(mLoc
al)の通常のオブジェクト間通信ではメッセージを配送
してあるメソッドを起動すると、それにフューチャ(Fu
ture)(またはフューチャID(futureID))が関係付
けられるのと同様に、メタオブジエクト(MDriveMaile
r)から配送されたタグIDが関係付けられる。
プライ(Reply()またはReply(ReplyMsg))を実行す
る。このとき、メタオブジエクト(MLocalMailer)はメ
ソッドA1(A::A1)を起動したときに関係付けられた
タグIDを調べ、タグIDが特定するタグの型をチェッ
クする。このとき、メタスペース(mLocal)上のオブジ
ェクトAからメタスペース(mDrive)上のオブジェクト
Bに通信した場合と同様に、タグIDの管理方式の観点
から、次の二つの可能性がある。
タグIDで特定できるタグの型をメタスペース(mDriv
e)のコンティネーション(Continuation)であるとわ
かる場合(タグIDの管理方式(1)) 2.メタオブジエクト(MLocalMailer)がタグIDで特
定できるタグの型を知ることができない場合(タグID
の管理方式(2)) いずれの場合においても、メタスペース(mLocal)上の
オブジェクトAからメタスペース(mDrive)上のオブジ
ェクトBに通信した場合と同様、なんらかの方法でメタ
オブジエクト(MDriveMailer)にタグIDを配送でき
る。メタオブジエクト(MDriveMailer)はタグIDを受
け取ると、図18で示したシナリオと同様の手続きを行
なう。すなわち、はじめにタグIDに対応したコンティ
ネーション(Continuation)を開き(Open)し、継続メ
ソッドと継続メッセージを得る。そして、継続メソッド
を配送するべきオブジェクト(コンティネーション(Co
ntinuation)のクリエータ(creator))のメッセージ
キューの状態に応じて、スケジューラ(Scheduler)を
アクセスし、最終的にメソッドB2(B::B2)を起動す
る。
の実現事例」本章では、本実施の形態において、タグを
使ってそれぞれメタスペース(mLocal)、メタスペース
(mDrive)に存在するオプジェクドが透明性を持って通
信することを可能にした実現方式について述べる。ここ
では異なる通信機構としてメタスペース(mLocal)通信
機構とメタスペース(mDrive)通信機構の二つのみが存
在することを仮定する。
ョン(Continuation)とタグ(Tag)]メタスペース(m
Local)におけるフューチャ(Future)、メタスペース
(mDrive)におけるコンティネーション(Continuatio
n)を、OSではタグ(Tag)として扱うことが可能であ
る。このとき、OSはタグ(Tag)がフューチャ(Futur
e)であるかコンティネーション(Continuation)であ
るかを識別する必要がある。それを識別するための型と
してAPIのメイラ(Mailer)のIDを使う。タグの型
として使われるメイラID(MailerID)がメタオブジエ
クト(MLocalMailer)の場合にはフューチャ(Futur
e)、メタオブジエクト(MDriveMailer)の場合にはコ
ンティネーション(Continuation)であると認識するこ
とができる。
e)、コンティネーション(Continuation)の関係、タ
グ(Tag)とタグID(TID)の関係をいわゆるOMT
(object modeling technique)法のオブジェクトモ
デル図で示している。クラスフューチャC1と、クラス
コンティネーションC2はクラスタグC3から派生した
サブクラスとして定義できる。タグ(Tag)はメイラ(M
ailer)を識別するIDとして実行場所ID(ExecSpace
ID)を使っている。この場合、実行場所ID(ExecSpac
eID)は、そのオブジェクトを示すIDと等価な意味で
使われている。タグ(Tag)はタグID(TID)というI
Dによって特定できる。タグ(Tag)に含まれるタイム
スタンプ(timeStamp)はタグ(Tag)をタグID(TI
D)を使って特定するとき時間軸に対してユニークであ
ることを保証するために使用される。フューチャ(Futu
re)およびコンティネーション(Continuation)を特定
することができれば、タイムスタンプ(timeStamp)は
必ずしも使われる必要はない。
ペース(mDrive)通信機構ではそれぞれフューチャ(Fut
ure)、コンティネーション(Continuation)を特定す
るためにフューチャID(futureID)、コンティネーシ
ョンID(ContID)が使われる。タグ(Tag)を導入し
た場合、OS内ではこれらはすべて共通に表記されるこ
とのできるタグID(TID)として特定することができ
る。
ース(mLocal)やメタスペース(mDrive)を提供してい
るインターフェースをそのまま使用することができるよ
うに、インターフェースを定義しているへッダフアイル
(MLocal.h、MDrive.h)では型の再定義が行われてい
る。すなわち、メタスペース(mLocal)のへッダフアイ
ル(MLocal.h)ではフューチャID(futureID)をタグ
IDに再定義する。これを例えばC言語やC++の定義
方法で示すと、typedef TID futureID;となる。な
お、typedefは新しい型を定義(define)すると言う意
味である。メタスペース(mDrive)のヘッダファイル(M
Drive.h)のコンティネーションヘッダファイル(Cont.
h)ではコンティネーションID(ContID)をタグID
に再定義している。これも同様に示すと、typedef TID
ContID;となる。
送するオブジェクト(Deliverer)]本実施の形態で
は、前記タグIDの管理方式(2B)を適用している。異
なるメタスペース間の通信機構をサポートするメタオブ
ジェクトとして、Delivererを導入する。オブジェクト
(Deliverer)は主に二つのインターフェース(メソッ
ド或いはAPI)を持つ。
ス(sError DeliverObject)は、メッセージ(msg)を
指定されたオブジェクト(destination)(引数オブジ
ェクトID(OID)及び宛先メソッド(sel)で示さ
れる。)に配送し、最終的にオブジェクト(destinatio
n)のメソッド(method)が起動されるよう、オブジェ
クト(destination)が存在するメタスペースのメイラ
(Mailer)に依頼をする。このインターフェース(sErr
or DeliverObject)は更に、引数の一つとして配送され
るタグID(TID)を、オブジェクト(destination)が
返答する場合に使用する。
ivereTag)は、タグID(TID)を配送する。オブジェ
クト(deliverer)はタグID(TID)に対応したタグ
(Tag)の型を調べ、どのメイラ(Mailer)にタグID
(TID)を配送すればよいかを知る。必要に応じて、返
答メッセージ(replyMsg)も配送する。
ion)が存在するメタスペースのメイラ(Mailer)を知
る方法としては、 1.オブジェクトの生成時にあらかじめオブジェクト
(deliverer)に登録をして、オブジェクト(delivere
r)がその内容を(テーブルなどを使って)管理する方
法 2.オブジェクトから直接たどることができるデータ構
造に、そのオブジェクトが所属しているメタスペースま
たはメタスペースを識別できるなにかのIDを含めてお
く方法 が考えられる。本実施の形態では、後者の方法を使って
いる。
異なるメタスペース間通信では、以下の二つの異なるメ
タスペース間通信(異なるメタスペースに存在するオブ
ジェクト間通信)が考えられる。
がメタスペース(mDrive)オブジェクトと通信する(或
いは通信して返答を受け取る)場合 B.メタスペース(mDrive)オブジェクトがメタスペー
ス(mLocal)オブジェクトに通信する(或いは通信して
返答を受け取る)場合 図22と図23は、オブジェクト(deliverer)を介し
て異なるメタスペース(メタスペース(mLocal)とメタ
スペース(mDrive))間通信を行なう場合の前者Aを、
図24と図25は後者Bのシナリオを示している。
alMailer)がベースオブジェクトのセンド(Send)の手
続きの依頼を受け付けてからフューチャ(Future)を生
成する処理(ステップST101)までは、図9と同様
である。但し、このフューチャ(Future)はタグのサブ
クラスとして生成される。
ージの配送先の確認を行い、メッセージの配送先がメタ
スペース(mLocal)オブジェクトではない場合、オブジ
ェクト(Deliverer)のメソッド(DeliverObject)にメ
ッセージを送る。
eliverObject)の引数にてその配送先を知ることができ
るので、ステップST103のように、そのメイラ(MD
riveMailer)にさらに配送する。ステップST106以
降に示す、メタオブジエクト(MDriveMailer)がインタ
ーフェース(DeliverObject)を通じて配送依頼された
後の手続き(ステップST106、ST107、ST1
08)は、前述した図17のメタオブジエクト(MDrive
Mailer)が終了時(Exit)にセンド(Send)のために行
なう手続き(ステップST83、ST84、ST85)
と同様である。但し、この場合はステップST107に
てメッセージキューにタグID(TID)を加えるようにな
っている。
れたタグID(TID)がメタスペース(mDrive)ではコン
ティネーションID(ContID)として扱われて、これを
キック(Kick)した場合の手続きを示している。
(MDriveMailer)は、ステップST111にて終了時
(Exit)のキック(Kick)のための処理時に指定された
コンティネーションID(ContID)がメタスペース(mDr
ive)のコンティネーション(Continuation)のもので
はないとわかる。そこでオブジェクト(Deliverer)の
タグ(DeliverTag)を使ってタグID(TID)を配送す
る。
T112にてタグID(TID)からタグ(Tag)を特定
し、その属性(ExecSpaceID meiler)から、そのタグ
(Tag)がメタオブジエクト(MLocalMailer)のもの
(メタスペース(mLocal)のフューチャ(Future))と
わかる。そこでメタオブジエクト(MLocalMailer)にそ
のタグID(TID)を配送する。
ID(TID)を受け取った後の手続きは、前述した図1
0のメタオブジエクト(MLocalMailer)のリプライ(Re
ply)と同様である(ステップST13が真であった場
合以降ステップST14、ST15、ST16、ST1
7、ST20まで)。
ive)からメタスペース(mLocal)にメッセージを送信
し、返答を受け取る場合のシナリオである。オブジェク
ト(Deliverer)の動作は図22、図23と同様であ
る。
クト(MDriveMailer)がベースオブジェクトのセンド
(Send)の手続きの依頼を受け付けてからコンティネー
ション(Continuation)を生成する処理(ステップST
121)は、図17と同様である。
ージの配送先の確認を行い、メッセージの配送先がメタ
スペース(mDrive)オブジェクトではない場合、オブジ
ェクト(mMLocal)のメソッド(DeliverObject)にメッ
セージを送る。
知ることができるので、ステップST123のように、
そのメイラ(MLocaMailer)にさらに配送する。ステッ
プST126、ST127、ST128に示す、メタオ
ブジエクト(MLocalMailer)がインターフェース(Deli
verObject)を通じて配送依頼された後の手続きは、前
述した図18のメタオブジエクト(MDriveMailer)が終
了時(Exit)にセンド(Send)のために行なう手続き
(ステップST94、ST95、ST96)と同様であ
る。
(MLocalMailer)は、ステップST131からステップ
ST134にて終了時(Exit)のキック(Kick)のため
の処理時に指定されたフューチャID(futureID)がメ
タスペース(mLocal)のフューチャ(Future)のもので
はないとわかる(図10のステップST11、ST1
2、ST13と同様)。そこでオブジェクト(Delivere
r)のタグ(DeliverTag)を使ってタグID(TID)を配
送する(図10のステップST13の偽の場合と同
じ)。
135にてタグID(TID)からタグ(Tag)を特定し、
その属性(ExecSpaceID meiler)から、そのタグ(Ta
g)がメタオブジエクト(MDriveMailer)のもの(メタ
スペース(mDrive)のコンティネーション(Continuati
on)とわかる。そこでメタオブジエクト(MDriveMaile
r)にそのタグID(TID)を配送する。
ID(TID)を受け取った後の手続き(ステップST1
38以降)は、前述した図18のメタオブジエクト(MD
riveMailer)の処理(ステップST93、ST94、S
T95、ST96)と同様である。
これまでに説明した実施の形態での実現方式以外に考え
られる「タグを使った通信機構」の実現方式について述
べる。
実施の形態では、タグ(Tag)の属性としてメイラ(Mai
ler)のIDを持っている。これによってタグ(Tag)の
型を識別した。つまり、タグID(TID)からタグ(Ta
g)を特定し、その属性からタグの型を認識した。別の
方法ではタグIDにタグの型を認識するための情報を付
加する方式である。いまタグIDが32ビットで表わさ
れる整数値だとした場合、例えば下位2ビットをタグ
(Tag)の型のために使うという方式が考えられる。図
26には、タグIDでタグの型を認証する方式の一例を
表す。すなわちこの図26では、下位2ビットの組み合
わせが00のときにはメタスペース(mLocal)のフュー
チャ(Future)を表すものとし、下位2ビットの組み合
わせが01のときにはメタスペース(mDrive)のコンテ
ィネーション(Continuation)を表すものとする。この
ようにタグの実体を用いずにタグID(TID)にみを発
生させて、このタグID(TID)にタグの属性を含めた
OMTを図21に対して図27として示す。なお、図2
7中の指示符号C1,C2は図21と同じものである。
このようにすれば、タグを介することなくフューチャや
コンティネーションを対応付けることができる。この場
合は、タグの領域をメモリ内に確保する必要がないの
で、メモリ領域を削減できる利益がある。なお、本実施
の形態ではタグの下位2ビットを利用する例を述べた
が、1ビット或いは上位、中位の任意のビットを用いて
も良いことは勿論である。
述したようにタグの管理方式(1)、(2A)、(2
B)の可能性を示したが、いずれの方式もタグにはその
属性として型があり、メイラ(Mailer)はその型を調べ
ることで少なくともそのメイラ(Mailer)自身が処理で
きるタグかどうかを判断する方式について述べた。これ
らとは別に、タグの属性には型を持たせずに、ただその
メイラ(Mailer)が処理できるタグをメイラ(Mailer)
内部に情報として管理するという方式が考えられる。
チャ(Future)やコンティネーション(Continuation)
を生成したら、その情報をメイラ(Mailer)自身が持つ
テーブルなどに保存する。リプライ(Reply)やキック
(Kick)でタグを配送するとき、メイラ(Mailer)はそ
のテーブルを走査し、そのタグがそのメイラ(Mailer)
で処理できる場合は通常のリプライ(Reply)、キック
(Kick)の処理を行なう。そうでない場合は、タグの管
理方式(2A)のように、どのメイラ(Mailer)にタグ
を配送すればよいか問い合わせたり、(2B)のように
他のオブジェクトに処理の続きを依頼することができ
る。
ジェクト(Deliverer)のような)タグIDとそれに対
応したタグを処理できるメイラ(Mailer)を知ることが
できるオブジェクトも、タグの属性としての型がない場
合には、テーブルなどでその対応を管理する必要があ
る。
におけるスレッド(Thread)の状態遷移図を示し、以下
にスケジューラ(Scheduler)の仕様の例を示す。
各状態を呈する。スケジューラ(Scheduler)はこれら
スレッド(Thread)の状態変化を司り、優先順位のよう
な属性(attribute)に基づいて次にどのスレッドを実
行すべきかを決定する。
ead)に関して実行されるべきものが無いことを示す、
このときのメッセージ(message)は受信可能の状態に
ある。
(Thread)は実行可能状態にあることを示し、スケジュ
ーラ(Scheduler)内の実行可能状態のスレッド(Threa
d)のためのキュー(レディキュー(Rdady Queus))に
入れられる(enqueue)。スレッド(Thread)が実行可
能状態(Ready)のときそのスレッド(Thread)に対応
付けられたオブジェクトはM(Meta Computation)で呼
び起こされる。
ead)は実行中であることを示す。
中断状態を示し、例えば前述のメタスペース(mLocal)
通信機能によってウェイトフォー(WaitFor)がリプラ
イ(Reply)よりも先に発行された場合に生ずる。
いくつか示す。
によりリンクされた宛先オブジェクトのセレクタ(se
l)で指定されるメソッドにメッセージ(msg)を送るた
めにメーラメタオブジェクト(例えば前述のメタオブジ
ェクト(MLocalMailer))により使用される。
hread)の状態を休止状態(Dormant)から実行可能状態
(Ready)に遷移させ、上記レディキュー(Rdady Queu
s)内の列にそれを入れる(enqueue)。
スケジュールされた時、すなわち上記スケジューラ(Sc
heduler)により実行可能状態(Ready)のスレッド(Th
read)が実行されるときに呼び起こされる。
果の状態を示し、メイクレディ(MakeReady)が正しく
動作した場合、それを示す返り値(sSuccess)を返す。
そうでない場合は各種のエラーを示す値を返す。
の実行を開始するためにメーラによって使用される。ス
ケジューラ(Scheduler)はスレッド(Thread)の状態
を待機状態(Wait)から実行可能状態(Ready)に変化
させ、レディキュー(Rdady Queus)内の列にそれを入
れる(enqueue)。このインターフェースは例えば前述
のメタスペース(mLocal)通信機能によってウェイトフ
ォー(WaitFor)を発行して待機状態(Wait)にあるオ
ブジェクトが、別のオブジェクトの発行したリプライ
(Reply)によって結果メッセージを受け取り、実行可
能状態にする必要があるときに使われる。
の実行を停止するために利用される。スケジューラ(Sc
heduler)はスレッド(Thread)を実行可能状態(Read
y)から待機状態(Wait)に遷移させ、レディキュー(R
dady Queus)内の列からそれを除く(dequeue)。な
お、上記各メーラはベースオブジェクトの実行停止のた
め、このインターフェースを呼び出す必要はない。なぜ
ならば、ベースオブジェクトが上述のM(Meta Computa
tion)を使ってメーラを呼び起こす時にその状態は待機
状態(Wait)に変化しているからである。
の実行を終了するために上記メーラによって利用され
る。スケジューラ(Scheduler)はスレッド(Thread)
の状態を実行可能状態(Ready)から休止状態(Dorman
t)に変化させ、レディキュー(Rdady Queus)内の列か
らそれを除く(dequeue)。
ジェクト(又はそれに関連付けられたスレッド)の状態
は、休止状態(Dormant)、実行可能状態(Ready)、待
機状態(Wait)の3つである。これは複数の実行可能状
態にあるオブジェクトのうち、どのオブジェクトをCP
Uが処理している(Running)かどうか、メイラは知る
必要がないからである。
ターフェースを持った通信機構がそれぞれ固有に持つオ
ブジェクト間通信の同期及び並行性の制御を行うための
タグを導入することによって、異なる環境間のオブジェ
クト間通信を透明性をもって容易に実現することができ
る。
るVCR装置の概略構成を示すブロック回路図である。
用OSとAPIにより通信が行われる様子の説明に用い
る図である。
ォー(WaitFor)がリプライ(Replay)よりも先に実行
された場合)の説明に用いる図である。
(Replay)がウェイトフォー(WaitFor)よりも先に実
行された場合)の説明に用いる図である。
ラのオブジェクトやスケジューラのオブジェクトに通信
を行う様子の説明に用いる図である。
である。
る図である。
説明に用いる図である。
ーラ(Scheduler)の関係(メタスペース(mLocal)に
おけるセンド(Send)の実現)の手続きの流れを示す図
である。
ューラ(Scheduler)の関係(メタスペース(mLocal)
におけるリプライ(Replay)の実現)の手続きの流れを
示す図である。
ューラ(Scheduler)の関係(メタスペース(mLocal)
におけるウェイトフォー(WaitFor)でリプライ(Repla
y)がウェイトフォー(WaitFor)よりも先に実行された
場合)の手続きの流れを示す図である。
ューラ(Scheduler)の関係(メタスペース(mLocal)
におけるウェイトフォー(WaitFor)でウェイトフォー
(WaitFor)がリプライ(Replay)よりも先に実行され
た場合)の手続きの流れを示す図である。
センド(Send)の手続きの流れを示す図である。
キック(Kick)の手続きの流れを示す図である。
(Exit)で、メタスペース(mDrive)上のベースオブジ
ェクトが処理を終了するときに呼び出される手続きの流
れを示す図である。
に登録(メタオブジエクト(MDriveMailer)のセンド
(Send)の場合)された手続きを処理する流れを示す図
である。
に登録(メタオブジエクト(MDriveMailer)のキック
(Kick)の場合)された手続きを処理する流れを示す図
である。
明に用いる図である。
ジェクトIIが割り込んだ場合の動作説明に用いる図で
ある。
ティネーション(Continuation)の関係、タグ(Tag)
とタグID(TID)の関係をOMT法のオブジェクトモ
デルで示す図である。
タスペース間通信を行なう場合(メタスペース(mLoca
l)がメタスペース(mDrive)に通信する場合)の往路の
流れを示す図である。
タスペース間通信を行なう場合(メタスペース(mLoca
l)がメタスペース(mDrive)に通信する場合)の復路の
流れを示す図である。
タスペース間通信を行なう場合(メタスペース(mDriv
e)がメタスペース(mLocal)に通信する場合)の往路
の流れを示す図である。
タスペース間通信を行なう場合(メタスペース(mDriv
e)がメタスペース(mLocal)に通信する場合)の復路
の流れを示す図である。
表す図である。
OMTを示す図である。
veMailer メタオブジエクト
Claims (10)
- 【請求項1】 複数のオブジェクト間で通信を行うデー
タ通信方法において、 異なる性質或いはインターフェースを持った通信機構を
それぞれ固有に持つオブジェクト間の通信の同期及び並
行性の制御を行うためのタグを生成し、 当該タグを通信メッセージと共に通信することを特徴と
するデータ通信方法。 - 【請求項2】 上記タグを生成する際、上記タグを識別
するためのタグIDと当該タグの型を示す属性とを、少
なくとも生成することを特徴とする請求項1記載のデー
タ通信方法。 - 【請求項3】 上記タグの型を管理するオブジェクトを
有することを特徴とする請求項1記載のデータ通信方
法。 - 【請求項4】 上記タグの型を管理するオブジェクトを
有することを特徴とする請求項2記載のデータ通信方
法。 - 【請求項5】 上記タグIDはオブジェクトによって上
記通信メッセージと共に配送されることを特徴とする請
求項2記載のデータ通信方法。 - 【請求項6】 上記タグIDを配送するオブジェクト
は、上記タグの型に基づいて配送先を決定することを特
徴とする請求項5記載のデータ通信方法。 - 【請求項7】 上記タグIDを配送するオブジェクト
は、上記タグの型と配送先のテーブルを有することを特
徴とする請求項6記載のデータ通信方法。 - 【請求項8】 上記タグを識別するための情報と当該タ
グの型を示す属性とを、少なくとも示すタグIDを生成
することを特徴とする請求項1記載のデータ通信方法。 - 【請求項9】 複数ビットにて形成される上記タグID
の一部のビットを用いて上記タグの型を表すことを特徴
とする請求項8記載のデータ通信方法。 - 【請求項10】 複数のオブジェクト間で通信を行うデ
ータ通信方法において、 異なる性質或いは異なるインターフェースを持った通信
機構をそれぞれ固有に持つ第1のオブジェクトと第2の
オブジェクト間で通信を行う際、 上記第1のオブジェクトで生成される第1のデータ構造
と上記第2のオブジェクトで生成される第2のデータ構
造を区別するための識別子を有する第3のデータ構造を
生成し、 当該第3のデータ構造に係るデータを通信メッセージと
共に通信することを特徴とするデータ通信方法。
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP09244697A JP3817823B2 (ja) | 1997-04-10 | 1997-04-10 | データ通信方法 |
KR1019980011458A KR19980080985A (ko) | 1997-04-10 | 1998-04-01 | 데이터 통신방법 |
US09/055,669 US6466991B1 (en) | 1997-04-10 | 1998-04-07 | Data communication method |
DE69837825T DE69837825T2 (de) | 1997-04-10 | 1998-04-08 | Datenübertragungsverfahren |
EP98302757A EP0871119B1 (en) | 1997-04-10 | 1998-04-08 | Data communication method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP09244697A JP3817823B2 (ja) | 1997-04-10 | 1997-04-10 | データ通信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH10283205A true JPH10283205A (ja) | 1998-10-23 |
JP3817823B2 JP3817823B2 (ja) | 2006-09-06 |
Family
ID=14054644
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP09244697A Expired - Fee Related JP3817823B2 (ja) | 1997-04-10 | 1997-04-10 | データ通信方法 |
Country Status (5)
Country | Link |
---|---|
US (1) | US6466991B1 (ja) |
EP (1) | EP0871119B1 (ja) |
JP (1) | JP3817823B2 (ja) |
KR (1) | KR19980080985A (ja) |
DE (1) | DE69837825T2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20000050238A (ko) * | 2000-05-30 | 2000-08-05 | 김호광 | 다수의 운영시스템에서 실행 가능한 프로그램 제작 시스템및 방법 |
KR20020031511A (ko) * | 2000-10-20 | 2002-05-02 | 김영돈, 정춘보 | 다수의 하드웨어에서 실행가능한 pda 어플리케이션제작방법 |
JP2007293826A (ja) * | 2006-03-31 | 2007-11-08 | Matsushita Electric Ind Co Ltd | セキュアデバイス及び読み書き装置 |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030079046A1 (en) * | 1996-11-27 | 2003-04-24 | Sony Europa B.V. | Data communication method using typed continuation |
EP1041485A1 (en) | 1999-03-31 | 2000-10-04 | Sony Service Center (Europe) N.V. | Object with polymorphism |
US7480909B2 (en) * | 2002-02-25 | 2009-01-20 | International Business Machines Corporation | Method and apparatus for cooperative distributed task management in a storage subsystem with multiple controllers using cache locking |
US20040003007A1 (en) * | 2002-06-28 | 2004-01-01 | Prall John M. | Windows management instrument synchronized repository provider |
US7124414B2 (en) * | 2002-10-31 | 2006-10-17 | International Business Machines Corporation | Method, system and program product for routing requests in a distributed system |
US8775651B2 (en) * | 2008-12-12 | 2014-07-08 | Raytheon Company | System and method for dynamic adaptation service of an enterprise service bus over a communication platform |
US8891411B2 (en) | 2011-09-23 | 2014-11-18 | Avaya Inc. | System and method for a conference foyer |
KR101389534B1 (ko) * | 2013-06-24 | 2014-04-28 | 액세스모바일 (주) | Id 태그 서비스 제공 시스템 및 방법 |
CN104063285B (zh) * | 2014-01-13 | 2017-06-23 | 惠州华阳通用电子有限公司 | 一种基于车载软件平台进程内模块间的消息广播通信方法 |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH01502861A (ja) * | 1987-09-04 | 1989-09-28 | ディジタル イクイプメント コーポレーション | 多重転送プロトコルを支援するデジタル処理システム用回路網内のセッション制御 |
US5124909A (en) * | 1988-10-31 | 1992-06-23 | Hewlett-Packard Company | Software program for providing cooperative processing between personal computers and a host computer |
EP0501610B1 (en) * | 1991-02-25 | 1999-03-17 | Hewlett-Packard Company | Object oriented distributed computing system |
SE500673C2 (sv) * | 1991-11-27 | 1994-08-08 | Icl Systems Ab | Förfarande och arrangemang för att åstadkomma en förenklad dialog mellan en central datorenhet och minst en användarenhet |
US5566302A (en) * | 1992-12-21 | 1996-10-15 | Sun Microsystems, Inc. | Method for executing operation call from client application using shared memory region and establishing shared memory region when the shared memory region does not exist |
EP0604010B1 (en) * | 1992-12-21 | 1999-12-29 | Sun Microsystems, Inc. | Method and apparatus for subcontracts in distributed processing systems |
JP3238788B2 (ja) * | 1993-03-30 | 2001-12-17 | 株式会社エヌ・ティ・ティ・データ | オブジェクト通信方式 |
AU1747395A (en) | 1994-03-30 | 1995-10-23 | Apple Computer, Inc. | Object oriented message passing system and method |
US5724503A (en) * | 1995-03-31 | 1998-03-03 | Sun Microsystems, Inc. | Method and apparatus for interpreting exceptions in a distributed object system |
US5615351A (en) * | 1995-07-07 | 1997-03-25 | Bell Communications Research, Inc. | Method and system for correlating usage data in a distributed architecture |
CA2240194C (en) * | 1995-12-15 | 2003-06-03 | Object Dynamics Corp. | Method and system for constructing software components and systems as assemblies of independent parts |
JP3622313B2 (ja) * | 1996-01-29 | 2005-02-23 | 株式会社日立製作所 | ドキュメント管理システム |
US6032199A (en) * | 1996-06-26 | 2000-02-29 | Sun Microsystems, Inc. | Transport independent invocation and servant interfaces that permit both typecode interpreted and compiled marshaling |
US6044409A (en) * | 1996-06-26 | 2000-03-28 | Sun Microsystems, Inc. | Framework for marshaling and unmarshaling argument object references |
US5966663A (en) * | 1997-01-14 | 1999-10-12 | Ericsson Messaging Systems Inc. | Data communications protocol for facilitating communications between a message entry device and a messaging center |
US5999988A (en) * | 1997-03-31 | 1999-12-07 | Sun Microsystems, Inc. | Method and apparatus for generating and employing a run-time generated stub to reference an object in object oriented systems |
US6157959A (en) * | 1997-07-03 | 2000-12-05 | Tandem Computers, Incorporated | Method and apparatus for providing portable kernel-mode support for fast interprocess communication |
-
1997
- 1997-04-10 JP JP09244697A patent/JP3817823B2/ja not_active Expired - Fee Related
-
1998
- 1998-04-01 KR KR1019980011458A patent/KR19980080985A/ko not_active Application Discontinuation
- 1998-04-07 US US09/055,669 patent/US6466991B1/en not_active Expired - Lifetime
- 1998-04-08 DE DE69837825T patent/DE69837825T2/de not_active Expired - Lifetime
- 1998-04-08 EP EP98302757A patent/EP0871119B1/en not_active Expired - Lifetime
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20000050238A (ko) * | 2000-05-30 | 2000-08-05 | 김호광 | 다수의 운영시스템에서 실행 가능한 프로그램 제작 시스템및 방법 |
KR20020031511A (ko) * | 2000-10-20 | 2002-05-02 | 김영돈, 정춘보 | 다수의 하드웨어에서 실행가능한 pda 어플리케이션제작방법 |
JP2007293826A (ja) * | 2006-03-31 | 2007-11-08 | Matsushita Electric Ind Co Ltd | セキュアデバイス及び読み書き装置 |
Also Published As
Publication number | Publication date |
---|---|
EP0871119B1 (en) | 2007-05-30 |
KR19980080985A (ko) | 1998-11-25 |
EP0871119A1 (en) | 1998-10-14 |
JP3817823B2 (ja) | 2006-09-06 |
DE69837825T2 (de) | 2008-01-31 |
DE69837825D1 (de) | 2007-07-12 |
US6466991B1 (en) | 2002-10-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1025493B1 (en) | Queued method invocations on distributed component applications | |
JP4550411B2 (ja) | 同期されたコールバック処理特徴をもったトランザクション処理システム及び方法 | |
US5991823A (en) | Low overhead object adaptor | |
US6901596B1 (en) | Method of communicating asynchronous events to remote procedure call clients | |
JP4148528B2 (ja) | 排他制御を効率化する技術 | |
US7424549B2 (en) | System, method, and article of manufacture for using a replaceable component to select a replaceable quality of service capable network communication channel component | |
US20040083481A1 (en) | System and method for transferring data between virtual machines or other computer entities | |
US20030097401A1 (en) | Method for determining on demand right size buffering within a socket server implementation | |
US20050289505A1 (en) | Method and system for improving performance and scalability of applications that utilize a flow-based-programming methodology | |
JPH10283205A (ja) | データ通信方法 | |
JPH0926925A (ja) | オブジェクトの集合を管理する方法および装置 | |
CN111857993B (zh) | 一种内核态调用用户态函数的方法 | |
US6598049B1 (en) | Data structure identifying method and recording medium | |
EP0924606A2 (en) | Method and apparatus for deferred throwing of exceptions in C++ | |
US20020016866A1 (en) | Methods and apparatus for managing computer processes | |
EP0940750B1 (en) | Data processing method | |
EP0940749A2 (en) | Data processing method | |
JP2002522823A (ja) | 分散アプリケーションを実現するためのコンピュータ化された方法およびシステム | |
US6061771A (en) | Cross-system data piping system using an external shared memory | |
CN114296809B (zh) | 一种基于操作***的对象模型构建方法及其***调用接口 | |
US6842900B2 (en) | Information processing apparatus executing processing corresponding to new thread by reusing arrangement for previous thread | |
JPS63113739A (ja) | Osのオ−バレイ方式 | |
JPH11237996A (ja) | 計算機間のデータ連携方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050615 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050726 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050926 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060110 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060313 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060523 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060605 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090623 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100623 Year of fee payment: 4 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110623 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110623 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120623 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120623 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130623 Year of fee payment: 7 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |