JP2008276666A - 情報処理装置および方法、並びにプログラム - Google Patents

Abstract

【課題】CPU使用帯域の保証を容易に実現することができるようにする。
【解決手段】プロセススケジューラ１５は、CPUの帯域が保証されているユーザプロセス１４であって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移するユーザプロセス１４の状態を、ユーザプロセス１４を実行する周期時間毎に実行状態に遷移させ、帯域保証ライブラリ２１は、周期時間を、一定の間隔でCPUに割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、CPUの帯域を管理することで、CPU使用帯域の保証を容易に実現することができるようになる。本発明は、パーソナルコンピュータに適用できる。
【選択図】図１

Description

本発明は、情報処理装置および方法、並びにプログラムに関し、特に、CPU（Central Processing Unit）使用帯域の保証を容易に実現することができるようにした情報処理装置および方法、並びにプログラムに関する。

従来より、周期時間単位で起動されたタスクを管理する手法が知られている。特許文献１に開示されている計算機のプロセススケジューラでは、OS（Operating System）がサポートするスケジューラ上に、ユーザレベルプロセススケジューラを、第１の優先度（最も高い優先度）のリアルタイムプロセスとして実装し、周期時間とCPU使用時間でCPUの使用率を計算している。ユーザプロセスはユーザレベルプロセススケジューラよりも低い優先度で実行されているため、最高優先度で動作しているユーザレベルプロセススケジューラが動作中であると、他のプロセスは動作できない。

この特許文献１では、周期時間が迫るプロセスが存在した場合、OSのシグナル機能を使用して、ユーザレベルプロセススケジューラに対し、周期時間であることを通知する。通知を受けた該ユーザレベルプロセススケジューラは、インデックスの内容に従って、順次、動作開始予定のプロセスに対して、OSのシグナル機能を使用して、「実行停止状態」から「実行可能状態」へ状態遷移させる。

その後、ユーザプロセスのCPU使用時間分、ユーザレベルプロセススケジューラ自身をusleep関数（マイクロ秒単位でプロセスの実行を延期する関数）でスリープ（待ち状態）させることで、ユーザレベルプロセススケジューラは「実行状態」から「待ち状態」に遷移する。その結果、次に優先度の高いユーザプロセスが「実行可能状態」から「実行状態」に遷移し、usleep関数でスリープしている時間分、ユーザプロセスは動作可能となる。

ユーザレベルプロセススケジューラは、usleep関数から戻ると、「待ち状態」から「実行状態」に遷移し、逆に、「実行状態」となっていたユーザプロセスは「実行状態」から「待ち状態」に遷移する。ユーザレベルプロセススケジューラはまた、OSのシグナル機能を利用して、該ユーザプロセスを「待ち状態」から「実行停止状態」に遷移させる。

このように、特許文献１では、最高優先度のユーザレベルプロセススケジューラが、ユーザプロセスのタスク状態をOSのシグナル機能を利用して変更すると共に、ユーザレベルプロセススケジューラ自身が、所定の時間、スリープ（待ち状態）に遷移することで、ユーザプロセスの定期的実行を管理している。

また、特許文献２においては、タスクの遅延保証と効率的なタスクの実行方法について提案されている。
特開平９−５４６９９号公報 特開平１０−１７１６６７号公報

しかしながら、OSの機能であるusleep関数は、例えばLinux2.6のマニュアルによると、「usleep関数は“少なくとも”指定されたマイクロ秒の間、呼び出し元のプロセスの実行を延期する。」となっており、正確な時間動作は保証されておらず、場合によっては、指定した時間よりも長くスリープしてしまう可能性がある。また、上記特許文献１では、周期時間についての詳細な説明は記載されていないが、仮に、usleep関数により全ての実行時間と周期時間を管理しているとすると、usleep関数の誤差が蓄積され、周期時間の誤差が大きくなる可能性があるという問題があった（以下、「第１の課題」と称する）。

さらに、特許文献１では、複数種類の周期が存在した場合、その周期時間の最小公倍数を基準周期として、ユーザプロセススケジューラ内で、各周期時間を考慮しつつ、全てのユーザプロセスが確実に実行されるように、プロセス管理表を生成する必要も出てくる。特許文献１には、そのような手法については記載されていないが、周期内に正確にCPU割り当てを行うプロセススケジューリング方法として、レートモノトニックスケジューリングやデッドラインモノトニックスケジューリングなどが広く一般的に使われている。しかし、これらの処理は複雑であるため、スケジューリング処理をユーザプロセススケジューラに実装することにより、CPU使用時間の圧迫やユーザプロセス投入から実際の実行までの遅延時間の増加などが懸念されるという問題もでてくる（以下、「第２の課題」と称する）。

さらにまた、ユーザプロセススケジューラがusleep関数の実行中、すなわち、ユーザプロセスに実行権限を与えている途中に、例えば、ユーザプロセスのI/O（Input/Output）待ちなどにより、「待ち状態」となった際の検出方法として、ユーザプロセスと同一優先度、あるいは下位の優先度のブロック検出プロセスにより、「待ち状態」を検出し、ブロックされている期間、他のプロセス（特許文献１では、タイムシェアリングクラスのプロセス）にCPUを割り当て、I/Oブロッキングから戻った際に、本来の該ユーザプロセスに割り当てたCPU使用時間の残り分についてCPUを割り当てている。従って、I/O待ちでブロックされたユーザプロセスが使用したCPU時間は、見かけ上、該ユーザプロセスが申告しているCPU使用時間とI/O待ち時間とを足し合わせた時間となり、これは申告時間を超過していることになる。

さらに、ユーザプロセスが１つであれば、特に問題にはならないが、複数のユーザプロセスが同一のI/Oにアクセスし、「待ち状態」となった場合、そのCPU使用時間の管理は複雑になることが予想される。従って、複数のユーザプロセスについて、I/O待ちまで含めたCPU使用時間を管理、保証することが困難であるという問題がある（以下、「第３の課題」と称する）。

また、上記特許文献２によると、遅延保証が必要なタスクについて、要求処理時間と許容遅延時間との和が小さい順にタスクの優先度を高くすることで、全てのタスクにおいて遅延保証を実現している。この特許文献２に記載されたタスク管理方法は、特許文献１におけるユーザプロセススケジューラの動作に該当する。特許文献２では、タイマにより一定時間毎にCPU割り込みを発生させ、タスクの動作時間を管理しているため、特許文献１における上記第１の課題については考慮する必要はないが、タイマ割り込み毎に、要求処理時間と許容遅延時間との和が小さい順にタスクの優先度を高くするためのCPU演算時間や優先度設定処理などによって、リソースを圧迫してしまう。これは特許文献１における上記第２の課題と同様である。また、特許文献２においては、I/O待ちによるプロセスの「待ち状態」については考慮されていない。

このように、特許文献１および特許文献２のいずれにしても、ある周期時間内にCPU使用時間を保証することはできたとしても、それ以上のCPU時間を使用することができないという問題がある。これは、例えば、動画データを扱うソフトウェアを考えた場合、動画データはある一定時間内に、一定量のデータをハンドリングしなければスムーズな動画再生を望むことはできない。そのため、ある周期時間に対し、CPUなどのリソース使用時間を保証する必要がある。そこで、特許文献１および特許文献２のように、周期時間を決め、その周期時間内に使用するリソース使用時間を保証する方法が考案されてきた。

しかしながら、例えば、上述した、動画データを再生する処理について考えると、その処理の流れは、ファイルから動画データを読み取り、メモリに動画データをバッファリングし、然るべき処理で動画データを再生する。この際、ファイルからのデータ読み出し遅延や、場合によっては、画像処理用に数秒分の動画データが必要となる場合があるため、再生する前に、予め数秒分の動画データがバッファリングされている必要がある。特許文献１や特許文献２のように、プロセスが周期時間内に決められたリソース使用時間しか使用できないと、上述した、バッファリングする処理に複数周期分の処理時間を要し、例えば、ユーザによって再生ボタンが押下されてから、実際に動画データが画面上に再生されるまでの時間が長くなってしまう。また、早送り動作などにおいても、一定のレートで動画データを読むのではなく、瞬時に複数周期分の動画データを処理する必要が出てくる。これは、周期時間内に決められたCPU使用時間以上を使用することができないことが原因で発生する問題である（以下、「第４の課題」と称する）。

この第４の課題を、特許文献１および特許文献２により解決しようとすると、予め、多めにCPU使用時間を確保しておく必要があり、その結果、CPU使用時間の保証可能な帯域が削減されてしまう。

以上のように、従来の方法では、第１の課題乃至第４の課題があるために、CPU使用帯域の保証を容易に実現することができないという問題があった。

本発明はこのような状況に鑑みてなされたものであり、CPU使用帯域の保証を容易に実現することができるようにするものである。

本発明の一側面の情報処理装置は、複数のプロセスを実行するためのリソースを有する情報処理装置において、前記リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間毎に、前記実行可能状態から前記実行状態に遷移させる状態制御手段と、前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御する実行制御手段とを備え、前記状態制御手段は、前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる。

前記実行制御手段には、前記プロセスから申告されてくる前記実行周期時間と、前記実行周期時間内で占有する前記リソースのリソース使用時間とから得られるリソース使用率であって、既に、前記リソースの使用を保証している全てのプロセスの前記リソース使用率の合計が、所定の閾値未満になる場合、前記実行周期時間を前記基準周期時間の2ⁿ倍とさせることができる。

前記実行優先度は、前記実行周期時間の短いプロセスほど高く設定されるようにすることができる。

前記状態制御手段には、前記リソース使用率が、前記閾値から前記リソース使用率の合計を減じた値よりも小さい場合、前記実行周期時間に係わらず、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させることができる。

前記状態制御手段には、既に、前記リソースの使用を保証している全てのプロセスから申告された前記実行周期時間のうち、最長の実行周期時間内の任意の時間となったとき、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させることができる。

前記実行制御手段には、前記プロセスが前記実行状態から前記実行可能状態に遷移した時間と、前記プロセスから申告された前記リソース使用時間とを比較し、申告された前記リソース使用時間よりも、前記実行可能状態に遷移した時間のほうが短い場合、その差分を余り時間として積算させ、前記状態制御手段には、前記余り時間の積算値が前記プロセスの申告した前記リソース使用時間よりも大きい場合、前記実行周期時間に係わらず、前記プロセスの状態を、実行可能状態から実行状態に遷移させることができる。

前記実行制御手段には、前記余り時間の積算値を、前記リソースの使用を保証している全てのプロセスから申告された前記実行周期時間のうち、最長の実行周期時間となったとき、0にクリアさせることができる。

前記実行制御手段には、前記プロセスの状態が、実行可能状態から実行状態に遷移される際に、前記リソースの使用を保証している全てのプロセスを再投入する処理を行うときの優先度である再投入優先度に基づいて、前記余り時間に再投入するプロセスを特定させることができる。

前記再投入優先度は、前記プロセスの状態に係わらず、任意の時間に設定または変更可能であるようにすることができる。

前記リソースは、CPU使用時間であるようにすることができる。

前記CPU使用時間は、ブロッキングI/Oの使用時間を含んでいるようにすることができる。

前記リソースは、非ブロッキングI/Oの使用時間を含んでおり、前記実行制御手段は、前記リソースの使用を保証している全てのプロセスのCPU使用率の合計が予め定められた第１の閾値未満となり、かつ、前記プロセスのうち、非ブロッキングI/Oの前記リソースの使用も保証しているプロセスの前記非ブロッキングI/O毎のリソース使用率の合計が予め定められた第２の閾値未満となるようにすることができる。

1回のI/Oアクセスサイズを、前記基準周期時間内に処理可能なサイズに分割する分割手段をさらに設けることができる。

前記実行制御手段には、前記リソースの使用を保証しているプロセスが申告したリソース使用時間を超過した場合、前記プロセスの前記実行優先度を一時的に下げさせることができる。

前記実行制御手段には、前記実行優先度を下げられたプロセスの1周期分の処理が完了したとき、前記実行優先度を元の値に戻させることができる。

前記実行制御手段には、前記実行優先度を下げられたプロセスの前記実行周期時間が再度経過したとき、前記実行優先度を元の値に戻させることができる。

本発明の一側面の情報処理方法は、複数のプロセスを実行するためのリソースを有する情報処理装置の情報処理方法において、前記リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間毎に、前記実行可能状態から前記実行状態に遷移させ、前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御し、前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させるステップを含む。

本発明の一側面のプログラムは、複数のプロセスを実行するためのリソースを有する情報処理装置の情報処理を、コンピュータに行わせるプログラムにおいて、前記リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間毎に、前記実行可能状態から前記実行状態に遷移させ、前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御し、前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させるステップを含む。

本発明の一側面においては、リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移するプロセスの状態が、所定の実行周期時間毎に、実行可能状態から実行状態に遷移され、実行周期時間の設定可能値が、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とされることで、プロセスの実行が制御され、基準周期時間の2ⁿ倍とされた実行周期時間毎に、プロセスの状態が、実行可能状態から実行状態に遷移される。

以上のように、本発明の一側面によれば、CPU使用帯域の保証を容易に実現することができる。

以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書または図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書または図面に記載されていることを確認するためのものである。従って、明細書または図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。

本発明の一側面の情報処理装置は、複数のプロセスを実行するためのリソースを有する情報処理装置において、前記リソースの使用が保証されているプロセス（例えば、図１のユーザプロセス１４）であって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間（例えば、起動周期時間）毎に、前記実行可能状態から前記実行状態に遷移させる状態制御手段（例えば、図１のプロセススケジューラ１５）と、前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間（例えば、基準周期T）の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御する実行制御手段（例えば、図１の帯域保証ライブラリ２１）とを備え、前記状態制御手段は、前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる（例えば、図８のステップＳ３４の処理）。

前記実行制御手段は、前記プロセスから申告されてくる前記実行周期時間と、前記実行周期時間内で占有する前記リソースのリソース使用時間とから得られるリソース使用率であって、既に、前記リソースの使用を保証している全てのプロセスの前記リソース使用率の合計が、所定の閾値未満になる場合、前記実行周期時間を前記基準周期時間の2ⁿ倍とする（例えば、図２のステップＳ１３の処理）。

前記実行優先度は、前記実行周期時間の短いプロセスほど高く設定される（例えば、図２のステップＳ１６の処理）。

前記状態制御手段は、前記リソース使用率が、前記閾値から前記リソース使用率の合計を減じた値よりも小さい場合、前記実行周期時間に係わらず、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる（例えば、図１５のステップＳ９４の処理）。

前記状態制御手段は、既に、前記リソースの使用を保証している全てのプロセスから申告された前記実行周期時間のうち、最長の実行周期時間内の任意の時間となったとき、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる（例えば、図１５のステップＳ９４の処理）。

前記実行制御手段は、前記プロセスが前記実行状態から前記実行可能状態に遷移した時間と、前記プロセスから申告された前記リソース使用時間とを比較し、申告された前記リソース使用時間よりも、前記実行可能状態に遷移した時間のほうが短い場合、その差分を余り時間として積算し（例えば、図１４のステップＳ１７２の処理）、前記状態制御手段は、前記余り時間の積算値が前記プロセスの申告した前記リソース使用時間よりも大きい場合、前記実行周期時間に係わらず、前記プロセスの状態を、実行可能状態から実行状態に遷移させる（例えば、図１５のステップＳ９４の処理）。

前記実行制御手段は、前記余り時間の積算値を、前記リソースの使用を保証している全てのプロセスから申告された前記実行周期時間のうち、最長の実行周期時間となったとき、0にクリアする（例えば、図１６のステップＳ１１４の処理）。

前記実行制御手段は、前記プロセスの状態が、実行可能状態から実行状態に遷移される際に、前記リソースの使用を保証している全てのプロセスを再投入する処理を行うときの優先度である再投入優先度に基づいて、前記余り時間に再投入するプロセスを特定する（例えば、図２１のステップＳ１５３の処理）。

前記リソースは、非ブロッキングI/Oの使用時間（例えば、ハードディスクドライブアクセスにおけるデータ待ち時間）を含んでおり、前記実行制御手段は、前記リソースの使用を保証している全てのプロセスのCPU使用率の合計が予め定められた第１の閾値未満（例えば、式（２））となり、かつ、前記プロセスのうち、非ブロッキングI/Oの前記リソースの使用も保証しているプロセスの前記非ブロッキングI/O毎のリソース使用率の合計が予め定められた第２の閾値未満（例えば、式（７））となるようにする（例えば、図２のステップＳ１３の処理）。

1回のI/Oアクセスサイズを、前記基準周期時間内に処理可能なサイズに分割する分割手段（例えば、図２８のアクセスサイズ分割部２１４）をさらに備えることができる。

前記実行制御手段は、前記リソースの使用を保証しているプロセスが申告したリソース使用時間を超過した場合、前記プロセスの前記実行優先度を一時的に下げる（例えば、図１４のステップＳ７４の処理）。

前記実行制御手段は、前記実行優先度を下げられたプロセスの1周期分の処理が完了したとき、前記実行優先度を元の値に戻す（例えば、図１６のステップＳ１１３の処理）。

前記実行制御手段は、前記実行優先度を下げられたプロセスの前記実行周期時間が再度経過したとき、前記実行優先度を元の値に戻す（例えば、図１６のステップＳ１１３の処理）。

本発明の一側面の情報処理方法またはプログラムは、複数のプロセスを実行するためのリソースを有する情報処理装置の情報処理方法において、または、複数のプロセスを実行するためのリソースを有する情報処理装置の情報処理を、コンピュータに行わせるプログラムにおいて、前記リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間毎に、前記実行可能状態から前記実行状態に遷移させ（例えば、図８のステップＳ３４の処理）、前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御し（例えば、図２のステップＳ１１の処理）、前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる（例えば、図８のステップＳ３４の処理）ステップを含む。

本発明の一側面のプログラムは、記録媒体（例えば、図３０のリムーバブルメディア３２１）に記録することができる。

以下、図面を参照しながら本発明の実施の形態について説明する。

図１は、本発明を適用したプロセススケジューリングシステムの一実施の形態の構成を示すブロック図である。

プロセススケジューリングシステム１は、一定の間隔でCPUに対して割り込みをかけるタイマ１１、タイマ割り込みにより周期時間を監視し、起動すべきプロセスが存在するか否かを判定する帯域管理部１２、各プロセスの起動周期時間やCPU時間（CPU使用時間）を保持する起動周期管理テーブル１３、決められた周期内に、決められたCPU使用時間を消費するユーザプロセス１４、プロセスの実行優先度（優先度）に応じて、ユーザプロセス１４を実行可能な状態に遷移させるプロセススケジューラ１５、およびユーザプロセス１４が起動されるべき時間に到達したら起動を指示する起動指示部１６を含むようにして構成される。以下、複数の実施の形態を説明するため、図１の構成を有するプロセススケジューリングシステム１を、第１の実施の形態と称して説明する。

なお、プロセススケジューリングシステム１には、図示しない、CPU（例えば後述する図３０のCPU３１１）やそのCPUにより実行されるOS（第１の実施の形態ではLinux2.6を使用した場合の例を説明する）、メモリ（例えば後述する図３０のRAM３１３）なども備えられており、例えば、一般的なパーソナルコンピュータ（例えば後述する図３０のパーソナルコンピュータ）やワークステーションと同等な構成上に、プロセススケジューリングシステム１は実装される。また、帯域管理部１２、起動周期管理テーブル１３、および起動指示部１６は、図中の点線で囲まれているが、これらのブロックをまとめて、帯域保証ライブラリ２１と称する。つまり、ユーザプロセス１４を開発する開発者は、開発しているユーザプロセス１４と帯域保証ライブラリ２１とをリンクさせることで、CPU使用帯域の保証が容易に実現可能となる。なお、帯域保証ライブラリ２１には、タイマ１１またはプロセススケジューラ１５を加えるようにしてもよい。

次に、図１の各ブロックの動作の内容について、順を追って説明する。

タイマ１１は、例えば、水晶振動子などを使用して、マイクロ秒（us）からミリ秒（ms）単位で正確に時刻を刻む機器から得られる信号を基に、設定された時間間隔でCPU割り込みを発生させる。なお、第１の実施の形態では、そのCPU割り込みの発生間隔を50msに設定し、この発生間隔を後述する基準周期Tとする。

起動指示部１６は、タイマ１１により基準周期T毎に発生させられるCPU割り込みを受け、然るべきタイミングで、ユーザプロセス１４に対してイベント（以下、プロセス実行イベントと称する）を通知する。このイベントの通知方法の詳細については後述する。

ユーザプロセス１４は、CPU使用時間を保証する必要があるプロセス（以下、CPU帯域保証型プロセスと称する）である。ユーザプロセス１４は、起動指示部１６からのプロセス実行イベントにより、「待ち状態」から「実行可能状態」に遷移し、プロセススケジューラ１５からの指示に従って、「実行可能状態」から「実行状態」に遷移することで起動される。なお、ユーザプロセス１４の状態遷移の詳細については後述する。

また、ユーザプロセス１４は、起動時に、起動周期時間と、その周期時間内に使用するCPU使用時間を帯域管理部１２に申告（通知）する。なお、図１では、説明を簡略化するために、ユーザプロセス１４は、１つだけ記載されているが、実際のシステムでは、複数種類のユーザプロセスがマルチタスクで動作可能となる。

帯域管理部１２は、ユーザプロセス１４から申告されてくる起動周期時間とCPU使用時間を、起動周期管理テーブル１３に格納する。また、帯域管理部１２は、起動周期管理テーブル１３に格納されたデータを基に、その申告を行ってきたユーザプロセス１４が実行可能であるか否かを判定する。

起動周期管理テーブル１３は、図示しないメモリ（例えば後述する図３０のRAM３１３）上に管理されており、ユーザプロセス１４のプロセスID、起動周期時間、CPU使用時間などの、ユーザプロセス１４から申告された情報を格納する。

ここで、プロセスIDとは、ユーザプロセス１４のプロセスを生成する際に、OSから発行されるシステム固有のIDである。このプロセスIDを利用して、実行優先度の設定や、起動、停止、強制終了などの様々な機能をOSが提供している。

プロセススケジューラ１５は、帯域管理部１２からの指示に従って、プロセスの優先度に応じて、ユーザプロセス１４の状態を「実行可能状態」から「実行状態」に遷移させる。

次に、図２のフローチャートを参照して、図１の帯域管理部１２によって行われる、帯域管理処理について説明する。

帯域管理部１２は、ユーザプロセス１４から起動周期時間（周期時間）とCPU使用時間が申告（通知）されたとき、図２のフローチャートの処理を実行する。

帯域管理部１２は、ステップＳ１１において、ユーザプロセス１４から通知された起動周期時間を基に、周期判定処理を実行し、起動周期時間が基準周期Tの2ⁿ倍となるか否かを判定する。

ここで、起動周期時間であるが、第１の実施の形態では、タイマ１１により発生される基準周期の2ⁿ倍（nは0から始まる整数値）に制限される。すなわち、例えば、基準周期Tが50msに設定されている場合、ユーザプロセス１４の申告可能な起動周期時間は、50，100，200，400，・・・，50×2ⁿとなる。従って、帯域管理部１２は、ユーザプロセス１４からの起動周期時間が基準周期Tの2ⁿ倍となるか否かを判定する処理を行う。

ステップＳ１１において、基準周期Tの2ⁿ倍以外であると判定された場合、ステップＳ１２において、帯域管理部１２は、起動周期時間を申告してきたユーザプロセス１４に対して、エラーを通知し、帯域管理処理は終了する。これにより、ユーザプロセス１４は、基準周期Tの2ⁿ倍以外の起動周期時間を申告できない。

一方、ステップＳ１１において、基準周期Tの2ⁿ倍となると判定された場合、ステップＳ１３において、帯域管理部１２は、ユーザプロセス１４にCPU帯域を割り当てられるか否かを判定する。

具体的には、帯域管理部１２は、ユーザプロセス１４から申告された起動周期時間とCPU使用時間から、式（１）を用いて、CPU使用率CPU_PROCを求める。

CPU_PROC ＝ CPU使用時間 ÷ 周期時間 ・・・（１）

次に、帯域管理部１２は、図示しないメモリ（内部記憶領域）に保存されている既存のCPU使用率合計値CPU_ALLと、式（１）により演算されたCPU_PROCが、下記の式（２）を満たすか否かを判定する。

CPU_ALL ＋ CPU_PROC ＜ THL_CPU ・・・（２）

なお、THL_CPUは、プロセススケジューリングシステム１において、CPU帯域保証型プロセスに割り当てることが可能な最大のCPU帯域である。例えば、CPU帯域の80％をCPU帯域保証型プロセスに割り当てる場合には、残りの20％はOSのカーネル処理やCPU使用時間を保証する必要のないユーザアプリケーションなどに割り当てられる。言い換えれば、THL_CPUは、CPU帯域におけるCPU帯域保証型プロセスの割合を決定するための閾値であるとも言える。

従って、帯域管理部１２は、例えば、式（２）を用いて、ユーザプロセス１４にCPU帯域を割り当てられるか否かを判定する。

ステップＳ１３において、CPU帯域を割り当てることができないと判定された場合、ユーザプロセス１４の動作を保証できるだけのCPU使用時間を確保できないので、ステップＳ１２において、帯域管理部１２は、起動周期時間を申告してきたユーザプロセス１４に対して、エラーを通知し、帯域管理処理は終了する。

一方、ステップＳ１３において、CPU帯域を割り当てることができると判定された場合、ユーザプロセス１４の動作を保証できるだけのCPU使用時間を確保できるので、ステップＳ１４において、帯域管理部１２は、下記の式（３）を用いて、CPU帯域（CPU使用率の合計値であるCPU_ALL）を更新する。

CPU_ALL ＝ CPU_ALL ＋ CPU_PROC ・・・（３）

ステップＳ１５において、帯域管理部１２は、ユーザプロセス１４から申請された起動周期時間と、その周期時間内に使用するCPU使用時間を、起動周期管理テーブル１３に追加する。

ここで、図３を参照して、起動周期管理テーブル１３について説明する。

図３の起動周期管理テーブル１３には、プロセスIDに対応して、周期時間（起動周期時間）とCPU使用時間が格納される。

図３の例では、プロセスID 50に対して周期時間100msとCPU使用時間10ms、プロセスID 51に対して周期時間200msとCPU使用時間20ms、プロセスID 52に対して周期時間400msとCPU使用時間200msがそれぞれ格納される。

すなわち、図３の起動周期管理テーブル１３には、例えば、100ms，200ms，400msなどのように、基準周期T（50ms）の2ⁿ倍となる周期時間（起動周期時間）となるプロセスIDであって、10ms，20ms，200msなどのCPU使用時間から求められるCPU使用率の合計が80％などの所定の閾値以下となる（CPU帯域を割り当て可能となる）プロセスIDだけが格納される。

図２のフローチャートに戻り、ステップＳ１６において、帯域管理部１２は、ユーザプロセス１４の優先度を決定し、その優先度をプロセスIDと共に、プロセススケジューラ１５に設定し、帯域管理処理は終了する。この優先度の決定方法の詳細については後述する。

ところで、上述したように、第１の実施の形態では、OSとして、Linux2.6を使用したときの例について説明するが、ここで、このLinux2.6のプロセススケジューラの概要について説明する。

このプロセススケジューラには、0から99までの静的優先度があり、優先度0が最も優先度が低く、数字が高くなるに従って優先度は高くなる。また、プロセススケジューラには、SCHED_OTHER，SCHED_BATCH，SCHED_FIFO，SCHED_RRの４種類のスケジュール方針がサポートされている。

SCHED_OTHERは、Linux2.6においてデフォルトの一般的な時分割型のスケジューラである。また、SCHED_BATCHは、いわゆるバッチ処理を目的としたスケジューラである。これら、SCHED_OTHERおよびSCHED_BATCHのスケジューリング方針で動作するプロセスを非リアルタイムプロセスと呼び、その静的優先度は0で固定である。

また、SCHED_FIFOは、時分割処理のない単純なスケジューリングアルゴリズムである。SCHED_FIFOはプロセス優先度が高いほど、最優先で処理が実行され、同一優先度のプロセスが複数あった場合は、先に実行されたプロセスが完了するまで、次の処理は実行されないこととなる（いわゆるFIFO（First-In First-Out）処理）。SCHED_RRは、SCHED_FIFOを拡張したものであり、SCHED_FIFOとの違いは、同一優先度のプロセスが複数あった場合、同一優先度内で、ある一定の時間間隔で、いわゆるラウンドロビン（Round Robin）動作をする点である。これら、SCHED_FIFOおよびSCHED_RRのスケジューリング方針で動作するプロセスをリアルタイムプロセスと呼び、その静的優先度は1から99までの値をとる（数値が大きいほど優先度は高くなる）。

第１の実施の形態では、SCHED_FIFOのスケジュール方針を採用した例について説明するので、次に、図４乃至６を参照して、SCHED_FIFOによるプロセススケジューリングについて詳細に説明する。

図４は、OSで管理されているプロセスの状態を表わす遷移図である。

なお、実際のLinux2.6では、プロセスの状態としては図４以外にも存在するが、第１の実施の形態では、説明を簡略化するため、一般的なOSの概念である３つのプロセスの状態遷移を使用して説明する。

図４において、「実行可能状態」は、プロセスの実行準備ができており、CPUさえ割り当てられれば即座に動作可能な状態を表わす。また、「実行状態」は、プロセスにCPUが割り当てられ、各種処理を実行している状態を表わす。なお、CPUの割り当てはCPUの数に依存し、第１の実施の形態では、その数は１つであるとする。従って、第１の実施の形態において、同時にCPUを割り当て可能な数は1となる。

「待ち状態」は、同期オブジェクト（例えばいわゆるセマフォ（Semaphore）など）やキー入力待ち、ハードディスクからのデータ待ちなど、何らかの外部イベントを待っている状態を表わす。

これらの状態をプロセススケジューラ１５は監視し、制御することで、複数のプロセスを処理することが可能となる。

次に、SCHED_FIFOの動作について説明する。図５は、プロセスＡ，Ｂ，Ｃの夫々がシングルプロセスで動作した場合のプロセスの動作開始時間と処理完了時間の例を表わすタイミングチャートである。なお、図５においては、図中のハッチングが施された四角は各プロセスが実行中されていることを示す。また、時間（時刻t）の方向は、図中左から右に向かう方向とされている。なお、このような、図中の四角の意味や時間（時刻t）の方向は、後述する他の図においても同様とされる。

例えば、プロセスＡは、何らかの要因（例えば、タイマ割り込みやユーザキー入力などのイベント）で、時刻t2で起床し、その処理は時刻t3まで継続する。プロセスＡはまた、時刻t5で再度起床し、その処理は時刻t7まで継続する。プロセスＢは、何らかの要因で、時刻t4で起床し、その処理は時刻t6まで継続する。プロセスＣは、何らかの要因で、時刻t1で起床し、その処理は時刻t5まで継続する。

ところが、実際のマルチタスクOSでは、図５のプロセスＡ，Ｂ，Ｃの処理のように、同時に複数の処理が重なってしまうと、動作することができないが、SCHED_FIFOによるスケジューリング方針を採用することで、それを回避することが可能となる。

図６は、SCHED_FIFOによるスケジューリング方針を使用して、図５の各プロセスをスケジューリングした結果の例を示すタイミングチャートである。

なお、図６においては、プロセスＡとプロセスＢとは同一優先度で、その値は60に設定されている。また、プロセスＣは、プロセスＡおよびプロセスＢよりも優先度が低く、その値は10に設定されている。以下、図６では、このような場合におけるSCHED_FIFOによるスケジューリング方法について説明する。

まず、時刻t1で「実行可能状態」になっているプロセスは、プロセスＣのみであるため、図６に示すように、時刻t1からプロセスＣが「実行状態」となる。次に、時刻t2で、プロセスＡが「待ち状態」から「実行可能状態」に遷移したため、プロセスＣよりも優先度の高いプロセスＡは、「実行可能状態」から「実行状態」に遷移する。また同時に、優先度の低いプロセスＣは、「実行状態」から「実行可能状態」に遷移し、一時的に動作が停止する。

プロセスＡは、時刻t3で一連の処理を終了し、「実行状態」から「待ち状態」に遷移する。このとき、プロセスＣよりも優先度の高いプロセスが存在しないため、プロセスＣは、再度、「実行可能状態」から「実行状態」に遷移し、一時的に中断していた動作を再開する。

次に、時刻t4で、プロセスＢが「待ち状態」から「実行可能状態」に遷移したため、プロセスＣよりも優先度の高いプロセスＢが「実行可能状態」から「実行状態」に遷移し、同時に、優先度の低いプロセスＣは、「実行状態」から「実行可能状態」に遷移し、一時的に動作が停止する。また、時刻t5でプロセスＡが「待ち状態」から「実行可能状態」に遷移するが、時刻t5の時点では、プロセスＡと同一優先度のプロセスＢが既に、「実行状態」にあるため、プロセスＡのタスク状態は「実行可能状態」のまま変化しない。

プロセスＢは、時刻t6で一連の処理を終了し、「実行状態」から「待ち状態」に遷移する。このとき、「実行可能状態」となっているプロセスは、プロセスＡとプロセスＣの２つ存在するが、優先度の高いプロセスＡが「実行可能状態」から「実行状態」に遷移することになる。プロセスＡは、時刻t7'で一連の処理を終了し、「実行状態」から「待ち状態」に遷移する。このとき、プロセスＣよりも優先度の高いプロセスは存在しないため、プロセスＣは、再度、「実行可能状態」から「実行状態」に遷移し、一時的に中断していた動作を再開する。その後、時刻t8で、プロセスＣは、「実行状態」から「待ち状態」に遷移する。これにより、全てのプロセスにおける一連の処理が完了する。

なお、当然ながら、図５におけるプロセスＣのCPU使用時間（時刻t5−t1）と、図６におけるプロセスＣのCPU使用時間（［時刻t2−時刻t1］＋［時刻t4−時刻t3］＋［時刻t8−時刻t7'］）とは等しいことになる。

また、帯域管理部１２により設定される優先度（図２のステップＳ１６の処理）には、リアルタイムプロセス、すなわち、静的優先度1から99までの値が設定され、そのスケジューリング方針として、SCHED_FIFOが設定される。この優先度は、図示しないメモリ上に予め用意されている優先度テーブルで管理される。

図７は、優先度テーブルの例を示す図である。

図７の優先度テーブルには、周期時間（起動周期時間）に対応させて、SCHED_FIFO優先度が格納される。図７の例では、周期時間50msには優先度81、周期時間100msには優先度65、周期時間200msには優先度49、周期時間400msには優先度33、周期時間800msには優先度17、周期時間1600msには優先度1がそれぞれ対応付けられて格納される。すなわち、図７の例では、プロセスの実行優先度が周期時間の短いものほど高く設定される。

これにより、プロセススケジューリングシステム１においては、帯域管理部１２によって、ユーザプロセス１４が申告した周期時間（起動周期時間）を基に、プロセスの優先度が一意に決定される。

なお、第１の実施の形態では、基準周期時間Tを50msとし、最大1600msの周期時間までをサポートしているとして説明するが、基準周期時間Tは任意の間隔であればよく、また、最大周期時間およびその途中の周期時間については、基準周期時間Tの2ⁿ倍であれば、如何なる時間であっても同様に処理することが可能である。

優先度テーブルによって優先度が決定された後、帯域管理部１２により、プロセススケジューラ１５には、ユーザプロセス１４のスケジューリング方針と優先度とが設定される。この設定は、例えば、Linux2.6の場合、sched_setscheduler関数を使用する。この関数は、上記プロセスIDとスケジューリング方針、およびその優先度を引数に設定し、実行することで、該プロセスIDに対し、引数で指定されたスケジューリング方針と優先度が適用される。

以上のようにして、帯域管理部１２において、上述したような、帯域管理処理が行われる。

次に、図８のフローチャートを参照して、帯域保証ライブラリ２１からの指示によって行われる、図１のユーザプロセス１４による周期内処理（内部動作）について説明する。

ユーザプロセス１４が、例えば、Linux2.6のデフォルトスケジューリング方針であるSCHED_OTHERにおいて生成されたとき、図８のフローチャートの処理が実行される。なお、ユーザプロセス１４は、例えば、Linux2.6のfork関数やpthread_create関数などにより生成される。

ステップＳ３１において、ユーザプロセス１４は、帯域保証ライブラリ２１（図１の点線部分）の初期化を行う。帯域保証ライブラリ２１の初期化では、ユーザプロセス１４の起動周期時間と該周期時間内に使用するCPU使用時間を、帯域保証ライブラリ２１内の帯域管理部１２に申告する。この申告の動作については、上述した通りである。

ユーザプロセス１４は、ステップＳ３２において、帯域保証ライブラリ２１の初期化に成功したか否かを判定し、初期化に失敗したと判定した場合、ユーザプロセス１４が動作するだけのCPU使用時間が保証されないので、ステップＳ３３において、例えば、エラーログにエラー内容を出力するなど、任意好適なエラー処理を行い、周期内処理は終了する。

一方、ステップＳ３２において、帯域保証ライブラリ２１の初期化に成功したと判定された場合、ユーザプロセス１４の動作が保証されるので、ユーザプロセス１４は、帯域保証ライブラリ２１からのプロセス実行イベントを待つ。なお、この時点で、ユーザプロセス１４は、上述したように、帯域管理部１２によって、該ユーザプロセス１４のスケジューリング方針がSCHED_FIFOに変更され、その優先度は起動周期時間から決定される値に設定されている。

ここで、ユーザプロセス１４におけるプロセス実行イベントを待つ動作とは、図４のプロセスの状態遷移において、「待ち状態」となることを意味する。例えば、Linux2.6では、select関数やセマフォを使用して「待ち状態」に遷移する。また、詳細は後述するが、この帯域保証ライブラリ２１から通知されるプロセス実行イベントは、起動指示部１６により発行されるイベントである（後述する図９のステップＳ５９の処理）。

ステップＳ３４において、帯域保証ライブラリ２１からプロセス実行イベントを受ける、すなわち、例えば、上記select関数から戻ると同時にユーザプロセス１４は、「待ち状態」から「実行可能状態」に遷移する。そして、上述したプロセススケジューラ１５によるCPU割り当てに応じて、「実行可能状態」から「実行状態」に遷移したユーザプロセス１４は、ステップＳ３５において、周期内処理を逐次実行する。

なお、ステップＳ３５の処理は、プロセス起動時に申告したCPU使用時間内に各種の処理を完了する必要がある。また、ここでのCPU使用時間は、単独プロセスとして動作させた場合のCPU使用時間であり、上述した、図６のプロセスＣのように、他のプロセスが処理の間に割り込まないことが前提の時間である。

ステップＳ３６において、ユーザプロセス１４は、周期内処理、すなわち、周期内においてCPUの使用時間を保証する処理を終了するか否かを判定する。ステップＳ３６において、周期内処理を終了しないと判定された場合、ステップＳ３４に戻り、周期内処理を終了すると判定されるまで、ステップＳ３４乃至ステップＳ３６の処理が繰り返される。つまり、ユーザプロセス１４は、再度、帯域保証ライブラリ２１からのプロセス実行イベントを待つことになる。

その後、ステップＳ３６において、周期内処理を終了すると判定された場合、ステップＳ３７において、ユーザプロセス１４は、帯域保証ライブラリ２１に対して帯域の開放を依頼し、周期内処理は終了する。

ここで、帯域の開放の詳細について説明する。帯域保証ライブラリ２１は、ユーザプロセス１４から開放を依頼されると、その依頼は帯域管理部１２に通知される。帯域管理部１２は、開放を依頼してきたユーザプロセス１４のプロセスIDを基に、プロセススケジューラ１５に対して、該プロセスIDのスケジュール方針をSCHED_OTHERに変更させる。なお、上述したように、スケジュール方針の変更には、例えば、Linux2.6のsched_setscheduler関数が使用される。

さらに、帯域管理部１２は、起動周期管理テーブル１３から該当するプロセスIDの起動周期時間とCPU使用時間を取得し、そのCPU使用率CPU_PROCを、上記式（１）により算出する。なお、このCPU使用率CPU_PROCは、再度、式（１）から算出してもよいが、起動周期管理テーブル１３にプロセスIDを追加する際に、CPU使用率CPU_PROCも併せて保持しておき、必要に応じて適宜参照してもよい。

そして、帯域管理部１２は、算出したCPU使用率CPU_PROCを基に、上述した、CPU_ALLを、下記の式（４）により求めて、更新する。

CPU_ALL ＝ CPU_ALL − CPU_PROC ・・・（４）

これにより、ユーザプロセス１４のために確保されていたCPU使用帯域は開放され、ユーザプロセス１４のスケジューリング方針は、Linux2.6のデフォルトの設定である、SCHED_OTHERとなり、ユーザプロセス１４は通常動作を行う。

以上のようにして、ユーザプロセス１４において、上述したような、周期内処理が行われる。

次に、このユーザプロセス１４にプロセス実行イベントを通知する起動指示部１６の詳細について説明する。

起動指示部１６は、タイマ１１から基準周期T毎に発生するCPU割り込み通知を受け、然るべきタイミングでユーザプロセス１４に対し、プロセス実行イベントを通知する。このイベントの通知方法は、例えばLinux2.6のpoll関数をカーネル空間に実装し、上述した、ユーザプロセス１４にコールされているselect関数に値を戻すことで、プロセス実行イベントが通知される。なお、ユーザプロセス１４で使用されるselect関数と、起動指示部１６で使用されるpoll関数の関係については、「Jonathan Corbet，Alessandro Rubini，Greg Kroah-Hartman著，「Linux デバイスドライバ第３版」，オライリー・ジャパン/オーム社，2005年10月発行，ISBN4-87311-253-2」に詳しく説明されている。また、select関数を使用せずに、セマフォやミューテックス（Mutex）など、任意好適な方法でユーザプロセス１４と起動指示部１６との間のイベント交換（同期処理）を実装してもよい。

図９のフローチャートを参照して、図１の起動指示部１６による、起動指示処理について説明する。

起動指示部１６は、ステップＳ５１において、カウンタNを0に初期化し、ステップＳ５２において、タイマ１１からの割り込みを待つ。ここで、上述したように、タイマ１１からの割り込みは基準時間T=50ms毎に発生する。

タイマ１１からの割り込みが発生した場合、起動指示部１６は、ステップＳ５３において、カウンタNの値が2ⁿ未満であるか否かを判定する。

ここで、カウンタNの値と比較される2ⁿは、プロセススケジューリングシステム１に実装されているCPU帯域保証型プロセスのうち、最大周期時間（50ms×2ⁿ）を表わす値である。例えば、プロセススケジューリングシステム１で実行されるCPU帯域保証型プロセスが、図３に示すように、プロセスID 50，51，52の３つである場合、その最大周期時間は400msであり、n=3となる。第１の実施の形態では、図７の優先度テーブルに示すように、基準周期Tに対し、2⁰から2⁵まで（50（50×2⁰）msから1600（50×2⁵）msまで）を周期時間の種類としているため、CPU帯域保証プロセスの周期時間に応じて、nの値を調整すればよいことになる。従って、ステップＳ５３の処理において、カウンタNの値と比較される値は、プロセススケジューリングシステム１内のCPU帯域保証型プロセスが使用する最大周期時間を表わす2ⁿ（例えば1600（50×2⁵））となる。

なお、上述したように、第１の実施の形態では、この範囲に限定されず、基準周期Tに対して2ⁿ倍であれば、任意の周期を設定可能である。

起動指示部１６は、Nが2ⁿ以上であると判定された場合、ステップＳ５４において、N=1とし、Nが2ⁿ未満であると判定された場合、ステップＳ５５において、Nに1を加算する。

そして、起動指示部１６は、ステップＳ５６から始まり、ステップＳ６０で閉じるループ処理を実行する。ステップＳ５６乃至ステップＳ６０のループは、m=0から、mがnより大きくなるまで、mをインクリメントしながらループする。

ステップＳ５７において、起動指示部１６は、カウンタNと2^mとの剰余を求め、剰余があるか否かを判定する。これは、各周期時間の開始時間のときに剰余が0となるので、ステップＳ５７において、剰余があると判定された場合、起動すべきタイミングではないので、ステップＳ５８およびステップＳ５９の処理をスキップして、ループの終端であるステップＳ６０にジャンプする。

一方、ステップＳ５７において、剰余が0であると判定された場合、起動すべきタイミングとなったので、ステップＳ５８において、起動指示部１６は、例えば、図３の起動周期管理テーブル１３を検索して、起動すべきプロセスが存在するか否かを判定する。

すなわち、図３の起動周期管理テーブル１３に、基準周期T×2^mとなる周期時間を持つプロセスが存在する場合、ステップＳ５８において、起動すべきプロセスが存在すると判定され、ステップＳ５９において、起動指示部１６は、その起動すべきプロセスのプロセスIDを基に、該当するユーザプロセス１４にプロセス実行イベントを通知する。

一方、ステップＳ５８において、起動すべきプロセスが存在しないと判定された場合、ステップＳ５９の処理をスキップして、ループの終端であるステップＳ６０にジャンプする。

これにより、起動指示部１６は、現在時刻において、周期起動する必要があるか否かを判定し、然るべきタイミングとなったとき、ユーザプロセス１４に対し、プロセス実行イベントを通知することで、ユーザプロセス１４を「待ち状態」から「実行可能状態」へ状態遷移させることが可能となる。

その後、mがnよりも大きくなるまで、mをインクリメントしながら、ステップＳ５６乃至ステップＳ６０のループ処理が実行され、mがnよりも大きくなると、処理はステップＳ５２に戻り、上述した処理が繰り返される。

以上のようにして、起動指示部１６において、上述したような、起動指示処理が行われる。

次に、図１０と図１１を参照して、この起動指示部１６からのプロセス実行イベントによって起動するユーザプロセス１４の詳細について説明する。

図１０は、図３の起動周期管理テーブル１３に格納された、プロセスID 50，51，52の起動タイミングを生成した結果の例を示すタイミングチャートである。

図１０において、図中の逆三角形の印は、起動指示部１６によって各プロセスに対して起動イベントが通知されたタイミングを表現している。

図１０では、プロセスID 50は、周期時間100msであるので、時刻0ms，時刻100ms，時刻200ms，時刻300ms，時刻400ms，時刻500ms，・・・に起動され、プロセスID 51は、周期時間200msであるので、時刻0ms，時刻200ms，時刻400ms，・・・に起動され、プロセスID 52は、周期時間400msであるので、時刻0ms，時刻400ms，・・・に起動されることを示している。

なお、実際には、イベント通知が重なった場合には、全ての該当するプロセスに対して、完全に同時には通知されないが、実際に処理が動作するタイミングは、「待ち状態」から「実行可能状態」へ遷移した後、プロセススケジューラ１５により優先度に応じて、順次、「実行可能状態」から「実行状態」へ遷移されたときになる。

図１１は、図３の起動周期管理テーブル１３に格納された、プロセスID 50，51，52をスケジューリングし、実行した結果の例を示すタイミングチャートである。

ここで、これらのプロセスID 50，51，52では、帯域管理部１２によって、各プロセスのスケジューリング方針がSCHED_FIFOに設定され、かつ、各プロセスの起動周期時間の短い順に優先度が高くなるように設定されている。

従って、図１１に示すように、プロセスID 50は、起動指示部１６からのプロセス実行イベントを受けると同時に、その状態を、「待ち状態」、「実行可能状態」、「実行状態」の順に、即座に遷移する。またこのとき、プロセスID 51は、起動指示部１６からのプロセス実行イベントを受けると、その状態を、「待ち状態」から「実行可能状態」へ遷移する。

その後、プロセスID 50が然るべき処理を終了し、select関数などをコールし、「待ち状態」となると、次に優先度の高い、プロセスID 51が「実行可能状態」から「実行状態」へと遷移する。同様にまた、プロセスID 52は、プロセスID 50，51の双方が「待ち状態」となっている場合にのみ、「実行状態」に遷移可能となる。このように、プロセスID 50，51，52は、図１０に示したタイミングで起動するが、優先度が高い順に起動するので、結果として、図１１に示したタイミングで起動し、処理を実行することになる。

つまり、このようなプロセス状態の遷移は、上述した、プロセススケジューラ１５によるプロセス１４の動作そのものである。

以上のように、第１の実施の形態によれば、タイマ１１を単一周期で使用しているため、上記第１の課題のような、周期時間の誤差が蓄積されるのを抑制することが可能となる。

また、プロセスの周期時間（起動周期時間）を基準周期Tの2ⁿ倍に制限することで、複数の周期を扱う場合でも周期時間の長さでプロセスの優先度を固定的に決定することができるため、周期毎のスケジューリングポリシや優先度の変更が必要なく、上記第２の課題のような、プロセススケジューラ処理が重くなって、CPU帯域を圧迫することを防止できる。

さらに、単に、帯域保証ライブラリ２１を追加するだけで、一般的なプロセススケジューラをそのまま使用することができるため、既存のOSのプロセススケジューラに手を加えることなく、簡単に、CPU使用時間を保証したシステムを実現することができる。

また、例えば、動画データを扱うソフトウェアを考えた場合、動画データはある一定時間内に、一定量のデータをハンドリングしなければスムーズな動画再生を望むことはできないが、第１の実施の形態によれば、CPUなどのリソース使用時間が保証されるので、確実に一定量のデータを処理して、スムーズな動画再生を行うことが可能となる。

ところで、CPU帯域保証型プロセスが複数存在するプロセススケジューリングシステムにおいては、何らかの原因で、あるCPU帯域保証型プロセスの実際のCPU使用時間が申告していたCPU使用時間を超過してしまうことも考えられる。そこで、次に、第２の実施の形態として、実際のCPU使用時間が申告していたCPU使用時間を超過した場合に、処理の投入を待っている他の帯域保証型プロセスの動作に影響を与えることなく、その超過した部分を動作させる方法について説明する。

図１２は、本発明を適用したプロセススケジューリングシステムの一実施の形態の他の構成を示すブロック図である。

なお、図１２では、図１と同様の箇所には、同一の符号が付してあり、処理が同じ部分に関しては、その説明は繰り返しになるので省略する。すなわち、図１２において、プロセススケジューリングシステム４１は、図１のプロセススケジューリングシステム１に対して、起動周期管理テーブル１３とプロセススケジューラ１５の代わりに、起動周期管理テーブル５１とプロセススケジューラ５２が設けられ、さらに、それらの起動周期管理テーブル５１とプロセススケジューラ５２との間に、実行時間監視部５３も設けられている。また、図中の点線で囲まれた部分を帯域保証ライブラリ６１と称して説明する。

また、図１２のプロセススケジューリングシステム４１は、図１のプロセススケジューリングシステム１と同様に、図示しないCPU（例えば後述する図３０のCPU３１１）やそのCPUにより実行されるOS、メモリ（例えば後述する図３０のRAM３１３）なども備えており、一般的なパーソナルコンピュータ（例えば後述する図３０のパーソナルコンピュータ）やワークステーションと同等な構成上に実装される。

起動周期管理テーブル５１は、図１３に示すように、図１の起動周期管理テーブル１３と比べて、格納している項目が増えている。

図１３は、起動周期管理テーブル５１の例を示す図である。

図１３の起動周期管理テーブル５１では、図１の起動周期管理テーブルに格納されるプロセスID、周期時間、CPU使用時間の項目の他に、実行時間、実行中フラグ、優先度フラグの項目も格納される。なお、図１３では、図３と同様の項目には、同様の名称が付してあり、その説明は繰り返しになるので省略する。

実行時間には、プロセスIDで特定されるユーザプロセス１４が実際に使用したCPU時間に関する情報が格納される。

実行中フラグには、該当するプロセスIDが「実行可能状態」あるいは「実行状態」の何れかの状態の場合には、1（真）であるフラグが格納され、それ以外の場合（例えば、「待ち状態」）には、0（偽）であるフラグが格納される。

優先度フラグには、該当するユーザプロセス１４の優先度が、SCHED_FIFOの場合には、1（真）であるフラグが格納され、SCHED_OTHERの場合には、0（偽）であるフラグが格納される。

図１３の例では、プロセスID 50に対して、周期時間100ms，CPU使用時間10ms，実行時間20ms，実行中フラグ1，優先度フラグ0が格納され、プロセスID 51に対して、周期時間200ms，CPU使用時間20ms，実行時間20ms，実行中フラグ0，優先度フラグ1が格納され、プロセスID 52に対して、周期時間400ms，CPU使用時間200ms，実行時間200ms，実行中フラグ0，優先度フラグ1が格納される。

すなわち、図１３の起動周期管理テーブル５１には、周期時間およびCPU使用時間の他に、実行時間、実行中フラグ、優先度フラグも格納されているので、これらのデータを参照することで、各プロセスの状態や優先度の有無などを確認することが可能となる。

図１２に戻り、プロセススケジューラ５２における、スケジューリング方針や優先度の考え方は、図１のプロセススケジューラ１５と同様であるが、プロセススケジューラ５２には、さらに、現在実行中のプロセスの動作時間を監視する機能が追加されている。

プロセス動作時間の監視は、プロセススケジューラ５２が有しているRUNキューの状態を確認することで測定できる。ここで、RUNキューとは、例えばLinux2.6のプロセススケジューラの一部であって、上述した、0から99までの静的優先度の数だけ用意されたキューである。「実行可能状態」となったプロセスは、該プロセスの静的優先度に対応したRUNキューに各種の情報と共に追加される。プロセススケジューラ５２は、優先度の高いRUNキューから順番に参照し、キューに追加された順にプロセスを、「実行可能状態」から「実行状態」に変化させる。現在のRUNキューが空になったら、次に優先度の高いRUNキューを参照し、同様の動作を繰り返す。

例えば、タイマ１１を使用することで、1ms毎にCPU割り込みを入れ、その時間にプロセススケジューラ５２が参照しているRUNキューの先頭を見ることで、現在実行中のプロセスIDが得られる。この方法を用いることで、1ms単位のプロセス使用時間が測定可能となる。

なお、RUNキューの概要は上述した通りであるが、その詳細については、例えば、「高橋浩和,小田逸郎,山幡為佐久著，「Linuxカーネル2.6解読室」，ソフトバンククリエイティブ，2006年11月21日発行，ISBN4-7973-3826-1」などのLinuxプロセススケジューラに関する専門書に詳しく記載されている。

また、第２の実施の形態では、タイマ割り込みを使用して、1ms精度のプロセス実行時間を取得する例について説明したが、カーネル時間タイマ（Tickタイマ）を任意好適な値に設定し、使用してもよい。さらに、プロセススケジューラ５２は、タイマ割り込み以外でも、例えば、I/Oアクセスなどを行った際に起動し、再スケジューリングを行い、そのタイミングでタイマをリードすることで、上述した、1ms精度よりも高い精度でのプロセス実行時間を測定できる。これらのプロセス実行時間取得は、システムが必要とする精度に合わせて任意好適な方法を選択すればよい。

実行時間監視部５３は、プロセスID毎に、そのプロセスIDに対応するユーザプロセス１４によって使用されたCPU時間を監視する。実行時間監視部５３は、監視の結果に応じて、そのユーザプロセス１４の優先度を変更させる。

ここで、図１４のフローチャートを参照して、図１２の実行時間監視部５３による、実行時間監視処理について説明する。

ステップＳ７１において、実行時間監視部５３は、プロセススケジューラ５２から通知される実行時間通知、すなわち、第２の実施の形態では、例えば1ms間隔で現在CPUを使用しているプロセスIDが通知されてくるので、それを受信する。

ステップＳ７２において、実行時間監視部５３は、通知されたプロセスIDのプロセス実行時間を計算する。実行時間監視部５３は、通知されたプロセスIDを基に、図１３の起動周期管理テーブル５１に格納されている、実行時間の項目に、そのプロセス実行時間を追加する。なお、通知されたプロセスIDが、図１３の起動周期管理テーブルに格納されていない場合には、ステップＳ７２の処理は実行しなくてよい。

ステップＳ７３において、実行時間監視部５３は、該プロセスIDのCPU使用時間（プロセス実行時に申告したCPU使用時間（申告時間））と、実際のCPU使用時間（実行時間）とを比較し、実行時間が申告時間を超えるか否かを判定する。

ステップＳ７３において、実行時間が申告時間を超えると判定された場合、ステップＳ７４において、実行時間監視部５３は、該プロセスIDの静的優先度を0、すなわち、SCHED_OTHERに落とす。この優先度の変更については、例えば、上述した、sched_setscheduler関数を使用すればよい。なお、変更する優先度は、第２の実施の形態では、静的優先度0としたが、他のCPU帯域保証が必要なプロセスの静的優先度よりも低い優先度であれば、その設定は任意好適に選択可能である。

そして、静的優先度を下げた後、ステップＳ７５において、実行時間監視部５３は、図１３の起動周期管理テーブル５１に対して、該プロセスIDの優先度フラグを0（偽）に更新するように依頼する。これにより、図１３の起動周期管理テーブル５１では、対象となるプロセスIDの優先度フラグが0に変更され、実行時間監視処理は終了する。

一方、ステップＳ７３において、実行時間が申告時間以下であると判定された場合、ステップＳ７４をスキップして、処理は、ステップＳ７５に進む。ステップＳ７５において、実行時間監視部５３は、静的優先度を変更せずに、起動周期管理テーブル５１を更新し、実行時間監視処理は終了する。

次に、図１５のフローチャートを参照して、実行時間監視部５３によって、静的優先度が下げられたプロセスIDに対応する、図１２のユーザプロセス１４による周期内処理について説明する。

ステップＳ９１乃至ステップＳ９５において、図８のステップＳ３１乃至ステップＳ３５における場合と同様に、ユーザプロセス１４によって、帯域保証ライブラリ６１から通知されるプロセス実行イベントに従って、周期内処理が行われる。

ステップＳ９６において、ユーザプロセス１４は、帯域保証ライブラリ６１の周期完了通知関数を呼び出して、その帯域保証ライブラリ６１（起動指示部１６）に周期完了を通知する（周期完了通知）。

ここで、周期完了通知関数とは、ユーザプロセス１４における1周期分の処理が完了したことを起動指示部１６に通知し、通知を受けた起動指示部１６に起動周期管理テーブル５１に格納された実行中フラグを変更させるための関数である。従って、起動指示部１６は、この通知を受けると、図１３の起動周期管理テーブル５１に対して、実行中フラグを1（真）から0（偽）に更新するよう依頼する。これにより、図１３の起動周期管理テーブル５１では、対象となるプロセスIDの実行中フラグが1（真）から0（偽）に変更される。

ステップＳ９７およびステップＳ９８において、図８のステップＳ３６およびステップＳ３７における場合と同様に、ユーザプロセス１４によって、周期内処理が終了すると、帯域保証ライブラリ６１に帯域の開放が依頼され、周期内処理は終了する。

ところで、第１の実施の形態における図１のユーザプロセス１４と、第２の実施の形態における図１２のユーザプロセス１４とは、起動指示部１６からのプロセス実行イベントが通知されると、「待ち状態」から「実行可能状態」に遷移し、プロセススケジューラ１５（プロセススケジューラ５２）による然るべき処理により、「実行可能状態」から「実行状態」に遷移して起動する点で、その動作は一致している。このように、ユーザプロセス１４の状態遷移については、その大まかな処理の流れは、第１の実施の形態と第２の実施の形態とでは同様であるが、第２の実施の形態では、起動指示部１６により生成されるプロセス実行イベントの通知の仕方が第１の実施の形態とは異なっている。つまり、第１の実施の形態で説明した、図９のステップＳ５９の処理の内容が異なる。

そこで、次に、図１６のフローチャートを参照して、図１２の起動指示部１６による、イベント通知処理について説明する。

なお、図１２の起動指示部１６は、図１の起動指示部１６と同様に、図９の起動指示処理を実行するが、図９のステップＳ５９の処理の代わりに、図１６のフローチャートの処理を実行する。

ステップＳ１１１において、起動指示部１６は、図１３の起動周期管理テーブル５１に格納された実行中フラグを参照することで、プロセス実行イベントを通知するプロセスIDに対応するユーザプロセス１４の状態が実行状態であるか否かを判定する。

ステップＳ１１１において、実行中フラグが1（真）であって、ユーザプロセス１４の状態が実行状態であると判定された場合、プロセス実行イベントを通知する必要がないので、ステップＳ１１２乃至ステップＳ１１５の処理をスキップし、イベント通知処理は終了する。

一方、ステップＳ１１１において、実行中フラグが0であって、ユーザプロセス１４の状態が実行状態でないと判定された場合、ステップＳ１１２において、起動指示部１６は、
図１３の起動周期管理テーブル５１を参照して、プロセス実行イベントを通知するプロセスIDに対応するユーザプロセス１４の優先度が0（偽）であるか否かを判定する。

ステップＳ１１２において、ユーザプロセス１４の優先度が1（真）であると判定された場合、ユーザプロセス１４が優先度の設定通りに動作しているので、ステップＳ１１３の処理をスキップし、処理はステップＳ１１４に進む。

一方、ステップＳ１１２において、ユーザプロセス１４の優先度が0（偽）であると判定された場合、上述したように、実行時間監視部５３によって、優先度が下げられているので、ステップＳ１１３において、起動指示部１６は、第１の実施の形態で説明した方法と同様に、周期時間に対して固定で割り当てられている静的優先度を該プロセスIDに設定し、さらに、優先度フラグを1（真）に変更する。

なお、この優先度を変更する処理は、図１６のフローチャートの処理が、図９のステップＳ５９の処理のタイミングで実行されるので、例えば、優先度が下げられたプロセスの1周期分の処理が完了したとき、または優先度が下げられたプロセスの起動周期時間が経過したときに実行される。

ステップＳ１１４において、起動指示部１６は、変更された優先度フラグ（優先度フラグ1）を上書きすることで、起動周期管理テーブル５１を更新する。なお、ここで、起動周期管理テーブル５１の更新する内容であるが、起動指示部１６は、優先度フラグの他に、該プロセスIDの実行時間も0msに更新する。これにより、起動周期のタイミング毎に、ユーザプロセス１４が使用したCPU使用時間をクリアすることができる。

ステップＳ１１５において、起動指示部１６は、該プロセスIDのユーザプロセス１４に対して、プロセス実行イベントを通知して、イベント通知処理は終了する。

なお、図１６のイベント通知処理は、上述したように、その全ての処理を、起動指示部１６が実行してもよいが、その一部の処理を、帯域保証ライブラリ６１内の帯域管理部１２などの他のブロックが行ってもよい。

図１７は、第２の実施の形態における、プロセスID 50，51，52のスケジューリング結果の例を示すタイミングチャートである。

図１７のタイミングチャートは、図１１のタイミングチャートと比べて、時刻600ms乃至時刻700msの区間におけるプロセスID 50の動作が異なっている。すなわち、図１７は、プロセスID 50において、時刻600msに動作を開始したが、何らかの影響により、CPU使用時間10msで申告していた時間が、実行時間20msまで長引いてしまった場合の例を示すタイミングチャートである。

図１７においては、プロセスID 50が申告しているCPU使用時間は10msであるため、時刻610msの時点で、プロセスID 50の優先度は0、すなわち、SCHED_OTHERに変更される。従って、より優先度の高い、プロセスID 51，52が先に動作し、それらのプロセスの動作が終了してから、プロセスID 50の残りの10msが再開される。これにより、処理が長引いた場合でも、確実に処理を実行することが可能となる。

その後、時刻700msで、再度、プロセスID 50が起動される場合には、本来の静的優先度に戻されるため、時刻700ms以降は、時刻600ms以前と同様のスケジューリングが適用される。なお、図１７の時刻t1付近おける起動周期管理テーブル５１には、図１３に示すように、プロセスID 50に対して、周期時間100ms，CPU使用時間10ms，実行時間20ms，実行中フラグ1，優先度フラグ0が格納される。

以上のように、第２の実施の形態によれば、CPU帯域保証型プロセスが複数存在するプロセススケジューリングシステム４１において、あるプロセスが何らかの原因で申告しているCPU使用時間を超過してしまっても、超過した部分に関しては優先度が低く実行されるため、その後、処理の投入を待っている他の帯域保証型プロセスの動作に影響を与えることなく、その超過した部分を動作させることが可能となる。

また、優先度が下げられた帯域保証型プロセスにおいても、一連の処理を終え、次の起動周期タイミングに達した段階で、落とされた優先度が本来の優先度に戻されるので、システム全体のダメージを軽減することができる。

ところで、CPU帯域保証型プロセスが複数存在するプロセススケジューリングシステムにおいては、時間帯によっては、CPU帯域保証型プロセスに割り当てられるCPU帯域に余裕がある場合も考えられる。そこで、次に、第３の実施の形態として、CPU帯域に余裕がある場合に、必要に応じてその帯域を、再度CPU帯域保証型プロセスに割り当てる方法について説明する。

図１８は、本発明を適用したプロセススケジューリングシステムの一実施の形態の他の構成を示すブロック図である。

なお、図１８では、図１と図１２と同様の箇所には、同一の符号が付してあり、処理が同じ部分に関しては、その説明は繰り返しになるので省略する。すなわち、図１８において、プロセススケジューリングシステム１０１は、図１２のプロセススケジューリングシステム４１に対して、起動周期管理テーブル５１と起動指示部１６の代わりに、起動周期管理テーブル１１１と起動指示部１１２が設けられている。また、図中の点線で囲まれた部分を帯域保証ライブラリ１２１と称して説明する。

また、図１８のプロセススケジューリングシステム１０１は、図１２のプロセススケジューリングシステム４１と同様に、図示しないCPU（例えば後述する図３０のCPU３１１）やOS、メモリ（例えば後述する図３０のRAM３１３）なども備えており、一般的なパーソナルコンピュータ（例えば後述する図３０のパーソナルコンピュータ）やワークステーションと同等な構成上に実装される。

起動周期管理テーブル１１１は、図１９に示すように、図１３の起動周期管理テーブル５１と比べて、格納している項目が増えている。

図１９は、起動周期管理テーブル１１１の例を示す図である。

図１９の起動周期管理テーブル１１１では、図１３の起動周期管理テーブルに格納されるプロセスID、周期時間、CPU使用時間、実行時間、実行中フラグ、優先度フラグの項目の他に、再投入優先度、再投入回数の項目も格納される。なお、図１９では、図３と図１３と同様の項目には、同様の名称が付してあり、その説明は繰り返しになるので省略する。

再投入優先度には、後述する再投入処理を行う際の優先度が格納される。例えば、再投入優先度には、優先度の最も低い0から優先度の最も高い99までの値が格納される。また、再投入回数についても後述するが、再投入回数には、決められた周期内に、何回余分にプロセスを実行するかを表わす情報が格納される。

図１９の例では、プロセスID 50に対して、周期時間100ms，CPU使用時間10ms，実行時間10ms，実行中フラグ0，優先度フラグ1，再投入優先度2，再投入回数1が格納され、プロセスID 51に対して、周期時間200ms，CPU使用時間20ms，実行時間20ms，実行中フラグ0，優先度フラグ1，再投入優先度1，再投入回数0が格納され、プロセスID 52に対して、周期時間400ms，CPU使用時間200ms，実行時間200ms，実行中フラグ0，優先度フラグ1，再投入優先度0，再投入回数0が格納される。

すなわち、図１９の起動周期管理テーブル１１１には、周期時間などの他に、再投入優先度、再投入回数も格納されているので、これらのデータを参照することで、各プロセスの再投入時の優先度や投入回数を確認することが可能となる。

図１８に戻り、起動指示部１１２は、その基本的な動作は図１および図１２の起動指示部１６と同様であるが、さらに、CPUの空き帯域を見つけ、必要に応じて周期内にプロセスを再投入する機能が追加されている。

次に、図２０のフローチャートを参照して、図１８の起動指示部１１２による、起動指示処理について説明する。

ステップＳ１３１乃至ステップＳ１３４において、図９のステップＳ５１乃至ステップＳ５４と同様に、起動指示部１１２によって、カウンタNの値が2ⁿ未満であるか否かが判定され、Nが2ⁿ以上であると判定された場合、プロセススケジューリングシステム１０１上のCPU帯域保証型プロセスの最大起動周期に到達したので、ステップＳ１３４において、N=1とされる。

その後、ステップＳ１３５において、起動指示部１１２は、図示しないメモリあるいはレジスタ上にある、再投入データ更新フラグを1（真）に更新（セット）する。

ステップＳ１３６乃至ステップＳ１４１において、図９のステップＳ５５乃至ステップＳ６０と同様に、起動指示部１１２によって、起動すべきプロセスに対して、プロセス実行イベントが通知される。その後、処理はステップＳ１３２に戻り、上述した処理が繰り返される。

ところで、図２０のステップＳ１４０の処理による、プロセス実行イベントの通知を受け取ったユーザプロセス１４は、周期内処理を実行する。この周期内処理は、上述した、図１５のフローチャートの処理と同様であるので、その処理の詳細な説明は省略するが、ユーザプロセス１４によって、周期内処理が行われた後、帯域保証ライブラリ１２１に周期完了が通知される（図１５のステップＳ９６の処理）。

そこで、次に、図２１のフローチャートを参照して、図１８の起動指示部１１２による、ユーザプロセス１４からの周期完了通知（図１５のステップＳ９６の処理）を受け取った際に実行される、周期完了通知処理について説明する。

すなわち、起動指示部１１２は、ユーザプロセス１４が1周期分の然るべき処理の完了後に通知してくる周期完了通知を受け取ったとき、図２１のフローチャートの処理を実行する。

ステップＳ１５１において、起動指示部１１２は、起動周期管理テーブル１１１に対し、通知を受けた該ユーザプロセス１４に該当するプロセスIDの実行中フラグを、1（真）から0（偽）に変更を依頼して、起動周期管理テーブル１１１を更新する。

ステップＳ１５２において、起動指示部１１２は、起動周期管理テーブル１１１を参照して、再投入データ更新フラグが1（真）であるか否かを判定する。ステップＳ１５２において、再投入データ更新フラグが真であると判定された場合、ステップＳ１５３において、起動指示部１１２は、起動周期管理テーブル１１１に対し、再投入回数の変更を依頼して、起動周期管理テーブル１１１を更新する。

ここで、再投入回数の決定方法について説明する。まず、起動指示部１１２は、プロセススケジューリングシステム１０１上のCPU帯域保証型プロセスのCPU使用率の合計を計算する。このCPU帯域保証型プロセスのCPU使用率は、起動周期管理テーブル１１１に問い合せることで、取得することが可能である。具体的には、第１の実施の形態で説明したように、起動指示部１１２によって、式（１）を用いて、個々のプロセスのCPU使用率が求められるので、そのCPU使用率の合計値を、システム全体のCPU帯域保証型プロセスが使用しているCPU使用率とする。

また、第１の実施の形態の式（２）で説明した通り、プロセススケジューリングシステム１０１では、例えばCPU帯域保証プロセス用に80％の帯域が確保されている。例えば、図１９の起動周期管理テーブル１１１に格納されているプロセスID毎のCPU使用率は、プロセスID 50が10％、プロセスID 51が10％、プロセスID 52が50％となる。従って、プロセススケジューリングシステム１０１でCPU帯域保証型プロセスが使用するCPU帯域は、その合計値である70％となる。従って、残り10％分に収まるCPU帯域保証型プロセスであれば、追加可能となる。

例えば、図１９において、プロセスID 50とプロセスID 51は、申告しているCPU使用率が夫々10％であるので、このどちらか一方は、再投入可能であることがわかる。以下、このように、プロセスが申告している周期とは関係なく、CPU帯域の余りを見つけて実行する動作を、再投入動作と称する。

また、図１９では、プロセスID 50またはプロセスID 51が同時に再投入動作可能となるが、そのどちらかを選択するかは、起動周期管理テーブル１１１に格納された再投入優先度の値に応じて決定される。第３の実施の形態では、例えば、再投入優先度を0から99までの値とし、0は再投入なしで、99が最も優先度が高く、また再投入優先度の値が再投入する回数を意味する。

図１９の起動周期管理テーブル１１１では、プロセスID 50の再投入優先度は2、プロセスID 51の再投入優先度は1が申告されている。これは、プロセスID 50は最大2回、再投入動作させることを希望し、プロセスID 51は最大1回、再投入動作させることを希望している。しかしながら、図１９の例では、CPU帯域保証型プロセスとして利用可能な帯域は10％しか残っていないため、より優先度の高い、プロセスID 50の再投入動作を1回とし、図１９の起動周期管理テーブル１１１に格納された再投入回数の値を更新する。

例えば、プロセススケジューリングシステム１０１で動作しているCPU帯域保証型プロセスが、図２２の起動周期管理テーブル１１１に示すような状態であった場合、それらのCPU帯域保証型プロセスが使用しているCPU使用率の合計は45％（10％+10％+25％）となり、まだ使用可能な余りのCPU使用率は35％となる。従って、図２２の起動周期管理テーブル１１１における、プロセスID 150とプロセスID 151が夫々要求している再投入回数に応じた再投入動作回数は、全て満たすことが可能となり、その結果、プロセスID 150とプロセスID 151における再投入回数は、夫々、2回、1回となる（CPU使用率の合計は30％）。

なお、上述した通り、再投入データ更新フラグは、プロセススケジューリングシステム１０１上のCPU帯域保証型プロセスの最大起動周期に達したときに、1（真）に設定されるため、再投入動作回数は、プロセススケジューリングシステム１０１上のCPU帯域保証型プロセスの最大起動周期時間毎に再計算される。

図２１のフローチャートに戻り、ステップＳ１５４において、起動指示部１１２は、周期完了通知を発行したユーザプロセス１４に該当するプロセスIDを再投入動作するか否かを判定する。

具体的には、起動指示部１１２は、図１９の起動周期管理テーブル１１１に格納された再投入回数の値を参照し、該プロセスIDに対応する再投入回数が1以上であれば、1（真）であると判定し、ステップＳ１５５において、プロセス実行イベントを通知する。このプロセス実行イベントを通知する処理については、図９のステップＳ５９の処理と同様であるので、その説明は省略する。

そして、ステップＳ１５６において、起動指示部１１２は、起動周期管理テーブル１１１に対し、再投入動作された該プロセスIDの再投入回数から1減算（デクリメント）を依頼して、起動周期管理テーブル１１１を更新し、周期完了通知処理は終了する。

一方、ステップＳ１５４において、再投入動作をしないと判定された場合、ステップＳ１５５およびステップＳ１５６をスキップし、周期完了通知処理は終了する。

図２３は、第３の実施の形態における、再投入動作によるプロセスID 50，51，52のスケジューリング結果の例を示すタイミングチャートである。

図２３のタイミングチャートは、図１１のタイミングチャートと比べて、時刻0ms乃至時刻100ms、時刻400ms乃至時刻500ms、時刻800ms乃至時刻900msの区間におけるプロセスID 50の動作が異なっている。

図２３において、プロセスID 50は、例えば、図１９の起動周期管理テーブル１１１に示すように、再投入優先度2、再投入回数1であるので、他のプロセスIDよりも、再投入優先度が高く、所定の周期（400ms周期）内に1回余分に実行される。これにより、図２３に示すように、プロセスID 50は、400ms周期毎に1回余分に実行される。

具体的には、時刻0ms乃至時刻100msの区間において、プロセスID 50は、時刻0msで、通常の周期内処理を実行した後、時刻t1で、自分が申告している周期とは関係なく、CPU帯域の余りを見つけて実行する再投入動作を開始する。つまり、プロセスID 50は、1回分余計に実行されたことになる。同様にまた、時刻400ms乃至時刻500msと時刻800ms乃至時刻900msの区間においても、通常の周期内処理を実行した後、時刻t2または時刻t3で、再投入動作が開始され、プロセスID 50が1回分余計に実行される。

以上のように、第３の実施の形態によれば、上記第４の課題のように、周期時間内に決められたCPU使用時間以上を使用することができないことを防止し、さらに、CPU帯域に余裕がある場合には、必要に応じてその帯域を、再度CPU帯域保証型プロセスに割り当てることが可能となる。また、優先度を指定することができるので、処理の重要度に応じて任意好適な再投入動作を実行させることが可能となる。

ところで、第３の実施の形態では、予め、各ユーザプロセス１４が申告した周期時間とCPU使用時間を基に、CPU帯域保証型プロセスの合計のCPU使用時間を求め、空き帯域に収まるCPU帯域保証型プロセスの再投入動作を行っているが、次に、第４の実施の形態として、第３の実施の形態で説明した方法に加えて、ユーザプロセス１４が一連の周期動作を終えたときの実CPU使用時間を基に、CPU空き時間を計算し、空き時間が発生した場合にも再投入動作を行う方法について説明する。

なお、第４の実施の形態は、上述した第３の実施の形態の変形例である。従って、第４の実施の形態では、第３の実施の形態と異なる点についてのみ説明する。

第４の実施の形態では、第３の実施の形態で説明した、図１９と図２２の起動周期管理テーブル１１１の代わりに、図２４の起動周期管理テーブル１１１が用いられる。

図２４は、起動周期管理テーブル１１１の例を示す図である。

図２４の起動周期管理テーブル１１１では、図１９の起動周期管理テーブル１１１に格納される、プロセスID、周期時間、CPU使用時間、実行時間、実行中フラグ、優先度フラグ、再投入優先度、再投入回数の項目の他に、実行時間と実行中フラグの間に、余り時間の項目も格納される。なお、図２４では、図１９と同様の項目には、同様の名称が付してあり、その説明は繰り返しになるので省略する。

余り時間には、プロセスIDで特定されるユーザプロセス１４が申告しているCPU使用時間と、そのユーザプロセス１４が実際に使用したCPU時間との差分の時間が格納される。すなわち、該ユーザプロセス１４が周期完了通知を発行した直後における、図２４のCPU使用時間と実行時間との差分の時間が、余り時間となる。

図２４の例では、プロセスID 50に対して、周期時間100ms，CPU使用時間10ms，実行時間10ms，余り時間0ms，実行中フラグ1，優先度フラグ1，再投入優先度2，再投入回数1が格納され、プロセスID 51に対して、周期時間200ms，CPU使用時間20ms，実行時間10ms，余り時間10ms，実行中フラグ0，優先度フラグ1，再投入優先度1，再投入回数1が格納され、プロセスID 52に対して、周期時間400ms，CPU使用時間200ms，実行時間200ms，余り時間0ms，実行中フラグ0，優先度フラグ1，再投入優先度0，再投入回数0が格納される。

すなわち、図２４の起動周期管理テーブル１１１には、周期時間などの他に、余り時間も格納されているので、そのデータを参照することで、再投入動作の有無などを確認することが可能となる。従って、図２４の起動周期管理テーブル１１１から、周期完了通知を発行しているプロセスIDに対応する実行時間を取得し、その実行時間と、該プロセスIDで特定されるユーザプロセス１４が申請しているCPU使用時間との差がある場合には、その差分に収まるプロセスについて再投入動作できる。

ところで、上述したように、あるユーザプロセス１４（例えばプロセスID 50）による一連の周期内処理が終了すると、次に優先度の高いユーザプロセス１４（例えばプロセスID 51）が「実行可能状態」から「実行状態」に遷移する。そして、そのユーザプロセス１４は、周期内処理を行った後、「実行状態」から「待ち状態」に遷移する直前で、帯域保証ライブラリ１２１に周期完了を通知する（図１５のステップＳ９６の処理）。

そこで、次に、図２５のフローチャートを参照して、図１８の起動指示部１１２による、ユーザプロセス１４から周期完了通知（図１５のステップＳ９６の処理）を受け取った際に実行される、再投入確認処理について説明する。

すなわち、起動指示部１１２は、ユーザプロセス１４が1周期分の然るべき処理の完了後に通知してくる周期完了通知を受け取ったとき、図２５のフローチャートの処理を実行する。

ステップＳ１７１において、起動指示部１１２は、図２４の起動周期管理テーブル１１１を参照して、余り時間を計算し、余り時間があるか否かを判定する。

具体的には、起動指示部１１２は、ユーザプロセス１４（例えばプロセスID 51）が周期完了通知を発行した直後における、図２４の起動周期管理テーブル１１１に格納された、例えばCPU使用時間20msと実行時間20msとの差分が余り時間となる。

ステップＳ１７１において、余り時間がないと判定された場合、再投入動作を実行しないので、ステップＳ１７２乃至ステップＳ１７６をスキップし、再投入確認処理は終了する。

一方、ステップＳ１７１において、余り時間があると判定された場合、ステップＳ１７２において、起動指示部１１２は、図２４の起動周期管理テーブル１１１に対し、通知を受けた該ユーザプロセス１４に該当するプロセスIDの余り時間の項目に、計算した余り時間の加算を依頼して、図２４の起動周期管理テーブル１１１を更新する。

ここで、余り時間の計算結果を加算する理由は、例えば、第３の実施の形態で説明したように、周期内に複数の再投入動作が行われた場合、それら全てについての余り時間を積算するためである。なお、余り時間の項目を初期化（0に初期化）するタイミングは、該ユーザプロセス１４の周期の先頭となる。従って、例えば、起動指示部１１２は、図２０のステップＳ１４０の処理を実行するタイミングで、余り時間の項目を0クリアする。

ステップＳ１７３において、起動指示部１１２は、該ユーザプロセス１４の再投入動作が必要であるか否かを判定する。これは、第３の実施の形態と同様に、起動指示部１１２によって、図２４の起動周期管理テーブル１１１に格納された再投入回数が参照され、1以上のプロセスIDであるか否かが判定されることで、確認可能となることを意味する。

ステップＳ１７３において、再投入動作が必要ないと判定された場合、再投入動作を実行しないので、ステップＳ１７４乃至ステップＳ１７６をスキップし、再投入確認処理は終了する。

一方、ステップＳ１７３において、再投入動作が必要であると判定された場合、ステップＳ１７４において、起動指示部１１２は、該ユーザプロセス１４が申告したCPU使用時間と、該ユーザプロセス１４の起動周期内における余り時間とを比較し、申告時間が余り時間内に収まるか否かを判定する。

ここで、起動周期内の余り時間の計算方法であるが、例えば、図２４の起動周期管理テーブル１１１に格納された、該ユーザプロセス１４に該当するプロセスIDの周期時間以上となるように全プロセスIDの余り時間の和を計算する。この場合、例えば、該プロセスIDの周期時間以下となるプロセスのうち、図２４の起動周期管理テーブル１１１に格納された実行中フラグが0となるプロセスIDの余り時間の合計値が、再投入すべきプロセスIDが使用可能となるCPU使用時間となる。

ステップＳ１７４において、申告時間が余り時間以内に収まらないと判定された場合、CPU使用時間が足りないために再投入動作を実行できないので、ステップＳ１７５およびステップＳ１７６をスキップし、再投入確認処理は終了する。

一方、ステップＳ１７４において、申告時間が余り時間以内に収まる（申告しているCPU使用時間≦余り時間）と判定された場合、ステップＳ１７５において、起動指示部１１２は、プロセス実行イベントを通知する。このプロセス実行イベントを通知する処理については、図２１のステップＳ１５５の処理と同様であるので、その説明は省略する。

ステップＳ１７６において、起動指示部１１２は、図２４の起動周期管理テーブル１１１に対し、該プロセスIDの再投入回数と、対象の余り時間の変更を依頼して、図２４の起動周期管理テーブル１１１を更新し、再投入確認処理は終了する。

ここで、図２４の起動周期管理テーブル１１１の更新方法であるが、例えば、再投入動作したプロセスIDの再投入回数を1減算（デクリメント）すると共に、上述した、余り時間の和を計算する際に使用した各プロセスID毎の余り時間のうち、周期時間の短いものから順に、再投入したプロセスIDのCPU使用時間分となるまで減算する。例えば、図２４に示すように、プロセスID 51のCPU使用時間は20msと申告されているが、プロセスID 51の余り時間が5ms、プロセスID 52の余り時間が20msであったと仮定すると、上記更新方法を適用して、プロセスID 51の余り時間は0msとなり、プロセスID 52の余り時間は5msとなる。

図２６は、第４の実施の形態における、再投入動作によるプロセスID 50，51，52のスケジューリング結果の例を示すタイミングチャートである。

図２６では、時刻t1の時点で、プロセスID 50は、通常の周期内処理と、第３の実施の形態で説明した処理によって、処理Ａが再投入動作されている。そのため、図２４に示すように、再投入回数が1に減算されている。また、プロセスID 51は、CPU使用時間として20msを申告しているが、実際には10msで周期内処理が終了しているため、図２４に示すように、余り時間は10msとなり、実行中フラグは0となっている。

この時点で、上述した方法で再投入処理を実行すると、図２４に示すように、プロセスID 50のCPU使用時間10msが余り時間と等しく、かつ、再投入優先度が最も高く、かつ、再投入回数が1となっているので、プロセスID 50を再投入することになる。図２６に示すように、プロセスID 50を再投入した結果、時刻t1で、処理Ｂが実行される。この段階で、プロセスID 50の再投入回数は0となる。これは第３の実施の形態で説明した通り、プロセススケジューリングシステム１０１の最大周期（プロセスID 52の周期）400msに達するまで再投入が行われないことを意味する。

同様に、時刻t2では、プロセスID 51によって実行される処理Ｅが10msで完了し（すなわち、10msの余り時間が発生）、時刻t3では、プロセスID 52によって実行される処理Ｇのように、合計190ms（60ms+90ms+40ms）で処理が完了し（すなわち、10msの余り時間が発生）、これらの余り時間の合計は、20msとなる。これにより、図２６に示すように、プロセスID 51が再投入され、処理Ｆが実行される。

なお、第３の実施の形態および第４の実施の形態では、再投入回数が全て0となった場合、次の再投入のタイミング（図２０のステップＳ１３５の処理）まで再投入されないが、それに限らず、例えば、再投入回数が0になったとき、図２１のステップＳ１５３の処理のように、再度、再投入回数を計算してもよい。

以上のように、第４の実施の形態によれば、申告されたCPU使用時間を基に、再投入動作を行うと共に、各プロセスが実際に消費したCPU使用時間を監視し、実際に消費されたCPU使用時間が申告されたCPU使用時間よりもはやく終了した際の余りの帯域を、再投入動作に使用可能であるため、上記第４の課題の周期時間内に決められたCPU使用時間以上を使用することができないことを防止し、空き帯域を有効に使用することが可能となる。

ところで、上述したように、第１の実施の形態乃至第４の実施の形態においては、CPU使用時間を管理する例について説明したが、帯域保証ライブラリは、CPU使用時間だけでなく、いわゆるブロッキングI/O（Input/Output）の使用時間についても管理するようにしてもよい。そこで、以下、第５の実施の形態として、CPU使用時間だけでなく、ブロッキングI/Oの使用時間も管理するタスク管理方法の例について説明する。

ここで、ブロッキングI/Oとは、I/Oアクセスを行う際に、CPUがI/Oアクセス命令を発行した後、I/Oアクセスが完了するまで、該I/Oアクセス命令が戻ってこないI/O処理を意味する。例えば、ネットワーク転送手段として広く用いられている、ソケット（socket）通信では、然るべき処理で、相手とネットワーク接続した後、例えば、データを送信する際に、send関数が使用される。send関数には、転送データサイズなどのパラメータがあり、このsend関数は、一度コールされると、全ての転送データ処理が終了するまでリターンしない。つまり、send関数のような振る舞いをするI/OがブロッキングI/Oである。

従って、ブロッキングI/Oの動作中、該I/OにアクセスしているプロセスはCPUを占有していることになる。つまり、何らかの方法で、CPU処理時間を制限することで、ブロッキングI/Oのアクセス時間を制限することが可能となる。このCPU処理時間は、上記第１の実施の形態乃至第４の実施の形態で説明した方法により制限（制御）することが可能である。

例えば、ネットワーク通信では、上述した、send関数が転送データ処理に要する時間（ネットワーク送信に必要なCPU使用時間）は、転送サイズに比例する。すなわち、第１の実施の形態乃至第４の実施の形態で説明した、ユーザプロセス１４が申告するパラメータとして、CPU使用時間などの他に、例えば、ネットワーク送信サイズといったパラメータも申告することで、CPU使用時間の他に、周期内に送信可能なネットワーク転送サイズも保証可能となる。

このネットワーク送信サイズとCPU使用関数との関係は、式（５）のようになる。

CPU_NET ＝ SENDSIZE_NET × SENDBPS_NET ・・・（５）

なお、式（５）においては、SENDSIZE_NETは、送信データサイズ（バイト）であり、SENDBPS_NETは、1バイト当たりに使用するCPU使用時間である。このSENDBPS_NETは、予め、使用環境に合わせて予備実験を行い、その関係を統計的に求めた値となる。これらのSENDSIZE_NETとSENDBPS_NETとを乗算することで、CPU_NET（CPU使用時間）が求められる。

このようにして、ネットワーク送信に必要なCPU使用時間（CPU_NET）を求め、ユーザプロセス１４が使用する（第１の実施の形態のCPU_PROC）に加算し、その値を新たなCPU_PROCとして第１の実施の形態乃至第４の実施の形態で説明したように処理を行うことで、CPU帯域の保証に加えて、ネットワークリソースの帯域の保証も可能となる。

なお、第５の実施の形態では、例えば、ネットワークトラフィックや切断などの異常事態などの外部的な要因については考慮しない。これらの要因については、従来からのQoS（Quality Of Service）技術を使用することで解決可能である。また、第５の実施の形態では、ブロッキングI/Oの一例として、ネットワーク送信について説明したが、それに限らず、ブロッキングI/Oであれば、如何なるものでも適用可能である。さらにまた、転送サイズと1バイト当たりに使用するCPU使用時間との関係が、単純な比例関係とはならない場合には、例えば、その関係を所定のテーブルに格納し、そのテーブルを参照することで、CPU使用時間を計算すればよい。

以上のように、第５の実施の形態によれば、CPU使用時間を制御することで、ブロッキングI/Oの使用時間を制御可能となる。その結果、ブロッキングI/Oの帯域を保証することが可能となる。

ところで、第１の実施の形態乃至第５の実施の形態においては、CPU使用時間とブロッキングI/Oを管理する例について説明したが、帯域保証ライブラリは、いわゆる非ブロッキングI/O（Input/Output）についても管理するようにしてもよい。そこで、以下、第６の実施の形態として、非ブロッキングI/Oの使用時間を管理するタスク管理方法の例について説明する。

ここで、非ブロッキングI/Oとは、ユーザプロセス１４がI/Oアクセスを発行すると、そのプロセスは、「実行状態」から「待ち状態」に遷移し、I/Oアクセスが完了すると、割り込み処理により、該プロセスが「待ち状態」から「実行状態」に再び遷移するようなI/Oアクセスである。非ブロッキングI/Oの代表的なものとしては、例えば、ハードディスク（HDD（Hard Disk Drive））のリード/ライト（read/write）処理などがある。

ユーザプロセス１４がread関数をコールすると、その関数内部でselectが実行され、該プロセスは、「実行状態」から「待ち状態」に遷移する。その後、デバイスドライバ内部でread関数に対応したファイルリード処理が完了したら、上述した、selectに戻り、該プロセスは「待ち状態」から、「実行状態」あるいは「実行可能状態」に遷移する。

このように、非ブロッキングI/Oでは、I/Oを利用しているプロセスは「待ち状態」となるため、その間、他のプロセスがCPUを使用することが可能となる。従って、第６の実施の形態では、第５の実施の形態のように、I/Oアクセス時間を、CPU使用時間に換算する必要はないが、別途、非ブロッキングI/O毎に使用率を管理する必要がある。

図２７は、Linux2.6におけるI/Oスケジューラ（I/Oアクセス順を決定する機構）の概念図である。

I/Oアクセスは一般的にはプロセスが持つ優先度に関係なく、I/Oデバイス２０４と接続されるリクエストキュー２０３のような、１つのFIFOバッファにより処理される。すなわち、どんなに優先度が高いプロセスであっても、既に優先度が低いプロセスがI/Oアクセスしていたら（リクエストキュー２０３にキューイングされていたら）、そのアクセスが完了するまで間、次のI/Oアクセスは待たされる。

例えば、図２７において、帯域保証プロセス２０１のI/Oアクセスを保証するためには、帯域保証プロセス２０１は、非帯域保証プロセス２０２よりも先に、I/Oデバイスに対しアクセスする必要がある。ところが、従来のLinux2.6のI/Oスケジューラでは、基本的にFIFO処理が行われるため、例えば、非帯域保証プロセス２０２が先にI/Oアクセスを発行していると、帯域保証プロセス２０１のI/Oアクセスは、先の非帯域保証プロセス２０２のI/Oアクセスが終了するまで実行されないこととなる。

図２８は、第６の実施の形態における、I/Oスケジューラの概念図である。

図２８において、帯域保証プロセス２１１は、非帯域保証プロセス２１２よりも高い優先度で動作している。このプロセスの動作については、第１の実施の形態乃至第５の実施の形態と同様である。

アクセスサイズ分割部２１３は、帯域保証プロセス２１１のI/Oアクセスを複数に分割する。同様にまた、アクセスサイズ分割部２１４は、非帯域保証プロセス２１２のI/Oアクセスを複数に分割する。この分割のサイズについては後述する。

同期オブジェクト２１５は、例えばセマフォのような同期オブジェクトを示す。ここで、各プロセスはI/Oアクセスする際に、必ず同期オブジェクト２１５をロックする。また、同期オブジェクト２１５をロックできないと、そのプロセスはロックできるまで、あるいは、タイムアウトするまで、「待ち状態」に遷移する。

また、同期オブジェクト２１５においては、ロックはCPU処理のため、優先度の高いプロセスほど先にロックすることが可能となる。すなわち、あるタイミングで優先度の高い帯域保証プロセス２１１がI/Oアクセスした場合、それよりも優先度の低いプロセスは同期オブジェクト２１５をロックすることができず、「待ち状態」となる。

ここで、図２７の一般的なI/Oスケジューラで説明した通り、I/Oデバイス２１７に接続されるリクエストキュー２１６は単純なFIFO動作をするため、優先度が高いプロセス（例えば帯域保証プロセス２１１）が実行されていない間に、膨大なサイズのI/Oアクセスを行うと、FIFOが優先度の低いプロセス（例えば非帯域保証プロセス２１２）のキューで埋まってしまい、該I/Oアクセスが完了するまで、帯域保証プロセス２１１のI/Oアクセスが待たされてしまう。

そこで、アクセスサイズ分割部２１４は、非帯域保証プロセス２１２のI/Oアクセスを複数に分割し、リクエストキュー２１６のFIFO段数を減らすことで（最小はFIFO処理をなくしてもよい）、非帯域保証プロセス２１２のI/Oアクセス占有時間を制限する。

アクセスサイズ分割部２１４による分割するサイズの決定方法は、例えば、図２９のグラフに示すように、I/Oアクセスサイズと、それに必要なアクセス時間を予備試験により測定し、その最悪値、あるいは平均値など、システムの特性に応じてI/Oアクセス時間から決定する。

図２９のグラフにおいては、点線は実際のI/Oリードおよびライト処理に必要なI/Oアクセス時間であるが、双方の最悪値にマージンを加算した実線をI/Oアクセス必要時間として採用している。このI/Oアクセス必要時間を基に、これまで説明してきた基準周期T以内に収まるI/OアクセスサイズSを求める。すなわち、アクセスサイズ分割部２１４は、このサイズを超えないように、アクセスサイズを分割する。これにより、非帯域保証プロセス２１２が大きなサイズのI/Oアクセスを実行しても、アクセスサイズ分割部２１４によって、基準周期T以内に収まるI/Oアクセスに細分化される。これにより、その後の同期オブジェクト２１５のロック動作については細分化された単位で行われることになる。

従って、仮に、帯域保証プロセス２１１がI/Oアクセスする前に、非帯域保証プロセス２１２が大きいサイズのI/Oアクセスを行った場合でも、細分化された１つのI/Oアクセス単位分のみの遅延で帯域保証プロセス２１１はI/Oアクセスを開始できる。

なお、第６の実施の形態では、細分化するI/Oアクセスのサイズを周期T分としているので、帯域保証プロセス２１１のI/Oアクセス遅延時間は、最大で周期T分となる。

帯域保証プロセス２１１におけるI/Oアクセス時間の保証は、第１の実施の形態乃至第５の実施の形態で説明した、起動周期時間と同じ時間を使用することで、優先順が固定的に決定可能となり、また周期をT×2ⁿと制限していることから、各プロセスの開始タイミングは優先度順に開始される。つまり、上述したように、同期オブジェクト２１５をロックするタイミングが優先度の高い順、すなわち、起動周期の短い順となり、結果的にI/Oアクセスも周期的に処理され、そのアクセス時間の最大値が保証可能となる。

I/O時間が保証可能か否かの判定は、上述した起動周期時間をT_CYCLEとし、I/Oアクセス時間をT_I/Oとすると、下記の式（６）を用いて、I/Oアクセス時間の保証が必要なプロセス（以下、I/O帯域保証型プロセスと称する）について、夫々I/O使用率I/O_USEを計算し、そのI/O帯域保証型プロセスのI/O使用率の合計I/O_ALLが、下記の式（７）を満たしているかを判定することで可能となる。

I/O_USE ＝ T_I/O ÷ T_CYCLE ・・・（６）

I/O_ALL ≦ THL _I/O ・・・（７）

ここで、式（７）のTHL _I/Oとは、プロセススケジューリングシステムにおいて予め決められた、I/O帯域保証型プロセスが使用可能なI/O使用率を表わす。例えば、第６の実施の形態では、THL _I/O＝80％として、残りの20％をI/O帯域保証型プロセス以外で使用する。

また、T_I/Oの求め方については、図２９に示したように、予備試験によりI/Oアクセスサイズと、I/Oアクセス時間との関係を求め、I/OアクセスサイズからI/Oアクセス時間T_I/Oを求めるための式を決定する。第６の実施の形態では、図２９の実線の傾きからT_I/Oを求めるが、例えば、リードとライトでパラメータを変えたり、複数ポイントの傾きをテーブルで持ち、より予備試験で得られた曲線に近い値になるように調整してもよい。また、ハードディスクドライブのように、メディアの転送レートの他に、固定的に決定されるシーク時間や、平均アクセス時間などをパラメータとして加味してもよい。

なお、第６の実施の形態では、１つのI/Oについての帯域保証方法を説明したが、２つの非ブロッキングI/Oデバイスがある場合、夫々について、式（７）を満足することを確認する必要がある。

また、非ブロッキングI/Oアクセスを保証するI/O帯域型保証プロセスは、第１の実施の形態乃至第５の実施の形態におけるCPU使用時間の保証も併せて実装することで、CPUのみでなく、I/Oについても帯域を保証したシステムを構築することが可能となる。この場合、例えば、図２のステップＳ１３において、帯域管理部１２により、式（２）を用いて、ユーザプロセス１４にCPU帯域を割り当てられるか否かが判定され、さらに、式（７）を用いて、I/O帯域を保証可能か否かが判定される。

また、第６の実施の形態では、帯域保証プロセス２１１についても、アクセスサイズ分割部２１３を備えているが、帯域保証プロセス２１１については、式（７）の帯域保証可能条件により、I/Oアクセス帯域の制御が行われているため、アクセスサイズ分割部２１３は省略可能である。アクセスサイズ分割部２１３を省略すると、あるI/O帯域保証型プロセスが、申告しているI/Oアクセスサイズ以上をアクセスしてしまったり、何らかの物理的要因でI/Oアクセスが遅れてしまい、結果的に申告しているI/O使用率を超過してしまった場合に、遅延時間が後に続くI/O帯域保証型プロセスに伝播してしまい、システム全体のI/O帯域保証ができなくなる可能性がある。これはI/Oデバイスの特性に合わせて、アクセスサイズ分割部２１３の有無や細分化サイズの調整、あるいは、I/Oアクセスバッファを設け、I/Oアクセス時間を平均化するなどの手段を選択すればよい。

また、第２の実施の形態乃至第５の実施の形態で説明した、CPU帯域保証型プロセスの再投入動作処理は、第６の実施の形態にも適用可能であり、その方法はCPU帯域の再投入動作処理と同じ手順で実現可能である。

なお、第６の実施の形態では、I/Oの物理的要因での遅延などについては述べていないが、I/Oの故障などで、アクセス時間が遅れた場合、エラー処理などして、ユーザに帯域が守れなかったことを通知する手段を設けてもよい。

以上のように、第６の実施の形態によれば、非I/O帯域保証型プロセスのI/Oアクセスを細分化し、I/Oアクセスキューを同期オブジェクト２１５で排他制御することで、I/O帯域保証型プロセスのI/Oアクセスを保証でき、かつ、CPU帯域の保証も可能となり、上記第３の課題の複数のユーザプロセスについて、I/O待ちまでを含めたCPU使用時間を管理、保証することが困難になるといった問題を解決可能である。

なお、第１の実施の形態乃至第６の実施の形態では、OSの一例として、Linux2.6を例にして説明したが、プロセスのスケジューリング機能を有する他のOSを用いてもよい。

また、第１の実施の形態乃至第６の実施の形態では、「タスク」、「プロセス」、「スレッド」は、その違いは区別せずに、同意に扱うものとする。

ところで、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等に、プログラム記録媒体からインストールされる。

図３０は、上述した一連の処理をプログラムにより実行するパーソナルコンピュータの構成の例を示すブロック図である。CPU３１１は、ROM（Read Only Memory）３１２、または記録部３１８に記録されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）３１３には、CPU３１１が実行するプログラムやデータ等が適宜記憶される。これらのCPU３１１、ROM３１２、およびRAM３１３は、バス３１４により相互に接続されている。

CPU３１１にはまた、バス３１４を介して入出力インターフェース３１５が接続されている。入出力インターフェース３１５には、マイクロホン等よりなる入力部３１６、ディスプレイ、スピーカ等よりなる出力部３１７が接続されている。CPU３１１は、入力部３１６から入力される指令に対応して各種の処理を実行する。そして、CPU３１１は、処理の結果を出力部３１７に出力する。

入出力インターフェース３１５に接続されている記録部３１８は、例えばハードディスクからなり、CPU３１１が実行するプログラムや各種のデータを記録する。通信部３１９は、インターネットやローカルエリアネットワーク等のネットワークを介して外部の装置と通信する。

また、通信部３１９を介してプログラムを取得し、記録部３１８に記録してもよい。

入出力インターフェース３１５に接続されているドライブ３２０は、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリ等のリムーバブルメディア３２１が装着されたとき、それらを駆動し、そこに記録されているプログラムやデータ等を取得する。取得されたプログラムやデータは、必要に応じて記録部３１８に転送され、記録される。

コンピュータにインストールされ、コンピュータによって実行可能な状態とされるプログラムを格納するプログラム記録媒体は、図３０に示すように、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)を含む）、光磁気ディスク、もしくは半導体メモリ等よりなるパッケージメディアであるリムーバブルメディア３２１、または、プログラムが一時的もしくは永続的に格納されるROM３１２や、記録部３１８を構成するハードディスク等により構成される。プログラム記録媒体へのプログラムの格納は、必要に応じてルータ、モデム等のインターフェースである通信部３１９を介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を利用して行われる。

なお、本明細書において、記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。

本発明を適用したプロセススケジューリングシステムの一実施の形態の構成を示すブロック図である。 帯域管理処理について説明するフローチャートである。 起動周期管理テーブルの例を示す図である。 プロセスの状態遷移の概要を説明する図である。 プロセスの投入時間の例を示すタイミングチャートである。 プロセスのスケジューリング結果の例を示すタイミングチャートである。 優先度テーブルの例を示す図である。 周期内処理について説明するフローチャートである。 起動指示処理について説明するフローチャートである。 プロセスの起動タイミングの例を示すタイミングチャートである。 プロセスのスケジューリング結果の例を示すタイミングチャートである。 本発明を適用したプロセススケジューリングシステムの一実施の形態の他の構成を示すブロック図である。 起動周期管理テーブルの例を示す図である。 実行時間監視処理について説明するフローチャートである。 周期内処理について説明するフローチャートである。 イベント通知処理について説明するフローチャートである。 プロセスのスケジューリング結果の例を示すタイミングチャートである。 本発明を適用したプロセススケジューリングシステムの一実施の形態の他の構成を示すブロック図である。 起動周期管理テーブルの例を示す図である。 起動指示処理について説明するフローチャートである。 周期完了通知処理について説明するフローチャートである。 起動周期管理テーブルの例を示す図である。 再投入動作のスケジューリング結果の例を示すタイミングチャートである。 起動周期管理テーブルの例を示す図である。 再投入確認処理について説明するフローチャートである。 再投入動作のスケジューリング結果の例を示すタイミングチャートである。 一般的なI/Oスケジューラの概念を説明する図である。 本実施の形態のI/Oスケジューラの概念を説明する図である。 I/Oデバイスのリード/ライト特性を説明する図である。 パーソナルコンピュータの構成を説明する図である。

符号の説明

１ プロセススケジューリングシステム， １１ タイマ， １２ 帯域管理部， １３ 起動周期管理テーブル， １４ ユーザプロセス， １５ プロセススケジューラ， １６ 起動指示部， ２１ 帯域保証ライブラリ， ４１ プロセススケジューリングシステム， ５１ 起動周期管理テーブル， ５２ プロセススケジューラ， ５３ 実行時間監視部， ６１ 帯域保証ライブラリ， １０１ プロセススケジューリングシステム， １１１ 起動周期管理テーブル， １１２ 起動指示部， １２１ 帯域保証ライブラリ， ２１１ 帯域保証プロセス， ２１２ 非帯域保証プロセス， ２１３ アクセスサイズ分割部， ２１４ アクセスサイズ分割部， ２１５ 同期オブジェクト， ２１６ リクエストキュー， ２１７ I/Oデバイス

Claims (18)

1. 複数のプロセスを実行するためのリソースを有する情報処理装置において、
   前記リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間毎に、前記実行可能状態から前記実行状態に遷移させる状態制御手段と、
   前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御する実行制御手段と
   を備え、
   前記状態制御手段は、前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる
   情報処理装置。
2. 前記実行制御手段は、前記プロセスから申告されてくる前記実行周期時間と、前記実行周期時間内で占有する前記リソースのリソース使用時間とから得られるリソース使用率であって、既に、前記リソースの使用を保証している全てのプロセスの前記リソース使用率の合計が、所定の閾値未満になる場合、前記実行周期時間を前記基準周期時間の2ⁿ倍とする
   請求項１に記載の情報処理装置。
3. 前記実行優先度は、前記実行周期時間の短いプロセスほど高く設定される
   請求項１に記載の情報処理装置。
4. 前記状態制御手段は、前記リソース使用率が、前記閾値から前記リソース使用率の合計を減じた値よりも小さい場合、前記実行周期時間に係わらず、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる
   請求項２に記載の情報処理装置。
5. 前記状態制御手段は、既に、前記リソースの使用を保証している全てのプロセスから申告された前記実行周期時間のうち、最長の実行周期時間内の任意の時間となったとき、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる
   請求項４に記載の情報処理装置。
6. 前記実行制御手段は、前記プロセスが前記実行状態から前記実行可能状態に遷移した時間と、前記プロセスから申告された前記リソース使用時間とを比較し、申告された前記リソース使用時間よりも、前記実行可能状態に遷移した時間のほうが短い場合、その差分を余り時間として積算し、
   前記状態制御手段は、前記余り時間の積算値が前記プロセスの申告した前記リソース使用時間よりも大きい場合、前記実行周期時間に係わらず、前記プロセスの状態を、実行可能状態から実行状態に遷移させる
   請求項２に記載の情報処理装置。
7. 前記実行制御手段は、前記余り時間の積算値を、前記リソースの使用を保証している全てのプロセスから申告された前記実行周期時間のうち、最長の実行周期時間となったとき、0にクリアする
   請求項６に記載の情報処理装置。
8. 前記実行制御手段は、前記プロセスの状態が、実行可能状態から実行状態に遷移される際に、前記リソースの使用を保証している全てのプロセスを再投入する処理を行うときの優先度である再投入優先度に基づいて、前記余り時間に再投入するプロセスを特定する
   請求項６に記載の情報処理装置。
9. 前記再投入優先度は、前記プロセスの状態に係わらず、任意の時間に設定または変更可能である
   請求項８に記載の情報処理装置。
10. 前記リソースは、CPU使用時間である
    請求項１に記載の情報処理装置。
11. 前記CPU使用時間は、ブロッキングI/O（Input/Output）の使用時間を含んでいる
    請求項１０に記載の情報処理装置。
12. 前記リソースは、非ブロッキングI/Oの使用時間を含んでおり、
    前記実行制御手段は、前記リソースの使用を保証している全てのプロセスのCPU使用率の合計が予め定められた第１の閾値未満となり、かつ、前記プロセスのうち、非ブロッキングI/Oの前記リソースの使用も保証しているプロセスの前記非ブロッキングI/O毎のリソース使用率の合計が予め定められた第２の閾値未満となるようにする
    請求項１０に記載の情報処理装置。
13. 1回のI/Oアクセスサイズを、前記基準周期時間内に処理可能なサイズに分割する分割手段をさらに備える
    請求項１２に記載の情報処理装置。
14. 前記実行制御手段は、前記リソースの使用を保証しているプロセスが申告したリソース使用時間を超過した場合、前記プロセスの前記実行優先度を一時的に下げる
    請求項２に記載の情報処理装置。
15. 前記実行制御手段は、前記実行優先度を下げられたプロセスの1周期分の処理が完了したとき、前記実行優先度を元の値に戻す
    請求項１４に記載の情報処理装置。
16. 前記実行制御手段は、前記実行優先度を下げられたプロセスの前記実行周期時間が再度経過したとき、前記実行優先度を元の値に戻す
    請求項１４に記載の情報処理装置。
17. 複数のプロセスを実行するためのリソースを有する情報処理装置の情報処理方法において、
    前記リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間毎に、前記実行可能状態から前記実行状態に遷移させ、
    前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御し、
    前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる
    ステップを含む情報処理方法。
18. 複数のプロセスを実行するためのリソースを有する情報処理装置の情報処理を、コンピュータに行わせるプログラムにおいて、
    前記リソースの使用が保証されているプロセスであって、実行優先度に応じて、少なくとも、実行状態、実行可能状態、または待ち状態の３状態に遷移する前記プロセスの状態を、所定の実行周期時間毎に、前記実行可能状態から前記実行状態に遷移させ、
    前記実行周期時間を、一定の間隔で割り込み処理を実行させるための基準周期時間の2ⁿ倍（nは0から始まる整数値）とし、前記プロセスの実行を制御し、
    前記基準周期時間の2ⁿ倍とされた前記実行周期時間毎に、前記プロセスの状態を、前記実行可能状態から前記実行状態に遷移させる
    ステップを含む処理をコンピュータに実行させるプログラム。

Images