情報処理装置およびそのエラー処理方法ならびに制御プログラム
【課題】 トランザクション管理で障害が発生した場合に、コヒーレンシ保障を保持した状態で、トランザクションの受け付けからリプライ返却までの処理を継続動作させることができる情報処理装置の提供。
【解決手段】 アウト・オブ・オーダー・トランザクション制御部１１は、障害検出部２２のリトライ可能障害部３１にてバッファ２１の障害を検出し、その障害に係るトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライする。
【解決手段】 アウト・オブ・オーダー・トランザクション制御部１１は、障害検出部２２のリトライ可能障害部３１にてバッファ２１の障害を検出し、その障害に係るトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置およびそのエラー処理方法ならびに制御プログラムに関し、特にプロセッサ等から発行されたトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置およびそのエラー処理方法ならびに制御プログラムに関する。
【背景技術】
【０００２】
プロセッサ等から発行されたトランザクションを受け付けてからリプライを返却するまでの間トランザクションを管理する情報処理装置は知られている。
【０００３】
このトランザクションの管理には２通りの方法が存在する。その一つはトランザクションの発行順序に従ってリプライを返却する方法であり、ＦＩＦＯ（ｆｉｒｓｔ−ｉｎ，ｆｉｒｓｔ−ｏｕｔ）を前提としており、トランザクションの発行順序とリプライ応答順序は一致する（例えば、特許文献１および２参照）。
【０００４】
他方はトランザクションの発行順序とリプライ応答順序が一致しない方法であり、これが上述のアウト・オブ・オーダー処理である。
【０００５】
従来のトランザクションの管理において、データに障害が発生した場合は、ＥＣＣ（ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｎｇ ｃｏｄｅ）等の誤り訂正機能を用いてその障害を復旧させている。
【０００６】
しかし、アドレス制御系で障害が発生した場合は、コヒーレンシ（ｃｏｈｅｒｅｎｃｙ：依存性）の保障やデータ化けを防止する必要があるため、動作を継続させることができず、システムダウンとしている。
【０００７】
一方、リトライの実施によって動作継続を図ることが可能な場合でも、バッファの特定部分に障害がある場合（以下、このような障害を「固定障害」と記す）は、リトライの失敗でシステムダウンを招く場合がある。
【０００８】
また、アウト・オブ・オーダーのトランザクションを処理する場合は、一般的に高性能化を図るために複数のトランザクションをオーバーラップして処理する。このため、アウト・オブ・オーダー処理を行う部位内にはハードマクロ（ｈａｒｄ ｍａｃｒｏ）やレジスタで構成される多数のバッファが使用されている。
【０００９】
したがって、これらのバッファの一箇所でも故障が発生するとシステムダウンにつながるので、信頼性がより高く求められる場合には、動作を継続させるための対策が必要である。
【００１０】
ところで、上述の特許文献１および２記載の発明は、高速化のため、先行ライトトランザクションの完了を待たずに後続ライトトランザクションを発行する装置に関するもので、先行ライトトランザクションがリトライになった場合に、同一ソースから発行された後続ライトトランザクションの順序保障を守るために、後続ライトトランザクションの全てをリトライさせるものである。
【００１１】
また、他の発明として、受け付けたトランザクション情報の全てをその処理が終了するまでシステム制御機能内のバッファに保持しておき、障害時には保持しておいたトランザクションをシステム制御内で再発行することによりシステムダウンを防止するメモリアクセス制御装置が開示されている（例えば、特許文献３参照）。
【００１２】
また、他の発明として、割り込みを受けたとき、処理を行っていたトランザクションがリトライ可能であれば、先に割り込みを処理し、その後にそのトランザクションをリトライする装置が開示されている（例えば、特許文献４参照）。
【００１３】
【特許文献１】特開２００１−２１６２５９号公報（段落０００８、図１）
【特許文献２】特開２００２−１０８８３６号公報（段落０００８、図１）
【特許文献３】特開平０１−１４０３５７号公報（第３頁左上欄、第８行〜第１４行、第１図）
【特許文献４】特開２００２−０９１９３９号公報（段落００１４、図１）
【発明の開示】
【発明が解決しようとする課題】
【００１４】
上述の特許文献１および２記載の発明はトランザクションの発行順序とリプライ応答順序が一致するトランザクションの管理に関するものであり、ＦＩＦＯを前提としている。このため同一ソースから発行された後続ライトトランザクションの順序保障を守るために、後続ライトトランザクションの全てをリトライさせている。
【００１５】
これに対し、本発明はアウト・オブ・オーダーのトランザクション管理に関し、アウト・オブ・オーダーのトランザクション管理では、ＦＩＦＯとは異なり、必ずしも同一ソースから発行された全ての後続トランザクションを順序保障のために全てリトライさせる必要はない。本発明は、障害が発生した箇所で処理されていたトランザクションをリトライすることで、システムダウンを減少させることを目的としている。
【００１６】
したがって、特許文献１および２記載の発明は、本発明とその目的、構成、効果のいずれもが全く相違する。
【００１７】
また、上述の特許文献３記載の発明はコヒーレンシ保障やバッファの固定故障の対策については触れておらず、コヒーレンシを保障しながらシステムダウンを回避することや、バッファの固定故障によるリトライの多発を回避することは困難である。
【００１８】
また、上述の特許文献４記載の発明は割り込み処理の高速化を目的とするものであり、その目的が本発明と全く相違する。
【００１９】
そこで本発明の目的は、トランザクション管理で障害が発生した場合に、コヒーレンシ保障を保持した状態で、トランザクションの受け付けからリプライ返却までの処理を継続動作させることができ、かつバッファの固定障害に起因するシステムダウンを低減させることが可能な情報処理装置およびそのエラー処理方法ならびに制御プログラムを提供することにある。
【課題を解決するための手段】
【００２０】
前記課題を解決するために、本発明による情報処理装置は、発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置であって、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御手段を含むことを特徴とする。
【００２１】
また、本発明によるエラー処理方法は、発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法であって、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御ステップを含むことを特徴とする。
【００２２】
また、本発明による制御プログラムは、発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法の制御プログラムであって、コンピュータに、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御処理を実行させるための制御プログラムであることを特徴とする。
【００２３】
本発明によれば、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライする。
【発明の効果】
【００２４】
本発明によれば、上記構成を含むため、トランザクション管理で障害が発生した場合に、コヒーレンシ保障を保持した状態で、トランザクションの受け付けからリプライ返却までの処理を継続動作させることができ、かつバッファの固定障害に起因するシステムダウンを低減させることが可能となる。
【００２５】
具体的には、情報処理装置でプロセッサ等が発行するトランザクションを受け付けてからアウト・オブ・オーダー処理でリプライを返却するまでの間トランザクションを管理するシステム制御部内において、ハードマクロやレジスタから構成されるバッファの特定部分に障害が発生した場合にも、コヒーレンシを保ちながら継続動作が出来、縮退動作も行うため、即システムダウンにつながる障害を減らすことが出来る。このためハードウェアの間欠障害やバッファの特定エントリの固定障害対策として有用である。また、プロセッサ等へのリトライ時に使用するトランザクション識別子等の情報以外のところで発生した障害であれば継続動作ができる可能性が高いためハードウェア故障の救済範囲を広げることが可能となる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施の形態について添付図面を参照しながら説明する。図１は本発明に係る情報処理装置の一例の構成図である。同図を参照すると、本発明に係る情報処理装置の一例は、システム制御部１と、複数のプロセッサ２（２−１〜２−ｎ（ｎは正の整数））と、複数のデバイス３（３−１〜３−ｍ（ｍは正の整数））と、第１メモリ４と、第２メモリ５とを含んで構成される。
【００２７】
複数のプロセッサ２、複数のデバイス３、第１メモリ４および第２メモリ５はシステム制御部１と接続されている。
【００２８】
システム制御部１はプロセッサ２、第１メモリ４あるいはデバイス３からトランザクションを受け付けて制御を行う。
【００２９】
なお、本実施例ではプロセッサ２が発行するトランザクションを受け付けてからアウト・オブ・オーダー処理でリプライを返却するまでの処理の一例について説明するが、プロセッサ２が発行するトランザクションに限定されるものではなく、第１メモリ４やデバイス３等の他のデバイスが発行するトランザクションに本発明を適用することが可能である。
【００３０】
一方、システム制御部１はアウト・オブ・オーダー・トランザクション制御部１１（以下、トランザクション制御部１１と記す）と、後続リトライ部１２とを含んで構成され、トランザクション制御部１１はバッファ２１と、障害検出部２２と、リプライ制御部２３と、障害カウンタ監視部２４とを含んで構成される。
【００３１】
また、障害検出部２２はリトライ可能障害部３１と、リトライ不可能障害部３２とを含んでおり、リプライ制御部２３はリトライ部４１を含んでいる。
【００３２】
障害検出部２２のリトライ可能障害部３１はバッファ２２と相互に信号の送受信を行い、受信した信号に基づく信号を後続リトライ部１２と、リプライ制御部２３内のリトライ部４１とに送信する。リトライ不可能障害部３２はバッファ２２からの信号の受信のみを行う。
【００３３】
また、バッファ２１からの信号はリプライ制御部２３のリトライ部４１に送信され、リプライ制御部２３からの信号は後続リトライ部１２へ送信される。
【００３４】
また、バッファ２１と障害カウンタ監視部２４は相互に信号の送受信を行う。
【００３５】
障害検出部２２は、リトライ可能障害部３１とリトライ不可能障害部３２に区別してシステム制御部１内の障害検出を行う。リプライ制御部２３のリトライ部４１は、障害が発生したときに、プロセッサ２−１〜２−n へ障害が発生したトランザクションや他の処理中のトランザクションのリトライを発行する。
【００３６】
後続リトライ部１２は、障害が検出されたトランザクションのリトライ処理が完了するまでの間、後続のプロセッサが発行するトランザクションのリトライを行う。障害カウンタ監視部２４はバッファ２１に設けられた後述する障害カウンタ５２を監視する。
【００３７】
次に、バッファ２１の構成の一例について説明する。図２はバッファ２１の構成の一例を示す図である。同図を参照すると、バッファ２１は複数のエントリ（エントリ０〜ｐ（ｐは正の整数））を含み、各エントリは使用中フラグ５０と、情報５１と、障害カウンタ５２とを含んでいる。一つのエントリが一つのトランザクションに対応している。
【００３８】
障害カウンタ５２は障害発生回数を格納する。障害カウンタ監視部２４は、固定障害時のリトライ多発によるシステムダウンを防ぐために、障害カウンタ５２に示される障害発生回数を監視して、一定期間に発生した障害が許容範囲回数以内の場合は障害カウンタ５２のリセットを実施し、障害が許容範囲を超えた場合は固定障害と認識してバッファ２１を縮退させる。
【００３９】
トランザクション制御部１１は、プロセッサ２が発行するトランザクションを受け付けてからアウト・オブ・オーダー処理でリプライを返却するまでの間、それぞれのトランザクションを唯一の識別子を使って管理する。
【００４０】
トランザクション制御部１１内にある複数エントリから成るバッファ２１で障害が発生したときに、プロセッサ２にリトライを発行してコヒーレンシを保ちながら障害を救済するための機能は次のもので構成する。
【００４１】
障害発生時にプロセッサにリトライを発行するための機能は、障害検出部２２のリトライ可能障害部３１とリトライ不可能障害部３２、リトライ部４１、後続リトライ部１２で構成され、障害による縮退機能は、バッファ２１中の障害カウンタ５２、障害カウンタ監視部２４から構成される。
【００４２】
バッファ２１の障害検出部２２は、プロセッサ２にリトライを返却して動作を継続できるような障害をリトライ可能障害部３１として、継続動作が不可能な場合はリトライ不可能障害部３２として分けて構成する。
【００４３】
リトライ不可能障害部３２で検出する障害としては、例えばプロセッサ２が発行したトランザクション識別子があげられる。これはアウト・オブ・オーダー処理ではプロセッサ２がトランザクションを発行したときに付与されている識別子を用いてプロセッサ２にリプライを返却するが、この識別子に障害が発生している場合は正しくリトライが出来ないためである。
【００４４】
リトライ部４１は、プロセッサ２から受け付けたトランザクションの応答を行うリプライ制御部２３内に持ち、障害検出部２２のリトライ可能障害部３１でバッファ２１障害が検出された場合に、リトライ可能障害部３１から通知を受け、障害が検出されたバッファ２１のエントリのトランザクションをプロセッサ２にリプライの一種としてリトライを発行する機能である。
【００４５】
また、障害が検出されたトランザクションがコヒーレンシ保障の必要があるトランザクションだった場合には、バッファ２１に格納されている他のトランザクションについてもプロセッサ２にリトライを発行してコヒーレンシを保つ機能も持つ。
【００４６】
後続リトライ部１２は、障害発生後から障害が検出されたトランザクションのリトライ処理が終了するまでの間に、新たにプロセッサ２から発行されたトランザクションをリトライするための機能であり、障害が発生したトランザクションがコヒーレンシ保障を必要とする場合に有効になり、障害トランザクションのリトライ処理が終了すると解除される。
【００４７】
後続リトライ部１２は、後続リトライ部１２が有効である間、プロセッサ２が発行した新規トランザクションがコヒーレンシ保障対象ではない場合は受け付けて通常の処理を行い、コヒーレンシ保障対象である場合はリトライにすることでコヒーレンシを保障している。
【００４８】
バッファ２１中の障害カウンタ５２はエントリ毎に設け、障害が発生するたびに１カウントアップする。障害カウンタ監視部２４は、バッファ２１中の障害カウンタ５２を監視する機能で、あらかじめ縮退させる障害発生回数を設定しておいて、障害カウンタ５２の値が設定回数を越えるとそのエントリを縮退する。
【００４９】
また、一定期間内で許容できる障害回数も定めておき、障害カウンタ５２の値が設定した回数以下の場合は障害カウンタ５２をリセットする。縮退方法についてはバッファの使用中フラグ５０を“使用中”にして、情報５１には例えばオール“０”のような他の制御に影響を及ぼさない無効データを格納して無効化する。使用中フラグ５０を“使用中”にしておくことで新たにそのエントリが選択されることはないため特別な回路を設けなくても縮退と同等の機能が得られる。
【００５０】
次に、システム制御部１のエラー処理方法について詳細に説明する。図３は障害が検出されたトランザクションについての処理の一例を示すフローチャートである。
【００５１】
図３を参照すると、障害検出部２２でバッファ２１の障害を検出する（Ｓ１０１）。リトライ可能障害部３１で障害を検出した場合（Ｓ１０２にて“ＹＥＳ”の場合）はシステムダウンさせずに障害が発生したバッファ２１のエントリの障害カウンタ５２のカウントアップを行い（Ｓ１０３）、リトライ部４１ではプロセッサ２等にリトライを発行するために必要な情報を読み出してリトライ処理を行う（Ｓ１０４）。
【００５２】
プロセッサ２へのリトライ発行が終了したところで、後続リトライ部１２が有効である場合（Ｓ１０５で“ＹＥＳ”の場合）は後続リトライ部１２を解除して（Ｓ１０６）、処理を終了する。
【００５３】
リトライ処理が終了したトランザクションのエントリの再使用については、直ぐに使用出来る場合や、一定期間おいた後でリセットして利用する場合、また、他のバッファのリセットも行って利用する場合等、バッファの用途や障害箇所によって異なる。
【００５４】
障害検出がリトライ可能障害部３１ではない場合（Ｓ１０２にて“ＮＯ”の場合）、すなわちリトライ不可能障害部３２で検出された場合はシステムダウンさせる（Ｓ１０９）。
【００５５】
リトライ可能障害部３１で障害を検出した場合には（Ｓ１０２にて“ＹＥＳ”の場合）、障害検出したバッファ２１のエントリのトランザクションがコヒーレンシ保障対象トランザクションかどうかについても調べる（Ｓ１０７）。
【００５６】
明らかにコヒーレンシ保障対象トランザクションではないと判断できる場合を除き（Ｓ１０７にて“ＹＥＳ”の場合）、コヒーレンシ保障対象トランザクションとみなして後続リトライ部１２を有効にする（Ｓ１０８）。
【００５７】
明らかにコヒーレンシ保障対象トランザクションではないとは判断できない例として、コヒーレンシ保障対象か否かを判断するための情報に障害が発生した場合があげられる。
【００５８】
後続リトライ部１２が有効でない場合（Ｓ１０５で“ＮＯ”の場合、および明らかにコヒーレンシ保障対象トランザクションではないと判断できる場合（Ｓ１０７にて“ＮＯ”の場合）は処理を終了する。
【００５９】
図４はバッファ２１のリトライ可能障害部３１で障害が検出された際に障害が検出されたトランザクション以外のアウト・オブ・オーダー処理中のトランザクションに対する処理の一例を示すフローチャートである。
【００６０】
図４を参照すると、リトライ可能障害部３１で障害が検出されると（Ｓ２０１）、リトライ部４１では障害が検出されたトランザクションがコヒーレンシ保障対象であるかどうかを調べる（Ｓ２０２）。
【００６１】
障害が検出されたトランザクションがコヒーレンシ保障対象でない場合は（Ｓ２０２にて“ＮＯ”の場合）、処理中のアウト・オブ・オーダー・トランザクションは通常処理を継続する（Ｓ２０５）。
【００６２】
障害が検出されたトランザクションがコヒーレンシ保障対象であった場合は（Ｓ２０２にて“ＹＥＳ”の場合）、処理中のアウト・オブ・オーダー・トランザクション全てについてそのトランザクションがコヒーレンシ保障対象であるかを調べ（Ｓ２０３）、コヒーレンシ保障対象でない場合は（Ｓ２０３にて“ＮＯ”の場合）、通常処理を継続し（Ｓ２０５）、コヒーレンシ保障対象であれば（Ｓ２０３にて“ＹＥＳ”の場合）、リトライ処理を行う（Ｓ２０４）。
【００６３】
リトライ処理（Ｓ２０４）は、バッファ２１のそれぞれのエントリの情報５１内に図示しないリトライフラグを設けておいて、障害発生時にリトライ処理が必要なトランザクションであると判定された場合はそのトランザクションのエントリのリトライフラグを有効にしておき、通常動作時のリプライを行うために必要な条件が揃った後でリトライに差し替えて、プロセッサへリトライを発行して処理を終了する。データが付随する場合はデータを廃棄して処理を終了する。
【００６４】
図５はリトライ可能障害部３１で検出された障害の処理中に、プロセッサ２から新規トランザクションが発行されたときの処理の一例を示すフローチャートである。プロセッサ２からトランザクションを受け付けると（Ｓ３０１）、後続リトライ部１２が有効かどうかを調べる（Ｓ３０２）。
【００６５】
後続リトライ部１２が無効な場合は（Ｓ３０２にて“ＮＯ”の場合）、トランザクションを受け付けてアウト・オブ・オーダー処理等の通常処理を実施する（Ｓ３０５）。
【００６６】
後続リトライ部１２が有効な場合は（Ｓ３０２にて“ＹＥＳ”の場合）、プロセッサ２から受け取ったトランザクションがコヒーレンシ保障対象か否かを調べ（Ｓ３０３）、コヒーレンシ保障対象の場合は（Ｓ３０３にて“ＹＥＳ”の場合）、リトライ処理を行い（Ｓ３０４）、コヒーレンシ保障対象でない場合は（Ｓ３０３にて“ＮＯ”の場合）、トランザクションを受け付けてアウト・オブ・オーダー処理等の通常処理を継続する（Ｓ３０５）。
【００６７】
図６はバッファ２１の障害カウンタ５２の監視動作の一例を示すフローチャートである。障害カウンタ監視部２４では、バッファ２１のそれぞれのエントリにある障害カウンタ５２を一定期間毎に監視し（Ｓ４０１）、障害カウンタ５２の値が縮退閾値回数を超えた場合は（Ｓ４０２にて“ＹＥＳ”の場合）、バッファ２１の該当エントリの縮退を行う（Ｓ４０５）。
【００６８】
これは固定故障によるリトライ多発を防ぐためである。ここで、縮退閾値回数とは縮退を開始する障害発生回数のことであり、使用する要件に応じて任意の値に設定可能である。
【００６９】
縮退縮退方法としてはバッファ２１のエントリの使用中フラグ５０を有効にすることによって、新たにそのエントリが使用されないようして、同時に、他の制御に影響を及ぼさないようにそのエントリの情報５１にはオール“０”等の無効なデータを書き込むことで縮退とする。
【００７０】
障害カウンタ５２が縮退閾値回数以下の場合は（Ｓ４０２にて“ＮＯ”の場合）、一定期間内で許容される障害回数として設定したリセット可能回数の値と障害カウンタ５２値とを比較し（Ｓ４０３）、リセット可能回数以下の場合は（Ｓ４０３にて“ＮＯ”の場合）、障害カウンタ５２をリセットする（Ｓ４０４）。これは間欠障害に起因したバッファの縮退によってバッファ容量の減少を防ぐためである。
【００７１】
一方、リセット可能回数を超えた場合は（Ｓ４０３にて“ＹＥＳ”の場合）、障害カウンタ５２をリセットしない。
【００７２】
次に、エラー処理方法の制御プログラムについて詳細に説明する。図１を参照すると、第１メモリ４と第２メモリ５とが表示されている。第１メモリには本発明に係るエラー処理以外の処理を行うための制御プログラムあるいはデータが格納されている。一方、第２メモリ５には本発明に係るエラー処理を行うための制御プログラムが格納されている。
本発明に係るエラー処理を行うための制御プログラムとは、図３〜図６にフローチャートで示す処理をコンピュータ（本実施例では図１のシステム制御部１）に実行させるためのプログラムである。
【００７３】
システム制御部１は第２メモリ５からエラー処理を行うための制御プログラムを読み出し、そのプログラムに従ってトランザクション制御部１１および後続リトライ部１２を制御する。その制御内容については既に述べたのでその説明は省略する。
【００７４】
なお、本実施例では、エラ−処理方法について、制御プログラムで実現する方法を示したが、これをハ−ドウエア・シ−ケンスで実現することも可能である。
【産業上の利用可能性】
【００７５】
プロセッサがリトライ機能を有し、アウト・オブ・オーダー・トランザクションを処理するシステムにおいて、多量なバッファを用いるような場合に有効であり、高信頼性が求められる情報処理装置での利用が考えられる。また、プロセッサに限らずＩ／Ｏカードやメモリからでも、リトライ機能を有しアウト・オブ・オーダー処理を実施している場合には適用可能である。
【図面の簡単な説明】
【００７６】
【図１】本発明に係る情報処理装置の一例の構成図である。
【図２】バッファ２１の構成の一例を示す図である。
【図３】障害が検出されたトランザクションについての処理の一例を示すフローチャートである。
【図４】バッファ２１のリトライ可能障害部３１で障害が検出された際に障害が検出されたトランザクション以外のアウト・オブ・オーダー処理中のトランザクションに対する処理の一例を示すフローチャートである。
【図５】リトライ可能障害部３１で検出された障害の処理中に、プロセッサ２から新規トランザクションが発行されたときの処理の一例を示すフローチャートである。
【図６】バッファ２１の障害カウンタ５２の監視動作の一例を示すフローチャートである。
【符号の説明】
【００７７】
１ システム制御部
２ プロセッサ
３ デバイス
４ 第１メモリ
５ 第２メモリ
１１ アウト・オブ・オーダー・トランザクション制御部
１２ 後続リトライ部
２３ リプライ制御部
２４ 障害カウンタ監視部
３１ リトライ可能障害部
３２ リトライ不可能障害部
４１ リトライ部
５０ 使用中フラグ
５１ 情報
５２ 障害カウンタ
【技術分野】
【０００１】
本発明は、情報処理装置およびそのエラー処理方法ならびに制御プログラムに関し、特にプロセッサ等から発行されたトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置およびそのエラー処理方法ならびに制御プログラムに関する。
【背景技術】
【０００２】
プロセッサ等から発行されたトランザクションを受け付けてからリプライを返却するまでの間トランザクションを管理する情報処理装置は知られている。
【０００３】
このトランザクションの管理には２通りの方法が存在する。その一つはトランザクションの発行順序に従ってリプライを返却する方法であり、ＦＩＦＯ（ｆｉｒｓｔ−ｉｎ，ｆｉｒｓｔ−ｏｕｔ）を前提としており、トランザクションの発行順序とリプライ応答順序は一致する（例えば、特許文献１および２参照）。
【０００４】
他方はトランザクションの発行順序とリプライ応答順序が一致しない方法であり、これが上述のアウト・オブ・オーダー処理である。
【０００５】
従来のトランザクションの管理において、データに障害が発生した場合は、ＥＣＣ（ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｎｇ ｃｏｄｅ）等の誤り訂正機能を用いてその障害を復旧させている。
【０００６】
しかし、アドレス制御系で障害が発生した場合は、コヒーレンシ（ｃｏｈｅｒｅｎｃｙ：依存性）の保障やデータ化けを防止する必要があるため、動作を継続させることができず、システムダウンとしている。
【０００７】
一方、リトライの実施によって動作継続を図ることが可能な場合でも、バッファの特定部分に障害がある場合（以下、このような障害を「固定障害」と記す）は、リトライの失敗でシステムダウンを招く場合がある。
【０００８】
また、アウト・オブ・オーダーのトランザクションを処理する場合は、一般的に高性能化を図るために複数のトランザクションをオーバーラップして処理する。このため、アウト・オブ・オーダー処理を行う部位内にはハードマクロ（ｈａｒｄ ｍａｃｒｏ）やレジスタで構成される多数のバッファが使用されている。
【０００９】
したがって、これらのバッファの一箇所でも故障が発生するとシステムダウンにつながるので、信頼性がより高く求められる場合には、動作を継続させるための対策が必要である。
【００１０】
ところで、上述の特許文献１および２記載の発明は、高速化のため、先行ライトトランザクションの完了を待たずに後続ライトトランザクションを発行する装置に関するもので、先行ライトトランザクションがリトライになった場合に、同一ソースから発行された後続ライトトランザクションの順序保障を守るために、後続ライトトランザクションの全てをリトライさせるものである。
【００１１】
また、他の発明として、受け付けたトランザクション情報の全てをその処理が終了するまでシステム制御機能内のバッファに保持しておき、障害時には保持しておいたトランザクションをシステム制御内で再発行することによりシステムダウンを防止するメモリアクセス制御装置が開示されている（例えば、特許文献３参照）。
【００１２】
また、他の発明として、割り込みを受けたとき、処理を行っていたトランザクションがリトライ可能であれば、先に割り込みを処理し、その後にそのトランザクションをリトライする装置が開示されている（例えば、特許文献４参照）。
【００１３】
【特許文献１】特開２００１−２１６２５９号公報（段落０００８、図１）
【特許文献２】特開２００２−１０８８３６号公報（段落０００８、図１）
【特許文献３】特開平０１−１４０３５７号公報（第３頁左上欄、第８行〜第１４行、第１図）
【特許文献４】特開２００２−０９１９３９号公報（段落００１４、図１）
【発明の開示】
【発明が解決しようとする課題】
【００１４】
上述の特許文献１および２記載の発明はトランザクションの発行順序とリプライ応答順序が一致するトランザクションの管理に関するものであり、ＦＩＦＯを前提としている。このため同一ソースから発行された後続ライトトランザクションの順序保障を守るために、後続ライトトランザクションの全てをリトライさせている。
【００１５】
これに対し、本発明はアウト・オブ・オーダーのトランザクション管理に関し、アウト・オブ・オーダーのトランザクション管理では、ＦＩＦＯとは異なり、必ずしも同一ソースから発行された全ての後続トランザクションを順序保障のために全てリトライさせる必要はない。本発明は、障害が発生した箇所で処理されていたトランザクションをリトライすることで、システムダウンを減少させることを目的としている。
【００１６】
したがって、特許文献１および２記載の発明は、本発明とその目的、構成、効果のいずれもが全く相違する。
【００１７】
また、上述の特許文献３記載の発明はコヒーレンシ保障やバッファの固定故障の対策については触れておらず、コヒーレンシを保障しながらシステムダウンを回避することや、バッファの固定故障によるリトライの多発を回避することは困難である。
【００１８】
また、上述の特許文献４記載の発明は割り込み処理の高速化を目的とするものであり、その目的が本発明と全く相違する。
【００１９】
そこで本発明の目的は、トランザクション管理で障害が発生した場合に、コヒーレンシ保障を保持した状態で、トランザクションの受け付けからリプライ返却までの処理を継続動作させることができ、かつバッファの固定障害に起因するシステムダウンを低減させることが可能な情報処理装置およびそのエラー処理方法ならびに制御プログラムを提供することにある。
【課題を解決するための手段】
【００２０】
前記課題を解決するために、本発明による情報処理装置は、発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置であって、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御手段を含むことを特徴とする。
【００２１】
また、本発明によるエラー処理方法は、発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法であって、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御ステップを含むことを特徴とする。
【００２２】
また、本発明による制御プログラムは、発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法の制御プログラムであって、コンピュータに、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御処理を実行させるための制御プログラムであることを特徴とする。
【００２３】
本発明によれば、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライする。
【発明の効果】
【００２４】
本発明によれば、上記構成を含むため、トランザクション管理で障害が発生した場合に、コヒーレンシ保障を保持した状態で、トランザクションの受け付けからリプライ返却までの処理を継続動作させることができ、かつバッファの固定障害に起因するシステムダウンを低減させることが可能となる。
【００２５】
具体的には、情報処理装置でプロセッサ等が発行するトランザクションを受け付けてからアウト・オブ・オーダー処理でリプライを返却するまでの間トランザクションを管理するシステム制御部内において、ハードマクロやレジスタから構成されるバッファの特定部分に障害が発生した場合にも、コヒーレンシを保ちながら継続動作が出来、縮退動作も行うため、即システムダウンにつながる障害を減らすことが出来る。このためハードウェアの間欠障害やバッファの特定エントリの固定障害対策として有用である。また、プロセッサ等へのリトライ時に使用するトランザクション識別子等の情報以外のところで発生した障害であれば継続動作ができる可能性が高いためハードウェア故障の救済範囲を広げることが可能となる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施の形態について添付図面を参照しながら説明する。図１は本発明に係る情報処理装置の一例の構成図である。同図を参照すると、本発明に係る情報処理装置の一例は、システム制御部１と、複数のプロセッサ２（２−１〜２−ｎ（ｎは正の整数））と、複数のデバイス３（３−１〜３−ｍ（ｍは正の整数））と、第１メモリ４と、第２メモリ５とを含んで構成される。
【００２７】
複数のプロセッサ２、複数のデバイス３、第１メモリ４および第２メモリ５はシステム制御部１と接続されている。
【００２８】
システム制御部１はプロセッサ２、第１メモリ４あるいはデバイス３からトランザクションを受け付けて制御を行う。
【００２９】
なお、本実施例ではプロセッサ２が発行するトランザクションを受け付けてからアウト・オブ・オーダー処理でリプライを返却するまでの処理の一例について説明するが、プロセッサ２が発行するトランザクションに限定されるものではなく、第１メモリ４やデバイス３等の他のデバイスが発行するトランザクションに本発明を適用することが可能である。
【００３０】
一方、システム制御部１はアウト・オブ・オーダー・トランザクション制御部１１（以下、トランザクション制御部１１と記す）と、後続リトライ部１２とを含んで構成され、トランザクション制御部１１はバッファ２１と、障害検出部２２と、リプライ制御部２３と、障害カウンタ監視部２４とを含んで構成される。
【００３１】
また、障害検出部２２はリトライ可能障害部３１と、リトライ不可能障害部３２とを含んでおり、リプライ制御部２３はリトライ部４１を含んでいる。
【００３２】
障害検出部２２のリトライ可能障害部３１はバッファ２２と相互に信号の送受信を行い、受信した信号に基づく信号を後続リトライ部１２と、リプライ制御部２３内のリトライ部４１とに送信する。リトライ不可能障害部３２はバッファ２２からの信号の受信のみを行う。
【００３３】
また、バッファ２１からの信号はリプライ制御部２３のリトライ部４１に送信され、リプライ制御部２３からの信号は後続リトライ部１２へ送信される。
【００３４】
また、バッファ２１と障害カウンタ監視部２４は相互に信号の送受信を行う。
【００３５】
障害検出部２２は、リトライ可能障害部３１とリトライ不可能障害部３２に区別してシステム制御部１内の障害検出を行う。リプライ制御部２３のリトライ部４１は、障害が発生したときに、プロセッサ２−１〜２−n へ障害が発生したトランザクションや他の処理中のトランザクションのリトライを発行する。
【００３６】
後続リトライ部１２は、障害が検出されたトランザクションのリトライ処理が完了するまでの間、後続のプロセッサが発行するトランザクションのリトライを行う。障害カウンタ監視部２４はバッファ２１に設けられた後述する障害カウンタ５２を監視する。
【００３７】
次に、バッファ２１の構成の一例について説明する。図２はバッファ２１の構成の一例を示す図である。同図を参照すると、バッファ２１は複数のエントリ（エントリ０〜ｐ（ｐは正の整数））を含み、各エントリは使用中フラグ５０と、情報５１と、障害カウンタ５２とを含んでいる。一つのエントリが一つのトランザクションに対応している。
【００３８】
障害カウンタ５２は障害発生回数を格納する。障害カウンタ監視部２４は、固定障害時のリトライ多発によるシステムダウンを防ぐために、障害カウンタ５２に示される障害発生回数を監視して、一定期間に発生した障害が許容範囲回数以内の場合は障害カウンタ５２のリセットを実施し、障害が許容範囲を超えた場合は固定障害と認識してバッファ２１を縮退させる。
【００３９】
トランザクション制御部１１は、プロセッサ２が発行するトランザクションを受け付けてからアウト・オブ・オーダー処理でリプライを返却するまでの間、それぞれのトランザクションを唯一の識別子を使って管理する。
【００４０】
トランザクション制御部１１内にある複数エントリから成るバッファ２１で障害が発生したときに、プロセッサ２にリトライを発行してコヒーレンシを保ちながら障害を救済するための機能は次のもので構成する。
【００４１】
障害発生時にプロセッサにリトライを発行するための機能は、障害検出部２２のリトライ可能障害部３１とリトライ不可能障害部３２、リトライ部４１、後続リトライ部１２で構成され、障害による縮退機能は、バッファ２１中の障害カウンタ５２、障害カウンタ監視部２４から構成される。
【００４２】
バッファ２１の障害検出部２２は、プロセッサ２にリトライを返却して動作を継続できるような障害をリトライ可能障害部３１として、継続動作が不可能な場合はリトライ不可能障害部３２として分けて構成する。
【００４３】
リトライ不可能障害部３２で検出する障害としては、例えばプロセッサ２が発行したトランザクション識別子があげられる。これはアウト・オブ・オーダー処理ではプロセッサ２がトランザクションを発行したときに付与されている識別子を用いてプロセッサ２にリプライを返却するが、この識別子に障害が発生している場合は正しくリトライが出来ないためである。
【００４４】
リトライ部４１は、プロセッサ２から受け付けたトランザクションの応答を行うリプライ制御部２３内に持ち、障害検出部２２のリトライ可能障害部３１でバッファ２１障害が検出された場合に、リトライ可能障害部３１から通知を受け、障害が検出されたバッファ２１のエントリのトランザクションをプロセッサ２にリプライの一種としてリトライを発行する機能である。
【００４５】
また、障害が検出されたトランザクションがコヒーレンシ保障の必要があるトランザクションだった場合には、バッファ２１に格納されている他のトランザクションについてもプロセッサ２にリトライを発行してコヒーレンシを保つ機能も持つ。
【００４６】
後続リトライ部１２は、障害発生後から障害が検出されたトランザクションのリトライ処理が終了するまでの間に、新たにプロセッサ２から発行されたトランザクションをリトライするための機能であり、障害が発生したトランザクションがコヒーレンシ保障を必要とする場合に有効になり、障害トランザクションのリトライ処理が終了すると解除される。
【００４７】
後続リトライ部１２は、後続リトライ部１２が有効である間、プロセッサ２が発行した新規トランザクションがコヒーレンシ保障対象ではない場合は受け付けて通常の処理を行い、コヒーレンシ保障対象である場合はリトライにすることでコヒーレンシを保障している。
【００４８】
バッファ２１中の障害カウンタ５２はエントリ毎に設け、障害が発生するたびに１カウントアップする。障害カウンタ監視部２４は、バッファ２１中の障害カウンタ５２を監視する機能で、あらかじめ縮退させる障害発生回数を設定しておいて、障害カウンタ５２の値が設定回数を越えるとそのエントリを縮退する。
【００４９】
また、一定期間内で許容できる障害回数も定めておき、障害カウンタ５２の値が設定した回数以下の場合は障害カウンタ５２をリセットする。縮退方法についてはバッファの使用中フラグ５０を“使用中”にして、情報５１には例えばオール“０”のような他の制御に影響を及ぼさない無効データを格納して無効化する。使用中フラグ５０を“使用中”にしておくことで新たにそのエントリが選択されることはないため特別な回路を設けなくても縮退と同等の機能が得られる。
【００５０】
次に、システム制御部１のエラー処理方法について詳細に説明する。図３は障害が検出されたトランザクションについての処理の一例を示すフローチャートである。
【００５１】
図３を参照すると、障害検出部２２でバッファ２１の障害を検出する（Ｓ１０１）。リトライ可能障害部３１で障害を検出した場合（Ｓ１０２にて“ＹＥＳ”の場合）はシステムダウンさせずに障害が発生したバッファ２１のエントリの障害カウンタ５２のカウントアップを行い（Ｓ１０３）、リトライ部４１ではプロセッサ２等にリトライを発行するために必要な情報を読み出してリトライ処理を行う（Ｓ１０４）。
【００５２】
プロセッサ２へのリトライ発行が終了したところで、後続リトライ部１２が有効である場合（Ｓ１０５で“ＹＥＳ”の場合）は後続リトライ部１２を解除して（Ｓ１０６）、処理を終了する。
【００５３】
リトライ処理が終了したトランザクションのエントリの再使用については、直ぐに使用出来る場合や、一定期間おいた後でリセットして利用する場合、また、他のバッファのリセットも行って利用する場合等、バッファの用途や障害箇所によって異なる。
【００５４】
障害検出がリトライ可能障害部３１ではない場合（Ｓ１０２にて“ＮＯ”の場合）、すなわちリトライ不可能障害部３２で検出された場合はシステムダウンさせる（Ｓ１０９）。
【００５５】
リトライ可能障害部３１で障害を検出した場合には（Ｓ１０２にて“ＹＥＳ”の場合）、障害検出したバッファ２１のエントリのトランザクションがコヒーレンシ保障対象トランザクションかどうかについても調べる（Ｓ１０７）。
【００５６】
明らかにコヒーレンシ保障対象トランザクションではないと判断できる場合を除き（Ｓ１０７にて“ＹＥＳ”の場合）、コヒーレンシ保障対象トランザクションとみなして後続リトライ部１２を有効にする（Ｓ１０８）。
【００５７】
明らかにコヒーレンシ保障対象トランザクションではないとは判断できない例として、コヒーレンシ保障対象か否かを判断するための情報に障害が発生した場合があげられる。
【００５８】
後続リトライ部１２が有効でない場合（Ｓ１０５で“ＮＯ”の場合、および明らかにコヒーレンシ保障対象トランザクションではないと判断できる場合（Ｓ１０７にて“ＮＯ”の場合）は処理を終了する。
【００５９】
図４はバッファ２１のリトライ可能障害部３１で障害が検出された際に障害が検出されたトランザクション以外のアウト・オブ・オーダー処理中のトランザクションに対する処理の一例を示すフローチャートである。
【００６０】
図４を参照すると、リトライ可能障害部３１で障害が検出されると（Ｓ２０１）、リトライ部４１では障害が検出されたトランザクションがコヒーレンシ保障対象であるかどうかを調べる（Ｓ２０２）。
【００６１】
障害が検出されたトランザクションがコヒーレンシ保障対象でない場合は（Ｓ２０２にて“ＮＯ”の場合）、処理中のアウト・オブ・オーダー・トランザクションは通常処理を継続する（Ｓ２０５）。
【００６２】
障害が検出されたトランザクションがコヒーレンシ保障対象であった場合は（Ｓ２０２にて“ＹＥＳ”の場合）、処理中のアウト・オブ・オーダー・トランザクション全てについてそのトランザクションがコヒーレンシ保障対象であるかを調べ（Ｓ２０３）、コヒーレンシ保障対象でない場合は（Ｓ２０３にて“ＮＯ”の場合）、通常処理を継続し（Ｓ２０５）、コヒーレンシ保障対象であれば（Ｓ２０３にて“ＹＥＳ”の場合）、リトライ処理を行う（Ｓ２０４）。
【００６３】
リトライ処理（Ｓ２０４）は、バッファ２１のそれぞれのエントリの情報５１内に図示しないリトライフラグを設けておいて、障害発生時にリトライ処理が必要なトランザクションであると判定された場合はそのトランザクションのエントリのリトライフラグを有効にしておき、通常動作時のリプライを行うために必要な条件が揃った後でリトライに差し替えて、プロセッサへリトライを発行して処理を終了する。データが付随する場合はデータを廃棄して処理を終了する。
【００６４】
図５はリトライ可能障害部３１で検出された障害の処理中に、プロセッサ２から新規トランザクションが発行されたときの処理の一例を示すフローチャートである。プロセッサ２からトランザクションを受け付けると（Ｓ３０１）、後続リトライ部１２が有効かどうかを調べる（Ｓ３０２）。
【００６５】
後続リトライ部１２が無効な場合は（Ｓ３０２にて“ＮＯ”の場合）、トランザクションを受け付けてアウト・オブ・オーダー処理等の通常処理を実施する（Ｓ３０５）。
【００６６】
後続リトライ部１２が有効な場合は（Ｓ３０２にて“ＹＥＳ”の場合）、プロセッサ２から受け取ったトランザクションがコヒーレンシ保障対象か否かを調べ（Ｓ３０３）、コヒーレンシ保障対象の場合は（Ｓ３０３にて“ＹＥＳ”の場合）、リトライ処理を行い（Ｓ３０４）、コヒーレンシ保障対象でない場合は（Ｓ３０３にて“ＮＯ”の場合）、トランザクションを受け付けてアウト・オブ・オーダー処理等の通常処理を継続する（Ｓ３０５）。
【００６７】
図６はバッファ２１の障害カウンタ５２の監視動作の一例を示すフローチャートである。障害カウンタ監視部２４では、バッファ２１のそれぞれのエントリにある障害カウンタ５２を一定期間毎に監視し（Ｓ４０１）、障害カウンタ５２の値が縮退閾値回数を超えた場合は（Ｓ４０２にて“ＹＥＳ”の場合）、バッファ２１の該当エントリの縮退を行う（Ｓ４０５）。
【００６８】
これは固定故障によるリトライ多発を防ぐためである。ここで、縮退閾値回数とは縮退を開始する障害発生回数のことであり、使用する要件に応じて任意の値に設定可能である。
【００６９】
縮退縮退方法としてはバッファ２１のエントリの使用中フラグ５０を有効にすることによって、新たにそのエントリが使用されないようして、同時に、他の制御に影響を及ぼさないようにそのエントリの情報５１にはオール“０”等の無効なデータを書き込むことで縮退とする。
【００７０】
障害カウンタ５２が縮退閾値回数以下の場合は（Ｓ４０２にて“ＮＯ”の場合）、一定期間内で許容される障害回数として設定したリセット可能回数の値と障害カウンタ５２値とを比較し（Ｓ４０３）、リセット可能回数以下の場合は（Ｓ４０３にて“ＮＯ”の場合）、障害カウンタ５２をリセットする（Ｓ４０４）。これは間欠障害に起因したバッファの縮退によってバッファ容量の減少を防ぐためである。
【００７１】
一方、リセット可能回数を超えた場合は（Ｓ４０３にて“ＹＥＳ”の場合）、障害カウンタ５２をリセットしない。
【００７２】
次に、エラー処理方法の制御プログラムについて詳細に説明する。図１を参照すると、第１メモリ４と第２メモリ５とが表示されている。第１メモリには本発明に係るエラー処理以外の処理を行うための制御プログラムあるいはデータが格納されている。一方、第２メモリ５には本発明に係るエラー処理を行うための制御プログラムが格納されている。
本発明に係るエラー処理を行うための制御プログラムとは、図３〜図６にフローチャートで示す処理をコンピュータ（本実施例では図１のシステム制御部１）に実行させるためのプログラムである。
【００７３】
システム制御部１は第２メモリ５からエラー処理を行うための制御プログラムを読み出し、そのプログラムに従ってトランザクション制御部１１および後続リトライ部１２を制御する。その制御内容については既に述べたのでその説明は省略する。
【００７４】
なお、本実施例では、エラ−処理方法について、制御プログラムで実現する方法を示したが、これをハ−ドウエア・シ−ケンスで実現することも可能である。
【産業上の利用可能性】
【００７５】
プロセッサがリトライ機能を有し、アウト・オブ・オーダー・トランザクションを処理するシステムにおいて、多量なバッファを用いるような場合に有効であり、高信頼性が求められる情報処理装置での利用が考えられる。また、プロセッサに限らずＩ／Ｏカードやメモリからでも、リトライ機能を有しアウト・オブ・オーダー処理を実施している場合には適用可能である。
【図面の簡単な説明】
【００７６】
【図１】本発明に係る情報処理装置の一例の構成図である。
【図２】バッファ２１の構成の一例を示す図である。
【図３】障害が検出されたトランザクションについての処理の一例を示すフローチャートである。
【図４】バッファ２１のリトライ可能障害部３１で障害が検出された際に障害が検出されたトランザクション以外のアウト・オブ・オーダー処理中のトランザクションに対する処理の一例を示すフローチャートである。
【図５】リトライ可能障害部３１で検出された障害の処理中に、プロセッサ２から新規トランザクションが発行されたときの処理の一例を示すフローチャートである。
【図６】バッファ２１の障害カウンタ５２の監視動作の一例を示すフローチャートである。
【符号の説明】
【００７７】
１ システム制御部
２ プロセッサ
３ デバイス
４ 第１メモリ
５ 第２メモリ
１１ アウト・オブ・オーダー・トランザクション制御部
１２ 後続リトライ部
２３ リプライ制御部
２４ 障害カウンタ監視部
３１ リトライ可能障害部
３２ リトライ不可能障害部
４１ リトライ部
５０ 使用中フラグ
５１ 情報
５２ 障害カウンタ
【特許請求の範囲】
【請求項１】
発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置であって、
受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御手段を含むことを特徴とする情報処理装置。
【請求項２】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、前記障害発生時に処理中のトランザクションであることを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、新規に発行されたトランザクションであることを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記バッファには発行元からのトランザクションに対応するエントリの障害発生回数が記録される障害カウンタが設けられ、前記トランザクション制御手段は前記障害カウンタの値が一定の閾値を超えた場合、該当エントリの縮退を行うことを特徴とする請求項１から３いずれかに記載の情報処理装置。
【請求項５】
発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法であって、
受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御ステップを含むことを特徴とするエラー処理方法。
【請求項６】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、前記障害発生時に処理中のトランザクションであることを特徴とする請求項５記載のエラー処理方法。
【請求項７】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、新規に発行されたトランザクションであることを特徴とする請求項５記載のエラー処理方法。
【請求項８】
前記バッファには発行元からのトランザクションに対応するエントリの障害発生回数が記録される障害カウンタが設けられ、前記トランザクション制御手段は前記障害カウンタの値が一定の閾値を超えた場合、該当エントリの縮退を行うことを特徴とする請求項５から７いずれかに記載のエラー処理方法。
【請求項９】
発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法の制御プログラムであって、
コンピュータに、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御処理を実行させるための制御プログラム。
【請求項１０】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、前記障害発生時に処理中のトランザクションであることを特徴とする請求項９記載の制御プログラム。
【請求項１１】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、新規に発行されたトランザクションであることを特徴とする請求項９記載の制御プログラム。
【請求項１２】
前記バッファには発行元からのトランザクションに対応するエントリの障害発生回数が記録される障害カウンタが設けられ、前記トランザクション制御手段は前記障害カウンタの値が一定の閾値を超えた場合、該当エントリの縮退を行うことを特徴とする請求項９から１１いずれかに記載の制御プログラム。
【請求項１】
発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置であって、
受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御手段を含むことを特徴とする情報処理装置。
【請求項２】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、前記障害発生時に処理中のトランザクションであることを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、新規に発行されたトランザクションであることを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記バッファには発行元からのトランザクションに対応するエントリの障害発生回数が記録される障害カウンタが設けられ、前記トランザクション制御手段は前記障害カウンタの値が一定の閾値を超えた場合、該当エントリの縮退を行うことを特徴とする請求項１から３いずれかに記載の情報処理装置。
【請求項５】
発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法であって、
受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御ステップを含むことを特徴とするエラー処理方法。
【請求項６】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、前記障害発生時に処理中のトランザクションであることを特徴とする請求項５記載のエラー処理方法。
【請求項７】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、新規に発行されたトランザクションであることを特徴とする請求項５記載のエラー処理方法。
【請求項８】
前記バッファには発行元からのトランザクションに対応するエントリの障害発生回数が記録される障害カウンタが設けられ、前記トランザクション制御手段は前記障害カウンタの値が一定の閾値を超えた場合、該当エントリの縮退を行うことを特徴とする請求項５から７いずれかに記載のエラー処理方法。
【請求項９】
発行元からのトランザクションを受け付けてからアウト・オブ・オーダー（ｏｕｔ ｏｆ ｏｒｄｅｒ）処理でリプライを返却するまでの間トランザクションを管理する情報処理装置におけるエラー処理方法の制御プログラムであって、
コンピュータに、受け付けたトランザクションを格納するバッファでの障害を検出し、そのトランザクションのリトライとともに、そのトランザクションとコヒーレンシの関係にある他のトランザクションもリトライするトランザクション制御処理を実行させるための制御プログラム。
【請求項１０】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、前記障害発生時に処理中のトランザクションであることを特徴とする請求項９記載の制御プログラム。
【請求項１１】
前記障害検出に係るトランザクションとコヒーレンシの関係にある他のトランザクションは、新規に発行されたトランザクションであることを特徴とする請求項９記載の制御プログラム。
【請求項１２】
前記バッファには発行元からのトランザクションに対応するエントリの障害発生回数が記録される障害カウンタが設けられ、前記トランザクション制御手段は前記障害カウンタの値が一定の閾値を超えた場合、該当エントリの縮退を行うことを特徴とする請求項９から１１いずれかに記載の制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００７−１４８４６７（Ｐ２００７−１４８４６７Ａ）
【公開日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願番号】特願２００５−３３７９７２（Ｐ２００５−３３７９７２）
【出願日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（０００１６８２８５）エヌイーシーコンピュータテクノ株式会社 (572)
【Ｆターム（参考）】
【公開日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（０００１６８２８５）エヌイーシーコンピュータテクノ株式会社 (572)
【Ｆターム（参考）】
[ Back to top ]