JP5516747B2 - マルチコアプロセッサシステム、監視制御方法、および監視制御プログラム - Google Patents

マルチコアプロセッサシステム、監視制御方法、および監視制御プログラム Download PDF

Info

Publication number
JP5516747B2
JP5516747B2 JP2012537511A JP2012537511A JP5516747B2 JP 5516747 B2 JP5516747 B2 JP 5516747B2 JP 2012537511 A JP2012537511 A JP 2012537511A JP 2012537511 A JP2012537511 A JP 2012537511A JP 5516747 B2 JP5516747 B2 JP 5516747B2
Authority
JP
Japan
Prior art keywords
thread
cpu
core
monitoring
monitoring thread
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2012537511A
Other languages
English (en)
Other versions
JPWO2012046302A1 (ja
Inventor
貴久 鈴木
浩一郎 山下
宏真 山内
康志 栗原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2012046302A1 publication Critical patent/JPWO2012046302A1/ja
Application granted granted Critical
Publication of JP5516747B2 publication Critical patent/JP5516747B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30043—LOAD or STORE instructions; Clear instruction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G06F11/0724—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1405—Saving, restoring, recovering or retrying at machine instruction level
    • G06F11/1407—Checkpointing the instruction stream
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/3009—Thread control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3842—Speculative instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5018—Thread allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明は、装置に対する監視を制御するマルチコアプロセッサシステム、監視制御方法、および監視制御プログラムに関する。
従来から、コンピュータシステムの信頼性を向上させる技術の一つとして、チェックポイント−リスタートという技術が開示されている（たとえば、下記非特許文献１を参照。）。この技術は、定期的に個々のアプリケーションもしくはシステム全体の状態情報をバックアップし、障害発生時にシステムの状態をバックアップした時点に巻き戻して実行を再開する手法である。ここで状態情報とは、メモリの内容やプロセッサ内のレジスタ情報を含んだ情報である。
非特許文献１の技術は、大型機の分野で計算に数日かかるような高度なシミュレーション処理中に障害が発生した場合に、処理を一から再実行しなくても済むように考案された技術である。したがって同時に稼働しているアプリケーションプログラムは一つであり、個々のアプリケーションに対してチェックポイント−リスタートにより高信頼化を行っていた。近年では、組込システムにおいても、自動車の制御のような高度な信頼性が求められる処理を行っており、このようなシステムは障害発生時に長時間制御不能な状態を避けるために、非特許文献１の技術によって障害発生後即座に処理に復帰できるようにしている。
非特許文献１の技術を組込システムに適用する場合、組込システムでは複数のアプリケーションが連携して動作するため、連携している全てのアプリケーションに対してチェックポイント−リスタートを行うように設定することになるため、開発効率が低下する。また、組込システムは大型機に比べＣＰＵ数、メモリ量が少ないため、非特許文献１の技術を組込システムに適用する場合は、ＯＳ等により、組込システム全体に対してチェックポイント−リスタートを行っている。
また、複数のＣＰＵを搭載するマルチコアプロセッサシステムにおける障害発生時の技術としては、たとえば、スレッドの実行情報をメモリに格納し、あるＣＰＵで障害が発生した場合に、他のＣＰＵで処理を代替するという技術が開示されている（たとえば、下記特許文献１を参照。）。また、別の技術として、実行されている各処理の状態を、監視装置にて一括で監視するという技術が開示されている（たとえば、下記特許文献２を参照。）。
非特許文献１の技術と特許文献２の技術とを用いてマルチコアプロセッサシステムの障害発生時の復元処理に適用すると、特定のＣＰＵが、マルチコアプロセッサシステム全体の状態情報を保存する処理を行う技術となる（以下、「従来技術１」と称する。）。従来技術１を適用することで、マルチコアプロセッサシステムは、障害発生時、保存された状態情報を用いて、状態を復元することができる。
特開２００６−１３９６２１号公報 特開２００８−３１０６３２号公報
「Ａ Ｓｕｒｖｅｙ ｏｆ Ｃｈｅｃｋｐｏｉｎｔ／Ｒｅｓｔａｒｔ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ」［ｏｎｌｉｎｅ］、２０１０年８月２４日検索、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｆｔｇ．ｌｂｌ．ｇｏｖ／ＣｈｅｃｋｐｏｉｎｔＲｅｓｔａｒｔ／Ｐｕｂｓ／ｃｈｅｃｋｐｏｉｎｔＳｕｒｖｅｙ−０２０７２４ｂ．ｐｄｆ＞
しかしながら、上述した従来技術において、従来技術１にかかる技術では、状態情報を保存する際に、状態を変更しないよう処理を停止させなければならず、停止した結果、何も処理を行えないために、ＣＰＵの処理能力が無駄となってしまうという問題があった。
具体的には、組込システムがＣＰＵを一つ搭載するシングルコアプロセッサであれば、同時に一つの処理しか行えないため、状態情報の保存中にはアプリケーションを実行することができないため、ＣＰＵの処理能力には空きが存在しなかった。しかし、組込システムがマルチコアプロセッサであれば、１つのＣＰＵが状態情報の保存を行う間、他のＣＰＵはアプリケーションを継続できず何も処理を行えないため、処理能力が無駄となってしまうという問題があった。
本発明は、上述した従来技術による問題点を解消するため、特定のコアが状態情報を保存する間、他のコアは処理を継続できるマルチコアプロセッサシステム、監視制御方法、および監視制御プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するため、開示のマルチコアプロセッサシステムは、複数のコアにて、プロセスが実行されることが検出された場合、プロセスの実行状態とプロセス内の各監視対象スレッドの実行状態とを示す状態情報を保存する特定のスレッドを生成する。
本マルチコアプロセッサシステム、監視制御方法、および監視制御プログラムによれば、特定のコアが状態情報を保存する間、他のコアは処理を継続でき、処理能力が向上し、無停止動作を実現することができるという効果を奏する。
実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアを示すブロック図である。 本実施の形態における各ＣＰＵとプロセスの実行状態の概要を示す説明図である。 マルチコアプロセッサシステム１００の機能を示すブロック図である。 正常時における監視スレッドによる状態情報の保存が行われるタイミングを示す説明図である。 障害発生時におけるマルチコアプロセッサシステム１００の動作を示す説明図である。 障害発生時に継続可能なプロセスの概要を示す説明図である。 監視スレッド２１１による状態情報２１５の保存の概要を示す説明図である。 監視スレッド２１１による状態情報２１５を用いた状態の復元の概要を示す説明図である。 ＯＳ内部の機能を示す説明図である。 プロセス用領域の記憶内容の生成例を示す説明図である。 ＯＳによるイベント処理を示すフローチャート（その１）である。 ＯＳによるイベント処理を示すフローチャート（その２）である。 監視スレッドの動作を示すフローチャート（その１）である。 監視スレッドの動作を示すフローチャート（その２）である。
以下に添付図面を参照して、本発明にかかるマルチコアプロセッサシステム、監視制御方法、および監視制御プログラムの好適な実施の形態を詳細に説明する。
（マルチコアプロセッサシステム１００のハードウェア）
図１は、実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアを示すブロック図である。図１において、マルチコアプロセッサシステム１００は、ＣＰＵを複数搭載するＣＰＵｓ１０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）１０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０３と、を含む。また、マルチコアプロセッサシステム１００は、フラッシュＲＯＭ１０４と、フラッシュＲＯＭコントローラ１０５と、フラッシュＲＯＭ１０６と、を含む。また、マルチコアプロセッサシステム１００は、ユーザやその他の機器との入出力装置として、ディスプレイ１０７と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１０８と、キーボード１０９と、を含む。また、各部はバス１１０によってそれぞれ接続されている。
ここで、ＣＰＵｓ１０１は、マルチコアプロセッサシステム１００の全体の制御を司る。ＣＰＵｓ１０１は、シングルコアのプロセッサを並列して接続した全てのＣＰＵを指している。ＣＰＵｓ１０１は、ＣＰＵ＃０〜ＣＰＵ＃３を含む。また、ＣＰＵｓ１０１は、少なくとも２つ以上のＣＰＵを含んでいてもよい。ＣＰＵ＃０〜ＣＰＵ＃３は、それぞれ専用のキャッシュメモリを有する。また、マルチコアプロセッサシステムとは、コアが複数搭載されたプロセッサを含むコンピュータのシステムである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、本実施の形態では、シングルコアのプロセッサであるＣＰＵが並列されている形態を例にあげて説明する。
ＲＯＭ１０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ１０３は、ＣＰＵｓ１０１のワークエリアとして使用される。フラッシュＲＯＭ１０４は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）などのシステムソフトウェアやアプリケーションソフトウェアなどを記憶している。たとえば、ＯＳを更新する場合、マルチコアプロセッサシステム１００は、Ｉ／Ｆ１０８によって新しいＯＳを受信し、フラッシュＲＯＭ１０４に格納されている古いＯＳを、受信した新しいＯＳに更新する。
フラッシュＲＯＭコントローラ１０５は、ＣＰＵｓ１０１の制御に従ってフラッシュＲＯＭ１０６に対するデータのリード／ライトを制御する。フラッシュＲＯＭ１０６は、フラッシュＲＯＭコントローラ１０５の制御で書き込まれたデータを記憶する。データの具体例としては、マルチコアプロセッサシステム１００を使用するユーザがＩ／Ｆ１０８を通して取得した画像データ、映像データなどである。フラッシュＲＯＭ１０６は、たとえば、メモリカード、ＳＤカードなどを採用することができる。
ディスプレイ１０７は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ１０７は、たとえば、ＴＦＴ液晶ディスプレイなどを採用することができる。
Ｉ／Ｆ１０８は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク１１１に接続され、ネットワーク１１１を介して他の装置に接続される。そして、Ｉ／Ｆ１０８は、ネットワーク１１１と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ１０８には、たとえばモデムやＬＡＮアダプタなどを採用することができる。
キーボード１０９は、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボード１０９は、タッチパネル式の入力パッドやテンキーなどであってもよい。
図２は、本実施の形態における各ＣＰＵとプロセスの実行状態の概要を示す説明図である。図２に示すマルチコアプロセッサシステム１００は、プロセス２１０、プロセス２２０、プロセス２３０という３つのプロセスを実行している。プロセス２１０〜プロセス２３０は、特定のサービスをユーザに提供する。たとえば、プロセス２１０がＷｅｂサービスを提供するＷｅｂブラウザプロセスであり、プロセス２２０がストリーミング動画を再生する動画再生プロセスである。
プロセス２１０〜プロセス２３０は、特定のサービスをユーザに提供するために、プログラムの実行単位となるスレッドごとに機能を分割して、１つのサービスを提供する。たとえば、Ｗｅｂブラウザプロセスは、以下３つのスレッドを有する。１つ目のスレッドが、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルに従ってデータを送受信するスレッドである。続けて、２つ目のスレッドが、受信したＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データを解析するスレッドである。最後に、３つ目のスレッドが、解析した結果を用いてＨＴＭＬデータを表示するスレッドである。
スレッドの状態には、実行状態、実行可能状態、待ち状態とがあり、以下、実行状態と実行可能状態を合わせて稼働状態と呼称する。ＯＳは、稼働状態にあるスレッドを、時分割、または優先度順といったＯＳのスケジューリングポリシーに基づいて、ＣＰＵに割り当てるスレッドを選択する機能を有し、ＣＰＵに割り当ててスレッドを実行させる。実行されたスレッドが実行状態のスレッドであり、ＣＰＵに割り当てられなかったスレッドが実行可能状態のスレッドである。
また、待ち状態のスレッドは、Ｉ／Ｏの応答待ち、または、ＯＳの待機命令であるｓｌｅｅｐコマンドの実行、など、何らかの理由により一時的に実行できない状態のスレッドである。待ち状態のスレッドにおいて、実行できない状態が解消され、待ち状態から稼働状態に遷移することを起床という。
また、プロセスとは、ＯＳにおける管理単位で、一つのプロセスには複数のスレッドが属することができる。同一のプロセスに属するスレッドは、メモリなどのＯＳが管理する計算機資源を共有することができる。一方で、異なるプロセスに属するスレッド同士は資源を共有しておらず、たとえば異なるプロセスのメモリの内容を参照することはできない。このように、プロセスごとに計算機資源が独立しているため、プロセスごとに状態情報を保存することができる。
また、プロセス２１０〜プロセス２３０は、本実施の形態の特徴である監視スレッドを有する。具体的には、プロセス２１０は、監視スレッド２１１と、スレッド２１２〜スレッド２１４を含む。プロセス２２０は、監視スレッド２２１と、スレッド２２２、スレッド２２３を含む。プロセス２３０は、監視スレッド２３１と、スレッド２３２〜スレッド２３５を含む。また、ＣＰＵ＃０〜ＣＰＵ＃３におけるプロセス２１０〜プロセス２３０のスレッドの割り当てとして、ＣＰＵ＃０には、監視スレッド２１１、スレッド２２２、スレッド２３２が割り当てられている。そしてＣＰＵ＃０は、ＯＳ＃０の機能により、割り当てられたスレッドの優先度に従って監視スレッド２１１、スレッド２２２、スレッド２３２を実行する。
同様に、ＣＰＵ＃１には、スレッド２１２、監視スレッド２２１、スレッド２３３が割り当てられている。ＣＰＵ＃２には、スレッド２１３、スレッド２３４、スレッド２３５が割り当てられている。ＣＰＵ＃３には、スレッド２１４、スレッド２２３、監視スレッド２３１が割り当てられている。このように、マルチコアプロセッサシステム１００は、監視スレッドが割り当てられているＣＰＵには同一プロセス内の他のスレッドを割り当てない。
なお、監視スレッドは、プロセス生成時にプロセスを生成するＣＰＵによって生成される。監視スレッドは、定期的に実行され、自身が属するプロセス内の監視スレッド以外のスレッドを監視対象スレッドとして、監視対象スレッドの状態情報をＲＡＭ１０３に保存する。なお、監視対象スレッドは、自身が属するプロセス内の監視スレッド以外の全てのスレッドであってもよいし、一部のスレッドであってもよい。以下、単にスレッドと記述した場合、そのスレッドは監視対象スレッドである。
たとえば、監視スレッド２１１は、プロセス２１０用領域内に状態情報２１５を生成してＲＡＭ１０３に保存する。同様に、監視スレッド２２１は、プロセス２２０用領域内に状態情報２２４を生成してＲＡＭ１０３に保存する。同様に、図２では図示していないが、監視スレッド２３１も、プロセス２３０用領域内に状態情報を生成してＲＡＭ１０３に保存する。
状態情報は、具体的には、スレッドの実行状態として、初期データから変更のあったデータと、データのアドレスとが含まれたデータである。また、スレッド実行中におけるＣＰＵのレジスタの値も、状態情報に含める。さらに、プロセスの実行状態として、プロセス全体の状態が変更した場合も、状態情報に含める。
プロセス全体の状態が変更される場合として、たとえば、プロセスの優先度、プロセスが確保しているメモリ量、等が変更した場合に、状態情報に含める。監視スレッド２１１が状態情報２１５をＲＡＭ１０３に保存することで、プロセス２１０の状態と、スレッド２１２〜スレッド２１４の状態を保存することになる。同様に、監視スレッド２２１が状態情報２２４をＲＡＭ１０３に保存することで、プロセス２２０の状態と、スレッド２２２、スレッド２２３の状態を保存することになる。
（マルチコアプロセッサシステム１００の機能）
次に、マルチコアプロセッサシステム１００の機能について説明する。図３は、マルチコアプロセッサシステム１００の機能を示すブロック図である。図３では、監視スレッドに関する機能について説明を行う。マルチコアプロセッサシステム１００は、検出部３０１、生成部３０２と、設定部３０３と、通知部３０４と、保存部３０５と、復元部３０６と、保存部３０７と、復元部３０８と、を含む。この制御部となる機能（検出部３０１〜復元部３０８）は、記憶装置に記憶されたプログラムをＣＰＵ＃０〜ＣＰＵ＃３のいずれかのＣＰＵが実行することにより、その機能を実現する。記憶装置とは、具体的には、たとえば、図１に示したＲＯＭ１０２、ＲＡＭ１０３、フラッシュＲＯＭ１０４、フラッシュＲＯＭ１０６などである。
また、図３では、検出部３０１〜復元部３０６は、ＣＰＵ＃０の機能として図示されているが、ＣＰＵ＃１〜ＣＰＵ＃３の機能であってもよい。たとえば、ＣＰＵ＃１が実行するプロセスにてプロセス２２０の起動要求が発生した場合、ＣＰＵ＃１がプロセス２２０を生成し、検出部３０１はＣＰＵ＃１の機能として実行される。また、保存部３０５と復元部３０６は、監視スレッド２１１に含まれる機能であり、ＣＰＵ＃０以外の他のＣＰＵで監視スレッドが実行される場合、他のＣＰＵの機能であってもよい。たとえば、保存部３０７と復元部３０８は、ＣＰＵ＃１で実行されている監視スレッド２２１に含まれる機能である。
検出部３０１は、複数のコアにて、プロセスが実行されることを検出する機能を有する。プロセスが実行される場合として、たとえば、検出部３０１は、プロセスが生成され、実行される場合を検出してもよい。または、生成されたプロセスが実行され、ユーザ等により状態情報の保存開始要求を受けた後、再び実行開始する場合に、プロセスが実行される場合として検出してもよい。具体的には、検出部３０１は、プロセス２１０が実行されることを検出する。なお、検出されたという情報は、検出部３０１が機能したＣＰＵのレジスタ、キャッシュメモリ、ＲＡＭ１０３などの記憶領域に記憶される。
生成部３０２は、検出部３０１によってプロセスが実行されることが検出された場合、プロセスの実行状態とプロセス内の各監視対象スレッドの実行状態とを示す状態情報を保存する特定のスレッドを生成する機能を有する。特定のスレッドとは監視スレッドのことである。たとえば、生成部３０２は、プロセス２１０が実行されることが検出された場合、プロセス２１０の実行状態と監視対象スレッドとなるスレッド２１２〜スレッド２１４の実行状態とを示す状態情報２１５を保存する監視スレッド２１１を生成する。なお、監視スレッドが生成されたという情報は、生成部３０２が機能したＣＰＵのレジスタ、キャッシュメモリ、ＲＡＭ１０３などの記憶領域に記憶される。
設定部３０３は、生成部３０２によって生成された特定のスレッドを実行するコアを、監視対象スレッドを実行するコアとは異なるコアに設定する機能を有する。たとえば、設定部３０３は、監視スレッド２１１を実行するＣＰＵを、スレッド２１２〜スレッド２１４を実行するＣＰＵ＃１〜ＣＰＵ＃３とは異なるＣＰＵ＃０に設定する。
また、設定部３０３は、監視スレッドが生成される時点で全てのＣＰＵで監視対象スレッドが実行されている場合、いくつかの監視対象スレッドをマイグレーションし、監視対象スレッドが実行されていないＣＰＵを用意してもよい。なお、監視スレッドを実行するＣＰＵの情報は、設定部３０３が機能したＣＰＵ、または監視スレッドを実行するＣＰＵのレジスタ、キャッシュメモリ、ＲＡＭ１０３などの記憶領域に記憶される。
通知部３０４は、再起動を完了したコアを検出したコアから、複数のコアのうち再起動が完了したコアを除く他のコアに、プロセスおよび各監視対象スレッドを状態情報が保存された時点の状態への復元要求を通知する機能を有する。また、通知部３０４は、複数のコアのうちいずれかのコアが再起動を完了した場合に実行される。なお、再起動を完了したコアを検出したコアは、再起動を完了したコア自身であってもよいし、再起動を完了したコア以外のコアであってもよい。
たとえば、通知部３０４は、ＣＰＵ＃１で再起動を完了した場合、ＣＰＵ＃１を除くＣＰＵ＃０、ＣＰＵ＃２、ＣＰＵ＃３に、プロセス２１０およびスレッド２１２〜スレッド２１４を状態情報２１５が保存された時点の状態への復元要求を通知する。なお、復元要求を受けたＣＰＵ＃０、ＣＰＵ＃２、ＣＰＵ＃３のうち、復元を行うのは監視スレッドを実行しているＣＰＵ＃０となる。
また、通知部３０４は、再起動が完了したコアにて再起動する要因となった障害が発生したことを検出したコアから、複数のコアのうち少なくとも障害が発生したコアを除く他のコアに、各監視対象スレッドの停止要求を通知してもよい。たとえば、通知部３０４は、ＣＰＵ＃１にて障害が発生したことを検出したＣＰＵ＃０から、少なくともＣＰＵ＃０、ＣＰＵ＃２、ＣＰＵ＃３に、スレッド２１２〜スレッド２１４の停止要求を通知する。
また、通知部３０４は、あるＣＰＵが再起動完了したことをＣＰＵｓ１０１のうち再起動が完了したＣＰＵ以外の他のＣＰＵに通知してもよい。他のＣＰＵで実行している監視スレッドは、再起動完了の通知を受けた場合にプロセスおよび監視対象スレッドの状態を復元してもよい。同様に、通知部３０４は、あるＣＰＵが障害発生したことをＣＰＵｓ１０１のうち少なくとも障害が発生したＣＰＵ以外の他のＣＰＵに通知してもよい。他のＣＰＵで実行している監視スレッドは、障害発生の通知を受けた場合に監視対象スレッドの停止を行ってもよい。
保存部３０５、保存部３０７は、プロセスの実行状態とプロセス内の各監視対象スレッドの実行状態とを示す状態情報を保存する機能を有する。たとえば、保存部３０５は、プロセス２１０の実行状態と監視対象スレッドとなるスレッド２１２〜スレッド２１４の実行状態とを示す状態情報２１５を保存する。なお、保存部３０５、保存部３０７は、監視スレッドが定期的に起床された場合に機能する。
復元部３０６、復元部３０８は、通知部３０４によって復元要求が通知された場合に、プロセスおよび各監視対象スレッドを状態情報が保存された時点の状態に復元する機能を有する。たとえば、復元部３０６は、プロセス２１０と監視対象スレッドとなるスレッド２１２〜スレッド２１４を状態情報２１５が保存された状態に復元する。また、復元部３０６、復元部３０８は、通知部３０４によって停止要求および復元要求が通知された場合に、復元してもよい。
図４は、正常時における監視スレッドによる状態情報の保存が行われるタイミングを示す説明図である。時刻ｔ０から時刻ｔ１にかけて、ＣＰＵ＃０がスレッド２２２を実行し、ＣＰＵ＃１がスレッド２１２とスレッド２３３を実行し、ＣＰＵ＃２がスレッド２１３を実行し、ＣＰＵ＃３がスレッド２２３とスレッド２１４を実行する。時刻ｔ１の時点で、ＣＰＵ＃０が監視スレッド２１１を実行すると、監視スレッド２１１の機能によりＣＰＵ＃０は、ＣＰＵ＃２で実行中のスレッド２１３とＣＰＵ＃３で実行中のスレッド２１４を停止させる。スレッド２１３とスレッド２１４の停止後、監視スレッド２１１の機能によりＣＰＵ＃０は、時刻ｔ０から時刻ｔ１にかけて実行されたプロセス２１０内のスレッド２１２〜スレッド２１４が書き込んだデータの差分を取得し、保存する。
また、時刻ｔ１から時刻ｔ２にかけて、ＣＰＵ＃０が、監視スレッド２１１を実行し、ＣＰＵ＃１がスレッド２３３を実行し、ＣＰＵ＃２がスレッド２３４を実行し、ＣＰＵ＃３がスレッド２２３を実行する。時刻ｔ２の時点で、ＣＰＵ＃３が監視スレッド２３１を実行すると、監視スレッド２３１の機能によりＣＰＵ＃３は、ＣＰＵ＃１で実行中のスレッド２３３とＣＰＵ＃２で実行中のスレッド２３４を停止させる。スレッド２３３とスレッド２３４の停止後、監視スレッド２３１の機能によりＣＰＵ＃３は、時刻ｔ０から時刻ｔ２にかけて実行されたプロセス２３０内のスレッド２３３、スレッド２３４が書き込んだデータの差分を取得し、保存する。
また、時刻ｔ２から時刻ｔ３にかけて、ＣＰＵ＃０が、スレッド２２２を実行し、ＣＰＵ＃１がスレッド２１２を実行し、ＣＰＵ＃２がスレッド２１３を実行し、ＣＰＵ＃３が監視スレッド２３１を実行する。時刻ｔ３の時点で、ＣＰＵ＃１が監視スレッド２２１を実行すると、監視スレッド２２１の機能によりＣＰＵ＃１は、ＣＰＵ＃０で実行中のスレッド２２２を停止させる。スレッド２２２の停止後、監視スレッド２２１の機能によりＣＰＵ＃１は、時刻ｔ０から時刻ｔ３にかけて実行されたプロセス２２０内のスレッド２２２、スレッド２２３が書き込んだデータの差分を取得し、保存する。
また、時刻ｔ３から時刻ｔ４にかけて、ＣＰＵ＃０が、スレッド２３２とスレッド２２２を実行し、ＣＰＵ＃１が監視スレッド２２１とスレッド２１２とスレッド２３３を実行する。さらに、ＣＰＵ＃２がスレッド２１３とスレッド２３５を実行し、ＣＰＵ＃３がスレッド２１４とスレッド２２３を実行する。時刻ｔ４の時点で、ＣＰＵ＃０が監視スレッド２１１を実行すると、監視スレッド２１１の機能によりＣＰＵ＃０は、ＣＰＵ＃３で実行中のスレッド２１４を停止させる。スレッド２１４の停止後、監視スレッド２１１の機能によりＣＰＵ＃０は、時刻ｔ２から時刻ｔ４にかけて実行されたプロセス２１０内のスレッド２１２〜スレッド２１４が書き込んだデータの差分を取得し、保存する。
同様に、時刻ｔ５の時点で、監視スレッド２３１の機能によりＣＰＵ＃３は、時刻ｔ３から時刻ｔ５にかけて実行されたプロセス２３０内のスレッド２３２、スレッド２３３、スレッド２３５が書き込んだデータの差分を取得し、保存する。また、時刻ｔ６の時点で、監視スレッド２２１の機能によりＣＰＵ＃１は、時刻ｔ３から時刻ｔ５にかけて実行されたプロセス２２０内のスレッド２２２、スレッド２２３が書き込んだデータの差分を取得し、保存する。
このように、監視スレッドが保存中であっても、他のプロセス内のスレッドは実行可能であるため、ＣＰＵの処理能力を有効活用することができる。また、監視スレッドは、ＯＳによって自動的に挿入されるため、各プロセスのプログラムを改変しなくてよい。
図５は、障害発生時におけるマルチコアプロセッサシステム１００の動作を示す説明図である。図５に示すマルチコアプロセッサシステム１００では、図４の時刻ｔ１にてＣＰＵ＃１に障害が発生した場合を想定している。時刻ｔ１にてＣＰＵ＃１に障害が発生すると、ＣＰＵ＃０は、障害発生の通知を受けた監視スレッド２１１によって、スレッド２１３、スレッド２１４を停止させる。さらに、ＣＰＵ＃３が監視スレッド２３１によって、スレッド２３２〜スレッド２３５を停止させる。なお、障害発生時のスレッド停止の概要については、図６にて後述する。
時刻ｔ１からＣＰＵ＃１が再起動完了する時刻ｔ２にかけて、ＣＰＵ＃０は、スレッド２２２を実行し、ＣＰＵ＃３は、スレッド２２３を実行する。ＣＰＵ＃２は、実行可能なスレッドが存在しないため、休止する。時刻ｔ２にて、ＣＰＵ＃１の再起動が完了すると、再起動完了モードにて起床された監視スレッド２１１、監視スレッド２３１によってプロセス２１０、プロセス２３０の復元を行う。具体的には、監視スレッド２１１が、スレッド２１２〜スレッド２１４の復元を行い、監視スレッド２３１が、スレッド２３２〜スレッド２３５の復元を行う。
また、障害発生したＣＰＵ＃１は、他のＯＳの管理情報を参照し、現在稼働しているプロセスと、他のＯＳに割り当てられている監視スレッドのリストから、プロセス２２０に監視スレッドが存在しないことを判断し、監視スレッド２２１を生成する。また、時刻ｔ３にて、ＣＰＵ＃０は、監視スレッド２１１の復元処理よりスレッド２２２の優先度が高いことを検出すると、監視スレッド２１１を退避し、スレッド２２２を実行する。このように、スレッドの優先度が高ければ復元処理に割り込むことも可能である。
時刻ｔ４にてプロセス２３０の復元が完了すると、スレッド２３２〜スレッド２３５が実行可能になる。ＣＰＵ＃０〜ＣＰＵ＃３は、スレッド２３２〜スレッド２３５と他の実行可能なスレッドのうち、優先度等に基づいてスレッドを実行する。具体的には、ＣＰＵ＃０は、時刻ｔ３から引き続きスレッド２２２を実行し、ＣＰＵ＃１は、スレッド２３３を実行し、ＣＰＵ＃２は、スレッド２３４を実行し、ＣＰＵ＃３は、スレッド２２３を実行する。
続けて、時刻ｔ５にてプロセス２１０の復元が完了すると、スレッド２１２〜スレッド２１４が実行可能になる。ＣＰＵ＃０〜ＣＰＵ＃３は、スレッド２１２〜スレッド２１４と他の実行可能なスレッドのうち、優先度等に基づいてスレッドを実行する。具体的には、ＣＰＵ＃０は、スレッド２３２を実行し、ＣＰＵ＃２は、時刻ｔ４から引き続きスレッド２３４を実行し、ＣＰＵ＃３は、時刻ｔ４から引き続きスレッド２２３を実行する。
また、図５では、プロセス２１０の復元処理を監視スレッド２１１を実行するＣＰＵ＃０が行い、プロセス２３０の復元処理を監視スレッド２３１を実行するＣＰＵ＃３が行っている。このように、マルチコアプロセッサシステム１００は、監視スレッドを割り当てるＣＰＵを分散していれば、障害発生時の復元処理を一つのＣＰＵに集中させず、各ＣＰＵに分散させることが可能である。
図６は、障害発生時に継続可能なプロセスの概要を示す説明図である。図６では、ＣＰＵ＃１にて障害が発生した場合を想定している。ＣＰＵ＃１にて障害が発生すると、プロセス内の監視スレッドは他のスレッドを停止させる。続けて、ＣＰＵ＃１の再起動完了後、監視スレッドは、復元処理を行う。具体的には、ＣＰＵ＃０が監視スレッド２１１によって、スレッド２１３、スレッド２１４を停止させる。さらに、ＣＰＵ＃３が監視スレッド２３１によって、スレッド２３２、スレッド２３４、スレッド２３５を停止させる。プロセス２２０のスレッド２２２とスレッド２２３は、復元処理を行わなくてよく、継続可能である。
このように、一部のプロセスが復元動作を行わずに動作継続可能となる。一部のプロセスとは、障害が発生したＣＰＵにて監視スレッドが割り当てられていたプロセスである。たとえば、図６で示した例とは別の例として、ＣＰＵ＃０で障害が発生した場合は、プロセス２１０のスレッド２１２〜スレッド２１４が動作継続可能となる。
図７は、監視スレッド２１１による状態情報２１５の保存の概要を示す説明図である。ＲＯＭ１０２には、ＯＳ＃０がアクセスする管理情報初期値７０１と、プロセス２１０用ロードモジュールが格納されている。プロセス２１０用ロードモジュールの内部には、プロセス２１０の初期データ７０２が格納されている。なお、管理情報初期値７０１とプロセス２１０用ロードモジュールはＲＡＭ１０３、フラッシュＲＯＭ１０４等に格納されていてもよい。
続けて、ＲＡＭ１０３には、プロセス２１０用領域が確保されており、プロセス２１０用領域の内部には、ＯＳ管理情報７０３、データ７０４、状態情報２１５が格納されている。ＯＳ管理情報７０３は、ＯＳ＃１が管理するプロセスの管理情報、スレッドの管理情報が格納されている。データ７０４は、スレッド２１２〜スレッド２１４がアクセスするデータが格納されている。なお、管理情報初期値７０１〜データ７０４については、図１０にて詳細に記述する。
監視スレッド２１１の機能によりＣＰＵ＃０は、管理情報初期値７０１と初期データ７０２とＯＳ管理情報７０３とデータ７０４を参照して、状態情報２１５を出力し、ＲＡＭ１０３に格納する。具体的には、ＣＰＵ＃０は、初期データ７０２とデータ７０４を比較し、データ７０４が初期データ７０２から変更されていた場合に、状態情報２１５に出力する。同様に、ＣＰＵ＃０は、管理情報初期値７０１とＯＳ管理情報７０３を比較し、ＯＳ管理情報７０３が管理情報初期値７０１から変更されていた場合に状態情報２１５に出力する。
図８は、監視スレッド２１１による状態情報２１５を用いた状態の復元の概要を示す説明図である。ＣＰＵ＃０を除くＣＰＵ＃１〜ＣＰＵ＃３のいずれかのＣＰＵで障害が発生し、障害が発生したＣＰＵの再起動が完了した場合を想定する。この時、監視スレッド２１１の機能によりＣＰＵ＃０は、管理情報初期値７０１と初期データ７０２と状態情報２１５を参照して、ＯＳ管理情報７０３とデータ７０４を更新する。
具体的には、ＣＰＵ＃０は、初期データ７０２と状態情報２１５から、スレッド２１２〜スレッド２１４がアクセスしていたデータ７０４を、状態情報２１５が格納された時点の状態にロールバックする。同様に、ＣＰＵ＃０は、管理情報初期値７０１と状態情報２１５からプロセス２１０の状態を、状態情報２１５が格納された時点の状態にロールバックする。
なお、図７と図８で説明した、プロセスの管理情報およびスレッドの管理情報の取得、復元には、特別な権限が要求される場合もある。このような場合、マルチコアプロセッサシステム１００は、監視スレッドの生成される際に、特別な権限を監視スレッドに付与しておく。
図９は、ＯＳ内部の機能を示す説明図である。図９では、ＯＳ＃０を例にあげて説明する。ＯＳ＃０以外のＯＳ＃１〜ＯＳ＃３も、同様の機能を有する。図３では、監視スレッドに関わる機能に対して説明を行ったが、図９では、プロセスとスレッド全体に関わる機能について説明を行う。ＯＳ＃０は、プロセス生成部９０１、プロセス管理部９０２、監視スレッド機能部９０３、メインスレッド生成部９０４、スレッド生成部９０５、スレッド管理部９０６、スケジューリング部９０７を含む。また、監視スレッド機能部９０３は、検出部３０１、生成部３０２、管理部９０８、設定部３０３を含み、さらに管理部９０８は、通知部３０４を含む。
また、ＲＡＭ１０３には、ＯＳ＃０用領域と、プロセス２１０〜プロセス２３０用の領域が確保されている。図９では、プロセス２１０〜プロセス２３０用の領域のうち、プロセス２１０用領域を代表して表示している。ＯＳ＃０用領域は、プロセスリスト９０９、スレッドリスト９１０、監視スレッドリスト９１１を格納している。プロセス２１０用領域は、図７で示したように、ＯＳ管理情報７０３と、データ７０４と、状態情報２１５を格納している。さらに、ＯＳ管理情報７０３は、プロセス管理情報９１２と、スレッド管理情報９１３を格納している。
プロセス生成部９０１は、ユーザやプロセスからの要求を受け付けて、新たにプロセスを生成する機能を有する。たとえば、ＯＳ＃０がＬｉｎｕｘ（登録商標）である場合、プロセス生成部９０１は、ｉｎｉｔプロセスからの要求によりプロセスを生成する。なお、生成されたプロセスは、プロセスリスト９０９に格納される。また、プロセス生成部９０１は、生成されたプロセス用のデータ領域をＲＡＭ１０３上に確保する。
プロセス管理部９０２は、プロセス生成部９０１によって生成されたプロセスを管理する機能を有する。具体的には、プロセス管理部９０２は、プロセスの優先度、プロセスが確保するメモリサイズ、生成されたプロセスへの引数等の情報を、プロセス管理情報９１２に格納する。
監視スレッド機能部９０３は、監視スレッドに対する機能群である。具体的には、監視スレッド機能部９０３は、検出部３０１によりプロセスが生成されたことを検出し、監視スレッドを生成する。続けて、監視スレッド機能部９０３は、設定部３０３により監視スレッドの割当先ＣＰＵを設定し、通知部３０４により監視スレッドに指示を通知する。
メインスレッド生成部９０４は、プロセス生成部９０１によってプロセスが生成された場合に、プログラムコードの開始位置からメインスレッドを生成する機能を有する。プログラムコードの開始位置に存在するのは、たとえば、ｍａｉｎ（）関数の先頭である。または、Ｗｉｎｄｏｗｓ（登録商標）であれば、ＷｉｎＭａｉｎ（）関数の先頭である。メインスレッド生成部９０４は、前述の関数からメインスレッドの実行を開始するように設定する。
スレッド生成部９０５は、スレッドを生成する機能を有する。たとえば、スレッド生成部９０５は、メインスレッドから新たなスレッドの生成要求が発行された場合に、スレッドを生成する。なお、監視スレッド機能部９０３の生成部３０２、メインスレッド生成部９０４、スレッド生成部９０５にて生成されたスレッドは、スレッドリスト９１０に格納される。
スレッド管理部９０６は、生成されたスレッドを管理する機能を有する。たとえば、スレッド管理部９０６は、生成されたスレッドがどのプロセスに属するかを判断し、該当するプロセス用データ領域内のスレッド管理情報９１３に生成されたスレッドを格納する。具体的に管理する情報として、スレッド管理部９０６は、スレッドが稼働状態か待ち状態かという値、スレッドの優先度、スレッドが確保するメモリサイズ、生成されたスレッドへの引数等の情報を、スレッド管理情報９１３に格納する。
スケジューリング部９０７は、割当先ＣＰＵが設定されたスレッド群を、優先度、時分割等に基づいてＣＰＵに割り当てる機能を有する。具体的には、スケジューリング部９０７は、ＣＰＵ＃０に割り当てられると設定された監視スレッド２１１、スレッド２２２、スレッド２３２を、優先度、時分割等に基づいてＣＰＵに順次割り当てる。
管理部９０８は、監視スレッドを管理する機能を有する。具体的には、管理部９０８は、生成部３０２によって生成された監視スレッドを監視スレッドリスト９１１に格納する。さらに、管理部９０８は、監視スレッドリスト９１１に格納された監視スレッドに対し、通知部３０４によって状態情報の復元の指示を通知する。
プロセスリスト９０９、スレッドリスト９１０、監視スレッドリスト９１１、はそれぞれ、プロセス、スレッド、監視スレッドを格納するリストである。具体的には、プロセス、スレッド、監視スレッドへのポインタが格納されている。
プロセス管理情報９１２は、プロセスの優先度、プロセスが確保するメモリサイズ、生成されたプロセスへの引数等の情報である。これらの情報は、プロセスが実行している途中で変更されることもあり得る。たとえば、プロセス２１０がＷｅｂサービスを提供するＷｅｂブラウザプロセスであり、利用者等によって、複数のＷｅｂページの閲覧要求が行われ、事前に確保してあったメモリ容量では複数のＷｅｂページを閲覧できない場合を想定する。この時、マルチコアプロセッサシステム１００は、プロセス２１０のメモリ容量を拡張する。メモリ容量の拡張に成功した場合、マルチコアプロセッサシステム１００は、拡張されたメモリサイズをプロセス管理情報９１２に書き込む。
スレッド管理情報９１３は、スレッドが稼働状態か待ち状態かという値、スレッドの優先度、スレッドが確保するメモリサイズ、生成されたスレッドへの引数等の情報である。これらの情報は、プロセス管理情報９１２と同様に、実行時に変更される。たとえば、スレッドの優先度、確保するメモリサイズが変更された場合に、マルチコアプロセッサシステム１００は、変更された値をスレッド管理情報９１３に書き込む。
図１０は、プロセス用領域の記憶内容の生成例を示す説明図である。図１０では、プロセス２１０用領域が生成される様子を示している。プロセス２１０用ロードモジュールは、実行することでプロセスを生成する実行ファイルである。プロセス２１０用ロードモジュールには、図７で示した初期データ７０２以外に、プロセス情報１００１、プログラムコード１００２が格納されている。
プロセス情報１００１には、メモリサイズ、領域配置情報、プログラム開始位置等が含まれる。プログラムコード１００２には、プログラムソースを機械語に変換したコードが格納される。たとえば、プロセス２１０用ロードモジュールがＥＬＦ（Ｅｘｅｃｕｔａｂｌｅ ａｎｄ Ｌｉｎｋａｂｌｅ Ｆｏｒｍａｔ）形式であれば、プロセス情報１００１はＥＬＦヘッダ等のヘッダ部分に格納される。同様に、プログラムコード１００２は．ｔｅｘｔセクションに、初期データ７０２は．ｄａｔａセクションに格納される。
また、ＲＯＭ１０２には、ＯＳ用データの一部として、監視スレッド用ロードモジュールが格納されている。監視スレッド用ロードモジュールは、各プロセスから利用可能な共有ライブラリとなる。監視スレッド用ロードモジュールには、共有ライブラリ情報１００３、監視スレッドプログラムコード１００４、監視スレッド初期データ１００５が格納されている。共有ライブラリ情報１００３に格納される内容は、プロセス情報１００１と等しい。
具体的には、共有ライブラリ情報１００３には、監視スレッドのメモリサイズ、領域配置情報、プログラム開始位置等が格納される。監視スレッドプログラムコード１００４には、監視スレッドに対応するプログラムソースを機械語に変換したコードが格納される。監視スレッド初期データ１００５には、監視スレッドの初期値が格納されている。なお、共有ライブラリ用ロードモジュールも前述のＥＬＦ形式であれば、共有ライブラリ情報１００３はＥＬＦヘッダ等のヘッダ部分に格納される。同様に、監視スレッドプログラムコード１００４は．ｔｅｘｔセクションに、監視スレッド初期データ１００５は．ｄａｔａセクションに格納される。
初期データ７０２、プロセス情報１００１〜監視スレッド初期データ１００５を参照して、プロセス生成部９０１は、プロセス２１０用領域に展開する。具体的には、プロセス生成部９０１は、プログラムコード１００２をＲＡＭ１０３上のプログラムコード１００６に展開し、初期データ７０２をＲＡＭ１０３上のデータ７０４に展開する。同様に、プロセス生成部９０１は、監視スレッドプログラムコード１００４をＲＡＭ１０３上の監視スレッドプログラムコード１００７に展開し、監視スレッド初期データ１００５をＲＡＭ１０３上の監視スレッドデータ１００８に展開する。監視スレッドデータ１００８の内部には、状態情報２１５を保存する保存領域１００９が確保される。
図９に示した機能群と図１０に示したプロセス用領域を使用して、マルチコアプロセッサシステム１００は、状態情報の保存処理と復元処理を行う。図１１、図１２にてＯＳによるイベント処理を示し、図１３、図１４にて監視スレッドによる保存処理と復元処理の説明を行う。監視スレッドによる保存処理と復元処理は、ＯＳによるイベント処理内部の監視スレッドへの通知により実行される。
図１１は、ＯＳによるイベント処理を示すフローチャート（その１）である。ＯＳによるイベント処理は、ＣＰＵ＃０〜ＣＰＵ＃３のいずれのＣＰＵでも実行されるが、図１１、図１２では、ＯＳ＃０の機能によりＣＰＵ＃０にて実行されることを想定する。また、図１１では、ＯＳによるイベント処理のうち、新規プロセス生成のイベントと、スレッド割当先ＣＰＵ設定のイベントについて説明を行う。
ＣＰＵ＃０は、発生したイベント種別を確認する（ステップＳ１１０１）。たとえば、ＣＰＵ＃０は、イベントキューに格納されたメッセージから、最古のメッセージを取得する。イベントが新規プロセス生成である場合（ステップＳ１１０１：新規プロセス生成）、ＣＰＵ＃０は、メインスレッドを生成する（ステップＳ１１０２）。メインスレッドを生成後、ＣＰＵ＃０は、監視スレッドを生成する（ステップＳ１１０３）。監視スレッドを生成後、ＣＰＵ＃０は、監視スレッドの割当先ＣＰＵを設定する（ステップＳ１１０４）。
たとえば、ＣＰＵ＃０は、生成された監視スレッドへのポインタとスレッド割当先ＣＰＵ設定を示すイベントＩＤとを含むメッセージを生成し、イベントキューに格納する。格納されたメッセージが取得された結果、ＣＰＵ＃０によってステップＳ１１０６〜ステップＳ１１０８の処理が実行されることにより、監視スレッドの割当先ＣＰＵを設定することができる。
続けて、ＣＰＵ＃０は、メインスレッドの割当先ＣＰＵを設定し（ステップＳ１１０５）、ステップＳ１１０１の処理に移行する。なお、割当先ＣＰＵが設定されたメインスレッドと監視スレッドは、それぞれのプログラムの開始位置から実行を開始するように設定され、稼働状態となる。同時に、監視スレッドの割宛先ＣＰＵは、自身のＯＳ内の監視スレッドリストに監視スレッドの識別情報、たとえば、監視スレッドへのポインタを登録する。なお、監視スレッドの動作の詳細については、図１３、図１４にて後述する。
イベントがスレッド割当先ＣＰＵ設定である場合（ステップＳ１１０１：スレッド割当先ＣＰＵ設定）、ＣＰＵ＃０は、割当先ＣＰＵを設定するスレッドが監視スレッドか否かを判断する（ステップＳ１１０６）。監視スレッドである場合（ステップＳ１１０６：Ｙｅｓ）、ＣＰＵ＃０は、全ＣＰＵ、すなわちＣＰＵ＃０〜ＣＰＵ＃３から、割当先ＣＰＵを設定する（ステップＳ１１０７）。なお、ステップＳ１１０７の処理にて、ＣＰＵ＃０は、全ＣＰＵのうち、監視スレッドの割当数が最も少ないＣＰＵに監視スレッドを割り当てると設定してもよい。これにより、マルチコアプロセッサシステム１００は、障害発生後の復元処理を各ＣＰＵに分散して実行させることができる。
監視スレッドでない場合（ステップＳ１１０６：Ｎｏ）、ＣＰＵ＃０は、同プロセスの監視スレッドの割当先ＣＰＵ以外から割当先ＣＰＵを設定する（ステップＳ１１０８）。ステップＳ１１０７、ステップＳ１１０８の終了後、ＣＰＵ＃０は、ステップＳ１１０１の処理に移行する。
図１２は、ＯＳによるイベント処理を示すフローチャート（その２）である。図１２では、ＯＳによるイベント処理のうち、障害発生検出のイベントと、復帰通知のイベントについて説明を行う。さらに、図１２では、障害発生検出に伴う、障害発生したＣＰＵでの監視スレッドの復帰処理も併せて説明を行う。
イベントが障害発生検出である場合（ステップＳ１１０１：障害発生検出）、ＣＰＵ＃０は、障害発生したＣＰＵ＃Ｎをリブートし（ステップＳ１２０１）、障害発生の検出を障害発生していないＣＰＵに通知する（ステップＳ１２０２）。なお、Ｎは０〜３までの整数である。
また、ステップＳ１２０２にて、ＣＰＵ＃０は、障害発生の検出を、障害発生したＣＰＵ＃Ｎを含めたＣＰＵ＃０〜ＣＰＵ＃３全てに通知してもよい。ＣＰＵ＃Ｎに通知を行っても、ＣＰＵ＃Ｎは障害発生中で通知を受け取れず破棄されるため、動作に影響を及ぼさない。障害発生していないＣＰＵに通知する方法をとれば、マルチコアプロセッサシステム１００は、無駄な通信を発生させなくて済むという効果がある。また、全てのＣＰＵに通知する方法をとれば、マルチコアプロセッサシステム１００は、通知先のＣＰＵ群を設定する際に、全てのＣＰＵから障害発生したＣＰＵ＃Ｎを除くという処理を行わなくてよいという効果がある。
なお、障害発生の検出方法としては、たとえば、ソフトエラーに対してはＣＰＵ内の演算回路を冗長化し、それぞれの回路から出力される結果が異なる場合を障害発生として検出する方法が存在する。また、別の方法として、プログラムの不具合に関してはＯＳから定期的にプロセス、スレッドに対して生存確認信号を送付して、プロセスやスレッドから応答が無ければ障害発生として検出する方法が存在する。
また、前述の障害検出方法は、それぞれの方法によって、障害発生したＣＰＵが検出する場合、２つのＣＰＵが互いに障害を監視し検出する場合、複数のＣＰＵのうち１つのＣＰＵが代表して検出する場合、等がある。いずれの障害検出方法であっても、障害発生を検出したＣＰＵは、ステップＳ１２０１の処理にて、障害発生したＣＰＵをリブートする。
通知後、ＣＰＵ＃０は、自ＣＰＵに割り当てられた全監視スレッドを障害発生モードで起床し（ステップＳ１２０３）、ステップＳ１１０１の処理に移行する。なお、自ＣＰＵに割り当てられた全監視スレッドとは、監視スレッドリスト９１１に登録されているスレッドである。また、障害発生の検出を受けたＣＰＵも、監視スレッドリスト９１１に登録された全監視スレッドを障害発生モードで起床する。なお、障害発生モードで起床した監視スレッドの動作については、図１３にて後述する。
障害発生していたＣＰＵ＃Ｎは、ＣＰＵ＃０からのリブート指示により再起動し、再起動完了後、他のＣＰＵに復帰通知を送信する（ステップＳ１２０４）。送信後、ＣＰＵ＃Ｎは、監視スレッドが無いプロセスが存在するかを判断する（ステップＳ１２０５）。具体的には、ＣＰＵ＃Ｎは、他のＯＳの管理情報を参照し、現在稼働しているプロセスと、他のＯＳに割り当てられている監視スレッドリスト９１１を取得することで、監視スレッドが無いプロセスが存在するかを判断することができる。
監視スレッドが無いプロセスが存在する場合（ステップＳ１２０５：Ｙｅｓ）、ＣＰＵ＃Ｎは、監視スレッドを生成し、ＣＰＵ＃Ｎに割り当てる（ステップＳ１２０６）。監視スレッドが無いプロセスが存在しない場合（ステップＳ１２０５：Ｎｏ）、またはステップＳ１２０６の処理を終了後、ＣＰＵ＃Ｎは、復帰処理を終了する。
イベントが復帰通知である場合（ステップＳ１１０１：復帰通知）、ＣＰＵ＃０は、自ＣＰＵに割り当てられた全監視スレッドを再起動完了モードで起床する（ステップＳ１２０７）。なお、復帰通知のイベントは、ステップＳ１２０４の処理にて、ＣＰＵ＃Ｎが他のＣＰＵに復帰通知を送信したことにより発生する。また、再起動完了モードで起床した監視スレッドの動作については、図１４にて後述する。
このとき、障害発生を検出したＣＰＵ、または障害発生の検出を受けたＣＰＵは、監視スレッドによる復元の代わりに、停止していないスレッドを実行してもよい。障害発生時に停止していないスレッドは、監視スレッドによって停止させられていないことを意味しており、監視スレッドが障害発生したＣＰＵで実行されていたことを示している。監視スレッドは復元を行わなくてよいため、障害発生したＣＰＵで監視スレッドを実行していたプロセスに属するスレッドは、復元を行わずに処理を継続することができる。たとえば、ＣＰＵ＃０は、再起動完了モードで起床した監視スレッドの優先度より、復元を行わない継続可能なスレッドの優先度が高い場合は、継続可能なプロセスのスレッドを優先して処理してもよい。
図１３は、監視スレッドの動作を示すフローチャート（その１）である。監視スレッドは、ＣＰＵ＃０〜ＣＰＵ＃３のいずれのＣＰＵでも実行されるが、図１３、図１４では、ＣＰＵ＃０にて実行されることを想定する。また、図１３では、監視スレッドの障害発生時の動作、スリープのタイマ満了時の動作、再起動完了時の動作のうち、障害発生時の動作について説明を行う。なお、監視スレッドの各動作の判別方法について、ＣＰＵ＃０は、スリープから復帰したときの復帰値を参照することで、判別することができる。
ＣＰＵ＃０は、監視スレッドを起動する（ステップＳ１３０１）。以下、ＣＰＵ＃０は、監視スレッドのプログラムコードに基づいて処理を実行する。続けて、ＣＰＵ＃０は、監視スレッドが属するプロセス用領域から、初期データ７０２を取得する（ステップＳ１３０２）。初期データ７０２を取得後、ＣＰＵ＃０は、保存領域１００９を確保する（ステップＳ１３０３）。具体的には、ＣＰＵ＃０は、初期データ７０２が全て保存可能なサイズにて、保存領域１００９を確保する。確保後、ＣＰＵ＃０は、スリープの満了時間を通常の時間に設定し（ステップＳ１３０４）、スリープする（ステップＳ１３０５）。
続けて、ＣＰＵ＃０は、スリープから起床されると、障害発生モードでの起床か否かを判断する（ステップＳ１３０６）。障害発生モードでの起床である場合（ステップＳ１３０６：Ｙｅｓ）、ＣＰＵ＃０は、プロセス内の監視スレッドを除いた全スレッドを停止させる（ステップＳ１３０７）。続けて、ＣＰＵ＃０は、スリープの満了時間を「無期限」に設定し（ステップＳ１３０８）、ステップＳ１３０５の処理に移行する。なお、満了時間を無期限にすることで、タイマ満了による起床が発生しなくなる。障害発生モードでの起床でない場合（ステップＳ１３０６：Ｎｏ）についての動作は、図１４にて後述する。
図１４は、監視スレッドの動作を示すフローチャート（その２）である。図１４では、監視スレッドの動作のうち、タイマ満了時の動作と、再起動完了時の動作について説明を行う。なお、タイマ満了時の動作が状態保存の処理となり、再起動完了時の動作が状態復元の処理となる。
障害発生モードでの起床でない場合（ステップＳ１３０６：Ｎｏ）、ＣＰＵ＃０は、再起動完了モードでの起床か否かを判断する（ステップＳ１４０１）。ステップＳ１３０４の処理にて設定したタイマ満了による起床の場合（ステップＳ１４０１：Ｎｏ）、ＣＰＵ＃０は、プロセスの全スレッドを取得する（ステップＳ１４０２）。続けて、ＣＰＵ＃０は、プロセス内の監視スレッドを除いた全スレッドを停止させる（ステップＳ１４０３）。スレッドを停止させた後、ＣＰＵ＃０は、プロセスが現在使用しているプロセス用領域を取得する（ステップＳ１４０４）。
取得後、ＣＰＵ＃０は、取得したデータ領域が保存領域１００９に収まるか否かを判断する（ステップＳ１４０５）。保存領域１００９に収まらない場合（ステップＳ１４０５：Ｎｏ）、ＣＰＵ＃０は、拡張した保存領域１００９を確保する（ステップＳ１４０６）。なお、保存領域１００９に収まらない場合としては、監視対象スレッドの内部でメモリ確保命令が実行され、メモリ領域が増加して状態情報の対象となる場合、または、初期値を持たない変数に、値が設定され、状態情報の対象となる場合、等が存在する。初期値を持たない変数の具体例としては、前述のＥＬＦ形式であれば、．ｂｓｓセクションに格納された変数である。
保存領域１００９に収まる場合（ステップＳ１４０５：Ｙｅｓ）、またはステップＳ１４０６の処理終了後、ＣＰＵ＃０は、プロセスのデータ７０４の差分を保存領域１００９に保存する（ステップＳ１４０７）。続けて、ＣＰＵ＃０は、プロセス管理情報９１２の差分、スレッド管理情報９１３の差分を保存領域１００９に保存する（ステップＳ１４０８）。
なお、ステップＳ１４０２〜ステップＳ１４０８までの状態保存処理の間に、ＣＰＵ＃１〜ＣＰＵ＃３のいずれかのＣＰＵで障害が発生し、ステップＳ１２０３によるＯＳ＃０から障害発生モードによる起床命令が実行された場合を想定する。この場合、少なくても状態保存時には、ステップＳ１４０３によって該当プロセスのスレッドは停止中で障害の影響は無いため、ＣＰＵ＃０は、障害発生モードによる起床命令をペンディングしたまま状態保存処理が継続される。ステップＳ１４０８の終了後、ステップＳ１３０５の処理にて監視スレッドがスリープした際に、すぐに障害発生モードによる起床が処理される。
再起動完了モードでの起床である場合（ステップＳ１４０１：Ｙｅｓ）、ＣＰＵ＃０は、プロセスの全スレッドを取得する（ステップＳ１４０９）。なお、プロセス内の監視スレッドを除いた全スレッドは、障害発生モードでの起床時に、ステップＳ１３０７の処理によって停止している。なお、ＣＰＵ＃０は、ステップＳ１３０７の時点でスレッドを停止させず、ステップＳ１４０９の後に、スレッドを停止させてもよい。
取得後、ＣＰＵ＃０は、プロセスが使用していたプロセス用領域を取得し（ステップＳ１４１０）、取得したプロセス用領域内の保存領域１００９からプロセス管理情報９１２、スレッド管理情報９１３を復元する（ステップＳ１４１１）。続けて、ＣＰＵ＃０は、保存領域１００９からプロセスのデータ７０４を復元する（ステップＳ１４１２）。なお、データ７０４の復元の際、初期データを持たない変数について、ＣＰＵ＃０は、保存領域１００９に保存されていたデータをそのままデータ７０４にコピーする。
ステップＳ１４０８、またはステップＳ１４１２の処理後、ＣＰＵ＃０は、停止していたスレッドの動作を再開し（ステップＳ１４１３）、ステップＳ１３０４の処理に移行する。
以上説明したように、マルチコアプロセッサシステム、監視制御方法、および監視制御プログラムによれば、プロセス内に生成された監視スレッドが自身のプロセスと内部の監視対象スレッドとの状態を保存する。これにより、マルチコアプロセッサシステムは、プロセスごとに状態保存を行うため、特定のコアが状態を保存する間、他のコアは処理を継続でき、コアの処理能力を有効に活用することができる。
また、マルチコアプロセッサシステムは、監視スレッドを実行するコアを、監視対象スレッドを実行するコアとは異なるコアに設定してもよい。これにより、マルチコアプロセッサシステムは、監視スレッドが割り当てられていたコアが障害発生を起こした場合に、監視スレッドが属していたプロセスを継続することができる。したがって、障害発生を起こし、コアが再起動中であっても、他のコアによって継続可能なプロセスを実行することで、コアの処理能力を有効に活用することができる。
また、従来技術１による技術では、障害発生したコアが再起動し、再起動完了してから復元処理を行っていた。したがって、障害発生していない稼働状態であるコアは復元処理も行えず、アプリケーションの処理も行えなかった。本実施の形態にかかる技術によれば、障害発生したコアが再起動中であっても、継続可能なプロセスを実行でき、無停止動作を実現することができる。
また、マルチコアプロセッサシステムは、いずれかのコアが再起動が完了した場合、プロセスと監視対象スレッドを状態情報が保存された状態への復元要求を、再起動を完了したコアを検出したコアから再起動が完了したコア以外の他のコアに通知してもよい。これにより、マルチコアプロセッサシステムは、再起動が完了し、復元が可能となった段階で、復元処理と、継続可能なプロセスを実行することができる。
なお、継続可能なプロセスの監視スレッドは、再起動が完了したコアで実行されるため、復元要求を行わない。したがって、再起動が完了したコア以外の他のコアは、どのスレッドが継続可能であるかという判断を行わなくてよく、監視スレッドによる復元処理と、復元要求を受けていない継続可能なスレッドと、をスレッドの優先度等に基づいて実行することができる。
また、マルチコアプロセッサシステムは、復元要求が通知された場合、監視スレッドを実行するコアによって、プロセスおよび各監視対象スレッドを状態情報が保存された時点の状態に復元してもよい。これにより、各プロセスの復元をコアごとに実行できるため、たとえば、複数の監視スレッドを各コアに分散して割り当てることで、障害発生後の復元処理を分散して実行することができる。復元処理を各コアで分散して実行することで、マルチコアプロセッサシステムは、障害発生前の状態に高速に復元することができる。
また、マルチコアプロセッサシステムは、障害発生したコアを検出した場合、監視対象スレッドの停止要求を、少なくとも障害発生したコア以外の他のコアに通知し、停止要求および復元要求の通知後に、プロセスおよび各監視対象スレッドを復元してもよい。これにより、マルチコアプロセッサシステムは、障害発生したコアが再起動中であっても、継続可能なプロセスを実行することができる。さらに、継続可能なプロセスの監視スレッドは、障害発生したコアで実行されていたため、停止要求を行わない。したがって、障害発生したコア以外の他のコアは、どのスレッドが継続可能であるかという判断を行わなくてよく、停止されていないスレッドをそのまま継続可能なスレッドとして実行することができる。
また、障害発生し、再起動が完了した段階で、継続可能でないスレッドは、状態情報が保存された時点に復元される。したがって、障害発生後から再起動完了まで処理を行っても、その間の処理結果は残らず、無駄となる。また、処理結果は、障害発生し、停止したスレッドがあるために、正しい処理結果とならない可能性がある。したがって、マルチコアプロセッサシステムは、障害発生した段階で継続可能でないスレッドを停止させることで、余計な処理を行わずに済み、省電力効果を生む。
また、マルチコアプロセッサシステムの状態保存、状態復元を行う処理を特定のコアによる実行からスレッドによる実行にすることにより、スレッドの特徴を生かして状態保存、状態復元を行うことができる。具体的には、マルチコアプロセッサシステムは、スレッドの優先度を用いて、特定のプロセスの状態保存を行っている間に、特定のプロセスより優先度の高いプロセスの処理を割り込ませることができる。状態復元も同様に、特定のプロセスの状態復元を行っている間に、特定のプロセスより優先度の高いプロセスの処理を割り込ませることができる。また、復元するプロセスが複数存在する場合にも、より優先度の高いプロセスの状態復元を先行させることができる。
また、自身のスレッドにて優先度が変更可能であるＯＳであれば、監視スレッドは、状態復元を行う際に自身の優先度を通常より高めてもよい。たとえば、あるコアにて障害発生し、別のコアにて２つの監視スレッドがそれぞれのプロセスの復元処理を行う場合を想定する。このとき、一方の監視スレッドの復元処理が完了すると優先度が通常に戻り、まだ復元処理が完了していない監視スレッドの優先度が高いままとなり、復元処理を実行中の監視スレッドが優先して実行されるようになる。このように、マルチコアプロセッサシステムは、スレッドの特徴を生かし、復元処理を行うときに優先度を高めることで、復元処理を優先して実行させることも可能である。
なお、本実施の形態で説明した監視制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本監視制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本監視制御プログラムは、インターネット等のネットワークを介して配布してもよい。
＃０、＃１ ＣＰＵ
１００ マルチコアプロセッサシステム
１０３ ＲＡＭ
１１０ バス
２１０、２２０ プロセス
２１１、２２１ 監視スレッド
２１２、２２２ スレッド
２１５、２２４ 状態情報
３０１ 検出部
３０２ 生成部
３０３ 設定部
３０４ 通知部
３０５、３０７ 保存部
３０６、３０８ 復元部

Claims (6)

  1. 複数のスレッドを有するプロセスを実行する複数のコアと、
    前記複数のコアからアクセスされる記憶部と
    を有するマルチコアプロセッサシステムであって、前記複数のコアのうちの第１のコアは、
    前記第１のコアを除く第２のコアで前記プロセスが実行される場合に、前記プロセスの実行状態を含む状態情報を前記記憶部に記憶させる監視スレッドを生成し、前記監視スレッドを実行する前に、前記第２のコアに前記プロセスの実行を停止させる
    マルチコアプロセッサシステム。
  2. 前記複数のコアのうち再起動を完了したコアを検出したコアは、
    前記複数のコアのうち前記再起動が完了したコアを除く他のコアに、前記プロセスを前記状態情報が保存された時点の状態への復元要求を通知する請求項１に記載のマルチコアプロセッサシステム。
  3. 前記第１のコアは、
    前記復元要求が通知された場合、前記監視スレッドによって、前記プロセスを前記状態情報が保存された時点の状態に復元する請求項２に記載のマルチコアプロセッサシステム。
  4. 前記再起動が完了したコアにて再起動する要因となった障害が発生したことを検出したコアは、
    前記複数のコアのうち少なくとも前記他のコアに、前記プロセスの停止要求を通知し、
    前記第１のコアは、
    前記停止要求および前記復元要求が通知された場合、前記監視スレッドによって、前記プロセスを前記状態情報が保存された時点の状態に復元する請求項３に記載のマルチコアプロセッサシステム。
  5. 複数のスレッドを有するプロセスを実行する複数のコアと、前記複数のコアからアクセスされる記憶部とを有するマルチコアプロセッサシステムの監視制御方法であって、前記複数のコアのうちの第１のコアが、
    前記第１のコアを除く第２のコアで前記プロセスが実行される場合に、前記プロセスの実行状態を含む状態情報を前記記憶部に記憶させる監視スレッドを生成し、前記監視スレッドを実行する前に、前記第２のコアに前記プロセスの実行を停止させる
    処理を実行する監視制御方法。
  6. 複数のスレッドを有するプロセスを実行する複数のコアと、前記複数のコアからアクセスされる記憶部とを有するマルチコアプロセッサシステムの監視制御プログラムであって、前記複数のコアのうちの第１のコアに、
    前記第１のコアを除く第２のコアで前記プロセスが実行される場合に、前記プロセスの実行状態を含む状態情報を前記記憶部に記憶させる監視スレッドを生成し、前記監視スレッドを実行する前に、前記第２のコアに前記プロセスの実行を停止させる
    処理を実行させる監視制御プログラム。
JP2012537511A 2010-10-05 2010-10-05 マルチコアプロセッサシステム、監視制御方法、および監視制御プログラム Expired - Fee Related JP5516747B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/067469 WO2012046302A1 (ja) 2010-10-05 2010-10-05 マルチコアプロセッサシステム、監視制御方法、および監視制御プログラム

Publications (2)

Publication Number Publication Date
JPWO2012046302A1 JPWO2012046302A1 (ja) 2014-02-24
JP5516747B2 true JP5516747B2 (ja) 2014-06-11

Family

ID=45927322

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012537511A Expired - Fee Related JP5516747B2 (ja) 2010-10-05 2010-10-05 マルチコアプロセッサシステム、監視制御方法、および監視制御プログラム

Country Status (5)

Country Link
US (1) US9335998B2 (ja)
EP (1) EP2626786B1 (ja)
JP (1) JP5516747B2 (ja)
CN (1) CN103154893B (ja)
WO (1) WO2012046302A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101715759B1 (ko) * 2015-09-22 2017-03-15 한국전자통신연구원 멀티코어 환경에서의 악성코드 분석 장치 및 방법

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2518671A (en) * 2013-09-30 2015-04-01 St Microelectronics Res & Dev Multiple Processor System
TWI625622B (zh) * 2013-10-31 2018-06-01 聯想企業解決方案（新加坡）有限公司 在多核心處理器系統與運作多核心處理器系統的電腦實施方法
FR3025627B1 (fr) * 2014-09-10 2018-03-23 Bull Sas Mecanisme haute performance pour generation d'informations de journalisation d'un processus informatique
CN105446933B (zh) * 2014-09-26 2018-04-24 扬智科技股份有限公司 多核心处理器的调试系统与调试方法
CN104298563B (zh) * 2014-10-13 2018-08-21 中国外汇交易中心 一种用于管理进程的方法及系统
US9404970B2 (en) * 2014-11-14 2016-08-02 Cavium, Inc. Debug interface for multiple CPU cores
EP3286974B1 (en) * 2015-04-24 2022-04-06 Nokia Technologies Oy Common random access channel resource based coordinated random access
DE102016200777A1 (de) * 2016-01-21 2017-07-27 Robert Bosch Gmbh Verfahren und Vorrichtung zum Überwachen und Kontrollieren quasi-paralleler Ausführungsstränge in einem ereignisorientierten Betriebssystem
JP6819061B2 (ja) * 2016-03-28 2021-01-27 日本電気株式会社 情報処理装置、プロセス切り替え方法及びプログラム
JP2018092571A (ja) * 2016-04-20 2018-06-14 株式会社リコー 電子装置、再起動方法およびプログラム
US10591976B2 (en) * 2016-11-10 2020-03-17 Apple Inc. Methods and apparatus for providing peripheral sub-system stability
US20190243698A1 (en) * 2018-02-02 2019-08-08 Robert Bosch Gmbh Electronic Control Unit for Flexible Replacement of Replaceable Components in a Vehicle
JP7087420B2 (ja) 2018-02-02 2022-06-21 富士通株式会社 処理プログラム、およびイベント処理方法
US11055366B2 (en) * 2018-06-04 2021-07-06 Genetec Inc. Electronic evidence transfer
JP2020009015A (ja) * 2018-07-04 2020-01-16 日本電産サンキョー株式会社 情報処理システム、情報処理装置、及び情報処理方法
DE102020205146A1 (de) * 2020-04-23 2021-10-28 Robert Bosch Gesellschaft mit beschränkter Haftung Vorrichtung und Verfahren zur Steuerung eines technischen Systems
CN113032207A (zh) * 2021-03-02 2021-06-25 广州虎牙科技有限公司 应用进程的监控方法、装置、电子设备及存储介质
JP7270278B2 (ja) * 2021-05-19 2023-05-10 株式会社ユニバーサルエンターテインメント 遊技機
CN115017004B (zh) * 2021-12-27 2023-07-07 荣耀终端有限公司 进程监控方法及电子设备
CN117112486A (zh) * 2023-08-09 2023-11-24 协创芯片(上海)有限公司 一种低功耗Soc芯片

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3253883B2 (ja) * 1997-01-31 2002-02-04 株式会社東芝 プロセスリスタート方法及びプロセス監視装置
JP2001331330A (ja) * 2000-05-19 2001-11-30 Fujitsu Ltd プロセス異常検知及び復旧システム
US7373548B2 (en) * 2003-08-29 2008-05-13 Intel Corporation Hardware recovery in a multi-threaded architecture
US9189230B2 (en) * 2004-03-31 2015-11-17 Intel Corporation Method and system to provide concurrent user-level, non-privileged shared resource thread creation and execution
US9038070B2 (en) * 2004-09-14 2015-05-19 Synopsys, Inc. Debug in a multicore architecture
JP2006139621A (ja) 2004-11-12 2006-06-01 Nec Electronics Corp マルチプロセッシングシステム及びマルチプロセッシング方法
US7472266B2 (en) * 2005-12-30 2008-12-30 Intel Corporation Fault resilient boot in multi-processor systems
JP2008003691A (ja) * 2006-06-20 2008-01-10 Hitachi Ltd 計算機のプロセス回復方法、チェックポイントリスタートシステム
JP4689572B2 (ja) * 2006-10-13 2011-05-25 日本電信電話株式会社 サーバ再開方法、サーバ再開装置、サーバ再開プログラム
JP5098456B2 (ja) 2007-06-15 2012-12-12 村田機械株式会社 プロセス状態監視装置
US7516365B2 (en) * 2007-07-27 2009-04-07 Sun Microsystems, Inc. System and method for split hardware transactions
US20100274972A1 (en) * 2008-11-24 2010-10-28 Boris Babayan Systems, methods, and apparatuses for parallel computing
US8881157B2 (en) * 2009-09-11 2014-11-04 Empire Technology Development Llc Allocating threads to cores based on threads falling behind thread completion target deadline
US8832663B2 (en) * 2009-11-23 2014-09-09 International Business Machines Corporation Thread serialization and disablement tool
US8549523B2 (en) * 2009-11-23 2013-10-01 International Business Machines Corporation Performing runtime analysis and control of folding identified threads by assuming context of another thread and executing in lieu of another thread folding tool
US20110161961A1 (en) * 2009-12-29 2011-06-30 Nokia Corporation Method and apparatus for optimized information transmission using dedicated threads
US8612730B2 (en) * 2010-06-08 2013-12-17 International Business Machines Corporation Hardware assist thread for dynamic performance profiling
US8464104B2 (en) * 2010-09-10 2013-06-11 International Business Machines Corporation Mobility of versioned workload partitions
US8589922B2 (en) * 2010-10-08 2013-11-19 International Business Machines Corporation Performance monitor design for counting events generated by thread groups
WO2012124077A1 (ja) * 2011-03-16 2012-09-20 富士通株式会社 マルチコアプロセッサシステムおよびスケジューリング方法
US9152510B2 (en) * 2012-07-13 2015-10-06 International Business Machines Corporation Hardware recovery in multi-threaded processor
US9063906B2 (en) * 2012-09-27 2015-06-23 International Business Machines Corporation Thread sparing between cores in a multi-threaded processor
US9280388B2 (en) * 2013-01-22 2016-03-08 Oracle International Corporation Method and apparatus for efficient scheduling of multithreaded programs
US9495159B2 (en) * 2013-09-27 2016-11-15 Intel Corporation Two level re-order buffer
US9678851B2 (en) * 2013-10-14 2017-06-13 International Business Machines Corporation Continuous monitoring and analysis of software events
KR101671372B1 (ko) * 2014-01-16 2016-11-16 한국전자통신연구원 멀티코어 기반 병렬 프로그램의 경합 탐지를 위한 확장적 감시 장치 및 방법
US9652247B2 (en) * 2014-01-24 2017-05-16 Nec Corporation Capturing snapshots of offload applications on many-core coprocessors

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101715759B1 (ko) * 2015-09-22 2017-03-15 한국전자통신연구원 멀티코어 환경에서의 악성코드 분석 장치 및 방법
US9965631B2 (en) 2015-09-22 2018-05-08 Electronics And Telecommunications Research Institute Apparatus and method for analyzing malicious code in multi-core environment using a program flow tracer

Also Published As

Publication number Publication date
EP2626786B1 (en) 2016-04-20
EP2626786A1 (en) 2013-08-14
US9335998B2 (en) 2016-05-10
EP2626786A4 (en) 2015-04-01
WO2012046302A1 (ja) 2012-04-12
JPWO2012046302A1 (ja) 2014-02-24
CN103154893B (zh) 2016-05-04
US20130238882A1 (en) 2013-09-12
CN103154893A (zh) 2013-06-12

Similar Documents

Publication Publication Date Title
JP5516747B2 (ja) マルチコアプロセッサシステム、監視制御方法、および監視制御プログラム
US8990617B2 (en) Fault-tolerant computer system, fault-tolerant computer system control method and recording medium storing control program for fault-tolerant computer system
JP5966927B2 (ja) 分散処理装置及び分散処理システム
WO2012093488A1 (ja) スケジューリング方法、およびマルチコアプロセッサシステム
JP5780292B2 (ja) 同期方法、マルチコアプロセッサシステム、および同期システム
US20140298333A1 (en) Migration processing program, migration method, and cloud computing system
CN112395050B (zh) 一种虚拟机备份方法、装置、电子设备及可读存储介质
JP6123626B2 (ja) 処理再開方法、処理再開プログラムおよび情報処理システム
CN111400086B (zh) 虚拟机容错的实现方法和系统
Chen et al. Replication-based fault-tolerance for large-scale graph processing
US10795708B1 (en) Transparent disk caching for virtual machines and applications
JP4992740B2 (ja) マルチプロセッサシステム、障害検出方法および障害検出プログラム
JP5708450B2 (ja) マルチコアプロセッサシステム、レジスタ利用方法、およびレジスタ利用プログラム
JP6677021B2 (ja) 情報処理装置、情報処理方法、プログラム
JP5780296B2 (ja) スレッド処理方法、およびスレッド処理システム
CN114756355B (zh) 一种计算机操作系统的进程自动快速恢复的方法和装置
JP5704176B2 (ja) プロセッサ処理方法、およびプロセッサシステム
JP2010231295A (ja) 解析システム
JP5867630B2 (ja) マルチコアプロセッサシステム、マルチコアプロセッサシステムの制御方法、およびマルチコアプロセッサシステムの制御プログラム
CN107315624B (zh) 信息处理方法及虚拟化管理器
JP2010231296A (ja) 並列計算システム
JP2003330737A (ja) 計算機システム
JP2020129329A (ja) 情報処理実行制御装置、情報処理実行制御システム、情報処理実行制御方法、及び、情報処理実行制御プログラム
JP5731665B2 (ja) 計算機システム及び複製制御方法
JP2009116885A (ja) コンピュータ及び制御方法

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140304

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140317

R150 Certificate of patent or registration of utility model

Ref document number: 5516747

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees