JPWO2013005322A1 - 制御端末、および制御方法 - Google Patents

Abstract

マスタ携帯端末（１１０）が、複数の携帯端末で並列処理可能な対象アプリの実行要求をスレーブ携帯端末（１１１−１〜１１１−３）に送信する。マスタ携帯端末（１１０）が、スレーブ携帯端末（１１１−１〜１１１−３）から実行要求に対する応答を受信する。ここで、共有データの送信時刻から最も応答の遅い受信時刻までの時間を通信状況によるオーバヘッド（τ＿ＭＡＸ）として扱う。マスタ携帯端末（１１０）が、対象アプリを４台で並列処理した場合の第２の処理時間にオーバヘッド（τ＿ＭＡＸ）を加算した合計値が、マスタ携帯端末（１１０）で逐次処理した場合の第１の処理時間未満であるか否かを判断する。マスタ携帯端末（１１０）が、該合計値が第１の処理時間未満であれば、対象アプリを複数の携帯端末で並列処理し、該合計値が第１の処理時間以上であれば、対象アプリをマスタ携帯端末（１１０）で逐次処理する。

Description

本発明は、アプリケーションの実行を制御する制御端末、および制御方法に関する。

従来、複数のコンピュータがネットワークを介してアプリケーション（以下、「アプリ」と称する。）を並列・分散処理する技術が知られている。さらに、近年では、複数の携帯端末が無線ネットワークを介して並列処理を行う技術が知られている。

関連する先行技術としては、たとえば、ループ演算を並列化させる際に、ループ演算間にデータの依存関係があれば、コンピュータ間の通信回数を減少させるようにシステムを構築する技術が知られている。また、たとえば、並列処理を管理するコンピュータが、他のコンピュータのリソース利用状況に基づいて処理を割り当てる技術が知られている。

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

しかしながら、無線ネットワークを介する携帯端末の場合、たとえば、携帯端末の所持者が移動してしまうと、通信状態が変化してしまう。複数の携帯端末で並列処理を行う場合に、アプリの処理時間とアプリに関するデータ転送時間との大小関係が変化してしまい、アプリによっては、複数の携帯端末で並列処理を行うことにより、性能が劣化してしまう問題点がある。

本発明は、上述した従来技術による問題点を解消するため、逐次処理でのアプリの性能を保証することができる制御端末、および制御方法を提供することを目的とする。

本発明の一側面によれば、対象アプリケーションを逐次処理した場合の第１の処理時間と、前記対象アプリケーションを並列処理した場合の第２の処理時間と、を記憶する記憶装置にアクセス可能であり、前記対象アプリケーションの起動指示を受け付けると、前記対象アプリケーションの実行要求を要求先端末に送信し、送信された前記実行要求に対する応答を前記要求先端末から受信し、受信された前記応答の受信時刻と前記実行要求の送信時刻との差分値と、前記記憶装置に記憶された前記第２の処理時間と、の合計値が、前記記憶装置に記憶された前記第１の処理時間以上であるか否かを判断し、前記合計値が前記第１の処理時間以上であると判断された場合、前記制御端末で逐次処理し、前記合計値が前記第１の処理時間以上でないと判断された場合、前記制御端末と前記要求先端末で並列処理する、制御端末、および制御方法が提案される。

本発明の一側面によれば、逐次処理でのアプリの性能を保証することができるという効果を奏する。

図１は、通信システム例を示す説明図である。 図２は、並列処理における性能指標の一例を示す説明図である。 図３は、携帯端末のハードウェア例を示すブロック図である。 図４は、固有データテーブルの一例を示す説明図である。 図５は、共有データテーブルの一例を示す説明図である。 図６は、アプリテーブルの一例を示す説明図である。 図７は、通信システム１００の機能ブロック例を示す説明図である。 図８は、一実施例を示す説明図である。 図９は、マスタ携帯端末１１０が行う処理手順の一例を示すフローチャート（その１）である。 図１０は、マスタ携帯端末１１０が行う処理手順の一例を示すフローチャート（その２）である。 図１１は、スレーブ携帯端末１１１が行う処理手順の一例を示すフローチャートである。

以下に添付図面を参照して、本発明にかかる制御端末、および制御方法の実施の形態を詳細に説明する。

（通信システム例）
図１は、通信システム例を示す説明図である。通信システム１００は、マスタ携帯端末１１０と、スレーブ携帯端末１１１−１〜１１１−３と、基地局１２０と、を有している。ここでは、マスタ携帯端末１１０がいずれのスレーブ携帯端末１１１と並列処理を行うかについては予め決定されていることとし、マスタ携帯端末１１０とスレーブ携帯端末１１１−１〜１１１−３は相互に宛先アドレスを知っていることとする。スレーブ携帯端末１１１については、１台以上であればよく、図１では、３台となっている。マスタ携帯端末１１０が制御端末であり、スレーブ携帯端末１１１−１〜１１１−３が要求先端末である。図１では、基地局１２０を介して携帯端末間が通信を行っているが、アドホック通信のように基地局１２０を介さずに直接携帯端末間で通信を行ってもよい。

ＰＣやサーバの場合、配置が固定されているが、携帯端末の場合、携帯端末の所持者が移動する場合がある。これにより、各携帯端末と基地局１２０との通信の信号強度が変化する場合がある。すなわち、マスタ携帯端末１１０とスレーブ携帯端末１１１−１〜１１１−３とのデータの通信状態が時々刻々と変化する。

マスタ携帯端末１１０が、複数の携帯端末で並列処理可能な対象アプリの起動指示を受け付けると、実行要求をスレーブ携帯端末１１１−１〜１１１−３に送信する。ここで、複数の携帯端末で並列処理可能な対象アプリとは、たとえば、ストリーミングに関するアプリが挙げられる。

スレーブ携帯端末１１１−１〜１１１−３が、それぞれ実行要求を受信すると、それぞれマスタ携帯端末１１０へ応答を送信する。図１の例では、スレーブ携帯端末１１１−３の通信状況が悪いため、マスタ携帯端末１１０への応答の送信が遅くなっている。本発明の一実施例では、共有データの送信時刻から、最も応答の遅い受信時刻までの時間を通信状態によるオーバヘッドτとして扱う。

マスタ携帯端末１１０が、対象アプリを複数の携帯端末で並列処理した場合の第２の処理時間にオーバヘッドτを加算した合計値が、マスタ携帯端末１１０で逐次処理した場合の第１の処理時間未満であるか否かを判断する。ここで、複数の携帯端末とは、マスタ携帯端末１１０とスレーブ携帯端末１１１−１〜１１１−３である。マスタ携帯端末１１０が、該合計値が第１の処理時間未満であれば、対象アプリを複数の携帯端末で並列処理し、該合計値が第１の処理時間以上であれば、対象アプリをマスタ携帯端末１１０で逐次処理する。

図２は、並列処理における性能指標の一例を示す説明図である。グラフ２００では、並列処理における性能指標であるアムダールの法則に対して、いくつかのオーバヘッドを加えた例がプロットされている。グラフ２００の横方向はＮ（ノード数）であり、グラフ２００の縦方向は性能である。ここで、グラフ２００のＮ（ノード数）は携帯端末数であり、すべての携帯端末のＣＰＵなどのハードウェアが同一であるとした場合である。グラフ２００の性能については、Ｎ＝１の場合を１とした場合の例である。

性能指標を示す式（１）を下記に示す。
Ｔ（Ｎ）＝（１−（１−Ｆ）／Ｎ）×Ｔ（１）＋τ・・・（１）

Ｆは並列化できない逐次処理部分の処理時間の割合である。並列化可能な部分の処理時間の割合は（１−Ｆ）である。τがオーバヘッドである。Ｔ（１）は、１台の携帯端末のみでアプリケーションを実行した場合の処理時間である。▲で示す折れ線２０１では、Ｆが５０［％］である。×で示す折れ線２０２では、Ｆが３０［％］である。折れ線２０１と折れ線２０２は理想値を示すために、オーバヘッドτが０である。◆で示す折れ線２０３では、Ｆが５０［％］であり、■で示す折れ線２０４では、Ｆが３０［％］である。折れ線２０３と折れ線２０４はτが含まれている。

折れ線２０３では、Ｎ＝２の場合に性能が１未満となっているが、Ｎ＝３〜８の場合に性能が１以上となっている。折れ線２０４では、Ｎ＝２〜８の場合に性能が１未満となっている。すなわち、アプリを並列処理するならば、逐次処理する方が性能がよい場合がある。

（携帯端末のハードウェア例）
図３は、携帯端末（マスタ携帯端末１１０、スレーブ携帯端末１１１−１〜１１１−３）のハードウェア例を示すブロック図である。携帯端末３００は、ＣＰＵ３０１と、ディスプレイ３０２と、キーボード３０３と、Ｉ／Ｆ（ＩｎｔｅｒＦａｃｅ）３０４と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０６と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０７と、を有している。携帯端末３００は、フラッシュＲＯＭ３０８と、フラッシュＲＯＭコントローラ３０９と、フラッシュＲＯＭ３１０と、を有している。ＣＰＵ３０１と、ディスプレイ３０２と、キーボード３０３と、Ｉ／Ｆ３０４と、ＲＡＭ３０６と、ＲＯＭ３０７と、フラッシュＲＯＭ３０８と、フラッシュＲＯＭコントローラ３０９とは、バス３１１を介して接続されている。

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

ディスプレイ３０２は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ３０２は、たとえば、ＴＦＴ液晶ディスプレイなどを採用することができる。キーボード３０３は、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボード３０３は、タッチパネル式の入力パッドやテンキーなどであってもよい。

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

ＲＯＭ３０７は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０６は、各ＣＰＵ３０１のワークエリアとして使用される。フラッシュＲＯＭ３０８は、ＯＳ３２１などのシステムソフトウェアやアプリケーションのプログラムを記憶している。ＲＡＭ３０６はフラッシュＲＯＭ３０８よりも各ＣＰＵ３０１からのアクセス速度が速い。ＯＳ３２１がアプリケーションのプログラムをフラッシュＲＯＭ３０８からＲＡＭ３０６へロードすることにより、該アプリケーションのコンテキスト情報がＲＡＭ３０６内に展開される。

フラッシュＲＯＭコントローラ３０９は、各ＣＰＵ３０１の制御に従ってフラッシュＲＯＭ３１０に対するデータのリード／ライトを制御する。フラッシュＲＯＭ３１０は、フラッシュＲＯＭコントローラ３０９の制御で書き込まれたデータを記憶する。データの具体例としては、端末を使用するユーザがＩ／Ｆ３０４を通して取得した画像データ、映像データなどである。フラッシュＲＯＭ３１０は、たとえば、メモリカード、ＳＤカードなどを採用することができる。

（固有データテーブル）
図４は、固有データテーブルの一例を示す説明図である。固有データテーブル４００は、アプリＩＤ、スレッドＩＤ、固有データＩＤ、合計サイズのフィールドを有している。各フィールドに情報を設定することで、固有情報（たとえば、４０１−１，４０１−２）がレコードとして記憶されている。

ここで、アプリＩＤのフィールドには、アプリの識別情報が登録される。スレッドＩＤのフィールドには、アプリが有するスレッドの識別情報が登録される。固有データＩＤのフィールドには、スレッドが固有で有する固有データの識別情報が登録される。合計サイズのフィールドには、スレッドが有する固有データの合計サイズが登録される。

（共有データテーブル）
図５は、共有データテーブルの一例を示す説明図である。共有データテーブル５００は、アプリＩＤ、共有データＩＤ、サイズのフィールドを有している。各フィールドに情報を設定することで、共有情報（たとえば、５０１−１，５０１−２）がレコードとして記憶されている。

ここで、アプリＩＤのフィールドには、アプリの識別情報が登録される。共有データのフィールドには、アプリのすべてのスレッドで共有する共有データの識別情報が登録される。サイズのフィールドには、共有データのサイズが登録される。

（アプリテーブル）
図６は、アプリテーブルの一例を示す説明図である。アプリテーブル６００は、アプリＩＤ、Ｔ（１）、ディスパッチ回数、並列度、割合のフィールドを有している。各フィールドに情報を設定することで、アプリ情報（たとえば、６０１−１，６０１−２）がレコードとして記憶されている。

アプリＩＤのフィールドには、アプリの識別情報が登録される。Ｔ（１）のフィールドには、アプリを１台の携帯端末で逐次処理した場合の処理時間が登録される。具体的には、たとえば、Ｔ（１）はアプリの設計時にシミュレーションにより算出される。ディスパッチ回数のフィールドには、アプリが有するスレッドで発生する割り当て回数が登録される。たとえば、並列処理可能なループ処理がある場合、少なくともループ回数分はディスパッチが発生することとなる。割合のフィールドには、並列度のフィールドに登録された携帯端末数でアプリが並列処理可能な割合が登録されている。

（通信システム１００の機能ブロック例）
図７は、通信システム１００の機能ブロック例を示す説明図である。マスタ携帯端末１１０は、受付部７０１と、送信部７０２と、受信部７０３と、算出部７０４と、判断部７０５と、制御部７０６と、を有している。受付部７０１〜制御部７０６は、具体的には、たとえば、制御プログラムにコーディングされており、該制御プログラムは図３に示したＲＯＭ３０７、フラッシュＲＯＭ３０８、フラッシュＲＯＭ３１０などの記憶装置に記憶されている。ＣＰＵ３０１が記憶装置から制御プログラムを読み出し、制御プログラムにコーディングされている処理を実行する。これにより、受付部７０１〜制御部７０６の処理が実行される。制御プログラムは、たとえば、図３に示したＯＳ３２１である。

スレーブ携帯端末１１１−ｎ（ｎ＝１〜３）は、受信部７１１−ｎと、判断部７１２−ｎと、送信部７１３−ｎと、を有している。受信部７１１−ｎ〜送信部７１３−ｎは、具体的には、たとえば、制御プログラムにコーディングされており、該制御プログラムは図３に示したＲＯＭ３０７、フラッシュＲＯＭ３０８、フラッシュＲＯＭ３１０などの記憶装置に記憶されている。ＣＰＵ３０１が記憶装置から制御プログラムを読み出し、制御プログラムにコーディングされている処理を実行する。これにより、受信部７１１−ｎ〜送信部７１３−ｎの処理が実行される。制御プログラムは、たとえば、図３に示したＯＳ３２１である。

受付部７０１は、対象アプリの起動指示を受け付ける。具体的には、たとえば、受付部７０１が、ウエイトキュー３３１に対象アプリが積まれるのを監視し、積まれた対象アプリを起動指示のあるアプリとして受け付ける。

送信部７０２は、受付部７０１により受け付けられた対象アプリが複数の携帯端末で並列処理を行うアプリである場合、対象アプリが有する共有データのうち、最小サイズの共有データをスレーブ携帯端末１１１−ｎに送信する。具体的には、たとえば、送信部７０２が、共有データテーブル５００から、対象アプリの識別情報に基づいて対象アプリの共有データのうちの最小サイズの共有データを特定する。そして、送信部７０２が、最小サイズの共有データをスレーブ携帯端末１１１−ｎに送信する。送信部７０２が、送信時刻を取得し、取得した送信時刻を出力する。

受信部７１１−ｎは、マスタ携帯端末１１０から送信された共有データを受信する。判断部７１２−ｎは、実行中のアプリおよび実行待機中のアプリの合計負荷量が閾値以上であるか否かを判断する。具体的には、たとえば、負荷量とは、単位時間当たりの処理時間である。

送信部７１３−ｎは、判断部７１２−ｎによって合計負荷量が閾値未満であると判断された場合、マスタ携帯端末１１０へ共有データの受信に対する応答を送信する。また、送信部７１３−ｎは、判断部７１２−ｎによって合計負荷量が閾値未満でないと判断された場合、マスタ携帯端末１１０へ共有データの受信に対する応答を送信しない。すなわち、スレーブ携帯端末１１１−ｎに対象アプリが有するスレッドを実行するための余力がある場合、応答がマスタ携帯端末１１０へ送信され、余力が無い場合、応答がマスタ携帯端末１１０へ送信されない。

受信部７０３は、スレーブ携帯端末１１１−ｎから一定時間以内に応答を受信する。具体的には、たとえば、受信部７０３は、送信時刻からの経過時間を監視することにより、一定時間以内には応答を待つ。さらに、具体的には、たとえば、受信部７０３は、スレーブ携帯端末１１１−ｎからの応答を受け付けると、スレーブ携帯端末１１１−ｎの識別情報と受信時刻とを関連付けて出力する。また、具体的には、たとえば、受信部７０３は、一定時間経過後、スレーブ携帯端末１１１−ｎからの応答の待ち状態を止める。

算出部７０４は、受信部７０３により応答のあったスレーブ携帯端末１１１とマスタ携帯端末１１０との携帯端末数と、第１の処理時間に基づいて、第２の処理時間を算出する。第１の処理時間は、対象アプリが１台の携帯端末で逐次処理した場合の処理時間であり、第２の処理時間は、対象アプリが該携帯端末数で並列処理した場合の処理時間である。判断部７０５は、送信部７０２による共有データの送信時刻と受信部７０３による応答の受信時刻との差分値と、第２の処理時間と、の合計値が、第１の処理時間以上であるか否かを判断する。

具体的には、たとえば、算出部７０４は、アプリテーブル６００から、対象アプリを１台の携帯端末で逐次処理させた場合のＴ（１）を第１の処理時間として取得し、各並列度での割合を取得する。そして、具体的には、たとえば、算出部７０４と判断部７０５は、下記式（２）および（３）を算出する。

τｎ＝ｔｄｎ−ｔｓ・・・（２）
Ｔ（Ｎ）＝（Ｆ（１）＋Ｆ（２）／２＋Ｆ（Ｎ−１）／（Ｎ−１））×Ｔ（１）＋τ＿ＭＡＸ×Ｍ・・・（３）

ｔｄｎ（ｎ＝１〜３）が応答を受信した受信時刻である。ｔｄ１がスレーブ携帯端末１１１−１からの応答の受信時刻であり、ｔｄ２がスレーブ携帯端末１１１−２からの応答の受信時刻であり、ｔｄ３がスレーブ携帯端末１１１−３からの応答の受信時刻である。ｔｓが共有データを送信した送信時刻である。

τｎ（ｎ＝１〜３）は、スレーブ携帯端末１１１−ｎの通信状況に関するオーバヘッドであり、マスタ携帯端末１１０が共有データを送信した送信時刻から、マスタ携帯端末１１０が応答を受信した受信時刻までの時間である。τ１がスレーブ携帯端末１１１−１の通信状況に関するオーバヘッドであり、τ２がスレーブ携帯端末１１１−２の通信状況に関するオーバヘッドであり、τ３がスレーブ携帯端末１１１−３の通信状況に関するオーバヘッドである。

τ＿ＭＡＸは、τ１〜τ３のうちの最大の時間である。Ｔ（１）が第１の処理時間である。Ｎは、応答のあったスレーブ携帯端末数＋１である。Ｐが実行割合である。Ｍがディスパッチ回数である。τ＿ＭＡＸ×Ｍがオーバヘッドである。式（３）のうち、τ＿ＭＡＸ×Ｍを除いた部分が第２の処理時間であり、Ｔ（Ｎ）が第２の処理時間とオーバヘッドの合計値である。第２の処理時間については、予めテーブル化しておいてもよい。具体的には、たとえば、判断部７０５は、算出したＴ（Ｎ）がＴ（１）以上であるか否かを判断する。

制御部７０６は、判断部７０５によってＴ（Ｎ）がＴ（１）以上であると判断された場合、逐次処理させる。具体的には、たとえば、制御部７０６は、応答のあった各スレーブ携帯端末１１１に逐次処理実行通知を送信し、対象アプリの実行処理を開始する。

また、制御部７０６は、判断部７０５によってＴ（Ｎ）がＴ（１）以上でないと判断された場合、応答のあったスレーブ携帯端末１１１とマスタ携帯端末１１０とで対象アプリを並列処理する。具体的には、たとえば、制御部７０６は、対象アプリが有するスレッドを固有データサイズの大きい順に特定する。

そして、具体的には、たとえば、制御部７０６は、算出したオーバヘッドの小さいスレーブ携帯端末１１１順に固有データサイズの大きいスレッドを割り当てる。そして、具体的には、たとえば、制御部７０６は、対象アプリの共有データ群の中で、特定した最小サイズの共有データを除く残余の共有データを、送信部７０２を用いて送信する。

図８は、一実施例を示す説明図である。図８では、対象アプリがアプリ＃０の場合を例に挙げる。アプリ＃０の共有データについては、共有データテーブル５００を参照することで特定することができる。アプリ＃０の共有データはｄａｔａ＃０とｄａｔａ＃１であり、最小サイズの共有データは、ｄａｔａ＃０であるため、ｄａｔａ＃０が各スレーブ携帯端末１１１に送信される。

スレーブ携帯端末１１１は、負荷量テーブル８００に基づいて、実行中のアプリおよび実行待機中のアプリの負荷量の合計値を算出する。負荷量テーブル８００は、アプリＩＤ、負荷量のフィールドを有している。各フィールドに情報を設定することで、負荷量情報（たとえば、８０１−１，８０１−２）がレコードとして記憶されている。ここで、アプリＩＤのフィールドには、アプリケーションの識別情報が登録される。負荷量のフィールドには、アプリケーションの負荷量が登録される。

たとえば、スレーブ携帯端末１１１−１では、アプリ＃２とアプリ＃３とが実行中であるとし、アプリ＃２とアプリ＃３の負荷量の合計値を算出する。該合計値は４０［％］である。スレーブ携帯端末１１１−１が、該合計値が閾値（たとえば、７０［％］）以上であるか否かを判断する。ここでは、合計値が閾値未満であるため、スレーブ携帯端末１１１−１が、ｄａｔａ＃０の受信に対して応答をマスタ携帯端末１１０へ送信する。

たとえば、ｄａｔａ＃０の送信時刻と、スレーブ携帯端末１１１−ｎからの応答の受信時刻とが、下記であるとする。ここでは、すべてのスレーブ携帯端末１１１から応答があったこととする。
・送信時刻ｔｓ：１３時０３分００秒
・受信時刻ｔｄ１（スレーブ携帯端末１１１−１からの応答）：１３時０３分０１秒
・受信時刻ｔｄ２（スレーブ携帯端末１１１−２からの応答）：１３時０３分０１秒８０
・受信時刻ｔｄ３（スレーブ携帯端末１１１−３からの応答）：１３時０３分０１秒

そして、各スレーブ携帯端末１１１の通信状態に関するオーバヘッドは下記となる。
オーバヘッドτ１：１［ｓ］
オーバヘッドτ２：０．８［ｓ］
オーバヘッドτ３：１［ｓ］
オーバヘッドτ＿ＭＡＸ：１［ｓ］

つぎに、上記式（３）に基づくＴ（Ｎ）は下記となる。Ｔ（１）は１０［ｓ］であり、ディスパッチ回数Ｍは２である。
・Ｔ（４）＝（３０［％］＋４０［％］／２＋１５［％］／３）×１０［ｓ］＋１［ｓ］×５
＝（５５［％］）×１０［ｓ］＋５［ｓ］
＝５．５［ｓ］＋５［ｓ］
＝１０．５［ｓ］

Ｔ（４）がＴ（１）より大きいため、マスタ携帯端末１１０は、アプリ＃０を逐次処理で実行するために、応答のあったスレーブ携帯端末１１１−ｎへ逐次実行処理通知を送信する。そして、マスタ携帯端末１１０は、アプリ＃０を逐次処理で実行する。スレーブ携帯端末１１１−ｎは、逐次実行処理通知を受け付けると、ｄａｔａ＃０を廃棄する。

（マスタ携帯端末１１０の処理手順）
図９および図１０は、マスタ携帯端末１１０が行う処理手順の一例を示すフローチャートである。まず、マスタ携帯端末１１０が、受付部により、アプリの起動指示を受け付けたか否かを判断する（ステップＳ９０１）。マスタ携帯端末１１０が、アプリの起動指示を受け付けていないと判断した場合（ステップＳ９０１：Ｎｏ）、ステップＳ９０１へ戻る。

マスタ携帯端末１１０が、アプリの起動指示を受け付けたと判断した場合（ステップＳ９０１：Ｙｅｓ）、起動指示を受け付けたアプリ（対象アプリ）が複数の携帯端末で並列処理するアプリか否かを判断する（ステップＳ９０２）。並列処理するか否かについては、たとえば、テーブルに対象アプリの識別情報が登録されているか否かによって判断することとする。

マスタ携帯端末１１０が、対象アプリが複数の携帯端末で並列処理するアプリでないと判断した場合（ステップＳ９０２：Ｎｏ）、ステップＳ９１８へ移行する。マスタ携帯端末１１０が、対象アプリが複数の携帯端末で並列処理するアプリであると判断した場合（ステップＳ９０２：Ｙｅｓ）、対象アプリの共有データ群の中で、最小サイズの共有データを特定する（ステップＳ９０３）。マスタ携帯端末１１０が、特定した共有データを各スレーブ携帯端末１１１に送信し（ステップＳ９０４）、送信時刻を取得し（ステップＳ９０５）、スレーブ携帯端末１１１から応答を受信したか否かを判断する（ステップＳ９０６）。

マスタ携帯端末１１０が、スレーブ携帯端末１１１から応答を受信していないと判断した場合（ステップＳ９０６：Ｎｏ）、ステップＳ９１０へ移行する。マスタ携帯端末１１０が、スレーブ携帯端末１１１から応答を受信したと判断した場合（ステップＳ９０６：Ｙｅｓ）、受信時刻を取得し（ステップＳ９０７）、応答の送信元のスレーブ携帯端末１１１の識別情報と取得した受信時刻を関連付けて出力する（ステップＳ９０８）。マスタ携帯端末１１０が、すべてのスレーブ携帯端末１１１から応答を受信したか否かを判断する（ステップＳ９０９）。

マスタ携帯端末１１０が、すべてのスレーブ携帯端末１１１から応答を受信していないと判断した場合（ステップＳ９０９：Ｎｏ）、一定時間経過したか否かを判断する（ステップＳ９１０）。マスタ携帯端末１１０が、一定時間経過していないと判断した場合（ステップＳ９１０：Ｎｏ）、ステップＳ９０６へ戻る。

マスタ携帯端末１１０が、一定時間経過したと判断した場合（ステップＳ９１０：Ｙｅｓ）、いずれのスレーブ携帯端末１１１からも応答がないか否かを判断する（ステップＳ９１１）。マスタ携帯端末１１０が、いずれのスレーブ携帯端末１１１からも応答がないと判断した場合（ステップＳ９１１：Ｙｅｓ）、ステップＳ９１８へ移行する。

マスタ携帯端末１１０が、いずれかのスレーブ携帯端末１１１から応答があると判断した場合（ステップＳ９１１：Ｎｏ）、ステップＳ９１２へ移行する。また、ステップＳ９０９において、マスタ携帯端末１１０が、すべてのスレーブ携帯端末１１１から応答を受信した判断した場合（ステップＳ９０９：Ｙｅｓ）、ステップＳ９１２へ移行する。

ステップＳ９１１のＮｏの場合、またはステップＳ９０９のＹｅｓの場合のつぎに、マスタ携帯端末１１０が、応答のあったスレーブ携帯端末１１１ごとに受信時刻と送信時刻との差分をスレーブ携帯端末１１１のτとして算出する（ステップＳ９１２）。マスタ携帯端末１１０が、算出した各スレーブ携帯端末１１１のτのうち、最大値を特定し（ステップＳ９１３）、Ｎ＝応答のあったスレーブ携帯端末１１１数＋１とし（ステップＳ９１４）、Ｔ（Ｎ）を算出する（ステップＳ９１５）。マスタ携帯端末１１０が、Ｔ（Ｎ）≧Ｔ（１）であるか否かを判断する（ステップＳ９１６）。

マスタ携帯端末１１０が、Ｔ（Ｎ）≧Ｔ（１）であると判断した場合（ステップＳ９１６：Ｙｅｓ）、応答のあった各スレーブ携帯端末１１１に逐次処理実行通知を送信し（ステップＳ９１７）、逐次処理を開始する（ステップＳ９１８）。マスタ携帯端末１１０が、対象アプリの実行が終了したか否かを判断する（ステップＳ９１９）。

マスタ携帯端末１１０が、対象アプリの実行が終了していないと判断した場合（ステップＳ９１９：Ｎｏ）、ステップＳ９１９へ戻る。マスタ携帯端末１１０が、対象アプリの実行が終了したと判断した場合（ステップＳ９１９：Ｙｅｓ）、一連の処理を終了する。

マスタ携帯端末１１０が、Ｔ（Ｎ）≧Ｔ（１）でないと判断した場合（ステップＳ９１６：Ｎｏ）、対象アプリが有するスレッドを固有データサイズの大きい順に特定する（ステップＳ９２０）。マスタ携帯端末１１０が、τの小さいスレーブ携帯端末１１１順に固有データサイズの大きいスレッドを割り当てる（ステップＳ９２１）。具体的には、たとえば、マスタ携帯端末１１０が、固有データテーブル４００を参照することで、固有データサイズの大きいスレッドを特定することができる。そして、マスタ携帯端末１１０が、対象アプリの共有データ群の中で、特定した最小サイズの共有データを除く残余の共有データを送信する（ステップＳ９２２）。

マスタ携帯端末１１０が、新たなスレッドが実行可能か否かを判断し（ステップＳ９２３）、新たなスレッドが実行可能でないと判断した場合（ステップＳ９２３：Ｎｏ）、ステップＳ９２３へ戻る。マスタ携帯端末１１０が、新たなスレッドが実行可能であると判断した場合（ステップＳ９２３：Ｙｅｓ）、τの小さいスレーブ携帯端末１１１にスレッドを割り当て（ステップＳ９２４）、対象アプリの実行が終了したか否かを判断する（ステップＳ９２５）。

マスタ携帯端末１１０が、対象アプリの実行が終了していないと判断した場合（ステップＳ９２５：Ｎｏ）、ステップＳ９２３に戻る。マスタ携帯端末１１０が、対象アプリの実行が終了したと判断した場合（ステップＳ９２５：Ｙｅｓ）、一連の処理を終了する。

（スレーブ携帯端末１１１の処理手順）
図１１は、スレーブ携帯端末１１１が行う処理手順の一例を示すフローチャートである。スレーブ携帯端末１１１が、対象アプリの最小サイズの共有データ、スレッドの割り当て、または逐次処理実行通知を受信したか否かを判断する（ステップＳ１１０１）。スレーブ携帯端末１１１が、対象アプリの最小サイズの共有データ、スレッドの割り当て、および逐次処理実行通知を受信していないと判断した場合（ステップＳ１１０１：Ｎｏ）、ステップＳ１１０１へ戻る。

スレーブ携帯端末１１１が、対象アプリの最小サイズの共有データを受信したと判断した場合（ステップＳ１１０１：共有データ）、実行中のアプリに基づき負荷量を算出する（ステップＳ１１０２）。スレーブ携帯端末１１１が、負荷量≦閾値であるか否かを判断し（ステップＳ１１０３）、負荷量≦閾値である場合（ステップＳ１１０３：Ｙｅｓ）、応答をマスタ携帯端末１１０へ送信し（ステップＳ１１０４）、ステップＳ１１０１へ戻る。スレーブ携帯端末１１１が、負荷量≦閾値でない場合（ステップＳ１１０３：Ｎｏ）、ステップＳ１１０１へ戻る。

スレーブ携帯端末１１１が、スレッドの割り当てを受信したと判断した場合（ステップＳ１１０１：割り当て）、割り当てられたスレッドの実行を開始し（ステップＳ１１０５）、スレッドの実行が終了したか否かを判断する（ステップＳ１１０６）。スレーブ携帯端末１１１が、スレッドの実行が終了していないと判断した場合（ステップＳ１１０６：Ｎｏ）、ステップＳ１１０６へ戻る。

スレーブ携帯端末１１１が、スレッドの実行が終了したと判断した場合（ステップＳ１１０６：Ｙｅｓ）、実行終了通知をマスタ携帯端末１１０へ送信する（ステップＳ１１０７）。スレーブ携帯端末１１１が、逐次処理実行通知を受信したと判断した場合（ステップＳ１１０１：逐次処理）、共有データを削除し（ステップＳ１１０８）、ステップＳ１１０１へ戻る。

以上説明したように、複数端末で並列処理可能なアプリであっても、実行前の通信状態に関するオーバヘッドを考慮した並列処理の処理時間が逐次処理の処理時間を超える場合、アプリを逐次処理する。実行要求の送信時刻から応答の受信時刻までの時間を実行時のオーバヘッドの目安としている。これにより、通信によるアプリの性能劣化を防止することができ、アプリの逐次処理での性能を保証することができる。

また、スレーブ携帯端末が複数ある場合、実行要求の送信時刻と応答の最も遅い受信時刻との差分値をオーバヘッドとすることにより、実行時における最も通信の悪い状態を想定することができる。

また、差分値にディスパッチ回数を掛けた値をオーバヘッドとすることにより、アプリが有するスレッドの数が多い場合であっても、より正確に並列処理時の処理時間を見積もることができる。

また、マスタ携帯端末が、実行要求の送信時刻から一定時間以内までの応答のみを受信することで、アプリの応答性能が下がるのを防止することができる。

また、マスタ携帯端末が実行要求に代わって共有データを送信することで、並列処理の準備を行うことができ、並列処理時のアプリの性能を向上させることができる。

また、スレーブ携帯端末が実行中のアプリの負荷量が多い場合に、マスタ携帯端末に応答を返信しないことで、並列処理で実行した場合に性能が劣化するのを防止することができる。

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

また、本実施の形態で示した携帯端末としては、たとえば、携帯電話機（スマートフォン、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）、タブレット型端末、モバイル型パソコンなどが挙げられる。また、制御端末と要求先端末のうち、いずれかがデスクトップ型パソコンやサーバなどであってもよい。

１００ 通信システム
１１０ マスタ携帯端末
１１１−１〜１１１−３ スレーブ携帯端末
６００ アプリテーブル
７０２ 送信部
７０３ 受信部
７０４ 算出部
７０５ 判断部
７０６ 制御部

Claims (6)

1. 対象アプリケーションを逐次処理した場合の第１の処理時間と、前記対象アプリケーションを並列処理した場合の第２の処理時間と、を記憶する記憶装置にアクセス可能な制御端末であって、
   前記対象アプリケーションの起動指示を受け付けると、前記対象アプリケーションの実行要求を要求先端末に送信する送信手段と、
   前記送信手段によって送信された前記実行要求に対する応答を前記要求先端末から受信する受信手段と、
   前記受信手段によって受信された前記応答の受信時刻と前記実行要求の送信時刻との差分値と、前記記憶装置に記憶された前記第２の処理時間と、の合計値が、前記記憶装置に記憶された前記第１の処理時間以上であるか否かを判断する判断手段と、
   前記判断手段によって前記合計値が前記第１の処理時間以上であると判断された場合、前記制御端末で逐次処理し、前記判断手段によって前記合計値が前記第１の処理時間以上でないと判断された場合、前記制御端末と前記要求先端末で並列処理する制御手段と、
   を備えることを特徴とする制御端末。
2. 前記受信手段は、
   前記要求先端末が複数ある場合、前記要求先端末ごとに前記応答を受信し、
   前記判断手段は、
   前記受信手段によって前記要求先端末ごとに受信された前記応答の受信時刻のうちの最も遅い受信時刻と前記実行要求の送信時刻との差分値と、前記記憶装置に記憶された前記第２の処理時間と、の合計値が、前記記憶装置に記憶された前記第１の処理時間以上であるか否かを判断し、
   前記制御手段は、
   前記判断手段によって前記合計値が前記第１の処理時間以上であると判断された場合、前記制御端末で逐次処理し、前記判断手段によって前記合計値が前記第１の処理時間以上でないと判断された場合、前記制御端末と前記要求先端末で並列処理することを特徴とする請求項１に記載の制御端末。
3. 前記記憶装置に前記対象アプリケーションを並列処理した場合のディスパッチ回数が記憶され、
   前記判断手段は、
   前記差分値と前記記憶装置に記憶されたディスパッチ回数を掛けた値と、前記第２の処理時間との合計値が、前記第１の処理時間以上であるか否かを判断し、
   前記制御手段は、
   前記判断手段によって前記合計値が前記第１の処理時間以上であると判断された場合、前記制御端末で逐次処理し、前記判断手段によって前記合計値が前記第１の処理時間以上でないと判断された場合、前記制御端末と前記要求先端末で並列処理することを特徴とする請求項１または２に記載の制御端末。
4. 前記受信手段が、
   前記送信手段によって前記実行要求を送信してから一定時間以内に前記応答を受信することを特徴とする請求項１〜３のいずれか一つに記載の制御端末。
5. 前記送信手段が、
   前記対象アプリケーションの実行要求に代わって前記対象アプリケーションの共有データを送信することを特徴とする請求項１〜４のいずれか一つに記載の制御端末。
6. 対象アプリケーションを逐次処理した場合の第１の処理時間と、前記対象アプリケーションを並列処理した場合の第２の処理時間と、を記憶する記憶装置にアクセス可能な制御端末が、
   前記対象アプリケーションの起動指示を受け付けると、前記対象アプリケーションの実行要求を要求先端末に送信する送信処理と、
   前記送信処理によって送信された前記実行要求に対する応答を前記要求先端末から受信する受信処理と、
   前記受信処理によって受信された前記応答の受信時刻と前記実行要求の送信時刻との差分値と、前記記憶装置に記憶された前記第２の処理時間と、の合計値が、前記記憶装置に記憶された前記第１の処理時間以上であるか否かを判断する判断処理と、
   前記判断処理によって前記合計値が前記第１の処理時間以上であると判断された場合、前記制御端末で逐次処理し、前記判断処理によって前記合計値が前記第１の処理時間以上でないと判断された場合、前記制御端末と前記要求先端末で並列処理する制御処理と、
   を実行することを特徴とする制御方法。

Images