JP5453825B2 - プログラム並列実行システム、マルチコアプロセッサ上のプログラム並列実行方法 - Google Patents

Description

本発明は、複数のプロセッサコアをバスによって相互結合したマルチコアプロセッサを備えるプログラム並列実行システムとマルチコアプロセッサ上のプログラム並列実行方法に関する。

単一の汎用ＣＰＵだけでは処理能力が不足する場合に用いられている技術としては、専用のハードウェア機構、例えば動画処理ハードウェア等を追加し、あるいは、ＤＳＰ(ディジタルシグナルプロセッサ)や３Ｄグラフィックプロセッサ(ＧＰＵとも称される)等の、用途に特化した演算能力を有する特別なプロセッサを導入し、これらを汎用ＣＰＵと組み合わせて所望の処理を行わせる手法がある。

例えば、ＮＥＣエレクトロニクス社による携帯機器用プロセッサＭＰ２０１は、汎用ＣＰＵであるＡＲＭ９に加え、画像や音声処理用にＤＳＰ（Ｋ６１１）、画像処理用にイメージ・プロセッサ及びローテータを備えており、動画再生の中枢処理をＤＳＰで行わせることで所望の動画再生能力を実現できる。

このように汎用ＣＰＵに加えて、画像や音声処理用にＤＳＰを備える関連技術が、例えば特許文献１に記載されている。

他方、汎用ＣＰＵの能力向上策の一つとして、マルチコア技術の開発が進んでいる。マルチコアプロセッサとは、「コア」と呼ばれる単体ＣＰＵを複数個結合したものであり、複数コアを同時に動かす並列処理によって高い処理能力を実現することができる。

マルチコアプロセッサの例として、ＮＥＣエレクトロニクス社／ＡＲＭ社によるＭＰＣｏｒｅが存在する。ＭＰＣｏｒｅは、ＡＲＭ１１コアを複数個（例えば４個）バス結合してワンチップに収めている。

汎用ＣＰＵ上ではシステム内の多種多様な処理を行えるため、ＯＳ（オペレーティングシステム）を導入して、その上で多数のタスクを切り替えながら実行する形態をとることが通例である。マルチコアプロセッサでは、ＳＭＰ（対称型マルチプロセシング）型のＯＳとして、例えば、Ｌｉｎｕｘはじめとする各種ＵＮＩＸや、マイクロソフト社のＷｉｎｄｏｗｓ等が用いられる。

マルチコアプロセッサ上では、アプリケーションをいくつかの部分に分解して複数コアで並列実行させることにより、アプリケーションの高速処理が可能である。例えば、動画再生アプリケーションにおいて、動画デコード処理を複数タスクで構成し、それらのタスクをＬｉｎｕｘやＷｉｎｄｏｗｓ上で実行開始させると、これらのＯＳが各タスクを各プロセッサコアに配置し、マルチコアを利用した並列処理によって動作再生を高速で行うことができる。

このように複数コアを同時に動かす並列処理によって高い処理能力を実現するマルチコアプロセッサに関する関連技術が、例えば特許文献２に記載されている。

このように、これまでは、単一ＣＰＵで処理能力が不足する場合、専用のハードウェア機構あるいは特別なプロセッサを導入して処理させるか、マルチコア上の並列化アプリケーションとして処理させる、という手法が用いられてきた。

特開２００８−１７６６９９号公報 特開２００７−１４１１５５号公報

特許文献１に記載の関連技術の問題は、専用ハードウェアや特別なプロセッサを導入するためにコストがかかることである。グラフィクスや動画等の用途に応じたハードウェア機構を自ら開発するとその開発コストがかかり、外部から調達するとライセンスの支払いが生じる。また、近年、システムの多様化に伴って多品種少量生産の傾向にあるが、これらの専用ハードウェアないし特別なプロセッサを含むシステムＬＳＩを開発する場合、その生産量が少ないと、開発コストを回収することが難しい場合がある。

特許文献２に記載の関連技術の問題は、汎用ＣＰＵベースのマルチコアでの実行オーバヘッドが高くなることである。汎用ＣＰＵは専用ハードウェアや特別なプロセッサに比べて単体性能に劣るため、所望の性能を実現するには複数コアに処理を分担させる並列処理が必要になる。他方、汎用ＣＰＵは多種多様なタスクを動かすためにＯＳを搭載するのが普通であり、各タスクはＯＳのサービスを介して互いの処理の同期や通信を行う。ここにＯＳ介在によるオーバヘッドが生じ、細かな単位で同期や通信を行おうとするとこのＯＳ介在によるオーバヘッドが無視できず、所望の並列性能を達成できなくなる場合がある。

特許文献２に記載の関連技術の他の問題は、汎用ＣＰＵベースのマルチコアでの実行時間予測が難しい点である。前述の通り汎用ＣＰＵ上には多種多様なタスクが存在し、これらが時分割実行されるため、特定タスクがいつ実行され、どれぐらいの実時間が経過すれば処理完了するのか、予測するのが難しい。これは、一定時間内での処理完了が求められるリアルタイム処理では特に問題になる。

（発明の目的）
本発明の目的は、汎用ＣＰＵベースのマルチコアプロセッサ上でオーバヘッドが少なく、かつ実行時間予測のつきやすい並列実行環境を実現できるプログラム並列実行システム、マルチコアプロセッサ上のプログラム並列実行方法を提供することにある。

本発明の他の目的は、専用ハードウェアや特別なプロセッサを導入するコストを抑えつつ、高い演算処理能力を実現できるプログラム並列実行システム、マルチコアプロセッサ上のプログラム並列実行方法を提供することにある。

本発明によるプログラム並列実行システムは、複数のプロセッサコアをバスによって相互結合したマルチコアプロセッサを備えるプログラム並列実行システムあって、複数のプロセッサコアを、オペレーティングシステムを稼動させ、当該オペレーティングシステム上で第１のアプリケーションプログラムを動作させる第１のグループのプロセッサコアと、オペレーティングシステムを稼動させずに、第１のアプリケーションからの要求によって第２のアプリケーションプログラムを動作させる第２のグループのプロセッサコアに分け、第１のグループのプロセッサコアと第２のグループのプロセッサコアの間の通信を行うことにより、第１のアプリケーションプログラムが、第２のアプリケーションプログラムを実行させ、又は第２のアプリケーションプログラムの処理結果を受け取るための制御を行う制御手段を含む。

本発明によるプログラム並列実行方法は、複数のプロセッサコアをバスによって相互結合したマルチコアプロセッサ上のプログラム並列実行方法であって、複数のプロセッサコアの第１のグループのプロセッサコア上で、オペレーティングシステムを稼動させ、当該オペレーティングシステム上で第１のアプリケーションプログラムを動作させ、複数のプロセッサコアの第２のグループのプロセッサコア上で、オペレーティングシステムを稼動させずに、第１のアプリケーションからの要求によって第２のアプリケーションプログラムを動作させ、第１のグループのプロセッサコアと第２のグループのプロセッサコアの間の通信を行うことにより、第１のアプリケーションプログラムから第２のアプリケーションプログラムを実行させ、又は第１のアプリケーションプログラムからで第２のアプリケーションプログラムの処理結果を受け取るための制御を行う。

本発明によれば、汎用ＣＰＵベースのマルチコアプロセッサ上でオーバヘッドが少なく、かつ実行時間予測のつきやすい並列実行環境を実現できる。

また、専用ハードウェアや特別なプロセッサを導入するコストを抑えつつ、高い演算処理能力を実現できる。

本発明の第１の実施の形態によるプログラム並列実行システムの全体構成を示すブロック図である。 第１の実施の形態によるプログラム並列実行システムにおける軽量スケジューラの内部構成を示すブロック図である。 第１の実施の形態によるプログラム並列実行システムにおけるＯＬタスク表の各エントリの構成例を示す図である。 第１の実施の形態によるプログラム並列実行システムにおけるＯＬリモート制御部の内部構成を示すブロック図である。 第１の実施の形態によるプログラム並列実行システムにおけるＯＬタスク制御の動作を示すフローチャートである。 第１の実施の形態によるプログラム並列実行システムにおけるＯＬタスクの時分割多重制御の動作を示すフローチャートである。 第１の実施の形態によるプログラム並列実行システムにおけるＯＬタスクサービス手段が提供するサービス関数例の一覧を示す図である。 本発明の第２の実施の形態によるプログラム並列実行システムの全体構成を示すブロック図である。 第２の実施の形態によるプログラム並列実行システムにおけるＯＬリモート制御部の内部構成を示すブロック図である。 第２の実施の形態によるプログラム並列実行システムにおける割り当てコア数増減の動作を示す図である。 第1の実施の形態における軽量スケジューラＬＳの実施例を示すブロック図である。 第1の実施の形態におけるＯＬリモート制御部の実施例を示すブロック図である。

次に、本発明の実施の形態について図面を参照して詳細に説明する。

（第１の実施の形態）
図１は、本発明の第１の実施の形態によるプログラム並列実行システムの構成を示すブロック図である。第１の実施の形態によるプログラム並列実行システムは、共有メモリ型のマルチコアプロセッサ上にアプリケーション用ＯＳと軽量スケジューラとを搭載する構成である。

図１を参照すると、第１の実施の形態によるプログラム並列実行システムは、複数のＣＰＵコアを有するマルチコアＳｏＣ（ＳｙｓｔｅｍＯｎＣｈｉｐ（システムオンチップ）；システムＬＳＩとも呼ばれる）１０と、それらのＣＰＵコア上で動作するＡＰ ＯＳ（アプリケーション用ＯＳ）２０および軽量スケジューラＬＳ（ＬｉｇｈｔｗｅｉｇｈｔＳｃｈｅｄｕｌｅｒ）３２と、ＡＰ ＯＳ２０上で動作するアプリケーション（ＡＰ）タスク群２１およびＯＬ（オフロード）リモート制御部２２と、ＬＳ３２上で動作するＯＬタスク群３１と、これらのソフトウェア動作に使用するメモリ５０とを含む。

マルチコアＳｏＣ１０は、同じ種類の複数個のＣＰＵコア（４０、４１、・・・、４ｎ）と、これらのＣＰＵコアの間で割り込みをかけるためのコア間割込機構４５と、メモリ５０を駆動するためのメモリ制御部４７とを含み、これらがＳｏＣバス４６で互いに接続されている。近年の一般的なプロセッサがそうであるように、各ＣＰＵコア内にはＬ１キャッシュ（１次キャッシュ）が含まれている。なお、図１に示したマルチコアＳｏＣは典型的な構成例を示したものであり、図示した構成要素以外の処理ユニット（ＤＭＡコントローラ、グラフィクスプロセッサ、各種Ｉ／Ｏコントローラ等）やローカルメモリを含む構成であっても良い。

マルチコアＳｏＣ１０が有するＣＰＵコア（４０、４１、・・・、４ｎ）は、その利用目的によりＡＰ（アプリケーション）処理用とＯＬ（オフロード）処理用の大きく２つの群に分けられる。ＡＰ（アプリケーション）処理用のＣＰＵコア上ではＡＰ ＯＳ２０として、汎用ＣＰＵ用ＯＳ（例えばＬｉｎｕｘはじめとする各種ＵＮＩＸ ＯＳ、Ｗｉｎｄｏｗｓ等）が動作する。ＡＰタスク群２１を構成する各ＡＰタスク２１０、２１１は、同じくＡＰ ＯＳ２０上で実行されるＯＬリモート制御部２２を介してＯＬ処理用のＣＰＵコアの上で動作しているＯＬタスク群と連係して動作する。

ＯＬ処理用のＣＰＵコア上で動作するＬＳ ３２は、ＯＬタスクの実行制御に特化した、コンパクトなスケジューラであり、その上では１つ以上のＯＬタスク（図１ではＯＬタスク３１０、３１１の２つが動作している例を示している）が動作している。このＬＳ３２は、単に機能を限定した小型のＯＳという位置づけではなく、共有メモリ型マルチコアプロセッサであることを活かし、ＬＳ３２とＯＬリモート制御部２２とにスケジューリング機能を分担させていることが、本実施の形態における特徴の一つである。

ＯＬタスク３１０、３１１は、各々が１つ以上のスレッドで構成されるマルチスレッドタスクである。ＯＬタスク３１０、３１１は、実行時にＬＳ３２に割り当てられるＯＬ処理用のＣＰＵコアの数と同じか、それ未満の数のスレッドが同時に存在するように設計されたアプリケーションプログラムであり、ＬＳ３２が複数のＯＬタスク間をギャングスケジューリング方式で時分割切り替えを行いながら実行する。ここで、ギャングスケジューリング方式とは、必要な数の物理コアすべてを一度に確保しタスク切り替えを行う方式である。

なお、ＡＰ処理用ＣＰＵコアとＯＬ処理用ＣＰＵコアについては、各々１つ以上であればよい。

次に、図１における軽量スケジューラＬＳ３２の内部構成について、図２を参照して詳しく説明する。

軽量スケジューラＬＳ３２は、複数のＯＬタスクを時分割で切り替えながら実行するための時分割多重化部１１０と、ＡＰ処理用ＣＰＵコア側との通信を行う対ＡＰ通信部１２０と、存在するＯＬタスクを管理するためのＯＬタスク表１６０と、現在実行中のＯＬタスクを示すカレントＯＬタスク変数１５０と、現在実行待機中のＯＬタスクを示すＯＬタスクキュー１４０と、ＯＬタスク表操作時の排他制御に用いるＯＬタスク表ロック変数１７０とを含んでいる。

時分割多重化部１１０は、所定の時間が経過したことを通知するタイマ１１１と、タイマ１１１からの通知によりＯＬタスクの切り替えを行う時分割多重化制御部１１２を備える。また、対ＡＰ通信部１２０は、ＡＰ側からの通信を受けるＬＳ側受信部１２１と、ＡＰ側への通信を発するＬＳ側送信部１２２を備える。

ＬＳ３２には、時分割多重化制御部１１２、ＬＳ側受信部１２１、およびＯＬタスク３１０、３１１から呼び出される各種の手段がある。この呼び出される各種の手段としては、これまで実行してきたＯＬタスクのコンテキストを退避するコンテキスト退避手段１３１と、これから実行しようとするＯＬタスクのコンテキストを復活させＯＬタスクを再開させるコンテキスト復活手段１３２と、ＯＬタスクキュー１４０の中から、次に実行しようとするＯＬタスクを選びだす新コンテキスト選定手段１３３と、ＡＰ側からの指示に基き、ＯＬタスクの開始や終了の制御を行うＯＬタスク制御手段１３４と、ＯＬタスク内のスレッド間通信やキャッシュ制御、ＯＬタスクの終了要求を処理するＯＬタスクサービス手段１３５とがある。

ここで、ＯＬタスクサービス手段１３５がＯＬタスク向けに提供するサービス関数の例を図７に示す。これらはマルチコアＳｏＣ１０内のＣＰＵコア（４０、４１、４２）が持つ機械命令、たとえば、ＣＰＵレジスタが持つ１ワードとメモリ上の１ワードをアトミックに交換するエクスチェンジ命令（ＸＣＨＧ等と表記されることが多い）や、ＣＰＵコアに付属のコプロセッサが持つキャッシュ制御命令等を用いることで、容易に実現できるサービス関数である。プログラマはこれらのサービス関数を用いてＯＬプログラムを開発する。また、必要に応じ、これらのサービス関数をインライン関数として実装することで、実行時オーバヘッドをより少なくすることができる。

ＯＬタスク表１６０には、１つのＯＬタスク毎に１つのエントリ（ＯＬタスク表エントリ）が登録される。このＯＬタスク表エントリは、図３に示すようなフィールドを有する。図３において、ＯＬタスク表エントリが有するフィールドは、ＯＬタスクを互いに一意に識別するための整数値を設定するＯＬタスクＩＤフィールド１６１、そのＯＬタスクを生成したＡＰタスクのＩＤフィールド１６３及びそのＡＰタスクが動作しているＯＳの識別ＩＤを設定するＡＰ ＯＳ ＩＤフィールド１６２、そのＯＬタスクが動作しているのか止まっているのか等を示す情報を設定するステータスフィールド１６４、そのＯＬタスクが使っている全レジスタや特殊レジスタ等を設定するコンテキストフィールド１６５、そのＯＬタスクの連続実行時間を規定するタイムスライスフィールド１６６、そのＯＬタスクとＡＰタスクとの間の同期をとるためのセマフォフィールド１６７、ならびに、そのＯＬタスクのプログラムメモリ領域や作業メモリ領域に関する情報を保持するメモリ領域情報フィールド１６８である。

ここで、ＡＰ ＯＳ ＩＤフィールド１６２は、図１におけるＡＰ ＯＳ２０を識別する整数値である。図１の例ではＡＰ ＯＳ２０はシステム内にただ一つしか存在しないのでこのＩＤの必要性はないが、マルチコアＳｏＣ１０が多数のＣＰＵコアを有し、その上で複数のＡＰ ＯＳ２０が稼動するようになったときに備え、図３のようにＡＰ ＯＳ２０を識別するＩＤを登録する。

また、ＡＰタスクＩＤフィールド１６３は、そのＡＰ ＯＳ２０内で複数のタスクを識別するためのＩＤであればよく、通常は当該ＯＳが使用しているタスクＩＤをそのまま用いる。

対ＡＰ通信部１２０は、後述するＡＰ側の対ＬＳ通信部２４０と対向接続される。

次に、図１においてＡＰ ＯＳ２０上に位置するＯＬリモート制御部２２の内部構成について、図４を用いて詳しく説明する。

ＯＬリモート制御部２２内部には、ＡＰタスクがＯＬタスクの制御するためのインタフェースとなるＡＰタスク向けインタフェース部２３０と、ＯＬ処理用ＣＰＵコア側との通信を行う対ＬＳ通信部２４０が含まれる。

また、ＡＰタスク向けインタフェース部２３０は、ＡＰタスクから呼び出されることを想定した、ＯＬ処理用ＣＰＵコア上でＬＳ３２が動作できるように初期設定を行うＬＳ初期化手段２３１、それによって稼働中のＬＳ３２上に新しくオフロード処理のプログラムをロードし実行可能な状態にセットアップするＯＬプログラムセットアップ手段２３２、ＯＬプログラムセットアップ手段２３２でセットアップしたＯＬプログラムの実行開始させるＯＬタスク開始手段２３３、ＯＬタスク開始手段２３３で開始したＯＬタスクの終了を待ち合わせるＯＬタスク終了待ち手段２３４、ＯＬタスク側の自主的な終了を待たず、強制的に終了させるためのＯＬタスク強制終了手段２３５、一旦終了したＯＬタスクを再ロードせずに初期状態に戻すＯＬタスク再初期化手段２３６、ロードしたＯＬプログラムを破棄してリソースを解放するＯＬプログラム破棄手段２３７、の各手段を含む。

対ＬＳ通信部２４０は、それぞれＬＳ側への送信とＬＳ側からの受信を行う、ＡＰ側送信部２４１、ＡＰ側受信部２４２から構成され、それぞれＬＳ側受信部１２１、ＬＳ側送信部１２２と対向接続される。

（第１の実施の形態の動作の説明）
次に、図５および図６のフロー図を参照して本実施の形態の全体動作について詳細に説明する。

まず、図５を参照して、ＡＰタスク（０）２１０がＯＬタスク（０）３１０を実行する一連の動作を例にとって説明する。

最初は、ＯＬ処理用ＣＰＵコアの上で軽量スケジューラＬＳ３２が動作していない状態である。

ここで、ＡＰタスク（０）２１０がＯＬリモート制御部２２内にあるＡＰタスク向けインタフェース部２３０のＬＳ初期化手段２３１を呼び出すと（ステップＳ１０１）、ＬＳ初期化手段２３１は、ＬＳ３２のプログラムをＯＬ処理用ＣＰＵコアがアクセス可能なメモリ領域にロードする（ステップＳ１０２）と共に、各々のＯＬ処理用ＣＰＵコアに対してＬＳ３２のプログラムのエントリ番地から実行を開始するよう指示する（ステップＳ１０３）。

ＬＳ３２がエントリ番地から実行を開始すると、ＬＳ３２は、ＯＬ処理用ＣＰＵコアのうちの１コアがＯＬタスク表１６０、ＯＬタスクキュー１４０、カレントＯＬタスク変数１５０の初期化を行った後（ステップＳ１０４）、ＡＰ側からの指示待ち状態となる（ステップＳ１０５）。ＯＬ処理用コアの他のＣＰＵコアは、すみやかにＡＰ側からの指示待ち状態となる。

ここで、ＡＰタスク（０）２１０がＯＬリモート制御部２２内にあるＡＰタスク向けインタフェース部２３０のＯＬプログラムセットアップ手段２３２を呼び出すと（ステップＳ１０６）、ＯＬプログラムセットアップ手段２３２は、ＯＬタスク表ロック変数１７０をロックしてＯＬタスク表１６０への排他的アクセス権を取得し、ＯＬタスク（０）３１０をＯＬ処理用ＣＰＵコアがアクセス可能なメモリ領域にロードすると共に、ＯＬタスク（０）３１０の処理用の作業メモリ領域を確保する（ステップＳ１０７）。続いて、ＯＬプログラムセットアップ手段２３２は、ＯＬタスク表１６０に新たなＯＬタスク表エントリを作成し、そのＯＬタスク表エントリの各フィールドを以下のように設定する（ステップＳ１０８）。

（Ａ） ＯＬタスクＩＤフィールド１６１＝ＯＬプログラムセットアップ手段２３２がＯＬタスク（０）３１０に割り当てたユニークな値。
（Ｂ） ＡＰ ＯＳ ＩＤフィールド１６２＝ＡＰタスクが動作しているＯＳの種類を識別する値。
（Ｃ） ＡＰタスクＩＤフィールド１６３＝ＡＰタスク（０）２１０のＡＰ ＯＳ内でのタスクＩＤ。
（Ｄ） ステータスフィールド１６４＝初期状態。
（Ｅ） メモリ領域情報フィールド１６８＝ＯＬタスク（０）３１０をロードしたメモリ領域および作業メモリ領域の情報。

続いて、ＯＬプログラムセットアップ手段２３２は、ＯＬタスク表ロック変数１７０をアンロックして排他的アクセス権を解放し、ＯＬタスクＩＤフィールド１６１の値を戻り値として呼び出し元のＡＰタスク（０）２１０に制御を戻す。このＯＬタスクＩＤフィールド１６１の値はＡＰタスク（０）２１０内部で保持され、以後のＡＰタスク向けインタフェース部２３０内の各手段を呼び出す際に引数として渡される。

次に、ＡＰタスク（０）２１０が設定したＯＬタスクＩＤフィールド１６１の値を引数としてＡＰタスク向けインタフェース部２３０のＯＬタスク開始手段２３３を呼び出すと（ステップＳ１０９）、ＯＬタスク開始手段２３３は、ＯＬタスク表１６０から設定したＯＬタスクＩＤフィールド１６１の値に該当するエントリを探し出し、そのエントリ内の次のフィールドを、次のように設定する（ステップＳ１１０）。

（Ａ） コンテキストフィールド１６５＝ＯＬタスク（０）３１０を開始するためのレジスタ値。
特に、プログラムカウンタについてはＯＬタスク（０）３１０のエントリ番地とし、もし必要ならスタックポインタやデータポインタとして確保したＯＬタスク用作業メモリ領域内の適切なアドレス値を与える。
（Ｂ） タイムスライスフィールド１６６＝ＯＬタスク（０）３１０の連続実行時間をタイマ１１１の動作周期（動作周波数の逆数）で割った値。
この連続実行時間を越えてＯＬタスクが実行を続けると、時分割多重化制御部１１２によって一旦処理を中断されることになる。ＯＬ処理用ＣＰＵコア上で複数のＯＬタスクが同時に動作する場面では、より優先的に処理したいＯＬタスクにより長めの連続実行時間を与えることで、それらのＯＬタスク間に優先度をつけることができる。
（Ｃ） セマフォフィールド１６７＝初期値ゼロ。

これらのフィールドを設定後、ＯＬタスク開始手段２３３は、対ＬＳ通信部２４０のＡＰ側送信部２４１を通じてＯＬタスクＩＤ値および処理要求種別「ＯＬタスク開始」の情報をＬＳ３２側に送る（ステップＳ１１１）。ＡＰ処理用ＣＰＵコアは、ここで呼び出し元のＡＰタスク（０）２１０に制御を戻す。

他方、ＬＳ３２側のＬＳ側受信部１２１は、ＡＰ側送信部２４１から送信された情報を受け取り、処理要求種別が「ＯＬタスク開始」であることを知り、それに対応した処理として、次の処理を行う。すなわち、ＯＬタスク表１６０から指定されたＯＬタスクＩＤ値に該当するエントリを探し出し、そのエントリ内のステータスフィールド１６４を「実行中状態」に設定し、ＯＬ処理用の全ＣＰＵコア間の同期（バリア同期）をとったうえで、ＯＬタスク表１６０のエントリ内のコンテキストフィールド１６５の値をＯＬ処理用の各ＣＰＵコアのレジスタに設定してコンテキストを復活させる（ステップＳ１１２）。

これにより、以後、ＡＰ処理用ＣＰＵコアではＡＰタスク（０）２１０の後続処理、ＯＬ処理用ＣＰＵコアではＯＬタスク（０）３１０の処理（ステップＳ１１３）が、並列して行われる。

次に、ＡＰタスク（０）２１０は、開始したＯＬタスク（０）３１０の終了を待ち合わせるため、ＯＬタスク（０）３１０のＯＬタスクＩＤ値を引数としてＡＰタスク向けインタフェース部２３０のＯＬタスク終了待ち手段２３４を呼び出す（ステップＳ１１４）。そして、ＯＬタスク終了待ち手段２３４は、ＯＬタスク表１６０から上記ＯＬタスクＩＤ値に該当するエントリを探し出し、そのエントリ内のセマフォフィールド１６７に対してセマフォＤＯＷＮ操作（ｓｅｍ＿ｄｏｗｎ）を行う（ステップＳ１１５）。

他方、ＯＬタスク（０）３１０側は、その処理結果を、ＡＰタスク（０）２１０とＯＬタスクとの間で共有されているメモリ５０上の領域に格納した後（ステップＳ１１６）、ＬＳ３２のＯＬタスクサービス手段１３５に対しＯＬタスク終了要求を送る（ステップＳ１１７）。

すると、ＬＳ３２のＯＬタスクサービス手段１３５は、カレントＯＬタスク変数１５０の値からＯＬタスク表１６０内のエントリを特定し、そのエントリ内のステータスフィールド１６４を「終了状態」に設定する。さらに、ＯＬタスクサービス手段１３５は、ＯＬタスク表１６０のエントリ内のＡＰ ＯＳ ＩＤフィールド１６２の値を元に当該ＯＬタスク（０）３１０を起動したＡＰタスク（０）２１０が動作しているＡＰ ＯＳを特定し、ＬＳ側送信部１２２を通じてＡＰ ＯＳ２０に対し、ＯＬタスクＩＤ値（ＯＬタスク表１６０のエントリ内のＯＬタスクＩＤフィールド１６１の値）および処理要求種別「ＯＬタスク終了」の情報を送る（ステップＳ１１８、Ｓ１１９）。

すると、対ＬＳ通信部２４０のＡＰ側受信部２４２がこの情報を受け取り、処理要求種別が「ＯＬタスク終了」であることを知り、それに対応した処理として、次の処理を行う。すなわち、ＯＬタスク表１６０から指定されたＯＬタスクＩＤ値に該当するエントリを探し出し、そのエントリ内のセマフォフィールド１６７に対してセマフォＵＰ操作（ｓｅｍ＿ｕｐ）を行う（ステップＳ１２０）。

これら２つのセマフォ操作により、ＡＰタスク（０）２１０とＯＬタスク（０）３１０とが同期され、ＡＰタスク（０）２１０はセマフォＤＯＷＮ操作の直後から動作を再開する。ＡＰタスク（０）２１０は、メモリ５０上の共有領域からデータを読み出すことで、ＯＬタスク（０）３１０にオフロードさせた処理の結果を取得する（ステップＳ１２１）。

ここで、ＡＰタスク（０）２１０がＯＬタスクＩＤ値を引数としてＡＰタスク向けインタフェース部２３０のＯＬタスク強制終了手段２３５を呼び出すと、ＯＬタスク強制終了手段２３５は、次の段階に沿って、実行中のＯＬタスクを強制的に終了させることを試みる。

第１段階として、通信によってＯＬタスク強制終了要求をＬＳ３２側に伝える。具体的には、ＯＬタスク（０）３１０のＯＬタスクＩＤ値および処理要求種別「ＯＬタスク強制終了」の情報をＡＰ側送信部２４１を通じてＬＳ３２側に送る。ＬＳ３２側ではＬＳ側受信部１２１がこの要求を受け、処理要求種別が「ＯＬタスク強制終了」であることを知り、ＯＬタスク表１６０およびＯＬタスクキュー１４０から当該ＯＬタスク（０）３１０に相当するエントリを削除する。

もし、ＯＬタスクの暴走等の原因でＬＳ３２側が正常に機能しない場合、第２段階として、ＡＰタスク向けインタフェース部２３０のＯＬタスク強制終了手段２３５は、ＯＬ処理用の各ＣＰＵコアに対してリセットをかけることでＯＬタスクを止める。この場合、ＯＬ処理用ＣＰＵコアでＯＬタスク（０）３１０以外のＯＬタスクが実行中であると、それらも含めてすべて止められてしまう。従って、第１段階の仕組みでの強制終了を試みるのが優先であって、この第２段階の処置は非常用に限定すべきである。

また、ＡＰタスク（０）２１０がＯＬタスク（０）３１０のＯＬタスクＩＤ値を引数としてＡＰタスク向けインタフェース部２３０のＯＬタスク再初期化手段２３６を呼び出すと、ＯＬタスク再初期化手段２３６はＯＬタスク表ロック変数１７０をロックしてＯＬタスク表１６０への排他的アクセス権を得てから、ＯＬタスク表１６０内の当該ＯＬタスクのエントリを探し出し、そのエントリ内のステータスフィールド１６４を「初期状態」に設定し、ＯＬタスク表ロック変数１７０をアンロックする。これにより、当該ＯＬタスク（０）３１０は初期状態に戻り、以後ＡＰタスク（０）２１０がＯＬタスク開始手段２３３を呼び出せば、再び当該ＯＬタスク（０）３１０を実行することができるようになる。

最後に、ＡＰタスク（０）２１０がＯＬタスクＩＤ値を引数としてＡＰタスク向けインタフェース部２３０のＯＬプログラム破棄手段２３７を呼び出すと（ステップＳ１２２）、ＯＬプログラム破棄手段２３７はＯＬタスク表ロック変数１７０をロックしてＯＬタスク表１６０への排他的アクセス権を得てから、ＯＬタスク表１６０内の当該ＯＬタスクのエントリを探し出す。次に、ＯＬプログラム破棄手段２３７は、そのＯＬタスク表エントリ内のメモリ領域情報の値を元に当該ＯＬタスク用に確保したメモリ領域を開放する。さらにＯＬプログラム破棄手段２３７は、そのＯＬタスク表エントリをＯＬタスク表１６０から削除し、最後にＯＬタスク表ロック変数１７０をアンロックして排他的アクセス権を返上する（ステップＳ１２３）。

図５には、ＡＰタスク（０）２１０がＯＬタスクＩＤ値を引数としてＡＰタスク向けインタフェース部２３０のＯＬプログラム破棄手段２３７を呼び出した場合の動作を示している。

ここで、ＯＬリモート制御部２２と軽量スケジューラＬＳ３２との間の通信の動作について説明する。

この通信の内部構造は本実施の形態の本質的な特徴ではなく、指定した通信相手ＣＰＵコアに２つの固定長整数値を伝え、その相手ＣＰＵコア側で事前登録されたハンドラを呼び出すことができれば、任意の通信方式を用いることができる。１つの実現方法として、図１に示したコア間割込機構４５とメモリ５０上のコア間共有メモリ領域を用い、相手に伝達すべき整数値を共有メモリ領域に格納してからコア間割込機構４５によって相手コアに割り込みを発生させ、相手コアの割込みハンドラにて共有メモリ領域に格納された値を読み出し、その値を引数として、事前登録されたハンドラ関数を呼び出す、という仕組みが考えられる。

次に、図６および図２を参照して、ＯＬ処理用ＣＰＵコア上で複数のＯＬタスクが存在する場合の時分割多重処理の動作について説明する。ここでは、ＯＬタスク（０）〜（２）の３タスクが存在し、現在ＯＬタスク（０）が実行中である、という事例を用いて説明する。

現在、ＯＬタスク（０）が実行中であるため、時分割多重化部１１０のタイマ１１１にはＯＬタスク（０）のタイムスライス値が初期値として設定されている。所定の時間が経過するとデクリメントしているタイマ１１１のカウンタがゼロに到達し（ステップＳ２０１）、タイマ１１１がその旨を時分割多重化部１１０の時分割多重化制御部１１２に通知する（ステップＳ２０２）。

時分割多重化制御部１１２は、まずコンテキスト退避手段１３１を呼び出す。コンテキスト退避手段１３１はカレントＯＬタスク変数１５０をチェックする。そして、カレントＯＬタスク変数１５０に有効なＯＬタスクが格納されていれば、これまで各ＯＬ処理用ＣＰＵコアで実行していたＯＬタスク（０）のレジスタ等のコンテキスト一式を、ＯＬタスク（０）に対するＯＬタスク表１６０のエントリにおけるコンテキストフィールド１６５に格納する（ステップＳ２０３）。

次に、時分割多重化制御部１１２は、新コンテキスト選定手段１３３を呼び出し、次に実行すべきＯＬタスクを決める。選定方法については種々考えられるが、ここでは単純なＦＩＦＯ方式による方法を説明する。すなわち、新コンテキスト選定手段１３３は、ＯＬタスクキュー１４０の先頭にあるＯＬタスクを次のコンテキストとして選定する（ステップＳ２０４）。図６の例ではＯＬタスク（１）が選定されることになる。新コンテキスト選定手段１３３は、選定したＯＬタスク（１）をＯＬタスクキュー１４０から取り除き、カレントＯＬタスク変数１５０に設定する。

次に、時分割多重化制御部１１２は、コンテキスト復活手段１３２を呼び出す。コンテキスト復活手段１３２は、カレントＯＬタスク変数１５０が指し示すＯＬタスク表１６０のＯＬタスク（１）に対するエントリを参照し、その中のタイムスライスフィールド１６６の値をタイマ１１１に設定すると共に（ステップＳ２０５）、ＯＬタスク表エントリのコンテキストフィールド１６５の内容に従って各ＯＬ処理用コアのレジスタ等を設定する。最後に全ＯＬ処理用コア間で同期を取った上で、レジスタコンテキストでの実行を開始する。これにより、ＯＬタスク（１）のコンテキストが再開されることになる（ステップＳ２０６）。

その後、上記で設定したタイムスライス分の時間が経過するとタイマ１１１のカウンタがゼロに到達し（ステップＳ２０７）、上述したタイマ１１１から時分割多重化制御部１１２への通知（ステップＳ２０８）、ならびに時分割多重化制御部１１２によるコンテキスト切替動作が繰り返される（ステップＳ２０９〜Ｓ２１２）。

上記コンテキスト退避手段１３１にて、カレントＯＬタスク変数１５０に有効なＯＬタスクが格納されていない場合は、退避すべきコンテキストは存在しないものとみなす。その場合、時分割多重化制御部１１２は、コンテキスト退避処理は行わず、その次の新コンテキスト選定手段１３３の呼び出しへ進む。

また、上記新コンテキスト選定手段１３３にて、ＯＬタスクキュー１４０が空である場合は、新コンテキストは存在しないことから、カレントＯＬタスク変数１５０には無効値（ＮＵＬＬ等）を設定する。その場合、後続のコンテキスト復活手段１３２では、タイマ１１１の設定も新コンテキストの各ＯＬ処理用コアレジスタへの設定も行わない。各ＯＬ処理用コアはそのまま停止状態に移行し、その後ＡＰ処理用コア側からのＯＬタスク開始等が通知されてくるのを待つことになる。

以上が複数のＯＬタスクを時分割多重化して制御する動作の説明であり、その具体的なフローの例が図６に示されている。

ＯＬ処理用ＣＰＵコアは一般には複数存在するが、これらの複数のＣＰＵコアは、ＡＰタスク側からのタスク開始指示（ＯＬタスク開始手段２３３参照）やタイマ１１１のゼロ到達（タイマ１１１から時分割多重化手段１１２への通知参照）を契機として、ＯＬタスク処理からＬＳ処理へ、あるいはＬＳ処理からＯＬタスク処理へと、全ＣＰＵコアが一斉に切り替わる。これはいわゆるギャングスケジューリングであり、ＯＬ処理用ＣＰＵコアできめ細かい並列処理を有効に行うための本実施の形態の特徴の１つである。

（第１の実施の形態による効果）
次に、上述した第１の実施の形態による効果について説明する。

本実施の形態では、マルチコアＳｏＣ１０（マルチコアプロセッサ）の複数のＣＰＵコアをＡＰ処理用ＣＰＵコアとＯＬ処理用ＣＰＵコアの２つのグループに分け、一方のＡＰ処理用ＣＰＵコアに一般的なアプリケーション用のＡＰ ＯＳ２０を動作させ、他方のＯＬ処理用ＣＰＵコアに軽量スケジューラＬＳ３２を載せることで、ＣＰＵコアやキャッシュ機能等のハードウェアリソースを最大限に活用した特定用途のプログラム（ＯＬタスク）を、ＯＳ用アプリケーションと同時に走らせることができる。特定用途プログラムであるＯＬタスクは、ハードウェアリソースを直接アクセスし、かつそれらのハードウェアリソースのＯＬタスクへの割当時間を指示できるため、実行時のオーバヘッドを少なくでき、実行時間予測が容易になる。これにより、相互に密に連携して動作する複数のスレッドを効率よく実行させることが可能となる。

すなわち、ＯＬ処理用ＣＰＵコアで動作するＯＬタスクはＡＰ ＯＳ２０からの影響を受けず、物理的なＣＰＵコア上での実行に極めて近い形態で動作することになり、オーバヘッドが少なく実行時間を予測しやすい並列実行環境が実現される。

また、本実施の形態では、ＡＰ処理用コアとＯＬ処理用コアの分割点を変えることで、ＡＰ処理とＯＬ処理の性能比率を任意に変更可能であるため、ＳｏＣに対する要求性能の異なるいくつかのシステムに対して、同じ種類のマルチコアＳｏＣを適用することが可能である。これにより、ＳｏＣ開発コストの低減とシステム開発日程の短縮という効果を実現できる。

すなわち、要求される処理能力に応じて、マルチコアプロセッサ上のＣＰＵコアの割り当てをソフトウェアによって変更可能とすることにより、システム仕様に応じて静的に、ＣＰＵコアのリソースを処理要求に割り当てることができる。この結果、スペックの異なる複数種類のシステムＬＳＩで対応していたシステムを一種類のマルチコアシステムＬＳＩで実現すること、あるいは、ある一製品において要求性能の異なる多様な動作モードを一種類のマルチコアシステムＬＳＩで実現できる。これにより、システムＬＳＩの販売可能性を高めることで生産量増加を促し、システムＬＳＩへの開発投資を回収しやすくなる。

（第２の実施の形態）
次に、本発明の第２の実施の形態によるプログラム並列実行システムについて図面を参照して詳細に説明する。

図８および図９を参照すると、第２の実施の形態は、第１の実施の形態に加えて、コアの割り当てを動的に変更するための仕組みを導入したものである。

図８を参照すると、第２の実施の形態においては、ＡＰ ＯＳ２０に、ＡＰ ＯＳ２０が使用するＣＰＵコアを変更するための稼動コア制御部２０１を備えると共に、ＡＰ ＯＳ ２０自体にＣＰＵのホットプラグ（ＨｏｔＰｌｕｇ）機能を備えている点が第１の実施の形態と異なっている。

ＣＰＵのホットプラグ機能とは、マルチコアプロセッサ内のいくつかのＣＰＵコア上であるＯＳが稼動している場合に、そのＯＳを終了あるいは再起動させることなく、そのＯＳの使用するＣＰＵコア群に新たなＣＰＵコアを追加したり、あるいはそのＯＳが使用中のＣＰＵコア群から一部のＣＰＵコアを取り除くことができる機能である。例えばＬｉｎｕｘにはＣＰＵホットプラグ機能を有する実装が存在する。

また、図９を参照すると、ＯＬリモート制御部２２は、第１の実施の形態に加え、ＡＰ ＯＳ２０と軽量スケジューラＬＳ３２が使用するＣＰＵコアの変更指示を行うための動的コンフィギュレーション変更部２３８を備えている。

第２の実施の形態におけるその他の構成要素については、図１に示した第１の実施の形態と同様であるので、同一の参照符号を付して説明を省略する。

（第２の実施の形態の動作の説明）
図１０を参照してＣＰＵコア割り当ての動的変更処理について説明する。

まず、はじめの状態では、図１０（Ａ）に示すように全ＣＰＵコア（ＡＰコア（０）〜（３））を使ってＡＰ ＯＳ２０が稼動している。ここで、動的コンフィギュレーション変更部２３８が、２つのＣＰＵコアを使ってＬＳを稼動させることを決めたとする。

すると、動的コンフィギュレーション変更部２３８は、ＡＰ ＯＳ２０内の稼動コア制御部２０１に対し、ＡＰ ＯＳ２０が使用中のＣＰＵコアのうちの２つを開放するよう指示する。

稼動コア制御部２０１は、ＣＰＵホットプラグ機能によりＡＰコア（２）とＡＰコア（３）の２つのＣＰＵコアをＡＰ ＯＳ２０から切り離し、これら２つのＣＰＵコアを停止させる。この状態が図１０（Ｂ）に示す状態である。

次に、動的コンフィギュレーション変更部２３８は、ＯＬリモート制御部２２が備えるＬＳ初期化手段２３１を呼び出して、切り離して停止させた２つのＣＰＵコア上で軽量スケジューラＬＳ３２が動作するよう、初期化処理を行う。この結果が図１０（Ｃ）に示された状態である。

このようにして、ＡＰ ＯＳ２０を稼動させたまま、ＣＰＵコア２つを使用するＬＳ３２を新たに稼動させることができる。

逆に、図１０（Ｃ）の状態にて、動的コンフィギュレーション変更部２３８が、ＬＳを停止させて全ＣＰＵコアをＡＰ ＯＳ２０で利用することを決めたとする。

すると、動的コンフィギュレーション変更部２３８は、まず、必要であればＯＬリモート制御部２２が持つＯＬタスク強制終了手段２３５を呼び出した上で、ＯＬリモート制御部２２が持つＯＬプログラム破棄手段２３７を呼び出してＬＳ３２およびその上で動作していたＯＬタスク等一式を停止、破棄させる。その状態が図１０（Ｂ）に示す状態である。

次に、動的コンフィギュレーション変更部２３８は、ＡＰ ＯＳ２０内の稼動コア制御部２０１に対し、ＡＰ ＯＳ２０が使用中のＣＰＵコア群に、上述の操作で停止させた２つのＣＰＵコアを追加する指示を送る。

稼動コア制御部２０１は、ＣＰＵホットプラグ機能によりこの２つのＣＰＵコア（ＡＰコア（２）、ＡＰコア（３））を追加し、ＡＰ ＯＳ２０が全ＣＰＵコアを使って稼動するように設定する。この結果が図１０（Ａ）に示された状態である。

このようにして、ＡＰ ＯＳ２０を稼動させたまま、ＬＳ３２に割り当てられていたＣＰＵコアの２つをＡＰ ＯＳ２０側に割り当て直すことができる。

上記説明では、全部で４つのＣＰＵコアを有するマルチコアＳｏＣ１０にて、初期状態で全４コアをＡＰ ＯＳ２０に割り当て、次に、そのうち２コアをＬＳ３２に割り当て、そして再び全４コアをＡＰ ＯＳ２０に割り当てる、という例を示した。しかし、この例に限定されるものではなく、任意のｎ個のＣＰＵコアを有するマルチコアＳｏＣ１０において、そのうちの１個以上（ｎ−１）個以下のＣＰＵコアをＬＳ３２に割り当てる場合にも上記のＣＰＵコア割り当ての動的変更処理をそのまま適用することが可能である。

また、必要がなければ一部のＣＰＵコアをＡＰ処理用にもＯＬ処理用にも割り当てずに停止させておくことで、マルチコアＳｏＣ１０全体の消費電力を低減することもできる。

（第２の実施の形態の効果）
次に、上述した第２の実施の形態による効果について説明する。

上述した第２の実施に形態によれば、第1の実施の形態による効果に加えて、システムを稼動させたまま、その処理性能要求の動的変化に応じてＯＬ処理用コアを割り当ててＯＬタスクを走らせ、また、当該処理要求がなくなれば全コアをＡＰ ＯＳ用に割り当てることができ、マルチコアプロセッサが有する能力をより柔軟に引き出すことが可能になる。これにより、一つの種類のマルチコアシステムＬＳＩを多様なシステムに適用することが可能になるという効果が実現される。

次に、プログラム並列実行システムの具体的な実施例について図面を参照して説明する。この実施例は、第１の実施の形態におけるＬＳ３２とＯＬリモート制御部２２が具体的にどのように構成されるかを示している。

図１１は、ＬＳ３２の実施例を示すブロック図である。点線３２１で囲まれた部分はマルチコアＳｏＣ１０内のハードウェアで実現される。すなわち、タイマ１１１はＣＰＵコアに付随するハードウェアタイマであり、対ＡＰ通信部１２０において通信を行う基盤部分はコア間割込機構４５と受け渡すパラメータを保持するメモリ上のパラメータ領域１２３で実現される。

点線３２２で囲まれた部分はＣＰＵコア上のソフトウェアとして実現される。時分割多重化制御部１１２はタイマ割込みハンドラ、ＬＳ側受信部１２１はコア間割込ハンドラを用いて実現される。時分割多重化制御部１１２が取り扱うコンテキストは、ＣＰＵコアの汎用レジスタ一式とステータスフラグである。

点線３２３で囲まれた部分はメモリ５０上のデータ構造や変数として実現される。これらのデータ構造は、表、キュー（ＦＩＦＯ）等、コンピュータ処理においてごく一般的な構造である。ＯＬタスクキュー１４０についてはＡＰ処理用コア側からはアクセスされないので、ＯＬタスクキュー１４０をＯＬ処理用コアのローカルメモリ上に配置して、同データ構造に対するメモリアクセス性能を改善することも可能である。

図１２はＯＬリモート制御部２２の実施例を示すブロック図である。ＡＰタスク向けインタフェース部２３０内の各手段２３１〜２３７はＡＰ処理用コアのソフトウェアとして記述される。これらはライブラリの形態にとりまとめられ、アプリケーションプログラムにリンクされて呼び出される。対ＬＳ通信部２４０は前述の対ＡＰ通信部１２０と同様、その基盤部分はコア間割込機構４５と受け渡すパラメータを保持するメモリ上のパラメータ領域１２３で実現される。

以上好ましい実施の形態と実施例をあげて本発明を説明したが、本発明は必ずしも、上記実施の形態及び実施例に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。

本発明は、同じ種類のプロセッサコアを複数有するマルチコアプロセッサを用いた情報処理装置であって、特に、高い演算能力やリアルタイム性を要する処理とそれ以外の汎用処理がシステム内に混在するような装置、例えば、携帯電話、カーナビゲーションシステム、セットトップボックス、ネットワーク制御機器等のシステムソフトウェアに適用できる。また、同じ種類のＣＰＵコアを複数有するマルチコアプロセッサを搭載したパーソナルコンピュータや汎用コンピュータシステムに適用することもできる。

１０：マルチコアＳｏＣ
２０：ＡＰ ＯＳ
２１：ＡＰタスク群
２２：ＯＬリモート制御部
３１：ＯＬタスク群
３２：ＬＳ（軽量スケジューラ）
４０、４１、４２：ＣＰＵコア
４５：コア間割込機構
４６：ＳｏＣバス
４７：メモリ制御部
５０：メモリ
１１０：時分割多重化部
１１１：タイマ
１１２：時分割多重化制御部
１２０：対ＡＰ通信部
１２１：ＬＳ側受信部
１２２：ＬＳ側送信部
１２３：パラメータ領域
１３１：コンテキスト退避手段
１３２：コンテキスト復活手段
１３３：新コンテキスト選定手段
１３４：ＯＬタスク制御手段
１３５：ＯＬタスクサービス手段
１４０：ＯＬタスクキュー
１５０：カレントＯＬタスク変数
１６０：ＯＬタスク表
１７０：ＯＬタスク表ロック変数
２０１：稼動コア制御部
２３０：ＡＰタスク向けインタフェース部
２３１：ＬＳ初期化手段
２３２：ＯＬプログラムセットアップ手段
２３３：ＯＬタスク開始手段
２３４：ＯＬタスク終了待ち手段
２３５：ＯＬタスク強制終了手段
２３６：ＯＬタスク再初期化手段
２３７：ＯＬプログラム破棄手段
２３８：動的コンフィギュレーション変更部
２４０：対ＬＳ通信部
２４１：ＡＰ側送信部
２４２：ＡＰ側受信部

Claims (16)

1. 複数のプロセッサコアをバスによって相互結合したマルチコアプロセッサを備えるプログラム並列実行システムあって、
   前記複数のプロセッサコアが、
   第１のアプリケーションプログラムが動作するオペレーティングシステムと、第２のグループのプロセッサコアの軽量スケジューラと通信を行うＯＬリモート制御手段とを含む第１のグループのプロセッサコアと、
   前記オペレーティングシステムを稼動させずに、前記ＯＬリモート制御手段からの要求に基づき、第２のアプリケーションプログラムを動作させる軽量スケジューラを含む第２のグループのプロセッサコアとを含み、
   前記ＯＬリモート制御手段が、
   前記第１のアプリケーションプログラムからの要求に基づき、前記軽量スケジューラに対し、前記第２のアプリケーションプログラムの開始又は終了を指示し、
   前記軽量スケジューラが、
   前記ＯＬリモート制御手段からの指示に基づき、前記第２のグループのプロセッサコア上で、複数のタスクから構成される前記第２のアプリケーションプログラムを動作させる手段と、
   実行中の前記タスクのコンテキストを退避させるコンテキスト退避手段と、
   前記コンテキスト退避手段の処理の後に、次に実行すべき前記タスクを選定する新コンテキスト選定手段と、
   前記新コンテキスト選定手段により選定された前記タスクの実行を開始するコンテキスト復活手段と、
   任意のタイミングで、前記コンテキスト退避手段、前記新コンテキスト選定手段、前記コンテキスト復活手段を呼び出すことにより、複数の前記タスクを時分割で切り替えながら実行する時分割多重化制御手段とを含み、
   前記時分割多重化制御手段は、
   前記タスクの連続実行時間に基づき設定されるタイマのカウンタがゼロに到達すると、前記コンテキスト退避手段、前記新コンテキスト選定手段、前記コンテキスト復活手段を呼び出すことにより、前記タスクを切り替える
   ことを特徴とするプログラム並列実行システム。
2. 前記軽量スケジューラが、
   前記第２のグループのプロセッサコア間の同期、排他制御や前記第２のグループのプロセッサコアに対するキャッシュ制御の少なくとも一の処理を行うＯＬタスクサービス手段を備える
   ことを特徴とする請求項１に記載のプログラム並列実行システム。
3. 前記軽量スケジューラが、
   前記第１のアプリケーションプログラム側からの指示に基き、タスクの開始や終了の制御を行うタスク制御手段と、タスク内のスレッド間通信やキャッシュ制御、タスクの終了要求を処理するＯＬタスクサービス手段を含むことを特徴とする請求項１又は２に記載のプログラム並列実行システム。
4. 前記ＯＬリモート制御手段が、
   前記第２のグループのプロセッサコア上で前記軽量スケジューラが動作できるように初期設定を行う初期化手段と、
   稼働中の前記軽量スケジューラ上に新しく前記タスクをロードし実行可能な状態にセットアップするセットアップ手段と、
   セットアップしたタスクを実行開始させるタスク開始手段と、
   開始したタスクの終了を待ち合わせるタスク終了待ち手段と、
   前記タスクを強制的に終了させるためのタスク強制終了手段と、
   一旦終了した前記タスクを再ロードせずに初期状態に戻すタスク再初期化手段と、
   ロードしたタスクを破棄してリソースを解放するプログラム破棄手段とを含む
   ことを特徴とする請求項１から請求項３の何れかに記載のプログラム並列実行システム。
5. 前記ＯＬリモート制御手段が、
   前記第１のグループのプロセッサコアの数と第２のグループのプロセッサコアの数のいずれか又は両方をシステム動作中に変化させる動的コンフィギュレーション変更手段を備える
   ことを特徴とする請求項１から請求項４の何れかに記載のプログラム並列実行システム。
6. 前記オペレーティングシステムが稼動するプロセッサコアを動的に追加又は削除する追加削除手段を備え、
   前記ＯＬリモート制御手段が、
   前記第２のグループのプロセッサコアを初期化して前記軽量スケジューラを開始させ、又は終了させる軽量スケジューラ開始終了手段を含む
   ことを特徴とする請求項１から請求項５の何れかに記載のプログラム並列実行システム。
7. システム動作中に、
   前記追加削除手段が、前記第１のグループのプロセッサコアを構成する一部のプロセッサコアを前記オペレーティングシステムから切り離し、
   前記切り離されたプロセッサコアを第２のグループのプロセッサコアとし、
   前記軽量スケジューラ開始終了手段が、前記第２のグループのプロセッサコア上に前記軽量スケジューラをロードして開始させる
   ことを特徴とする請求項６に記載のプログラム並列実行システム。
8. システム動作中に、
   前記軽量スケジューラ開始終了手段が、前記第２のグループのプロセッサコアを停止させ、
   前記追加削除手段が、停止させたプロセッサコアを前記第１のグループのプロセッサコアに追加する
   ことを特徴とする請求項６又は請求項７に記載のプログラム並列実行システム。
9. 複数のプロセッサコアをバスによって相互結合したマルチコアプロセッサを備えるプログラム並列実行システムであって、前記複数のプロセッサコアが、第１のアプリケーションプログラムが動作するオペレーティングシステムと、第２のグループのプロセッサコアの軽量スケジューラと通信を行うＯＬリモート制御手段とを含む第１のグループのプロセッサコアと、前記オペレーティングシステムを稼動させずに、前記ＯＬリモート制御手段からの要求に基づき、第２のアプリケーションプログラムを動作させる軽量スケジューラを含む第２のグループのプロセッサコアとを含むプログラム並列実行システムによるプログラム並列実行方法であって、
   前記ＯＬリモート制御手段が、前記第１のアプリケーションプログラムからの要求に基づき、前記軽量スケジューラに対し、前記第２のアプリケーションプログラムの開始又は終了を指示するステップと、
   前記軽量スケジューラが、前記ＯＬリモート制御手段からの指示に基づき、前記第２のグループのプロセッサコア上で、複数のタスクから構成される前記第２のアプリケーションプログラムを動作させるステップと、
   前記軽量スケジューラが備えるコンテキスト退避手段が、実行中の前記タスクのコンテキストを退避させるコンテキスト退避ステップと、
   前記軽量スケジューラが備える新コンテキスト選定手段が、前記コンテキスト退避手段の処理の後に、次に実行すべき前記タスクを選定する新コンテキスト選定ステップと、
   前記軽量スケジューラが備えるコンテキスト復活手段が、前記新コンテキスト選定手段により選定された前記タスクの実行を開始するコンテキスト復活ステップと、
   前記軽量スケジューラが備える時分割多重化制御手段が、任意のタイミングで、前記コンテキスト退避手段、前記新コンテキスト選定手段、前記コンテキスト復活手段を呼び出すことにより、複数の前記タスクを時分割で切り替えながら実行する時分割多重化制御ステップとを有し、
   前記時分割多重化制御ステップで、
   前記タスクの連続実行時間に基づき設定されるタイマのカウンタがゼロに到達すると、前記コンテキスト退避手段、前記新コンテキスト選定手段、前記コンテキスト復活手段を呼び出すことにより、前記タスクを切り替える
   ことを特徴とするプログラム並列実行方法。
10. 前記軽量スケジューラが備えるＯＬタスクサービス手段が、前記第２のグループのプロセッサコア間の同期、排他制御や前記第２のグループのプロセッサコアに対するキャッシュ制御の少なくとも一の処理を行うＯＬタスクサービスステップを有する
    ことを特徴とする請求項９に記載のプログラム並列実行方法。
11. 前記軽量スケジューラが備えるタスク制御手段が、前記第１のアプリケーションプログラム側からの指示に基き、タスクの開始や終了の制御を行うタスク制御ステップと、
    前記軽量スケジューラが備えるＯＬタスクサービス手段が、タスク内のスレッド間通信やキャッシュ制御、タスクの終了要求を処理するＯＬタスクサービスステップと
    を有することを特徴とする請求項９又は１０に記載のプログラム並列実行方法。
12. 前記ＯＬリモート制御手段が備える初期化手段が、前記第２のグループのプロセッサコア上で前記軽量スケジューラが動作できるように初期設定を行う初期化ステップと、
    前記ＯＬリモート制御手段が備えるセットアップ手段が、稼働中の前記軽量スケジューラ上に新しく前記タスクをロードし実行可能な状態にセットアップするセットアップステップと、
    前記ＯＬリモート制御手段が備えるタスク開始手段が、セットアップしたタスクを実行開始させるタスク開始ステップと、
    前記ＯＬリモート制御手段が備えるタスク終了待ち手段が、開始したタスクの終了を待ち合わせるタスク終了待ちステップと、
    前記ＯＬリモート制御手段が備えるタスク強制終了手段が、前記タスクを強制的に終了させるタスク強制終了ステップと、
    前記ＯＬリモート制御手段が備えるタスク再初期化手段が、一旦終了した前記タスクを再ロードせずに初期状態に戻すタスク再初期化ステップと、
    前記ＯＬリモート制御手段が備えるプログラム破棄手段が、ロードしたタスクを破棄してリソースを解放するプログラム破棄ステップと
    を有することを特徴とする請求項９から請求項１１の何れかに記載のプログラム並列実行方法。
13. 前記ＯＬリモート制御手段が備える動的コンフィギュレーション変更手段が、前記第１のグループのプロセッサコアの数と第２のグループのプロセッサコアの数のいずれか又は両方をシステム動作中に変化させる動的コンフィギュレーション変更ステップを有する
    ことを特徴とする請求項９から請求項１２の何れかに記載のプログラム並列実行方法。
14. 追加削除手段が、前記オペレーティングシステムが稼動するプロセッサコアを動的に追加又は削除する追加削除ステップと、
    前記ＯＬリモート制御手段が備える軽量スケジューラ開始手段が、前記第２のグループのプロセッサコアを初期化して前記軽量スケジューラを開始させ、又は終了させる軽量スケジューラ開始終了ステップと
    を有する特徴とする請求項９から請求項１３の何れかに記載のプログラム並列実行方法。
15. システム動作中に、
    前記追加削除ステップで、前記第１のグループのプロセッサコアを構成する一部のプロセッサコアを前記オペレーティングシステムから切り離し、
    前記切り離されたプロセッサコアを第２のグループのプロセッサコアとし、
    前記軽量スケジューラ開始終了ステップで、前記第２のグループのプロセッサコア上に前記軽量スケジューラをロードして開始させる
    ことを特徴とする請求項１４に記載のプログラム並列実行方法。
16. システム動作中に、
    前記軽量スケジューラ開始終了ステップで、前記第２のグループのプロセッサコアを停止させ、
    前記追加削除ステップで、停止させたプロセッサコアを前記第１のグループのプロセッサコアに追加する
    ことを特徴とする請求項１４又は請求項１５に記載のプログラム並列実行方法。

Images