JP5915656B2 - スケジューリング方法、およびスケジューリングシステム - Google Patents

Description

本発明は、アプリを割り当てるスケジューリング方法、およびスケジューリングシステムに関する。

従来、複数のコンピュータがネットワークを介してアプリケーション（以下、「アプリ」と称する。）を並列・分散処理する技術が知られている。関連する技術としては、たとえば、複数のコンピュータで分散処理を行う際に、各コンピュータの性能と負荷に応じて、処理の緊急度と優先順位を変更する手続きを行う技術が知られている。

さらに、近年では、携帯電話や、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）などの複数の携帯端末が無線ネットワークを介して並列処理を行う技術が知られている。

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

しかしながら、複数のコンピュータで並列処理を行うと、各処理をいずれのコンピュータに割り当てるかを決定するための機能（「マスター機能」と称する。）を有するコンピュータに負荷がかかる問題点がある。マスター機能を有するコンピュータがアプリを実行すると、マスター機能に関する処理によってアプリの性能が劣化する問題点がある。

本発明は、上述した従来技術による問題点を解消するため、アプリの性能劣化を低減することができるスケジューリング方法、およびスケジューリングシステムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一側面によれば、少なくとも一のデータ処理装置を含む第１グループに含まれる第１データ処理装置が起動対象のアプリケーションの優先度が所定の優先度であるか否かを判定し、前記アプリケーションの優先度が前記所定の優先度であるときは、それぞれが少なくとも一のデータ処理装置を含む複数のグループのうちの第２グループまたは前記第１グループに含まれる第２データ処理装置に前記第１データ処理装置の所定の機能を移転して前記第１データ処理装置が前記アプリケーションを実行し、前記アプリケーションの優先度が前記所定の優先度ではないときは、前記第１データ処理装置の実行キューに前記アプリケーションを配置するスケジューリング方法、およびスケジューリングシステムが提案される。

本発明の一側面によれば、アプリの性能劣化の低減を図ることができるという効果を奏する。

図１−１は、本発明による割り当て例（その１）を示す説明図である。 図１−２は、本発明による割り当て例（その２）を示す説明図である。 図２は、スケジューリングシステムの一例を示す説明図である。 図３は、各携帯端末２０１のハードウェア構成例を示す説明図である。 図４−１は、各携帯端末２０１のメモリ３０７管理の一例を示す説明図である。 図４−２は、ＧＬＯＢＡＬ領域の管理例を示す説明図である。 図４−３は、ＳＨＡＲＥＤ領域の管理例を示す説明図である。 図５は、各携帯端末２０１の有するテーブル例を示す説明図である。 図６は、スレッドテーブル６００の一例を示す説明図である。 図７−１は、各携帯端末２０１のＯＳ３２１の機能例を示すブロック図である。 図７−２は、各携帯端末２０１のＯＳ３２１の機能例を示すブロック図である。 図７−３は、各携帯端末２０１のＯＳ３２１の機能例を示すブロック図である。 図８−１は、対象アプリが強制アプリの場合の動作例（その１）を示す説明図である。 図８−２は、対象アプリが強制アプリの場合の動作例（その２）を示す説明図である。 図９は、対象アプリが強制アプリでない場合の動作例を示す説明図である。 図１０は、他のグループに対象アプリが割り当てられる例を示す説明図である。 図１１は、図１０で示した各通知のデータ構造の一例を示す説明図である。 図１２は、割り当て依頼通知が他のグループから送信された場合の例を示す説明図である。 図１３は、タイマ割り込みを検出した場合の全体マスター端末の動作例を示す説明図である。 図１４は、移転後のグループを示す説明図である。 図１５は、スレーブ端末がグループから離脱する例を示す説明図である。 図１６は、スレーブ端末が他のグループに移動する例を示す説明図である。 図１７は、スレーブ端末のグループ登録例を示す説明図である。 図１８は、全体マスター端末が行う処理手順の一例を示すフローチャート（その１）である。 図１９は、全体マスター端末が行う処理手順の一例を示すフローチャート（その２）である。 図２０は、全体マスター端末が行う処理手順の一例を示すフローチャート（その３）である。 図２１は、全体マスター端末が行う処理手順の一例を示すフローチャート（その４）である。 図２２は、全体マスター端末が行う処理手順の一例を示すフローチャート（その５）である。 図２３は、全体マスター端末が行う処理手順の一例を示すフローチャート（その６）である。 図２４は、全体マスター端末が行う処理手順の一例を示すフローチャート（その７）である。 図２５は、全体マスター端末が行う処理手順の一例を示すフローチャート（その８）である。 図２６は、図１８で示したグループ内負荷量解析処理（ステップＳ１８０４）の詳細な説明を示すフローチャートである。 図２７は、図２０で示した各グループ負荷量解析処理（ステップＳ１８１９）の詳細な説明を示すフローチャートである。 図２８は、図１８で示したデータ移行処理（ステップＳ１８０７）の詳細な説明を示すフローチャートである。 図２９は、グループマスター端末が行う処理手順の一例を示すフローチャート（その１）である。 図３０は、グループマスター端末が行う処理手順の一例を示すフローチャート（その２）である。 図３１は、グループマスター端末が行う処理手順の一例を示すフローチャート（その３）である。 図３２は、グループマスター端末が行う処理手順の一例を示すフローチャート（その４）である。 図３３は、グループマスター端末が行う処理手順の一例を示すフローチャート（その５）である。 図３４は、グループマスター端末が行う処理手順の一例を示すフローチャート（その６）である。 図３５は、グループマスター端末が行う処理手順の一例を示すフローチャート（その７）である。 図３６は、グループマスター端末が行う処理手順の一例を示すフローチャート（その８）である。 図３７は、図２９で示したデータ移行処理（ステップＳ２９０７）の詳細な説明を示すフローチャートである。 図３８は、スレーブ端末が行う処理手順を示すフローチャート（その１）である。 図３９は、スレーブ端末が行う処理手順を示すフローチャート（その２）である。 図４０は、スレーブ端末が行う処理手順を示すフローチャート（その３）である。 図４１は、スレーブ端末が行う処理手順を示すフローチャート（その４）である。 図４２は、スレーブ端末が行う処理手順を示すフローチャート（その５）である。

複数のコンピュータで並列処理や分散処理を行う場合、１台のマスター機能を有するコンピュータが複数のコンピュータの全体の制御を行うと、割り当てにかかる時間が大きくなる可能性がある。そこで、本実施の形態では、複数のコンピュータをグループ化し、スケジューリングシステムの全体を制御する全体マスター端末とグループに属するコンピュータを制御するグループマスター端末とが、割り当て処理を行うこととする。これにより、全体マスター端末の割り当てにかかる時間を減らし、全体マスター端末が過負荷状態となるのを回避することができる。

しかしながら、緊急性の高いアプリを実行する場合、全体マスター端末が割当先となるグループを決定する処理と、グループマスター端末がグループに属する複数の携帯端末から割当先を決定する処理との２段階の割り当て処理が行われる。緊急性の高いアプリとは、たとえば、動画処理や画像処理などのストリーミング系のアプリが挙げられ、携帯電話であれば電話やメールが挙げられる。たとえば、動画処理や画像処理などのストリーミング系のアプリでは、応答が遅いと処理が途切れてしまい、利用者に不快感を与えてしまうので、ここでは緊急性の高いアプリとして挙げる。また、緊急性の高いアプリとしては、応答性が早い方が利用者によいとスケジューリングシステムの設計者によって判断されたアプリである。２段階の割り当て処理が行われると、緊急性の高いアプリの場合、実行性能に影響を与える可能性がある。

また、全体マスター端末やグループマスター端末で緊急性の高いアプリが起動されると、全体マスター端末やグループマスター端末は、マスター機能に関する処理と、該アプリと、の両方を実行しなければならない。そのため、マスター機能に関する処理により該アプリの性能が劣化してしまう可能性がある。

そこで、本実施の形態では、緊急性の高いアプリであるか否かによって、割り当て方法を切り替えることで、アプリの性能劣化を低減させる。

本実施の形態では、並列処理を行うスケジューリングシステムについて、複数の携帯端末を例に挙げて説明する。たとえば、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）などの高速無線通信サービスによって、今後複数の携帯端末で並列分散処理を行うサービスが提供されることが予測される。以下に添付図面を参照して、本発明にかかるスケジューリング方法、およびスケジューリングシステムの実施の形態を詳細に説明する。

図１−１〜１−２は、本発明による割り当て例を示す説明図である。図１−１，１−２では、複数の携帯端末２０１が、第１グループであるグループＧ１と第２グループであるグループＧ２に分類されている。グループＧ１は携帯端末２０１−１〜２０１−４を有し、グループＧ２は携帯端末２０１−５〜２０１−８を有している。グループＧ１とグループＧ２との通信は、アクセスポイント２０２を介して接続される。アクセスポイント２０２とは、たとえば、携帯端末２０１であれば基地局である。グループＧ１の携帯端末２０１間の通信は、アドホックモードで直接接続される。

ここで、携帯端末２０１―１は、複数の携帯端末２０１で並列分散処理されるアプリやスレッドを割り当てる全体マスターの機能を有する全体マスター端末である。さらに、携帯端末２０１−１は、グループＧ１に含まれる携帯端末２０１にアプリやスレッドを割り当てるグループマスターの機能を有する。ここで、携帯端末２０１―５は、グループＧ２に含まれる携帯端末２０１にアプリやスレッドを割り当てるグループマスターの機能を有するグループマスター端末である。

たとえば、携帯端末２０１―１が起動要求の発生した対象アプリの優先度が所定の優先度であるか否かを判定する。携帯端末２０１−１は、対象アプリの優先度が所定の優先度であれば、対象アプリを緊急性の高いアプリであると判断し、対象アプリの優先度が所定の優先度でなければ、対象アプリを緊急性の高くないアプリであると判断する。ここでは、たとえば、対象アプリの優先度は、対象アプリの設計者によりあらかじめ定められていることとする。

まず、図１−１の例では、携帯端末２０１−１が、対象アプリの優先度が所定の優先度であると判断する。そして、携帯端末２０１−１が、アプリの優先度が所定の優先度である場合、グループＧ２またはグループＧ１に含まれる他の携帯端末２０１に全体マスター端末の機能を移転する。図１−１の例では、携帯端末２０１−１が、携帯端末２０１−２に全体マスターの機能を移転する。そして、携帯端末２０１−１が対象アプリの実行を直ちに開始する。これにより、携帯端末２０１−１が対象アプリの実行に処理を専念できる。

つぎに、図１−２の例では、携帯端末２０１−１が、対象アプリの優先度が所定の優先度でないと判断する。そして、携帯端末２０１−１が、対象アプリの優先度が所定の優先度でない場合、ランキューにアプリを登録する。これにより、携帯端末２０１−１が、対象アプリと全体マスター端末の機能に関する処理とを切り替えながら実行する。

（スケジューリングシステム例）
図２は、スケジューリングシステムの一例を示す説明図である。スケジューリングシステム２００では、複数の携帯端末２０１−１〜２０１−ｎ（ｎ≧２，図２ではｎ＝１６）と、アクセスポイント２０２−１〜２０２−ｍ（ｍ≧１，図２ではｍ＝３）と、を有している。複数の携帯端末２０１−１〜２０２−１６はグループに群分けされている。

携帯端末２０１間は、無線ＬＡＮネットワークで接続される。たとえば、異なるグループの携帯端末２０１同士は、アクセスポイント２０２を介して通信を行い、同一のグループの携帯端末２０１同士は、アクセスポイント２０２を介さずに直接通信を行う。また、携帯端末２０１は、常時同一のアクセスポイント２０２に接続するのではなく、近傍のアクセスポイント２０２を探索する。アクセスポイント２０２間については、たとえば、有線ＬＡＮネットワークで接続されている。

図２では、グループＧ１には携帯端末２０１−１〜２０１−４が属し、グループＧ２には携帯端末２０１−５〜２０１−８が属し、グループＧ３には携帯端末２０１−９〜２０１−１２が属し、グループＧ４には携帯端末２０１−１３〜２０１−１６が属する。グループについては、たとえば、同一アクセスポイント２０２を介する携帯端末２０１ごとに所定数で分けてもよい。

また、複数の携帯端末２０１は、あらかじめ該スケジューリングシステム２００に属する識別情報を有していることとする。複数の携帯端末２０１−１〜２０１−１６は、全体マスター端末と、グループマスター端末と、スレーブ端末に分類される。全体マスター端末は、スケジューリングシステム２００の全体を制御し、全体マスター端末が属するグループのグループマスター端末でもある。図２の例では、全体マスター端末は、携帯端末２０１−１である。

グループマスター端末は、グループマスター端末が属するグループの全体を制御する。図２の例では、グループＧ１のグループマスター端末は携帯端末２０１−１であり、グループＧ２のグループマスター端末は携帯端末２０１〜５である。そして、図２の例では、グループＧ３のグループマスター端末は携帯端末２０１−９であり、グループＧ４のグループマスター端末は携帯端末２０１−１３である。複数の携帯端末２０１−１〜２０１−１６のうち、全体マスター端末とグループマスター端末を除く残余の携帯端末２０１は、スレーブ端末である。

全体マスター端末が、複数の携帯端末２０１で並列処理可能な対象アプリの起動指示を受け付けると、実行要求をスレーブ端末に送信する。つぎに、各携帯端末２０１のハードウェア構成例を図３に示す。本実施の形態では、理解の容易化のために、すべての携帯端末２０１を同一のハードウェア構成としている。

（各携帯端末２０１のハードウェア構成例）
図３は、各携帯端末２０１のハードウェア構成例を示す説明図である。携帯端末２０１は、ＣＰＵ３０１と、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）３０２と、Ｉ／Ｆ（ＩｎｔｅｒＦａｃｅ）３０４と、メモリコントローラ３０６と、メモリ３０７と、ストレージ３０９と、ストレージコントローラ３０８と、を有している。ＣＰＵ３０１と、Ｉ／Ｏ３０２と、Ｉ／Ｆ３０４と、メモリコントローラ３０６と、ストレージコントローラ３０８とは、バス３１０を介して接続されている。

ここで、ＣＰＵ３０１は、携帯端末２０１の全体の制御を司る。ＣＰＵ３０１は、レジスタとコアとキャッシュを有している。コアは、演算機能を有している。各ＣＰＵ３０１内のレジスタは、ＰＣ（Ｐｒｏｇｒａｍ Ｃｏｕｎｔｅｒ）やリセットレジスタを有している。ＣＰＵ３０１はＯＳ３２１を実行し、ＯＳ３２１は携帯端末２０１に割り当てられたアプリやスレッドを実行する。ＯＳ３２１は、ウエイトキュー３３１と、ランキュー３３２を有している。ＯＳ３２１は、ウエイトキュー３３１にアプリが積まれると、該アプリの起動指示を受け付けたと判断する。ＯＳ３２１は、実行待機中のアプリやスレッドを実行キューであるランキュー３３２に積むことで、複数のアプリやスレッドを切り替えて実行することができる。

Ｉ／Ｏ３０２は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。Ｉ／Ｏ３０２は、たとえば、ＴＦＴ液晶ディスプレイなどを採用することができる。また、Ｉ／Ｏ３０２は、タッチパネル式の入力パッドであり、数字、各種指示などの入力を受け付けることができる。

Ｉ／Ｆ３０４は、無線通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク３０５に接続され、ネットワーク３０５を介して他の携帯端末２０１に接続される。そして、Ｉ／Ｆ３０４は、ネットワーク３０５と内部のインターフェースを司り、外部装置や他の携帯端末２０１からのデータの入出力を制御する。Ｉ／Ｆ３０４には、たとえば、無線通信用のモデムを採用することができる。たとえば、Ｉ／Ｆ３０４は、アドホックモードにより他の携帯端末２０１と直接通信を行い、インフラストラクチャー・モードにより他の携帯端末２０１とアクセスポイント２０２を介して通信を行う機能を有する。

ストレージ３０９は、たとえば、ＲＯＭ、フラッシュＲＯＭなどが挙げられる。ストレージコントローラ３０８は、ＣＰＵ３０１からストレージ３０９へのアクセスを制御する。たとえば、ＲＯＭは、ブートプログラムなどのプログラムを記憶している。フラッシュＲＯＭは、ＯＳ３２１などのシステムソフトウェアやアプリケーションのプログラムを記憶している。

メモリ３０７は、各ＣＰＵ３０１のワークエリアとして使用される。メモリコントローラ３０６は、ＣＰＵ３０１からメモリ３０７へのアクセスを制御する。メモリ３０７は、たとえば、ＲＡＭが挙げられる。つぎに、メモリ３０７の管理について図４−１〜４−３を用いて説明する。

（各携帯端末２０１のメモリ３０７管理例）
図４−１は、各携帯端末２０１のメモリ３０７管理の一例を示す説明図である。本実施の形態では、全体マスター端末とグループマスター端末の２段階で処理の割り当てを決定する。そこで、本実施の形態では、割り当てや並列処理を容易化させるために、各携帯端末２０１がメモリ３０７の領域を３つの領域に分割して管理する。ただし、携帯端末２０１が、緊急性の高いアプリ（以下、「強制アプリ」と称する。）を実行中であれば、強制アプリにメモリ３０７を独占して使用させるために３つの領域に分けない。図４−１で示すように、携帯端末２０１が強制アプリを実行していない場合にメモリ３０７は、ＧＬＯＢＡＬ領域と、ＳＨＡＲＥＤ領域と、ＬＯＣＡＬ領域と、の３つの領域に分けて管理される。

たとえば、ＧＬＯＢＡＬ領域は第１領域であり、ＧＬＯＢＡＬ領域には、異なるグループで割り当てられたアプリやスレッドに関するデータが記憶され、該スケジューリングシステム２００全体に関する情報が記憶される。たとえば、ＳＨＡＲＥＤ領域は第２領域であり、ＳＨＡＲＥＤ領域には、携帯端末２０１が属するグループのグループマスター端末に割り当てられたアプリの命令コードやアプリのデータやスレッド間で共有するデータなどが記憶される。たとえば、ＬＯＣＡＬ領域には、携帯端末２０１でのみ実行されるアプリやスレッドに関する情報が記憶される。

また、携帯端末２０１が強制アプリを実行している場合にメモリ３０７領域が分類されていると、強制アプリの実行性能に影響を与える可能性があるため、携帯端末２０１が強制アプリを実行している場合には、メモリ３０７領域をすべてＬＯＣＡＬ領域とする。

メモリ管理テーブル４００は、領域名、アドレスのフィールドを有している。領域名のフィールドには、ＬＯＣＡＬ、ＳＨＡＲＥＤ、ＧＬＯＢＡＬが登録されている。アドレスのフィールドには、領域ごとに確保されたアドレス情報が登録される。携帯端末２０１が強制アプリを実行していない場合のメモリ管理テーブル４００には、各領域に対応するアドレスのフィールドにはアドレス情報が登録されている。携帯端末２０１が強制アプリを実行している場合のメモリ管理テーブル４００には、ＳＨＡＲＥＤ領域とＧＬＯＢＡＬ領域に対応するアドレスのフィールドにはアドレス情報が登録されていない。メモリ管理テーブル４００については、ＬＯＣＡＬ領域または書き込み可能なストレージ３０９に記憶されていることとする。

図４−２は、ＧＬＯＢＡＬ領域の管理例を示す説明図である。図４−２では、各携帯端末２０１のメモリ３０７であることを明確にするため、各携帯端末２０１に付された通し番号と同一の番号がメモリ３０７にも付してある。ここでは、ＧＬＯＢＡＬ領域は、ＣＰＵ３０１のキャッシュのスヌープ処理のように管理される。たとえば、ある携帯端末２０１がＧＬＯＢＡＬ領域内のデータを変更しても、他の携帯端末２０１が有するＧＬＯＢＡＬ領域内の該データを同様に更新することができるようにする。

図４−２では、携帯端末２０１−４でＧＬＯＢＡＬ領域への書き込み要求が発生し、ＧＬＯＢＡＬ領域に変更が発生した例を示している。たとえば、携帯端末２０１−４ではＧＬＯＢＡＬ領域への書き込み要求はメモリコントローラ３０６が検出することとする。そして、携帯端末２０１−４のメモリコントローラ３０６がＣＰＵ３０１に対して該書き込み要求の検出を通知し、携帯端末２０１のＣＰＵ３０１が、（１）Ｉ／Ｆ３０４を介して全体マスター端末である携帯端末２０１−１にデータの変更通知を送信する。

そして、携帯端末２０１−１が該データの変更通知を受信すると、該データをＧＬＯＢＡＬ領域に有している場合、該データを更新する。そして、携帯端末２０１−１が、（２）他のグループのグループマスター端末である携帯端末２０１−５と携帯端末２０１−９と携帯端末２０１−１３とにデータの変更通知を送信する。さらに、携帯端末２０１−１が、（３）携帯端末２０１−１が属するグループＧ１のスレーブ端末である携帯端末２０１−２と携帯端末２０１−３に対して該データの変更通知を送信する。

そして、各グループのグループマスター端末である携帯端末２０１−５や携帯端末２０１−９や携帯端末２０１−１３は、データの変更通知を受け付けると、該データをそれぞれのＧＬＯＢＡＬ領域に有している場合、（４）該データを更新する。そして、携帯端末２０１−５や携帯端末２０１−９や携帯端末２０１−１３は、（５）それぞれが属するグループのスレーブ端末に該データの変更通知を送信する。各スレーブ端末は、該データの変更通知を受け付けると、該データをＧＬＯＢＡＬ領域に有している場合、（６）該データを更新する。

図４−３は、ＳＨＡＲＥＤ領域の管理例を示す説明図である。ここでは、ＳＨＡＲＥＤ領域については、分散共有メモリのように、グループ内の携帯端末２０１で共有することとする。また、位置情報は、全体マスター端末やグループマスター端末が有していることとする。位置情報の詳細は、図５にて後述する。

図４−３の例では、たとえば、全体マスター端末である携帯端末２０１−１が、（１）割り当て指示の送信によってスレッドを携帯端末２０１−３に割り当て、（２）スレッドの格納指示を携帯端末２０１−２に送信する。そして、携帯端末２０１−２は、（３）格納指示によってスレッドの命令コードをＳＨＡＲＥＤ領域に格納する。携帯端末２０１−３は、（４）携帯端末２０１−２のＳＨＡＲＤ領域に記憶されたスレッドの命令コードを参照することで、割り当てられたスレッドを実行する。スレッドの命令コードを参照するとは、具体的には、たとえば、携帯端末２０１−３がＩ／Ｆ３０４を介して携帯端末２０１−２にアドホックモードで通信を行い、携帯端末２０１−２のＳＨＡＲＥＤ領域にアクセスする。

（各携帯端末２０１の有するテーブル例）
図５は、各携帯端末２０１の有するテーブル例を示す説明図である。各携帯端末２０１は、全体マスター端末の機能を処理している場合と、グループマスター端末の機能を処理している場合と、スレーブ端末の機能を処理している場合と、で保持しているテーブルが異なる。

まず、たとえば、全体マスター端末は、グループマスター端末情報５０１と、位置情報５０２と、スレッドテーブル６００と、を有している。図５では、全体マスター端末である携帯端末２０１−１の例が挙げられている。グループマスター端末情報５０１には、いずれの携帯端末２０１が各グループのグループマスター端末であるかが登録されている。たとえば、グループマスター端末情報５０１には、グループマスター端末の識別情報が登録されている。これにより、全体マスター端末は、グループマスター端末情報５０１に登録されている携帯端末２０１の識別情報に基づいて、各グループにアプリやスレッドの割り当て依頼通知や実行終了通知を送信することができる。

位置情報５０２には、全体マスター端末のグループに属する各スレーブ端末の位置に関する情報が登録されている。上述したように、同一グループ内であれば、全体マスター端末とスレーブ端末とは、アドホックモードにより通信が行われるため、全体マスター端末は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）などを用いて取得したスレーブ端末の位置に関する情報を有していることとする。位置情報５０２は、グループ内端末ＩＤ、位置のフィールドを有している。グループ内端末ＩＤのフィールドには、全体マスター端末のグループに属するスレーブ端末の識別情報が登録されている。位置のフィールドには、全体マスター端末のグループに属するスレーブ端末の位置情報が登録されている。グループマスター端末情報５０１は、全体マスター端末のメモリ３０７などの記憶装置に記憶されている。位置情報５０２は、上述したようにメモリ３０７のＳＨＡＲＥＤ領域に記憶されている。スレッドテーブル６００については、図６を用いて後述する。

つぎに、たとえば、グループマスター端末は、全体マスター端末情報５０３と、位置情報５０４と、スレッドテーブル６００と、を有している。全体マスター端末情報５０３には、全体マスター端末の識別情報が登録されている。図５では、グループマスター端末である携帯端末２０１−５の例が挙げられている。これにより、グループマスター端末が、後述する割り当て依頼通知やマイグレーション依頼通知や実行終了通知などを全体マスター端末へ送信することができる。

位置情報５０４には、グループマスター端末のグループに属する各スレーブ端末の位置に関する情報が登録されている。位置情報５０４は、グループ内端末ＩＤ、位置のフィールドを有している。グループ内端末ＩＤのフィールドには、グループマスター端末のグループに属するスレーブ端末の識別情報が登録されている。位置のフィールドには、全体マスター端末のグループに属するスレーブ端末の位置情報が登録されている。これにより、グループマスター端末が、同一グループに属するスレーブ端末とアドホックモードにより通信を行うことができる。全体マスター端末情報５０３は、全体マスター端末のメモリ３０７などの記憶装置に記憶されている。位置情報５０４は、上述したようにメモリ３０７のＳＨＡＲＥＤ領域に記憶されている。スレッドテーブル６００については、図６を用いて後述する。

そして、スレーブ端末は、グループマスター端末情報５０５と、スレッドテーブル６００と、を有している。図５では、スレーブ端末である携帯端末２０１−２の例が挙げられている。グループマスター端末情報５０５は、スレーブ端末が属するグループのグループマスター端末の識別情報が登録されている。これにより、各スレーブ端末が、後述する割り当て依頼通知やマイグレーション依頼通知や実行終了通知などをグループマスター端末へ送信することができる。グループマスター端末情報５０５は、全体マスター端末のメモリ３０７などの記憶装置に記憶されている。つぎに、スレッドテーブル６００について、図６を用いて説明する。

（スレッドテーブル６００）
図６は、スレッドテーブル６００の一例を示す説明図である。スレッドテーブル６００には、各アプリに関する情報が登録されている。ここで、アプリは１以上のスレッドを有している。スレッドとは、ＣＰＵ３０１で実行される処理の単位である。本実施の形態では、アプリが１スレッドのみを有している場合、アプリとスレッドは同一であるが、アプリが２以上のスレッドを有している場合、２以上のスレッドの集合をアプリと称する。

スレッドテーブル６００は、アプリＩＤ、スレッドＩＤ、共有データ、フラグ、終了時刻、負荷量のフィールドを有している。各フィールドに値が設定されることで、スレッド情報（たとえば、６０１−１，６０１−２）がレコードとして記憶される。

アプリＩＤのフィールドには、アプリの識別情報が登録される。スレッドＩＤのフィールドには、スレッドの識別情報が登録される。共有データのフィールドには、複数のスレッドで共有されるデータが登録される。

フラグのフィールドには、アプリが強制アプリであるか否かを示す値が登録される。本実施の形態では、アプリの優先度を強制アプリであるか否かによって表すこととする。強制アプリであると分類されたアプリは、アプリの優先度が所定の優先度であると識別され、強制アプリでないと分類されたアプリは、アプリの優先度が所定の優先度でないと識別されることとする。たとえば、フラグのフィールドに０が登録されているアプリは、強制アプリでないが、フラグのフィールドに１が登録されているアプリは、強制アプリである。スレッドテーブル６００は、各携帯端末２０１のメモリ３０７やストレージ３０９などの記憶装置に記憶されていることとする。

終了時刻のフィールドには、スレッドの実行を終了させなければならない時刻が登録される。ここでは、たとえば、終了時刻のフィールドに時刻情報が設定されているスレッドは、リアルタイム制約を有していると判断され、終了時刻のフィールドに時刻情報が設定されていないスレッドは、リアルタイム制約を有していないと判断される。また、図示していないが、実行開始から実行終了までの時間があらかじめ決定されている場合にもスレッドは、リアルタイム制約があると判断される。

本実施の形態では、理解の容易化のために、すべての携帯端末２０１が同一のスレッドテーブル６００を有していることとしている。実際には、携帯端末２０１によってダウンロードされるアプリが異なるため、各携帯端末２０１が異なるスレッドテーブル６００を有することとなる。または、並列分散処理されるスレッドの情報のみをスレッドテーブル６００に登録し、各携帯端末２０１のみで処理されるスレッド情報は各携帯端末２０１でテーブル化してもよい。

また、理解の容易化のため、すべての携帯端末２０１が同一のハードウェア構成であるとしているため、負荷量がすべての携帯端末２０１で共通化されているが、実際には携帯端末２０１のＣＰＵ３０１性能によって負荷量が異なる。

（各携帯端末２０１のＯＳ３２１の機能例を示すブロック図）
図７−１〜７−３は、各携帯端末２０１のＯＳ３２１の機能例を示すブロック図である。各携帯端末２０１のＯＳ３２１は、全体マスター端末の機能と、グループマスター端末の機能と、スレーブ端末の機能と、をすべて有しているが、各携帯端末２０１は各機能の有効無効を設定可能であることとする。これにより、各携帯端末２０１は、全体マスター端末の機能やグループマスター端末の機能を移転させたり、全体マスター端末やグループマスター端末に遷移したりすることができる。

図７−１では、全体マスター端末である場合のＯＳ３２１（「全体マスター端末のＯＳ３２１」と称する。）の機能ブロック図を示している。全体マスター端末のＯＳ３２１は、検出部７０１＃１と、アプリ識別部７０２＃１と、第１スケジューラ７０３＃１と、第２スケジューラ７０４＃１と、負荷量解析部７０５＃１と、を有している。さらに、全体マスター端末のＯＳ３２１は、遷移部７０６＃１と、実行部７０７＃１と、判断部７０８＃１と、更新部７０９＃１と、格納部７１０＃１と、を有している。

検出部７０１＃１から格納部７１０＃１の処理がＯＳ３２１にコーディングされている。ＣＰＵ３０１が、ストレージ３０９などの記憶装置に記憶されているＯＳ３２１を読み出し、ＯＳ３２１にコーディングされている処理を実行する。これにより、検出部７０１＃１から格納部７１０＃１の機能が実現される。

図７−２では、グループマスター端末である場合のＯＳ３２１（「グループマスター端末のＯＳ３２１」と称する。）の機能ブロック図を示している。グループマスター端末のＯＳ３２１は、検出部７０１＃２と、アプリ識別部７０２＃２と、第１スケジューラ７０３＃２と、第２スケジューラ７０４＃２と、負荷量解析部７０５＃２と、を有している。さらに、グループマスター端末のＯＳ３２１は、遷移部７０６＃２と、実行部７０７＃２と、判断部７０８＃２と、更新部７０９＃２と、格納部７１０＃２と、を有している。検出部７０１＃２から格納部７１０＃２の処理がＯＳ３２１にコーディングされている。ＣＰＵ３０１が、ストレージ３０９などの記憶装置に記憶されているＯＳ３２１を読み出し、ＯＳ３２１にコーディングされている処理を実行する。これにより、検出部７０１＃２から格納部７１０＃２の機能が実現される。

図７−３では、スレーブ端末である場合のＯＳ３２１（「スレーブ端末のＯＳ３２１」と称する。）の機能ブロック図を示している。スレーブ端末のＯＳ３２１は、検出部７０１＃３と、アプリ識別部７０２＃３と、スケジューラ７０３＃３と、負荷量解析部７０４＃３と、遷移部７０５＃３と、実行部７０６＃３と、判断部７０７＃３と、格納部７０８＃３と、を有している。検出部７０１＃３から格納部７０８＃３の処理がＯＳ３２１にコーディングされている。ＣＰＵ３０１が、ストレージ３０９などの記憶装置に記憶されているＯＳ３２１を読み出し、ＯＳ３２１にコーディングされている処理を実行する。これにより、検出部７０１＃３から格納部７０８＃３の機能が実現される。

つぎに、図７−１〜７−３で示したＯＳ３２１の機能について、実施例１〜実施例６を挙げて詳細に説明する。

（実施例１）
まず、実施例１では、全体マスター端末において、強制アプリの起動要求を受け付けたら、強制アプリを優先的に実行させるために、全体マスター端末の機能を他の携帯端末２０１に移転する。これにより、強制アプリの実行にＣＰＵ３０１の能力を割り当てることができ、強制アプリの性能劣化を低減することで、強制アプリの応答性を向上させることができる。

まず、全体マスター端末の検出部７０１＃１は、イベントの発生を検出する。ここでは、具体的には、たとえば、全体マスター端末の検出部７０１＃１は、アプリ（対象アプリ）の起動要求を検出することとする。つぎに、全体マスター端末のアプリ識別部７０２＃１は、検出部７０１＃１により対象アプリの起動要求が検出されると、対象アプリが強制アプリであるか否かを識別する。具体的には、たとえば、全体マスター端末のアプリ識別部７０２＃１は、対象アプリの識別情報に基づいてスレッドテーブル６００を参照し、対象アプリに関するスレッド情報のフラグのフィールドの値を特定する。そして、たとえば、全体マスター端末のアプリ識別部７０２＃１は、特定した値が１であれば、対象アプリを強制アプリであると識別し、特定した値が０であれば、対象アプリを強制アプリでないと識別する。

そして、全体マスター端末の第１スケジューラ７０３＃１は、アプリ識別部７０２＃１によって対象アプリが強制アプリであると識別した場合に、全体マスター端末の機能を移転する移転先の携帯端末２０１を選択する。つぎに、対象アプリが強制アプリである場合の詳細な動作例を説明する。

図８−１は、対象アプリが強制アプリの場合の動作例（その１）を示す説明図である。具体的には、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、アプリ識別部７０２＃１によって対象アプリが強制アプリであると識別された場合に、同一グループＧ１内の各スレーブ端末の負荷量を負荷量解析部７０５＃１に解析させる。全体マスター端末の負荷量解析部７０５＃１は、グループＧ１内の各スレーブ端末の負荷量を解析する。具体的には、たとえば、全体マスター端末の負荷量解析部７０５＃１は、グループＧ１内の各スレーブ端末に負荷量算出通知を送信する。

各スレーブ端末の検出部７０１＃３は、負荷量算出通知の受信を検出する。そして、各スレーブ端末の負荷量解析部７０４＃３は、スレーブ端末で実行中または実行待機中のアプリやスレッドの負荷量の合計値を算出する。そして、各スレーブ端末の負荷量解析部７０４＃３は、算出した負荷量の合計値をスレーブ端末の負荷量として負荷量算出通知の送信元の携帯端末２０１へ送信する。

そして、全体マスター端末の負荷量解析部７０５＃１は、各スレーブ端末から、スレーブ端末で実行中または実行待機中のアプリやスレッドの負荷量の合計値を受け付ける。図８−１では、携帯端末２０１−３の負荷量の合計値が７５［％］であり、携帯端末２０１−４の負荷量の合計値が７５［％］であり、携帯端末２０１−２の負荷量の合計値が３０［％］である。

そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、グループＧ１内の強制アプリを実行していないスレーブ端末から、負荷量が最小のスレーブ端末を全体マスター端末の機能の移転先として選択する。ここでは、たとえば、移転先を携帯端末２０１−２とする。

図８−２は、対象アプリが強制アプリの場合の動作例（その２）を示す説明図である。全体マスター端末の第１スケジューラ７０３＃１は、アプリ識別部７０２＃１により対象アプリが強制アプリであると識別された場合、ＧＬＯＢＡＬ領域に記憶されているデータをすべて廃棄する。そして、全体マスター端末の第１スケジューラ７０３＃１は、全体マスター端末の機能の移転先に決定された携帯端末２０１−２のＳＨＡＲＥＤ領域に携帯端末２０１のＳＨＡＲＥＤ領域に記憶された位置情報５０２を移行させる。

つぎに、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、ＳＨＡＲＥＤ領域に記憶されたデータから順に移行対象データに選択する。そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、選択された移行対象データと依存関係のあるアプリまたはスレッドを実行中の携帯端末２０１を特定する。たとえば、全体マスター端末の第１スケジューラ７０３＃１は、スレッドテーブル６００を参照することで、いずれのスレッドが移行対象データを利用しているかを特定する。そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、特定したスレッドが割り当てられているグループＧ１内のスレーブ端末を特定する。

たとえば、携帯端末２０１−１のＳＨＡＲＥＤ領域に記憶されているデータａは、スレッド８０１−１−１とスレッド８０１−１−２で共有される共有データである。図８−２では、スレッド８０１−１−２が携帯端末２０１−４に割り当てられているため、全体マスター端末の第１スケジューラ７０３＃１は、携帯端末２０１−４にデータａを送信することで、携帯端末２０１−４のＳＨＡＲＥＤ領域にデータａを記憶させる。

たとえば、携帯端末２０１−１のＳＨＡＲＥＤ領域に記憶されているデータｋは、スレッド８０１−１−１とスレッド８０１−１−２で共有される共有データである。図８−２では、スレッド８０１−１−２が携帯端末２０１−４に割り当てられているため、全体マスター端末の第１スケジューラ７０３＃１は、携帯端末２０１−４にデータｋを送信することで、携帯端末２０１−４のＳＨＡＲＥＤ領域にデータｋを記憶させる。

たとえば、携帯端末２０１−１のＳＨＡＲＥＤ領域に記憶されているデータｂは、スレッド８０１−１−１とスレッド８０１−１−３で共有される共有データである。図８−２では、スレッド８０１−１−３が携帯端末２０１−３に割り当てられているため、全体マスター端末の第１スケジューラ７０３＃１は、携帯端末２０１−３にデータｂを送信することで、携帯端末２０１−３のＳＨＡＲＥＤ領域にデータｂを記憶させる。

そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、メモリ管理テーブル４００のＬＯＣＡＬ領域に関するアドレスのフィールドにＧＬＯＢＡＬ領域とＳＨＡＲＥＤ領域のアドレスを追加する。そして、全体マスター端末の第１スケジューラ７０３＃１は、メモリ管理テーブル４００のＧＬＯＢＡＬ領域のアドレスのフィールドと、ＳＨＡＲＥＤ領域のアドレスのフィールドと、を空にする。これにより、強制アプリが実行中にメモリ３０７の空間を広く使用することができる。

図８−１に戻って、つぎに、全体マスター端末の第１スケジューラ７０３＃１は、全体マスター端末の機能の移転先に決定した携帯端末２０１−２に全体マスター端末への遷移通知を送信する。具体的には、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、スレーブ端末の機能から全体マスター端末の機能への遷移通知を携帯端末２０１−２に送信する。

さらに、全体マスター端末の第１スケジューラ７０３＃１は、各グループマスター端末に全体マスター端末の機能の移転先を通知する。そして、全体マスター端末の遷移部７０６＃１は、全体マスター端末の機能からスレーブ端末の機能に遷移する。そして、全体マスター端末からスレーブ端末に遷移した携帯端末２０２−２の実行部７０７＃３は、対象アプリを実行する。

そして、たとえば、携帯端末２０１−２の検出部７０１＃３が、スレーブ端末の機能から全体マスター端末の機能への遷移通知の受信を検出し、携帯端末２０１−２の遷移部７０５＃１が、スレーブ端末の機能から全体マスター端末の機能に遷移する。

実施例１によれば、強制アプリを優先的に実行させることができ、強制アプリの応答性を向上させることができる。さらに、実施例１によれば、強制アプリの実行時には、他の携帯端末２０１と並列分散処理を行うために記憶されたデータを他の携帯端末２０１に移行させることで、強制アプリがメモリ３０７を使用可能な領域を最大限に広げることができる。これにより、強制アプリの実行性能を向上させることができる。

また、実施例１では、全体マスター端末を例に挙げているが、グループマスター端末も同様に、起動要求の発生した対象アプリが強制アプリであれば、グループマスター端末の機能を他の携帯端末２０１に移転させる。さらに、全体マスター端末の機能やグループマスター端末の機能だけでなく、割り当てられているスレッドを他の携帯端末２０１に移行させてもよい。

（実施例２）
つぎに、実施例２では、起動要求の発生した対象アプリが強制アプリでない場合であっても、携帯端末２０１の負荷が余力を超えそうな場合には他の携帯端末２０１に対象アプリを割り当てる。これにより、対象アプリやすでに携帯端末２０１で実行中のアプリや実行待機中のアプリの性能劣化を低減させることができる。

図９は、対象アプリが強制アプリでない場合の動作例を示す説明図である。全体マスター端末の第２スケジューラ７０４＃１は、アプリ識別部７０２＃１によって対象アプリが強制アプリでないと識別した場合に、ランキュー３３２に対象アプリを登録する。具体的には、たとえば、全体マスター端末の負荷量解析部７０５＃１は、携帯端末２０１に割り当てられたアプリおよびスレッドの負荷量の合計値を算出する。

つぎに、たとえば、全体マスター端末の第２スケジューラ７０４＃１は、負荷量解析部７０５＃１によって算出された負荷量の合計値が閾値未満であるか否かを判断する。図９の例では、アプリまたはスレッドのそれぞれに括弧（ ）で負荷量を示している。全体マスター端末の第２スケジューラ７０４＃１は、負荷量の合計値（４０［％］＋４０［％］＝８０［％］）が閾値（たとえば、７０［％］）より大きいと判断する。ここで、閾値については、図９の例ではスケジューリングシステム２００の設計者が決定した固定値となっているが、１００［％］から対象アプリの負荷量を引いた値であってもよい。

全体マスター端末の負荷量解析部７０５＃１は、負荷量の合計値が閾値より大きいと判断された場合、グループＧ１内の各スレーブ端末の負荷量を解析する。全体マスター端末の負荷量解析部７０５＃１によるグループ内の各スレーブ端末の負荷量の解析については、実施例１で説明した処理と同一であるため、詳細な説明を省略する。

全体マスター端末の第２スケジューラ７０４＃１は、負荷量解析部７０５＃１によって解析された各スレーブ端末の負荷量が閾値未満であるか否かを判断する。ここで、閾値は、たとえば、対象アプリの負荷量であってもよいし、スケジューリングシステム２００の設計者が決定した固定値であってもよい。図９の例では、全体マスター端末の第２スケジューラ７０４＃１は、携帯端末２０１−３の負荷量と携帯端末２０１−４の負荷量が閾値より大きいと判断し、携帯端末２０１−２の負荷量が閾値未満であると判断する。そして、全体マスター端末の第２スケジューラ７０４＃１は、負荷量が閾値未満である携帯端末２０１−２に対象アプリを割り当てる。

実施例２によれば、起動要求の発生した対象アプリやすでに携帯端末２０１で実行中のアプリや実行待機中のアプリの性能劣化を低減させることができる。

また、実施例２では、全体マスター端末を例に挙げているが、グループマスター端末やスレーブ端末も同様に、対象アプリを実行可能な余力が無い場合に、対象アプリを同一グループ内の他の携帯端末２０１に割り当ててもよい。

（実施例３）
つぎに、実施例３では、対象アプリが強制アプリでない場合に、起動要求の発生した対象アプリを実行するための余力のある携帯端末２０１が同一グループ内に無い場合、他のグループの余力のある携帯端末２０１に対象アプリを割り当てる。これにより、グループ間の負荷を分散させることができ、対象アプリの性能劣化を低減させることができる。

図１０は、他のグループに対象アプリが割り当てられる例を示す説明図である。ここでは、全体マスター端末のアプリ識別部７０２＃１が、対象アプリを強制アプリでないと識別済であり、全体マスター端末の負荷量解析部７０５＃１が、グループ内のスレーブ端末の負荷量を解析済であるとする。

そして、全体マスター端末の第２スケジューラ７０４＃１は、負荷量が閾値未満であるグループＧ１内のスレーブ端末がないと判断した場合、負荷量解析部７０５＃１に他のグループの負荷状況を解析させる。具体的には、たとえば、全体マスター端末の負荷量解析部７０５＃１が、各グループのグループマスター端末へ負荷状況通知を送信する。

そして、たとえば、各グループマスター端末の検出部７０１＃２が、負荷状況通知の受信を検出する。つぎに、たとえば、各グループマスター端末の負荷量解析部７０５＃２が、グループ内のスレーブ端末の負荷量を解析する。グループ内のスレーブ端末の負荷量の解析については、実施例１で説明した全体マスター端末による処理と同一であるため、詳細な説明を省略する。

そして、たとえば、各グループマスター端末の負荷量解析部７０５＃２は、負荷量が閾値未満であるスレーブ端末があるか否かを判断する。そして、たとえば、各グループマスター端末の負荷量解析部７０５＃２は、判断結果を負荷状況として全体マスター端末に送信する。

そして、たとえば、全体マスター端末の検出部７０１＃１が、各グループマスター端末から負荷状況の受信を検出する。ここでは、全体マスター端末の検出部７０１＃１は、各グループマスター端末から負荷状況を受信すると共に、携帯端末２０１−１と各グループマスター端末との通信速度を取得することとする。ここでは、たとえば、携帯端末２０１−１から各グループマスター端末まで負荷状況通知がいくつのアクセスポイント２０２を介して送信されたかを通信速度の目安とする。図１０の例では、携帯端末２０１−１から携帯端末２０１−５までの負荷状況通知がアクセスポイント２０２を１個経由して送信され、携帯端末２０１−１から携帯端末２０１−９までの負荷状況通知がアクセスポイント２０２を２個経由して送信された。また、たとえば、全体マスター端末が、負荷状況通知の送信時刻から各グループマスター端末からの負荷状況の受信時刻を計測してもよい。

そして、全体マスター端末の第２スケジューラ７０４＃１は、負荷量解析部７０５＃１により解析された各グループの負荷状況に基づいて、負荷量が閾値未満の携帯端末２０１を有するグループを特定する。図１０の例では、全体マスター端末の第２スケジューラ７０４＃１は、負荷量が閾値未満の携帯端末２０１を有するグループとしてグループＧ２とグループＧ３を特定する。そして、たとえば、全体マスター端末の第２スケジューラ７０４＃１は、特定したグループの中で、通信速度が最も速いグループのグループマスター端末に対象アプリの割り当て依頼通知を送信する。

グループマスター端末の検出部７０１＃２は、対象アプリの割り当て依頼通知の受信を検出する。そして、グループマスター端末の第１スケジューラ７０３＃２が、負荷量解析部７０５＃２によってスレーブ端末の負荷量が閾値未満であるか否かを解析する。グループマスター端末の第１スケジューラ７０３＃２が、負荷量解析部７０５＃２によって負荷量が閾値未満であると解析されたスレーブ端末に対象アプリを割り当てる。ここでは、グループマスター端末の第１スケジューラ７０３＃２が、携帯端末２０１−８に対象アプリの割り当て通知を送信する。これにより、対象アプリを実行可能な余力のある携帯端末２０１に対象アプリを割り当てることができ、対象アプリの性能劣化を低減させることができる。

そして、たとえば、携帯端末２０１−８の検出部７０１＃３は、対象アプリの割り当てを検出すると、携帯端末２０１−８の実行部７０６＃３が、対象アプリを実行する。そして、たとえば、携帯端末２０１−８の検出部７０１＃３は、対象アプリの終了を検出すると、グループマスター端末に対象アプリの実行結果を有する実行終了通知を送信する。そして、たとえば、グループマスター端末の検出部７０１＃２は、対象アプリの実行終了通知の受信を検出する。グループマスター端末の検出部７０１＃２は、実行が終了したアプリの依頼元携帯端末が自携帯端末２０１の属するグループの携帯端末２０１であるか否かを判断する。図１０の例では、グループマスター端末の検出部７０１＃２は、依頼元携帯端末が自携帯端末２０１の属するグループの携帯端末２０１でないと判断し、全体マスター端末に実行終了通知を送信する。

全体マスター端末の検出部７０１＃１は、実行終了通知の受信を検出すると、実行が終了したアプリの依頼元携帯端末が自携帯端末２０１の属するグループＧ１の携帯端末２０１であるか否かを判断する。図１０の例では、全体マスター端末の検出部７０１＃１は、依頼元携帯端末が自携帯端末２０１の属するグループＧ１の携帯端末２０１であると判断する。そして、たとえば、全体マスター端末の検出部７０１＃１は、依頼元携帯端末が自携帯端末２０１であるか否かを判断する。図１０の例では、全体マスター端末の検出部７０１＃１は、対象アプリの依頼元携帯端末は自携帯端末２０１であると判断し、実行終了通知に含まれる実行結果をメモリ３０７またはストレージ３０９などの記憶装置に格納する。

図１１は、図１０で示した各通知のデータ構造の一例を示す説明図である。各通知のヘッダは、送信元のアドレスと、宛先のアドレスと、を保持する。図１１の例では、各携帯端末２０１に割り当てた符号をアドレスの代わりに表記している。各通知のタグには、依頼元端末ＩＤと、依頼元のグループマスター端末ＩＤと、割り当て対象のアプリＩＤ／スレッドＩＤと、を保持する。各通知のペイロードには、メッセージ種別を保持する。

ヘッダやペイロードに変更があっても、通知を受け付けた各携帯端末２０１がタグの値を変更せずに通知を作成する。これにより、スケジューリングシステム２００のいずれの携帯端末２０１で対象アプリが実行されても、全体マスター端末やグループマスター端末を介して、依頼元携帯端末に実行結果が渡される。

たとえば、携帯端末２０１−１から携帯端末２０１−５に送信された割り当て依頼通知のメッセージ種別は、割当依頼である。たとえば、携帯端末２０１−５から携帯端末２０１−８に送信された割り当て通知のメッセージ種別は、割当である。たとえば、携帯端末２０１−８から携帯端末２０１−５に送信された実行終了通知のメッセージ種別は、終了である。たとえば、携帯端末２０１−５から携帯端末２０１−１に送信された実行終了通知のメッセージ種別は、終了である。

また、図示していないが、実行終了通知のペイロードには、たとえば、実行結果が保持されている。また、たとえば、割り当て依頼通知のペイロードや割り当て通知のペイロードには、たとえば、割り当ての対象となるアプリやスレッドの命令コードが保持されていてもよい。

実施例３によれば、同一グループ内の携帯端末２０１に余力がなければ、他のグループの余力のある携帯端末２０１に対象アプリを割り当てることで、グループ間で負荷を分散させることができ、対象アプリの性能劣化を低減させることができる。

（実施例４）
実施例４では、割り当て依頼がグループ間を跨ぐ際には、全体マスター端末とグループマスター端末を介することで、割り当て依頼の経路を明確にすることができる。これにより、１台の携帯端末２０１にすべての割り当て処理を行わせずに、グループごとにグループマスター端末に割り当てを行わせることで、１台の携帯端末２０１が割り当て処理によって過負荷状態となるのを防止することができる。

図１２は、割り当て依頼通知が他のグループから送信された場合の例を示す説明図である。図１２の例では、携帯端末２０１−１４が、（１）対象アプリの割り当て依頼通知を携帯端末２０１−１４が属するグループマスター端末に送信する。そして、グループマスター端末である携帯端末２０１−１３が、対象アプリを実行可能な余力のあるスレーブ端末がグループ内にないと判断すると、（２）全体マスター端末である携帯端末２０１−１に割り当て依頼通知を送信する。

たとえば、全体マスター端末の検出部７０１＃１は、グループマスター端末から割り当て依頼通知の受信を検出する。そして、全体マスター端末の第１スケジューラ７０３＃１は、負荷量解析部７０５＃１に各グループの負荷状況を解析させる。全体マスター端末の負荷量解析部７０５＃１による各グループの負荷状況の解析は、実施例３で示した処理と同一であるため、詳細な説明を省略する。図１２の例では、全体マスター端末の第１スケジューラ７０３＃１が、負荷量解析部７０５＃１による解析結果に基づいて、（３）割り当て依頼通知をグループのグループマスター端末である携帯端末２０１−５に送信する。

そして、グループマスター端末である携帯端末２０１−５が、割り当て依頼通知を受信すると、グループ内の各スレーブ端末の負荷量を解析する。図１２の例では、グループマスター端末である携帯端末２０１−５が、（４）割り当て通知を携帯端末２０１−８に送信する。

そして、たとえば、携帯端末２０１−８が、対象アプリの割り当て通知を受信すると、対象アプリを実行する。そして、携帯端末２０１−８が、対象アプリの実行終了を検出すると、（５）グループマスター端末である携帯端末２０１−５に対象アプリの実行終了通知を送信する。

グループマスター端末である携帯端末２０１−５が、対象アプリの実行終了通知を受信すると、実行終了通知に含まれるタグに基づいて、（６）全体マスター端末である携帯端末２０１−１に対象アプリの実行終了通知を送信する。

全体マスター端末である携帯端末２０１−１が、対象アプリの実行終了通知を受信すると、実行終了通知に含まれるタグに基づいて、（７）グループマスター端末である携帯端末２０１−１３に対象アプリの実行終了通知を送信する。

グループマスター端末である携帯端末２０１−１３が、対象アプリの実行終了通知を全体マスター端末から受信すると、実行終了通知に含まれるタグに基づいて、（８）依頼元携帯端末である携帯端末２０１−１４に対象アプリの実行終了通知を送信する。

依頼元携帯端末である携帯端末２０１−１４は、グループマスター端末からの実行終了通知の受信を検出すると、実行結果をメモリ３０７やストレージ３０９などの記憶装置に格納する。

実施例４によれば、割り当て依頼がグループ間を跨ぐ際には、全体マスター端末とグループマスター端末を介することで、割り当て依頼の経路を明確にすることができる。これにより、１台の携帯端末２０１にすべての割り当て処理を行わせずに、グループごとにグループマスター端末に割り当てを行わせることで、１台の携帯端末２０１が割り当て処理によって過負荷状態となるのを防止することができる。さらに、割り当てにかかる時間によってアプリの実行性能が低下するのを抑制することができる。さらに、１台の携帯端末２０１に対して通信をさせないことで、通信待ちによる性能劣化を低減させることができる。

（実施例５）
つぎに、本実施の形態で示すスケジューリングシステム２００のように、各装置が携帯端末２０１であると、携帯端末２０１の電池消耗により電池残量が減少したり、各携帯端末２０１の位置が移動したりすることで携帯端末２０１の通信環境が悪化する可能性がある。実施例５では、全体マスター端末の電池残量や通信強度を定期的にモニターし、電池残量か通信強度のいずれか一方であっても、閾値を下回る場合には全体マスター端末の機能を他の携帯端末２０１に移転させる。これにより、電池が切れることなく、通信環境がよい携帯端末２０１に全体マスター端末の機能を行わせることができ、スケジューリングシステム２００の全体の制御が絶たれてしまうことを防止することができる。実施例５では、タイマ割り込みが検出される都度、電池残量と通信強度をモニターすることとする。

図１３は、タイマ割り込みを検出した場合の全体マスター端末の動作例を示す説明図である。まず、全体マスター端末の検出部７０１＃１は、タイマ割り込みを検出する。そして、全体マスター端末の判断部７０８＃１は、検出部７０１＃１によりタイマ割り込みが検出された場合、自携帯端末２０１の電池残量が閾値以上であるか否かを判断する。さらに、全体マスター端末の判断部７０８＃１は、自携帯端末２０１とアクセスポイント２０２−１との通信強度が閾値以上であるか否かを判断する。

そして、全体マスター端末の第１スケジューラ７０３＃１は、判断部７０８＃１により電池残量が閾値未満であると判断された場合、携帯端末２０１の全体マスター端末の機能の移転先となる携帯端末２０１を選択する。そして、全体マスター端末の第１スケジューラ７０３＃１は、判断部７０８＃１により通信強度が閾値未満であると判断された場合、携帯端末２０１の全体マスター端末の機能の移転先となる携帯端末２０１を選択する。全体マスター端末の第１スケジューラ７０３＃１は、決定した移転先に全体マスター端末の機能を移転する。

具体的には、たとえば、全体マスター端末の判断部７０８＃１は、各携帯端末２０１の電池残量をＯＳ３２１のＡＰＩにより取得することができる。図１３の例では、各携帯端末２０１の電池残量が３段階に分けられている。ここでは、たとえば、電池残量が下の１段階目の場合には電池残量が閾値未満であると判断され、電池残量が上の２段階の場合には電池残量が閾値以上であると判断されることとする。図１３の例では、全体マスター端末の判断部７０８＃１は、携帯端末２０１の電池残量が閾値以上であると判断する。

そして、全体マスター端末の判断部７０８＃１は、自携帯端末２０１の電池残量が閾値以上であると判断した場合、自携帯端末２０１とアクセスポイント２０２との通信強度が閾値以上であるか否かを判断する。たとえば、全体マスター端末の判断部７０８＃１は、通信強度をＯＳ３２１のＡＰＩにより取得することができる。

図１３の例では、通信強度が３段階に分けられている。ここでは、たとえば、全体マスター端末の判断部７０８＃１が、通信強度が下の１段階目の場合には通信強度が閾値未満であると判断し、通信強度が上の２段階の場合には通信強度が閾値以上であると判断することとする。図１３の例では、全体マスター端末の判断部７０８＃１は、携帯端末２０１の通信強度が閾値未満であると判断する。

つぎに、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、判断部７０８＃１により自携帯端末２０１の通信強度が閾値未満であると判断された場合、自携帯端末２０１が属するグループＧ１の各スレーブ端末に電池残量の確認通知を送信する。これにより、全体マスター端末の第１スケジューラ７０３＃１は、グループＧ１の各スレーブ端末の電池残量を取得する。

そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、各スレーブ端末の電池残量が閾値以上であるか否かを判断する。図１３の例では、全体マスター端末の第１スケジューラ７０３＃１は、携帯端末２０１−３の電池残量と携帯端末２０１−４の電池残量が閾値未満であると判断し、携帯端末２０１−２の電池残量の電池残量が閾値以上であると判断する。

そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１が、携帯端末２０１とアクセスポイント２０２との通信強度の確認通知を送信する。これにより、全体マスター端末の第１スケジューラ７０３＃１は、グループＧ１の各スレーブ端末の通信強度を取得する。

そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、携帯端末２０１とアクセスポイント２０２との通信強度が閾値以上であるか否かを判断する。図１３の例では、全体マスター端末の第１スケジューラ７０３＃１は、携帯端末２０１−２，２０１−３，２０１−４とアクセスポイント２０２−１との通信強度が閾値以上でないと判断する。したがって、全体マスター端末の第１スケジューラ７０３＃１は、グループＧ１のスレーブ端末に全体マスター端末の機能を移転できないと判断する。

つぎに、たとえば、全体マスター端末の第１スケジューラ７０３＃１が、自携帯端末２０１が属するグループＧ１以外の他のグループのグループマスター端末に応答要求を送信し、最も応答の早いグループマスター端末を検出する。図１３の例では、携帯端末２０１−５が最も応答の早いグループマスター端末であるとする。そして、たとえば、全体マスター端末の第１スケジューラ７０３＃１は、検出されたグループマスター端末に全体マスター端末の機能を移転する。

図１４は、移転後のグループを示す説明図である。携帯端末２０１−１がグループＧ１の全体マスター端末の機能をＧ２のグループマスター端末に移転してしまうと、グループＧ１のグループマスター端末の機能も移転してしまうので、グループＧ１とグループＧ２は１つのグループＧ２となる。

実施例５によれば、電池が切れることなく、通信環境がよい携帯端末２０１に全体マスター端末の機能を移転させることができ、スケジューリングシステム２００の全体の制御が絶たれてしまうことを防止することができる。

また、実施例５では、電池残量や通信強度によって全体マスター端末の機能を移転させる例を示したが、グループマスター端末の機能も同様に電池残量や通信強度によって移転させてもよい。

（実施例６）
実施例６では、定期的に電池残量と通信状態をモニターし、スレーブ端末の電池残量が少ない場合や通信環境が悪い場合にはグループから離脱させる。これにより、他の携帯端末２０１からの割り当てを実行可能な環境である携帯端末２０１だけで、並列分散処理を行うことができる。

図１５は、スレーブ端末がグループから離脱する例を示す説明図である。グループＧ１のスレーブ端末である携帯端末２０１−４の検出部７０１＃３は、タイマ割り込みを検出する。そして、たとえば、携帯端末２０１−４の判断部７０７＃３は、検出部７０１＃３によりタイマ割り込みが検出された場合、自携帯端末２０１の電池残量が閾値以下であるか否かを判断する。図１５の例では、携帯端末２０１−４の判断部７０７＃３は、自携帯端末２０１の電池残量が閾値以下であると判断する。

そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、判断部７０７＃３により自携帯端末２０１の電池残量が閾値以下であると判断した場合、メモリ３０７のＧＬＯＢＡＬ領域を破棄する。そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、メモリ３０７のＳＨＡＲＥＤ領域の移行処理を行う。移行処理については、実施例１の図８−２で説明した処理と同様の処理であるため、詳細な説明を省略する。

そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、判断部７０７＃３により自携帯端末２０１の電池残量が閾値以下であると判断された場合、グループＧ１から離脱する離脱通知を携帯端末２０１−１に通知する。携帯端末２０１−１は、全体マスター端末であり、グループＧ１のグループマスター端末でもある。

たとえば、携帯端末２０１−１の検出部７０１＃１は、携帯端末２０１−４からの離脱通知の受信を検出する。そして、たとえば、携帯端末２０１−１の更新部７０９＃１は、検出部７０１＃１により離脱通知の受信が検出された場合、位置情報５０２から携帯端末２０１−４の情報を削除する。

実施例６によれば、他の携帯端末２０１からの割り当てを実行可能な環境である携帯端末２０１だけで、並列分散処理を行うことができる。

（実施例７）
スレーブ端末の位置が変化することで、スレーブ端末がいままで属していたグループの携帯端末２０１よりも他のグループの携帯端末２０１との通信状態の方がよくなる場合がある。そこで、実施例７では、スレーブ端末とグループマスター端末との通信強度を定期的にモニターし、スレーブ端末が属するグループを更新する。これにより、アドホックモードによる通信環境がよい携帯端末２０１同士でグループ化させることができ、通信環境による性能劣化を軽減させることができる。

図１６は、スレーブ端末が他のグループに移動する例を示す説明図である。グループＧ１のスレーブ端末である携帯端末２０１−４の検出部７０１＃３は、タイマ割り込みを検出する。そして、たとえば、携帯端末２０１−４の判断部７０７＃３は、検出部７０１＃３によりタイマ割り込みが検出された場合、自携帯端末２０１がいずれかのグループに属しているか否かを判断する。ここでは、たとえば、携帯端末２０１−４の判断部７０７＃３は、自携帯端末２０１がグループに属していると判断する。そして、たとえば、携帯端末２０１−４の判断部７０７＃３は、自携帯端末２０１の電池残量が閾値以上であるか否かを判断する。図１６の例では、携帯端末２０１−４の判断部７０７＃３は、自携帯端末２０１の電池残量が閾値以上であると判断する。

そして、携帯端末２０１−４のスケジューラ７０３＃３は、判断部７０７＃３により自携帯端末２０１の電池残量が閾値以上であると判断された場合、自携帯端末２０１と各グループマスター端末とのアドホックモードによる通信での通信強度を検出する。そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、通信強度が最も強いグループマスター端末を検出する。図１６の例では、携帯端末２０１−４の検出部７０１＃３は、携帯端末２０１−５を検出する。

そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末と自携帯端末２０１との通信強度が閾値以上であるか否かを判断する。ここでは、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末と自携帯端末２０１との通信強度が閾値以上であると判断することとする。そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末が属するグループと自携帯端末２０１の属するグループが同一か否かを判断する。図１６の例では、携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末が属するグループと自携帯端末２０１の属するグループが同一でないと判断する。

そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、自携帯端末２０１が属するグループマスター端末である携帯端末２０１−１にグループの離脱通知を送信する。そして、たとえば、携帯端末２０１−１の検出部７０１＃１は、離脱通知の受信を検出する。つぎに、たとえば、携帯端末２０１−１の更新部７０９＃１は、位置情報５０２から携帯端末２０１−４の情報を削除する。

そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末である携帯端末２０１−５にグループＧ２への登録通知を送信する。そして、たとえば、携帯端末２０１−５の検出部７０１＃２は、登録通知の受信を検出する。そして、たとえば、携帯端末２０１−５の更新部７０９＃２は、位置情報５０４に携帯端末２０１の情報を登録する。

実施例７によれば、スレーブ端末とグループマスター端末との通信強度を定期的にモニターし、各スレーブ端末が属するグループを変更する。これにより、アドホックモードによる通信環境がよい携帯端末２０１同士でグループ化させることができ、通信環境による性能劣化を軽減させることができる。

（実施例８）
つぎに、電池残量や通信環境によって携帯端末２０１がグループから離脱したとしても、携帯端末２０１に電池が充電されることで、電池残量が増加したり、携帯端末２０１の位置が変化することで、通信環境がよくなることがある。そこで、実施例８では、いずれのグループに属していなくとも定期的に電池残量と通信環境をモニターし、グループに属せるか否かを決定する。これにより、電池残量や通信環境のよい携帯端末２０１でスケジューリングシステム２００による並列分散処理を行うことができる。

図１７は、スレーブ端末のグループ登録例を示す説明図である。スレーブ端末である携帯端末２０１−４の検出部７０１＃３は、タイマ割り込みを検出する。そして、たとえば、携帯端末２０１−４の判断部７０７＃３は、検出部７０１＃３によりタイマ割り込みが検出された場合、自携帯端末２０１がいずれかのグループに属しているか否かを判断する。ここでは、たとえば、携帯端末２０１−４の判断部７０７＃３は、自携帯端末２０１がいずれのグループにも属していないと判断する。そして、たとえば、携帯端末２０１−４の判断部７０７＃３は、自携帯端末２０１の電池残量が閾値以上であるか否かを判断する。図１７の例では、携帯端末２０１−４の判断部７０７＃３は、自携帯端末２０１の電池残量が閾値以上であると判断する。

つぎに、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、判断部７０７＃３により自携帯端末２０１の電池残量が閾値以上であると判断された場合、自携帯端末２０１と各グループマスター端末とのアドホックモードによる通信の通信強度を検出する。具体的には、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、アドホックモードによって通信可能な携帯端末２０１のすべてと一定期間の間に通信を行うことで、グループマスター端末を探索することができ、通信強度を検出することができる。そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、通信強度が最も強いグループマスター端末を検出する。図１７の例では、携帯端末２０１−４のスケジューラ７０３＃３は、通信強度が最も強いグループマスター端末として携帯端末２０１−１を検出する。

携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末と自携帯端末２０１との通信強度が閾値以上であるか否かを判断する。ここでは、携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末と自携帯端末２０１との通信強度が閾値以上であると判断することとする。

そして、たとえば、携帯端末２０１−４のスケジューラ７０３＃３は、検出されたグループマスター端末にグループの登録通知を送信する。そして、たとえば、検出された携帯端末２０１−１の検出部７０１＃１は、登録通知の受信を検出する。そして、携帯端末２０１−１の更新部７０９＃１は、位置情報５０２に携帯端末２０１−４の情報を登録することで、携帯端末２０１−４をグループＧ１に登録する。

実施例８によれば、電池残量や通信環境のよい携帯端末２０１でスケジューリングシステム２００による並列分散処理を行うことができる。

（全体マスター端末が行う処理手順）
図１８〜２５は、全体マスター端末が行う処理手順の一例を示すフローチャートである。まず、全体マスター端末が、検出部７０１＃１により、イベントの発生を検出したか否かを判断する（ステップＳ１８０１）。そして、全体マスター端末が、検出部７０１＃１により、イベントの発生を検出していないと判断した場合（ステップＳ１８０１：Ｎｏ）、ステップＳ１８０１へ戻る。つぎに、全体マスター端末が、アプリの起動要求を検出したと判断した場合（ステップＳ１８０１：起動要求）、アプリ識別部７０２＃１により、起動要求が検出された対象アプリが強制アプリであるか否かを識別する（ステップＳ１８０２）。

そして、全体マスター端末が、対象アプリが強制アプリであるか否かを判断する（ステップＳ１８０３）。つぎに、全体マスター端末が、対象アプリが強制アプリであると判断した場合（ステップＳ１８０３：Ｙｅｓ）、負荷量解析部７０５＃１により、グループ内負荷量解析処理を実行する（ステップＳ１８０４）。そして、全体マスター端末が、第１スケジューラ７０３＃１により、受け付けた負荷量が最小のスレーブ端末を全体マスター端末の機能の移転先に決定する（ステップＳ１８０５）。つぎに、全体マスター端末が、第１スケジューラ７０３＃１により、ＧＬＯＢＡＬ領域のデータを廃棄する（ステップＳ１８０６）。そして、全体マスター端末が、第１スケジューラ７０３＃１により、データ移行処理を実行する（ステップＳ１８０７）。

そして、全体マスター端末が、第１スケジューラ７０３＃１により、移転先となるスレーブ端末に全体マスター端末への遷移を通知する（ステップＳ１８０８）。つぎに、全体マスター端末が、第１スケジューラ７０３＃１により、全体マスター端末の移転先をグループマスター端末に通知する（ステップＳ１８０９）。そして、全体マスター端末が、遷移部７０６＃１により、スレーブ端末に遷移し、実行部７０７＃１により、対象アプリの実行を開始し（ステップＳ１８１０）、ステップＳ１８０１へ戻る。

また、ステップＳ１８０３において、全体マスター端末が、対象アプリが強制アプリでないと判断した場合（ステップＳ１８０３：Ｎｏ）、第２スケジューラ７０４＃１により、リアルタイム制約があるか否かを判断する（ステップＳ１８１１）。リアルタイム制約があるとは、実行開始から実行終了までの時間があらかじめ決定されていたり、実行終了時刻が定められていたりする場合を示している。そして、全体マスター端末が、リアルタイム制約があると判断した場合（ステップＳ１８１１：Ｙｅｓ）、ステップＳ１８１４へ移行する。

つぎに、全体マスター端末が、リアルタイム制約がないと判断した場合（ステップＳ１８１１：Ｎｏ）、負荷量解析部７０５＃１により、負荷量を算出し（ステップＳ１８１２）、算出した負荷量＞閾値であるか否かを判断する（ステップＳ１８１３）。そして、全体マスター端末が、算出した負荷量＞閾値でないと判断した場合（ステップＳ１８１３：Ｎｏ）、第２スケジューラ７０４＃１により、ランキュー３３２に対象アプリを登録し（ステップＳ１８１４）、ステップＳ１８０１へ戻る。

一方、全体マスター端末が、算出した負荷量＞閾値であると判断した場合（ステップＳ１８１３：Ｙｅｓ）、負荷量解析部７０５＃１により、グループ内負荷量解析処理を実行する（ステップＳ１８１５）。つぎに、全体マスター端末が、第２スケジューラ７０４＃１により、受け付けた負荷量と対象アプリの負荷量に基づき、対象アプリを実行可能なスレーブ端末を特定し（ステップＳ１８１６）、特定したか否かを判断する（ステップＳ１８１７）。そして、全体マスター端末が、特定したと判断した場合（ステップＳ１８１７：Ｙｅｓ）、第２スケジューラ７０４＃１により、特定したスレーブ端末の中で、負荷量が最小のスレーブ端末に対象アプリの割り当て通知を送信する（ステップＳ１８１８）。そして、全体マスター端末が、ステップＳ１８０１へ戻る。

そして、全体マスター端末が、特定していないと判断した場合（ステップＳ１８１７：Ｎｏ）、負荷量解析部７０５＃１により、各グループ負荷量解析処理を実行する（ステップＳ１８１９）。つぎに、全体マスター端末が、第２スケジューラ７０４＃１により、受け付けたグループの負荷状況と対象アプリの負荷量に基づき、対象アプリを実行可能なスレーブ端末を有するグループを特定する（ステップＳ１８２０）。

そして、全体マスター端末が、特定したか否かを判断する（ステップＳ１８２１）。そして、全体マスター端末が、特定していないと判断した場合（ステップＳ１８２１：Ｎｏ）、第２スケジューラ７０４＃１により、ランキュー３３２に対象アプリを登録し（ステップＳ１８２２）、ステップＳ１８０１へ戻る。そして、全体マスター端末が、特定したと判断した場合（ステップＳ１８２１：Ｙｅｓ）、第２スケジューラ７０４＃１により、特定したグループの中で通信速度が最速のグループのグループマスター端末に対象アプリの割り当て依頼通知を送信する（ステップＳ１８２３）。そして、全体マスター端末が、ステップＳ１８０１へ戻る。

また、ステップＳ１８０１において、全体マスター端末が、検出部７０１＃１により、グループマスター端末または同一グループ内のスレーブ端末からの実行終了通知の受信を検出した場合（ステップＳ１８０１：実行終了通知）、ステップＳ２１０１へ移行する。ステップＳ２１０１は図２１に示す。

全体マスター端末が、実行が終了したアプリまたはスレッドの割り当て依頼を行った依頼元携帯端末は同一グループに属するか否かを判断する（ステップＳ２１０１）。全体マスター端末が、依頼元携帯端末は同一グループに属さないと判断した場合（ステップＳ２１０１：Ｎｏ）、対象スレッドの依頼元グループのグループマスター端末に実行終了通知を送信する（ステップＳ２１０２）。

全体マスター端末が、依頼元携帯端末は同一グループに属すると判断した場合（ステップＳ２１０１：Ｙｅｓ）、依頼元携帯端末が自携帯端末２０１か否かを判断する（ステップＳ２１０３）。全体マスター端末が、依頼元携帯端末が自携帯端末２０１であると判断した場合（ステップＳ２１０３：Ｙｅｓ）、格納部７１０＃１により、実行結果を格納し（ステップＳ２１０５）、ステップＳ２１０１へ戻る。

全体マスター端末が、依頼元携帯端末が自携帯端末２０１でないと判断した場合（ステップＳ２１０３：Ｎｏ）、依頼元携帯端末であるスレーブ端末に実行終了通知を送信し（ステップＳ２１０４）、ステップＳ２１０１へ戻る。

また、ステップＳ１８０１において、全体マスター端末が、検出部７０１＃１により、スレーブ端末からの割り当て依頼通知の受信を検出したと判断した場合（ステップＳ１８０１：スレーブ端末からの割り当て依頼通知）、ステップＳ２２０１へ移行する。ステップＳ２２０１は図２２に示す。

全体マスター端末が、負荷量解析部７０５＃１により、グループ内負荷量解析処理を実行する（ステップＳ２２０１）。そして、全体マスター端末が、第１スケジューラ７０３＃１により、受け付けたグループの負荷量と対象スレッドの負荷量に基づき、対象スレッドを実行可能なスレーブ端末を特定する（ステップＳ２２０２）。

全体マスター端末が、特定したか否かを判断する（ステップＳ２２０３）。全体マスター端末が、特定したと判断した場合（ステップＳ２２０３：Ｙｅｓ）、第１スケジューラ７０３＃１により、特定したスレーブ端末の中で負荷量が最小のスレーブ端末に対象スレッドの割り当て通知を送信する（ステップＳ２２０４）。そして、全体マスター端末が、ステップＳ１８０１へ戻る。

また、全体マスター端末が、特定していないと判断した場合（ステップＳ２２０３：Ｎｏ）、負荷量解析部７０５＃１により、各グループ負荷量解析処理を実行する（ステップＳ２２０５）。全体マスター端末が、受け付けたグループの負荷状況と対象スレッドの負荷量に基づき、対象スレッドを実行可能なスレーブ端末を有するグループを特定する（ステップＳ２２０６）。

そして、全体マスター端末が、特定したか否かを判断する（ステップＳ２２０７）。全体マスター端末が、特定したと判断した場合（ステップＳ２２０７：Ｙｅｓ）、第１スケジューラ７０３＃１により、特定したグループの中で通信速度が最速のグループのグループマスター端末に対象スレッドの割り当て依頼通知を送信する（ステップＳ２２０８）。そして、全体マスター端末が、ステップＳ１８０１へ戻る。

全体マスター端末が、特定していないと判断した場合（ステップＳ２２０７：Ｎｏ）、第１スケジューラ７０３＃１により、依頼元携帯端末に対象スレッドの割り当て通知を送信し（ステップＳ２２０９）、ステップＳ１８０１へ戻る。

また、ステップＳ１８０１において、全体マスター端末が、検出部７０１＃１により、グループマスター端末からの割り当て依頼通知の受信を検出したと判断した場合（ステップＳ１８０１：グループマスター端末からの割り当て依頼）、ステップＳ２２０５へ移行する。

また、ステップＳ１８０１において、全体マスター端末が、検出部７０１＃１により、タイマ割り込みを検出したと判断した場合（ステップＳ１８０１：タイマ割り込み）、ステップＳ２３０１へ移行する。ステップＳ２３０１は図２３に示す。

全体マスター端末が、判断部７０８＃１により、電池残量＞閾値であるか否かを判断する（ステップＳ２３０１）。全体マスター端末が、電池残量＞閾値でないと判断した場合（ステップＳ２３０１：Ｎｏ）、ステップＳ２３０３へ移行する。全体マスター端末が、電池残量＞閾値であると判断した場合（ステップＳ２３０１：Ｙｅｓ）、判断部７０８＃１により、自携帯端末２０１とアクセスポイント２０２との通信強度＞閾値であるか否かを判断する（ステップＳ２３０２）。全体マスター端末が、自携帯端末２０１とアクセスポイント２０２との通信強度＞閾値であると判断した場合（ステップＳ２３０２：Ｙｅｓ）、ステップＳ１８０１へ戻る。

そして、全体マスター端末が、自携帯端末２０１とアクセスポイント２０２との通信強度＞閾値でないと判断した場合（ステップＳ２３０２：Ｎｏ）、ステップＳ２３０３へ移行する。そして、全体マスター端末が、第１のスケジューラ７０３＃１により、自携帯端末２０１と同一グループの各スレーブ端末に各スレーブ端末とアクセスポイント２０２との通信強度と電池残量との確認通知を送信する（ステップＳ２３０３）。つぎに、全体マスター端末が、スレーブ端末から電池残量と通信強度を受け付けたか否かを判断する（ステップＳ２３０４）。

全体マスター端末が、スレーブ端末から電池残量と通信強度を受け付けたと判断した場合（ステップＳ２３０４：Ｙｅｓ）、すべてのスレーブ端末から電池残量と通信強度を受け付けたか否かを判断する（ステップＳ２３０５）。全体マスター端末が、すべてのスレーブ端末から電池残量と通信強度を受け付けたと判断した場合（ステップＳ２３０５：Ｙｅｓ）、ステップＳ２３０７へ移行する。

ステップＳ２３０４において、全体マスター端末が、スレーブ端末から電池残量と通信強度を受け付けていないと判断した場合（ステップＳ２３０４：Ｎｏ）、ステップＳ２３０６へ移行する。ステップＳ２３０５において、全体マスター端末が、すべてのスレーブ端末から電池残量と通信強度を受け付けていないと判断した場合（ステップＳ２３０５：Ｎｏ）、ステップＳ２３０６へ移行する。

つぎに、全体マスター端末が、一定時間経過したか否かを判断する（ステップＳ２３０６）。全体マスター端末が、一定時間経過していないと判断した場合（ステップＳ２３０６：Ｎｏ）、ステップＳ２３０４へ戻る。一方、全体マスター端末が、一定時間経過したと判断した場合（ステップＳ２３０６：Ｙｅｓ）、ステップＳ２３０７へ移行する。

つぎに、全体マスター端末が、第１スケジューラ７０３＃１により、受け付けた通信強度＞閾値であるスレーブ端末を特定し（ステップＳ２３０７）、特定したか否かを判断する（ステップＳ２３０８）。全体マスター端末が、特定したと判断した場合（ステップＳ２３０８：Ｙｅｓ）、第１スケジューラ７０３＃１により、特定したスレーブ端末のうち、電池残量＞閾値であるスレーブ端末を特定する（ステップＳ２３０９）。全体マスター端末が、特定したか否かを判断する（ステップＳ２３１０）。

全体マスター端末が、受け付けた通信強度＞閾値であるスレーブ端末を特定していないと判断した場合（ステップＳ２３０８：Ｎｏ）、ステップＳ２３１１へ移行する。また、全体マスター端末が、特定したスレーブ端末のうち、電池残量＞閾値であるスレーブ端末を特定していないと判断した場合（ステップＳ２３１０：Ｎｏ）、ステップＳ２３１１へ移行する。つぎに、全体マスター端末が、第１スケジューラ７０３＃１により、各グループマスター端末に応答要求を送信し（ステップＳ２３１１）、いずれかのグループマスター端末から応答を受信したか否かを判断する（ステップＳ２３１２）。

全体マスター端末が、いずれのグループマスター端末からも応答を受信していないと判断した場合（ステップＳ２３１２：Ｎｏ）、ステップＳ２３１２へ移行する。また、全体マスター端末が、グループマスター端末から応答を受信したと判断した場合（ステップＳ２３１２：Ｙｅｓ）、第１スケジューラ７０３＃１により、応答の送信元であるグループマスター端末を全体マスター端末の機能の移転先に決定する（ステップＳ２３１３）。そして、全体マスター端末が、ステップＳ２３１５へ移行する。

全体マスター端末が、特定したと判断した場合（ステップＳ２３１０：Ｙｅｓ）、第１スケジューラ７０３＃１により、特定したスレーブ端末を全体マスター端末の機能の移転先に決定し（ステップＳ２３１４）、ステップＳ２３１５へ移行する。

つぎに、全体マスター端末が、第１スケジューラ７０３＃１により、ＧＬＯＢＡＬ領域のデータを廃棄し（ステップＳ２３１５）、第１スケジューラ７０３＃１により、データ移行処理を実行する（ステップＳ２３１６）。そして、全体マスター端末が、決定したスレーブ端末に全体マスター端末への遷移を通知する（ステップＳ２３１７）。そして、全体マスター端末が、第１スケジューラ７０３＃１により、全体マスター端末の変更を各グループマスター端末に通知する（ステップＳ２３１８）。

そして、全体マスター端末が、遷移部７０６＃１により、スレーブ端末に遷移し、ランキュー３３２に登録されている他の携帯端末２０１からのアプリまたはスレッドのマイグレーションを移転後の全体マスター端末に依頼する（ステップＳ２３１９）。そして、全体マスター端末が、ステップＳ１８０１へ戻る。

また、ステップＳ１８０１において、全体マスター端末が、検出部７０１＃１により、マイグレーション依頼通知の受信を検出した場合（ステップＳ１８０１：マイグレーション依頼通知）、ステップＳ２５０１へ移行する。ステップＳ２５０１は、図２５に示す。

全体マスター端末が、第１スケジューラ７０３＃１により、マイグレーション依頼されたデータのうち、未移行のデータがあるか否かを判断する（ステップＳ２５０１）。ここで、マイグレーション依頼されるのはアプリやスレッドなどの処理であるが、移行されるのは処理に関するデータであるため、マイグレーション依頼されたデータとしている。

そして、全体マスター端末が、マイグレーション依頼されたデータのうち、未移行のデータがないと判断した場合（ステップＳ２５０１：Ｎｏ）、ステップＳ１８０１へ戻る。つぎに、全体マスター端末が、マイグレーション依頼されたデータのうち、未移行のデータがあると判断した場合（ステップＳ２５０１：Ｙｅｓ）、未移行のデータのうち、サイズが最大のデータを移行対象データに選択する（ステップＳ２５０２）。

つぎに、全体マスター端末が、第１スケジューラ７０３＃１により、移行対象データと依存関係のあるアプリまたはスレッドを実行中の同一グループ内のスレーブ端末を特定する（ステップＳ２５０３）。そして、全体マスター端末が、特定したか否かを判断する（ステップＳ２５０４）。全体マスター端末が、特定したと判断した場合（ステップＳ２５０４：Ｙｅｓ）、特定したスレーブ端末に移行可能か否かを判断する（ステップＳ２５０５）。ここでは、たとえば、特定したスレーブ端末に移行対象データを記憶可能な領域が空いていない場合には、移行できないと判断される。

全体マスター端末が、特定したスレーブ端末に移行可能であると判断した場合（ステップＳ２５０５：Ｙｅｓ）、第１スケジューラ７０３＃１により、特定したスレーブ端末に移行対象データを送信し（ステップＳ２５０６）、ステップＳ２５０１へ戻る。全体マスター端末が、特定していないと判断した場合（ステップＳ２５０４：Ｎｏ）、または特定したスレーブ端末に移行できないと判断した場合（ステップＳ２５０５：Ｎｏ）、ステップＳ２５０７へ移行する。

そして、全体マスター端末が、同一グループ内のスレーブ端末から、移行対象データを記憶可能なＳＨＡＲＥＤ領域を有するスレーブ端末を特定する（ステップＳ２５０７）。全体マスター端末が、特定したか否かを判断し（ステップＳ２５０８）、特定したと判断した場合（ステップＳ２５０８：Ｙｅｓ）、負荷量解析部７０５＃１により、グループ内負荷量解析処理を実行する（ステップＳ２５０９）。そして、全体マスター端末が、第１スケジューラ７０３＃１により、特定したスレーブ端末の中で、負荷最小のスレーブ端末に移行対象データを送信し（ステップＳ２５１０）、ステップＳ２５０１へ戻る。

また、全体マスター端末が、特定していないと判断した場合（ステップＳ２５０８：Ｎｏ）、ステップＳ２５１１へ移行する。そして、全体マスター端末が、第１スケジューラ７０３＃１により、移行対象データと依存関係のある処理とデータを移行対象としてグループマスター端末にマイグレーション依頼通知を送信し（ステップＳ２５１１）、ステップＳ２５０１へ戻る。ここで、マイグレーション依頼の送信先となるグループマスター端末は、いずれのグループマスター端末であってもよいが、たとえば、全体マスター端末が各グループの負荷状況に基づいて決定してもよい。

図２６は、図１８で示したグループ内負荷量解析処理（ステップＳ１８０４）の詳細な説明を示すフローチャートである。グループ内負荷量解析処理（ステップＳ１８１５，Ｓ２２０１）はグループ内負荷量解析処理（ステップＳ１８０４）と同一処理である。まず、全体マスター端末が、グループ内の各スレーブ端末に負荷量算出通知を送信し（ステップＳ２６０１）、スレーブ端末から負荷量を受け付けたか否かを判断する（ステップＳ２６０２）。全体マスター端末が、スレーブ端末から負荷量を受け付けたと判断した場合（ステップＳ２６０２：Ｙｅｓ）、グループ内のすべてのスレーブ端末から負荷量を受け付けたか否かを判断する（ステップＳ２６０３）。

全体マスター端末が、グループ内のすべてのスレーブ端末から負荷量を受け付けたと判断した場合（ステップＳ２６０３：Ｙｅｓ）、ステップＳ１８０５（Ｓ１８１６，Ｓ２２０４）に移行する。全体マスター端末が、スレーブ端末から負荷量を受け付けていないと判断した場合（ステップＳ２６０２：Ｎｏ）、ステップＳ２６０４へ移行する。また、全体マスター端末が、グループ内のすべてのスレーブ端末から負荷量を受け付けていないと判断した場合（ステップＳ２６０３：Ｎｏ）、ステップＳ２６０４へ移行する。

そして、全体マスター端末が、一定時間経過したか否かを判断する（ステップＳ２６０４）。全体マスター端末が、一定時間経過していないと判断した場合（ステップＳ２６０４：Ｎｏ）、ステップＳ２６０２へ戻る。一方、全体マスター端末が、一定時間経過したと判断した場合（ステップＳ２６０４：Ｙｅｓ）、ステップＳ１８０５（Ｓ１８１６，Ｓ２２０４）に移行する。

図２７は、図２０で示した各グループ負荷量解析処理（ステップＳ１８１９）の詳細な説明を示すフローチャートである。各グループ負荷量解析処理（ステップＳ２２０５）は、各グループ負荷量解析処理（ステップＳ１８１９）と同一処理である。まず、全体マスター端末が、各グループのグループマスター端末に負荷状況通知を送信し（ステップＳ２７０１）、グループマスター端末から負荷状況を受け付けたか否かを判断する（ステップＳ２７０２）。

全体マスター端末が、グループマスター端末から負荷状況を受け付けたと判断した場合（ステップＳ２７０２：Ｙｅｓ）、すべてのグループマスター端末から負荷状況を受け付けたか否かを判断する（ステップＳ２７０３）。全体マスター端末が、すべてのグループマスター端末から負荷状況を受け付けたと判断した場合（ステップＳ２７０３：Ｙｅｓ）、ステップＳ１８２０（Ｓ２２０６）へ移行する。

全体マスター端末が、グループマスター端末から負荷状況を受け付けていないと判断した場合（ステップＳ２７０２：Ｎｏ）、ステップＳ２７０４へ移行する。また、全体マスター端末が、すべてのグループマスター端末から負荷状況を受け付けていないと判断した場合（ステップＳ２７０３：Ｎｏ）、ステップＳ２７０４へ移行する。

そして、全体マスター端末が、一定時間経過したか否かを判断する（ステップＳ２７０４）。全体マスター端末が、一定時間経過していないと判断した場合（ステップＳ２７０４：Ｎｏ）、ステップＳ２７０２へ戻る。一方、全体マスター端末が、一定時間経過したと判断した場合（ステップＳ２７０４：Ｙｅｓ）、ステップＳ１８２０（Ｓ２２０６）へ移行する。

図２８は、図１８で示したデータ移行処理（ステップＳ１８０７）の詳細な説明を示すフローチャートである。データ移行処理（ステップＳ２３１６）は、データ移行処理（ステップＳ１８０７）と同一処理である。まず、全体マスター端末が、ＳＨＡＲＥＤ領域の位置情報を決定した移転先のＳＨＡＲＥＤ領域に移行する（ステップＳ２８０１）。全体マスター端末が、ＳＨＡＲＥＤ領域に未移行のデータがあるか否かを判断する（ステップＳ２８０２）。全体マスター端末が、ＳＨＡＲＥＤ領域に未移行のデータがないと判断した場合（ステップＳ２８０２：Ｎｏ）、ステップＳ１８０８（Ｓ２３１７）へ移行する。

そして、全体マスター端末が、ＳＨＡＲＥＤ領域に未移行のデータがあると判断した場合（ステップＳ２８０２：Ｙｅｓ）、未移行のデータのうち、サイズが最大のデータを移行対象データに選択する（ステップＳ２８０３）。

つぎに、全体マスター端末が、移行対象データと依存関係のあるアプリまたはスレッドを実行中の同一グループ内のスレーブ端末を特定する（ステップＳ２８０４）。そして、全体マスター端末が、特定したか否かを判断する（ステップＳ２８０５）。全体マスター端末が、特定したと判断した場合（ステップＳ２８０５：Ｙｅｓ）、特定したスレーブ端末に移行可能か否かを判断する（ステップＳ２８０６）。ここでは、たとえば、特定したスレーブ端末に移行対象データを記憶可能な領域が空いていない場合には、移行できないと判断される。

全体マスター端末が、特定したスレーブ端末に移行可能であると判断した場合（ステップＳ２８０６：Ｙｅｓ）、特定したスレーブ端末に移行対象データを送信し（ステップＳ２８０７）、ステップＳ２８０２へ戻る。全体マスター端末が、特定していないと判断した場合（ステップＳ２８０５：Ｎｏ）、または特定したスレーブ端末に移行できないと判断した場合（ステップＳ２８０６：Ｎｏ）、ステップＳ２８０８へ移行する。

そして、全体マスター端末が、同一グループ内のスレーブ端末から、移行対象データを記憶可能なＳＨＡＲＥＤ領域を有するスレーブ端末を特定する（ステップＳ２８０８）。全体マスター端末が、特定したか否かを判断し（ステップＳ２８０９）、特定したと判断した場合（ステップＳ２８０９：Ｙｅｓ）、グループ内負荷量解析処理を実行する（ステップＳ２８１０）。グループ内負荷量解析処理（ステップＳ２８１０）については、上述したグループ内負荷量解析処理（ステップＳ１８０４）と同一処理であるため、詳細な説明を省略する。そして、全体マスター端末が、特定したスレーブ端末の中で、負荷最小のスレーブ端末に移行対象データを送信し（ステップＳ２８１１）、ステップＳ２８０２へ戻る。

また、全体マスター端末が、特定していないと判断した場合（ステップＳ２８０９：Ｎｏ）、ステップＳ２８１２へ移行する。そして、全体マスター端末が、移行対象データと依存関係のある処理とデータを移行対象としてグループマスター端末にマイグレーション依頼通知を送信し（ステップＳ２８１２）、ステップＳ２８０２へ戻る。ここで、マイグレーション依頼の送信先となるグループマスター端末は、いずれのグループマスター端末であってもよいが、たとえば、全体マスター端末が各グループの負荷状況に基づいて決定してもよい。

（グループマスター端末が行う処理手順）
図２９〜３６は、グループマスター端末が行う処理手順の一例を示すフローチャートである。まず、グループマスター端末が、検出部７０１＃２により、イベントの発生を検出したか否かを判断する（ステップＳ２９０１）。グループマスター端末が、イベントの発生を検出していないと判断した場合（ステップＳ２９０１：Ｎｏ）、ステップＳ２９０１へ戻る。

まず、グループマスター端末が、対象アプリの起動要求を検出したと判断した場合（ステップＳ２９０１：起動要求）、ステップＳ２９０２へ移行する。ステップＳ２９０２〜Ｓ２９１８は、それぞれステップＳ１８０１〜Ｓ１８１８と同一処理であるため、詳細な説明を省略する。ステップＳ２９１７のＮｏの場合のつぎに、グループマスター端末が、第２スケジューラ７０４＃２により、全体マスター端末に割り当て依頼通知を送信し（ステップＳ２９１９）、ステップＳ２９０１へ戻る。

また、ステップＳ２９０１において、グループマスター端末が、検出部７０１＃２により、スレーブ端末からの実行終了通知の受信を検出した場合（ステップＳ２９０１：スレーブ端末からの実行終了通知）、ステップＳ３１０１へ移行する。ステップＳ３１０１は、図３１に示す。ステップＳ３１０１〜Ｓ３１０５は、図２１で示したステップＳ２１０１〜Ｓ２１０５と同一処理であるため、詳細な説明を省略する。

また、ステップＳ２９０１において、グループマスター端末が、検出部７０１＃２により、スレーブ端末からの割り当て依頼通知の受信を検出した場合（ステップＳ２９０１：スレーブ端末からの割り当て依頼通知）、ステップＳ３２０１へ移行する。ステップＳ３２０１は図３２に示す。

ステップＳ３２０１〜Ｓ３２０４は、図２２で示したステップＳ２２０１〜Ｓ２２０４と同一処理であるため、詳細な説明を省略する。ステップＳ３２０３のＮｏの場合のつぎに、グループマスター端末が、第１スケジューラ７０３＃２により、全体マスター端末に割り当て依頼通知を送信し（ステップＳ３２０５）、ステップＳ２９０１へ移行する。

また、ステップＳ２９０１において、グループマスター端末が、検出部７０１＃２により、全体マスター端末からの割り当て依頼通知の受信を検出した場合（ステップＳ２９０１：全体マスター端末からの割り当て依頼通知）、ステップＳ３３０１へ移行する。ステップＳ３３０１は、図３３に示す。

そして、グループマスター端末が、負荷量解析部７０５＃２により、グループ内負荷量解析処理を実行する（ステップＳ３３０１）。グループ内負荷量解析処理（ステップＳ３３０１）については、グループ内負荷量解析処理（ステップＳ１８０４）と同一処理であるため、詳細な説明を省略する。そして、グループマスター端末が、第１スケジューラ７０３＃２により、受け付けた負荷量に基づき、グループ内で負荷量が最小のスレーブ端末を特定する（ステップＳ３３０２）。グループマスター端末が、第１スケジューラ７０３＃２により、特定した負荷量が最小のスレーブ端末に対象スレッドの割り当て通知を送信し（ステップＳ３３０３）、ステップＳ２９０１へ戻る。

また、図２９で示すステップＳ２９０１において、グループマスター端末が、検出部７０１＃２により、タイマ割り込みを検出した場合（ステップＳ２９０１：タイマ割り込み）、ステップＳ３４０１（図３４に示す。）へ移行する。ステップＳ３４０１〜Ｓ３４０８，Ｓ３４１２〜Ｓ３４１７は、図２３，２４で示したステップＳ２３０１〜Ｓ２３０８，Ｓ２３１４〜Ｓ２３１９と同一処理であるため、詳細な説明を省略する。

ステップＳ３４０８のＮｏの場合、またはステップＳ３４１０のＮｏの場合のつぎに、グループマスター端末が、全体マスター端末にグループから離脱する離脱通知を送信し（ステップＳ３４１１）、ステップＳ２９０１へ戻る。

また、図２９で示すステップＳ２９０１において、グループマスター端末が、マイグレーション依頼通知を検出したと判断した場合（ステップＳ２９０１：マイグレーション依頼通知）、ステップＳ３６０１（図３６に示す。）へ移行する。ステップＳ３６０１〜Ｓ３６１０は、図２５で示したステップＳ２５０１〜Ｓ２５１０と同一処理であるため、詳細な説明を省略する。

ステップＳ３６０８のＮｏの場合のつぎに、グループマスター端末が、第１スケジューラ７０３＃２により、移行対象データと依存関係のある処理とデータを移行対象として全体マスター端末にマイグレーション依頼通知を送信する（ステップＳ３６１１）。そして、グループマスター端末が、ステップＳ３６０１へ戻る。

図３７は、図２９で示したデータ移行処理（ステップＳ２９０７）の詳細な説明を示すフローチャートである。ステップＳ３７０１〜Ｓ３７１１については、図２８で示したステップＳ２８０１〜Ｓ２８１１と同一処理であるため、詳細な説明を省略する。ステップＳ３７０９のＮｏの場合、グループマスター端末が、移行対象データと依存関係のある処理とデータを移行対象として全体マスター端末にマイグレーション依頼通知を送信し（ステップＳ３７１２）、ステップＳ３７０２へ戻る。

（スレーブ端末が行う処理手順）
図３８〜４２は、スレーブ端末が行う処理手順を示すフローチャートである。まず、スレーブ端末が、検出部７０１＃３により、イベントの発生を検出したか否かを判断する（ステップＳ３８０１）。そして、スレーブ端末が、イベントの発生を検出していないと判断した場合（ステップＳ３８０１：Ｎｏ）、ステップＳ３８０１へ戻る。つぎに、スレーブ端末が、イベントの発生を検出したと判断した場合（ステップＳ３８０１：起動要求）、ステップＳ３９０１へ移行する。ステップＳ３９０１は図３９に示す。

スレーブ端末が、アプリ識別部７０２＃３により、起動要求が検出された対象アプリが強制アプリか否かを識別し（ステップＳ３９０１）、対象アプリが強制アプリであるか否かを判断する（ステップＳ３９０２）。スレーブ端末が、対象アプリが強制アプリであると判断した場合（ステップＳ３９０２：Ｙｅｓ）、スケジューラ７０３＃３により、ＧＬＯＢＡＬ領域のデータを廃棄し（ステップＳ３９０３）、データ移行処理を実行する（ステップＳ３９０４）。データ移行処理（ステップＳ３９０４）については、図２８で示したデータ移行処理（ステップＳ１８０７）と同一であるため、詳細な説明を省略する。そして、スレーブ端末が、実行部７０６＃３により、対象アプリの実行を開始し（ステップＳ３９０５）、ステップＳ３８０１へ戻る。

一方、スレーブ端末が、対象アプリが強制アプリでないと判断した場合（ステップＳ３９０２：Ｎｏ）、リアルタイム制約があるか否かを判断する（ステップＳ３９０６）。スレーブ端末が、リアルタイム制約があると判断した場合（ステップＳ３９０６：Ｙｅｓ）、自携帯端末２０１の負荷量を算出する（ステップＳ３９０７）。そして、スレーブ端末が、算出した負荷量＞閾値であるか否かを判断する（ステップＳ３９０８）。

スレーブ端末が、算出した負荷量＞閾値であると判断した場合（ステップＳ３９０８：Ｙｅｓ）、グループマスター端末に対象アプリの割り当て依頼を通知し（ステップＳ３９０９）、ステップＳ３８０１へ戻る。スレーブ端末が、リアルタイム制約がないと判断した場合（ステップＳ３９０６：Ｎｏ）、または算出した負荷量＞閾値でないと判断した場合（ステップＳ３９０８：Ｎｏ）、ランキュー３３２に対象アプリを登録し（ステップＳ３９１０）、ステップＳ３８０１へ戻る。

また、ステップＳ３８０１において、スレーブ端末が、検出部７０１＃３により、グループマスター端末の機能への遷移命令の受信を検出したと判断した場合（ステップＳ３８０１：グループマスター端末の機能への遷移命令）、ステップＳ３８０２へ移行する。そして、スレーブ端末が、遷移部７０５＃３により、グループマスター端末に遷移し（ステップＳ３８０２）、ステップＳ３８０１へ戻る。

また、ステップＳ３８０１において、スレーブ端末が、検出部７０１＃３により、全体マスター端末の機能への遷移命令の受信を検出したと判断した場合（ステップＳ３８０１：全体マスター端末の機能への遷移命令）、ステップＳ３８０３へ移行する。そして、スレーブ端末が、遷移部７０５＃３により、全体マスター端末に遷移し（ステップＳ３８０３）、ステップＳ３８０１へ戻る。

また、ステップＳ３８０１において、スレーブ端末が、アプリまたはスレッドの実行終了を検出したと判断した場合（ステップＳ３８０１：実行終了）、ステップＳ４００１へ移行する。スレーブ端末が、グループマスター端末に割り当てられたスレッドであるか否かを判断する（ステップＳ４００１）。スレーブ端末が、グループマスター端末に割り当てられたスレッドであると判断した場合（ステップＳ４００１：Ｙｅｓ）、実行終了通知をグループマスター端末に送信し（ステップＳ４００２）、ステップＳ３８０１へ戻る。

一方、スレーブ端末が、グループマスター端末に割り当てられたスレッドでないと判断した場合（ステップＳ４００１：Ｎｏ）、格納部７０８＃３により、実行結果を格納する（ステップＳ４００３）。そして、スレーブ端末が、実行終了したスレッドが強制アプリであるか否かを判断する（ステップＳ４００４）。

そして、スレーブ端末が、実行終了したスレッドが強制アプリであると判断した場合（ステップＳ４００４：Ｙｅｓ）、ＧＬＯＢＡＬ領域を作成し（ステップＳ４００５）、ＳＨＡＲＥＤ領域を作成する（ステップＳ４００６）。つぎに、スレーブ端末が、実行終了したスレッドが強制アプリでないと判断した場合（ステップＳ４００４：Ｎｏ）、ステップＳ３８０１へ戻る。

また、ステップＳ３８０１において、スレーブ端末が、検出部７０１＃３により、スイッチを検出したと判断した場合（ステップＳ３８０１：スイッチ）、強制アプリがランキュー３３２にあるか否かを判断する（ステップＳ３８０４）。スレーブ端末が、強制アプリがランキュー３３２にあると判断した場合（ステップＳ３８０４：Ｙｅｓ）、スイッチ後のスレッドのマイグレーション依頼通知をグループマスター端末に送信し（ステップＳ３８０５）、ステップＳ３８０１へ戻る。スレーブ端末が、強制アプリがランキュー３３２にないと判断した場合（ステップＳ３８０４：Ｎｏ）、ステップＳ３８０１へ戻る。

また、ステップＳ３８０１において、スレーブ端末が、検出部７０１＃３により、タイマ割り込みを検出したと判断した場合（ステップＳ３８０１：タイマ割り込み）、ステップＳ４１０１へ移行する。ステップＳ４１０１は、図４１に示す。そして、スレーブ端末が、自携帯端末２０１がいずれかのグループに属しているか否かを判断し（ステップＳ４１０１）、いずれかのグループに属していると判断した場合（ステップＳ４１０１：Ｙｅｓ）、判断部７０７＃３により、電池残量＞閾値であるか否かを判断する（ステップＳ４１０２）。

そして、スレーブ端末が、電池残量＞閾値であると判断した場合（ステップＳ４１０２：Ｙｅｓ）、スケジューラ７０３＃３により、近傍のグループマスター端末を探索する（ステップＳ４１０３）。そして、スレーブ端末が、スケジューラ７０３＃３により、探索したグループマスター端末のうち、自携帯端末２０１との通信強度が最も強いグループマスター端末を特定する（ステップＳ４１０４）。グループマスター端末と自携帯端末２０１との通信強度とは、アドホックモードによる無線ＬＡＮ通信である。

つぎに、スレーブ端末が、スケジューラ７０３＃３により、特定したグループマスター端末と自携帯端末２０１との通信強度＞閾値であるか否かを判断する（ステップＳ４１０５）。スレーブ端末が、スケジューラ７０３＃３により、特定したグループマスター端末と自携帯端末２０１との通信強度＞閾値であると判断した場合（ステップＳ４１０５：Ｙｅｓ）、特定したグループマスター端末が、自携帯端末２０１が属するグループマスター端末であるか否かを判断する（ステップＳ４１０６）。

スレーブ端末が、特定したグループマスター端末が、自携帯端末２０１が属するグループマスター端末であると判断した場合（ステップＳ４１０６：Ｙｅｓ）、ステップＳ３８０１へ戻る。また、スレーブ端末が、特定したグループマスター端末が、自携帯端末２０１が属するグループマスター端末でないと判断した場合（ステップＳ４１０６：Ｎｏ）、データ移行処理を実行する（ステップＳ４１０７）。データ移行処理（ステップＳ４１０７）については、図２８で示したデータ移行処理（ステップＳ１８０７）と同一であるため、詳細な説明を省略する。

そして、スレーブ端末が、自携帯端末２０１が属するグループのグループマスター端末にグループから離脱する離脱通知を送信する（ステップＳ４１０８）。そして、スレーブ端末が、スケジューラ７０３＃３により、特定したグループマスター端末のグループに移動し（ステップＳ４１０９）、ステップＳ３８０１へ戻る。

そして、ステップＳ４１０２において、スレーブ端末が、電池残量＞閾値でないと判断した場合（ステップＳ４１０２：Ｎｏ）、ステップＳ４１１０へ移行する。また、ステップＳ４１０５において、スレーブ端末が、特定したグループマスター端末と自携帯端末２０１との通信強度＞閾値でないと判断した場合（ステップＳ４１０５：Ｎｏ）、ステップＳ４１１０へ移行する。

そして、スレーブ端末が、スケジューラ７０３＃３により、ＧＬＯＢＡＬ領域のデータを廃棄し（ステップＳ４１１０）、データ移行処理を実行する（ステップＳ４１１１）。データ移行処理（ステップＳ４１１１）については、図２８で示したデータ移行処理（ステップＳ１８０７）と同一であるため、詳細な説明を省略する。そして、スレーブ端末が、スケジューラ７０３＃３により、グループマスター端末により割り当てられたスレッドのマイグレーション依頼通知をグループマスター端末へ送信する（ステップＳ４１１２）。そして、スレーブ端末が、グループマスター端末にグループから離脱する離脱通知を送信し（ステップＳ４１１３）、ステップＳ３８０１へ戻る。

つぎに、ステップＳ４１０１において、スレーブ端末が、いずれのグループにも属していないと判断した場合（ステップＳ４１０１：Ｎｏ）、判断部７０７＃３により、電池残量＞閾値であるか否かを判断する（ステップＳ４１１４）。そして、スレーブ端末が、電池残量＞閾値でないと判断した場合（ステップＳ４１１４：Ｎｏ）、ステップＳ３８０１へ戻る。

一方、スレーブ端末が、電池残量＞閾値であると判断した場合（ステップＳ４１１４：Ｙｅｓ）、スケジューラ７０３＃３により、近傍のグループマスター端末を探索する（ステップＳ４１１５）。そして、スレーブ端末が、探索したグループマスター端末のうち、自携帯端末２０１との通信強度が最も強いグループマスター端末を特定し（ステップＳ４１１６）、特定したグループマスター端末と自携帯端末２０１との通信強度＞閾値であるか否かを判断する（ステップＳ４１１７）。

そして、スレーブ端末が、特定したグループマスター端末と自携帯端末２０１との通信強度＞閾値でないと判断した場合（ステップＳ４１１７：Ｎｏ）、ステップＳ３８０１へ戻る。スレーブ端末が、特定したグループマスター端末と自携帯端末２０１との通信強度＞閾値であると判断した場合（ステップＳ４１１７：Ｙｅｓ）、スケジューラ７０３＃３により、ＧＬＯＢＡＬ領域を作成する（ステップＳ４１１８）。そして、スレーブ端末が、スケジューラ７０３＃３により、ＳＨＡＲＥＤ領域を作成し（ステップＳ４１１９）、特定したグループマスター端末のグループに移動し（ステップＳ４１２０）、ステップＳ３８０１へ戻る。

また、スケジューリングシステム２００では、装置をすべて携帯端末２０１で表したが、これに限らず、たとえば、装置がノート型パソコン、デスクトップ型パソコン、サーバであってもよい。また、スケジューリングシステム２００では、複数種類の装置が混在していてもよい。

以上説明したように、スケジューリング方法、およびスケジューリングシステムによれば、マスターの機能を担う第１装置に緊急性の高いアプリが起動された際には、マスターの機能を第１装置と同一グループまたは他のグループの第２装置に移転させる。これにより、スケジューリング方法、およびスケジューリングシステムによれば、第１装置に緊急性の高いアプリの実行に専念させることができ、マスター機能の負荷による緊急性の高いアプリの性能劣化の低減を図ることができる。

また、第１装置から第２装置にマスター機能を移転させる際には、第１装置は、各グループのグループマスターである装置にマスター機能の移転先を通知する。これにより、スケジューリングシステムでは、各グループがいずれの装置がマスター機能に関する処理を行っているかを管理することができる。

また、メモリの領域が、複数のグループの装置で共有されるデータを記憶する第１領域と、自装置が属するグループでデータが共有される第２領域と、自装置のみが使用する第３領域と、に分割される。スケジューリングシステムでは、複数のグループで共有するデータを第１領域に記憶させることで、キャッシュのスヌープ処理のように管理を容易化させることができる。

さらに、スケジューリングシステムでは、同一グループ内で第２領域を分散共有メモリのように扱う。同一グループ内の装置の方が、他のグループの装置よりもアプリやスレッドを並列処理させる可能性が高い。さらに、並列処理されるアプリやスレッドであれば、同一のデータを用いる可能性がある。そこで、スケジューリングシステムでは、第２領域を同一グループ内の装置で共有することで、同一グループ内でメモリの使用量を減少させることができる。

また、各装置は、緊急性の高いアプリの実行時には、第１領域に格納されているデータを削除し、第２領域に格納されているデータを他の携帯端末に退避する。これにより、スケジューリングシステムでは、緊急性の高いアプリが使用するメモリの領域を広げることができ、緊急性の高いアプリの性能劣化の低減を図ることができる。

また、起動対象のアプリが緊急性の高くないアプリである場合、第１装置の負荷量が閾値より大きいとき、第１装置と同一のグループまたは異なるグループの第２装置に起動対象のアプリを割り当てる。これにより、スケジューリングシステムでは、第１装置で実行中の異なる処理の負荷による起動対象のアプリの性能劣化の低減を図ることができる。

また、第１装置が、複数のグループから負荷量が所定値以下であるデータ処理装置を有するグループを選択し、選択されたグループの中で最大の通信速度を有するグループにマスター機能の移転通知を送信する。これにより、スケジューリングシステムでは、余力のあるグループにマスター機能を移転させることができ、スケジューリングシステム内で負荷量を分散させることができる。これにより、スケジューリングシステムでは、各アプリやスレッドが他のアプリや他のスレッドの負荷によって性能劣化するのを低減することができる。

また、第１装置が、複数のグループから負荷量が所定値以下であるデータ処理装置を有するグループを選択し、選択されたグループの中で最大の通信速度を有するグループに割り当て依頼通知を送信する。これにより、スケジューリングシステムでは、１グループに負荷が偏らないようにスケジューリングシステム内で負荷量を分散させることができる。これにより、各アプリやスレッドが他のアプリや他のスレッドの負荷によって性能劣化するのを低減することができる。

また、グループマスターである装置が割り当て依頼通知を受けたときに、まずは同一グループ内で余力のある装置を探索するが、いずれの装置にも余力が無い場合には、全体マスターである装置に割り当て依頼通知を送信する。これにより、スケジューリングシステムでは、スケジューリングシステム内で負荷量を分散させることができる。これにより、各アプリやスレッドが他のアプリや他のスレッドの負荷によって性能劣化するのを低減することができる。

また、装置が携帯端末であれば、電池の消耗によって電池残量が減少してしまったり、携帯端末の位置が移動することで、通信環境が悪化したりする可能性がある。そこで、スケジューリングシステムでは、各装置で定期的に電池残量と通信環境をモニターし、電池残量か通信強度のいずれか一方であっても、閾値を下回る場合にはグループを離脱する。これにより、スケジューリングシステムでは、電池が切れることなく、通信環境がよい装置で並列分散処理を行うことができる。

また、スケジューリングシステムでは、マスター機能に関する処理を実行する装置の電池残量が閾値以下である、または通信環境が悪化している場合には、電池残量または基地局との通信強度の大きさに基づいてマスター機能の移転先を決定する。これにより、スケジューリングシステムでは、電池が切れることなく、通信環境がよい装置に全体マスター端末の機能を行わせることができ、スケジューリングシステムの全体の制御が絶たれてしまうことを防止することができる。

また、スケジューリングシステムでは、アプリやスレッドを移行させる場合、該アプリやスレッドに関するデータを記憶可能な領域を有している装置を該アプリやスレッドの移行先にする。これにより、アプリやスレッドがメモリの領域不足によって性能劣化するのを軽減させることができる。

また、スケジューリングシステムでは、データを移行させる場合、該データと依存関係のある処理を実行する装置をデータの移行先にする。これにより、該依存関係のある処理がデータの読み出し・書き込みにかかる時間を減少させることができ、データを最適な装置のメモリに記憶させることができる。

なお、本実施の形態で説明したスケジューリング方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本スケジューリングプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本スケジューリングプログラムは、インターネット等のネットワークを介して配布してもよい。

Ｇ１〜Ｇ４ グループ
２００ スケジューリングシステム
２０１−１〜２０１−１６ 携帯端末
２０２ アクセスポイント
３３２ ランキュー
７０２＃１，７０２＃２ アプリ識別部
７０３＃１，７０３＃２ 第１スケジューラ
７０４＃１，７０４＃２ 第２スケジューラ
７０５＃１，７０５＃２ 負荷量解析部

Claims (12)

1. 少なくとも一のデータ処理装置を含む第１グループに含まれる第１データ処理装置であって、それぞれが少なくとも一のデータ処理装置を含む複数のグループのうちの第２グループおよび前記第１グループのデータ処理装置間で共有されるデータを格納する第１領域と前記第１グループのデータ処理装置間で共有されるデータを格納する第２領域とを含むメモリを含む第１データ処理装置が、
   起動対象のアプリケーションの優先度が所定の優先度であるか否かを判定し、
   前記アプリケーションの優先度が前記所定の優先度であるときは、前記第１データ処理装置の前記メモリに含まれる前記第１領域に格納されるデータを削除するとともに、前記第１データ処理装置内の前記第２領域に格納されるデータを退避させ、前記第２グループまたは前記第１グループに含まれる第２データ処理装置であって、前記第１グループおよび前記第２グループのデータ処理装置間で共有されるデータを格納する第１領域と、前記第２データ処理装置を含む前記第１グループまたは前記第２グループのデータ処理装置間で共有されるデータを格納する第２領域とを含むメモリを含む前記第２データ処理装置に、前記第１データ処理装置が有する機能でありいずれのデータ処理装置に各処理を割り当てるかを決定する所定の機能を移転して前記アプリケーションを実行し、
   前記アプリケーションの優先度が前記所定の優先度ではないときは、前記第１データ処理装置の実行キューに前記アプリケーションを配置すること
   を特徴とするスケジューリング方法。
2. 前記第１データ処理装置が、
   前記アプリケーションの優先度が前記所定の優先度ではないときは、前記第１データ処理装置の負荷量が閾値より大きいとき、前記第１グループまたは前記複数のグループに含まれる第３データ処理装置に前記アプリケーションを割り当てること
   を特徴とする請求項１に記載のスケジューリング方法。
3. 前記第１データ処理装置が、
   前記第１データ処理装置から前記第２データ処理装置への前記所定の機能の移転を、前記複数のグループのそれぞれの所定のデータ処理装置に通知すること
   を特徴とする請求項１または請求項２に記載のスケジューリング方法。
4. 前記第１データ処理装置が、
   前記複数のグループから負荷量が所定値以下であるデータ処理装置を有するグループを選択し、前記選択されたグループの中で最大の通信速度を有するグループを前記第２グループとして選択すること
   を特徴とする請求項１乃至請求項３の何れか一に記載のスケジューリング方法。
5. 前記第１データ処理装置が、
   前記第１データ処理装置が前記所定の機能を有する場合に、前記複数のグループの一のグループに含まれるデータ処理装置のうち前記一のグループ内において各処理をいずれのデータ処理装置に割り当てるかを決定する機能を有するデータ処理装置からの処理を前記複数のグループのいずれかに割り当てるためのスケジューリングの要求に基づいて、前記複数のグループから負荷量が所定値以下であるデータ処理装置を有するグループを選択し、前記選択されたグループの中で最大の通信速度を有するグループに含まれるデータ処理装置のうち当該グループにおいて各処理をいずれのデータ処理装置に割り当てるかを決定する機能を有するデータ処理装置に、当該グループ内のデータ処理装置に前記処理を割り当てる前記スケジューリングを要求すること
   を特徴とする請求項１乃至請求項４の何れか一に記載のスケジューリング方法。
6. 前記第１データ処理装置が、
   前記第１データ処理装置の前記所定の機能を移転する場合に、前記第１データ処理装置の電池残量または基地局との通信強度と閾値との比較結果に基づいて、前記第１データ処理装置の前記所定の機能を前記第１グループまたは前記複数のグループの何れかのグループに含まれる第４データ処理装置に移転すること
   を特徴とする請求項１乃至請求項５の何れか一に記載のスケジューリング方法。
7. 前記複数のグループの各々において前記グループに含まれるデータ処理装置が並列処理を行っており、
   前記第１データ処理装置が、
   前記第１データ処理装置の電池残量または基地局との通信強度と閾値との比較結果に基づいて、前記第１データ処理装置を前記第１グループから離脱させること
   を特徴とする請求項１または請求項２に記載のスケジューリング方法。
8. 前記第１データ処理装置が、
   前記第１データ処理装置が前記所定の機能を有する場合に、前記第１グループの一データ処理装置からの要求であり、処理を前記第１グループ内のいずれのデータ処理装置に割り当てるかのスケジューリングの要求に基づいて前記第１グループ内のデータ処理装置の負荷量を解析し、
   前記負荷量が閾値よりも大きいときは、前記複数のグループの一のグループに含まれるデータ処理装置のうち前記一のグループ内において各処理をいずれのデータ処理装置に割り当てるかを決定する機能を有するデータ処理装置に、前記一のグループ内のいずれかのデータ処理装置に前記処理を割り当てる前記スケジューリングを要求すること
   を特徴とする請求項１乃至請求項３および請求項７の何れか一に記載のスケジューリング方法。
9. 前記第２グループに含まれる所定のデータ処理端末が、
   前記第１データ処理装置が前記第１データ処理装置の前記第２領域に記憶された前記データを退避させる際に前記第１データ処理装置からの前記第１データ処理装置の前記第２領域に記憶された前記データの移転の要求に基づいて、前記第１グループの他のデータ処理装置の電池残量、基地局との通信強度、または前記第１グループのデータ処理装置間で共有される前記第２領域の大きさに基づいて、前記第１データ処理装置の前記第２領域に記憶された前記データを移転するデータ処理装置を選択すること
   を特徴とする請求項１乃至請求項３および請求項７の何れか一に記載のスケジューリング方法。
10. 前記第１データ処理装置が、
    前記第１データ処理装置の前記第２領域に記憶された前記データと前記第１グループのデータ処理装置が実行する処理に関連するデータとの依存関係に基づいて、前記第１データ処理装置の前記第２領域に記憶された前記データまたは前記関連するデータのいずれかの転送を前記複数のグループの一のグループのデータ処理装置に依頼すること
    を特徴とする請求項９に記載のスケジューリング方法。
11. 第１グループに含まれ、前記第１グループおよび第２グループのデータ処理装置間で共有されるデータを格納する第１領域と前記第１グループのデータ処理装置間で共有されるデータを格納する第２領域とを含むメモリを含む第１データ処理装置と、
    前記第２グループに含まれ、前記第１グループおよび前記第２グループのデータ処理装置間で共有されるデータを格納する第１領域と前記第２グループのデータ処理装置間で共有されるデータを格納する第２領域とを含むメモリを含む第２データ処理装置と、
    を含み、
    前記第１データ処理装置は、
    起動対象のアプリケーションの優先度が所定の優先度であるか否かを判定するアプリケーション識別ユニットと、
    前記アプリケーションの優先度が前記所定の優先度である場合に、前記第１データ処理装置の前記第１領域に格納される前記データを削除するとともに、前記第１データ処理装置の前記第２領域に格納される前記データを退避し、前記第１データ処理装置が有する機能でありいずれのデータ処理装置に各処理を割り当てるかを決定する所定の機能を移転するデータ処理装置を選択する第１スケジューラと、
    前記アプリケーションの優先度が前記所定の優先度でない場合に、実行キューに前記アプリケーションを配置する第２スケジューラと、を含むこと
    を特徴とするスケジューリングシステム。
12. 前記第１データ処理装置は、
    前記アプリケーションの優先度が前記所定の優先度である場合に、前記第１グループおよび前記第２グループに含まれるデータ処理装置の負荷量を解析する負荷量解析ユニットを含み、
    前記第１スケジューラは、
    前記負荷量解析ユニットによって解析された負荷量が最も小さいデータ処理装置を、前記所定の機能を移転するデータ処理装置として選択すること、
    を特徴とする請求項１１に記載のスケジューリングシステム。
    

Images