JP2013182502A - Resource allocation system, resource allocation method, and resource allocation program - Google Patents
Resource allocation system, resource allocation method, and resource allocation program Download PDFInfo
- Publication number
- JP2013182502A JP2013182502A JP2012046963A JP2012046963A JP2013182502A JP 2013182502 A JP2013182502 A JP 2013182502A JP 2012046963 A JP2012046963 A JP 2012046963A JP 2012046963 A JP2012046963 A JP 2012046963A JP 2013182502 A JP2013182502 A JP 2013182502A
- Authority
- JP
- Japan
- Prior art keywords
- resource
- performance
- amount
- task
- performance guarantee
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
Description
本発明は、リソース配分システム、リソース配分方法、及びリソース配分プログラムに関し、特にタスクの所定区間における性能保証が可能なリソース配分システム、リソース配分方法、及びリソース配分プログラムに関する。 The present invention relates to a resource allocation system, a resource allocation method, and a resource allocation program, and more particularly to a resource allocation system, a resource allocation method, and a resource allocation program that can guarantee performance in a predetermined section of a task.
複数のタスクを処理するコンピュータシステムでは、各タスクの処理順序や優先度を制御する、いわゆる、「タスクスケジューリング」が行われることがある。 In a computer system that processes a plurality of tasks, so-called “task scheduling” that controls the processing order and priority of each task may be performed.
タスクスケジューリングを行うリソース制御システムの一例が、特許文献１に記載されている。特許文献１のリソース制御システムは、複数のＣＰＵ（Central Processing Unit）コアを有するコンピュータシステム上で複数のメディア処理が行われる際の、タスクスケジューリングを行う技術である。このシステムは、グローバルスケジューラと呼ばれる機能ブロックがタスクの処理順序や優先度を制御し、最終的なメディア処理性能を高めることを目指している。
An example of a resource control system that performs task scheduling is described in
特許文献１には、タスクの実行を優先させる選択基準として、４つのポリシーが例示されている。第１のポリシーは、データの作成時刻を見て、処理のレイテンシの最小化を図るポリシーである。第２のポリシーは、当該タスクの出力に依存している別タスクの数が多いものを優先するポリシーである。第３のポリシーは、当該タスクの入力として必要なデータが揃っていないものを低優先とするポリシーである。第４のポリシーは、キャッシュミスを減らすために、同一のプロセッサによって実行されるスレッドを優先するポリシーである。
特許文献２、３には、プロセスやジョブを処理するための、プロセッサやサーバ等のリソースを予約するシステムが開示されている。
特許文献１の技術の問題点は、メディア処理のように時間当たりの処理性能を一定以上に保つ必要があるシステムにおいても、入力負荷が一時的に増加すると処理性能が低下することである。処理性能が低下すると、システムで求められる最低処理性能を満たせなくなる可能性がある。
The problem of the technology of
なぜなら、一時的な高負荷状態に対し、負荷の増大分に見合う追加演算リソースが配分されないため、高負荷状態における処理に通常より長い時間を要するからである。 This is because, in the temporary high load state, additional calculation resources corresponding to the increase in load are not allocated, and therefore processing in the high load state takes a longer time than usual.
特許文献２、３の技術では、処理が完了すべき時刻や必要な計算量、必要なリソースの量を考慮してリソースの予約を行うことができる。しかし、特許文献２、３の技術にも、入力負荷が一時的に増加した場合に対応できないという、特許文献１の技術と同様の課題がある。
（発明の目的）
本発明の目的は、入力負荷の変動が生じても、タスクの所定区間の処理性能の最低値を保証できるような、リソース配分システム、リソース配分方法及びリソース配分プログラムを提供することにある。
In the techniques of
(Object of invention)
An object of the present invention is to provide a resource allocation system, a resource allocation method, and a resource allocation program that can guarantee a minimum processing performance value in a predetermined section of a task even when an input load fluctuates.
本発明のリソース配分システムは、タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のためにタスクへ割り当てられたと仮定されたリソースの量である第１のリソース量と、タスクに第１のリソース量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報を保持する性能情報保持部と、性能保証区間を有する性能保証型タスクから、性能保証区間の実行開始前に、性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定し、性能保証区間に対して第２のリソース量のリソースが割り当てられたことを示す割当通知を性能保証型タスクに送信するリソース要求量決定部と、性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持するタスク状態保持部と、割当対象となりうるリソースの総量である第４のリソース量、第２のリソース量及び第３のリソース量に基づいて、性能保証区間に対する第２のリソース量のリソースの割当の可否を決定するリソース配分決定部と、を備えることを特徴とする。 The resource allocation system according to the present invention includes a first resource amount that is an amount of a resource assumed to be allocated to a task for processing in a performance guarantee section in which a certain level of processing performance guarantee is required in the task, A performance information holding unit for holding resource-performance correspondence information indicating a correspondence relationship with processing performance in the performance guarantee section when the resource of the first resource amount is allocated to the performance guarantee type task having the performance guarantee section Before the start of the performance guarantee section, the process completion time requirement value indicating the time at which the process of the performance guarantee section should be completed and the scheduled process load amount representing the process load amount scheduled in the performance guarantee section are received and processed. A second resource amount that is a required amount of resources used for processing in the performance guarantee section based on the completion time request value, the scheduled processing load amount, and the resource-performance correspondence information A resource request amount determination unit that sends an allocation notification indicating that a second resource amount resource has been allocated to the performance guarantee section to the performance guarantee type task, and is currently assigned to the performance guarantee type task. Based on the task state holding unit that holds the third resource amount that represents the resource amount, and the fourth resource amount, the second resource amount, and the third resource amount that are the total amount of resources that can be allocated. And a resource allocation determination unit that determines whether or not the second resource amount can be allocated to the guaranteed section.
本発明のリソース配分方法は、タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のためにタスクへ割り当てられたと仮定されたリソースの量である第１のリソース量と、タスクに第１のリソース量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報、及び性能保証区間を有する性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持し、性能保証型タスクから、性能保証区間の実行開始前に、性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定し、割当対象となりうるリソースの総量である第４のリソース量、第２のリソース量及び第３のリソース量に基づいて、性能保証区間に対する第２のリソース量のリソースの割当の可否を決定し、性能保証区間に対して第２のリソース量のリソースが割り当てられたことを示す割当通知を性能保証型タスクに送信することを特徴とする。 The resource allocation method of the present invention includes a first resource amount that is an amount of a resource assumed to be allocated to a task for processing in a performance guarantee section in which a certain level of processing performance guarantee is required in the task, Resource-performance correspondence information indicating a correspondence relationship with the processing performance in the performance guarantee section when the resource of the first resource amount is assigned to the resource, and the resource currently assigned to the performance guarantee type task having the performance guarantee section The third resource amount representing the amount is retained, and from the performance guarantee type task, before the execution of the performance guarantee interval starts, the processing completion time requirement value and the performance guarantee interval representing the time at which the processing of the performance guarantee interval is to be completed A scheduled processing load amount representing a scheduled processing load amount is received, and performance maintenance is performed based on the processing completion time requirement value, the scheduled processing load amount, and the resource-performance correspondence information. A second resource amount that is a required amount of resources used for processing of a section is determined, and based on a fourth resource amount, a second resource amount, and a third resource amount that are total amounts of resources that can be allocated, Deciding whether or not to allocate the second resource amount to the performance guarantee section, and sending an assignment notification indicating that the second resource amount resource has been assigned to the performance guarantee section to the performance guarantee type task It is characterized by.
本発明のリソース配分プログラムは、リソース配分システムが備えるコンピュータを、タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のためにタスクへ割り当てられたと仮定されたリソースの量である第１のリソース量と、タスクに第１のリソース量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報、及び性能保証区間を有する性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持する保持手段と、性能保証型タスクから、性能保証区間の実行開始前に、性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信する受信手段と、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定する要求量決定手段と、割当対象となりうるリソースの総量である第４のリソース量、第２のリソース量及び第３のリソース量に基づいて、性能保証区間に対する第２のリソース量のリソースの割当の可否を決定する割当決定手段と、性能保証区間に対して第２のリソース量のリソースが割り当てられたことを示す割当通知を性能保証型タスクに送信する通知手段として機能させることを特徴とする。 The resource allocation program of the present invention is the amount of resources assumed to have been allocated to a task for processing in a performance guarantee section in which a certain level of processing performance guarantee is required in the task, with the computer provided in the resource allocation system. A performance-guaranteed task having resource-performance correspondence information indicating a correspondence relationship between the first resource amount and the processing performance in the performance guarantee interval when the resource of the first resource amount is assigned to the task, and the performance guarantee interval The time required for the processing of the performance guarantee section to be completed before the execution of the performance guarantee section from the holding means for holding the third resource amount representing the amount of resources currently allocated to the A receiving means for receiving a processing completion time requirement value and a scheduled processing load amount indicating a processing load amount scheduled in the performance guarantee section; Request amount determination means for determining a second resource amount that is a request amount of a resource used for processing in the performance guarantee section based on the completion time request value, the scheduled processing load amount, and the resource-performance correspondence information, and a resource that can be allocated Allocation determining means for determining whether or not to allocate a resource of the second resource amount to the performance guarantee section based on the fourth resource amount, the second resource amount, and the third resource amount that are the total amount of It is characterized by functioning as a notification means for transmitting an allocation notification indicating that a resource of the second resource amount has been allocated to the section to the performance guarantee type task.
本発明のリソース配分システム、リソース配分方法及びリソース配分プログラムによると、入力負荷が変動しても、タスクの所定区間については最低限の処理性能を維持することができる。なぜなら、処理すべき負荷の量に対応して、性能を維持するために必要なリソース量を動的に算出し、それに沿ってリソース配分量を動的に変化させるからである。 According to the resource allocation system, the resource allocation method, and the resource allocation program of the present invention, the minimum processing performance can be maintained for a predetermined section of a task even if the input load varies. This is because the resource amount necessary for maintaining the performance is dynamically calculated according to the amount of load to be processed, and the resource allocation amount is dynamically changed accordingly.
（第１の実施形態）
発明を実施するための形態について図面を参照して詳細に説明する。図１に、本発明の第１の実施形態のリソース配分システムの全体構成のブロック図を示す。
(First embodiment)
DESCRIPTION OF EMBODIMENTS Embodiments for carrying out the invention will be described in detail with reference to the drawings. FIG. 1 is a block diagram showing the overall configuration of the resource distribution system according to the first embodiment of this invention.
第１の実施形態のリソース配分システムは、ソフトウェアとして、１つ以上のタスク３０−１、３０−２と、唯一のリソース制御部１０と、一般的なＯＳ（Operating System。オペレーティングシステム）３５と、を備える。
The resource allocation system according to the first embodiment includes, as software, one or more tasks 30-1 and 30-2, a single
タスク３０−１、３０−２は、アプリケーションプログラムの実行インスタンスである。リソース制御部１０は、各タスクに配分するリソース量を制御する。
Tasks 30-1 and 30-2 are execution instances of application programs. The
タスクには、その動作性能が保証されるべき「性能保証型タスク」と、動作性能が必ずしも保証されない「ベストエフォート型タスク」の２種類がある。図１では、タスク３０−１が性能保証型タスク、タスク３０−２がベストエフォート型タスクである。性能保証型タスク３０−１にはスレッド制御部２０が連結されている。なお、本実施形態においては、全タスクの中に、性能保証型タスク３０−１は最低１個含まれている必要があるが、ベストエフォート型タスク３０−２は必ずしも含まれている必要はない。
There are two types of tasks: a “performance guaranteed task” whose operation performance should be guaranteed and a “best effort task” whose operation performance is not necessarily guaranteed. In FIG. 1, the task 30-1 is a performance guarantee type task, and the task 30-2 is a best effort type task. The
リソース制御部１０は、スレッド要求量決定部１１、スレッド−性能対応表１２、スレッド配分決定部１３、タスク状態表１４、を有する。スレッド要求量決定部１１は、タスクからの要請でスレッド要求数を決定する。スレッド−性能対応表１２は、スレッド要求量決定部１１が要求数を決める際に参照される。スレッド配分決定部１３は、各タスクのスレッド要求数を鑑みて、各タスクへの適切なスレッド配分量を決定する。タスク状態表１４は、現在の各タスクへのスレッド配分状態を記録する。
The
図２は、スレッド制御部２０の内部構造を示す。スレッド制御部２０は、タスクインタフェース部２１（図２では「タスクI/F部」と記載）と、リソース制御インタフェース部２２（図２で「RM I/F部」と記載）と、スレッドプール２４と、スレッドプール制御部２３と、スレッド開始パラメータ２５と、スレッド状態表２６と、を有する。
FIG. 2 shows the internal structure of the
タスクインタフェース部２１は、性能保証型タスク３０−１との通信を行う。リソース制御インタフェース部２２は、リソース制御部１０との通信を行う。スレッドプール２４は、あらかじめ生成しておいたＯＳ上のスレッドの集合を保管する。スレッドプール制御部２３は、スレッドプール２４内の各スレッドの実行や停止を制御する。スレッド開始パラメータ２５は、各スレッドの実行開始時のパラメータを保持する。スレッド状態表２６は、各スレッドの現在の状態を記録する。
The
性能保証型タスク３０−１は、その内部に性能保証区間３１と呼ばれる部分を有する。「性能保証区間」とは、一つの開始点と一つの終了点を持つ、プログラムコードの一部であって、その開始点から終了点までのタスク実行時間が別途指定される値以下となることが、システム要件から要請されているものである。
The performance guarantee type task 30-1 has a portion called a
例えば、毎秒30フレームの動画像に対して、フレームごとの画像処理をリアルタイムで実行するタスクの場合、性能保証区間は１フレームに対する当該画像処理を行うサブルーチンである。この場合、性能保証区間の処理時間の上限値は、33ミリ秒（30フレーム/秒の逆数）、となる。 For example, in the case of a task that executes image processing for each frame in real time for a moving image of 30 frames per second, the performance guarantee section is a subroutine for performing the image processing for one frame. In this case, the upper limit value of the processing time in the performance guarantee section is 33 milliseconds (the reciprocal of 30 frames / second).
図３は、スレッド−性能対応表１２の一例である。スレッド−性能対応表１２は、各々の性能保証区間に対するスレッド−性能対応表エントリ１２１〜１２３を有する。
FIG. 3 is an example of the thread-performance correspondence table 12. The thread-performance correspondence table 12 includes thread-performance
スレッド−性能対応表エントリ１２１〜１２３には、区間名（図３では“SEC1”, “SEC2”等）で識別された性能保証区間ごとに、いくつかのスレッド数とその処理時間の対応が記載されている。ここでの「処理時間」とは、当該性能保証区間をそのスレッド数のスレッドで実行した場合に要する処理時間である。処理時間の測定に用いる、当該性能保証区間での処理対象とされるデータの量は、当該性能保証区間に対して基準となる（ベースとなる）量とする。
The thread-performance
ここで、指定スレッド数で実行した場合の処理時間に関して補足する。ある決まった処理を、あるスレッド数で実行した場合の処理時間は、システム内にトータルでいくつの有効スレッドが存在するかによって変化する。 Here, it supplements regarding the processing time at the time of performing with the designated number of threads. When a certain process is executed with a certain number of threads, the processing time varies depending on the total number of valid threads in the system.
本実施形態の技術を利用する際には、まず、システム内の有効スレッド数の合計値Ｎall（Ｎallは１以上の整数）を一意に定める。Ｎallはシステム内のプロセッサコア数に合わせることもできるが、コア数以上の値を選ぶこともできる。次に、ＯＳ上でＮall個のスレッドを生成し、うちＲ個（Ｒは、１以上、Ｎall以下の整数）のスレッドを当該処理に、（Ｎall−Ｒ）個のスレッドを他のダミー処理にそれぞれ割り当る。そして、当該処理に対し基準量となる処理対象データを与えて、当該処理の実行時間ｔを測定する。Ｒを１、２、・・・と変化させながらｔの値を測定し、スレッド−性能対応表１２を作成する。 When using the technique of the present embodiment, first, the total value Nall (Nall is an integer of 1 or more) of the number of effective threads in the system is uniquely determined. Nall can be adjusted to the number of processor cores in the system, but a value larger than the number of cores can be selected. Next, Nall threads are generated on the OS, of which R threads (R is an integer of 1 or more and Nall or less) are used for this process, and (Nall-R) threads are used for other dummy processes. Assign each one. Then, processing target data serving as a reference amount is given to the process, and the execution time t of the process is measured. The value of t is measured while changing R to 1, 2,..., And the thread-performance correspondence table 12 is created.
図４は、タスク状態表１４の一例である。タスク状態表１４は、システム内の性能保証型タスク３０−１の各々に対して一つのエントリを持つ表である。各エントリは、タスクを一意に識別するためのタスクＩＤ、当該タスクが要求しているスレッド数、当該タスクの状態、の各欄を有する。タスク状態表１４の各エントリはまた、当該タスクの動作性能を測定した値を保持する性能測定値欄を有してもよい。 FIG. 4 is an example of the task status table 14. The task state table 14 is a table having one entry for each performance guarantee type task 30-1 in the system. Each entry has columns of a task ID for uniquely identifying a task, the number of threads requested by the task, and the state of the task. Each entry of the task state table 14 may also have a performance measurement value column for holding a value obtained by measuring the operation performance of the task.
次に、本実施の形態の全体の動作について、図１から図６を参照して、タスクの開始、タスク内の性能保証区間の開始と終了、そしてタスクの終了、の順で詳細に説明する。 Next, the overall operation of the present embodiment will be described in detail in the order of task start, performance guarantee interval start and end in the task, and task end with reference to FIGS. .
性能保証型タスク３０の実行が開始されると、性能保証型タスク３０はタスクインタフェース部２１に対し、”初期化通知”を送信する。典型的な実装形態では、スレッド制御部２０は性能保証型タスク３０のプログラムにリンクされて実行されているから、上記の初期化通知はタスクインタフェース部の当該機能の関数エントリを呼び出すことで行われる。
When the execution of the performance
タスクインタフェース部２１は、”初期化通知”を受信すると、リソース制御インタフェース部２２を初期化して、リソース制御部１０とスレッド制御部２０とが正しく通信できるようにする。さらに、タスクインタフェース部２１は、スレッドプール制御部２３に対してスレッドプールの初期化を指示する”初期化指示”を送信する。
Upon receiving the “initialization notification”, the
スレッドプール制御部２３は、”初期化指示”を受信すると、ＯＳ３５上で、ある個数のスレッドを作成し、それらの属性を高優先度に設定する。そして、スレッドプール制御部２３は、スレッドの実行を同期命令により起こされるまでブロックし、スレッドプール２４内で待機させる。ここで作成するスレッドの数は、性能保証区間３１で必要とされるスレッドの数を想定して、アプリケーション又はシステム設計時にあらかじめ決めておればよい。あるいは、リソース制御インタフェース部２２を通じてリソース制御部１０に問い合わせて、適切な初期スレッド数を得てもよい。
Upon receiving the “initialization instruction”, the thread
なお、初期化時にスレッドを生成しておく理由は、性能保証区間の実行開始時にスレッドを生成するための時間的オーバヘッドをできるだけ回避するためである。タスク実行の進行に際してスレッドが不足すれば、後述のように動的にスレッドを追加生成する。 The reason for creating a thread at the time of initialization is to avoid as much time overhead as possible to create a thread at the start of execution of the performance guarantee section. If there are not enough threads as the task execution proceeds, additional threads are dynamically generated as described later.
性能保証区間を実行するためのスレッドは、その属性が高優先度に設定された「高優先なスレッド」である。「高優先なスレッド」とは、「次に実行すべきスレッドを選択しようとしているプロセッサコアがあるとき、実行可能な高優先スレッドが一つでも存在すれば、いかなる通常スレッドよりも先に、実行可能な高優先スレッドが選択され実行される。」というルールを満たすものである。 The thread for executing the performance guarantee section is a “high priority thread” whose attribute is set to high priority. “High priority thread” means “When there is a processor core that is trying to select the next thread to be executed, if there is one executable high priority thread, it will be executed before any normal thread. The possible high priority thread is selected and executed ".
図５を参照して、性能保証区間の処理が開始するときの動作について、送受信される情報を具体例に示して説明する。性能保証区間の開始点において、性能保証型タスク３０はタスクインタフェース部２１に対し、”性能保証区間開始通知”を送信する（Ｓ２０１）。性能保証区間開始通知には、性能保証区間を識別する区間名、当該性能保証区間でその後処理される負荷の多寡を示す予定処理負荷量、及び当該性能保証区間での処理完了時間の要求値が、パラメータとして含まれる。
With reference to FIG. 5, the operation when the processing in the performance guarantee section starts will be described with reference to information transmitted and received as a specific example. At the start point of the performance guarantee section, the performance
予定処理負荷量は、当該性能保証区間における基準量（ベースとなる量）に対する比の値で指定される。例えば、画素単位に単純な演算を施す画像処理（演算量が画素数に比例する処理）では、予定処理負荷量は次のようになる。ＱＶＧＡ（Quarter Video Graphics Array）サイズ（320×240画素）の入力画像が基準となる入力データサイズである場合、ＶＧＡ（Video Graphics Array）サイズ（640×480画素）の画像を与えるときの予定処理負荷量は４となる。すなわち、ＶＧＡサイズの入力画像を与えると、基準値の４倍の負荷量が予定される。 The scheduled processing load amount is specified by a ratio value with respect to a reference amount (a base amount) in the performance guarantee section. For example, in an image process (a process in which the calculation amount is proportional to the number of pixels) in which simple calculation is performed for each pixel, the scheduled processing load amount is as follows. QVGA (Quarter Video Graphics Array) size (320 x 240 pixels) input image is the standard input data size, and the expected processing load when VGA (Video Graphics Array) size (640 x 480 pixels) image is provided The amount is 4. That is, when an input image of VGA size is given, a load amount four times the reference value is scheduled.
タスクインタフェース部２１はリソース制御部インタフェース部２２を通じ、”性能保証区間開始通知”をリソース制御部１０に送信する。典型的な実装形態では、リソース制御部１０はＯＳ３５上の一つのタスクとして実現され、この送信はＯＳ３５上でのタスク間通信を用いて行われる。送信される性能保証区間開始通知には、前述した内容と同じく、性能保証区間の区間名、予定処理負荷量、ならびに処理完了時間要求値が、パラメータとして含まれる（図５ Ｓ２０２）。
The
リソース制御部１０内にあるスレッド要求量決定部１１は、送信されてきた”性能保証区間開始通知”を受信する。そして、スレッド要求量決定部１１は、スレッド−性能対応表１２を参照して、次のようにして当該タスクが必要としているスレッド数を決定する（図５ Ｓ２０３）。
The thread request
ステップ１： スレッド−性能対応表１２の中の、当該性能保証区間に対するエントリを見つける。 Step 1: Find an entry for the performance guarantee section in the thread-performance correspondence table 12.
ステップ２： 当該エントリ中の、スレッド数−処理時間の対応列を参照し、処理時間に予定処理負荷量を乗じた値が処理完了時間要求値を下回る対応列の中で、最もスレッド数が小さいものを見つける。 Step 2: Referring to the correspondence column of the number of threads-processing time in the entry, the number of threads is the smallest in the correspondence column in which the value obtained by multiplying the processing time by the scheduled processing load amount is lower than the processing completion time request value. Find things.
上記ステップ２で見つけた最小のスレッド数を、スレッド要求量決定部１１で決定した「要求スレッド数Ｎinc（Ｎincは１以上の整数）」とする。スレッド要求量決定部１１は、タスクＩＤと決定した要求スレッド数の情報を組にして、スレッド配分決定部１３に”スレッド要求通知”を送信する（図５ Ｓ２０４）。
The minimum number of threads found in
スレッド配分決定部１３は、スレッド要求量決定部１１から新たな”スレッド要求通知”を受信すると、タスク状態表１４に新たなエントリを設ける。そして、そのタスクＩＤ欄及び要求スレッド数欄に、前記スレッド要求通知に記載されていたタスクＩＤ及び要求スレッド数Ｎincを転記するとともに、その状態欄にWAIT（待機中）と記入する（図５ Ｓ２０５）。
When the thread
次にスレッド配分決定部１３は、タスク状態表１４の中で、状態欄の値がPRIO-RUN（高優先実行中）であるエントリすべてを探し、それらのエントリの要求スレッド数の欄の値の総和Ｎold（Ｎoldは１以上の整数））を求める。PRIO-RUN状態のタスクの要求スレッド数の欄には、そのタスクに現在割り当てられているスレッド数が登録されている。従って、Ｎoldは、その時点で、PRIO-RUN状態の全タスクに割り当てられているスレッド数の合計値を意味する。
Next, the thread
もし Ｎold＋Ｎinc＜Ｎall であれば、割当済みのスレッド数と新たに要求されたスレッド数の合計が、システム内の有効スレッド数の合計値、すなわち、割当可能なスレッド数の上限値よりも少ないことを意味する。従って、今回の新たなスレッド要求は承諾される。このとき、スレッド配分決定部１３は、当該タスクに連結されたスレッド制御部２０に対し、Ｎinc数の高優先スレッドが割り当てられた旨の”スレッド割当通知”を送信する（図５ Ｓ２０６）。そして、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をPRIO-RUNに変更する。
If Nold + Ninc <Nall, the total number of allocated threads and the number of newly requested threads is less than the total number of active threads in the system, that is, the upper limit of the number of allocatable threads. means. Therefore, this new thread request is accepted. At this time, the thread
もし Ｎold＋Ｎinc≧Ｎall であれば、割当済みのスレッド数と新たに要求されたスレッド数の合計が、割当可能なスレッド数の上限値以上であることを意味する。従って、今回の新たなスレッド要求は拒否される。このとき、スレッド配分決定部１３は、当該タスクに連結されたスレッド制御部２０に対し、Ｎinc数の通常スレッドが割り当てられた旨の”スレッド割当通知”を送信する。そして、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をSTD-RUNに変更する。
If Nold + Ninc ≧ Nall, it means that the total of the number of allocated threads and the number of newly requested threads is equal to or greater than the upper limit of the number of threads that can be allocated. Therefore, this new thread request is rejected. At this time, the thread
スレッド制御部２０内のリソース制御インタフェース部２２は、リソース制御部１０内のスレッド配分決定部１３から”スレッド割当通知”を受信する。前述のように、スレッド割当通知は、性能保証型タスク３０とリソース制御部１０の間のタスク間通信で行われる。
The resource
スレッド割当通知の内容がＮ個の高優先スレッド割当の場合、リソース制御インタフェース部２２は、スレッドプール制御部２３に指示してスレッドプール２４からＮ個のスレッドを取り出して性能保証区間３１の実行に用いる（図５ Ｓ２０７）。すなわち、次のステップＳ１０からＳ１３が順に実行される。
When the content of the thread assignment notification is N high-priority thread assignments, the resource
ステップＳ１０： スレッドプール制御部２３は、性能保証区間３１の開始点アドレスと、性能保証区間３１の実行に必要なその他のパラメータをスレッド開始パラメータ２５に記入する。
Step S10: The thread
ステップＳ１１： スレッドプール制御部２３は、スレッド状態表２６を参照して、現在実行中ではないスレッド数を調べる。現在実行中ではないスレッドがＮ個未満であれば、スレッドプール制御部２３は、ＯＳ３５を呼び出して新規に高優先スレッドを生成し、現在実行中ではないスレッドが延べＮ個以上になるようにする。
Step S11: The thread
ステップＳ１２： スレッドプール制御部２３は、スレッド状態表２６を参照して、現在実行中ではないＮ個のスレッドを選び、それら選ばれたＮスレッドの実行を再開させる。これにより、各スレッドは、スレッド開始パラメータ２５に記入されたパラメータを用い、同様にスレッド開始パラメータ２５の中に記入された開始点アドレスから、その実行が再開される。
Step S12: The thread
他方、リソース制御インタフェース部２２が受信したスレッド割当通知の内容がＮ個の通常スレッド割当であった場合、次のステップＳ１５からＳ１６が順に実行される。
On the other hand, when the content of the thread assignment notification received by the resource
ステップＳ１５： リソース制御インタフェース部２２は、スレッドプール制御部２３に指示して、ＯＳの通常スレッドＮ個を用いて性能保証区間３１を実行させる。すなわち、スレッドプール制御部２３は、性能保証区間３１の開始点アドレスと、性能保証区間３１の実行に必要なその他のパラメータをスレッド開始パラメータ２５に記入し、ＯＳ上で生成したＮ個のスレッドに前記開始点アドレスからの実行を開始させる。
Step S15: The resource
ステップＳ１６： スレッドプール制御部２３は、さらに、上記で生成したＮ個のスレッドを識別するスレッドＩＤ（のべＮ個）をスレッド状態表２６に記録する。
Step S16: The thread
このようにして、タスク側で性能保証区間の実行開始時点でリソース制御部１０が必要なスレッド割当数を決定する。そして、その決定数に基づいて、当該タスクは、高優先スレッド又は通常スレッドが割り当てられ、実行される（図５ Ｓ２０８）。
In this way, the
次に、図６を参照して、性能保証区間の処理が終了するときの動作、すなわち、ある性能保証型タスク３０−１ａがその性能保証区間の実行から抜け出す際の動作を説明する。 Next, with reference to FIG. 6, the operation when the processing of the performance guarantee section ends, that is, the operation when a certain performance guarantee type task 30-1a exits from the execution of the performance guarantee section will be described.
性能保証区間の終了点において、性能保証区間の実行に割り当てられたスレッドがそのうちの一つを除きすべて終了すると、性能保証型タスク３０−１ａはタスクインタフェース部２１−１ａに対し、”性能保証区間終了通知”を送信する（図６のＳ２２１）。性能保証区間終了通知には、性能保証区間を識別するための区間名がパラメータとして含まれる。タスクインタフェース部２１ａはリソース制御部インタフェース２２ａを通じ、”性能保証区間終了通知”をリソース制御部１０に送信する（図６ Ｓ２２２）。
When all but one of the threads assigned to the execution of the performance guarantee section are terminated at the end point of the performance guarantee section, the performance guarantee type task 30-1a gives the “performance guarantee section” to the task interface unit 21-1a. An “end notification” is transmitted (S221 in FIG. 6). In the performance guarantee section end notification, a section name for identifying the performance guarantee section is included as a parameter. The
リソース制御部１０では、スレッド要求量決定部１１ではなく、スレッド配分決定部１３が前記で送信されてきた”性能保証区間終了通知”を受信し、タスク状態表１４を参照して関係タスクのスレッド配分を変更する（図６ Ｓ２２３）。図８を参照しながらこのスレッド配分決定部１３の動作を説明する。
In the
ステップＳ３０１、Ｓ３０２： 当該性能保証区間に対するタスクを得、タスク状態表１４の中で前記タスクのＩＤに合致するエントリＬを探す。通常、ただ一つのエントリが合致するはずであるが、複数合致あるいは合致しない場合は無効な通知として無視するか適切なエラーを出力する。 Steps S301 and S302: A task for the performance guarantee section is obtained, and an entry L matching the task ID is searched for in the task state table 14. Normally, only one entry should match, but if it matches or does not match, it is ignored as an invalid notification or an appropriate error is output.
ステップＳ３０３： 上記で見つかったエントリＬ中のスレッド要求量欄の値をＮdecとする。Ｎdecは当該タスクに割り当てられていたスレッド数である。 Step S303: The value of the thread request amount column in the entry L found above is set to Ndec. Ndec is the number of threads assigned to the task.
ステップＳ３０４： ステップＳ３０１で見つかったエントリＬ中の状態欄の値を調べる。値がPRIO-RUNである場合、高優先スレッドの再割当探索を行う。（以下のステップＳ３０５〜ステップＳ３１２）状態欄の値がPRIO-RUNであるエントリにおけるスレッド要求量の値Ｎdecは、性能保証区間の実行から抜け出したために性能保証型タスク３０−１ａにとっては不要となり、リソース制御部１０へ返却される高優先スレッドの数を意味する。そして、返却されたスレッドは、他の性能保証型タスクから要求があったときに、リソース制御部１０によって、再割当のために使用される。
Step S304: The value in the status column in the entry L found in step S301 is checked. When the value is PRIO-RUN, a reassignment search for a high priority thread is performed. (Steps S305 to S312 below) The value Ndec of the thread request amount in the entry whose status column value is PRIO-RUN has become unnecessary for the performance guarantee type task 30-1a because it escaped from the execution of the performance guarantee section. This means the number of high priority threads returned to the
ステップＳ３０５： ステップＳ３０１で見つかったエントリＬの状態欄にWAITと記入する。 Step S305: WAIT is written in the status column of the entry L found in step S301.
ステップＳ３０６、Ｓ３０７： タスク状態表１４の中で、エントリの状態欄の値がPRIO-RUN（高優先実行中）であるエントリすべてを探し、それらのエントリの要求スレッド数欄の値の総和Ｎoldを求める。これを用いて、システム内の空き高優先スレッド数 Ｎfree＝Ｎall−Ｎold＋Ｎdec を計算する。 Steps S306 and S307: The task status table 14 is searched for all entries whose value in the entry status column is PRIO-RUN (high priority execution), and the sum Nold of the values in the requested thread number column of those entries is determined. Ask. Using this, the number of free high priority threads in the system Nfree = Nall−Nold + Ndec is calculated.
ステップＳ３０８、Ｓ３１０： タスク状態表１４の中で、状態欄の値がSTD-RUNであり、スレッド要求数欄の値がＮfree未満のエントリすべてを探し、そのうちスレッド要求数欄の値が最大であるエントリＮを特定する。そのエントリＮのタスクを以後性能保証型タスク３０−１ｂと呼ぶ。またこのエントリＮのスレッド数要求数欄の値をＮincとする。 Steps S308 and S310: In the task status table 14, search for all entries in which the value in the status column is STD-RUN and the value in the thread request count column is less than Nfree, and the value in the thread request count column is the maximum. Entry N is specified. The task of entry N is hereinafter referred to as a performance guarantee type task 30-1b. In addition, the value of the thread number request number column of this entry N is Ninc.
ステップＳ３１１： ステップＳ３１０で見つかったエントリＮのタスクＩＤ欄に記載された性能保証型タスク３０−１ｂに対し、”高優先スレッド再割当通知”を送信する。すなわち、当該性能保証型タスク３０−１ｂに連結されたスレッド制御部２０ｂに対し、Ｎinc個の高優先スレッドが再割当された旨の”スレッド割当通知”を送信する（図６ Ｓ２２４）とともに、前記エントリＮの状態欄の内容をPRIO-RUNに変更する。 Step S311: A “high priority thread reassignment notification” is transmitted to the performance guarantee type task 30-1b described in the task ID column of the entry N found in Step S310. That is, a “thread assignment notification” indicating that Ninc high-priority threads have been reassigned is transmitted to the thread control unit 20b connected to the performance-assured task 30-1b (S224 in FIG. 6). Change the contents of the entry N status column to PRIO-RUN.
ステップＳ３１２： Ｎfreeの値をＮincだけ減じる。新たなエントリが見つからなくなるまで、ステップＳ３０８〜ステップＳ３１２を繰り返す。 Step S312: Decrease the value of Nfree by Ninc. Steps S308 to S312 are repeated until no new entry is found.
ステップＳ３２０、Ｓ３２１： ステップＳ３０１で見つかったエントリＬ中の状態欄の値がSTD-RUNである場合は、その状態欄にWAITと記入するのみで、高優先スレッド再割当は行わない。状態欄の値がSTD-RUNであるエントリは、当該タスクには通常スレッドが割り当てられていたことを意味する。従って、優先スレッドの再割当は行わない。 Steps S320 and S321: When the value in the status column in the entry L found in step S301 is STD-RUN, only WAIT is written in the status column, and high-priority thread reassignment is not performed. An entry whose value in the status column is STD-RUN means that a normal thread has been assigned to the task. Therefore, the priority thread is not reassigned.
上記ステップＳ３１１で高優先スレッド再割当が行われた場合、性能保証型タスク３０−１ｂのスレッド制御部２０ｂ内のリソース制御インタフェース部２２ｂが”スレッド割当通知”を受信し、ただちにその内容をスレッドプール制御部２３ｂに伝える（図６ Ｓ２２５）。その通知内容には、再割当高優先スレッド数Ｎincが含まれている。
When the high-priority thread reallocation is performed in step S311, the resource
スレッドプール制御部２３ｂは、スレッド状態表２６ｂを参照し、性能保証型タスク３０−１ｂの性能保証区間３１ｂの実行のために通常スレッドが割り当てられており、そのスレッド数がＮincに等しいことを確認する。それが確認できれば、スレッドプール制御部２３ｂは、前記Ｎinc個の通常スレッドの実行属性を高優先に変更する（図６ Ｓ２２６）。この変更は通常、ＯＳ３５に対してスレッドのスケジューリングパラメータや優先度パラメータを再設定することで行うことができる。その際に必要となるスレッドＩＤはスレッド状態表２６ｂに記録されているものを使用する。
The thread
性能保証型タスク３０が終了する際、性能保証型タスク３０はタスクインタフェース部２１に対し”タスク終了通知”を送信する。タスクインタフェース部２１は、”タスク終了通知”を受信すると、スレッドプール制御部２３に対し全スレッドの終了を指示する”スレッド割当通知”を送信するとともに、リソース制御インタフェース部２２に対して性能保証型タスク３０の終了を通知するために”タスク終了通知”を送信する。
When the performance
スレッドプール制御部２３は”スレッド終了指示”を受信すると、スレッド状態表２６とスレッドプール２４を参照し、スレッド制御部で生成したすべてのスレッドを終了させる。
When receiving the “thread end instruction”, the thread
リソース制御部１０は、リソース制御インタフェース部２２から性能保証型タスク３０の”タスク終了通知”を受信すると、スレッド配分決定部１３に指示して、タスク状態表１４から性能保証型タスク３０に対応するエントリを抹消させる。
When the
以上のように、本実施形態のタスク配分システムは、性能保証型タスクから必要な処理性能や予定されている負荷量についての情報を受け取る。そして、本実施形態のタスク配分システムは、スレッドの割当数とそのときの処理性能との対比情報及び現在のスレッド割当状況を基に、性能保証型タスクへのスレッドの割当量を決定する。 As described above, the task distribution system according to the present embodiment receives information on necessary processing performance and a planned load amount from a performance guarantee type task. Then, the task distribution system according to the present embodiment determines the thread allocation amount to the performance guaranteed task based on the comparison information between the number of allocated threads and the processing performance at that time and the current thread allocation status.
ところで、本実施形態において割り当てられるスレッドは、タスクの処理に用いられる「リソース」の一種であって、割り当てられるリソースはスレッドには限定されない。すなわち、本実施形態は、タスクに割当可能で、割当量に依存してタスクの処理性能が変化するような有限リソース一般に適用可能である。このようなリソースには、プロセッサ関連としては、スレッドの他に、プロセッサコアの個数がある。メモリ関連では、単純なメモリ使用量や、キャッシュメモリ割当量も、上記のようなリソースである。あるいは、タスクがネットワークを使用する場合にはネットワークの帯域幅も、割当可能であり、タスクの処理性能に影響を与えるリソースである。 By the way, the thread allocated in the present embodiment is a kind of “resource” used for task processing, and the allocated resource is not limited to the thread. In other words, this embodiment can be applied to general finite resources that can be assigned to tasks and whose task processing performance changes depending on the assigned amount. Such resources include the number of processor cores in addition to threads in terms of processors. Regarding memory, simple memory usage and cache memory allocation are also resources as described above. Alternatively, when a task uses a network, the bandwidth of the network can also be allocated, and is a resource that affects task processing performance.
また、本実施形態のリソース配分システムは、タスクへのリソース割当とタスクからの不要リソース回収の機能を備えればよく、タスク自体は、本実施形態のリソース配分システム内に備えられている必要はない。また、スレッド制御部２０やＯＳ３５も、リソース配分システム内に備えられている必要はない。従って、図１のリソース配分システムは、図７のリソース配分システム１００のように簡略化できる。図７は、第１の実施形態のリソース配分システムの最小構成を示すブロック図である。リソース配分システム１００は、図１におけるリソース制御部１０において、スレッドをリソースに一般化したものに相当する。
Further, the resource allocation system of the present embodiment only needs to have the functions of resource allocation to tasks and collection of unnecessary resources from tasks, and the tasks themselves need to be provided in the resource allocation system of the present embodiment. Absent. Further, the
リソース配分システム１００は、リソース要求量決定部１１、リソース−性能対応情報１２、タスク状態表１４、リソース配分決定部１３を備える。
The
性能情報保持部１０２は、スレッド−性能対応表１２に相当する。性能情報保持部１０２は、割当仮定量と、性能保証型タスクにその割当仮定量のリソースが割り当てられたときの性能保証区間における処理性能との対応関係を表すリソース−性能対応情報を保持する。割当仮定量とは、性能保証区間の処理のために、当該性能保証型タスクへ割り当てられたと仮定されたリソースの量である。実際に割り当てられるリソースの量は、後述のように、リソース配分決定部１０３が決定する。なお、性能情報保持部１０２が保持するリソース−性能対応情報は、表形式に配置された情報には限定されない。すなわち、リソース−性能対応情報は、割当仮定量とその量のリソースが割り当てられたときの処理性能との関係を規定する情報であればよい。従って、リソース−性能対応情報は、例えば、割当仮定量と処理性能との関係を規定する関数であってもよい。
The performance
リソース要求量決定部１０１は、スレッド要求量決定部１１に相当する。リソース要求量決定部１０１は、外部の性能保証型タスクから、性能保証区間の実行開始前に、処理完了時間要求値及び予定処理負荷量を受信する。そして、リソース要求量決定部１０１は、処理完了時間要求値、予定処理負荷量及びリソース−性能対応情報に基づいて性能保証区間の処理に用いるリソースの要求量である要求リソース量を決定する。また、リソース要求量決定部１０１は、性能保証区間に対して実際に割り当てられることが決定したリソースの量である割当リソース量を性能保証型タスクに通知する。
The resource request
タスク状態保持部１０４は、タスク状態表１４に相当する。タスク状態保持部１０４は、ある性能保証型タスクに現在割り当てられているリソースの量を表す割当済リソース量を保持する。
The task
リソース配分決定部１０３は、割当対象となりうるリソースの総量である全リソース量、割当要求リソース量及び割当済リソース量に基づいて割当リソース量を決定する。全リソース量は、Ｎallに相当する量であり、割当対象として取り扱うことができるリソースの全体量である。従って、全リソース量は、ある時点において、常にその量が割当可能であるとは限らない。そこで、リソース配分決定部１０３は、全リソース量と割当済リソース量とから割当可能なリソースの量を判断し、割当要求リソース量のリソースを割当可能か否かを判定する。そして、リソース配分決定部１０３は、実際に割り当てるリソース量、すなわち、割当リソース量を決定する。そのため、割当リソース量が０であることもありうる。
The resource
リソース配分システム１００は、スレッドのみでなく、タスクに割当可能で、割当量に依存してタスクの処理性能が変化するようなリソースを、性能保証型タスクに配分する。リソース配分システム１００の処理は、スレッドの割当を例として説明した、図１のリソース配分システムと同じなので、詳細な説明は省略する。
The
なお、リソース配分システム１００は、ハードウェアによって実現されても、ソフトウェアによって実現されてもよい。ソフトウェアによってリソース配分システム１００が実現される場合は、本システムを適用するコンピュータシステムが備える所定のＣＰＵ（図示なし）によって、リソース配分プログラムが実行される。プログラムの処理手順は、図８に示した通りである。
Note that the
リソース配分プログラムは、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等の半導体記憶装置、光ディスク、磁気ディスク、光磁気ディスク等、非一時的な媒体に格納されてもよい。 The resource allocation program may be stored in a non-transitory medium such as a semiconductor storage device such as a ROM (Read Only Memory) or a RAM (Random Access Memory), an optical disk, a magnetic disk, or a magneto-optical disk.
次に、本実施形態の効果について説明する。 Next, the effect of this embodiment will be described.
本実施形態では、タスクがリソース制御部に対し予定処理負荷量と処理完了時間の要求値を伝える。リソース制御部はその性能要件を満たすのに必要な最小限のスレッド数を決定する。タスクのスレッド制御部は、その決定に沿ってスレッドを開始し、並列処理を行う。そのため、タスクに要求される処理性能を達成することができる。さらに、あるタスクに過剰なスレッドを割り当てることによる他タスクの性能低下を招く可能性が抑えられる。 In this embodiment, the task informs the resource control unit of the requested processing load amount and the required value of the processing completion time. The resource control unit determines the minimum number of threads necessary to satisfy the performance requirement. The thread control unit of the task starts a thread according to the determination and performs parallel processing. Therefore, the processing performance required for the task can be achieved. Furthermore, it is possible to suppress the possibility of causing the performance degradation of other tasks by allocating excessive threads to a certain task.
また、本実施形態では、性能保証が必要な部分の実行を終えたときには、割り当てられていたスレッドがリソース制御部に返却され、必要としている他のタスクへのスレッド再割当をただちに行う。そのため、スレッドリソースは必要なタスクに速やかに配分される。従って、タスクへの要求性能が実際に達成される可能性を高めることができる。
（第２の実施形態）
本発明を実施するための第２の実施形態について説明する。
Further, in this embodiment, when the execution of the portion requiring performance guarantee is completed, the assigned thread is returned to the resource control unit, and the thread reassignment to another necessary task is immediately performed. Therefore, thread resources are promptly allocated to necessary tasks. Therefore, it is possible to increase the possibility that the required performance for the task is actually achieved.
(Second Embodiment)
A second embodiment for carrying out the present invention will be described.
第１の実施形態では、スレッド制御部２０は、高優先スレッドはスレッドプール２４で管理し、通常スレッドはそのたびにＯＳに依頼して生成する。これは、本発明では、システム内に存在する実行中の高優先スレッドの数とそれらの割り当て方を正確に管理するためである。他方、スレッドプールは、スレッドを生成するときのオーバヘッドを減らすという長所を持つ。
In the first embodiment, the
そこで、第２の実施の形態として、高優先スレッドに加え、通常スレッドもスレッドプールで管理する方式を示す。すなわち、初期化時には一定数の高優先スレッド及び一定数の通常スレッドを生成して、両者ともスレッドプール２４の管理下に置く。スレッドプール制御部２３は、スレッド配分決定部１３からのスレッド割当通知が高優先スレッド割当か通常スレッド割当かによって、スレッドプール２４の管理下にある高優先スレッドあるいは通常スレッドを選択する。選択されたスレッドは、性能保証区間３１の実行に使用される。
Therefore, as a second embodiment, a method for managing not only high priority threads but also normal threads in a thread pool will be described. That is, at initialization, a certain number of high priority threads and a certain number of normal threads are generated, and both are under the management of the
このような実施形態をとることにより、高優先スレッドの割当に成功するか否かにかかわらず、ほぼ一定コストで並列処理を開始できる。 By adopting such an embodiment, it is possible to start parallel processing at a substantially constant cost regardless of whether or not high-priority thread assignment is successful.
第２の実施形態を採用する際に留意すべき点は、第１の実施形態に比べ、ＯＳ上で生成される総スレッド数が多くなるため、ＯＳにおけるスレッド管理オーバヘッドが増える可能性がある点である。そのため、スレッド制御部２０内のスレッドプールのオーバヘッドとＯＳによるシステム内の全スレッドの管理オーバヘッドのトレードオフを鑑みて、第１の実施形態と第２の実施形態のうち、適切な方を選ぶのがよい。
（第３の実施形態）
本発明を実施するための第３の実施形態について詳細に説明する。
The point to be noted when adopting the second embodiment is that the total number of threads generated on the OS is larger than that of the first embodiment, so that the thread management overhead in the OS may increase. It is. Therefore, in view of the trade-off between the overhead of the thread pool in the
(Third embodiment)
A third embodiment for carrying out the present invention will be described in detail.
本実施形態は、第１の実施形態の変形であるが、第２の実施形態と組みあわて実施されることも可能である。 This embodiment is a modification of the first embodiment, but can also be implemented in combination with the second embodiment.
第１の実施形態では、スレッド配分決定部１３は、新たなスレッド要求が承諾されない場合、要求元タスクに対して、高優先スレッドではなく通常スレッドを割り当てる。この割当は、必ずしも要求元タスクの性能が満たされる保証はないが、ベストエフォートで処理を進めておくことが望ましいとの考え方に基づくものである。
In the first embodiment, when a new thread request is not accepted, the thread
別の方式として、要求された個数の高優先スレッドが割り当てられない場合は割当を一時保留し、のちに割当可能になった時点で要求された個数の高優先スレッドを割り当てる、という方式もある。この場合、新たな”スレッド要求通知”を受信した際のスレッド配分決定部１３の動作は次のようになる。
As another method, when the requested number of high priority threads cannot be allocated, the allocation is temporarily suspended, and the requested number of high priority threads is allocated when the allocation becomes possible later. In this case, the operation of the thread
スレッド要求量決定部１１から新たな”スレッド要求通知”を受信すると、スレッド配分決定部１３は、タスク状態表１４に新たなエントリを設ける。そして、スレッド配分決定部１３は、そのタスクＩＤ欄及び要求スレッド数欄に、スレッド要求通知に記載されていたタスクＩＤ及びスレッド数（その値をＮincとする）を転記するとともに、その状態欄にWAITと記入する。
When a new “thread request notification” is received from the thread request
次に、スレッド配分決定部１３は、タスク状態表１４の中で、状態欄の値がPRIO-RUNであるすべてのエントリを探し、それらのエントリの要求スレッド数欄の値の総和（その値をＮoldとする）を求める。
Next, the thread
もし Ｎold＋Ｎinc＜Ｎall であれば、今回の新たなスレッド要求は承諾される。すなわち、スレッド配分決定部１３は、当該タスクに連結されたスレッド制御部２０に対し、Ｎinc数の高優先スレッドが割り当てられた旨の”スレッド割当通知”を送信する。さらに、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をPRIO-RUNに変更する。
If Nold + Ninc <Nall, this new thread request is accepted. That is, the thread
もし Ｎold＋Ｎinc≧Ｎall であれば、今回の新たなスレッド要求は一時保留される。このとき、スレッド配分決定部１３は、新たに作成したタスク状態表エントリの状態欄の内容をREADY（実行可能）に変更する。この場合、スレッド制御部２０へは何も通知されない。
If Nold + Ninc ≧ Nall, this new thread request is temporarily suspended. At this time, the thread
スレッド制御部から”性能保証区間終了通知”を受信すると、スレッド配分決定部１３は以下の手順Ｓ３３１からＳ３３６を実行する。
When the “performance guarantee section end notification” is received from the thread control unit, the thread
ステップＳ３３１： 当該性能保証区間が設定されたタスクを特定し、タスク状態表１４の中でそのタスクのＩＤに合致するエントリＬを探す。このとき、唯一のエントリが合致するのが正常である。複数のエントリが合致する場合、あるいは合致するエントリがない場合は、当該性能保証区間終了通知が無効な通知として無視されるか、適切なエラーが出力される。 Step S331: The task in which the performance guarantee section is set is specified, and the entry L that matches the ID of the task is searched in the task state table 14. At this time, it is normal that only one entry matches. When a plurality of entries match or there is no matching entry, the performance guarantee section end notification is ignored as an invalid notification or an appropriate error is output.
ステップＳ３３２： ステップＳ３３１で発見されたエントリＬ中のスレッド要求量欄の値をＮdecとする。この値は当該タスクに割り当てられているスレッド数である。 Step S332: The value of the thread request amount column in the entry L found in step S331 is set to Ndec. This value is the number of threads assigned to the task.
ステップＳ３３３： ステップＳ３３１で発見されたエントリＬの状態欄にWAITと記入する。 Step S333: WAIT is written in the status column of the entry L found in Step S331.
ステップＳ３３４： タスク状態表１４の中で、状態欄の値がREADYであり、スレッド要求数欄の値がＮdecを越えないエントリすべてを探し、そのうちスレッド要求数欄の値が最大であるエントリＮを特定する。そのエントリＮのスレッド数要求数欄の値をＮincとする。 Step S334: The task status table 14 is searched for all entries whose value in the status column is READY and whose value in the thread request number column does not exceed Ndec, and among them, the entry N having the maximum value in the thread request number column is selected. Identify. Let Ninc be the value in the thread count request count column for entry N.
ステップＳ３３５： 上記で見つかったエントリＮのタスクＩＤ欄に記載されたタスクに対し、高優先スレッドが割り当てられた旨の”スレッド割当通知”を送信するとともに、前記エントリＮの状態欄の内容をPRIO-RUNに変更する。 Step S335: A “thread assignment notification” indicating that a high priority thread has been assigned is transmitted to the task described in the task ID field of the entry N found above, and the contents of the status field of the entry N are set to PRIO. Change to -RUN.
ステップＳ３３６： Ｎdecの値をＮincだけ減じる。新たなエントリが見つからなくなるまで、ステップＳ３３４〜ステップＳ３３６を繰り返す。 Step S336: Decrease the value of Ndec by Ninc. Steps S334 to S336 are repeated until no new entry is found.
なお、第３の実施形態におけるスレッド制御部２０の動作は、第１の実施形態に記載した内容と同じである。
The operation of the
第３の実施形態では、タスクが性能保証区間の実行に必要とする分のリソースが確保できないときは、当該区間の実行が延期され、のちにリソース確保された段階で当該区間に対し必要分のリソースが割り当てられたうえで実行開始される。そのため、性能保証区間の開始から終了までの実行性能は要求通りであることが保証される、という新たな効果が得られる。
（第４の実施形態）
次に、具体例を用いて、本発明を実施するための実施形態の動作を説明する。
In the third embodiment, when the resources required for the execution of the performance guarantee section cannot be secured in the third embodiment, the execution of the section is postponed, and at the stage where the resources are secured, Execution starts after resources are allocated. Therefore, it is possible to obtain a new effect that the execution performance from the start to the end of the performance guarantee section is guaranteed as requested.
(Fourth embodiment)
Next, the operation of the embodiment for carrying out the present invention will be described using a specific example.
第４の実施形態のタスク配分システムでは、ＯＳとしてＬｉｎｕｘ（登録商標）が使用され、各タスクはＬｉｎｕｘ上のスレッドあるいはプロセスとして実現される。リソース制御部１０はＬｉｎｕｘ上の一つのプロセスであるリソース制御プロセスとして、スレッド制御部２０はＬｉｎｕｘプロセスにリンクするスレッド制御ライブラリとして実現される。
In the task distribution system of the fourth embodiment, Linux (registered trademark) is used as the OS, and each task is realized as a thread or process on Linux. The
スレッド制御ライブラリは次の関数エントリをタスク向けに公開する。
(1) スレッド制御部初期化関数： パラメータなし
(1)−1： リソース制御プロセスとの間のプロセス間通信を確立し、リソース制御プロセスからのメッセージを処理する受信スレッド（後述）を生成し開始する。
The thread control library exposes the following function entries for tasks.
(1) Thread controller initialization function: no parameters
(1) -1: Establish inter-process communication with the resource control process, and generate and start a reception thread (described later) that processes messages from the resource control process.
(1)−2： リソース制御プロセスから指示された個数、Ｌｉｎｕｘ環境変数から取得した値、又はスレッド制御ライブラリの設計時のデフォルト値を基に、一定個数の、高優先スレッド及び通常スレッドを生成する。 (1) -2: Based on the number specified by the resource control process, the value acquired from the Linux environment variable, or the default value at the time of designing the thread control library, a fixed number of high priority threads and normal threads are generated. .
ここでのスレッドにはpthread (POSIXスレッド) を使用し、高優先スレッドは、pthreadのスレッド属性で、スケジューリングポリシーとして”リアルタイムスケジューリング”を指定することで実現する。
(2) 性能保証区間開始： パラメータ＝区間名, 予定処理負荷量, 完了時間要求値
以下の情報の組をリソース制御プロセスに送信する。
Pthread (POSIX thread) is used for the thread here, and the high-priority thread is realized by specifying "real-time scheduling" as the scheduling policy in the thread attribute of pthread.
(2) Performance guarantee section start: Parameter = section name, scheduled processing load, completion time requirement value Send the following information set to the resource control process.
（区間開始, 自プロセスＩＤ, 区間名, 予定処理負荷量, 完了時間要求値）
ここで一つめの情報である「区間開始」とは、リソース制御プロセスに送信されるコマンドの一つである。
(Section start, own process ID, section name, scheduled processing load, completion time required value)
Here, the first information “section start” is one of commands transmitted to the resource control process.
また、「区間名」は、性能保証区間の各々に対して当該プログラムの開発者又は言語処理系が付与した整数値であり、一つのプロセス内でユニークであれば任意の値でよい。
(3) 性能保証区間終了： パラメータ＝区間名
以下の情報の組をリソース制御プロセスに送信する。
The “section name” is an integer value assigned to each performance guarantee section by the program developer or the language processing system, and may be an arbitrary value as long as it is unique within one process.
(3) Performance guarantee section end: Parameter = section name The following information pair is sent to the resource control process.
（区間終了, 自プロセスＩＤ, 区間名）
(4) スレッド制御部終了処理関数： パラメータなし
(4)−1： 上記(1)−2で生成した全スレッドの終了を確認し、未終了のものは強制終了させる。
(Section end, own process ID, section name)
(4) Thread control unit termination processing function: no parameter
(4) -1: Confirm the termination of all threads generated in (1) -2 above, and forcibly terminate those that have not been terminated.
(4)−2： リソース制御プロセスに対し以下の情報の組を送信する。 (4) -2: Send the following set of information to the resource control process.
（プロセス終了, 自プロセスＩＤ）
スレッド制御ライブラリは、リソース制御プロセスからのプロセス間通信メッセージを処理する受信スレッドを生成し、実行する。スレッド制御ライブラリの動作はおおむね次の通りである。
(1) リソース制御プロセスからのメッセージ到着を待つ。メッセージ内のコマンド種別により、次の(2)〜(4)に分岐する。
(2) 「高優先スレッド割当」の場合： パラメータ＝スレッド数Ｎ
スレッドプールにある待機中の高優先スレッドからＮ個を選び、性能保証区間の開始点からスレッドの実行を再開させる。もし高優先スレッドがＮ個に満たない場合は、新たに高優先スレッドを生成して上記再開処理を行う。
(Process end, own process ID)
The thread control library generates and executes a reception thread that processes interprocess communication messages from the resource control process. The operation of the thread control library is as follows.
(1) Wait for the arrival of a message from the resource control process. Branches to the following (2) to (4) depending on the command type in the message.
(2) For "High priority thread allocation": Parameter = Number of threads N
N threads are selected from the waiting high priority threads in the thread pool, and the execution of the thread is resumed from the start point of the performance guarantee section. If the number of high-priority threads is less than N, a new high-priority thread is newly generated and the restart process is performed.
実行を再開させた各スレッドのスレッドＩＤをスレッド状態表に記録する。
(3) 「通常スレッド割当」の場合： パラメータ＝スレッド数Ｎ
スレッドプールにある待機中の通常スレッドからＮ個を選び、性能保証区間の開始点からスレッドの実行を再開させる。
The thread ID of each thread whose execution has been resumed is recorded in the thread state table.
(3) For "Normal thread allocation": Parameter = Number of threads N
N threads are selected from the waiting normal threads in the thread pool, and the execution of the threads is resumed from the start point of the performance guarantee section.
もし通常スレッドがＮ個に満たない場合は、新たに通常スレッドを生成して上記再開処理を行う。 If the number of normal threads is less than N, a new normal thread is generated and the restart process is performed.
実行を再開させた各スレッドのスレッドＩＤをスレッド状態表に記録する。
(4) 「高優先スレッド再割当」の場合： パラメータ＝スレッド数Ｎ
スレッド状態表を参照し、実行中の通常スレッドがＮ個あることを確認したうえで、それらの各スレッドに対しpthreadのスレッド属性変更関数を適用し、スケジューリングポリシーを”リアルタイムスケジューリング”に変更する。
The thread ID of each thread whose execution has been resumed is recorded in the thread state table.
(4) For "High priority thread reallocation": Parameter = Number of threads N
Referring to the thread state table, after confirming that there are N normal threads being executed, the thread attribute change function of pthread is applied to each of these threads, and the scheduling policy is changed to “real time scheduling”.
リソース制御プロセス、すなわち、リソース制御部１０は、Ｌｉｎｕｘ上の常駐型プロセスとして実装され、他のプロセスにリンクされたスレッド制御ライブラリからプロセス間通信で送信されてくるコマンドの内容に応じた処理を行う。スレッド−性能対応表は、リソース制御プロセス開始時にＬｉｎｕｘ上のファイルから読み込まれ、リソース制御プロセス内のメモリ上データとして保持される。
The resource control process, that is, the
ここで本実施形態の理解の一助とするために、本実施形態に基づいた動作事例を、時間の流れに沿って具体的に説明する。 Here, in order to help understanding of the present embodiment, an operation example based on the present embodiment will be specifically described along the flow of time.
システムは次のような構成であるとする。 Assume that the system has the following configuration.
１２個のプロセッサコア
有効スレッド数 Ｎall＝１２
３つの性能保証型タスクＡ、Ｂ、Ｃ
他に、ベストエフォート型タスクＸ１、Ｘ２、・・・、Ｘｎ
性能保証型のタスクＡ、Ｂ、Ｃは、各々次の性能保証区間を有し、それらの目標処理時間が次のように指定されている。
12 processor cores Effective threads Nall = 12
Three performance-guaranteed tasks A, B, C
In addition, best effort type tasks X1, X2,..., Xn
The performance guarantee type tasks A, B, and C each have the following performance guarantee section, and their target processing times are designated as follows.
タスクＡ 性能保証区間SEC-A： 目標処理時間75ms
タスクＢ 性能保証区間SEC-B： 目標処理時間80ms
タスクＣ 性能保証区間SEC-C： 目標処理時間75ms
各性能保証区間に対するスレッド−性能対応表は図９に示す通りである。
Task A Performance guarantee section SEC-A: Target processing time 75ms
Task B Performance assurance section SEC-B: Target processing time 80ms
Task C Performance assurance section SEC-C: Target processing time 75ms
The thread-performance correspondence table for each performance guarantee section is as shown in FIG.
処理負荷については、初期状態では、タスクＡ、Ｂ、Ｃともに、通常の処理負荷量を持つが、その後、図１０に示すような処理負荷の変動が発生する動作事例を考える。図１０では、横軸は時刻、縦軸は予定処理負荷量である。 Regarding the processing load, in the initial state, all tasks A, B, and C have normal processing load amounts, but consider an operation example in which processing load fluctuations as shown in FIG. 10 occur thereafter. In FIG. 10, the horizontal axis represents time, and the vertical axis represents scheduled processing load.
図１１は、タスクＡ、Ｂ、Ｃのそれぞれの予定処理負荷量が図１０のように変化したときの、タスク状態表の内容の変化を示す。図１２乃至図２０は、タスクＡ、Ｂ、Ｃのそれぞれの性能保証区間SEC-A、SEC-B、SEC-Cにおける、目標処理時間と実際の処理時間を示す。 FIG. 11 shows changes in the contents of the task state table when the scheduled processing load amounts of the tasks A, B, and C change as shown in FIG. 12 to 20 show the target processing time and the actual processing time in the performance guarantee sections SEC-A, SEC-B, and SEC-C of the tasks A, B, and C, respectively.
以下、図１０のタイミングT0からT5のそれぞれにおける動作を順に説明する。
１）時刻T0
時刻T0において、タスクＡは自らの負荷が通常通りであることを把握し、タスクＡ内の性能保証区間SEC-Aの実行を開始する。実行の開始に先立ちタスクＡは、次のパラメータを伴って、タスクＡにリンクされたスレッド制御ライブラリの性能保証区間開始エントリを呼び出す。
Hereinafter, the operation at each of the timings T0 to T5 in FIG. 10 will be described in order.
1) Time T0
At time T0, task A grasps that its own load is normal, and starts executing the performance guarantee section SEC-A in task A. Prior to the start of execution, task A calls the performance guarantee section start entry of the thread control library linked to task A with the following parameters.
区間名＝SEC-A, 予定処理負荷量＝1, 完了時間要求値＝75ms
すると、タスクＡにリンクされたスレッド制御ライブラリは、次のメッセージＭ１をリソース制御プロセスに送信する。
Section name = SEC-A, Scheduled processing load = 1, Completion time required value = 75 ms
Then, the thread control library linked to the task A transmits the next message M1 to the resource control process.
（コマンド＝区間開始, プロセスID＝TID-A, 区間名＝SEC-A, 予定処理負荷量＝1, 完了時間要求値＝75ms）・・・Ｍ１
リソース制御プロセスは、メッセージＭ１を受信し、まず、リソース制御プロセス内のスレッド要求量決定部１１が要求スレッド数を求める。その際、スレッド要求量決定部１１は、図９に示すスレッド−性能対応表内のSEC-Aの対応表を参照し、処理時間に予定処理負荷量である１を乗じた値が、処理完了時間要求値である75を下回るものとして、スレッド数＝２を見つける。これにより、スレッド要求量決定部は要求スレッド数をＮinc＝２と決定する。
(Command = section start, process ID = TID-A, section name = SEC-A, scheduled processing load = 1, completion time request value = 75 ms) ... M1
The resource control process receives the message M1, and first, the thread request
次に、リソース制御プロセス（リソース制御部１０）内のスレッド配分決定部１３が、タスクＡへのスレッド割当を決定する。メッセージＭ１の到着直前のタスク状態表（図１１（a））では、タスクＩＤは登録されていない。従って、
高優先実行中（PRIO-RUN)のタスクへのスレッド配分数Ｎold＝０
であり、
有効スレッド数Ｎall＝１２
であるから、
Ｎold＋Ｎinc＜Ｎall
となり、タスクＡには要求通り高優先スレッドが２個割り当てられる。これによりタスク状態表は図１１（b）のようになる。
Next, the thread
Number of threads allocated to high-priority task (PRIO-RUN) tasks Nold = 0
And
Number of effective threads Nall = 12
Because
Nold + Ninc <Nall
Thus, two high priority threads are assigned to task A as requested. As a result, the task state table becomes as shown in FIG.
また、スレッド配分決定部はタスクＡのスレッド制御ライブラリに対し次のメッセージＭ２を送信する。 In addition, the thread distribution determination unit transmits the next message M2 to the thread control library of task A.
（高優先スレッド割当 スレッド数＝２）・・・Ｍ２
メッセージＭ２を受信し、タスクＡのスレッド制御ライブラリはスレッドプールから２個の待機中高優先スレッドを選び、それらのスレッドに性能保証区間SEC-Aの実行を開始させる。
(High-priority thread allocation number of threads = 2) M2
Upon receiving the message M2, the thread control library of task A selects two waiting high priority threads from the thread pool, and causes these threads to start executing the performance guarantee section SEC-A.
このように、タスクＡ側で、性能保証区間SEC-Aの開始時にリソース制御プロセスにスレッド割当数を問い合わせる。そして、リソース制御プロセスによる２個の高優先スレッドの割当の決定を受けて、タスクＡでは性能保証区間SEC-Aを２スレッドでの並列実行を開始する。この状態を図１２（a）に示す。ここで点線は目標処理時間、実線は実際の処理時間を表す。すなわち、SEC-Aでは、目標処理時間75msに対し、２スレッドでの実行により50msで処理が終了している。 As described above, the task A inquires the resource control process about the number of threads allocated at the start of the performance guarantee section SEC-A. Then, in response to the determination of the allocation of the two high priority threads by the resource control process, the task A starts parallel execution with two threads in the performance guarantee section SEC-A. This state is shown in FIG. Here, the dotted line represents the target processing time, and the solid line represents the actual processing time. That is, in SEC-A, the processing is completed in 50 ms by executing with two threads with respect to the target processing time of 75 ms.
システム内には合計２４個のスレッドが生成され、SEC-A以外の期間及び表示された以外のスレッドでは、ベストエフォート型タスクＸ１〜ＸｎからＯＳによって選択されたタスクがベストエフォートで実行される。 A total of 24 threads are generated in the system, and tasks selected by the OS from the best effort tasks X1 to Xn are executed at best effort in a period other than SEC-A and threads other than those displayed.
図１０の例では、時刻T0では、タスクＡに加え、タスクＢ及びタスクＣもそれぞれの性能保証区間の実行が開始される。そこで、上記と同様に、タスクＢ及びタスクＣのスレッド制御ライブラリはリソース制御プロセスに対し次のメッセージＭ３、Ｍ４を送信する。 In the example of FIG. 10, at time T0, in addition to task A, task B and task C also start executing their respective performance guarantee sections. Therefore, as described above, the thread control libraries of task B and task C send the following messages M3 and M4 to the resource control process.
（コマンド＝区間開始, プロセスID＝TID-B, 区間名＝SEC-B, 予定処理負荷量＝1, 完了時間要求値＝80ms）・・・Ｍ３
（コマンド＝区間開始, プロセスID＝TID-C, 区間名＝SEC-C, 予定処理負荷量＝1, 完了時間要求値＝75ms）・・・Ｍ４
リソース制御プロセスは、まずSEC-Bに関するメッセージＭ３を処理する。
(Command = section start, process ID = TID-B, section name = SEC-B, scheduled processing load = 1, completion time request value = 80 ms) ... M3
(Command = section start, process ID = TID-C, section name = SEC-C, scheduled processing load = 1, completion time request value = 75 ms) M4
The resource control process first processes the message M3 related to SEC-B.
図９のスレッド−性能対応表より、SEC-B実行に必要なスレッド数は１であり、要求スレッド数Ｎinc＝１となる。 From the thread-performance correspondence table of FIG. 9, the number of threads necessary for SEC-B execution is 1, and the number of requested threads Ninc = 1.
図１１（b）のタスク状態表より、高優先実行中タスクへのスレッド配分数Ｎold＝２であるから、スレッド配分決定部は、タスクＢに対し、要求通り高優先スレッドを１個だけ割り当てる判断を下す。そして、スレッド配分決定部は、タスクＢのスレッド制御ライブラリに対して、
（高優先スレッド割当 スレッド数＝１）・・・Ｍ５
とのメッセージＭ５を送信し、タスクＢにてSEC-Bが１スレッドで実行が開始される。
From the task state table of FIG. 11B, since the thread allocation number Nold = 2 to the high-priority executing task, the thread allocation determination unit determines to allocate only one high-priority thread to task B as requested. Down. Then, the thread allocation determination unit performs the task B thread control library on
(High-priority thread allocation thread count = 1) ... M5
Message M5 is transmitted, and in task B, execution of SEC-B is started in one thread.
リソース制御プロセスは引き続きSEC-Cに関するメッセージＭ４を処理する。図９のスレッド−性能対応表より、SEC-C実行に必要なスレッド数は２であるから、Ｎinc＝２となる。高優先実行中タスクへのスレッド配分数Ｎold＝３であるから、スレッド配分決定部はタスクＣに対し要求通り高優先スレッドを２個だけ割り当てる判断を下す。そして、スレッド配分決定部は、タスクＣのスレッド制御ライブラリに対して、
（高優先スレッド割当 スレッド数＝2）・・・Ｍ６
とのメッセージＭ６を送信し、タスクＣにてSEC-Cが２スレッドで実行が開始される。
The resource control process continues to process message M4 for SEC-C. From the thread-performance correspondence table of FIG. 9, the number of threads required for SEC-C execution is 2, so Ninc = 2. Since the thread allocation number Nold = 3 to the high-priority executing task, the thread allocation determination unit determines to allocate only two high-priority threads to the task C as requested. Then, the thread allocation determination unit performs the task C thread control library on
(High priority thread allocation number of threads = 2) ... M6
Message M6 is transmitted, and execution of SEC-C in two threads is started in task C.
ここまでで、タスク状態表は図１１（c）のように更新される。図１２（b）は、このときの性能保証区間各々の実行の様子を示す。SEC-A, SEC-B, SEC-Cには各々２スレッド, １スレッド, ２スレッドが割り当てられ、いずれも目標処理時間以下で処理が行われている。
２）時刻T1
時刻T1でタスクＡがSEC-Aを実行しようとするとき、タスクＡは自らの負荷が通常の２倍であることを認知し、タスクＡのスレッド制御ライブラリはリソース制御プロセスに次のメッセージＭ７を送信する。
Up to this point, the task status table is updated as shown in FIG. FIG. 12B shows how each performance guarantee section is executed at this time. SEC-A, SEC-B, and SEC-C are assigned 2 threads, 1 thread, and 2 threads, respectively, and processing is performed within the target processing time.
2) Time T1
When task A tries to execute SEC-A at time T1, task A recognizes that its load is twice that of normal, and the thread control library of task A sends the next message M7 to the resource control process. Send.
（コマンド＝区間開始, プロセスID＝TID-A, 区間名＝SEC-A, 予定処理負荷量＝2, 完了時間要求値＝75ms）・・・Ｍ７
リソース制御プロセスは、予定処理負荷量＝２であることから、SEC-A実行にはスレッド数３が必要と認識する。このときタスクＢ、Ｃは性能保証区間SEC-B, SEC-Cの前回実行を終えているから、この時点での高優先実行中タスクへのスレッド配分数Ｎold＝０である。従って、リソース制御プロセスはSEC-Aに要求通り３スレッドを割当することを決定する。
(Command = section start, process ID = TID-A, section name = SEC-A, scheduled processing load = 2, completion time request value = 75 ms) ... M7
The resource control process recognizes that the number of threads is three for executing SEC-A because the scheduled processing load = 2. At this time, since the tasks B and C have completed the previous execution of the performance guarantee sections SEC-B and SEC-C, the thread allocation number Nold = 0 to the high priority execution task at this time. Therefore, the resource control process decides to allocate 3 threads to SEC-A as requested.
続いて、時刻T1でタスクＢ、Ｃもそれぞれ性能保証区間SEC-B, SEC-Cの実行を新たに開始しようとする。これらの予定処理負荷量はいずれも１である。上記でSEC-Aに３スレッド割り当ててＮold＝３であるから、SEC-B, SEC-Cには要求どおり１, ２スレッドを割当可能と判断する。これによりタスク状態表は図１１（d）のように更新される。 Subsequently, at time T1, tasks B and C try to newly start execution of the performance guarantee sections SEC-B and SEC-C, respectively. These scheduled processing load amounts are all 1. Since 3 threads are allocated to SEC-A and Nold = 3, it is determined that 1 or 2 threads can be allocated to SEC-B and SEC-C as requested. As a result, the task status table is updated as shown in FIG.
図１３は、このときの性能保証区間各々の実行の様子を示す。タスクＡでは負荷が２倍になったが、割当スレッド数が３に増加したことによって目標処理時間以内に処理を終了している。
３）時刻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）のように更新される。そして、リソース制御プロセスからタスクＡのスレッド制御ライブラリへは次のメッセージＭ８が送信される。
FIG. 13 shows the state of execution of each performance guarantee section at this time. In task A, the load has doubled, but the processing is completed within the target processing time because the number of assigned threads has increased to three.
3) Time T2
At time T2, in addition to the task A load remaining twice, the task B load increases five times. The resource control process recognizes that the number of request threads of task B is 6, and after confirming that the total number of request threads is less than the number of effective threads Nall, assigns six high priority threads to task B as requested. Also, it is determined that two threads can be assigned to task C as requested, as in the latest. The task status table at this time is shown in FIG. 11 (e), and the state of execution is shown in FIG.
4) Time T3
At time T3, the load on task A returns to the normal level, but the load on task B is slightly reduced, but is still four times the normal, and the load on task C is increased to twice the normal. At this time, the resource control process calculates the number of request threads of task A, task B, and task C to be 2, 5, and 4, respectively, and since the sum of these is less than Nall, the number of requests for each task is equal to the number of requests. Make a decision to assign a high priority thread. The task status table at this time is shown in FIG. 11 (f), and the state of execution is shown in FIG.
5) Time T4
At time T4, the load on task A doubles again. The resource control process recognizes that the number of request threads from task A is 3 (ie, Ninc = 3). However, since nine high-priority threads have already been assigned to SEC-B and SEC-C by the start of SEC-B and SEC-C immediately before (that is, Nold = 9), Nold + Ninc ≧ Nall. For this reason, the resource control process cannot assign a high-priority thread to the task A, and determines the normal thread assignment. At this time, the task state table is updated as shown in FIG. Then, the next message M8 is transmitted from the resource control process to the thread control library of task A.
（通常スレッド割当 スレッド数＝３）・・・Ｍ８
これにより、タスクＡの性能保証区間SEC-Aは、通常の優先度しか持たない３つのスレッドにより実行される。これらのスレッドはベストエフォート型タスクＸ１、Ｘ２、・・・、Ｘｎを実行するスレッドとＣＰＵリソースを共有するため、SEC-Aの実行性能は必ずしも保証されない。しかし、これは、既に実行中の性能保証区間SEC-B及びSEC-Cの実行性能を引き続き保証するためにやむを得ない措置と判断される。そこで、リソース制御プロセスは、SEC-Aに対して性能保証できなくなった旨のメッセージをログに記録する、あるいは制御コンソールに出力する等の、異常発生時の所定の処理を行う。
(Normal thread allocation thread count = 3) M8
As a result, the performance guarantee section SEC-A of task A is executed by three threads having only normal priority. Since these threads share CPU resources with threads that execute the best effort tasks X1, X2,..., Xn, the execution performance of SEC-A is not necessarily guaranteed. However, this is considered to be an unavoidable measure for continuing to guarantee the execution performance of the performance guarantee sections SEC-B and SEC-C that are already being executed. Therefore, the resource control process performs predetermined processing when an abnormality occurs, such as recording a message indicating that performance cannot be guaranteed for SEC-A in a log or outputting it to the control console.
時刻T4の直後、タスクＣの性能保証区間SEC-Cが一旦終了すると、タスクＣからリソース制御プロセスへ次のメッセージＭ９が送信される。 Immediately after time T4, once the performance guarantee section SEC-C of task C ends, the next message M9 is transmitted from task C to the resource control process.
（コマンド＝区間終了, プロセスID＝TID-C, 区間名＝SEC-C）・・・Ｍ９
リソース制御プロセス内のスレッド配分決定部は、タスク状態表（図１１（g）の状態にある）を参照し、SEC-Cに割り当てられていた高優先スレッドが２個であったことを知る（Ｎdec＝２）。SEC-C以外の高優先スレッド数の合計Ｎold＝５であり、Ｎfree＝１２−５＋２＝９であるから、タスク状態表内のタスクＡに対するエントリ（TID-Aの行）が高優先スレッドの再割当先となる。すなわち、スレッド配分決定部は、通常スレッド３つが割り当てられていたタスクＡに対し高優先スレッド３個を再割当することを決定し、タスク状態表を図１１（h）のように更新するとともに、タスクＡのスレッド制御ライブラリに対し
（高優先スレッド再割当 スレッド数＝３）・・・Ｍ１０
なるメッセージＭ１０を送信する。
(Command = end of section, process ID = TID-C, section name = SEC-C) ... M9
The thread allocation determination unit in the resource control process refers to the task state table (in the state of FIG. 11 (g)) and knows that there are two high priority threads assigned to SEC-C ( Ndec = 2). Since the total number of high priority threads other than SEC-C is Nold = 5 and Nfree = 12-5 + 2 = 9, the entry for task A in the task state table (TID-A row) Become the assignee. That is, the thread allocation determination unit determines to reallocate three high priority threads to the task A to which three normal threads are allocated, and updates the task state table as shown in FIG. For the thread control library of task A (high-priority thread reallocation thread count = 3) ... M10
The message M10 is transmitted.
メッセージＭ１０を受信し、タスクＡのスレッド制御ライブラリはSEC-Aを実行している各スレッドのスレッド属性を”リアルタイムスケジューリングポリシー”に変更する。すなわち、タスクＡの性能保証区間SEC-Aには本来必要な数の高優先スレッドが割り当てられ、以後性能保証された形で実行される。このときの実行の様子を図１５に示す。
６）時刻T5
時刻T5にて、タスクＣが再び通常負荷で性能保証区間SEC-Cを開始すると、リソース制御プロセスは前記手順に沿って、SEC-Cに対し高優先スレッド２個を割り当てることを決定する。このときのタスク状態表を図１１（i）に示す。
Upon receiving the message M10, the thread control library of task A changes the thread attribute of each thread executing SEC-A to “real-time scheduling policy”. In other words, a necessary number of high priority threads are allocated to the performance guarantee section SEC-A of task A, and thereafter, the performance is guaranteed and executed. The state of execution at this time is shown in FIG.
6) Time T5
When the task C starts the performance guarantee section SEC-C again with the normal load at time T5, the resource control process determines to allocate two high priority threads to the SEC-C according to the above procedure. The task status table at this time is shown in FIG.
このように、本実施形態によれば、処理負荷の変動に応じてスレッド割当を動的に変化させ、各処理に常に適切なＣＰＵリソースを配分する。従って、指定された箇所の処理時間が所定の時間内に収まるようにできるとともに、空いたＣＰＵリソースは他のベストエフォート型処理に最大限振り向けることができる。 As described above, according to the present embodiment, thread allocation is dynamically changed according to fluctuations in processing load, and appropriate CPU resources are always allocated to each process. Therefore, the processing time of the designated location can be kept within a predetermined time, and the free CPU resource can be allocated to other best effort type processing as much as possible.
以上、スレッドと処理時間との対応が図９の通りで、予定処理負荷量が図１０のように変化したときの、タスク状態表の内容の変化及び各期間における目標処理時間と実際の処理時間について説明した。 As described above, the correspondence between the thread and the processing time is as shown in FIG. 9, and the change in the contents of the task state table and the target processing time and the actual processing time in each period when the scheduled processing load changes as shown in FIG. Explained.
ここで比較の対象として、適切なスレッド配分を行わなかった場合の動作例を示してみる。 Here, as an object of comparison, an example of operation when appropriate thread distribution is not performed will be shown.
第４の実施形態として先の動作事例にあげたものと同じシステム及びタスク構成を想定するが、今回は、性能保証型タスクＡ、Ｂ、Ｃに対して最初から十分な数のスレッドを割り当てておいた場合をとりあげる。図９のスレッド−性能対応表に示すように、タスクＡ、Ｂ、Ｃの各性能保証区間は最大６スレッドによる並列処理が可能であるから、各タスクには６スレッドずつ固定的に割り当てておく。 Assuming the same system and task configuration as those described in the previous operation example as the fourth embodiment, this time, a sufficient number of threads are allocated to the performance guarantee type tasks A, B, and C from the beginning. Take up the case. As shown in the thread-performance correspondence table of FIG. 9, each performance guarantee section of tasks A, B, and C can be processed in parallel by a maximum of 6 threads, so 6 threads are fixedly assigned to each task. .
この場合、システム内には性能保証型タスク向けだけで計１８個のスレッドがあり、ベストエフォート型タスク向けも含めれば、１８個以上のスレッドが存在する。これらのスレッドには物理的なＣＰＵコアリソースがＯＳによって平均化されて割り当てられる。先の動作事例ではＮall＝１２すなわちシステム内には１２個のスレッドのみが存在するとしたが、今回は１８個以上のスレッドが存在するため、各スレッドに割り当てられるＣＰＵコアリソースは平均的に１２÷１８すなわち３分の２以下となる。そのため、各性能保証区間の実行時間も図９に示す値の１．５倍（３分の２の逆数）以上になる。 In this case, there are a total of 18 threads for the performance-guaranteed task only in the system, and 18 or more threads exist for the best-effort task. These threads are allocated with physical CPU core resources averaged by the OS. In the previous operation example, Nall = 12, that is, only 12 threads exist in the system. However, since there are 18 or more threads this time, the CPU core resource allocated to each thread is 12 ÷ on average. 18 or 2/3 or less. Therefore, the execution time of each performance guarantee section is also 1.5 times the value shown in FIG. 9 (the reciprocal of 2/3) or more.
時刻T0での各性能保証区間の実行の様子を図１７に示す。本発明技術の適用時の時刻T0での実行の様子（図１３）に比べ、各処理は短時間に完了しており、低負荷状態では低レイテンシで処理が行われている。 FIG. 17 shows how each performance guarantee section is executed at time T0. Each process is completed in a short time compared to the state of execution at time T0 when the present invention technique is applied (FIG. 13), and the process is performed with low latency in a low load state.
同様に時刻T1での実行の様子を図１８に示す。時刻T2での実行の様子を図１９に示す。高負荷になったタスクＢは、所定の時間内に処理が終えられなくなっている。 Similarly, the state of execution at time T1 is shown in FIG. FIG. 19 shows the state of execution at time T2. The task B that has become heavily loaded cannot finish processing within a predetermined time.
また時刻T3での実行の様子を図１９に示す。ここでも高負荷状態のタスクＢ及びタスクＣは所定の時間内に処理が終えられなくなっている。これは、各タスクに対し必要以上のスレッドを割り当てた結果、タスクの並列処理効率が低下してＣＰＵコアリソースが無駄に消費されてしまい、真に急ぐべきタスクの処理が間に合わなくなっていることを意味する。 FIG. 19 shows the state of execution at time T3. Here again, the tasks B and C in the high load state cannot be completed within a predetermined time. This means that as a result of allocating more threads than necessary to each task, the parallel processing efficiency of the task is reduced and CPU core resources are wasted, and the task processing that should be really rushed is not in time. means.
このように、単純に潤沢な数のスレッドを割り当てておくだけでは、負荷変動が生じた際に性能保証できなくなる場面が出てくる。 In this way, simply assigning an abundant number of threads will cause a situation where performance cannot be guaranteed when load fluctuation occurs.
本実施形態のリソース配分システムは、最適なスレッド配分を通じて最適なＣＰＵコアリソースの配分を行うことで、負荷変動が生じても性能保証できる可能性を高め、万一性能保証できない場合もその旨を警告する機能を提供するものである。 The resource allocation system according to the present embodiment increases the possibility of guaranteeing the performance even if load fluctuation occurs by allocating the optimal CPU core resource through the optimum thread allocation. It provides a warning function.
なお、以上の実施形態は、各々の全体又は一部を、他の実施形態と組み合わせることができる。 In addition, the above embodiment can combine the whole or one part with other embodiment.
１２ スレッド−性能対応表
１２１、１２２、１２３ スレッド−性能対応表エントリ
１４ タスク状態表
12 Thread-performance correspondence table 121, 122, 123 Thread-performance
Claims (9)
前記性能保証区間を有する性能保証型タスクから、前記性能保証区間の実行開始前に、前記性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び前記性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、前記処理完了時間要求値、前記予定処理負荷量及び前記リソース−性能対応情報に基づいて前記性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定し、前記性能保証区間に対して前記第２のリソース量のリソースが割り当てられたことを示す割当通知を前記性能保証型タスクに送信するリソース要求量決定部と、
前記性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持するタスク状態保持部と、
割当対象となりうるリソースの総量である第４のリソース量、前記第２のリソース量及び前記第３のリソース量に基づいて、前記性能保証区間に対する前記第２のリソース量のリソースの割当の可否を決定するリソース配分決定部と、
を備えることを特徴とするリソース配分システム。 A first resource amount that is an amount of a resource assumed to be allocated to the task for processing in a performance guarantee section in which a certain level of processing performance guarantee is required in the task, and the task includes the first resource A performance information holding unit for holding resource-performance correspondence information indicating a correspondence relationship with processing performance in the performance guarantee section when an amount of resources is allocated;
From the performance guarantee type task having the performance guarantee section, before the start of the execution of the performance guarantee section, a process completion time requirement value indicating a time at which the process of the performance guarantee section should be completed and the performance guarantee section are scheduled. A request amount of a resource used for processing in the performance guarantee section is received based on the processing completion time request value, the scheduled processing load amount, and the resource-performance correspondence information. A resource request amount determination unit that determines the resource amount of 2 and transmits an allocation notification indicating that the resource of the second resource amount is allocated to the performance assurance section to the performance assurance type task;
A task state holding unit for holding a third resource amount indicating the amount of resources currently allocated to the performance-guaranteed task;
Based on the fourth resource amount, which is the total amount of resources that can be assigned, the second resource amount, and the third resource amount, whether or not the resource of the second resource amount can be assigned to the performance guarantee interval is determined. A resource allocation determination unit to determine;
A resource distribution system comprising:
ことを特徴とする請求項１記載のリソース配分システム。 The resource allocation determination unit determines whether or not to allocate based on a comparison result between a total of the third resource amount and the second resource amount and a fourth resource amount. Item 4. The resource allocation system according to Item 1.
前記性能保証区間の実行開始に先立って生成された所定の数の前記高優先スレッドを待機させるスレッドプールを含み、前記リソース制御部からの指示により、前記スレッドプール内の前記高優先スレッドに対する前記性能保証区間の実行の開始を指示する機能、又は前記性能保証区間を実行中のスレッドの優先度若しくはスケジューリング属性を変更する機能を有し、前記リソース要求量決定部に前記予定処理負荷量及び前記処理完了時間要求値とを通知し、前記割当通知に基づき、前記高優先スレッドを用いて前記性能保証区間の実行制御を行うスレッド制御部を備え、
前記リソース要求量決定部は、前記予定処理負荷量と前記処理完了時間要求値から前記第２のリソース量として、前記スレッドプール内の前記高優先スレッドの数を決定する
ことを特徴とする、請求項１又は２に記載のリソース配分システム。 The resource whose allocation is determined by the resource allocation determination unit is a high priority thread given a higher priority than a normal thread,
A thread pool that waits for a predetermined number of the high-priority threads generated prior to the start of execution of the performance-guaranteed section, and the performance for the high-priority threads in the thread pool according to an instruction from the resource control unit A function for instructing start of execution of the guaranteed section, or a function for changing the priority or scheduling attribute of a thread executing the performance guaranteed section, and the resource request amount determination unit includes the scheduled processing load amount and the processing A thread control unit that notifies a completion time request value and performs execution control of the performance guarantee section using the high-priority thread based on the allocation notification;
The resource request amount determination unit determines the number of high priority threads in the thread pool as the second resource amount from the scheduled processing load amount and the processing completion time request value. Item 3. The resource allocation system according to Item 1 or 2.
前記タスク状態保持部は、前記性能保証区間が性能保証状態で実行されているか非性能保証状態で実行されているかを表すタスク実行状態、及び前記性能保証区間に対して割り当てられている前記割当スレッドの数である前記第３のリソース量を保持し、
前記予定処理負荷量は、前記性能保証区間に与えられた処理対象のデータの量の、前記規定量に対する比の値であり、
前記リソース要求量決定部は、第１の前記性能保証型タスクから前記性能保証区間の開始を通知する性能保証区間開始通知を受信したとき、前記リソース−性能対応情報における前記処理時間に前記予定処理負荷量を乗じた値が、前記処理完了時間要求値を下回る最小の前記割当スレッド数を前記第２のリソース量とし、
前記リソース配分決定部は、
前記タスク状態保持部が保持する前記性能保証状態で実行されているスレッドの総数に、前記第２のリソース量を加えた合計値が前記第４のリソース量を下回る場合は、前記第１の性能保証型タスクに前記第２のリソース量の前記高優先スレッドを割り当て、前記第１の性能保証型タスクが前記性能保証状態で実行されている旨を前記タスク状態保持部に記録し、
前記第１の値が前記第４のリソース量値以上である場合は、前記第１の性能保証型タスクに前記第２のリソース量の通常スレッドを割り当て、前記非性能保証状態で実行されている旨を前記タスク状態保持部に記録し、
第２の前記性能保証型タスクから前記性能保証区間の終了を通知する性能保証区間終了通知を受信したとき、前記第２の性能保証型タスクに対して、前記第２の性能保証型タスクに割り当てられていた前記高優先度スレッドを返却させて、前記第３のリソース量を更新する、
ことを特徴とする、請求項３記載のリソース配分システム。 The resource-performance correspondence information includes the first resource amount that is the number of assigned threads assumed to be assigned to the performance guarantee section given a specified amount of processing target data, and the assigned thread assigns the resource-performance correspondence information. Represents the correspondence with the processing time when
The task state holding unit includes a task execution state indicating whether the performance guarantee section is executed in a performance guarantee state or a non-performance guarantee state, and the assigned thread assigned to the performance guarantee section Holding the third resource amount that is the number of
The scheduled processing load amount is a value of a ratio of the amount of processing target data given to the performance guarantee section to the specified amount,
The resource request amount determination unit receives the performance guarantee section start notification for notifying the start of the performance guarantee section from the first performance guarantee type task, and performs the scheduled processing at the processing time in the resource-performance correspondence information. The minimum number of allocated threads that is less than the processing completion time requirement value multiplied by the load amount is the second resource amount,
The resource allocation determination unit
When a total value obtained by adding the second resource amount to the total number of threads executed in the performance guarantee state held by the task state holding unit is less than the fourth resource amount, the first performance Assigning the high-priority thread of the second resource amount to the guaranteed task, and recording in the task state holding unit that the first guaranteed performance task is being executed in the guaranteed performance state,
When the first value is greater than or equal to the fourth resource amount value, a normal thread having the second resource amount is allocated to the first performance guarantee type task and is executed in the non-performance guarantee state. Is recorded in the task state holding unit,
When a performance guarantee section end notification for notifying the end of the performance guarantee section is received from the second performance guarantee type task, the second performance guarantee type task is assigned to the second performance guarantee type task. Returning the high-priority thread that was being used, and updating the third resource amount,
The resource allocation system according to claim 3, wherein:
前記第２の性能保証型タスクから前記性能保証区間終了通知を受信したとき、前記非性能保証状態で実行されており、かつ、前記合計値が前記第４のリソース量を下回るような前記性能保証区間を、前記タスク状態表を参照して第２の性能保証区間として選択し、
前記第２の性能保証区間に、前記第２のリソース量の前記高優先スレッドを割り当て、前記第２の性能保証区間が前記性能保証状態で実行されている旨を前記タスク状態保持部に記録し、
前記第２の性能保証区間を有するタスクに対し、前記第２のリソース量の前記高優先スレッドの割当を通知する
ことを特徴とする、請求項４記載のリソース配分システム。 The resource allocation determination unit
When the performance assurance section end notification is received from the second performance assurance type task, the performance assurance is executed in the non-performance assurance state and the total value is less than the fourth resource amount Select the section as the second performance guarantee section with reference to the task state table,
The high priority thread of the second resource amount is allocated to the second performance guarantee section, and the fact that the second performance guarantee section is executed in the performance guarantee state is recorded in the task state holding unit. ,
5. The resource allocation system according to claim 4, wherein the task having the second performance guarantee section is notified of the allocation of the high priority thread of the second resource amount.
前記第１の性能保証型タスクから前記性能保証区間開始通知を受信したとき、前記第２のリソース量のリソースを割り当てることができないと判断した場合に、前記性能保証区間の実行を一時保留し、
前記第２の性能保証型タスクから前記性能保証区間終了通知を受信したとき、一時保留状態にある前記性能保証区間のうち、前記性能保証区間終了通知によって終了が通知された前記性能保証区間に割り当てられていたリソースを再配分することによって前記第２のリソース量を満たすことができる前記性能保証区間を、前記タスク状態表を参照して第３の性能保証区間として選択し、前記第３の性能保証区間に前記第２の必要リソース量のリソースを割り当てて実行を再開させる
ことを特徴とする、請求項４又は請求項５記載のリソース配分システム。 The resource allocation determination unit
When the performance guarantee section start notification is received from the first performance guarantee type task, when it is determined that the resource of the second resource amount cannot be allocated, the execution of the performance guarantee section is temporarily suspended,
When the end of the performance guarantee section is received from the second performance assurance type task, the performance guarantee section allocated temporarily to the performance guarantee section whose end has been notified by the performance guarantee section end notification among the performance guarantee sections in the temporarily suspended state The performance guarantee section that can satisfy the second resource amount by redistributing the allocated resources is selected as a third performance guarantee section with reference to the task state table, and the third performance 6. The resource allocation system according to claim 4, wherein execution of the resource allocation is resumed by allocating the second required resource amount to the guaranteed section.
前記性能保証型タスクから、前記性能保証区間の実行開始前に、前記性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び前記性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信し、
前記処理完了時間要求値、前記予定処理負荷量及び前記リソース−性能対応情報に基づいて前記性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定し、
割当対象となりうるリソースの総量である第４のリソース量、前記第２のリソース量及び前記第３のリソース量に基づいて、前記性能保証区間に対する前記第２のリソース量のリソースの割当の可否を決定し、
前記性能保証区間に対して前記第２のリソース量のリソースが割り当てられたことを示す割当通知を前記性能保証型タスクに送信する
ことを特徴とするリソース配分方法。 A first resource amount that is an amount of a resource assumed to be allocated to the task for processing in a performance guarantee section in which a certain level of processing performance guarantee is required in the task, and the task includes the first resource The resource-performance correspondence information indicating the correspondence relationship with the processing performance in the performance guarantee section when an amount of resources is assigned, and the amount of resources currently assigned to the performance guarantee type task having the performance guarantee section Hold a third resource amount,
From the performance guarantee type task, before the start of execution of the performance guarantee section, a processing completion time requirement value indicating a time to complete processing of the performance guarantee section and a processing load amount scheduled in the performance guarantee section are represented. Receive scheduled processing load,
Determining a second resource amount that is a required amount of a resource to be used for processing in the performance guarantee section based on the processing completion time requirement value, the scheduled processing load amount, and the resource-performance correspondence information;
Based on the fourth resource amount, which is the total amount of resources that can be assigned, the second resource amount, and the third resource amount, whether or not the resource of the second resource amount can be assigned to the performance guarantee interval is determined. Decide
A resource allocation method, comprising: transmitting an allocation notification indicating that a resource of the second resource amount has been allocated to the performance guarantee section to the performance guarantee type task.
タスクにおいて一定以上の処理性能の保証が要求される性能保証区間の処理のために前記タスクへ割り当てられたと仮定されたリソースの量である第１のリソース量と、前記タスクに前記第１のリソース量のリソースが割り当てられたときの前記性能保証区間における処理性能との対応関係を表すリソース−性能対応情報、及び前記性能保証区間を有する性能保証型タスクに現在割り当てられているリソースの量を表す第３のリソース量を保持する保持手段と、
前記性能保証型タスクから、前記性能保証区間の実行開始前に、前記性能保証区間の処理が完了されるべき時間を表す処理完了時間要求値及び前記性能保証区間で予定される処理負荷量を表す予定処理負荷量を受信する受信手段と、
前記処理完了時間要求値、前記予定処理負荷量及び前記リソース−性能対応情報に基づいて前記性能保証区間の処理に用いるリソースの要求量である第２のリソース量を決定する要求量決定手段と、
割当対象となりうるリソースの総量である第４のリソース量、前記第２のリソース量及び前記第３のリソース量に基づいて、前記性能保証区間に対する前記第２のリソース量のリソースの割当の可否を決定する割当決定手段と、
前記性能保証区間に対して前記第２のリソース量のリソースが割り当てられたことを示す割当通知を前記性能保証型タスクに送信する通知手段
として機能させるためのリソース配分プログラム。 The computer provided in the resource allocation system
A first resource amount that is an amount of a resource assumed to be allocated to the task for processing in a performance guarantee section in which a certain level of processing performance guarantee is required in the task, and the task includes the first resource The resource-performance correspondence information indicating the correspondence relationship with the processing performance in the performance guarantee section when an amount of resources is assigned, and the amount of resources currently assigned to the performance guarantee type task having the performance guarantee section Holding means for holding a third resource amount;
From the performance guarantee type task, before the start of execution of the performance guarantee section, a processing completion time requirement value indicating a time to complete processing of the performance guarantee section and a processing load amount scheduled in the performance guarantee section are represented. A receiving means for receiving the scheduled processing load amount;
Requested amount determining means for determining a second resource amount that is a requested amount of a resource used for processing in the performance guarantee section based on the processing completion time request value, the scheduled processing load amount, and the resource-performance correspondence information;
Based on the fourth resource amount, which is the total amount of resources that can be assigned, the second resource amount, and the third resource amount, whether or not the resource of the second resource amount can be assigned to the performance guarantee interval is determined. An allocation determination means to determine;
A resource allocation program for causing an allocation notification indicating that a resource of the second resource amount has been allocated to the performance guarantee section to function as a notification unit that transmits to the performance guarantee type task.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012046963A JP6007516B2 (en) | 2012-03-02 | 2012-03-02 | Resource allocation system, resource allocation method, and resource allocation program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012046963A JP6007516B2 (en) | 2012-03-02 | 2012-03-02 | Resource allocation system, resource allocation method, and resource allocation program |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2013182502A true JP2013182502A (en) | 2013-09-12 |
| JP6007516B2 JP6007516B2 (en) | 2016-10-12 |
Family
ID=49273093
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012046963A Active JP6007516B2 (en) | 2012-03-02 | 2012-03-02 | Resource allocation system, resource allocation method, and resource allocation program |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6007516B2 (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017168814A1 (en) * | 2016-03-28 | 2017-10-05 | 株式会社日立産機システム | Controller apparatus and task execution management method for controller apparatus |
| WO2018198745A1 (en) * | 2017-04-27 | 2018-11-01 | 日本電気株式会社 | Calculation resource management device, calculation resource management method, and computer-readable recording medium |
| CN113032113A (en) * | 2019-12-25 | 2021-06-25 | 中科寒武纪科技股份有限公司 | Task scheduling method and related product |
| CN113641517A (en) * | 2021-08-10 | 2021-11-12 | 平安科技（深圳）有限公司 | Service data sending method and device, computer equipment and storage medium |
| JP2022045666A (en) * | 2020-09-09 | 2022-03-22 | 株式会社日立製作所 | Resource allocation control device, computing system and resource allocation control method |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0628323A (en) * | 1992-07-06 | 1994-02-04 | Nippon Telegr & Teleph Corp <Ntt> | Process execution control method |
| JPH11213143A (en) * | 1998-01-23 | 1999-08-06 | Fuji Xerox Co Ltd | Image processor and image processing time predicting method |
| JP2000322394A (en) * | 1999-05-13 | 2000-11-24 | Canon Inc | Picture forming device, plotting assigning method and storage medium |
| JP2010160552A (en) * | 2009-01-06 | 2010-07-22 | Nec Corp | Resource distribution device, method thereof, and program |
| JP2011180725A (en) * | 2010-02-26 | 2011-09-15 | Nec Corp | System, method and program for hybrid parallel processing |
| JP2011181032A (en) * | 2010-03-04 | 2011-09-15 | Nec Corp | Server device, information processing method, and program |
| JP2011197846A (en) * | 2010-03-18 | 2011-10-06 | Fujitsu Ltd | Information processor, parallel computing control method, program, and parallel computing system |
-
2012
- 2012-03-02 JP JP2012046963A patent/JP6007516B2/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0628323A (en) * | 1992-07-06 | 1994-02-04 | Nippon Telegr & Teleph Corp <Ntt> | Process execution control method |
| JPH11213143A (en) * | 1998-01-23 | 1999-08-06 | Fuji Xerox Co Ltd | Image processor and image processing time predicting method |
| JP2000322394A (en) * | 1999-05-13 | 2000-11-24 | Canon Inc | Picture forming device, plotting assigning method and storage medium |
| JP2010160552A (en) * | 2009-01-06 | 2010-07-22 | Nec Corp | Resource distribution device, method thereof, and program |
| JP2011180725A (en) * | 2010-02-26 | 2011-09-15 | Nec Corp | System, method and program for hybrid parallel processing |
| JP2011181032A (en) * | 2010-03-04 | 2011-09-15 | Nec Corp | Server device, information processing method, and program |
| JP2011197846A (en) * | 2010-03-18 | 2011-10-06 | Fujitsu Ltd | Information processor, parallel computing control method, program, and parallel computing system |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017168814A1 (en) * | 2016-03-28 | 2017-10-05 | 株式会社日立産機システム | Controller apparatus and task execution management method for controller apparatus |
| JP2017182105A (en) * | 2016-03-28 | 2017-10-05 | 株式会社日立産機システム | Controller device and method for managing tasks of controller device |
| TWI646412B (en) * | 2016-03-28 | 2019-01-01 | 日立產機系統股份有限公司 | Controller device and task execution management method of controller device |
| WO2018198745A1 (en) * | 2017-04-27 | 2018-11-01 | 日本電気株式会社 | Calculation resource management device, calculation resource management method, and computer-readable recording medium |
| JPWO2018198745A1 (en) * | 2017-04-27 | 2020-03-05 | 日本電気株式会社 | Computing resource management device, computing resource management method, and program |
| US11204805B2 (en) | 2017-04-27 | 2021-12-21 | Nec Corporation | Computational resource management apparatus which optimizes computational resources to be allocated to tasks having a dependency relationship, computational resource management method and computer readable recording medium |
| CN113032113A (en) * | 2019-12-25 | 2021-06-25 | 中科寒武纪科技股份有限公司 | Task scheduling method and related product |
| JP2022045666A (en) * | 2020-09-09 | 2022-03-22 | 株式会社日立製作所 | Resource allocation control device, computing system and resource allocation control method |
| JP7191906B2 (en) | 2020-09-09 | 2022-12-19 | 株式会社日立製作所 | RESOURCE ALLOCATION CONTROL DEVICE, COMPUTER SYSTEM, AND RESOURCE ALLOCATION CONTROL METHOD |
| CN113641517A (en) * | 2021-08-10 | 2021-11-12 | 平安科技（深圳）有限公司 | Service data sending method and device, computer equipment and storage medium |
| CN113641517B (en) * | 2021-08-10 | 2023-08-29 | 平安科技（深圳）有限公司 | Service data transmitting method, device, computer equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6007516B2 (en) | 2016-10-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9262181B2 (en) | Process grouping for improved cache and memory affinity | |
| US9483319B2 (en) | Job scheduling apparatus and method therefor | |
| KR101626378B1 (en) | Apparatus and Method for parallel processing in consideration of degree of parallelism | |
| US20150309842A1 (en) | Core Resource Allocation Method and Apparatus, and Many-Core System | |
| JP6007516B2 (en) | Resource allocation system, resource allocation method, and resource allocation program | |
| CN108549574B (en) | Thread scheduling management method and device, computer equipment and storage medium | |
| US9875139B2 (en) | Graphics processing unit controller, host system, and methods | |
| KR20110075295A (en) | Job allocation method on multi-core system and apparatus thereof | |
| CN105786603B (en) | Distributed high-concurrency service processing system and method | |
| CN112783659B (en) | Resource allocation method and device, computer equipment and storage medium | |
| KR20100074920A (en) | Apparatus and method for load balancing in multi-core system | |
| CN111625339A (en) | Cluster resource scheduling method, device, medium and computing equipment | |
| CN111352735A (en) | Data acceleration method, device, storage medium and equipment | |
| CN112925616A (en) | Task allocation method and device, storage medium and electronic equipment | |
| CN113535087B (en) | Data processing method, server and storage system in data migration process | |
| US9740530B2 (en) | Decreasing the priority of a user based on an allocation ratio | |
| US20150212859A1 (en) | Graphics processing unit controller, host system, and methods | |
| KR20190056624A (en) | Resource assignment method using Continuous Double Auction protocol in distributed processing environment, recording medium and distributed processing device applying the same | |
| CN112114877A (en) | Method for dynamically compensating thread bundle warp, processor and computer storage medium | |
| JP2015148909A (en) | Parallel computer system, control method of parallel computer system, and control program of management node | |
| JP2013114538A (en) | Information processing apparatus, information processing method and control program | |
| WO2014188642A1 (en) | Scheduling system, scheduling method, and recording medium | |
| JP2008225641A (en) | Computer system, interrupt control method and program | |
| KR20130104958A (en) | Apparatus and methods for executing multi-operating systems | |
| JP2022539956A (en) | MEMORY MANAGEMENT METHOD AND RELATED PRODUCTS |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20150216 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20150825 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20151006 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20151207 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20160510 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160711 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160816 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160829 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6007516 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |