JP2005018590A - スケジューリング方法およびリアルタイム処理システム - Google Patents

Abstract

【課題】互いに協調して動作するスレッド間のデータの受け渡しを効率よく実行する。
【解決手段】リアルタイム処理システムは、密結合スレッドグループというスレッドグループの属性を利用し、スレッドグループが互いに協調して動作するスレッド群を含む密結合スレッドグループであるか否かを判別する。スレッドグループが密結合スレッドグループであることが判別された場合、リアルタイム処理システムは、密結合スレッドグループに属するスレッド群がそれぞれ別のプロセッサ（ＶＰＵ）によって同時に実行されるように、密結合スレッドグループに属するスレッド群を当該スレッド群の個数分のプロセッサ（ＶＰＵ）にそれぞれディスパッチするためのスケジューリング処理を実行する。
【選択図】 図２５

Description

【０００１】
【発明の属する技術分野】
本発明は複数のプロセッサにリアルタイム処理を実行するためのスレッド群を割り当てるスケジューリング方法およびリアルタイム処理システムに関する。
【０００２】
【従来の技術】
従来より、サーバコンピュータのような計算機システムにおいては、その演算処理能力の向上を図るために、マルチプロセッサ、並列プロセッサのようなシステムアーキテクチャが利用されている。マルチプロセッサおよび並列プロセッサのどちらも、複数のプロセッサユニットを利用することによって演算処理の並列化を実現している。
複数のプロセッサユニットを備えたシステムとしては、例えば、１台の高速ＣＰＵ、複数台の低速ＣＰＵ、および共有メモリを備えたシステムが知られている（例えば、特許文献１参照）。このシステムにおいては、高速ＣＰＵおよび複数台の低速ＣＰＵに対する処理プログラムのプロセス群の割付は、プロセス群の並列動作度の大小および処理時間の大小に応じて行われる。
【０００３】
また、複数のプロセッサにスレッド群を割り当てるためのスケジューリング技術としては、同一のプロセス内に属するスレッドを同一のプロセッサに実行させる技術が知られている（例えば、特許文献２参照）。
【０００４】
ところで、最近では、計算機システムのみならず、例えば、ＡＶ（オーディオ・ビデオ）データのような大容量のデータをリアルタイムに処理する組み込み機器においても、その演算処理能力の向上のためにマルチプロセッサ、並列プロセッサのようなシステムアーキテクチャの導入が要求されている。
【０００５】
【特許文献１】
特開平１０−１４３３８０号公報
【０００６】
【特許文献２】
特開平８−１８００２５号公報
【０００７】
【発明が解決しようとする課題】
しかし、マルチプロセッサ、並列プロセッサのようなシステムアーキテクチャを前提としたリアルタイム処理システムの報告はほとんどなされていないのが現状である。
リアルタイム処理システムにおいては、ある許容時間時間の制限内に個々の処理を完了することが要求される。しかし、マルチプロセッサ、並列プロセッサのようなシステムアーキテクチャをリアルタイム処理システムに適用した場合においては、互いに異なるプロセッサユニットによって実行されるスレッド間の通信に関するレイテンシが大きな問題となる。
【０００８】
すなわち、通常、互いに異なるプロセッサユニットによって実行されるスレッド間でデータを受け渡すための通信は、共有メモリ上のバッファを介して行う必要がある。これは、それらスレッドそれぞれがどのようなタイミングでどのプロセッサユニットに割り当てられたとしても、データ欠損等の問題が生じないようにするためである。
【０００９】
本発明は上述の事情を考慮してなされたものであり、互いに協調して動作するスレッド間のデータの受け渡しを効率よく実行することが可能なスケジューリング方法およびリアルタイム処理システムを提供することを目的とする。
【００１０】
【課題を解決するための手段】
上述の課題を解決するため、本発明は、複数のプロセッサにリアルタイム処理を実行するためのスレッド群を割り当てるスケジューリング方法であって、スレッド間の結合属性を示す結合属性情報に基づいて、前記リアルタイム処理を実行するためのスレッド群の中から、互いに協調して動作する複数のスレッドの集合である密結合スレッドグループを選択する選択ステップと、前記選択ステップによって選択された前記密結合スレッドグループに属するスレッド群がそれぞれ別のプロセッサによって同時に実行されるように、前記密結合スレッドグループに属するスレッド群を当該スレッド群の個数分のプロセッサにそれぞれディスパッチするためのスケジューリング処理を実行するステップとを具備することを特徴とする。
【００１１】
このように、結合属性情報に基づいて、互いに協調して動作する複数のスレッドの集合である密結合スレッドグループを選択することにより、密結合スレッドグループに属するスレッド群がそれぞれ別のプロセッサによって同時に実行されることを保証することが可能となる。よって、スレッド間の通信は、例えば、互いに相手のスレッドが実行されているプロセッサの例えばレジスタ等を直接アクセスするといった軽量な仕組みによって実現することができ、スレッド間の通信を軽量且つ高速に実行することが可能となる。
【００１２】
複数のプロセッサはローカルメモリをそれぞれ有することが好ましい。この場合、密結合スレッドグループに属するスレッド群の各々の実効アドレス空間の一部に、密結合スレッドグループに属する他のスレッドが実行されるプロセッサのローカルストレージをマッピングすることにより、各スレッドが、相手のスレッドが実行されているプロセッサのローカルストレージを直接的にアクセスすることが可能となる。
【００１３】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。
図１には、本発明の一実施形態に係るリアルタイム処理システムを実現するための計算機システムの構成例が示されている。この計算機システムは、リアルタイム性が要求される各種処理をその時間的な制約条件の範囲内で実行する情報処理システムであり、汎用計算機として利用できるほか、リアルタイム性が要求される処理を実行するための様々な電子機器用の埋め込みシステムとして利用することができる。図１に示されているように、この計算機システムにおいては、マスタープロセッサユニット（ＭＰＵ１１：Ｍａｓｔｅｒ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、複数のバーサタイルプロセッサユニット（ＶＰＵ：Ｖｅｒｓａｔｉｌｅ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２と、メインメモリ１４と、入出力制御装置１５とが、接続装置１３によって相互に接続されている。接続装置１３は、例えば、クロスバスイッチのような相互結合網、あるいはバスによって構成されている。リング状のバス構造を用いることも出来る。ＭＰＵ１１は計算機システムの動作を制御するメインプロセッサである。オペレーティングシステム（ＯＳ：Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は、主にＭＰＵ１１によって実行される。ＯＳの一部の機能はＶＰＵ１２や入出力制御装置１５で分担して実行することもできる。各ＶＰＵ１２は、ＭＰＵ１１の管理の下で各種の処理を実行するプロセッサである。ＭＰＵ１１は、複数のＶＰＵ１２に処理を振り分けて並列に実行させるための制御を行う。これにより高速で効率よい処理の実行を行うことが出来る。メインメモリ１４は、ＭＰＵ１１、複数のＶＰＵ１２および入出力制御装置１５によって共有される記憶装置（共有メモリ）である。ＯＳおよびアプリケーションプログラムはメインメモリ１４に格納される。入出力制御装置１５には、ひとつあるいは複数の入出力デバイス（入出力装置）１６が接続される。入出力制御装置１５はブリッジとも呼ばれる。
【００１４】
接続装置１５はデータ転送レートを保証するＱｏＳ機能を持つ。この機能は、接続装置１５を介したデータ転送を予約されたバンド幅（転送速度）で実行することによって実現される。ＱｏＳ機能は、たとえば、あるＶＰＵ１２からメモリ１４に５Ｍｂｐｓでライトデータを送信する場合、あるいはあるＶＰＵ１２と別のＶＰＵ１２との間で１００Ｍｂｐｓでデータ転送する場合に利用される。ＶＰＵ１２は接続装置１３に対してバンド幅（転送速度）を指定（予約）する。接続装置１３は指定されたバンド幅を要求したＶＰＵ１２に対して優先的に割り当てる。あるＶＰＵ１２のデータ転送に対してバンド幅が予約されたならば、そのＶＰＵ１２によるデータ転送中に他のＶＰＵ１２、ＭＰＵ１１あるいは入出力制御装置１５が大量のデータ転送を行っても、予約されたバンド幅は確保される。この機能は、特に、リアルタイム処理を行う計算機にとって重要な機能である。
【００１５】
図１の構成では、ＭＰＵ１１が１つ、ＶＰＵ１２が４つ、メモリ１４が１つ、入出力制御装置が１つであるが、ＶＰＵ１２の個数は制限されない。またＭＰＵ１１を持たない構成も可能である。この場合、ＭＰＵ１１の行う処理は、ある一つのＶＰＵ１２が担当する。つまり、仮想的なＭＰＵ１１の役割をＶＰＵが兼ねる。
【００１６】
図２には、ＭＰＵ１１と各ＶＰＵ１２の構成が示されている。ＭＰＵ１１は処理ユニット２１およびメモリ管理ユニット２２を備えている。処理ユニット２１は、メモリ管理ユニット２２を通してメモリ１４をアクセスする。メモリ管理ユニット２２は、仮想記憶管理と、メモリ管理ユニット２２内のキャッシュメモリの管理を行うユニットである。各ＶＰＵ１２は、処理ユニット３１、ローカルストレージ（ローカルメモリ）３２、およびメモリコントローラ３３を備えている。各ＶＰＵ１２の処理ユニット３１は、そのＶＰＵ内部のローカルストレージ３２を直接アクセスすることができる。メモリコントローラ３３は、ローカルストレージ３２とメモリ１４の間のデータ転送を行うＤＭＡコントローラの役割を持つ。このメモリコントローラ３３は、接続装置１４のＱｏＳ機能を利用できるように構成されており、バンド幅を予約する機能および予約したバンド幅でデータ入出力を行う機能を有している。またメモリコントローラ３３は、ＭＰＵ１１のメモリ管理ユニット２２と同様の仮想記憶管理機能を持つ。ＶＰＵ１２の処理ユニット３１はローカルストレージ３２を主記憶として使用する。処理ユニット３１はメモリ１４に対して直接的にアクセスするのではなく、メモリコントローラ３３に指示して、メモリ１４の内容をローカルストレージ３２に転送して読んだり、ローカルストレージ３２の内容をメモリ１４に書いたりする。
【００１７】
ＭＰＵ１１のメモリ管理ユニット２２およびＶＰＵ１２のメモリコントローラ３３それぞれによって実行される仮想記憶管理は、たとえば図３のように実施することができる。ＭＰＵ１１の処理ユニット２１あるいはＶＰＵ１２のメモリコントローラ３３から見たアドレスは、図３の上の部分に示すような６４ビットのアドレスである。この６４ビットのアドレスは、上位の３６ビットがセグメント番号、中央の１６ビットがページ番号、下位の１２ビットがページオフセットである。このアドレスから、実際に接続装置１３を通してアクセスする実アドレス空間への変換は、セグメントテーブル５０およびページテーブル６０を用いて実行される。セグメントテーブル５０およびページテーブル６０は、メモリ管理ユニット２２およびメモリコントローラ３３に各々設けられている。
【００１８】
ＭＰＵ１１および各ＶＰＵ１２から見た実アドレス（ＲＡ）空間には、図４に示すように、たとえば以下のようなデータがマッピングされている。
１．メモリ（主記憶装置）
２．ＭＰＵ１１の各種制御レジスタ
３．各ＶＰＵ１２の各種制御レジスタ
４．各ＶＰＵ１２のローカルストレージ
５．各種入出力デバイス（入出力装置）の制御レジスタ（入出力制御装置の制御レジスタも含む）
ＭＰＵ１１および各ＶＰＵ１２は、実アドレス空間の該当するアドレスにアクセスすることで、１〜５の各データを読み書きすることができる。特に、実アドレス空間にアクセスすることで、どのＭＰＵ１１からでも、あるいはどのＶＰＵ１２からでも、さらに入出力制御装置１５からでも、任意のＶＰＵ１２のローカルストレージ３２にアクセスすることができることは重要である。またセグメントテーブルあるいはページテーブルを用いて、ＶＰＵ１２のローカルストレージ３２の内容が自由に読み書きされないように保護することもできる。
ＭＰＵ１１あるいはＶＰＵ１２からみたアドレス空間は、図３の仮想記憶メカニズムを用いて、たとえば図５に示すようにマッピングされる。ＭＰＵ１１あるいはＶＰＵ１２上で実行しているプログラムから直接見えるのは、実効アドレス（ＥＡ；Ｅｆｆｅｃｔｉｖｅ Ａｄｄｒｅｓｓ）空間である。ＥＡは、セグメントテーブル５０によって、仮想アドレス（ＶＡ；Ｖｉｒｔｕａｌ Ａｄｄｒｅｓｓ）空間にマッピングされる。さらにＶＡは、ページテーブル６０によって、実アドレス（ＲＡ；Ｒｅａｌ Ａｄｄｒｅｓｓ）空間にマップされる。このＲＡが、図４で説明したような構造を持っている。
【００１９】
ＭＰＵ１１は制御レジスタ等のハードウェア機構によって、例えば、各ＶＰＵ１２のレジスタの読み書き、各ＶＰＵ１２のプログラムの実行開始／停止などの、各ＶＰＵ１２の管理を行うことができる。また、ＭＰＵ１１とＶＰＵ１２の間、あるいはあるＶＰＵ１２と他のＶＰＵ１２の間の通信や同期は、メールボックスやイベントフラグなどのハードウェア機構によって行うことが出来る。
【００２０】
この実施形態の計算機システムは、従来ハードウェアで実現されていたようなリアルタイム性の要求の厳しい機器の動作を、ソフトウェアを用いて実現することを可能にする。例えば、あるＶＰＵ１２があるハードウェアを構成するある幾つかのハードウェアコンポーネントに対応する演算処理を実行し、それと並行して、他のＶＰＵ１２が他の幾つかのハードウェアコンポーネントに対応する演算処理を実行する。
【００２１】
図６はデジタルテレビ放送の受信機の簡略化したハードウェア構成を示している。図６においては、受信した放送信号はＤＥＭＵＸ（デマルチプレクサ）回路１０１によって音声データと映像データと字幕データそれぞれに対応する圧縮符号化されたデータストリームに分解される。圧縮符号化された音声データストリームはＡ−ＤＥＣ（音声デコーダ）回路１０２によってデコードされる。圧縮符号化された映像データストリームはＶ−ＤＥＣ（映像デコーダ）回路１０３によってデコードされる。デコードされた映像データストリームはＰＲＯＧ（プログレッシブ変換）回路１０５に送られ、そこでプログレッシブ映像信号に変換するためのプログレッシブ変換処理が施される。プログレッシブ変換された映像データストリームはＢＬＥＮＤ（画像合成）回路１０６に送られる。字幕データストリームはＴＥＸＴ（字幕処理）回路１０４によって字幕の映像に変換された後、ＢＬＥＮＤ回路１０６に送られる。ＢＬＥＮＤ回路１０６は、ＰＲＯＧ回路１０５から送られてくる映像と、ＴＥＸＴ回路１０４から送られてくる字幕映像とを合成して、映像ストリームとして出力する。この一連の処理が、映像のフレームレート（たとえば、１秒間に３０コマ、３２コマ、または６０コマ）に従って、繰り返し実行される。
【００２２】
図６のようなハードウェアの動作をソフトウェアによって実行するために、本実施形態では、たとえば図７に示すように、図６のハードウェアの動作をソフトウェアとして実現したプログラムモジュール１００を用意する。このプログラムモジュール１００は、複数の処理要素の組み合わせから構成されるリアルタイム処理を計算機システムに実行させるためのアプリケーションプログラムであり、マルチスレッドプログラミングを用いて記述されている。このプログラムモジュール１００は、図６のハードウェアコンポーネント群に対応する複数の処理要素それぞれに対応した手順を記述した複数のプログラム１１１〜１１６を含んでいる。すなわち、プログラムモジュール１００には、ＤＥＭＵＸプログラム１１１、Ａ−ＤＥＣプログラム１１２、Ｖ−ＤＥＣプログラム１１３、ＴＥＸＴプログラム１１４、ＰＲＯＧプログラム１１５、およびＢＬＥＮＤプログラム１１６が含まれている。ＤＥＭＵＸプログラム１１１、Ａ−ＤＥＣプログラム１１２、Ｖ−ＤＥＣプログラム１１３、ＴＥＸＴプログラム１１４、ＰＲＯＧプログラム１１５、およびＢＬＥＮＤプログラム１１６は、それぞれ図６のＤＥＭＵＸ回路１０１、Ａ−ＤＥＣ回路１０２、Ｖ−ＤＥＣ回路１０３、ＴＥＸＴ回路１０４、ＰＲＯＧ回路１０５、およびＢＬＥＮＤ回路１０６に対応する処理を実行するためのプログラムであり、それぞれスレッドとして実行される。つまり、プログラムモジュール１００の実行時には、ＤＥＭＵＸプログラム１１１、Ａ−ＤＥＣプログラム１１２、Ｖ−ＤＥＣプログラム１１３、ＴＥＸＴプログラム１１４、ＰＲＯＧプログラム１１５、およびＢＬＥＮＤプログラム１１６それぞれに対応するスレッドが生成され、生成されたスレッドそれぞれが１以上のＶＰＵ１２にディスパッチされて実行される。ＶＰＵ１２のローカルストレージ３２にはそのＶＰＵ１２にディスパッチされたスレッドに対応するプログラムがロードされ、スレッドはローカルストレージ３２上のプログラムを実行する。デジタルテレビ放送の受信機を構成するハードウェアモジュール群それぞれに対応するプログラム１１１〜１１６と、構成記述１１７と呼ぶデータとをパッケージ化したものが、デジタルテレビ放送の受信機を実現するプログラムモジュール１００になる。
【００２３】
構成記述１１７は、プログラムモジュール１００内の各プログラム（スレッド）をどのように組み合わせて実行するべきかを示す情報であり、プログラム１１１〜１１６間の入出力関係および各プログラムの処理に必要なコスト（時間）などを示す。図８には構成記述１１７の例が示されている。
【００２４】
図８の構成記述１１７の例では、スレッドとして動作する各モジュール（プログラムモジュール１００内の各プログラム）に対して、その入力につながるモジュール、その出力がつながるモジュール、そのモジュールの実行に要するコスト、出力がつながるモジュールそれぞれへの出力に必要なバッファサイズが記述されている。たとえば、番号▲３▼のＶ−ＤＥＣプログラムは、番号▲１▼のＤＥＭＵＸプログラムの出力を入力とし、その出力は番号▲５▼のＰＲＯＧプログラムに向かっており、その出力に必要なバッファは１ＭＢで、番号▲３▼のＶ−ＤＥＣプログラム自体の実行コストは５０であることを示している。なお、実行に必要なコストは、実行に必要な時間（実行期間）やステップ数などを単位として記述することができる。また、何らかの仮想的な仕様のＶＰＵで実行した場合の時間を単位とすることも可能である。計算機によってＶＰＵの仕様や処理性能が異なる場合もあるので、このように仮想的な単位を設けてコストを表現するのは望ましい形態である。図８に示した構成記述１１７に従って実行する場合の、プログラム間のデータの流れは図９の通りである。
【００２５】
さらに、構成記述１１７には、プログラム１１１〜１１６それぞれに対応するスレッド間の結合属性を示す結合属性情報がスレッドパラメータとして記述されている。なお、スレッドパラメータはプログラム１１１〜１１６中にコードとして直接記述することも可能である。
【００２６】
次に、図１０、図１１を参照して、プログラム１１１〜１１６が本実施形態の計算機システムによってどのように実行されるかを説明する。ここでは、ＶＰＵ０とＶＰＵ１の２つのＶＰＵ１２が計算機システムに設けられている構成を想定する。毎秒３０フレームで映像を表示する場合の、各ＶＰＵ１２に対するプログラムの割り当てを時間を追って記入したのが図１０である。ここでは周期１の間で１フレーム分の音声と映像を出力している。まず、ＶＰＵ０でＤＥＭＵＸプログラムが処理を行い、その結果の音声と映像と字幕のデータをバッファに書き込む。その後ＶＰＵ１でＡ−ＤＥＣプログラムとＴＥＸＴプログラムを順次実行し、それぞれの処理結果をバッファに書き込む。ＶＰＵ０では、次にＶ−ＤＥＣプログラムが映像データの処理を行い、結果をバッファに書き込む。ＶＰＵ０では、続いてＰＲＯＧプログラムが処理を行い、結果をバッファに書き込む。この時点で、ＶＰＵ１でのＴＥＸＴの処理は終わっているので、最後のＢＬＥＮＤプログラムの実行をＶＰＵ０で行い、最終的な映像データを作成する。この処理の流れを、毎周期繰り返すように実行する。
【００２７】
ここで説明したように、所望の動作を滞りなく行えるように、各ＶＰＵ１２上で、いつ、どのプログラムを実行するかを決める作業を、スケジューリングとよぶ。スケジューリングを行うモジュールをスケジューラとよぶ。本実施形態では、プログラムモジュール１００中に含まれる上述の構成記述１１７に基づいてスケジューリングが行われる。
【００２８】
図１１は、毎秒６０フレームで表示する場合の実行の様子を示している。図１０と異なるのは、図１０では毎秒３０フレームだったので、１周期（１／３０秒）で１フレーム分の処理を完了できたのに対し、図１１では毎秒６０フレーム処理する必要がある点である。すなわち、１周期（１／６０秒）では１フレーム分の処理を完了できないので、図１１では、複数（ここでは２）周期にまたがったソフトウェアパイプライン処理を行っている。たとえば周期１のはじめに入力された信号に対して、ＶＰＵ０でＤＥＭＵＸ処理とＶ−ＤＥＣ処理を行う。その後、周期２においてＶＰＵ１でＡ−ＤＥＣ、ＴＥＸＴ、ＰＲＯＧ、ＢＬＥＮＤの各処理を行って最終的な映像データを出力する。周期２ではＶＰＵ０は次のフレームのＤＥＭＵＸとＶ−ＤＥＣの処理を行っている。このように、ＶＰＵ０によるＤＥＭＵＸ，Ｖ−ＤＥＣの処理と、ＶＰＵ１によるＡ−ＤＥＣ、ＴＥＸＴ、ＰＲＯＧ、ＢＬＥＮＤの処理を、２周期にまたがってパイプライン的に実行する。
【００２９】
なお、図７に示したプログラムモジュール１００は、本実施形態の計算機システムを組み込んだ機器内のフラッシュＲＯＭやハードディスクに予め記録しておいてもよいが、ネットワークを介して流通させるようにしてもよい。この場合、本実施形態の計算機システムによって実行される処理の内容は、ネットワークを介してダウンロードしたプログラムモジュールの種類に応じて決まる。よって、例えば本実施形態の計算機システムを組み込んだ機器に、様々な専用ハードウェアそれぞれに対応するリアルタイム処理を実行させることが出来る。例えば、新しいコンテンツの再生に必要な新しいプレーヤーソフトウェアやデコーダソフトウェアや暗号ソフトウェアなどを、本実施形態の計算機システムで実行可能なプログラムモジュールとして、コンテンツと一緒に配布することで、本実施形態の計算機システムを搭載した機器であれば、いずれの機器でも、その能力が許す範囲内で、そのコンテンツを再生することができる。
【００３０】
（オペレーティングシステム）
本計算機システムでは、システム内にＯＳ（オペレーティングシステム）をひとつだけ実装する場合には、図１２に示すように、そのＯＳ２０１がすべての実資源（たとえば、ＭＰＵ１１、ＶＰＵ１２、メモリ１４、入出力制御装置１５、入出力装置１６など）を管理する。
一方、仮想計算機方式を用いて、複数のＯＳを同時に動作させることも可能である。この場合には、図１３に示すように、まず仮想計算機ＯＳ３０１を実装し、それがすべての実資源（たとえば、ＭＰＵ１１、ＶＰＵ１２、メモリ１４、入出力制御装置１５、入出力装置１６など）を管理する。仮想計算機ＯＳ３０１はホストＯＳと称されることもある。さらに仮想計算機ＯＳ３０１の上に、ひとつ以上のＯＳ（ゲストＯＳとも呼ぶ）を実装する。各ゲストＯＳ３０２，３０３は、図１４に示すように、仮想計算機ＯＳ３０１によって与えられる仮想的な計算機資源から構成される計算機上で動作し、ゲストＯＳ３０２，３０３の管理するアプリケーションプログラムに各種のサービスを提供する。図１４の例では、ゲストＯＳ３０２は、１つのＭＰＵ１１と、２つのＶＰＵ１２と、メモリ１４とから構成される計算機上で動いていると思っており、ゲストＯＳ３０３は１つのＭＰＵ１１と、４つのＶＰＵ１２と、メモリ１４とから構成される計算機上で動いていると思っている。ゲストＯＳ３０２からみたＶＰＵ１２や、ゲストＯＳ３０３からみたＶＰＵ１２が、実際には実資源のどのＶＰＵ１２に対応しているかは、仮想計算機ＯＳ３０１が管理している。ゲストＯＳ３０２，３０３は、その対応を意識する必要はない。
【００３１】
仮想計算機ＯＳ３０１は、計算機システム全体の資源を時分割で各ゲストＯＳ３０２，３０３に割り当てるように、ゲストＯＳ３０２，３０３のスケジューリングを行う。例えば、ゲストＯＳＯＳ３０２がリアルタイム処理を行うものであるとする。たとえば１秒間に３０回、正しいペースで処理を行いたい場合には、各ゲストＯＳ３０２はそのパラメタを仮想計算機ＯＳ３０１に設定する。仮想計算機ＯＳ３０１は、１／３０秒に１回、確実にそのゲストＯＳ３０１に必要なだけの処理時間が割り当てられるようにスケジューリングを行う。リアルタイム性を要求しない処理を行うゲストＯＳには、リアルタイム性を要求するゲストＯＳよりも低い優先度で、処理時間の割り当てを行うように、スケジューリングが行われる。図１５は、時間軸を横にとって、ゲストＯＳ３０２とゲストＯＳ３０３が切り替わりながら動いている様子を示している。ゲストＯＳ３０２が動いている間は、ＭＰＵ１１と全てのＶＰＵ１２がゲストＯＳ３０２の資源として使用され、ゲストＯＳ３０３が動いている間は、ＭＰＵ１１と全てのＶＰＵ１２がゲストＯＳ３０３の資源として使用される。
【００３２】
図１６は別の動作モードを示している。ターゲットアプリケーションによってはＶＰＵ１２をずっと占有して利用したい場合がある。たとえば、常にデータやイベントを監視し続けることが必要なアプリケーションがこれに相当する。このようなときには、特定のＶＰＵ１２を特定のゲストＯＳによって占有するように、仮想計算機３０１のスケジューラがスケジュール管理する。図１６では、ＶＰＵ４をゲストＯＳ３０１の専用資源に指定した場合の例である。仮想計算機ＯＳ３０１がゲストＯＳ３０２（ＯＳ１）とゲストＯＳ３０３（ＯＳ２）を切り替えても、ＶＰＵ４は常にゲストＯＳ３０１（ＯＳ１）の管理下で動作し続ける。
【００３３】
さて、複数のＶＰＵ１２を用いてプログラムを動作させるために、本実施形態では、複数のＶＰＵ１２それぞれに割り当てるスレッドをスケジューリングするためのスケジューラを含む、ＶＰＵ実行環境と呼ぶソフトウェアモジュールを用いる。本計算機システムにＯＳがひとつしか搭載されていない場合は、図１７に示すようにそのＯＳ２０１にＶＰＵ実行環境４０１を実装する。この時、ＶＰＵ実行環境４０１は、ＯＳ２０１のカーネル内に実装することもできるし、ユーザプログラムレベルで実装することもできるし、両者に分割して協調して動作するように実装することも出来る。一方、仮想計算機ＯＳ上でひとつあるいは複数のＯＳを動作させる場合、ＶＰＵ実行環境４０１を実装する方式には、次のような方式がある。
１．仮想計算機ＯＳ３０１の中にＶＰＵ実行環境４０１を実装する方式（図１８）
２．ＶＰＵ実行環境４０１を仮想計算機ＯＳ３０１が管理するひとつのＯＳとして実装する方式（図１９）。図１９では、仮想計算機ＯＳ３０１上で動作するゲストＯＳ３０４自体がＶＰＵ実行環境４０１である。
３．仮想計算機ＯＳ３０１が管理する各ゲストＯＳに、それぞれ専用のＶＰＵ実行環境４０１を実装する方式（図２０）。図２０においては、ゲストＯＳ３０２，３０３にそれぞれＶＰＵ実行環境４０１，４０２が実装されている。ＶＰＵ実行環境４０１，４０２は、仮想計算機ＯＳ３０１の提供するゲストＯＳ間の通信機能を用いて、必要に応じて、互いに連携して動作する。
４．仮想計算機ＯＳ３０１が管理するゲストＯＳのうちのひとつにＶＰＵ実行環境４０１を実装して、ＶＰＵ実行環境を持たないゲストＯＳは、仮想計算機ＯＳ３０１の提供するゲストＯＳ間の通信機能を用いて、ＶＰＵ実行環境４０１を持つゲストＯＳのＶＰＵ実行環境４０１を利用する方式（図２１）。
【００３４】
これらの方式のメリットは以下のとおりである。
方式１のメリット
・仮想計算機ＯＳの持つゲストＯＳ（仮想計算機ＯＳが管理する対象のＯＳ）のスケジューリングと、ＶＰＵ１２のスケジューリングを一体化できるので、効率良く、きめ細かなスケジューリングができ、資源を有効利用できる。
・複数のゲストＯＳ間でＶＰＵ実行環境を共有できるので、新しいゲストＯＳを導入する場合に新しくＶＰＵ実行環境を作らなくてもよい。
方式２のメリット
・仮想計算機ＯＳの上にあるゲストＯＳ間でＶＰＵ１２のスケジューラを共有できるので、効率良く、きめ細かなスケジューリングができ、資源を有効利用できる。
・複数のゲストＯＳ間でＶＰＵ実行環境を共有できるので、新しいゲストを導入する場合に新しくＶＰＵ実行環境を作らなくてもよい。
・ＶＰＵ実行環境を仮想計算機ＯＳや特定のゲストＯＳに依存せずに作れるので、標準化がしやすく、取り替えて使うことも出来る。特定の組み込み機器に適応したＶＰＵ実行環境を作って、その機器の特性を活かしたスケジューリング等を行うことで、効率良い実行ができる。
方式３のメリット
・各ゲストＯＳに対してＶＰＵ実行環境を最適に実装できるので、効率良く、きめ細かなスケジューリングができ、資源を有効利用できる。
【００３５】
方式４のメリット
・すべてのゲストＯＳがＶＰＵ実行環境を実装する必要がないので、新しいゲストＯＳを追加しやすい。
このように、いずれの方式でもＶＰＵ実行環境を実装することができる。また、このほかにも適宜実施可能である。
【００３６】
（サービスプロバイダ）
本実施形態の計算機システムにおいては、ＶＰＵ実行環境４０１は、各ＶＰＵ１２に関連する各種資源（各ＶＰＵの処理時間、メモリ、接続装置のバンド幅、など）の管理とスケジューリング機能の他に、さまざまなサービス（ネットワークを使った通信機能、ファイルの入出力機能、コーデックなどのライブラリ機能の呼び出し、ユーザとのインタフェース処理、入出力デバイスを使った入出力処理、日付や時間の読み出し、など）を提供する。これらのサービスは、ＶＰＵ１２上で動作するアプリケーションプログラムから呼び出されて、簡単なサービスの場合にはそのＶＰＵ１２上のサービスプログラムで処理される。しかし通信やファイルの処理などＶＰＵ１２だけでは処理できないサービスに関しては、ＭＰＵ１１上のサービスプログラムによって処理する。このようなサービスを提供するプログラムを、サービスプロバイダ（ＳＰ）と呼ぶ。
【００３７】
図２２にＶＰＵ実行環境のひとつの実施例を示す。ＶＰＵ実行環境の主要部分はＭＰＵ１１上に存在する。これが、ＭＰＵ側ＶＰＵ実行環境５０１である。各ＶＰＵ１２上には、そのＶＰＵ１２内で処理可能なサービスを実行する最小限の機能のみを持つＶＰＵ側ＶＰＵ実行環境５０２が存在する。ＭＰＵ側ＶＰＵ実行環境５０１の機能は、大きく、ＶＰＵコントロール５１１と、サービスブローカ５１２の２つに分けられる。ＶＰＵコントロール５１２は、主に、各ＶＰＵ１２に関連する各種資源（ＶＰＵの処理時間、メモリ、仮想空間、接続装置のバンド幅、など）の管理機構や、同期機構や、セキュリティの管理機構や、スケジューリング機能を提供する。スケジューリング結果に基づいてＶＰＵ１２上のプログラムのディスパッチを行うのは、このＶＰＵコントロール５１１である。サービスブローカ５１２は、ＶＰＵ１２上のアプリケーションが呼び出したサービス要求を受けて、適当なサービスプログラム（サービスプロバイダ）を呼び出してそのサービスを提供する。
ＶＰＵ側ＶＰＵ実行環境５０２は、主に、ＶＰＵ１２上のアプリケーションプログラムが呼び出したサービス要求を受けて、ＶＰＵ１２内で処理できるものは処理し、そうでないものはＭＰＵ側ＶＰＵ実行環境５０１のサービスブローカ５１２に処理を依頼する働きをする。
【００３８】
図２３に、ＶＰＵ側ＶＰＵ実行環境５０２がサービス要求を処理する手順を示す。ＶＰＵ側ＶＰＵ実行環境５０２はアプリケーションプログラムからのサービス呼び出しを受け取ると（ステップＳ１０１）、ＶＰＵ実行環境５０２内で処理できるサービスであるかどうかを判別し（ステップＳ１０２）、それであれば、対応するサービスを実行して、結果を呼び出し元へ返す（ステップＳ１０３，Ｓ１０７）。一方、ＶＰＵ実行環境５０２内で処理できるサービスではないならば、該当するサービスを実行可能なサービスプログラムがＶＰＵ１２上で実行可能なプログラムとして登録されているかどうかを判断する（ステップＳ１０４）。登録されているならば、当該サービスプログラムを実行し、結果を呼び出し元へ返す（ステップＳ１０５，Ｓ１０７）。登録されていないならば、サービスブローカ５１２に処理を依頼し、そしてサービスブローカ５１２から返されるサービスの結果を呼び出し元へ返す（ステップＳ１０６，Ｓ１０７）。
【００３９】
図２４に、ＭＰＵ側ＶＰＵ実行環境５０１のサービスブローカ５１２が、ＶＰＵ側ＶＰＵ実行環境５０２から要求されたサービスを処理する手順を示す。サービスブローカ５１２はＶＰＵ側ＶＰＵ実行環境５０２からのサービス呼び出しを受け取ると（ステップＳ１１１）、ＶＰＵ実行環境５０１内で処理できるサービスであるかどうかを判別し（ステップＳ１１２）、それであれば、対応するサービスを実行して、結果を呼び出し元のＶＰＵ側ＶＰＵ実行環境５０２へ返す（ステップＳ１１３，Ｓ１１４）。一方、ＶＰＵ実行環境５０１内で処理できるサービスではないならば、該当するサービスを実行可能なサービスプログラムがＭＰＵ１１上で実行可能なプログラムとして登録されているかどうかを判断する（ステップＳ１１４）。登録されているならば、当該サービスプログラムを実行し、結果を呼び出し元のＶＰＵ側ＶＰＵ実行環境５０２へ返す（ステップＳ１１６，Ｓ１１４）。登録されていないならば、エラーを呼び出し元のＶＰＵ側ＶＰＵ実行環境５０２へ返す（ステップＳ１１７）。
【００４０】
なお、ＶＰＵ１２で実行するプログラムが発行するサービス要求には、サービスの実行結果のリプライを返すものもあれば、要求を出すだけでリプライの無いものもある。また、リプライ先は、通常は要求を出したスレッドであるが、リプライ先として他のスレッド、スレッドグループ、あるいはプロセスを指定することもできる。そのため、サービス要求のメッセージには、リプライ先の指定も含めることが好ましい。サービスブローカ５１２は、広く使われているオブジェクトリクエストブローカを用いて実現することができる。
【００４１】
（リアルタイム処理）
本実施形態の計算機システムはリアルタイム処理システムとして機能する。この場合、そのリアルタイム処理システムの対象とする処理は、大きく、
１．ハードリアルタイム処理
２．ソフトリアルタイム処理
３．ベストエフォート処理（ノンリアルタイム処理）
の３種類に分類できる。１と２がいわゆるリアルタイム処理と呼ばれるものである。本実施形態のリアルタイム処理システムは、多くの既存のＯＳと同様、スレッドとプロセスの概念を持っている。ここではまず、本実施形態のリアルタイム処理システムにおけるスレッドとプロセスに関して説明する。
【００４２】
スレッドには、次の３つのクラスがある。
１．ハードリアルタイムクラス
このスレッドクラスは、その時間要件（ｔｉｍｉｎｇ ｒｅｑｕｉｒｅｍｅｎｔｓ）は非常に重要で、その要件が満たされなかった際に重大な状況になるような、重要なアプリケーションに用いる。
２．ソフトリアルタイムクラス
このスレッドクラスは、例えその時間要件が満たされなかった場合においても、その品質が低下するだけのアプリケーションに用いる。
３．ベストエフォートクラス
このスレッドクラスは、その要件の中に一切の時間要件を含まないアプリケーションに用いる。
【００４３】
スレッドは本アルタイム処理システム内において処理を実行する実体である。スレッドには、そのスレッドが実行するプログラムが関連付けられている。各スレッドは、スレッドコンテクストと呼ぶ、それぞれのスレッドに固有の情報を保持している。スレッドコンテクストには、たとえば、プロセッサのレジスタの値や、スタックなどの情報が含まれている。
本リアルタイム処理システムにおいては、ＭＰＵスレッドとＶＰＵスレッドの２種類のスレッドが存在する。これら２つのスレッドは、そのスレッドが実行されるプロセッサ（ＭＰＵ１１かＶＰＵ１２）によって分類されており、スレッドとしてのモデルは全く同じである。ＶＰＵスレッドのスレッドコンテクストには、ＶＰＵ１２のローカルストレージ３２の内容や、メモリコントローラ３３の持つＤＭＡコントローラの状態なども含む。
【００４４】
複数のスレッドをグループとしてまとめたものを、スレッドグループと呼ぶ。スレッドグループは、グループに含まれるスレッドすべてに対して同じ属性を与える、などの処理を効率よく簡単にできるメリットがある。ハードリアルタイムクラスまたはソフトリアルタイムクラスのスレッドグループは、密結合スレッドグループ（ｔｉｇｈｔｌｙ ｃｏｕｐｌｅｄ ｔｈｒｅａｄ ｇｒｏｕｐ）と疎結合スレッドグループ（ｌｏｏｓｅｌｙ ｃｏｕｐｌｅｄ ｔｈｒｅａｄ ｇｒｏｕｐ）の２種類に大別される。密結合スレッドグループ（ｔｉｇｈｔｌｙ ｃｏｕｐｌｅｄ ｔｈｒｅａｄ ｇｒｏｕｐ）と疎結合スレッドグループ（ｌｏｏｓｅｌｙ ｃｏｕｐｌｅｄ ｔｈｒｅａｄ ｇｒｏｕｐ）はスレッドグループに付加された属性情報（結合属性情報）によって識別される。アプリケーションプログラム内のコードまたは上述の構成記述によってスレッドグループの結合属性を明示的に指定することができる。
密結合スレッドグループは互いに協調して動作する複数のスレッドの集合から構成されるスレッドグループである。すなわち、密結合スレッドグループは、そのグループに属するスレッド群が、お互いに密接に連携して動作することを示す。密接な連携とは、例えば，頻繁にスレッド間で通信あるいは同期処理などの相互作用（ｉｎｔｅｒａｃｔｉｏｎ）を行ったり、あるいは、レイテンシ（ｌａｔｅｎｃｙ）（遅延）の小さい相互作用を必要とする場合などである。一方、疎結合スレッドグループは、密結合スレッドグループに比べてそのグループに属するスレッド群間の密接な連携が不要であるスレッドグループであり、スレッド群はメモリ１４上のバッファを介してデータ受け渡しのための通信を行う。
【００４５】
（密結合スレッドグループ）
図２５に示すように、密結合スレッドグループに属するスレッド群にはそれぞれ別のＶＰＵが割り当てられ、各スレッドが同時に実行される。密結合スレッドグループに属するスレッドを、密結合スレッド（ｔｉｇｈｔｌｙ ｃｏｕｐｌｅｄ ｔｈｒｅａｄ）と呼ぶ。この場合、密結合スレッドグループに属する密結合スレッドそれぞれの実行期間がそれら密結合スレッドの個数と同数のＶＰＵそれぞれに対して予約され、それら密結合スレッドが同時に実行される。図２５においては、ある密結合スレッドグループにスレッドＡ，Ｂの２つが密結合スレッドとして含まれており、それらスレッドＡ，ＢがそれぞれＶＰＵ０，ＶＰＵ１によって同時に実行されている様子を示している。スレッドＡ，Ｂをそれぞれ別のＶＰＵによって同時に実行することを保証することにより、各スレッドは相手のスレッドが実行されているＶＰＵのローカルストレージや制御レジスタを通じて相手のスレッドとの通信を直接的に行うことが出来る。図２６は、スレッドＡ，Ｂがそれぞれ実行されるＶＰＵ０，ＶＰＵ１のローカルストレージを介してスレッドＡ，Ｂ間の通信が実行される様子を示している。この場合、スレッドＡが実行されるＶＰＵ０においては、そのスレッドＡのＥＡ空間の一部に、通信相手のスレッドＢが実行されるＶＰＵ１のローカルストレージ３２に対応するＲＡ空間がマッピングされる。このマッピングのためのアドレス変換は、ＶＰＵ０のメモリコントローラ３３内に設けられたアドレス変換ユニット３３１がセグメントテーブルおよびページテーブルを用いて実行する。スレッドＢが実行されるＶＰＵ１においては、そのスレッドＢのＥＡ空間の一部に、通信相手のスレッドＡが実行されるＶＰＵ０のローカルストレージ３２に対応するＲＡ空間がマッピングされる。このマッピングのためのアドレス変換は、ＶＰＵ１のメモリコントローラ３３内に設けられたアドレス変換ユニット３３１がセグメントテーブルおよびページテーブルを用いて実行する。図２７には、ＶＰＵ０上で実行されるスレッドＡが自身のＥＡ空間にスレッドＢが実行されるＶＰＵ１のローカルストレージ（ＬＳ１）３２をマッピングし、ＶＰＵ１上で実行されるスレッドＢが自身のＥＡ空間にスレッドＡが実行されるＶＰＵ０のローカルストレージ（ＬＳ０）３２をマッピングした様子が示されている。例えば、スレッドＡはスレッドＢに引き渡すべきデータがローカルストレージＬＳ０上に準備できた時点で、そのことを示すフラグをローカルストレージＬＳ０またはスレッドＢが実行されるＶＰＵ１のローカルストレージＬＳ１にセットする。スレッドＢはそのフラグのセットに応答して、ローカルストレージＬＳ０上のデータをリードする。
【００４６】
このように、結合属性情報によって密結合関係にあるスレッドを特定できるようにすると共に、結合関係にあるスレッドＡ，Ｂがそれぞれ別のＶＰＵによって同時に実行されることを保証することにより、スレッドＡ，Ｂ間の通信、同期に関するインタラクションをより軽量で且つ遅延無く行うことが可能となる。
【００４７】
（疎結合スレッドグループ）
疎結合スレッドグループに属するスレッド群それぞれの実行時間は、それらスレッド群間の入出力関係によって決定され、たとえ実行順序の制約がないスレッド同士であってもそれらが同時に実行されることは保証されない。疎結合スレッドグループ属するスレッドを、疎結合スレッド（ｌｏｏｓｅｌｙ ｃｏｕｐｌｅｄ ｔｈｒｅａｄ）と呼ぶ。図２８においては、ある疎結合スレッドグループにスレッドＣ，Ｄの２つが疎結合スレッドとして含まれており、それらスレッドＣ，ＤがそれぞれＶＰＵ０，ＶＰＵ１によって実行されている様子を示している。図２８に示すように、各スレッドの実行時間はばらばらになる。スレッドＣ，Ｄ間の通信は、図２９に示すように、メインメモリ１４上に用意したバッファを介して行われる。スレッドＣはローカルストレージＬＳ０に用意したデータをＤＭＡ転送によってメインメモリ１４上に用意したバッファに書き込み、スレッドＤはその開始時にＤＭＡ転送によってメインメモリ１４上のバッファからローカルストレージＬＳ１にデータを読み込む。
【００４８】
（プロセスとスレッド）
プロセスは，図３０に示すように、一つのアドレス空間と一つ以上のスレッドから構成される。一つのプロセスに含まれるスレッドの数と種類は，どのような組み合わせでも構わない。例えば，ＶＰＵスレッドのみから構成されるプロセスも構築可能であるし，ＶＰＵスレッドとＭＰＵスレッドが混在するプロセスも構築可能である。スレッドがスレッド固有の情報としてスレッドコンテクストを保持しているのと同様に，プロセスもプロセス固有の情報としてプロセスコンテクストを保持する。このプロセスコンテクストには，プロセスに固有であるアドレス空間と，プロセスが含んでいる全スレッドのスレッドコンテクストが含まれる。プロセスのアドレス空間は，プロセスに属するすべてのスレッド間で共有することができる。一つのプロセスは，複数のスレッドグループを含むことができる。しかし，一つのスレッドグループが複数のプロセスに属することはできない。このため，あるプロセスに属するスレッドグループは，そのプロセスに固有であるということになる。本実施形態のリアルタイム処理システムにおいて、スレッドを新しく生成する方式には、Ｔｈｒｅａｄ ｆｉｒｓｔ ｍｏｄｅｌとＡｄｄｒｅｓｓ ｓｐａｃｅ ｆｉｒｓｔ ｍｏｄｅｌの２種類がある。Ａｄｄｒｅｓｓ ｓｐａｃｅ ｆｉｒｓｔ ｍｏｄｅｌは既存のＯＳで採用されているのと同様の方式で、ＭＰＵスレッドにもＶＰＵスレッドにも適用できる。一方、Ｔｈｒｅａｄ ｆｉｒｓｔ ｍｏｄｅｌはＶＰＵスレッドにしか適用できない方式で、本発明のリアルタイム処理システムに特有の方式である。Ｔｈｒｅａｄ ｆｉｒｓｔ ｍｏｄｅｌでは，既存のスレッド（新しくスレッドを作りたいと思っている側のスレッド。新しく作るスレッドの親になるスレッドのこと。）は，まず新規スレッドが実行するプログラムを指定して，新規スレッドにプログラムの実行を開始させる。この時、プログラムはＶＰＵ１２のローカルストレージに格納され、所定の実行開始番地から処理が開始される。この時点では、この新規スレッドにはアドレス空間が関連付けられていないので、自身のローカルストレージはアクセスできるが、メモリ１４はアクセスできない。その後，新規スレッドは，必要に応じて自身でＶＰＵ実行環境のサービスを呼び出してアドレス空間を生成して関連付けたり、ＭＰＵ１１側の処理によってアドレス空間を関連付けられたりして、メモリ１４にアクセスできるようになる。Ａｄｄｒｅｓｓ ｓｐａｃｅ ｆｉｒｓｔ ｍｏｄｅｌでは，既存のスレッドは，新しくアドレス空間を生成するか、あるいは既存のアドレス空間を指定して、そのアドレス空間に新規スレッドが実行するプログラムを配置する。そして新規スレッドにそのプログラムの実行を開始させる。Ｔｈｒｅａｄ ｆｉｒｓｔ ｍｏｄｅｌのメリットは、ローカルストレージだけで動作するので、スレッドの生成やディスパッチや終了処理などのオーバーヘッドを小さくできることである。
【００４９】
（スレッド群のスケジューリング）
次に、図３１のフローチャートを参照して、ＶＰＵ実行環境４０１によって実行されるスケジューリング処理について説明する。ＶＰＵ実行環境４０１内のスケジューラは、スケジュール対象のスレッド群にスレッドグループ単位で付加されている結合属性情報に基づいて、スレッド間の結合属性をチェックし（ステップＳ１２１）、各スレッドグループ毎にそのスレッドグループが密結合スレッドグループおよび疎結合スレッドグループのいずれであるかを判別する（ステップＳ１２２）。結合属性のチェックは、プログラムコード中のスレッドに関する記述あるいは上述の構成記述１１７中のスレッドパラメータを参照することによって行われる。このようにして、密結合スレッドグループおよび疎結合スレッドグループをそれぞれ特定することにより、スケジュール対象のスレッド群は密結合スレッドグループと疎結合スレッドグループとに分離される。
【００５０】
密結合スレッドグループに属するスレッド群に対するスケジューリングは次のように行われる。すなわち、ＶＰＵ実行環境４０１内のスケジューラは、スケジュール対象のスレッド群から選択された密結合スレッドグループに属するスレッド群がそれぞれ別のＶＰＵによって同時に実行されるように、その密結合スレッドグループに属するスレッド群と同数のＶＰＵそれぞれの実行期間を予約し、スレッド群をそれら予約したＶＰＵそれぞれに同時にディスパッチする（ステップＳ１２３）。そして、スケジューラは、各スレッドが実行されるＶＰＵ内のアドレス変換ユニット３３１を用いて、各スレッドのＥＡ空間の一部に、協調して相互作用を行う相手となる他のスレッドが実行されるＶＰＵのローカルストレージに対応するＲＡ空間をマッピングする（ステップＳ１２４）。一方、スケジュール対象のスレッド群から選択された疎結合スレッドグループに属する疎結合スレッド群については、スケジューラは、それらスレッド群間の入出力関係に基づいてそれらスレッド群を１以上のＶＰＵに順次ディスパッチする（ステップＳ１２５）。
【００５１】
（ローカルストレージのマッピング）
本実施形態のリアルタイム処理システムにおいて、ＭＰＵスレッドとＶＰＵスレッドの間、あるいはＶＰＵスレッドと他のＶＰＵスレッドの間で、何らかの通信や同期を行いながら協調して動作を行う場合には、協調相手のＶＰＵスレッドのローカルストレージにアクセスする必要がある。たとえば、より軽量で高速な同期機構は、ローカルストレージ上に同期変数を割り付けて実装する。そのため、あるＶＰＵ１２のローカルストレージを、他のＶＰＵ１２あるいはＭＰＵ１１のスレッドが直接アクセスする必要がある。図４に示す例のように、各ＶＰＵ１２のローカルストレージが実アドレス空間に割り付けられている場合、セグメントテーブルやページテーブルを適切に設定すれば、相手のＶＰＵ１２のローカルストレージを直接アクセスすることができる。しかしこの場合に、大きく２つの問題が生じる。
【００５２】
第１の問題は、ＶＰＵスレッドのディスパッチ先ＶＰＵ１２の変更に関する問題である。図３２のように，ＶＰＵスレッドＡとＢが存在し，それぞれＶＰＵ０とＶＰＵ１で動いているとする。そして，このスレッドＡとＢはお互いのスレッドと協調したいので，お互いのスレッドのＬＳ（ローカルストレージ）を，自分のＥＡ空間にマッピングしているとする。また，ＶＰＵ０，１，２のＬＳ０，１，２はそれぞれ図３２のようにＲＡ空間に存在するとする。この時，ＶＰＵスレッドＡが，自分のＥＡ空間にマッピングしているのは，ＶＰＵスレッドＢが動いているＶＰＵのＬＳ，つまり，ＶＰＵ１のＬＳであるＬＳ１である。逆に，ＶＰＵスレッドＢが，自分のＥＡ空間にマッピングしているのは，ＶＰＵスレッドＡが動いているＶＰＵのＬＳ，つまり，ＶＰＵ０のＬＳであるＬＳ０である。その後，ＶＰＵ実行環境の中のスケジューラによって、ＶＰＵスレッドＡを実行するＶＰＵがディスパッチされて，ＶＰＵスレッドＡは，ＶＰＵ２で動くことになったとする。この時、もはやＶＰＵスレッドＡはＶＰＵ０では動いていないので，ＶＰＵスレッドＢが，自分のＥＡ空間にマッピングしているＶＰＵ０のＬＳは，意味がなくなる。この場合，スレッドＢが，スレッドＡのディスパッチ先ＶＰＵが変更になったことを知らなくてもいいように，システムは何らかの方法でＬＳ０にマッピングされていたＥＡ空間のアドレスをＬＳ２にマッピングして、スレッドＢから、スレッドＡのローカルストレージとしてＶＰＵ２のＬＳであるＬＳ２が見えるようにする必要がある。
【００５３】
第２の問題は、物理ＶＰＵと論理ＶＰＵの対応関係の問題である。ＶＰＵをＶＰＵスレッドに割り当てるまでには，実際には，２つのレベルがある。一つは論理ＶＰＵのＶＰＵスレッドへの割り当てであり，もう一つが物理ＶＰＵの論理ＶＰＵへの割り当てである。物理ＶＰＵとは，仮想計算機ＯＳ３０１が管理している物理的なＶＰＵ１２である。そして，論理ＶＰＵとは，仮想計算機ＯＳ３０１がゲストＯＳ割り当てた、論理的なＶＰＵのことである。この関係は図１４にも示している。たとえば、ＶＰＵ実行環境４０１が論理的なＶＰＵを管理する場合、図３２の例で、ＶＰＵスレッドの割り当て対象となるＶＰＵは論理ＶＰＵである。
【００５４】
図３３は，この２つのレベルの割り当ての概念を示している。直前に説明した第１の問題は，図３３の上の段に位置する，ＶＰＵスレッドの論理ＶＰＵへの割り当て問題に相当する。第２の問題である物理ＶＰＵの論理ＶＰＵへの割り当て問題は，下の段に位置する割り当てに相当する。図３３では，４つの物理ＶＰＵから，３つのＶＰＵを選択し，３つの論理ＶＰＵに割り当てていることを示している。もし，この物理ＶＰＵと論理ＶＰＵの対応関係が変わった場合，ＶＰＵスレッドの論理ＶＰＵへの割り当てが変更になっていなくても，適切な設定の変更が必要となる。例えば，変更後の論理ＶＰＵのＬＳに対するアクセスが，正しい物理ＶＰＵのＬＳを指すように，ＬＳに対応するページテーブルエントリを入れ換える，などである。
【００５５】
ある時刻に，図３４のように，物理ＶＰＵ１，２，３が論理ＶＰＵ０，１，２にそれぞれ割り当てられているとする。そして，論理ＶＰＵ１はＶＰＵスレッドＡに，そして論理ＶＰＵ２はＶＰＵスレッドＢに割り当てられていたとする。そして，ＶＰＵスレッドＡとＢは，それぞれ，お互いに，相手の動作している物理ＶＰＵのＬＳを自分のＥＡ空間にマッピングしているとする。ＶＰＵスレッドＡのＥＡ空間にはＶＰＵスレッドＢが実行されている物理ＶＰＵ３のＬＳ３が，そしてＶＰＵスレッドＢのＥＡ空間にはＶＰＵスレッドＡが実行されている物理ＶＰＵ２のＬＳ２がマッピングされている。その後，ある時刻に，仮想計算機ＯＳ３０１によって、論理ＶＰＵ０，１が物理ＶＰＵ０，１に，再割り当てされたとする。すると，今までＶＰＵスレッドＡが動作していた論理ＶＰＵ１は，物理ＶＰＵ２から物理ＶＰＵ１へと変化する。論理ＶＰＵのＶＰＵスレッドへの割り当ては変化していないが，物理ＶＰＵと論理ＶＰＵの対応関係が変化したことになる。このため，ＶＰＵスレッドＢがＥＡ空間にマッピングしている，ＶＰＵスレッドＡの動作しているＶＰＵのＬＳを，ＬＳ２からＬＳ１に変更し，正しくアクセスできるようにする必要がある。
【００５６】
これらの２つの問題を解決するために、本実施形態のリアルタイム処理システムでは、スレッドから見たＥＡ空間の固定アドレスに、必ず相手のスレッドを実行しているＶＰＵのローカルストレージがマップされて見えるように仮想記憶機構を制御する。すなわち、ＶＰＵスケジューラによる論理ＶＰＵのディスパッチ時、および仮想計算機ＯＳ等による物理ＶＰＵと論理ＶＰＵの対応関係の切り替え時に、適宜ページテーブルやセグメントテーブルを書き換えることで、ＶＰＵ上で動作しているスレッドからは、いつも同じ番地に相手のスレッドを実行しているＶＰＵのローカルストレージが見えるようにする。
【００５７】
まず、２つのスレッドのＥＡ空間の関係について説明する、２つのスレッドのＥＡ空間は、次の３つのいずれかのパターンで共有あるいは非共有になっている。
１．共有ＥＡ型： ２つのスレッド１，２がセグメントテーブルもページテーブルも共有している（図３５）
２．共有ＶＡ型： ２つのスレッド１，２は、ページテーブルは共有するが、セグメントテーブルは共有せず、それぞれが持っている（図３６）
３．非共有型： ２つのスレッド１，２はページテーブルもセグメントテーブルも共有せず、それぞれが持っている（図３７）
以下、１の共有ＥＡ型を例に、ＶＰＵのローカルストレージをどのようにマップするように制御するかについて説明する。
まず、図３８に示すように、ＶＡ空間上に各論理ＶＰＵに対応した領域を設け、そこに、その論理ＶＰＵが対応付けられている物理ＶＰＵのローカルストレージがマップされるように、ページテーブルを設定する。この例の場合、物理ＶＰＵ０，１，２がそれぞれ論理ＶＰＵ０，１，２に対応付けられている状態を示している。次に、スレッドＡからはスレッドＢを実行しているＶＰＵのローカルストレージが、固定アドレスであるセグメントａの領域に見えるように、セグメントテーブルを設定する。また、スレッドＢからはスレッドＡを実行している論理ＶＰＵのローカルストレージが、固定アドレスであるセグメントｂに見えるように、セグメントテーブルを設定する。この例では、スレッドＡは論理ＶＰＵ２で、スレッドＢは論理ＶＰＵ１で実行している状況を示している。ここで、ＶＰＵ実行環境４０１のスケジューラが、スレッドＢを論理ＶＰＵ０にディスパッチしたとする。この時、ＶＰＵ実行環境４０１は、図３９に示すように、スレッドＡからは固定アドレスであるセグメントａを通して、スレッドＢを現在実行している論理ＶＰＵ０のローカルストレージを見えるように、ＶＰＵ実行環境４０１はセグメントテーブルを自動的に書き換える。
さらにここで、たとえば仮想計算機ＯＳ３０１がゲストＯＳのディスパッチをしたため、物理ＶＰＵと論理ＶＰＵの対応が変化したとする。このとき、たとえば図４０に示すように、ＶＰＵ実行環境４０１は、ページテーブルを書き換えて、ＶＡ空間上に固定されている論理ＶＰＵのローカルストレージの領域が、正しい物理ＶＰＵのローカルストレージの領域を指すようにする。図４０の例では、物理ＶＰＵ１，２，３が論理ＶＰＵ０，１，２に対応するように変更されたため、ページテーブルを書き換えて、現在の正しいマッピングになるようにしている。
【００５８】
このように、ＶＰＵ実行環境４０１のスケジューラのディスパッチによって、スレッドを実行する論理ＶＰＵが変更になった場合には、ＥＡ空間からＶＡ空間へのマッピングを行っているセグメントテーブルを書き換えて、第１の問題を解決している。また、仮想計算機ＯＳ３０１などによって、物理ＶＰＵと論理ＶＰＵの対応が変更になった場合は、ＶＡ空間からＲＡ空間へのマッピングを行っているページテーブルを書き換えて、第２の問題を解決している。
このようして、相互作用を行う相手のスレッドが実行されるプロセッサに応じて、実効アドレス空間にマッピングされる、相手のスレッドに対応するプロセッサのローカルメモリが自動的に変更することにより、各スレッドは相手のスレッドがディスパッチされるプロセッサを意識することなく、相手のスレッドとの相互作用を効率よく行うことが出来る。よって、複数のスレッドを効率よく並列に実行することが可能となる。
【００５９】
以上、共有ＥＡ型の場合の例を説明したが、２の共有ＶＡ型、３の非共有型についても、セグメントテーブルまたはページテーブルを書き換えることにより、同様にして第１の問題および第２の問題を解決することができる。
【００６０】
上記の第１および第２の問題を解決する別の方法について述べる。ここでも、共有ＥＡ型の場合を例に説明する。図４１に示すように、協調して動作する複数のＶＰＵスレッドがある場合、それらのスレッドを実行するＶＰＵのローカルストレージを、セグメント上に連続してマップするように、ページテーブルとセグメントテーブルを設定する。図４１の例の場合、スレッドＡは物理ＶＰＵ２で、スレッドＢは物理ＶＰＵ０で実行されており、それぞれのＶＰＵのローカルストレージが同一のセグメントに連続して配置されるように、ページテーブルとセグメントテーブルを設定している。ここで、ＶＰＵ実行環境４０１のスケジューラによってスレッドを実行する論理ＶＰＵがディスパッチされたり、仮想計算機ＯＳ３０１等によって物理ＶＰＵと論理ＶＰＵの対応が変更になった場合には、それぞれの変更がスレッドＡおよびスレッドＢに対して隠蔽されるように、ページテーブルを書き換えて、ＶＡ空間とＲＡ空間のマップを変更する。たとえば図４２は、スレッドＡを実行しているＶＰＵが物理ＶＰＵ１に、スレッドＢを実行しているＶＰＵが物理ＶＰＵ３に変更になった場合のマッピングを示している。この変更が行われても、スレッドＡおよびスレッドＢからは、固定したアドレスを持つセグメント内の、所定の領域をアクセスすることで、常に相手のスレッドを実行しているＶＰＵのローカルストレージをアクセスすることができる。
【００６１】
次に、図４３のフローチャートを参照して、ＶＰＵ実行環境４０１によって実行されるアドレス管理処理の手順について説明する。ＶＰＵ実行環境４０１は、各スレッドのＥＡ空間上の固定アドレスに、相手スレッドを実行しているＶＰＵのローカルストレージに対応するＲＡ空間をマッピングする（ステップＳ２０１）。この後、ＶＰＵ実行環境４０１は、相手スレッドのディスパッチ先ＶＰＵの変更あるいは論理ＶＰＵと物理ＶＰＵの対応関係の変更に起因して、相手スレッドが実行されるＶＰＵが変更されたかどうかを判別する（ステップＳ２０２）。相手スレッドが実行されるＶＰＵが変更されたならば、ＶＰＵ実行環境４０１は、セグメントテーブルまたはページテーブルの内容を書き換えて、各スレッドのＥＡ空間上の固定アドレスにマッピングされているローカルストレージを、相手スレッドが実行されるＶＰＵに合わせて変更する（ステップＳ２０３）。
【００６２】
これまでの例では、蜜結合スレッドグループのように、互いにＶＰＵによって実行中のスレッド間で、相手のスレッドを実行しているＶＰＵのローカルストレージをアクセスする方式を説明した。しかし、疎結合スレッドグループなど、協調して動作するスレッドが必ずしも同時にＶＰＵに割り当てられて実行していない場合も存在する。そのような場合でも、ＥＡ空間上には相手のスレッドを実行しているＶＰＵ１２のローカルストレージをマップする領域は存在するので、その領域を以下のように用いて対処する。
【００６３】
第１の方法： 相手のスレッドが実行中で無い場合には、そのスレッドに対応するＶＰＵのローカルストレージをマップする領域にアクセスすると、スレッドは相手のスレッドが実行開始するまで待たされるようにする。
第２の方法： 相手のスレッドが実行中で無い場合には、そのスレッドに対応するＶＰＵのローカルストレージをマップする領域にアクセスすると、スレッドは例外発生やエラーコードによって、その旨を知る。
【００６４】
第３の方法： スレッドの終了時に、そのスレッドを最後に実行していたときのローカルストレージの内容をメモリに保存しておき、そのスレッドに対応付けられたローカルストレージを指すページテーブルあるいはセグメントテーブルのエントリからは、そのメモリ領域を指すようにマッピングを制御する。この方式により、相手のスレッドが実行中でなくても、相手のスレッドに対応付けられたローカルストレージがあたかもあるように、スレッドの実行を続けることができる。図４４および図４５に具体例を示す。
▲１▼： いま、スレッドＡ，ＢがそれぞれＶＰＵ０，１で実行されており、スレッドＢのＥＡ空間には相手のスレッドＡが実行されているＶＰＵ０のローカルストレージＬＳ０がマッピングされているとする。
▲２▼： スレッドＡの終了時には、スレッドＡまたはＶＰＵ実行環境４０１は、スレッドＡが実行されているＶＰＵ０のローカルストレージＬＳ０の内容をメモリ１４に保存する（ステップＳ２１１）。
▲３▼： ＶＰＵ実行環境４０１は、スレッドＢのＥＡ空間にマッピングされている相手先スレッドＡのローカルストレージのアドレス空間を、ＶＰＵ０のＬＳ０から、ＬＳ０の内容が保存されたメモリ１４上のメモリ領域に変更する（ステップＳ２１２）。これにより、スレッドＢは、相手のスレッドＡが実行中でなくなった後も、その動作を継続することができる。
▲４▼： スレッドＡに再びＶＰＵが割り当てられたとき、ＶＰＵ実行環境４０１は、メモリ１４上のメモリ領域をスレッドＡが実行されるＶＰＵのローカルストレージに戻す（ステップＳ２１３）。たとえばスレッドＡに再びＶＰＵ０が割り当てられたときは、メモリ１４上のメモリ領域の内容は、ＶＰＵ０のローカルストレージＬＳ０に戻される。
▲５▼： ＶＰＵ実行環境４０１は、スレッドＢのＥＡ空間にマッピングされている相手先スレッドＡのローカルストレージのアドレス空間を、スレッドＡが実行されるＶＰＵのローカルストレージに変更する（ステップＳ２１４）。たとえばスレッドＡに再びＶＰＵ０が割り当てられたときは、スレッドＢのＥＡ空間にマッピングされている相手先スレッドＡのローカルストレージのアドレス空間は、ＶＰＵ０のローカルストレージＬＳ０に戻される。
【００６５】
なお、スレッドＡにＶＰＵ２が割り当てられたときは、メモリ１４上のメモリ領域の内容は、ＶＰＵ２のローカルストレージＬＳ２に復元される。そして、スレッドＢのＥＡ空間にマッピングされている相手先スレッドＡのローカルストレージのアドレス空間は、ＶＰＵ２のローカルストレージＬＳ２に変更される。
【００６６】
（スレッドの状態遷移）
一般にスレッドは、生成されてから消滅するまで、たとえば図４６に示すような状態遷移を行う。図４６の例では、以下の７種類の状態を遷移する。
１．ＮＯＴ ＥＸＩＳＴＥＮＴ状態
論理的な状態であり，有効なスレッドでは，この状態はない。
２．ＤＯＲＭＡＮＴ状態
スレッドは生成されているが，まだ実行は開始されていない。
３．ＲＥＡＤＹ状態
スレッドが，その実行を開始する準備ができている状態。
４．ＷＡＩＴＩＮＧ状態
スレッドが，実行を開始（再開）するための条件が満たされることを待っている状態。
５．ＲＵＮＮＩＮＧ状態
スレッドが，実際にＶＰＵまたはＭＰＵ上で実行されている状態。
６．ＳＵＳＰＥＮＤＥＤ状態
ＶＰＵ実行環境や他のスレッドにより，スレッドが強制的にその実行を中断させられている状態。
７．ＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態
ＷＡＩＴＩＮＧ状態とＳＵＳＰＥＮＤＥＤ状態が重なった状態。
【００６７】
これらの７つの状態の間の遷移条件と、その遷移に伴うスレッドコンテクストの扱いは、以下のようになる。
＜ＮＯＴ ＥＸＩＳＴＥＮＴ状態からＤＯＲＭＡＮＴ状態への遷移＞
・スレッドの作成によって遷移する。
・スレッドコンテクストが作成される。ただしコンテクストの中身は初期状態である。
＜ＤＯＲＭＡＮＴ状態からＮＯＴ ＥＸＩＳＴＥＮＴ状態への遷移＞
・スレッドの削除によって遷移する。
・スレッドが，そのスレッドコンテクストを保存するように設定されていた場合，この遷移によって，保存されていたコンテクストは破棄される。
＜ＤＯＲＭＡＮＴ状態からＷＡＩＴＩＮＧ状態への遷移＞
・スレッドが，実行環境に対してスレッドのスケジューリングをリクエストすると，スレッドの状態は，ＤＯＲＭＡＮＴ状態からＷＡＩＴＩＮＧ状態へ遷移する。
＜ＷＡＩＴＩＮＧ状態からＲＥＡＤＹ状態への遷移＞
・スレッドが，生起するのを待っていたイベント（例えば，同期や通信，タイマなど）が，生起した場合に，スレッドの状態はＷＡＩＴＩＮＧ状態からＲＥＡＤＹ状態へ遷移する。
【００６８】
＜ＲＥＡＤＹ状態からＲＵＮＮＩＮＧ状態への遷移＞
・スレッドが，実行環境によってＭＰＵまたはＶＰＵにディスパッチされると，スレッドの状態は，ＲＥＡＤＹ状態からＲＵＮＮＩＮＧ状態へ遷移する。
【００６９】
・スレッドコンテクストがロードされる。また，スレッドコンテクストが退避されていた場合には，復元される。
＜ＲＵＮＮＩＮＧ状態からＲＥＡＤＹ状態への遷移＞
・スレッドが，スレッドの実行を横取りされると，スレッドの状態は，ＲＵＮＮＩＮＧ状態からＲＥＡＤＹ状態へ遷移する。
【００７０】
＜ＲＵＮＮＩＮＧ状態からＷＡＩＴＩＮＧ状態への遷移＞
・スレッドが，同期や通信などの機構を利用し，イベントを待つために自身の実行を中断した場合，スレッドの状態は，ＲＵＮＮＩＮＧ状態からＷＡＩＴＩＮＧ状態へ遷移する。
・すべてのクラスのスレッドは，スレッドコンテクストを保存するように設定することができる。スレッドが，スレッドコンテクストを保存するように設定されていた場合は，ＲＵＮＮＩＮＧ状態からＷＡＩＴＩＮＧ状態へ遷移する際に，実行環境によって，そのスレッドのスレッドコンテクストが退避される。このスレッドコンテクストは，ＤＯＲＭＡＮＴ状態に遷移しない限り保持され，次にこのスレッドがＲＵＮＮＩＮＧ状態に遷移した時に復元される。
＜ＲＵＮＮＩＮＧ状態からＳＵＳＰＥＮＤＥＤ状態への遷移＞
・スレッドが，実行環境や他のスレッドからの指示などによって，強制的にその実行を中断させられた場合，スレッドの状態は，ＲＵＮＮＩＮＧ状態からＳＵＳＰＥＮＤＥＤ状態へ遷移する。
・すべてのクラスのスレッドは，スレッドコンテクストを保存するように設定することができる。スレッドが，スレッドコンテクストを保存するように設定されていた場合は，ＲＵＮＮＩＮＧ状態からＳＵＳＰＥＮＤ状態へ遷移する際に，実行環境によって，スレッドコンテクストが退避される。このスレッドコンテクストは，ＤＯＲＭＡＮＴ状態に遷移しない限り，次にこのスレッドがＲＵＮＮＩＮＧ状態に遷移した時に復元される。
【００７１】
＜ＲＵＮＮＩＮＧ状態からＤＯＲＭＡＮＴ状態への遷移＞
・スレッドは，スレッド自身でその実行を終了した場合に，ＲＵＮＮＩＮＧ状態からＤＯＲＭＡＮＴ状態へ遷移する。
・スレッドが，そのスレッドコンテクストを保存するように設定されていた場合，この遷移によってコンテクストの内容が破棄される。
＜ＷＡＩＴＩＮＧ状態からＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態への遷移＞
・スレッドがＷＡＩＴＩＮＧ状態にてイベントなどの生起を待っている最中に，外部から強制的にスレッドの実行を中断された場合，スレッドの状態は，ＷＡＩＴＩＮＧ状態からＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態へ遷移する。
＜ＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態からＷＡＩＴＩＮＧ状態への遷移＞
・スレッドが，ＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態にいる最中に，外部からスレッドの実行を再開された場合，スレッドの状態はＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態からＷＡＩＴＩＮＧ状態へ遷移する。
【００７２】
＜ＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態からＳＵＳＰＥＮＤＥＤ状態への遷移＞
・スレッドは，スレッドがＷＡＩＴＩＮＧ状態にいた時に待っていたイベントが生起した場合に，スレッドの状態は，ＷＡＩＴＩＮＧ−ＳＵＳＰＥＮＤＥＤ状態からＳＵＳＰＥＮＤＥＤ状態へ遷移する。
【００７３】
＜ＳＵＳＰＥＮＤＥＤ状態からＲＥＡＤＹ状態への遷移＞
・スレッドが，外部からスレッドの実行を再開させられた時に，スレッドの状態は，ＳＵＳＰＥＮＤＥＤ状態からＲＥＡＤＹ状態へ遷移する。
【００７４】
＜ＲＥＡＤＹ状態からＳＵＳＰＥＮＤＥＤ状態への遷移＞
・スレッドが，外部環境によってスレッドの実行が中断させられた場合に，スレッドの状態は，ＲＥＡＤＹ状態からＳＵＳＰＥＮＤＥＤ状態へ遷移する。
【００７５】
（スレッドの実行期間）
スレッドに実際にＶＰＵが割り当てられて処理を実行しているＲＵＮＮＩＮＧ状態の期間を、実行期間（ｅｘｅｃｕｔｉｏｎ ｔｅｒｍ）と呼ぶ。一般にスレッドが生成されてから消滅するまでの間には、スレッドは複数の実行期間を持つ。図４７はあるスレッドの生成から消滅までの時間軸に沿った状態の変化の例を示しているが、この例では、その生存期間中に、２回の実行期間があることを示している。実行期間と実行期間との間のコンテクストの保存（ｓａｖｅ）や復元（ｒｅｓｔｏｒｅ）は、さまざまな方法を用いて実現することができる。たとえば、多くの通常のスレッドは、実行期間が終了した時点のコンテクストを保存しておいて、次の実行期間の初めにそのコンテクストを復元するように動作させる。一方、ある種の周期的な（ｐｅｒｉｏｄｉｃ）処理においては、全ての周期（ｐｅｒｉｏｄ）において、実行期間の開始時には新しいコンテクストを作成してその実行期間中はそのコンテクストを使って実行を進め、実行期間の終了時にはそのコンテクストは廃棄するように動作させる。
【００７６】
（蜜結合スレッドグループに属するスレッドの実行期間）
蜜結合スレッドグループに属するスレッドの場合の実行期間は、たとえば図４８のようになる。すなわち、蜜結合スレッドグループに属するすべてのスレッドは、ある一つの実行期間において、全てのスレッドが同時に実行されるように、ＶＰＵ実行環境４０１によってスケジューリングされる。このような蜜結合スレッドグループは、主としてハードリアルタイムスレッドに対して使用される。そのため、この動作を実現するために、ＶＰＵ実行環境４０１は、ハードリアルタイムクラスにおける実行期間を予約するときに、同時に使用するプロセッサとその数を指定する。さらに、ＶＰＵ実行環境４０１は、予約するそれぞれのプロセッサに対して、一対一に同時実行させるスレッドのコンテクストを対応させる。
【００７７】
なお、ある期間において蜜結合スレッドグループに属していた複数のスレッドは、他の実行期間においては、蜜結合の関係を解消して、各スレッドが別々に動作することもできる。このような場合には、各スレッドは、今、蜜結合スレッドとして動作しているのか、あるいは、別々に動作しているのかを意識して、相手のスレッドとの通信や同期等の処理を行う必要がある。各スレッドには、横取り可能（ｐｒｅｅｍｐｔｉｖｅ）か横取り不可（ｎｏｎ−ｐｒｅｅｍｐｔｉｖｅ）を示すプリエンプションに関連した属性が与えられる。Ｐｒｅｅｍｐｔｉｖｅとは、スレッドの実行期間中に、そのスレッドが横取りされることを許す、すなわち、実行を停止させることができるという属性である。Ｎｏｎ−ｐｒｅｅｍｐｔｉｖｅとは、スレッドの実行期間中に、そのスレッドが横取りされないことを保障するという属性である。この横取り不可（ｎｏｎ−ｐｒｅｅｍｐｔｉｖｅ）という属性の意味は、スレッドのクラス間で異なる。ハードリアルタイムクラスでは、スレッドが実行を開始すると、実行期間が終わるまで、そのスレッド自身以外、誰もその実行を止めることが出来ないことを意味する。ソフトリアルタイムクラスでは、そのクラスにとって、横取り可能性（ｐｒｅｅｍｐｔｉｖｅ−ｎｅｓｓ）は必要不可欠であるため、横取り不可の属性はサポートされない。ベストエフォートクラスでは、スレッドの実行は、他のベストエフォートクラスからの横取りからは保護ざれるものの、ハードリアルタイムやソフトリアルタイムクラスといったより高いレベルからは、横取りされる。
【００７８】
（スレッドの実行モデル）
スレッドの実行モデルは、大きく、図４９に示すような周期実行モデルと、図５０に示すような非周期実行モデルの２つに分類できる。周期実行モデルでは、スレッドは周期的（ｐｅｒｉｏｄｉｃａｌｌｙ）に実行される。その一方、非周期実行モデルでは、イベントを起点としてその実行が行われる。周期実行モデルの実装方式には、ソフトウェア割込みを用いる方式と、同期機構（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｐｒｉｍｉｔｉｖｅｓ）のようなイベントオブジェクトを用いる方式がある。ハードリアルタイムクラスでは、ソフトウェア割込みを用いて実装する。すなわち、ＶＰＵ実行環境４０１は、周期的な処理を開始するタイミングで、所定の方法で決定されるスレッドのエントリポイントへジャンプしたり、あるいは、事前に所定の手順で登録されたコールバック関数を呼び出す。ソフトリアルタイムクラスでは、イベントオブジェクトを用いて実装する。すなわち、各周期において、あらかじめ登録されたイベントオブジェクトに対して、たとえばＶＰＵ実行環境４０１がイベントを通知するので、ソフトリアルタイムスレッドは、毎周期そのイベントオブジェクトを待ち、イベントが発生したら所定の処理を実行するようにプログラムを構成することで、周期実行モデルを実現する。ベストエフォートクラスの場合は、ソフトウェア割込みを用いる方式を用いても、イベントオブジェクトを用いる方式を用いても、周期実行モデルを実装できる。なお、実際の実行は、それぞれの周期の先頭で常に開始されるとは限らず、制約条件（ｃｏｎｓｔｒａｉｎｔｓ）の範囲内で、状態に応じて遅らされることもある。
【００７９】
非周期実行モデルは、イベントモデルを用いると、周期実行モデルと同様に実現できる。すなわち、ソフトリアルタイムやベストエフォートクラスでは、非周期実行モデルは、イベントが通知されるタイミングが異なるだけで、実装手法上は周期実行モデルと同じになる。ハードリアルタイムクラスの場合は、時間要件を保障するために必要な、最小発生期間（ｍｉｎｉｍｕｍ ｉｎｔｅｒ−ａｒｒｉｖａｌ ｔｉｍｅ）やデットラインは、システムの振る舞いを強く制約するため、非周期実行は制限される。
【００８０】
（コンテクストの切り替え）
本実施形態のリアルタイム処理システムにおいては、ＶＰＵスレッドの実行期間の終了に伴うコンテクストの切り替え方式は、複数の方式から選択することができる。ＶＰＵのコンテクスト切り替えのコストは非常に大きいので、その方式を選択できるようにすることで、コンテクスト切り替えの効率を向上させることができる。指定したコンテクスト切り替え方式は、スレッドの予約された実行期間が終了した際に用いられるものである。実行期間中のコンテクスト切り替え、すなわち、いわゆるプリエンプションの際には、どの様な場合においても現在のスレッドの全てのコンテクストを保存して、次に実行再開するときに復元する必要がある。本実施形態のリアルタイム処理システムで提供するＶＰＵコンテクスト切り替えの方式には、たとえば、以下のような方式がある。
【００８１】
１．コンテクストの破棄
いかなるコンテクストも保存しない。
２．完全なコンテクストの保存
ＶＰＵのレジスタ、ローカルストレージ、およびメモリコントローラ内のＤＭＡコントローラの状態を含む、ＶＰＵの完全なコンテクストを保存する。
３．Ｇｒａｃｅｆｕｌコンテキスト保存
ＶＰＵのメモリコントローラ内のＤＭＡコントローラが実行中の全ての動作が完了するまでコンテクスト切り替えを遅延する。その後、ＶＰＵのレジスタとローカルストレージの内容を保存する。この方式では、完全なコンテクスト保存と同様、ＶＰＵのコンテクストの全てが保存される。
【００８２】
スレッドのスケジューリングを行うスケジューラは、ＭＰＵスレッドとＶＰＵスレッドの両方をスケジューリングするひとつのスケジューラとして実装することもできるし、ＭＰＵスレッド用のスケジューラとＶＰＵスレッド用のスケジューラを別に実装することもできる。ＭＰＵとＶＰＵではコンテクスト切り替えのコストが異なるため、別々にそれぞれに適したスケジューラを実装するほうが効率よくなる。
【００８３】
（ハードリアルタイムクラスのスケジューリング）
ハードリアルタイムクラスのスレッド群のスケジューリングは、タスクグラフを拡張した予約グラフを用いて行われる。図５１はタスクグラフの例である。タスクグラフは、タスク間の関係を表す。タスク間の矢印は、タスク間の依存関係（入出力関係）を示している。図５１の例では、タスク１とタスク２は、自由に実行を開始することが出来ることを表している。それに対し、タスク３は、タスク１とタスク２両方の実行終了後に始めて実行を開始することが出来ることを表している。また、タスク４とタスク５は、タスク３の実行終了後に実行を開始することが出来ることを表している。タスクグラフにはコンテクストの概念がない。例えば、タスク１とタスク４とを同じコンテクストを用いて実行したい場合に、それを記述することができない。そこで、本実施形態のリアルタイム処理システムでは、以下のようにしてタスクグラフを拡張した予約グラフを用いる。
【００８４】
まず、タスクグラフを、タスクではなく実行期間の間の関係を示すものととらえる。そして、それぞれの実行期間に、コンテクストを関係付けることで、そのコンテクストに対応するスレッドが、その実行期間に実行されることを示す。複数の実行期間に同じコンテクストが関係付けると、それら全ての実行期間において、そのスレッドが実行されることを示す。例えば、図５２では、スレッド１のコンテクストが実行期間１と２とに関係付けられており、スレッド１は、実行期間１と２の期間で実行されることを示す。さらに、グラフに用いられる実行期間の間の矢印に、実行環境にて保障されるハードリアルタイムの制約条件を表す属性を付加する。このようにして作成した予約グラフを用いて、リアルタイムシステムアプリケーションのモデルを一切修正することなく、処理モデルとその処理が持つ時間要件などの制約条件を記述することが可能になる。図５３に、図５２をベースに作成した予約グラフの例を示す。図５３でコンテクスト１，２，３は、それぞれ図５２のスレッド１，２，３のコンテクストを示している。
【００８５】
（ソフトリアルタイムクラスのスケジューリング）
ソフトリアルタイムクラスのスケジューリングは、スレッドの実行形態を予測可能とするために、固定優先度スケジューリングを用いて実行される。そのスケジューリング方式としては、固定優先度ＦＩＦＯスケジューリングと固定優先度ラウンドロビンスケジューリングの２種類のスケジューリングアルゴリズムを用意する。優先度の高いスレッドの実行を優先するため、低い優先度のスレッドが実行中であっても、より高い優先度のスレッドが実行可能になった場合には、低優先度のスレッドの実行をプリエンプトし、直ちに高優先度のスレッドの実行を開始する。クリティカルセクション（ｃｒｉｔｉｃａｌ ｓｅｃｔｉｏｎ）の実行時に発生する、優先度逆転問題を避けるため、優先度継承プロトコルや、優先度シーリングプロトコルなどの同期機構を併せて実施するのが望ましい。
【００８６】
（ベストエフォートクラスのスケジューリング）
ベストエフォートクラスのスケジューリングは、たとえば、動的優先度スケジューリングなどを用いる。
【００８７】
（階層型スケジューラ）
ＶＰＵ実行環境４０１内のスケジューリング機能は、図５４に示すような階層型のスケジューラとして実施することができる。すなわち、スレッドレベルのスケジューリングは、スレッドクラス間（ｉｎｔｅｒ−ｃｌａｓｓ）スケジューリングと、スレッドクラス内（ｉｎｔｒａ−ｃｌａｓｓ）スケジューリングの、２つの階層により構成する。そのため、ＶＰＵ実行環境４０１内のスケジューラは、スレッドクラス内（ｉｎｔｒａ−ｃｌａｓｓ）スケジューリング部６０１と、スレッドクラス間（ｉｎｔｅｒ−ｃｌａｓｓ）スケジューリング部６０２とを持つ。スレッドクラス間スケジューリングでは、スレッドクラス間を跨るスケジューリングを行う。スレッドクラス内スケジューリングでは、それぞれのスケジューリングクラスごとに、そのスケジューリングクラスに属するスレッドのスケジューリングを行う。スレッドクラス内（ｉｎｔｒａ−ｃｌａｓｓ）スケジューリング部６０１には、ハードリアルタイム（ハードＲＴ）クラススケジューリング部６１１、ソフトリアルタイム（ソフトＲＴ）クラスケジューリング部６１２、ベストエフォートクラスケジューリング部６１３が設けられている。
【００８８】
スレッドクラス間スケジューリングとスレッドクラス内スケジューリングは、階層構造をなしており、まず、スレッドクラス間スケジューリングが動作して、どのスレッドクラスを実行するか決定した後、該当するスレッドクラス内スケジューリングによって、そのスレッドクラス内のどのスレッドを実行するかを決定する。スレッドクラス間スケジューリングは、プリエンプト可能な固定優先度スケジューリングを用いる。このとき、ハードリアルタイムクラスが最高優先度を持ち、ソフトリアルタイムクラス、ベストエフォートクラスの順に優先度が低くなるようにする。低優先度クラスのスレッドは、より優先度の高いクラスのスレッドが実行可能（ｒｅａｄｙ）になると、その実行はプリエンプトされる。スレッドクラス間の同期は、ＶＰＵ実行環境４０１によって提供される同期プリミティブによって実現する。このとき特に、ハードリアルタイムスレッドにはブロックすることのないプリミティブのみ使用できるようにして、ハードリアルタイムスレッドのブロックが発生しないようにする。また、ベストエフォートスレッドがソフトリアルタイムスレッドをブロックした場合には、そのベストエフォートスレッドは、ソフトリアルタイムスレッドとして扱うことで、スレッドクラス間の優先度逆転の発生を防止するようにする。さらに、そのベストエフォートスレッドが、他のソフトリアルタイムスレッドによってブロックされるような場合には、優先度継承プロトコルなどの方式を用いてブロックされないようにする。
【００８９】
（スレッドパラメタ）
本実施形態のリアルタイム処理システムでは、さまざまなパラメタを用いてスケジューリングを行う。各クラスのスレッドに共通のパラメタには、たとえば以下のようなものがある。
・スレッドのクラス（ハードリアルタイム、ソフトリアルタイム、ベストエフォート）
・使用するリソース（ＭＰＵもしくはＶＰＵの数、バンド幅、物理メモリサイズ、入出力デバイス）
・優先度
・横取り可能（ｐｒｅｅｍｐｔｉｖｅ）か横取り不可（ｎｏｎ−ｐｒｅｅｍｐｔｉｖｅ）か
さらにハードリアルタイムクラスのスレッドに関しては、たとえば以下のようなパラメタがある。
【００９０】
・実行期間
・デッドライン
・周期あるいは最小発生期間（ｍｉｎｉｍｕｍ ｉｎｔｅｒ−ａｒｒｉｖａｌ ｔｉｍｅ）
・ＶＰＵのコンテクスト切り替え方式
図５５にハードリアルタイムクラスの基本的なパラメタの例を示す。図５７の一番上にある例１の実行期間の予約指定の例では、指定した実行期間の間、ＭＰＵを１つ、ＶＰＵを２つ同時に予約し、ＶＰＵのコンテクストを完全に保存することを指定している。この場合、３つのプロセッサ上で同時にスレッドが実行され、その実行期間終了後に、ＭＰＵスレッドに加え、ＶＰＵスレッドのコンテクストが完全に保存される。次に、右上にある例２では、ＶＰＵ数とその実行期間によって表現される処理が、デッドラインより以前に実行されることを保障する際の、デッドラインの指定方法を示している。デッドラインは、予約リクエストを行った時刻（ｒｅｑｕｅｓｔ ｔｉｍｅ）からの相対時刻で指定される。もっとも下にある例３では、周期実行を指定している。この例では、２つのＶＰＵ１２を指定した実行期間が、周期的に実行され、また、各周期の実行後にＶＰＵスレッドのコンテクストが破棄され、全ての処理が新しいコンテクストで処理されること示している。さらに、その周期の先頭からの相対時刻を用いてデッドラインを指定している。
【００９１】
ハードリアルタイムクラスで用いる別のパラメタとして、たとえば以下に示すような制約条件がある。
・タイミング制約（絶対タイミング制約、相対タイミング制約）
・先行制約
・相互排他制約
タイミング制約は、実行タイミングを遅らせる手段を提供する。絶対タイミング制約は、図５６に示すように、例えば周期の開始時刻のような、ある静的なタイミングを基準として遅延時間を指定する制約条件である。相対タイミング制約は、図５７に示すように、例えば他の実行期間の開始時刻や終了時刻のような、動的なタイミングやイベントを基準として許容可能な遅延時間を指定する制約条件である。先行制約は、相対タイミング制約を用いて、他の実行期間の終了時間を基準にし、その遅延時間を０以上と指定することで実現できるので、先行制約は相対タイミング制約の特殊な場合と考えることができる。
【００９２】
相互排他制約（ｍｕｔｕａｌ ｅｘｃｌｕｓｉｖｅ）は、図５８に示すように、それぞれの実行期間が、時間的に重ならないことを保障する制約である。相互排他制約を用いることによって、ロックによって発生するスレッド実行時間の予測不可能性を削減することが可能になる。すなわち、あるリソースを共有する全てのスレッドが同時に実行されないようにして、そのリソースに関するロックをなくすことができる。
【００９３】
（スレッドの同期機構）
本実施形態のリアルタイム処理システムでは、スレッドの同期機構として、たとえば以下のような手段を用いる。
【００９４】
・セマフォ
・メッセージキュー
・メッセージバッファ
・イベントフラグ
・バリア
・ミューテックス
その他の同期プリミティブも、これらと同様に用いることができる。このような同期機構を実現する手段として、本発明のリアルタイム処理システムでは、次の３通りの方式がある。
【００９５】
・メモリ（主記憶）１３あるいはＶＰＵのローカルストレージ３２上に、たとえばＴＥＳＴ＆ＳＥＴのような命令を使って実現する
・メールボックスやシグナルレジスタなどのハードウェア機構を使って実現する
・ＶＰＵ実行環境がサービスとして提供する機構を利用する
これらの実現手段の異なる同期機構は、それぞれ得失を持っているため、それを利用するスレッドの属性等によって、たとえば図５９のように使い分けるのが望ましい。すなわち、ＭＰＵやＶＰＵが共有してアクセスできるメモリ１３（主記憶ＭＳ）を使って実装した同期機構は、すべてのクラスのスレッドで使用できる。それに対して，ＶＰＵ１２のローカルストレージＬＳ上に実装した同期機構は、密結合スレッドグループ（ｔｉｇｈｔｌｙ ｃｏｕｐｌｅｄ ｔｈｒｅａｄ ｇｒｏｕｐ）に属するスレッドのみが使うことができる。これは、密結合スレッドグループに属するスレッドのみが，同期相手のスレッドが同時に動作していることを保障されるからである。例えば，相手のスレッドが動作しているＶＰＵのローカルストレージ上に実装した同期機構を用いる場合、密結合スレッドグループのスレッドであれば、同期機構を使う時点で、相手のスレッドが動作していることが保障されているので、その相手スレッドを実行しているＶＰＵのローカルストレージに同期機構のための情報が必ず存在する。
【００９６】
メモリ（主記憶ＭＳ）やローカルストレージＬＳ以外の手段を用いて実装した同期機構としては、ハードウェア機構を使って実現する場合と、ＶＰＵ実行環境４０１のサービスを使う場合がある。密結合スレッドグループに属するスレッド、あるいはハードリアルタイムクラスのスレッドは，速い同期機構が必要であるので、ハードウェア機構を用いて実装した同期機構を用いるのが望ましい。それに対して，疎結合スレッドグループに属するスレッド、あるいはソフトリアルタイムクラスと，ベストエフォートクラスのスレッドは，実行環境が提供する機構を利用するのが望ましい。
【００９７】
（同期機構の自動選択）
本実施形態のリアルタイム処理システムでは、上記の同期機構を、スレッドの属性や状態に合わせて自動的に選択・切り替えを行うことができる。これは例えば図６０に示すような手順により、同期処理を行いたいスレッドが蜜結合スレッドグループに属している状態の間は（ステップＳ２０１のＹＥＳ）、メモリ１４あるいはＶＰＵ１２のローカルストレージ３２あるいはハードウェア機構を用いて実装された高速な同期機構を用いるが（ステップＳ２０２，Ｓ２０３，Ｓ２０４，Ｓ２０５）、スレッドの状態が変化して蜜結合関係になくなった状態では（ステップＳ２０１のＮＯ）、メモリ１４上に実装された同期機構化あるいはＶＰＵ実行環境４０１のサービスとして提供されている同期機構を用いるように同期機構を切り替える（ステップＳ２０６，Ｓ２０７，Ｓ２０８）。
この切り替え手段は、ＶＰＵ１２上で動作するプログラムに対して、ライブラリの形式で提供するようにしても良いし、ＶＰＵ１２側のＶＰＵ実行環境５０２の提供するサービスとして提供することもできる。複数の同期機構を切り替える方式としては、あらかじめ複数の同期機構を確保しておいて、それを使い分けるようにすることもできるし、切り替えを行う時点で新しく同期機構を確保するようにすることもできる。
【００９８】
ＶＰＵ１２のローカルストレージを用いた同期機構は、蜜結合スレッドグループに属するスレッド間のように、同期処理を行う時点で、同期機構を実装しているＶＰＵ１２のローカルストレージが必ず有効になっている必要がある。この制限を緩和する方式としては、スレッドが実行中（ＲＵＮＮＩＮＧ状態）で無い場合には、そのスレッドを最後に実行していたときのローカルストレージの内容をメモリに保存しておき、そのスレッドに対応付けられたローカルストレージを指すページテーブルあるいはセグメントテーブルのエントリからは、その保存したメモリ領域を指すようにマッピングを制御する。この方式により、相手のスレッドが実行中でなくても、相手のスレッドに対応付けられたローカルストレージがあたかもあるように、スレッドの実行を続けることができる。実行中で無かったスレッドが、ＶＰＵ１２を割り当てられて実行を始めるときには、メモリ１４に保存していた内容を、再びローカルストレージに戻して、対応するページテーブルあるいはセグメントテーブルのマップを変更する。このように、ＶＰＵ１２のローカルストレージのバックアップコピーに対しても動作可能なように同期機構を実装しておくことで、蜜結合スレッドグループに属するスレッドでなくても、ＶＰＵ１２のローカルストレージを用いて実装した高速な同期機構を利用できるようになる。
【００９９】
（予約グラフ）
図６１は、図９に例として示した処理フローに対応する予約グラフを示したものである。図６１において、６つの四角い箱は実行期間（ｅｘｅｃｕｔｉｏｎ ｔｅｒｍ）を表している。各実行期間の四角の左上の番号は予約する実行期間のＩＤであり、実行期間の四角の中の記号は、その実行期間に対応付けられているスレッドコンテクストの識別子である。実行期間の四角の下の数値は、その実行期間の長さ（コスト）を表している。実行期間の四角の間を結ぶ矢印は、ここではすべて先行制約を表している。すなわち、矢印が入る実行期間は、必ず矢印が出ている実行期間が終わった後で実行を開始することを示している。また、矢印に添えられている番号はその矢印で結ばれた実行期間の間でデータの受け渡しに使うバッファのＩＤを表しており、番号と共に添えられている数値はバッファのサイズを表している。図６１に示した予約グラフに従って処理を実行するための手順は、以下のようになる。
【０１００】
１．ＤＥＭＵＸプログラム１１１を実行するスレッドコンテクストを作成して、その識別子をＤＥＭＵＸとする。
２．Ａ−ＤＥＣプログラム１１２を実行するスレッドコンテクストを作成して、その識別子をＡ−ＤＥＣとする。
３．Ｖ−ＤＥＣプログラム１１３を実行するスレッドコンテクストを作成して、その識別子をＶ−ＤＥＣとする。
４．ＴＥＸＴプログラム１１４を実行するスレッドコンテクストを作成して、その識別子をＴＥＸＴとする。
５．ＰＲＯＧプログラム１１５を実行するスレッドコンテクストを作成して、その識別子をＰＲＯＧとする。
６．ＢＬＥＮＤプログラム１１６を実行するスレッドコンテクストを作成して、その識別子をＢＬＥＮＤとする 。
【０１０１】
７．図６２に示すようなデータ構造の予約リクエストを作成し、ＶＰＵ実行環境４０１に渡して予約を行う。
ここで手順１から６までのスレッドコンテクストの作成は、スレッドとして実行したいプログラムを指定してＶＰＵ実行環境４０１に依頼すると、ＶＰＵ実行環境４０１が必要な資源を割り当ててスレッドコンテクストを作成し、そのハンドルを返してくるので、それを識別子と関連付けている。
【０１０２】
図６２の予約リクエストは、ＢＵＦＦＥＲと書かれたバッファデータと、ＴＡＳＫと書かれた実行期間データから構成される。バッファデータは、実行期間の間でデータを受け渡すために用いるメモリ１４上のバッファを宣言するもので、Ｉｄ：にバッファ番号を、Ｓｉｚｅ：にバッファサイズを、ＳｒｃＴａｓｋ：にデータを書き込む実行期間の番号を、ＤｓｔＴａｓｋ：にデータを読み出す実行期間の番号を持つ。実行期間データは、Ｉｄ：に実行期間番号を、Ｃｌａｓｓ：にスレッドクラス（ＶＰＵはＶＰＵスレッドであることを示し、ＨＲＴはハードリアルタイムクラスであることを示す。他に、ＭＰＵスレッドを示すＭＰＵや、ソフトリアルタイムクラスを示すＳＲＴや、ベストエフォートクラスを示すＢＳＴなどがある）を、ＴｈｒｅａｄＣｏｎｔｅｘｔ：にこの実行期間に対応付けるスレッドコンテクストを、Ｃｏｓｔ：にこの実行期間の長さあるいはコストを、Ｃｏｎｓｔｒａｉｎｔ：にこの実行期間を基準とする各種の制約を、ＩｎｐｕｔＢｕｆｆｅｒ：にこの実行期間で読み出すバッファの識別子のリストを、ＯｕｔｐｕｔＢｕｆｆｅｒ：にこの実行期間で書き込むバッファの識別子のリストを持つ。Ｃｏｎｓｔｒａｉｎｔ：には、先行制約を示すＰｒｅｃｅｄｅｎｃｅ：や、絶対タイミング制約を示すＡｂｓｏｌｕｔｅＴｉｍｉｎｇ：や、相対タイミング制約を示すＲｅｌａｔｉｖｅＴｉｍｉｎｇ：や、排他制約を示すＥｘｃｌｕｓｉｖｅ：などを指定でき、それぞれ制約の相手になる実行期間の番号のリストを持つ。
【０１０３】
図６２の予約リクエストで予約したバッファ領域は、ＶＰＵ実行環境４０１が、バッファにデータを書き込むスレッドの実行開始時に割り当て、データを読み出すスレッドの実行終了時に解放する。割り当てられたバッファのアドレスは、たとえばスレッドの起動時にあらかじめ決まっているアドレスあるいは変数あるいはレジスタなどを用いて、スレッドに通知することができる。本実施形態のリアルタイム処理システムでは、図７に示したようなプログラムモジュール１００が与えられたときに、その中にある、図８に示すような構成記述１１７を読み込んで、それに基づいて、上記の手順でスレッドコンテクストの生成と図６２の予約リクエストの作成・発行を行って、そのプログラムモジュール１００の実行を行う機能を提供する。この機能により、図７のようなプログラムモジュール１００によって記述された専用ハードウェアの処理を、複数のプロセッサによるソフトウェア処理によって実現することが可能となる。実現したいハードウェア毎に図７のような構造を持つプログラムモジュールを作成して、それを本実施形態のリアルタイム処理システムに準拠した機能が組み込まれた機器で実行することにより、当該機器を所望のハードウェアとして動作させることが可能となる。
【０１０４】
図６２に示す予約リクエストが与えられると、ＶＰＵ実行環境４０１は、各実行期間を周期内のどのタイミングでどのＶＰＵ１２で実行するかを決める。これがスケジューリングである。本実施形態のリアルタイム処理システムが組み込まれる電子機器の種類によっては、実際には、このような予約リクエストが同時に複数与えられることもあるので、それらが矛盾ないように（与えられた制約が満たされないことがないように）処理のタイミングが決定される。例えば、図６３に示すように、ＶＰＵ１２が２つあるときに、図６２の予約リクエストだけが入っていたとすると、ＤＥＭＵＸ、Ｖ−ＤＥＣ、ＰＲＯＧ、ＢＬＥＮＤの並行に実行できない処理をＶＰＵ０で順次実行し、ＤＥＭＵＸの実行後に並行して動作できるＡ−ＤＥＣとＴＥＸＴをＶＰＵ１で実行するようにスケジューリングする。
【０１０５】
（ソフトウェアパイプライン）
ここでもし、ひとつの周期内でＤＥＭＵＸ、Ｖ−ＤＥＣ、ＰＲＯＧ、ＢＬＥＮＤを順次実行できるだけの時間がない場合には、複数の周期にまたがるようにソフトウェアパイプライン化を行う。例えば図６４に示すように、最初の周期１ではＤＥＭＵＸとＶ−ＤＥＣをＶＰＵ０で行い、次の周期２でＡ−ＤＥＣ、ＴＥＸＴ、ＰＲＯＧ、ＢＬＥＮＤの処理をＶＰＵ１で行うようにする。この周期２では、Ａ−ＤＥＣ、ＴＥＸＴ、ＰＲＯＧ、ＢＬＥＮＤの処理と並行して、次のフレームのＤＥＭＵＸとＶ−ＤＥＣがＶＰＵ０によって実行される。すなわち、図６５に示すように、ＶＰＵ０がＤＥＭＵＸとＶ−ＤＥＣを実行している間、ＶＰＵ１では前の周期のＤＥＭＵＸとＶ−ＤＥＣの出力を受けたＡ−ＤＥＣ、ＴＥＸＴ、ＰＲＯＧ、ＢＬＥＮＤが動くという具合に、パイプライン処理を行う。
【０１０６】
（バッファ量を考慮したスケジューリング）
ある実行期間に実行するスレッドと、別の実行期間に実行するスレッドの間で、バッファを使ってデータを送る場合、そのバッファはデータを書き込む側の実行期間の初めから、データを読み出す側の実行期間の最後までの間、専有されることになる。例えば、図６６に示すように、実行期間Ａと実行期間Ｂの間でバッファを使ってデータを送る場合、図６６に示すように、実行期間Ａの初めから、実行期間Ｂの最後までの期間、メモリ１４（主記憶）上のバッファは占有して使用されることになる。そのため、実行期間Ａから実行期間Ｂにバッファを使ってデータを送るときで、ソフトウェアパイプライン化した際に実行期間ＡとＢが隣り合う別の周期で実行するような場合、実行期間ＡとＢの実行タイミングによって必要なバッファの量が変わってくる。例えば、図６７に示すように、各周期内で実行期間ＡがＢよりも早く実行されるようにスケジューリングした場合、実行期間Ａｎ（Ａｎは周期ｎにおけるＡをあらわす）からのデータは次の周期の実行期間Ｂｎに渡され、実行期間Ａｎ＋１からのデータは次の周期の実行期間Ｂｎ＋１に渡される。このとき、実行期間Ａｎ＋１はＡｎとＢｎに挟まれているため、ＡｎがＢｎにデータを渡すために使っているバッファは利用できず、新しいバッファを用いる。つまり、ダブルバッファリングが必要になる。一方、図６８に示すように、周期内で実行期間ＡがＢの終了後に開始するようにすると、実行期間Ａｎがデータを書いたバッファをＢｎが読んだ後、同じバッファを使いまわして、Ａｎ＋１がデータを書いてＢｎ＋１が読むように、シングルバッファですむ。
【０１０７】
本実施形態のリアルタイム処理システムでは、ＶＰＵ実行環境４０１のスケジューラが、このように、バッファメモリ領域の使用量ができるだけ少なくなるように、予約される実行期間をスケジューリングする。すなわち、ソフトウェアパイプラインを行う場合には、図６９のフローチャートに示されているように、ＶＰＵ実行環境４０１のスケジューラは、ＶＰＵ０，１の２つのＶＰＵによるソフトウェアパイプラインを実行するために、一連の処理を２つの部分処理（ＶＰＵ０によって先行して実行される部分処理と、その部分処理に後続してＶＰＵ１によって実行される部分処理）に分割する（ステップＳ２１１）。そして、ＶＰＵ実行環境４０１のスケジューラは、２つの部分処理間でバッファを介して入出力を行うスレッド同士（例えば、先行して実行される部分処理内のスレッドＡと、後続して実行される部分処理内のスレッドＢ）を抽出し（ステップＳ２１２）、各周期において、先行して実行される部分処理内のスレッドＡが、後続する部分処理内のスレッドＢの実行期間終了後に開始されるように、スレッドＡ，Ｂをスケジューリングする（ステップＳ２１３）。
【０１０８】
（階層構造を持つ予約グラフ）
図６１に示した予約グラフは階層構造を持っていないが、図７０に示すように、階層構造を持つ予約グラフを扱うことも出来る。図７０の例では、実行期間ＡはＢに先行し、ＢはＣに先行する。Ｂの中はＤがＥとＦに先行している。それゆえ、階層を解くと、ＡはＤに先行し、ＥとＦはＣに先行することになる。
【０１０９】
（密結合スレッドグループを考慮した予約リクエスト）
例えば図６１に示した予約グラフにおいてＶ−ＤＥＣを実行するスレッドとＰＲＯＧを実行するスレッドが密結合スレッドグループに属する場合、その結合属性を示す予約リクエストが図７１のように生成される。図７１の例においては、ＴｉｇｈｔｌｙＣｏｕｐｌｅｄ：に相手先のスレッドに対応する実行期間のＩＤが記述されている。これにより、Ｖ−ＤＥＣを実行するスレッドとＰＲＯＧを実行するスレッドがそれぞれ別のＶＰＵによって同時に実行されるように、例えば図７２に示すようにスケジューリングされる。この場合、Ｖ−ＤＥＣを実行するスレッドとＰＲＯＧを実行するスレッドとの間の通信はローカルストレージを介して実行できるので、バッファをメモリ１４上に用意する必要はない。
【０１１０】
（構成記述に基づくスケジューリングアルゴリズム）
以下、プログラムモジュールに組み込まれた構成記述に基づいて各スレッドの実行期間を予約するための処理手順について説明する。
【０１１１】
図７のプログラムモジュール１００内の構成記述１１７は、図８の例のようになっている。この構成記述１１７が与えられると、ＶＰＵ実行環境４０１は次の手順を実行する。
１．構成記述１１７のモジュール欄に書かれている各プログラムをロードして、それぞれを実行するスレッドを生成する。このとき、本実施形態では、構成記述１１７のエントリそれぞれに対して一つのスレッドを生成する。構成記述１１７の中に、同じモジュール名を持つ複数のエントリが存在する場合には、同じモジュールを実行する複数のスレッドをそれぞれのエントリと対応するように生成することになる。なお、図８の例では、すべてのスレッドはひとつのプロセスに属するように生成されるものとしているが、それぞれのスレッドが別のプロセスに属するように実施することもできるし、あるグループのスレッドはあるプロセスに属し、また他のグループのスレッドは別のプロセスに属するといったように実施することもできる。
２．構成記述１１７の情報から、図６２で説明したような予約リクエストのデータ構造を作成する。
３．予約リクエストをＶＰＵ実行環境に渡して処理のスケジューリングを行い、実行を開始する。
【０１１２】
この２番目の予約リクエストを作成するステップは、次のように行う。
まず、構成記述１１７の出力欄に１対１に対応するように、ＢＵＦＦＥＲレコードを作成して予約リクエストに加える。例えば、図８の構造記述１１７の例では、ＤＥＭＵＸモジュールの２番目の出力は１ＭＢのバッファを使ってデータをＶ−ＤＥＣに渡しているので、それに対応するように、図６２のＩｄが２のＢＵＦＦＥＲレコードを作成している。Ｉｄが２のＢＵＦＦＥＲレコードには、そのバッファサイズがＳｉｚｅ欄に１ＭＢと記録され、そのバッファにデータを書き込むＤＥＭＵＸモジュールに対応するタスクであるＩｄが１のＴＡＳＫレコードへの参照がＳｒｃＴａｓｋ欄に記録され、そのバッファのデータを読み出すＶ−ＤＥＣモジュールに対応するタスクであるＩｄが３のＴＡＳＫレコードへの参照がＤｓｔＴａｓｋ欄に記録されている。
【０１１３】
次に、構成記述１１７のモジュール欄に１対１に対応するように、ＴＡＳＫレコードを作成して予約リクエストに加える。例えば、図８の構造記述１１７の例で、Ｖ−ＤＥＣモジュールに対応するＴＡＳＫレコードとして、図６２のＩｄが３のＴＡＳＫレコードを作成している。Ｉｄが３のＴＡＳＫレコードには、以下のような情報が記録されている。
【０１１４】
Ｃｌａｓｓ欄： このＴＡＳＫレコードに指定されるスレッドをどのような属性で実行させるかを示すフラグ。ＶＰＵはＶＰＵ上で実行するスレッドであることを、ＨＲＴはハードリアルタイムクラスのスレッドであることを示す。これらの情報は、図８の例では構成記述１１７のスレッドパラメタに記述されている情報をもとに設定する。
【０１１５】
ＴｈｒｅａｄＣｏｎｔｅｘｔ欄： このＴＡＳＫレコードで実行の予約を行いたいスレッドのスレッドコンテクストを指定する。具体的には、図８の構成記述１１７のモジュール欄に指定されたプログラムモジュールをロードして、それを実行するスレッドをＶＰＵ実行環境４０１によって生成し、そのスレッドのスレッドコンテクストの識別子（あるいはポインタなど）を、ＴｈｒｅａｄＣｏｎｔｅｘｔ欄に記録する。
Ｃｏｎｓｔｒａｉｎｔ欄： このＴＡＳＫレコードに関する制約条件を記録する。先行制約の場合は、Ｐｒｅｃｅｄｅ：の後にそのＴＡＳＫが先行する他のＴＡＳＫのＩｄを必要な数指定する。Ｉｄが３のＴＡＳＫレコードの場合、Ｉｄが５のＰＲＯＧモジュールに対応するＴＡＳＫに先行することを示している。
ＩｎｐｕｔＢｕｆｆｅｒ欄： このＴＡＳＫレコードで指定されるスレッドがデータを読み出すバッファのＢｕｆｆｅｒレコードのＩｄを必要な数指定する。
ＯｕｔｐｕｔＢｕｆｆｅｒ欄： このＴＡＳＫレコードで指定されるスレッドがデータを書き込むバッファのＢｕｆｆｅｒレコードのＩｄを必要な数指定する。
このようにして、構造記述が与えられるとそれに対する予約リクエストが作成される。
【０１１６】
次に、その予約リクエストをＶＰＵ実行環境４０１内のスケジューラに渡すと、スケジューラは、指定された予約リクエストを実行するのに必要なスケジュールを作成する。このスケジューリング処理の結果作成されたスケジュールは、例えば図６３に示すような、各周期のどのタイミングで、どのＶＰＵを、どれだけの時間、どのスレッドに割り当てるかを示すものである。実際には、例えば図７３のような予約リストによって表現されるように実施することができる。
【０１１７】
図７３の予約リストは、各ＶＰＵに対応付けられた予約エントリから構成される。予約エントリには、ひとつのスレッドに対して、それを各周期内のどのタイミングでＶＰＵを割り当てて実行を始めるかを開始時間欄に、どれくらいの時間でＶＰＵを取り上げるかを実行期間欄に、そのスレッドの識別子を実行スレッド欄に記録している。それらの予約エントリは、実行するＶＰＵ別に、開始時間順にソートされて予約リストにつながれている。
【０１１８】
図６２または図７１に示すような予約リクエストから、図７３に示すような予約リストを作成する手順は、例えば図７４のフローチャートで示す手順で実施できる。
基本は、予約リクエスト中の各ＴＡＳＫレコードを、ＢＵＦＦＥＲを使った入出力関係を考慮して順序付けして、データの流れる順に、ＶＰＵの実行時間を割り付けて行けばよい。このとき、蜜結合スレッドグループに指定されているＴＡＳＫ群には、それぞれのＴＡＳＫのスレッドに同時にＶＰＵを割り付けるようにする必要がある。
【０１１９】
図７４にその手順を示す。予約リクエストが与えられると、その中のＴＡＳＫレコードに指定されているすべてのタスクの集合に対して、以下の手順でスケジューリング（いいかえると、スケジュールの割り付け、あるいは予約リストの作成）を行う。
ステップＳ３０１： 全ての入力タスクが割付け済みのタスクで、密結合指定のないタスクを選択する。すなわち、未割り付けのタスク（すなわち、まだ予約エントリを作って予約リストにつないでいないタスク）の中で、そのタスクの入力となるデータのソースになるタスクがすべて割り付け済み（予約エントリが予約リストに入っている）であるか、あるいはそのタスクはデータの入力を持たない場合であって、かつ、そのタスクが密結合指定されていないものが存在すれば、それを選択してステップＳ３０２へ、そうでなければステップＳ３０４へ行く。
ステップＳ３０２： 選択したタスクを予約できるＶＰＵが存在すれば（言い換えると、他のタスクとの間の制約を満たす開始時間と実行期間を予約できるＶＰＵが存在すれば）、ステップＳ３０３へ、そうでなければスケジューリング不可能なので失敗を通知する。
ステップＳ３０３： 選択したタスクの予約エントリを作成して、予約リストにつなぐ。
【０１２０】
ステップＳ４０４： 全ての入力タスクが割付け済みのタスクで、密結合関係にあるタスク群を選択する。すなわち、未割り付けのタスク（すなわち、まだ予約エントリを作って予約リストにつないでいないタスク）の中で、そのタスクの入力となるデータのソースになるタスクがすべて割り付け済み（予約エントリが予約リストに入っている）であるか、あるいはそのタスクはデータの入力を持たないものの集合であって、かつ、その集合に属するタスク間が密結合指定されているものが存在すれば、そのタスク集合（タスク群とも呼ぶ）を選択してステップＳ３０５５へ、そうでなければ既にすべてのタスクを割り付けているのでスケジューリング処理を終了する。
ステップＳ３０５： 選択したタスク集合に含まれるすべてのタスクを同時に（同じ開始時間で同じ実行期間を持つように）予約できる複数のＶＰＵが存在すればステップＳ３０６へ、そうでなければスケジューリング不可能なので失敗を通知する。
ステップＳ３０６： 選択したタスク集合のすべてのタスクの予約エントリを作成して、予約リストにつなぐ。
【０１２１】
ここでの説明はひとつの予約リクエストのスケジューリングの手順について述べたが、上述したように、実際は、ひとつのシステムにおいて複数の予約リクエストが同時に存在することが普通である。そのような場合には、複数の予約リクエストを順次上記の手順でスケジューリングするように実施することもできるし、より望ましくは、同時に複数の予約リクエストを上記の手順でスケジューリングするように実施する。
【０１２２】
以上、デジタルテレビ放送用受信機の動作を記述したプログラムモジュールを例に説明したが、他の様々なハードウェアの動作を記述したプログラムモジュールを用意することにより、デジタルテレビ放送用受信機以外の他の任意のハードウェアの動作をソフトウェアによって実現することが出来る。
【０１２３】
なお、図１の計算機システムに設けられたＭＰＵ１１と複数のＶＰＵ１２は。それらを１チップ上に混載した並列プロセッサとして実現することもできる。この場合も、ＭＰＵ１１によって実行されるＶＰＵ実行環境、あるいは特定の一つのＶＰＵなどによって実行されるＶＰＵ実行環境が、複数のＶＰＵ１２に対するスケジューリングを制御することが出来る。
【０１２４】
またＶＰＵ実行環境として動作するプログラムまたはそのＶＰＵ実行環境を含むオペレーティングシステムなどのプログラムをコンピュータ読み取り可能な記憶媒体に記憶することにより、その記憶媒体を通じて当該プログラムを、ローカルプロセッサをそれぞれ有する複数のプロセッサを含むコンピュータに導入して実行するだけで、本実施形態と同様の効果を得ることが出来る。
【０１２５】
また、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１２６】
【発明の効果】
以上説明したように、本発明によれば、互いに協調して動作するスレッド間のデータの受け渡しのような相互作用を効率よく実行することが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るリアルタイム処理システムを構成する計算機システムの例を示すブロック図。
【図２】同実施形態のリアルタイム処理システムに設けられたＭＰＵおよびＶＰＵそれぞれの構成を示すブロック図。
【図３】同実施形態のリアルタイム処理システムで用いられる仮想アドレス変換機構の例を示す図。
【図４】同実施形態のリアルタイム処理システムにおける実アドレス空間にマッピングされるデータの例を示す図。
【図５】同実施形態のリアルタイム処理システムにおける実効アドレス空間、仮想アドレス空間、実アドレス空間を説明するための図。
【図６】デジタルテレビ放送の受信機の構成を示すブロック図。
【図７】同実施形態のリアルタイム処理システムによって実行されるプログラムモジュールの構成の例を示す図。
【図８】図７のプログラムモジュール内に含まれる構成記述の例を示す図。
【図９】図７のプログラムモジュールに対応するプログラム間のデータの流れを示す図。
【図１０】図７のプログラムモジュールが２つのＶＰＵによって並列に実行される様子を示す図。
【図１１】図７のプログラムモジュールが２つのＶＰＵによってパイプライン形式で実行される様子を示す図。
【図１２】同実施形態のリアルタイム処理システムにおけるオペレーティングシステムの実装形態の例を示す図。
【図１３】同実施形態のリアルタイム処理システムにおけるオペレーティングシステムの実装形態の他の例を示す図。
【図１４】同実施形態のリアルタイム処理システムにおける仮想計算機ＯＳとゲストＯＳとの関係を示す図。
【図１５】同実施形態のリアルタイム処理システムにおいて複数のゲストＯＳに時分割で資源が割り当てられる様子を示す図。
【図１６】同実施形態のリアルタイム処理システムにおいてある特定のゲストＯＳによって特定の資源が専有される様子を示す図。
【図１７】同実施形態のリアルタイム処理システムにおいてスケジューラとして用いられるＶＰＵ実行環境を示す図。
【図１８】同実施形態のリアルタイム処理システムで用いられる仮想計算機ＯＳにＶＰＵ実行環境を実装した例を示す図。
【図１９】同実施形態のリアルタイム処理システムで用いられる一つのゲストＯＳとしてＶＰＵ実行環境を実装する例を示す図。
【図２０】同実施形態のリアルタイム処理システムで用いられる複数のゲストＯＳそれぞれにＶＰＵ実行環境を実装する例を示す図。
【図２１】同実施形態のリアルタイム処理システムで用いられる一つのゲストＯＳにＶＰＵ実行環境を実装する例を示す図。
【図２２】同実施形態のリアルタイム処理システムで用いられるＭＰＵ側ＶＰＵ実行環境とＶＰＵ側ＶＰＵ実行環境を説明するための図。
【図２３】同実施形態のリアルタイム処理システムで用いられるＶＰＵ側ＶＰＵ実行環境によって実行される処理手順を示すフローチャート。
【図２４】同実施形態のリアルタイム処理システムで用いられるＭＰＵ側ＶＰＵ実行環境によって実行される処理手順を示すフローチャート。
【図２５】同実施形態のリアルタイム処理システムにおいて密結合スレッドグループに属するスレッド群がそれぞれ別のプロセッサによって同時に実行される様子を示す図。
【図２６】同実施形態のリアルタイム処理システムにおける密結合スレッド間の相互作用を説明するための図。
【図２７】同実施形態のリアルタイム処理システムにおいて各密結合スレッドの実効アドレス空間に相手のスレッドが実行されるＶＰＵのローカルストレージがマッピングされる様子を示す図。
【図２８】同実施形態のリアルタイム処理システムにおける疎結合スレッドグループに属するスレッド群に対するプロセッサの割り当てを説明するための図。
【図２９】同実施形態のリアルタイム処理システムにおける疎結合スレッド間の相互作用を説明するための図。
【図３０】同実施形態のリアルタイム処理システムにおけるプロセスとスレッドとの関係を説明するための図。
【図３１】同実施形態のリアルタイム処理システムにおけるスケジューリング処理の手順を示すフローチャート。
【図３２】同実施形態のリアルタイム処理システムにおけるローカルストレージのマッピングに関する第１の問題を説明するための図。
【図３３】同実施形態のリアルタイム処理システムにおける物理ＶＰＵと論理ＶＰＵとの関係を示す図。
【図３４】同実施形態のリアルタイム処理システムにおけるローカルストレージのマッピングに関する第２の問題を説明するための図。
【図３５】同実施形態のリアルタイム処理システムにおける実効アドレス空間共有モデルを示す図。
【図３６】同実施形態のリアルタイム処理システムにおける仮想アドレス空間共有モデルを示す図。
【図３７】同実施形態のリアルタイム処理システムにおける非共有モデルを示す図。
【図３８】同実施形態のリアルタイム処理システムにおけるローカルストレージのマッピング変更を説明するための第１の図。
【図３９】同実施形態のリアルタイム処理システムにおけるローカルストレージのマッピング変更を説明するための第２の図。
【図４０】同実施形態のリアルタイム処理システムにおけるローカルストレージのマッピング変更を説明するための第３の図。
【図４１】同実施形態のリアルタイム処理システムにおけるローカルストレージのマッピング変更を説明するための第４の図。
【図４２】同実施形態のリアルタイム処理システムにおけるローカルストレージのマッピング変更を説明するための第５の図。
【図４３】同実施形態のリアルタイム処理システムにおいてローカルストレージのマッピング変更を行うために実行されるアドレス管理処理の手順を示すフローチャート。
【図４４】同実施形態のリアルタイム処理システムにおいて実行されるローカルストレージとメモリとの間のマッピング変更を説明するための図。
【図４５】同実施形態のリアルタイム処理システムにおいて実行されるローカルストレージとメモリとの間のマッピング変更処理の手順を示すフローチャート。
【図４６】同実施形態のリアルタイム処理システムにおけるスレッドの状態遷移を示す図。
【図４７】同実施形態のリアルタイム処理システムにおけるスレッドと実効期間との関係を説明するための図。
【図４８】同実施形態のリアルタイム処理システムにおける密結合スレッド群がある実効期間において同時に実行される様子を示す図。
【図４９】同実施形態のリアルタイム処理システムにおける周期実行モデルを示す図。
【図５０】同実施形態のリアルタイム処理システムにおける非周期実行モデルを示す図。
【図５１】タスクグラフを説明するための図。
【図５２】同実施形態のリアルタイム処理システムで用いられる予約グラフの原理を説明するための図。
【図５３】同実施形態のリアルタイム処理システムで用いられる予約グラフの例を説明するための図。
【図５４】同実施形態のリアルタイム処理システムで用いられる階層型スケジューラを説明するための図。
【図５５】同実施形態のリアルタイム処理システムがハードリアルタイムクラスのスケジューリングのために使用するパラメータの例を説明する図。
【図５６】同実施形態のリアルタイム処理システムで用いられる絶対タイミング制約を説明する図。
【図５７】同実施形態のリアルタイム処理システムで用いられる相対タイミング制約を説明する図。
【図５８】同実施形態のリアルタイム処理システムで用いられる相互排他制約を説明する図。
【図５９】同実施形態のリアルタイム処理システムにおける同期機構を説明するための図。
【図６０】同実施形態のリアルタイム処理システムにおいて同期機構を使い分ける手順を示すフローチャート。
【図６１】同実施形態のリアルタイム処理システムにおいて用いられる予約グラフの例を示す図。
【図６２】同実施形態のリアルタイム処理システムにおいて生成される予約リクエストの例を示す図。
【図６３】同実施形態のリアルタイム処理システムが図６２の予約リクエストに基づいて実行するスケジューリングの例を示す図。
【図６４】同実施形態のリアルタイム処理システムによって実行されるソフトウェアパイプライン形式のスケジューリングを説明するための第１の図。
【図６５】同実施形態のリアルタイム処理システムによって実行されるソフトウェアパイプライン形式のスケジューリングを説明するための第２の図。
【図６６】同実施形態のリアルタイム処理システムにおいて実行されるバッファ量を考慮したスケジューリングを説明するための第１の図。
【図６７】同実施形態のリアルタイム処理システムにおいて実行されるバッファ量を考慮したスケジューリングを説明するための第２の図。
【図６８】同実施形態のリアルタイム処理システムにおいて実行されるバッファ量を考慮したスケジューリングを説明するための第３の図。
【図６９】同実施形態のリアルタイム処理システムにおいて実行されるバッファ量を考慮したスケジューリング処理の手順を示すフローチャート。
【図７０】同実施形態のリアルタイム処理システムにおいて用いられる階層構造を持つ予約グラフの例を示す図。
【図７１】同実施形態のリアルタイム処理システムによって生成される、密結合スレッドグループを考慮した予約リクエストの例を示す図。
【図７２】同実施形態のリアルタイム処理システムが図７１の予約リクエストに基づいて行うスケジューリングの例を示す図。
【図７３】同実施形態のリアルタイム処理システムにおいて用いられる予約リストの例を示す図。
【図７４】同実施形態のリアルタイム処理システムにおける実行期間予約処理の手順を示すフローチャート。
【符号の説明】
１１…ＭＰＵ（Ｍａｓｔｅｒ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、１２…ＶＰＵ（Ｓｌａｖｅ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、１４…メインメモリ、２１…処理ユニット、２２…メモリ管理ユニット、３１…処理ユニット、３２…ローカルストレージ、３３…メモリコントローラ、５０…セグメントテーブル、６０…ページテーブル、１００…プログラムモジュール、１１７…構成記述、３３１…アドレス変換ユニット、４０１…ＶＰＵ実行環境。

Claims (16)

1. 複数のプロセッサにリアルタイム処理を実行するためのスレッド群を割り当てるスケジューリング方法であって、
   スレッド間の結合属性を示す結合属性情報に基づいて、前記リアルタイム処理を実行するためのスレッド群の中から、互いに協調して動作する複数のスレッドの集合である密結合スレッドグループを選択する選択ステップと、
   前記選択ステップによって選択された前記密結合スレッドグループに属するスレッド群がそれぞれ別のプロセッサによって同時に実行されるように、前記密結合スレッドグループに属するスレッド群を当該スレッド群の個数分のプロセッサにそれぞれディスパッチするためのスケジューリング処理を実行するステップとを具備することを特徴とするスケジューリング方法。
2. 前記複数のプロセッサはそれぞれローカルメモリを有しており、
   別のプロセッサにそれぞれディスパッチされる前記密結合スレッドグループに属するスレッド群の各々の実効アドレス空間の一部に、前記密結合スレッドグループに属する他のスレッドが実行されるプロセッサのローカルメモリをマッピングするステップをさらに具備することを特徴とする請求項１記載のスケジューリング方法。
3. 前記スケジューリング処理を実行するステップは、前記密結合スレッドグループに属するスレッド群が同一の実行期間に同時に実行されるように、前記密結合スレッドグループに属するスレッド群の個数分のプロセッサそれぞれの実行期間を予約するステップを含むことを特徴とする請求項１記載のスケジューリング方法。
4. 前記密結合スレッドグループに属するスレッド群の各々は、当該スレッドが実行されるプロセッサのレジスタおよびローカルストレージの内容を示すコンテクスト情報を含むことを特徴とする請求項１記載のスケジューリング方法。
5. 前記複数のプロセッサは共有メモリにそれぞれ電気的に接続されており、
   前記結合属性情報に基づいて、前記リアルタイム処理を実行するためのスレッド群の中から、前記共有メモリ上のバッファを介して通信を行うスレッドの集合である疎結合スレッドグループを選択するステップをさらに具備し、
   前記スケジューリング処理を実行するステップは、前記選択された疎結合スレッドグループに属するスレッド群がそれらスレッド間の入出力関係に対応する順序で実行されるように、前記疎結合スレッドグループに属するスレッド群を１以上のプロセッサにディスパッチするためのスケジューリング処理を実行するステップを含むことを特徴とする請求項１記載のスケジューリング方法。
6. 前記スケジューリング処理は、前記複数のプロセッサの一つによって実行されるオペレーティングシステムによって実行されることを特徴とする請求項１記載のスケジューリング方法。
7. ローカルメモリをそれぞれ有する第１および第２のプロセッサにリアルタイム処理を実行するためのスレッド群を割り当てるスケジューリング方法であって、
   互いに協調して動作する第１および第２のスレッドがそれぞれ前記第１および第２のプロセッサによって同時に実行されるように、前記第１および第２のスレッドを前記第１および第２のプロセッサにディスパッチするスケジューリング処理を実行するステップと、
   前記第２のスレッドが実行される前記第２のプロセッサのローカルストレージを前記第１のプロセッサによって実行される前記第１のスレッドの実効アドレス空間にマッピングするステップとを具備することを特徴とするスケジューリング方法。
8. 前記第１のスレッドが実行される前記第１のプロセッサのローカルストレージを前記第２のプロセッサによって実行される前記第２のスレッドの実効アドレス空間にマッピングするステップをさらに具備することを特徴とする請求項７記載のスケジューリング方法。
9. 複数のプロセッサと、
   スレッド間の結合属性を示す結合属性情報に基づいて、リアルタイム処理を実行するためのスレッド群の中から、互いに協調して動作する複数のスレッドの集合である密結合スレッドグループを選択する選択手段と、
   前記選択手段によって選択された前記密結合スレッドグループに属するスレッド群がそれぞれ別のプロセッサによって同時に実行されるように、前記密結合スレッドグループに属するスレッド群を当該スレッド群の個数分のプロセッサにそれぞれディスパッチするためのスケジューリング処理を実行する手段とを具備することを特徴とするリアルタイム処理システム。
10. 前記複数のプロセッサはそれぞれローカルメモリを有しており、
    別のプロセッサにそれぞれディスパッチされる前記密結合スレッドグループに属するスレッド群の各々の実効アドレス空間の一部に、前記密結合スレッドグループに属する他のスレッドが実行されるプロセッサのローカルメモリをマッピングする手段をさらに具備することを特徴とする請求項９記載のリアルタイム処理システム。
11. 前記スケジューリング処理を実行する手段は、前記密結合スレッドグループに属するスレッド群が同一の実行期間に同時に実行されるように、前記密結合スレッドグループに属するスレッド群の個数分のプロセッサそれぞれの実行期間を予約する手段を含むことを特徴とする請求項９記載のリアルタイム処理システム。
12. 前記複数のプロセッサは共有メモリにそれぞれ電気的に接続されており、
    前記結合属性情報に基づいて、前記リアルタイム処理を実行するためのスレッド群の中から、前記共有メモリ上のバッファを介して通信を行うスレッドの集合である疎結合スレッドグループを選択する手段をさらに具備し、
    前記スケジューリング処理を実行する手段は、前記選択された疎結合スレッドグループに属するスレッド群がそれらスレッド間の入出力関係に対応する順序で実行されるように、前記疎結合スレッドグループに属するスレッド群を１以上のプロセッサにディスパッチするためのスケジューリング処理を実行する手段を含むことを特徴とする請求項９記載のリアルタイム処理システム。
13. ローカルメモリをそれぞれ有する第１および第２のプロセッサと、
    互いに協調して動作する第１および第２のスレッドがそれぞれ前記第１および第２のプロセッサによって同時に実行されるように、前記第１および第２のスレッドを前記第１および第２のプロセッサにディスパッチするスケジューリング処理を実行する手段と、
    前記第１のプロセッサに設けられ、前記第２のスレッドが実行される前記第２のプロセッサのローカルメモリに対応する物理アドレス空間を、前記第１のプロセッサによって実行される前記第１のスレッドの実効アドレス空間にマッピングするためのアドレス変換処理を実行するアドレス変換手段とを具備することを特徴とするリアルタイム処理システム。
14. 前記第２のプロセッサに設けられ、前記第１のスレッドが実行される前記第１のプロセッサのローカルメモリに対応する物理アドレス空間を、前記第２のプロセッサによって実行される前記第２のスレッドの実効アドレス空間にマッピングするためのアドレス変換処理を実行するアドレス変換手段をさらに具備することを特徴とする請求項１３記載のリアルタイム処理システム。
15. 複数のプロセッサを含むコンピュータに、リアルタイム処理を実行するためのスレッド群を前記複数のプロセッサに割り当てるスケジューリング処理を実行させるプログラムであって、
    スレッド間の結合属性を示す結合属性情報に基づいて、前記リアルタイム処理を実行するためのスレッド群の中から、互いに協調して動作する複数のスレッドの集合である密結合スレッドグループを選択する処理を、前記コンピュータに実行させる手順と、
    前記選択された前記密結合スレッドグループに属するスレッド群がそれぞれ別のプロセッサによって同時に実行されるように、前記密結合スレッドグループに属するスレッド群を当該スレッド群の個数分のプロセッサにそれぞれディスパッチするためのスケジューリング処理を、前記コンピュータに実行させる手順とを具備することを特徴とするプログラム。
16. 前記複数のプロセッサはそれぞれローカルメモリを有しており、
    別のプロセッサにそれぞれディスパッチされる前記密結合スレッドグループに属するスレッド群の各々の実効アドレス空間の一部に、前記密結合スレッドグループに属する他のスレッドが実行されるプロセッサのローカルメモリをマッピングする処理を、前記コンピュータに実行させる手順をさらに具備することを特徴とする請求項１５記載のプログラム。

Images