JP6007516B2 - リソース配分システム、リソース配分方法、及びリソース配分プログラム - Google Patents

Description

本発明は、リソース配分システム、リソース配分方法、及びリソース配分プログラムに関し、特にタスクの所定区間における性能保証が可能なリソース配分システム、リソース配分方法、及びリソース配分プログラムに関する。

複数のタスクを処理するコンピュータシステムでは、各タスクの処理順序や優先度を制御する、いわゆる、「タスクスケジューリング」が行われることがある。

タスクスケジューリングを行うリソース制御システムの一例が、特許文献１に記載されている。特許文献１のリソース制御システムは、複数のＣＰＵ（Central Processing Unit）コアを有するコンピュータシステム上で複数のメディア処理が行われる際の、タスクスケジューリングを行う技術である。このシステムは、グローバルスケジューラと呼ばれる機能ブロックがタスクの処理順序や優先度を制御し、最終的なメディア処理性能を高めることを目指している。

特許文献１には、タスクの実行を優先させる選択基準として、４つのポリシーが例示されている。第１のポリシーは、データの作成時刻を見て、処理のレイテンシの最小化を図るポリシーである。第２のポリシーは、当該タスクの出力に依存している別タスクの数が多いものを優先するポリシーである。第３のポリシーは、当該タスクの入力として必要なデータが揃っていないものを低優先とするポリシーである。第４のポリシーは、キャッシュミスを減らすために、同一のプロセッサによって実行されるスレッドを優先するポリシーである。

特許文献２、３には、プロセスやジョブを処理するための、プロセッサやサーバ等のリソースを予約するシステムが開示されている。

特表２０１０−５０８５７４号公報（第１４−１５頁） 特開２００５−１５７９５５号公報（第１０−１１頁） 特開２００５−２３４６３７号公報（第７頁）

特許文献１の技術の問題点は、メディア処理のように時間当たりの処理性能を一定以上に保つ必要があるシステムにおいても、入力負荷が一時的に増加すると処理性能が低下することである。処理性能が低下すると、システムで求められる最低処理性能を満たせなくなる可能性がある。

なぜなら、一時的な高負荷状態に対し、負荷の増大分に見合う追加演算リソースが配分されないため、高負荷状態における処理に通常より長い時間を要するからである。

特許文献２、３の技術では、処理が完了すべき時刻や必要な計算量、必要なリソースの量を考慮してリソースの予約を行うことができる。しかし、特許文献２、３の技術にも、入力負荷が一時的に増加した場合に対応できないという、特許文献１の技術と同様の課題がある。
（発明の目的）
本発明の目的は、入力負荷の変動が生じても、タスクの所定区間の処理性能の最低値を保証できるような、リソース配分システム、リソース配分方法及びリソース配分プログラムを提供することにある。

本発明のリソース配分システムは、タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のためにタスクへ割り当てられたと仮定されたリソースの量である第１のリソース量と、タスクに第１のリソース量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報を保持する性能情報保持部と、性能保証区間を有する性能保証型タスクから、性能保証区間の実行開始前に、性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定し、性能保証区間に対して第２のリソース量のリソースが割り当てられたことを示す割当通知を性能保証型タスクに送信するリソース要求量決定部と、性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持するタスク状態保持部と、割当対象となりうるリソースの総量である第４のリソース量、第２のリソース量及び第３のリソース量に基づいて、性能保証区間に対する第２のリソース量のリソースの割当の可否を決定するリソース配分決定部と、を備えることを特徴とする。

本発明のリソース配分方法は、タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のためにタスクへ割り当てられたと仮定されたリソースの量である第１のリソース量と、タスクに第１のリソース量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報、及び性能保証区間を有する性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持し、性能保証型タスクから、性能保証区間の実行開始前に、性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定し、割当対象となりうるリソースの総量である第４のリソース量、第２のリソース量及び第３のリソース量に基づいて、性能保証区間に対する第２のリソース量のリソースの割当の可否を決定し、性能保証区間に対して第２のリソース量のリソースが割り当てられたことを示す割当通知を性能保証型タスクに送信することを特徴とする。

本発明のリソース配分プログラムは、リソース配分システムが備えるコンピュータを、タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のためにタスクへ割り当てられたと仮定されたリソースの量である第１のリソース量と、タスクに第１のリソース量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報、及び性能保証区間を有する性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持する保持手段と、性能保証型タスクから、性能保証区間の実行開始前に、性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信する受信手段と、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定する要求量決定手段と、割当対象となりうるリソースの総量である第４のリソース量、第２のリソース量及び第３のリソース量に基づいて、性能保証区間に対する第２のリソース量のリソースの割当の可否を決定する割当決定手段と、性能保証区間に対して第２のリソース量のリソースが割り当てられたことを示す割当通知を性能保証型タスクに送信する通知手段として機能させることを特徴とする。

本発明のリソース配分システム、リソース配分方法及びリソース配分プログラムによると、入力負荷が変動しても、タスクの所定区間については最低限の処理性能を維持することができる。なぜなら、処理すべき負荷の量に対応して、性能を維持するために必要なリソース量を動的に算出し、それに沿ってリソース配分量を動的に変化させるからである。

本発明の第１の実施形態のリソース配分システムの全体構成を示すブロック図である。 本発明の第１の実施形態のスレッド制御部の内部構造を示すブロック図である。 本発明の第１の実施形態のスレッド−性能対応表の一例である。 本発明の第１の実施形態のタスク状態表の一例である。 本発明の第１の実施形態のリソース配分システムの、性能保証区間の処理が開始するときの動作を示す図である。 本発明の第１の実施形態のリソース配分システムの、性能保証区間の処理が終了するときの動作を示す図である。 本発明の第１の実施形態のリソース配分システムの最小構成を示すブロック図である。 本発明の第１の実施形態のリソース配分システムの、性能保証区間終了時のスレッド配分決定部の動作を示すフローチャートである。 本発明の第４の実施形態のスレッド−性能対応表の一例である。 本発明の第４の実施形態のリソース配分システムにおける予定処理負荷量の時間変化を示すグラフである。 本発明の第４の実施形態のリソース配分システムにおける、時間経過に伴って変化するタスク状態表の一例である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、各タスクの性能保証区間の目標処理時間と実際の処理時間を表す図である。 本発明の第４の実施形態のリソース配分システムにおける、期間ごとの目標処理時間と実際の処理時間の例を表す図である。

（第１の実施形態）
発明を実施するための形態について図面を参照して詳細に説明する。図１に、本発明の第１の実施形態のリソース配分システムの全体構成のブロック図を示す。

第１の実施形態のリソース配分システムは、ソフトウェアとして、１つ以上のタスク３０−１、３０−２と、唯一のリソース制御部１０と、一般的なＯＳ（Operating System。オペレーティングシステム）３５と、を備える。

タスク３０−１、３０−２は、アプリケーションプログラムの実行インスタンスである。リソース制御部１０は、各タスクに配分するリソース量を制御する。

タスクには、その動作性能が保証されるべき「性能保証型タスク」と、動作性能が必ずしも保証されない「ベストエフォート型タスク」の２種類がある。図１では、タスク３０−１が性能保証型タスク、タスク３０−２がベストエフォート型タスクである。性能保証型タスク３０−１にはスレッド制御部２０が連結されている。なお、本実施形態においては、全タスクの中に、性能保証型タスク３０−１は最低１個含まれている必要があるが、ベストエフォート型タスク３０−２は必ずしも含まれている必要はない。

リソース制御部１０は、スレッド要求量決定部１１、スレッド−性能対応表１２、スレッド配分決定部１３、タスク状態表１４、を有する。スレッド要求量決定部１１は、タスクからの要請でスレッド要求数を決定する。スレッド−性能対応表１２は、スレッド要求量決定部１１が要求数を決める際に参照される。スレッド配分決定部１３は、各タスクのスレッド要求数を鑑みて、各タスクへの適切なスレッド配分量を決定する。タスク状態表１４は、現在の各タスクへのスレッド配分状態を記録する。

図２は、スレッド制御部２０の内部構造を示す。スレッド制御部２０は、タスクインタフェース部２１（図２では「タスクI/F部」と記載）と、リソース制御インタフェース部２２（図２で「RM I/F部」と記載）と、スレッドプール２４と、スレッドプール制御部２３と、スレッド開始パラメータ２５と、スレッド状態表２６と、を有する。

タスクインタフェース部２１は、性能保証型タスク３０−１との通信を行う。リソース制御インタフェース部２２は、リソース制御部１０との通信を行う。スレッドプール２４は、あらかじめ生成しておいたＯＳ上のスレッドの集合を保管する。スレッドプール制御部２３は、スレッドプール２４内の各スレッドの実行や停止を制御する。スレッド開始パラメータ２５は、各スレッドの実行開始時のパラメータを保持する。スレッド状態表２６は、各スレッドの現在の状態を記録する。

性能保証型タスク３０−１は、その内部に性能保証区間３１と呼ばれる部分を有する。「性能保証区間」とは、一つの開始点と一つの終了点を持つ、プログラムコードの一部であって、その開始点から終了点までのタスク実行時間が別途指定される値以下となることが、システム要件から要請されているものである。

例えば、毎秒30フレームの動画像に対して、フレームごとの画像処理をリアルタイムで実行するタスクの場合、性能保証区間は１フレームに対する当該画像処理を行うサブルーチンである。この場合、性能保証区間の処理時間の上限値は、33ミリ秒（30フレーム/秒の逆数）、となる。

図３は、スレッド−性能対応表１２の一例である。スレッド−性能対応表１２は、各々の性能保証区間に対するスレッド−性能対応表エントリ１２１〜１２３を有する。

スレッド−性能対応表エントリ１２１〜１２３には、区間名（図３では“SEC1”, “SEC2”等）で識別された性能保証区間ごとに、いくつかのスレッド数とその処理時間の対応が記載されている。ここでの「処理時間」とは、当該性能保証区間をそのスレッド数のスレッドで実行した場合に要する処理時間である。処理時間の測定に用いる、当該性能保証区間での処理対象とされるデータの量は、当該性能保証区間に対して基準となる（ベースとなる）量とする。

ここで、指定スレッド数で実行した場合の処理時間に関して補足する。ある決まった処理を、あるスレッド数で実行した場合の処理時間は、システム内にトータルでいくつの有効スレッドが存在するかによって変化する。

本実施形態の技術を利用する際には、まず、システム内の有効スレッド数の合計値Ｎall（Ｎallは１以上の整数）を一意に定める。Ｎallはシステム内のプロセッサコア数に合わせることもできるが、コア数以上の値を選ぶこともできる。次に、ＯＳ上でＮall個のスレッドを生成し、うちＲ個（Ｒは、１以上、Ｎall以下の整数）のスレッドを当該処理に、（Ｎall−Ｒ）個のスレッドを他のダミー処理にそれぞれ割り当る。そして、当該処理に対し基準量となる処理対象データを与えて、当該処理の実行時間ｔを測定する。Ｒを１、２、・・・と変化させながらｔの値を測定し、スレッド−性能対応表１２を作成する。

図４は、タスク状態表１４の一例である。タスク状態表１４は、システム内の性能保証型タスク３０−１の各々に対して一つのエントリを持つ表である。各エントリは、タスクを一意に識別するためのタスクＩＤ、当該タスクが要求しているスレッド数、当該タスクの状態、の各欄を有する。タスク状態表１４の各エントリはまた、当該タスクの動作性能を測定した値を保持する性能測定値欄を有してもよい。

次に、本実施の形態の全体の動作について、図１から図６を参照して、タスクの開始、タスク内の性能保証区間の開始と終了、そしてタスクの終了、の順で詳細に説明する。

性能保証型タスク３０の実行が開始されると、性能保証型タスク３０はタスクインタフェース部２１に対し、”初期化通知”を送信する。典型的な実装形態では、スレッド制御部２０は性能保証型タスク３０のプログラムにリンクされて実行されているから、上記の初期化通知はタスクインタフェース部の当該機能の関数エントリを呼び出すことで行われる。

タスクインタフェース部２１は、”初期化通知”を受信すると、リソース制御インタフェース部２２を初期化して、リソース制御部１０とスレッド制御部２０とが正しく通信できるようにする。さらに、タスクインタフェース部２１は、スレッドプール制御部２３に対してスレッドプールの初期化を指示する”初期化指示”を送信する。

スレッドプール制御部２３は、”初期化指示”を受信すると、ＯＳ３５上で、ある個数のスレッドを作成し、それらの属性を高優先度に設定する。そして、スレッドプール制御部２３は、スレッドの実行を同期命令により起こされるまでブロックし、スレッドプール２４内で待機させる。ここで作成するスレッドの数は、性能保証区間３１で必要とされるスレッドの数を想定して、アプリケーション又はシステム設計時にあらかじめ決めておればよい。あるいは、リソース制御インタフェース部２２を通じてリソース制御部１０に問い合わせて、適切な初期スレッド数を得てもよい。

なお、初期化時にスレッドを生成しておく理由は、性能保証区間の実行開始時にスレッドを生成するための時間的オーバヘッドをできるだけ回避するためである。タスク実行の進行に際してスレッドが不足すれば、後述のように動的にスレッドを追加生成する。

性能保証区間を実行するためのスレッドは、その属性が高優先度に設定された「高優先なスレッド」である。「高優先なスレッド」とは、「次に実行すべきスレッドを選択しようとしているプロセッサコアがあるとき、実行可能な高優先スレッドが一つでも存在すれば、いかなる通常スレッドよりも先に、実行可能な高優先スレッドが選択され実行される。」というルールを満たすものである。

図５を参照して、性能保証区間の処理が開始するときの動作について、送受信される情報を具体例に示して説明する。性能保証区間の開始点において、性能保証型タスク３０はタスクインタフェース部２１に対し、”性能保証区間開始通知”を送信する（Ｓ２０１）。性能保証区間開始通知には、性能保証区間を識別する区間名、当該性能保証区間でその後処理される負荷の多寡を示す予定処理負荷量、及び当該性能保証区間での処理完了時間の要求値が、パラメータとして含まれる。

予定処理負荷量は、当該性能保証区間における基準量（ベースとなる量）に対する比の値で指定される。例えば、画素単位に単純な演算を施す画像処理（演算量が画素数に比例する処理）では、予定処理負荷量は次のようになる。ＱＶＧＡ（Quarter Video Graphics Array）サイズ（320×240画素）の入力画像が基準となる入力データサイズである場合、ＶＧＡ（Video Graphics Array）サイズ（640×480画素）の画像を与えるときの予定処理負荷量は４となる。すなわち、ＶＧＡサイズの入力画像を与えると、基準値の４倍の負荷量が予定される。

タスクインタフェース部２１はリソース制御部インタフェース部２２を通じ、”性能保証区間開始通知”をリソース制御部１０に送信する。典型的な実装形態では、リソース制御部１０はＯＳ３５上の一つのタスクとして実現され、この送信はＯＳ３５上でのタスク間通信を用いて行われる。送信される性能保証区間開始通知には、前述した内容と同じく、性能保証区間の区間名、予定処理負荷量、ならびに処理完了時間要求値が、パラメータとして含まれる（図５ Ｓ２０２）。

リソース制御部１０内にあるスレッド要求量決定部１１は、送信されてきた”性能保証区間開始通知”を受信する。そして、スレッド要求量決定部１１は、スレッド−性能対応表１２を参照して、次のようにして当該タスクが必要としているスレッド数を決定する（図５ Ｓ２０３）。

ステップ１： スレッド−性能対応表１２の中の、当該性能保証区間に対するエントリを見つける。

ステップ２： 当該エントリ中の、スレッド数−処理時間の対応列を参照し、処理時間に予定処理負荷量を乗じた値が処理完了時間要求値を下回る対応列の中で、最もスレッド数が小さいものを見つける。

上記ステップ２で見つけた最小のスレッド数を、スレッド要求量決定部１１で決定した「要求スレッド数Ｎinc（Ｎincは１以上の整数）」とする。スレッド要求量決定部１１は、タスクＩＤと決定した要求スレッド数の情報を組にして、スレッド配分決定部１３に”スレッド要求通知”を送信する（図５ Ｓ２０４）。

スレッド配分決定部１３は、スレッド要求量決定部１１から新たな”スレッド要求通知”を受信すると、タスク状態表１４に新たなエントリを設ける。そして、そのタスクＩＤ欄及び要求スレッド数欄に、前記スレッド要求通知に記載されていたタスクＩＤ及び要求スレッド数Ｎincを転記するとともに、その状態欄にWAIT（待機中）と記入する（図５ Ｓ２０５）。

次にスレッド配分決定部１３は、タスク状態表１４の中で、状態欄の値がPRIO-RUN（高優先実行中）であるエントリすべてを探し、それらのエントリの要求スレッド数の欄の値の総和Ｎold（Ｎoldは１以上の整数））を求める。PRIO-RUN状態のタスクの要求スレッド数の欄には、そのタスクに現在割り当てられているスレッド数が登録されている。従って、Ｎoldは、その時点で、PRIO-RUN状態の全タスクに割り当てられているスレッド数の合計値を意味する。

もし Ｎold＋Ｎinc＜Ｎall であれば、割当済みのスレッド数と新たに要求されたスレッド数の合計が、システム内の有効スレッド数の合計値、すなわち、割当可能なスレッド数の上限値よりも少ないことを意味する。従って、今回の新たなスレッド要求は承諾される。このとき、スレッド配分決定部１３は、当該タスクに連結されたスレッド制御部２０に対し、Ｎinc数の高優先スレッドが割り当てられた旨の”スレッド割当通知”を送信する（図５ Ｓ２０６）。そして、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をPRIO-RUNに変更する。

もし Ｎold＋Ｎinc≧Ｎall であれば、割当済みのスレッド数と新たに要求されたスレッド数の合計が、割当可能なスレッド数の上限値以上であることを意味する。従って、今回の新たなスレッド要求は拒否される。このとき、スレッド配分決定部１３は、当該タスクに連結されたスレッド制御部２０に対し、Ｎinc数の通常スレッドが割り当てられた旨の”スレッド割当通知”を送信する。そして、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をSTD-RUNに変更する。

スレッド制御部２０内のリソース制御インタフェース部２２は、リソース制御部１０内のスレッド配分決定部１３から”スレッド割当通知”を受信する。前述のように、スレッド割当通知は、性能保証型タスク３０とリソース制御部１０の間のタスク間通信で行われる。

スレッド割当通知の内容がＮ個の高優先スレッド割当の場合、リソース制御インタフェース部２２は、スレッドプール制御部２３に指示してスレッドプール２４からＮ個のスレッドを取り出して性能保証区間３１の実行に用いる（図５ Ｓ２０７）。すなわち、次のステップＳ１０からＳ１３が順に実行される。

ステップＳ１０： スレッドプール制御部２３は、性能保証区間３１の開始点アドレスと、性能保証区間３１の実行に必要なその他のパラメータをスレッド開始パラメータ２５に記入する。

ステップＳ１１： スレッドプール制御部２３は、スレッド状態表２６を参照して、現在実行中ではないスレッド数を調べる。現在実行中ではないスレッドがＮ個未満であれば、スレッドプール制御部２３は、ＯＳ３５を呼び出して新規に高優先スレッドを生成し、現在実行中ではないスレッドが延べＮ個以上になるようにする。

ステップＳ１２： スレッドプール制御部２３は、スレッド状態表２６を参照して、現在実行中ではないＮ個のスレッドを選び、それら選ばれたＮスレッドの実行を再開させる。これにより、各スレッドは、スレッド開始パラメータ２５に記入されたパラメータを用い、同様にスレッド開始パラメータ２５の中に記入された開始点アドレスから、その実行が再開される。

他方、リソース制御インタフェース部２２が受信したスレッド割当通知の内容がＮ個の通常スレッド割当であった場合、次のステップＳ１５からＳ１６が順に実行される。

ステップＳ１５： リソース制御インタフェース部２２は、スレッドプール制御部２３に指示して、ＯＳの通常スレッドＮ個を用いて性能保証区間３１を実行させる。すなわち、スレッドプール制御部２３は、性能保証区間３１の開始点アドレスと、性能保証区間３１の実行に必要なその他のパラメータをスレッド開始パラメータ２５に記入し、ＯＳ上で生成したＮ個のスレッドに前記開始点アドレスからの実行を開始させる。

ステップＳ１６： スレッドプール制御部２３は、さらに、上記で生成したＮ個のスレッドを識別するスレッドＩＤ（のべＮ個）をスレッド状態表２６に記録する。

このようにして、タスク側で性能保証区間の実行開始時点でリソース制御部１０が必要なスレッド割当数を決定する。そして、その決定数に基づいて、当該タスクは、高優先スレッド又は通常スレッドが割り当てられ、実行される（図５ Ｓ２０８）。

次に、図６を参照して、性能保証区間の処理が終了するときの動作、すなわち、ある性能保証型タスク３０−１ａがその性能保証区間の実行から抜け出す際の動作を説明する。

性能保証区間の終了点において、性能保証区間の実行に割り当てられたスレッドがそのうちの一つを除きすべて終了すると、性能保証型タスク３０−１ａはタスクインタフェース部２１−１ａに対し、”性能保証区間終了通知”を送信する（図６のＳ２２１）。性能保証区間終了通知には、性能保証区間を識別するための区間名がパラメータとして含まれる。タスクインタフェース部２１ａはリソース制御部インタフェース２２ａを通じ、”性能保証区間終了通知”をリソース制御部１０に送信する（図６ Ｓ２２２）。

リソース制御部１０では、スレッド要求量決定部１１ではなく、スレッド配分決定部１３が前記で送信されてきた”性能保証区間終了通知”を受信し、タスク状態表１４を参照して関係タスクのスレッド配分を変更する（図６ Ｓ２２３）。図８を参照しながらこのスレッド配分決定部１３の動作を説明する。

ステップＳ３０１、Ｓ３０２： 当該性能保証区間に対するタスクを得、タスク状態表１４の中で前記タスクのＩＤに合致するエントリＬを探す。通常、ただ一つのエントリが合致するはずであるが、複数合致あるいは合致しない場合は無効な通知として無視するか適切なエラーを出力する。

ステップＳ３０３： 上記で見つかったエントリＬ中のスレッド要求量欄の値をＮdecとする。Ｎdecは当該タスクに割り当てられていたスレッド数である。

ステップＳ３０４： ステップＳ３０１で見つかったエントリＬ中の状態欄の値を調べる。値がPRIO-RUNである場合、高優先スレッドの再割当探索を行う。（以下のステップＳ３０５〜ステップＳ３１２）状態欄の値がPRIO-RUNであるエントリにおけるスレッド要求量の値Ｎdecは、性能保証区間の実行から抜け出したために性能保証型タスク３０−１ａにとっては不要となり、リソース制御部１０へ返却される高優先スレッドの数を意味する。そして、返却されたスレッドは、他の性能保証型タスクから要求があったときに、リソース制御部１０によって、再割当のために使用される。

ステップＳ３０５： ステップＳ３０１で見つかったエントリＬの状態欄にWAITと記入する。

ステップＳ３０６、Ｓ３０７： タスク状態表１４の中で、エントリの状態欄の値がPRIO-RUN（高優先実行中）であるエントリすべてを探し、それらのエントリの要求スレッド数欄の値の総和Ｎoldを求める。これを用いて、システム内の空き高優先スレッド数 Ｎfree＝Ｎall−Ｎold＋Ｎdec を計算する。

ステップＳ３０８、Ｓ３１０： タスク状態表１４の中で、状態欄の値がSTD-RUNであり、スレッド要求数欄の値がＮfree未満のエントリすべてを探し、そのうちスレッド要求数欄の値が最大であるエントリＮを特定する。そのエントリＮのタスクを以後性能保証型タスク３０−１ｂと呼ぶ。またこのエントリＮのスレッド数要求数欄の値をＮincとする。

ステップＳ３１１： ステップＳ３１０で見つかったエントリＮのタスクＩＤ欄に記載された性能保証型タスク３０−１ｂに対し、”高優先スレッド再割当通知”を送信する。すなわち、当該性能保証型タスク３０−１ｂに連結されたスレッド制御部２０ｂに対し、Ｎinc個の高優先スレッドが再割当された旨の”スレッド割当通知”を送信する（図６ Ｓ２２４）とともに、前記エントリＮの状態欄の内容をPRIO-RUNに変更する。

ステップＳ３１２： Ｎfreeの値をＮincだけ減じる。新たなエントリが見つからなくなるまで、ステップＳ３０８〜ステップＳ３１２を繰り返す。

ステップＳ３２０、Ｓ３２１： ステップＳ３０１で見つかったエントリＬ中の状態欄の値がSTD-RUNである場合は、その状態欄にWAITと記入するのみで、高優先スレッド再割当は行わない。状態欄の値がSTD-RUNであるエントリは、当該タスクには通常スレッドが割り当てられていたことを意味する。従って、優先スレッドの再割当は行わない。

上記ステップＳ３１１で高優先スレッド再割当が行われた場合、性能保証型タスク３０−１ｂのスレッド制御部２０ｂ内のリソース制御インタフェース部２２ｂが”スレッド割当通知”を受信し、ただちにその内容をスレッドプール制御部２３ｂに伝える（図６ Ｓ２２５）。その通知内容には、再割当高優先スレッド数Ｎincが含まれている。

スレッドプール制御部２３ｂは、スレッド状態表２６ｂを参照し、性能保証型タスク３０−１ｂの性能保証区間３１ｂの実行のために通常スレッドが割り当てられており、そのスレッド数がＮincに等しいことを確認する。それが確認できれば、スレッドプール制御部２３ｂは、前記Ｎinc個の通常スレッドの実行属性を高優先に変更する（図６ Ｓ２２６）。この変更は通常、ＯＳ３５に対してスレッドのスケジューリングパラメータや優先度パラメータを再設定することで行うことができる。その際に必要となるスレッドＩＤはスレッド状態表２６ｂに記録されているものを使用する。

性能保証型タスク３０が終了する際、性能保証型タスク３０はタスクインタフェース部２１に対し”タスク終了通知”を送信する。タスクインタフェース部２１は、”タスク終了通知”を受信すると、スレッドプール制御部２３に対し全スレッドの終了を指示する”スレッド割当通知”を送信するとともに、リソース制御インタフェース部２２に対して性能保証型タスク３０の終了を通知するために”タスク終了通知”を送信する。

スレッドプール制御部２３は”スレッド終了指示”を受信すると、スレッド状態表２６とスレッドプール２４を参照し、スレッド制御部で生成したすべてのスレッドを終了させる。

リソース制御部１０は、リソース制御インタフェース部２２から性能保証型タスク３０の”タスク終了通知”を受信すると、スレッド配分決定部１３に指示して、タスク状態表１４から性能保証型タスク３０に対応するエントリを抹消させる。

以上のように、本実施形態のタスク配分システムは、性能保証型タスクから必要な処理性能や予定されている負荷量についての情報を受け取る。そして、本実施形態のタスク配分システムは、スレッドの割当数とそのときの処理性能との対比情報及び現在のスレッド割当状況を基に、性能保証型タスクへのスレッドの割当量を決定する。

ところで、本実施形態において割り当てられるスレッドは、タスクの処理に用いられる「リソース」の一種であって、割り当てられるリソースはスレッドには限定されない。すなわち、本実施形態は、タスクに割当可能で、割当量に依存してタスクの処理性能が変化するような有限リソース一般に適用可能である。このようなリソースには、プロセッサ関連としては、スレッドの他に、プロセッサコアの個数がある。メモリ関連では、単純なメモリ使用量や、キャッシュメモリ割当量も、上記のようなリソースである。あるいは、タスクがネットワークを使用する場合にはネットワークの帯域幅も、割当可能であり、タスクの処理性能に影響を与えるリソースである。

また、本実施形態のリソース配分システムは、タスクへのリソース割当とタスクからの不要リソース回収の機能を備えればよく、タスク自体は、本実施形態のリソース配分システム内に備えられている必要はない。また、スレッド制御部２０やＯＳ３５も、リソース配分システム内に備えられている必要はない。従って、図１のリソース配分システムは、図７のリソース配分システム１００のように簡略化できる。図７は、第１の実施形態のリソース配分システムの最小構成を示すブロック図である。リソース配分システム１００は、図１におけるリソース制御部１０において、スレッドをリソースに一般化したものに相当する。

リソース配分システム１００は、リソース要求量決定部１１、リソース−性能対応情報１２、タスク状態表１４、リソース配分決定部１３を備える。

性能情報保持部１０２は、スレッド−性能対応表１２に相当する。性能情報保持部１０２は、割当仮定量と、性能保証型タスクにその割当仮定量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報を保持する。割当仮定量とは、性能保証区間の処理のために、当該性能保証型タスクへ割り当てられたと仮定されたリソースの量である。実際に割り当てられるリソースの量は、後述のように、リソース配分決定部１０３が決定する。なお、性能情報保持部１０２が保持するリソース−性能対応情報は、表形式に配置された情報には限定されない。すなわち、リソース−性能対応情報は、割当仮定量とその量のリソースが割り当てられたときの処理性能との関係を規定する情報であればよい。従って、リソース−性能対応情報は、例えば、割当仮定量と処理性能との関係を規定する関数であってもよい。

リソース要求量決定部１０１は、スレッド要求量決定部１１に相当する。リソース要求量決定部１０１は、外部の性能保証型タスクから、性能保証区間の実行開始前に、処理完了時間要求値及び予定処理負荷量を受信する。そして、リソース要求量決定部１０１は、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である要求リソース量を決定する。また、リソース要求量決定部１０１は、性能保証区間に対して実際に割り当てられることが決定したリソースの量である割当リソース量を性能保証型タスクに通知する。

タスク状態保持部１０４は、タスク状態表１４に相当する。タスク状態保持部１０４は、ある性能保証型タスクに現在割り当てられているリソースの量を表す割当済リソース量を保持する。

リソース配分決定部１０３は、割当対象となりうるリソースの総量である全リソース量、割当要求リソース量及び割当済リソース量に基づいて割当リソース量を決定する。全リソース量は、Ｎallに相当する量であり、割当対象として取り扱うことができるリソースの全体量である。従って、全リソース量は、ある時点において、常にその量が割当可能であるとは限らない。そこで、リソース配分決定部１０３は、全リソース量と割当済リソース量とから割当可能なリソースの量を判断し、割当要求リソース量のリソースを割当可能か否かを判定する。そして、リソース配分決定部１０３は、実際に割り当てるリソース量、すなわち、割当リソース量を決定する。そのため、割当リソース量が０であることもありうる。

リソース配分システム１００は、スレッドのみでなく、タスクに割当可能で、割当量に依存してタスクの処理性能が変化するようなリソースを、性能保証型タスクに配分する。リソース配分システム１００の処理は、スレッドの割当を例として説明した、図１のリソース配分システムと同じなので、詳細な説明は省略する。

なお、リソース配分システム１００は、ハードウェアによって実現されても、ソフトウェアによって実現されてもよい。ソフトウェアによってリソース配分システム１００が実現される場合は、本システムを適用するコンピュータシステムが備える所定のＣＰＵ（図示なし）によって、リソース配分プログラムが実行される。プログラムの処理手順は、図８に示した通りである。

リソース配分プログラムは、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等の半導体記憶装置、光ディスク、磁気ディスク、光磁気ディスク等、非一時的な媒体に格納されてもよい。

次に、本実施形態の効果について説明する。

本実施形態では、タスクがリソース制御部に対し予定処理負荷量と処理完了時間の要求値を伝える。リソース制御部はその性能要件を満たすのに必要な最小限のスレッド数を決定する。タスクのスレッド制御部は、その決定に沿ってスレッドを開始し、並列処理を行う。そのため、タスクに要求される処理性能を達成することができる。さらに、あるタスクに過剰なスレッドを割り当てることによる他タスクの性能低下を招く可能性が抑えられる。

また、本実施形態では、性能保証が必要な部分の実行を終えたときには、割り当てられていたスレッドがリソース制御部に返却され、必要としている他のタスクへのスレッド再割当をただちに行う。そのため、スレッドリソースは必要なタスクに速やかに配分される。従って、タスクへの要求性能が実際に達成される可能性を高めることができる。
（第２の実施形態）
本発明を実施するための第２の実施形態について説明する。

第１の実施形態では、スレッド制御部２０は、高優先スレッドはスレッドプール２４で管理し、通常スレッドはそのたびにＯＳに依頼して生成する。これは、本発明では、システム内に存在する実行中の高優先スレッドの数とそれらの割り当て方を正確に管理するためである。他方、スレッドプールは、スレッドを生成するときのオーバヘッドを減らすという長所を持つ。

そこで、第２の実施の形態として、高優先スレッドに加え、通常スレッドもスレッドプールで管理する方式を示す。すなわち、初期化時には一定数の高優先スレッド及び一定数の通常スレッドを生成して、両者ともスレッドプール２４の管理下に置く。スレッドプール制御部２３は、スレッド配分決定部１３からのスレッド割当通知が高優先スレッド割当か通常スレッド割当かによって、スレッドプール２４の管理下にある高優先スレッドあるいは通常スレッドを選択する。選択されたスレッドは、性能保証区間３１の実行に使用される。

このような実施形態をとることにより、高優先スレッドの割当に成功するか否かにかかわらず、ほぼ一定コストで並列処理を開始できる。

第２の実施形態を採用する際に留意すべき点は、第１の実施形態に比べ、ＯＳ上で生成される総スレッド数が多くなるため、ＯＳにおけるスレッド管理オーバヘッドが増える可能性がある点である。そのため、スレッド制御部２０内のスレッドプールのオーバヘッドとＯＳによるシステム内の全スレッドの管理オーバヘッドのトレードオフを鑑みて、第１の実施形態と第２の実施形態のうち、適切な方を選ぶのがよい。
（第３の実施形態）
本発明を実施するための第３の実施形態について詳細に説明する。

本実施形態は、第１の実施形態の変形であるが、第２の実施形態と組みあわて実施されることも可能である。

第１の実施形態では、スレッド配分決定部１３は、新たなスレッド要求が承諾されない場合、要求元タスクに対して、高優先スレッドではなく通常スレッドを割り当てる。この割当は、必ずしも要求元タスクの性能が満たされる保証はないが、ベストエフォートで処理を進めておくことが望ましいとの考え方に基づくものである。

別の方式として、要求された個数の高優先スレッドが割り当てられない場合は割当を一時保留し、のちに割当可能になった時点で要求された個数の高優先スレッドを割り当てる、という方式もある。この場合、新たな”スレッド要求通知”を受信した際のスレッド配分決定部１３の動作は次のようになる。

スレッド要求量決定部１１から新たな”スレッド要求通知”を受信すると、スレッド配分決定部１３は、タスク状態表１４に新たなエントリを設ける。そして、スレッド配分決定部１３は、そのタスクＩＤ欄及び要求スレッド数欄に、スレッド要求通知に記載されていたタスクＩＤ及びスレッド数（その値をＮincとする）を転記するとともに、その状態欄にWAITと記入する。

次に、スレッド配分決定部１３は、タスク状態表１４の中で、状態欄の値がPRIO-RUNであるすべてのエントリを探し、それらのエントリの要求スレッド数欄の値の総和（その値をＮoldとする）を求める。

もし Ｎold＋Ｎinc＜Ｎall であれば、今回の新たなスレッド要求は承諾される。すなわち、スレッド配分決定部１３は、当該タスクに連結されたスレッド制御部２０に対し、Ｎinc数の高優先スレッドが割り当てられた旨の”スレッド割当通知”を送信する。さらに、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をPRIO-RUNに変更する。

もし Ｎold＋Ｎinc≧Ｎall であれば、今回の新たなスレッド要求は一時保留される。このとき、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をREADY（実行可能）に変更する。この場合、スレッド制御部２０へは何も通知されない。

スレッド制御部から”性能保証区間終了通知”を受信すると、スレッド配分決定部１３は以下の手順Ｓ３３１からＳ３３６を実行する。

ステップＳ３３１： 当該性能保証区間が設定されたタスクを特定し、タスク状態表１４の中でそのタスクのＩＤに合致するエントリＬを探す。このとき、唯一のエントリが合致するのが正常である。複数のエントリが合致する場合、あるいは合致するエントリがない場合は、当該性能保証区間終了通知が無効な通知として無視されるか、適切なエラーが出力される。

ステップＳ３３２： ステップＳ３３１で発見されたエントリＬ中のスレッド要求量欄の値をＮdecとする。この値は当該タスクに割り当てられているスレッド数である。

ステップＳ３３３： ステップＳ３３１で発見されたエントリＬの状態欄にWAITと記入する。

ステップＳ３３４： タスク状態表１４の中で、状態欄の値がREADYであり、スレッド要求数欄の値がＮdecを越えないエントリすべてを探し、そのうちスレッド要求数欄の値が最大であるエントリＮを特定する。そのエントリＮのスレッド数要求数欄の値をＮincとする。

ステップＳ３３５： 上記で見つかったエントリＮのタスクＩＤ欄に記載されたタスクに対し、高優先スレッドが割り当てられた旨の”スレッド割当通知”を送信するとともに、前記エントリＮの状態欄の内容をPRIO-RUNに変更する。

ステップＳ３３６： Ｎdecの値をＮincだけ減じる。新たなエントリが見つからなくなるまで、ステップＳ３３４〜ステップＳ３３６を繰り返す。

なお、第３の実施形態におけるスレッド制御部２０の動作は、第１の実施形態に記載した内容と同じである。

第３の実施形態では、タスクが性能保証区間の実行に必要とする分のリソースが確保できないときは、当該区間の実行が延期され、のちにリソース確保された段階で当該区間に対し必要分のリソースが割り当てられたうえで実行開始される。そのため、性能保証区間の開始から終了までの実行性能は要求通りであることが保証される、という新たな効果が得られる。
（第４の実施形態）
次に、具体例を用いて、本発明を実施するための実施形態の動作を説明する。

第４の実施形態のタスク配分システムでは、ＯＳとしてＬｉｎｕｘ（登録商標）が使用され、各タスクはＬｉｎｕｘ上のスレッドあるいはプロセスとして実現される。リソース制御部１０はＬｉｎｕｘ上の一つのプロセスであるリソース制御プロセスとして、スレッド制御部２０はＬｉｎｕｘプロセスにリンクするスレッド制御ライブラリとして実現される。

スレッド制御ライブラリは次の関数エントリをタスク向けに公開する。
(1) スレッド制御部初期化関数： パラメータなし
(1)−1： リソース制御プロセスとの間のプロセス間通信を確立し、リソース制御プロセスからのメッセージを処理する受信スレッド（後述）を生成し開始する。

(1)−2： リソース制御プロセスから指示された個数、Ｌｉｎｕｘ環境変数から取得した値、又はスレッド制御ライブラリの設計時のデフォルト値を基に、一定個数の、高優先スレッド及び通常スレッドを生成する。

ここでのスレッドにはpthread (POSIXスレッド) を使用し、高優先スレッドは、pthreadのスレッド属性で、スケジューリングポリシーとして”リアルタイムスケジューリング”を指定することで実現する。
(2) 性能保証区間開始： パラメータ＝区間名, 予定処理負荷量, 完了時間要求値
以下の情報の組をリソース制御プロセスに送信する。

（区間開始, 自プロセスＩＤ, 区間名, 予定処理負荷量, 完了時間要求値）
ここで一つめの情報である「区間開始」とは、リソース制御プロセスに送信されるコマンドの一つである。

また、「区間名」は、性能保証区間の各々に対して当該プログラムの開発者又は言語処理系が付与した整数値であり、一つのプロセス内でユニークであれば任意の値でよい。
(3) 性能保証区間終了： パラメータ＝区間名
以下の情報の組をリソース制御プロセスに送信する。

（区間終了, 自プロセスＩＤ, 区間名）
(4) スレッド制御部終了処理関数： パラメータなし
(4)−1： 上記(1)−2で生成した全スレッドの終了を確認し、未終了のものは強制終了させる。

(4)−2： リソース制御プロセスに対し以下の情報の組を送信する。

（プロセス終了, 自プロセスＩＤ）
スレッド制御ライブラリは、リソース制御プロセスからのプロセス間通信メッセージを処理する受信スレッドを生成し、実行する。スレッド制御ライブラリの動作はおおむね次の通りである。
(1) リソース制御プロセスからのメッセージ到着を待つ。メッセージ内のコマンド種別により、次の(2)〜(4)に分岐する。
(2) 「高優先スレッド割当」の場合： パラメータ＝スレッド数Ｎ
スレッドプールにある待機中の高優先スレッドからＮ個を選び、性能保証区間の開始点からスレッドの実行を再開させる。もし高優先スレッドがＮ個に満たない場合は、新たに高優先スレッドを生成して上記再開処理を行う。

実行を再開させた各スレッドのスレッドＩＤをスレッド状態表に記録する。
(3) 「通常スレッド割当」の場合： パラメータ＝スレッド数Ｎ
スレッドプールにある待機中の通常スレッドからＮ個を選び、性能保証区間の開始点からスレッドの実行を再開させる。

もし通常スレッドがＮ個に満たない場合は、新たに通常スレッドを生成して上記再開処理を行う。

実行を再開させた各スレッドのスレッドＩＤをスレッド状態表に記録する。
(4) 「高優先スレッド再割当」の場合： パラメータ＝スレッド数Ｎ
スレッド状態表を参照し、実行中の通常スレッドがＮ個あることを確認したうえで、それらの各スレッドに対しpthreadのスレッド属性変更関数を適用し、スケジューリングポリシーを”リアルタイムスケジューリング”に変更する。

リソース制御プロセス、すなわち、リソース制御部１０は、Ｌｉｎｕｘ上の常駐型プロセスとして実装され、他のプロセスにリンクされたスレッド制御ライブラリからプロセス間通信で送信されてくるコマンドの内容に応じた処理を行う。スレッド−性能対応表は、リソース制御プロセス開始時にＬｉｎｕｘ上のファイルから読み込まれ、リソース制御プロセス内のメモリ上データとして保持される。

ここで本実施形態の理解の一助とするために、本実施形態に基づいた動作事例を、時間の流れに沿って具体的に説明する。

システムは次のような構成であるとする。

１２個のプロセッサコア
有効スレッド数 Ｎall＝１２
３つの性能保証型タスクＡ、Ｂ、Ｃ
他に、ベストエフォート型タスクＸ１、Ｘ２、・・・、Ｘｎ
性能保証型のタスクＡ、Ｂ、Ｃは、各々次の性能保証区間を有し、それらの目標処理時間が次のように指定されている。

タスクＡ 性能保証区間SEC-A： 目標処理時間75ms
タスクＢ 性能保証区間SEC-B： 目標処理時間80ms
タスクＣ 性能保証区間SEC-C： 目標処理時間75ms
各性能保証区間に対するスレッド−性能対応表は図９に示す通りである。

処理負荷については、初期状態では、タスクＡ、Ｂ、Ｃともに、通常の処理負荷量を持つが、その後、図１０に示すような処理負荷の変動が発生する動作事例を考える。図１０では、横軸は時刻、縦軸は予定処理負荷量である。

図１１は、タスクＡ、Ｂ、Ｃのそれぞれの予定処理負荷量が図１０のように変化したときの、タスク状態表の内容の変化を示す。図１２乃至図２０は、タスクＡ、Ｂ、Ｃのそれぞれの性能保証区間SEC-A、SEC-B、SEC-Cにおける、目標処理時間と実際の処理時間を示す。

以下、図１０のタイミングT0からT5のそれぞれにおける動作を順に説明する。
１）時刻T0
時刻T0において、タスクＡは自らの負荷が通常通りであることを把握し、タスクＡ内の性能保証区間SEC-Aの実行を開始する。実行の開始に先立ちタスクＡは、次のパラメータを伴って、タスクＡにリンクされたスレッド制御ライブラリの性能保証区間開始エントリを呼び出す。

区間名＝SEC-A, 予定処理負荷量＝1, 完了時間要求値＝75ms
すると、タスクＡにリンクされたスレッド制御ライブラリは、次のメッセージＭ１をリソース制御プロセスに送信する。

（コマンド＝区間開始, プロセスID＝TID-A, 区間名＝SEC-A, 予定処理負荷量＝1, 完了時間要求値＝75ms）・・・Ｍ１
リソース制御プロセスは、メッセージＭ１を受信し、まず、リソース制御プロセス内のスレッド要求量決定部１１が要求スレッド数を求める。その際、スレッド要求量決定部１１は、図９に示すスレッド−性能対応表内のSEC-Aの対応表を参照し、処理時間に予定処理負荷量である１を乗じた値が、処理完了時間要求値である75を下回るものとして、スレッド数＝２を見つける。これにより、スレッド要求量決定部は要求スレッド数をＮinc＝２と決定する。

次に、リソース制御プロセス（リソース制御部１０）内のスレッド配分決定部１３が、タスクＡへのスレッド割当を決定する。メッセージＭ１の到着直前のタスク状態表（図１１（a））では、タスクＩＤは登録されていない。従って、
高優先実行中（PRIO-RUN)のタスクへのスレッド配分数Ｎold＝０
であり、
有効スレッド数Ｎall＝１２
であるから、
Ｎold＋Ｎinc＜Ｎall
となり、タスクＡには要求通り高優先スレッドが２個割り当てられる。これによりタスク状態表は図１１（b）のようになる。

また、スレッド配分決定部はタスクＡのスレッド制御ライブラリに対し次のメッセージＭ２を送信する。

（高優先スレッド割当 スレッド数＝２）・・・Ｍ２
メッセージＭ２を受信し、タスクＡのスレッド制御ライブラリはスレッドプールから２個の待機中高優先スレッドを選び、それらのスレッドに性能保証区間SEC-Aの実行を開始させる。

このように、タスクＡ側で、性能保証区間SEC-Aの開始時にリソース制御プロセスにスレッド割当数を問い合わせる。そして、リソース制御プロセスによる２個の高優先スレッドの割当の決定を受けて、タスクＡでは性能保証区間SEC-Aを２スレッドでの並列実行を開始する。この状態を図１２（a）に示す。ここで点線は目標処理時間、実線は実際の処理時間を表す。すなわち、SEC-Aでは、目標処理時間75msに対し、２スレッドでの実行により50msで処理が終了している。

システム内には合計２４個のスレッドが生成され、SEC-A以外の期間及び表示された以外のスレッドでは、ベストエフォート型タスクＸ１〜ＸｎからＯＳによって選択されたタスクがベストエフォートで実行される。

図１０の例では、時刻T0では、タスクＡに加え、タスクＢ及びタスクＣもそれぞれの性能保証区間の実行が開始される。そこで、上記と同様に、タスクＢ及びタスクＣのスレッド制御ライブラリはリソース制御プロセスに対し次のメッセージＭ３、Ｍ４を送信する。

（コマンド＝区間開始, プロセスID＝TID-B, 区間名＝SEC-B, 予定処理負荷量＝1, 完了時間要求値＝80ms）・・・Ｍ３
（コマンド＝区間開始, プロセスID＝TID-C, 区間名＝SEC-C, 予定処理負荷量＝1, 完了時間要求値＝75ms）・・・Ｍ４
リソース制御プロセスは、まずSEC-Bに関するメッセージＭ３を処理する。

図９のスレッド−性能対応表より、SEC-B実行に必要なスレッド数は１であり、要求スレッド数Ｎinc＝１となる。

図１１（b）のタスク状態表より、高優先実行中タスクへのスレッド配分数Ｎold＝２であるから、スレッド配分決定部は、タスクＢに対し、要求通り高優先スレッドを１個だけ割り当てる判断を下す。そして、スレッド配分決定部は、タスクＢのスレッド制御ライブラリに対して、
（高優先スレッド割当 スレッド数＝１）・・・Ｍ５
とのメッセージＭ５を送信し、タスクＢにてSEC-Bが１スレッドで実行が開始される。

リソース制御プロセスは引き続きSEC-Cに関するメッセージＭ４を処理する。図９のスレッド−性能対応表より、SEC-C実行に必要なスレッド数は２であるから、Ｎinc＝２となる。高優先実行中タスクへのスレッド配分数Ｎold＝３であるから、スレッド配分決定部はタスクＣに対し要求通り高優先スレッドを２個だけ割り当てる判断を下す。そして、スレッド配分決定部は、タスクＣのスレッド制御ライブラリに対して、
（高優先スレッド割当 スレッド数＝2）・・・Ｍ６
とのメッセージＭ６を送信し、タスクＣにてSEC-Cが２スレッドで実行が開始される。

ここまでで、タスク状態表は図１１（c）のように更新される。図１２（b）は、このときの性能保証区間各々の実行の様子を示す。SEC-A, SEC-B, SEC-Cには各々２スレッド, １スレッド, ２スレッドが割り当てられ、いずれも目標処理時間以下で処理が行われている。
２）時刻T1
時刻T1でタスクＡがSEC-Aを実行しようとするとき、タスクＡは自らの負荷が通常の２倍であることを認知し、タスクＡのスレッド制御ライブラリはリソース制御プロセスに次のメッセージＭ７を送信する。

（コマンド＝区間開始, プロセスID＝TID-A, 区間名＝SEC-A, 予定処理負荷量＝2, 完了時間要求値＝75ms）・・・Ｍ７
リソース制御プロセスは、予定処理負荷量＝２であることから、SEC-A実行にはスレッド数３が必要と認識する。このときタスクＢ、Ｃは性能保証区間SEC-B, SEC-Cの前回実行を終えているから、この時点での高優先実行中タスクへのスレッド配分数Ｎold＝０である。従って、リソース制御プロセスはSEC-Aに要求通り３スレッドを割当することを決定する。

続いて、時刻T1でタスクＢ、Ｃもそれぞれ性能保証区間SEC-B, SEC-Cの実行を新たに開始しようとする。これらの予定処理負荷量はいずれも１である。上記でSEC-Aに３スレッド割り当ててＮold＝３であるから、SEC-B, SEC-Cには要求どおり１, ２スレッドを割当可能と判断する。これによりタスク状態表は図１１（d）のように更新される。

図１３は、このときの性能保証区間各々の実行の様子を示す。タスクＡでは負荷が２倍になったが、割当スレッド数が３に増加したことによって目標処理時間以内に処理を終了している。
３）時刻T2
時刻T2では、タスクＡの負荷が２倍のままであることに加え、タスクＢの負荷が５倍となる。リソース制御プロセスはタスクＢの要求スレッド数を６と認識し、要求スレッド数の総和が有効スレッド数Ｎall未満に収まることを確認したうえで、タスクＢに対し要求通り６つの高優先スレッドを割り当てる。またタスクＣに対しては直近と同じく、要求どおり２スレッドを割当可能と判断する。このときのタスク状態表は図１１（e）に、実行の様子は図１４に示されている。
４）時刻T3
時刻T3では、タスクＡの負荷が通常レベルに戻るが、タスクＢの負荷は若干低下するも依然通常の４倍あり、タスクＣの負荷は通常の２倍に増加する。このとき、リソース制御プロセスはタスクＡ、タスクＢ、タスクＣの要求スレッド数を各々２、５、４と算出するが、これらの総和がＮall未満に収まることから、各タスクに対し要求数どおりの高優先スレッドを割り当てる決定を下す。このときのタスク状態表は図１１（f）に、実行の様子は図１４に示されている。
５）時刻T4
時刻T4では、タスクＡの負荷が再び２倍に増加する。リソース制御プロセスはタスクＡからの要求スレッド数は３スレッドと認識する（すなわちＮinc＝３）。ところが、直前のSEC-B, SEC-C開始により既にSEC-B, SEC-Cに合計９個の高優先スレッドを割り当てているため（すなわちＮold＝9）、Ｎold＋Ｎinc≧Ｎall となる。そのため、リソース制御プロセスは、タスクＡへの高優先スレッド割当はできず、通常スレッドの割当を決定する。このとき、タスク状態表は図１１（g）のように更新される。そして、リソース制御プロセスからタスクＡのスレッド制御ライブラリへは次のメッセージＭ８が送信される。

（通常スレッド割当 スレッド数＝３）・・・Ｍ８
これにより、タスクＡの性能保証区間SEC-Aは、通常の優先度しか持たない３つのスレッドにより実行される。これらのスレッドはベストエフォート型タスクＸ１、Ｘ２、・・・、Ｘｎを実行するスレッドとＣＰＵリソースを共有するため、SEC-Aの実行性能は必ずしも保証されない。しかし、これは、既に実行中の性能保証区間SEC-B及びSEC-Cの実行性能を引き続き保証するためにやむを得ない措置と判断される。そこで、リソース制御プロセスは、SEC-Aに対して性能保証できなくなった旨のメッセージをログに記録する、あるいは制御コンソールに出力する等の、異常発生時の所定の処理を行う。

時刻T4の直後、タスクＣの性能保証区間SEC-Cが一旦終了すると、タスクＣからリソース制御プロセスへ次のメッセージＭ９が送信される。

（コマンド＝区間終了, プロセスID＝TID-C, 区間名＝SEC-C）・・・Ｍ９
リソース制御プロセス内のスレッド配分決定部は、タスク状態表（図１１（g）の状態にある）を参照し、SEC-Cに割り当てられていた高優先スレッドが２個であったことを知る（Ｎdec＝２）。SEC-C以外の高優先スレッド数の合計Ｎold＝５であり、Ｎfree＝１２−５＋２＝９であるから、タスク状態表内のタスクＡに対するエントリ（TID-Aの行）が高優先スレッドの再割当先となる。すなわち、スレッド配分決定部は、通常スレッド３つが割り当てられていたタスクＡに対し高優先スレッド３個を再割当することを決定し、タスク状態表を図１１（h）のように更新するとともに、タスクＡのスレッド制御ライブラリに対し
（高優先スレッド再割当 スレッド数＝３）・・・Ｍ１０
なるメッセージＭ１０を送信する。

メッセージＭ１０を受信し、タスクＡのスレッド制御ライブラリはSEC-Aを実行している各スレッドのスレッド属性を”リアルタイムスケジューリングポリシー”に変更する。すなわち、タスクＡの性能保証区間SEC-Aには本来必要な数の高優先スレッドが割り当てられ、以後性能保証された形で実行される。このときの実行の様子を図１５に示す。
６）時刻T5
時刻T5にて、タスクＣが再び通常負荷で性能保証区間SEC-Cを開始すると、リソース制御プロセスは前記手順に沿って、SEC-Cに対し高優先スレッド２個を割り当てることを決定する。このときのタスク状態表を図１１（i）に示す。

このように、本実施形態によれば、処理負荷の変動に応じてスレッド割当を動的に変化させ、各処理に常に適切なＣＰＵリソースを配分する。従って、指定された箇所の処理時間が所定の時間内に収まるようにできるとともに、空いたＣＰＵリソースは他のベストエフォート型処理に最大限振り向けることができる。

以上、スレッドと処理時間との対応が図９の通りで、予定処理負荷量が図１０のように変化したときの、タスク状態表の内容の変化及び各期間における目標処理時間と実際の処理時間について説明した。

ここで比較の対象として、適切なスレッド配分を行わなかった場合の動作例を示してみる。

第４の実施形態として先の動作事例にあげたものと同じシステム及びタスク構成を想定するが、今回は、性能保証型タスクＡ、Ｂ、Ｃに対して最初から十分な数のスレッドを割り当てておいた場合をとりあげる。図９のスレッド−性能対応表に示すように、タスクＡ、Ｂ、Ｃの各性能保証区間は最大６スレッドによる並列処理が可能であるから、各タスクには６スレッドずつ固定的に割り当てておく。

この場合、システム内には性能保証型タスク向けだけで計１８個のスレッドがあり、ベストエフォート型タスク向けも含めれば、１８個以上のスレッドが存在する。これらのスレッドには物理的なＣＰＵコアリソースがＯＳによって平均化されて割り当てられる。先の動作事例ではＮall＝１２すなわちシステム内には１２個のスレッドのみが存在するとしたが、今回は１８個以上のスレッドが存在するため、各スレッドに割り当てられるＣＰＵコアリソースは平均的に１２÷１８すなわち３分の２以下となる。そのため、各性能保証区間の実行時間も図９に示す値の１．５倍（３分の２の逆数）以上になる。

時刻T0での各性能保証区間の実行の様子を図１７に示す。本発明技術の適用時の時刻T0での実行の様子（図１３）に比べ、各処理は短時間に完了しており、低負荷状態では低レイテンシで処理が行われている。

同様に時刻T1での実行の様子を図１８に示す。時刻T2での実行の様子を図１９に示す。高負荷になったタスクＢは、所定の時間内に処理が終えられなくなっている。

また時刻T3での実行の様子を図１９に示す。ここでも高負荷状態のタスクＢ及びタスクＣは所定の時間内に処理が終えられなくなっている。これは、各タスクに対し必要以上のスレッドを割り当てた結果、タスクの並列処理効率が低下してＣＰＵコアリソースが無駄に消費されてしまい、真に急ぐべきタスクの処理が間に合わなくなっていることを意味する。

このように、単純に潤沢な数のスレッドを割り当てておくだけでは、負荷変動が生じた際に性能保証できなくなる場面が出てくる。

本実施形態のリソース配分システムは、最適なスレッド配分を通じて最適なＣＰＵコアリソースの配分を行うことで、負荷変動が生じても性能保証できる可能性を高め、万一性能保証できない場合もその旨を警告する機能を提供するものである。

なお、以上の実施形態は、各々の全体又は一部を、他の実施形態と組み合わせることができる。

１２ スレッド−性能対応表
１２１、１２２、１２３ スレッド−性能対応表エントリ
１４ タスク状態表

Claims (6)

1. タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のために前記タスクへ割り当てられたと仮定されたリソースの量である割当仮定量と、前記タスクに前記割当仮定量のリソースが割り当てられたときの前記性能保証区間における処理性能との対応関係を表すリソース−性能対応情報を保持する性能情報保持部と、
   前記性能保証区間を有する性能保証型タスクから、前記性能保証区間の実行開始前に、前記性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び前記性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、前記処理完了時間要求値、前記予定処理負荷量及び前記リソース−性能対応情報に基づいて前記性能保証区間の処理に用いるリソースの要求量である要求リソース量を決定し、前記性能保証区間に対して前記要求リソース量のリソースが割り当てられたことを示す割当通知を前記性能保証型タスクに送信するリソース要求量決定部と、
   前記性能保証型タスクに現在割り当てられているリソースの量を表す割当済リソース量を保持するタスク状態保持部と、
   割当対象となりうるリソースの総量である全リソース量、前記要求リソース量及び前記割当済リソース量に基づいて、前記性能保証区間に対する前記要求リソース量のリソースの割当の可否を決定するリソース配分決定部と、
   を備え、
   前記処理性能は処理時間である
   ことを特徴とするリソース配分システム。
2. 前記リソース配分決定部は、前記割当済リソース量と前記要求リソース量との合計と、全リソース量との比較結果に基づいて前記割当の可否を決定する
   ことを特徴とする請求項１記載のリソース配分システム。
3. 前記リソース配分決定部によって割当が決定されたリソースは、通常のスレッドより高い優先度を与えられた高優先スレッドであり、
   前記性能保証区間の実行開始に先立って生成された所定の数の前記高優先スレッドを待機させるスレッドプールを含み、前記性能保証型タスクからの指示により、前記スレッドプール内の前記高優先スレッドに対する前記性能保証区間の実行の開始を指示する機能、又は前記性能保証区間を実行中のスレッドの優先度若しくはスケジューリング属性を変更する機能を有し、前記リソース要求量決定部に前記予定処理負荷量及び前記処理完了時間要求値とを通知し、前記割当通知に基づき、前記高優先スレッドを用いて前記性能保証区間の実行制御を行うスレッド制御部を備え、
   前記リソース要求量決定部は、前記予定処理負荷量と前記処理完了時間要求値から前記要求リソース量として、前記スレッドプール内の前記高優先スレッドの数を決定する
   ことを特徴とする、請求項１又は２に記載のリソース配分システム。
4. タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のために前記タスクへ割り当てられたと仮定されたリソースの量である割当仮定量と、前記タスクに前記割当仮定量のリソースが割り当てられたときの前記性能保証区間における処理性能との対応関係を表すリソース−性能対応情報、及び前記性能保証区間を有する性能保証型タスクに現在割り当てられているリソースの量を表す割当済リソース量を保持し、
   前記性能保証型タスクから、前記性能保証区間の実行開始前に、前記性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び前記性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、
   前記処理完了時間要求値、前記予定処理負荷量及び前記リソース−性能対応情報に基づいて前記性能保証区間の処理に用いるリソースの要求量である要求リソース量を決定し、
   割当対象となりうるリソースの総量である全リソース量、前記要求リソース量及び前記割当済リソース量に基づいて、前記性能保証区間に対する前記要求リソース量のリソースの割当の可否を決定し、
   前記性能保証区間に対して前記要求リソース量のリソースが割り当てられたことを示す割当通知を前記性能保証型タスクに送信し、
   前記処理性能は処理時間である
   ことを特徴とするリソース配分方法。
5. リソース配分システムが備えるコンピュータを、
   タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のために前記タスクへ割り当てられたと仮定されたリソースの量である割当仮定量と、前記タスクに前記割当仮定量のリソースが割り当てられたときの前記性能保証区間における処理性能との対応関係を表すリソース−性能対応情報、及び前記性能保証区間を有する性能保証型タスクに現在割り当てられているリソースの量を表す割当済リソース量を保持する保持手段と、
   前記性能保証型タスクから、前記性能保証区間の実行開始前に、前記性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び前記性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信する受信手段と、
   前記処理完了時間要求値、前記予定処理負荷量及び前記リソース−性能対応情報に基づいて前記性能保証区間の処理に用いるリソースの要求量である要求リソース量を決定する要求量決定手段と、
   割当対象となりうるリソースの総量である全リソース量、前記要求リソース量及び前記割当済リソース量に基づいて、前記性能保証区間に対する前記要求リソース量のリソースの割当の可否を決定する割当決定手段と、
   前記性能保証区間に対して前記要求リソース量のリソースが割り当てられたことを示す割当通知を前記性能保証型タスクに送信する通知手段
   として機能させ、
   前記処理性能は処理時間である
   ことを特徴とするリソース配分プログラム。
6. 請求項５記載のリソース配分プログラムを記憶した、非一時的なコンピュータ読み取り可能な記憶媒体。

Images