処理中

しばらくお待ちください...

設定

設定

出願の表示

1. WO2013005322 - 制御端末、および制御方法

Document

明 細 書

発明の名称 制御端末、および制御方法

技術分野

0001  

背景技術

0002   0003  

先行技術文献

特許文献

0004  

発明の概要

発明が解決しようとする課題

0005   0006  

課題を解決するための手段

0007  

発明の効果

0008  

図面の簡単な説明

0009  

発明を実施するための形態

0010   0011   0012   0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079  

符号の説明

0080  

請求の範囲

1   2   3   4   5   6  

図面

1   2   3   4   5   6   7   8   9   10   11  

明 細 書

発明の名称 : 制御端末、および制御方法

技術分野

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

背景技術

[0002]
 従来、複数のコンピュータがネットワークを介してアプリケーション(以下、「アプリ」と称する。)を並列・分散処理する技術が知られている。さらに、近年では、複数の携帯端末が無線ネットワークを介して並列処理を行う技術が知られている。
[0003]
 関連する先行技術としては、たとえば、ループ演算を並列化させる際に、ループ演算間にデータの依存関係があれば、コンピュータ間の通信回数を減少させるようにシステムを構築する技術が知られている。また、たとえば、並列処理を管理するコンピュータが、他のコンピュータのリソース利用状況に基づいて処理を割り当てる技術が知られている。

先行技術文献

特許文献

[0004]
特許文献1 : 特開2008-3907号公報
特許文献2 : 特開2002-358291号公報
特許文献3 : 特開平5-158895号公報

発明の概要

発明が解決しようとする課題

[0005]
 しかしながら、無線ネットワークを介する携帯端末の場合、たとえば、携帯端末の所持者が移動してしまうと、通信状態が変化してしまう。複数の携帯端末で並列処理を行う場合に、アプリの処理時間とアプリに関するデータ転送時間との大小関係が変化してしまい、アプリによっては、複数の携帯端末で並列処理を行うことにより、性能が劣化してしまう問題点がある。
[0006]
 本発明は、上述した従来技術による問題点を解消するため、逐次処理でのアプリの性能を保証することができる制御端末、および制御方法を提供することを目的とする。

課題を解決するための手段

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

発明の効果

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

図面の簡単な説明

[0009]
[図1] 図1は、通信システム例を示す説明図である。
[図2] 図2は、並列処理における性能指標の一例を示す説明図である。
[図3] 図3は、携帯端末のハードウェア例を示すブロック図である。
[図4] 図4は、固有データテーブルの一例を示す説明図である。
[図5] 図5は、共有データテーブルの一例を示す説明図である。
[図6] 図6は、アプリテーブルの一例を示す説明図である。
[図7] 図7は、通信システム100の機能ブロック例を示す説明図である。
[図8] 図8は、一実施例を示す説明図である。
[図9] 図9は、マスタ携帯端末110が行う処理手順の一例を示すフローチャート(その1)である。
[図10] 図10は、マスタ携帯端末110が行う処理手順の一例を示すフローチャート(その2)である。
[図11] 図11は、スレーブ携帯端末111が行う処理手順の一例を示すフローチャートである。

発明を実施するための形態

[0010]
 以下に添付図面を参照して、本発明にかかる制御端末、および制御方法の実施の形態を詳細に説明する。
[0011]
(通信システム例)
 図1は、通信システム例を示す説明図である。通信システム100は、マスタ携帯端末110と、スレーブ携帯端末111-1~111-3と、基地局120と、を有している。ここでは、マスタ携帯端末110がいずれのスレーブ携帯端末111と並列処理を行うかについては予め決定されていることとし、マスタ携帯端末110とスレーブ携帯端末111-1~111-3は相互に宛先アドレスを知っていることとする。スレーブ携帯端末111については、1台以上であればよく、図1では、3台となっている。マスタ携帯端末110が制御端末であり、スレーブ携帯端末111-1~111-3が要求先端末である。図1では、基地局120を介して携帯端末間が通信を行っているが、アドホック通信のように基地局120を介さずに直接携帯端末間で通信を行ってもよい。
[0012]
 PCやサーバの場合、配置が固定されているが、携帯端末の場合、携帯端末の所持者が移動する場合がある。これにより、各携帯端末と基地局120との通信の信号強度が変化する場合がある。すなわち、マスタ携帯端末110とスレーブ携帯端末111-1~111-3とのデータの通信状態が時々刻々と変化する。
[0013]
 マスタ携帯端末110が、複数の携帯端末で並列処理可能な対象アプリの起動指示を受け付けると、実行要求をスレーブ携帯端末111-1~111-3に送信する。ここで、複数の携帯端末で並列処理可能な対象アプリとは、たとえば、ストリーミングに関するアプリが挙げられる。
[0014]
 スレーブ携帯端末111-1~111-3が、それぞれ実行要求を受信すると、それぞれマスタ携帯端末110へ応答を送信する。図1の例では、スレーブ携帯端末111-3の通信状況が悪いため、マスタ携帯端末110への応答の送信が遅くなっている。本発明の一実施例では、共有データの送信時刻から、最も応答の遅い受信時刻までの時間を通信状態によるオーバヘッドτとして扱う。
[0015]
 マスタ携帯端末110が、対象アプリを複数の携帯端末で並列処理した場合の第2の処理時間にオーバヘッドτを加算した合計値が、マスタ携帯端末110で逐次処理した場合の第1の処理時間未満であるか否かを判断する。ここで、複数の携帯端末とは、マスタ携帯端末110とスレーブ携帯端末111-1~111-3である。マスタ携帯端末110が、該合計値が第1の処理時間未満であれば、対象アプリを複数の携帯端末で並列処理し、該合計値が第1の処理時間以上であれば、対象アプリをマスタ携帯端末110で逐次処理する。
[0016]
 図2は、並列処理における性能指標の一例を示す説明図である。グラフ200では、並列処理における性能指標であるアムダールの法則に対して、いくつかのオーバヘッドを加えた例がプロットされている。グラフ200の横方向はN(ノード数)であり、グラフ200の縦方向は性能である。ここで、グラフ200のN(ノード数)は携帯端末数であり、すべての携帯端末のCPUなどのハードウェアが同一であるとした場合である。グラフ200の性能については、N=1の場合を1とした場合の例である。
[0017]
 性能指標を示す式(1)を下記に示す。
 T(N)=(1-(1-F)/N)×T(1)+τ・・・(1)
[0018]
 Fは並列化できない逐次処理部分の処理時間の割合である。並列化可能な部分の処理時間の割合は(1-F)である。τがオーバヘッドである。T(1)は、1台の携帯端末のみでアプリケーションを実行した場合の処理時間である。▲で示す折れ線201では、Fが50[%]である。×で示す折れ線202では、Fが30[%]である。折れ線201と折れ線202は理想値を示すために、オーバヘッドτが0である。◆で示す折れ線203では、Fが50[%]であり、■で示す折れ線204では、Fが30[%]である。折れ線203と折れ線204はτが含まれている。
[0019]
 折れ線203では、N=2の場合に性能が1未満となっているが、N=3~8の場合に性能が1以上となっている。折れ線204では、N=2~8の場合に性能が1未満となっている。すなわち、アプリを並列処理するならば、逐次処理する方が性能がよい場合がある。
[0020]
(携帯端末のハードウェア例)
 図3は、携帯端末(マスタ携帯端末110、スレーブ携帯端末111-1~111-3)のハードウェア例を示すブロック図である。携帯端末300は、CPU301と、ディスプレイ302と、キーボード303と、I/F(InterFace)304と、RAM(Random Access Memory)306と、ROM(Read Only Memory)307と、を有している。携帯端末300は、フラッシュROM308と、フラッシュROMコントローラ309と、フラッシュROM310と、を有している。CPU301と、ディスプレイ302と、キーボード303と、I/F304と、RAM306と、ROM307と、フラッシュROM308と、フラッシュROMコントローラ309とは、バス311を介して接続されている。
[0021]
 ここで、CPU301は、携帯端末300の全体の制御を司る。CPU301は、レジスタとコアとキャッシュを有している。コアは、演算機能を有している。各CPU301内のレジスタは、PC(Program Counter)やリセットレジスタを有している。CPU301はOS321を実行し、OS321は携帯端末300に割り当てられたスレッドを実行する。OS321は、ウエイトキュー331を有している。OS321は、ウエイトキュー331にアプリが積まれると、該アプリの起動指示を受け付けたと判断する。
[0022]
 ディスプレイ302は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ302は、たとえば、TFT液晶ディスプレイなどを採用することができる。キーボード303は、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボード303は、タッチパネル式の入力パッドやテンキーなどであってもよい。
[0023]
 I/F304は、無線通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワーク305に接続され、ネットワーク305を介して他の携帯端末に接続される。そして、I/F304は、ネットワーク305と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F304には、たとえば、無線通信用のモデムやLANアダプタなどを採用することができる。
[0024]
 ROM307は、ブートプログラムなどのプログラムを記憶している。RAM306は、各CPU301のワークエリアとして使用される。フラッシュROM308は、OS321などのシステムソフトウェアやアプリケーションのプログラムを記憶している。RAM306はフラッシュROM308よりも各CPU301からのアクセス速度が速い。OS321がアプリケーションのプログラムをフラッシュROM308からRAM306へロードすることにより、該アプリケーションのコンテキスト情報がRAM306内に展開される。
[0025]
 フラッシュROMコントローラ309は、各CPU301の制御に従ってフラッシュROM310に対するデータのリード/ライトを制御する。フラッシュROM310は、フラッシュROMコントローラ309の制御で書き込まれたデータを記憶する。データの具体例としては、端末を使用するユーザがI/F304を通して取得した画像データ、映像データなどである。フラッシュROM310は、たとえば、メモリカード、SDカードなどを採用することができる。
[0026]
(固有データテーブル)
 図4は、固有データテーブルの一例を示す説明図である。固有データテーブル400は、アプリID、スレッドID、固有データID、合計サイズのフィールドを有している。各フィールドに情報を設定することで、固有情報(たとえば、401-1,401-2)がレコードとして記憶されている。
[0027]
 ここで、アプリIDのフィールドには、アプリの識別情報が登録される。スレッドIDのフィールドには、アプリが有するスレッドの識別情報が登録される。固有データIDのフィールドには、スレッドが固有で有する固有データの識別情報が登録される。合計サイズのフィールドには、スレッドが有する固有データの合計サイズが登録される。
[0028]
(共有データテーブル)
 図5は、共有データテーブルの一例を示す説明図である。共有データテーブル500は、アプリID、共有データID、サイズのフィールドを有している。各フィールドに情報を設定することで、共有情報(たとえば、501-1,501-2)がレコードとして記憶されている。
[0029]
 ここで、アプリIDのフィールドには、アプリの識別情報が登録される。共有データのフィールドには、アプリのすべてのスレッドで共有する共有データの識別情報が登録される。サイズのフィールドには、共有データのサイズが登録される。
[0030]
(アプリテーブル)
 図6は、アプリテーブルの一例を示す説明図である。アプリテーブル600は、アプリID、T(1)、ディスパッチ回数、並列度、割合のフィールドを有している。各フィールドに情報を設定することで、アプリ情報(たとえば、601-1,601-2)がレコードとして記憶されている。
[0031]
 アプリIDのフィールドには、アプリの識別情報が登録される。T(1)のフィールドには、アプリを1台の携帯端末で逐次処理した場合の処理時間が登録される。具体的には、たとえば、T(1)はアプリの設計時にシミュレーションにより算出される。ディスパッチ回数のフィールドには、アプリが有するスレッドで発生する割り当て回数が登録される。たとえば、並列処理可能なループ処理がある場合、少なくともループ回数分はディスパッチが発生することとなる。割合のフィールドには、並列度のフィールドに登録された携帯端末数でアプリが並列処理可能な割合が登録されている。
[0032]
(通信システム100の機能ブロック例)
 図7は、通信システム100の機能ブロック例を示す説明図である。マスタ携帯端末110は、受付部701と、送信部702と、受信部703と、算出部704と、判断部705と、制御部706と、を有している。受付部701~制御部706は、具体的には、たとえば、制御プログラムにコーディングされており、該制御プログラムは図3に示したROM307、フラッシュROM308、フラッシュROM310などの記憶装置に記憶されている。CPU301が記憶装置から制御プログラムを読み出し、制御プログラムにコーディングされている処理を実行する。これにより、受付部701~制御部706の処理が実行される。制御プログラムは、たとえば、図3に示したOS321である。
[0033]
 スレーブ携帯端末111-n(n=1~3)は、受信部711-nと、判断部712-nと、送信部713-nと、を有している。受信部711-n~送信部713-nは、具体的には、たとえば、制御プログラムにコーディングされており、該制御プログラムは図3に示したROM307、フラッシュROM308、フラッシュROM310などの記憶装置に記憶されている。CPU301が記憶装置から制御プログラムを読み出し、制御プログラムにコーディングされている処理を実行する。これにより、受信部711-n~送信部713-nの処理が実行される。制御プログラムは、たとえば、図3に示したOS321である。
[0034]
 受付部701は、対象アプリの起動指示を受け付ける。具体的には、たとえば、受付部701が、ウエイトキュー331に対象アプリが積まれるのを監視し、積まれた対象アプリを起動指示のあるアプリとして受け付ける。
[0035]
 送信部702は、受付部701により受け付けられた対象アプリが複数の携帯端末で並列処理を行うアプリである場合、対象アプリが有する共有データのうち、最小サイズの共有データをスレーブ携帯端末111-nに送信する。具体的には、たとえば、送信部702が、共有データテーブル500から、対象アプリの識別情報に基づいて対象アプリの共有データのうちの最小サイズの共有データを特定する。そして、送信部702が、最小サイズの共有データをスレーブ携帯端末111-nに送信する。送信部702が、送信時刻を取得し、取得した送信時刻を出力する。
[0036]
 受信部711-nは、マスタ携帯端末110から送信された共有データを受信する。判断部712-nは、実行中のアプリおよび実行待機中のアプリの合計負荷量が閾値以上であるか否かを判断する。具体的には、たとえば、負荷量とは、単位時間当たりの処理時間である。
[0037]
 送信部713-nは、判断部712-nによって合計負荷量が閾値未満であると判断された場合、マスタ携帯端末110へ共有データの受信に対する応答を送信する。また、送信部713-nは、判断部712-nによって合計負荷量が閾値未満でないと判断された場合、マスタ携帯端末110へ共有データの受信に対する応答を送信しない。すなわち、スレーブ携帯端末111-nに対象アプリが有するスレッドを実行するための余力がある場合、応答がマスタ携帯端末110へ送信され、余力が無い場合、応答がマスタ携帯端末110へ送信されない。
[0038]
 受信部703は、スレーブ携帯端末111-nから一定時間以内に応答を受信する。具体的には、たとえば、受信部703は、送信時刻からの経過時間を監視することにより、一定時間以内には応答を待つ。さらに、具体的には、たとえば、受信部703は、スレーブ携帯端末111-nからの応答を受け付けると、スレーブ携帯端末111-nの識別情報と受信時刻とを関連付けて出力する。また、具体的には、たとえば、受信部703は、一定時間経過後、スレーブ携帯端末111-nからの応答の待ち状態を止める。
[0039]
 算出部704は、受信部703により応答のあったスレーブ携帯端末111とマスタ携帯端末110との携帯端末数と、第1の処理時間に基づいて、第2の処理時間を算出する。第1の処理時間は、対象アプリが1台の携帯端末で逐次処理した場合の処理時間であり、第2の処理時間は、対象アプリが該携帯端末数で並列処理した場合の処理時間である。判断部705は、送信部702による共有データの送信時刻と受信部703による応答の受信時刻との差分値と、第2の処理時間と、の合計値が、第1の処理時間以上であるか否かを判断する。
[0040]
 具体的には、たとえば、算出部704は、アプリテーブル600から、対象アプリを1台の携帯端末で逐次処理させた場合のT(1)を第1の処理時間として取得し、各並列度での割合を取得する。そして、具体的には、たとえば、算出部704と判断部705は、下記式(2)および(3)を算出する。
[0041]
 τn=tdn-ts・・・(2)
 T(N)=(F(1)+F(2)/2+F(N-1)/(N-1))×T(1)+τ_MAX×M・・・(3)
[0042]
 tdn(n=1~3)が応答を受信した受信時刻である。td1がスレーブ携帯端末111-1からの応答の受信時刻であり、td2がスレーブ携帯端末111-2からの応答の受信時刻であり、td3がスレーブ携帯端末111-3からの応答の受信時刻である。tsが共有データを送信した送信時刻である。
[0043]
 τn(n=1~3)は、スレーブ携帯端末111-nの通信状況に関するオーバヘッドであり、マスタ携帯端末110が共有データを送信した送信時刻から、マスタ携帯端末110が応答を受信した受信時刻までの時間である。τ1がスレーブ携帯端末111-1の通信状況に関するオーバヘッドであり、τ2がスレーブ携帯端末111-2の通信状況に関するオーバヘッドであり、τ3がスレーブ携帯端末111-3の通信状況に関するオーバヘッドである。
[0044]
 τ_MAXは、τ1~τ3のうちの最大の時間である。T(1)が第1の処理時間である。Nは、応答のあったスレーブ携帯端末数+1である。Pが実行割合である。Mがディスパッチ回数である。τ_MAX×Mがオーバヘッドである。式(3)のうち、τ_MAX×Mを除いた部分が第2の処理時間であり、T(N)が第2の処理時間とオーバヘッドの合計値である。第2の処理時間については、予めテーブル化しておいてもよい。具体的には、たとえば、判断部705は、算出したT(N)がT(1)以上であるか否かを判断する。
[0045]
 制御部706は、判断部705によってT(N)がT(1)以上であると判断された場合、逐次処理させる。具体的には、たとえば、制御部706は、応答のあった各スレーブ携帯端末111に逐次処理実行通知を送信し、対象アプリの実行処理を開始する。
[0046]
 また、制御部706は、判断部705によってT(N)がT(1)以上でないと判断された場合、応答のあったスレーブ携帯端末111とマスタ携帯端末110とで対象アプリを並列処理する。具体的には、たとえば、制御部706は、対象アプリが有するスレッドを固有データサイズの大きい順に特定する。
[0047]
 そして、具体的には、たとえば、制御部706は、算出したオーバヘッドの小さいスレーブ携帯端末111順に固有データサイズの大きいスレッドを割り当てる。そして、具体的には、たとえば、制御部706は、対象アプリの共有データ群の中で、特定した最小サイズの共有データを除く残余の共有データを、送信部702を用いて送信する。
[0048]
 図8は、一実施例を示す説明図である。図8では、対象アプリがアプリ#0の場合を例に挙げる。アプリ#0の共有データについては、共有データテーブル500を参照することで特定することができる。アプリ#0の共有データはdata#0とdata#1であり、最小サイズの共有データは、data#0であるため、data#0が各スレーブ携帯端末111に送信される。
[0049]
 スレーブ携帯端末111は、負荷量テーブル800に基づいて、実行中のアプリおよび実行待機中のアプリの負荷量の合計値を算出する。負荷量テーブル800は、アプリID、負荷量のフィールドを有している。各フィールドに情報を設定することで、負荷量情報(たとえば、801-1,801-2)がレコードとして記憶されている。ここで、アプリIDのフィールドには、アプリケーションの識別情報が登録される。負荷量のフィールドには、アプリケーションの負荷量が登録される。
[0050]
 たとえば、スレーブ携帯端末111-1では、アプリ#2とアプリ#3とが実行中であるとし、アプリ#2とアプリ#3の負荷量の合計値を算出する。該合計値は40[%]である。スレーブ携帯端末111-1が、該合計値が閾値(たとえば、70[%])以上であるか否かを判断する。ここでは、合計値が閾値未満であるため、スレーブ携帯端末111-1が、data#0の受信に対して応答をマスタ携帯端末110へ送信する。
[0051]
 たとえば、data#0の送信時刻と、スレーブ携帯端末111-nからの応答の受信時刻とが、下記であるとする。ここでは、すべてのスレーブ携帯端末111から応答があったこととする。
 ・送信時刻ts:13時03分00秒
 ・受信時刻td1(スレーブ携帯端末111-1からの応答):13時03分01秒
 ・受信時刻td2(スレーブ携帯端末111-2からの応答):13時03分01秒80
 ・受信時刻td3(スレーブ携帯端末111-3からの応答):13時03分01秒
[0052]
 そして、各スレーブ携帯端末111の通信状態に関するオーバヘッドは下記となる。
 オーバヘッドτ1:1[s]
 オーバヘッドτ2:0.8[s]
 オーバヘッドτ3:1[s]
 オーバヘッドτ_MAX:1[s]
[0053]
 つぎに、上記式(3)に基づくT(N)は下記となる。T(1)は10[s]であり、ディスパッチ回数Mは2である。
 ・T(4)=(30[%]+40[%]/2+15[%]/3)×10[s]+1[s]×5
 =(55[%])×10[s]+5[s]
 =5.5[s]+5[s]
 =10.5[s]
[0054]
 T(4)がT(1)より大きいため、マスタ携帯端末110は、アプリ#0を逐次処理で実行するために、応答のあったスレーブ携帯端末111-nへ逐次実行処理通知を送信する。そして、マスタ携帯端末110は、アプリ#0を逐次処理で実行する。スレーブ携帯端末111-nは、逐次実行処理通知を受け付けると、data#0を廃棄する。
[0055]
(マスタ携帯端末110の処理手順)
 図9および図10は、マスタ携帯端末110が行う処理手順の一例を示すフローチャートである。まず、マスタ携帯端末110が、受付部により、アプリの起動指示を受け付けたか否かを判断する(ステップS901)。マスタ携帯端末110が、アプリの起動指示を受け付けていないと判断した場合(ステップS901:No)、ステップS901へ戻る。
[0056]
 マスタ携帯端末110が、アプリの起動指示を受け付けたと判断した場合(ステップS901:Yes)、起動指示を受け付けたアプリ(対象アプリ)が複数の携帯端末で並列処理するアプリか否かを判断する(ステップS902)。並列処理するか否かについては、たとえば、テーブルに対象アプリの識別情報が登録されているか否かによって判断することとする。
[0057]
 マスタ携帯端末110が、対象アプリが複数の携帯端末で並列処理するアプリでないと判断した場合(ステップS902:No)、ステップS918へ移行する。マスタ携帯端末110が、対象アプリが複数の携帯端末で並列処理するアプリであると判断した場合(ステップS902:Yes)、対象アプリの共有データ群の中で、最小サイズの共有データを特定する(ステップS903)。マスタ携帯端末110が、特定した共有データを各スレーブ携帯端末111に送信し(ステップS904)、送信時刻を取得し(ステップS905)、スレーブ携帯端末111から応答を受信したか否かを判断する(ステップS906)。
[0058]
 マスタ携帯端末110が、スレーブ携帯端末111から応答を受信していないと判断した場合(ステップS906:No)、ステップS910へ移行する。マスタ携帯端末110が、スレーブ携帯端末111から応答を受信したと判断した場合(ステップS906:Yes)、受信時刻を取得し(ステップS907)、応答の送信元のスレーブ携帯端末111の識別情報と取得した受信時刻を関連付けて出力する(ステップS908)。マスタ携帯端末110が、すべてのスレーブ携帯端末111から応答を受信したか否かを判断する(ステップS909)。
[0059]
 マスタ携帯端末110が、すべてのスレーブ携帯端末111から応答を受信していないと判断した場合(ステップS909:No)、一定時間経過したか否かを判断する(ステップS910)。マスタ携帯端末110が、一定時間経過していないと判断した場合(ステップS910:No)、ステップS906へ戻る。
[0060]
 マスタ携帯端末110が、一定時間経過したと判断した場合(ステップS910:Yes)、いずれのスレーブ携帯端末111からも応答がないか否かを判断する(ステップS911)。マスタ携帯端末110が、いずれのスレーブ携帯端末111からも応答がないと判断した場合(ステップS911:Yes)、ステップS918へ移行する。
[0061]
 マスタ携帯端末110が、いずれかのスレーブ携帯端末111から応答があると判断した場合(ステップS911:No)、ステップS912へ移行する。また、ステップS909において、マスタ携帯端末110が、すべてのスレーブ携帯端末111から応答を受信した判断した場合(ステップS909:Yes)、ステップS912へ移行する。
[0062]
 ステップS911のNoの場合、またはステップS909のYesの場合のつぎに、マスタ携帯端末110が、応答のあったスレーブ携帯端末111ごとに受信時刻と送信時刻との差分をスレーブ携帯端末111のτとして算出する(ステップS912)。マスタ携帯端末110が、算出した各スレーブ携帯端末111のτのうち、最大値を特定し(ステップS913)、N=応答のあったスレーブ携帯端末111数+1とし(ステップS914)、T(N)を算出する(ステップS915)。マスタ携帯端末110が、T(N)≧T(1)であるか否かを判断する(ステップS916)。
[0063]
 マスタ携帯端末110が、T(N)≧T(1)であると判断した場合(ステップS916:Yes)、応答のあった各スレーブ携帯端末111に逐次処理実行通知を送信し(ステップS917)、逐次処理を開始する(ステップS918)。マスタ携帯端末110が、対象アプリの実行が終了したか否かを判断する(ステップS919)。
[0064]
 マスタ携帯端末110が、対象アプリの実行が終了していないと判断した場合(ステップS919:No)、ステップS919へ戻る。マスタ携帯端末110が、対象アプリの実行が終了したと判断した場合(ステップS919:Yes)、一連の処理を終了する。
[0065]
 マスタ携帯端末110が、T(N)≧T(1)でないと判断した場合(ステップS916:No)、対象アプリが有するスレッドを固有データサイズの大きい順に特定する(ステップS920)。マスタ携帯端末110が、τの小さいスレーブ携帯端末111順に固有データサイズの大きいスレッドを割り当てる(ステップS921)。具体的には、たとえば、マスタ携帯端末110が、固有データテーブル400を参照することで、固有データサイズの大きいスレッドを特定することができる。そして、マスタ携帯端末110が、対象アプリの共有データ群の中で、特定した最小サイズの共有データを除く残余の共有データを送信する(ステップS922)。
[0066]
 マスタ携帯端末110が、新たなスレッドが実行可能か否かを判断し(ステップS923)、新たなスレッドが実行可能でないと判断した場合(ステップS923:No)、ステップS923へ戻る。マスタ携帯端末110が、新たなスレッドが実行可能であると判断した場合(ステップS923:Yes)、τの小さいスレーブ携帯端末111にスレッドを割り当て(ステップS924)、対象アプリの実行が終了したか否かを判断する(ステップS925)。
[0067]
 マスタ携帯端末110が、対象アプリの実行が終了していないと判断した場合(ステップS925:No)、ステップS923に戻る。マスタ携帯端末110が、対象アプリの実行が終了したと判断した場合(ステップS925:Yes)、一連の処理を終了する。
[0068]
(スレーブ携帯端末111の処理手順)
 図11は、スレーブ携帯端末111が行う処理手順の一例を示すフローチャートである。スレーブ携帯端末111が、対象アプリの最小サイズの共有データ、スレッドの割り当て、または逐次処理実行通知を受信したか否かを判断する(ステップS1101)。スレーブ携帯端末111が、対象アプリの最小サイズの共有データ、スレッドの割り当て、および逐次処理実行通知を受信していないと判断した場合(ステップS1101:No)、ステップS1101へ戻る。
[0069]
 スレーブ携帯端末111が、対象アプリの最小サイズの共有データを受信したと判断した場合(ステップS1101:共有データ)、実行中のアプリに基づき負荷量を算出する(ステップS1102)。スレーブ携帯端末111が、負荷量≦閾値であるか否かを判断し(ステップS1103)、負荷量≦閾値である場合(ステップS1103:Yes)、応答をマスタ携帯端末110へ送信し(ステップS1104)、ステップS1101へ戻る。スレーブ携帯端末111が、負荷量≦閾値でない場合(ステップS1103:No)、ステップS1101へ戻る。
[0070]
 スレーブ携帯端末111が、スレッドの割り当てを受信したと判断した場合(ステップS1101:割り当て)、割り当てられたスレッドの実行を開始し(ステップS1105)、スレッドの実行が終了したか否かを判断する(ステップS1106)。スレーブ携帯端末111が、スレッドの実行が終了していないと判断した場合(ステップS1106:No)、ステップS1106へ戻る。
[0071]
 スレーブ携帯端末111が、スレッドの実行が終了したと判断した場合(ステップS1106:Yes)、実行終了通知をマスタ携帯端末110へ送信する(ステップS1107)。スレーブ携帯端末111が、逐次処理実行通知を受信したと判断した場合(ステップS1101:逐次処理)、共有データを削除し(ステップS1108)、ステップS1101へ戻る。
[0072]
 以上説明したように、複数端末で並列処理可能なアプリであっても、実行前の通信状態に関するオーバヘッドを考慮した並列処理の処理時間が逐次処理の処理時間を超える場合、アプリを逐次処理する。実行要求の送信時刻から応答の受信時刻までの時間を実行時のオーバヘッドの目安としている。これにより、通信によるアプリの性能劣化を防止することができ、アプリの逐次処理での性能を保証することができる。
[0073]
 また、スレーブ携帯端末が複数ある場合、実行要求の送信時刻と応答の最も遅い受信時刻との差分値をオーバヘッドとすることにより、実行時における最も通信の悪い状態を想定することができる。
[0074]
 また、差分値にディスパッチ回数を掛けた値をオーバヘッドとすることにより、アプリが有するスレッドの数が多い場合であっても、より正確に並列処理時の処理時間を見積もることができる。
[0075]
 また、マスタ携帯端末が、実行要求の送信時刻から一定時間以内までの応答のみを受信することで、アプリの応答性能が下がるのを防止することができる。
[0076]
 また、マスタ携帯端末が実行要求に代わって共有データを送信することで、並列処理の準備を行うことができ、並列処理時のアプリの性能を向上させることができる。
[0077]
 また、スレーブ携帯端末が実行中のアプリの負荷量が多い場合に、マスタ携帯端末に応答を返信しないことで、並列処理で実行した場合に性能が劣化するのを防止することができる。
[0078]
 なお、本実施の形態で説明した制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本制御プログラムは、ハードディスク、フレキシブルディスク、CD-ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本制御プログラムは、インターネット等のネットワークを介して配布してもよい。
[0079]
 また、本実施の形態で示した携帯端末としては、たとえば、携帯電話機(スマートフォン、PHS(Personal Handyphone System)、タブレット型端末、モバイル型パソコンなどが挙げられる。また、制御端末と要求先端末のうち、いずれかがデスクトップ型パソコンやサーバなどであってもよい。

符号の説明

[0080]
 100 通信システム
 110 マスタ携帯端末
 111-1~111-3 スレーブ携帯端末
 600 アプリテーブル
 702 送信部
 703 受信部
 704 算出部
 705 判断部
 706 制御部

請求の範囲

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

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]