JPH08110860A - インターフエース機構、クラス・ライブラリ及び非同期のデータ処理方法 - Google Patents

Abstract

(57)【要約】 【目的】 Ｃ⁺⁺言語のようなシーケンシヤルのオブジエ
クト指向言語において、コンパイラを修正せず、コンピ
ユータ言語を拡張することなく、また事前処理を必要と
せずに非同期で複数の処理動作を与えること。 【構成】 特別に設けられたポインタは、連続した処理
をコーリング・プログラムに許容する所与の応答を戻し
ている間で、プロシージヤのコールを非同期のタスクの
スレツドに変換する。戻された値は、無視されるか、あ
るいは、若しコーリング・プログラムが非同期のスレツ
ドで独立して処理した結果値を必要とすれば、将来の変
数に変換される。本発明は並列マルチプロセツサの環境
でも、並列処理特性を有する単一プロセツサ・システム
の環境でも使用することができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、Ｃ⁺⁺言語のような言語
で書かれたプログラムのコンパイルされたオブジエクト
指向プログラムの活用例において特にプロセツサを最大
限に使用するために、同時処理動作を与える機構に関す
る。

【０００２】

【従来の技術】簡単化されたコンピユータ・モデル（例
えば、独立したワークステーシヨン）において、単一の
プロセツサ中で実行されている単一のプログラムは、プ
ログラムで順序付けられた順番で各プログラム・ルーチ
ンを遂行し、プログラム・ルーチンが完了するまでプロ
セツサを支配する。サブルーチン（メモリの別領域にス
トアされたプログラム・モジユールにより生じるルーチ
ン）に対するコール（呼び出し）は、サブルーチンが処
理されている間で、メイン・プログラムに関するプロセ
ツサの動作の中断、即ち阻止を生じる。このような背景
において、プロセツサのリソースは完全に利用され（プ
ロセツサはアイドル状態にならない）、そして、プロセ
ツサのリソースに対して競合する同時進行のプログラム
はないから、プログラム及びそのルーチンを処理する期
間の間のプロセツサの支配は問題とならない。

【０００３】分散コンピユータ・システムにおいて、複
数のプロセツサの各々は１つのメモリに関連を持ち、そ
して、プログラムの外部サブルーチンに対するコール
は、システム中の異なつたプロセツサ中に常駐するプロ
グラム・モジユールへのコールであることがしばしば生
じる。従つて、メイン・プログラムに対して所望の結果
を返還するためのサブルーチンの動作を遂行するのは遠
隔地プロセツサである。

【０００４】リンクされたマルチ・コンピユータ・シス
テム、即ち分散コンピユータ・システムは、開放された
コンピユータ・システムの供給源（Open System Founda
tion-OSF）の分散した計算環境（Distributed Computin
g Envionment-DCE）の利点によつて次第にポピユラーに
なつてきて、異種のコンピユータ・システムの間で分散
された計算を可能とする技術が出現している。

【０００５】通常の地域的プロシージヤ・コールにおい
て、コーリング・プログラム（呼び出しプログラム）と
特定のサブルーチンとの間に特別なインターフエースが
あり、地域的プロシージヤ・コールは、動作の可能性を
持つすべての必要なロジツクを呼び出す。分散コンピユ
ータ・システム中にあるコーリング・プログラムを含む
装置ではない他の装置中にサブルーチンが常駐する時、
通信ロジツク（即ち、サブルーチンの位置、データ変換
などのロジツク）がそのコールに対して要求され、そし
て、通常、コーリング・プログラム、またはコールド・
プログラム（呼び出されたプログラム）の中に物理的に
コード化されていなければならない。これは、遠隔地プ
ロセツサが、コールした関数と同種でない場合とか、ま
たは互換性を持たない場合には特に複雑になる。

【０００６】これとは対照的に、ＤＣＥが異種のコンピ
ユータ・システムの各々において実施された時、ＤＣＥ
は、地域プロシージヤ・コールの概念を、分散されたコ
ンピユータ・システムの環境、特に異種のコンピユータ
・システムを持つ環境に拡大する「遠隔地プロシージヤ
・コール（ＲＰＣ）」と呼ばれる機構によつてネツトワ
ーク中のコンピユータの間で透明な相互動作を行なわせ
ることができる。

【０００７】その結果、プログラマは、各遠隔地コール
をサポートするコードを最早や必要としないから、遠隔
地コールは、プログラマに対しても、ユーザに対しても
透明に処理される。

【０００８】然しながら、すべての分散コンピユータ・
システムの環境において、プログラムを計画している時
の規則が作られなければ、メイン・プログラムは、メイ
ン・プログラムを中断、即ち阻止して、その遠隔地コー
ルの返還を待機している間でも、そのプロセツサを占領
し続ける。この中断期間の間でプロセツサはアイドル状
態にある。

【０００９】待機しているプログラムが中断されている
時間は、若し遠隔地プロセツサがサブルーチンに直ちに
動作することができるならば、実時間で、たつた１秒に
も満たない時間である。然しながら、複雑な分散コンピ
ユータ・システムにおいて、遠隔地プロセツサにおける
待ち行列は、可成りの遅延時間を生じ、すべての遅延時
間において、待機しているプロセツサはアイドル状態が
続けられる。

【００１０】理想的な状態は、各プロセツサに同時進行
的な動作を持たせること、つまり、すべてのオブジエク
トは分離したスレツド（thread−処理）を持ち、１つの
スレツドが「待機」即ち中断している間で他のスレツド
がプロセツサを使用することができるような状態にする
ことである。

【００１１】ＤＣＥのシステム（及び他のシステム）
は、プログラマが１つのプログラム中で複数のスレツド
を作成し操作できる機構を含んでいる。ＤＣＥのシステ
ムにおいて、このマルチスレツドの機構は、ＩＥＥＥの
１００３．４ａスタンダード（草案４）中のＰｏｓｉｘ
によつて特定される「ピー・スレツド（pthread）」イ
ンターフエースに基づくアプリケーシヨン・プログラム
のインターフエースの型式として存在している。ＩＥＥ
Ｅの１００３．４ａスタンダードは、１９９０年８月１
０日開催のＩＥＥＥコンピユータ協会（IEEE Computer
Society）のオペレーテイング・システムに関する技術
委員会の「Threads Extension for Portable Operating
Systems」と題するＩＥＥＥのＰ１００３．４ａ／Ｄ４
ドラフト・スタンダードである。

【００１２】然しながら、ＤＣＥ及び他のマルチスレツ
ドの機構を持つシステムは、複数の制御スレツドを持つ
プログラムを構成することがプログラマにより必要とな
り、これは、プログラムを設計する際に複雑さを導入す
ることになる。多数のスレツドが管理され、計画され、
そして制御された態様で通信されなければならず、更
に、特に、長いスレツドの拡大が、遠隔地コールの間で
遠隔地プロセツサ中の因子によつて発生された場合に
は、同時進行の処理（concurrency−以下、同時処理と
いう）が適当であるすべての場合を予測することは通常
困難である。

【００１３】従つて、マルチスレツドの機構は使用を妨
げる傾向を持ち、生じ得る問題を予測するのは困難であ
る。

【００１４】加えて、プロセツサ中のスレツドを待機ス
レツドに切り換え、プロセツサのレジスタ中に保持し、
再ロードし、そして新しいスレツドに対して適当なスレ
ツドの積み重ねに調節することに関連するコストの問題
がある。その結果、プロセツサ中のスレツドの間で計画
される制御スイツチの数は、同時処理の経済的利益を事
実上最大限にするために、従来のマルチスレツドの機構
を持つシステムにおいて最小限の数にされなければなら
ない。

【００１５】オブジエクト指向ではないシステム及びあ
る種のオブジエクト指向システムにおいて、上述の問題
の解決方法が提案されており、この方法は、例えば、Ｃ
ＯＯＬ（１９９０年のＭＩＴプレスに記載された、チヤ
ンドラ（R. Chandra）等の「COOL: A Language for Par
allel Programming」、編集者ゲランター（D. Gelernte
r）等の「Languages and Compilers for Parallel Comp
uting」）において、「将来の結果（future result）」
機構と呼ばれて知られている機構である。遠隔地コール
が発生された時、サブルーチンのコールの結果は、将来
のプロシージヤ・コールに応答してメイン・プログラム
に戻されるべき将来のオブジエクト、即ち将来のオブジ
エクト・タイプとしてストアされる。このようにして、
サブルーチンを同時に実行している、即ち同期して実行
している間で、メイン・プログラムはそのプロセツサ中
で実行を続行する。将来の変数が使用可能になる前に、
若しメイン・プログラムが「将来」のコールに到達した
ならば、メイン・プログラムは、所望の結果を待機する
ためにその位置において単純に中断する。

【００１６】オブジエクト指向ではないシステムにおい
て、ユーザが同期呼び出しを行なうメツセージは、コン
ピユータ言語毎に大きく異なつている。ある種のシステ
ムにおいては、アーギユメントとして「将来」コールす
る「解答（resolve）」のような明示的な関数が必要と
され、他方、他のシステムにおいては「将来」のコール
は自動的に処理される。

【００１７】オブジエクト指向の環境は、遠隔地コール
及び遠隔地プロシージヤ・コールを通じて使用するのに
特に適しているように思える。何故ならば、オブジエク
ト指向のコンピユータ言語の概念及び実施は、コードを
共有する場合にモジユラ・プログラミングのためのツー
ルと容易性とを与えるからである。

【００１８】オブジエクト指向のシステムの活用例にお
いて、コンピユータでシミユレートされた「オブジエク
ト」は、相互に独立して定義され、維持されており、オ
ブジエクトの定義は、その「メソツド（method）」（即
ち、そのオブジエクトが遂行する能力を持つているプロ
シージヤ（処理手順）、または処理動作）と、その「変
数」（即ち、属性、または時間の経過で変化する値）と
を含んでいる。オブジエクトはクラス定義（class defi
nition）によつて決められる。オブジエクト・クラス
は、オブジエクトの特定のタイプに含まれているメソツ
ド及び変数を定義するテンプレートである。オブジエク
ト・クラスは他のオブジエクト・クラスの術語で定義す
ることができる。つまり、サブクラスの特性（メソツド
及び／または変数）は、上位のオブジエクト・クラス、
より包括的な基本オブジエクト・クラスから継承するこ
とができる。それらのサブクラスが継承したメソツド及
び変数に加えて、サブクラスはそれ自身のメソツド及び
変数を定義することができ、そして、このように導き出
されたクラスの実施は、他のクラスの実施の汚染を避け
るためにそのクラス内だけで可視的にされるけれども、
このようにサブクラス自身のメソツド及び変数を定義で
きる特性は、継承された特徴を無効にする特性を含んで
いる。

【００１９】アブストラクト・クラスはオブジエクト、
またはインスタンスを持たない基本クラスであり、アブ
ストラクト・クラスのただ１つの目的は、クラス階層を
構成すること、または低いレベルの継承されたクラスに
適用するメソツド、または変数を見い出すことにある。
継承されたメソツド及び変数は、より狭く定義すること
ができ、あるいは、導き出されたクラスを再定義するこ
ともできるので、この技術によつて定義されたオブジエ
クトは、高度に特別化することができ、かつ、全く同一
オブジエクトではないが、関連したオブジエクトを複雑
なシステム中に適合することができ、しかも、クラス階
層は多数のレベルを包括することができる。オブジエク
ト指向の技術により得られる柔軟性は、分散された計算
環境に付加することのできる範囲を拡張する点で明らか
に魅力的である。

【００２０】然しながら、例えば、最もポピユラーなオ
ブジエクト指向のプログラム言語Ｃ⁺⁺は、同時処理のた
めの規則を持たない特有のシーケンシヤル言語である。
事実、同時処理のプログラミング動作は、同時処理機構
の制御、同期及び相互排斥のための適当なサポートがな
いために、一般的にはオブジエクト指向のシステムの適
用例において実施するのは困難であつた。

【００２１】将来の結果は、Ｃ⁺⁺言語以外のオブジエク
ト指向のプログラム言語（例えばＬＩＳＰ、Ｃｏｎｃｕ
ｒｒｅｎｔ ＳｍａｌｌＴａｌｋ及びＣＯＯＬ）に使用
されているが、しかし、Ｃ⁺⁺言語中にそれらの言語を導
入する従来の試みは、例えば将来の結果を特別に取り扱
うプログラムにおいて前書き及び後書きコードを必要と
するような統語論的な不備を持つているか、またはコン
ピユータ言語の拡張、またはコンパイラの標準的でない
修正を必要とする。

【００２２】また、下記の２つのアプローチの内の１つ
を用いてＣ⁺⁺言語に同時処理を付加する多くの試みがな
されてきた。第１のアプローチにおいては、コンピユー
タ言語が拡張され、新しいコンピユータ言語構成が同時
処理機構の作成及び制御を処理するように付加されるこ
と、つまり、コンパイラが新しい言語の作成を認識でき
るように拡張されることである。同時処理を付加するた
めに、これらの言語によつて用いられる共通の方法は、
オブジエクト・レベルにおいて、共通処理機構の作成、
同期及び相互排斥を一括することである。このオブジエ
クトは「アクテイブ」オブジエクトと呼ばれる。このよ
うな新しく拡張されたコンピユータ言語は、強化された
性能、高レベルの構成及びコンパイル時間のチエツクを
与えるけれども、これらの言語はオペレーテイング・シ
ステム間の可搬性がないという点で限界がある。

【００２３】第２のアプローチは、同時処理の低いレベ
ルの細部（例えば、アーキテクチヤ、データ区分、通信
及び同期機能）を一括した再使用可能な抄録ライブラリ
を用いている。このライブラリ式のアプローチは、プロ
グラマが熟知しているコンパイラ及びプログラム用ツー
ルで仕事を遂行することができるように、コンピユータ
言語の外側に同時処理機構を保持し、そして、これは、
オペレーテイング・システム間の高いレベルの可搬性を
サポートし、更に、種々のライブラリによつて多くの同
時処理のモデルをサポートするオプシヨンを与えること
ができる。然しながら、現在の殆どのＣ⁺⁺言語用の同時
処理タスクのライブラリは、「アクテイブ」オブジエク
トを通して同時処理を与えることを試みているが、これ
らのライブラリは暗黙的な同時処理を与えず、また、ユ
ーザに対して使い易さを与えていない。例えば、ブラウ
ン大学のコンピユータ・サイエンス部のドープナ二世
（T.W.Doeppner,Jr）等による「C++ on a Parallel Mac
hine」と題する１９８７年１１月の報告書ＣＳ−８７−
２６に記載されているタスク・ライブラリは、真の同期
処理を与える最も早期のＣ⁺⁺言語のライブラリの１つで
ある。然しながら、スレツドの管理は明確に述べられて
おり（適正な管理をプログラマに課している）、１つの
レベルのサブクラスだけにしか許していない（オブジエ
クト指向の言語において使用可能な複数の継承レベルに
より得られる柔軟性を制限することになる）。多数の継
承レベルを１つに制限することは、１９８９年のＡＴ＆
ＴのＣ⁺⁺言語システムのリリース２．０の「プロダクト
参照マニユアル」選択コード３０７−１４６の中で記載
されているクラス・ライブラリにおいて取られているア
プローチと類似している。ボールダ市のコロラド大学の
コンピユータ・サイエンス部のグランワルド（D.Grunwa
ld）による「A Users Guide to AWESIME: An Object Or
iented Parallel Programming and Simulation System
s」と題する技術リポートＣＵ−ＣＳ−５５２−９１の
中に記載されているライブラリは、「スレツド」と呼ば
れるライブラリ中のタスクのクラスから任意のレベルの
サブクラスにすることを許容しているが、このライブラ
リを用いたスレツド管理は、明示されている。クラス・
ライブラリを介してＣ⁺⁺言語における同時処理の問題を
解決する種々の試みにおいて、ネツトワーク内のオブジ
エクトの配分、非同期呼び出し及び将来の通信に関する
問題には触れられていない。

【００２４】

【発明が解決しようとする課題】従つて、本発明の目的
は、コンパイラの修正とか、特別の事前処理などを必要
としないで、Ｃ⁺⁺言語のようなコンパイルされたオブジ
エクト指向のプログラム言語の中に、非同期の呼び出し
及び将来の結果の両方を円滑かつ暗黙のうちに導入する
機構を提供することにある。

【００２５】本発明の他の目的は、アクテイブ・オブジ
エクト毎にスレツドを発生する機構を提供することにあ
り、この機構によつて、共有メモリ、または分散メモリ
のマルチプロセツサ中か、または同時処理をシミユレー
トするプロセツサ・クラスタ、または単一のプロセツサ
中で他のアクテイブ・オブジエクトを同時に実行するこ
とができる。

【００２６】

【課題を解決するための手段】従つて、本発明は、拡張
されていないコンパイラと、オブジエクト・クラスを作
成するのに適し、かつ 分離した処理動作に関連した少
なくとも２つのメモリ・ストレージ装置とを有する並列
コンピユータの環境におけるコンピユータのオペレーテ
イング・システムによつて実行されるインターフエース
機構及び関連メソツドを与える。このインターフエース
機構は、上述のメモリ・ストレージ装置の１つに関連し
た第１の処理動作からのプロシージヤ・コールを受け取
り、かつ、第１の処理動作の繰り返しを発生させる応答
を発生するための第１のリンク手段と、第１の処理動作
の傍らにある他のメモリ・ストレージ装置に関連した第
２の処理動作のためのデータ・オブジエクトの関数を呼
び出すための少なくとも１つのレジスタとによつて非同
期処理動作を発生するために用いられる。

【００２７】本発明の他の実施例において、単一のオブ
ジエクト指向プログラム中に並列処理動作を発生するた
めに、少なくとも第１及び第２の処理手段と、オブジエ
クト指向プログラムの拡張されていないコンパイラと、
第１の処理手段と関連したオブジエクト・クラスを作成
するためのダイナミツク・メモリ・ストレージとを有す
るコンピユータ・オペレーテイング・システム中にイン
ターフエース機構が設けられている。このインターフエ
ース機構は、第１のプロセツサ処理手段からのプロシー
ジヤ・コールを受け取り、かつ、第１の処理手段の処理
を続行させる応答を発生する第１のリンク手段と、第２
の処理手段中の処理に対してデータ・オブジエクトの関
数を呼び出すための少なくとも１つのレジスタとを含ん
でいる。

【００２８】また、このインターフエース機構は、第２
の処理手段中のデータ・オブジエクトの関数を処理する
ために結果の変数を受け取つてストアする手段と、第１
の処理手段と関連するダイナミツク・ストレージに結果
の変数を転送する第２のリンク手段とを含むことが望ま
しい。

【００２９】本発明の他の実施例において、少なくとも
第１及び第２の処理手段と、第１の処理手段と関連した
ダイナミツク・メモリ・ストレージ装置とを有する並列
コンピユータの環境において、オブジエクト指向プログ
ラムの拡張されていないコンパイラで使用するのに適し
たクラス・ライブラリが与えられている。このクラス・
ライブラリは、非同期メソツドを呼び出すために関数の
実行データを含むオブジエクト・クラスと、第１の処理
手段からのプロシージヤ・コールを受け取る時に第１の
処理手段及びオブジエクト・クラスとの間でリンクされ
るのに適した第１のインターフエースと、非同期メソツ
ドの処理を呼び出し、かつ上記処理からの結果を受け取
るために、オブジエクト・クラス及び第２の処理手段の
間でリンクされるのに適した第２のインターフエース
と、第１の処理手段を上記処理からの結果にリンクする
のに適した第３のインターフエースとを含んでいる。

【００３０】

【実施例】本発明の実施例は、共有メモリ、または分散
メモリのマルチプロセツサのような並列処理のコンピユ
ータ・システムにおいて使用するために開発されたもの
である。然しながら、本発明は、例えばＤＣＥタイプの
環境の下とか、また、応答型のコンピユータ・システ
ム、即ち対話式のコンピユータ・システムのような同時
処理をシミユレートする単一プロセツサの下とかのよう
な異種の分散コンピユータ・システムにも同様に適用で
きるように考えられている。

【００３１】以下に説明される本発明の良好な実施例
は、Ｃ⁺⁺プログラム言語用のクラス・ライブラリによつ
て実施される。「仮想」宣言及び「オーバーローデイン
グ」の言語演算子（例えば、導き出されたクラス中のビ
ルトイン演算子を再度定義付けするためのＣ⁺⁺言語の機
構）を用いることによつて、本発明は、一方のプロセツ
サ中で実行しているプログラムから、他方のプロセツサ
にメソツドを呼び出すことができるオブジエクト、また
は他方のプロセツサにメソツドが呼び出されねばならな
いオブジエクトへのインターフエースが、プロシージヤ
・コールにおいて挿入されることを与える。従つて、こ
のインターフエース機構は、第１の処理環境中のコーリ
ング・プログラムからそのオブジエクトを隔離し、そし
て、コーリング・プログラムの処理と、異なつた処理環
境において呼び出されたオブジエクトのメソツドの処理
とを同時に独立して処理する。

【００３２】更に、オブジエクトの呼び出しの処理結果
は、第２の処理環境から、第１の処理環境より直接アク
セス可能なレジスタに戻され、これにより、若しコーリ
ング・プログラム中の将来のある位置において、上述の
呼び出しの処理結果が必要とされるならば、それを使用
可能にする。若し第１のコーリング・プログラムにおい
て、上述の呼び出しの処理結果が必要なければ、最終的
には、オブジエクトの呼び出しの処理結果は上述のレジ
スタから削除される。

【００３３】開始した同時処理、即ち独立した処理は図
１の流れ図に示されている。マルチプロセツサの環境の
場合において、コーリング・プログラムを処理するプロ
セツサ（ブロツク１０）は、データが遠隔地プロセツサ
の中に常駐しているクラス中のメソツドを呼び出す（ブ
ロツク１２）。このメソツドの呼び出しは、「非同期」
ポインタ、即ち「スマート」ポインタを参照、即ち発生
し（ブロツク１４）、次に、以下に説明されるような本
発明の遠隔地コールのインターフエースを初期化する
（ブロツク１６）。

【００３４】Ｃ⁺⁺言語におけるテンプレートのクラス
は、良好な実施例において、非同期呼び出しを呼び出
す、即ち非同期呼び出しを遂行するのに使用される「ス
マート・ポインタ」のクラスを定義するのに用いられ、
このスマート・ポインタは非同期ポインタと呼ばれる。
（本発明は同時に進行する処理を遂行する方向に向けら
れているが、各処理ルーチンはそれ自身の時間の中で通
常の処理動作を続けることが許されている。従つて、各
処理「スレツド」は、あたかも非同期の動作であるかの
ように取り扱われる。）

【００３５】「スマート・ポインタ」の概念は、最早や
使用していないデータ・オブジエクトをダイナミツク・
メモリから削除するのを許容するためのストレージ管理
方式としてＣ⁺⁺言語に最初に導入されたものである。

【００３６】通常、ポインタは、データ・フイールドの
ダイナミツク・メモリの変化するアドレス、即ちメモリ
位置を登録するプログラムによつて使用される変数であ
る。然しながら、従来の使用例において、スマート・ポ
インタは、実際のオブジエクトの位置を指示するのでは
なく、実際のオブジエクトを指示するポインタを含む
「仮想」オブジエクトを介在させている。スマート・ポ
インタは、オブジエクトを削除するときの安全装置とし
て、実際のオブジエクトに対してどれだけ多くの他のポ
インタが指示されているかの情報を含んで、オブジエク
トの削除に関連する情報を含むことができる。実際のオ
ブジエクトに対して指示する他のポインタの数がゼロで
ある場合、実際のオブジエクトは安全に削除することが
できる。

【００３７】本発明の良好な実施例において、Ｃ⁺⁺プロ
グラムのテンプレート機構は、図２の参照数字３０で示
した仮想関数テーブルを含むスマート・ポインタのクラ
スを定義するのに用いられる。良好な実施例において、
「AsynCall」と呼ばれるテンプレートのクラスは、幾つ
かの仮想的な「AsyncTask」ポインタを含んでおり、こ
のポインタの任意の１つは、以下に細部が説明されるよ
うに、スレツドの早すぎる除去を回避するためのビルト
イン安全装置を有する複数の独立スレツド、即ち非同期
のスレツドの作成及び削除を管理することができる。こ
のように、AsynCallテンプレート・クラスのプライベー
ト用及びパブリツク用の宣言の部分は下記のように定義
される。

【００３８】

【表１】 template<class T> class AsynCall [ private: T^* actual_pointer; virtual AsynTask^* af0(...); virtual AsynTask^* af1(...); virtual AsynTask^* af2(...); . . . virtual AsynTask^* afn(...); public: AsynCall(T^* p){ actual_pointer = p; }; AsynCall(){ actual_pointer = (T^*)0; }; T^* operator->(){ return (T^*)this; }; AsynCall<T>& operator=(T^* p){ actual_pointer = p; return(^*this); }; AsynCall<T>& operator=(constant AsynCall<T>& arg){ actual_pointer = arg.actual_pointer; return(^*this); }; };

【００３９】本発明に従つて、非同期呼び出しのための
プロシージヤ・コール、またはメソツドの呼び出しは、
スマート・ポインタの従来の使用と同じように、スマー
ト・ポインタ３２から「仮想」オブジエクトへ発生され
る。然しながら、そのスマート・ポインタはポインタ４
０をその呼び出しのターゲット・オブジェクトへ戻さな
いが、しかしオブジェクトはそれ自身典型的には、仮想
関数テーブル３４を指示する仮想関数テーブル・ポイン
タ３１を含み、ここでそのオブジェクトは、仮想関数テ
ーブル・ポインタ４２を参照するタスクを発生すること
によってターゲット・オブジェクト仮想関数テーブル３
６から意図する方法を呼び出す。

【００４０】単一レベルの継承（inheritance）におい
て、仮想オブジエクトからのポインタによつてアドレス
されたオブジエクトはスマート・ポインタそれ自身であ
つてもよく、そして、上述のリストされたAsynCallテン
プレートにおいて示されたように、３２個までの非同期
タスクを１つのクラスの中に定義することができ、依然
としてＣ⁺⁺プログラムにおいて拡張されていない標準の
コンパイラによつて使用可能な仮想関数テーブルの認識
可能な変数の範囲中に含まれる。図２において、仮想関
数テーブル３４の括弧を付したブロツク３３は、ターゲ
ツト・オブジエクト３８と関連した仮想関数テーブル３
６と対応するために必要とされる仮想関数だけを表わし
ている。

【００４１】複数レベルの継承の場合、ポインタは、従
来技術において知られているように、ポインタの適当な
入れ子によつてオブジエクトに返還される。

【００４２】図１に示した本発明の良好な実施例の１つ
の特徴において、AsynCall仮想メソツドは、ターゲツト
・オブジエクトのコールを処理し（ブロツク１８）、コ
ールされた、即ち呼び出されたメソツドの処理を開始す
るために非同期のスレツドを発生し（ブロツク２０）、
そして、コーリング・オブジエクトへ「位置ホルダ」の
アドレスを返還する（ブロツク２４）。返還された位置
ホルダの値はコーリング・プログラムによつて無視され
（ブロツク２６）、そしてコーリング・プログラムのオ
ブジエクト及びコールド・プログラムのオブジエクトは
同時に処理される（ブロツク２８及び２２）。

【００４３】このプロシージヤが「非同期」呼び出しを
発生する理由は、スマート・ポインタのメソツドが直ち
にコーリング・プログラムに戻されるので（ブロツク１
８及び２４）、それ自身の速度で処理するようにスパン
のないスレツドを残すことにある。並列コンピユータに
おいて、そのようなスレツドを発生することは、真の並
列性を生じる。これとは異なつて、ある種の並列計算シ
ステムにおいては、並行性はスレツドの発生によつて生
じない。その代わりに、待機中のタスクの順番にエント
リが行なわれる。このようなシステムにおいて本発明を
実施した場合、非同期コールがタスクを実行するために
活動しているタスクのために待機している間で、コール
したタスクが連続して処理できるように、スマート・ポ
インタのメソツドの各々は、適当な待ち行列エントリを
作つた後に直ちに戻る。

【００４４】非同期呼び出しの例を下記に示す。

【表２】 class c { public: int n; virtual int f(); }; int::f(){. . .; riturn(n);}; //fは漸時計算して、nに戻る main(){ C c; //Cのインスタンス AsynCall<C> p = &c; //スマート・ポインタのインスタンス p->f(); //fの非同期呼び出し（結果は削除される） . . //p->f()と並列の幾つかの付加的な計算 . }

【００４５】非同期呼び出しは真の並列コンピユータに
有用であるけれども、これは直列コンピユータにおいて
も有用であることにも注意を払う必要がある。直列コン
ピユータにおいて、このようなスレツドまたはタスクは
シミユレートすることができ、論理的並列動作を行なう
ことに意義がある場合には、プログラマは、論理的並列
性（真の意味の並列性ではないけれども）を持たせて記
載することができる。並列性を持たせて記載し、そして
シミユレートする能力がスループツトと、システムの関
知し得る応答度とを改善する場合には、論理的並列動作
を行なうことは特に有利である。

【００４６】また、本発明はメイン・プログラムの処理
と同時に将来の値を計算することができ、この処理は図
３の流れ図に示されている。

【００４７】既に述べたように、将来の結果は、Ｃ⁺⁺プ
ログラムの中に導入されているけれども、メソツドの呼
び出しを区切ることができるように、ユーザのすべての
メソツドを改名するプリ・プロセツサ（pre-processo
r）を使用することによつてしか行なうことができな
い。この機構によつて、将来の結果は通常のメソツドか
らの処理結果を受け取るために使用することはできな
い。その代わりに、プログラマは、将来のリフアレンス
・アーギユメントか、または返還される将来の処理結果
を期待するために、すべてのメソツド（通常、取り出さ
れたクラスの中のメソツド）を再度書き込まなければな
らない。将来の結果を用いるこの方法は非常に不便で取
り扱い難い。

【００４８】本発明において、将来の結果は、プリ・プ
ロセツサ、または拡張されたコンパイラを用いることな
く導入することができる。処理の繰り返しを許容するた
めに、コーリング・プログラムに値が返還される位置ま
で、図１に関連して説明したステツプが続けられる（図
１のブロツク２４）。無視される「位置ホルダ」の値を
返還する代わりに、非同期ポインタはコーリング・プロ
グラムに値を返還する（図３のブロツク５０）。然しな
がら、この値は、ターゲツト・オブジエクトに関して動
作しているターゲツト・メソツドから返還されるべき値
のための所望の値ではない。その代わりに、その値は、
その結果を計算することに充当されるスレツド（また
は、活動しているタスクの待ち行列のエントリ）を指示
するポインタである。

【００４９】本発明の良好な実施例において、この返還
ポインタのタイプは、AsyncTaskと表示される（つま
り、非同期タスクを指示するポインタ）が、特定の返還
ポインタのタイプは、将来の結果が用いられる特定の並
列計算システムに依存する。これらのAsyncTaskポイン
タは、この実施例の型式において、将来の結果を用いる
ためのシステムの主要な要素である。何故ならば、上述
したような将来の結果は、コーリング・プログラムにそ
の値が返還される毎に、ターゲツト・メソツドから最終
的に返還される値に対する臨時の代理値として実質的に
用いられるからである。若しコーリング・プログラム
が、あるターゲツト・メソツドから返還された値を必要
としなければ、その値は、そのプログラムに返還された
AsyncTaskポインタを無視することができる（図１のメ
ソツドにおいて提案されているように）。然しながら、
若しコーリング・プログラムがその値の必要性を予測し
たならば、この値は将来のオブジエクトの中にストアさ
れ（ブロツク５２乃至５６）、以下に示されたような将
来のテンプレートで作成される。

【００５０】

【表３】 template<class T> class Future { AsyncTask^* at; public: Future(cost T& val){ at=(AsyncTask^*)val; //実際に使用される値はタスク・ポインタである }; Future(){ at = (AsyncTask^*)0; }; Future<T>& perator=(const T& val){ at=(AsyncTask^*)val; //実際に割当てられる値はタスク・ポインタである return ^*this; }; int readyp(){ return at ->readyp(); }; conversion operator T() { return (T) at ->join(); }; //結合はスレツドが完了するのを待ち、完了された値を返還する };

【００５１】将来のクラスは、ターゲツト・メソツドか
ら返還され予測される将来のタイプにパラメータ化さ
れ、これは、用いられる将来の結果を示す。

【００５２】従つて、すべての処理プログラムは非同期
的に呼び出されたターゲツト・メソツドから返還された
値を使用し、処理プログラムは、非同期メソツドの呼び
出しから直ちに返還された値を将来のオブジエクトの中
にストアするオーバーロード演算子「＝」を用いる。コ
ンパイラは、そのような 将来の 割り当てのターゲツ
ト・オブジエクトとして将来のオブジエクトの使用を許
容する。何故ならば、オーバーロード演算子「＝」は、
呼び出されたメソツドが返還にタイプ付けされたタイプ
と同じタイプのアーギユメントを予測するようタイプ付
けされるからである。然しながら、実際上では、返還さ
れた値はAsyncTaskの値であり、コンパイラは非同期呼
び出しから返還されたポインタ・タイプに関して実質的
に誤つて認識させられる。これは、ターゲツト・メソツ
ドの代わりにテンプレートAsynCallの仮想メソツドのう
ちの１つのメソツドを呼び出すコードをコンパイラが発
生することになる。テンプレートAsynCallが呼び出した
メソツドは、「タスク」の代わりにAsyncTaskポインタ
を返還し（ブロツク６４）、そして、予測されたアーギ
ユメントが「タスク」のタイプを持つていることをコン
パイラに告げることによつて、将来のオブジエクトの演
算子「＝」が、コンパイラを誤認させた時、アーギユメ
ントのタイプはテンプレートAsynCallのタスクであるこ
とを実際に知る。このようにして、修正されず拡張され
ていない仮想的なすべてのＣ⁺⁺プログラムのコンパイラ
は、将来の結果を実行するコードを発生し、これは、言
語が円滑に集合され拡張されたように見える感じを持た
せる。

【００５３】本発明の良好な実施例において、将来の結
果は、以下のように呼び出される。

【００５４】演算子「＝」が呼び出された時、その演算
子により取られる最初のアクシヨンは、そのアーギユメ
ントを正しいポインタ・タイプ（即ち、ブロツク５２の
AsyncTask）のアーギユメントであるように変換するこ
とである。そのテンプレートのクラスにおいて、この変
換は単純なタイプ予測（type cast）により行なわれる
が、実際上では、マルチ・ワード返還値の最初のワード
を取り出すような、より複雑な変換を用いることができ
る。このような変換は、将来のテンプレートのタスクに
対する演算子のＣ⁺⁺言語のサイズを適用することによつ
て返還された値のサイズにキーすることができる。

【００５５】第２に、レコードがターゲツト・メソツド
から最終的に返還される実際の値に対して求められた値
を発生するため責任ある計算の代理値の記録を作るよう
に、演算子「＝」はプライベートの変数に変換されたア
ーギユメントを割り当てる（ブロツク５４）。最後に、
演算子「＝」は、返還値としてそれ自身に参照子を与え
るコーリング・プログラムに戻る（ブロツク５６）。

【００５６】演算子「＝」が将来のオブジエクトの呼び
出しから戻つた後、コーリング・プログラムは、ターゲ
ツト・メソツドによつて最終的に計算されるべき結果を
待機させることなく、独立して進むことができる（ブロ
ツク５８）。然しながら、その計算結果は、通常、プロ
グラムのある位置において必要とされ、将来のオブジエ
クトは、その計算結果を送り出す「約束」を表示する。
この約束は、将来のテンプレートにおいて示される変換
演算子（演算子「Ｔ」）によつて遂行される（つまり、
将来の結果は「解決された」）。タスクを要求する位置
において将来のインスタンスが用いられる時には、この
演算子「Ｔ」がＣ⁺⁺プログラムによつて呼び出される。
変換演算子は単なる変換を行なうだけではなく、将来の
結果が解決されたか否かをチエツクする（つまり、非同
期呼び出しが予測した処理結果を返還したか否かをチエ
ツクする）。若し将来のオブジエクトが未解決ならば、
変換演算子は、必要に応じてコーリング・プログラムを
阻止して、非同期呼び出しの完了を待つ（ブロツク６
０）。将来のオブジエクトが解決された後、変換演算子
は予測された値を返還し（ブロツク６２、６４）、そし
てコーリング・オブジエクトはその処理動作を進める
（ブロツク６６）。

【００５７】将来のオブジエクトの使用を示すプログラ
ムを以下に示す。

【表４】 class C{ public: int n; virtual int f(); }; int C::f(){ . . . ;}; //fは漸時計算し、次にnに戻る main(){ int y; C c; AsynCall<C> p = &c; Future<intt> x; x = p->f(); //前と同じように、非同期コールであり、今度は値を返還する . . //計算を行なう . y = x; //待機した後、p->f()から返還された値を検索する }

【００５８】良好な実施例の将来的な側面において、非
同期タスクに関係する場合、ストレージ管理を生じるこ
とがあげられる。Ｃ⁺⁺プログラムは本来的に劣悪な集合
（データの動的な構造管理）機構を持たず、従つて、Ｃ
⁺⁺言語のプログラマは、演算子「新規」及び「削除」に
よつてストレージを明示的に取り扱わなければならな
い。良好な実施例において、将来の結果の利用は、将来
の結果のユーザに関して特別なストレージ管理の要求を
賦課しないが、テンプレートAsynCall及び将来のテンプ
レートは、ストレージの賢明な利用を行なうようにプロ
グラムされなければならない。換言すれば、非同期のメ
ソツド呼び出しの仕事を遂行する非同期タスクを動的に
割り当てるAsynCallテンプレートは、後で削除されるべ
きストレージの配列も含まねばならないということであ
る。

【００５９】１実施例において、AsynCallデストラクタ
は削除を行なう。このデストラクタは、AsynCallを削除
する前に終了するため非同期タスクを待機するが、これ
は、将来のインスタンスを発生するために使用されるAs
ynCallのインスタンスは、将来のインスタンスと共に削
除されることを意味する。

【００６０】本発明の他の実施例は、処理結果が割り当
てられる将来のインスタンスに対する削除をAsynCallが
ポインタに委譲することである。従つて、そのような委
譲を遂行する将来の結果はそれらのデストラクタを含ん
でいる。然しながら、将来のインスタンスに対してこの
委譲を割り当てる可能性は避けるよう注意（即ち、処理
結果が無視されることの注意）しなければならない。

【００６１】図２に示した良好な実施例において、Asyn
Callのメソツドは、オブジエクトにポインタ４０を戻
し、これは転じて、非同期タスクのポインタ４２を含ん
でいる。また、このオブジエクトは、削除の雑用を取り
去つたことを表示するために将来のインスタンスによつ
て用いられるべき整数を含ませることができる。従つ
て、AsynCallデストラクタが呼び出された時、デストラ
クタは、将来の結果がそれ自身の削除動作を行なうこと
を約束したか否かをチエツクし、若し約束をしていなけ
れば、それ自身の削除を行なう。

【００６２】若し削除が将来の結果に委譲されているな
らば、将来のテンプレートは、将来の結果の複数のコピ
ーを管理するために、コピー・コンストラクタ（及び必
要に応じて付加的なプライベート・データ）を含むよう
に修正される。将来の結果をコピーすることは、割り当
てによるか、またはパラメータの転送によつて生じ、通
常、これはＣ⁺⁺プログラムの問題ではない。然しなが
ら、若しコピーすることが削除の委任と提携して発生し
たならば、削除を行なう将来の対象のコピーだけが、最
後に削除されたものであることを保証するために、標準
のＣ⁺⁺プログラム技術（例えば、参照子の計数）が用い
られる。

【００６３】単一のオブジエクトに関する複数の呼び出
し（即ち、幾つかの非同期メソツドの呼び出しを同時に
実行すること）の場合、これらの呼び出しの大部分か、
すべての呼び出しは単一のAsynCallポインタによつて発
生されるので、ストレージの管理について複雑さが生じ
る。削除が発生するタスクの約束していない削除を遂行
することが若しポインタの責任であれば、そのデストラ
クタは削除を行なうためにタスクのリストを反復するこ
とができるように、そのようなタスクのリスト（また
は、他の入れもの）を維持しなければならない。

【００６４】本発明の良好な実施例の同時処理のクラス
・ライブラリは、内部プロセツサ通信用のＴＣＰ／ＩＰ
を用いてＩＢＭ社のＲＩＳＣ Ｓｙｓｔｅｍ／６０００
（ＩＢＭ社の商標）プロセツサのネツトワークで実施さ
れた。このプログラムは、アセンブリ言語で書かれてい
る若干のコード・ラインを除いてＣ⁺⁺言語で書かれてい
る。然しながら、同時処理クラス・ライブラリは、分散
メモリ・マルチプロセツサ、または並列処理能力をシミ
ユレートする機構を含んで、他の装置に入れることがで
きる。

【００６５】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００６６】（１）オブジエクト指向プログラムの拡張
されていないコンパイラと、オブジエクト・クラスを作
成するのに適し、かつ分離した処理動作に関連した少な
くとも２つのメモリ・ストレージ装置と、非同期処理動
作を発生するためのインターフエース機構を有するコン
ピユータの環境において、メモリ・ストレージ装置の１
つに関連した第１の処理動作からのプロシージヤを受け
取り、かつ、第１の処理動作の繰り返しを発生させる応
答を発生するための第１のリンク手段と、第１の処理動
作の傍らにある他のメモリ・ストレージ装置に関連した
第２の処理動作のためのデータ・オブジエクトの関数を
呼び出すための少なくとも１つのレジスタとからなるイ
ンターフエース機構。 （２）第１のリンク手段は位置ホルダの値を第１の処理
動作に返還するのに適したポインタ機構と、位置ホルダ
の値を無視するための第１の処理動作中の手段とを含む
（１）に記載のインターフエース機構。 （３）第２の処理動作から処理結果の変数を受け取つて
ストアする手段と、上記処理結果の変数を第１の処理動
作の１つのメモリ・ストレージ装置に転送する第２のリ
ンク手段とを含む（１）に記載のインターフエース機
構。 （４）上記第２のリンク手段は、第１のリンク手段から
の応答を第１の処理動作中の将来の変数に変換するため
の変換手段と、上記将来の変数を第１の処理動作の処理
結果の変数に置換する手段とを含むことを特徴とする
（３）に記載のインターフエース機構。 （５）少なくとも第１及び第２の処理手段と、オブジエ
クト指向プログラムの拡張されていないコンパイラと、
第１の処理手段と関連してオブジエクト・クラスを作成
するダイナミツク・メモリ・ストレージ装置と、単一の
オブジエクト指向プログラム中で並列処理動作を発生す
るインターフエース機構とを有する並列コンピユータの
環境において、第１のプロセツサからプロシージヤ・コ
ールを受け取り、かつ第１のプロセツサに処理を連続さ
せる応答を発生するための第１のリンク手段と、第２の
処理手段中の処理のためのデータ・オブジエクトの関数
を呼び出すための少なくとも１つのレジスタとを含むイ
ンターフエース機構。 （６）第１のリンク手段は位置ホルダ値を第１のプロセ
ツサに返還するのに適したポインタ機構と、位置ホルダ
値を無視するために呼び出し可能なダイナミツク・メモ
リ・ストレージ装置中の手段とを含む（５）に記載のイ
ンターフエース機構。 （７）第２の処理動作中のデータ・オブジエクトの関数
の処理からの結果の変数を受け取つてストアする手段
と、上記結果の変数を第１の処理動作に関連するダイナ
ミツク・メモリ・ストレージ装置に転送する第２のリン
ク手段とを含む（５）に記載のインターフエース機構。 （８）上記第２のリンク手段は、上記第１のリンク手段
からの応答を第１のプロセツサ中の将来の値の変数に変
換する変換手段と、将来の値の変数を第１プロセツサ中
の結果の変数に置換する手段とを含むことを特徴とする
（３）に記載のインターフエース機構。 （９）少なくとも第１及び第２の処理手段及び第１の処
理手段と関連したダイナミツク・メモリ・ストレージ装
置を有する並列コンピユータの環境においてオブジエク
ト指向プログラムの拡張されていないコンパイラを使用
するのに適したクラス・ライブラリにおいて、非同期メ
ソツドを呼び出すために関数の実行データを含むオブジ
エクト・クラスと、第１の処理手段及び第１の処理手段
からのプロシージヤ・コールを受け取る時に第１の処理
手段及びオブジエクト・クラス間にリンクされるのに適
した第１のインターフエースと、第１の処理手段の傍ら
の非同期メソツドの処理を呼び出すために、オブジエク
ト・クラス及び第２処理手段間でリンクされるのに適し
た第２のインターフエースと、第１の処理手段を上記処
理からの処理結果にリンクするのに適した第３のインタ
ーフエースとを含むクラス・ライブラリ。 （１０）少なくとも第１のオブジエクト指向プログラム
の処理手段を有するコンピユータ環境において非同期処
理動作を行なうコンピユータ処理において、第１のプロ
セツサからのプロシージヤ・コールをインターフエース
にリンクするステツプと、第１のプロセツサの処理を続
けさせる、第１のプロセツサに対する応答を発生するス
テツプと、インターフエースから仮想オブジエクトにプ
ロシージヤ・コールを発生するステツプと、仮想オブジ
エクトからタスクへの少なくとも１つのプロシージヤ・
コールを発生するステツプと、第１の処理手段の傍らの
処理のためのタスクから非同期のスレツドを発生するス
テツプとからなる非同期のデータ処理方法。 （１１）非同期のスレツドは独立したプロセツサ中の処
理のために発生されることを特徴とする（１０）に記載
の非同期のデータ処理方法。 （１２）非同期のスレツドの処理の処理結果を受け取る
ステツプと、第１の処理手段に上記処理結果を通信する
ステツプとを含む（１０）、または（１１）に記載の非
同期のデータ処理方法。

【００６７】

【発明の効果】本発明は、コンパイラの修正とか、特別
の事前処理などを必要としないで、コンパイルされたオ
ブジエクト指向のプログラム言語中に、非同期の呼び出
し及び将来の結果の両方を円滑かつ暗黙のうちに導入す
る機構を与え、共有メモリ、または分散メモリのマルチ
プロセツサ、同時処理をシミユレートするプロセツサ、
または単一のプロセツサ中で他のアクテイブ・オブジエ
クトを同時に実行することができる。

【図面の簡単な説明】

【図１】本発明に従つた同時処理をコンピユータで行な
うためのステツプを表わした流れ図である。

【図２】本発明に従つて非同期の呼び出しをするための
ポインタ機構の構造及び機能を示す模式図である。

【図３】本発明に従つた同時処理をコンピユータで行な
うためのステツプを表わした流れ図である。

【符号の説明】

３１ メソツドの呼び出し ３２ スマート・ポインタ ３４ 仮想オブジエクト ３６ 仮想関数テーブル ３８ ターゲツト・オブジエクト

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ウイリアム・ジー・オファレル カナダ国 オンタリオ、ドン・ミルズ、バ レー・ウッズ・ロード 48−21 (72)発明者 イシュラット・アルジョマンディ カナダ国 オンタリオ、エトビコーク、エ デンブリッジ・ドライブ 196

Claims (12)

【特許請求の範囲】
1. 【請求項１】オブジエクト指向プログラムの拡張されて
   いないコンパイラと、オブジエクト・クラスを作成する
   のに適し、かつ分離した処理動作に関連した少なくとも
   ２つのメモリ・ストレージ装置と、非同期処理動作を発
   生するためのインターフエース機構を有するコンピユー
   タの環境において、 メモリ・ストレージ装置の１つに関連した第１の処理動
   作からのプロシージヤを受け取り、かつ、第１の処理動
   作の繰り返しを発生させる応答を発生するための第１の
   リンク手段と、 第１の処理動作の傍らにある他のメモリ・ストレージ装
   置に関連した第２の処理動作のためのデータ・オブジエ
   クトの関数を呼び出すための少なくとも１つのレジスタ
   とからなるインターフエース機構。
2. 【請求項２】第１のリンク手段は位置ホルダの値を第１
   の処理動作に返還するのに適したポインタ機構と、位置
   ホルダの値を無視するための第１の処理動作中の手段と
   を含む請求項１に記載のインターフエース機構。
3. 【請求項３】第２の処理動作から処理結果の変数を受け
   取つてストアする手段と、 上記処理結果の変数を第１の処理動作の１つのメモリ・
   ストレージ装置に転送する第２のリンク手段とを含む請
   求項１に記載のインターフエース機構。
4. 【請求項４】上記第２のリンク手段は、 第１のリンク手段からの応答を第１の処理動作中の将来
   の変数に変換するための変換手段と、 上記将来の変数を第１の処理動作の処理結果の変数に置
   換する手段とを含むことを特徴とする請求項３に記載の
   インターフエース機構。
5. 【請求項５】少なくとも第１及び第２の処理手段と、オ
   ブジエクト指向プログラムの拡張されていないコンパイ
   ラと、第１の処理手段と関連してオブジエクト・クラス
   を作成するダイナミツク・メモリ・ストレージ装置と、
   単一のオブジエクト指向プログラム中で並列処理動作を
   発生するインターフエース機構とを有する並列コンピユ
   ータの環境において、第１のプロセツサからプロシージ
   ヤ・コールを受け取り、かつ第１のプロセツサに処理を
   連続させる応答を発生するための第１のリンク手段と、 第２の処理手段中の処理のためのデータ・オブジエクト
   の関数を呼び出すための少なくとも１つのレジスタとを
   含むインターフエース機構。
6. 【請求項６】第１のリンク手段は位置ホルダ値を第１の
   プロセツサに返還するのに適したポインタ機構と、位置
   ホルダ値を無視するために呼び出し可能なダイナミツク
   ・メモリ・ストレージ装置中の手段とを含む請求項５に
   記載のインターフエース機構。
7. 【請求項７】第２の処理動作中のデータ・オブジエクト
   の関数の処理からの結果の変数を受け取つてストアする
   手段と、 上記結果の変数を第１の処理動作に関連するダイナミツ
   ク・メモリ・ストレージ装置に転送する第２のリンク手
   段とを含む請求項５に記載のインターフエース機構。
8. 【請求項８】上記第２のリンク手段は、 上記第１のリンク手段からの応答を第１のプロセツサ中
   の将来の値の変数に変換する変換手段と、 将来の値の変数を第１プロセツサ中の結果の変数に置換
   する手段とを含むことを特徴とする請求項３に記載のイ
   ンターフエース機構。
9. 【請求項９】少なくとも第１及び第２の処理手段及び第
   １の処理手段と関連したダイナミツク・メモリ・ストレ
   ージ装置を有する並列コンピユータの環境においてオブ
   ジエクト指向プログラムの拡張されていないコンパイラ
   を使用するのに適したクラス・ライブラリにおいて、 非同期メソツドを呼び出すために関数の実行データを含
   むオブジエクト・クラスと、 第１の処理手段及び第１の処理手段からのプロシージヤ
   ・コールを受け取る時に第１の処理手段及びオブジエク
   ト・クラス間にリンクされるのに適した第１のインター
   フエースと、 第１の処理手段の傍らの非同期メソツドの処理を呼び出
   すために、オブジエクト・クラス及び第２処理手段間で
   リンクされるのに適した第２のインターフエースと、 第１の処理手段を上記処理からの処理結果にリンクする
   のに適した第３のインターフエースとを含むクラス・ラ
   イブラリ。
10. 【請求項１０】少なくとも第１のオブジエクト指向プロ
    グラムの処理手段を有するコンピユータ環境において非
    同期処理動作を行なうコンピユータ処理において、 第１のプロセツサからのプロシージヤ・コールをインタ
    ーフエースにリンクするステツプと、 第１のプロセツサの処理を続けさせる、第１のプロセツ
    サに対する応答を発生するステツプと、 インターフエースから仮想オブジエクトにプロシージヤ
    ・コールを発生するステツプと、 仮想オブジエクトからタスクへの少なくとも１つのプロ
    シージヤ・コールを発生するステツプと、 第１の処理手段の傍らの処理のためのタスクから非同期
    のスレツドを発生するステツプとからなる非同期のデー
    タ処理方法。
11. 【請求項１１】非同期のスレツドは独立したプロセツサ
    中の処理のために発生されることを特徴とする請求項１
    ０に記載の非同期のデータ処理方法。
12. 【請求項１２】非同期のスレツドの処理の処理結果を受
    け取るステツプと、 第１の処理手段に上記処理結果を通信するステツプとを
    含む請求項１０、または１１に記載の非同期のデータ処
    理方法。