JP2022124765A - 多重制御プログラム、情報処理装置および多重制御方法 - Google Patents

Abstract

【課題】１台のＧＰＵが複数の処理を多重で実行しても、処理の重複実行による処理時間の増加を抑制する。
【解決手段】実行サーバ１は、複数の推論プロセス１１の処理を多重で実行させる場合に、複数の推論プロセス１１の処理の中で第１の工程の処理時間を閾値としてプロファイル情報１５に記録する。そして、実行サーバ１は、複数の推論プロセス１１のうちいずれかの推論プロセス１１の処理を実行中に、後続の推論プロセス１１から実行要求を受け付けると、後続の推論プロセス１１の処理の開始を、先行して実行中の推論プロセス１１の処理の開始から閾値以上遅らせる。
【選択図】図３

Description

本発明は、多重制御プログラムなどに関する。

近年、ＧＰＵ（Graphical Processing Unit）を使ってＡＩ（Artificial Intelligence）処理を実行するシステムが増加している。例えば、映像のＡＩ処理により物体検知等を行うシステムがある。

このようなシステムでは、１台のＧＰＵが１台のカメラから転送される映像を処理していたが、映像は一定周期で送られるため、処理の隙間でＧＰＵが空く時間が生じる。そこで、１台のＧＰＵが複数台のカメラから転送される映像を収容して処理することで、相互に隙間を埋めて効率よく利用することが期待される。

特開２０２０－１０９８９０号公報特開２０２０－１３５０６１号公報特開２０１９－１７５２９２号公報

しかしながら、１台のＧＰＵで複数の映像を処理する場合、１台のＧＰＵで複数の処理が多重で実行されることがある。このとき、処理同士の干渉により処理時間が増加するという問題がある。

ここで、処理同士の干渉により処理時間が増加する場合について、図２２を参照して説明する。図２２は、処理同士の干渉による処理時間の増加を説明する図である。図２２に示すように、１台のＧＰＵは、複数のタスクを多重で処理することが可能である。ここでは、タスクの処理は、映像の推論処理であり、４個の処理が並列で実行されている。

ＧＰＵは、単体で映像の推論処理を実行する場合には、予め定められた一定周期で推論処理を実行する。ところが、ＧＰＵが、４並列で映像の推論処理を実行する場合には、推論処理同士が干渉してしまい、処理時間が増加する場合がある。処理時間の増加の程度は、推論処理の内容や重なり方によって異なる。例えば、推論処理間の重なりが大きく、推論処理の重なる数が多い方が、処理時間の増加の程度は大きくなる。推論処理の開始タイミングは別々であるため、偶々開始が近い推論処理が多いと、推論処理の重なる数が多くなり、処理時間の増加の程度が大きくなり、推論処理の処理時間が一定周期を超過してしまう。すなわち、処理同士の干渉により処理時間が増加するという問題が起きる。

本発明は、１つの側面では、１台のＧＰＵが複数の処理を多重で実行しても、処理の重複実行による処理時間の増加を抑制することを目的とする。

１つの態様では、多重制御プログラムは、複数のアプリケーションの処理を多重で実行させる場合に、前記複数のアプリケーションの処理の中で第１の工程の処理時間を閾値として記憶部に記録し、前記複数のアプリケーションのうちいずれかのアプリケーションの処理を実行中に、後続のアプリケーションから実行要求を受け付けると、前記後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの処理の開始から前記閾値以上遅らせる、処理をコンピュータに実行させる。

１実施態様によれば、１台のＧＰＵが複数の処理を多重で実行しても、処理の重複実行による処理時間の増加を抑制することが可能となる。

図１は、実施例１に係る実行サーバを含むシステムの機能構成の一例を示す図である。図２Ａは、実施例１に係る多重制御を説明する図（１）である。図２Ｂは、実施例１に係る多重制御を説明する図（２）である。図３は、実施例１に係るＧＰＵ利用制御部の機能構成の一例を示す図である。図４は、実施例１に係るプロファイル情報の一例を示す図である。図５は、要求キューのデータ構造の一例を示す図である。図６は、実行サーバのハードウェア構成の一例を示す図である。図７は、実施例１に係る遅延実行判定処理のフローチャートの一例を示す図である。図８は、実施例１に係る遅延待機中要求管理処理のフローチャートの一例を示す図である。図９は、実施例１に係る利用要求送信処理のフローチャートの一例を示す図である。図１０は、実施例１に係る処理結果送信先判定処理のフローチャートの一例を示す図である。図１１は、実施例２に係るＧＰＵ利用制御部の機能構成の一例を示す図である。図１２は、実施例２に係るプロファイル情報の一例を示す図である。図１３は、実施例２に係る遅延実行判定処理のフローチャートの一例を示す図である。図１４は、実施例２に係る遅延待機中要求管理処理のフローチャートの一例を示す図である。図１５は、実施例３に係るＧＰＵ利用制御部の機能構成の一例を示す図である。図１６は、実施例３に係るプロファイル情報の一例を示す図である。図１７は、実施例３に係る遅延実行判定処理のフローチャートの一例を示す図である。図１８は、実施例３に係る遅延待機中要求管理処理のフローチャートの一例を示す図である。図１９は、実施例３に係る利用要求送信処理のフローチャートの一例を示す図である。図２０は、実施例３に係る処理結果送信先判定処理のフローチャートの一例を示す図である。図２１は、実施例１～３に係る多重制御の用途の一例を示す図である。図２２は、処理同士の干渉による処理時間の増加を説明する図である。

以下に、本願の開示する多重制御プログラム、情報処理装置および多重制御方法の実施例を図面に基づいて詳細に説明する。なお、本発明は、実施例により限定されるものではない。

［システムの構成］
図１は、実施例１に係る実行サーバを含むシステムの機能構成の一例を示す図である。システム９は、実行サーバ１と、ストレージサーバ３と、複数のカメラ５とを有する。システム９は、動画像（映像）に関し、推論処理する推論プロセス１１（アプリケーション）を、ＧＰＵ（Graphics Processing Unit）を搭載する実行サーバ１上で実行する。そして、システム９は、１台のＧＰＵ上で複数の推論プロセス１１を実行することを想定する。ここでいう推論プロセス１１とは、例えば、カメラ５から出力される映像から不審者を推定したり、交通量を推定したりするアプリケーションのことをいう。推論プロセス１１は、ＡＩフレームワーク１４の所定のライブラリを組み込んで推論モデル３２を用いて推論処理を実行する。

ストレージサーバ３は、複数のカメラ５からそれぞれ出力される映像のデータソース３１と、推論モデル３２とを有する。推論モデル３２は、推論プロセス１１の推論処理に用いられるモデルであり、所定のアルゴリズムに基づくものである。実施例１では、複数の推論プロセス１１で同じアルゴリズムに基づく推論モデル３２が用いられる場合とする。

実行サーバ１は、複数の推論プロセス１１と、ＧＰＵドライバ１３およびＡＩフレームワーク１４との間にＧＰＵ利用制御部１２を設ける。加えて、実行サーバ１は、プロファイル情報１５を有する。

ＧＰＵドライバ１３は、ＧＰＵを制御するための専用のソフトウェアである。例えば、ＧＰＵドライバ１３は、ＧＰＵ利用制御部１２から要求されるＧＰＵ利用要求をＡＩフレームワーク１４に送信する。ＧＰＵドライバ１３は、ＡＩフレームワーク１４から返却される処理結果をＧＰＵ利用制御部１２に送信する。

ＡＩフレームワーク１４は、推論プロセス１１の推論処理を実行する。ＡＩフレームワーク１４は、映像に関する推論処理を行うためのライブラリであり、推論プロセス１１（アプリケーション）に組み込まれる。ＡＩフレームワーク１４は、推論プロセス１１から呼び出され、ＧＰＵドライバ１３を介して推論処理を実行する。ＡＩフレームワーク１４としては、一例として、ＴｅｎｓｏｒＦｌｏｗ、ＭＸＮｅｔ、Ｐｙｔｏｒｃｈなどが挙げられる。

ＧＰＵ利用制御部１２は、推論プロセス１１（アプリケーション）からのＧＰＵ利用要求を監視して、推論プロセス１１におけるＧＰＵ利用の開始タイミングを変更する。例えば、ＧＰＵ利用制御部１２は、複数の推論プロセス１１を多重で実行させる場合には、所定の閾値に基づいて後続の推論プロセス１１の開始を遅延させてＧＰＵの利用を制御する。実施例１では、所定の閾値は、推論プロセス１１に含まれる複数のフェーズの中の、重複（干渉）して実行すると処理時間の影響が大きいフェーズの処理時間の値である。言い換えると、所定の閾値は、推論プロセス１１に含まれる複数のフェーズの中で重複（干渉）すると処理時間が増加してしまうフェーズの処理時間の値である。ＧＰＵ利用制御部１２は、２つの推論プロセス１１が近いタイミングで実行される場合には、先行の推論プロセス１１の開始から所定の閾値だけ後続の推論プロセス１１の開始を遅延させることで、干渉による処理時間の増加を抑制する。なお、実施例１では、複数の推論プロセス１１で用いられる推論モデル３２（アルゴリズム）が同じ場合であるので、複数の推論プロセス１１のそれぞれの複数のフェーズの処理時間は同一であるとする。

プロファイル情報１５は、所定の閾値を記憶する。所定の閾値は、例えば、後述する畳込み処理の処理時間である。一例として、ＧＰＵ利用制御部１２が、予め畳込み処理の処理時間を計測して、プロファイル情報１５に記録しておく。なお、プロファイル情報１５は、記憶部の一例である。

［実施例１に係る多重制御］
ここで、実施例１に係る多重制御について、図２Ａおよび図２Ｂを参照して説明する。図２Ａおよび図２Ｂは、実施例１に係る多重制御を説明する図である。図２Ａに示すように、推論プロセス１１は、３つのフェーズを含む。３つのフェーズは、前処理、畳込み処理および後処理であり、各処理の特性は異なる。前処理は、例えば、データソース３１等の処理データを用意するＣＰＵ処理と、ＣＰＵからＧＰＵへデータを転送するデータ転送処理とを含む。畳込み処理は、例えば、ディープラーニングの中核部分である、ＧＰＵを利用したデータ処理であり、畳込みニューラルネットワーク（Convolutional neural network）を用いて実行される。後処理は、例えば、ＧＰＵからＣＰＵへ処理結果を転送するデータ転送処理と処理結果を取り出して加工するＣＰＵ処理とを含む。

複数の推論プロセス１１が多重で実行される場合には、重なるフェーズの組み合わせにより処理時間の増加の影響が異なる。同種のフェーズが重なる場合には、処理時間の増加が大きくなる。異種のフェーズが重なる場合には、処理時間の増加は少なくなる。図２Ａ左図に示すように、畳込み処理および前処理や、後処理および畳込み処理のように、異なるフェーズ同士が重なる場合には、処理時間の増加は少ない。これに対して、図２Ａ右図に示すように、特に畳込み処理同士が重なる場合には、処理時間の増加は大きくなる。そこで、実施例では、処理時間の影響が大きい畳込み処理同士が重複（干渉）して実行しないように、ＧＰＵ利用制御部１２が、推論プロセス１１の開始タイミングを制御する。

具体的には、ＧＰＵ利用制御部１２は、複数の推論プロセス１１が近いタイミングで実行される場合には、推論プロセス１１の中の畳込み処理の処理時間を閾値として、後続の推論プロセス１１の開始を閾値以上遅延させる。ここでいう閾値として用いられる畳込み処理の処理時間は、推論プロセス１１が他の推論プロセス１１と重複しない状態で計測された畳込み処理の処理時間であり、予め計測されれば良い。

図２Ｂに示すように、例えば、ＧＰＵ利用制御部１２は、推論プロセス１１を示すアプリａ、アプリｂ、アプリｃを近いタイミングで実行させるとする。ＧＰＵ利用制御部１２は、アプリａの開始要求（ＧＰＵ利用要求）をＡＩフレームワーク１４に送り、推論処理を実行させる。アプリａに後続するアプリｂについて、ＧＰＵ利用制御部１２は、直前に実行されたアプリａの推論処理の開始よりも閾値以上遅らせて、アプリｂの開始要求（ＧＰＵ利用要求）をＡＩフレームワーク１４に送り、推論処理を実行させる。これにより、ＧＰＵ利用制御部１２は、アプリａおよびアプリｂの畳込み処理が重ならないように制御できる。

また、アプリｂに後続するアプリｃについて、ＧＰＵ利用制御部１２は、直前に実行されたアプリｂの推論処理の開始よりも閾値以上遅らせて、アプリｃの開始要求（ＧＰＵ利用要求）をＡＩフレームワーク１４に送り、推論処理を実行させる。これにより、ＧＰＵ利用制御部１２は、アプリａ、アプリｂおよびアプリｃの畳込み処理が重ならないように制御できる。

［ＧＰＵ利用制御部の機能構成］
図３は、実施例１に係るＧＰＵ利用制御部の機能構成の一例を示す図である。図３に示すように、ＧＰＵ利用制御部１２は、利用検知部１２１、読込部１２２、遅延実行判定部１２３、遅延待機中要求管理部１２４、要求キュー１２５、利用要求送信部１２６、処理結果受信部１２７、処理結果送信先判定部１２８および処理結果送信部１２９を有する。なお、遅延実行判定部１２３および遅延待機中要求管理部１２４は、遅延待機部の一例である。

利用検知部１２１は、推論プロセス１１（アプリケーション）からＧＰＵの利用要求（アプリの開始要求）を検知する。ＧＰＵの利用要求には、推論モデル３２の名前と、データソース３１の識別子とが含まれる。そして、利用検知部１２１は、検知したＧＰＵの利用要求における推論プロセス１１のプロセスＩＤを遅延実行判定部１２３に出力する。

読込部１２２は、プロファイル情報１５から閾値を読み込む。そして、読込部１２２は、読み込んだ閾値を後述する遅延実行判定部１２３に出力する。

ここで、実施例１に係るプロファイル情報１５の一例を、図４を参照して説明する。図４は、実施例１に係るプロファイル情報の一例を示す図である。図４に示すように、プロファイル情報１５には、閾値が設定される。閾値は、予め畳込み処理の処理時間を計測して得られた値である。一例として、閾値として「ｎｎ」が設定されている。なお、「ｎｎ」は、正の整数である。

図３に戻って、遅延実行判定部１２３は、ＧＰＵの利用要求がされた推論プロセス１１の実行までの遅延時間を判定する。例えば、遅延実行判定部１２３は、ＧＰＵの利用要求を蓄積する要求キュー１２５が空であるか否かを判定する。遅延実行判定部１２３は、要求キュー１２５が空である場合には、ＧＰＵを最終に利用した時刻（ＧＰＵ最終利用時刻）を取得する。遅延実行判定部１２３は、プロファイル情報１５から閾値を取得する。遅延実行判定部１２３は、最終利用時刻に閾値を加えた時刻から現在時刻を引いた時間を待機時間として計算する。そして、遅延実行判定部１２３は、待機時間が０より大きい場合には、ＧＰＵの利用要求を要求キュー１２５に蓄積するとともに、遅延待機中要求管理部１２４へ待機時間を設定する。すなわち、遅延実行判定部１２３は、ＧＰＵの利用要求がされた（後続の）推論プロセス１１の開始タイミングを先行の推論プロセス１１の利用開始から閾値以上遅らせるように制御する。つまり、遅延実行判定部１２３は、ＧＰＵの利用要求がされた推論プロセス１１の畳込み処理と先行の推論プロセス１１の畳込み処理が重複しないように制御する。また、遅延実行判定部１２３は、待機時間が０以下の場合には、ＧＰＵの利用要求を利用要求送信部１２６に対して依頼する。すなわち、待機時間が０以下の場合には、ＧＰＵ最終利用時刻は現在時刻より閾値以上前となる。このため、遅延実行判定部１２３は、後続の推論プロセス１１が先行の推論プロセス１１の畳込み処理と重複しないと判断し、後続の推論プロセス１１のＧＰＵの利用要求を依頼する。

また、遅延実行判定部１２３は、要求キュー１２５が空でない場合には、ＧＰＵの利用要求を要求キュー１２５に蓄積する。ここで、要求キュー１２５のデータ構造の一例を、図５を参照して説明する。

図５は、要求キューのデータ構造の一例を示す図である。図５に示すように、要求キュー１２５は、１つのＧＰＵ利用要求に対して、ＧＰＵ利用要求情報および要求元プロセスＩＤを保持する。ＧＰＵ利用要求情報には、推論モデル名と入力データ識別子とが含まれる。推論モデル名は、推論モデル３２の名前である。入力データ識別子は、データソース３１を一意に識別する識別子である。要求元プロセスＩＤは、推論プロセス１１のプロセスＩＤである。

図３に戻って、遅延待機中要求管理部１２４は、遅延を待機しているＧＰＵの利用要求を管理する。例えば、遅延待機中要求管理部１２４は、遅延実行判定部１２３によって設定された待機時間だけ待機する。遅延待機中要求管理部１２４は、待機時間だけ待機すると、要求キュー１２５の先頭のＧＰＵの利用要求を利用要求送信部１２６に対して依頼する。そして、遅延待機中要求管理部１２４は、要求キュー１２５が空であるか否かを判定する。遅延待機中要求管理部１２４は、要求キュー１２５が空でない場合には、プロファイル情報１５から閾値を取得し、取得した閾値を待機時間に設定する。すなわち、遅延待機中要求管理部１２４は、後続の推論プロセス１１の畳込み処理と先行の推論プロセス１１の畳込み処理が重複しないように、現に送信した推論プロセス１１の利用開始から閾値分後続の推論プロセス１１の開始タイミングを遅らせるように制御する。

利用要求送信部１２６は、ＧＰＵの利用要求を、ＧＰＵドライバ１３を介してＡＩフレームワーク１４へ送信する。例えば、利用要求送信部１２６は、ＧＰＵを最終に利用した時刻（ＧＰＵ最終利用時刻）を現在時刻に更新する。そして、利用要求送信部１２６は、ＧＰＵの利用要求の依頼元のプロセスＩＤをＧＰＵ最終利用時刻に対応付けて記録する。なお、ＧＰＵ最終利用時刻と依頼元のプロセスＩＤとの対応付けは、図示せぬ記憶部に記録される。そして、利用要求送信部１２６は、ＧＰＵの利用要求をＧＰＵドライバ１３へ送信する。

処理結果受信部１２７は、ＡＩフレームワーク１４によって処理された処理結果を、ＧＰＵドライバ１３を介して受信する。

処理結果送信先判定部１２８は、処理結果の送信先を判定する。例えば、処理結果送信先判定部１２８は、利用要求送信部１２６から、記録された、ＧＰＵ最終利用時刻に対応付けられた依頼元のプロセスＩＤを処理結果の送信先として取得する。

処理結果送信部１２９は、処理結果を、処理結果送信先判定部１２８によって判定された依頼元のプロセスＩＤに対応する推論プロセス１１へ送信する。

［実行サーバのハードウェア構成］
図６は、実行サーバのハードウェア構成の一例を示す図である。図６に示すように、実行サーバ１は、ＣＰＵ２１に加えてＧＰＵ２２を有する。そして、実行サーバ１は、メモリ２３、ハードディスク２４およびネットワークインターフェイス２５を有する。図６に示した各部は、例えばバス２６で相互に接続される。

ネットワークインターフェイス２５は、ネットワークインターフェイスカード等であり、ストレージサーバ３等の他の装置との通信を行う。ハードディスク２４は、図１および図３に示した機能を動作させるプログラムやプロファイル情報１５を記憶する。

ＣＰＵ２１は、図１および図３に示した各処理部と同様の処理を実行するプログラムをハードディスク２４等から読み出してメモリ２３に展開することで、図１および図３等で説明した各機能を実行するプロセスを動作させる。例えば、このプロセスは、実行サーバ１が有する各処理部と同様の機能を実行する。具体的には、ＣＰＵ２１は、推論プロセス１１、ＧＰＵ利用制御部１２、ＧＰＵドライバ１３およびＡＩフレームワーク１４等と同様の機能を有するプログラムをハードディスク２４等から読み出す。そして、ＣＰＵ２１は、推論プロセス１１、ＧＰＵ利用制御部１２、ＧＰＵドライバ１３およびＡＩフレームワーク１４等と同様の処理を実行するプロセスを実行する。

ＧＰＵ２２は、図１で示したＡＩフレームワーク１４を用いて推論プロセス１１の推論処理を実行するプログラムをハードディスク２４等から読み出してメモリ２３に展開することで、当該プログラムを実行するプロセスを動作させる。ＧＰＵ２２は、複数の推論プロセス１１を多重で動作させる。

［ＧＰＵ利用制御のフローチャート］
ここで、実施例１に係るＧＰＵ利用制御処理のフローチャートを、図７～図１０を参照して説明する。

［遅延実行判定処理のフローチャート］
まず、図７は、実施例１に係る遅延実行判定処理のフローチャートの一例を示す図である。図７に示すように、利用検知部１２１は、ＧＰＵの利用要求を検知したか否かを判定する（ステップＳ１１）。ＧＰＵの利用要求を検知していないと判定した場合には（ステップＳ１１；Ｎｏ）、利用検知部１２１は、ＧＰＵの利用要求を検知するまで、判定処理を繰り返す。一方、ＧＰＵの利用要求を検知したと判定した場合には（ステップＳ１１；Ｙｅｓ）、利用検知部１２１は、要求送信元のプロセスＩＤ（ＰＩＤ）を取得する（ステップＳ１２）。

続いて、遅延実行判定部１２３は、待機中の利用要求を蓄積する要求キュー１２５が空であるか否かを判定する（ステップＳ１３）。要求キュー１２５が空であると判定した場合には（ステップＳ１３；Ｙｅｓ）、遅延実行判定部１２３は、図示せぬ記憶部に記録されているＧＰＵ最終利用時刻を取得する（ステップＳ１４）。ＧＰＵ最終利用時刻は、ＧＰＵを最終に利用した時刻であり、具体的には直近でＧＰＵの利用要求を送信した時刻である。ＧＰＵ最終利用時刻は、利用要求送信部１２６によって記録される。

遅延実行判定部１２３は、プロファイル情報１５から閾値を取得する（ステップＳ１５）。遅延実行判定部１２３は、システム（ＯＳ）から現在時刻を取得する（ステップＳ１６）。そして、遅延実行判定部１２３は、以下の式（１）から待機時間を計算する（ステップＳ１７）。
待機時間＝（ＧＰＵ最終利用時刻＋閾値）－現在時刻・・・（１）

そして、遅延実行判定部１２３は、待機時間が０より大きいか否かを判定する（ステップＳ１８）。待機時間が０以下であると判定した場合には（ステップＳ１８；Ｎｏ）、遅延実行判定部１２３は、ＧＰＵ利用要求で検知した要求とＰＩＤを利用要求送信部１２６へ出力して当該要求の送信を依頼する（ステップＳ１９）。すなわち、待機時間が０以下の場合には、ＧＰＵ最終利用時刻が現在時刻より閾値以上前である。このため、遅延実行判定部１２３は、後続の推論プロセス１１が先行の推論プロセス１１の畳込み処理と重複しないと判断し、後続の推論プロセス１１のＧＰＵ利用要求を依頼する。そして、遅延実行判定部１２３は、遅延実行判定処理を終了する。

一方、待機時間が０より大きいと判定した場合には（ステップＳ１８；Ｙｅｓ）、遅延実行判定部１２３は、要求キュー１２５にＧＰＵ利用要求情報およびＰＩＤを追加する（ステップＳ２０）。そして、遅延実行判定部１２３は、遅延待機中要求管理部１２４へ待機時間を設定する（ステップＳ２１）。すなわち、遅延実行判定部１２３は、ＧＰＵの利用要求が検知された（後続の）推論プロセス１１の開始タイミングを先行の推論プロセス１１の利用開始から閾値以上遅らせるように制御する。つまり、遅延実行判定部１２３は、ＧＰＵの利用要求がされた推論プロセス１１の畳込み処理と先行の推論プロセス１１の畳込み処理が重複しないように制御する。そして、遅延実行判定部１２３は、遅延実行判定処理を終了する。

また、ステップＳ１３において、要求キュー１２５が空でないと判定した場合には（ステップＳ１３；Ｎｏ）、遅延実行判定部１２３は、要求キュー１２５の末尾にＧＰＵ利用要求情報およびＰＩＤを追加する（ステップＳ２２）。そして、遅延実行判定部１２３は、遅延実行判定処理を終了する。

［遅延待機中要求管理処理のフローチャート］
次に、図８は、実施例１に係る遅延待機中要求管理処理のフローチャートの一例を示す図である。図８に示すように、遅延待機中要求管理部１２４は、待機時間が設定されたか否かを判定する（ステップＳ３１）。待機時間が設定されていないと判定した場合には（ステップＳ３１；Ｎｏ）、遅延待機中要求管理部１２４は、待機時間が設定されるまで、判定処理を繰り返す。

一方、待機時間が設定されていると判定した場合には（ステップＳ３１；Ｙｅｓ）、遅延待機中要求管理部１２４は、設定された時間だけ待機する（ステップＳ３２）。設定された時間だけ待機した後、遅延待機中要求管理部１２４は、要求キュー１２５の先頭の要求とＰＩＤを利用要求送信部１２６へ出力して当該要求の送信を依頼する（ステップＳ３３）。

そして、遅延待機中要求管理部１２４は、要求キュー１２５が空であるか否かを判定する（ステップＳ３４）。要求キュー１２５が空でないと判定した場合には（ステップＳ３４；Ｎｏ）、遅延待機中要求管理部１２４は、プロファイル情報１５から閾値を取得する（ステップＳ３５）。そして、遅延待機中要求管理部１２４は、次の要求を待機させるべく、閾値を待機時間に設定する（ステップＳ３６）。すなわち、遅延待機中要求管理部１２４は、次のＧＰＵの利用要求の推論プロセス１１の開始タイミングを先行の推論プロセス１１の利用開始から閾値以上遅らせるように制御する。そして、遅延待機中要求管理部１２４は、ステップＳ３２に移行する。

一方、要求キュー１２５が空であると判定した場合には（ステップＳ３４；Ｙｅｓ）、遅延待機中要求管理部１２４は、遅延待機中要求管理処理を終了する。

［利用要求送信処理のフローチャート］
次に、図９は、実施例１に係る利用要求送信処理のフローチャートの一例を示す図である。図９に示すように、利用要求送信部１２６は、ＧＰＵ利用要求の送信依頼があったか否かを判定する（ステップＳ４１）。ＧＰＵ利用要求の送信依頼がなかったと判定した場合には（ステップＳ４１；Ｎｏ）、利用要求送信部１２６は、送信依頼があるまで、判定処理を繰り返す。

一方、ＧＰＵ利用要求の送信依頼があったと判定した場合には（ステップＳ４１；Ｙｅｓ）、利用要求送信部１２６は、システム（ＯＳ）から現在時刻を取得する（ステップＳ４２）。そして、利用要求送信部１２６は、ＧＰＵ最終利用時刻を現在時刻に更新する（ステップＳ４３）。利用要求送信部１２６は、ＧＰＵ最終利用時刻に対応付けて依頼元のＰＩＤを記録する（ステップＳ４４）。

そして、利用要求送信部１２６は、ＧＰＵドライバ１３へＧＰＵ利用要求を送信する（ステップＳ４５）。そして、利用要求送信部１２６は、利用要求送信処理を終了する。

［処理結果送信先判定処理のフローチャート］
次に、図１０は、実施例１に係る処理結果送信先判定処理のフローチャートの一例を示す図である。図１０に示すように、処理結果送信先判定部１２８は、処理結果を受信したか否かを判定する（ステップＳ５１）。処理結果を受信していないと判定した場合には（ステップＳ５１；Ｎｏ）、処理結果送信先判定部１２８は、処理結果を受信するまで、判定処理を繰り返す。

一方、処理結果を受信したと判定した場合には（ステップＳ５１；Ｙｅｓ）、処理結果送信先判定部１２８は、利用要求送信部１２６から、記録された依頼元のＰＩＤを取得する（ステップＳ５２）。そして、処理結果送信先判定部１２８は、取得したＰＩＤに対応するアプリケーション（推論プロセス１１）へ処理結果を送信する（ステップＳ５３）。そして、処理結果送信先判定部１２８は、処理結果送信先判定処理を終了する。

［実施例１の効果］
このようにして、上記実施例１では、実行サーバ１は、複数のアプリケーションの処理を多重で実行させる場合に、複数のアプリケーションの処理の中で第１の工程の処理時間を閾値としてプロファイル情報１５に記録する。実行サーバ１は、複数のアプリケーションのうちいずれかのアプリケーションの処理を実行中に、後続のアプリケーションから実行要求を受け付けると、後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの処理の開始から閾値以上遅らせる。かかる構成によれば、実行サーバ１は、第１の工程が重複しないように制御できることとなり、第１の工程の重複実行による処理時間の増加を抑制することができる。

また、上記実施例１では、実行サーバ１は、後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの開始時刻に閾値を加えた値から後続のアプリケーションの実行要求のタイミングの時刻を差し引いた値以上遅らせる。かかる構成によれば、実行サーバ１は、後続のアプリケーションの処理の開始を第１の工程が重複しないような長さ以上遅らせることができる。

また、上記実施例１では、実行サーバ１は、複数のアプリケーションの処理が同一のアルゴリズムを用いる場合には、第１の工程の処理時間を測定して得られる値を閾値とする。かかる構成によれば、実行サーバ１は、第１の工程の処理時間を測定して得られる値を閾値として用いることで、第１の工程の重複実行による処理時間の増加を抑制することができる。

ところで、実施例１では、複数の推論プロセス１１を多重で実行させる場合に、各推論プロセス１１で用いられる推論モデル３２（アルゴリズム）が同じ場合であるとした。すなわち、実行サーバ１は、いずれかの推論プロセス１１の畳込み処理の処理時間を計測して閾値としてプロファイル情報１５に記録しておき、後続の推論プロセス１１の開始タイミングを、先行の推論プロセス１１の利用開始から閾値以上遅らせる。しかしながら、実施例１では、これに限定されず、複数の推論プロセス１１を多重で実行させる場合に、各推論プロセス１１で用いられる推論モデル３２（アルゴリズム）が異なる場合であっても良い。

そこで、実施例２では、複数の推論プロセス１１を多重で実行させる場合に、各推論プロセス１１で用いられる推論モデル３２（アルゴリズム）が異なる場合を説明する。

［ＧＰＵ利用制御部の機能構成］
図１１は、実施例２に係るＧＰＵ利用制御部の機能構成の一例を示す図である。なお、図３に示すＧＰＵ利用制御部と同一の構成については同一符号を示すことで、その重複する構成および動作の説明ついては省略する。実施例１と実施例２とが異なるところは、プロファイル情報１５をプロファイル情報１５Ａに変更した点にある。また、実施例１と実施例２とが異なるところは、遅延実行判定部１２３、遅延待機中要求管理部１２４をそれぞれ遅延実行判定部１２３Ａ、遅延待機中要求管理部１２４Ａに変更した点にある。

プロファイル情報１５Ａは、推論モデル３２（アルゴリズム）ごとの、前処理の処理時間と、畳込み処理の処理時間を記憶する。一例として、ＧＰＵ利用制御部１２が、予め推論モデル３２ごとの、前処理および畳込み処理の処理時間を計測して、プロファイル情報１５Ａに記録しておく。

ここで、実施例２に係るプロファイル情報１５Ａの一例を、図１２を参照して説明する。図１２は、実施例２に係るプロファイル情報の一例を示す図である。図１２に示すように、プロファイル情報１５Ａは、モデル名、前処理時間および畳込み処理時間を対応付けて記憶する。モデル名は、推論プロセス１１の推論処理に用いられる推論モデル３２の名前である。前処理時間は、モデル名が示す推論モデル３２を用いた推論プロセス１１の前処理の処理時間である。畳込み処理時間は、モデル名が示す推論モデル３２を用いた推論プロセス１１の畳込み処理の処理時間である。モデル名ごとの前処理時間および畳込み処理時間は、予め計測して得られた値である。

一例として、モデル名が「モデルＡ」である場合に、前処理時間として「Ｔｂ＿Ａ」、畳込み処理時間として「Ｔｔ＿Ａ」と記憶している。モデル名が「モデルＢ」である場合に、前処理時間として「Ｔｂ＿Ｂ」、畳込み処理時間として「Ｔｔ＿Ｂ」と記憶している。モデル名が「モデルＣ」である場合に、前処理時間として「Ｔｂ＿Ｃ」、畳込み処理時間として「Ｔｔ＿Ｃ」と記憶している。なお、「Ｔｂ＿Ａ」、「Ｔｔ＿Ａ」、「Ｔｂ＿Ｂ」、「Ｔｔ＿Ｂ」、「Ｔｂ＿Ｃ」および「Ｔｔ＿Ｃ」は、正の整数である。

図１１に戻って、遅延実行判定部１２３Ａは、ＧＰＵの利用要求がされた推論プロセス１１の実行までの遅延時間を判定する。

例えば、遅延実行判定部１２３Ａは、ＧＰＵの利用要求に含まれる推論モデル３２のモデル名を取得する。そして、遅延実行判定部１２３Ａは、ＧＰＵの利用要求を蓄積する要求キュー１２５が空であるか否かを判定する。遅延実行判定部１２３Ａは、要求キュー１２５が空である場合には、ＧＰＵを最終に利用した時刻（ＧＰＵ最終利用時刻）と最終に利用した推論モデル３２のモデル名を取得する。つまり、遅延実行判定部１２３Ａは、直前に実行された（先行した）推論プロセス１１で用いられる推論モデル３２のモデル名を取得する。遅延実行判定部１２３Ａは、プロファイル情報１５Ａから、先行した推論プロセス１１で用いられる推論モデル３２のモデル名に対応する前処理時間および畳込み処理時間を取得する。遅延実行判定部１２３Ａは、プロファイル情報１５Ａから、要求された（後続の）推論プロセス１１で用いられる推論モデル３２のモデル名に対応する前処理時間および畳込み処理時間を取得する。

そして、遅延実行判定部１２３Ａは、先行した推論プロセス１１で用いられる推論モデル３２に対応する前処理時間と畳込み処理時間とを加えた値から、後続の推論プロセス１１で用いられる推論モデル３２に対応する前処理時間を引いた値を閾値として計算する。すなわち、遅延実行判定部１２３Ａは、先行の推論プロセス１１で用いられる推論モデル３２と後続の推論プロセス１１で用いられる推論モデル３２との組み合わせに基づいて閾値を計算する。

そして、遅延実行判定部１２３Ａは、最終利用時刻に閾値を加えた時刻から現在時刻を引いた時間を待機時間として計算する。そして、遅延実行判定部１２３Ａは、待機時間が０より大きい場合には、ＧＰＵの利用要求を要求キュー１２５に蓄積するとともに、遅延待機中要求管理部１２４Ａへ待機時間を設定する。すなわち、遅延実行判定部１２３Ａは、ＧＰＵの利用要求がされた（後続の）推論プロセス１１の開始タイミングを先行の推論プロセス１１の利用開始から閾値以上遅らせるように制御する。つまり、遅延実行判定部１２３Ａは、ＧＰＵの利用要求がされた推論プロセス１１の畳込み処理と先行の推論プロセス１１の畳込み処理が重ならないように制御する。また、遅延実行判定部１２３Ａは、待機時間が０以下の場合には、ＧＰＵの利用要求を利用要求送信部１２６に対して依頼する。すなわち、待機時間が０以下の場合には、ＧＰＵ最終利用時刻が現在時刻より閾値以上前である。このため、遅延実行判定部１２３Ａは、後続の推論プロセス１１が先行の推論プロセス１１の畳込み処理と重複しないと判断し、後続の推論プロセス１１のＧＰＵの利用要求を依頼する。

遅延待機中要求管理部１２４Ａは、遅延を待機しているＧＰＵの利用要求を管理する。例えば、遅延待機中要求管理部１２４Ａは、遅延実行判定部１２３Ａによって設定された待機時間だけ待機する。遅延待機中要求管理部１２４Ａは、待機時間だけ待機すると、要求キュー１２５の先頭のＧＰＵの利用要求を利用要求送信部１２６に対して依頼する。そして、遅延待機中要求管理部１２４Ａは、要求キュー１２５が空であるか否かを判定する。遅延待機中要求管理部１２４Ａは、要求キュー１２５が空でない場合には、要求キュー１２５の先頭にある要求の推論モデル名を取得する。遅延待機中要求管理部１２４Ａは、直前に実行された（先行した）推論プロセス１１で用いられる推論モデル３２のモデル名を取得する。遅延待機中要求管理部１２４Ａは、プロファイル情報１５Ａから、要求の推論モデル名に対応する前処理時間および畳込み処理時間を取得する。遅延待機中要求管理部１２４Ａは、プロファイル情報１５Ａから、先行した推論プロセス１１で用いられる推論モデル３２のモデル名に対応する前処理時間および畳込み処理時間を取得する。

そして、遅延待機中要求管理部１２４Ａは、先行した推論プロセス１１で用いられる推論モデル３２に対応する前処理時間と畳込み処理時間とを加えた値から、要求の推論モデル名に対応する前処理時間を引いた値を閾値として計算する。すなわち、遅延待機中要求管理部１２４Ａは、先行の推論プロセス１１で用いられる推論モデル３２と要求の推論プロセス１１で用いられる推論モデル３２との組み合わせに基づいて閾値を計算する。

そして、遅延待機中要求管理部１２４Ａは、計算した閾値を待機時間に設定する。すなわち、遅延待機中要求管理部１２４Ａは、後続の推論プロセス１１の畳込み処理と先行の推論プロセス１１の畳込み処理が重複しないように、現に送信した推論プロセス１１の利用開始から閾値分後続の推論プロセス１１の開始タイミングを遅らせるように制御する。

［ＧＰＵ利用制御のフローチャート］
ここで、実施例２に係る遅延実行判定処理のフローチャートを、図１３を参照して説明する。図１３は、実施例２に係る遅延実行判定処理のフローチャートの一例を示す図である。図１３に示すように、利用検知部１２１は、ＧＰＵの利用要求を検知したか否かを判定する（ステップＳ６１）。ＧＰＵの利用要求を検知していないと判定した場合には（ステップＳ６１；Ｎｏ）、利用検知部１２１は、ＧＰＵの利用要求を検知するまで、判定処理を繰り返す。一方、ＧＰＵの利用要求を検知したと判定した場合には（ステップＳ６１；Ｙｅｓ）、利用検知部１２１は、要求送信元のプロセスＩＤ（ＰＩＤ）と要求に対応するモデル名を取得する（ステップＳ６２）。ここでは、要求に対応するモデル名は、「モデルＡ」であるとする。

続いて、遅延実行判定部１２３Ａは、待機中の利用要求を蓄積する要求キュー１２５が空であるか否かを判定する（ステップＳ６３）。要求キュー１２５が空であると判定した場合には（ステップＳ６３；Ｙｅｓ）、遅延実行判定部１２３Ａは、記録されているＧＰＵ最終利用時刻と最終利用モデル名を取得する（ステップＳ６４）。ここでは、最終利用モデル名は、「モデルＢ」であるとする。ＧＰＵ最終利用時刻および最終利用モデル名は、利用要求送信部１２６によって記録される。

遅延実行判定部１２３Ａは、プロファイル情報１５Ａからモデル名に対応する情報を取得する（ステップＳ６５）。ここでは、遅延実行判定部１２３Ａは、プロファイル情報１５Ａから、最終利用モデル名（モデルＢ）に対応する前処理時間および畳込み処理時間を取得する。遅延実行判定部１２３Ａは、プロファイル情報１５Ａから、要求に対応するモデル名（モデルＡ）に対応する前処理時間および畳込み処理時間を取得する。

遅延実行判定部１２３Ａは、システム（ＯＳ）から現在時刻を取得する（ステップＳ６６）。そして、遅延実行判定部１２３は、以下の式（２）から閾値を計算し、計算した閾値を用いて、式（３）から待機時間を計算する（ステップＳ６７）。なお、式（３）は、式（１）と同じ式である。
閾値＝モデルＢ前処理時間＋モデルＢ畳込み処理時間－モデルＡ前処理時間・・・（２）
待機時間＝（ＧＰＵ最終利用時刻＋閾値）－現在時刻・・・・・・・・・・・・・（３）

そして、遅延実行判定部１２３Ａは、待機時間が０より大きいか否かを判定する（ステップＳ６８）。待機時間が０以下であると判定した場合には（ステップＳ６８；Ｎｏ）、遅延実行判定部１２３Ａは、ＧＰＵ利用要求で検知した要求とＰＩＤを利用要求送信部１２６へ出力して当該要求の送信を依頼する（ステップＳ６９）。すなわち、待機時間が０以下の場合には、ＧＰＵ最終利用時刻が現在時刻より閾値以上前である。このため、遅延実行判定部１２３Ａは、後続の推論プロセス１１が先行の推論プロセス１１の畳込み処理と重複しないと判断し、後続の推論プロセス１１のＧＰＵ利用要求を依頼する。そして、遅延実行判定部１２３Ａは、遅延実行判定処理を終了する。

一方、待機時間が０より大きいと判定した場合には（ステップＳ６８；Ｙｅｓ）、遅延実行判定部１２３Ａは、要求キュー１２５にＧＰＵ利用要求情報およびＰＩＤを追加する（ステップＳ７０）。そして、遅延実行判定部１２３Ａは、遅延待機中要求管理部１２４Ａへ待機時間を設定する（ステップＳ７１）。すなわち、遅延実行判定部１２３Ａは、後続の推論プロセス１１が先行の推論プロセス１１の処理時間の影響が大きい畳込み処理と重複しないように、先行の推論プロセス１１の利用開始から閾値以上後続の推論プロセス１１の開始タイミングを遅らせるように制御する。そして、遅延実行判定部１２３Ａは、遅延実行判定処理を終了する。

また、ステップＳ６３において、要求キュー１２５が空でないと判定した場合には（ステップＳ６３；Ｎｏ）、遅延実行判定部１２３Ａは、要求キュー１２５の末尾にＧＰＵ利用要求情報およびＰＩＤを追加する（ステップＳ７２）。そして、遅延実行判定部１２３Ａは、遅延実行判定処理を終了する。

次に、図１４は、実施例２に係る遅延待機中要求管理処理のフローチャートの一例を示す図である。図１４に示すように、遅延待機中要求管理部１２４Ａは、待機時間が設定されたか否かを判定する（ステップＳ８１）。待機時間が設定されていないと判定した場合には（ステップＳ８１；Ｎｏ）、遅延待機中要求管理部１２４Ａは、待機時間が設定されるまで、判定処理を繰り返す。

一方、待機時間が設定されていると判定した場合には（ステップＳ８１；Ｙｅｓ）、遅延待機中要求管理部１２４Ａは、設定された時間だけ待機する（ステップＳ８２）。設定された時間だけ待機した後、遅延待機中要求管理部１２４Ａは、要求キュー１２５の先頭の要求とＰＩＤを利用要求送信部１２６へ出力して当該要求の送信を依頼する（ステップＳ８３）。

そして、遅延待機中要求管理部１２４Ａは、要求キュー１２５が空であるか否かを判定する（ステップＳ８４）。要求キュー１２５が空でないと判定した場合には（ステップＳ８４；Ｎｏ）、遅延待機中要求管理部１２４Ａは、要求キュー１２５の先頭にある要求のモデル名を取得する（ステップＳ８５）。ここでは、先頭にある要求のモデル名は、モデルＡであるとする。遅延待機中要求管理部１２４Ａは、直前の送信依頼に対応するモデル名を取得する（ステップＳ８６）。ここでは、直前の送信依頼に対応するモデル名は、モデルＢであるとする。なお、遅延待機中要求管理部１２４Ａは、直前の送信依頼に対応するモデル名として、ＧＰＵ最終利用時刻に対応付けられたモデル名を取得すれば良い。

そして、遅延待機中要求管理部１２４Ａは、プロファイル情報１５Ａからモデル名に対応する情報を取得する（ステップＳ８７）。ここでは、遅延待機中要求管理部１２４Ａは、プロファイル情報１５Ａから、モデルＡに対応する前処理時間および畳込み処理時間を取得し、モデルＢに対応する前処理時間および畳込み処理時間を取得する。

そして、遅延待機中要求管理部１２４Ａは、前述した式（２）から閾値を計算する（ステップＳ８８）。そして、遅延待機中要求管理部１２４Ａは、次の要求を待機させるべく、閾値を待機時間に設定する（ステップＳ８９）。そして、遅延待機中要求管理部１２４Ａは、ステップＳ８２に移行する。

一方、要求キュー１２５が空であると判定した場合には（ステップＳ８４；Ｙｅｓ）、遅延待機中要求管理部１２４Ａは、遅延待機中要求管理処理を終了する。

［実施例２の効果］
このようにして、上記実施例２では、実行サーバ１は、複数のアプリケーションの処理が異なるアルゴリズムを用いる場合には、アルゴリズムごとに第１の工程と第１の工程より前の第２の工程の処理時間をプロファイル情報１５Ａに記録する。実行サーバ１は、先行して実行中のアプリケーションの処理におけるアルゴリズムに対応する第１の工程の処理時間と第２の工程の処理時間と、後続のアプリケーションの処理におけるアルゴリズムに対応する第１の工程の処理時間とから閾値を算出する。そして、実行サーバ１は、後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの処理の開始から閾値以上遅らせる。かかる構成によれば、実行サーバ１は、複数のアプリケーションの処理が異なるアルゴリズムを用いる場合であっても、第１の工程の重複実行による処理時間の増加を抑制することが可能となる。

ところで、実施例１では、実行サーバ１は、予めいずれかの推論プロセス１１の畳込み処理の処理時間を計測して閾値としてプロファイル情報１５に記録しておき、後続の推論プロセス１１の開始タイミングを遅らせる制御をこの閾値を読み込んで利用した。しかしながら、予め閾値を計測するＧＰＵと実際にＧＰＵ利用制御処理を実行するＧＰＵとが異なる場合がある。

そこで、実施例３では、予め閾値を計測するＧＰＵと実際に実行するＧＰＵとが異なる場合のＧＰＵ利用制御処理について説明する。

［ＧＰＵ利用制御部の機能構成］
図１５は、実施例３に係るＧＰＵ利用制御部の機能構成の一例を示す図である。なお、図３に示すＧＰＵ利用制御部と同一の構成については同一符号を示すことで、その重複する構成および動作の説明ついては省略する。実施例１と実施例３とが異なるところは、プロファイル情報１５をプロファイル情報１５Ｂに変更した点にある。また、実施例１と実施例３とが異なるところは、遅延実行判定部１２３、遅延待機中要求管理部１２４、利用要求送信部１２６、処理結果送信先判定部１２８をそれぞれ遅延実行判定部１２３Ｂ、遅延待機中要求管理部１２４Ｂ、利用要求送信部１２６Ｂ、処理結果送信先判定部１２８Ｂに変更した点にある。

プロファイル情報１５Ｂは、所定の閾値のほか、処理時間を記憶する。加えて、プロファイル情報１５Ｂは、推論プロセス１１ごとの係数を記憶する。閾値は、予め第１のＧＰＵを用いて畳込み処理の処理時間を計測して得られた値である。処理時間は、予め第１のＧＰＵを用いて推論プロセス１１を実行した場合の全体の実行時間である。係数は、予め第１のＧＰＵを用いて計測した際の全体の実行時間と、実際に第２のＧＰＵを用いて実行した際の実処理時間との比率である。なお、実処理時間および係数は、処理結果送信先判定部１２８Ｂによって計算される。

ここで、実施例３に係るプロファイル情報１５Ｂの一例を、図１６を参照して説明する。図１６は、実施例３に係るプロファイル情報の一例を示す図である。図１６に示すように、プロファイル情報１５Ｂには、閾値に加えて処理時間が設定される。また、プロファイル情報１５Ｂには、ＰＩＤと係数とが対応付けて設定される。ＰＩＤは、推論プロセス１１を実行した際のプロセスＩＤである。

一例として、閾値として「ｎｎ」が記憶されている。処理時間として「ｔ０」が記憶されている。なお、「ｎｎ」、「ｔ０」は、正の整数である。また、ＰＩＤが「ＰＩＤ＿Ａ」である場合には、係数として「係数Ａ」が記憶されている。

図１５に戻って、遅延実行判定部１２３Ｂは、ＧＰＵの利用要求がされた推論プロセス１１の実行までの遅延時間を判定する。例えば、遅延実行判定部１２３Ｂは、ＧＰＵの利用要求を蓄積する要求キュー１２５が空であるか否かを判定する。遅延実行判定部１２３Ｂは、要求キュー１２５が空である場合には、ＧＰＵを最終に利用した時刻（ＧＰＵ最終利用時刻）を取得する。遅延実行判定部１２３は、プロファイル情報１５Ｂから、閾値および推論プロセス１１のプロセスＩＤに対応する係数を取得する。遅延実行判定部１２３Ｂは、閾値に係数を乗じて得られた新たな閾値を計算する。遅延実行判定部１２３Ｂは、最終利用時刻に新たな閾値を加えた時刻から現在時刻を引いた時間を待機時間として計算する。そして、遅延実行判定部１２３Ｂは、待機時間が０より大きい場合には、ＧＰＵの利用要求を要求キュー１２５に蓄積するとともに、遅延待機中要求管理部１２４Ｂへ待機時間を設定する。また、遅延実行判定部１２３Ｂは、待機時間が０以下の場合には、ＧＰＵの利用要求を利用要求送信部１２６Ｂに対して依頼する。

また、遅延実行判定部１２３Ｂは、要求キュー１２５が空でない場合には、ＧＰＵの利用要求を要求キュー１２５に蓄積する。

なお、プロセスＩＤに対応する係数がプロファイル情報１５Ｂに設定されていない場合には、遅延実行判定部１２３Ｂは、ＧＰＵが空いていれば、ＧＰＵの利用要求の実行を利用要求送信部１２６Ｂへ依頼する。これは、ＧＰＵに負荷がかかっていないタイミングで対象の利用要求を実行させて実処理時間を計算させ、対象の利用要求を発行した推論プロセス１１のプロセスＩＤに対応する係数を計算させるためである。

遅延待機中要求管理部１２４Ｂは、遅延を待機しているＧＰＵの利用要求を管理する。例えば、遅延待機中要求管理部１２４Ｂは、遅延実行判定部１２３Ｂによって設定された待機時間だけ待機する。遅延待機中要求管理部１２４Ｂは、待機時間だけ待機すると、要求キュー１２５の先頭のＧＰＵの利用要求を利用要求送信部１２６Ｂに対して依頼する。そして、遅延待機中要求管理部１２４Ｂは、要求キュー１２５が空であるか否かを判定する。遅延待機中要求管理部１２４Ｂは、要求キュー１２５が空でない場合には、プロファイル情報１５Ｂから、閾値および要求キュー１２５に蓄積された先頭のプロセスＩＤに対応する係数を取得する。遅延待機中要求管理部１２４Ｂは、閾値に係数を乗じて得られた新たな閾値を待機時間に設定する。

なお、プロセスＩＤに対応する係数がプロファイル情報１５Ｂに設定されていない場合には、遅延待機中要求管理部１２４Ｂは、ＧＰＵが空いていれば、ＧＰＵの利用要求の実行を利用要求送信部１２６Ｂへ依頼する。これは、ＧＰＵに負荷がかかっていないタイミングで対象の利用要求を実行させて実処理時間を計算させ、対象の利用要求を発行した推論プロセス１１のプロセスＩＤに対応する係数を計算させるためである。

利用要求送信部１２６Ｂは、ＧＰＵの利用要求を、ＧＰＵドライバ１３を介してＡＩフレームワーク１４へ送信する。例えば、利用要求送信部１２６Ｂは、ＧＰＵを最終に利用した時刻（ＧＰＵ最終利用時刻）を現在時刻に更新する。そして、利用要求送信部１２６Ｂは、ＧＰＵの利用要求の依頼元のプロセスＩＤをＧＰＵ最終利用時刻に対応付けて記録する。そして、利用要求送信部１２６Ｂは、ＧＰＵの利用要求をＧＰＵドライバ１３へ送信する。そして、利用要求送信部１２６Ｂは、ＧＰＵの処理状態を「処理中」に記録する。

処理結果送信先判定部１２８Ｂは、処理結果の送信先を判定する。

例えば、処理結果送信先判定部１２８Ｂは、ＧＰＵの処理状態を、ＧＰＵが処理していないことを示す「空き」に記録する。処理結果送信先判定部１２８Ｂは、利用要求送信部１２６Ｂから、記録された、ＧＰＵ最終利用時刻に対応付けられた依頼元のプロセスＩＤを処理結果の送信先として取得する。そして、処理結果送信先判定部１２８Ｂは、処理結果送信部１２９を介して、依頼元のプロセスＩＤに対応する推論プロセス１１へ送信する。

また、処理結果送信先判定部１２８Ｂは、プロセスＩＤに対応する係数がプロファイル情報１５Ｂに設定されていない場合には、プロセスＩＤに対応する係数を計算する。一例として、処理結果送信先判定部１２８Ｂは、現在時刻から最終利用時刻を引いた実処理時間を計算する。そして、利用要求送信部１２６Ｂは、実処理時間を、プロファイル情報１５Ｂに設定された処理時間で割った値を係数として計算し、プロファイル情報１５Ｂに記録する。

［遅延実行判定処理のフローチャート］
図１７は、実施例３に係る遅延実行判定処理のフローチャートの一例を示す図である。図１７に示すように、利用検知部１２１は、ＧＰＵの利用要求を検知したか否かを判定する（ステップＳ９１）。ＧＰＵの利用要求を検知していないと判定した場合には（ステップＳ９１；Ｎｏ）、利用検知部１２１は、ＧＰＵの利用要求を検知するまで、判定処理を繰り返す。一方、ＧＰＵの利用要求を検知したと判定した場合には（ステップＳ９１；Ｙｅｓ）、利用検知部１２１は、要求送信元のプロセスＩＤ（ＰＩＤ）を取得する（ステップＳ９２）。

続いて、遅延実行判定部１２３Ｂは、待機中の利用要求を蓄積する要求キュー１２５が空であるか否かを判定する（ステップＳ９３）。要求キュー１２５が空であると判定した場合には（ステップＳ９３；Ｙｅｓ）、遅延実行判定部１２３Ｂは、記録されているＧＰＵ最終利用時刻を取得する（ステップＳ９４）。ＧＰＵ最終利用時刻は、ＧＰＵを最終に利用した時刻であり、具体的には直近でＧＰＵの利用要求を送信した時刻である。ＧＰＵ最終利用時刻は、利用要求送信部１２６Ｂによって記録される。

遅延実行判定部１２３Ｂは、プロファイル情報１５Ｂから閾値を取得する（ステップＳ９５）。遅延実行判定部１２３Ｂは、システム（ＯＳ）から現在時刻を取得する（ステップＳ９６）。遅延実行判定部１２３Ｂは、プロファイル情報１５ＢからＰＩＤに対応する係数を取得する（ステップＳ９７）。

遅延実行判定部１２３Ｂは、係数が空であるか否かを判定する（ステップＳ９８）。係数が空であると判定した場合には（ステップＳ９８；Ｙｅｓ）、遅延実行判定部１２３Ｂは、ＧＰＵの処理状態を取得する（ステップＳ９９）。そして、遅延実行判定部１２３Ｂは、処理状態が「処理中」であるか否かを判定する（ステップＳ１００）。処理状態が「処理中」でないと判定した場合には（ステップＳ１００；Ｎｏ）、遅延実行判定部１２３Ｂは、ＧＰＵ利用要求の送信を依頼すべく、ステップＳ１０２に移行する。これは、ＧＰＵに負荷がかかっていないタイミングで対象の利用要求を実行させて実処理時間を計算させ、対象の利用要求を発行した推論プロセス１１のプロセスＩＤに対応する係数を計算させるためである。

一方、処理状態が「処理中」であると判定した場合には（ステップＳ１００；Ｙｅｓ）、遅延実行判定部１２３Ｂは、要求キュー１２５にＧＰＵ利用要求情報、要求元プロセスＩＤを追加する（ステップＳ１０１）。かかる場合には、係数が設定されていないので、遅延実行判定部１２３Ｂは、待機時間を計算できず、遅延待機中要求管理部１２４Ｂに待機時間を設定しない。そして、遅延実行判定部１２３Ｂは、遅延実行判定処理を終了する。

ステップＳ９８において、係数が空でないと判定した場合には（ステップＳ９８；Ｎｏ）、遅延実行判定部１２３Ｂは、以下の式（４）から待機時間を計算する（ステップＳ１０３）。
待機時間＝（ＧＰＵ最終利用時刻＋閾値×係数）－現在時刻・・・（４）

そして、遅延実行判定部１２３Ｂは、待機時間が０より大きいか否かを判定する（ステップＳ１０４）。待機時間が０以下であると判定した場合には（ステップＳ１０４；Ｎｏ）、遅延実行判定部１２３Ｂは、ＧＰＵ利用要求で検知した要求とＰＩＤを利用要求送信部１２６Ｂへ出力して当該要求の送信を依頼する（ステップＳ１０２）。そして、遅延実行判定部１２３Ｂは、遅延実行判定処理を終了する。

一方、待機時間が０より大きいと判定した場合には（ステップＳ１０４；Ｙｅｓ）、遅延実行判定部１２３Ｂは、要求キュー１２５にＧＰＵ利用要求情報およびＰＩＤを追加する（ステップＳ１０５）。そして、遅延実行判定部１２３Ｂは、遅延待機中要求管理部１２４Ｂへ待機時間を設定する（ステップＳ１０６）。そして、遅延実行判定部１２３Ｂは、遅延実行判定処理を終了する。

また、ステップＳ９３において、要求キュー１２５が空でないと判定した場合には（ステップＳ９３；Ｎｏ）、遅延実行判定部１２３Ｂは、要求キュー１２５の末尾にＧＰＵ利用要求情報およびＰＩＤを追加する（ステップＳ１０７）。そして、遅延実行判定部１２３Ｂは、遅延実行判定処理を終了する。

［遅延待機中要求管理処理のフローチャート］
図１８は、実施例３に係る遅延待機中要求管理処理のフローチャートの一例を示す図である。図１８に示すように、図１８に示すように、遅延待機中要求管理部１２４Ｂは、待機時間が設定されたか否かを判定する（ステップＳ１１１）。待機時間が設定されていないと判定した場合には（ステップＳ１１１；Ｎｏ）、遅延待機中要求管理部１２４Ｂは、待機時間が設定されるまで、判定処理を繰り返す。

一方、待機時間が設定されていると判定した場合には（ステップＳ１１１；Ｙｅｓ）、遅延待機中要求管理部１２４Ｂは、設定された時間だけ待機する（ステップＳ１１２）。設定された時間だけ待機した後、遅延待機中要求管理部１２４Ｂは、要求キュー１２５の先頭の要求とＰＩＤを利用要求送信部１２６Ｂへ出力して当該要求の送信を依頼する（ステップＳ１１３）。

そして、遅延待機中要求管理部１２４Ｂは、要求キュー１２５が空であるか否かを判定する（ステップＳ１１４）。要求キュー１２５が空でないと判定した場合には（ステップＳ１１４；Ｎｏ）、遅延待機中要求管理部１２４Ｂは、プロファイル情報１５Ｂから閾値を取得する（ステップＳ１１５）。加えて、遅延待機中要求管理部１２４Ｂは、要求キュー１２５の先頭の要求におけるＰＩＤに対応する係数を取得する（ステップＳ１１６）。

そして、遅延待機中要求管理部１２４Ｂは、係数が空であるか否かを判定する（ステップＳ１１７）。係数が空でないと判定した場合には（ステップＳ１１７；Ｎｏ）、遅延待機中要求管理部１２４Ｂは、次の要求を待機させるべく、閾値に係数を乗じて得られる値を待機時間に設定する（ステップＳ１１７Ａ）。そして、遅延待機中要求管理部１２４Ｂは、ステップＳ１１２に移行する。

一方、係数が空であると判定した場合には（ステップＳ１１７；Ｙｅｓ）、遅延待機中要求管理部１２４Ｂは、ＧＰＵの処理状態を取得する（ステップＳ１１８Ａ）。遅延待機中要求管理部１２４Ｂは、処理状態が「処理中」であるか否かを判定する（ステップＳ１１８Ｂ）。処理状態が「処理中」であると判定した場合には（ステップＳ１１８Ｂ；Ｙｅｓ）、遅延待機中要求管理部１２４Ｂは、遅延待機中要求管理処理を終了する。

一方、処理状態が「処理中」でないと判定した場合には（ステップＳ１１８Ｂ；Ｎｏ）、遅延待機中要求管理部１２４Ｂは、要求キュー１２５の先頭の要求のＰＩＤを利用要求送信部１２６Ｂへ出力して当該要求の送信を依頼する（ステップＳ１１８Ｃ）。これは、ＧＰＵに負荷がかかっていないタイミングで対象の利用要求を実行させて実処理時間を計算させ、対象の利用要求を発行した推論プロセス１１のプロセスＩＤに対応する係数を計算させるためである。そして、遅延待機中要求管理部１２４Ｂは、遅延待機中要求管理処理を終了する。

ステップＳ１１４において、要求キュー１２５が空であると判定した場合には（ステップＳ１１４；Ｙｅｓ）、遅延待機中要求管理部１２４Ｂは、遅延待機中要求管理処理を終了する。

［利用要求送信処理のフローチャート］
次に、図１９は、実施例３に係る利用要求送信処理のフローチャートの一例を示す図である。図１９に示すように、利用要求送信部１２６Ｂは、ＧＰＵ利用要求の送信依頼があったか否かを判定する（ステップＳ１２１）。ＧＰＵ利用要求の送信依頼がなかったと判定した場合には（ステップＳ１２１；Ｎｏ）、利用要求送信部１２６Ｂは、送信依頼があるまで、判定処理を繰り返す。

一方、ＧＰＵ利用要求の送信依頼があったと判定した場合には（ステップＳ１２１；Ｙｅｓ）、利用要求送信部１２６Ｂは、システム（ＯＳ）から現在時刻を取得する（ステップＳ１２２）。そして、利用要求送信部１２６は、ＧＰＵ最終利用時刻を現在時刻に更新する（ステップＳ１２３）。利用要求送信部１２６Ｂは、ＧＰＵ最終利用時刻に対応付けて依頼元のＰＩＤを記録する（ステップＳ１２４）。

そして、利用要求送信部１２６Ｂは、ＧＰＵドライバ１３へＧＰＵ利用要求を送信する（ステップＳ１２５）。加えて、利用要求送信部１２６Ｂは、ＧＰＵの処理状態を「処理中」と記録する（ステップＳ１２６）。そして、利用要求送信部１２６Ｂは、利用要求送信処理を終了する。

［処理結果送信先判定処理のフローチャート］
図２０は、実施例３に係る処理結果送信先判定処理のフローチャートの一例を示す図である。図２０に示すように、処理結果送信先判定部１２８Ｂは、処理結果を受信したか否かを判定する（ステップＳ１３１）。処理結果を受信していないと判定した場合には（ステップＳ１３１；Ｎｏ）、処理結果送信先判定部１２８Ｂは、処理結果を受信するまで、判定処理を繰り返す。

一方、処理結果を受信したと判定した場合には（ステップＳ１３１；Ｙｅｓ）、処理結果送信先判定部１２８Ｂは、ＧＰＵの処理状態を「空き」と記録する（ステップＳ１３２）。そして、処理結果送信先判定部１２８Ｂは、利用要求送信部１２６Ｂから、記録された依頼元のＰＩＤを取得する（ステップＳ１３３）。そして、処理結果送信先判定部１２８Ｂは、プロファイル情報１５Ｂから取得したＰＩＤに対応する係数を取得する（ステップＳ１３４）。

続いて、処理結果送信先判定部１２８Ｂは、係数が空であるか否かを判定する（ステップＳ１３５）。係数が空であると判定した場合には（ステップＳ１３５；Ｙｅｓ）、処理結果送信先判定部１２８Ｂは、システム（ＯＳ）から現在時刻を取得する（ステップＳ１３６）。そして、処理結果送信先判定部１２８Ｂは、現在時刻からＧＰＵ最終利用時刻を引いて得られる値を実処理時間として算出する（ステップＳ１３７）。

さらに、処理結果送信先判定部１２８Ｂは、プロファイル情報１５Ｂから処理時間を取得する（ステップＳ１３８）。そして、処理結果送信先判定部１２８Ｂは、（実処理時間／処理時間）をＰＩＤに対応する係数としてプロファイル情報１５Ｂに記録する（ステップＳ１３９）。

処理結果送信先判定部１２８Ｂが、要求キューが空であるか否かを判定する（ステップＳ１４０）。要求キューが空であると判定した場合には（ステップＳ１４０；Ｙｅｓ）、処理結果送信先判定部１２８Ｂは、ステップＳ１４２に移行する。

一方、要求キューが空でないと判定した場合には（ステップＳ１４０；Ｎｏ）、処理結果送信先判定部１２８Ｂは、次の要求を即座に開始すべく、遅延待機中要求管理部１２４Ｂへ待機時間を０に設定する（ステップＳ１４１）。そして、処理結果送信先判定部１２８Ｂは、ステップＳ１４２に移行する。

ステップＳ１４２において、処理結果送信先判定部１２８Ｂは、取得したＰＩＤに対応するアプリケーション（推論プロセス１１）へ処理結果を送信する（ステップＳ１４２）。そして、処理結果送信先判定部１２８Ｂは、処理結果送信先判定処理を終了する。

［多重制御の用途］
図２１は、実施例１～３に係る多重制御の用途の一例を示す図である。図２１左に示すように、従来では、１台のＧＰＵが１台のカメラから転送される動画（映像）を処理していた。実施例１～３に係る多重制御では、図２１右に示すように、実行サーバ１は、１台のＧＰＵ２２が複数台のカメラから転送される動画（映像）を処理することができる。例えば、実行サーバ１は、複数の推論アプリ（推論プロセス）（１１）を近いタイミングで実行させる場合に、推論アプリ（１１）の中の、重複して実行すると処理時間への影響が大きい処理の処理時間を閾値として、後続の推論アプリ（１１）の開始を閾値以上遅延させる。これにより、実行サーバ１は、１台のＧＰＵ２２が複数の推論アプリ（１１）を多重で実行しても、処理の重複実行による処理時間の増加を抑制することが可能になる。

［実施例３の効果］
このようにして、上記実施例３では、実行サーバ１は、複数のアプリケーションの処理が同一のアルゴリズムを用いる場合に、第１のＧＰＵで第１の工程の処理時間を測定して得られる値を閾値とする。そして、実行サーバ１は、第１のＧＰＵで実行した場合のいずれかのアプリケーションの処理の総処理時間を、さらにプロファイル情報１５Ｂに記録する。実行サーバ１は、第１のＧＰＵと異なる第２のＧＰＵで実行する場合に、初回のアプリケーションの処理時に、他のアプリケーションの処理と重ならないように制御して、処理の総処理時間を測定する。実行サーバ１は、プロファイル情報１５Ｂに記憶された総処理時間と測定された総処理時間との比率を算出し、算出した比率を閾値に乗じた値を新たな閾値として用いる。かかる構成によれば、実行サーバ１は、実行するＧＰＵが変わった場合であっても、重複実行による処理時間の増加を抑制することができる。

［その他］
なお、実施例３では、実行サーバ１は、複数の推論プロセス１１が同一のアルゴリズムを用いる場合の多重制御について説明した。しかしながら、実行サーバ１が行う多重制御は、複数の推論プロセス１１が異なるアルゴリズムを用いる場合であっても良い。例えば、実行サーバ１は、複数のアプリケーションの処理が異なるアルゴリズムを用いる場合に、第１のＧＰＵで実行した場合のアルゴリズムごとのアプリケーションの処理の総処理時間を測定し、プロファイル情報１５Ｂに記録する。実行サーバ１は、第１のＧＰＵと異なる第２のＧＰＵで実行する場合に、初回のアプリケーションの処理時に、他のアプリケーションの処理と重ならないように制御して、アルゴリズムごとの処理の総処理時間を測定する。そして、実行サーバ１は、プロファイル情報１５Ｂに記憶されたアルゴリズムごとの総処理時間と測定されたアルゴリズムごとの総処理時間とからアルゴリズムごとの比率（係数）を算出し、算出したアルゴリズムごとの比率と閾値を用いて新たな閾値を算出する。そして、実行サーバ１は、アルゴリズムに応じた新たな閾値を用いて該当する推論プロセス１１の待機時間を求めれば良い。これにより、実行サーバ１は、複数の推論プロセス１１が異なるアルゴリズムを用いる場合に、実行する際のＧＰＵが変わった場合であっても、重複実行による処理時間の増加を抑制することができる。

また、図示した実行サーバ１に含まれるＧＰＵ利用制御部１２の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、読込部１２２と遅延実行判定部１２３とを１つの部として統合しても良い。また、遅延待機中要求管理部１２４を、ＧＰＵの利用要求を設定された待機時間だけ待機する待機部と、次のＧＰＵの利用要求の待機時間を計算し設定する設定部とに分散しても良い。また、プロファイル情報１５などを記憶する記憶部（図示しない）を実行サーバ１の外部装置としてネットワーク経由で接続するようにしても良い。

１ 実行サーバ
３ ストレージサーバ
５ カメラ
９ システム
１１ 推論プロセス
１２ ＧＰＵ利用制御部
１３ ＧＰＵドライバ
１４ ＡＩフレームワーク
１５、１５Ａ、１５Ｂ プロファイル情報
２１ ＣＰＵ
２２ ＧＰＵ
２３ メモリ
２４ ハードディスク
２５ ネットワークインターフェイス
２６ バス
３１ データソース
３２ 推論モデル
１２１ 利用検知部
１２２ 読込部
１２３、１２３Ａ、１２３Ｂ 遅延実行判定部
１２４、１２４Ａ、１２４Ｂ 遅延待機中要求管理部
１２５ 要求キュー
１２６、１２６Ｂ 利用要求送信部
１２７ 処理結果受信部
１２８、１２８Ｂ 処理結果送信先判定部
１２９ 処理結果送信部

Claims (10)

1. 複数のアプリケーションの処理を多重で実行させる場合に、前記複数のアプリケーションの処理の中で第１の工程の処理時間を閾値として記憶部に記録し、
   前記複数のアプリケーションのうちいずれかのアプリケーションの処理を実行中に、後続のアプリケーションから実行要求を受け付けると、前記後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの処理の開始から前記記憶部に記憶された閾値以上遅らせる
   処理をコンピュータに実行させることを特徴とする多重制御プログラム。
2. 前記記憶部に記憶された閾値以上遅らせる処理は、先行して実行中のアプリケーションの開始時刻に前記閾値を加えた値から前記後続のアプリケーションの実行要求のタイミングの時刻を差し引いた値以上遅らせる
   ことを特徴とする請求項１に記載の多重制御プログラム。
3. 前記複数のアプリケーションの処理が同一のアルゴリズムを用いる場合には、前記第１の工程の処理時間を測定した値を閾値とする
   ことを特徴とする請求項１に記載の多重制御プログラム。
4. 前記記録する処理は、複数のアプリケーションの処理が異なるアルゴリズムを用いる場合には、アルゴリズムごとに前記第１の工程と前記第１の工程より前の第２の工程の処理時間を前記記憶部に記録し、
   先行して実行中のアプリケーションの処理におけるアルゴリズムに対応する前記第１の工程の処理時間と前記第２の工程の処理時間と、後続のアプリケーションの処理におけるアルゴリズムに対応する前記第１の工程の処理時間とから、前記閾値を算出し、
   前記記憶部に記憶された閾値以上遅らせる処理は、前記後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの処理の開始から前記閾値以上遅らせる
   ことを特徴とする請求項１に記載の多重制御プログラム。
5. 前記記録する処理は、第１のＧＰＵで実行した場合のいずれかのアプリケーションの処理の総処理時間を、さらに前記記憶部に記録し、
   前記第１のＧＰＵと異なる第２のＧＰＵで実行する場合に、初回のアプリケーションの処理時に、他のアプリケーションの処理と重ならないように制御して、処理の総処理時間を測定し、
   前記記憶部に記憶された総処理時間と測定された総処理時間との比率を算出し、
   前記比率を前記閾値に乗じた値を新たな閾値として用いる
   ことを特徴とする請求項３に記載の多重制御プログラム。
6. 前記記録する処理は、第１のＧＰＵで実行した場合のアルゴリズムごとのアプリケーションの処理の総処理時間を、さらに前記記憶部に記録し、
   前記第１のＧＰＵと異なる第２のＧＰＵで実行する場合に、初回のアプリケーションの処理時に、他のアプリケーションの処理と重ならないように制御して、アルゴリズムごとの処理の総処理時間を測定し、
   前記算出する処理は、前記記憶部に記憶されたアルゴリズムごとの総処理時間と測定されたアルゴリズムごとの総処理時間とからアルゴリズムごとの比率を算出し、
   前記アルゴリズムごとの比率と前記閾値を用いて新たな閾値を算出する
   ことを特徴とする請求項４に記載の多重制御プログラム。
7. 前記第１の工程の処理は、前記アプリケーションが映像に関する推論アプリである場合には、畳込み処理である
   ことを特徴とする請求項１に記載の多重制御プログラム。
8. 前記複数のアプリケーションの処理は、ＧＰＵを使用した推論であることを特徴とする請求項１に記載の多重制御プログラム。
9. 複数のアプリケーションの処理を多重で実行させる場合に、前記複数のアプリケーションの処理の中で第１の工程の処理時間を閾値として記憶する記憶部と、
   前記複数のアプリケーションのうちいずれかのアプリケーションの処理を実行中に、後続のアプリケーションから実行要求を受け付けると、前記後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの処理の開始から前記記憶部に記憶された閾値以上遅らせる遅延待機部と、
   を有することを特徴とする情報処理装置。
10. 複数のアプリケーションの処理を多重で実行させる場合に、前記複数のアプリケーションの処理の中で第１の工程の処理時間を閾値として記憶部に記録し、
    前記複数のアプリケーションのうちいずれかのアプリケーションの処理を実行中に、後続のアプリケーションから実行要求を受け付けると、前記後続のアプリケーションの処理の開始を、先行して実行中のアプリケーションの処理の開始から前記記憶部に記憶された閾値以上遅らせる
    処理をコンピュータが実行することを特徴とする多重制御方法。

Images