JP3209748B2 - 外部事象を処理できるフォールトトレラントコンピュータシステム - Google Patents

外部事象を処理できるフォールトトレラントコンピュータシステム

Info

Publication number
JP3209748B2
JP3209748B2 JP51335893A JP51335893A JP3209748B2 JP 3209748 B2 JP3209748 B2 JP 3209748B2 JP 51335893 A JP51335893 A JP 51335893A JP 51335893 A JP51335893 A JP 51335893A JP 3209748 B2 JP3209748 B2 JP 3209748B2
Authority
JP
Japan
Prior art keywords
task
backup
message
transmitted
main
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
JP51335893A
Other languages
English (en)
Other versions
JPH07503334A (ja
Inventor
グリーソン，バリー・ジョン
Original Assignee
ユニシス・コーポレイション
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 ユニシス・コーポレイション filed Critical ユニシス・コーポレイション
Publication of JPH07503334A publication Critical patent/JPH07503334A/ja
Application granted granted Critical
Publication of JP3209748B2 publication Critical patent/JP3209748B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare 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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • 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/86—Event-based monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Retry When Errors Occur (AREA)
  • Multi Processors (AREA)

Description

【発明の詳細な説明】 発明の背景 この発明は、データ処理システムにおいてフォールト
トレランスを与えるための改良された手段および方法に
関する。
コンピュータシステムの速度、パワーおよび複雑さが
増すにつれて、ハードウェアおよび／またはソフトウェ
アの故障の際にシステムが「ダウンする」のを防ぐため
に、このようなシステムにフォールトトレランスを与え
ることがますます重要となっている。しかしながら、コ
ンピュータシステムにフォールトトレランス能力を与え
ることは高価であるとともに、かなりの性能の代償をも
たらすことがわかった。
データ処理システムにおいてフォールトトレランスを
達成する基本的な方法は、各タスク（プロセスとも呼ば
れる）にバックアップタスクを与え、主タスクが故障し
てもバックアップタスクが自動的にリカバーして実行を
続けられるようにするものである。たとえば、主タスク
およびそのバックアップタスクは、一方が故障しても他
方で実行が続くように相互結合された１対の同時実行CP
U（中央処理装置）を用いて与えてもよい。このような
二重のハードウェアを設けることは、特に、同時に動作
する二重ハードウェアを、さらなるデータ処理力を与え
るのには使用できないので、フォールトトレランスを達
成するには非常に高価な方法であることが認められるで
あろう。
ハードウェアを二重にすることを避ける既知のアプロ
ーチの１つとして、主タスクには第１のCPUを設け、バ
ックアップタスクには第２のCPUを設けて、主タスクが
故障した場合のみにバックアップがリカバーし、実行を
続けるように活性となるというものがある。それまで
は、バックアップCPUは他の処理を行なえる。主プロセ
スが故障した場合にはバックアッププロセスが必ずそれ
を引き継ぐことができるように、この既知のアプローチ
では、主データ空間が変わるときには常にチェックポイ
ント動作が起こる。このチェックポイント動作は主タス
クの状態およびデータ空間をバックアップのそれにコピ
ーし、そのため主タスクが故障しても、バックアップタ
スクが実行を続けることができる。しかしながら、この
アプローチで必要とされる頻繁なチェックポイント動作
は、性能に悪影響を与え、追加される計算力のかなりの
部分を使ってしまう。
別の既知のアプローチが、米国特許番号第4,590,544
号に開示されている。このアプローチもまたチェックポ
イント動作を用いるが、チェックポイントの頻度をかな
り減じるフォールトトレラントアーキテクチャを使用す
るという利点をもたらす。しかしながら、このアプロー
チには、メッセージが主およびバックアッププロセッサ
に実質的に同時に伝送されることを必要とする点におい
て本質的に同期しているメッセージ伝送プロトコルを必
要とする欠点がある。さらに、上述の特許に開示されて
いるアプローチには、アトム的伝送を必要とする別の欠
点があり、受信タククおよびすべてのバックアップがメ
ッセージを受け取ることができることを示さなければ、
タスクによるメッセージの伝送が許可されない。さら
に、すべての受信タスクおよびバックアップがメッセー
ジの受信に肯定応答するまで、受信タスクは進行を許可
されない。これらのメッセージ伝送プロトコルの要件
が、システムをさらに複雑にする制約をもたらし、かつ
性能にかなりの悪影響を与える。
上述の特許第4,590,554号に開示されるのと同様のア
プローチが、エー・ボルグ（A.Borg）らによる、オペレ
ーティングシステム原理に関する第９回シンポジウム
（Ninth Symposium on Operating Systems Principle
s）（ブレトン・ウッズ（Breton Woods）、N.H.、1983
年10月）、1983年、ニューヨーク、ACM、90−99頁の論
文「フォールトトレランスを支持するメッセージシステ
ム」（A Message System Supporting Fault Toleranc
e）および、エー・ボルグらのコンピュータシステムに
関するACMトランザクション（ACM Transactions on Com
puter Systems）,Vol.7,No.1、1989年２月、１−24頁の
論文「UNIXでのフォールトトレランス」（Fault Tolera
nce Under UNIX）に説明される。
上述の特許第4,590,554号に開示されるものよりもか
なり改良されたアプローチが、私の上述の特許出願連続
番号第07/521,283号に説明され、これはメッセージ伝送
上の制約を減じながら、特許第4,590,554号の利点を有
するフォールトトレラントデータ処理システムを提供し
ている。より特定的には、連続番号第07/521,283号のシ
ステムは、フォールトトレラント動作を行なうのに伝送
のアトム性も同時性も要求せず、それによって性能が向
上する。連続番号第07/521,283号のこのシステムは、以
下フレキシブル・フォールト．トレラント・システムと
称する。
発明の概要 この発明の広い目的は、データ処理システムにおいて
フォールトトレランスを達成するための改良された手段
および方法を提供することである。
この発明のより特定的な目的は、上述の特許第4,590,
550号に開示されるものと類似した、またはフレキシブ
ル・フォールト・トレラント・システムに類似したフォ
ールトトレラントシステムを提供することであり、外部
事象が起こるときをタスクがほとんど、または全く制御
できない状態、および、タスクの振舞がこの外部事象が
発生するときに依存して異なる可能性のある状態におい
て、プロセス（タスク）がこの制御されない外部事象に
適応することができる。
この発明のさらに別の目的は、上述の目的に従って、
比較的簡単かつ経済的に実現されるフォールトトレラン
トデータシステムを提供することである。
この発明の具体的な好ましい実施例において、メモリ
への「書込」参照をカウントするためにさらなるハード
ウェアが設けられる、フレキシブル・フォールト・トレ
ラント・システムに類似したフォールトトレラントシス
テムが提供される。この「書込」メモリ参照データカウ
ントは、タスクのコンテキストの一部として扱われる。
外部事象が発生する回数は、そのバックアップによるタ
スクのリカバリ中に、表示されない外部事象の各々が、
主タスクに渡されるのと同じ論理的ポイントでバックア
ップに再び渡されるようにこのメモリ参照「書込」デー
タカウントと関連づけられ、それによってこのような外
部事象の発生にもかかわらず、故障したタスクが適切に
リカバーすることを確実とする。
この発明の特定的な性質、ならびにその他の目的、特
徴、利点および用途は、添付の図面とともに、好ましい
実施例の以下の詳細な説明から明らかになるであろう。
図面の簡単な説明 図１は、米国特許番号第4,590,554号からの先行技術
のフォールトトレラントシステムのブロック図である。
図２は、米国特許番号第4,590,554号からの、図１の
タスクプロセッサの１つを一般化したブロック図であ
る。
図３は、フォールトトレラントシステムの好ましい実
施例のブロック図である。
図3Aは、図３のタスクを一般化して表示したものであ
る。
図４−９は、図３の好ましい実施例の種々の動作例を
示すフローチャートである。
詳細な説明 同様の番号および記号は、図面を通して同様の要素を
示す。
米国特許番号第4,590,554号の概要（図１および２） ここに述べるこの発明の貢献および詳細な説明を理解
するにあたって、その内容がここに引用によって援用さ
れる上述の米国特許番号第4,590,554号に開示される実
施例の構成および動作の概要をまず述べることが有用で
あろう。この目的で、特許第4,590,554号の図１および
２にそれぞれ相当するこの発明の図１および２を参照す
る。
図１は、主プロセッサ11および21、そのそれぞれの関
連したバックアッププロセッサ12および22、共通メモリ
CM、ならびに相互接続メッセージバスMBを含む並列コン
ピュータシステムPCSを示す。
図２は、図１のプロセッサの１つを示し、読出カウン
タRC、書込カウンタWC、メッセージキューMQおよびプロ
セッサの残りRPを含む。主プロセッサ（11または21）は
読出カウンタRCのみを用い、バックアッププロセッサ
（12または22）は、書込カウンタWCのみを用いる。RCお
よびWCの双方とも、動作の開始時にゼロに初期化され
る。動作中に、各主プロセッサの読出カウンタRCは、そ
のそれぞれの主プロセッサ（11または21）がそのメッセ
ージキューMQからプロセッサの残りRPに読出したメッセ
ージ数のカウントを累積する。各バックアッププロセッ
サ（12または22）の書込カウンタWCは、そのそれぞれの
主プロセッサ（11または21）によって伝送されたメッセ
ージ数のカウントを累積する。
米国特許番号第4,590,554号に開示される実施例に関
して説明される動作では、第１のプロセス（タスク）が
主プロセッサ11で実行され、第２のプロセス（タスク）
は主プロセッサ21で実行される。主プロセッサ（たとえ
ば11）によって伝送された各メッセージは、３つのプロ
セッサ、すなわち、宛先主プロセッサ（たとえば21）、
宛先プロセッサ21のバックアッププロセッサ22、および
伝送プロセッサ11のバックアッププロセッサ12に実質的
に同時に送られる。これら３つのプロセッサすべてがメ
ッセージを受け取り、かつそのように肯定応答したとき
のみ、メッセージの伝送が完了したとみなされる（アト
ム性）。宛先プロセッサ21およびそのバックアッププロ
セッサ22の双方は、メッセージをそのそれぞれのメッセ
ージキューMQにロードする。しかしながら、伝送プロセ
ッサのバックアッププロセッサ12は、受け取ったメッセ
ージを単にその書込カウンタWCを増分するためのみに使
用し、その後そのメッセージは捨てられる。主プロセッ
サは、受け取ったメッセージを処理するごとに、その読
出カウンタを１だけ増分する。
バックアッププロセッサのメッセージMQ内のメッセー
ジの数が多くなり過ぎると、米国特許番号第4,590,554
号の実施例では、主プロセッサとバックアッププロセッ
サとの間でチェックポイン動作が自動的に開始される。
チェックポイント動作は、バックアッププロセスをその
主プロセスと同じ状態にもたらし、これはそのデータ空
間を同一にすることを含む。さらに、チェックポイント
動作によって、主プロセスは、累積された読出カウント
をそのバックアッププロセスに送った後、その読出カウ
ンタRCをゼロにする。この読出カウントRCは、開始時か
らまたは最後のチェックポイント動作からの、そのメッ
セージキューMQから主プロセスによって読出されたメッ
セージの数を示すことに留意されたい。バックアッププ
ロセスは、チェックポイント動作の間にこの読出カウン
トを用いて、そのメッセージキューMQから同じ数のメッ
セージを捨てる。このように、主プロセスが万一故障し
ても、バックアッププロセスは、主プロセスによって既
に処理されたメッセージは処理しない。
上述の特許番号第4,590,554号の実施例の動作の一例
として、主プロセッサ21が故障すると仮定する。このよ
うな場合、そのバックアッププロセッサ22は最後のチェ
ックポイントの点から（または開始時から）出発し、そ
のメッセージキューMQ（図２）内のメッセージを処理し
始める。これらは、主プロセッサ21に送られたものと同
じメッセージである。適切なリカバリを施すために、バ
ックアッププロセッサ22は、その故障した主プロセッサ
21が故障前に伝送したいかなるメッセージも再び伝送し
ないようにされる。これは、バックアッププロセッサ22
の書込カウンタWCの累積されたカウントを用いることに
よって達成され、これは、そのそれぞれの主プロセッサ
21によって送られたメッセージの数に対応することに留
意されたい。出力メッセージがバックアッププロセッサ
22によってリカバリ中に生成されるごとに、この書込カ
ウンタWCは１だけ減分される。バックアッププロセッサ
22は、書込カウンタWCがゼロに達して初めて、メッセー
ジを伝送することを許可される。バックアッププロセッ
サ22は、このようにその故障した主プロセッサ21の状態
にもたらされ、故障した主プロセッサ21が実行していた
プロセス（タスク）の処理を引き継ぐことができる。
フレキシブル・フォールト・トレラント・システムの説
明（図３−９） まず、フォールトトレラント動作に関係のある幾つか
の点の考察を行なうことが有用であろう。
タスクがメッセージを受け取り、その直後に故障した
場合、タスクがメッセージを受け取る直前に故障したか
のように進行してもよい。
実際に、故障した後も永続するある動作、たとえばタ
スクがディスクまたは端末に書込んだり、またはメッセ
ージをその故障を切り抜けた別のタスクに送る等をタス
クが実行するまではタスクがメッセージを受け取る前に
故障したかのように進めることにしてもよい。CPUの故
障によって、そのCPU上で動いているすべてのタスクの
故障が起こるので、同じCPU内で動作している別のタス
クに送られるメッセージは、受信側がそれに応じて「永
続的動作」を行なわない限り、CPUの故障の後も永続す
る動作ではない。
より一般的には、CPUが故障すると、そのCPUの外部の
あらゆる装置およびタスク（他のCPU、ディスク、端末
等）が、その故障時のCPUの状態について一致している
ことが重要である。その一致した状態が、故障時のCPU
の実際の状態であるかどうかは重要でない。
故障したCPUが実際に多数の付加的な処理ステップを
実行したとしても、永続的動作を全く実行していないの
であれば、その場合にはバックアップは適切にリカバー
するためにそれらを考慮する必要はない。このように、
リカバリは一致した状態で始まり、故障時の実際の状態
まで、およびそれを越える処理ステップを再計算する。
実際に、リカバリで元のCPUとは異なる処理ステップを
実行するかもしれないが、これは元の処理ステップのど
の結果も見えないので、上述の考察からわかるように、
ユーザには見えない。
図３に示されるように、３つの主タスク31、41および
51が、CPU Ａ上で実現され、互いに、そして出力CPUキ
ューと、内部メッセージ網35を介して通信するが、これ
は従来のバス構成であってもよい。CPU Ａに３つの主
タスク31、41および51しか図示されていないが、さらな
るタスクが設けられてもよいことを理解されたい。
図３にまた示されるように、CPU Ａのタスク31に
は、CPU Ｂで実現されるバックアップタスク32が備え
られ、CPU Ａのタクク41には、CPU Ｃで実現されるバ
ックアップタスク42が備えられ、CPU Ａのタスク51に
は、CPU Ｄで実現されるバックアップタスク52が備え
られる。同じCPUで２つ以上のバックアップタスクが実
現されてもよい。各CPUは、内部通信網35に結合される
メモリＭを含み、これはCPUで実現される各タスクにつ
いてそれぞれデータ空間を与える。CPU Ｂ、Ｃおよび
Ｄの各々は、（CPU Ａのように）CPUキューを有しても
よいが、これは、CPUがバックアップタスクしか含まな
ければ、使用されない。CPU Ａ、Ｂ、ＣとＤとの間の
通信は、外部通信網45によってもたらされ、これは上述
の特許番号第4,590,554号のメッセージBUS MBで示され
るような、当該分野では既知である種々の形態をとって
もよい。図３に示されるように、周辺機器Ｐがまた、I/
Oを介して外部通信網45に結合される。通信機器Ｐは、
たとえば１つまたはそれ以上のディスクドライブを含ん
でもよい。
各主タスク31、41、51およびそのそれぞれのバックア
ップタスク32、42、52を、より詳細に検討する。当業者
には、以下の説明より、さらにタスクおよびCPUを備え
た異なる構成も使用できることが理解されるであろう。
ここで検討される実施例の目的のために、すべてCPU
Ａにある主タスク31、41、51は、内部通信網35を介して
互いからのみメッセージを受け取り、そのそれぞれのCP
U Ａの外からは受け取らないと仮定する。タスク31、4
1、51からCPU Ａの外へのメッセージ分配は、外部通信
網45を介して、CPU Ｂ、Ｃ、Ｄのそれぞれのバックア
ップタスク32、42、52に対してのみと仮定する。当業者
には明らかであるように、ここで開示されるタスクの構
造および動作は、そのそれぞれのCPUによって実現され
る。
図3Aに示されるように、各タスク（31、32、41、42、
51、52）は、メッセージを受け取りかつ記憶するための
メッセージキューMQを含む。各タスクはまた、読出カウ
ンタRCと書込カウンタWCとを含む。タスクが主タスク
（図３の31、41、51）であれば、読出カウンタRCのみが
使用され、その用途は、そのメッセージキューMQから主
タスクによって読出されるメッセージ数のカウントを累
積することである。逆に、タスクがバックアップタスク
（図３において32、42および52）であれば、書込カウン
タWCのみが使用され、その用途は、そのそれぞれの主タ
スク（図３において31、41、51）によって送られるメッ
セージ数を累積することである。
メッセージキューMQ、書込カウンタWC、および書込カ
ウンタWCの動作は、典型的には上述の特許番号第4,599,
554号に関してここで先に説明したものであってもよ
い。バックアップタスクによるリカバリおよびチェック
ポイント動作もまた同様に、典型的には、先に検討した
「考察」を活用することから起こる、ここで指摘した違
いを除いては、上述の特許番号第4,590,554号で説明さ
れるとおりであってもよい。図３および3Aに示される実
施例の動作を、以下により詳細に説明する。上述のよう
に、CPU Ａの主タスク31、41、51は、内部通信網35を
介して互いにのみ通信し、それぞれのバックアップタス
ク32、42、52が、それぞれCPU Ｂ、ＣおよびＤに設け
られると仮定する。主タスク（31、41または51）によっ
て送られるメッセージの各々は、典型的には関連するタ
スクアドレスを含み、これを、示されたタスクにメッセ
ージを送るために内部通信網35が使用する。バックアッ
プタスク（CPU Ｂ、Ｃ、Ｄにおいてそれぞれ32、42、5
2）に送られなくてはならないメッセージは、内部通信
網35によって、先入れ先立し方式（FIFO）で動作する、
出力CPUキューに送られる。
重要な特徴は、ここで先に考察したことを利用して、
同じCPUの別のタスクにメッセージを伝送する主タスク
は、この別のタスクおよびそれぞれのCPUキューへのメ
ッセージの分配が確実に行なわれる限り、CPUキューに
おける対応するバックアップメッセージがバックアップ
タスクにまだ送られていなくても、その処理を直ちに継
続することができることであり、これによって処理を高
速にする。上述の特許番号第4,590,554号とは異なり、
これらのバックアップメッセージは、外部通信網45を介
して適切なバックアップタスクに、そうすることが好都
合であるときに送られてもよい。このことは、主タスク
が永続的動作を行なわない限り当てはまり、永続的動作
とは、タスクがディスクまたは端末に書込んだり、また
は故障を切り抜けた別のタスクにメッセージを送るとき
等の、故障後も永続する、主タスクによって行なわれる
動作であることに留意されたい。
主タスク（31、41または51）が永続的動作を行なう必
要がある場合には、主タスクはまず出力CPUキューをチ
ェックし、タスクによって既に処理されたメッセージに
対応するバックアップメッセージのすべてがバックアッ
プに送られたかどうかを決定する。これらの必要なメッ
セージのすべてが確実に送られていれば、タスクは永続
的動作を実行し、処理を継続する。もしそうでなけれ
ば、主タスクはバックアップに必要な分配を始め、その
後、主タスクは永続的動作を実行し、処理を継続する。
タスクは、次の永続的動作を実行する必要があるときま
で、そのバックアップに処理されたメッセージを送るこ
とに関係なく、処理を継続してもよい。伝送されるメッ
セージの分配を確実にするために、たとえば、肯定応答
信号、ハンドシェイキング、エコー、誤り検出、または
他の適切な手段等を用いること等の、当該分野では周知
である種々の技術を用いてもよいことを理解されたい。
図３の動作を例示する種々の例を次に挙げる。これら
の例は、図４−９のフローチャートにおいて要約された
形で示される。これらのフローチャートはまた、各例に
ついて含まれる状態表に対応するフローの時点を示す。
さらに、これらの例および表を上述の特許番号第4,590,
554号で挙げられているものと比較することが有用であ
ろう。
以下に示す例は、CPU Ａの主タスク31および41、お
よびCPU ＢおよびCPU Ｃのそれぞれのバックアップタ
スクそれぞれ32および42のみに関する。さらに、これら
のタスクおよびCPUのみがこれらの例では参照される。
さらに、これらの例に関してはCPU ＡだけがCPUキュー
を有する必要があるので、CPUキューとは、CPU ＡのCP
Uキューをさす。加えて、先に指摘したように、伝送さ
れるメッセージの分配を確実にするために適切な手段を
備えると仮定する。
例１（図４） 以下の表Ｉは、CPU Ａの主タスク31、41と、CPU Ｂ
およびＣのそのそれぞれのバックアップタスクそれぞれ
32、42に関して、書込カウンタWC、読出カウンタRC、メ
ッセージキューMQおよびCPUキューの開始状態を示す。
主タスク31が３つのメッセージM1、M2、M3を主タスク
41に伝送し、これらはタスク41のメッセージキューMQに
記憶されると仮定する。これらのメッセージはまた、バ
ックアップCPU ＢおよびＣへのその後の分配のため
に、CPUキューに記憶される。タスク31は、バックアッ
プタスク32および42を含むそれぞれバックアップCPU
ＢおよびＣにメッセージM1、M2、M3が伝送されなくて
も、その処理を続けることができる。CPU Ａは、主タ
スク31または41が永続的動作を必要としていない限り
は、都合のよいときにメッセージM1、M2、M3を伝送でき
る。この例では、この時点でCPU Ａがこれらのメッセ
ージM1、M2、M3を伝送しないと仮定する。その結果は以
下の表IIに示される。
次に、タスク41はそのメッセージMQに記憶されている
M1およびM2を読出し、これらを処理し、その読出カウン
タRCを２に進ませて、２つのメッセージが処理されたこ
とを示す。その結果は以下の表IIIに示される。
メッセージM1およびM2に応答して、タスク41は２つの
メッセージM4およびM5を発生し、これらをタスク31に送
る。メッセージM4およびM5はタスク31のメッセージキュ
ーMQに記憶され、CPU ＢおよびＣへのその後の分配の
ために、CPUキューにも記憶される。その結果は以下の
表IVに示される。
CPU Ａがこの時点で故障し、主タスク31および41を
ダウンさせると仮定する。バックアップタスク32および
42は、CPU Ａが、主タスク31および41によってどのメ
ッセージも送られていないまたは処理されていない状態
にあったことで一致している（CPU ＡのCPUキューによ
って何も送られていないので）。バックアップタスク32
および42はこの一致した状態に基づいて、最後にわかっ
ている状態、すなわち初期状態から再現する。このよう
に、この時点までの処理全体が、初期状態から、外部通
信網45を介して互いに通信するバックアップタスク32お
よび42によって正確に繰返される。CPU Ａのその故障
前の状態（表IV）は、実際にはバックアップタスク32お
よび42が一致したものとはかなり異なっていても、うま
くリカバリが達成されたことに留意されたい。
例２（図５） この例の最初の状態は、CPU Ａの故障前の状態を示
す、上の例１から表IVに表わされる。この例２では、CP
U ＡがそのCPUキュー内のメッセージM1をCPU Ａが故
障する前に、CPU ＢおよびＣのそれぞれバックアップ
タスク32および42に伝送すると仮定する。メッセージM1
は、バックアップタスク42のメッセージキューMQに記憶
され、バックアップタスク32の書込カウンタWCは１に進
んで、そのそれぞれの主タスク41によって１つのメッセ
ージが送られたことを示す。CPUAVによるこの伝送の結
果は、以下の表Ｖに示される。
ここでCPU Ａが故障すれば、バックアップタスク32
および42の双方は、CPU Ａが、主タスク31によってM1
だけが主タスク41に送られた状態にあったということで
一致している。バックアップタスク32および42によるリ
カバリは、このタスク32および42のこの一致に基づいて
最後にわかっている状態（初期状態）から再出発して行
なわれる。このリカバリは、典型的には上述の特許番号
第4,590,554号に関連して説明したように行なわれても
よい。タスク32がリカバリ中にM1を再び発生させると、
この書込カウンタWC（上の表Ｖに示されるように１にあ
る）は１だけ減分されてゼロとなり、M1は捨てられる。
M2およびM3がバックアップタスク32によって再び発生さ
れると、タスク32の書込カウンタWCが現在ゼロなので、
これらは通常どおり外部通信網45を介してタスク42に伝
送される。タスク42が再出発し、その最初のメッセージ
を処理しようとすると、そのメッセージキューMQに記憶
された元のメッセージM1を与えられる（上の表Ｖ）。バ
ックアップタスク42によるさらなるメッセージの読出
は、メッセージキューMQが今度は空であるので、リカバ
ーしているバックアップタスク32から伝送される、再発
生されたM2およびM3を用いる。
例３（図６） この例の始めの状態は、上の例１からの表IIIに示さ
れる。この例３では、タスク41がこの時点で、ディスク
への書込（このディスクは典型的には図３の周辺機器Ｐ
内に位置されていてもよい）等の永続的動作を行なう必
要があると仮定する。このディスクが書込まれる前に、
CPU Ａで処理されたすべてのメッセージは、そのそれ
ぞれのバックアップタスクに伝送されなくてはならな
い。したがって、メッセージM1およびM2（処理されてい
る）は、ディスクへの書込の前にバックアップタスク32
および42を含むCPU ＢおよびＣに伝送されなくてはな
らない、というのはM1およびM2が（タスク41によって）
処理されているからである。メッセージM1およびM2がデ
ィスクへの書込が行なわれる前に送られることを保証す
るために、マーカＤがCPUキュー内の少なくともM1およ
びM2の後の位置に記憶されて、M1およびM2が送られるま
では実行がＤに達しないようにする。CPUキュー内にＤ
を記憶した結果は、以下の表VIに示される。
上の表VIに関して、M1およびM2とともにM3を送ること
はリカバリを妨げないので、Ｄは、CPUキュー内のM1お
よびM2の後のいかなる点（たとえばM3の後）に置かれて
もよいことに注目されたい。
主タスク41がディスクへの書込を行なうのを可能にす
るために、ここでCPU ＡはそのCPUキューからM1および
M2をCPU ＢおよびＣに伝送する。メッセージM1およびM
2はこのように、CPU Ｃのバックアップタスク42のメッ
セージキューMQに記憶され、バックアップタスク32の書
込カウンタWCは２に進んで、２つのメッセージ（M1およ
びM2）がCPU Ａのそのそれぞれの主タスク31によって
送られたことを示す。その結果は以下の表VIIに示され
る。
タスク41はここで、CPU ＡのキューからＤエントリ
を削除し、ディスクへの書込を実行する。
CPU Ａが故障した場合に、CPUのタスク41のバックア
ップタスク42がディスクへの書込を繰返すのを防ぐため
に、主タスク41によるディスクへの書込の実行はまた、
CPU Ｃに送られるメッセージとなり、これによってバ
ックアップタスク42の書込カウンタWCは１に進む。その
結果は、以下の表VIIIに示される。
タスク41がそのメッセージキューMQから次にM3を読出
し、M3を処理し、タスク31にメッセージM4およびM5を送
ることで応答し、M4およびM5はタスク31のメッセージキ
ューMQおよびCPUキューに記憶されると仮定する。その
結果は以下の表IXに示される。
CPU Ａがこの時点（上の表IX）で故障すれば、CPU
ＢおよびＣの双方は、CPU Ａに関して、メッセージM1
およびM2が既に送られ、ディスクへの書込が終了してい
ると一致する。故障の前にタスク41がM3を処理し、M4お
よびM5をタスク31に送ったということは、CPUの故障に
先立ってさらなる永続的動作が起こっていないので、十
分なリカバリとは関係がない。リカバリは上述した態様
で通常どおり進行する。チェックポイント動作がまだ起
こっていないので、リカバリは初期状態（表Ｉ）から始
まる。より特定的には、バックアップタスク32に関し
て、リカバリ中にタスク41によって発生されたメッセー
ジM1およびM2は、より特定的には、バックアップタスク
32に関して、リカバリ中にタスク41によって発生された
メッセージM1およびM2は送られずに捨てられる、という
のはM2が再発生されるまで、書込カウンタWCが「０」に
減分されないからである。バックアップタスク42に関し
て、そのメッセージキューMQ内のメッセージM1およびM2
は、現在故障しているCPU Ａ内の主タスク41で起こっ
たのと同じように処理される。リカバリーしているバッ
クアップタスク42が、ディスクへの書込が行なわれるべ
き（これは主タスク41によって行なわれたことに留意さ
れたい）点に達すると、このディスクへの書込動作は、
この時点でタスク42の書込カウンタWCが「１」である結
果、再び行なわれないようにされる。メッセージがタス
ク42によって送られるのは、タスク42の書込カウンタが
（このディスクへの書込防止の後）「０」に減分されて
からである。したがって、メッセージM4およびM5がタス
ク42によって発生されるときに書込カウンタWCがこのよ
うに「０」であるので、これらはタスク32に送られ、そ
れによってCPU Ａの故障の前に達した点へのリカバリ
を達成する。外部通信網45を介して通信するバックアッ
プタスク32および42を用いて、処理はこのリカバリ点を
越えて継続する。
例４（図８） この例４（および例５）の目的は、図３の実施例にお
けるチェックポイント動作を説明することであり、最初
の状態は上の例１から表IVに対応すると仮定する。
上の表IVに示される状態に達した後、タスク41がチェ
ックポイント動作を始めると仮定する。チェックポイン
ト動作は、タスク41の状態についての情報がCPU Ａの
外に伝送されることを必要とするので、これは永続的動
作である。したがって、タスク41はチェックポイントデ
ータ（または適切なチェックポイントマーカCK）を、M1
およびM2が処理されているので、CPUキュー内の少なく
ともM1およびM2の後の位置に置く。この結果は以下の表
Ｘに示される。
上の表Ｘにおいて、タスク41の読出カウンタは、タス
ク41に関する限り必要なチェックポイント動作が既に起
こっているので、ゼロにされていることに注目された
い。さらに、タスク31および41の両方は、チェックポイ
ントデータがそのそれぞれのバックアップに伝送される
までいかなる後続の永続的動作も遅延される限り、チェ
ックポイントデータがいつ実際にCPU Ｃ内のバックア
ップタスク42に送られるかとは関係なく、処理を進める
ことができることにも注目されたい。表Ｘにおいて、CK
は、CPUキュー内のM1およびM2の直後ではなく、M5の後
に置かれており、M1およびM2と同様にM3、M4およびM5も
チェックポイントデータCKの前に伝送されることを意味
していることに注目されたい。このことは、永続的動作
に遭遇しなげれば、CPU Ａは（上述のように）そのCPU
キューからメッセージを都合のよいときに伝送できる
し、永続的動作に遭遇するような場合には、処理された
メッセージは永続的動作が実行できる前にそのそれぞれ
のバックアップに伝送されなくてはならないので、問題
は生じない。
例４のために、ここでCPU ＡがCPU ＢおよびＣのバ
ックアップタスクそれぞれ32および42にM1ないしM5を伝
送し始めるが、CPU ＡはM1、M2、M3、M4を伝送し終わ
ってから故障し、M5またはチェックポイントデータCKの
いずれも伝送されないと仮定する。この結果として生じ
る、故障の直前の状態は以下の表XIに示される。
CPU ＢおよびＣのそれぞれバックアップタスク32お
よび42は、メッセージM1、M2、M3、M4のみが伝送され、
チェックポイントはまだ起こっていないという一致した
認識に基づいて、初期状態（表Ｉ）からリカバリを始め
る。
例５（図９）： この例は上記の例４の表Ｘに対応する最初の状態をと
る。しかしながら、例４で説明したように、M1−M4の伝
送の後にフェールする代わりに、この例５はCPU ＡのM
1−M5およびCKの伝送が成功すると仮定し、下記の表XII
に示すような結果となる： 上に議論したように、チェックポイント動作によりバ
ックアップタスク42はその主タスク41と同じ状態になり
かつ主タスク41とバックアップタスク42とのそれぞれの
メモリＭ中のデータ空間は同一になる。
チェックポイントデータがうまく伝送されるまでさら
なる永続的動作が遅延されると仮定すれば、メッセージ
M1ないしM5およびCKが伝送されている間、CPU Ａは主
タスク31および41のためのさらなる作業の処理を自由に
継続できるということが理解される。
もし引続いてCPU Ａの故障が発生するとすれば、バ
ックアップタスク32はSTARTからリカバーし、かつバッ
クアップタスク42は上記のチェックポイントからリカバ
ーする。
外部事象の処理（表Ａ−Ｆ） 上述のシステムでは、タスクへの入力はメッセージに
よってなされる。オペレーティングシステムの呼出はメ
ッセージとして取扱われ得るため、これらのシステムに
よって容易に処理される。しかしながら、タスクの振舞
いはこれらのシステムによって容易に距離されない他の
やり方で影響を受けるかもしれない。たとえば、タスク
の状態は、外部事象がいつ発生するかをタスクがほとん
どまたは全く制御できない、かつこの外部事象の発生時
期によってタスクの振舞いが変化し得るような、制御さ
れない外部事象によって変えられるかもしれない。
たとえば、係る外部事象は、割込みハンドラの動作の
ために、または共通メモリへの別のプロセスの書込の結
果として発生し得る。以下の例は簡単ではあるが係る制
御されない外部事象がどのようにタスクの振舞いに影響
を及ぼすかを示すものである。
このために、タスクは表Ａに示されるプログラムを実
行すると仮定する。もし制御されない外部事象がこのプ
ログラムの実行の間に発生しなければ、プログラム出力
（表Ａ中ではプログラムステップPC＝２で発生）は表Ｂ
に示されるようになる。
前述の特許第4,590,554号およびフレキシブル・フォ
ールト・トレラント・システムから理解されることだ
が、もしタスクがフェールするとすれば、表Ｂのプログ
ラム出力は同じプログラムを実行し、かつ同じ態様で初
期化されるバックアップタスクを用いて正確に再現され
る。
ここで上記のプログラムが次の相違点を有して再び実
行されると仮定する。つまり、制御されない外部事象
（共通メモリへの別のプロセスの書込によって作られる
ような事象）が、上記のタスクプログラムが実行されて
いる間にMEM（STATE←GREEN）のメモリ動作を発生させ
ると仮定する。もしこの外部から引起こされたメモリ動
作が表Ｂ中の第２のREDの後（つまり表Ｂ中のプログラ
ム出力ライン３と４との間）、かつ表Ａのプログラムス
テップPC＝２とPC＝３との間で発生するとすれば、プロ
グラムはPC＝５へ進み、これはメモリ状態をMEM（STATE
＝RED）へと戻す。結果として生じるプログラム出力
は、表Ｃに示されるようになる。
一方、もし外部事象MEM（STATE←GREEN）が、第１のG
REENプログラム出力の後（つまり表Ｂ中のプログラム出
力ライン２と３との間）で発生したとすれば、表Ｂに示
される元のプログラム出力は変化しない。なぜなら外部
事象は表ＡのPC＝２におけるメモリの状態に影響しない
からである。同様に、もし外部事象が表Ａのプログラム
ステップPC＝３とPC＝４との間に発生するとしても表Ｂ
の元のプログラム出力は変化しないであろう。なぜなら
これもまた表ＡのPC＝２におけるメモリの状態に影響し
ないからである。
したがって明らかに、制御されない外部事象の発生時
期はタスクがどのように働くかということに影響を及ぼ
し得る。したがって、もしバックアップタスクが係る制
御されない外部事象によって影響されるフェールした主
タスクを正しく再現するのであれば、タスクの実行の間
にこれらの外部事象を適切に生じさせるための準備がな
されなくてはならない。本発明はこの問題を特に有利に
解決する方法を提供する。
先に開示したようなフォールト・トレラント・システ
ム中で制御されない外部事象を処理するための本発明の
好ましい実施例によって用いられるアプローチを次に説
明する。基本的なアプローチは、これらの外部事象の発
生を主タスクで発生する特定の事象に関連づけることで
ある。これらの特定の事象はタスクコンテキストの一部
として取扱われるため、フェールしたタスクのリカバリ
の間、各外部事象は主タスクの実行の間に発生したのと
同じ論理的ポイントにおいてバックアップタスクの再現
の間に再び渡され、これによりバックアップが適切にリ
カバーすることを保証する。ここに説明する好ましい実
施例においては、これはメモリへ「書込」データ参照を
カウントすることによって達成され、その結果生じる
「書込」カウントはタスクコンテキストの一部である。
係るメモリ「書込」カウンティングは当業者によって容
易に行なわれる。たとえば、もしCPUがモトローラ（Mot
orola）88,000チップを用いるとすれば、このカウンテ
ィングは完了したメモリ記憶（書込）指令をカウントす
ることによって行なわれる。
次に図10に示す本発明の好ましい実施例を参照して、
この図は基本的には図３と同じであるが、表ＢのCPU
Ａ、CPU ＢおよびCPU Ｃの各々に、メモリ「書込」カ
ウント機能を行ない、かつリカバリを行なうのに使用さ
れるメモリ参照カウンタMRCおよびメモリ参照カウンタ
比較レジスタMRCCRが追加されている。各CPUにおいて、
MRCおよびMRCCRは内部通信網35を介してタスク31、41、
51およびメモリＭと通信し得る。
主タスクの動作の間、メモリＭへの各「書込」データ
参照は、タスクがオペレーティングシステムの呼出を行
ない、オペレーティングシステムコードの実行を開始
し、オペレーティングシステムの呼出が完了するまでタ
スクが休止したままでいる場合以外は、MRCを１だけ増
分させる。各チェックポイントの後だけでなく各オペレ
ーティングシステムの呼出の後にもMRCをゼロにするこ
とが有利であり、これはなぜならカウントを小さくし、
カウンタオーバーフローの可能性を低減するからであ
る。システムの呼出はメッセージとして取扱われるた
め、各オペレーティングシステム呼出の後にMRCをゼロ
にすることはメモリ「書込」カウンティングに関しては
何の支障もない。
タスクのメモリを変える外部信号（先に例示したよう
な）などの制御されない外部事象が主タスクの実行の間
に発生する場合は、MRC中の既存のメモリ参照カウント
は外部信号のタイプの表示およびタスクのレジスタコン
テキストともに各バックアップタスクに送られて、その
各CPUのメモリＭに記憶されなければならない。特許第
4,590,554のフォールトトレラントシステム（図１およ
び図２）を用いれば、このデータは、この特許の概要で
説明されるように即座にバックアップへ送られなければ
ならない。しかしながら、フレキシブル・フォールト・
トレラント・システム（図３−９）においては、このデ
ータは他のメッセージと同様に取扱われ、CPU ＡのCPU
キューに置かれる。たとえば、もしフォールトトレラン
トシステムの状態が表IIに示されるようなものであると
仮定すれば、タスク31に関して制御されない外部信号が
発生すれば、タスクおよび信号のタイプを示すマーカー
ＳをMRCの現在のカウントを含むタスク31レジスタコン
テキストＲとともにCPUキューに位置させる。これは下
記の表XIIIに示される： 代替的に、CPUキューに記憶されるレジスタコンテキ
ストＲは単なるマーカーであり、完全なレジスタコンテ
キストはメモリＭ中のタスク31のメモリ空間に記憶され
ているようにもできる。その場合、CPUキュー内におい
てマーカーＳに到達すると、記憶されたレジスタコンテ
キストＲがメモリＭから呼出され、バックアップへ伝送
されてバックアップメモリＭに記憶される。
次に、主タスクの故障の前の主タスクの実行の間に制
御されない外部事象が発生する場合に、フェールしたタ
スクがバックアップによってリカバーされる様子を示す
例を挙げる。このために、主タスクは表Ａに示したもの
と同じ表Ｄに示されるプログラムを実行すると仮定す
る。この例は、その上で主タスクが実行されるべきCPU
が少なくともメモリ参照カウンタMRCを含み（図10）、
かつその各々のバックアップCPUが少なくともメモリ参
照カウンタMRCおよびメモリ参照比較カウンタレジスタM
RCCRを含むと仮定する。
表Ｅは図10のCPU Ａ上で主タスクによって表Ｄのプ
ログラムが実行される様子を示す。表Ｅはプログラムの
実行の間に「事象」、「ハードウェアコンテキスト」お
よび「プログラム出力」が発生することを示すと理解さ
れたい。最初の「事象」はチェックポイント動作であ
り、MRC＝０に設定する。このときPC＝３かつCF＝FALSE
であり、かつメモリの状態はMEM（STATE＝RED）であ
る。表Ｅに示されるように、プログラムの実行はこのチ
ェックポイント動作で始まり、その後、「プログラム出
力」がGREEN、RED、GREEN、RED、GREENと交互に代わ
り、かつMRCの値が各メモリの変化（書込）に応じて１
だけ増分されるという予定の態様で進む。
表Ｅに示されるように、外部信号（STATE←GREEN）は
MRC＝５の後に発生し、このときMEM（STATE＝RED）であ
る。このとき、「ハードウェアコンテキスト」レジスタ
の値はPC＝８、CF＝FALSE、およびMRC＝５である。4,59
0,554のシステムにおいては、このレジスタコンテキス
トは信号のタイプの表示とともに各タスクバックアップ
へ送られる。フレキシブル・フォールト・トレラント・
システムにおいては、このデータのバックアップへの送
信は、表XIIIに示されるように、CPUキューにこのデー
タを記憶することによって遅延され得る。
表Ｅの例の説明を続けると、外部信号（STATE←GREE
N）の発生はメモリの状態をMEM（STATE＝RED）からMEM
（STATE＝GREEN）へと変える。したがって、次のプログ
ラム出力はREDではなくてGREEN（先の出力と同じく）で
あり、これは外部信号（STATE←GREEN）が発生しなかっ
た場合と同じである。
その後、プログラムは継続する。フェールは示される
ようにMRC＝８で発生する。
次に表Ｆに注目して、これはバックアップがどのよう
に表Ｅのフェールしたタスクを再現するかを示す例であ
る。この例は、レジスタコンテキストおよび信号のタイ
プが故障の前にバックアップに送られていると仮定す
る。表Ｅのチェックポイントの後にはシステム呼出はな
かったため、バックアップはこのチェックポイントで始
まり、これは表Ｅのチェックポイントでもっていた値に
それぞれ対応するようにPC＝３、CF＝FALSEおよびMRC＝
０に設定する。さらに、MRCCRはMRCCR＝５に設定され、
これは外部信号が発生した場合の主タスクのMRCの値で
あり、この値は表Ｅに関連して説明したようにレジスタ
コンテキストの一部としてバックアップに送られた。MR
CCR＝５により、外部信号（この信号のタイプもまたバ
ックアップに送られる）が５つのメモリへの「書込」参
照の後に渡されるべきであるとバックアップに指令する
ということが理解される。
したがって表Ｆに示すように、バックアップは、MRC
が各メモリ「書込」ごとに１だけ増分される状態で通常
通り進行する。MRCの各増分ごとにMRCCR＝５との比較が
行なわれる。MRC＝５の場合レジスタは、外部信号が主
タスクの実行の間に渡される直前のレジスタコンテキス
トに従って設定され、このレジスタコンテキストは上述
のようにバックアップに送られてそこに記憶されてい
る。したがって、PCおよびCFはそれぞれPC＝８およびCF
＝FALSEに設定され、さらに、MRCCRはMRCCR＝０となる
ようにゼロにされる。その後、外部信号（STATE←GREE
N）がバックアップ記憶装置から取出されて渡され、そ
れに続いて、表ＥおよびＦのプログラム出力の比較から
明らかなように、再実行が主タスクを正確に再現し続け
る。
もし主タスクがフェールする前に第２の外部信号がバ
ックアップに送られていたとすれば、MRCCRは表ＦのMRC
＝MRCCRの場合にゼロにされず、この第２の信号が発生
したときにMRCが主タスクに持っていた値に設定されて
いたであろうということが理解される。したがって、こ
の第２の外部信号を用いる動作は第１の外部信号につい
て説明したものと同じであったであろう。この意味で、
表ＦにおいてMRCは、上述のように主タスクの実行の間
に発生しかつバックアップに送られたかもしれない他の
外部信号の分配時期を制御するためのカウントを与える
ように、MRC＝５を超えて増分を続ける。さらに、MRCの
カウントはタスクコンテキストの一部であるため、表Ｆ
に示される再現は継続的である必要はないということに
も留意されたい。再現はいつでも差替可能であり、他の
タスクが外部信号を正確に再び送ることに影響を及ぼさ
ずに実行され得る。
特定の好ましい実施例および動作例に関して本発明を
ここに説明してきたが、その構成、配列、使用法および
動作において幅広い修正、追加および拡張が本発明の範
囲を逸脱することなくなされ得るということが理解され
るべきである。たとえば、本発明は、制御されない外部
事象が正確な再現のために関連付けられるカウントを与
えるためにメモリ「書込」参照を用いることに限定され
るものではない。たとえばもし都合がよければメモリ
「読出」および「書込」の両方がカウントされてもよ
い。また、プログラムステップもカウント可能である
が、これは大抵の場合非常に面倒である。
さらに、表Ｆの再現の開始時にMRCCRに設定される参
照カウントは、外部信号をいつ送るかを決定するために
様々な他のやり方で用いられてもよいということが理解
される。たとえば、表ＦのようにMRCCRをMCRと比較する
代わりに、MRCCRは外部信号がいつ送られるべきかを示
すためにゼロまでカウントダウンされることもできる。
さらに、外部信号をバックアップ中に送るためにCPU
のオペレーティングシステムのページフォールト能力を
用いることもできるということが理解される。たとえ
ば、表ＦのMRC＝MRCCRの後、外部信号の分配を開始する
ためにバックアップのオペレーティングシステムが用い
られて次のメモリ参照上にページフォールトを作出すこ
とができる。
さらに、表ＥおよびＦの例はオペレーティングシステ
ムへの呼出を含まないが、係る呼出は正しい再現には干
渉はしないということが理解されるべきである。上述の
ように、オペレーティングシステム呼出は主タスクの実
行の間にMRCをゼロにするために用いられることがで
き、これはなぜなら係るゼロ化は再現の間に正確に実行
されるからである。これはMRCのオーバーフローを防止
するという利点を有する。
上述の可能な修正および拡張の例は単に代表的なもの
であり、これに尽きるものではない。したがって本発明
は、後述の請求の範囲によって包括されるあらゆる修
正、変形および拡張を含むと考えられるべきである。
プログラム出力 プログラム出力 １ RED １ RED ２ GREEN ２ GREEN ３ RED ３ RED ４ GREEN ４ RED ５ RED ５ GREEN ・ ・ ・ ・ ETC. ETC. 表Ｂ 表Ｃ
フロントページの続き (56)参考文献 特表 昭59−501802（ＪＰ，Ａ) 国際公開91／117504（ＷＯ，Ａ１) (58)調査した分野(Int.Cl.7，ＤＢ名) G11B 11/14 - 11/20 G11B 9/46 G11B 15/16 - 15/177

Claims (15)

    (57)【特許請求の範囲】
  1. 【請求項１】複数の主タスクを提供するデータプロセッ
    サを含み、前記主タスクの少なくとも１つは永続的動作
    を実行し、主タスクは、その発生時間がその実行に影響
    を及ぼし得る外部事象を受け、 前記複数の主タスクをバックアップするために前記デー
    タプロセッサの外部に、対応する複数の相互接続される
    バックアップタスクを提供するフォールトトレラントコ
    ンピュータシステムにおいて、 処理のために前記主タスク間でメッセージを伝送するス
    テップと、 伝送されたメッセージを記憶するステップと、 各外部事象のタイプおよび予め定められた主タスク事象
    に対するその発生関係を示す外部事象データをまた記憶
    するステップと、 各主タスクが、当該各主タスクに伝送されたメッセージ
    を処理するステップと、 前記メッセージの記憶に続いて、記憶されたメッセージ
    の少なくとも特定のものを、前記バックアップタスク
    に、永続的動作の実行に先立って、少なくとも、前記パ
    ックアップタスクが前記データプロセッサの故障からリ
    カバーするために必要とする特定のメッセージが前記バ
    ックアップタスクに伝送されるような態様で、前記バッ
    クアップタスクに伝送するステップと、 前記永続的動作の実行の前に外部事象データもまたそれ
    ぞれのバックアップタスクへ伝送するステップとを含
    み、 前記主タスクは前述のメッセージおよび外部事象データ
    の前記バックアップタスクへの伝送が合致する限り、前
    記主タスクへ伝送されたメッセージを処理し続け、さら
    に 前記バックアップタスクに、当該バックアップタスクに
    伝送された外部事象データおよびメッセージを処理させ
    ることによって故障からリカバーするステップを含み、
    前記外部事象データと前記メッセージとの各々の発生の
    前後関係が、前記リカバリ中に、そのそれぞれの外部事
    象がいつ起こるかを定めるために用いられ、それによっ
    て適切なリカバリが達成される、方法。
  2. 【請求項２】前記バックアップタスクおよび前記システ
    ムの前記バックアップタスク以外の部分が、前記故障の
    前の各主タスクの特定の状態で一致するように前記特定
    のメッセージが選択され、当該特定の状態はフェール時
    のその実際の状態でなくてもよい、請求項１に記載の方
    法。
  3. 【請求項３】前記主タスクはそこに伝送されたメッセー
    ジを連続して処理し、かつ前記特定のメッセージは少な
    くとも最も最近処理されたメッセージおよび前記主タス
    クによって伝送された、前記最も最近処理されたメッセ
    ージ以前のすべてのメッセージを含む、請求項２に記載
    の方法。
  4. 【請求項４】前記主タスクは当該主タスクに伝送された
    メッセージを連続して処理し、前記伝送されたメッセー
    ジの記憶は伝送されたメッセージを伝送の順に記憶する
    キューの中で行われ、外部事象データは発生順に前記キ
    ューに記憶され、永続的動作の実行は、永続的動作の表
    示を最も最近処理されたメッセージの位置より前ではな
    い位置に記憶することによって前記キュー中に示され、
    かつ前記特定のメッセージおよび外部事象データは、前
    記キュー中の前記永続的動作表示の位置に基づく前記永
    続的動作の実行の前に前記バックアップタスクへ伝送さ
    れる、請求項３に記載の方法。
  5. 【請求項５】前記リカバリステップは、各バックアップ
    タスクがそれぞれ特定の状態に達するようになる態様
    で、前記バックアップタスクに伝送されたメッセージお
    よび外部事象データを当該バックアップタスクに処理さ
    せるステップを含む、請求項１に記載の方法。
  6. 【請求項６】前記特定のメッセージおよび前記外部事象
    データは、各バックアップタスクが前記特定のメッセー
    ジのうちのその各主タスクへ伝送された各メッセージを
    受信し、かつその各主タスクごとに発生する各外部事象
    に対応する外部事象データを受信するように、前記バッ
    クアップタスクへ伝送される、請求項１に記載の方法。
  7. 【請求項７】前記特定のメッセージは、各バックアップ
    タスクが前記特定のメッセージのうちのその各主タスク
    によって伝送された各メッセージをまた受信するよう
    に、前記バックアップタスクへ伝送される、請求項６に
    記載の方法。
  8. 【請求項８】各バックアップタスクが、その各主タスク
    によって伝送された受信したメッセージの数のカウント
    を与えることを含み、前記カウントは前記発生関係を決
    定するために用いられる、請求項７に記載の方法。
  9. 【請求項９】各バックアッププロセッサは前記リカバリ
    の間に外部事象がいつ起こるかを決定するために前記カ
    ウントを用いる、請求項８に記載の方法。
  10. 【請求項１０】少なくとも複数個のメッセージが前記主
    タスクへ伝送された後に、主タスクとその各バックアッ
    プタスクとの間でチェックポイント動作を実行するステ
    ップを含み、前記チェックポイント動作は、主タスクの
    状態に対応するチェックポイントデータを記憶し、かつ
    前記記憶に続いて、かつ前記バックアップタスクが各主
    タスクからそこに伝送されたメッセージを用いて前記デ
    ータプロセッサのフェールからリカバするのに必要な時
    間より遅くない時間に、前記チェックポイントデータを
    各バックアップタスクへ伝送するステップを含み、前記
    チェックポイントデータは、前記チェックポイントデー
    タが伝送されたバックアップタスクをチェックポイント
    動作時に各主タスクと同じ状態にさせる、請求項１に記
    載の方法。
  11. 【請求項１１】前記チェックポイントデータは、その開
    始時または最新のチェックポイント設定から主タスクに
    よって処理されたメッセージの数のカウントを含み、か
    つ各バックアップタスクは前記カウントを用いて、対応
    するメッセージの数を廃棄する、請求項10に記載の方
    法。
  12. 【請求項１２】前記主タスクはそこに伝送されたメッセ
    ージを連続して処理し、前記伝送されたデータの記憶は
    その伝送順に伝送されたメッセージを記憶するキュー中
    で行なわれ、外部事象データは発生順に前記キューに記
    憶され、前記キューはまた前記チェックポイント動作の
    実行時間を示す位置にチェックポイント表示を記憶し、
    永続的動作の実行は最も最近処理されたメッセージの位
    置に基づいて前記キュー中に入力された永続的動作の表
    示を記憶することによって前記キューに示され、前記特
    定のメッセージおよび外部事象データは、前記キュー中
    で前記永続的動作の表示よりも前に位置していれば前記
    永続的動作の実行の前に前記バックアップタスクへ伝送
    され、かつ前記チェックポイントデータもまた、前記永
    続的動作表示の位置よりも前に位置していれば各バック
    アップへ伝送される、請求項10に記載の方法。
  13. 【請求項１３】前記予め定められた主タスク事象はメモ
    リアクセス動作である、請求項１または２に記載の方
    法。
  14. 【請求項１４】前記予め定められた主タスク事象は、前
    記主タスクの実行の間に複数回発生し、かつ前記外部事
    象データは、各外部事象ごとに、当該外部事象の発生前
    の、主タスク事象の発生数のカウントのための基準時点
    以後に前記予め定められた主タスク事象が発生した回数
    に関係したカウントを含む、請求項１または２に記載の
    方法。
  15. 【請求項１５】前記カウントは、前記バックアップタス
    クに送信された前記メッセージと前記外部事象データと
    を処理することによって前記バックアップタスクのリカ
    バーを行なう間に前記バックアップタスクによって用い
    られて、対応する外部事象が前記バックアップタスクに
    いつ送られるかを決定する、請求項14に記載の方法。
JP51335893A 1992-01-22 1993-01-22 外部事象を処理できるフォールトトレラントコンピュータシステム Expired - Fee Related JP3209748B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US824,134 1992-01-22
US07/824,134 US5363503A (en) 1992-01-22 1992-01-22 Fault tolerant computer system with provision for handling external events
PCT/US1993/000618 WO1993015461A1 (en) 1992-01-22 1993-01-22 Fault tolerant computer system with provision for handling external events

Publications (2)

Publication Number Publication Date
JPH07503334A JPH07503334A (ja) 1995-04-06
JP3209748B2 true JP3209748B2 (ja) 2001-09-17

Family

ID=25240678

Family Applications (1)

Application Number Title Priority Date Filing Date
JP51335893A Expired - Fee Related JP3209748B2 (ja) 1992-01-22 1993-01-22 外部事象を処理できるフォールトトレラントコンピュータシステム

Country Status (5)

Country Link
US (1) US5363503A (ja)
EP (1) EP0623230B1 (ja)
JP (1) JP3209748B2 (ja)
DE (1) DE69311797T2 (ja)
WO (1) WO1993015461A1 (ja)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1993009494A1 (en) * 1991-10-28 1993-05-13 Digital Equipment Corporation Fault-tolerant computer processing using a shadow virtual processor
US5398330A (en) * 1992-03-05 1995-03-14 Seiko Epson Corporation Register file backup queue
JPH05260134A (ja) * 1992-03-12 1993-10-08 Fujitsu Ltd 伝送装置の監視システム
US5715386A (en) * 1992-09-30 1998-02-03 Lucent Technologies Inc. Apparatus and methods for software rejuvenation
CA2106280C (en) * 1992-09-30 2000-01-18 Yennun Huang Apparatus and methods for fault-tolerant computing employing a daemon monitoring process and fault-tolerant library to provide varying degrees of fault tolerance
JPH07175597A (ja) * 1993-12-17 1995-07-14 Fujitsu Ltd 記憶媒体の二重化装置
JPH10506483A (ja) * 1994-06-10 1998-06-23 テキサス・マイクロ・インコーポレーテッド フォールト・トレラントなコンピュータ・システムのためのメイン・メモリ・システム及びチェックポイント用プロトコル
CA2167634A1 (en) * 1995-01-23 1996-07-24 Michael E. Fisher Method and apparatus for maintaining network connections across a voluntary process switchover
US5621885A (en) * 1995-06-07 1997-04-15 Tandem Computers, Incorporated System and method for providing a fault tolerant computer program runtime support environment
US5699502A (en) * 1995-09-29 1997-12-16 International Business Machines Corporation System and method for managing computer system faults
US5864657A (en) * 1995-11-29 1999-01-26 Texas Micro, Inc. Main memory system and checkpointing protocol for fault-tolerant computer system
US5802265A (en) * 1995-12-01 1998-09-01 Stratus Computer, Inc. Transparent fault tolerant computer system
US5819021A (en) * 1995-12-11 1998-10-06 Ab Initio Software Corporation Overpartitioning system and method for increasing checkpoints in component-based parallel applications
FR2743164B1 (fr) * 1995-12-28 1998-02-06 Cegelec Procede pour ordonnancer une pluralite de messages provenant respectivement d'une pluralite de sources, et systeme pour la mise en oeuvre de ce procede
US5978933A (en) * 1996-01-11 1999-11-02 Hewlett-Packard Company Generic fault tolerant platform
GB9601585D0 (en) * 1996-01-26 1996-03-27 Hewlett Packard Co Fault-tolerant processing method
GB9601584D0 (en) * 1996-01-26 1996-03-27 Hewlett Packard Co Fault-tolerant processing method
US5796941A (en) * 1996-09-06 1998-08-18 Catalyst Semiconductor, Inc. Method for supervising software execution in a license restricted environment
US5835698A (en) * 1996-09-20 1998-11-10 Novell, Inc. Unilaterally-controlled, time-insensitive, data-link recovery apparatus and method
US5983371A (en) * 1997-07-11 1999-11-09 Marathon Technologies Corporation Active failure detection
US6289474B1 (en) 1998-06-24 2001-09-11 Torrent Systems, Inc. Computer system and process for checkpointing operations on data in a computer system by partitioning the data
US6801938B1 (en) * 1999-06-18 2004-10-05 Torrent Systems, Inc. Segmentation and processing of continuous data streams using transactional semantics
GB2359384B (en) 2000-02-16 2004-06-16 Data Connection Ltd Automatic reconnection of partner software processes in a fault-tolerant computer system
US20020129110A1 (en) * 2001-03-07 2002-09-12 Ling-Zhong Liu Distributed event notification service
US6971043B2 (en) * 2001-04-11 2005-11-29 Stratus Technologies Bermuda Ltd Apparatus and method for accessing a mass storage device in a fault-tolerant server
US6954877B2 (en) * 2001-11-29 2005-10-11 Agami Systems, Inc. Fault tolerance using logical checkpointing in computing systems
US7478275B1 (en) * 2004-03-29 2009-01-13 Symantec Operating Corporation Method and apparatus for performing backup storage of checkpoint data within a server cluster
US7644050B2 (en) * 2004-12-02 2010-01-05 International Business Machines Corporation Method and apparatus for annotation-based behavior extensions
FR2882448B1 (fr) * 2005-01-21 2007-05-04 Meiosys Soc Par Actions Simpli Procede de gestion, de journalisation ou de rejeu du deroulement d'un processus applicatif
FR2881306B1 (fr) * 2005-01-21 2007-03-23 Meiosys Soc Par Actions Simpli Procede de journalisation non intrusive d'evenements externes aupres d'un processus applicatif, et systeme mettant en oeuvre ce procede
FR2881246B1 (fr) * 2005-01-21 2007-03-23 Meiosys Soc Par Actions Simpli Procede perdictif de gestion, de journalisation ou de rejeu d'operations non deterministes au sein du deroulement d'un processus applicatif
FR2881307B1 (fr) * 2005-01-21 2007-03-23 Meiosys Soc Par Actions Simpli Procede non intrusif de simulation ou rejeu d'evenements externes aupres d'un processus applicatif, et systeme mettant en oeuvre ce procede
FR2881308B1 (fr) * 2005-01-21 2007-03-23 Meiosys Soc Par Actions Simpli Procede d'acceleration de la transmission de donnees de journalisation en environnement multi ordinateurs et systeme utilisant ce procede
FR2881309B1 (fr) * 2005-01-21 2007-03-23 Meiosys Soc Par Actions Simpli Procede d'optimisation de la transmission de donnees de journalisation en environnement multi-ordinateurs et systeme mettant en oeuvre ce procede
FR2882449A1 (fr) * 2005-01-21 2006-08-25 Meiosys Soc Par Actions Simpli Procede non intrusif de rejeu d'evenements internes au sein d'un processus applicatif, et systeme mettant en oeuvre ce procede
US20060222126A1 (en) * 2005-03-31 2006-10-05 Stratus Technologies Bermuda Ltd. Systems and methods for maintaining synchronicity during signal transmission
US20060222125A1 (en) * 2005-03-31 2006-10-05 Edwards John W Jr Systems and methods for maintaining synchronicity during signal transmission
US8041985B2 (en) 2006-08-11 2011-10-18 Chicago Mercantile Exchange, Inc. Match server for a financial exchange having fault tolerant operation
US7480827B2 (en) 2006-08-11 2009-01-20 Chicago Mercantile Exchange Fault tolerance and failover using active copy-cat
US7434096B2 (en) 2006-08-11 2008-10-07 Chicago Mercantile Exchange Match server for a financial exchange having fault tolerant operation

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4347563A (en) * 1980-06-16 1982-08-31 Forney Engineering Company Industrial control system
US4485438A (en) * 1982-06-28 1984-11-27 Myrmo Erik R High transfer rate between multi-processor units
US4590554A (en) * 1982-11-23 1986-05-20 Parallel Computers Systems, Inc. Backup fault tolerant computer system
US4493035A (en) * 1982-12-07 1985-01-08 Motorola, Inc. Data processor version validation
US4524415A (en) * 1982-12-07 1985-06-18 Motorola, Inc. Virtual machine data processor
US4562538A (en) * 1983-05-16 1985-12-31 At&T Bell Laboratories Microprocessor having decision pointer to process restore position
EP0254247A3 (de) * 1984-04-26 1988-08-10 BBC Brown Boveri AG Einrichtung zur Rettung des Rechnerzustandes
SE454730B (sv) * 1986-09-19 1988-05-24 Asea Ab Forfarande och datorutrustning for stotfri omkoppling av funktionen fran aktiva enheter till beredskapsenheter i en centralenhet
DE69021712T2 (de) * 1990-02-08 1996-04-18 Ibm Wiederanlaufkennzeichnungsmechanismus für fehlertolerierende Systeme.
US5271013A (en) * 1990-05-09 1993-12-14 Unisys Corporation Fault tolerant computer system
US5032979A (en) * 1990-06-22 1991-07-16 International Business Machines Corporation Distributed security auditing subsystem for an operating system
US5175847A (en) * 1990-09-20 1992-12-29 Logicon Incorporated Computer system capable of program execution recovery

Also Published As

Publication number Publication date
US5363503A (en) 1994-11-08
DE69311797D1 (de) 1997-07-31
WO1993015461A1 (en) 1993-08-05
EP0623230A1 (en) 1994-11-09
DE69311797T2 (de) 1998-02-05
JPH07503334A (ja) 1995-04-06
EP0623230B1 (en) 1997-06-25

Similar Documents

Publication Publication Date Title
JP3209748B2 (ja) 外部事象を処理できるフォールトトレラントコンピュータシステム
US5271013A (en) Fault tolerant computer system
US6161198A (en) System for providing transaction indivisibility in a transaction processing system upon recovery from a host processor failure by monitoring source message sequencing
US6401216B1 (en) System of performing checkpoint/restart of a parallel program
Scales et al. The design of a practical system for fault-tolerant virtual machines
US6393583B1 (en) Method of performing checkpoint/restart of a parallel program
US6931502B2 (en) Recovery of data using write request copies in delta queue
US5448718A (en) Method and system for time zero backup session security
US6718447B2 (en) Method and system for providing logically consistent logical unit backup snapshots within one or more data storage devices
EP0566966B1 (en) Method and system for incremental backup copying of data
US7290086B2 (en) Method, apparatus and program storage device for providing asynchronous status messaging in a data storage system
US6338147B1 (en) Program products for performing checkpoint/restart of a parallel program
US6058491A (en) Method and system for fault-handling to improve reliability of a data-processing system
US20100049927A1 (en) Enhancement of data mirroring to provide parallel processing of overlapping writes
US20050071708A1 (en) Method, system, and program for recovery from a failure in an asynchronous data copying system
US20060161732A1 (en) Disk array apparatus and disk array apparatus control method
JPH07117903B2 (ja) 障害回復方法
US7047441B1 (en) Recovery guarantees for general multi-tier applications
WO1997046939A1 (en) Method and structure for balanced queue communication between nodes in a distributed computing application
WO1993009494A1 (en) Fault-tolerant computer processing using a shadow virtual processor
KR100304319B1 (ko) 시간 지연 이중화 기술을 구현하는 장치 및 방법
JP3481737B2 (ja) ダンプ採取装置およびダンプ採取方法
US6636984B1 (en) System and method for recovering data from mirror drives following system crash
JP2002183088A (ja) オンラインシステム回復方法及びその実施装置並びにその処理プログラムを記録した記録媒体
US5539875A (en) Error windowing for storage subsystem recovery

Legal Events

Date Code Title Description
R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20070713

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080713

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080713

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090713

Year of fee payment: 8

LAPS Cancellation because of no payment of annual fees