WO2006126331A1

WO2006126331A1 - 情報処理方法、情報処理装置、およびサーバ

Info

Publication number: WO2006126331A1
Application number: PCT/JP2006/307323
Authority: WO
Inventors: Kenichi Murata; Tsutomu Horikawa
Original assignee: Sony Computer Entertainment Inc
Current assignee: Sony Interactive Entertainment Inc
Priority date: 2005-05-27
Filing date: 2006-04-06
Publication date: 2006-11-30
Anticipated expiration: 2007-11-27
Also published as: US8266621B2; US20080163228A1; JP4298679B2; JP2006331207A

Abstract

　図２において、メインプロセッサに含まれ、情報処理装置全体の制御やサブプロセッサへの複数のタスクの割り当てを行う管理プロセッサ３２において、ロード要求受付部６０は、新規ソフトウェアのロード要求をユーザより受け付ける。属性取得部６２は、新規ソフトウェアに付加された属性ファイルを読み込み、当該ソフトウェアのタスクの処理に必要な処理時間を検出する。状況取得部６４は、サブプロセッサへ割り当て済みのタスクに関するスケジュールファイルを読み込み、サブプロセッサの空き時間を導出する。判定部６６は新規ソフトウェアのタスク処理に必要な時間とサブプロセッサの空き時間を比較し、必要な時間が空き時間を超えない場合には、起動処理部６８が新規ソフトウェアのロードを完了させる。

Description

明細書

情報処理方法、情報処理装置、およびサーバ

技術分野

[0001] 本発明は情報処理技術に関し、特にオペレーティングシステムによって複数のタスク処理を制御する情報処理装置と、その装置における情報処理方法、およびその装置を支援するサーバに関する。

背景技術

[0002] 近年の著し、技術進歩に伴、、テレビ、コンピュータゲーム、ディジタルビデオ、電子メールなどを含む複数の機能を、一の装置で並行して実行することのできるコンビユータが広く一般に浸透しつつある。そのようなコンピュータの実現において根幹をなす技術的課題のひとつが処理の高速ィ匕である。処理の高速化は、コンピュータを構成する各モジュールにおける処理速度の向上以外に、それらのモジュールが供給する量的、時間的資源を効率的に使用することによってももたらされる。例えば演算処理を高速ィ匕するためにマルチプロセッサによる並列処理を行ったり、アプリケーションソフトウェアやユーティリティソフトウェアなどのソフトウェアが使用する関数をコンポ一ネントとして別に保持し、必要に応じてロードすることによって効率的な処理を行つたりする。

[0003] 上記のコンポーネントや、ソフトウェア本体、基本ソフトウェアであるオペレーティングシステム（以下、 OSと呼ぶ)などの技術開発は日々進拔しており、ユーザは自らのコンピュータの性能向上を求めて、それらを最新バージョンへと更新しようと望む。しかしながらソフトウェアは通常、ソフトウェア本体の他、コンポーネントや OS、および装置との協働によって実現されるものであるため、個々にバージョンアップを行うことによつて互換性がなくなり、ソフトウェアの動作に不具合が生じることがある。そこでコンポ一ネントにバージョン互換性を記述したファイルを付加しておき、互換性を別に管理することによってバージョンアップを効率ィ匕し、かつ不具合が発生しないようにする技術が提案されている (例えば特許文献 1参照)。

特許文献 1 :特開 2001— 331324号公報発明の開示

発明が解決しょうとする課題

[0004] 演算の並列処理など装置自体の進歩や、上述のような機能の分業などの工夫により可能となった複数のソフトウェアの並行処理においては、コンピュータに含まれるプロセッサ、メモリ、およびバスなどの資源を、複数のソフトウェアで共有する必要がある。このため、起動するソフトウェアの数が増加するほど、一のソフトウェアが占有できる資源が減少し、処理の順番待ちなどによって動作速度が低下する。しかし、ソフトゥヱァによってはある動作速度を確保できな、と、正常な動作を確保できな、場合があることを、本発明者は認識した。

[0005] 本発明はこのような課題に鑑みてなされたものであり、その目的は複数のソフトゥヱァを正常かつ効率的に動作させる技術の提供にある。

課題を解決するための手段

[0006] 本発明のある態様は情報処理方法に関する。この情報処理方法は、新規タスクの実行要求を受け付けるステップと、新規タスクの所要処理時間および新規タスクの処理における所要バス帯域の少なくとも一方を特定するステップと、複数のタスクに関する処理手順を表すスケジューラに予約された予約済みタスクと、新規タスクの所要処理時間とを合計した総所要処理時間と、それらのタスクを実行する装置が確保できる処理時間との比較、および、予約済みタスクと新規タスクの処理における所要バス帯域とを合計した総所要ノス帯域と、それらのタスクを実行する装置が確保できるバス帯域との比較、の少なくとも一方を行うステップと、比較結果に基づき新規タスクの実行可否を判定するステップと、新規タスクが実行可能と判定された場合、その新規タスクをスケジューラに予約するステップと、スケジューラに基づき実行可能と判定された新規タスクを含むタスクの処理を行うステップと、を含むことを特徴とする。ここで実行可否を判定するステップは、新規タスクの優先度情報を取得するステップを含み、取得した優先度情報に基づ!、て実行可否を判定する。

[0007] 「タスク」とは、ある目的を達成するためにプログラムされたアプリケーションまたはそれに含まれる情報処理の内容をいい、アプリケーションと対応してもよいし、入出力制御やユーザが指定したコマンドなどアプリケーションよりも小さい単位と対応してもよく、何らかの処理または機能の単位に対応すればよ!、。

[0008] 本発明の別の態様は情報処理装置に関する。この情報処理装置は、主に装置全体を統括的に制御する第一のプロセッサと、主に演算処理を行う第二のプロセッサと、処理するタスクに関する情報を記憶するメインメモリと、外部装置とのデータ入出力を制御するデータ入出力プロセッサと、を備える情報処理装置であって、第一のプロセッサは、新規タスクの実行要求を受け付ける実行要求受付け部と、新規タスクの処理に係る時間関連パラメータを特定するパラメータ特定部と、特定した時間関連パラメータと、情報処理装置の内部に係る情報のうち時間関連パラメータと対応する対応内部情報と、に基づき新規タスクの実行可否を判定する実行許可部と、新規タスクが実行可能と判定された場合、新規タスクの処理を起動する起動処理部と、を備え、時間関連パラメータは、第一のプロセッサとメインメモリ間のデータ転送において新規タスクが必要とするバス帯域、第一のプロセッサと第二のプロセッサ間のデータ転送にぉ、て新規タスクが必要とするバス帯域、および第一のプロセッサとデータ入出力プ口セッサ間のデータ転送において新規タスクが必要とするバス帯域のうち、少なくともひとつを含むことを特徴とする。

[0009] なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である

発明の効果

[0010] 本発明によれば、複数のタスクの正常な動作の保障を効率的に実現できる。

図面の簡単な説明

[0011] [図 1]実施の形態 1における情報処理装置の構成を示すブロック図である。

[図 2]実施の形態 1における管理プロセッサの構成を示すブロック図である。

[図 3]実施の形態 1における記憶装置の構成を模式的に示した図である。

[図 4]実施の形態 1における属性ファイルのデータ構造の例を示した図である。

[図 5]実施の形態 1において行われるソフトウェアのロード処理手順を示すフローチヤートである。

[図 6]実施の形態 1において行われるソフトウェアのロード処理手順を示すフローチヤートである。

[図 7]実施の形態 1において行われるソフトウェアのロード処理手順を示すフローチヤートである。

[図 8]実施の形態 1にお、てスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示した図である。

[図 9]実施の形態 2においてスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示した図である。

[図 10]実施の形態 2における属性ファイルのデータ構造の例を示した図である。

[図 11]実施の形態 2において行われるソフトウェアのロード処理手順を示すフローチヤートである。

[図 12]実施の形態 3における属性ファイルのデータ構造の例を示した図である。

[図 13]実施の形態 3において行われるソフトウェアのロード処理手順を示すフローチヤートである。

[図 14]実施の形態 4における属性ファイルのデータ構造の例を示した図である。

[図 15]実施の形態 4において行われるソフトウェアのロード処理手順を示すフローチヤートである。

[図 16]実施の形態 5における属性ファイルのデータ構造の例を示した図である。

[図 17]実施の形態 5におけるバス帯域予約ファイルのデータ構造の例を示した図である。

[図 18]実施の形態 5において行われるソフトウェアのロード処理手順を示すフローチヤートである。

[図 19]実施の形態 6における記憶装置の構成を模式的に示した図である。

[図 20]実施の形態 7におけるシステムの全体構成を示した図である。

[図 21]実施の形態 8におけるシステムの全体構成を示した図である。

符号の説明

30· ··サブプロセッサ、 32…管理プロセッサ、 40· ··ノス、 50· ··メインメモリ、 6 0…ロード要求受付部、 62· ··属性取得部、 64· ··状況取得部、 66· ··判定部、 6 8…起動処理部、 100· ··グラフィックプロセッサ、 200· ··メインプロセッサ、 600· ·· 記憶装置、 650…入出力プロセッサ、 700· "サーバ、 702…サーバ側情報処理部、 704…サーバ側記憶装置、 1000…情報処理装置。

発明を実施するための最良の形態

[0013] (実施の形態の概要）

複数のソフトウェアを同時に実行する情報処理装置においては、プロセッサによる処理時間やデータ転送に使用されるバス帯域などの有限な資源をいかに各ソフトゥアに割り振るかが重要な問題である。例えば、すでに複数のソフトウェアが動作している装置で、新たにソフトウェアを起動した場合、動作するソフトウェアで均等に処理時間やバス帯域を割り振れば、各ソフトウェアの動作は当然遅くなる。しかし、グラフィック処理などリアルタイム性を要求されるタスクを含むソフトウェアでは、一定以上の処理速度を確保できな、と正常な動作が保障されな、場合がある。本実施の形態では、処理速度に対し重要となる、プロセッサの占有時間（以後、処理時間と呼ぶ)やバス帯域を、タスクの起動時に確認することにより、起動するタスクおよび起動済みのタスクの、ずれにお、ても、ユーザの期待しな、動作速度での処理や不具合の発生を抑制する。より具体的には以下のような処理を行う。

[0014] 1.まず新規ソフトウエアの実行要求を受け付けた際、対応するタスク (以後、新規タスクと呼ぶ）が必要とする処理時間、または必要とするバス帯域の少なくとも一方を特定する。それらの値は、新規ソフトウェアのソースプログラムに付加されたり、ネットヮークを介してサーバより取得したりする属性ファイル中、処理時間属性、バス帯域属性にそれぞれ記述されている。さらに、すでに起動しているタスク（以後、予約済みタスクと呼ぶ）が必要とする処理時間、または必要とするバス帯域を特定する。それらの値は、メインメモリに格納したスケジュールファイル、バス帯域予約ファイルに、タスクごとに記述されている。続いて、新規タスクが必要とする処理時間と、予約済みタスクの処理時間から計算されるプロセッサの空き時間との比較、および新規タスクが必要とするバス帯域と、予約済みタスクの使用バス帯域力計算されるバス帯域の空きとの比較、の少なくとも一方を行い、新規タスクが処理時間、バス帯域の少なくともいずれかの観点から、実行可能かどうかを判定する。実行可能と判定された場合は、スケジュールファイル、バス帯域予約ファイルを更新し、新規タスクを起動させ、スケジュールファイルに基づき処理を行う。実行可否判断には各タスクの優先度を考慮してもよい。新規タスクの優先度は優先度属性としてソースプログラムなどに付加される。予約済みタスクの優先度は、メインメモリなどに格納した優先度ファイルに、タスクごと〖こ記述されている（実施の形態 1〜8)。

[0015] 2.新規タスクが必要とする処理時間がプロセッサの空き時間より大きい場合、または、必要とするバス帯域がバス帯域の空きより大きい場合、優先度に基づいて予約済みタスクの停止の可否も判定する（実施の形態 4、 5)。

[0016] 3.新規タスクが必要とするバス帯域がバス帯域の空きより大きい場合、優先度に基づ、て各タスクが使用するバス帯域を調整する（実施の形態 5)。

[0017] 4.新規タスクが実行不可と判定された場合は、当該タスクの実行要求を起こしたタスクに対し、その旨を通知する（実施の形態 1〜5)。

[0018] 5.新規タスクの実行不可や、予約済みタスクの停止が判定されたときは、装置を制御するメインプロセッサがそれを認識し、ユーザへその旨を通知する（実施の形態 1

〜5)。

[0019] (実施の形態 1)

図 1は、本実施の形態における情報処理装置 1000の構成を示すブロック図である。情報処理装置 1000は、グラフィックプロセッサ 100、メインプロセッサ 200、入出力プロセッサ 650、およびメインメモリ 50を含み、それらはバス 40によって相互に接続されている。入出力プロセッサ 650は、表示装置 500および記憶装置 600と接続されている。

[0020] 図 1において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウエア的には、 CPU、メモリ、その他の LSIで構成することができ、ソフトウェア的には、メモリにロードされた予約管理機能のあるプログラムなどによって実現される。したがつて、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによって、ろ、ろな形で実現できることは当業者には理解されるところであり、 Vヽずれかに限定されるものではな、。

[0021] この情報処理装置 1000では、情報処理装置 1000を効率よく使用するための機能、環境を提供し、装置全体を統括的に制御する OSが実行される。その OSによって情報処理装置 1000の各機能ブロックが動作することにより、複数のソフトウェアが実行される。

[0022] メインプロセッサ 200は、複数のサブプロセッサ 30と管理プロセッサ 32を含む。管理プロセッサ 32は、複数のソフトウェアに対応するタスクを時分割し、タイムスライスごとにサブプロセッサ 30に割り当て、それをメインメモリ 50に格納したスケジュールファィルに書き込む。さらにバス 40の帯域を、バス帯域予約ファイルをもとに複数のタスクに割り振り、ハードウェアとの協働により使用ノス帯域の制御を行う。サブプロセッサ 3 0は、スケジュールファイルに則りタスクの並列処理を行う。

[0023] グラフィックプロセッサ 100は、グラフィックメモリ 10および処理ユニット 12を含む。メインプロセッサ 200により処理されるそれぞれのタスクに関連する画像処理を処理ュニット 12が行い、生成された画像、映像はー且グラフィックメモリ 10に格納され、入出力プロセッサ 650の制御により表示装置 500または記憶装置 600に出力される。

[0024] メインメモリ 50は、主にメインプロセッサ 200によって使用される記憶領域である。このメインメモリ 50は、ロードされたソフトウェアのプログラムや、ソフトウェアに対応するタスクに関連するデータが格納される。また、予約済みタスクのスケジュールファイル、ノス帯域予約ファイル、優先度ファイルもメインメモリ 50に格納される。

[0025] 表示装置 500はメインプロセッサ 200およびグラフィックプロセッサ 100の処理の結果得られた画像、映像を出力する。記憶装置 600はハードディスク装置、 CD-RO M、 MO、半導体の記憶素子などの外部記憶装置のいずれか、またはそれらの組み合わせでよい。情報処理装置 1000は OSの制御のもと、記憶装置 600に記憶されたソフトウェアをメインメモリ 50に読み出すことにより、当該ソフトウェアのロードを行い、タスクの処理を実行する。入出力プロセッサ 650は表示装置 500や記憶装置 600と情報処理装置 1000との上述のようなデータの入出力を制御する。

[0026] なお図 1において、バス 40は簡単のために一の線で示されている力実際には複数のバスで構成してよぐ所定の機能ブロック間に専用バスを設けてよい。

[0027] 図 2は、本実施の形態における管理プロセッサ 32の構成を示すブロック図である。

管理プロセッサ 32は、ユーザが記憶装置 600に格納されたソフトウェアを情報処理装置 1000に認識させることによって行う、ソフトウェアのロード要求を受け付けるロード要求受付部 60と、ロード要求を受け付けた新規ソフトウェアの属性ファイルを記憶装置 600より読み出し、新規タスクの所要処理時間を取得する属性取得部 62と、スケジュールファイルをメインメモリ 50より読み出し、予約済みタスクの所要処理時間を取得する状況取得部 64と、新規タスクの所要処理時間とプロセッサの空き時間を比較し、新規タスクの処理を実行できる力否力判定する判定部 66と、実行可能と判定された新規ソフトウェアのプログラムを記憶装置 600より読み出し、メインメモリ 50へ格納し、新規タスクをサブプロセッサ 30に割り当て、スケジュールファイルを更新する起動処理部 68と、を含む。起動処理部 68は、新規ソフトウェアのロードが実行不可とされたときも、新規ソフトウェアを格納した記憶装置 600へロード要求拒否の信号を送信し、入出力プロセッサ 650を介して表示装置 500へロード不可の通知を表示するなどのロード不許可処理を行う。

[0028] 図 3は本実施の形態における記憶装置 600の構成を模式的に示している。本実施の形態では、属性ファイルがソフトウェア本体であるプログラムファイルや各種コンポ一ネントなどとともに記憶装置 600に格納される。

[0029] 図 4は本実施の形態における属性ファイルのデータ構造の例を示している。属性テ一ブル 70は、属性名称欄 70a、および必要値欄 70bを含む。ここでは、「処理時間」属性に対し、タスクの処理に必要な処理時間が必要値欄 70bに記述されている。図 4 における処理時間属性の必要値は、所定単位時間に対して当該タスクがサブプロセッサ 30を占有する時間の絶対値として表現されている力これについては後述する。処理時間の必要値はソフトウェアの出荷時にソフトウェアメーカによって設定される値であり、過負荷での検証実験などによって得られた値を採用する。

[0030] 属性は処理時間属性の他、実行許可属性やメモリ容量属性を含んでもよ!、。実行許可属性は例えば、ドンダルの接続やシリアルナンバーの入力など、実行に必要な条件を、メモリ容量属性はタスクの処理に必要なメモリ容量を表す。

[0031] 次に上述した構成による動作を説明する。図 5、図 6および図 7は、主に管理プロセッサ 32によって行われるソフトウェアのロードに係る処理手順を示す。まず図 5において、ユーザはゲームなど所望の新規ソフトウェアを記憶した CD— ROMを情報処理装置 1000に接続された読み取り装置へ挿入するなどして、情報処理装置 1000〖こ対し新規ソフトウェアのロード要求を行、、管理プロセッサ 32のロード要求受付部 60 はそれを受信する（S 10)。なお、新規ソフトウェアが格納された記憶装置 600は、 C D— ROMに限られず、ハードディスク装置、 MO、半導体の記憶素子などの記憶装置でもよい。さらに、図示しないネットワークに接続されたサーバから、所望の新規ソフトウェアを情報処理装置 1000にダウンロードするように要求する構成としてもよい。ここでは記憶装置 600として CD— ROMを例に説明する。

[0032] ロード要求受付部 60がロード要求を受け付けると、属性取得部 62は、新規ソフトゥエアの CD— ROMに記憶された属性ファイルに含まれる、実行許可属性やメモリ容量属性など一般的な属性を取得する。次、で状況取得部 64がそれぞれの属性の実態を確認し、判定部 66がそれぞれの属性の条件を実態が満足して、るかを判定する（S12)。条件を満たしていないと判定された場合は（SI 2の N)、起動処理部 68が上述のロード不許可処理を行い（S 14)、シーケンスを終了する。

[0033] 一方、条件を満たしていると判定された場合 (S 12の Y)、図 6示すように、属性取得部 62は属性ファイル内の処理時間属性を検出し、必要値を読み込む（S30)。次いで状況取得部 64はスケジュールファイルをメインメモリ 50より読み込み、予約済みタスクの割り当て状況力もサブプロセッサ 30の空き時間を導出する（S32)。そして判定部 66は、処理時間の必要値と、サブプロセッサ 30の空き時間とを比較する（S34)。比較の結果、処理時間の必要値がサブプロセッサ 30の空き時間を上回っていると判定された場合は（S34の N)、起動処理部 68がロード不許可処理を行い（S37)、シ一ケンスを終了する。

[0034] 一方、処理時間の必要値がサブプロセッサ 30の空き時間を超えないと判定された場合は（S34の Y)、図 7のごとぐ起動処理部 68により新規ソフトウェアの本体を CD —ROMからメインメモリ 50へ読み出し、ロードを完了する（S38)。さらに起動処理部 68は、新規タスクを時分割し、タイムスライスごとにサブプロセッサ 30に割り当て、メインメモリ 50に格納されたスケジュールファイルを更新する（S40)。これにより、上述のとおりサブプロセッサ 30による新規タスクの処理が開始される。

[0035] 次に処理時間属性について説明する。図 8は本実施の形態におけるスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示している。同図は、 2つの予約済みソフトウェア、ソフトウェア Aおよびソフトウェア Bにそれぞれ対応するタスク Aおよびタスク Bが時分割され、あら力じめ設定された単位期間においてそれらのタスクが順番に処理されるように複数のサブプロセッサ 30a〜30dに割り当てられた様子を示している。この単位期間内の処理を繰り返すことにより、タスク A、タスク Bの実行が進拔する。

[0036] 本実施の形態において S30で読み込まれる処理時間属性の必要値は、この単位期間のうち、タスクが必要とする処理時間の絶対値で表現する。図 8の例では、ソフトウェア Aおよびソフトウェア Bの処理時間属性の必要値はそれぞれ単位期間の 20% 、および 40%であるから、単位期間が例えば 16. 6msであるとすると、 3. 3ms、 6. 6 msと記述されて、ることになる。そしてそれらのソフトウェアが実行可能と判定され口ードされたときに、 S40にてスケジュールファイルにそれらの値が書き込まれ、各サブプロセッサ 30によってタスクの処理がなされる。

[0037] ここでユーザが、処理時間属性の必要値が単位期間の 50%である新規ソフトゥェァ Cのロード要求を行ったとする。図 8で示された予約済みソフトウェア Aおよび Bの占有割合の合計が 60%であるため、状況取得部 64が S32で導出するサブプロセッサ 30の空き時間は割合にして 40%である。したがって判定部 66は S34において、ソフトウェア Cの処理時間属性の必要値がサブプロセッサ 30の空き時間を上回っていると判定し、ソフトウェア Cのロードは行われない。一方、ソフトウェア Cの処理時間属性の必要値が単位期間の 30%を示して、た場合は、サブプロセッサ 30の空き時間を超えな、と判定され、ソフトウェア Cがロードされる。

[0038] 上述の場合、管理プロセッサ 32の処理を制御する OSにおいてあらかじめ単位期間を設定しておき、各ソフトウェアは同一の単位期間に対してそれぞれのタスクに必要な処理時間の絶対値を処理時間属性の必要値として保持する。単位期間としては例えば、表示装置 500の垂直同期信号の周期を設定する。

[0039] ソフトウェアがコンピュータゲームなど、 3次元グラフィックス処理を伴う場合、サブプ口セッサ 30とグラフィックプロセッサ 100との協働によって生成されたフレームデータは、グラフィックメモリ 10に格納され、表示装置 500に表示される。表示装置 500にお V、て、あるフレームの表示終了力次のフレームの表示終了までに力かる時間が垂直同期信号の周期であるから、動きのある画像を滞りなく表示しソフトウェアを正常に動作させるためには、所望の解像度や動作速度などに応じて、ソフトウェアごとに垂直同期信号の周期内で確保しなければならない処理時間が決まってくる。したがつて処理時間属性の必要値を垂直同期信号の周期を単位に設定することにより、ソフトウェアの動作保障のための設定が容易になる。

[0040] 本実施の形態では、処理時間属性をソフトウェアごとに保持することによって、ユーザがロード要求を行ったソフトウェアの動作環境を前もって把握し、正常な動作を保障できる場合に限りロードを行う。これにより、ロードを行ったにも関わらずソフトウェアがユーザの期待通りの動作をしな、などの不具合を未然に防ぐことができる。また予約済みソフトウェアのタスク処理時間を最低限確保できる力確認して力新規ソフトゥエアのロードを行うため、新規ソフトウェアのロードによってすでに起動しているソフトゥアの動作に支障をきたすことがなくなる。さらに必要な処理時間が比較的短ぐ時間的制限の軽微なソフトウェアに対して、グラフィック処理などを含みリアルタイム性を要求されるソフトウェアに選択的に多くのタイムスライスを確保することによって、有限なプロセッサ資源の効率的な使用が可能となり、ユーザのニーズへ対応する余地が広がる。

[0041] 上述の形態では、垂直同期信号の周期をソフトウェアに共通の単位期間とし、その単位期間に対する処理時間の絶対値をもって処理時間属性の必要値としたが、単位期間は、垂直同期信号の周期の倍数などでもよい。すなわち処理時間属性の必要値は、ある単位期間におけるタスク処理に必要な時間であればよい。または、ある単位期間に対するタスク処理に必要な時間の割合でもよい。さらに単位期間は、ソフトウエアに共通でなくてもよい。例えば、基準となる単位期間の値および、その期間中に必要な処理時間、の 2値を処理時間属性とし、ソフトウェアごとに設定してもよい。そのほか、ある時刻と、それまでに必要な処理時間の絶対値、の 2値を処理時間属性としてもよい。これらの処理時間属性の形式を混在させる場合は、処理時間属性にさらに記述形式を識別する識別子を付加し、管理プロセッサ 32を制御する OSによつて識別するようにする。そして判定部 66は、識別子に基づき各ソフトウェアに付加された処理時間属性の形式をスケジュールファイルの形式に即した値に変換してから、タスクに必要な処理時間とサブプロセッサ 30の空き時間とを比較するようにしてもよい。この場合、ソフトウェアの内容に適した形式で処理時間属性を表現できるため、正常な動作の保障を確実ィ匕できるとともに、 OSの種類やバージョンアップなどによつてスケジュールファイルの形式が変化しても、ソフトウェアの属性ファイルを書き変えることなく本実施の形態を適用することができる。

[0042] (実施の形態 2)

本実施の形態は、実施の形態 1における図 1で示した情報処理装置 1000および、図 2で示した管理プロセッサ 32と同様の構成で実施することができる。ここでは主に、実施の形態 1との相違点に着目し、説明する。

[0043] 実施の形態 1では処理時間属性として処理時間の必要値のみを設定した。これにより新規タスクを含む各タスクは、全サブプロセッサ 30を必要値に示された処理時間で占有した。すなわち、メインプロセッサ 200が同時に処理するのはひとつのタスクとなっていた。本実施の形態では処理時間属性として、処理時間の必要値に加えサブプロセッサの必要個数を設定し、同時に複数のタスクを処理するようなスケジユーリングに対応させる。

[0044] 図 9は本実施の形態におけるスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示して、る。本実施の形態では処理時間属性としてサブプロセッサ 30の必要個数および、それらのサブプロセッサ 30によって処理した際に必要となる処理時間とを設定できることから、同時に複数のタスクを処理することが可能となる。図 9の例では、 3つのタスク、タスク A、タスク B、およびタスク Cがスケジューリングされて、るが、タスク Cのように長時間のシリアル処理が必要なタスクを処理する場合などに、効率の良い処理を行うことのできるサブプロセッサ 30の割り当てが可能であり、本実施の形態での処理時間属性の設定はこのようなスケジューリング手法に対応する。

[0045] 図 10は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル 71は、実施の形態 1と同様、属性名称欄 71aおよび必要値欄 71bを含む。本実施の形態では、必要値欄 71bにはサブプロセッサの必要個数および処理時間の必要値の 2値が記載される。 [0046] 次に本実施の形態において主に管理プロセッサ 32によって行われる処理について説明する。新規ソフトウェアのロード要求受け付けから、一般的な属性に係る処理は、実施の形態 1における図 5と同様の処理を行う。図 11は、一般的な属性について実行可能の判定がなされたら（S12の Y)、それに引き続き行われる、処理時間属性に係る処理手順を示して！/、る。

[0047] まず実施の形態 1と同様、属性ファイル内の処理時間属性を検出し、必要値を読み込み（S30)、スケジュールファイルに記載された予約済みタスクの割り当て状況からサブプロセッサ 30の空き時間を導出する（S32)。そして処理時間の必要値とサブプ口セッサ 30の空き時間との比較を行う（S34)。但し、本実施の形態における「必要値」は上述の 2値であり、「空き時間」は、上述のとおり必要個数分のサブプロセッサが同時期に有する空き時間である。

[0048] 必要な処理時間がサブプロセッサ 30の空き時間を上回って、ると判定された場合 ( S34の N)、本実施の形態では、スケジュールファイルに記載された予約済みタスクの割り当てスケジュールにつ、て仮調整を行、 (S35)、再度処理時間の必要値とサブプロセッサ 30の空き時間との比較を行う（S36)。ここで行われるスケジュールの仮調整は、実際のタスク処理とは独立に、計算のみで行う思考実験的な処理である。処理時間の必要値がサブプロセッサ 30の空き時間を超えな、と判定された場合は（S3 4の Y、 S36の Υ)、実施の形態 1の図 7のごとぐ起動処理部 68はロードの完了（S38 )およびスケジュールファイルの更新（S40)を行う。このとき、スケジュールの仮調整を行ってロードが許可された場合は、その仮調整の内容も反映させる。スケジュールの仮調整を行っても十分な空き時間を確保できな、場合は (S36の Ν)、実施の形態 1と同様に、新規ソフトウェアのロード不許可処理を行い（S37)、シーケンスを終了する。

[0049] 図 9に示した割り当て状況を例に、図 11の手順を説明すると次のようになる。例えばユーザがロードを要求した新規ソフトウェアの処理時間属性として、サブプロセッサ

30の必要個数が 3個、処理時間の必要値が単位期間の 20%に相当する値であった場合、タスク Bが終了した時点以降、 3つのサブプロセッサ 30a、 30bおよび 30cに、単位期間に対する割合にして 40%の空き時間が確保できるため、 S34において空き時間は十分であると判定される。一方、サブプロセッサ 30の必要個数が 1個で、処理時間の必要値が単位期間の 90%に相当する値である場合は、最も空き時間の長ヽサブプロセッサ 30cにおいても、その空き時間が単位期間の 80%であるため、 S34 において処理時間の必要値が空き時間を上回ると判定される。そこで S35においてタスク Cの処理を、サブプロセッサ 30cのタスク Aの処理後に行うようにスケジュールの仮調整を行う。するとサブプロセッサ 30dの空き時間が単位期間の 100%となるため、 S36において処理時間の必要値が空き時間を超えないと判定され、当該新規ソフトウエアのロードが許可される。

[0050] 本実施の形態によれば、実施の形態 1と同様、ロード要求がなされたソフトウェアの動作環境を把握し、正常な動作を保障できる場合に限りロードを行うため、新規ソフトウェアや予約済みソフトウェアの動作不具合の発生を防止できる。さらに、短期間のノレル処理を必要とするタスク、長期間のシリアル処理を必要とするタスクなど、個々のタスクの処理態様を時間処理属性としてあらかじめ取得することにより、処理時間の割り当てのみならず、サブプロセッサ 30の割り当てに対して自由度を有するスケジユーリングに対応させることができ、より柔軟なロード許可判定を行うことができる。これにより上述した効果を、より効率的な資源の使用とともに得ることができ、ユーザのニーズに対応する余地が広がる。

[0051] (実施の形態 3)

本実施の形態は、実施の形態 1における図 1で示した情報処理装置 1000および、図 2で示した管理プロセッサ 32と同様の構成で実施することができる。ここでは主に、実施の形態 1および 2との相違点に着目し、説明する。

[0052] 実施の形態 1および 2では新規ソフトウェアのロード要求に対し、属性ファイル内の処理時間属性を取得した。本実施の形態ではさらにバス帯域属性を取得する。そして、予約済みタスクのバス帯域の予約状況を記載したバス帯域予約ファイルに基づき、新規ソフトウェアの実行可否判定を行う。

[0053] 図 12は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル 72は、属性名称欄 72a、必要値欄 72bおよび、識別子欄 72cを含む。ここでは、「処理時間」属性に対し、タスクの処理に必要なサブプロセッサ 30の個数および処理時間力「バス帯域」属性に対し、タスク処理中のデータ転送に必要なバス帯域の割合力必要値欄 72bに記述されている。必要なバス帯域の割合は、情報処理装置 1000に設けられたバス 40の帯域に対して必要とされる割合である。必要なバス帯域の割合に代わり、必要なバス帯域の絶対値や、必要なデータ転送速度で表してもよい。必要なデータ転送速度から、情報処理装置 1000が有するクロック周波数特性を用いて、必要なノス帯域を算出できる。

[0054] データを転送する区間によって専用のバスが設けられるなどバス帯域が異なったり、各タスクが必要とする転送速度が異なったりするため、バス帯域の必要値は複数設定できるようにする。特にメインメモリ 50とメインプロセッサ 200との間のデータ転送、グラフィックプロセッサ 100とメインプロセッサ 200との間の転送、およびメインプロセッサ 200と入出力プロセッサ 650との間の転送は、タスクの処理速度に大きく影響するため、本実施の形態ではそれらの区間において必要なバス帯域の割合を、バス帯域の必要値とする。このため、各必要値に対応するバス 40の区間を識別するための識別子が識別子欄 72cに記載される。図 12の例では、「mem」はメインメモリ 50とメインプロセッサ 200との間、「gra」はグラフィックプロセッサ 100とメインプロセッサ 200との間、「io」はメインプロセッサ 200と入出力プロセッサ 650との間のバス 40をそれぞれ表している。バス帯域の必要値も処理時間属性と同様、過負荷での検証実験などによって得られた値を設定する。

[0055] 次に本実施の形態において主に管理プロセッサ 32によって行われる処理について説明する。新規ソフトウエアのロード要求受け付けから、処理時間属性に係る処理は、実施の形態 1における図 5、および実施の形態 2における図 11と同様の処理を行う。図 13は、処理時間属性について実行可能の判定がなされたら（S34の Y、 S36の Υ)、それに引き続き行われる、バス帯域属性に係る処理手順を示している。

[0056] まず属性取得部 62は属性ファイル内のバス帯域属性を検出し、必要値および識別子を全て読み込む（S42)。次いで状況取得部 64は、バス帯域予約ファイルをメインメモリ 50より取得し、同時に処理が行われる予約済みタスクが予約したバス帯域の合計から、新規タスクのために確保できるバス帯域の時間変化を識別子で識別されたバスの区間ごとに導出する（S44)。バス帯域予約ファイルは、予約済みソフトウェアをロードした際に読み込んだ、バス帯域属性の必要値および識別子を記載したファィルである。一方、あら力じめ算出した確保できるバス帯域の時間変化を別のフアイルとしてメインメモリ 50に格納しておき、ソフトウェアをロード、もしくはアンロードする都度、当該パラメータを計算し直してファイルを更新するようにしてもよい。この場合上述した S44のステップは、当該ファイルを参照するのみでよ！/、。

[0057] そして判定部 66は、新規ソフトウェアのバス帯域属性内の必要値をバスの区間ごとに、確保できるバス帯域と比較する（S46)。予約済みタスクの処理スケジュールに応じて、確保できるバス帯域は時間依存の変数となるため、 S46の処理は実際には、新規タスクに必要な処理時間とバス帯域の双方に基づき比較を行う。新規タスクに必要なノス帯域力バスの区間のいずれかにおいて、確保できるバス帯域を上回っていると判定された場合 (S46の N)、まずスケジュールファイルに記載された予約済みタスクの割り当てスケジュールについて、実施の形態 2と同様の調整を行い（S47)、再度バス帯域属性の必要値と確保できるバス帯域との比較を行う（S48)。スケジュールを調整してもなお、十分なノス帯域を確保できない場合は (S48の N)、新規タスクが必要とするバス帯域を確保できない旨の通知を表示装置 500に表示し、ロード処理を続行するかどうかをユーザへ確認する（S49)。

[0058] ユーザがロードのキャンセルを選択した場合（S49の N)、起動処理部 68が実施の形態 1で述べたロード不許可処理を行い（S50)、シーケンスを終了する。一方、新規タスクに必要なノス帯域が確保できるバス帯域をどの時間においても超えないようにスケジューリングできると判定された場合（S46の Y、 S48の Υ)または、必要なバス帯域が確保できるバス帯域を超えて!/、てもユーザがロードの続行を希望した場合 (S49 の Υ)、図 7のごとぐ起動処理部 68はロードの完了（S38)およびスケジュールフアイルの更新（S40)を行う。このとき、スケジュールの仮調整を行ってロードが許可された場合は、その仮調整の内容も反映させる。 S40ではさらに、バス帯域予約ファイルに、ロードしたソフトウェアのタスクが使用できるバス帯域を書きこむ。ここで、必要なバス帯域が確保できるバス帯域を超えない場合は（S46の Υ)、その必要なバス帯域が書きこまれ、必要なノス帯域が確保できるバス帯域を上回り（S46の Ν)、ユーザの選択により（S49の Υ)ロードされた新規ソフトウェアについては、 S44で取得した確保できるバス帯域を書き込み、予約する。確保できるバス帯域が時間によって変化する場合は、その最小値を使用できるバス帯域としてもよいし、時間変化をそのまま反映した形で予約してもよい。これにより、必要なバス帯域が確保できた場合は望ましいバス帯域を使用し、必要なバス帯域が確保できな力た場合は最大限使用できるバス帯域を利用して、新規タスクの処理がなされる。

[0059] ここで再度、図 9に示した割り当て状況を例にとり、図 13の手順を説明すると次のようになる。ある転送区間において、図 9に示された 3つの予約済みタスク A、タスク Bおよびタスク Cは、それぞれ 60%、 40%および 40%のバス帯域を予約しているとする。さらに、ユーザがロードを要求した新規ソフトウェアの処理時間属性は、サブプロセッサ 30の必要個数が 3個、処理時間の必要値が単位期間の 20%、バス帯域属性は必要値が 80%であったとする。この場合、図 11の処理時間属性に係る処理では、実施の形態 2で説明したように、 3つのサブプロセッサ 30a、 30bおよび 30cにおいて、タスク Bが終了した時点以降、十分な空き時間があるため、例えばタスク Bが終了した直後の 3つのサブプロセッサ 30a、 30bおよび 30cに新規タスクを割り当てることにより新規ソフトウェアは実行可能との判定がなされる。し力しながら、このような割り当てを行つた場合、新規タスクの開始時にはサブプロセッサ 30dによってバス帯域の必要値が 40%であるタスク Cの処理がなされているため、確保できるバス帯域は 60%であり、バス帯域属性に係る判定、すなわち図 13の S46で、必要なバス帯域 80%が確保できるバス帯域を超えていると判定される。

[0060] そこで S47において、タスク Cの処理が終了した後の 4つのサブプロセッサ 30a、 30 b、 30cおよび 30dのうちのいずれ力 3つに新規タスクを割り当てるようにスケジュールの仮調整を行う。タスク Cの処理の終了後は予約済みタスクの処理は行われないため、確保できるノス帯域は 100%となり、 S48において必要なバス帯域が確保できるバス帯域を超えないと判定され、当該新規ソフトウェアのロードが許可される。この例では、新規タスクに対してのみスケジュールの仮調整を行った力実施の形態 2と同様、新規タスクが処理時間とバス帯域の双方に対して必要値を満足するように、予約済みタスクのスケジュール仮調整を同時に行ってもょ、。あるいは予約済みタスクのみスケジュール仮調整を行ってもよ、。 [0061] 上述の例におけるタスク Aとタスク Cのように、メインプロセッサ 200において同時に処理されるタスクのバス帯域の必要値の合計が 100%である場合には、それぞれが使用するバス帯域が予約した値を超えないようにハードウェアによって制御を行う。これにより、本実施の形態によってー且ロードの許可がなされ、バス帯域の必要値を予約できたソフトウェアは、他にどのようなソフトウェアが実行されようとも、その必要値を最低限確保できることになる。一方タスク Bとタスク Cのように、バス帯域の必要値の合計が 100%未満であった場合は、ハードウェア制御により余ったバス帯域を適宜両タスクに割り振ることにより、より効率のよい資源の使用が可能となる。

[0062] 例えばコンピュータゲームなど、 3次元グラフィックス処理を伴うソフトウェアを実行する場合、図 1に示した情報処理装置 1000において、メインプロセッサ 200が処理するタスクに含まれる画像処理はグラフィックプロセッサ 100が行、、画像処理に係る情報はメインメモリ 50に格納される。したがってフレームデータを生成し、滞りなく表示装置 500に表示することによりゲームのリアルタイム性を確保するためには、各プロセッサの処理速度とともにメインプロセッサ 200とメインメモリ 50間や、メインプロセッサ 2 00とグラフィックプロセッサ 100間の画像処理に係るデータの転送速度が重要な要素となる。すなわちフレームデータの生成に際し、それに必要なデータの転送が間に合わなければ、結果的に表示装置 500に表示されるフレームレートに影響を与えることになる。したがって本実施の形態では、望ましい解像度や動作速度で動画を表現するために最低限必要とされるバス帯域をバス帯域属性としてソフトウエアごとに保持する。これにより、実施の形態 1および 2と同様、新規ソフトウェアの動作環境をロード前に把握することができ、ロードを行ったにも関わらずソフトウェアがユーザの期待通りの動作をしないなどの不具合を未然に防ぐことができる。

[0063] 一方、本実施の形態では、新規タスクが必要とするバス帯域が確保できるバス帯域を超えて、てもロードする可能性が残されて、る。これはもし望まし!/、バス帯域が得られなくても、遅い速度での進行をユーザが許容する場合が考えられるためである。したがって S49のユーザ確認処理では、動作速度が低下する可能性がある旨の警告を表示するようにしてもょ、。

[0064] 本実施の形態によれば、上述のとおり新規ソフトウェアの動作にユーザが期待しない不具合が生じるのをロード前に防止することができるとともに、すでに実行されているソフトウェアのタスクに必要なバス帯域も必ず確保されるため、新規ソフトウェアが口ードされることによってそれらのソフトウェアの動作に支障をきたすことがなくなる。さらにデータ転送量が小さい、または、時間的制限の軽微なタスクに対して、グラフィック処理などを含みリアルタイム性を要求されるタスクに選択的に多くのバス帯域を確保することによって、有限なプロセッサ資源の効率的な使用が可能となり、ユーザの- ーズに適合した処理を行うことができる。本実施の形態では実施の形態 1および 2と同様に、処理時間属性の確認も行われるため、処理時間およびバス帯域の両側面力もの確認およびタスクの選択ができ、また個々のタスクの処理態様に応じたスケジユーリングに対応するため、より効果的な資源使用、および正常な動作保障を行うことがでさる。

[0065] (実施の形態 4)

[0066] 実施の形態 1および 2では新規ソフトウェアのロード要求に対し、属性ファイル内の処理時間属性を取得した。本実施の形態ではさらに優先度属性を取得する。そして、予約済みタスクの優先度を記載した優先度ファイルに基づき、新規ソフトウェアの実行可否判定を行うが、この場合はさらに、予約済みソフトウェアをも実行可否判定の対象とする。

[0067] 図 14は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル 74は、実施の形態 1と同様、属性名称欄 74aおよび必要値欄 74bを含む。ここでは、「処理時間」属性に対し、タスクの処理に必要なサブプ口セッサ 30の個数および処理時間力「優先度」属性に対し、タスクの優先度力それぞれ必要値欄 74bに記載される。

[0068] 優先度は、新規タスクと予約済みタスク間、または予約済みタスクどうしで比較される相対値であり、例えば 1から 5までの 5段階の自然数によって表現する。図 14の例では 5段階のうち「4」の優先度を有している。優先度は、ソフトウェアの出荷時に内容に応じて設定される。

[0069] 次に本実施の形態において主に管理プロセッサ 32によって行われる処理について説明する。新規ソフトウェアのロード要求受け付けから、一般的な属性に係る処理は、実施の形態 1における図 5と同様の処理を行う。図 15は、一般的な属性について実行可能の判定がなされたら (S12の Y)、それに引き続き行われる、処理時間属性および優先度属性に係る処理手順を示してヽる。

[0070] まず実施の形態 2と同様、属性ファイル内の処理時間属性を検出し、必要値を読み込み（S30)、スケジュールファイルに記載された予約済みタスクの割り当て状況からサブプロセッサ 30の空き時間を導出する（S32)。そして処理時間の必要値とサブプ口セッサ 30の空き時間との比較を行う（S34)。当初の予約済みタスクのスケジュールでは十分な空き時間が確保できない場合は、実施の形態 2と同様、スケジュールの仮調整を行ったうえで再度比較を行うが、図の簡単のため、図 15においてはそれらの処理も S34に含めるものとする。

[0071] 本実施の形態では、必要な処理時間がサブプロセッサ 30の空き時間を上回っていると判定された場合 (S34の N)、属性取得部 62が、属性ファイル内の優先度属性を検出し読み込む（S56)。次いで状況取得部 64は優先度ファイルをメインメモリ 50より取得し、予約済みタスクの優先度を全て特定する（S58)。優先度ファイルは、予約済みソフトウェアをロードした際に読み込んだ優先度データを蓄積したファイルである。

[0072] そして判定部 66は、新規タスクの優先度と、予約済みタスクの優先度を比較する（S 60)。新規タスクの優先度より低い優先度の予約済みタスク（以後、低優先度タスクと呼ぶ）が存在する場合（S60の Y)、そのうちのひとつを例えばタスクの優先度に基づいて抽出し、抽出された低優先度タスクの処理予約を仮に取り消した場合 (S64)の、サブプロセッサ 30の仮の空き時間を算出する（S32)。そして判定部 66が新規タスクに必要な処理時間と仮の空き時間とを比較する（S34)。この場合も仮の空き時間が足りない場合は、残りの予約済みタスクに対してスケジュールの仮調整を行ったうえで再度比較をする処理を含めてよい。予約の仮取り消しなどは、実際のタスク処理とは独立に、計算のみで行う思考実験的な処理である。

[0073] 新規タスクに必要な処理時間が空き時間を超えな、場合は（S34の Y)、抽出した低優先度タスクを停止する旨の警告を表示装置 500に表示のうえ (S68)、当該タスクを停止し（S70)、スケジュールファイルより予約を取り消す（S72)。そして図 7のごとく、ロードの完了（S38)およびスケジュールファイルの更新（S40)を行う。 S40ではさらに、ロードしたソフトウェアのタスクの優先度を優先度ファイルに書き込む。 S68の、低優先度タスクの停止に関する警告では、低優先度タスクの実行停止の可否をユーザに判断させるようにしてもよい。この場合は、ユーザが当該タスクの実行停止を拒否したら、新規ソフトウェアのロード不許可処理を行い、シーケンスを終了する。一方、ユーザが実行停止を了承したら、上述のように新規ソフトウェアのロード処理を行う

[0074] 必要な処理時間が仮の空き時間を上回る場合は（S34の N)、優先度ファイルにさらに低優先度タスクがあれば (S60の Y)、そのタスクを仮に取り消した場合 (S64)の仮の空き時間と新規タスクに必要な処理時間とを比較する（S32、 S34)。以上の処理を、新規タスクに必要な処理時間が仮の空き時間を超えなくなる（S34の Y)まで繰り返すが、その前に取り消すことのできる低優先度タスクが存在しなくなったら（S60 の N)、新規ソフトウェアのロード不許可処理を行う（S62)。これらの処理により、先に実行されて、ても優先度の低ヽタスクを停止させ、その代わりに新規タスクを起動させることができる。

[0075] 本実施の形態によれば、実施の形態 1および 2と同様、新規ソフトウェアの動作、および予約済みソフトウェアの動作にユーザが期待しない不具合が生じるのをロード前に防止することができ、さらにプロセッサ資源を効率的に使用することができる。さらに本実施の形態では、優先度属性を導入することによって、新規タスクに必要な処理時間がサブプロセッサ 30の空き時間を上回った場合でも、予約済みタスクの停止を視野に入れてロード可否判断がなされるため、ソフトウェアの内容などに応じた柔軟な対応を行うことができる。

[0076] (実施の形態 5)

本実施の形態は、実施の形態 1における図 1で示した情報処理装置 1000および、図 2で示した管理プロセッサ 32と同様の構成で実施することができる。ここでは主に、実施の形態 1〜4との相違点に着目し、説明する。 [0077] 実施の形態 4では、新規タスクが必要とする処理時間属性とサブプロセッサ 30の空き時間との比較に際し、優先度属性を導入した。本実施の形態ではさらに、実施の形態 3で述べた新規タスクが必要とするバス帯域と、バス帯域予約ファイルに基づく確保できるバス帯域との比較においても同じ優先度属性を参照する。さらに本実施の形態では、バス帯域属性を、最適バス帯域と最低必要バス帯域との 2段階に分けて表現する。そして新規タスクおよび予約済みタスクの優先度に基づき各タスクの使用バス帯域を調整しながら、実行可否判定を行う。

[0078] 図 16は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル 76は、属性名称欄 76a、第一必要値欄 76b、第二必要値欄 76cおよび、識別子欄 76dを含む。「処理時間」属性に対し、タスクの処理に必要なサブプロセッサ 30の個数および処理時間力「優先度」属性に対し、タスクの優先度が、それぞれ第一必要値欄 76bに記載される。「バス帯域」属性は、タスクの処理に最適なバス帯域の割合が第一必要値欄 76bに、動作に不具合が生じない範囲で最低限必要なノス帯域の割合が第二必要値欄 76cに、バスの区間を識別するための識別子が識別子欄 76dに記載される。各タスクは、他のタスクとの優先度の比較によって、第一必要値欄 76b、および第二必要値欄 76cに記載された数値に基づき、その使用バス帯域が決定される。決定手順について以下に述べる。

[0079] 図 17は本実施の形態において参照されるバス帯域予約ファイルに格納されたバス帯域予約テーブルのデータ構造の例を示している。バス帯域予約テーブル 78は、ソフトウェア名欄 78a、タスクナンバー欄 78b、最適値欄 78c、最低値欄 78dおよび使用値欄 78eを含む。各ソフトウェアに対し、スケジューリングされたタスクは番号付けされ、その番号がタスクナンバー欄 78bに示される。さらにそれぞれのソフトウェアのバス帯域属性より読みだされた、第一必要値および第二必要値が、最適バス帯域および最低バス帯域としてそれぞれ最適値欄 78cおよび最低値欄 78dに示される。さらに現在予約されている、すなわち各タスクが使用できるバス帯域の割合が使用値欄 7 8eに示される。この使用バス帯域は、後述のバス帯域属性に係る処理において自動的に決定される。ノス帯域の使用値は最適値が上限、最低値が下限となる。またバス帯域使用値は実施の形態 3で説明したとおり、ハードウェアによって最低限保障される。

[0080] 本実施の形態において、主に管理プロセッサ 32によって行われる処理について説明する。新規ソフトウェアのロード要求受け付けから、優先度を考慮した処理時間属性に係る処理は、実施の形態 1における図 5および、実施の形態 4における図 15と同様の処理を行う。図 18は、処理時間属性について実行可能の判定がなされたら（S3 4の Y、 S66〜S72)、それに引き続き行われる、優先度を考慮したバス帯域属性に係る処理手順を示して！/、る。

[0081] まず属性取得部 62は、新規ソフトウェアの属性ファイル内のバス帯域属性を検出し、第一必要値、第二必要値、および識別子を読み込む (S74)。次に状況取得部 64 は、バス帯域予約ファイルに基づき確保できるバス帯域の時間変化をバスの区間ごとに導出する（S76)。

[0082] 次いで判定部 66は、新規ソフトウェアのバス帯域属性のうち第一必要値を取得し、バスの区間ごとに、確保できるバス帯域との比較を行う（S78)。ここでの比較も実施の形態 3と同様に、新規タスクの必要処理時間を考慮する。また当初の予約済みタスクの割り当てスケジュールでは十分なバス帯域が確保できな、場合は、実施の形態 3 と同様、スケジュールの仮調整を行ったうえで再度比較を行うが、図の簡単のため、図 18においてはそれらの処理も S78に含めるものとする。新規タスクの最適バス帯域力バスの区間において、確保できるバス帯域をどの時間においても超えないようにスケジューリングできると判定された場合は（S78の Y、 S88の Ν)、図 7のごとぐ口ードの完了（S38)およびスケジュールファイルおよびバス帯域予約ファイルを更新する（S40)。このときバス帯域予約テーブル 78の新規ソフトウェアの使用値欄 78eには、最適バス帯域が記載される。

[0083] 一方、最適バス帯域が確保できるバス帯域を上回って、ると判定された場合 (S78 の N)、判定部 66は、処理時間属性に係る処理時に読み込まれた新規タスクの優先度（図 15の S56)と、予約済みタスクの優先度（同図の S58)とを比較する（S80)。低優先度タスクが存在しない場合 (S80の N)、起動処理部 68は新規ソフトウェアのロード不許可処理を行う（S82)。低優先度タスクが存在する場合 (S80の Y)、状況取得部 64はバス帯域予約ファイルを参照し、低優先度タスクのうち、最低バス帯域より大、値が使用バス帯域となって、るものを抽出する（S84)。該当する低優先度タスクがあったら（S84の Y)、そのうちのひとつの使用値を仮に削減した場合の、仮に確保できるバス帯域を算出する（S86、 S76)。そして判定部 66が新規タスクの最適バス帯域と仮に確保できるバス帯域とを比較する（S78)。低優先度タスクの使用バス帯域の削減は、最低バス帯域を限度とする。削減は判定部 66による判定結果を見ながら徐々に行ってもよい。さらに、複数の低優先度タスク力均等に、徐々に削減していってもよい。

[0084] 新規タスクの最適バス帯域が確保できたら（S78の Y)、起動処理部 68は、バス帯域の削減対象となった低優先度タスクの処理動作が遅くなる可能性についての警告を表示装置 500に表示のうえ（S88の Y、 S90)、当該タスクの使用バス帯域を削減するようバス帯域予約テーブル 78の該当ソフトウェアの使用値欄 78eを変更する（S9 2)。そして、図 7のごとぐ起動処理部 68が新規ソフトウェアのロードの完了（S38)およびスケジュールファイル、バス帯域予約ファイル、および優先度ファイルの更新処理を行う。 S90のステップではユーザに対し、低優先度タスクの動作が遅くなつてもよいか問い合わせるようにしてもよい。この場合は、ユーザが当該タスクの動作速度低減を拒否したら、 S82と同様に新規ソフトウェアのロードを行わない。一方、ユーザが動作速度低減を了承したら、上述のロード完了処理を行う。

[0085] 新規タスクの最適バス帯域が仮に確保できるバス帯域を上回る場合 (S78の N)、さらに使用バス帯域が最低バス帯域より大きい低優先度タスクがあれば (S80の Y、 S8 4の Υ)、その使用バス帯域を削減した場合の仮に確保できるバス帯域と新規タスクの最適バス帯域とを比較する（S86、 S76、 S78)。以上の処理を、新規タスクの最適バス帯域が仮に確保できるバス帯域を超えなくなる（S78の Y)まで繰り返すが、その前に低優先度タスク全ての使用バス帯域を最低バス帯域に設定してもなお、新規ソフトウェアの最適バス帯域分を確保できない場合は（S84の N)、新規タスクの使用バス帯域を仮に削減し (S94、 S96)、仮に確保できたバス帯域を超えないか判定する（S 78)。新規タスクの使用バス帯域の削減も、バス帯域属性の第二必要値を限度とする。そして、仮に確保できるバス帯域を超えなければ (S78の Y)、起動処理部 68は、ノス帯域の削減対象となった低優先度タスクの動作が遅くなる可能性、および、新規タスクの動作が遅くなる可能性についての警告を表示装置 500に表示のうえ（S88の Y、 S90)、低優先度タスクの使用バス帯域を削減するようバス帯域予約テーブル 78 の該当ソフトウェアの使用値欄 78eを変更する（S92)。そして、図 7のごとぐ新規ソフトウエアのロードの完了（S38)およびスケジュールファイル、バス帯域予約ファイル、および優先度ファイルの更新処理（S40)を行う。このとき、新規ソフトウェアのタスクの使用バス帯域はバス帯域属性の第一必要値力削減した値を記載する。

[0086] 新規タスクの使用バス帯域を第二必要値まで削減しても仮に確保できたバス帯域を超える場合は（S78の N)、起動処理部 68は、新規タスクの最低バス帯域を確保できるまで低優先度タスクを優先度などに基づき抽出し、実施の形態 4の図 15における S68、 S70、 S72で行ったのと同様の低優先度タスクの停止処理を行う（S98)。そして上述の新規ソフトウェアのロード処理（図 7の S38、 S40)を行う。

[0087] 以上の処理により、新規タスク、予約済みタスクの双方の使用バス帯域を許容範囲内で調整しながら、可能な限り全てのタスクを実行することができる。さらに、使用バス帯域の削減や低優先度タスクの停止を行う前にユーザへ確認する態様とすれば、動作が遅くなる可能性があっても全てのタスクを実行する、動作を遅くせず優先度の低いタスクを停止する、など多様な対策の中からのユーザによる選択が可能となる。

[0088] 本実施の形態では、実施の形態 1〜4と同様、新規ソフトウェアの動作、および予約済みソフトウェアにユーザが期待しない不具合が生じるのをロード前に防止することができ、さらにプロセッサ資源を効率的に使用することができる。また実施の形態 4と同様、優先度属性を導入することによって処理時間に対してより柔軟な運用形態となる。さらに、バス帯域に対する判定にも優先度属性を導入することにより、優先度に応じてロードの可否判断がなされるとともに、ノス帯域の調整を自動的に行うことができ、ロードの可否のみならず使用ノス帯域についても柔軟な運用形態となるほか、より効率的な資源の使用を行うことができる。

[0089] なお、本実施の形態ではバス帯域属性として第一必要値と第二必要値の 2段階で表現したが、必要値をひとつ設定し、それが厳守値であるか望ましい値であるかを識別するよう〖こしてもよい。この場合、設定されたバス帯域が厳守値であるタスクの使用バス帯域は優先度に関わらず削減対象からはずす。望まし、値であるタスクの使用バス帯域は、例えばある共通の最低必要バス帯域をあら力じめ設定しておき、その値まで削減させてよいとする。この場合も、上述の場合と同様の効果を得ることができる

[0090] (実施の形態 6)

本実施の形態は、実施の形態 1における図 1で示した情報処理装置 1000および、図 2で示した管理プロセッサ 32と同様の構成で実施することができる。また、管理プロセッサ 32で行われる処理手順は実施の形態 1〜5のいずれかと同様に行われる。ここでは主に、実施の形態 1との相違点に着目し、説明する。

[0091] 図 19は本実施の形態における記憶装置 600の構成を模式的に示している。実施の形態 1では、処理時間属性やバス帯域属性を示すファイル力ソフトウェアのプログラムファイルと同一の、 CD— ROMなどの記憶装置に格納されているとしたが、本実施の形態では属性ファイルはプログラムファイルとは異なる記憶装置 600に格納される。そして属性取得部 62は、新規ソフトウェアのロード処理とは別に、属性ファイルの格納された記憶装置 600から属性ファイルのみをまずメインメモリ 50にロードし、属性ファイルに含まれる処理時間属性、バス帯域属性、優先度属性のデータに基づき、ロード可否の判定を行う。

[0092] 本実施の形態によれば、管理プロセッサ 32の処理動作などを制御する OSのバージョンが更新されたり、プロセッサの演算速度やバス帯域が大きい情報処理装置 100 0の機種が新たに製品化されたりした場合でも、それらの変化に対応した属性フアイルを記憶した CD— ROMなどの記憶装置 600のみを新たに読み込ませれば、プログラムファイルを格納した記憶装置 600はそのまま利用することができる。これによりュ一ザは、実施の形態 1〜5で説明したのと同様の効果と、最新環境がもたらす処理速度に係る効果との相乗効果を容易に享受することができる。また、属性ファイルの記憶装置 600を情報処理装置 1000に接続したノヽードディスクとすれば、例えば優先度属性などをユーザが自分の好みに応じて書き変えることも可能となる。これにより、よりユーザのニーズに即したロード処理を行うことができる。

[0093] (実施の形態 7)

本実施の形態は、実施の形態 1における図 2で示した管理プロセッサ 32と同様の構成で実施することができる力図 1で示した情報処理装置 1000は図 20の全体構成で示すようにネットワークを介してサーバ 700に接続されて!、る。管理プロセッサ 32で行われる処理手順は実施の形態 1〜5のいずれかと同様に行われる。ここでは主に、実施の形態 1および 6との相違点に着目し、説明する。

[0094] 図 20は本実施の形態におけるシステムの全体構成を示している。実施の形態 1〜 6では、処理時間属性やバス帯域属性を示すファイル力 CD— ROMなど情報処理装置 1000に直接接続された記憶装置 600に格納されているとしたが、本実施の形態ではサーバ 700において管理される。一方、ソフトウェアには、対応する属性フアイルの名称や OSのバージョン情報など、当該ソフトウェアに対応した属性ファイルをサーバより検出するための識別子が付加される。

[0095] そして情報処理装置 1000の属性取得部 62は、処理時間属性やバス帯域属性を取得する際、サーバ 700に識別子を送信して問い合わせを行う。サーバ 700のサーバ側情報処理部 702は情報処理装置 1000からの問、合わせに従、、サーバ側記憶装置 704から当該識別子に対応する属性ファイルを検出し、情報処理装置 1000 に対しダウンロードの準備ができた旨の通知を行う。属性取得部 62は当該通知を受けて属性ファイルのダウンロードを行うことにより、メインメモリ 50に格納する。その後は実施の形態 1〜5と同様に、当該属性ファイルに含まれる処理時間属性、バス帯域属性、優先度属性のデータに基づき、ロード可否の判定を行う。

[0096] 本実施の形態によれば、属性ファイルの管理は常にサーバ 700が行っているため、ソフトウェアメーカなどによる属性データの検証実験により属性データが改善された場合や、情報処理装置 1000で実行される OSのバージョンが更新されたり、プロセッサの演算速度やバス帯域が大きい情報処理装置 1000の機種が新たに製品化されたりした場合でも、ソフトウェアに対応する範囲内で最新の属性データによる運用を自動的に行うことができる。これによりユーザは、実施の形態 1〜5で説明したのと同様の効果と、最新環境がもたらす処理速度に係る効果との相乗効果を容易に享受することがでさる。

[0097] 上述の構成では、識別子およびプログラムファイルは情報処理装置 1000に接続された記憶装置 600に格納されていた力これらもサーバ 700のサーバ側記憶装置 7 04に格納してよい。この場合、ユーザが表示装置 500上でソフトウェア名の選択などを行うと、対応する属性ファイルのダウンロードが先に行われる。これにより新規ソフトウェアのロード可否判定を行い、ロード可能と判定された場合に、情報処理装置 100 0はその旨の信号をサーバ 700へ送信し、ソフトウェアのプログラムファイルのダウンロードを行う。このような構成により、新規ソフトウェアに係る記憶装置 600をユーザが全く保持せずとも、本実施の形態の実施が可能となり、上述と同様の効果を得ることができる。

[0098] (実施の形態 8)

本実施の形態は、実施の形態 1における図 2で示した管理プロセッサ 32と同様の構成で実施することができるが、図 1で示した情報処理装置 1000は実施の形態 7と同様にネットワークを介してサーバ 700に接続されている。管理プロセッサ 32で行われる処理手順は実施の形態 1〜5のいずれかと同様に行われる。ここでは主に、実施の形態 7との相違点に着目し、説明する。

[0099] 図 21は本実施の形態におけるシステムの全体構成を示している。実施の形態 7では、処理時間属性やバス帯域属性を示す属性ファイルをサーバ 700で一元的に管理していた力本実施の形態では、ソフトウェアのプログラムファイルが格納されているのと同一の記憶装置 600にも格納される。すなわち、ソフトウェアの出荷時にはその時点で最新の属性ファイルをプログラムファイルに付加しておく。その後、ソフトゥェァメーカなどによる属性データの検証実験により属性データが改善された場合や、情報処理装置 1000で実行される OSのバージョンが更新された場合などに、サーバ 70 0より属性ファイルを取得する。そのため、ソフトウェアには、付加された属性ファイルのバージョン情報や、その時点での OSのバージョン情報などの識別子が付加される

[0100] そして情報処理装置 1000の属性取得部 62は、処理時間属性やバス帯域属性を取得する際、まずサーバ 700に識別子を送信して問い合わせを行う。サーバ 700のサーバ側情報処理部 702は当該識別子に対応する属性ファイルをサーバ側記憶装置 704から検出し、バージョンが更新されているかどうかを確認する。更新されていればその旨を情報処理装置 1000へ通知し、情報処理装置 1000は最新の属性フアイルをサーバ 700よりダウンロードする。さらに情報処理装置 1000で実行されている O Sのバージョンが更新されている場合も、情報処理装置 1000はサーバ 700に問い合わせを行い、更新後の OSのバージョンに対応した属性ファイルをダウンロードする。ダウンロードの手順は実施の形態 7と同様である。その後は実施の形態 1から 5と同様に、当該属性ファイルに含まれる処理時間属性、バス帯域属性、優先度属性のデータに基づき、ロード可否の判定を行う。

[0101] 本実施の形態によれば、出荷時点で最新の属性データはソフトウェアが格納されているのと同一の記憶装置 600に格納されているため、情報処理装置 1000が例えネットワークと接続していない状態であったとしても運用が可能である。さらに実施の形態 7と同様、属性データの改善、 OSのバージョンの更新、情報処理装置 1000の機種変更などの変化に適宜対応した最新の環境での運用が可能となり、実施の形態 1 〜5で説明したのと同様の効果と、最新環境がもたらす処理速度に係る効果との相乗効果を容易に享受することができる。

[0102] 以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せに、ろ、ろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

[0103] 実施の形態 3および 5では、バス帯域属性に係る処理を処理時間属性に係る処理の後に行った力処理時間属性に係る処理の前、あるいはバス帯域属性のみを参照する処理を行ってもよい。この場合も、本実施の形態と同様の効果を得ることができる

[0104] また、各属性は別の属性ファイルに記述されてもよぐ格納する記憶装置が異なつて!、てもよ、。例えばユーザによる設定が容易な優先度属性のみを記載したファイルを初回ロード時にハードディスクなどに格納して更新、参照を行い、そのほかの属性はソフトウェアのプログラムファイルとともに CD— ROMに格納したファイル、またはサーバ 700に格納されたファイルを参照してもよい。これにより、属性そのものの性質に応じた臨機応変な運用形態で、本実施の形態で述べた効果を得ることができる。産業上の利用可能性

[0105] 以上のように本発明は、複数のタスクを並列に実行するコンピュータ、ゲーム機器などの電子機器に利用可能である。

Claims

請求の範囲

[1] 新規タスクの実行要求を受け付けるステップと、

前記新規タスクの所要処理時間および前記新規タスクの処理における所要バス帯域の少なくとも一方を特定するステップと、

複数のタスクの処理手順を表すスケジューラに予約された予約済みタスクと前記新規タスクの所要処理時間を合計した総所要処理時間と、それらのタスクを実行する装置が確保できる処理時間との比較、および、前記予約済みタスクと前記新規タスクの処理における所要バス帯域を合計した総所要バス帯域と、それらのタスクを実行する装置が確保できるバス帯域との比較、の少なくとも一方を行うステップと、

比較結果に基づき前記新規タスクの実行可否を判定するステップと、

前記新規タスクが実行可能と判定された場合、前記新規タスクを前記スケジューラに予約するステップと、

前記スケジューラに基づき前記実行可能と判定された新規タスクを含むタスクの処理を行うステップと、

を含み、

前記実行可否を判定するステップは、前記新規タスクの優先度情報を取得するステツプを含み、前記取得した優先度情報に基づ、て前記実行可否を判定することを特徴とする情報処理方法。

[2] 前記実行可否を判定するステップは、

前記総所要バス帯域が前記確保できるバス帯域を上回って、た際、前記新規タスクの優先度情報と前記予約済みタスクの優先度情報を参照するステップをさらに含み、

参照した前記優先度情報に基づいて前記新規タスクに加え前記予約済みタスクの実行可否を判定することを特徴とする請求項 1に記載の情報処理方法。

[3] 前記実行可否を判定するステップにおいて前記新規タスクの実行可否を判定する前に、前記新規タスクおよび前記予約済みタスクの処理態様の調整を行うステップをさらに含むことを特徴とする請求項 2に記載の情報処理方法。

[4] 前記実行可否を判定するステップにお！ヽて前記新規タスクが実行不可と判定された場合、前記新規タスクの実行要求を起こしたタスクに対して、前記判定結果を通知するステップをさらに含むことを特徴とする請求項 1から 3のいずれかに記載の情報処理方法。

[5] 前記実行可否を判定するステップにお!、て前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された場合、前記装置を制御するシステム制御部に対して、前記判定結果を通知するステップをさらに含むことを特徴とする請求項 2または 3に記載の情報処理方法。

[6] 前記システム制御部に通知された前記判定結果に基づき、ユーザが認識可能な表現にて前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された旨の通知をユーザに対し行うステップをさらに含むことを特徴とする請求項 5に記載の情報処理方法。

[7] 通知を受けたユーザ力もの、実行不可と判定されたタスクの実行不履行の許可に係る情報の入力を受け付けるステップをさらに含み、前記許可に係る情報に基づき、前記新規タスクおよび前記予約済みタスクの実行可否を再判定することを特徴とする請求項 6に記載の情報処理方法。

[8] 主に装置全体を統括的に制御する第一のプロセッサと、主に演算処理を行う第二のプロセッサと、処理するタスクに関する情報を記憶するメインメモリと、外部装置とのデータ入出力を制御するデータ入出力プロセッサと、を備える情報処理装置であつて、

前記第一のプロセッサは、

新規タスクの実行要求を受け付ける実行要求受付け部と、

前記新規タスクの処理に係る時間関連パラメータを特定するパラメータ特定部と、特定した前記時間関連パラメータと、前記情報処理装置の内部に係る情報のうち前記時間関連パラメータと対応する対応内部情報と、に基づき前記新規タスクの実行可否を判定する実行許可部と、

前記新規タスクが実行可能と判定された場合、前記新規タスクの処理を起動する起動処理部と、を備え、

前記時間関連パラメータは、前記第一のプロセッサと前記メインメモリ間のデータ転送にぉ、て前記新規タスクが必要とするバス帯域、前記第一のプロセッサと前記第二のプロセッサ間のデータ転送にお、て前記新規タスクが必要とするバス帯域、および前記第一のプロセッサと前記データ入出力プロセッサ間のデータ転送において前記新規タスクが必要とするバス帯域のうち、少なくともひとつを含むことを特徴とする情報処理装置。

[9] 前記第二のプロセッサはグラフィックプロセッサであり、前記第一のプロセッサによる制御により、取得した画像処理に係るデータに基づき画像処理演算を行うことを特徴とする請求項 8に記載の情報処理装置。

[10] 前記実行許可部は、

前記新規タスクが必要とするバス帯域と、複数のタスクの処理手順を表すスケジューラに予約された予約済みタスクが必要とするバス帯域とを合計した総所要バス帯域と、前記情報処理装置の確保できるバス帯域と、をバス区間ごとに比較し、前記総所要バス帯域が前記情報処理装置の確保できるバス帯域を上回って!/、た際、前記新規タスクの優先度情報と前記予約済みタスクの優先度情報に基づいて前記新規タスクの実行可否を判定することを特徴とする請求項 8に記載の情報処理装置。

[11] 前記実行許可部は、前記優先度情報に基づいて、前記新規タスクおよび前記予約

、、前記新規タスクに加え前記予約済みタスクの実行可否を判定することを特徴とする請求項 10に記載の情報処理装置。

[12] 前記時間関連パラメータは、前記新規タスクを処理するための最適バス帯域および最小限度バス帯域を含み、

前記実行許可部は、優先度の低い前記予約済みタスクが使用するバス帯域を前記最適バス帯域以下、前記最小限度バス帯域以上の範囲で調整することにより、前記新規タスクの実行可否を判定することを特徴とする請求項 10に記載の情報処理装置

[13] 前記第一のプロセッサと、前記第二のプロセッサと、前記データ入出力プロセッサとの間のバスにお、て、前記新規タスクおよび前記予約済みタスクがそれぞれ使用する帯域を前記調整の結果に基づいて制御するバス帯域制御部をさらに含むことを特徴とする請求項 11に記載の情報処理装置。

[14] 前記実行許可部にお！ヽて前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された場合、ユーザが認識可能な表現にて前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された旨の通知をユーザに対し行う判定結果通知部をさらに含むことを特徴とする請求項 11に記載の情報処理装置。

[15] 前記第一のプロセッサは複数の処理ユニットを含み、

前記時間関連パラメータは前記新規タスクを前記複数の処理ユニットの少なくともひとつへ割り当てて処理した際の所要処理時間をさらに含むことを特徴とする請求項 10に記載の情報処理装置。

[16] 前記時間関連パラメータは前記新規タスクを前記所要処理時間内で処理する際の所要処理ユニット数を含み、

前記実行許可部は、前記予約済みタスクに対し未割り当ての期間を有する前記処理ユニットの数と、それらの処理ユニットの前記未割り当ての期間とを、前記新規タスクの前記所要処理ユニット数および前記所要処理時間と比較することにより、前記新規タスクの実行可否を判定することを特徴とする請求項 15に記載の情報処理装置。

[17] 前記実行許可部は、前記予約済みタスクに割り当てられた処理ユニットを別の処理ユニットに割り当てなおして前記未割り当ての期間を調整することにより、前記新規タスクの実行可否を判定することを特徴とする請求項 16に記載の情報処理装置。

[18] 前記パラメータ特定部は、前記新規タスクの処理に係る時間関連パラメータの情報要求を、ネットワークを介して接続したサーバに対し発行するパラメータ要求発行部と前記情報要求に応じて前記サーバが特定した前記時間関連パラメータを受信するパラメータ受信部と、

を含むことを特徴とする請求項 8に記載の情報処理装置。

[19] タスクごとに、タスクの処理に係る時間関連パラメータを記憶したパラメータ記憶部をさらに含み、

前記パラメータ特定部は、前記パラメータ記憶部を検索することにより、前記新規タスクの処理に係る時間関連パラメータを特定することを特徴とする請求項 8に記載の情報処理装置。

[20] タスクの実行要求を受けた装置力前記タスクの所要処理時間および前記タスクの処理における所要バス帯域の少なくとも一方を含む時間関連パラメータの情報要求を受け付けるパラメータ要求受付け部と、

前記情報要求に対し、前記時間関連パラメータを特定するパラメータ取得部と、特定した前記時間関連パラメータに関する情報を前記タスクの実行要求を受けた装置へ送信するパラメータ送信部と、

を含むことを特徴とするサーバ。

[21] コンピュータにタスクを実行させるコンピュータプログラムであって、

前記タスクの処理に係り、前記コンピュータの内部に係る対応情報との比較により前記タスクの実行可否が前記コンピュータにより判定される、タスクの所要処理時間および所要バス帯域の少なくとも一方を含む時間関連パラメータが、属性として付カロされていることを特徴とするコンピュータプログラム。

[22] コンピュータが処理するタスクごとに、前記コンピュータの内部に係る対応情報との比較により前記タスクの実行可否が前記コンピュータにより判定される、タスクの所要処理時間および所要バス帯域の少なくとも一方を含む時間関連パラメータを記録したことを特徴とする記録媒体。