(57)【要約】      （修正有）【課題】オブジェクトプログラムを、プログラムの実行中に動的に変更する。【解決手段】一または複数のクライアント・マシン１０１、１０３，１０５と、一または複数のサーバ・マシン１０７とを備え、それぞれのクライアント・マシンは、オブジェクトプログラムを対応するサーバ・マシンから供給されるように構成されている。それぞれのクライアント・マシンが実行する実行プログラムは、該実行プログラムの起動時にそのオブジェクトプログラムをリンクしておらず、それぞれのクライアント・マシンは、該実行プログラムを実行する際に、サーバ・マシンから供給されたオブジェクトプログラムをリンクして実行するように構成されている。【選択図】図１
2011164861.tif 000002
【特許請求の範囲】
【請求項１】
一または複数のクライアント・マシンと、一または複数のサーバ・マシンとを備え、それぞれのクライアント・マシンは、オブジェクトプログラムを対応するサーバ・マシンから供給されるように構成された情報処理システムであって、
それぞれのクライアント・マシンが実行する実行プログラムは、該実行プログラムの起動時にそのオブジェクトプログラムをリンクしておらず、それぞれのクライアント・マシンは、該実行プログラムを実行する際に、オブジェクトプログラムをリンクして実行するように構成された情報処理システム。
【請求項２】
該対応するサーバ・マシンが、あるオブジェクトプログラムの複数のバージョンを有し、状況に応じてそのうちの一つが選択され、それぞれのクライアント・マシンに供給されるように構成された請求項１に記載の情報処理システム。
【請求項３】
それぞれのクライアント・マシンは、それぞれのクライアント・マシンにおけるオブジェクトプログラムの保管状態を管理する参照テーブルを備え、該参照テーブルを参照して、必要な場合に該対応するサーバ・マシンに対してオブジェクトプログラムを要求し、該実行プログラムを実行するように構成された、請求項１または２に記載の情報処理システム。
【請求項４】
該対応するサーバ・マシンは、オブジェクトプログラム管理テーブルを備え、該オブジェクトプログラム管理テーブルによってオブジェクトプログラムの保管状況を管理するように構成された請求項１から３のいずれかに記載の情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一または複数のクライアント・マシンと、一または複数のサーバ・マシンとを備え、クライアント・マシンは、実行ファイルを作成するためのオブジェクトプログラムをサーバ・マシンから供給されるように構成された情報処理システムに関する。
【背景技術】
【０００２】
ここで、クライアント・マシンとは、外部機器との入出力信号のやり取り及び演算を行なう端末である。また、サーバ・マシンとは、クライアント・マシンに、その処理を行うために必要なオブジェクトプログラムを供給する機器である。
【０００３】
通常、プロセッサがプログラムを実行する場合、オブジェクトプログラムを静的または動的にリンクする必要がある。リンク処理は、オブジェクトプログラム内部のシンボルの解決である。すなわち、それぞれのオブジェクトプログラム内の変数のアドレスや関数のエントリィポイントを、他のオブジェクトプログラムが参照できるようにする処理である。一般的に、ユーザによってコンパイルされたオブジェクトプログラムは静的にリンクされることが多い。他方、数値計算や画像などのライブライブラリファイルは動的にリンクされることが多い。
【０００４】
上述のように、従来の情報処理システムにおいて、オブジェクトプログラムは、実行可能なコードとしてリンクされた形態で存在している。このようにリンクされた形態のオブジェクトプログラムは、プログラムの実行中に動的に変更することはできない。
【０００５】
特許文献１は、JAVA言語及びJAPAプログラムの分割手法について開示している。特許文献２は、JAVA言語あるいはJAVAプログラムの起動を統一するとともに、プログラムを速く起動できるようにする方法を開示している。特許文献３は、分散共有マルチプロセッサにおけるメモリの割り当て方について開示している。しかし、いずれの特許文献も、オブジェクトプログラムを、プログラムの実行中に動的に変更することには対応していない。
【０００６】
他方、サーバ・マシンが保管するオブジェクトプログラムをプログラムの実行中に動的に変更することができれば、オブジェクトプログラムの修整に容易に対応することができ、メンテナンスの点から都合がよい。また、サーバ・マシンが、オブジェクトプログラムの複数のバージョンを保管し、状況に応じて、オブジェクトプログラムの複数のバージョンの一つがクライアント・マシンへ供給されるように情報処理システムを構成すれば、オブジェクトプログラムの複数のバージョンを一元的に管理することができ、また、場合によってはクライアント・マシンのメモリの容量などを低減することができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−３２３３５８
【特許文献２】特開２００９−１５８３０
【特許文献３】ＷＯ２００４／０９９９８１Ａ１
【発明の概要】
【発明が解決しようとする課題】
【０００８】
したがって、オブジェクトプログラムを、プログラムの実行中に動的に変更することのできる情報処理システムに対するニーズがある。
【課題を解決するための手段】
【０００９】
本発明の情報処理システムは、一または複数のクライアント・マシンと、一または複数のサーバ・マシンとを備え、それぞれのクライアント・マシンは、オブジェクトプログラムを対応するサーバ・マシンから供給されるように構成されている。本発明の情報処理システムにおいて、それぞれのクライアント・マシンが実行する実行プログラムは、該実行プログラムの起動時にそのオブジェクトプログラムをリンクしておらず、それぞれのクライアント・マシンは、該実行プログラムを実行する際に、オブジェクトプログラムをリンクして実行するように構成されている。
【００１０】
本発明の情報処理システムは、実行プログラムの起動時にそのオブジェクトプログラムをリンクしていないので、プログラムの実行中にオブジェクトプログラムを変更することに対応することができる。したがって、システムのメンテナンスが容易である。
【００１１】
本発明の実施形態による情報処理システムは、該対応するサーバ・マシンが、あるオブジェクトプログラムの複数のバージョンを有し、状況に応じてそのうちの一つが選択され、該それぞれのクライアント・マシンに供給されるように構成されている。
【００１２】
本実施形態によれば、複数のクライアント・マシンが同様のオブジェクトプログラムを実行する場合に、それぞれのクライアント・マシンが、複数のバージョンのオブジェクトプログラムを保管する必要がないので、クライアント・システムのメモリなどのコストを低減することができる。
【００１３】
本発明の他の実施形態による情報処理システムにおいて、それぞれのクライアント・マシンは、それぞれのクライアント・マシンにおけるオブジェクトプログラムの保管状態を管理する参照テーブルを備え、該参照テーブルを参照して、必要な場合に該対応するサーバ・マシンに対してオブジェクトプログラムを要求し、該実行プログラムを実行するように構成されている。
【００１４】
本実施形態によれば、参照テーブルを使用することにより、それぞれのクライアント・マシンは、予めリンクされていないオブジェクトプログラムを確実に実行することができる。
【００１５】
本発明の他の実施形態による情報処理システムにおいて、該対応するサーバ・マシンは、オブジェクトプログラム管理テーブルを備え、該オブジェクトプログラム管理テーブルによってオブジェクトプログラムの保管状況を管理するように構成されている。
【００１６】
本実施形態によれば、オブジェクトプログラム管理テーブルを使用することにより、サーバ・マシンは、クライアント・マシンによって要求されたオブジェクトプログラムを確実にクライアント・マシンへ供給することができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態による情報処理システムの構成を示す図である。
【図２】クライアント・マシンの構成の一例を示す図である。
【図３】クライアント・マシンの構成の他の例を示す図である。
【図４】オブジェクトファイルの構成の一例を示す図である。
【図５】関数参照テーブルの構成の一例を示す図である。
【図６】クライアント・マシンが、関数を準備する手順を示す流れ図である。
【図７】クライアント・マシンが実行する関数及びその順序を示す図である。
【図８ａ】関数参照テーブルの内容を示す図である。
【図８ｂ】関数参照テーブルの内容を示す図である。
【図８ｃ】関数参照テーブルの内容を示す図である。
【図８ｄ】関数参照テーブルの内容を示す図である。
【図９】サーバ・マシンが保持する関数管理テーブルの構成の一例を示す図である。
【図１０】関数を含むオブジェクトファイルの例を示す図である。
【図１１】第１の具体的応用例に使用される、時間帯の一例と時間帯に対応するオブジェクトプログラムを含むライブラリィを示す図である。
【図１２】第１の具体的応用例に使用される、３種類の時間帯に対応する３個のライブラリィとその中に含まれるオブジェクトプログラムを示す図である。
【図１３】第２の具体的な応用例に使用される表を示す図である。
【発明を実施するための形態】
【００１８】
図１は、本発明の一実施形態による情報処理システムの構成を示す図である。情報処理システムは、２次記憶装置を備えていないｍ台のクライアント・マシン１０１，１０３，・・・１０５と、２次記憶装置１０９を備えた１台のサーバ・マシン１０７と、から構成される。ｍ台のクライアント・マシン１０１，１０３，・・・１０５及び１台のサーバ・マシン１０７は、ネットワーク１０７を介して相互に接続されている。本実施形態において、サーバ・マシンの数は１であるが複数であってもよい。
【００１９】
図２は、クライアント・マシンの構成の一例を示す図である。ｍ台のクライアント・マシン１０１，１０３，・・・１０５は、異なる構成を有していてもよいが、本実施形態においては、簡単のため、いずれも図２に示す構成を有するとする。クライアント・マシンは、入出力モジュール２０１、読み取り専用メモリ２０３、タイマー２０５、プロセッサ２０７、通信モジュール２１１、関数参照テーブル２１３及び主記憶装置２１５を備え、これらは内部バス２０９によって相互に接続されている。クライアント・マシンは、プロセッサ２０７を介して演算処理を行う。クライアント・マシンは、通信モジュール２１１及びネットワークを介して、サーバ・マシン１０７との通信を行い、入出力モジュール２０１を介して、外部機器との入出力信号のやり取りを行う。クライアント・マシンは、通信モジュール２１１を介してサーバ１０７から受け取ったオブジェクトプログラムを主記憶装置２１５のいずれかのメモリ・バンクに格納する。主記憶装置２１５の構成の詳細及び関数参照テーブル２１３については、クライアント・マシンのプログラム実行処理に関連して後で詳細に説明する。
【００２０】
図３は、クライアント・マシンの構成の他の例を示す図である。図３において、主記憶装置３１５のそれぞれのメモリ・バンクは２ポートのＲＡＭで構成される。一方のポート（Port-A）は、内部バス３０９に接続され、他方のポート（Port-B）は、通信モジュール３１１に接続される。本構成によれば、クライアント・マシンが通信モジュール３１１を介してサーバ・マシン１０７からオブジェクトプログラムを受け取る際に内部バス３０９が占有されないので、クライアント・マシンの他の処理が妨げられない。
【００２１】
サーバ・マシン１０７は、オブジェクトプログラムを収めたオブジェクトファイルを保管している。
【００２２】
図４は、オブジェクトファイルの構成の一例を示す図である。オブジェクトファイルの先頭には、１６バイトのヘッダ領域４０１が備わる。その後に、オブジェクトファイル内のシンボルテーブルのオフセット値が記述されたＶテーブル領域４０３が備わる。さらにその後に、オブジェクトプログラムの実行可能なバイナリコードが記憶された領域４０５が備わる。
【００２３】
つぎに、クライアント・マシンのプログラム実行処理を説明する。クライアント・マシンは、プログラムを実行する際に、オブジェクトファイルをサーバ・マシン１０７から受け取り、主記憶装置のいずれかのメモリ・バンクへ格納し、オブジェクトファイル内のオブジェクトプログラムを実行する。本明細書において、オブジェクトプログラムを関数とも呼称する。クライアント・マシンが関数を呼び出す際に、関数参照テーブルが参照される。具体的には、関数の記述の最初に関数参照テーブルをアクセスするマクロ記述を挿入しておく。
【００２４】
図５は、関数参照テーブルの構成の一例を示す図である。関数参照テーブルは、ロック・フラッグ、データバンク・フラッグ、コードバンク・バリッドフラッグ、ダウンロード・フラッグ及び関数番号のフィールドを有する。これらのフィールドは、それぞれのメモリバンク（図５では０乃至３）に対して設けられている。関数番号によって関数が識別される。ダウンロード・フラッグは、該関数をサーバ・マシンからダウンロード中であることを示す。コードバンク・バリッドフラッグは、該関数は、サーバ・マシンからダウンロードされ、主記憶に有効に存在することを示す。データバンク・フラッグは、該関数は、データバンクであることを示す。ロック・フラッグは、主記憶上の該関数の入れ替えを禁止することを示す。
【００２５】
図６は、クライアント・マシンが、関数を準備する手順を示す流れ図である。
【００２６】
図６のステップＳ２１０において、プログラムを実行する際に関数が呼び出される。
【００２７】
図６のステップＳ２１５において、呼び出された関数エントリィが関数参照テーブルに存在し、コードバンク・バリッドフラッグが有効であるかどうか判断される。肯定であれば、該関数がすでに主記憶装置にロードされていると判断し、ステップＳ２４５へ進む。否定であれば、ステップＳ２２０へ進む。
【００２８】
図６のステップＳ２２０において、呼び出された関数エントリィが関数参照テーブルに存在し、ダウンロード・フラッグが有効であるかどうか判断される。肯定であれば、ステップＳ２３５へ進む。否定であれば、ステップＳ２２５へ進む。
【００２９】
図６のステップＳ２２５において、関数エントリィを関数参照テーブルに書き込み、ダウンロード・フラッグを有効にし、同時に、ロード対象のメモリ・バンクに現在格納されているオブジェクトプログラムを無効にするために、ロード対象のメモリ・バンクのコードバンク・バリッドフラッグを無効にする。
【００３０】
図６のステップＳ２３０において、サーバ・マシンに対して関数のダウンロードを要求する。
【００３１】
図６のステップＳ２３５において、サーバ・マシンからの関数のダウンロードが終了するまで待つ。
【００３２】
図６のステップＳ２４０において、コードバンク・バリッドフラッグを有効にする。
【００３３】
図６のステップＳ２４５において、目的の関数がロードされているコードバンクにジャンプする。
【００３４】
図７、図８ａ、図８ｂ、図８ｃ及び図８ｄを使用して、クライアント・マシンが、プログラムを実行する際に、関数参照テーブルが具体的にどのように更新されるかを説明する。
【００３５】
図７は、クライアント・マシンが実行する関数及びその順序を示す図である。具体的に、クライアント・マシンは、ブートシーケンス実行後、func1、func2、func1、func3、func4、func3、func5、func6、func5の順で関数を実行するとする。
【００３６】
図８ａ、図８ｂ、図８ｃ及び図８ｄは、関数参照テーブルの内容を示す図である。メモリ・バンクは４個備わる（バンク番号０乃至３）。そのうち、バンク番号０のメモリ・バンクはブートプログラム用に使用され、バンク番号１のメモリ・バンクは、データ保持用に使用される。バンク番号２及び３のメモリ・バンクに関数を含むオブジェクトファイルが格納される。
【００３７】
図７の番号１（丸で囲った数字）の時点で、func1.oが呼び出されたので、バンク番号２の関数名にfunc1.oに相当する管理番号が登録され、バンク番号２のコードバンク・バリッドフラッグは０（無効）とされ、バンク番号２のダウンロード・フラッグは１（有効）とされる（図８ａ）。オブジェクトファイルが番号２のメモリ・バンクにダウンロードされた時点で、コードバンク・バリッドフラッグは１とされ、ダウンロード・フラッグは０とされる。
【００３８】
図７の番号２（丸で囲った数字）の時点で、func2.oが呼び出されたので、バンク番号３の関数名にfunc2.oに相当する管理番号が登録され、バンク番号３のコードバンク・バリッドフラッグは０（無効）とされ、バンク番号３のダウンロード・フラッグは１（有効）とされる（図８ｂ）。オブジェクトファイルが番号３のメモリ・バンクにダウンロードされた時点で、コードバンク・バリッドフラッグは１とされ、ダウンロード・フラッグは０とされる。
【００３９】
図７の番号３（丸で囲った数字）の時点で、func1.oが呼び出される。func1.oは、すでに主記憶装置にロードされているので、ダウンロード作業は行われない（図８ｃ）。
【００４０】
図７の番号４（丸で囲った数字）の時点で、func3.oが呼び出される。現在実行されているコードはバンク番号３のメモリ・バンクのものであるので、バンク番号２のメモリ・バンクの書き換えが行なわれる（図８ｄ）。
【００４１】
図７の番号５（丸で囲った数字）の時点で、func4.oが呼び出される。現在実行されているコードはバンク番号２のメモリ・バンクのものであるので、バンク番号３のメモリ・バンクの書き換えが行なわれる。
【００４２】
図７の番号６（丸で囲った数字）の時点で、func3.oが呼び出される。func3.oは、すでに主記憶装置にロードされているので、ダウンロード作業は行われない。
【００４３】
図７の番号７（丸で囲った数字）の時点で、func5.oが呼び出される。現在実行されているコードはバンク番号２のメモリ・バンクのものであるので、バンク番号３のメモリ・バンクの書き換えが行なわれる。
【００４４】
図７の番号８（丸で囲った数字）の時点で、func6.oが呼び出される。現在実行されているコードはバンク番号３のメモリ・バンクのものであるので、バンク番号２のメモリ・バンクの書き換えが行なわれる。
【００４５】
図７の番号９（丸で囲った数字）の時点で、func5.oが呼び出される。func5.oは、すでに主記憶装置にロードされているので、ダウンロード作業は行われない。
【００４６】
図７の番号１０（丸で囲った数字）の時点で、関数func1、func2、func1、func3、func4、func3、func5、func6、func5からなるプログラムを実行する処理が終了する。
【００４７】
つぎに、サーバ・マシンが、オブジェクトプログラムを含むオブジェクトファイルをどのように管理しているかについて説明する。
【００４８】
図９は、サーバ・マシンが保持する関数管理テーブルの構成の一例を示す図である。
【００４９】
図１０は、関数を含むオブジェクトファイルの例を示す図である。
【００５０】
サーバ・マシンは、クライアント・マシンから要求されるオブジェクトファイルを、関数管理テーブルを使用して管理している。関数管理テーブルは、クライアント番号、関数番号、ファイルの属性及びファイル名のフィールドを備える。図９の関数管理テーブルは、図７に示した６個の関数が、どのような形態で保管されているかをファイル名として示している。図１０に示すように、 func1.oとfunc2.oは共有ライブラリィlib_seta.soに含まれている。func3.oとfunc4.oはファイルfunc3.oとfunc4.oとして存在する。func5.oとfunc6.oは、ライブラリィlib_setc.aに含まれている。
【００５１】
関数管理テーブルは、クライアント・マシンのプログラムをコンパイルする際に生成される。しかしながら、動的に更新し、変更を加えてもよい。
【００５２】
クライアント・マシンは、プログラム全体がどのようなオブジェクトファイルを呼び出すかについて全く管理する必要はなく、サーバ・マシンに対して実行に必要なオブジェクトファイルのダウンロードを要求するだけでよい。サーバ・マシンは、クライアント・マシンが実行する関数のオブジェクトファイルを管理すればよい。
【００５３】
つぎに、本発明の具体的応用例について説明する。ここで説明する具体的応用例は、サーバ・マシンが、あるオブジェクトプログラムの複数のバージョンを有し、状況に応じてそのうちの一つが選択され、それぞれのクライアント・マシンに供給されるように構成された情報処理システムである。
【００５４】
第１の具体的応用例は、交差点における信号管理のための情報処理システムである。本システムにおいて、１日をたとえば、３種類の時間帯に分けて、サーバ・マシンは、それぞれの時間帯ごとに異なるバージョンのオブジェクトプログラムを備え、時間帯に応じてバージョンを選択してクライアント・マシンへ供給するように構成される。
【００５５】
図１１は、第１の具体的応用例に使用される、時間帯の一例と時間帯に対応するオブジェクトプログラムを含むライブラリィを示す図である。図１１においては、朝夕の交通量の多い時間帯（７時から９時と１７時から１９時）、昼間の時間帯（９時から１７時）及び夜間の時間帯（１９時から７時）の３種類の時間帯が設けられている。３種類の時間帯には、それぞれの時間帯に対応する異なるバージョンのオブジェクトプログラムを含む３個のライブラリィが使用される。
【００５６】
図１２は、第１の具体的応用例に使用される、３種類の時間帯に対応する３個のライブラリィとその中に含まれるオブジェクトプログラムを示す図である。オブジェクトプログラム名はすべての時間帯で、func1.oとfunc2.oであるが、これらが含まれているライブラリィ名がそれぞれの時間帯で異なり、サーバ・マシンは、時間にしたがって異なるライブラリィからオブジェクトプログラムをクライアント・マシンに供給する。クライアント・マシンは、一例として、スケジューラによって、時間帯の変わり目において、関数参照テーブルのコードバンク・バリッドフラッグを無効として、オブジェクトプログラムが切り替わるようにする。
【００５７】
たとえば、十字路交差点では通常４台の信号機が存在する。交通量が多い場合には、さらに予備信号機が設置されることもある。それぞれの信号機にクライアント・マシンが設けられる。それぞれの信号機のクライアント・マシンに交通量に応じて対応するようなプログラムを実装すると、それぞれのクライアント・マシンに大量のメイン・メモリ（ＲＡＭ）やＲＯＭが必要となり、コストが増大する。これに対して、サーバ・マシンに交通量に応じて対応するようなプログラムを実装する本例のシステムによれば、コストを抑制することができるとともに、マシンのメンテナンスやプログラムの修正なども容易になる。
【００５８】
第２の具体的な応用例は、自動車などのサスペンションの硬さを自動制御する情報処理システムである。外気温度及び乗員重量の条件ごとに異なるバージョンのオブジェクトプログラムを備え、条件に応じてバージョンを選択するように構成される。
【００５９】
図１３は、第２の具体的な応用例に使用される表を示す図である。表において、３個の外気温度の範囲及び３個の乗員重量の範囲によって区分される９個の範囲に対して、９個の異なるライブラリィが指定されている。クライアント・マシンは、外気温度及び乗員重量の条件によって、いずれかのライブラリィを定め、そのライブラリィをサーバ・マシンに対して要求する。
【００６０】
本発明による情報処理システムの特徴について説明する。本システムにおいては、プログラムのソースコード全体をコンパイルした後、オブジェクトファイルの全てをリンクして実行ファイルの形式にする必要がない。オブジェクトファイルは、サーバ・マシンがクロスコンパイラを用い、アドレス・リロケータブルなバイナリィ形式で保持しておけばよい。クライアント・マシンは、バイナリィ形式のオブジェクトファイルをダウンロードすることができる。
【００６１】
また、LinuxなどのUnix系のＯＳでみられる共有ライブラリィ(.so)形式、またはライブラリィ(.a)形式でサーバ・マシンがオブジェクトファイルを保持することが可能であり、従来通りのコンパイル手法を用いることができる。
【００６２】
このように本発明による情報処理システムにおいては、オブジェクトファイル内部の関数のエントリィポイントが静的に定まっておらず、プログラムの実行時に一旦関数参照テーブルへアクセスし、その都度、目的の関数のエントリィポイントのアドレスを得るように構成されている。したがって、本システムは、クライアント・マシンを含むマシンが必要に応じてオブジェクトファイルを動的に変更することに対応することができる。また、新たに関数を追加することも可能である。
【符号の説明】
【００６３】
１０１、１０３，１０５…クライアント・マシン、１０７…サーバ・マシン、１０９…２次記憶装置、２１３，３１３…関数参照テーブル、２１５，３１５…主記憶装置
【図１】
2011164861.tif 000003
【図２】
2011164861.tif 000004
【図３】
2011164861.tif 000005
【図４】
2011164861.tif 000006
【図５】
2011164861.tif 000007
【図６】
2011164861.tif 000008
【図７】
2011164861.tif 000009
【図８ａ】
2011164861.tif 000010
【図８ｂ】
2011164861.tif 000011
【図８ｃ】
2011164861.tif 000012
【図８ｄ】
2011164861.tif 000013
【図９】
2011164861.tif 000014
【図１０】
2011164861.tif 000015
【図１１】
2011164861.tif 000016
【図１２】
2011164861.tif 000017
【図１３】
2011164861.tif 000018