(57)【要約】      （修正有）【課題】システムの高信頼化が必要なミッションクリティカルなアプリ運用のシステムにおいて、アプリの実行状態の管理及び監視が確実にできる実行環境をＯＳ上のミドルまたはアプリレイヤで実現し、アプリの実行状態によって必要な高信頼性機能を実現する特殊なハードウェアやＯＳの機能に依存しないアプリ実行基盤を提供する。【解決手段】アプリを関数化して関数化アプリとして格納する共有ライブラリを生成し、関数化アプリを実行するスレッドを予め生成してプールし、ユーザからアプリの開始要求を受けて、当該開始要求があった実行対象のアプリとプールしたスレッドから選択した空きのスレッドとを関連付け、当該関連付けた空きのスレッドを使って実行対象のアプリに対応する共通ライブラリ上の関数化アプリを実行する【選択図】図１
2019185423.tif 000002
【特許請求の範囲】
【請求項１】
アプリを関数化して関数化アプリとして格納する共有ライブラリを生成し、前記関数化アプリを実行するスレッドを予め生成してプールし、ユーザから前記アプリの開始要求を受けて、当該開始要求があった実行対象のアプリとプールした前記スレッドから選択した空きのスレッドとを関連付け、当該関連付けた空きのスレッドを使って前記実行対象のアプリに対応する前記共通ライブラリ上の前記関数化アプリを実行する
ことを特徴とするアプリの実行方法。
【請求項２】
請求項１に記載のアプリの実行方法であって、
前記スレッドをプールするに際し、設定数分の前記スレッドに対して当該スレッドの実行制御に係るパラメータを初期化する
ことを特徴とするアプリの実行方法。
【請求項３】
請求項２に記載のアプリの実行方法であって、
前記関連付けた空きのスレッドに対して、前記開始要求があった実行対象のアプリに関係する前記パラメータを通知する
ことを特徴とするアプリの実行方法。
【請求項４】
請求項１から３のいずれか１項に記載のアプリの実行方法であって、
前記関連付けた空きのスレッドに対して、当該スレッドの優先度及び資源アクセス権限が設定される
ことを特徴とするアプリの実行方法。
【請求項５】
請求項１から４のいずれか１項に記載のアプリの実行方法であって、
実行が終了した前記アプリに関連付けられた前記スレッドが実行済みで初期化状態に戻ったか否かを監視する
ことを特徴とするアプリの実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリの実行状態の管理及び監視を可能にするアプリの実行方法に関する。
【背景技術】
【０００２】
情報システム及び制御システムにおける高信頼性を保証するために、運用するアプリの確実な実行状態の管理が要求される。しかし、アプリの実行状態は、ＯＳ内部で管理されることが多いことから、ＯＳ上のミドルレイヤやアプリのレイヤでの監視は容易ではない。特に、情報システム及び制御システムとして、アプリの終了状態を明確に把握し、該当のアプリが確保したメモリ等の計算機資源を確実に解放してシステムの高信頼性を保証するためには、ＯＳ内部の情報を取得するための方法を考案する必要がある。
【０００３】
また、ハードウェアやＯＳの世代交代によりアプリを移植するための開発投資を最小限に抑えるニーズが多いため、アプリ実行状態の管理がＯＳ上のミドルレイヤやアプリレイヤで実現されることが望ましい。その一つの手法として、例えばＬｉｎｕｘの場合、ＯＳとアプリ間での通信手段であるＮｅｔＬｉｎｋ等のインタフェースを活用して、アプリの実行状態を監視することができる。ただし、その監視方法において、ＯＳからのアプリ状態通知イベントを確実に受け取るためには、別のアプリが必要であり、さらにそのイベントを取りこぼさないためには、該当アプリを高優先度で実行する必要がある。
【０００４】
一方、制御システムのような制御処理以外のアプリによって性能干渉が発生するようなアプリを運用ことは困難である。そのため、ＯＳ上のミドルレイヤまたはアプリレイヤで運用するアプリの実行状態を管理できる手法が必要である。例えば、非特許文献１に記載の「Ｊａｖａ  ＶＭ」は、ミドルレイヤにおいてＪａｖａ言語で書かれたアプリを制御・管理できる技術であり、そのアプリの実行状態の監視は容易である。しかし、Ｊａｖａ言語ではない言語で書かれたアプリの運用は困難であり、特に制御システムのようなリアルタイムの性能要件が厳しい環境では、Ｃ言語かアセンブラで書かれたアプリの運用が大半であり、その技術の適用には困難を伴う。
【０００５】
また、特許文献１には、アプリのイベント情報を管理するイベント管理手段として複数のイベント通知スレッドを有し、このイベント管理手段を用いて複数のアプリの動作を制御する技術が示されている。
さらに、特許文献２には、スレッドのコンパイル時に、スレッドの内部情報を読み出すような別処理をリンクする手順に関する技術が示されている、
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−２８０９２６号公報
【特許文献２】特開２００５−２４２８７９号公報
【非特許文献】
【０００７】
【非特許文献１】Ｔｈｅ  Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ
【発明の概要】
【発明が解決しようとする課題】
【０００８】
システムの高信頼化が必要なミッションクリティカルなアプリを運用するシステムにおいて、アプリの実行状態の管理及び監視が確実にできるアプリの実行環境をＯＳ上のミドルレイヤまたはアプリレイヤで実現し、アプリの実行状態によって必要な高信頼性機能の実現を容易にしたいニーズがある。さらには、ハードウェアやＯＳの世代交代によってアプリを移植する必要が発生するが、そのための開発投資を最小限に抑えたいニーズがある。
それらに応えるために、本発明の目的は、特殊なハードウェアやＯＳの機能に依存しないアプリの実行基盤を実現提供することである。
【課題を解決するための手段】
【０００９】
本発明は、前記課題を解決するために、アプリを関数化して関数化アプリとして格納する共有ライブラリを生成し、関数化アプリを実行するスレッドを予め生成してプールし、ユーザからアプリの開始要求を受けて、当該開始要求があった実行対象のアプリとプールしたスレッドから選択した空きのスレッドとを関連付け、当該関連付けた空きのスレッドを使って実行対象のアプリに対応する共通ライブラリ上の関数化アプリを実行することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、処理性能要件が厳しい制御システムにおいて、特殊なハードウェエアやＯＳの機能に依存せずにアプリの実行状態を管理及び監視することが可能となる。また、アプリのソースレベルの修正を要求しないため、ミドルレイヤ及びアプリレイヤで、管理対象のアプリの実行状態を管理及び監視することが可能であり、特にアプリの終了状態をもって実現する計算機資源の開放等といった高信頼性を必要とする機能の実現が容易となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施例に係るハードウェア及びソフトウェアプログラムの構成の一例を示す図である。
【図２】アプリ（ＡＰ）管理テーブルの構成を示す図である。
【図３】スレッド管理テーブルの構成を示す図である。
【図４】スレッドイベントテーブルの構成を示す図である。
【図５】共有ライブラリ化部処理が実行する処理フローの詳細を示す図である。
【図６】スレッドプール管理部が実行する処理フローの詳細を示す図である。
【図７】アプリ開始処理の処理フローの詳細を示す図である。
【図８】スレッド処理部が実行する処理フローの詳細を示す図である。
【図９】アプリ実行処理の処理フローの詳細を示す図である。
【図１０】スレッド監視部が実行する処理フローの詳細を示す図である。
【発明を実施するための形態】
【００１２】
通常のＯＳ上で実行されるアプリの処理ロジックのソースをコンパイルすると、ＯＳ上の１つのプロセスとして実行されるバイナリが生成される。本発明では、実行状態を管理対象のアプリをＯＳ上の一つのプロセスではなく、１つの関数としてコンパイルし計算機のメモリ上にロード可能なアプリの共有ライブラリとして生成すると共に、この関数化したアプリを実行するスレッドを生成し運用する。
【００１３】
また、本発明は、前記スレッドにおいては監視対象のアプリは一つの関数として扱うため、関数の終了をもって該当アプリの実行終了を確実に把握する。さらに、関数化されたアプリのエントリポイントやそのアプリに引き渡す引数は、外部テーブルを設けて指定または設定し、スレッドプールから１つのスレッドを選び、該スレッドがその外部テーブルから関数化されたアプリのバイナリの実行のためのパラメータを取得する。
【００１４】
以下に、本発明を実施するための形態として、実施例について図面を用いて詳細に説明する。なお、図面においては、アプリ及びライブライの表記を「ＡＰ」及び「Ｌｉｂ」としている。
【実施例】
【００１５】
図１は、本発明の実施例に係るハードウェア及びソフトウェアプログラムの構成の一例を示す図である。
ハードウェア構成としては、ＯＳを含むソフトウェアプログラムを実行する演算装置１１、前記プログラム及びその実行に必要なデータを格納する記憶装置１２を備える。ここで、記憶装置１２は、例えばＲＡＭやハードディスクなどである。また、演算装置１１は、１つ以上のＣＰＵ１１−Ａを備える。
【００１６】
ソフトウェアプログラムの構成について説明する。
ＯＳ２１は、ＯＳの上で動作するアプリをスケジュールする機能、演算装置１１及び記憶装置１２のような計算機資源の排他制御機能及びアプリ間の協調のための動作制御用として同期イベントの発生制御機能を有する。また、ＬｉｎｕｘやＷｉｎｄｏｗｓのような汎用ＯＳが備える機能も有する。
【００１７】
アプリ５１は、少なくとも１つ以上存在し、演算装置１１が実行可能な命令コードからなるバイナリを生成するためのソースファイルである。また、アプリ５１は、コンパイラによってアセンブルコードに変換され、演算装置１１が実行可能なバイナリに変換される。バイナリに変換されたアプリ５１は、ＯＳ２１によって、ＯＳ２１が管理するプロセス単位で実行される。
【００１８】
共有ライブラリ（Ｌｉｂ）化部３１は、コンパイラによって通常プロセス単位で実行されるバイナリに変換されるアプリ５１を、共有ライブラリ５３の１つの関数単位のバイナリに変換するための処理機能を有する。この機能により、１つ以上のアプリ５１をそれぞれ関数単位でバイナリ変換した後、コンパイラ機能を利用し共有ライブラリ５３を生成する。
【００１９】
スレッドプール管理部４１は、共有ライブラリ５３に含まれる関数化されたアプリ５１のバイナリを実行する１つ以上のスレッド６１を生成管理する。スレッド６１は、ＯＳ２１が管理するプロセスまたはスレッドであり、スレッドプール管理部４１がＯＳ２１の機能を用いて生成する。
【００２０】
また、スレッドプール管理部４１は、スレッド処理部４２及びスレッド監視部４３と、テーブルとして、アプリ（ＡＰ）管理テーブル４４、スレッド管理テーブル４５並びにスレッドイベントテーブル４６とを備える。
【００２１】
スレッド処理部４２は、スレッド６１が実行する処理機能であり、スレッド監視部４３は、監視スレッド６２が実行する処理機能である。ここで、監視スレッド６２は、スレッドプール管理部４１により生成され、スレッド６１の異常監視を行う。
【００２２】
各テーブル（アプリ管理テーブル４４、スレッド管理テーブル４５及びスレッドイベントテーブル４６）について、図２〜４を用いて順に説明する。
図２は、アプリ管理テーブル４４の構成を示す図である。アプリ管理テーブル４４は、従来アプリ５１が運用されている計算機環境上において、ＯＳレイヤで管理運用されるテーブルである。アプリ管理テーブル４４によって、アプリ５１の実行状態が監視でき、システムに必要な高信頼機能が実現できる。例えば、該当アプリに割り当てられた計算機資源の解放などがある。本実施例では、共有ライブラリ化部３１とスレッドプール管理部４１とによって、ＯＳ２１上のミドルレイヤで運用可能である。
【００２３】
アプリ管理テーブル４４は、アプリ（ＡＰ）５１を識別するためのアプリ（ＡＰ）識別子４４−Ａ及びアプリ５１の実行状態を格納するアプリ（ＡＰ）状態４４−Ｂから構成される。アプリ５１の実行状態としては、アプリ５１を実行するためのスレッド６１が割り当てられていることを示す‘Ｄ’、アプリ５１のバイナリの実行開始を表す‘Ｓ’、アプリ５１のバイナリ実行中を示す‘Ｒ’及びアプリ５１の実行終了を表す‘Ｅ’の各値をもつ。ここで、‘Ｓ’及び‘Ｅ’の実行状態は、スレッド６１で処理されるスレッド処理部４２で設定される。その他の状態は、スレッドプール管理部４１が、アプリ５１のバイナリの処理内容によって設定する。
【００２４】
図３は、スレッド管理テーブル４５の構成を示す図である。スレッド管理テーブル４５は、スレッドプール管理部４１が生成するスレッド６１の最大数の値を格納するスレッドＭＡＸ数４５−Ａ、監視スレッド６２のスレッド監視部４３における処理結果を格納する異常フラグ４５−Ｂ、スレッド６１を識別するためのスレッド識別子４５−Ｃ及びスレッド６１が実行するアプリ５１の識別子を格納する４５−Ｄから構成される。スレッドＭＡＸ数４５−Ａは、ユーザによって予め設定される。異常フラグ４５−Ｂは、異常状態を表す‘１’及び正常状態を表す‘０’のいずれの値を格納する。
【００２５】
図４は、スレッドイベントテーブル４６の構成を示す図である。スレッドイベントテーブル４６は、スレッドプール管理部４１とスレッド６１との間で引き渡されるパラメータを設定するもので、スレッド６１の数分だけレコード行が存在する。各レコード行には、スレッドプール管理部４１がイベントを引き渡したいスレッドを識別するためのスレッド識別子４６−Ａ及び引き渡すパラメータから構成される。
【００２６】
このパラメータとしては、スレッド管理用パラメータ４６−Ｂ及びアプり（ＡＰ）実行用パラメータ４６−Ｃを備える。さらに、スレッド管理用パラメータ４６−Ｂとしては、スレッドの優先度４６−Ｂ１と計算機資源のアクセスを制御するための資源アクセス権限４６−Ｂ２とを有する。また、アプリ実行用パラメータ４６−Ｃは、スレッド６１が実行するアプリ５１の関数化されたバイナリを実行するために用いられる。
【００２７】
スレッド管理用パラメータ４６−Ｂの中のスレッドの優先度４６−Ｂ１は、従来アプリ５１を一つのプロセスとして実行した計算機環境上のＯＳで備えられたスケジューラを、ＯＳ２１上のミドルウェアレイヤのスレッドプール管理部４１で実現するためのパラメータである。例えば、優先度ベースのリアルタイムスケジュールは、優先度４６−Ｂ１で優先度を設定すればよい。設定した優先度は、従来アプリのバイナリを共有ライブラリ化部３１によって、共有ライブラリ５３上の関数化されたバイナリを実行するスレッド６１の優先度としてＯＳ２１に反映される。これにより、従来アプリを運用したスケジューラを外付けで柔軟に実現することができる。
【００２８】
また、アプリ実行用パラメータ４６−Ｃをスレッド６１に渡すことができるため、従来アプリの処理が、関数化されたバイナリでも実現できる。例えば、ｗｅｂサーバのアプリを共有ライブラリ化部３１によって関数化し、スレッド６１によって実行することを可能とし、その処理の開始と終了とをＯＳ２１のミドルレイヤで確実に監視することを可能とする。なお、アプリ処理の開始及び終了の監視処理の詳細については、図９を用いて後述する。
【００２９】
次に、共有ライブラリ化部３１による処理フローについて説明する。図５は、共有ライブラリ化部３１が実行する処理フローの詳細を示す図である。なお、以下の各ステップでは、共有ライブラリ化部３１が処理の実行主体であるので、主体の記載を省略する。
【００３０】
＜ステップ１０１＞
ユーザから、関数化バイナリの作成対象であるアプリ５１のアプリ識別子を受け取る。
【００３１】
＜ステップ１０２＞
ユーザが予め指定した、アプリ５１のソースファイルから関数化バイナリを作成するための中間ファイルを保存する場所を、その情報を格納する変換済アプリ（ＡＰ）格納場所記憶部３２から読込む。
【００３２】
＜ステップ１０３＞
アプリ（ＡＰ）ソースのアプリ５１を、コンパイラでアセンブルコードＡＰ５２に書換えて、変換済アプリ格納場所記憶部３２の指定場所へ格納する。ここで用いるコンパイラは、ＯＳ２１で運用可能な汎用コンパイラでよい。例えば汎用Ｌｉｎｘｕの場合、コンパイラ「ｇｃｃ（ＧＮＵ  Ｃｏｍｐｉｌｅｒ  Ｃｏｌｌｅｃｔｉｏｎ）」に相当するものである。
【００３３】
＜ステップ１０４＞
アセンブルコードＡＰ５２を読込み、このアセンブルコードからｅｎｔｒｙ＿ｐｏｉｎｔ処理の「＿ｍａｉｎ」シンボルを探し、ステップ１０１から受け取ったアプリ識別子を先頭に付け、ｅｎｔｒｙ＿ｐｏｉｎｔのシンボルを変換する。例えば、アプリ識別子が「ＡＰ１」の場合、「＿ｍａｉｎ」から「＿ＡＰ１＿ｍａｉｎ」に変換される。ただし、変換の形式には拘らず、アプリ５１と結び付けられるものであればよい。
【００３４】
＜ステップ１０５＞
アセンブルコードから終了処理の「＿ｅｘｉｔ」シンボルを探し、このシンボルがあれば、関数からのリターン処理に置換える。例えば、スタックフレームの「ｐｏｐ」と「ｒｅｔ」のアセンブラに置き換える。
【００３５】
＜ステップ１０６＞
コンパイラの共有ライブラリ生成オプションにより、変換済アプリ格納場所記憶部３２に中間ファイルとして格納されている変換済の全アセンブルコードＡＰ５２をコンパイルし、共有ライブラリ５３を生成する。例えば、先の「ｇｃｃ」の場合、「−ｓｈａｒｅｄ」のオプションを使う。
【００３６】
＜ステップ１０７＞
共有ライブラリ５３上の関数化されたアプリ５１のバイナリを実行するスレッド６１がアクセスできるように、記憶装置１２のＲＡＭ上にロードする。例えば、ＰＯＳＩＸのＡＰＩを活用するか、標準Ｌｉｎｕｘの場合には「ｌｄｃｏｎｆｉｇ」コマンドを活用することが可能である。
【００３７】
次に、スレッドプール管理部４１による処理フローについて説明する。図６は、スレッドプール管理部４１が実行する処理フローの詳細を示す図である。なお、以下の各ステップでは、スレッドプール管理部４１が処理の実行主体であるので、主体の記載を省略する。
【００３８】
＜ステップ２０１＞
スレッド監視テーブル４５のスレッドＭＡＸ数４５−Ａを読取り、内部変数に格納する。なお、スレッドＭＡＸ数４５−Ａは、ユーザから設定されていることを前提とし、本実施例では「３２」とする。
【００３９】
＜ステップ２０２＞
スレッド生成カウンタ（ｃｎｔ）の内部変数を初期化する（ｃｎｔ←０）。
【００４０】
＜ステップ２０３＞
スレッド生成カウンタ（ｃｎｔ）の値が、スレッドＭＡＸ数４５−Ａの値を超えたか否かを確認する。超えた場合には（Ｙ）、ステップ２０４に進み、超えていない場合には（Ｎ）、ステップ２１１に進む。
【００４１】
＜ステップ２０４＞
スレッド監視部４３により処理される監視スレッド６２を生成する。監視スレッド６２は、ＯＳ２１の機能を用いて生成する。
【００４２】
＜ステップ２０５＞
アプリ開始処理へ進む。アプリ開始処理については、図７を用いて後述する。
【００４３】
＜ステップ２１１＞
スレッド処理部４２により処理されるスレッド６１を生成し、ＯＳ２１からの戻り値を内部変数ＴＩＤへ格納する。スレッド６１は、ＯＳ２１の機能を用いて生成する。
【００４４】
＜ステップ２１２＞
スレッド生成カウンタ（ｃｎｔ）を１増加し、このスレッド生成カウンタ番目に対するスレッド管理テーブル４５のスレッド識別子４５−Ｃに、内部変数ＴＩＤを格納する。
【００４５】
＜ステップ２１３＞
スレッドイベントテーブル４６のスレッド生成カウンタ番目のスレッド識別子４６−Ａに内部変数ＴＩＤを格納し、同スレッド識別子４６−Ａの行を‘０’で初期化する。
【００４６】
＜ステップ２１４＞
スレッド管理テーブル４５のスレッド生成カウンタ番目の実行アプリ（ＡＰ）識別子４５−Ｄを‘０’で初期化する。
【００４７】
以上のように、ステップ２１１からステップ２１４まで、必要なスレッドを予め生成してプール化しておくことで、従来アプリ５１がプロセスとして実行開始するときに必要なプロセス生成処理時間を省くことができる。また、本実施例は、リアルタイム性が必要なシステムのアプリ５１の実行環境においても有効である。
【００４８】
続いて、先のステップ２０５のアプリ開始処理の処理フローについて説明する。図７は、アプリ開始処理の処理フローの詳細を示す図である。なお、以下の各ステップでは、スレッドプール管理部４１が処理の実行主体であるので、主体の記載を省略する。
＜ステップ３０１＞
ユーザからのアプリ開始要求のイベント通知、またはスレッド監視部４３からのイベント通知を受け取る。コンソールによるユーザからの要求イベントや後述するスレッド監視部４３からのイベントは、ＯＳ２１の機能を用いて実現する。例えば汎用Ｌｉｎｕｘの場合には、「ｓｅｌｅｃｔ」ＡＰＩの非同期イベント機能が利用できる。
【００４９】
＜ステップ３０２＞
受け取ったイベント通知が、アプリ開始要求のイベントか否かを確認する。アプリ開始要求のイベント通知である場合は（Ｙ）、ステップ３０３に進む。アプリ開始要求のイベント通知でない場合は（Ｎ）、すなわちスレッド監視部４３からのイベント通知である場合、ステップ３１１に進む。
【００５０】
＜ステップ３０３＞
ユーザから、アプリ識別子４４−Ａ、スレッド管理用パラメータ４６−Ｂ及びアプリ実行用パラメータ４６−Ｃを受け取る。これらのパラメータは、先のステップ３０２におけるユーザからのＡ５１開始要求のイベント通知が行われる際に、ユーザが設定するものである。
【００５１】
＜ステップ３０４＞
スレッド管理テーブル４５の実行アプリ識別子４５−Ｄの値が‘０’であるスレッド識別子４５−Ｃを読み取る。
【００５２】
＜ステップ３０５＞
スレッドイベントテーブル４６において、先のステップ３０４で読み取ったスレッド識別子４５−Ｃの識別子名を持つスレッド識別子４６−Ａと同じ行のスレッド管理用パラメータ４６−Ｂ及びアプリ実行用パラメータ４６−Ｃに、先のステップ３０３で受け取ったパラメータを格納する。
【００５３】
＜ステップ３０６＞
先のステップ３０４で読み取ったスレッド識別子４５−Ｃの識別子名を持つスレッド６１に対して、ＯＳ２１の機能を用いてイベント通知を行う。
【００５４】
＜ステップ３１１＞
スレッド管理テーブル４５の異常フラグ４５−Ｂを読み取る。
【００５５】
＜ステップ３１２＞
異常フラグ４５−Ｂの値が、正常値‘０’か否かを確認する。正常値‘０’であれば（Ｙ）、ステップ３０１に戻り、異常値‘１’であれば（Ｎ）、スレッドプール管理４１の処理を終了する。この終了処理には、先のステップ２１１で生成したスレッド６１を終了する処理などが含まれる。
【００５６】
次に、スレッド処理部４２による処理フローについて説明する。図８は、スレッド処理部４２が実行する処理フローの詳細を示す図である。なお、以下の各ステップでは、スレッド処理部４２が処理の実行主体であるので、主体の記載を省略する。
【００５７】
＜ステップ４０１＞
スレッドプール管理部４１からのイベント通知を待つ状態で、先のステップ３０５でスレッドイベントテーブル４６に必要なパラメータが設定された後に、スレッドプール管理部４１から先のステップ３０６によりイベント通知されるので、このイベント通知を受け取る。
【００５８】
＜ステップ４０２＞
スレッドイベントテーブル４６のスレッド管理用パラメータ４６−Ｂを読み取る。
【００５９】
＜ステップ４０３＞
スレッド管理用パラメータ４６−Ｂの中から４６−Ｂ１に格納されたスレッドの優先度及び４６−Ｂ２に格納された資源アクセス権限を、ＯＳ２１の機能を使って設定する。
【００６０】
＜ステップ４０４＞
スレッドイベントテーブル４６のアプリ実行用パラメータ４６−Ｃを読み取る。
【００６１】
＜ステップ４０５＞
アプリ実行処理に進む。アプリ実行処理については、図９を用いて後述する。
【００６２】
＜ステップ４０６＞
先のステップ４０３で設定したスレッドの優先度及び資源アクセス権限を元に戻す。先のステップ２１１でスレッド６１が生成された時には、ＯＳ２１で設定されたｄｅｆａｕｌｔのスレッドの優先度及び資源アクセス権限に戻す。
【００６３】
以上により、ステップ４０５の前後のステップ４０４とステップ４０６とによって、外付けで従来アプリ５１が運用された計算機環境上のプロセスまたはスレッドのスケジュール方法が実現できる。例えば、優先度ベースのリアルタイムスケジュール方式は、本実施例により容易に実現可能である。
【００６４】
次に、先のステップ４０５のアプリ実行処理について説明する。図９は、アプリ実行処理の処理フローの詳細を示す図である。なお、以下の各ステップでは、スレッド処理部４２が処理の実行主体であるので、主体の記載を省略する。
＜ステップ５０１＞
スレッドイベントテーブル４６のアプリ実行用パラメータ４６−Ｃにおけるｅｎｔｒｙ＿ｐｏｉｎｔ名４６−Ｃ１からアプリ識別子を取り出し、スレッド管理テーブル４５における自らのスレッド識別子４５−Ｃと同行にある実行アプリ識別子４５−Ｄに当該アプリ識別子を格納する。自らのスレッド識別子４５−Ｃは、ＯＳ２１の機能で取得可能であり、先のステップ２１１で格納したＯＳ２１の戻り値と一致する。
本ステップ５０１によって、実行対象のアプリ５１のバイナリと実行するスレッド６１との間の関連付けが行われる。
【００６５】
＜ステップ５０２＞
先のステップ５０１で取り出したアプリ識別子を、アプリ管理テーブル４４のアプリ識別子４４−Ａに格納し、アプリ状態４４−Ｂに開始状態を示す‘Ｓ’を格納する。
【００６６】
＜ステップ５０３＞
スレッドイベントテーブル４６のアプリ実行用パラメータ４６−Ｃにおけるｅｎｔｒｙ＿ｐｏｉｎｔ名４６−Ｃ１が示す関数を呼び出し、当該関数に引数４６−Ｃ２を渡し、共有ライブラリ５３上のアプリ５１のバイナリ処理を実行する。
【００６７】
＜ステップ５０４＞
先のステップ５０３によるアプリ５１のバイナリ処理からの戻り値を確認し、アプリ管理テーブル４４のアプリ状態４４−Ｂに終了状態を示す‘Ｅ’を格納する。先のステップ５０２と本ステップ５０４とによって、ＯＳ２１のミドルレイヤでアプリ５１の開始及び終了の実行状態が明確に管理できることになり、それを利用した高信頼機能の実現が容易となる。
【００６８】
＜ステップ５０５＞
スレッド管理テーブル４５の実行アプリ識別子４５−Ｄに‘０’を格納し、初期化状態にする。これによって、他のアプリ５１からの実行開始要求の受付が可能となる。
【００６９】
最後に、スレッド監視部４３による処理フローについて説明する。図１０は、スレッド監視部４３が実行する処理フローの詳細を示す図である。なお、以下の各ステップでは、スレッド監視部４３が処理の実行主体であるので、主体の記載を省略する。
【００７０】
本処理フローは、監視スレッド６２を使って処理される。スレッド６１が実行するアプリ５１のバイナリ処理が終了し、アプリ管理テーブル４４のアプリ状態４４−Ｂは‘Ｅ’状態である。この状態において、監視スレッド６２は、スレッド管理テーブル４５においてスレッド６１の実行アプリ識別子４５−Ｄがまだ‘０’でない状態をもつスレッド６１を監視する。それによって、スレッド６１の実行状態の監視が可能となり、ユーザからのアプリ５１の開始要求を実行できるスレッド６１が枯渇されることを防ぐ。もし、枯渇した場合にも、新しいスレッド６１を立ち上げる等の処理を実施することも可能である。また、この監視処理を、一定周期で以て実施してもよいし、異常カウンタを設けて異常の再確認処理として行ってもよい。
【００７１】
＜ステップ６０１＞
スレッド管理テーブル４５の異常フラグ４５−Ｂに‘０’を格納し、初期化する。
【００７２】
＜ステップ６０２＞
アプリ管理テーブル４４の先頭レコードのアプリ状態４４−Ｂを読み取る。
【００７３】
＜ステップ６０３＞
読み取ったアプリ状態が終了を示す‘Ｅ’か否かを判断する。終了‘Ｅ’であれば（Ｙ）、ステップ６０４に進み、終了‘Ｅ’でなければ（Ｎ）、ステップ６１１に進む。
【００７４】
＜ステップ６０４＞
アプリ管理テーブル４４から読み取ったアプリ状態４４−Ｂと同行にあるアプリ識別子４４−Ａを読み取る。
【００７５】
＜ステップ６０５＞
読み取ったアプリ識別子４４−Ａが、スレッド管理テーブル４５の実行アプリ識別子４５−Ｄに存在するか否かを確認する。
【００７６】
＜ステップ６０６＞
存在すれば（Ｙ）、ステップ６０７に進み、存在しなければ（Ｎ）、ステップ６１１に進む。
【００７７】
＜ステップ６０７＞
スレッド管理テーブル４５の異常フラグ４５−Ｂに異常を示す‘１’を格納する。
【００７８】
＜ステップ６０８＞
スレッドプール管理部４１へ、ＯＳ２１の機能によってイベント通知をする。また、このイベント通知によって、スレッドプール管理部４１において先のステップ３１１の処理が実行される。
【００７９】
＜ステップ６１１＞
アプリ管理テーブル４４の最後尾の行まで処理を行ったか否かを確認する。最後尾の行でなければ（Ｙ）、ステップ６１２に進み、最後尾の行であれば（Ｎ）、ステップ６０２に進む。
【００８０】
＜ステップ６１２＞
アプリ管理テーブル４４の次の行のアプリ状態４４−Ｂを読み取り、ステップ６０３に戻る。
【符号の説明】
【００８１】
１１…演算装置、１１−Ａ…ＣＰＵ、１２…記憶装置、２１…ＯＳ、
３１…共有ライブラリ（Ｌｉｂ）化部、３２…変換済アプリ（ＡＰ）格納場所記憶部、
４１…スレッドプール管理部、４２…スレッド処理部、４３…スレッド監視部、
４４…アプリ（ＡＰ）管理テーブル、４５…スレッド管理テーブル、
４６…スレッドイベントテーブル、５１…既存アプリ（ＡＰ）ソース、
５２…書換えアセンブルコード、５３…アプリ５１を関数化した共有ライブラリ、
６１…スレッド、６２…監視スレッド
【図１】
2019185423.tif 000003
【図２】
2019185423.tif 000004
【図３】
2019185423.tif 000005
【図４】
2019185423.tif 000006
【図５】
2019185423.tif 000007
【図６】
2019185423.tif 000008
【図７】
2019185423.tif 000009
【図８】
2019185423.tif 000010
【図９】
2019185423.tif 000011
【図１０】
2019185423.tif 000012