(57)【要約】【課題】  コンピュータシステムに発生する障害から回復できる非決定的プロセッサの方法およびシステムを提供する。【解決手段】  緩やかなロックステップ非決定的プロセッサ（ＰＡ、ＰＢ、ＰＣ）の方法およびシステム。いくつかの例示的な実施形態は、ユーザプログラムの１つのコピーが、非決定的実行を行う第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）で実行され、ユーザプログラムの複製コピーが、非決定的実行を行う第２のプロセッサ（ＰＡ、ＰＢ、ＰＣ）で実行される、ユーザプログラムのフォールトトレランスコピーを実行することを含み、第１のプロセッサおよび第２のプロセッサ（ＰＡ、ＰＢ、ＰＣ）における実行は、サイクルごとにロックステップされない方法に基づくプロセッサであり得る。【選択図】図１
2005285119.tif 000002
【特許請求の範囲】
【請求項１】
ユーザプログラムのフォールトトレランスコピーを実行する方法であって、
前記ユーザプログラムの１つのコピーは、非決定的実行を行う第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）で実行され、
前記ユーザプログラムの複製コピーは、非決定的実行を行う第２のプロセッサ（ＰＡ、ＰＢ、ＰＣ）で実行され、
前記第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）および前記第２のプロセッサ（ＰＡ、ＰＢ、ＰＣ）における前記実行は、サイクルごとのロックステップではない
方法。
【請求項２】
第１のコンピュータシステム（１０）の一部である前記第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）で前記ユーザプログラムを実行し、
第２のコンピュータシステム（１０）の一部である第２のプロセッサ（ＰＡ、ＰＢ、ＰＣ）で前記ユーザプログラムの前記複製コピーを実行する
ことをさらに含む請求項１に記載の方法。
【請求項３】
前記第１のコンピュータシステムと前記第２のコンピュータシステム（１０）とを連結する論理システム（１８、２０、２２、２４）を使用して、前記各ユーザプログラムの状態に関する情報を交換する
ことをさらに含む請求項２に記載の方法。
【請求項４】
非決定的実行を行う第３のプロセッサ（ＰＡ、ＰＢ、ＰＣ）で前記ユーザプログラムの複製コピーを実行することをさらに含み、
前記第１のプロセッサ、前記第２のプロセッサおよび前記第３のプロセッサ（ＰＡ、ＰＢ、ＰＣ）における前記実行は、サイクルごとのロックステップではない
請求項１に記載の方法。
【請求項５】
前記非決定性は、タイミング非決定性、アーキテクチャ上可視的でない非決定性、または、データアクセスにおけるエラーハンドリングに関係した非決定性の群から選択された少なくとも１つを含む
請求項１に記載の方法。
【請求項６】
第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）と、
前記第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）に連結された第２のプロセッサと
を備え、
前記プロセッサは、前記第１のプロセッサがユーザプログラムを実行し、前記第２のプロセッサが前記ユーザプログラムの複製コピーを実行する、前記ユーザプログラムのフォールトトレランスコピーを実行し、
前記第１のプロセッサおよび前記第２のプロセッサでの前記ユーザプログラムの前記実行は、厳密なロックステップではなく、
前記第１のプロセッサおよび前記第２のプロセッサは、それらの各ユーザプログラムを非決定的に実行する
システム。
【請求項７】
前記第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）を備える第１のコンピュータシステム（１０）と、
前記第２のプロセッサを備える第２のコンピュータシステムと、
前記第１のコンピュータシステムと前記第２のコンピュータシステム（１０）とを連結する投票者論理回路システム（５６）と
をさらに備え、
前記投票者論理回路（５６）は、入出力（Ｉ／Ｏ）デバイス（１４、１６）に向けられた複製読み出し要求を前記プロセッサから受信し、この要求を単一の要求に集約し、この単一の要求を前記Ｉ／Ｏデバイス（１４、１６）に転送する
請求項６に記載のシステム。
【請求項８】
前記第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）を備える第１のコンピュータシステム（１０）と、
前記第２のプロセッサ（ＰＡ、ＰＢ、ＰＣ）を備える第２のコンピュータシステム（１０）と、
前記第１のコンピュータシステムと前記第２のコンピュータシステム（１０）とを連結する投票者論理回路システム（５６）と
をさらに備え、
前記投票者論理回路（５６）は、各プロセッサ上で実行されるソフトウェアに向けられた要求を外部デバイスから受信し、この要求を複製し、この要求を、各プロセッサに１つずつ転送する
請求項６に記載のシステム。
【請求項９】
前記第１のプロセッサ（ＰＡ、ＰＢ、ＰＣ）を備える第１のコンピュータシステム（１０）と、
前記第２のプロセッサ（ＰＡ、ＰＢ、ＰＣ）を備える第２のコンピュータシステム（１０）と、
前記第１のコンピュータシステムと前記第２のコンピュータシステム（１０）とを連結する投票者論理回路システム（５６）と
をさらに備え、
前記投票者論理回路（５６）は、入出力（Ｉ／Ｏ）デバイス（１４、１６）に向けられた複製書き込み要求を受信し、この要求を単一の要求に集約し、この単一の要求を前記Ｉ／Ｏデバイス（１４、１６）に転送する
請求項６に記載のシステム。
【請求項１０】
前記ユーザプログラムの前記非決定的な実行は、タイミング非決定性、アーキテクチャ上可視的でない非決定性、または、データアクセスにおけるエラーハンドリングに関係した非決定性の群から選択された少なくとも１つを含む
請求項６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
この出願は、仮出願第６０／５５７８１２号の利益を主張する。
この仮出願は、参照によって、あたかも以下に完全に再現されたかのように本明細書に援用される。
さらに、この出願は、同時に出願された出願である「Method and System of Servicing Asynchronous Interrupts in Multiple Processors Executing a User Program」という発明の名称の出願第１１／０４２４２９号、「Method and System of Exchanging Information Between Processors」という発明の名称の出願第１１／０４２９８５号、および「Method and System of Determining Whether a User Program Has Made a System Level Call」という発明の名称の出願第１１／０４２９８１号に関連する。
【背景技術】
【０００２】
［背景］
少なくとも２つのタイプの計算障害が、コンピュータシステム設計者にとって問題となりうる。
第１の障害は、プロセッサの故障や回復不可能なメモリエラー等のハードウェアの故障でありうる。
第２の障害は、ハードウェアのビットの状態を変化させる宇宙線によって引き起こされうるような計算障害でありうる。
コンピュータシステムが、ハードウェアの障害後も引き続き動作したり、計算障害を検出して計算障害から回復したりするために、ある計算システムは、同じソフトウェアアプリケーションを実行する複数のプロセッサを有する。
それらプロセッサの１つが、ハードウェアの故障を経験した場合に、その計算は、その時点でもまだ適切に機能している１つまたは２つ以上のプロセッサで継続する。
複数のプロセッサの出力を比較することによって、計算障害の検出および訂正が、可能にされうる。
【０００３】
場合によっては、同じソフトウェアアプリケーションを実行するプロセッサは、サイクルごとにまたは厳密なロックステップで動作し、各プロセッサは、複製クロック信号を供給され、サイクルごとに同じソフトウェアコードを実行する。
プロセッサのクロック周波数が増加している一方で、チップのサイズも増大している。
クロック周波数が増加すると、チップサイズの増大と組み合わさって、コンピュータシステムのクロック信号の位相差の制御が困難となり、したがって、厳密なロックステップの実施も困難となる。
さらなる困難は、或るプロセッサ内では発生しているが、それ以外のプロセッサ内では発生していない回復可能なエラー（ソフトエラー）のハンドリングを含む。
これら困難に対処するために、あるコンピュータ製造者は、プロセッサが同じコードを実行するが、必ずしもサイクルごとの形式または同じ壁時計時刻で実行しない緩やかなロックステップシステムを実施する。
同じコードを実行するプロセッサが、互いにあまりにも遠く隔たらないことを確保するために、これらのシステムは、実行された命令をカウントし、所定の個数の命令の終了後、速いプロセッサを引き止めて、遅いプロセッサが追いつくことを可能にすることによって同期する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、プロセッサ設計の振興技術によって、非決定的プロセッサの実行が可能になっている。
非決定的プロセッサの実行は、同じソフトウェアアプリケーション命令を提供された複数のプロセッサが、必ずしも同じ順序で、または、同じ個数のステップを使用して、命令を実行しないことを意味し得る。
これらの相違は、プロセッサ内で実施された投機的実行（分岐予測等）、アウトオブオーダ処理、ソフトエラー回復等の進行に起因しうる。
このように、同じソフトウェアアプリケーションを実行する２つまたは３つ以上のプロセッサは、同じ命令シーケンスを正確に実行しないことがあり、したがって、厳密なロックステップフォールトトレランスが不可能な場合があるだけでなく、終了した命令（retired instruction）をカウントすることに依拠する緩やかなロックステップフォールトトレランスも不可能な場合がある。
【課題を解決するための手段】
【０００５】
次に、本発明の例示の実施の形態を詳細に説明するために、添付図面を参照する。
【０００６】
［表記法および用語体系］
以下の説明および特許請求の範囲の全体にわたって、特定のシステムコンポーネントを指すために、一定の用語が使用される。
当業者には理解されるように、コンピュータ製造会社は、１つのコンポーネントを異なる名前で指しうる。
この文書は、名前では異なるが機能では異ならないコンポーネントを区別することは意図していない。
【０００７】
以下の説明および特許請求の範囲において、用語「含む」および「備える」は、オープンエンド形式で使用され、したがって、「〜を含むが、これらに限定されるものではない」ことを意味するように解釈されるべきである。
また、用語「連結する」は、間接的な接続または直接的な接続のいずれをも意味するように意図されている。
したがって、第１のデバイスが第２のデバイスに連結する場合、その接続は、直接的な接続を通じて行われうるし、他のデバイスおよび接続を介して、間接的な電気接続を通じても行われうる。
【発明を実施するための最良の形態】
【０００８】
［詳細な説明］
以下の説明は、本発明のさまざまな実施の形態を対象とする。
これらの実施の形態の１つまたは２つ以上が好適とされうるが、開示した実施の形態は、この開示の範囲を限定するとして解釈されるべきでもなく、その他の方法で使用されるべきでもない。
さらに、以下の説明が広い用途を有し、どの実施の形態の説明も、その実施の形態の例示にすぎないように意図されており、開示の範囲がその実施の形態に限定されることを暗示するように意図されていないことが、当業者には理解されよう。
【０００９】
図１は、本発明の実施の形態による計算システム１０００を示している。
詳細には、計算システム１０００は、複数のマルチプロセッサコンピュータシステム１０を備えうる。
いくつかの実施の形態では、２つのマルチプロセッサコンピュータシステム１０のみが使用されることがあり、したがって、計算システム１０００は、２重化冗長構成（ＤＭＲ（dual-modular redundant））システムを実施しうる。
図１に示すように、計算システム１０００は、３つのマルチプロセッサコンピュータシステム１０を備え、したがって、３重化冗長構成（ＴＭＲ（tri-modular redundant））システムを実施する。
コンピュータシステムが２重化冗長構成であるのか、それとも３重化冗長構成であるのかにかかわらず、計算システム１０００は、これらのマルチプロセッサコンピュータシステム間でユーザプログラムを冗長に実行することによってフォールトトレランスを実施する。
【００１０】
本発明の実施形態によると、各マルチプロセッサコンピュータシステム１０は、好適には、１つまたは２つ以上のプロセッサを備え、図１に示すように、４つのプロセッサを備える。
図１の各プロセッサは、プロセッサを示す頭文字「Ｐ」を有する。
さらに、各プロセッサは、そのプロセッサの物理的な位置が、それぞれ、マルチプロセッサコンピュータシステム１０Ａ、１０Ｂおよび１０Ｃの１つにあることを示す「Ａ」、「Ｂ」、または「Ｃ」の文字符号を与えられる。
最後に、各プロセッサは、各マルチプロセッサコンピュータシステム内におけるそのプロセッサの位置を示す数字符号を与えられる。
したがって、例えば、マルチプロセッサコンピュータシステム１０Ａのプロセッサは、符号「ＰＡ１」、「ＰＡ２」、「ＰＡ３」および「ＰＡ４」を有する。
【００１１】
本発明の実施の形態によると、各マルチプロセッサコンピュータシステム１０からの少なくとも１つのプロセッサは、論理的にグループ化されて、論理プロセッサ１２を形成しうる。
図１の例示の実施の形態では、プロセッサＰＡ３、ＰＢ３およびＰＣ３がグループ化されて、論理プロセッサ１２を形成する。
本発明の実施の形態によると、論理プロセッサ内の各プロセッサは、ユーザプログラムの複製コピーをほぼ同時に実行し、したがって、フォールトトレランスを実施する。
より詳細には、論理プロセッサ内の各プロセッサは、ユーザプログラムの同じ命令ストリームを提供され、（エラーがないと仮定して）同じ結果を計算する。
しかし、論理プロセッサ内のプロセッサは、サイクルごとでもなければ、厳密なロックステップでもない。
逆に、プロセッサは、緩やかなロックステップとされており、同期および割り込みのハンドリングが、ランデブーポイント（以下で説明）に基づいて行われる。
いくつかの実施の形態によると、プロセッサは、非決定的な実行を有することができ、したがって、厳密なロックステップが不可能な場合がある。
プロセッサの１つが故障すると、残りの１つまたは２つ以上のプロセッサが、システム全体の性能に影響を与えることなく、処理を続行しうる。
【００１２】
論理プロセッサ内の２つまたは３つ以上のプロセッサが、同じユーザプログラムを実行しうるので（in as much as）、入出力（Ｉ／Ｏ）デバイス１４および１６に対する読み出しおよび書き込み等の複製読み出しおよび複製書き込みが、生成されうる。
Ｉ／Ｏデバイス１４および１６は、任意の適切なＩ／Ｏデバイスであってよく、例えば、ネットワークインターフェースカード、フロッピィドライブ、ハードディスクドライブ、ＣＤＲＯＭドライブおよび／またはキーボードであってよい。
障害検出目的でこれらの読み出しおよび書き込みを比較するために、各論理プロセッサは、自身を同期論理回路に関連付けている。
例えば、プロセッサＰＡ１、ＰＢ１およびＰＣ１は、同期論理回路１８に関連付けられた論理プロセッサを形成しうる。
同様に、プロセッサＰＡ２、ＰＢ２およびＰＣ２も、同期論理回路２０に関連付けられた論理プロセッサを形成しうる。
論理プロセッサ１２は、同期論理回路２２に関連付けうる。
最後に、プロセッサＰＡ４、ＰＢ４およびＰＣ４は、同期論理回路２４に関連付けられた論理プロセッサを形成しうる。
したがって、各マルチプロセッサコンピュータシステム１０は、それぞれを、相互接続部２６を経由して、同期論理回路１８、２０、２２、および２４のそれぞれに連結しうる。
相互接続部２６は、周辺機器相互接続（ＰＣＩ）バスであってよく、特に、直列化ＰＣＩバスであってよい。
ただし、他のバスおよび／またはネットワーク通信方式が、同等に使用されうる。
【００１３】
各同期論理回路１８、２０、２２および２４は、例えば、同期論理回路２２の投票者論理回路２８といった投票者論理ユニットを備える。
以下の説明は、同期論理回路２２の投票者論理回路２８を対象にしているが、同期論理回路１８、２０、２２および２４のそれぞれの各投票者論理ユニットにも等しく適用しうる。
投票者論理回路２８は、プロセッサからの読み出し要求および書き込み要求を集約するように動作し、プロセッサ間の情報交換の役割を果たす。
説明のために、論理プロセッサ１２の各プロセッサがユーザプログラムの自身のコピーを実行することについて考察し、各プロセッサがネットワークインターフェース３４に対する読み出し要求を生成することについて考察する。
論理プロセッサ１２の各プロセッサは、自身の読み出し要求を投票者論理回路２８に送信する。
投票者論理回路２８は、各読み出し要求を受信し、それら読み出し要求を比較し、（読み出し要求が一致すると仮定して）ネットワークインターフェース３４に単一の読み出し要求を発行する。
【００１４】
同期論理回路が発行した単一の読み出し要求に応答して、例示のネットワークインターフェース３４は、要求された情報を投票者論理回路２８に返信する。
次に、投票者論理回路は、要求された情報を複製して、論理プロセッサ内のプロセッサのそれぞれに渡す。
同様に、パケットメッセージの書き込みや他のプログラム（他の論理プロセッサ上で実行されることがある）へのパケットメッセージの転送等の他の入出力機能についても、同期論理回路は、それらの要求が一致することを確認し、次いで、単一の要求を適切な位置に転送する。
論理プロセッサのいずれか１つのプロセッサが適切に機能しない場合（例えば、要求を生成できない場合、指定された時間内に要求を生成できない場合、一致しない要求を生成する場合、または、完全に故障している場合）、ユーザプログラムは、論理プロセッサの残りの１つまたは複数のプロセッサの要求に基づいて続行しうる。
同様に、外部で生成された通信についても、同期論理回路は、その外部通信を複製し、各プロセッサにその通信を提供する。
外部で生成された要求が、ダイレクトメモリアクセス（リモートＤＭＡとしても知られている）を求めるものである場合には、同期論理回路は、それらの要求を複製して分配し、それらの要求に基づいて、各プロセッサが提供したデータを比較して集約する。
【００１５】
外部インターフェース（ネットワークインターフェース３４等）に対する読み出しおよび書き込みの集約、および、それら外部インターフェースからのメッセージおよびデータの複製に加えて、同期論理回路は、日時情報の要求が行われた時に、各プロセッサに同じ日時が確実に提供されるようにする役割も果たす。
詳細には、ユーザプログラムは、それらユーザプログラムの実行における一定のポイントで、日時情報を要求するシステムコールを行うことがある。
システムコールは、オペレーティングシステムプログラム等の（ユーザモードよりも高い特権モードで実行される）特権プログラムに対するあらゆるコールである。
日時情報を得るためのシステムコールは、システムコールのカテゴリーに分類されるプログラムファミリーの単なる一例にすぎず、論理プロセッサ内のプロセッサ間のユーザプログラムを同期させる際のシステムコールの役割、および、割り込みをハンドリングする際のシステムコールの役割は、以下でより十分に説明される。
ユーザプログラムにおける対応する実行ポイントにおいて、各ユーザプログラムが、（それらの実行ポイントに到達した時の壁時計時刻が異なるにもかかわらず）同じ日時を提供されるために、本発明の実施の形態による同期論理回路は、論理プロセッサ内の各プロセッサに日時情報を提供する。
すなわち、各プロセッサでの各ユーザプログラムにおける、割り込みにサービスを提供するポイントをスケジューリングするプロセスの一部として（以下でより十分に説明する）、同期論理回路が、各プロセッサに日時情報を提供する。
本発明の実施の形態による日時システムコールは、ユーザプログラムがそのような要求を行った時の日時を内部で導出するのではなく、同期論理回路が提供する最も近時の日時情報を利用する。
このように、各ユーザプログラムは、それらユーザプログラムが正確に同じ壁時計時刻で実行されているかどうかとは関係なく、同じ日時情報を提供される。
【００１６】
図２は、マルチプロセッサコンピュータシステム１０をより詳細に示している。
詳細には、図２は、本発明の実施の形態によるマルチプロセッサコンピュータシステム１０が、複数のプロセッサを有することができ、図２の例示の事例では４つのこのようなプロセッサ３４、３６、３８および４０を有することを示している。
４つのプロセッサのみが示されているが、本発明の範囲および精神から逸脱することなく、任意の個数のプロセッサが使用されうる。
プロセッサ３４〜４０は、個別にパッケージングされたプロセッサであってもよく、プロセッサのパッケージは、単一のパッケージ内に２つまたは３つ以上のプロセッサチップを備えるか、または、単一のチップ上に複数のプロセッサを備える。
プロセッサのそれぞれは、プロセッサバス４４を経由して、Ｉ／Ｏブリッジおよびメモリコントローラ４２（以下、Ｉ／Ｏブリッジ４２という）に連結されうる。
Ｉ／Ｏブリッジ４２は、メモリバス４５を経由して、プロセッサ３４〜４０を１つまたは２つ以上のメモリモジュール４６に連結する。
したがって、Ｉ／Ｏブリッジ４２は、１つまたは２つ以上のメモリモジュール４６によって画定されたメモリ領域に対する読み出しおよび書き込みを制御する。
また、Ｉ／Ｏブリッジ４２は、バスライン４３によって示されるように、プロセッサ３４〜４０のそれぞれが同期論理回路（図２には図示せず）に連結することも可能にする。
【００１７】
図２をさらに参照して、１つまたは２つ以上のメモリモジュール４６によって画定されたメモリは、各プロセッサにつき１つのパーティションとして区画されうる。
したがって、プロセッサのそれぞれは、独立に動作することが可能になる。
代替的な実施の形態では、各プロセッサは、それ自身の集積されたメモリコントローラを有することができ、したがって、各プロセッサは、それ自身の専用メモリを有することができ、これも本発明の考慮の範囲内にある。
マルチプロセッサコンピュータシステム１０がその一部を成しうる計算システム１０００は、論理プロセッサ内のプロセッサ間で、ユーザプログラムの緩やかなロックステップ実行を実施する。
緩やかなロックステップは、論理プロセッサ（例えば、論理プロセッサ１２）の各プロセッサがユーザプログラムの複製コピーを実行できるが、その命令は厳密なロックステップ形式で実行する必要もなければ、同じ壁時計時刻で実行する必要もないことを意味しうる。
したがって、プロセッサ３４〜４０は、非決定的プロセッサを含めて（これに限定されるものではない）、さまざまなアーキテクチャであってもよい。
非決定的プロセッサは、厳密なロックステップ実行に適合しなくてもよく、終了した命令のカウントに基づかなくてもよい。
Ｉｎｔｅｌ（登録商標）のＩｔａｎｉｕｍ（登録商標）プロセッサファミリー（ＩＰＦ）は、非決定的な実行を行い、したがって、厳密なロックステップ実行にも適合せず、終了した命令のカウントにも基づかないプロセッサファミリーの一例である。
【００１８】
図２は、さらに、各マルチプロセッサコンピュータシステム１０が、Ｉ／Ｏブリッジ４２とメモリモジュール４６との間に連結された再統合論理回路４８を備えることも示している。
図１の例示の実施の形態は、再統合論理回路の相互接続部（ライン５１）をリング形で示しているが、任意のネットワークトポロジーが、同等に使用されうる（例えば、リング、ツリー、２重リング、完全接続）。
動作時において、再統合論理回路４８は、Ｉ／Ｏブリッジ４２に対してトランスペアレントであり、１つまたは２つ以上のメモリモジュール４６に対する読み出しおよび書き込みと連係しない。
しかしながら、論理プロセッサ内の或るプロセッサが障害を経験し、再起動される必要がある場合に、再統合論理回路４８は役割を果たす。
【００１９】
プロセッサの再起動時には、エラーを経験しなかった論理プロセッサ内のプロセッサと同じポイントで、ユーザプログラムの実行を開始することが望ましい。
換言すると、再起動されるプロセッサは、そのプロセッサが一時的な故障またはハードウェアエラーを経験したポイントではなく、他のプロセッサがユーザプログラムにおいて到達したポイントで再開する（pick up）ことができる。
図２に示す実施の形態では、各マルチプロセッサコンピュータシステム１０の再統合論理回路４８は、そのメモリを、そのプロセッサのうちの１つのエラーを経験しなかった故障していないマルチプロセッサコンピュータシステムのメモリから複製する。
したがって、図１を再び参照して、再起動されるマルチプロセッサコンピュータシステムが、論理パーティションの他のプロセッサと同じ状態から開始できるように、マルチプロセッサコンピュータシステム１０のそれぞれが、メモリパーティションの複製を容易にするために共に連結された自身の再統合論理回路４８を有することを、ライン５１は示している。
マルチプロセッサコンピュータシステムの或るプロセッサの故障によるメモリ全体の複製およびその後のマルチプロセッサコンピュータシステムの全プロセッサの再起動は、単一のメモリコントローラ（Ｉ／Ｏブリッジ）４２のみを有することによって指令されうる。
代替的な実施の形態では、複数のメモリコントローラ（例えば、各プロセッサにつき１つ）が存在してもよく、したがって、メモリの一部のみが、複製されればよく（すなわち、再起動を必要とするプロセッサにより使用されるメモリコントローラに対応するメモリパーティション）、同様に、プロセッサの一部のみが、再起動されればよい（すなわち、複製されたメモリに関連するプロセッサ）。
【００２０】
緩やかなロックステップシステムでは、或るプロセッサが進んだり遅れたりすることがある理由は、多く存在し得る。
例えば、各プロセッサは、ほぼ同じクロック周波数で命令を実行しうる一方、実際のクロック周波数の差は小さくても、時間の経過によってかなりの差になりうる（タイミング非決定性）。
その上、本発明の少なくともいくつかの実施の形態に従って実施されたプロセッサは、非決定的な実行を有し、したがって、たとえ正確に同じユーザプログラムが提供されても、プロセッサは、ユーザプログラムの共通のポイントに到達する実行ステップ数において、大きく乖離しうる。
さらにまた、いくつかのプロセッサは、データアクセス遅延および／または定着性エラー（fixable error）（アーキテクチャ上可視的でない状態非決定性（non-architecturally visible state nondeterminism））に遭遇する。
いくつかの例は、或るプロセッサが、他のプロセッサが経験することができないキャッシュミスを経験することがある、或るプロセッサが訂正可能なメモリエラーを経験することがあり、したがって、残りのプロセッサには必要とされない回復ルーチンの実行を必要とする、および、或るプロセッサが変換索引バッファのミスを経験することがあり、それによって、ユーザプログラムの最終結果に影響を与えないが付加的処理が行われる、という例である。
これらの場合も、プロセッサは、最終的に、ユーザプログラムの同じ実行ポイントに到達するが、実行される命令数およびそれらの命令を実行するために必要な時間は、同じでないことがある。
【００２１】
論理プロセッサにおけるプロセッサが、同じ命令ストリームを実行しているが、その命令ストリームの同じポイントに存在しないことがあるという考えに留意して、説明は、このような環境における割り込みのハンドリングに移る。
たとえ、同じ割り込みが、正確に同じ壁時計時刻で各プロセッサにアサートされても、それら各プロセッサの緩やかなロックステップステップ実行により、割り込みは、ユーザプログラムの同じ実行ポイントでアサートされないことがある。
この問題は、割り込みアサート自体が非同期であることによって、さらに激化する。
適切なオペレーションを確保するために、論理プロセッサ内の各プロセッサは、ユーザプログラムの命令ストリームの同じ実行ポイントで、割り込みにサービスを提供する必要がある。
本発明の実施の形態によると、割り込みが命令ストリームの同じ実行ポイントでサービスを受けることを確保することは、割り込みにサービスを提供するためのランデブーポイントについて合意するメカニズムとして同期論理回路を利用することによって行われる。
【００２２】
本発明の実施の形態によると、論理プロセッサ内のプロセッサは、特定の割り込みがアサートされたことと、実行を一時停止して割り込みにサービスを提供するユーザプログラムで提案されたポイントとを互いに通信する。
換言すると、論理プロセッサ内のプロセッサは、どの割り込みにサービスを提供すべきか（または最初にサービスを提供すべきか）について合意し、また、割り込みにサービスを提供するユーザプログラムのポイントについても合意する。
図３は、協力して割り込みのサービス提供を調整するさまざまなコンポーネントのオペレーションを説明するために、部分的な計算システム１０００を示している。
図３は、論理プロセッサ５０が、この場合に、２つのプロセッサＰＡ１およびＰＢ１のみを備えるという意味で、図１のシステムが簡略化された説明である。
また、図３は、別の意味では、各プロセッサのメモリパーティション５２を示し、プロセッサがＩ／Ｏブリッジ４２を通じてメモリパーティションおよび投票者論理回路にどのように連結するかを示しているので、図１よりも詳細化されている。
このように、図３の論理プロセッサ５０は、マルチプロセッサコンピュータシステム１０Ａおよび１０Ｂからのそれぞれ１つのプロセッサを備える。
プロセッサＰＡ１は、Ｉ／Ｏブリッジ４２Ａに連結し、Ｉ／Ｏブリッジ４２Ａは、同期論理回路１８およびＰＡ１プロセッサのメモリパーティション５２Ａの双方に連結する。
プロセッサＰＢ１は、その各Ｉ／Ｏブリッジ４２Ｂに連結し、Ｉ／Ｏブリッジ４２Ｂは、同期論理回路１８およびＰＢ１プロセッサのメモリパーティション５２Ｂに連結する。
【００２３】
少なくともいくつかの実施の形態によると、論理プロセッサにおけるプロセッサに、ランデブーポイントを確立するための情報を交換させるには、各プロセッサが、同期論理回路１８の投票者論理回路５６における同期レジスタ５４に情報を書き込むことが必要とされる。
本発明の実施の形態によると、ランデブーポイントは、任意の適切な位置とすることができ、オペレーティングシステムのディスパッチャ機能が実行され、他のタスクを実行に設定する各時刻、トラップおよび障害ハンドラ、ユーザプログラムが行ったシステムコール等とすることができる。
用語「システムコール」は、この明細書および特許請求の範囲では、任意の可能なランデブーポイントを指すために使用される。
システムコール番号は、システムコールが任意の開始点（starting point）から行われた回数を示す番号であってよい。
図３の位置７２は、システムコール番号が存在できるメモリパーティション５２の位置を示している。
代替的な実施の形態では、システムコール番号は、メモリパーティション５２以外に位置するレジスタにも同等に記憶されうる。
図３に示す実施の形態では、同期レジスタ５４は、事前に設計されたメモリ位置であるが、データを書き込むことができる位置ならばどの位置でも十分である。
プロセッサの一部またはすべてが自身の各情報を書き込んだ後、投票者論理回路５６は、同期レジスタ５４の情報を、メモリパーティション５２のそれぞれの対応するレジスタセット５７にライトバックする。
また、投票者論理回路５６は、ライトバックオペレーション中にレジスタ５７に、日時情報等の他の情報を書き込むこともできる。
同期論理回路へ情報を書き込むことによって、残りのプロセッサが割り込みを調べることを待っている間、ユーザプログラムの処理が継続することが可能になる。
代替的な実施の形態では、各プロセッサは、同期レジスタ５４のメモリ位置に対する待機読み出し（waited read）を行うことができる。
待機することは、各プロセッサが割り込みに関する対応する情報を書き込むまで、読み出しが完了しないことを意味する。
副作用としての待機読み出しは、プロセッサを同期させるように動作するが、各プロセッサは、その読み出しの完了をソフトウェアループで待機し、したがって、割り込みに関する情報を交換するメカニズムとしての待機読み出しによって、ユーザプログラムは、実行を継続することができない。
データ交換がどのように実行されるかにかかわらず、情報を交換することによって、論理プロセッサ内のプロセッサは、ユーザプログラムのどのポイントで割り込みにサービスを提供するかを調整する。
【００２４】
割り込みは、割り込み情報を含んだパケットベースのメッセージを介して、または、専用割り込み信号ラインを介して、任意の時刻に、プロセッサにアサートされうる。
また、割り込みは、或るプロセッサクロックサイクル数の後に満了するように設定されたタイマ等の内部信号源からも、プロセッサにアサートされうる。
このようなパケット、信号ラインまたは内部割込みが、プロセッサによって受信され検出されると、ユーザプログラムは一時停止され、割り込みハンドラルーチンが起動される。
割り込みハンドラルーチンの目的は、ランデブーポイントを識別するプロセスを開始することである。
割り込みによって要求されたサービスに関する動作は、割り込みハンドラルーチンによって行われない。
ランデブーポイント（例えば、システムコール）は、当該ランデブーポイントをスケジューリングするプロセスが完了したポイントであり、また、受信された割り込みにサービスを提供するプログラムをスケジューリングするポイントでもある。
【００２５】
図４は、本発明の実施の形態による１組のイベントの例示の時間表（時間はページの下方に向かって増加する）を示している。
参照符号ＰＡ１およびＰＢ１の下にある縦のバーは、それぞれ、それらのプロセッサによるプログラムの実行を表している。
これら縦のラインの間にあるブロックは、ハードウェアおよび／またはイベントを表し、中央のブロックと縦のバーとの間のラインは、時間に応じたさまざまなコンポーネントの相互作用を表している。
図３および図４を同時に参照して、各プロセッサが（ブロック５８および縦のバーのそれぞれを指し示す矢印によって示すように）割り込みを受信すると仮定する。
図示するように、割り込みは、異なる時刻に各プロセッサにアサートされる。
割り込みが受信されると、ユーザプログラムは一時停止され、割り込みハンドラルーチンが（クロスの網掛け領域５９によって例示されるように）実行される。
割り込みハンドラルーチンは、割り込みの性質を判断し、割り込みにサービスを提供するための提案されたシステムコール番号と共に、割り込みに関する情報を同期レジスタに書き込む。
割り込み情報および提案されたシステムコール番号の書き込みは、ライン６０によって図示される。
ライン６０は、プロセッサＰＡ１が割り込み５を受信したこと、および、このプロセッサがシステムコール番号１００１で割り込みにサービスを提供することを提案することを例示している。
プロセッサＰＢ１についても同様に、割り込みは、ユーザプログラムにおいてわずかに異なる時刻にアサートされうるが、割り込みハンドラルーチンが、その後直ちに実行され（クロスの網掛け領域５９）、この割り込みハンドラルーチンは、ライン６２によって示すように、割り込みが受信されたことの表示と、その割り込みにサービスを提供するための提案されたシステムコール番号とを同期レジスタ５４に書き込む。
割り込みハンドラルーチンが、同期レジスタへのその書き込みを完了するとすぐに、ユーザプログラムは、実行を継続する（ポイント６１および６３で開始する）。
【００２６】
論理プロセッサ内の全プロセッサが、自身の各データを同期レジスタ５４に書き込むと、投票者論理回路５６は、同期レジスタ５４の情報の少なくとも一部を、論理プロセッサにおける各プロセッサのメモリパーティションの対応するレジスタ５７に書き込む。
本発明の少なくともいくつかの実施の形態によると、全プロセッサからの情報は、日時情報と共に、各個々のプロセッサにライトバックされる。
【００２７】
いくつかの実施の形態では、割り込みにサービスを提供するためのシステムコール番号は、論理プロセッサ内のプロセッサのいずれかにより提案される最も高いシステムコール番号である。
各個々のプロセッサが、指定されたシステムコール番号に到達する（例えば、各個々のプロセッサが、システムコール番号が最も高い提案されたシステムコール番号である日時コールを行う）と、各個々のプロセッサのシステムコールプログラムは、その指定されたタスクを実行することに加えて、割り込みサービスルーチンを、実行のためにその各ディスパッチキューに置く。
このように、プロセッサＰＡ１は、事前に決定されたシステムコール番号（この事例ではＳＣＮ１００１、ＰＡ１の時間表の斜線領域６４によって示す）の実行直後に、（斜線領域６７によって示すように）割り込み５のサービスルーチンを実行する。
代替的に、サービスルーチンは、システムコールの直前に実行されてもよい。
その後、遅れているプロセッサＰＢ１が、事前に決定されたシステムコール番号（ＳＣＮ１００１）に到達し、そのシステムコールを実行し（斜線領域６６）、そして、例示の割り込み５の割り込みサービスルーチンを実行する（ＰＢ１の時間表の斜線領域６７）。
このように、双方のプロセッサは同時に割り込みを受信せず、プロセッサは緩やかにしかロックステップされていないが、割り込みは、ユーザプログラムの同じポイントでサービスを受ける。
図４に示すように、割り込みを受信して割り込みハンドラルーチンを実行した後、割り込みサービスルーチンを実行するためのシステムコール番号に到達するまでは、各プロセッサ内の通常の処理が継続することに留意されたい。
また、図４の例示の事例では、プロセッサは、ユーザプログラムの実行ポイントに関して、最小限に相違するだけであり、したがって、図示した方法では、プロセッサは、時間をかせぐこともしないしスローにもならないことにも留意されたい。
図４に示すイベントの列は、簡単な事例であり、本発明の実施の形態による割り込みハンドリングの本質に読み手をなじませるために提示される。
他の事例は、割り込みハンドラルーチンが行うステップ、および、本発明の実施の形態によるシステムコールが実行するステップのより詳細な説明の後に、以下に提示される。
【００２８】
図５（図５Ａおよび図５Ｂを含む）は、本発明の実施の形態による割り込みハンドラルーチンのフロー図を示している。
このプロセスは、割り込みのアサートおよび割り込みハンドラルーチンの実行によって開始することができる（ブロック５００）。
次のステップは、割り込みを無効にすることとすることができる（ブロック５０２）。
このステップに続いて、割り込みハンドラをトリガした割り込みが、非協調プロセスタイマの満了であったかどうかが判断される（ブロック５０４）。
非協調プロセスタイマが、割り込みハンドラのこのインスタンスを引き起こした場合には、非協調プロセスハンドラが呼び出される（ブロック５０６）。
非協調プロセス、および、本発明の実施の形態によるそれら非協調プロセスをハンドリングする方法は、図１２について以下でより十分に説明される。
割り込みは、非協調プロセスタイマの満了によって引き起こされないと仮定すると、このトリガ割り込みは、割り込みタイプの表示を含めて、保留リストに加えられる（ブロック５０８）。
Ｉｔａｎｉｕｍ（登録商標）プロセッサファミリーからのプロセッサを実施するシステムでは、割り込みタイプの決定は、割り込みベクトルレジスタ（ＩＶＲ）を読み出すことによって行われうる。
したがって、保留リストは、アサートされた割り込みのリストであるが、それらの割り込みに対して、ランデブーポイントをスケジューリングするプロセスは、まだ開始していない。
【００２９】
例示のプロセスの次のステップは、まだ完了していないランデブーポイントのスケジューリングの試みがあったかどうかの判断でありうる（ブロック５１０）。
プロセッサの見地から、ランデブーのスケジューリングは、提案されたランデブー情報を同期レジスタ５４に書き込むこと、および、論理プロセッサの一部またはすべてのプロセッサから確認を受信することの２ステップのプロセスとすることができる。
したがって、まだ完了していないランデブーポイントのスケジューリングは、まだ返されていないデータが同期レジスタ５４へ書き込まれた状況、または、データは返されたが、まだ解析されていない状況とすることができる。
ランデブーポイントをスケジューリングする未処理の試みが存在しない場合、例示の方法は、最も高い優先度の割り込みを、保留リストから選択することができる（ブロック５１２）。
この最も高い優先度の割り込みは、トリガ割り込みであってもよいし、保留リストに先に置かれた他のより高い優先度の割り込みであってもよい。
代替的な実施の形態は、複数の最も高い優先度の割り込みを、保留リストから選択しうる。
その後、メモリパーティションのレジスタ５７（このレジスタ５７に、投票者論理回路は最終的にデータを書き込む）はクリアされ、割り込み番号、および、割り込みにサービスを提供するための提案されたシステムコール番号が、同期レジスタ５４に書き込まれる（ブロック５１４）。
システムコール番号は、（図３に位置７２によって示すように）各プロセッサのメモリパーティション５２内に存在する番号であってよい。
この番号は、任意の開始ポイントから行われたシステムコールの回数を示す。
本発明の少なくともいくつかの実施の形態によると、提案されたシステムコール番号は、１つずつインクリメントされる現在のシステムコール番号であってよい。
２つ以上ずつシステムコール番号をインクリメントして、提案されたシステムコール番号を作成することも、本発明の範囲および精神の範囲内にある。
割り込み識別子および提案されたシステムコール番号の書き込み（ブロック５１２）は、図４では、（プロセッサＰＡ１については）ライン６０および（プロセッサＰＢ１については）ライン６２によって示されている。
【００３０】
次に、即時動作割り込み（immediate action interrupt）を説明するために迂回して、同期レジスタへの書き込みの後、プロセスの次のステップは、割り込み番号および提案されたシステムコール番号を保留ランデブーログに書き込んで、保留リストから割り込み（または複数の割り込み）を削除することとすることができる（ブロック５１８）。
したがって、保留ランデブーログは、提案は行われているが、確認がまだ受信されていないか、または、合意に達していない割り込みのリストである。
他のプロセッサが合意した確認が、投票者論理回路から受信されると、図５を実施するプログラムに加えて、他のプログラム（詳細には、図７について説明するようなシステムコールプログラム）も、保留ランデブーログからそのエントリをクリアする。
本発明の少なくともいくつかの実施の形態によると、保留ランデブーログは、各プロセッサのメモリパーティション内の１組のメモリ位置４６（図３参照）であってよい。
その後、割り込みが有効にされ（ブロック５２０）、割り込みハンドラプロセスは終了する（ブロック５２２）。
次に、割り込みハンドラルーチンとの関連で即時動作割り込みの説明に移る。
【００３１】
図４について説明したように、ユーザプログラムは、割り込みのアサートの後に実行を再開することができ、したがって、プロセッサがどの割り込みにサービスを提供するかについて合意するための時間、および、割り込みにサービスを提供するためのシステムコール番号を与える。
一方、いくつかの割り込みは、（ユーザプログラムの継続実行を可能にすることなく）即座にサービスを受ける必要があり、したがって、「即時動作割り込み」と呼ばれうる。
即時動作割り込みは、ページフォールトに加えて、非協調プロセスを訂正する動作も含みうる。
即時動作型でない割り込みは、入出力（Ｉ／Ｏ）完了割り込み、キューに入れられたイベントの割り込み、および、ブートオペレーション中にプロセッサ間で情報を交換するソフトウェアイベント割り込みを含みうる。
まだ完了していないランデブーポイントをスケジューリングする試みがあったかどうかの判断（ブロック５１０）に戻って、ランデブーポイントをスケジューリングする未処理の試みが存在する場合、次のステップは、投票者論理回路が、先の未確認のランデブーポイントに関する情報をライトバックしたかどうかをチェックすることとすることができる（ブロック５２４）。
投票者論理回路が、まだデータをライトバックしていない場合（ブロック５２４）、次のステップは、保留リストに即時動作割り込みが存在するかどうかの判断とすることができる（ブロック５２８）。
即時動作割り込みが保留リストに存在しない場合には（ブロック５２８）、前の割り込みのランデブーポイントのスケジューリングはまだ完了していないので、割り込みが有効にされ（ブロック５２０）、そして、プロセスは終了し（ブロック５２２）、いくつかの実施の形態によると、一度に１つのスケジューリングの試みのみがアクティブにされうる。
他方、即時動作割り込みが、保留リストに存在する場合には（ブロック５２８）、プロセスは、前のスケジューリングの試みからのデータのライトバックをソフトウェアループで待機する（ブロック５３０）。
投票者論理回路が、レジスタ５７にデータをライトバックすると、プロセスは、図５Ｂの例示の方法のステップに移動する。
同様に、ランデブーポイントをスケジューリングする未処理の試みが存在し（ブロック５１０）、投票者論理回路がデータをライトバックしていた場合には（ブロック５２４）、図５Ｂの例示の方法のステップが起動される。
また、例示のプロセスは、ちょうど提案された割り込みが即時動作型であったかどうかの判断（ブロック５１６）を介して、ソフトウェアループで待機することにも達することができ（ブロック５３０）、その後、図５Ｂの例示のステップに達することができる。
【００３２】
図５Ｂは、投票者論理回路からのデータの返信に応答して行われるステップを示している。
詳細には、即時動作割り込みが、割り込みハンドラのこの実行において提案されたかどうかについての判断が行われる（ブロック５５０）。
（図５Ａの）ブロック５２４を経由してこの例示のサブプロセスに入った場合には、即時動作割り込みは、このプロセッサによって事前に提案されていなかったことになる。
一方、（図５Ａの）ブロック５３０を経由してこの例示のサブプロセスに入った場合には、即時動作割り込みが事前に提案されたか、または、保留リストに即時動作割り込みが存在する。
このプロセッサによる事前に提案された割り込みが、即時動作型でなかった場合には、他のプロセッサが、即時動作割り込みのサービス提供を提案したかどうかについての判断が行われる（ブロック５５２）。
提案した場合には、保留ランデブーログの割り込みが保留リストに戻され（ブロック５６０）、保留リストから最も高い優先度の割り込みを選択することから実行が再開する（図５Ａのブロック５１２）。
論理プロセッサの他のプロセッサが、即時動作割り込みにサービスを提供することを提案しなかった場合には（再びブロック５５２）、割り込みと、他のプロセッサが提案したそれら割り込みにサービスを提供するためのシステムコール番号とについての表記が、保留ランデブーログに行われる（ブロック５５３）。
その後、どの割り込みにサービスを提供するかについてプロセッサが合意するかどうかの判断（ブロック５５４）。
割り込みについて合意がある場合には、保留ランデブーログにおける当該合意のある１つまたは２つ以上の割り込みが、確認リストに移動され（ブロック５６２）、最も高い優先度の割り込みを保留リストから選択することから実行が再開される（図５Ａのブロック５１２）。
したがって、別のプロセッサが即時動作割り込みを提案した場合（ブロック５５２および５６０）を除いて、割り込みは、一旦保留ランデブーログに置かれると、それら割り込みにサービスを提供するプロセッサの合意があるまで、保留ランデブーログに留まることになる。
【００３３】
図５Ｂをさらに参照して、ブロック５５０に戻り、事前に提案された割り込みが即時動作型（ブロック５３０を通じたエントリ）であった場合、投票者論理回路により返信されたデータが解析されて、論理プロセッサ内の他のプロセッサが、即時動作割り込みにサービスを提供することを同様に提案したかどうかが判断される（ブロック５５８）。
提案した場合には、適切な即時動作割り込みサービスルーチンが起動され（ブロック５６４）、その表示が保留リストから削除され、サービスルーチンから復帰すると、最も高い優先度の割り込みを保留リストから選択することから実行が再開する（図５Ａのブロック５１２）。
プロセッサが合意しない場合、即時動作割り込みは、保留リストに再び置かれ（ブロック５６６）、最も高い優先度の割り込みを保留リストから選択することから実行が再開する（ブロック５Ａのブロック５１２）。
一方、この場合、リストにちょうど置かれた即時動作割り込みが、最も高い優先度の割り込みであり、したがって、図５の割り込みハンドラルーチンは、再度、論理プロセッサにおけるプロセッサに、その即時動作割り込みにサービスを提供することに合意させるプロセスを直ちに開始する。
【００３４】
図６は、同期論理回路１８内で実施されて、そのランデブーポイントスケジューリング部を実行することができるプロセスのフロー図を示している。
図６に示すステップは、同期論理回路の一部としてのプロセッサまたはマイクロコントローラ（具体的に図示せず）上で実行されるソフトウェアで実施されうるし、このプロセスは、おそらく例示のステップを実施する状態マシンとして設計された特定用途向け集積回路（ＡＳＩＣ）としてのハードウェアでも実施されうる。
プロセスは開始して（ブロック６００）、同期レジスタ５４のトリガレジスタにデータが存在するかどうかの判断（ブロック６０２）に移動する。
いくつかの実施の形態では、同期論理回路１８は、書き込まれたデータが「新しい」か「古い」かに気付かないことがある。
これらの実施の形態では、各プロセッサが書き込みを行うレジスタ５４の少なくとも１つが、トリガレジスタとして動作することができ、各プロセッサに受信されたデータの少なくとも一部を書き込む前に、すべてのプロセッサからのデータを待機するプロセスの一部としてのタイマを起動する。
代替的な実施の形態では、同期論理回路１８は、データを比較して、データが「古い」か「新しい」かを判断できるように十分に高度化されてもよい。
【００３５】
プロセッサが、トリガレジスタに書き込みを行うと（ブロック６０２）、論理プロセッサに２つ以上のプロセッサが存在するかどうかについての判断が行われる（ブロック６０３）。
例えば、２重システムで１つのプロセッサが故障すると、論理プロセッサは、単一のプロセッサのみによって動作することができる。
同様に、３重化システムで２つのプロセッサが故障すると、論理プロセッサは、単一のプロセッサのみで動作することができる。
論理プロセッサにおいて１つのプロセッサしかアクティブでない場合には、データは、直ちにライトバックされうる（ブロック６１８）。
【００３６】
２つ以上のプロセッサが、論理プロセッサ内でアクティブであると仮定すると、タイマが起動され（ブロック６０４）、論理プロセッサの第２のプロセッサが、その各トリガレジスタに書き込みを行うかどうかについての判断が行われる（ブロック６０６）。
書き込みを行わない場合には、トリガレジスタが書き込まれるまで、または、タイマが満了するまで、プロセスは、ソフトウェアループで待機する（ブロック６０６および６０８）。
３つ以上のプロセッサが、論理プロセッサに存在する場合には（ブロック６１０）、タイマが再起動され（ブロック６１２）、この場合も、第３のプロセッサのトリガレジスタが書き込まれるまで、または、タイマが満了するまで、プロセスは、ソフトウェアループで待機する（ブロック６１４および６１６）。
図６の方法は、３つのプロセッサを備える論理プロセッサの例示である。
より多くのプロセッサが存在する場合には、追加されたタイマの再起動およびソフトウェアループでの待機が追加されうる。
同様に、論理プロセッサが、２つのプロセッサしか備えていない場合には、第３のプロセッサに関連したステップが省略されうる。
すべてのデータが受信されると、それらデータの少なくとも一部は、日時データと共に、各論理プロセッサに書き込まれる（ブロック６１８）。
プロセッサの１つが、タイマの満了前に自身の各トリガレジスタに書き込むことができない場合に、同期論理回路１８に書き込まれたデータの少なくとも一部は、各プロセッサにライトバックされる（ブロック６２０）。
プロセッサによって供給されたデータを書き込むことに加えて、ステータスワードも、各メモリパーティションに書き込まれうる。
このステータスワードは、オペレーションが完了したこと、どのプロセッサがオペレーションに参加したかの表示、および、どのプロセッサ（もしあれば）がタイムアウトしたか（再びブロック６２０）を示す。
或るプロセッサが、割り当てられた時刻に書き込みを行えない場合に、その支障のあるプロセッサは論理プロセッサから除去され（ブロック６２２）、例示のプロセスは新たに開始する。
本発明の少なくともいくつかの実施の形態によると、プロセッサが、数ミリ秒内で第１のプロセッサの同期レジスタにデータを書き込まない場合に、訂正動作が取られるべきである。
【００３７】
さまざまな実施の形態の論理プロセッサは、緩やかなロックステップ実行を実施するので、各プロセッサの割り込みハンドラルーチン（および、後に分かるように、システムコール）が同期レジスタ５４にデータを書き込む時刻は、正確に整列していないことがある。
したがって、ブロック６０４、６１６を組み合わせることによって、すべてのプロセッサが割り込みを検出して割り込みに反応することができる一定の余裕が可能になる。
図３を手短に参照して、同期レジスタから各プロセッサへの確認データのライトバックには、同期レジスタ５４から、例えば位置５７Ａおよび５７Ｂといった各メモリパーティションの位置へデータをコピーすることが必要となることがある。
本発明の少なくともいくつかの実施の形態によると、投票者論理回路５６がメモリパーティションに書き込んだデータは、ホストプロセッサの自然キャッシュブロックアラインメント（natural cache block alignment）と整列される。
【００３８】
続ける前に要約すると、割り込みが、割り込みハンドラルーチンの実行をトリガする。
図４のハッシュされた（網掛け（hashed））領域５９は、割り込みハンドラルーチンの実行を表し、したがって、ユーザプログラムが一時的に停止されることを表している。
ランデブーポイントをスケジューリングする現在未完了の試みが存在しないと仮定すると、割り込みハンドラは、割り込みにサービスを提供するための提案されたシステムコール番号と共に、割り込み識別子を投票者論理回路５６の同期レジスタ５４に書き込む（図４のライン６０および６２を参照、図５のブロック５１４）。
論理プロセッサ内の各プロセッサが自身の情報を書き込むと、投票者論理回路５６は、その情報の少なくとも一部を各プロセッサのメモリパーティションの位置５７に書き込む（図４のライン６５を参照、図６のブロック６１８または６２０）。
適切なシステムコール番号を有するシステムコールにおいて、その割り込みの割り込みサービスルーチンが、スケジューラキューに置かれ、サービスの提供を受ける。
【００３９】
図７は、例えば、日時の取り出しといったシステムコールの通常のタスクに加えて、ランデブーポイントの機能を果たし、割り込みハンドリングを調整する少なくともいくつかのシステムコールによって実施されるステップの少なくとも一部を示している。
したがって、図７に提示される方法のステップは、どの１つのシステムコールでも実行できるステップの組全体であるとは主張せず、例示のフロー図は、システムコールの少なくとも一部が、割り込みハンドリングを調整するために、および、場合により緩やかなロックステッププロセッサの同期を行うために実行することができる付加的なステップを強調する。
このプロセスは、ユーザプログラムが現在の日時の要求またはメモリ割り当ての要求等のシステムコールを発行することによって開始することができる（ブロック７００）。
その後、システムコールプログラムは、割り込みを無効にすることができ（ブロック７０２）、システムコール番号をインクリメントすることができ（ブロック７０４）、その結果、特定のプロセッサは、自身がどのシステムコール番号を現在実行中であるかを知る。
次に、非協調プロセス（ブロック７０６、７２４、および７２６）をスキップして、プロセスの次のステップは、完了したランデブーポイントをスケジューリングする試みがあるかどうかの判断とすることができる（ブロック７０８）。
これは、レジスタ５７の非ゼロのデータをチェックすることによって判断されうる。
スケジューリングする試みがある場合に、次のステップは、他の任意のプロセッサが即時動作割り込みにサービスを提供することを提案したかどうかの判断とすることができる（ブロック７３０）。
提案した場合には、保留ランデブーログの割り込みは、保留リストに戻される（ブロック７３６）。
いくつかの実施の形態では、他のプロセッサ（または他の複数のプロセッサ）に見られる即時動作割り込みのトリガが、その時点のプロセッサ（instant processor）で行われようとしており、したがって、その状況は無視され、ランデブーポイントをスケジューリングするさらなる試みが行われうると仮定する（ブロック７１２の判断から開始する）。
代替的な実施の形態では、処理は、即時動作割り込みをトリガした予想されたエラーへの対処を開始してもよい（具体的に図示せず）。
【００４０】
ブロック７３０に戻って、他のプロセッサが、即時動作割り込みにサービスを提供することを提案しなかった場合には、次のステップは、割り込みと、他のプロセッサの提案されたシステムコール番号とを保留ランデブーログに記録することとすることができる（ブロック７３１）。
その後、プロセッサが、どの割り込みにサービスを提供するかについて合意するかどうかの判断（ブロック７３４）が行われる。
合意がある場合には、割り込みは、保留ランデブーログから確認リストへ移動され（ブロック７３２）、ランデブーポイントをスケジューリングするさらなる試みが行われうる（ブロック７１２の判断から開始する）。
確認リストは、割り込みにサービスを提供すべきとの確認であって、どのシステムコール番号で割り込みにサービスを提供すべきかの確認、が受信された当該割り込みのリストである。
例えば、或るプロセッサは割り込み５にサービスを提供することを提案する一方、第２のプロセッサは割り込み９にサービスを提供することを提案するといったように、プロセッサがどの割り込みにサービスを提供するかについて合意していない場合には（ブロック７３４）、その状況は、今後の提案で調整され、ランデブーポイントをスケジューリングするさらなる試みが行われうる（ブロック７１２の判断から開始する）。
【００４１】
ランデブーが完了していない場合には（ブロック７０８）、次のステップは、まだ完了していないランデブーが開始したかどうかの判断とすることができる（ブロック７１０）。
一時的に保留リストの解析（ブロック７１２）をスキップして、例示のプロセスの次のステップは、現在のシステムコール番号について提案された割り込みが保留ランデブーログにあるかどうかをチェックすることとすることができる（ブロック７１４）。
保留ランデブーログにある場合、例示のプログラムは、割り込みをポーリングし（ブロック７１６）（割り込みはブロック７０２によって無効にされているので）、プロセスは、ソフトウェアループで待機する（ブロック７０８の判断から開始する）。
この状況では、その時点のプロセッサが提案したシステムコール番号は、最も高いシステムコール番号とすることができ、したがって、プロセッサは、確認をソフトウェアループで待機する。
【００４２】
現在のシステムコール番号でサービスを提供するように提案された割り込みが、保留ランデブーログに存在しない場合には（ブロック７１４）、次のステップは、現在のシステムコール番号についてスケジューリングされた割り込みが確認リストに存在するかどうかの判断とすることができる（ブロック７１８）。
したがって、現在のシステムコール番号でサービスを提供するようにスケジューリングされた、確認リストにおける割り込みは、それぞれ、それらの割り込みサービスルーチンが実行用にスケジューリングされ、それらのエントリが確認リストから除去され（ブロック７２０）、割り込みは有効にされ（ブロック７２２）、そして、システムは、その通常動作（例えば、日時コール）を実行する（ブロック７２３）。
図４を手短に参照して、現在のシステムコールプログラムが終了すると（網掛け領域６４および６６）、網掛け領域６７によって示すように、タスクスケジューラに置かれた１つまたは２つ以上の割り込みサービスルーチンが実行される。
代替的に、割り込みサービスルーチンは、システムコールの主要な機能を実行する前に実行することもできる。
現在のシステムコール番号のランデブーを有する割り込みが、確認リストに存在しない場合には（ブロック７１８）、割り込みが有効にされ（ブロック７２０）、システムはその通常動作を実行する（ブロック７２３）。
【００４３】
本発明の少なくともいくつかの実施の形態によると、少なくとも１つの割り込み番号および提案されたシステムコール番号が投票者論理回路に書き込まれ、同じ情報が保留ランデブーログに書き込まれた（図５のブロック５１４および５１８）後は、投票者論理回路がデータを返信するまで、ランデブーポイントについてのさらなる提案は開始されえない。
したがって、いくつかの割り込みは、今後のスケジューリングのために保留リストに置かれうる（図５のブロック５０８）。
確認リストへの書き込み（ブロック７３２）、保留ランデブーログの割り込みの保留リストへの返却（ブロック７３６）、または、どの割り込みにサービスを提供するかについての不合意（ブロック７３４）によって、ランデブーポイントスケジューリングプロセスを再び開始する機会が存在する。
この理由のため、システムコールプログラムは、割り込みハンドラと同様の作業を行うことができ、保留リストをチェックすることによって、サービスのスケジューリングする必要のある割り込みがあるかどうかを判断することができる（ブロック７１２）。
スケジューリングする必要のある割り込みが存在する場合には、システムコールは、提案されたランデブー情報を同期レジスタ５４に書き込む（ブロック７４０）ことを含めて、スケジューリングプロセスの初期段階を実行する。
ランデブースケジューリングの初期段階を実行するのに必要とされるステップは、図５のブロック５１２、５１４、５１６、５３０および５５０、５６６に詳細に示されている。
これら同じステップは、システムコールプログラムによって実行されうるが、図を過度に複雑化しないために、例示の方法では、単一のエントリ（ブロック７４０）に結合されている。
【００４４】
図８は、論理プロセッサの或るプロセッサが、別のプロセッサの前に割り込みを調べ、さらに、それらのプロセッサが、どのシステムコール番号で割り込みにサービスを提供すべきかについて合意する場合に生じ得る状況を示している。
詳細には、プロセッサＰＡ１は、割り込みのアサートの直前に、システムコール番号１００３を実行する一方、プロセッサＰＢ１は、割り込みのアサートよりもかなり前に、システムコール番号１００３を実行する。
双方のプロセッサは、ライン１００および１０２によって示すように、例示の割り込み５がシステムコール番号１００４でサービスの提供を受けることを提案する。
一方、この例示の事例では、プロセッサＰＢ１は、投票者論理回路５６が同期データをプロセッサにライトバックする前に、システムコール番号１００４に到達する。
この場合、割り込みがシステムコール番号１００４でサービスの提供を受けることを確認するデータがライトバックされるまで、プロセッサＰＢ１は、斜線領域１０４によって示すように、ソフトウェアループで待機する（図７のブロック７０８、７１０、および７１４）。
同様に、投票者論理回路が書き込みを行う前に、プロセッサＰＡ１は、システムコール番号１００４に到達し、同様に、プロセッサＰＡ１は、斜線領域１０６によって示すように、ソフトウェアループで待機する（再び、図７のブロック７０８、７１０、および７１４）。
これら例示の２つのプロセッサに関連した投票者論理回路が、収集した情報をプロセッサのそれぞれのメモリパーティションにライトバックし、システムコールプログラムが、割り込みにサービスを提供すべき箇所がシステムコール番号１００４であることを確認すると（図７のブロック７３２および７３４）、双方のプロセッサは、その割り込みにサービスを提供し（図７のブロック７２０）、通常処理を継続する。
これら２つのプロセッサは、最初はそれらの実行ポイントに関して幾分相違はあるが、投票者論理回路からの同期レジスタの書き込み時およびその後の割り込みへのサービスの提供時には、少なくとも部分的にどのように同期するようになるかについて留意されたい。
【００４５】
図９は、論理プロセッサにおけるプロセッサが、異なる割り込み番号のサービス提供を提案または広告する状況を示している。
図９に示す例示の事例では、プロセッサＰＡ１は、自身の割り込みが割り込み５のアサートの直前に有効にされ、したがって、プロセッサＰＡ１は、システムコール番号９６で割り込み５にサービスを提供することを提案する。
一方、プロセッサＰＢ１は、割り込み５および９のアサートの後になるまで、自身の割り込みを有効にしない。
説明のため、割り込み９は割り込み５よりも高い優先度を有すると仮定する。
したがって、プロセッサＰＢ１は、割り込みを有効にした後、（割り込み９の優先度が高いために）例示のシステムコール番号９６で割り込み９にサービスを提供することを提案する。
この事例のプロセッサＰＡ１は、同期レジスタからメモリパーティションへデータをライトバックする前にシステムコール番号９６に到達するので、プロセッサＰＡ１は、ソフトウェアループで待機する（図７のブロック７０８、７１０、および７１４）。
同様に、プロセッサＰＢ１は、自身が提案した割り込み９がシステムコール番号９６でサービスの提供を受けることになるかどうかの確認の前にシステムコール番号９６に到達し、同様に、ソフトウェアループで確認の待機も行う。
投票者論理回路が、同期データを各プロセッサのメモリパーティションにライトバックすると、各プロセッサは、割り込みタイプの不一致に気付く（一方のプロセッサは、割り込み５にサービスを提供することを提案しているのに対して、第２のプロセッサは、割り込み９にサービスを提供することを提案している）（図７のブロック７３４）。
いずれにしても、これらのプロセッサは、その後、先に提案されていないそれらプロセッサの最も高い優先度の割り込みを提案する（図７のブロック７１２および７４０）。
例示のＰＡ１の場合には、割り込み９が最も高い優先度の割り込みであり、したがって、この割り込みが提案される。
さらに、プロセッサＰＡ１は、先に、システムコール番号９６で割り込み５にサービスを提供することを提案しており、その提案は依然として未処理であるので、システムコールは、ソフトウェアループで待機し続ける（図７のブロック７０８、７１０、および７１４）。
例示のプロセッサＰＢ１については、先に提案していない最も高い優先度の割り込みは割り込み５であり、したがって、割り込み５が提案される（図７のブロック７１２および７４０）。
図９の２番目の例示の書き込みからのデータのライトバックによって、これらのプロセッサは、提案した最も高いシステムコール番号、この事例では９７で、割り込み５および９の双方にサービスを提供することに合意する。
システムコール番号９７が各プロセッサで現れると、これらの割り込みは、最も高い優先度の割り込みが最初にサービスの提供を受ける（ブロック７１８および７２０）。
【００４６】
図４、図８、および図９の例示のシステムでは、アサートされた割り込みのそれぞれは、イベントタイプの割り込みである。
この割り込みは、当該割り込みがイベントを示すことを意味し、即時動作が必要とされることがないことを意味する。
一方、即時動作割り込みは、異なったハンドリングを受ける。
図１０は、本発明の実施の形態によるページフォールト等の即時動作割り込みのハンドリングの時間表を示している。
図１０の例示の事例では、プロセッサＰＢ１が、この例示の事例ではページフォールト（ＰＦ）である即時動作割り込みを経験する。
割り込みハンドラルーチンがトリガされ、即時動作割り込みの性質が決定され（図５のブロック５１６）、即時動作割り込みの表示が同期レジスタに書き込まれる（図５のブロック５１４）。
本発明の実施の形態によると、プロセッサＰＢ１は、ユーザプログラムをそれ以上実行せず、他のプロセッサもページフォールトに到達したことの確認をソフトウェアループで待機する（図５のブロック５３０）。
図１０を引き続き参照して、プロセッサＰＢ１のページフォールトの後に、プロセッサＰＡ１が、対応するページフォールトを経験し、その割り込みハンドラルーチンがトリガされ、ページフォールトの表示が同期レジスタに送信される。
投票者論理回路が各プロセッサからデータを受信する（または、プロセッサの１つがタイムアウトする）と、その情報は、ライン１５０によって例示するように、各プロセッサのメモリパーティションに書き込まれる（図６のブロック６１８または６２０）。
割り込みハンドラルーチンが、すべてのプロセッサが即時動作割り込みについて合意したことを確認すると（図５のブロック５５８）、各割り込みハンドラルーチンは、即時動作割り込みの割り込みサービスルーチンをスケジューリングして実行する（図５のブロック５６４）。
即時動作割り込みの割り込みサービスルーチンが完了した後、割り込みハンドラは、新たに、ランデブーポイントのスケジューリングを開始する（図５のブロック５１２から開始する）。
このページフォールトの例示の事例では、即時動作割り込みの割り込みサービスルーチンは、ページフォールトサービスルーチンであってよい。
図１０に関して、各プロセッサの処理は、ページフォールトが発生するユーザプログラムのポイントにすべてのプロセッサが到達したことを確認するまで停止することに留意されたい。
【００４７】
図１１は、イベント割り込みおよび即時動作割り込みの相対的な取り扱いを示している。
詳細には、図１１は、２つのプロセッサＰＡ１およびＰＢ１を有する例示のシステムにおいて、プロセッサＰＡ１がページフォールト割り込み前に割り込み５の表示を受信する一方、プロセッサＰＢ１がページフォールト割り込み後に割り込み５を受信することを示している。
この場合、プロセッサＰＡ１上で実行される割り込みハンドラルーチンは、システムコール番号１００６で割り込み５にサービスを提供する提案を書き込む（図５のブロック５１４）。
一方、（ページフォールトに基づいて）プロセッサＰＢ１上で実行される割り込みハンドラルーチンは、ページフォールトにサービスを提供することを提案し、その提案が確認されるまでソフトウェアループで待機する（図５のブロック５１４、５１６、および５３０）。
その後、プロセッサＰＡ１は自身のページフォールトに遭遇する。
この例示の状況では、プロセッサＰＡ１は、（割り込み５の）未確認のランデブーを有し、したがって、ページフォールトによってトリガされた割り込みハンドラルーチンの実行時に、プロセッサは、投票者論理回路が同期情報をライトバックするまでソフトウェアループで待機する（図５のブロック５３０）。
これら２つのプロセッサに関連した投票者論理回路は、同期レジスタの情報をそれらプロセッサのそれぞれのメモリパーティションにライトバックする。
一方、同期データの各プロセッサのメモリパーティションへのこの最初の書き込みにおいて、一方のプロセッサは、システムコール番号１００６で割り込み５にサービスを提供することを提案しているが、他方のプロセッサは、ページフォールトにサービスを提供することを提案している。
この場合、各プロセッサは、割り込みにサービスを提供する試みを取りやめる（プロセッサＰＢ１については、ブロック５６６のオペレーションによる。
プロセッサＰＡ１については、図５のブロック５５２、５６０のオペレーションによる）。
いずれの場合にも、即時動作割り込みは、（図５のブロック５１２で選択された）最も高い優先度の割り込みであり、したがって、双方のプロセッサは、即時動作割り込みにサービスを提供することを提案する。
その後、投票者論理回路５６は、各プロセッサのメモリパーティションに情報をライトバックし、図におけるこの時に、プロセッサは、ページフォールトに対処すべきことに合意する。
図１１を引き続き参照して、その後、即時動作割り込みが、サービスの提供を受けると、プロセッサＰＡ１およびＰＢ１のそれぞれは、特定のシステムコール番号、この例示の事例ではシステムコール番号１００６で、先にアサートされた割り込み５をスケジューリングすることを提案する。
ページフォールトがクリアされた以上、システムコール番号１００６で割り込み５へのサービス提供が、他の例示の実施の形態で説明したように行われうる。
図４および図８〜図１１のそれぞれは、２つのプロセッサのみを示しているが、説明した技法は、各論理プロセッサに３つまたは４つ以上のプロセッサを有するコンピュータシステム１０００にも等しく適用可能であることが理解されよう。
図４および図８〜図１１についての説明は、さまざまなイベント割り込みおよび即時動作割り込みのハンドリングを過度に複雑にしないために、２つのプロセッサを示す。
【００４８】
図４および図８〜図１１によって示すランデブーポイントのスケジューリングの説明は、一度に１つの割り込みのみをスケジューリングすることに限られている。
例えば、図４は、各プロセッサが単一の割り込み番号、および、割り込みにサービスを提供するための提案したシステムコール番号を同期レジスタに書き込むことを示している。
代替的な実施の形態によると、複数の割り込み（および割り込みにサービスを提供するための提案したシステムコール番号）は、各割り込みのランデブーポイントをスケジューリングする試みで、同期レジスタに書き込まれうる。
いくつかの実施の形態では３つである複数の割り込みが、一度に、提案され、保留ランデブーログに書き込まれうること、および、同様に複数の割り込みが、確認リストに移動されうることは別として、これらの代替的な実施の形態のオペレーションのさまざまなフロー図は、変更されない。
【００４９】
さらに、これまでに説明したさまざまな実施の形態は、保留リスト（アサートされたがまだ提案されていない割り込み）、保留ランデブーログ（提案されたが、確認がまだ受信されていないか、受信されたが解析されていない割り込み）、および、合意リストまたは確認リスト（確認が受信された割り込み）の３つのリストを利用する。
代替的な実施の形態は、保留リストおよび確認リストの２つのリストのみを使用することができる。
これらの実施の形態では、１つまたは２つ以上の割り込みを一度に提案することができるが、それらの割り込みは、ランデブーポイントについてプロセッサ間で合意があるまで、保留リストに留まる。
各割り込みについて合意があると、各割り込みは、保留リストから確認リストに移動される。
ランデブーポイントをスケジューリングする１組の提案のみが未処理である場合があるので、これらの代替的な実施の形態は、データが同期レジスタに書き込まれた時に、未処理の試みの表示として、フラグをセットすることができる。
同様に、確認データが、投票者論理回路から返信された時に、そのフラグは、リセットされうる。
これらの代替的な実施の形態では、プロセッサが、割り込みにサービスを提供することに合意する前に、各割り込みは、複数回提案されうる（即時動作割り込みがない場合であっても）。
したがって、これらの代替的な実施の形態では、各プロセッサは、他のプロセッサの返信データを解析して、１つまたは２つ以上の割り込みにサービスを提供することについて合意があるかどうかを調べる。
合意がある場合には、合意された割り込みが、保留リストから除去されて、確認リストに置かれる。
合意のない割り込みの場合、返信データは廃棄され、プロセスは、保留リストから最も高い優先度の割り込みを選択することによって新たに開始して、ランデブーポイントを提案する。
【００５０】
即時動作割り込みについては、これまでに説明したさまざまな実施の形態では、１つのプロセッサが、即時動作割り込みに遭遇する（かつ、即時動作割り込みを提案する）と、他のプロセッサは、自身も即時動作割り込みに遭遇するような時まで、自身の最も高い優先度の非即時動作割り込みを提案し続けることができる。
代替的な実施の形態では、少なくとも１つのプロセッサが、即時動作割り込みにサービスを提供することを提案すると、残りのプロセッサは、非即時動作割り込みのそれ以上の提案を控えることができ、その代わり、対応する即時動作割り込みが発生するまで、処理を継続しうる。
したがって、非即時動作割り込みは、即時動作割り込みがサービスの提供を受けた後になるまで、各プロセッサの保留リストに蓄積しうる。
したがって、これらの代替的な実施の形態は、すべてのプロセッサが即時動作割り込みに到達し、合意し、かつ、サービスを提供するのに要する時間を削減することができる。
【００５１】
上述したように、プロセッサの少なくとも部分的な同期、および、割り込みの調整されたサービス提供は、本発明の実施の形態によるランデブーポイントで達成されることができる。
一方、長期間の間、システムコールを行わないユーザプログラムが存在し得る。
したがって、論理プロセッサ内のプロセッサが、実行しているユーザプログラムの部分について大幅に異なる可能性があり、さらに、割り込みにサービスを提供する十分な機会がない可能性がある。
十分な頻度でシステムコールを行わないユーザプログラムは、「非協調プロセス」と呼ばれうる。
【００５２】
説明のため、非協調プロセスのハンドリングは、４つの段階を有するとみなされうる。
第１段階は、ユーザプログラムが確かに非協調的であると識別することである。
第２段階は、アプリケーションの非協調性が引き起こす、論理プロセッサ内のプロセッサ間での計算障害の可能性を最小にし、さらに、非協調性プロセスおよび他の関係のないプロセスが協調的になることを期待して、これらのプロセスに実行継続を可能にすることである。
第３段階は、論理プロセッサにおける各プロセッサの非協調プロセスが同じ実行ステージにあることを保証する動作を行うことである。
最後に、最終段階は、元非協調プロセスを変更することである。
これらの段階のそれぞれについて、次に取り扱うことにする。
【００５３】
いくつかの実施の形態では、ユーザプログラムが稀にしかシステムコールを行わず、したがって、非協調的であるとみなされることを識別することは、タイマの使用を必要とする。
ユーザプログラムが、タイマの満了前にシステムコールを行わない場合、そのユーザプログラムは、非協調プロセスである。
本発明のいくつかの実施の形態によると、プロセッサのディスパッチャプログラム（最も高い特権状態であるカーネルモードで動作する）が、ユーザプログラムを実行にセットするごとに、ディスパッチャは、非協調プロセスタイマも始動し、現在のシステムコール番号の表示を記憶する。
タイマの満了時に、非協調プロセスハンドラルーチンを起動する割り込みがアサートされる。
非協調プロセスハンドラルーチンは、タイマが規定する期間中に少なくとも１つのシステムコールがあったかどうかをチェックする。
このタイマが規定する期間は、いくつかの実施の形態では、およそ１００マイクロ秒程度とすることができる。
代替的な実施の形態では、システムコールプログラムは、タイマをリセットして、非協調プロセスハンドラルーチンのトリガを回避することができるが、これらのリセットは、多大な費用を要するカーネルモードプロセスコールを必要とすることがある。
【００５４】
図１２（図１２Ａおよび図１２Ｂを含む）は、本発明の実施の形態による非協調プロセスハンドラのフロー図を示している。
詳細には、非協調プロセスハンドラは、ディスパッチャにより始動されたタイマの満了後に割り込みをアサートすることによって開始することができる（ブロック１２０１）。
ディスパッチャにより始動されたタイマは、以下、非協調プロセスタイマをいう。
非協調プロセスタイマの満了によって、例示の図１２は、直接開始されてもよいし、図１２のステップは、非協調プロセスタイマの満了の判断（図５のブロック５０４）および割り込みハンドラの呼び出し（図５のブロック５０６）により割り込みハンドラを通じて起動されてもよい。
割り込みを無効にした（ブロック１２０４）後、非協調プロセスハンドラは、現在のシステムコール番号（ブロック１２０８）、および、開始時にディスパッチャにより記憶されたシステムコール番号（ブロック１２１２）を読み出すことができる。
現在のシステムコール番号がディスパッチャによって開始時に記憶されたシステムコール番号と同じである（ブロック１２１６）ことは、ユーザプログラムが、タイマによって規定された期間中にシステムコールを行わなかったことを示し、したがって、ユーザプログラムが非協調プロセスであることを示す。
他方、現在のシステムコール番号が、記憶されたシステムコール番号と同じでない場合には（再びブロック１２１６）、そのプロセスは協調的であり、したがって、例示の方法は、非協調プロセスタイマを再始動し（ブロック１２３７）、現在のシステムコール番号を記憶し（ブロック１２３９）、割り込みを有効にして（ブロック１２３８）、そして終了する（ブロック１２３６）。
【００５５】
本発明の実施の形態によると、ユーザプログラムが論理プロセッサの少なくとも１つのプロセッサ内で非協調的になることによって、ランデブーオペレーションが起動され、論理プロセッサの他のプロセッサがその非協調性に合意するかどうかが判断される。
引き続き図１２を参照して、現在のシステムコール番号が、ディスパッチャによって記憶されたシステムコール番号と同じである場合（ブロック１２１６）、次のステップは、未確認のランデブーオペレーションがあるかどうかの判断とすることができる（ブロック１２２０）。
未確認のランデブーオペレーションがない場合、次のステップは、ユーザプログラムの非協調性の表示を、現在のシステムコール番号と共に、投票者論理回路５６の同期レジスタ５４に書き込むことによってランデブーオペレーションを開始することとすることができる（ブロック１２２４）。
その後、非協調プロセスハンドラルーチンは、投票者論理回路が同期データを返信することを、ソフトウェアループで待機する（ブロック１２２８）。
【００５６】
どの時点においても、ランデブーポイントの１つのスケジューリングしか実行しえないので、非協調プロセスタイマの満了時にまだ完了していないランデブーが開始されている場合には（再びブロック１２２０）、次のステップは、投票者論理回路が同期データを書き込むまでソフトウェアループで待機することとすることができる（ブロック１２４６）。
ライトバックされた同期データは、前の割り込み（非協調プロセスハンドラルーチンの現在の実行をトリガした非協調プロセスタイマ満了割り込みではない）に関することに留意して、ランデブー情報が、今後の実行のために確認リストに書き込まれるか、または、この割り込みが、保留リストに戻される（ブロック１２５０）（図５のブロック５５２、５５４、５６０、５６２、および５５６を参照）。
その後、プロセスは、ユーザプログラムの非協調性の表示を、現在のシステムコール番号と共に、投票者論理回路５６の同期レジスタ５４に書き込むことに進み（ブロック１２２４）、データの返信をソフトウェアループで待機する（ブロック１２２８）。
【００５７】
プロセッサが、ユーザプログラムが非協調的であることに合意しない場合には（ブロック１２３２）、同期データの解析が行われて、ユーザプログラムが他のプロセッサにおいて協調的であるかどうかが判断される（ブロック１２３４）。
例えば、一方のプロセッサの非協調プロセスタイマは、ユーザプログラムによるシステムコールの直前に満了する（またはロールオーバする）ことがある一方、論理プロセスの第２のプロセッサのユーザプログラムは、満了直前にシステムコールを行うことがある。
したがって、一方のプロセッサは、プロセスが非協調的であることを示し、第２のプロセッサは、提案されたランデブーポイントの書き込みを含めて、次の割り込みのハンドリングのスケジューリングを試みる。
この解析によって、ユーザプログラムがまもなくシステムコールを行うことが明らかになると（ブロック１２３４）、非協調プロセスタイマが再始動され（ブロック１２３７）、現在のシステムコール番号が記憶され（ブロック１２３９）、割り込みが有効にされ（ブロック１２３８）、そして、プロセスは終了する（ブロック１２３６）。
【００５８】
引き続き図１２を参照して、論理プロセッサのすべてのプロセッサが、ユーザプログラムが非協調的であることに合意すると（ブロック１２３２）（ユーザプログラムが非協調プロセスタイマの期間の間、同じシステムコール番号にあったことをすべてのプロセッサが示すと）、非協調プロセスの第１ステージのハンドリングは、非協調プロセスフラグをセットしてカウンタをインクリメントすることによって開始する（ブロック１２５４）。
これが、ユーザプログラムが非協調的としてフラグセットされた最初の時である場合には（ブロック１２５８）、非協調プロセスと同じメモリ位置の同じデータ値にアクセスするユーザプログラム（非協調プログラムの「プロセスセット」）は、それらユーザプログラムの継続実行を許可しないリストに置かれる。
最初の時であることは、おそらくカウンタ（ブロック１２５４でインクリメントされる）を読み出すことによって判断される。
換言すると、プロセッサのディスパッチャは、プロセスセットのどのメンバの実行もスケジューリングしない。
これは、プロセスセットの隔離（quarantine of the process set）としても知られている（ブロック１２６２）。
プロセスセットは非協調プロセスとメモリを共有し、さらに、論理プロセッサのプロセッサ間で非協調プロセス内の実行ポイントが相違する可能性があり、プロセスセットが共有メモリの相違に遭遇するおそれがあることから、プロセスセットの隔離は、プロセスセットのプロセスが（プロセッサ間で）メモリの異なるデータに遭遇しないことを保証し、したがって、計算障害を引き起こさないことを保証する。
この第１ステージでは、非協調プロセスは、協調的になることを期待して、まだ実行が許可されている。
したがって、プロセスセットの隔離後、非協調プロセスハンドラルーチンは、非協調プロセスタイマを再始動し（ブロック１２３７）、現在のシステムコール番号を記憶し（ブロック１２３９）、割り込みを有効にし（ブロック１２３８）、そして終了する（ブロック１２３６）。
【００５９】
本発明の実施の形態によると、非協調プロセスは、そのプロセスが隔離状態にある間、実行の継続を許可される。
非協調プロセスの実行の次のスケジューリング時に、ディスパッチャは、再び、現在のシステムコール番号を記憶し、非協調プロセスタイマを始動する。
非協調プロセスが、非協調プロセスタイマの期間の間、再び、システムコールを行うことなく実行されると、非協調プロセスハンドラルーチンが、再び起動される。
すべてのプロセッサが、再び、ユーザプログラムの非協調性に合意すると（ブロック１２３２）、ルーチンは、非協調プロセスフラグをセットし（ブロック１２５４）（ただし、このフラグは、前のエントリに基づいてすでにアサートされている）、カウンタがインクリメントされる（ブロック１２５４）。
この例示の状況では、ユーザプログラムは、新しく非協調的になったのではないので（ブロック１２５８）、次のステップは、ユーザプログラムが所定の回数の繰り返しの間、非協調的であることが判明したかどうかの判断とすることができる（ブロック１２６６）。
いくつかの実施の形態では、プロセスセットの隔離の後、その後の訂正動作が行われる前に、ユーザプログラムが非協調的であると１０回宣言されうる。
ユーザプログラムが、所定の回数の繰り返しよりも少ない繰り返しで非協調的であると確認されると（ブロック１２６６）、さらに動作を行う前に、再び、非協調プロセスが協調的になることを期待して、非協調割り込みハンドラルーチンは、非協調プロセスタイマを再始動し（ブロック１２３７）、現在のシステムコール番号を記憶し（ブロック１２３９）、割り込みを有効にし（ブロック１２３８）、そして終了する（ブロック１２３６）。
非協調プロセスハンドリングの段階３は、システムコールが所定の回数の繰り返し前に行われた場合に、非協調プロセスがどのように取り扱われるかを説明した後に説明される。
【００６０】
さらに説明のために、ユーザプログラムは、少なくとも１回、非協調的であると確認され、そのプロセスセットが隔離されたが、ユーザプログラムは、所定の回数の繰り返しの間、非協調的であるとまだ確認されていないと仮定する。
さらに、ユーザプログラムがシステムコールを行うものと仮定する。
再び、図７を手短に参照して、システムコールプログラムが実行されると、システムコール番号をインクリメントした（ブロック７０４）後、呼び出し側プログラムが、非協調的であるとして事前にフラグセットされているかどうかについての判断が行われる（ブロック７０６）。
フラグセットされていない場合には、システムコールは、上述したようなステップを実行する。
一方、呼び出し側プログラムが、事前に非協調的であるとフラグセットされている場合には、システムコールプログラムは、プロセスセットの隔離を解除することができ（ブロック７２４）、非協調プロセスフラグをクリアすることができる（ブロック７２６）。
【００６１】
図１３は、図１２の方法をさらに示すために、イベント割り込みに関係した非協調プロセスのハンドリングを示す時間表である。
詳細には、図１３は、各プロセッサがシステムコール番号１９９９に遭遇する状況を示している。
プロセッサＰＡ１の場合、割り込み５は、非協調プロセスタイマの満了前にアサートされ、したがって、プロセッサＰＡ１は、システムコール番号２０００で割り込み５のサービス提供を提案する（ライン１３００、図５のブロック５１４）。
割り込み５のサービス提供を提案した直後、プロセッサＰＡ１の非協調プロセスタイマは満了し、ランデブーが未確認であるため、このプロセッサは、投票者論理回路が前の提案からの同期データをライトバックすることを、ソフトウェアループで待機する（図１２のブロック１２４６）。
これに対して、プロセッサＰＢ１は、割り込みがアサートされる前に、自身の非協調プロセスタイマが満了し、したがって、プロセッサＰＢ１は、非協調プロセス情報を同期レジスタ５４に書き込み（ライン１３０２）、確認をソフトウェアループで待機する（図１２のブロック１２２４および１２２８）。
その後、投票者論理回路は、同期データを各プロセッサにライトバックする（ライン１３０４）。
プロセッサが割り込みのサービス提供に合意せず、非協調プロセス割り込みが即時動作性であることから、プロセッサＰＡ１は、割り込み５を保留リストにライトバックし（ブロック１２５０）、非協調プロセスの表示を同期レジスタに書き込み（ライン１３０６、ブロック１２２４）、そして、確認をソフトウェアループで待機する（ブロック１２２８）。
プロセッサＰＢ１について、プロセッサは、非協調プロセスに関して合意しない（ブロック１２３２）（プロセッサＰＡ１は、ユーザプログラムが非協調的であることを示すのではなく、割り込みにサービスを提供することを提案した）。
さらに、プロセッサＰＡ１によって提案されたシステムコール番号（この例示の事例ではシステムコール２０００）は、プロセッサＰＢ１のシステムコールが次に行われることを意味せず、提案されたシステムコール番号２０００は、プロセッサＰＡ１もシステムコール番号１９９９に達していることを暗に意味する（ブロック１２３４）。
したがって、プロセッサＰＢ１は、非協調プロセスを示す同期データの第２の書き込みを行い（ライン１３０８、ブロック１２２４）、この場合も、確認をソフトウェアループで待機する（ブロック１２２８）。
その後、投票者論理回路５６は、同期データを各プロセッサに書き込む（ライン１３１０）。
この例示の第２の書き込みでは、プロセッサは、非協調ステータスに合意し（各プロセッサについてブロック１２３２）、したがって、各プロセッサは、非協調プロセスフラグをアサートし、非協調プロセスカウンタをインクリメントし（ブロック１２５４）、そして、非協調プロセスのプロセスセットを隔離する（ブロック１２６２）。
その後、ユーザプログラムは、非協調プロセスのプロセスセットが隔離されているにもかかわらず、動作を続ける（各プロセッサの時間表の領域１３１２）。
【００６２】
また、図１３は、投票者論理回路に書き込まれた同期データが一致しないにもかかわらず、ユーザプログラムの非協調性がまもなく終了する可能性があるという情報をプロセッサが収集する状況も示している。
詳細には、図１３は、プロセッサＰＡ１が、この例示の事例ではシステムコール番号３０００のシステムコールを行うこともさらに示している（領域１３１４）。
システムコールプロセスの一部として、プロセッサＰＡ１は、次のランデブーを提案または広告する（ライン１３１６、図７のブロック７１２および７４０も参照）。
これに対して、プロセッサＰＢ１は、自身の非協調プロセスタイマがシステムコール前に満了し、したがって、非協調プロセスの表示を書き込み（ライン１３１８、ブロック１２２４）、確認をソフトウェアループで待機する（ブロック１２２８）。
投票者論理回路が同期データを返信すると（ライン１３２０）、プロセッサＰＡ１は、割り込みタイプの不一致に気付き（システムコールによって解析された場合には図７のブロック７３０、割り込みハンドラによって解析された場合にはブロック５５２）、再び、同期データの書き込みを試みる（ライン１３２１、図７のブロック７４０または図５のブロック５１４）。
これに対して、プロセッサＰＢ１は、同期データを受信し（ライン１３２０）、プロセッサがユーザプログラムの非協調性について合意しない（ブロック１２３２）一方、プロセッサＰＡ１からの提案されたランデブー情報は、システムコールが次に行われることを示している（ブロック１２３４）。
したがって、プロセッサＰＢ１は、システムコールが行われるまで、ユーザプログラムの実行を継続する。
その後、プロセッサは、プロセッサＰＡ１によって最初に提案された割り込みに合意する。
【００６３】
次に、図１２、特に、ブロック１２６６が示すステップを参照されたい。
ユーザプログラムが、所定の回数の繰り返しの間、非協調プロセスとしてフラグセットされている場合には（ブロック１２６６）、次のステップは、この非協調プロセスを隔離すること（ブロック１２６８）、および、プロセスレベル再統合ルーチンを呼び出すること（ブロック１２７０）とすることができる。
【００６４】
論理プロセッサの各プロセッサで実行され、非協調プロセスとして特定されているユーザプログラムは、プロセッサ間でそれらユーザプログラムの実行ポイントが大幅に相違することがある。
本発明の少なくともいくつかの実施の形態によると、ユーザプログラムが、システムコールに基づいて同期する機会を提供しない場合には、同期は、各ユーザプログラムの実行を命令ストリームの同じポイントで強制的に再開させることによって行われうる。
これは、いくつかのプロセッサが、いくつかの命令を重複して実行し、他のプロセッサが、いくつかの命令の実行をスキップすることを意味することがある。
一方、命令ストリームの同じポイントでユーザプログラムの実行再開を可能にする前に、各プロセッサのワーキングメモリが同じである必要がある。
換言すると、非協調プロセスが書き込みアクセスを行うどのメモリも、論理プロセッサのプロセッサ間で比較されて、同じにされるべきである。
このように、実行が再開されると、各プロセッサのプロセス状態は同じになる。
したがって、本発明の実施の形態によると、図１２に示す非協調プロセスハンドラルーチンが、強制的な同期を必要とすると判断すると（ブロック１２６６）、ユーザプログラムのワーキングメモリのプロセスレベル再統合が必要とされうる。
【００６５】
図１４は、論理プロセッサの各プロセッサでほぼ同時に実行できるプロセスレベル再統合ルーチンのフロー図を示している。
詳細には、このプロセスは、図１２に示す非協調プロセスハンドラルーチンによる呼び出しに基づいて開始する（ブロック１４００）。
この例示のプロセスの次のステップは、論理プロセッサの他のプロセッサと共に動作して、ソースプロセッサを選択することである（ブロック１４０２）。
ソースプロセッサを選択するために、メッセージは、投票者論理回路を使用して、プロセッサ間で交換されうる。
論理プロセッサにおけるプロセッサのいずれか１つが選択されうる。
【００６６】
例示のプロセスの次のステップは、非協調プロセスが書き込みアクセスを行うメモリ領域を決定することである（ブロック１４０４）。
この決定は、例えば、プロセッサのメモリ管理テーブルおよび／またはメモリページテーブルを参照することによって行われうる。
非協調プロセスが書き込みアクセスを行うメモリ領域の範囲が決定されると、次のステップは、メモリページがその生成以来変更されていない（通常、クリーンとして知られている）かどうかの判断である（ブロック１４０６）。
例示の図１４の説明の残りは、一度に１つのメモリページしかプロセッサによって解析されないと仮定する。
一方、代替的な実施の形態は、一度に複数のメモリページを比較する。
検討対象のメモリページがクリーンでない（通常、ダーティとして知られている）場合には（再びブロック１４０６）、例示のプロセスの次のステップは、メモリページのチェックサムを計算することである（ブロック１４０８）。
【００６７】
例示のプロセスの次のステップは、データを交換することである（ブロック１４１０）。
このデータは、検討対象のメモリページがクリーンであることの表示（ブロック１４０６を通じてのエントリ）、または、メモリページがダーティである場合に計算されたチェックサム（ブロック１４０８を通じてのエントリ）の一方である。
このデータ交換は、投票者論理回路を使用して行われることができ、各プロセッサが投票者論理回路から返信されるデータをソフトウェアループで待機する（各プロセッサがその各データを書き込むのを待機し、投票者論理回路がデータをライトバックするのを待機する）という意味で、即時動作割り込みに関する交換と同様である。
これらのステップは、図を過度に複雑にしないために、明示的に示されていない。
データが受信されると、メモリページがクリーンであることにすべてのプロセッサが合意するかどうかについての判断が行われる（ブロック１４１２）。
すべてのプロセッサが、メモリページがクリーンであることに合意すると、ソースプロセッサからメモリページをコピーする必要はない。
したがって、次のステップは、すべてのメモリページが解析されたかどうかの判断とすることができる（ブロック１４１４）。
すべてのメモリページが解析されていない場合には、プロセスは、新たに、別のメモリページを解析することから開始する。
【００６８】
引き続き図１４を参照して、すべてのプロセッサが、メモリページのクリーンステータスに合意していない場合（再びブロック１４１２）、次のステップは、例示のプロセスを実行しているプロセッサおよびソースプロセッサが、メモリページがダーティであることに合意するかどうかの判断である（ブロック１４１６）。
合意する場合には、ソースプロセッサが提供したチェックサムと、例示のプロセスを実行しているプロセッサが計算したチェックサムとが等しいかどうかについての判断が行われる（ブロック１４１８）。
チェックサムが等しい場合には、メモリページは、ダーティではあるが、同じデータを含むので、ソースプロセッサからメモリページをコピーする必要はない。
他方、ソースプロセッサと、例示のプロセスを実行しているプロセッサとの間でチェックサムが等しくない場合には（再びブロック１４１８）、メモリページは同じではなく、したがって、ソースプロセッサからのメモリページが、例示のプロセスを実行しているプロセッサにコピーされる（ブロック１４２０）。
同様に、ソースプロセッサ、および、例示のプロセスを実行しているプロセッサが、メモリページのダーティステータスについて合意しない場合には（再びブロック１４１６）、メモリページは同じではなく、したがって、ソースプロセッサからのメモリページが、例示のプロセスを実行しているプロセッサにコピーされる（再びブロック１４２０）。
ソースプロセッサからメモリページをコピーすることに加えて、メモリページに関連付けられたクリーン／ダーティビットも、ソースプロセッサからコピーされる。
これらのビットは、例えば、プロセッサのソースのページテーブルまたはページマッピングテーブルに記憶されうる。
双方のプロセッサが、メモリページのダーティ状態について合意する場合には、クリーン／ダーティビットをコピーする必要はない。
一方、メモリページがコピーされるごとにこれらのビットをコピーすることは、便利な場合があり、プログラミングおよび交換時間の観点からあまり多くの費用を要しない場合がある。
コピーの後、例示の方法は、さらに解析するメモリページがあるかどうかの判断に移動する（ブロック１４１４）。
【００６９】
すべてのページが解析され、おそらく、いくつかのメモリページが、ソースプロセッサから非ソースプロセッサの１つまたは２つ以上にコピーされると、例示のプロセスの次のステップは、場合によっては命令ポインタおよび他のレジスタを含めて、プロセス制御ブロックをソースプロセッサから非ソースプロセッサへコピーすることである（ブロック１４２２）。
このコピーは、各プロセッサが、ソースプロセッサと同じ実行ポイントでユーザプログラムの実行を再開することを保証する。
その後、プロセスレベル再統合ルーチンは復帰する（ブロック１４２６）。
プロセスレベル再統合ルーチンは、他のプロセス（隔離されたプロセスセットのプロセスを除く）の実行とインターリーブされて、プロセスとして実行されることに留意されたい。
【００７０】
制御が、図１２に示す非協調プロセスハンドラに復帰すると、ユーザプログラムおよびそのプロセスセットは隔離リストから除去され（ブロック１２７４）、非協調プロセスフラグおよびカウンタはクリアされ（ブロック１２７８）、非協調プロセスタイマは再始動され（ブロック１２３７）、現在のシステムコール番号は記憶され（ブロック１２３９）、割り込みは有効にされ（ブロック１２３８）、そして、プロセスは終了する（ブロック１２３６）。
したがって、元非協調プロセスは、（この場合、書き込み可能メモリのプロセスレベル再統合によって）同期されており、再びプロセッサによって実行されうる。
ソースプロセッサからの命令ポインタおよび他のレジスタがコピーされたので、すべてのプロセッサは、ユーザプログラムの同じ実行ポイントで実行を再開する。
【００７１】
少なくともいくつかの実施の形態によると、ユーザプログラムの非協調性にかかわらず、適切なオペレーションを確保するには、プロセスレベル再統合だけで十分な場合がある。
プロセスレベル再統合に加えて、または、これに代えて、少なくともいくつかの実施の形態は、事前対策ステップを行って、ユーザプログラムの少なくとも非協調プロセスの指定を引き起こした部分が再びそのようにならないことを確保することができる（ブロック１４２４）。
この事前対策ステップは多くの形態を取ることができる。
いくつかの実施の形態では、ユーザプログラムの好ましくない部分（ほとんどはソフトウェアループ）が、システムコールを含むように変更される。
これは、例えば、ノーオペレーション命令（ＮＯＰ）をシステムコール（例えば、日時コール）と置換することによって行われることができる。
ユーザプログラム命令ストリームが、単なる置換を許容していない場合には、命令は、その置換される命令を指し示す分岐命令、システムコールおよび復帰分岐命令と置換されうる。
これらの変更は、ユーザプログラムがメインメモリに存在するときはユーザプログラムに対して行うことができ、かつ／または、ユーザプログラムがディスクドライブ等の長期記憶デバイスにあるときはユーザプログラムに対して行うことができる。
さらに別の実施の形態では、マルチプロセッサコンピュータシステム（協調プロセスおよび非協調プロセスの双方を有するプロセッサ）内の全プロセッサの再統合が、複数のプロセッサ間で非協調プロセスを同期するために使用されうる。
【００７２】
さらに他の代替的な実施の形態では、プロセッサハードウェアは、命令ストリームの特定のポイントに割り込みを挿入するメカニズムをサポートすることができ、この割り込みは、同期および割り込みスケジューリングのためにシステムコールをトリガすることができる。
例えば、Ｉｎｔｅｌ（登録商標）が製造したＩｔａｎｉｕｍ（登録商標）プロセッサファミリーは、「命令ブレークポイントレジスタ」として知られているプロセッサ内のレジスタをサポートする。
このブレークポイントレジスタには、命令ポインタ値がロードされうる。
実際の命令ポインタがブレークポイントレジスタの値と一致すると、割り込みがトリガされる。
したがって、この例示のメカニズムは、割り込みをトリガするために使用されることができ、この割り込みは、次に、同期の目的でシステムコールをトリガする。
ハードウェアベースのメカニズムは、すべてのアーキテクチャでは利用可能でない場合があるが、ユーザプログラムを変更する実施の形態は、汎用的な用途を有することができる。
【００７３】
さらに他の実施の形態では、（非協調プロセスを有するプロセッサおよびプロセスが協調的であるプロセッサの双方について）マルチプロセッサコンピュータシステム内の全プロセッサの再統合（すべてのメモリのコピー）が、論理プロセッサの複数のプロセッサ間で非協調プロセスを同期するために使用されることができる。
【００７４】
上記説明は、本発明の原理およびさまざまな実施の形態の例示であるように意図されている。
当業者には、上記開示を十分に理解することによって、多数の変形および変更が明らかになる。
添付した特許請求の範囲は、このようなすべての変形および変更を包含するように解釈されることが意図されている。
【図面の簡単な説明】
【００７５】
【図１】本発明の実施の形態による計算システムを示す図である。
【図２】本発明の実施の形態による計算システムをより詳細に示す図である。
【図３】本発明の実施の形態による部分的な計算システムを示す図である。
【図４】本発明の少なくともいくつかの実施の形態による例示の時間表である。
【図５Ａ】本発明の実施の形態による割り込みハンドラルーチンによって実施できるフロー図である。
【図５Ｂ】本発明の実施の形態による割り込みハンドラルーチンによって実施できるフロー図である。
【図６】本発明の実施の形態による同期論理回路内で実施できるフロー図である。
【図７】本発明の実施の形態によるシステムコールによって実施できるフロー図である。
【図８】本発明の実施の形態による時間表である。
【図９】本発明の実施の形態による時間表である。
【図１０】本発明の実施の形態による時間表である。
【図１１】本発明の実施の形態による時間表である。
【図１２Ａ】本発明の実施の形態による非協調プロセスハンドラルーチンによって実施できるフロー図である。
【図１２Ｂ】本発明の実施の形態による非協調プロセスハンドラルーチンによって実施できるフロー図である。
【図１３】本発明の実施の形態によるさらに別の時間表である。
【図１４】本発明の実施の形態によるプロセスレベル再統合ルーチンによって実施できるフロー図である。
【符号の説明】
【００７６】
１０００・・・計算システム
１０Ａ、１０Ｂ、１０Ｃ・・・コンピュータシステム
１２・・・論理プロセッサ
１４、１６・・・Ｉ／Ｏデバイス
１８・・・同期論理回路
２２・・・同期論理回路
２６・・・相互接続部
２８・・・投票者論理回路
３０、３２・・・ネットワーク
３４、３６、３８、４０・・・プロセッサ
４２・・・Ｉ／Ｏブリッジメモリコントローラ
４４・・・プロセッサバス
４６・・・メモリモジュール
４８・・・再統合論理回路
５０・・・論理プロセッサ
５２Ａ、５２Ｂ・・・メモリパーティション
５４・・・同期レジスタ
５６・・・投票者論理回路
【図１】
2005285119.tif 000003
【図２】
2005285119.tif 000004
【図３】
2005285119.tif 000005
【図４】
2005285119.tif 000006
【図５Ａ】
2005285119.tif 000007
【図５Ｂ】
2005285119.tif 000008
【図６】
2005285119.tif 000009
【図７】
2005285119.tif 000010
【図８】
2005285119.tif 000011
【図９】
2005285119.tif 000012
【図１０】
2005285119.tif 000013
【図１１】
2005285119.tif 000014
【図１２Ａ】
2005285119.tif 000015
【図１２Ｂ】
2005285119.tif 000016
【図１３】
2005285119.tif 000017
【図１４】
2005285119.tif 000018
【外国語明細書】
METHOD AND SYSTEM EXECUTING USER PROGRAMS ON NON DETERMINISTIC PROCESSORS
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims the benefit of provisional application serial number 60/557812, which is incorporated by reference herein as if reproduced in full below.  Further, this application is related to concurrently filed applications: application serial number 11/042429, titled, “Method and System of Servicing Asynchronous Interrupts in Multiple Processors Executing a User Program”; application serial number 11/042985, titled, “Method and System of Exchanging Information Between Processors”; and application serial number 11/042981, titled, “Method and System of Determining Whether a User Program Has Made a System Level Call.”
BACKGROUND
At least two types of computing faults may be of concern to computer system designers.  A first fault may be the failure of hardware, such as the failure of a processor or an unrecoverable memory error.  A second fault may be a computational fault, such as may be caused by cosmic radiation changing the state of a bit in hardware.  In order for the computer system to remain operational following a failure of hardware or to detect and recover from a computational fault, some computing systems have multiple processors executing the same software applications.  In the event one of the processors experiences a failure of hardware, the computing continues with the one or more processors still functioning properly.  Comparison of outputs of the multiple processors may allow detection and correction of computational faults.
In some cases the processors executing the same software application operate in cycle-by-cycle or strict lock-step, each processor provided a duplicate clocking signal and executing cycle-by-cycle the same software code.  While processor clocking frequencies have increased, so too has the die size.  Increased clock frequency, in combination with larger die sizes, makes it difficult to control phase differences in the clocking signals of computer systems, and therefore also difficult to implement strict lock-step.  Further difficulties may include handling of recoverable errors (soft errors) that occur in one processor, but not others.  To address these difficulties, some computer manufacturers may implement loose lock-step systems where processors execute the same code, but not necessarily in a cycle-by-cycle fashion or at the same wall clock time.  In order to ensure that processors executing the same code do not get too far removed from one another, these systems count executed instructions and, after expiration of a predetermined number of instructions, synchronize by stalling the faster processor to allow the slower processor to catch up.
However, emerging technology in processor design allows non-deterministic processor execution.  Non-deterministic processor execution may mean that multiple processors provided the same software application instructions will not necessarily execute the instructions in the same order, or using the same number of steps.  The differences may be attributable to advances such as speculative execution (such as branch prediction), out of order processing, and soft error recovery implemented within the processor.  Thus, two or more processors executing the same software application may not perform precisely the same sequence of instructions, and therefore strict lock-step fault tolerance, as well as loose lock-step fault tolerance relying on counting of retired instructions, may not be possible.
BRIEF DESCRIPTION OF THE DRAWINGS
For a detailed description of exemplary embodiments of the invention, reference will now be made to the accompanying drawings in which:
Figure 1 illustrates a computing system in accordance with embodiments of the invention;
Figure 2 illustrates in greater detail a computing system in accordance with embodiments of the invention;
Figure 3 illustrates a partial computing system in accordance with embodiments of the invention;
Figure 4 illustrates an exemplary timeline in accordance with at least some embodiments of the invention;
Figures 5A and 5B illustrates a flow diagram that may be implemented by an interrupt handler routine in accordance with embodiments of the invention;
Figure 6 illustrates a flow diagram that may be implemented within a synchronization logic in accordance with embodiments of the invention;
Figure 7 illustrates a flow diagram that may be implemented by a system call in accordance with embodiments of the invention;
Figure 8 illustrates a timeline in accordance with embodiments of the invention;
Figure 9 illustrates a timeline in accordance with embodiments of the invention;
Figure 10 illustrates a timeline in accordance with embodiments of the invention;
Figure 11 illustrates a timeline in accordance with embodiments of the invention;
Figure 12A and 12B illustrates a flow diagram that may be implemented by an uncooperative process handler routine in accordance with embodiments of the invention;
Figure 13 illustrates yet another timeline in accordance with embodiments of the invention; and
Figure 14 illustrates a flow diagram that may be implemented by a process level reintegration routine in accordance with embodiments of the invention.
NOTATION AND NOMENCLATURE
Certain terms are used throughout the following description and claims to refer to particular system components.  As one skilled in the art will appreciate, computer manufacturing companies may refer to a component by different names.  This document does not intend to distinguish between components that differ in name but not function.
In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to… .”  Also, the term “couple” or “couples” is intended to mean either an indirect or direct connection.  Thus, if a first device couples to a second device, that connection may be through a direct connection, or through an indirect electrical connection via other devices and connections.
DETAILED DESCRIPTION
The following discussion is directed to various embodiments of the invention.  Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure.  In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure is limited to that embodiment.
Figure 1 illustrates a computing system 1000 in accordance with embodiments of the invention.  In particular, the computing system 1000 may comprise a plurality of multiprocessor computer systems 10.  In some embodiments, only two multiprocessor computer systems 10 may be used, and as such the computing system 1000 may implement a dual-modular redundant (DMR) system.  As illustrated in Figure 1, the computing system 1000 comprises three multiprocessor computer systems 10, and therefore implements a tri-modular redundant (TMR) system.  Regardless of whether the computer system is dual modular redundant or tri-modular redundant, the computing system 1000 implements fault tolerance by redundantly executing user programs across the multiprocessor computer systems.
In accordance with embodiments of the invention, each multiprocessor computer system 10 preferably comprises one or more processors, and as illustrated in Figure 1 four processors.  Each processor of Figure 1 has a leading “P,” indicating a processor.  Further, each processor is given a letter designation of “A,” “B,” or “C,” to indicate the processor’s physical location within one of the multiprocessor computer systems 10A, 10B and 10C respectively.  Finally, each processor is given a numerical designation to indicate that processor’s location within each multiprocessor computer system.  Thus, for example, the processors in multiprocessor computer system 10A have designations “PA1,” “PA2,” “PA3,” and “PA4.”
In accordance with embodiments of the invention, at least one processor from each multiprocessor computer system 10 may be logically grouped to form a logical processor 12.  In the illustrative embodiments of in Figure 1, processors PA3, PB3, and PC3 are grouped to form the logical processor 12.  In accordance with embodiments of the invention, each processor within a logical processor substantially simultaneously executes duplicate copies of a user program, thus implementing fault tolerance.  More particularly, each processor within a logical processor is provided the same instruction stream for the user programs and computes the same results (assuming no errors), but the processors within the logical processor are not in cycle-by-cycle or strict lock-step; rather, the processors are loosely lock stepped, with synchronization and handling of interrupts occurring based on rendezvous points (discussed below).  In accordance with some embodiments, the processors may have non-deterministic execution, and thus strict lock step may not be possible.  In the event one of the processors fails, the one or more remaining processors may continue without affecting overall system performance.
Inasmuch as there may be two or more processors within a logical processor executing the same user program, duplicate reads and writes may be generated, such as reads and writes to input/output (I/O) devices 14 and 16.  The I/O devices 14 and 16 may be any suitable I/O device, e.g., a network interface card, a floppy drive, a hard disk drive, a CD ROM drive and/or a keyboard.  In order to compare the reads and writes for purposes of fault detection, each logical processor has associated therewith a synchronization logic.  For example, processors PA1, PB1 and PC1 may form a logical processor associated with synchronization logic 18.  Likewise, the processors PA2, PB2 and PC2 may form a logical processor associated with synchronization logic 20.  The logical processor 12 may be associated with synchronization logic 22.  Finally, processors PA4, PB4 and PC4 may form a logical processor associated with synchronization logic 24.  Thus, each multiprocessor computer system 10 may couple one each to each of the synchronization logics 18, 20, 22 and 24 by way of an interconnect 26.  The interconnect 26 may be a Peripheral Component Interconnected (PCI) bus, and in particular a serialized PCI bus, although other bus and/or network communication schemes may be equivalently used.
Each synchronization logic 18, 20, 22 and 24 comprises a voter logic unit, e.g., voter logic 28 of synchronization logic 22.  The following discussion, while directed to voter logic 28 of synchronization logic 22, is equally applicable to each voter logic unit in each of the synchronization logics 18, 20, 22 and 24.  The voter logic 28 acts to consolidate read and write requests from the processors, and plays a role in the exchange of information between processors.  Consider for purposes of explanation each processor in logical processor 12 executing its copy of a user program, and that each processor generates a read request to network interface 34.  Each processor of logical processor 12 sends its read request to the voter logic 28.  The voter logic 28 receives each read request, compares the read requests, and (assuming the read requests agree) issues a single read request to the network interface 34.
In response to the single read request issued by a synchronization logic, the illustrative network interface 34 returns the requested information to the voter logic 28.  In turn, the voter logic replicates and passes the requested information to each of the processors of the logical processor.  Likewise, for other input/output functions, such as writes and transfer of packet messages to other programs (possibly executing on other logical processors), the synchronization logic ensures that the requests match, and then forwards a single request to the appropriate location.  In the event that any one processor in a logical processor does not function properly (e.g., fails to generate a request, fails to generate a request within a specified time, generates a non-matching request, or fails completely), the user program may continue based on requests of the remaining processor or processors of the logical processor.  Likewise for externally generated communications, the synchronization logic duplicates the external communication and provides the communication to each processor.  In the case of externally generated requests for direct memory access (also known as remote DMA), the synchronization logic duplicates the requests for distribution, and compares and consolidates data provided by each processor based on those requests.
In addition to consolidating reads and writes to external interfaces (such as network interface 34), and duplicating messages and data from those external interfaces, synchronization logics also play a role in ensuring each processor is provided the same time of day when a request for that information is made.  In particular, user programs may at certain points in their execution make system calls requesting time of day information.  A system call is any call to a privileged program (executed in a higher privileged mode than a user mode), such as operating system programs.  A system call to obtain time of day information is only one example of the family of programs that fall within the category of system calls, and the role of system calls in synchronizing user programs between processors in a logical processor and handling interrupts will be discussed more fully below.  In order that each user program is provided the same time of day at corresponding execution points in the user program (in spite of the differences in wall clock time when those execution points are reached), synchronization logics in accordance with embodiments of the invention provide the time of day information to each processor in a logical processor.  That is, as part of the process of scheduling a point in each user program in each processor to service interrupts (discussed more thoroughly below), the synchronization logics provide time of day information to each processor.  Rather than internally deriving time of day when a user program so requests, time of day system calls in accordance with embodiments of the invention utilize the most recent time of day information provided by the synchronization logics.  In this way, each user program is provided the same time of day information independent of whether the user programs are executing at precisely the same wall clock time.
Figure 2 illustrates in greater detail a multiprocessor computer system 10.  In particular, Figure 2 illustrates that a multiprocessor computer system 10 in accordance with embodiments of the invention may have a plurality of processors, in the illustrative case of Figure 2 four such processors 34, 36, 38 and 40.  While only four processors are shown, any number of processors may be used without departing from the scope and spirit of the invention.  The processors 34-40 may be individually packaged processors, processor packages comprising two or more processor dies within a single package, or multiple processors on a single die.  Each of the processors may couple to an I/O bridge and memory controller 42 (hereinafter I/O bridge 42) by way of a processor bus 44.  The I/O bridge 42 couples the processors 34-40 to one or more memory modules 46 by way of a memory bus 45.  Thus, the I/O bridge  42 controls reads and writes to the memory area defined by the one or more memory modules 46.  The I/O bridge 42 also allows each of the processors 34-40 to couple to synchronization logics (not shown in Figure 2), as illustrated by bus lines 43.
Still referring to Figure 2, the memory defined by the one or more memory modules 46 may be partitioned, one partition for each processor, therefore allowing each of the processors to operate independently.  In alternative embodiments, each processor may have its own integrated memory controller, and thus each processor may have its own dedicated memory, and this too would be within the contemplation of the invention.  The computing system 1000, of which the multiprocessor computer system 10 may form a part, implements loosely lock stepped execution of user programs among processors within a logical processor.  Loosely lock stepped may mean that that each processor of a logical processor (e.g., logical processor 12) may execute a duplicate copy of a user program, but the instructions need neither be executed in a strict lock step fashion, nor executed at the same wall clock time.  Thus, the processors 34-40 may be of various architectures, including (but not limited to) non-deterministic processors which may not be suitable for strict lock-step execution or on counting retired instructions.  Intel’sR ItaniumR processor family (IPF) is one example of a family of processors that performs non-deterministic execution and therefore is not suitable for strict lock-step execution or on counting retired instructions.
Figure 2 further shows that each multiprocessor computer system 10 comprises a reintegration logic 48 coupled between the I/O bridge 42 and the memory modules 46.  The illustrative embodiments of Figure 1 show the interconnections of the reintegration logics (line 51) in the form of a ring, but any network topology may be equivalently used (e.g., ring, tree, dual rings, fully connected).  In operation, the reintegration logic 48 is transparent to the I/O bridge 42, and does not interfere with reads and writes to the one or more memory modules 46.  However, in the event that one processor within a logical processor experiences a fault and needs to be restarted, the reintegration logic 48 plays a role.
When restarting a processor it is desirable to begin execution of the user program at the same point as the processors in the logical processor which did not experience an error.  Stated otherwise, the restarted processor may pick up at the point the other processors have reached in the user program rather than where the processor experienced a transient failure or hardware error.  In the embodiments illustrated in Figure 2, the reintegration logic 48 in each multiprocessor computer system 10 duplicates the memory from a memory of a non-failed multiprocessor computer system that did not experience an error of one of its processors.  Thus, referring again to Figure 1, line 51 illustrates that each of the multiprocessor computer systems 10 have their reintegration logics 48 coupled together to facilitate the duplication of memory partitions so that restarted multiprocessor computer systems may begin from the same state as other processors in the logical partition.  Duplication of the entire memory, and subsequent restarting of all the processors in a multiprocessor computer system because of the failure of one processor in the system, may be dictated by having only a single memory controller (I/O bridge) 42.  In alternative embodiments, there may be a plurality of memory controllers (e.g., one each for each processor), and thus only a portion of the memory may need to be duplicated (i.e., those memory partitions that correspond to the memory controller used by the processor that requires restarting), and likewise only a portion of the processors may need to be restarted (i.e., those that are associated with the memory that was duplicated).
In a loosely lock stepped system, the reasons a processor may lead or lag may be many.  For example, while each processor may execute instructions at substantially the same clock frequency, even minor differences in actual clock frequency may result in substantial differences over time (timing nondeterminism).  Moreover, processors implemented in accordance with at least some embodiments of the invention have non-deterministic execution, and thus even provided precisely the same user program the processors may diverge greatly in the number of executing steps to arrive at a common point in the user program.  Further still, some processors could encounter data access delays and/or fixable errors (non-architecturally visible state nondeterminism).  Some examples may be: one processor may experience a cache miss that other processors may not experience; one processor may experience a correctable memory error, thus requiring execution of a recovery routine not needed by the remaining processors; and one processor may experience a miss of the translation look aside buffer, causing additional processing but not affecting final outcome of the user program.  Again, while the processors eventually arrive at the same execution point in the user program, the number of instructions executed and the time required to execute those instructions may not be the same.
With the idea in mind that processors of a logical processor may be executing the same instruction stream, but may not be at the same point in the instruction stream, the discussion turns to handling of interrupts in such an environment.  Even if the same interrupt is asserted to each processor at precisely the same wall clock time, by virtue of the loosely lock stepped execution of their respective processors the interrupts may not be asserted at the same execution point of the user program.  The difficulty is further exacerbated by the fact that interrupt assertion itself is asynchronous.  In order to ensure proper operation, each processor within a logical processor needs to service interrupts at the same execution point in the instruction stream of the user program.  Ensuring interrupts are serviced at the same execution point in the instruction stream is accomplished in accordance with embodiments of the invention by utilizing the synchronization logic as a mechanism to agree on a rendezvous point at which to service the interrupt.
In accordance with embodiments of the invention, processors within a logical processor communicate with each other that: particular interrupts have been asserted; and a proposed point in the user program at which to suspend execution and to service the interrupt.  Stated otherwise, processors in a logical processor agree on which interrupt to be serviced (or to be serviced first) and also agree on a point in the user program at which to service the interrupt.  Figure 3 illustrates a partial computing system 1000 in order to describe the operation of the various components that work together to coordinate servicing of interrupts.  Figure 3 is a simplified version of the system of Figure 1 in the sense that the logical processor 50 in this case comprises only two processors PA1 and PB1.  Figure 3 is also, in another sense, more detailed than Figure 1 inasmuch as Figure 3 illustrates the memory partition 52 for each processor, and how the processor couples to the memory partition and the voter logic through the I/O bridge 42.  Thus, the logical processor 50 of Figure 3 comprises one processor each from the multiprocessor computer systems 10A and 10B.  Processor PA1 couples to I/O bridge 42A, which in turn couples both to the synchronization logic 18 and PA1 processor’s memory partition 52A.  Processor PB1 couples to its respective I/O bridge 42B, which in turn couples to the synchronization logic 18 and PB1 processor’s memory partition 52B.
In accordance with at least some embodiments, having the processors of a logical processor exchange information for purposes of establishing a rendezvous point involves each processor writing information to synchronization registers 54 in the voter logic 56 of the synchronization logic 18.  A rendezvous point, in accordance with embodiments of the invention, may be any suitable location, such as: each time a dispatcher function of the operating system executes and sets other tasks to execution; traps and fault handlers; and system calls made by user programs.  The term "system call" is used in this specification, and in the claims, to refer to any potential rendezvous point.  A system call number may be a number which indicates how many system calls have been made from an arbitrary staring point.  Location 72 of Figure 3 illustrates a location in a memory partition 52 at which a system call number may reside.  In alternative embodiments, the system call number may be equivalently stored in a register located other than in memory partition 52. In the embodiments illustrated in Figure 3, the synchronization registers 54 are pre-designated memory locations, but any location where data may be written will suffice.  After some or all of the processors have written their respective information, voter logic 56 writes the information in the synchronization registers 54 back to corresponding set of registers 57 in each of the memory partitions 52.  The voter logic 56 may also write other information to the registers 57 during the write back operation, such as time of day information.  Writing the information to the synchronization logic allows the processing of the user program to continue while waiting for the remaining processors to see the interrupt.  In alternative embodiments, each processor may make a waited read to the memory locations in the synchronization registers 54, waiting meaning that the read will not complete until each processor writes the corresponding information regarding the interrupt. While the waited read as a byproduct may act to synchronize the processors, each processor waits in a software loop for the read to complete, and thus waited reads as a mechanism to exchange information regarding interrupts does not allow the user program to continue execution.  Regardless of how the data exchange is performed, by exchanging information the processors within a logical processor coordinate at what point in the user program to service an interrupt.
Interrupts may be asserted to a processor at any time by way of packet-based messages containing interrupt information, or by way of dedicated interrupt signal lines.  Interrupts may also be asserted to a processor from an internal source, such as a timer that is set to expire after some number of processor clock cycles.  When such a packet, signal line or internal interrupt is received and detected by the processor, the user program is suspended and an interrupt handler routine is invoked.  The purpose of the interrupt handler routine is to begin the process of identifying the rendezvous point.  No action is taken with respect to the services requested by the interrupt by the interrupt handler routine.  Rendezvous points (e.g., system calls) are the points at which the process of scheduling the rendezvous point is completed, and also scheduling programs to service the interrupts received.
Figure 4 shows an illustrative timeline (with time increasing down the page) of a set of events in accordance with embodiments of the invention.  The vertical bars underneath the references PA1 and PB1 represent, respectively, execution by those processors of programs.  The blocks between the vertical lines represent hardware and/or events, and the lines between the central blocks and the vertical bars represent interaction of the various components as a function of time.  Referring simultaneously to Figures 3 and 4, assume that each processor receives an interrupt (as indicated by block 58 and the arrows pointing to each of the vertical bars).  As illustrated, the interrupt is asserted to each processor at different times.  When the interrupt is received, the user program is suspended and interrupt handler routine is executed (as exemplified by cross-hatched area 59).  The interrupt handler routine determines the nature of the interrupt, and writes information regarding the interrupt along with a proposed system call number at which to service the interrupt to the synchronization registers.  The write of the interrupt information and proposed system call number is illustrated by line 60 exemplifying that processor PA1 received an interrupt 5, and that this processor proposes that the interrupt be serviced at system call number 1001.  Likewise with respect to processor PB1, though the interrupt may be asserted at a slightly different time in the user program, an interrupt handler routine is executed soon thereafter (cross-hatched area 59), and the interrupt handler routine writes an indication to the synchronization registers 54 that an interrupt has been received and a proposed system call number at which to service the interrupt, as indicated by line 62.  As soon as a interrupt handler routine completes its write to the synchronization registers, the user program continues execution (beginning at points 61 and 63).
Once all the processors within a logical processor have written their respective data to the synchronization registers 54, the voter logic 56 writes at least a portion of the information in the synchronization registers 54 to the corresponding registers 57 in the memory partition of each processor in the logical processor.  In accordance with at least some embodiments of the invention, information from all processors is written back to each individual processor along with time of day information.
The system call number at which to service an interrupt is, in some embodiments, the highest system call number proposed by any of the processors within the logical processor.  When each individual processor reaches the designated system call number (e.g., makes a time of day call whose system call number is the highest proposed system call number), the system call program of each individual processor places an interrupt service routine in its respective dispatch queue for execution, in addition to performing its designated task.  Thus, processor PA1 executes the service routine for interrupt 5 (as indicated by shaded area 67) just after the execution of the previously determined system call number (in this case SCN 1001; indicated by shaded area 64 in the PA1 time line).  Alternatively, the service routine may be performed immediately before the system call.  At some time thereafter, the lagging processor PB1 reaches the previously determined system call number (SCN 1001), executes the system call (shaded area 66), and executes the interrupt service routine for the exemplary interrupt 5 (shaded area 67 in the PB1 time line).  Thus, though both processors do not receive the interrupt at the same time, and the processors are only loosely lock stepped, interrupts are serviced at the same point in the user program.  Note that, as illustrated in Figure 4, normal processing within each processor continues after the receipt of the interrupt and execution of the interrupt handler routine until the arrival at the system call number at which to execute the interrupt service routine.  Note also that in the illustrative case of Figure 4 the processors are minimally divergent in terms of their execution point of the user program, and thus in the illustrated method neither processor is stalled or slowed.  The series of events illustrated in Figure 4 is a simple case, and is presented to orient the reader to the nature of the interrupt handling in accordance with embodiments of the invention.  Other cases are presented below after a more detailed description of the steps taken by the interrupt handler routine, as well as steps performed by system calls in accordance with embodiments of the invention.
Figure 5 (comprising 5A and 5B) illustrates a flow diagram of an interrupt handler routine in accordance with embodiments of the invention.  The process may start (block 500) by the assertion of an interrupt and execution of the interrupt handler routine.  The next steps may be disabling interrupts (block 502), followed by a determination of whether the interrupt that triggered the interrupt handler was the expiration of an uncooperative process timer (block 504).  If an uncooperative process timer caused this instance of the interrupt handler, an uncooperative process handler is called (block 506).  Uncooperative processes, and how to handle them in accordance with embodiments of the invention, are discussed more fully below with respect to Figure 12.  Assuming that the interrupt is not caused by expiration of the uncooperative process timer, the triggering interrupt is added to the pending list (block 508), including an indication of the interrupt type. In systems implementing processors from the ItaniumR processor family, determining the interrupt type may be accomplished by reading the interrupt vector register (IVR).  Thus, the pending list is a list of interrupts that have been asserted, but for which the process of scheduling a rendezvous point has yet to begin.
The next step in the illustrative process may be a determination of whether there has been an attempt to schedule a rendezvous point that has yet to complete (block 510).  From the point of view of a processor, scheduling a rendezvous may be a two step process: writing proposed rendezvous information to the synchronization registers 54; and receiving confirmation from some or all the processors of the logical processor.  Scheduling of a rendezvous point that has yet to complete may thus be the situation where data has been written to the synchronization registers 54 that has yet to be returned, or for which data has been returned but has yet to be analyzed.  If there is not an outstanding attempt to schedule a rendezvous point, the illustrative method may select the highest priority interrupt from the pending list (block 512), which could be the triggering interrupt or other higher priority interrupt previously placed in the pending list.  Alternative embodiments may select a plurality of the highest priority interrupts from the pending list.  Thereafter, the registers 57 in the memory partition (to which the voter logic will eventually write data) are cleared, and the interrupt number and proposed system call number at which to service the interrupt are written to the synchronization registers 54 (block 514).  The system call number may be a number residing within the memory partition 52 of each processor (as illustrated in Figure 3 by location 72) which indicates how many system calls have been made from an arbitrary starting point.  In accordance with at least some embodiments of the invention, the proposed system call number may be the current system call number incremented by one.  Incrementing the system call number by more than one to create the proposed system call number is also within the scope and spirit of the invention.  Writing of the interrupt identifier and the proposed system call number (block 512) is illustrated in Figure 4 by line 60 (for processor PA1) and line 62 (for processor PB1).
Bypassing for now a discussion of immediate action interrupts, after writing the synchronization registers, the next step in the process may be writing the interrupt number and proposed system call number to a pending rendezvous log and remove the interrupt(s) from the pending list (block 518).  The pending rendezvous log is thus a list of interrupts for which proposals have been made, but for which either confirmation has yet to be received, or for which no agreement has been reached.  Once confirmation is received from the voter logic that the other processors agree, the program implementing Figure 5, as well as other programs (in particular system call programs as discussed with respect to Figure 7), clear the entry from the pending rendezvous log.  In accordance with at least some embodiments of the invention, the pending rendezvous log may be a set of memory locations 46 within each processor’s memory partition (see Figure 3).  Thereafter, interrupts are enabled (block 520), and the interrupt handler process ends (block 522).  The discussion now turns to immediate action interrupts in the context of the interrupt handler routine.
As discussed with respect to Figure 4, user programs may resume execution after assertion of an interrupt, thus giving time for the processors to agree as to which interrupt to service, and a system call number at which to service the interrupt.  However, some interrupts need to be serviced immediately (without allowing the user program to continue), and thus may be referred to as “immediate action interrupts.”  Immediate action interrupts may comprise page faults, as well as actions to correct uncooperative processes.  Interrupts that are not of the immediate action type may comprise input/output (I/O) completion interrupts, queued event interrupts, and software event interrupts to exchange information between processors during boot operations.  Returning to the determination of whether there has been an attempt to schedule a rendezvous point that has yet to complete (block 510), if there is an outstanding attempt to schedule a rendezvous point, the next step may be checking whether the voter logic has written back information regarding a previously unconfirmed rendezvous point (block 524).  If the voter logic has yet to write back data (block 524), the next step may be a determination of whether there is an immediate action interrupt on the pending list (block 528).  If no immediate action interrupt is on the pending list (block 528), interrupts are enabled (block 520) and the process ends (block 522) because the scheduling of the rendezvous point for the previous interrupt has yet to complete, and in accordance with some embodiments only one scheduling attempt may be active at any one time.  If, on the other hand, there is an immediate action interrupt on the pending list (block 528), the process waits in a software loop (block 530) for write back of data from the previous scheduling attempt.  When the voter logic writes the data back to the registers 57, the process moves to the illustrative method steps of Figure 5B.  Likewise, If there is an outstanding attempt to schedule a rendezvous point (block 510), and the voter logic has written back data (block 524), the illustrative method steps of Figure 5B are invoked.  The illustrative process may also arrive at waiting in a software loop (block 530), and subsequently the illustrative steps of Figure 5B, by way of a determination of whether the interrupt just proposed was an immediate action type (block 516).
Figure 5B illustrates steps taken in response to return of data from the voter logic.  In particular, a determination is made as to whether an immediate action interrupt was proposed (block 550) in this execution of the interrupt handler.  If this illustrative sub-process was entered by way of block 524 (of Figure 5A), then an immediate action interrupt was not previously proposed by this processor.  If, however, this illustrative sub-process was entered by way of block 530 (of Figure 5A), then either an immediate action interrupt was previously proposed, or there is an immediate action interrupt on the pending list.  If the previously proposed interrupt by this processor was not an immediate action type, a determination is made as to whether other processors proposed servicing of an immediate action interrupt (block 552).  If so, the interrupt on the pending rendezvous log is moved back to the pending list (block 560), and execution resumes with selecting the highest priority interrupt from the pending list (block 512 of Figure 5A).  If other processors of the logical processor did not propose servicing an immediate action interrupt (again block 552), a notation is made on the pending rendezvous log as to the interrupts and system call numbers at which to service those interrupts proposed by the other processors (block 553).  Thereafter, a determination of whether the processors agree as to the which interrupt to service (block 554).  For interrupts for which there is agreement, the one or more interrupts on the pending rendezvous log for which there is agreement are moved to the confirmed list (block 562), and execution resumes with selecting the highest priority interrupt from the pending list (block 512 of Figure 5A).  Thus, except for the case where another processor proposes an immediate action interrupt (block 552 and 560), once placed on the pending rendezvous log interrupts will there remain until there is agreement of the processors to service the interrupts.
Still referring to Figure 5B, and returning to block 550, if the previously proposed interrupt was an immediate action type (entry through block 530), then data returned by the voter logic is analyzed to determine if other processors in the logical processor likewise proposed servicing the immediate action interrupt (block 558).  If so, an appropriate immediate action interrupt service routine is invoked (block 564) and its indication removed from the pending list, and upon return from the service routine execution resumes with selecting the highest priority interrupt from the pending list (block 512 of Figure 5A).  If the processors do not agree, the immediate action interrupt is placed back on the pending list (block 566), and execution resumes with selecting the highest priority interrupt from the pending list (block 512 of Figure 5A).  In this case however, the immediate action interrupt just placed on the list will be the highest priority interrupt, and thus the interrupt handler routine of Figure 5 immediately again begins the process of getting the processors of the logical processor to agree to service the immediate action interrupt.
Figure 6 illustrates a flow diagram of the process that may be implemented within the synchronization logic 18 to perform its portion of scheduling the rendezvous point.  The steps illustrated in Figure 6 may be implemented either in software executed on a processor or a microcontroller as part of the synchronization logic (not specifically shown), or the process may be implemented in hardware, possibly by way of an application specific integrated circuit (ASIC) designed as a state machine to implement the illustrative steps.  The process starts (block 600), and moves to a determination of whether there is data in the trigger register of the synchronization registers 54 (block 602).  In some embodiments, the synchronization logics 18 may be unaware of whether data written is “new” or “old.”  In these embodiments, of the registers 54 to which each processor writes, at least one may act as a trigger register, starting a timer as part of the process to wait for data from all processors before writing at least some of the data received to each processor.  In alternative embodiments, the synchronization logics 18 may be sufficiently sophisticated to be able to compare data to determine whether it is “old” or “new.”
Once a processor writes a trigger register (block 602), a determination is made as to whether there is more than one processor in the logical processor (block 603).  For example, if one processor fails in a duplex system, the logical processor may be operating with only a single processor.  Likewise, if two processors fails in a tri-modular system, the logical processor may be operating with only a single processor.  In the event only one processor is active in the logical processor, the data may be immediately written back (block 618).
Assuming that more than one processor is active within the logical processor, a timer is started (block 604) and a determination is made as to whether a second processor of the logical process writes its respective trigger register (block 606).  If not, the process waits in a software loop (blocks 606 and 608) until the trigger register is written or the timer expires.  If there are more than two processors in the logical processor (block 610), the timer is restarted (block 612) and again the process waits in a software loop (blocks 614 and 616) until the trigger register for the third processor is written or the timer expires.  The method of Figure 6 is illustrative of a logical processor comprising three processors.  If more processors are present, additional timer restarts and waits in a software loop may be added.  Likewise, if a logical processor comprises only two processors, the steps associated with the third processor may be omitted.  If all data has been received, at least some of the data is written to each logical processor (block 618), along with time of day data.  If one of the processors fails to write its respective trigger register before expiration of the timer, at least a portion of the data that was written to the synchronization logic 18 is written back to each processor (block 620).  In addition to writing the data supplied by the processors, a status word may also be written to each memory partition; the status word indicates that the operation is complete, an indication of which processors took part in the operation, and which processors (if any) timed out (again block 620).  If one processor fails to write in the allotted time, the offending processor is removed from the logical processor (block 622), and the illustrative process begins anew.  In accordance with at least some embodiments of the invention, if a processor does not write data to the synchronization register within a few milliseconds of the first processor, then corrective action should be taken.
Because the logical processors of the various embodiments implement loosely lock stepped execution, the times at which the interrupt handler routines (and as we shall later see, the system calls) of each processor writes data to the synchronization register 54 may not precisely align.  Thus, the combination of blocks 604 616 allow a certain amount of leeway in which all the processors may detect and react to the interrupts.  Referring briefly to Figure 3, the confirmation data write from the synchronization registers back to each processor may involve copying the data from the synchronization registers 54 to a location in each memory partition, e.g., location 57A and 57B.  In accordance with at least some embodiments of the invention, the data written to the memory partitions by the voter logic 56 is aligned with the natural cache block alignment of the host processor.
Summarizing before continuing, an interrupt triggers execution of the interrupt handler routine.  The hashed areas 59 in Figure 4 represent execution of the interrupt handler routine and thus that the user program is suspended momentarily.  Assuming there is not a currently incomplete attempt to schedule the rendezvous point, the interrupt handler writes an interrupt identifier, along with a proposed system call number at which to service the interrupt, to the synchronization registers 54 in the voter logic 56 (see lines 60 and 62 of Figure 4; block 514 of Figure 5).  Once each processor within a logical processor writes its information, voter logic 56 writes at least some of the information to the location 57 in the memory partition of each processor (see line 65 of Figure 4; blocks 618 or 620 of Figure 6).  At the system call having the appropriate system call number, an interrupt service routine for the interrupt is placed in the scheduler queue and serviced.
Figure 7 illustrates at least a portion of the steps implemented by at least some system calls to act as a rendezvous point and to coordinate interrupt handling, in addition to the system call’s normal task, e.g., retrieving a time of day.  Thus, the method steps presented in Figure 7 do not purport to be the entire set of steps that any one system call may perform; rather, the illustrative flow diagram highlights the additional steps that at least some of the system calls may perform in order to coordinate interrupt handling and in some cases achieve synchronization of the loosely lock-stepped processors.  The process may start (block 700) by a user program issuing a system call, such as a request for the current time of day or for a memory allocation.  Thereafter, the system call program may disable interrupts (block 702) and increment the system call number (block 704) so that the particular processor knows which system call number it is currently executing.  Skipping for now uncooperative processes (blocks 706, 724 and 726), the next step in the process may be a determination of whether there has been an attempt to schedule a rendezvous point that has completed (block 708), which may be determined by checking for non-zero data in registers 57.  If so, the next step may be a determination of whether any other processors proposed servicing an immediate action interrupt (block 730).  If so, the interrupt on the pending rendezvous log is moved back to the pending list (block 736).  In some embodiments, it is assumed that trigger for the immediate action interrupt seen in the other processor(s) will be forthcoming in the instant processor, and thus the situation is ignored and further attempts to schedule a rendezvous point may take place (beginning with the determination of block 712).  In alternative embodiments, processing may begin to address the anticipated error that triggered the immediate action interrupt (not specifically shown).
Returning to block 730, if other processors did not propose servicing an immediate action interrupt, the next step may be recording the interrupts and proposed system call numbers of the other processors in the pending rendezvous log (block 731).  Thereafter, a determination of whether the processors agree as to which interrupt to service (block 734) is made.  If there is agreement, the interrupt is moved from the pending rendezvous log to the confirmed list (block 732), and further attempts to schedule a rendezvous point may take place (beginning with the determination of block 712).  The confirmed list is a list of interrupts for which confirmation has been received that the interrupt should be serviced, and at what system call number the interrupt should be serviced.  If the processors disagree as to which interrupt to service (block 734), e.g., one processor proposes servicing interrupt 5 while a second proposes servicing interrupt 9, then the situation will be rectified at future proposals, and further attempts to schedule a rendezvous point may take place (beginning with the determination of block 712).
If a rendezvous has not completed (block 708), the next step may be a determination of whether there has been a rendezvous started that has yet to complete (block 710).  Skipping for a moment an analysis of the pending list (block 712), the next step in the illustrative process may be checking whether there are any interrupts on the pending rendezvous log that were proposed for the current system call number (block 714).  If so, the illustrative program polls for interrupts (block 716) (because interrupts are disabled by block 702), and the process waits in a software loop (starting with the determination of block 708).  In this situation, the system call number proposed by the instant processor may be the highest system call number, and therefore the processor waits in a software loop for confirmation.
If there are no interrupts on the pending rendezvous log that were proposed to be serviced at the current system call number (block 714), the next step may be a determination of whether there are any interrupts on the confirmed list scheduled for the current system call number (block 718).  Interrupts on the confirmed list scheduled to be serviced at the current system call number thus each have a their interrupt service routines scheduled for execution and their entries removed from the confirmed list (block 720), interrupts are enabled (block 722), and the system performs its normal activity (e.g., a time of day call) (block 723).  Referring briefly to Figure 4, where the current system call program ends (hatched areas 64 and 66), the one or more interrupt service routines placed in the task scheduler execute, as indicated by hatched areas 67.  Alternatively, the interrupt service routine may execute prior to the performing the primary function of the system call.  If there are no interrupts on the confirmed list having a rendezvous at the current system call number (block 718), interrupts are enabled (block 720), and the system performs its normal activity (block 723).
In accordance with at least some embodiments of the invention, after at least one interrupt number and proposed system call number are written to the voter logic and the same information is written to the pending rendezvous log (blocks 514 and 518 of Figure 5), no further proposals for rendezvous points may be started until the voter logic returns the data.  Thus, some interrupts may be placed on the pending list (block 508 of Figure 5) for future scheduling.  With the write to the confirmed list (block 732), the return to the pending list of an interrupt on the pending rendezvous log (block 736), or the disagreement as which interrupt to service (block 734), there exists an opportunity to begin again the rendezvous point scheduling process.  For this reason, the system call program may perform a similar effort as the interrupt handler, and determine if any interrupts need to be scheduled for service by checking the pending list (block 712).  If there are interrupts that need to be scheduled, the system call performs the initial phase of the scheduling process, including writing the proposed rendezvous information to the synchronization registers 54 (block 740).  The steps involved in performing the initial phase of the rendezvous scheduling are illustrated in greater detail in Figure 5, blocks 512, 514, 516, 530 and 550 566. These same steps may be performed by the system call program, but are combined into a single entry in the illustrative method (block 740) so as not to unduly complicate the figure.
Figure 8 illustrates a situation that may be encountered where one processor of a logical processor sees an interrupt before another, yet they agree at which system call number the interrupt should be serviced.  In particular, processor PA1 performs system call number 1003 just prior to assertion of the interrupt, whereas processor PB1 performs system call number 1003 well before the assertion of the interrupt.  Both processors propose that the exemplary interrupt 5 be serviced at system call number 1004, as indicated by lines 100 and 102.  In this exemplary case, however, processor PB1 reaches system call number 1004 prior to writing of the synchronization data back to the processors by the voter logic 56.  In this case, processor PB1 waits in a software loop (blocks 708, 710, and 714 of Figure 7), as indicated by shaded area 104, until data is written back that confirms that the interrupt will be serviced at system call number 1004.  Likewise, prior to writing by the voter logic, processor PA1 reaches system call number 1004, and likewise processor PA1 waits in a software loop (again blocks 708, 710 and 714 of Figure 7), as indicated by the shaded area 106.  When the voter logic associated with the exemplary two processors writes the gathered information back to the memory partition of each of the processors, and the system call programs confirm that system call number 1004 is where the interrupt should be serviced (blocks 732 and 734 of Figure 7), both processors service the interrupt (block 720 of Figure 7) and continue normal processing.  Note how the two processors, while initially somewhat divergent in terms of their execution point, become at least partially synchronized upon the writing of the synchronization registers from the voter logic and subsequent servicing of the interrupt.
Figure 9 illustrates a situation in which processors of a logical processor propose or advertise servicing of different interrupt numbers.  In the illustrative case shown in Figure 9, the processor PA1 has its interrupts enabled just prior to the assertion of interrupt 5, and therefore processor PA1 proposes servicing interrupt 5 at system call number 96.  However, processor PB1 does not enable its interrupts until after assertion of interrupts 5 and 9.  Assume for purposes of explanation that interrupt 9 is of higher priority than interrupt 5.  After enabling of interrupts, therefore, processor PB1 proposes servicing interrupt 9 (because of its higher priority) at illustrative system call number 96.  Because processor PA1 in this case reaches system call number 96 prior to writing of the data from the synchronization registers back to the memory partition, processor PA1 waits in a software loop (blocks 708, 710 and 714 of Figure 7).  Likewise, processor PB1 reaches system call number 96 prior to confirmation of whether its proposed interrupt 9 will be serviced at system call number 96, and likewise it too waits in a software loop for confirmation.  When the voter logic writes the synchronization data back to each processor’s memory partition, each processor notes an interrupt type mismatch (one processor proposed servicing interrupt 5 while the second processor proposed servicing interrupt 9) (block 734 of Figure 7).  In each case, the processors then propose their highest priority interrupts not previously proposed (blocks 712 and 740 of Figure 7).  In the case of illustrative PA1, interrupt 9 is the highest priority interrupt, and thus it is proposed.  Moreover, since processor PA1 had previously proposed servicing of interrupt 5 at system call number 96, and that proposal is still outstanding, the system call continues to wait in a software loop (blocks 708, 710 and 714, of Figure 7).  With regard to illustrative processor PB1, the highest priority interrupt not previously proposed is interrupt 5, and thus interrupt 5 is proposed (blocks 712 and 740 of Figure 7).  With the write back of data from the second illustrative write of Figure 9, the processors agree to servicing of both interrupts 5 and 9 at the highest proposed system call number, in this case 97.  When system call number 97 occurs in each processor, the interrupts are serviced (blocks 718 and 720), highest priority interrupt first.
In the illustrative systems of Figures 4, 8 and 9, each of the interrupts asserted is an event-type interrupt, meaning that the interrupt signifies an event but immediate action may not be required.  However, immediate action interrupts are handled differently.  Figure 10 illustrates a time line of handling of immediate action interrupts, such as page faults, in accordance with embodiments of the invention.  In the illustrative case of Figure 10, processor PB1 experiences an immediate action interrupt, in this illustrative case a page fault (PF).  The interrupt handler routine is triggered, the immediate action interrupt nature is determined (block 516 of Figure 5), and an indication of the immediate action interrupt is written to the synchronization registers (block 514 of Figure 5). In accordance with embodiments of the invention, the processor PB1 does not do further execution of the user program, but rather waits in a software loop for confirmation that the other processors have also reached the page fault (blocks 530 of Figure 5).  Still referring to Figure 10, at some time after the page fault for processor PB1, the processor PA1 experiences the corresponding page fault, its interrupt handler routine is triggered, and an indication of the page fault is sent to the synchronization registers.  Once the voter logic receives the data from each processor (or one of the processors times out), that information is written to the memory partitions of each processor (block 618 or 620 of Figure 6), as exemplified by lines 150.  Once the interrupt handler routine confirms that all processors agree on the immediate action interrupt (block 558 of Figure 5), each interrupt handler routine schedules for execution an interrupt service routine for the immediate action interrupt (block 564 of Figure 5).  After completing the interrupt service routine for the immediate action interrupt, the interrupt handler begins anew scheduling of a rendezvous point (beginning with block 512 of Figure 5).  In the illustrative case of a page fault, the interrupt service routine for the immediate action interrupt may be a page fault service routine.  Notice, with reference to Figure 10, that processing stops in each processor until confirmation that all the processors have reached the point in the user program where page fault occurs.
Figure 11 illustrates the relative treatment of event interrupts and immediate action interrupts.  In particular, Figure 11 illustrates that in the exemplary system having two processors PA1 and PB1, processor PA1 receives indication of interrupt 5 prior to a page fault interrupt, whereas processor PB1 receives the interrupt 5 after the page fault interrupt.  In this case, the interrupt handler routine executing on processor PA1 writes a proposal to service interrupt 5 at system call number 1006 (block 514 of Figure 5).  However, the interrupt handler routine executing on processor PB1 (based on the page fault) proposes servicing the page fault, and waits in a software loop until that proposal is confirmed (blocks 514, 516 and 530 of Figure 5).  At some time thereafter, processor PA1 sees its page fault.  In this exemplary situation processor PA1 has an unconfirmed rendezvous (for interrupt 5), and thus upon the execution of the interrupt handler routine triggered by the page fault the processor waits in a software loop (block 530 of Figure 5) until the voter logic writes back the synchronization information.  The voter logic associated with these two processors writes the information in the synchronization registers back to the memory partitions of each of the processors.  However, in this first write of synchronization data to the memory partitions of each processor, one processor proposed servicing interrupt 5 at system call number 1006, while the other processor proposed servicing the page fault.  In this case, each processor scrubs the attempt to service the interrupt (for processor PB1, by operation of block 566, and for processor PA1 by operation of blocks 552, 560 of Figure 5).  In each case, the immediate action interrupt is the highest priority interrupt (selected at block 512 of Figure 5), and thus both processors propose servicing the immediate action interrupt.  Thereafter, voter logic 56 writes the information back to the memory partitions of each processor, and this time in the illustration the processors agree that the page fault should be addressed.  Once the immediate action interrupt has been serviced, at some later time, and still referring to Figure 11, each of the processors PA1 and PB1 propose scheduling the previously asserted interrupt 5 at a particular system call number, in this illustrative case system call number 1006.  Now that the page fault is cleared, servicing of interrupt 5 at system call number 1006 may take place as described in the other exemplary embodiments.  While each of Figures 4 and 8-11 show only two processors, it will be understood that the techniques described are equally applicable to computer systems 1000 having three or more processors in each logical processor.  The descriptions with respect to Figures 4 and 8-11 show two processors so as not to unduly complicate handling of the various event interrupts and immediate action interrupts.
The discussion of scheduling of a rendezvous point shown by Figures 4 and 8-11 is limited to scheduling of only one interrupt at a time.  For example, Figure 4 illustrates that each processor writes a single interrupt number, and proposed system call number at which to service the interrupt, to the synchronization registers.  In accordance with alternative embodiments, multiple interrupts (and proposed system call numbers at which to service the interrupts) may be written to the synchronization registers in an attempt to schedule a rendezvous point for each interrupt.  The various flow diagrams remain unchanged for operation of these alternative embodiments, save that multiple interrupts, in some embodiments three, may be proposed and written to the pending rendezvous log at one time, and likewise multiple interrupts may be moved to the confirmed list.
Further, the various embodiments described to this point utilize three lists: a pending list (interrupts asserted but not yet proposed); a pending rendezvous log (interrupts proposed but for which confirmation has not been received or received but not analyzed); and an agreed or confirmed list (interrupts for which confirmation has been received).  Alternative embodiments may use only two lists: the pending list and the confirmed list.  In these embodiments, one or more interrupts may be proposed at one time, but the interrupts remain on the pending list until there is agreement among the processors as to a rendezvous point.  Once there is agreement for each interrupt, it is moved from the pending list to the confirmed list.  Because only one set of proposals to schedule a rendezvous point may be outstanding, these alternative embodiments may set a flag when data is written to the synchronization registers as an indication of the outstanding attempt.  Likewise, the flag may be reset when confirmation data is returned from the voter logic.  In these alternative embodiments, each interrupt may be proposed multiple times (even in the absence of an immediate action interrupt) before the processors agree to service the interrupt.  Thus, in these alternative embodiments each processor analyzes the returned data to see of other processors agree to servicing of one or more interrupts.  If there is agreement, the agreed interrupts are removed from the pending list and placed on the confirmed list.  For interrupts for which there is no agreement, the returned data is discarded and the process begins anew by selecting the highest priority interrupts from the pending list to propose rendezvous points.
With regard to immediate action interrupts, in the various embodiments described to this point when one processor sees (and proposes) an immediate action interrupt, other processors may continue to propose their highest priority non-immediate action interrupts until such time as they too see the immediate action interrupt.  In alternative embodiments, once at least one processor proposes servicing an immediate action interrupt, the remaining processors may refrain from further proposals of non-immediate action interrupts, and instead continue processing until the corresponding immediate action interrupt occurs.  Thus, non-immediate action interrupts may accumulate in the pending list of each processor until after the immediate action interrupt is serviced.  These alternative embodiments may thus reduce the time it takes for all the processors to reach, agree to, and service the immediate action interrupt.
As discussed above, at least partial synchronization of processors, and coordinated servicing of interrupts, may be accomplished at rendezvous points in accordance with embodiments of the invention.  However, there may be user programs that, for extended periods of time, do not make system calls.  Therefore, it is possible that processors within a logical processor may significantly diverge with respect to the portion of a user program that they are executing, and further may not have ample opportunity to service interrupts.  A user program that does not make system calls with sufficient frequency may be called an “uncooperative process.”
Handling of uncooperative processes may, for purposes of explanation, be considered to have four phases.  The first phase is identification that a user program is indeed uncooperative.  The second phase may be minimizing the likelihood of computational faults that the uncooperative nature of the application causes as between processors in a logical processor, yet allowing the uncooperative process, and other non-related processes, to continue execution in the hope that the process becomes cooperative.  The third phase may be taking action to ensure that the uncooperative process in each processor of a logical processor is at the same stage of execution.  Finally, the last phase may be modifying the formerly uncooperative process.  Each of these phases will be addressed in turn.
In some embodiments, identifying that a user program makes infrequent system calls, and is therefore considered uncooperative, involves the use of a timer.  If the user program does not make a system call before the expiration of the timer, then the user program is an uncooperative process. In accordance with some embodiments of the invention, each time the dispatcher program of a processor (operating in the highest privilege state -- kernel mode) sets a user program to execution, the dispatcher also starts an uncooperative process timer and stores an indication of the current system call number.  At the expiration of the timer, an interrupt is asserted which invokes an uncooperative process handler routine.  The uncooperative process handler routine checks whether there has been at least one system call during the period of time defined by the timer, which in some embodiments may be on the order of 100 micro-seconds.  In alternative embodiments, system call programs may reset the timer to avoid triggering of the uncooperative process handler routine, but these resets may require costly kernel mode process calls.
Figure 12 (comprising 12A and 12B) illustrates a flow diagram of the uncooperative process handler in accordance with embodiments of the invention.  In particular, the uncooperative process handler may start (block 1201) by the assertion of an interrupt after expiration of the timer initiated by the dispatcher, hereinafter referred to as the uncooperative process timer.  Expiration of the uncooperative process timer may start the illustrative Figure 12 directly, or the steps of Figure 12 may be invoked through the interrupt handler by the determination of expiration of an uncooperative process timer (block 504 of Figure 5) and calling of the handler (block 506 of Figure 5).  After disabling interrupts (block 1204) the uncooperative process handler may read the current system call number (block 1208) and the system call number stored by the dispatcher at initiation (block 1212). The current system call number being the same as the system call number stored at initiation by the dispatcher (block 1216) is indicative that the user program has failed to make a system call during the period of time defined by the timer, and is therefore an uncooperative process.  If, on the other hand, the current system call number is not the same as the stored system call number (again block 1216), the process is cooperative and therefore the illustrative method restarts the uncooperative process timer (block 1237), stores the current system call number (block 1239), enables interrupts (block 1238) and ends (block 1236).
In accordance with embodiments of the invention, a user program becoming uncooperative within at least one processor of a logical processor invokes a rendezvous operation to determine if other processors in the logical processor agree to its uncooperative nature.  Still referring to Figure 12, if the current system call number is the same as the system call number stored by the dispatcher (block 1216), the next step may be a determination of whether there is an unconfirmed rendezvous operation (block 1220).  If not, the next step may be beginning a rendezvous operation by writing an indication of uncooperative nature of the user program, along with the current system call number, to the synchronization registers 54 in the voter logic 56 (block 1224).  Thereafter, the uncooperative process handler routine waits in a software loop for the voter logic to return the synchronization data (block 1228).
Because only one scheduling of a rendezvous point may be in progress at any one time, if there has been a rendezvous started that has yet to complete at the expiration of the uncooperative process timer (again block 1220), the next step may be waiting in a software loop (block 1246) until the voter logic writes the synchronization data.  Keeping in mind that the synchronization data written back is with regard to a previous interrupt (not the uncooperative process timer expiration interrupt that triggered the current execution of the uncooperative process handler routine), either rendezvous information is written to the confirmed list for future execution, or the interrupt is moved back to the pending list (block 1250) (see blocks 552, 554, 560, 562 and 556 of Figure 5).  Thereafter, the process proceeds to writing an indication of the uncooperative nature of the user program, along with the current system call number, to the synchronization registers 54 in the voter logic 56 (block 1224) and waits in a software loop for return of the data (block 1228).
If the processors do not agree that the user program is uncooperative (block 1232), an analysis of the synchronization data is made to determine if the user program is cooperative in other processors (block 1234). For example, while the uncooperative process timer in one processor may expire (or roll over) just prior to a system call by the user program, the user program in a second processor of the logical process may make the system call just before expiration.  Thus, one processor will indicate that the process is uncooperative, and the second processor will attempt to schedule handling of the next interrupt, including the writing of a proposed rendezvous point.  If the analysis reveals the user program will soon make a system call (block 1234), the uncooperative process timer is restarted (block 1237), the current system call number stored (block 1239), interrupts enabled (block 1238) and the process ends (block 1236).
Still referring to Figure 12, if all the processors of the logical processor agree that the user program is uncooperative (block 1232) (all the processors indicate the user program has been on the same system call number for the uncooperative process timer period), then first stage handling of the uncooperative process begins by setting an uncooperative process flag and incrementing a counter (block 1254).  If this is the first time the user program is flagged as uncooperative (block 1258), possibly determined by reading the counter (incremented in block 1254), then the user programs that access the same data values in the same memory locations as the uncooperative process (the uncooperative program’s “process set”) are placed on a list which disallows their continued execution.  Stated otherwise, the dispatcher for the processor will not schedule any member of the process set for execution, also known as a quarantine of the process set (block 1262).  Because the process set shares memory with the uncooperative process, and further because of potential disparities in execution point within the uncooperative process as between processors of a logical processor which may cause differences in the shared memory seen by the process set, a quarantine of the process set ensures that no processes in the process set see different data in memory (as between processors), thus causing computational faults.  In this first stage, the uncooperative process is still allowed to run in the hope that it will become cooperative.  Thus, after a quarantine of the process set, the uncooperative process handler routine restarts the uncooperative process timer (block 1237), stores the current system call number (block 1239), enables interrupts (block 1238) and ends (block 1236).
In accordance with embodiments of the invention, the uncooperative process is allowed to continue execution while its process set remains quarantined.  On the next scheduling of the uncooperative process for execution, the dispatcher again stores the current system call number and starts the uncooperative process timer.  If the uncooperative process executes again for the uncooperative process timer period without making a system call, the uncooperative process handler routine is again invoked.  If all the processors agree again to the uncooperative nature of the user program (block 1232), the routine sets the uncooperative process flag (block 1254) (but this flag was already asserted based on a previous entry), and the counter is incremented (block 1254).  Since in this exemplary situation the user program is not newly uncooperative (block 1258), the next step may be a determination of whether user program has been found to be uncooperative for predetermined number of iterations (block 1266).  In some embodiments, after quarantine of the process set the user program may be declared uncooperative ten times before further corrective action is taken.  If the user program has been confirmed as uncooperative less than the predetermined number of iterations (block 1266), the uncooperative interrupt handler routine restarts the uncooperative process timer (block 1237), stores the current system call number (block 1239), enables interrupts (block 1238) and ends (block 1236), again in the hope that the uncooperative process becomes cooperative before further action is taken.  Phase three of the uncooperative process handling will be discussed after discussing how the uncooperative process is treated if a system call is made before the predetermined number of iterations.
Assume for purposes of further explanation that a user program has been confirmed as uncooperative at least once, has had its process set quarantined, but has yet to be confirmed as uncooperative for the predetermined number of iterations.  Further assume that the user program makes a system call.  Referring again briefly to Figure 7, when the system call program executes, after incrementing the system call number (block 704), a determination is made as to whether the calling program has been previously flagged as uncooperative (block 706).  If not, the system call performs the steps as previously discussed.  If, however, the calling program has been previously flagged as uncooperative, the system call program may unquarantine the process set (block 724) and clear the uncooperative process flag (block 726).
Figure 13 is a timeline illustrating handling of an uncooperative process in relation to event interrupts to further illustrate the methods of Figure 12.  In particular, Figure 13 illustrates a situation where each processor sees system call number 1999.  In the case of processor PA1, interrupt 5 is asserted prior to expiration of the uncooperative process timer, and thus processor PA1 proposes servicing of interrupt 5 at system call number 2000 (line 1300; block 514 of Figure 5).  Soon after proposing service of interrupt 5, the uncooperative process timer for processor PA1 expires, and because of the unconfirmed rendezvous the processor waits in a software loop (block 1246 of Figure 12) for the voter logic to write back synchronization data from the previous proposal.  Processor PB1, by contrast, has its uncooperative process timer expire before the interrupt is asserted, and thus processor PB1 writes uncooperative process information to the synchronization registers 54 (line 1302) and waits in a software loop for confirmation (blocks 1224 and 1228 of Figure 12).  The voter logic then writes the synchronization data back to each processor (line 1304).  Because the processors did not agree to servicing of the interrupt, and because of the immediate action nature of uncooperative process interrupts, processor PA1 writes the interrupt 5 back to the pending list (block 1250), writes the indication of the uncooperative process to the synchronization registers (line 1306; block 1224), and waits in a software loop for confirmation (block 1228).  With regard to processor PB1, the processors do not agree regarding the uncooperative process (block 1232) (processor PA1 proposed servicing an interrupt rather than an indication that the user program is uncooperative).  Moreover, the system call number proposed by processor PA1 (in this exemplary case system call 2000) does not suggest that a system call in processor PB1 is upcoming; rather, the proposed system call number of 2000 implies that processor PA1 is also standing at system call number 1999 (block 1234).  Thus, processor PB1 makes a second write of synchronization data indicating an uncooperative process (line 1308; block 1224), and again waits in a software loop for confirmation (block 1228).  At some time thereafter, the voter logic 56 writes the synchronization data to each processor (lines 1310).  In this exemplary second write, the processors agree to the uncooperative status (block 1232 for each processor), and thus each processor asserts the uncooperative process flag, increments the uncooperative process counter (block 1254), and quarantines the process set for the uncooperative process (block 1262).  Thereafter, the user program continues to operate (regions 1312 in each processor time line), albeit with the process set for the uncooperative process quarantined.
Figure 13 also illustrates a situation where, in spite of a mismatch of synchronization data written to the voter logic, a processor gleans information that the uncooperative nature of the user program may soon end.  In particular, Figure 13 further illustrates processor PA1 making a system call (region 1314), in this exemplary case system call number 3000.  As part of the system call process, processor PA1 proposes or advertises the next rendezvous (line 1316; see also blocks 712 and 740 of Figure 7).  Processor PB1, by contrast, has its uncooperative process timer expire prior to the system call, and therefore writes an indication of the uncooperative process (line 1318; block 1224) and waits in a software loop for confirmation (block 1228).  When the voter logic returns the synchronization data (lines 1320), processor PA1 sees an interrupt type mismatch (block 730 of Figure 7 if analyzed by a system call, and block 552 if analyzed the interrupt handler) and attempts again to write synchronization data (line 1321; block 740 of Figure 7 or block 514 of Figure 5).  Processor PB1, by contrast, receives the synchronization data (line 1320), and while the processors do not agree as the uncooperative nature of the user program (block 1232), the proposed rendezvous information from processor PA1 shows that a system call is upcoming (block 1234).  Thus, processor PB1 continues execution of the user program until the system call is made.  At some later time the processors agree to the interrupt originally proposed by processor PA1.
Returning now to Figure 12, and in particular the step illustrated by block 1266.  If a user program has been flagged as an uncooperative process for a predetermined number of iterations (block 1266), the next steps may be quarantining the uncooperative process (block 1268), and calling a process level reintegration routine (block 1270).
User programs running in each processor of a logical processor and identified as an uncooperative process may diverge significantly in their execution point as between the processors.  In accordance with at least some embodiments of the invention, if the user program will not provide an opportunity to synchronize based on a system call, the synchronization may take place by forcing each user program to resume execution at the same point in the instruction stream.  This may mean that some processors duplicatively execute some instructions, and other processors may skip execution of some instructions.  However, before allowing the user programs to resume execution at the same point in the instruction stream, the working memory of each processor needs to be the same.  Stated otherwise, any memory to which the uncooperative process has write access should be compared as between the processors of the logical processor and made the same.  In this way, when execution resumes the process state for each processor will be the same.  Thus, in accordance with embodiments of the invention, when the uncooperative process handler routine illustrated in Figure 12 determines that a forced synchronization is required (block 1266), process level reintegration of the working memory of the user program may be needed.
Figure 14 illustrates a flow diagram of a process level reintegration routine that may be substantially simultaneously executed in each processor of a logical processor.  In particular, the process starts (block 1400) based on a call by the uncooperative process handler routine illustrated in Figure 12.  The next step in the illustrative process is working with other processors of the logical processor to select a source processor (block 1402).  To select a source processor, messages may be exchanged between the processors using the voter logic.  Any one of the processors of the logical processor may be selected.
The next step of the illustrative process is determining the memory area to which the uncooperative process has write access (block 1404).  This determination may be made, for example, by referring to the memory management and/or page tables of the processor.  Once the extent of the memory area to which the uncooperative process has write access is determined, the next step is a determination of whether a memory page has been unmodified since its creation (otherwise known as clean) (block 1406).  The balance of the description of illustrative Figure 14 assumes that only one memory page at a time is analyzed by the processors; however, alternative embodiments compare a plurality of memory pages at any one time.  If the memory page under consideration is not clean (otherwise known as dirty) (again block 1406), the next step of the illustrative process is computing a checksum for the memory page (block 1408).
The next step of the illustrative process is exchanging data (block 1410) being one of an indication that the memory page under consideration is clean (entry through block 1406), or the checksum calculated if the memory page is dirty (entry through block 1408).  This exchange of data may take place using the voter logic, and is similar to the exchange regarding an immediate action interrupt in the sense that each processors waits in a software loop for the data to be returned from the voter logic (waiting for each processor to write its respective data, and for the voter logic to write the data back).  These steps are not explicitly shown so as not to unduly complicate the figure.  Once the data is received, a determination is made as to whether all processors agree that the memory page is clean (block 1412).  If all the processors agree the memory page is clean, there is no need to copy the memory page from the source processor, thus the next step may be a determination of whether all the memory pages have been analyzed (block 1414).  If not, the process begins anew with the analysis of another memory page.
Still referring to Figure 14, if all the processors do not agree to the clean status of the memory page (again block 1412), the next step is a determination of whether the processor in which the illustrative process is running and the source processor agree that the memory page is dirty (block 1416).  If so, a determination is made as to whether the checksum provided by the source processor and checksum calculated by the processor in which the illustrative process is running are equal (block 1418).  If the checksums are equal, there is no need to copy the memory page from the source processor as the memory pages, though dirty, contain the same data.  If, on the other hand the checksum as between the source processor and the processor in which the illustrative process is running are not equal (again block 1418), the memory pages are not the same and thus the memory page from the source processor is copied to the processor in which the illustrative process is running (block 1420).  Likewise if the source processor and the processor in which the illustrative process is running disagree as the dirty status of the memory page (again block 1416), the memory pages are not the same and thus the memory page from the source processor is copied to the processor in which the illustrative process is running (again block 1420).  In addition to copying the memory page from the source processor, the clean/dirty bits associated with the memory page are copied from the source processor.  These bits may be stored, for example, in the page table or page mapping table of the source of the processor.  It is not necessary to copy the clean/dirty bits in the case where both processors agree as to the dirty state of the memory page; however, it may be convenient, and not too costly from a programming and exchange time standpoint, to copy the bits each time a memory page is copied.  After copying, the illustrative method moves to the determination if there are more memory pages to analyze (block 1414).
Once all the pages have been analyzed, and possibly some memory pages copied from the source processor to one or more of the non-source processors, the next step in the illustrative process is copying of the process control block, possibly including the instruction pointer and other registers, from the source processor to the non-source processors (block 1422).  This copying ensures that each processor resumes execution of the user program at the same execution point as the source processor.  Thereafter, the process level reintegration routines returns (block 1426).  It is noted that the process level reintegration routine runs as a process, interleaved with execution of other processes (except those in the quarantined process set).
Once control has returned to the uncooperative process handler illustrated in Figure 12, the user program, and its process set, are removed from the quarantine list (block 1274), the uncooperative process flag and the counter are cleared (block 1278), the uncooperative process timer is restarted (block 1237), the current system call number stored (block 1239), interrupts enabled (block 1238) and the process ends (block 1236). Thus, the formerly uncooperative process has been synchronized (in this case by a process level reintegration of the writable memory), and may again be executed by the processors.  Because the instruction pointer and other registers from the source processor were copied, all the processors resume execution at the same execution point in the user program.
In accordance with at least some embodiments, process level reintegration alone may be sufficient to ensure proper operation in spite of a user program’s uncooperative nature.  In addition to, or in place of, the process level reintegration, at least some embodiments may take proactive steps to ensure that at least the portion of the user program that caused the uncooperative process designation does not do so again (block 1424).  The proactive steps may take many forms.  In some embodiments, the offending portion of the user program (most likely a software loop) is modified to contain a system call.  This may be accomplished, for example, by replacing no-operation instructions (NOPs) with system calls (e.g., a time of day call).  If the user program instruction stream does not allow for mere replacement, an instruction may be replaced with a branch instruction that points to the replaced instruction, a system call, and a return branch instruction.  These modifications may be made to the user program as it exists in the main memory and/or made to the user program as it exists on a long term storage device, such as a disk drive.  In yet further embodiments, full processor reintegration within a multiprocessor computer system (both processors with cooperative and uncooperative processes) may be used to synchronize the uncooperative processes across multiple processors.  
In yet still further alternative embodiments, processor hardware may support a mechanism for insertion of an interrupt at a particular point in the instruction stream, and the interrupt may trigger the system call for synchronization and interrupt scheduling.  For example, the ItaniumR processor family manufactured by IntelR supports registers within the processor known as “instruction breakpoint registers.”  The breakpoint registers may be loaded with an instruction pointer value, and when the actual instruction pointer matches value in the breakpoint register, an interrupt is triggered.  This exemplary mechanism may thus be used to trigger an interrupt, which in turn triggers a system call for synchronization purposes.  The hardware based mechanism may not be available in all architectures, but the embodiments of modifying the user program may have universal application.
In yet still further embodiments, full processor reintegration (copy of all the memory) within a multiprocessor computer system (both for processors with uncooperative processes, and processors whose processes are cooperative) may be used to synchronize the uncooperative processes across the multiple processors of the logical processor.
The above discussion is meant to be illustrative of the principles and various embodiments of the present invention.  Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated.  It is intended that the following claims be interpreted to embrace all such variations and modifications.
1. A method comprising:
executing fault tolerant copies of a user program, one copy of the user program executed in a first processor (PA, PB, PC) performing non-deterministic execution, and a duplicate copy of the user program executing in a second processor (PA, PB, PC) performing non-deterministic execution;
wherein the executing in the first processor (PA, PB, PC) and second processor (PA, PB, PC) is not in cycle-by-cycle lock-step. 
2. The method as defined in claim 1 further comprising:
executing the user program in the first processor (PA, PB, PC) being part of a first computer system (10);
executing the duplicate copy of the user program in a second processor (PA, PB, PC) being part of a second computer system (10).
3. The method as defined in claim 2 further comprising exchanging information about the state of the respective user programs using a logic system (18, 20, 22, 24) coupling the first and second computer systems (10).
4. The method as defined in claim 1 further comprising executing a duplicate copy of the user program in a third processor (PA, PB, PC) performing non-deterministic execution, and wherein the executing in the first, second and third processors (PA, PB, PC) is not in cycle-by-cycle lock-step.
5. The method as defined in claim 1 wherein the non-determinism comprises at least one selected from the group: timing non-determinism; non-architecturally visible non-determinism; or non-determinism related to error handling in data access. 
6. A system comprising:
a first processor (PA, PB, PC);
a second processor coupled to the first processor (PA, PB, PC);
wherein the processors execute fault tolerant copies of a user program, the first processor executing the user program, and the second processor executing a duplicate copy of the user program;
wherein the execution of the user programs in the first and second processors are not in strict lock-step, and wherein the first and second processors execute their respective user programs non-deterministically. 
7. The system as defined in claim 6 further comprising:
a first computer system (10) comprising the first processor (PA, PB, PC);
a second computer system comprising the second processor; and
a voter logic system (56) coupling the first and second computer systems (10);
wherein the voter logic (56) receives, from the processors, duplicate read requests directed to an input/output (I/O) device (14, 16), consolidates the requests into a single request, and forwards the single request to the I/O device (14, 16).
8. The system as defined in claim 6 further comprising:
a first computer system (10) comprising the first processor (PA, PB, PC);
a second computer system (10) comprising the second processor (PA, PB, PC); and
a voter logic system (56) coupling the first and second computer systems (10);
wherein the voter logic (56) receives, from an external device, requests directed to the software executing on each processor, duplicates the requests, and forwards the requests one each to each processor. 
9. The system as defined in claim 6 further comprising:
a first computer system (10) comprising the first processor (PA, PB, PC);
a second computer system (10) comprising the second processor (PA, PB, PC); and
a voter logic system (56) coupling the first and second computer systems (10);
wherein the voter logic (56) receives duplicate write requests directed to an input/output (I/O) device (14, 16), consolidates the requests into a single request, and forwards the single request to the I/O device (14, 16).
10. The system as defined in claim 6 wherein the non-deterministic execution of the user program comprises at least one selected from the group: timing non-determinism; non-architecturally visible non-determinism; or non-determinism related to error handling in data access.
A method and system of loosely lock-stepped non deterministic processors (PA, PB, PC).  Some exemplary embodiments may be a processor based method comprising executing fault tolerant copies of a user program, one copy of the user program executed in a first processor (PA, PB, PC) performing non-deterministic execution, and a duplicate copy of the user program executing in a second processor (PA, PB, PC) performing non-deterministic execution, with the executing in the first processor and second processor (PA, PB, PC) not in cycle-by-cycle lock-stepped.
2005285119.tif 000019
2005285119.tif 000020
2005285119.tif 000021
2005285119.tif 000022
2005285119.tif 000023
2005285119.tif 000024
2005285119.tif 000025
2005285119.tif 000026
2005285119.tif 000027
2005285119.tif 000028
2005285119.tif 000029
2005285119.tif 000030
2005285119.tif 000031
2005285119.tif 000032
2005285119.tif 000033
2005285119.tif 000034