(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-07-16
(45)【発行日】2024-07-24
(54)【発明の名称】情報処理装置およびプログラム
(51)【国際特許分類】
G06F 9/50 20060101AFI20240717BHJP
【ＦＩ】
G06F9/50 150E
【請求項の数】
5
(21)【出願番号】P 2023036524
(22)【出願日】2023-03-09
【審査請求日】2023-03-09
(73)【特許権者】
【識別番号】313006647
【氏名又は名称】セイコーソリューションズ株式会社
(74)【代理人】
【識別番号】100165179
【弁理士】
【氏名又は名称】田▲崎▼ 聡
(74)【代理人】
【識別番号】100126664
【弁理士】
【氏名又は名称】鈴木 慎吾
(74)【代理人】
【識別番号】100161207
【弁理士】
【氏名又は名称】西澤 和純
(72)【発明者】
【氏名】工藤 裕章
(72)【発明者】
【氏名】小西 裕志
(72)【発明者】
【氏名】上木 洋介
(72)【発明者】
【氏名】丹野 一也
(72)【発明者】
【氏名】塚本 俊
【審査官】坂東 博司
(56)【参考文献】
【文献】中国特許出願公開第１１１８５７６１６（ＣＮ，Ａ）
【文献】中国特許出願公開第１１１４２７７５１（ＣＮ，Ａ）
【文献】米国特許出願公開第２００７／０００５９４２（ＵＳ，Ａ１）
【文献】中国特許出願公開第１１２３０６６４６（ＣＮ，Ａ）
【文献】右京 和馬，ユーザーを待たせない マルチスレッド＆非同期プログラミング入門，日経ソフトウエア 第１５巻 第１１号 NIKKEI SOFTWARE，日本，日経ＢＰ社 Nikkei Business Publications,Inc.，2019年09月24日，第15巻 第１１号，６４～６８，CSND201200470010
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ９／５０
(57)【特許請求の範囲】
【請求項1】
デフォルトではシングルスレッドで動作するＪａｖａＳｃｒｉｐｔエンジンをマルチスレッド化し、互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行する情報処理装置であって、メインスレッドと、スレッドプールを有する第１サブスレッドと、が配置され、
前記メインスレッドは、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストを前記第１サブスレッドに通知し、
前記第１サブスレッドは、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する、
情報処理装置。
【請求項2】
前記処理モジュールは、処理ごとに用意され、前記処理モジュールの中身は、フェーズごとに分割されており、
それぞれの処理ごとの１個の前記処理モジュール内に各フェーズの処理がサブモジュール化されて含まれており、
前記各フェーズは、各々異なるスレッドで実行され、
前記処理モジュールを含む前記リクエストがあった場合、前記第１サブスレッドは、前記処理モジュールを含む前記リクエストを受け取ると、その中に含まれる第１サブモジュールの処理実行を前記第２サブスレッドに依頼し、これに応じて前記第２サブスレッドは、前記第１サブモジュールの処理実行結果を前記第１サブスレッドに返却し、前記第１サブスレッドは当該処理実行結果を受け取り、
前記第１サブスレッドは、前記処理モジュールの中に含まれる第２サブモジュールの処理実行を第３サブスレッドに依頼し、これに応じて前記第３サブスレッドは、前記第２サブモジュールの処理実行結果を前記第１サブスレッドに返却し、前記第１サブスレッドは当該処理実行結果を受け取り、
以上の場合に、前記処理モジュールにおいて、前記第１サブモジュール、前記第２サブモジュールの順に同期処理が行われ、または、前記第１サブモジュールと前記第２サブモジュールとで非同期処理が行われる、
請求項１に記載の情報処理装置。
【請求項3】
前記メインスレッドは、フロントエンドまたはバックエンドにより、前記処理モジュールの前記指定および前記リクエストを受け付ける、請求項１または請求項２に記載の情報処理装置。
【請求項4】
前記メインスレッドは、表示画面に対してユーザーが行った操作に応じて、前記処理モジュールの前記指定および前記リクエストを受け付ける、請求項１または請求項２に記載の情報処理装置。
【請求項5】
デフォルトではシングルスレッドで動作するＪａｖａＳｃｒｉｐｔエンジンをマルチスレッド化し、互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行するコンピューターに、メインスレッドが、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストをスレッドプールを有する第１サブスレッドに通知する機能と、
前記第１サブスレッドが、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理装置およびプログラムに関する。
【背景技術】
【0002】
例えば、デフォルトのＪａｖａＳｃｒｉｐｔエンジンは、シングルスレッドで動作する。このため、完全非同期化を実現するためには、複数スレッドの制御を実現することが必要となる。
【0003】
特許文献１に記載されたコンピューターでは、対象プログラムを修正しなくとも、マルチコアプロセッサーによる動作性能向上および省電力化の効果を得ることが図られている。具体的には、当該コンピューターでは、与えられた対象プログラムの複数のスレッドを各々が独立して実行可能な複数のコアを備えるマルチコアプロセッサー上で、当該対象プログラムと、当該対象プログラムのスレッドが動作可能なコアを指定するコア割り当てプログラムと、当該対象プログラムによって発生されたスレッド生成要求に応じて新規スレッドを生成するスレッド生成機能および動作可能に指定された当該コアで当該新規スレッドを動作させるコアアフィニティ機能を備えるオペレーティングシステムとが動作すると共に、当該マルチコアプロセッサーは、当該コア割り当てプログラムの実行により、当該スレッド生成要求の発生を検出するスレッド生成監視機能と、検出された当該スレッド生成要求によって生成された新規スレッドが動作するコアを指定するコア割り当て設定機能とを備える（特許文献１参照。）。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２０１２－１３３６８２号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来の技術では、メインスレッドにスレッドプールを配置した構成では、マルチコアを十分に使用することができなかった。
例えば、処理が集中しがちなメインスレッドにスレッドプールが配置される構成では、処理のボトルネックになるといった問題があった。
例えば、処理が集中しがちなメインスレッドにスレッドプールが配置される構成では、処理のボトルネックになるといった問題があった。
【0006】
本開示は、このような事情を考慮してなされたもので、処理をマルチスレッド化した場合に、マルチコアを十分に使用することが可能な情報処理装置およびプログラムを提供することを課題とする。
【課題を解決するための手段】
【0007】
本開示の一態様は、デフォルトではシングルスレッドで動作するＪａｖａＳｃｒｉｐｔエンジンをマルチスレッド化し、互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行する情報処理装置であって、メインスレッドと、スレッドプールを有する第１サブスレッドと、が配置され、前記メインスレッドは、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストを前記第１サブスレッドに通知し、前記第１サブスレッドは、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する、情報処理装置である。
【0008】
本開示の一態様は、デフォルトではシングルスレッドで動作するＪａｖａＳｃｒｉｐｔエンジンをマルチスレッド化し、互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行するコンピューターに、メインスレッドが、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストをスレッドプールを有する第１サブスレッドに通知する機能と、前記第１サブスレッドが、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する機能と、を実現させるためのプログラムである。
【発明の効果】
【0009】
本開示に係る情報処理装置およびプログラムによれば、処理をマルチスレッド化した場合に、マルチコアを十分に使用することが可能である。
【図面の簡単な説明】
【0010】
【図1】実施形態に係る情報処理装置におけるプログラムの模式的な構成の一例を示す図である。
【図2】実施形態に係るリクエスト発生時における処理モジュールの呼び出し処理の手順の一例を示す図である。
【図3】実施形態に係る処理モジュールの模式的な構成例を示す図である。
【図4】実施形態に係る非同期処理を模式的に示す図である。
【図5】実施形態に係る派生処理を模式的に示す図である。
【図6】（Ａ）～（Ｈ）は実施形態に係るフロントエンドのマルチコア対応機能有りの結果の一例を示す図である。
【図7】（Ａ）～（Ｈ）は比較例に係るフロントエンドのマルチコア対応機能無しの結果の一例を示す図である。
【図8】（Ａ）～（Ｈ）は実施形態に係るバックエンドのマルチコア対応機能有りの結果の一例を示す図である。
【図9】（Ａ）～（Ｈ）は比較例に係るバックエンドのマルチコア対応機能無しの結果の一例を示す図である。
【図10】実施形態に係る情報処理装置のハードウェアの構成例を示す図である。
【図11】比較例に係る情報処理装置におけるプログラムの模式的な構成の一例を示す図である。
【図12】比較例に係るリクエスト発生時における処理モジュールの呼び出し処理の手順の一例を示す図である。
【発明を実施するための形態】
【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】
＜処理モジュールの指定（処理Ｓ１０２に関する例）＞
図１２は、比較例に係るリクエスト発生時における処理モジュールの呼び出し処理の手順の一例を示す図である。
図１２は、比較例に係るリクエスト発生時における処理モジュールの呼び出し処理の手順の一例を示す図である。
【0081】
（処理Ｓ１０２１）
比較例では、入口部１０２１は、クライアントからリクエストを受け付ける。この際に、比較例では、呼び出すべき処理モジュールの指定を受け付けない。
メイン回路１０２３は、入口部１０２１から、クライアントからのリクエストを受け付ける。
このように、比較例では、図１１に示される処理Ｓ１０１において、メイン回路１０２３は、入口部１０２１から、当該リクエストを受け付ける。
比較例では、入口部１０２１は、クライアントからリクエストを受け付ける。この際に、比較例では、呼び出すべき処理モジュールの指定を受け付けない。
メイン回路１０２３は、入口部１０２１から、クライアントからのリクエストを受け付ける。
このように、比較例では、図１１に示される処理Ｓ１０１において、メイン回路１０２３は、入口部１０２１から、当該リクエストを受け付ける。
【0082】
（処理Ｓ１０２２）
次に、メイン回路１０２３は、リクエストに基づいて、呼び出すべき処理モジュールを判断する。
次に、メイン回路１０２３は、リクエストに基づいて、呼び出すべき処理モジュールを判断する。
【0083】
（処理Ｓ１０２３）
次に、メイン回路１０２３は、判断した処理モジュールを呼び出す。
具体的には、比較例では、図１１に示される処理Ｓ１０２において、メイン回路１０２３は、自己で判断した処理モジュールの指定を有するリクエストを含むメッセージをスレッドプール１０４２に送信する。
次に、メイン回路１０２３は、判断した処理モジュールを呼び出す。
具体的には、比較例では、図１１に示される処理Ｓ１０２において、メイン回路１０２３は、自己で判断した処理モジュールの指定を有するリクエストを含むメッセージをスレッドプール１０４２に送信する。
【0084】
（処理Ｓ１０２４）
その後、メイン回路１０２３は、スレッドプール１０４２から指定の処理モジュールのレスポンスを含むメッセージを受信した場合、処理モジュールの処理結果を入口部１０２１に返却する。図１１の例では、処理Ｓ１１１において、メイン回路１０２３は、処理モジュールの処理結果を含むレスポンスを入口部１０２１に返却する。
その後、メイン回路１０２３は、スレッドプール１０４２から指定の処理モジュールのレスポンスを含むメッセージを受信した場合、処理モジュールの処理結果を入口部１０２１に返却する。図１１の例では、処理Ｓ１１１において、メイン回路１０２３は、処理モジュールの処理結果を含むレスポンスを入口部１０２１に返却する。
【0085】
ここで、処理モジュールとしては、特に限定はなく、例えば、ユーザーの登録処理に関するユーザー登録処理モジュール、ユーザーの削除処理に関するユーザー削除処理モジュール、あるいは、ユーザーの更新処理に関するユーザー更新処理モジュールなどであってもよい。
【0086】
このように、比較例では、メイン回路１０２３が、クライアントからのリクエストに基づいて呼び出すべき処理モジュール（機能モジュール）を判断し、判断した処理モジュールを呼び出す。
【0087】
ここで、比較例では、メイン回路１０２３は、リクエストに基づいて呼び出すべき処理モジュールを判断する判断ロジックを有しており、当該判断ロジックに基づいて呼び出すべき処理モジュールを決定している。
このため、比較例では、例えば、新規の処理モジュールが追加されるたびに、情報処理装置Ｑ１におけるプログラムの判断ロジックを改修する必要があり、保守性が低いといった問題がある。このような問題は、処理をマルチスレッド化させることに伴う問題である。
これに対して、本実施形態では、クライアントからのリクエストに処理モジュールの指定があることにより、このような問題を解消することができる。
このため、比較例では、例えば、新規の処理モジュールが追加されるたびに、情報処理装置Ｑ１におけるプログラムの判断ロジックを改修する必要があり、保守性が低いといった問題がある。このような問題は、処理をマルチスレッド化させることに伴う問題である。
これに対して、本実施形態では、クライアントからのリクエストに処理モジュールの指定があることにより、このような問題を解消することができる。
【0088】
［以上の実施形態について］
以上のように、本実施形態に係る情報処理装置Ｐ１では、処理をマルチスレッド化した場合に、マルチコアを十分に使用することが可能である。
本実施形態に係るプログラムＰ１では、メインスレッド１１から独立したスレッドプール４２を１つ目のサブスレッド（本実施形態では、アダプタ１２）に配置した。
以上のように、本実施形態に係る情報処理装置Ｐ１では、処理をマルチスレッド化した場合に、マルチコアを十分に使用することが可能である。
本実施形態に係るプログラムＰ１では、メインスレッド１１から独立したスレッドプール４２を１つ目のサブスレッド（本実施形態では、アダプタ１２）に配置した。
【0089】
例えば、負荷の大きい描画など一部の処理はメインスレッドでしか動作しない前提では、メインスレッドに負荷が集中する傾向がある。この前提では、スレッドプールをメインスレッド上に配置すると、スレッドプールのパフォーマンスが低下して、処理のボトルネックになり得る。
これに対して、本実施形態では、このような問題を解消することができる。
これに対して、本実施形態では、このような問題を解消することができる。
【0090】
本実施形態に係る情報処理装置Ｐ１では、マルチスレッド化のための汎用的なミドルウェアを実現することが可能である。
本実施形態に係る情報処理装置Ｐ１では、例えば、マルチスレッド化のためのコードを集約しており、開発者は情報処理装置Ｐ１に処理モジュールを渡してマルチスレッド化させる、ことが行われてもよい。
例えば、ＪａｖａＳｃｒｉｐｔでマルチスレッドを利用するためには、開発者が処理ごとにマルチスレッド化のためのコードを書く必要がある。このため、あらゆる処理をマルチスレッド化するためには、膨大なマルチスレッド化のためのコードを書く必要がある。
これに対して、本実施形態では、マルチスレッド化のためのコードを１箇所のミドルウェアに集約し、あらゆる処理がそのミドルウェアを利用することが可能である。これにより、マルチスレッド化のためのコードをあらゆる処理に繰り返し個別に書き加える場合と比べて、本実施形態では、コード量の削減を見込める。このため、上記のような問題を解消することができる。
本実施形態に係る情報処理装置Ｐ１では、例えば、マルチスレッド化のためのコードを集約しており、開発者は情報処理装置Ｐ１に処理モジュールを渡してマルチスレッド化させる、ことが行われてもよい。
例えば、ＪａｖａＳｃｒｉｐｔでマルチスレッドを利用するためには、開発者が処理ごとにマルチスレッド化のためのコードを書く必要がある。このため、あらゆる処理をマルチスレッド化するためには、膨大なマルチスレッド化のためのコードを書く必要がある。
これに対して、本実施形態では、マルチスレッド化のためのコードを１箇所のミドルウェアに集約し、あらゆる処理がそのミドルウェアを利用することが可能である。これにより、マルチスレッド化のためのコードをあらゆる処理に繰り返し個別に書き加える場合と比べて、本実施形態では、コード量の削減を見込める。このため、上記のような問題を解消することができる。
【0091】
本実施形態に係る情報処理装置Ｐ１では、完全非同期化をすることで、ユーザーの要求を満たすために、ハードウェア資源を使い切ることが可能である。
本実施形態に係る情報処理装置Ｐ１では、メインスレッド１１に対する１つ目のサブスレッド（本実施形態では、アダプタ１２）にスレッドプール４２を配置することにより、複数のコアに対する負荷分散が十分に可能となる。
本実施形態に係る情報処理装置Ｐ１では、メインスレッド１１に対する１つ目のサブスレッド（本実施形態では、アダプタ１２）にスレッドプール４２を配置することにより、複数のコアに対する負荷分散が十分に可能となる。
【0092】
本実施形態に係る情報処理装置Ｐ１では、例えば、コアの数と同じ数のスレッドを用意することで、スレッド過多によるオーバーヘッドを防止することができる。
【0093】
なお、本実施形態に係るマルチコア対応機構が利用されない場合においても、１つのスレッドの負荷はすべてのコアに分散されるが、素の状態では１つのスレッドに割り当てられるだけの計算資源しか利用できず、ハードウェアが持つ計算資源を十分に使い切ることができない。
これに対して、本実施形態に係るマルチコア対応機構を利用することで、ハードウェアが持つ計算資源を十分に使い切ることができる。
これに対して、本実施形態に係るマルチコア対応機構を利用することで、ハードウェアが持つ計算資源を十分に使い切ることができる。
【0094】
従来では、１つのメインスレッドにイニシエータとスレッドプールが配置されていたため、これらは１個のコアしか使用することができなかった。
本実施形態では、メインスレッド１１とアダプタ１２とを別にして、これらが別々のコアを使用することができ、これらが互いに通信することで、完全非同期処理が可能である。
本実施形態では、メインスレッド１１とアダプタ１２とを別にして、これらが別々のコアを使用することができ、これらが互いに通信することで、完全非同期処理が可能である。
【0095】
なお、本実施形態と特許文献１との相違点を説明しておく。
本実施形態では、サブスレッド（本実施形態では、モデル、ステート、アクション）に処理の割り当てを行うスレッドプールを１つ目のサブスレッド（本実施形態では、アダプタ１２）に固定で配置している点で、特許文献１の開示内容とは相違する。本実施形態では、この点により、処理が集中しがちなメインスレッドにスレッドプールが配置されて処理のボトルネックになるといった問題を解消することができる。
従来技術では、処理ごとに必要に応じてスレッドを生成して割り当てるが、本実施形態では、例えば、必要な処理を分解して複数の処理として固定数のサブスレッドに割り当てることにより、スレッドの生成あるいは消去などのスレッド管理で生じるオーバーヘッドを低減することができる。
本実施形態では、サブスレッド（本実施形態では、モデル、ステート、アクション）に処理の割り当てを行うスレッドプールを１つ目のサブスレッド（本実施形態では、アダプタ１２）に固定で配置している点で、特許文献１の開示内容とは相違する。本実施形態では、この点により、処理が集中しがちなメインスレッドにスレッドプールが配置されて処理のボトルネックになるといった問題を解消することができる。
従来技術では、処理ごとに必要に応じてスレッドを生成して割り当てるが、本実施形態では、例えば、必要な処理を分解して複数の処理として固定数のサブスレッドに割り当てることにより、スレッドの生成あるいは消去などのスレッド管理で生じるオーバーヘッドを低減することができる。
【0096】
ここで、本実施形態では、ＪａｖａＳｃｒｉｐｔにマルチコア対応機構を適用した場合を示したが、他のプログラミング言語に適用されてもよい。
また、本実施形態では、サブスレッドとして、モデル（Ｍｏｄｅｌ）、ステート（Ｓｔａｔｅ）、アクション（Ａｃｔｉｏｎ）が用いられる場合を示したが、これに限られず、サブスレッドとしては任意のスレッドが用いられてもよい。
また、本実施形態では、サブスレッドとして、モデル（Ｍｏｄｅｌ）、ステート（Ｓｔａｔｅ）、アクション（Ａｃｔｉｏｎ）が用いられる場合を示したが、これに限られず、サブスレッドとしては任意のスレッドが用いられてもよい。
【0097】
また、本実施形態では、メインスレッド１１とアダプタ１２とが１対１である場合を示したが、他の例として、メインスレッド１１とアダプタ１２とが１対複数であってもよく、この場合、複数のアダプタ１２を管理するメタアダプタがメインスレッド１１とアダプタ１２との間にインタフェース機能として備えられてもよい。
【0098】
なお、以上に説明した任意の装置における任意の構成部の機能を実現するためのプログラムを、コンピューター読み取り可能な記録媒体に記録し、そのプログラムをコンピューターシステムに読み込ませて実行するようにしてもよい。なお、ここでいう「コンピューターシステム」とは、オペレーティングシステムあるいは周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークあるいは電話回線等の通信回線を介してプログラムが送信された場合のサーバーあるいはクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含むものとする。当該揮発性メモリーは、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）であってもよい。記録媒体は、例えば、非一時的記録媒体であってもよい。
【0099】
また、上記のプログラムは、このプログラムを記憶装置等に格納したコンピューターシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピューターシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークあるいは電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。
また、上記のプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、上記のプログラムは、前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイルであってもよい。差分ファイルは、差分プログラムと呼ばれてもよい。
また、上記のプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、上記のプログラムは、前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイルであってもよい。差分ファイルは、差分プログラムと呼ばれてもよい。
【0100】
また、以上に説明した任意の装置における任意の構成部の機能は、プロセッサーにより実現されてもよい。例えば、実施形態における各処理は、プログラム等の情報に基づき動作するプロセッサーと、プログラム等の情報を記憶するコンピューター読み取り可能な記録媒体により実現されてもよい。ここで、プロセッサーは、例えば、各部の機能が個別のハードウェアで実現されてもよく、あるいは、各部の機能が一体のハードウェアで実現されてもよい。例えば、プロセッサーはハードウェアを含み、当該ハードウェアは、デジタル信号を処理する回路およびアナログ信号を処理する回路のうちの少なくとも一方を含んでもよい。例えば、プロセッサーは、回路基板に実装された１または複数の回路装置、あるいは、１または複数の回路素子のうちの一方または両方を用いて、構成されてもよい。回路装置としてはＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などが用いられてもよく、回路素子としては抵抗あるいはキャパシターなどが用いられてもよい。
【0101】
ここで、プロセッサーは、例えば、ＣＰＵであってもよい。ただし、プロセッサーは、ＣＰＵに限定されるものではなく、例えば、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、あるいは、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）等のような、各種のプロセッサーが用いられてもよい。また、プロセッサーは、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）によるハードウェア回路であってもよい。また、プロセッサーは、例えば、複数のＣＰＵにより構成されていてもよく、あるいは、複数のＡＳＩＣによるハードウェア回路により構成されていてもよい。また、プロセッサーは、例えば、複数のＣＰＵと、複数のＡＳＩＣによるハードウェア回路と、の組み合わせにより構成されていてもよい。また、プロセッサーは、例えば、アナログ信号を処理するアンプ回路あるいはフィルター回路等のうちの１以上を含んでもよい。
【0102】
以上、この開示の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この開示の要旨を逸脱しない範囲の設計等も含まれる。
【0103】
［付記］
（構成例１）～（構成例５）を示す。
（構成例１）～（構成例５）を示す。
【0104】
（構成例１）
互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行する情報処理装置であって、
メインスレッドと、スレッドプールを有する第１サブスレッドと、が配置され、
前記メインスレッドは、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストを前記第１サブスレッドに通知し、
前記第１サブスレッドは、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する、
情報処理装置。
互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行する情報処理装置であって、
メインスレッドと、スレッドプールを有する第１サブスレッドと、が配置され、
前記メインスレッドは、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストを前記第１サブスレッドに通知し、
前記第１サブスレッドは、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する、
情報処理装置。
【0105】
ここで、図１の例では、情報処理装置Ｐ１が情報処理装置の一例であり、メインスレッド１１がメインスレッドの一例であり、アダプタ１２が第１サブスレッドの一例であり、モデル１１１－１～１１１－ｍ、ステート１２１－１～１２１－ｍ、アクション１３１－１～１３１－ｍが第２サブスレッドの一例である。
【0106】
（構成例２）
前記処理モジュールは、処理ごとに用意され、
前記処理モジュールの中身は、フェーズごとに分割されており、
それぞれの処理ごとの１個の前記処理モジュール内に各フェーズの処理がサブモジュール化されて含まれている、
（構成例１）に記載の情報処理装置。
前記処理モジュールは、処理ごとに用意され、
前記処理モジュールの中身は、フェーズごとに分割されており、
それぞれの処理ごとの１個の前記処理モジュール内に各フェーズの処理がサブモジュール化されて含まれている、
（構成例１）に記載の情報処理装置。
【0107】
（構成例３）
前記メインスレッドは、フロントエンドまたはバックエンドにより、前記処理モジュールの前記指定および前記リクエストを受け付ける、
（構成例１）または（構成例２）に記載の情報処理装置。
前記メインスレッドは、フロントエンドまたはバックエンドにより、前記処理モジュールの前記指定および前記リクエストを受け付ける、
（構成例１）または（構成例２）に記載の情報処理装置。
【0108】
（構成例４）
前記メインスレッドは、表示画面に対してユーザーが行った操作に応じて、前記処理モジュールの前記指定および前記リクエストを受け付ける、
（構成例１）から（構成例３）のいずれか１項に記載の情報処理装置。
前記メインスレッドは、表示画面に対してユーザーが行った操作に応じて、前記処理モジュールの前記指定および前記リクエストを受け付ける、
（構成例１）から（構成例３）のいずれか１項に記載の情報処理装置。
【0109】
情報処理装置を構成するコンピューターにおいて実行されるプログラム（コンピュータープログラム）を提供することも可能である。
（構成例５）
互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行するコンピューターに、
メインスレッドが、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストをスレッドプールを有する第１サブスレッドに通知する機能と、
前記第１サブスレッドが、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する機能と、
を実現させるためのプログラム。
（構成例５）
互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行するコンピューターに、
メインスレッドが、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストをスレッドプールを有する第１サブスレッドに通知する機能と、
前記第１サブスレッドが、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する機能と、
を実現させるためのプログラム。
【符号の説明】
【0110】
１、１００１…ブラウザ内部、２、１００２…ブラウザ外部、１１、１０１１…メインスレッド、１２…アダプタ、２１、１０２１…入口部、２２、１０２２…イニシエータ、２３、１０２３…メイン回路、４１－１～４１－ｎ、１０４１－１～１０４１－ｎ…サブ回路ワーカインスタンス、４２、１０４２…スレッドプール、１１１－１～１１１－ｍ、１１１１－１～１１１１－ｍ…モデル（Ｍｏｄｅｌ）、１１２、１２２、１３２、１１１２、１１２２、１１３２…内部処理部、１２１－１～１２１－ｍ、１１２１－１～１１２１－ｍ…ステート（Ｓｔａｔｅ）、１３１－１～１３１－ｍ、１１３１－１～１１３１－ｍ…アクション（Ａｃｔｉｏｎ）、２１１、１２１１…サービス、２１２、１２１２…認可サーバー、４１１、５１１…要求元、４１２、５１２…要求先、６０１、Ｐ１、Ｑ１…情報処理装置、６２１…入出力部、６２２…記憶部、６２３…通信部、６２４…制御部、６４１…マルチコアプロセッサー
【要約】
【課題】処理をマルチスレッド化した場合に、マルチコアを十分に使用することが可能な情報処理装置を提供する。
【解決手段】互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行する情報処理装置であって、メインスレッドと、スレッドプールを有する第１サブスレッドと、が配置され、前記メインスレッドは、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストを前記第１サブスレッドに通知し、前記第１サブスレッドは、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する、情報処理装置。
【選択図】図１
【解決手段】互いに非同期であって別々のコアを並列的に使用する複数のスレッドを実行する情報処理装置であって、メインスレッドと、スレッドプールを有する第１サブスレッドと、が配置され、前記メインスレッドは、処理モジュールの指定が付されたリクエストを受け付けて、前記処理モジュールの指定および前記リクエストを前記第１サブスレッドに通知し、前記第１サブスレッドは、前記メインスレッドから前記リクエストが通知された場合、前記メインスレッドから通知された前記指定に係る前記処理モジュールに応じて第２サブスレッドに処理を依頼する、情報処理装置。
【選択図】図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】