"複数のコア群を有するマルチコアプロセッサと、アプリケーションごとに実行時間に関する制約を記憶する記憶装置と、を備えるマルチコアプロセッサシステムであって、前記マルチコアプロセッサのうちの第1の特定コアが、前記アプリケーションのうち、起動指示を受け付けた対象アプリケーションの実行時間に関する制約を前記記憶装置から特定する制約特定手段と、前記制約特定手段により特定された制約が性能劣化条件を満たすか否かを判断する判断手段と、前記判断手段により前記特定された制約が前記性能劣化条件を満たすと判断された場合、前記対象アプリケーションを前記マルチコアプロセッサのうちの所定コアに割り当てる割当手段と、前記判断手段により前記特定された制約が前記性能劣化条件を満たさないと判断された場合、前記複数のコア群のうちのいずれかのコア群の第2の特定コアに前記対象アプリケーションの割当指示を通知する通知手段と、を備えることを特徴とするマルチコアプロセッサシステム。前記マルチコアプロセッサのうちのいずれかのコアが、前記マルチコアプロセッサの各コアでのアプリケーションの実行の有無に基づいて、前記所定コアを決定する決定手段を備えることを特徴とする請求項1に記載のマルチコアプロセッサシステム。前記マルチコアプロセッサのコアごとに前記コアで実行中のアプリケーションの割り当て時刻が記憶装置に記憶され、前記いずれかのコア群の第2の特定コアが、前記通知手段によって通知された前記割当指示を受け付けると、前記いずれかのコア群のうち、実行中のアプリケーションの負荷量が最小のコアを特定する負荷特定手段と、前記負荷特定手段により特定された最小のコアに前記対象アプリケーションを割り当てるコア群内割当手段と、前記コア群内割当手段による前記割り当て後に、前記記憶装置内の前記最小のコアに関する前記割り当て時刻を更新する更新手段と、を備えることを特徴とする請求項2に記載のマルチコアプロセッサシステム。前記決定手段は、前記コアで実行中のアプリケーションに関する前記更新手段による更新後の割り当て時刻に基づいて、前記所定コアを決定することを特徴とする請求項3に記載のマルチコアプロセッサシステム。前記所定コアが、前記割当手段による前記対象アプリケーションの割り当てを受け付けると、前記所定コアで実行中のアプリケーションを前記所定コアの属するコア群の他のコアに移行させる移行指示を前記所定コアが属するコア群の第2の特定コアに通知する移行通知手段を備え、前記所定コアが属するコア群の第2の特定コアが、前記所定コアで実行中のアプリケーションを前記所定コアの属するコア群の他のコアに移行させる移行処理を実行する移行処理実行手段を備えることを特徴とする請求項1~4のいずれか一つに記載のマルチコアプロセッサシステム。前記マルチコアプロセッサで共有する共有資源を備え、前記所定コアが、前記割当手段による前記対象アプリケーションの割り当てを受け付けると、前記所定コアから前記共有資源へのアクセスの比率を前記対象アプリケーションの割り当ての受付前よりも高くするアクセス比率設定手段を備えることを特徴とする請求項1~5のいずれか一つに記載のマルチコアプロセッサシステム。前記所定コアが属するコア群で共有するキャッシュを備え、前記所定コアが属するコア群のうちの他のコアが、前記割当手段により前記対象アプリケーションが前記所定コアに割り当てられると、前記キャッシュへアクセスを行わないキャッシュモード設定手段を備えることを特徴とする請求項1~6のいずれか一つに記載のマルチコアプロセッサシステム。アプリケーションごとに実行時間に関する制約を記憶する記憶装置にアクセス可能な複数のコア群を有するマルチコアプロセッサのうちの第1の特定コアが、前記アプリケーションのうち、起動指示を受け付けた対象アプリケーションの実行時間に関する制約を前記記憶装置から特定し、特定された制約が性能劣化条件を満たすか否かを判断し、前記特定された制約が前記性能劣化条件を満たすと判断された場合、前記対象アプリケーションを前記マルチコアプロセッサのうちの所定コアに割り当て、前記特定された制約が前記性能劣化条件を満たさないと判断された場合、前記複数のコア群のうちのいずれかのコア群の第2の特定コアに前記対象アプリケーションの割当指示を通知する、処理を実行することを特徴とする制御方法。しかしながら、複数のスレーブCPUをマスタCPUによって全体のスケジューリングを行う場合、マスタCPUがスケジューリング計算によって過負荷状態となり、スケジューリングに時間がかかる問題点がある。また、マルチコアプロセッサを複数のCPUごとにグルーピングし、全体マスタCPUとグループマスタCPUとでスケジューリングを行う場合、2回のスケジューリングを行うため、スケジューリングに時間がかかる問題点がある。2回のスケジューリングとは、全体マスタCPUがいずれのグループに割り当てるかと、グループマスタがグループ内のいずれのCPUに割り当てるかである。本発明は、上述した従来技術による問題点を解消するため、スケジューリングによるアプリの実行性能の劣化を防止することができるマルチコアプロセッサシステム、および制御方法を提供することを目的とする。上述した課題を解決し、目的を達成するため、本発明の一側面によれば、アプリケーションごとに実行時間に関する制約を記憶する記憶装置にアクセス可能な複数のコア群を有するマルチコアプロセッサのうちの第1の特定コアが、前記アプリケーションのうち、起動指示を受け付けた対象アプリケーションの実行時間に関する制約を前記記憶装置から特定し、特定された制約が性能劣化条件を満たすか否かを判断し、前記特定された制約が前記性能劣化条件を満たすと判断された場合、前記対象アプリケーションを前記マルチコアプロセッサのうちの所定コアに割り当て、前記特定された制約が前記性能劣化条件を満たさないと判断された場合、前記複数のコア群のうちのいずれかのコア群の第2の特定コアに前記対象アプリケーションの割当指示を通知するマルチコアプロセッサシステム、および制御方法が提案される。本発明の一側面によれば、スケジューリングによるアプリの実行性能の劣化を防止することができるという効果を奏する。以下に添付図面を参照して、本発明にかかるマルチコアプロセッサシステム、および制御方法の実施の形態を詳細に説明する。ここで、マルチコアプロセッサシステムおいて、マルチコアプロセッサとは、コアが複数搭載されたプロセッサである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、本実施の形態では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。図1は、本発明の一実施例を示す説明図である。マルチコアプロセッサシステム100では、マルチコアプロセッサの複数のCPUはグループG1~Gnn≧1にあらかじめグループ化されている。たとえば、グループG1には、CPU111-1~CPU111-kが属し、グループGm1<m≦nには、CPU11m-1~CPU11m-kが属している。グループGm1には、CPU11m1-1~CPU11m1-kが属し、グループGnには、CPU11n-1~CPU11n-kが属している。kは、2,4,8などの所定値であり、マルチコアプロセッサシステム100の設計者があらかじめ決定していることとする。CPU111-1は、マルチコアプロセッサの全体を制御する全体マスタCPUであり、かつグループG1に属するCPU111-2~111-kを制御するグループマスタCPUである。CPU111-2~111-kはスレーブCPUである。また、グループG2~Gnには、それぞれグループマスタCPUであるCPU11m-1,11m1-1,11n-1があり、各グループG2~Gnを制御している。CPU111-2~111-k,CPU11m-2~11m-k,11m1-2~11m1-k,11n-2~11n~-kは、スレーブCPUである。共有メモリ102などの記憶装置は、アプリごとに実行時間に関する制約以下、リアルタイム制約と称する。が記述されたテーブルを有している。リアルタイム制約とは、たとえば、起動指示を受け付けてから何[ms]以内に実行を終了しなければならないかについてである。たとえば、アプリAの制約は起動指示を受け付けてから3[ms]以内に実行を終了することとする。たとえば、アプリBの制約は起動指示を受け付けてから1[s]以内に実行を終了することとする。まず、全体マスタCPUであるCPU111-1が、起動指示を受け付けた対象アプリの実行時間に関する制約を記憶装置から特定する。たとえば、アプリAが対象アプリであるとする。そして、CPU111-1が、特定された制約が性能劣化条件を満たすか否かを判断する。性能劣化条件とは、たとえば、いずれかのグループのグループマスタCPUに割当指示が通知され、グループマスタCPUがグループ内のいずれかのCPUにアプリが割り当てられた場合に性能が劣化してしまう条件である。具体的には、割当時間とアプリの実行時間の合計時間が制約を遵守できるか否かの条件である。性能劣化条件は、あらかじめアプリの設計時にシミュレーションにより決定されていることとする。ここで、性能劣化条件が満たされるアプリは、リアルタイム制約の強いアプリとし、所定条件が満たされないアプリは、リアルタイム制約の弱いアプリとする。リアルタイム制約の強いアプリであると、割当時間の影響が大きく、アプリの性能が劣化する可能性がある。リアルタイム制約の弱いアプリであると、割当時間の影響がリアルタイム制約の強いアプリと比較して小さいため、割当時間によってアプリの性能が劣化する可能性が低い。たとえば、性能劣化条件が50[ms]以内であるとする。たとえば、アプリAの制約は3[ms]であるので、アプリAの制約は50[ms]以内である。よって、アプリAの制約は性能劣化条件を満たしていると判断される。すなわち、アプリAは、リアルタイム制約の強いアプリである。CPU111-1が、特定された制約が性能劣化条件を満たすと判断された場合、対象アプリをマルチコアプロセッサのうちの所定CPUに割り当てる。図1では、所定CPUがCPU111-3であるとし、アプリAがCPU111-1に割り当てられている。たとえば、アプリBの制約は1[s]であるので、アプリBの制約は50[ms]より大きい。よって、アプリAの制約は所定条件を満たしていないと判断される。すなわち、アプリBは、リアルタイム制約の弱いアプリである。CPU111-1が、特定された制約が所定条件を満たさないと判断された場合、グループG1~GnのうちのいずれかのグループのグループマスタCPUに対象アプリの割当指示を通知する。図1では、グループGm1のCPU11m1-1に割当指示が通知され、CPU11m1-1が、CPU11m1-2にアプリBを割り当てている。また、本実施の形態では、CPUの処理単位をアプリとしているが、これに限らず、たとえば、スレッドであってもよい。つぎに、マルチコアプロセッサシステム100について詳細に説明する。マルチコアプロセッサシステム100は、CPU111-1~111-k,11m-1~11m-k,11m1-1~11m1-k,11n-1~11n-kと、有している。さらに、マルチコアプロセッサシステム100は、共有メモリ102と、メモリコントローラ103と、I/O105と、I/F104と、を有している。また、各部はバス101によってそれぞれ接続されている。CPU111-1~111-k,11m-1~11m-k,11m1-1~11m1-k,11n-1~11n-kは、それぞれOS131-1~131-k,13m-1~13m-k,13m1-1~13m1-k,13n-1~13n-kを実行している。OS131-1は、マルチコアプロセッサの全体のマスタOSであり、グループG1のマスタOSである。OS131-1は、ウエイトキュー140を有している。OS131-1は、ウエイトキュー140にアプリが積まれると、該アプリの起動指示を受け付けたと判断する。OS132-1,133-1,134-1は、それぞれグループG2,3,4のマスタOSである。OS131-1~131-k,13m-1~13m-k,13m1-1~13m1-k,13n-1~13n-kは、図示していないが、それぞれランキューを有している。各ランキューには各CPUに割り当てられたアプリのコンテキスト情報のポインタが積まれる。コンテキスト情報とは、たとえば、ロードされたアプリの実行状態や該アプリ内の変数などが含まれる情報である。各OSはランキュー内のコンテキスト情報のポインタを取得し、アプリのコンテキスト情報にアクセスすることで、アプリを直ぐに実行することができる。各CPUが有する1次キャッシュはOSが実行するアプリから共有メモリ102への書込処理を一時的に記憶する。各1次キャッシュは、共有メモリ102から読み出されたデータを一時的に記憶する。グループG1~Gnのそれぞれに属するCPUが有する1次キャッシュは、スヌープ回路によって接続されている。スヌープ回路は、各グループに属するCPUが有する1次キャッシュで共有するデータがいずれかの1次キャッシュで更新された場合、該更新を検出し、他の1次キャッシュの該データも更新する。グループG1~Gnでは、それぞれに属するCPUが2次キャッシュ121~12nを共有している。2次キャッシュ121~12nは、キャッシュメモリとキャッシュコントローラとを有している。2次キャッシュ121~12nでは、各グループに属するCPUが有する1次キャッシュから追い出されたデータを記憶する。2次キャッシュ121~12nは、1次キャッシュよりも、記憶容量が大きくかつCPUからのアクセス速度が遅い。2次キャッシュ121~12nは共有メモリ102より、記憶容量が小さくかつCPUからのアクセス速度が速い。共有メモリ102は、たとえば、ROM、RAM、フラッシュROMが挙げられる。ROMは、ブートプログラムなどのプログラムを記憶している。RAMは、CPU111-1~CPU11n-kのワークエリアとして使用される。フラッシュROMは、OSなどのシステムソフトウェアやアプリのプログラムを記憶している。フラッシュROMは、たとえば、マルチコアプロセッサシステム100に内蔵されていてもよいし、メモリカード、SDカードなどの記録媒体であってもよい。メモリコントローラ103は、共有メモリ102へのアクセスを制御する。I/O105は、たとえば、ディスプレイやキーボードなどが挙げられる。ディスプレイは、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイは、たとえば、TFT液晶ディスプレイなどを採用することができる。キーボードは、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボードは、タッチパネル式の入力パッドやテンキーなどであってもよい。I/F104は、無線通信回線を通じてLANLocalAreaNetwork、WANWideAreaNetwork、インターネットなどのネットワークNWに接続され、ネットワークNWを介して他の携帯端末に接続される。そして、I/F104は、ネットワークNWと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F104には、たとえば、無線通信用のモデムやLANアダプタなどを採用することができる。実施例1まず、実施例1では、リアルタイム制約が強いアプリは直ちに実行させるために所定CPUに割り当て、リアルタイム制約が弱いアプリはいずれかのCPU群に割当指示を通知する例を示す。これにより、全体マスタCPUの負荷を軽減することができる。実施例1では、n=4であり、m=2であり、k=4である例を示す。また、実施例1では、各アプリのリアルタイム制約に関してあらかじめ解析済であるとし、アプリごとにリアルタイム制約の強弱を示すフラグが登録されたアプリテーブルが記憶装置に記憶されていることとする。図2にアプリテーブルの一例を示す。アプリテーブル図2は、アプリテーブルの一例を示す説明図である。アプリテーブル200は、アプリID、アプリフラグ、負荷量のフィールドを有している。各フィールドに値が設定されることで、アプリ情報たとえば、201-1,201-2がレコードとして記憶される。アプリIDのフィールドには、アプリの識別情報が登録される。アプリフラグのフィールドには、リアルタイム制約の強弱を示すフラグが登録されている。たとえば、アプリフラグのフィールドに0が登録されていれば、リアルタイム制約が弱いことを示し、アプリフラグのフィールドに1が登録されていれば、リアルタイム制約が強いことを示すとする。負荷量のフィールドには、アプリの単位時間当たりのCPUの使用量が登録される。アプリテーブル200は、共有メモリ102に記憶されていることとする。CPUテーブル図3は、CPUテーブルの一例を示す説明図である。CPUテーブル300は、各CPUに割り当てられたアプリの最新の割当時刻を記憶する時刻情報を有している。CPUテーブル300は、CPUID、時刻、フラグ、割当アプリのフィールドを有している。各フィールドに値が設定されることで、CPU情報たとえば、301-1,301-2がレコードとして記憶される。CPUIDのフィールドには、CPUの識別情報が登録される。時刻のフィールドには、アプリまたはスレッドがディスパッチされた最新の時刻が登録される。フラグのフィールドには、各CPUで現在実行中のアプリのうち、アプリフラグが1であるアプリを実行中であるか否かを示す値が登録される。フラグのフィールドに1が登録されている場合、リアルタイム制約が強いアプリを実行中であり、フラグのフィールドに0が登録されている場合、リアルタイム制約が強くないアプリを実行中である。割当アプリのフィールドには、CPUに割り当てられたアプリの識別情報が設定される。CPUテーブル300は、共有メモリ102に記憶されていることとする。ディスパッチ先CPU情報図4は、ディスパッチ先CPU情報の一例を示す説明図である。ディスパッチ先CPU情報400は、リアルタイム制約が強いアプリが起動された場合に該アプリを割り当てる割当先のCPUの識別情報が登録されている。図1では、所定CPUと称している。ディスパッチ先CPU情報400は、ディスパッチ先CPU情報400に登録された割当先のCPUによって更新される。ディスパッチ先CPU情報400は、共有メモリ102に記憶されていることとする。実施例1にかかるマルチコアプロセッサシステム100の機能ブロック図例図5は、実施例1にかかるマルチコアプロセッサシステム100の機能ブロックの一例を示す説明図である。全体マスタOSであるOS131-1は、アプリ特性解析部501と、割当部502と、グループ間割当部503と、を有している。具体的には、たとえば、アプリ特性解析部501~グループ間割当部503の処理が、OSにコーディングされている。CPU111-1が、ROMやフラッシュROMなどの記憶装置に記憶されたOS131-1を読み出し、OS131-1にコーディングされている処理を実行する。これにより、アプリ特性解析部501~グループ間割当部503の処理が実現される。グループマスタOSであるOS13ii=1~4-1は、受付部521-iと、コア群内割当部522-iと、更新部523-iを有している。具体的には、たとえば、受付部521-i~更新部523-iの処理が、OS13i-1にコーディングされている。CPU11i-1が、ROMやフラッシュROMなどの記憶装置に記憶されたOS13i-1を読み出し、OS13i-1にコーディングされている処理を実行する。これにより、受付部521-i~更新部523-iの処理が実現される。スレーブOSであるOS13jj=1~4-ll=2~4は、受付部531-jlと、決定部532-jlと、を有している。具体的には、たとえば、受付部531-jl~決定部532-jlの処理が、OS13j-lにコーディングされている。CPU11j-lが、ROMやフラッシュROMなどの記憶装置に記憶されたOS13j-lを読み出し、OS13j-lにコーディングされている処理を実行する。これにより、受付部531-jl~決定部532-jlの処理が実現される。ここで、各部の詳細な例について、図6~8を用いて説明する。図6は、リアルタイム制約の強いアプリの割当例を示す説明図である。アプリ特性解析部501は、起動指示のあった対象アプリのリアルタイム制約が強いか弱いかを解析する。具体的には、たとえば、アプリ特性解析部501は、受付部511と、制約特定部512と、判断部513と、を有している。受付部511は、対象アプリの起動指示を受け付ける。図6の例では、対象アプリがアプリAである。具体的には、たとえば、受付部511は、ウエイトキュー140にアプリが積まれると、該対象アプリの起動指示を受け付けたと判断する。制約特定部512は、対象アプリの制約に関するアプリ情報を特定する。具体的には、たとえば、制約特定部512は、アプリテーブル200から、対象アプリに関するアプリ情報を特定し、特定したアプリ情報のアプリフラグのフィールドに設定された値を特定する。ここで、アプリAに関するアプリ情報201-1のアプリフラグのフィールドには1が設定されていることが特定される。つぎに、判断部513は、対象アプリがリアルタイム制約の強いアプリであるか否かを判断する。具体的には、たとえば、判断部513は、制約特定部512により特定されたアプリフラグのフィールドに設定された値が1であれば、対象アプリをリアルタイム制約が強いアプリであると判断する。また、具体的には、たとえば、判断部513は、特定したアプリフラグのフィールドに設定された値が0であれば、対象アプリをリアルタイム制約が弱いアプリであると判断する。ここで、アプリAに関するアプリ情報201-1のアプリフラグのフィールドには1が設定されているため、アプリAはリアルタイム制約の強いアプリであると判断される。割当部502は、アプリ特性解析部501により対象アプリがリアルタイム制約の強いアプリであると判断された場合、所定CPUに対象アプリを割り当てる。具体的には、たとえば、割当部502は、ディスパッチ先CPU情報400に登録された識別情報が示すCPU112-2に対象アプリを割り当てる。さらに、具体的には、たとえば、割当部502は、割り当て結果をCPUテーブル300に出力する。図7は、リアルタイム制約の弱いアプリの割当例を示す説明図である。図7では、アプリ特性解析部501について、図6で説明した処理例と同一処理であるため、詳細な説明を省略する。図7では、対象アプリがアプリBである。アプリテーブル200内のアプリBに関するアプリ情報201-2のアプリフラグのフィールドには0が設定されている。よって、アプリBはリアルタイム制約の弱いアプリであると判断される。グループ間割当部503は、アプリ特性解析部501により対象アプリがリアルタイム制約の弱いアプリであると判断された場合、グループG1~G4のうちのいずれかのグループのグループマスタCPUに対象アプリの割当指示を通知する。具体的には、たとえば、グループ間割当部503は、グループ特定部514と通知部515を有している。グループ特定部514は、グループG1~G4のうち、グループG1~G4のそれぞれが属するCPUで実行中のアプリの負荷量の合計値が最小のグループを特定する。具体的には、たとえば、グループ特定部514は、グループG1~G4の各グループマスタCPUに対して、グループG1~G4のそれぞれが属するCPUで実行中のアプリの負荷量の合計値の算出を依頼して、算出結果を取得することとしてもよい。または、たとえば、各グループマスタCPUが、グループに属するCPUで実行中のアプリの負荷量の合計値を定期的に全体マスタOSOS131-1に通知していることとしてもよい。そして、具体的には、たとえば、グループ特定部514は、負荷量の合計値が最小であるグループを特定する。図7では、グループG1に属するCPUで実行中のアプリの負荷量の合計値は、80[]である。図7では、グループG2に属するCPUで実行中のアプリの負荷量の合計値は、50[]である。図7では、グループG3に属するCPUで実行中のアプリの負荷量の合計値は、70[]である。図7では、グループG4に属するCPUで実行中のアプリの負荷量の合計値は、20[]である。よって、負荷量の合計値が最小であるグループとしてグループG4が特定される。通知部515は、グループ特定部514により特定されたグループのグループマスタCPUに対象アプリの割当指示を通知する。具体的には、たとえば、通知部515は、CPU111-1とCPU114-1とのCPU間通信によって割当指示を通知する。図7では、アプリBの割当指示がCPU114-1によりCPU114-2i=4,k=2に通知されている。受付部521-4は、グループ間割当部503により通知された対象アプリの割当指示を受け付ける。具体的には、たとえば、受付部521-4は、CPU間通信により全体マスタCPUから割当指示を受け付ける。コア群内割当部522-4は、受付部521-4により対象アプリの割当指示を受け付けると、グループに属するCPUのうち、いずれかのCPUに対象アプリを割り当てる。具体的には、たとえば、コア群内割当部522-4は、グループG4内に属するCPUごとに実行中のアプリの負荷量の合計値を特定する。そして、たとえば、コア群内割当部522-4は、グループG4内に属するCPUごとに実行中のアプリを特定する。そして、たとえば、コア群内割当部522-4は、CPUごとに特定したアプリの負荷量を、アプリテーブル200を参照することで取得する。そして、たとえば、コア群内割当部522-4は、CPUごとに負荷量の合計値を算出し、負荷量の合計値が最小であるCPUを特定する。そして、たとえば、コア群内割当部522-4は、特定したCPUに対象アプリを割り当てる。更新部523-4は、コア群内割当部522-4による割当結果に基づいてCPUテーブル300を更新する。具体的には、たとえば、更新部523-4は、CPUテーブル300からCPU114-2に関するCPU情報を特定する。そして、具体的には、たとえば、更新部523-4は、CPU情報の時刻のフィールドに現時刻を設定し、CPU情報の割当アプリのフィールドに対象アプリの識別情報を設定する。図7では、グループG4のCPU114-1にはアプリが割り当てられているが、CPU114-2~114-4にはアプリが割り当てられていない。そのため、CPU114-2が負荷量の合計値が最小であるCPUとして特定され、アプリBが割り当てられている。図8は、ディスパッチ先CPU情報400の更新例を示す説明図である。ディスパッチ先CPU情報400に識別情報が設定されたOS132-2j=2,l=2の受付部531-22が、ディスパッチ先CPU情報400に識別情報の更新指示を受け付ける。具体的には、たとえば、各スレーブOSが、アプリの実行を終了すると、該更新指示をディスパッチ先CPU情報400に識別情報が設定されたOS132-2に通知し、受付部531-22が該更新指示を受け付けることとする。決定部532-22は、受付部531-22が該更新指示を受け付けると、各CPUでのアプリの実行の有無に基づいて割当部502での割当先のCPU上述の所定CPUを決定する。具体的には、たとえば、決定部532-22は、CPUテーブル300を参照し、割当アプリのフィールドに何も設定されていないCPUをアイドル状態のCPUとして特定する。ここで、CPUがアイドル状態であるとは、いずれのアプリも割り当てられていないことを示している。そして、具体的には、たとえば、決定部532-22は、アイドル状態のCPUを有するグループごとにグループに属しているCPUに関するCPUテーブル300のCPU情報を特定する。具体的には、たとえば、決定部532-22は、アイドル状態のCPUを有するグループごとに特定したCPU情報のフラグのフィールドが0であるか否かを判断する。これにより、決定部523-22は、アイドル状態のCPUを有するグループのうち、リアルタイム制約の強いアプリを実行していないグループがあるか否かを判断することができる。そして、リアルタイム制約の強いアプリを実行していないグループがある場合、たとえば、決定部532-22は、該グループのうち、アイドル状態のCPUが最も多いグループを特定する。そして、決定部532-22は、特定したグループのうちの、アイドル状態のCPUの識別情報をディスパッチ先CPU情報400に登録する。これにより、ディスパッチ先CPU情報400が、マルチコアプロセッサの各CPUでのアプリの実行状態に応じて更新される。図8では、アイドル状態のCPUを有するグループは、グループG2~G4である。グループG4のCPU114-3では、リアルタイム制約の強いアプリを実行しているが、グループG2,G3の各CPUでは、リアルタイム制約の強いアプリを実行していない。グループG2,G3のうち、アイドル状態のCPU数が多いのはグループG3であるため、グループG3のうちのアイドル状態のCPU113-2が割当部502での割当先のCPUに決定される。そして、CPU113-2の識別情報が、ディスパッチ先CPU情報400に新たに設定されている。図9は、ディスパッチ先CPU情報400の更新の他の例を示す説明図である。図9では、アイドル状態のCPUが無い場合について説明する。具体的には、たとえば、決定部532-22は、アイドル状態のCPUが存在しないと判断した場合、リアルタイム制約が強いアプリを実行していないグループがあるか否かを判断する。具体的には、たとえば、決定部532-22は、リアルタイム制約が強いアプリを実行していないグループがないと判断した場合、アプリが割り当てられてから最も時間が経過しているCPUを特定する。具体的には、たとえば、決定部532-22は、最も時間が経過しているか否かについてCPUテーブル300を参照し、各CPU情報の時刻のフィールドに設定された時刻を取得する。そして、たとえば、決定部532-22は、CPU情報ごとの取得した時刻と現時刻との差分を算出することにより、各CPUで実行中のアプリが割り当てられてからの経過時間CPUに関する経過時間と称する。を特定することができる。そして、決定部532-22は、特定したCPUに関する経過時間が最大であるCPUの識別情報をディスパッチ先CPU情報400に設定する。図9では、たとえば、CPU133-1に関する経過時間が、3[s]であり、CPU133-2に関する経過時間が、10[s]である。そして、たとえば、CPU133-2に関する経過時間が最大であると判断されると、ディスパッチ先CPU情報400にCPU133-2の識別情報があらたに登録される。ここで、たとえば、全体マスタCPUやグループマスタCPUについては、あらかじめディスパッチ先CPU情報400に識別情報が登録されるCPUの対象外としておくとよい。これにより、全体マスタCPUやグループマスタCPUの負荷を軽減させることができる。全体マスタCPUが行う処理手順図10は、全体マスタCPUが行う処理手順の一例を示すフローチャートである。まず、全体マスタCPUが、アプリの起動指示を受け付けたか否かを判断しステップS1001、アプリの起動指示を受け付けていないと判断した場合ステップS1001:No、ステップS1001へ戻る。全体マスタCPUが、アプリの起動指示を受け付けたと判断した場合ステップS1001:Yes、起動指示を受け付けたアプリがリアルタイム制約の強いアプリであるか否かを判断するステップS1002。全体マスタCPUが、リアルタイム制約の強いアプリであると判断した場合ステップS1002:Yes、ディスパッチ先CPU情報400に登録されている識別情報が示すCPUにアプリを割り当てステップS1003、一連の処理を終了する。ステップS1002において、全体マスタCPUが、リアルタイム制約の強いアプリでないと判断した場合ステップS1002:No、複数のグループのうち、グループに属するCPUの負荷量の合計値が最小のグループを特定するステップS1004。そして、全体マスタCPUが、特定したグループに割当指示を通知しステップS1005、一連の処理を終了する。実施例1にかかるグループマスタCPUが行う処理手順図11は、実施例1にかかるグループマスタCPUが行う処理手順の一例を示すフローチャートである。まず、グループマスタCPUが、アプリの割当指示を受け付けたか否かを判断するステップS1101。グループマスタCPUが、アプリの割当指示を受け付けていないと判断した場合ステップS1101:No、ステップS1101へ戻る。グループマスタCPUが、アプリの割当指示を受け付けたと判断した場合ステップS1101:Yes、グループ内で負荷量が最小のCPUを特定するステップS1102。グループマスタCPUが、アプリを特定したCPUに割り当てステップS1103、特定したCPUに関するCPUテーブル300の時刻情報を更新しステップS1104、ステップS1101へ戻る。実施例1にかかる各CPUが行う処理手順図12は、実施例1にかかる各CPUが行う処理手順の一例を示すフローチャートである。まず、CPUが、イベントが発生したか否かを判断するステップS1201。CPUが、イベントが発生していないと判断した場合ステップS1201:No、ステップS1201へ戻る。CPUが、アプリの割り当てを受け付けた場合ステップS1201:割り当て、割り当てられたアプリの実行を開始しステップS1202、ステップS1201へ戻る。CPUが、アプリの実行が終了した場合ステップS1201:実行終了、ディスパッチ先CPU情報400に識別情報が登録されているCPUにディスパッチ先CPU情報400の更新指示を通知しステップS1203、ステップS1201へ戻る。また、たとえば、ディスパッチ先CPU情報400として、全体マスタCPUやグループマスタCPUを設定しないようにあらかじめ決定しておくことで、図で示す処理を全体マスタCPUやグループマスタCPUが行わなくてよくなる。これにより、全体マスタCPUやグループマスタCPUの負荷を軽減させることができる。実施例1にかかるスレーブCPUが行う処理手順図13は、実施例1にかかるスレーブCPUが行う処理手順の一例を示すフローチャートである。まず、スレーブCPUが、ディスパッチ先CPU情報400の更新指示を受け付けたか否かを判断するステップS1301。スレーブCPUが、ディスパッチ先CPU情報400の更新指示を受け付けていないと判断した場合ステップS1301:No、ステップS1301へ戻る。スレーブCPUが、ディスパッチ先CPU情報400の更新指示を受け付けたと判断した場合ステップS1301:Yes、アイドル状態のCPUを特定するステップS1302。そして、スレーブCPUが、アイドル状態のCPUが存在するか否かを判断しステップS1303、アイドル状態のCPUが存在すると判断した場合ステップS1303:Yes、ステップS1304へ移行する。そして、スレーブCPUが、アイドル状態のCPUを有するグループのうち、リアルタイム制約の強いアプリを実行していないグループがあるか否かを判断するステップS1304。スレーブCPUが、リアルタイム制約の強いアプリを実行していないグループがあると判断した場合ステップS1304:Yes、リアルタイム制約の強いアプリを実行していないグループのうち、アイドル状態のCPUが最も多いグループを特定するステップS1305。そして、スレーブCPUが、特定したグループに属するCPUのうち、アイドル状態のCPUの識別情報をディスパッチ先CPU情報400に登録しステップS1306、一連の処理を終了する。ステップS1304において、スレーブCPUが、リアルタイム制約の強いアプリを実行していないグループがないと判断した場合ステップS1304:No、アイドル状態のCPUが最も多いグループを特定するステップS1307。スレーブCPUが、特定したグループに属するアイドル状態のCPUのうちのいずれかのCPUの識別情報をディスパッチ先CPU情報400に登録しステップS1308、一連の処理を終了する。ステップS1303において、スレーブCPUが、アイドル状態のCPUが存在しないと判断した場合ステップS1303:No、リアルタイム制約が強いアプリを実行していないグループがあるか否かを判断するステップS1309。スレーブCPUが、リアルタイム制約が強いアプリを実行していないグループがあると判断した場合ステップS1309:Yes、ステップS1310へ移行する。スレーブCPUが、リアルタイム制約が強いアプリを実行していないCPUの中で、負荷が最小のCPUの識別情報をディスパッチ先CPU情報400に登録しステップS1310、一連の処理を終了する。ステップS1309において、スレーブCPUが、リアルタイム制約が強いアプリを実行していないグループがないと判断した場合ステップS1309:No、ステップS1311に移行する。スレーブCPUが、アプリが割り当てられてから最も時間が経過しているCPUの識別情報をディスパッチ先CPU情報400に登録しステップS1311、一連の処理を終了する。実施例2実施例2では、リアルタイム制約が強い対象アプリを割り当て時において、対象アプリの実行時にリアルタイム制約を違反することを防止させるために、対象アプリの割当先CPUの性能を劣化させないように制御する例を示す。たとえば、グループG1~G4ごとにそれぞれ2次キャッシュ121~124を有している場合、同一グループ内の複数のCPUが同時に2次キャッシュ121~124へのアクセスを行うと、アクセスの競合が発生することにより、CPUの性能が劣化する。そこで、実施例2では、リアルタイム制約が強い対象アプリの割り当て時に、対象アプリの割当先CPUが属するグループの割当先CPUを除くCPUに割当先CPUが用いる2次キャッシュを利用させないようにする。これにより、対象アプリの割当先CPUの性能劣化を防止することができ、対象アプリの実行時にリアルタイム制約を違反することを防止することができる。複数のCPUが同時に共有メモリ102へのアクセスを行うと、アクセスの競合が発生することにより、CPUの性能が劣化する。そこで、実施例2では、リアルタイム制約が強い対象アプリの割り当て時に、対象アプリの割当先CPUの共有メモリ102へのアクセス比率を該割り当て前よりも高くする。これにより、対象アプリの割当先CPUの性能劣化を防止することができ、対象アプリの実行時にリアルタイム制約を違反することを防止することができる。実施例2では、実施例1で説明した処理、部、テーブルと同一の処理、部、テーブルについては同一の符号を付し、詳細な説明を省略する。実施例2であらたに利用するCPUテーブルとキャッシュモード設定情報についてそれぞれ図14,15で説明する。実施例2で用いるCPUテーブル図14は、実施例2で用いるCPUテーブルの一例を示す説明図である。CPUテーブル1400は、CPUID、時刻、フラグ、割当アプリ、バス優先度のフィールドを有している。各フィールドに値が設定されることで、CPU情報たとえば、1401-1,1401-2がレコードとして記憶される。CPUIDのフィールドには、CPUの識別情報が登録される。時刻のフィールドには、アプリが割り当てられた最新の時刻が登録される。フラグのフィールドには、各CPUで現在実行中のアプリのうち、アプリフラグが1であるアプリを実行中であるか否かを示す値が登録される。フラグのフィールドに1が登録されている場合、リアルタイム制約が強いアプリを実行中であり、フラグのフィールドに0が登録されている場合、リアルタイム制約が強くないアプリを実行中である。割当アプリのフィールドには、CPUに割り当てられたアプリの識別情報が設定される。バス優先度のフィールドには、CPUのバス優先度が登録される。リアルタイム制約が強いアプリを実行中であるCPUのバス優先度はリアルタイム制約が弱いアプリよりも大きい値が設定される。バス優先度のフィールドに登録されるデフォルト値は、1である。CPUテーブル1400は、共有メモリ102に記憶されていることとする。キャッシュモード設定情報図15は、キャッシュモード設定情報の一例を示す説明図である。キャッシュモード設定情報1500は2次キャッシュ121~124ごとにあるが、図15では、グループG2の2次キャッシュ122で用いる例について説明する。キャッシュモード設定情報1500は2次キャッシュ122を共有するCPU112-1~112-4が2次キャッシュ122を利用するか否かが設定される情報である。キャッシュモード設定情報1500は、CPUID、キャッシュモードのフィールドを有している。各フィールドに情報が設定されることで、利用情報たとえば、1501-1~1501-4がレコードとして記憶される。CPUIDのフィールドには、2次キャッシュ122を共有するCPU112-1~112-4の識別情報が登録されている。キャッシュモードのフィールドには、non-cache、またはcacheのいずれかが設定される。キャッシュモードのフィールドにnon-cacheが設定されている場合、CPU112-xx=1~4が2次キャッシュ122を利用しないことを示す。キャッシュモードのフィールドにcacheが設定されている場合、CPU112-xx=1~4が2次キャッシュ122を利用することを示す。キャッシュモードのフィールドのデフォルトの設定はcacheとし、キャッシュモード設定情報1500のキャッシュモードのフィールドに対しては、2次キャッシュ122を共有するCPU112-xx=1~4であれば設定の変更が可能であるとする。たとえば、2次キャッシュ122のキャッシュコントローラがキャッシュモード設定情報1500を有していることとする。2次キャッシュ122のキャッシュコントローラは、キャッシュモード設定情報1500に沿って2次キャッシュ122のキャッシュメモリにデータを記憶させる。実施例2にかかるマルチコアプロセッサシステム100の機能ブロック図例図16は、実施例2にかかるマルチコアプロセッサシステム100の機能ブロックの一例を示す説明図である。まず、図16で示す全体マスタOSであるOS131-1は、図5で示した例と同一であるため詳細な説明を省略する。グループマスタOSであるOS13i-1は、受付部521-iと、コア群内割当部522-iと、更新部523-iと、移行処理実行部524-iを有している。具体的には、たとえば、受付部521-i~移行処理実行部524-iの処理が、OS13i-1にコーディングされている。CPU11i-1が、ROMやフラッシュROMなどの記憶装置に記憶されたOS13i-1を読み出し、OS13i-1にコーディングされている処理を実行する。これにより、受付部521-i~移行処理実行部524-iの処理が実現される。コア群内割当部522-iの詳細な処理については、実施例1で説明した処理と同一であるため、詳細な説明を省略する。スレーブOSであるOS13j-lは、受付部531-jlと、決定部532-jlと、キャッシュモード設定部534-jlと、移行通知部533-jlと、アクセス比率設定部535-jlと、を有している。具体的には、たとえば、受付部531-jl~アクセス比率設定部535-jlの処理が、OS13j-lにコーディングされている。CPU11j-lが、ROMやフラッシュROMなどの記憶装置に記憶されたOS13j-lを読み出し、OS13j-lにコーディングされている処理を実行する。これにより、受付部531-jl~アクセス比率設定部535-jlの処理が実現される。受付部531-jlと決定部532-jlの詳細な処理については、実施例1で説明した処理と同一であるため、詳細な説明を省略する。具体的な例としては、図6で挙げたように、アプリAがリアルタイム制約の強いアプリであり、割当部502が、アプリAをCPU112-2j=2,l=2に割り当てたこととする。キャッシュモード設定部534-22は、割当部502による対象アプリの割り当てを受け付けると、同一グループG2に属する他のCPUが2次キャッシュ122へアクセスを行わないように設定する。具体的には、たとえば、キャッシュモード設定部534-22は、同一グループG2に属する他のCPU112-1,112-3,112-4へキャッシュモードをnon-cacheモードに変更させる変更指示をCPU間通信により通知する。また、受付部531-22が、CPU間通信により通知されたnon-cacheモードに変更させる変更指示を受け付けると、キャッシュモード設定部534-22は、2次キャッシュ122上のデータを共有メモリ102へ退避させる。そして、キャッシュモード設定部534-22は、CPU112-2のキャッシュモードを変更する。具体的には、たとえば、キャッシュモード設定部534-22は、2次キャッシュ122に記憶されている実行中のアプリに関するデータを各データの論理アドレスに基づいて特定する。そして、たとえば、キャッシュモード設定部534-22は、特定したデータを2次キャッシュ122から退避させる。そして、キャッシュモード設定部534-22は、キャッシュモード設定情報1500にアクセスして、CPU112-2に関する利用情報を特定する。そして、特定した利用情報のキャッシュモードのフィールドにnon-cacheを設定する。図17は、設定後のキャッシュモード設定情報1500の一例を示す説明図である。たとえば、アプリAはCPU112-2に割り当てられたため、CPU112-1,112-3,112-4に関する利用情報のキャッシュモードのフィールドがnon-cacheに設定される。そして、2次キャッシュ122のキャッシュコントローラがキャッシュモード設定情報1500の変化を検出し、キャッシュモード設定情報1500に基づいてデータを2次キャッシュのキャッシュメモリに記憶させるか否かを制御する。図16の説明に戻る。移行通知部533-22は、割当部502による対象アプリの割り当てを受け付けると、実行中のアプリをすべて同一グループ内の他のCPUに移行させる移行指示をグループマスタCPUであるCPU112-1に通知する。具体的に、たとえば、移行通知部533-22が、移行元CPUである情報を含む移行指示をCPU間通信でグループマスタCPUに通知する。受付部521-2は、移行指示を受け付けると、移行処理実行部524-2は、移行指示の通知元CPUで実行中のアプリおよび実行待機状態のアプリをすべてグループG2内の他のCPUに移行させる移行処理を実行する。具体的には、たとえば、受付部521-2は、CPU間通信でCPUから通知される移行指示を受け付ける。具体的には、たとえば、移行処理実行部524-2は、移行元CPUの1次キャッシュに含まれるデータを共有メモリ102に書き出す。そして、具体的には、たとえば、移行処理実行部524-2は、マイグレートする対象となるアプリのコンテキスト情報のポインタを移行先CPUにCPU間通信で通知する。これにより、リアルタイム制約の強い対象アプリが、他のアプリの実行と競合することなく実行される。アクセス比率設定部535-22は、割当部502による対象アプリの割り当てを受け付けると、CPU112-2から共有メモリ102へのアクセス比率を対象アプリの割当前のアクセス比率よりも高くする。たとえば、アクセス比率のデフォルト値を1とし、リアルタイム制約の強いアプリを実行するCPUのアクセス比率の値を10とする。具体的には、たとえば、アクセス比率設定部535-22は、CPU112-2に関するアクセス比率を10に設定する変更指示をメモリコントローラ103に通知する。変更指示には、たとえば、CPU112-2の識別情報と、変更後のアクセス比率の値が含まれていることとする。さらに、たとえば、アクセス比率設定部535-22は、CPUテーブル300を参照し、CPU112-2のCPU情報を特定する。そして、たとえば、アクセス比率設定部535-22は、特定したCPU情報のバス優先度のフィールドの値を10に設定する。図18は、アクセス比率を上げる例を示す説明図である。メモリコントローラ103は、リクエストキュー1800に登録されているアクセスのリクエスト順にタイムスライスで各CPUからのアクセスを制御する。ここでは、たとえば、メモリコントローラ103が各CPUに対応するレジスタを有し、該レジスタに各CPUのアクセス比率が設定されていることとする。そして、メモリコントローラ103が、各CPUに対応するレジスタの値に基づいて各CPUからのリクエストキュー1800へのリクエストの登録を制御する。たとえば、メモリコントローラ103は、各CPUからのアクセス比率の変更指示を受け付けると、変更指示に含まれるCPUの識別情報に基づいて、CPUに関するレジスタの値を変更指示に含まれるアクセス比率に変更する。リクエストキュー1800の中の各ボックスがアクセスリクエストである。メモリコントローラ103は、リクエストキュー1800の右側からアクセスリクエストを受け付け、左側から順にアクセスリクエストを処理することとする。たとえば、リクエストキュー1800内のボックスのうち、各CPUの符号が付されたボックスが各CPUからのアクセスリクエストである。対象アプリの割当前には、アクセス比率がすべて1であるため、各CPUからのアクセスリクエストが1個ずつリクエストキュー1800に登録される。対象アプリの割当後には、CPU112-2からのアクセス比率が高くなり、リクエストキュー1800内のボックスのうち、112-2が付されているボックスが10個続いている。実施例2にかかるグループマスタCPUの処理手順図19は、実施例2にかかるグループマスタCPUが行う処理手順の一例を示すフローチャートである。まず、グループマスタCPUが、イベントが発生したか否かを判断するステップS1901。グループマスタCPUが、イベントが発生していないと判断した場合ステップS1901:No、ステップS1901へ戻る。グループマスタCPUが、アプリの割当指示を受け付けたと判断した場合ステップS1901:割当指示、グループ内で負荷量が最小のCPUを特定するステップS1902。グループマスタCPUが、アプリを特定したCPUに割り当てステップS1903、特定したCPUに関するCPUテーブルの時刻情報を更新しステップS1904、ステップS1901へ戻る。ここで、時刻情報とは、CPUテーブルの時刻のフィールドの値を示している。グループマスタCPUが、移行指示を受け付けたと判断した場合ステップS1901:移行指示、グループ内で負荷量が最小のCPUを特定するステップS1905。そして、グループマスタCPUが、移行指示の通知元を移行元にし、特定したCPUを移行先にして移行処理を実行するステップS1906。グループマスタCPUが、移行終了を移行指示の通知元に通知しステップS1907、ステップS1901へ戻る。実施例2にかかるスレーブCPUが行う処理手順図20は、実施例2にかかるスレーブCPUが行う処理手順の一例を示すフローチャートである。まず、スレーブCPUが、イベントが発生したか否かを判断するステップS2001。スレーブCPUが、イベントが発生していないと判断した場合ステップS2001:No、ステップS2001へ戻る。スレーブCPUが、キャッシュモードの変更指示を受け付けたと判断した場合ステップS2001:変更指示、noncacheモードへの変更であるか否かを判断するステップS2002。スレーブCPUが、noncacheモードへの変更であると判断した場合ステップS2002:Yes、2次キャッシュ上のデータを共有メモリ102へ退避するステップS2003。そして、スレーブCPUが、キャッシュモードを変更しステップS2004、ステップS2001へ戻る。ステップS2002において、スレーブCPUが、noncacheモードへの変更でないと判断した場合ステップS2002:No、ステップS2004へ移行する。ステップS2001において、スレーブCPUが、アプリの実行終了を受け付けたと判断した場合ステップS2001:実行終了、実行が終了したアプリはリアルタイム制約の強いアプリであるか否かを判断するステップS2005。スレーブCPUが、実行が終了したアプリはリアルタイム制約の強いアプリでないと判断した場合ステップS2005:No、ステップS2001へ戻る。スレーブCPUが、実行が終了したアプリはリアルタイム制約の強いアプリであると判断した場合ステップS2005:Yes、グループの中の他のCPUにcachemodeへの変更を通知するステップS2006。スレーブCPUが、バス優先度をデフォルト値に変更する変更指示をメモリコントローラ103へ通知しステップS2007、ステップS2001へ戻る。ステップS2001において、スレーブCPUが、アプリの割り当てを受け付けたと判断した場合ステップS2001:割り当て、リアルタイム制約の強いアプリの割り当てであるか否かを判断するステップS2008。スレーブCPUが、リアルタイム制約の強いアプリの割り当てでないと判断した場合ステップS2008:No、ステップS2013へ移行する。スレーブCPUが、リアルタイム制約の強いアプリの割り当てであると判断した場合ステップS2008:Yes、同一グループの他のCPUにnoncacheモードへの変更指示を通知するステップS2009。つぎに、スレーブCPUが、バス優先度を指定値へ変更する変更指示をメモリコントローラ103へ通知しステップS2010、実行中のアプリを同一グループの他のCPUに移行させる移行指示をグループマスタCPUへ通知するステップS2011。そして、スレーブCPUが、移行完了したか否かを判断するステップS2012。具体的には、グループマスタCPUが、移行完了を通知するため、スレーブCPUは、移行完了の通知を受け付けたか否かによって移行完了したか否かを判断する。そして、スレーブCPUが、移行完了していないと判断した場合ステップS2012:No、ステップS2012へ戻る。スレーブCPUが、移行完了したと判断した場合ステップS2012:Yes、割り当てられたアプリの実行を開始しステップS2013、ステップS2001へ戻る。マルチコアプロセッサシステム100の適用例図21は、図1に示したマルチコアプロセッサシステム100の適用例を示す図である。図21において、ネットワークNWは、サーバ2101,2102とクライアント2131~2134とが通信可能なネットワークNWであり、たとえば、LANLocalAreaNetwork、WANWideAreaNetwork、インターネット、携帯電話網などで構成される。サーバ2102は、クラウド2120を構成するサーバ群サーバ2121~2125の管理サーバである。クライアント2131~2134のうち、クライアント2131はノート型パソコン、クライアント2132はデスクトップ型パソコン、クライアント2133は携帯電話機スマートフォン、PHSPersonalHandyphoneSystemでもよい、クライアント2134はタブレット型端末である。図21のサーバ2101,2102,2121~2125、クライアント2131~2134は、たとえば、図1に示したコンピュータにより実現される。また、本実施の形態は、図1に示した各CPU、および共有メモリ102がそれぞれ異なるコンピュータたとえば図21の携帯電話機やサーバに搭載され、複数のコンピュータがネットワークNWを介して分散型の並列処理をおこなう構成に適用することもできる。以上説明したように、リアルタイム制約が強いアプリの場合、いずれかのグループのグループマスタコアに割当指示し、グループマスタCPUに割り当てを行わせると、スケジューリング時間で性能が劣化してしまう。そこで、対象アプリを所定CPUに割り当てて、直ちに実行させる。これにより、対象アプリがスケジューリングによる影響で性能が劣化することを防止することができる。さらに、複数のアプリの起動指示が同時に発生した場合、全体マスタCPUがスケジューリングにかける負荷を減らすことができる。また、マルチコアプロセッサの各CPUでのアプリケーションの実行の有無に基づいて、所定CPUを決定する。これにより、リアルタイム制約が強いアプリが他のアプリとCPU上で競合せずに実行させることができ、アプリの性能劣化を防止することができる。また、リアルタイム制約が弱いアプリの場合、いずれかのグループのグループマスタCPUに割当指示し、グループマスタコアに割り当てを行わせることで、全体マスタCPUの負荷を軽減させることができる。また、アプリが割り当てられてから最も時間が経過しているCPUを所定CPUに決定する。最も時間が経過しているCPUであれば、リアルタイム制約の強いような緊急性の高いアプリケーションが実行されている可能性が低いため、リアルタイム制約の強いアプリを優先して実行させることができる。また、リアルタイム制約が強いアプリが所定CPUに割り当てられた場合、所定CPUから共有資源へのアクセス比率を該アプリの割当前よりも高くする。これにより、所定CPUと他のCPUとが共有資源でアクセス競合するのを防止することができ、アクセス競合によるアプリの実行性能が劣化するのを防止することができる。また、リアルタイム制約が強いアプリが所定CPUに割り当てられた場合、所定CPUが属するグループで共有する2次キャッシュを、所定CPUを除く他のCPUに利用させないようにする。これにより、2次キャッシュへのアクセスが競合しないため、アクセス競合によるアプリの実行性能が劣化するのを防止することができる。なお、本実施の形態で説明した制御方法は、あらかじめ用意された制御プログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本制御プログラムは、ハードディスク、フレキシブルディスク、CD-ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本制御プログラムは、インターネット等のネットワークを介して配布してもよい。"