JPH10501083A - 別の環境で走行するプログラムから関数を呼び出す方法およびシステム - Google Patents

Abstract

(57)【要約】 第１プログラミング言語で記述され、第１環境内で実行されるように設計されたコンピュータ・プログラム関数２１１、２１２を、第２プログラミング言語で記述され、第１環境内で実行不能であるコンピュータ・プログラム２２０からの要求として呼び出すことができるようにする方法を開示する。コンピュータ・プログラム２２０は、要求を供給し、その動作の中断および再開の能力を有する。要求は、待ち行列２０６に置かれ、第１環境で走行するスレッド２０４によって待ち行列２０６から除去される。コンピュータ・プログラム２２０が必要な環境を提供しないので、関数２１１、２１２をコンピュータ・プログラム２２０によって実行することはできない。

Description

【発明の詳細な説明】 別の環境で走行するプログラムから 関数を呼び出す方法およびシステム 発明の分野 本発明は、分散コンピューティングに関し、具体的には、Ｃプログラミング言 語で記述されず、Ｃ環境で実行されないコンピュータ・プログラムからの、Ｃプ ログラミング言語で記述された関数の呼出しに関する。さらに具体的に言うと、 本発明は、多重仮想記憶域（ＭＶＳ）環境などのＤＣＥ（Distributed Computin g Environment、分散コンピューティング環境）以外の環境で走行するプログラ ムからのＤＣＥサービスの使用に関する。発明の背景 分散コンピューティングにおける最近の進展が、ＯＳＦ（Open Software Foun dation）のＤＣＥの出現である。ＤＣＥの目的は、異機種計算機オペレーティン グ環境で、ある程度の透過的コンピューティングを提供することである。ＯＳＦ は、Ｃ言語で記述されたポータブルなソース・コードと、このソース・コードの 移植を支援するための仕様を提供する。ＯＳＦ ＤＣＥは、ＵＮＩＸ、ＭＳ−Ｄ ＯＳ、ＶＭＳ、ＣＲＡＹおよびＳＡＡ環境を含む多数のオペレーティング・シス テムに関して、使用可能であるか計画されている。その特徴には、共通の通信プ ロトコル、共通のシステム管理および共通のデータ・サービスが含まれる。具体 的に言うと、ＯＳＦ ＤＣＥは、一般性を提供し、下記の主要な構成要素の統合 化を支援することを目的とする。 ・分散環境の複雑さを隠蔽するＲＰＣ（Remote Procedure Call，遠隔手続き呼 出し） ・位置、システム、ローカルな命名規則と独立に情報を使用するためのネーミン グ・ディレクトリ ・遠隔位置にあるファイルを透過的に使用するための分散ファイル・システム ・分散資源への許可されないアクセスを防止するためのセキュリテイ ・ＭＳ−ＤＯＳパーソナル・コンピュータによるＤＣＥサービスへのアクセスを 提供するのを助けるＰＣ統合化 ・システム管理機能 上で述べたように、ＤＣＥはＣ言語で記述され、ＯＳＦによってＵＮＩＸオペ レーティング・システム上で開発された。 ＭＶＳは、ＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎ社のシステム／３７０およびシス テム／３９０メインフレーム・コンピュータ上で走行するオペレーティング・シ ステムである。ＭＶＳは、これらの計算機用のアセンブラ（Ａｓｍ）で記述され ている。 ほとんどのＤＣＥ関数はＣ言語で記述されているので、Ｃ で記述されたアプリケーションから簡単に呼び出すことができる。これらの関数 は、Ｃプログラム内の「main」関数の存在によって駆動されるＣライブラリによ って確立された「Ｃ環境」から呼び出されることが想定されている。 「Ｃ環境」およびＣプログラミング全般に関する情報は、カーニハン（B.W．K ernighan）およびリッチー（D.M．Ritchie）著、「The C Programming Language : Second Edition」、１９８８年、Prentice Hall刊（邦題「プログラミング言 語Ｃ第２版」、石田晴久訳、共立出版）に記載されている。 ＤＣＥ関数では、アプリケーションが、リンクの慣例、スタックおよび回復ル ーチン群の使用法ならびに関数へ引数またはパラメータを渡す方法として期待さ れるものも含めて、この「Ｃ環境」で走行することが前提になっている。パラメ ータ渡しの相違を、異なる環境の例としてこれから説明する。 Ｃ関数では、パラメータが「値渡し」を使用して渡されると想定されている。 値渡しの場合、呼び出される関数には、元々の変数ではなく一次変数でパラメー タの値が与えられる。呼び出された関数は、呼出し元の関数の変数の値を直接に 変更することはできず、呼び出された関数の私的な一時コピーを変更することし かできない。呼出し元の関数の変数を変更する必要がある場合には、呼出し元が 、変更される変数のアドレスを提供しなければならず、呼び出される関数では、 そのパラメータをポインタとして宣言し、それを介して間接的に変数にアクセス しなければならない。 ＭＶＳでは、「参照渡し（call by reference）」を使用して関数に引数が渡 されると想定されている。参照渡しの場合、呼び出されるルーチンは、局所コピ ーではなく元々のパラメータへのアクセス権を有する。 Ｃで記述されていないアプリケーション、特に、３７０アセンブラで記述され たアプリケーションは、ＤＣＥ関数で期待される環境を提供しない。システム／ ３７０コンピュータ用に記述されたこのようなアプリケーションの１例が、ＩＢ Ｍ Ｃｏｒｐｏｒａｔｉｏｎ社のＣＩＣＳ系列のトランザクション処理ソフトウ ェアである。 この問題は、上ではＤＣＥ関数に関して述べたが、Ｃ言語で記述された関数に アクセスしようとする、Ｃ言語で記述されていないすべてのソフトウェアについ ても存在する。 ある環境から別の環境の関数を呼び出すという問題に対する以前の解決は、特 定の環境と特定のアプリケーションに関する問題の解決を対象としてきた。すな わち、Ｃで記述された関数を呼び出す非Ｃアプリケーションの問題に対する一般 的な解決を提供しようとする試みはなかった。これらの解決には、Ｃ関数にとっ てＣ環境にみえるものを用意するためにまずセットアップ・ルーチンを呼び出す 非Ｃ呼出し元ルーチンが含まれる。その後、Ｃ関数が呼び出され、完了時に、非 Ｃ呼出し元ルーチンは、Ｃ関数の結果を集め、エラー状態などを解決するために 、クロージング・ルーチンを呼び出さなければならない。このような解決は、環 境設定のオーバーヘ ッドがあるので性能が低く、プログラミングが複雑でエラーも多い。 したがって、２つの環境（「Ｃ環境」と「非Ｃ環境」）の間のブリッジとして のインターフェースを提供して、特定の環境と特定のアプリケーションのための 特別のコードを必要とせずにＤＣＥサービスを非ＤＣＥ環境からアクセスできる ようにすると有利である。 環境間の以前のインターフェースは、ブートストラップ・モジュールまたは初 期設定モジュールにかなりの量のプログラミング・ロジックを有する。これらの 初期設定モジュールは、通常は、別の環境でその関数を利用しようとするアプリ ケーション（利用側）によって、メモリなどの資源を割り振られる。これらのイ ンターフェースは、利用側アプリケーションを停止させなければ簡単には停止さ せることができない。したがって、利用側アプリケーションを停止させずに異な る特性によってインターフェースをリフレッシュすることは不可能である。遮断 の後に、カスタマイズ・ファイルを使用して調整された異なる特性を有する状態 で再始動できるインターフェースを提供すると有利である。発明の開示 したがって、本発明は、第１プログラミング言語で記述され、第１環境で実行 されるように設計されたコンピュータ・プログラム関数を、第２プログラミング 言語で記述され、第 １環境で実行することができず、要求を供給し、動作の中断および再開の能力を 有するコンピュータ・プログラムから、要求として呼び出せるようにする方法で あって、前記第１環境で走行するスレッドを作成するステップと、前記要求のた めの待ち行列を提供するステップと、コンピュータ・プログラムから要求を受け 取るステップと、要求を待ち行列に置くステップと、スレッドによって前記要求 を待ち行列から除去するステップと、スレッド内で関数をロードし、実行するス テップとを含む方法を提供する。 好ましい実施例では、アプリケーション・プログラム自体が実行を継続する前 に関数が実行を完了するのをアプリケーション・プログラムが待つのではなく、 前記待ち行列に置くステップの後に、コンピュータ・プログラムを中断するステ ップと、前記実行するステップの後に、関数の完了時にコンピュータ・プログラ ムを再開するステップとが、この方法にさらに含まれる。アプリケーション・プ ログラムは、関数が実行を完了するのを待っている間に、処理を継続することが できる。 また、好ましい実施例では、第１プログラミング言語がＣプログラミング言語 であり、第１環境がＣプログラミング環境である。 この方法では、要求時に関数を個別にロードすることができるが、好ましい実 施例では、複数の関数が、関数のモジュールで提供され、関数のモジュールをロ ードした後、関数の 実行の前に、要求された関数のアドレスが、関数のモジュールから取得され、実 行するステップが、取得されたアドレスの呼出しからなる。関数のモジュールを 使用することによって、たとえば、セキュリティに関連するＤＣＥ関数などの関 数を単一モジュールに集め、その結果、ロードするステップの性能が向上すると いう長所がもたらされる。また、好ましい実施例では、複数のスレッドが用意さ れ、これらの複数のスレッドは、単一の待ち行列から要求を除去し、共通の関数 を共用する。やはり、複数のスレッドを使用して要求の処理のスループットを改 善することによって、性能が向上する。 好ましい実施例では、関数は、Ｃで記述されたＤＣＥ関数であり、アセンブラ （Ａｓｍ）で記述されたコンピュータ・プログラムは、ＭＶＳ環境で走行する。 本発明は、Ｃプログラミング言語で記述されたコンピュータ・プログラム関数 を、Ｃプログラミング言語で記述されず、Ｃ環境で実行されず、要求を供給し、 動作の中断および再開の能力を有するコンピュータ・プログラムからの要求とし て呼び出せるようにするためのデータ処理システムであって、Ｃ環境で走行する スレッドを作成するための手段と、要求のための待ち行列手段と、コンピュータ ・プログラムから要求を受け取るための手段と、待ち行列手段に要求を置くため の手段と、コンピュータ・プログラムを中断するための手段と、スレッドによる 待ち行列手段からの前記要求の除去のための手段と、スレッド内での関数のロー ドおよび実行のための手 段と、関数の完了時にコンピュータ・プログラムを再開するための手段とを含む システムも提供する。図面の簡単な説明 本発明の実施例を、例として示す添付の図面を参照して説明する。 第１図は、本発明のインターフェースのブロック図である。 第２図は、第１図のインターフェースの初期設定動作の流れ図である。 第３図は、第１図のインターフェースの要求処理動作の流れ図である。発明の詳細な説明 Ｃ言語で記述されたプログラムは、通常は、複数のプログラム内での使用のた めに記述された、プログラム内またはプログラミング片内で共通して使用される プログラミング片が、プログラミング片の出現ごとにプログラムのソース（人間 可読）コード内で完全にリストされないように構造化される。このようなプログ ラミング片を、関数と称し、ソース・コード内にこれらが現れる位置には、関数 の名前の参照だけがある。関数は、プログラム内の後方で完全にリストすること ができ、もしくは、ライブラリ内で完全にリストすることができ、このライブラ リは、後程プログラムをコンパイルする時またはプログラムをリンクする時に参 照される。関数のリス ティングは、独立のプログラムではなく、完全なプログラムから呼び出される必 要がある。 ＤＣＥ関数 例１に、ＭＶＳ環境から呼び出されることが所望されるＤＣＥ関数sec_login_ setup_identity()を示す。Ｃ関数の使用に精通している者であれば、例１に、関 数の実際のプログラミング・コードではなく、関数と入出力パラメータの使用の 構文が示されていることに気付くであろう。この関数の目的は、ユーザのネット ワーク識別を設定することである。この関数は、認証されたネットワーク動作を 実行するのに必要な局所環境のすべてを作成する。しかし、局所オペレーティン グ・システム環境は全く確立されず、したがって、呼出し元ルーチンによってそ のような環境が確立されることが期待される。この動作によって設定されるネッ トワーク識別は、もう１つのＤＣＥ関数sec_login_validate_identity()によっ て検証されるまでは使用できない。この関数および他のＤＣＥ関数に関する情報 は、「OSF DCE Appllcation Development Reference」、１９９３年、Prentice Hall刊に記載されている。 この関数の入力パラメータは次のとおりである。 principal 呼出し元プロセスに対応するレジストリ・アカウント上のPrinc ipal名を含む文字列を示すポインタ。 flags 新しいネットワーク信任状（credential）の使用方法に関する 情報を含むフラグの組。 この関数の出力パラメータは次のとおりである。 login_context ログイン・コンテキスト・データへの非透過的ハンドルを指 すポインタ。 status 完了状況を指すポインタ。 本発明のインターフェースは、ＤＣＥ関数が期待する環境の設定に使用され、 また、必要な入出力パラメータの受け渡しに使用される。 Interface（インターフェース）の概要 このインターフェースは、非ＤＣＥ環境とＤＣＥ環境の間のブリッジとして説 明できる。非ＤＣＥ環境で走行するコード（Throwerコード）は、ＤＣＥ要求を 作成する。このインターフェースの利用側（アプリケーション・プログラムなど ）は、「Throwerコード」と、ＤＣＥ環境で走行する対応する「Catcherコード」 の両方を提供する。このインターフェースは、ThrowerコードからCatcherコード へ制御を渡し、CatcherコードからThrowerコードへ制御を返すための機構を提供 する。このインターフェースを用いると、あらゆる種類と内容のパラメータを、 ThrowerコードとCatcherコードの間で渡せるようになり、また、Ｃ環境で走行す ることを期待するCatcherコードがＣ環境で走行することが保証される。 利用側によって供給される「Throwerコード」は、利用側コードが走行する特 定の非ＤＣＥ環境用に記述される。この利用側記述コードに要求される機能は、 次のとおりである。 １．Bootstrap（ブートストラップ）モジュールのロードとこのモジュールへの 分岐 ２．SUSPEND（中断）関数とRESUME（再開）関数の提供 ３．Request Control Block（要求制御ブロック）の作成とInterfaceモジュール ・コードへの分岐 利用側が供給する「Catcher」コードは、非ＤＣＥ環境が利用しようとする「 Ｃ」関数群であり、これらの関数へのエン トリ・ポイントを提供するためのヘッダを有する。このコードは、「fetchable （取出可能）」コンパイラ・オプション付きでコンパイルされるが、このオプシ ョンは、関数の実行が要求される場合、その時に、ＭＶＳオペレーティング・シ ステムが、その関数をメモリにロードでき、モジュールの大きさ、そのエントリ ・ポイントの場所などの情報を実行時に発見できることを意味する。しかし、Ｍ ＶＳは、Ｃ環境が欠けているので、スタブ・モジュールを直接に呼び出すことは できない。 Interface構成要素 本発明のインターフェースは、多数のソフトウェア・パートからなり、これら のパートは、表１に一覧を示されたインターフェース初期設定に使用されるもの と、表２に一覧を示された要求処理に使用されるものに分割される。これらのパ ートの一部を、第１図に示す。 Interface初期設定 ここで第２図の流れ図を参照して、インターフェースの実施例の動作を、イン ターフェースの初期設定から説明する。 ステップ３０１で、Throwerコード２２０が、Bootstrapモジュール（第１図に は図示せず）をメモリにロードし、このモジュールに分岐する。ステップ３０２ で、Bootstrapモジュールが、Parameter List（パラメータ・リスト）を読み取 って、Bootstrapモジュールの動作をカストマイズする。Parameter Listには、 インターフェースをカストマイズするパラメ ータが含まれる。通常のParameter Listに含まれるパラメータを、表３に示す。 受け取った要求を処理するＤＣＥスレッド２０４の数は、Parameter Listのパ ラメータである。このインターフェースが一時に処理する要求の最大サイズであ る要求待ち行列２０６の最大サイズも、Parameter Listに含まれる。 このインターフェースを異なる要件に合わせて調整またはカストマイズするた めに、ロードされるメインのInterfaceモジュール２０２を含むライブラリが、P arameter Listに含まれる。この調整は、後で説明する。 ＤＣＥ環境で実行されるStubモジュール２１０をそこから ロードすることのできるライブラリは、Parameter Listに含まれる必要がある。 やはり、これを使用してこのインターフェースを調整またはカストマイズするこ とができる。頻繁に使用されるStubモジュール２１０は、ディスク記憶装置など へのアクセスなしに使用できるように、初期設定処理の一部として事前ロードす ることができる。このようなStubモジュール２１０の名前は、Parameter Listに 含まれる。 第２図の流れ図を参照すると、ステップ３０３で、Bootstrapモジュールがメ インのInterfaceモジュール２０２をロードする。ステップ３０４で、Bootstrap モジュールは、ＤＣＥスレッド２０４を作成することによって、メインのInterf aceモジュール２０２に制御を渡す。ステップ３０５で、Throwerコード２２０が 、Throwerコード２２０の「待機」に使用されるSUSPEND出口のアドレスと、Thro werコード２２０の「再開」に使用されるRESUME出口のアドレスとをInterfaceモ ジュール２０２に供給する。ステップ３０６で、Interfaceモジュール２０２は 、Throwerコード２２０からの要求を引数にして呼び出すことができるエントリ ・ポイントを、Throwerコード２２０に返す。 インターフェースの実施例の変形では、非同期初期設定が使用される。この場 合、初期設定が完了する前に、Throwerコード２２０に制御が返される。これに よって、Throwerコード２２０が、ＤＣＥ環境が完全に確立されるのを待ちなが ら長期間拘束される必要がなくなる。 システム再始動か、インターフェース特性を変更するために異なるParameter Listを用いる再始動が要求されたかのいずれかの理由でインターフェースが再始 動されない限り、Bootstrapモジュールは、これ以上の目的のためには働かない 。 要求の処理 ここで第３図の流れ図を参照して、このインターフェースによる要求の処理を 説明する。ステップ４０１で、Throwerコード２２０がRequest Control Blockを 作成する。Request Control Blockは、インターフェースに要求を渡すのに使用 される。表４に、通常のRequest Control Blockの内容を示す。 ステップ４０２で、Throwerコード２２０が、実行が所望されるスタブ関数に 関する情報を含むRequest Control Blockを 指すポインタを引数にして、Interfaceモジュール２０２のエントリ・ポイント を呼び出す。ステップ４０３で、Interfaceモジュール２０２が、要求をＦＩＦ Ｏの要求待ち行列２０６に置く。ステップ４０４で、Interfaceモジュール２０ ２が、使用可能なＤＣＥスレッド２０４にその要求を処理するように通知する。 ステップ４０５で、Interfaceモジュール２０２が、SUSPEND出口を呼び出す。こ のSUSPEND出口のアドレスは、ステップ３０５でThrowerコードによって供給され ている。 ステップ４０６で、通知されたＤＣＥスレッド２０４が、ＦＩＦＯの要求待ち 行列２０６から要求を除去する。ステップ４０７で、ＤＣＥスレッド２０４が、 ステップ４０２でThrowerコードによって供給されたポインタを使用してRequest Control Blockをアドレッシングする。ステップ４０８で、ＤＣＥスレッド２０ ４が、Request Control Blockから、スタブ関数２１１、２１２のＩＤとそれを 含むStubモジュール２１０の名前を判定する。ステップ４０９で、Stubモジュー ル２１０がまだロードされていない場合には、これをロードし、そのエントリ・ ポイントを記録する。Stubモジュール２１０がすでにロードされている場合、ス テップ４１１に進む。 Ｃで記述された１つまたは複数のスタブ関数２１１、２１２を含むStubモジュ ール２１０は、関数番号を引数にして呼び出すことができるエントリ・ポイント を有し、このエントリ・ポイントは、要求された関数の直接エントリ・ポイント を呼出し元に返す。Stubモジュールは、fetchableオプション 付きでコンパイルされるが、これは、関数の実行が要求される場合、その時に、 ＭＶＳオペレーティング・システムがその関数をメモリにロードでき、モジュー ルの大きさ、エントリ・ポイントの位置などの情報を実行時に発見できることを 意味する。しかし、ＭＶＳは、Ｃ環境が欠けているのでStubモジュールを直接に 呼び出すことができない。このようなstubモジュール２１０の例を、例２に示す 。 このコードには、必要な関数番号を引数にして、最初のエントリ・ポイント（ EUVQLKUP）から進入する。このコードは、指定された関数番号のエントリ・ポイ ントが見つからない場合にはnull表示、そうでない場合にはその関数のエントリ ・ポイントを戻り値として終了する。 Stubモジュール２１０に含まれるスタブ関数２１１、２１２のそれぞれには、 これ以外のエントリ・ポイントがある。例では、これらを「stub_functionlのエ ントリ・ポイント」、「stub_function2のエントリ・ポイント」として示す。 ステップ４１１で、ＤＣＥスレッド２０４が、スタブ関数２１１、２１２のＩ Ｄを引数にしてStubモジュールのエントリ・ポイントを呼び出す。ステップ４１ ２で、Stubモジュール２１０が、ステップ４１１の呼出しからリターンし、要求 されたスタブ関数２１１、２１２のエントリ・ポイントをＤＣＥスレッド２０４ に返す。 ステップ４１３で、ＤＣＥスレッド２０４が、通常のＣ関数を呼び出すのと同 じ形でスタブ関数２１１、２１２を呼び出し、Throwerコード２２０によって渡 された４バイト値からなる単一のパラメータを渡す。ステップ４１４で、スタブ 関数２１１、２１２が、「Ｃ」環境を有するＤＣＥスレッド２０４内で走行し、 Throwerコード２２０から渡された４バイト値を介して、ThrowerのParameter Li stにアクセスする。ステ ップ４１５で、スタブ関数２１１、２１２が、必要なＤＣＥ関数を呼び出し、ス テップ４１６で、適当な戻りパラメータに結果を置き、ステップ４１３でこれを 呼び出したＤＣＥスレッド２０４にリターンする。 ステップ４１７で、ＤＣＥスレッド２０４が、初期設定のステップ３０５でア ドレスを渡されたRESUME出口を呼び出す。ステップ４１８で、RESUME出口が、Ｍ ＶＳ ＰＯＳＴマクロを使ってThrowerタスクを覚醒させることによって、ＤＣ Ｅ要求が完了したことを待機中のThrowerタスクに示す。ステップ４１９で、新 たに覚醒されたThrowerコード２２０が、ＤＣＥスレッド２０４を休眠させ、Int erfaceモジュール２０２からの要求処理を求める別の要求を待つ。ステップ４２ ０で、Throwerコードが、ステップ４０５で進入したSUSPEND出口からリターンし 、Interfaceモジュール２０２に制御を渡し、ステップ４２１で、Interfaceモジ ュール２０２が、要求が完了したことを知らせ、ステップ４０２で開始された呼 び出しからリターンする。 初期設定中にこのインターフェースを調整する能力を、これから説明する。 インターフェースの調整 非ＤＣＥ環境で走行するコードは、このインターフェースを遮断し、初期設定 コードを呼び出すことによって、再始動することができる。これを行う場合には 、異なるParameter Listを指定することによって、異なる版のインターフェースをロードすることが できる。表３に、Parameter Listの内容の例を示す。この遮断と再始動は、たと えば、Throwerタスク（アプリケーション・プログラム）を走行状態に保ちなが ら、更新された版のインターフェースを導入し、したがって、Throwerタスクの 可用性を最大にする時に望ましい。 要求の取消（cancel） 上で述べたように、Throwerコード２２０は、Interfaceモジュール２０２がTh rowerコード２２０の中断と再開を行うためのアドレス（SUSPENDとRESUME）を供 給する。要求が、Interfaceモジュール２０２によって受け取られ、要求待ち行 列２０６に置かれてＤＣＥスレッド２０４による処理を待っている状態になった ならば、SUSPEND出口が呼び出され、利用側は、要求が完了した時までThrowerコ ード２２０を待つのに必要なすべての処置を行う。要求が待ち行列化された時か ら、要求が完了したことをＤＣＥスレッド２０４が示すまで、ＤＣＥスレッド２ ０４の下で走行するStubモジュール２１０（「Catcher」コード）は、Throwerコ ード２２０によって供給されたパラメータ記憶域のいずれかをアクセスする可能 性を有する。 システム一貫性の必要があるので、Throwerコード２２０に属するパラメータ 記憶域は、Stubモジュール２１０の「Catcher」コードのすべてがそれにアクセ スしようとしないことが 明白になるまで、解放することも再割振りすることもできない。このことから、 Throwerコード２２０が要求の完了を待っている間に、Throwerコード２２０を終 了し、その記憶域を解放する必要がある場合に問題が発生する。さらに、ＤＣＥ 環境での要求の取消は、非同期事象であるから、Throwerコード２２０が、まだ 走行中の要求に関するＤＣＥ取消を発行する場合であっても、洗練された同期化 ロジックがなければ、Throwerコード２２０は、要求が終了したか否かを知らな いはずである。 この問題を克服するために、ＤＣＥスレッド２０４の下で走行するStubモジュ ール２１０の「Catcher」コードがまだ走行している可能性がある場合であって も、Throwerコード２２０を除去できるようにする、プロトコルと一連の関数が 使用される。このプロトコルのほかに、この解決に本質的に含まれるのは、Inte rfaceモジュール２０２による「除去ウィンドウ」ロック機能の提供である。こ の機能によって、Stubモジュール２１０の「Catcher」コードが前のＤＣＥ要求 を取り消す要求を受け入れることができるか否かを示すための手段が提供される 。 除去プロトコル このプロトコルに適合するために、Throwerコード２２０は、SUSPEND出口の中 にいる場合に、パラメータ記憶域を解放する前に、まずInterfaceモジュール２ ０２から「同意」を得なけ ればならないことを保証しなければならない（たとえば、除去の処理中）。この 「同意」は、Interfaceモジュール２０２に取消要求を発行することによって得 られる。取消要求からの応答が満足なものである場合、Throwerコード２２０は 、除去を進めることができる。しかし、応答が満足でない場合、Throwerコード ２２０は、進行してはならない。この場合、Ｔhrowerコード２２０は、ある時間 だけ待った後に、取消要求を再試行することが好ましい。 Stubモジュール２１０の「Catcher」コードは、排除プロトコルに適合しなけ ればならない場合には、例３に示されるような構造になっていなければならない 。Stubモジュール２１０の「Catcher」コードは、「非取消」ウィンドウ内にあ るのでなければ、取消の候補とみなされる。Stubモジュール２１０の「Catcher 」コードは、setcancel関数を呼び出して取消をオフにセットしなければならな いことを指定することによって、そのようなウインドウに入ろうとしていること をInterfaceモジュール２０２に知らせる。同様に、Stubモジュール２１０の「C atcher」コードは、「Thrower」記憶域からまたはそこへのコピーを完了したな らば、setcancel(ON)関数を呼び出すことによってこれを取り消すことができる ことを示す。 好ましい実施例では、「Compare and Swap（比較と交換）」命令を使用して、 Stubモジュール２１０の「Catcher」コードの取消状況の変更が、Throwerコード ２２０とStubモジュール２１０の「Catcher」コードの間で同期化されることを 保証する。たとえば、setcancel(OFF)が発行される「前」に、インターフェース が取消要求を受け取り、処理する場合、その要求は、取消済みとしてマークされ 、Throwerコードは、そのパラメータ記憶域の解放を許可される。Stubモジュー ル２１０の「Catcher」コードによる後続のsetcancel(OFF)の呼び出しは、その 要求の取消をもたらし、Stubモジュール２１０の「Catcher」コードがこの事象 をトラップする回復ロジックを 有するのでない限り、制御は絶対にStubモジュール２１０の「Catcher」コード には戻らない。 しかし、Stubモジュール２１０の「Catcher」コードのsetcancel(OFF)要求が 処理された「後」にThrowerコード２２０の取消要求が処理される場合には、Stu bモジュール２１０の「Catcher」コードの要求は、「取消不能」としてすでにマ ークされており、Throwerコード２２０の取消要求は失敗する。

Claims (1)

1. 【特許請求の範囲】 １．第１プログラミング言語で記述され、第１環境内で実行されるように設計さ れたコンピュータ・プログラム関数を、第２プログラミング言語で記述され、前 記第１環境内で実行不能であり、要求を供給し、その動作の中断および再開の能 力を有するコンピュータ・プログラムからの前記要求として呼び出すことができ るようにする方法であって、 前記第１環境内で走行するスレッドを作成するステップと、 前記要求のための待ち行列を提供するステップと、 前記コンピュータ・プログラムから前記要求を受け取るステップと、 前記要求を前記待ち行列に置くステップと、 前記スレッドによって前記待ち行列から前記要求を除去するステップと、 前記スレッド内で関数をロードし、実行するステップと を含む方法。 ２．さらに、 前記待ち行列に置くステップの後に、前記コンピュータ・プログラムを中断す るステップと、 前記実行するステップの後に、関数の完了時に前記コンピュータ・プログラム を再開するステップと を含む、請求項１に記載の方法。 ３．前記第１プログラミング言語が、Ｃプログラミング言語 であり、前記第１環境が、Ｃプログラミング環境であることを特徴とする、前記 請求項のいずれか一項に記載の方法。 ４．複数の関数が、モジュールで提供され、前記関数をロードするステップが、 前記複数の関数を含むモジュールをロードするステップであることを特徴とする 、前記請求項のいずれか一項に記載の方法。 ５．さらに、前記複数の関数を含むモジュールをロードした後、関数の実行の前 に、前記複数の関数を含むモジュールから要求された関数のアドレスを取得する ステップを含み、前記実行するステップが、取得されたアドレスの呼び出しによ ることを特徴とする、請求項４に記載の方法。 ６．複数のスレッドが作成され、前記複数のスレッドが、単一の待ち行列からの 要求を除去し、共通の関数を共用することを特徴とする、前記請求項のいずれか 一項に記載の方法。 ７．前記スレッドを作成するステップが、要求される関数をロードするステップ も含むことを特徴とする、前記請求項のいずれか一項に記載の方法。 ８．前記関数が、ＤＣＥ関数であることを特徴とする、前記請求項のいずれか一 項に記載の方法。 ９．前記コンピュータ・プログラムが、ＭＶＳ環境で走行することを特徴とする 、前記請求項のいずれか一項に記載の方法。 １０．前記要求の提供が、要求データを指すポインタの提供を含むことを特徴と する、前記請求項のいずれか一項に記載 の方法。 １１．前記スレッド内での関数の実行の前に、 関数を取り消してはならないことの表示をセットするように前記コンピュータ ・プログラムによって要求された場合に、関数を取り消してはならないことの表 示をセットするステップと、 前記コンピュータ・プログラムによって供給された必要なパラメータを、前記 コンピュータ・プログラムに割り振られた記憶域から、前記関数に割り振られた 記憶域へコピーするステップと、 前記関数を取り消してはならないことの表示をクリアするように前記コンピュ ータ・プログラムによって要求された場合に、前記関数を取り消してはならない ことの表示をクリアするステップと を含み、さらに、前記スレッド内での関数の完了の前に、 前記関数を取り消してはならないことの表示をセットするように前記コンピュ ータ・プログラムによって要求された場合に、前記関数を取り消してはならない ことの表示をセットするステップと、 前記関数によって供給された返されたパラメータを、前記関数に割り振られた 記憶域から、前記コンピュータ・プログラムに割り振られた記憶域へコピーする ステップと、 前記関数を取り消してはならないことの表示をクリアするように前記コンピュ ータ・プログラムによって要求された場 合に、前記関数を取り消してはならないことの表示をクリアするステップと を含む、前記請求項のいずれか一項に記載の方法。 １２．第１プログラミング言語で記述され、第１環境で実行されるように設計さ れたコンピュータ・プログラム関数を、第２プログラミング言語で記述され、前 記第１環境で実行不能であり、要求を供給し、それ自体の動作の中断および再開 の能力を有するコンピュータ・プログラムからの前記要求として呼び出せるよう にするためのデータ処理システムであって、 Ｃ環境で走行するスレッドを作成するための手段と、 要求のための待ち行列手段と、 前記コンピュータ・プログラムから要求を受け取るための手段と、 前記待ち行列手段に要求を置くための手段と、 前記スレッドによって前記待ち行列手段から前記要求を除去するための手段と 、 前記スレッド内での関数のロードと実行のための手段と を含むシステム。 １３．さらに、 前記コンピュータ・プログラムを中断するための手段と、 前記関数の完了時に前記コンピュータ・プログラムを再開するための手段と を含む、請求項１２に記載のシステム。 １４．前記第１プログラミング言語が、Ｃプログラミング言語であり、前記第１ 環境が、Ｃプログラミング環境であることを特徴とする、請求項１２または請求 項１３に記載のシステム。 １５．複数のスレッドが作成され、前記複数のスレッドが、単一の待ち行列手段 からの要求を除去し、共通の関数を共用することを特徴とする、請求項１２ない し請求項１４のいずれか一項に記載のシステム。 １６．前記関数が、ＤＣＥ関数であり、前記コンピュータ・プログラムが、ＭＶ Ｓ環境で走行することを特徴とする、請求項１２ないし請求項１５のいずれか一 項に記載のシステム。