JP5102634B2 - 決定的イベント・シーケンスのロギングおよび再生のための命令をカウントする方法 - Google Patents

Description

本発明は、１つ以上のプロセッサ、特に並列アーキテクチャを有するマルチプロセッサ・システムにおいて実行されるタスクの動作を監視し管理するための透明かつ非侵入的な方法に関する。これは、具体的には、ネットワークにおいて実行されるマルチタスク・トランザクション・アプリケーションの様々なタスクに適用される。この管理は、特に、ロギング・データの形態でこれらのタスクの動作を記録し、かかるロギング・データからこの動作を再生して、ロギングの間に取得したものに対応する挙動および結果を提示することを可能とする。

また、本発明は、実行するソフトウェア・アプリケーションの機能管理においてかかる方法を実装するシステムに関する。

管理されるアプリケーションに関して非侵入的かつ透明な機能管理を実装することは、極めて有用である。これによって、特に、オリジナルの状態にある多くの既存のアプリケーション（「レガシー・アプリケーション」）を、一層柔軟に、信頼性高く、または高性能で使用可能とすることができる。

中間捕獲を行い、同期点または再開始点（「チェックポイント」）でアプリケーションの状態を復元することによる非侵入的な機能管理技法は、本出願人によって、特許文献１においてすでに提案されている。補足的に、非侵入的なロギングおよび再生技法が、本出願人によって、特許文献２および３においてすでに提案されている。
フランス国特許出願ＦＲ ０４ ０７１８０ フランス国特許出願ＦＲ ０５ ００６０５ フランス国特許出願ＦＲ ０５ ００６１３ フランス国特許ＦＲ ２ ８２０ ２２１

しかしながら、１つ以上のイベントのロギングは、ログされたアプリケーションまたはこれを実行するシステムにとって作業オーバーヘッドとなり、これをできる限り小さくすることには極めて関心が高い。

アプリケーションの実行を構成するイベントの中で、アプリケーションの状態に対して非決定的な挙動を有するものは、後の再生の間にそれらの結果を強制または再注入することができるように、それらの結果をロギング・データにストアしなければならない。従って、目的とすることは、非決定的として処理しなければならないイベントの数をできる限り減らすことである。

アプリケーションの外部イベント、またはこれを実行しているシステムの外部イベントは、本質的に非決定的な挙動を有することが多く、一般に、例えば前掲の特許文献に記載されているようにストアしなければならない。

これに比べて、内部イベントは、非常に多くの場合に決定的な挙動を有し、アプリケーションの稼働中に実行される動作の大部分を構成する。従って、目的となるのは、特に内部イベントのうち非決定的なイベントのロギングを集約しかつ最適化することである。

実行の一部からの全てのイベントが決定的である場合、この部分は全て、例えば再開始点の形態で単にアプリケーションの開始状態をストアすることによって、経済的にログすることができる。そして、再生を行うには、例えば、アプリケーションをストアの際の再開始点状態に復元し、これらの決定的イベントの実行を起動する。その場合、決定的イベントのみから成る決定的部分のグループを含む「区分的に決定的な実行モデル」という用語を用いることができる。従って、一般に、決定的部分の境界は、非決定的イベントによって構成される。例えば、その開始時には外部メッセージが到着し、その終了時には別の非決定的イベントが起こる。

本発明の１つの目的は、かかる決定的部分のロギングおよび再生を簡略化または最適化することである。

更に、あるタイプのコンピュータ・アーキテクチャは、時にそれら自身の性質に固有の非決定性の原因（non-determinism causes）を含む場合がある。特に並列アーキテクチャ・システムにおいて、時に物理的または実際の並列処理として認められるものがそうである。

従って、本発明の別の目的は、ロギングおよび再生機能の実装を容易にするまたは最適化することであり、特にマルチタスク・アプリケーションについて、並列環境において非決定性の原因を少なくすることである。

冗長アーキテクチャにおける機能管理の状況において、本発明の別の目的は、並列環境において実行されるマルチタスク・アプリケーションの機能を高信頼性化する（reliabilize）ことである。

決定的部分は、本来、同じ状況から開始して同じ命令を実行すると、常に同じ結果を与える。従って、かかる決定的部分をログしかつ再生するためには、開始状況のみをストアしかつ復元して、この部分の長さに対応する命令数の間、同じ実行可能ファイルから実行を行わせることができる。

しかしながら、これが最初のアプリケーションにおいて想定されていない場合、実行された命令のカウントの実装は、これらの命令を実行する少なくとも１つの機械にとって著しい作業負荷となる。既知の技法では、かかる過負荷は多くの場合、容認できないか、またはかかる実装を実験的な状況に限定してしまい、活用するという状況においては殆ど用いることができない。

本発明の目的は、これらの欠点の全てまたは一部を克服することである。

このため、本発明は、コンピュータ・システムにおいて、性能を監視または推定する手段を備えたプロセッサ内で、活動期間（activity period）と称する所与の実行期間中に、ターゲットと称するコンピュータ・タスクを管理するための方法を提案する。これらの手段は、相対エラーと称する＋または−の所与の可能なエラーを有するカウンタを含む。

この方法は、前記カウンタを用いて、前記活動期間の少なくとも１つの所与の時点まで、実行された命令の数を評価するステップと、プロセッサまたはコンピュータ・システムの状態から読み取られたかまたは計算された、前記活動期間の少なくとも１つの所与の時点に対応する、署名と称するデータを生成するステップを含む。

管理された期間の開始以降に実行された命令の数の評価が、コンピュータと共同で同期バリアとして少なくとも１つのシステム・コール命令を用いると好都合である。

この方法は、特に、２つの非決定的動作の間の連続的な決定的動作から成る活動期間の間のタスクを管理するために有用である。

従って、本発明は、ログされたプロセッサと称するプロセッサにログされているタスクを管理することを提案し、ログされた期間と称する前記タスクのこの活動期間に対応するロギング・データをストアすることを含む。かかるロギング・データは、実行された命令の数の少なくとも１つの推定値および前記ログされた期間の終了に対応するログされた署名と称する署名を含む。

従って、順序付けられた態様で、プロセッサ・ログと称する少なくとも１つのファイルに、前記プロセッサにおいて実行される複数のタスクの連続的な活動期間のロギングを表すロギング・データをストアすることによって、プロセッサの使用をログすることができる。ロギング・データは、実行されたタスクを識別するデータのアイテムをこれらの各期間ごとに含む。

かかるロギング・データから、本発明は、ログされた期間の開始時においてログされたプロセッサまたはログされたシステムの状態に対応する状態から開始して、再生コンピュータ・システム内で、再生プロセッサと称するプロセッサによって実行される、再生タスクと称するタスクを管理することによって、ログされた期間を再生することを提案する。また、この方法は、再生タスクの実行の監視段階と確認段階を含む。
この監視段階は、カウンタによって評価されたログされた期間の命令数をカウンタの相対エラーだけ減少させた、ログされた期間の命令数の推定値に等しいかまたはこれより少ない数の命令を、再生の期間の開始から実行する。
この確認段階は、再生における所与の時点における再生タスクの実行を中断するステップと、ログされた署名と再生中断時点に対応する署名との間の比較テスト・ステップとの繰り返しからなる。

特に、ログされた署名は、ログ・ポインタと称するデータを含み、これがログされた期間の終了時におけるログされたタスクの命令ポインタの値を表す。また、この方法は、ログされたポインタ・データに対応する再生命令上にブレークポイントを設定するステップも含む。

本発明によれば、再生タスクの実行の監視段階は、特に、カウンタのオーバーフローを含み、このカウンタが、再生期間の開始から実行しなければならない命令の数を決定するために事前に初期化され、そのオーバーフローによって再生タスクの中断を生じさせる。

しかしながら、このタイプのカウンタは、かかる正確な使用には想定されていないので、かかる中断は、カウンタ・オーバーフローの後にある遅延をもって発生する場合がある。

従って、本発明は、カウンタのオーバーフローとこれを生じさせたタスクの中断との間にレイテンシ期間が存在する場合に充分に早期にオーバーフローを起こすため、再生タスクによって実行される命令数が、前記カウンタの相対エラーだけ減少させた、ログされた期間の命令数の推定値に等しいかまたはこれより少ない数となるように、カウンタを、一定のマージンをもって再生期間の開始時において初期化することを提案する。

更に、セキュリティとして、確認段階は、再生タスクによって実行される命令数が、ログされた期間の命令数を所与の命令数だけ増大させた推定値を超えた場合に、エラーを信号で知らせるセキュリティ・ステップを含むことができる。

このようにログされたいくつかの期間を表すログから、本発明は、前記ログされたプロセッサにおいてログされた連続的な活動期間の１組の順序付けられたロギング・データを用いることによって、再生プロセッサと称するプロセッサにおいて、ログされたプロセッサの使用の再生を実行することができる。

また、本発明は、複数のログされたタスクによってアクセスされる、ターゲット・リソースと称する共有リソースに関連する連続的な帰属された排他的アクセスのロギングを行い、この方法は、リソース・ログと称する少なくとも１つのファイルの送信またはストアも行う。従って、このリソースは、これらの排他的アクセスを取得した異なる連続的なタスクの各々の識別を表すロギング・データを含む。

これらの技法から開始して、本発明は、少なくとも２つの演算ユニットにおいて同時に多数のアプリケーション・タスクを実行することができる計算手段を含む並列構造を備えた、コンピュータ・システムにおいて、少なくとも２つのアプリケーション・タスクの実行を連続的な活動化によって管理するシステム・ソフトウェア内で、前記タスクの機能を管理することを提案する。少なくとも１つの共有リソースにアクセスする、かかるアプリケーション・タスクについて、この方法は、
第１の演算ユニットにおいてこれらのタスクの一方または他方の第１の連続的な活動期間をロギングするステップと、
第２の演算ユニットにおいてこれらのタスクの一方または他方の第２の連続的な活動期間をロギングするステップと、
前記ターゲット・リソースに対するアクセスの要求に応答して、前記タスクのうちいわゆるアクセス・タスクに対して、前記ターゲット・リソースに排他的と称するアクセスの連続的な帰属（attribution）をロギングするステップを含む。すなわち、かかる帰属は、前記アクセス要求の直後のアクセス・タスクの活動期間の残り全ての間、これらのタスクの別のものによる前記ターゲット・リソースに対するいかなるアクセスも排除する。

他方で、この方法は、再生シリアル化と称する順序付けられた構造において、演算ユニットの各々における連続的な活動期間を表すロギング・データを、連続的な帰属された排他的アクセスを表すロギング・データと組み合わせる。この組み合わせは、各タスク内で、共有リソースに関連して、連続的な活動期間の順序を維持するように構成されている。

本発明によれば、ログされたタスクのログされた実行を再生するために、再生コンピュータ・システム内で、再生シリアル化データを用いることができる。

更に、この方法は、再生コンピュータ・システム内で、ロギングの間にログされたタスクにアクセス可能な前記ソフトウェア・リソースの全てまたは一部を仮想化することを含むことができる。

本発明によるこの方法は、コンピュータ・ネットワークの、１次ノードと称する並列構造を有する少なくとも１つのノード上で実行され、少なくとも１つの共有リソースにアクセスする、少なくとも２つのタスクを含むログされたアプリケーションの機能の、アクティブと称する複製を実行することを可能とする。従って、この複製は、再生システム上の少なくとも１つの再生アプリケーションにおいて、１次ノードから発生された場合に第２のノードへとオン・ザ・フローで送信されるロギング・データから開始する再生シリアル化の再生を含む。

一実施形態において、本発明は、コンピュータ・ネットワークの、１次ノードと称する並列構造を有する少なくとも１つのノード上で実行され、少なくとも１つの共有リソースにアクセスする、少なくとも２つのタスクを含むアプリケーションの高信頼性化を実行することができる。従って、この高信頼性化は、１次ノード内での故障または所与のイベントの検出時に開始される、１次ノードから少なくとも１つの２次ノードへのサービスのスイッチングも含む。

別の実施形態において、本発明は、１次ノード上で実行されるターゲット・アプリケーションのアクティブ・レプリカを少なくとも１つの２次ノード上で実行するコンピュータ・ネットワーク内で、作業負荷の平衡化または調整を可能とする。従って、この負荷の平衡化は、管理されたターゲット・アプリケーションが提供するサービスの全てまたは一部のアクティブ・レプリカへのスイッチングを含む。

従って、本発明による方法は、例えばミドルウェア・タイプの１つ以上の機能管理アプリケーションが管理するクラスタを構成するネットワークのような、コンピュータ・ネットワークの少なくとも１つのノード内で実装することができる。従って、この方法は、特に命令シーケンスのロギングおよび再生によって、この機能管理の性能および機能を拡張または最適化することができる。

同一の状況において、本発明は、この方法を実装するシステムも提案する。これは、並列タイプまたは並列システムを構成し、場合によってはネットワークにおいて用いられる１つ以上のコンピュータ・システムに適用される。

本発明の他の特徴および利点は、限定的なものではない実施形態の詳細な説明および添付図面から、明らかになろう。

発明を実装するための最良の形態

本明細書中に記載する技法は、例えばＡＭＤ社からのＡｔｈｌｏｎ（TM）タイプのプロセッサ、またはＩｎｔｅl社からのＰｅｎｔｉｕｍ（R）プロセッサ等の、ＰＣタイプのコンピュータにおいて用いられるタイプのプロセッサのある特性を用いた本発明の実施形態に対応する。もちろん、例えばワークステーションにおいて用いられる他の現行プロセッサまたは将来のプロセッサも、これらの特性または同様の特性の全てまたは一部を提供することができ、本発明を実行するために使用可能である。

図１および図２は、単一のμＰｒｏＸプロセッサまたは演算ユニットによって連続的に実行される、決定的内部イベントの異なる部分をロギングするための技法を示す。

図１に示すように、異なるタスクＴＡおよびＴＢは、スケジューラＳＣＨによって連続的に起動される、活動期間Ｓｃｈ１〜Ｓｃｈ３と称する部分によって実行することができる。スケジューラＳＣＨは、コンテキスト・マネージャと称するシステム・エージェントの一部を形成し、これらの交番または交差を管理する。

コンピュータ・システムまたはプロセッサ内で実行される異なるタスクのうち、一部のものが、管理対象のアプリケーションの部分である場合があり、「被監視」タスクとして認められる。これらのタスクは、タスク記述子内の通常用いられないデータ・ビットの状態（１にセットされる）によって識別され、ここではこれを管理ビットＭｍＡまたはＭｍＢ（図７を参照）と称する。被監視タスクおよび監視されない他のものは、プロセッサにおいて実行される連続的な活動期間内で交番することができる。

図２において文字「ｍ」によって標示される被監視タスクＴＡおよびＴＢについては、それらが決定的イベントのみで構成されるように活動期間を選択する。これらの決定的期間は、１つ以上のロギング・ソフトウェア・エージェントによって定義される。このロギング・エージェントは、機能管理アプリケーションのタスクとして、コンピュータ・システムのユーザ・メモリ空間において実行される要素を含むことができる。また、このロギング・エージェントは、システム・ソフトウェア内、例えばスケジューラ内で、変更または追加された要素を含むかまたは用いることができる。

アプリケーションのイベントの大部分は内部イベントであり、それらの多くは決定的であるので、管理された各タスクの大部分は決定的イベントから成る。非決定的イベントが起こるたびに、ロギング・エージェントは決定的期間を終了させる。次いで、検出された非決定的イベントは、場合によっては監視されないタスクの形態で実行され、既知の方法に従ってその結果と共にログされる。この非決定的イベントが完了すると、ロギング・エージェントは新しい決定的部分の開始を定義し、再び命令のカウントを起動する。

非決定的イベントのロギングおよび場合によってはその処理は、決定的な活動期間の外で、例えば、カーネル・モードＫＬｖにおける実行期間Ｋ１またはＫ２で行われる。すなわちプロセッサ特権モードの値が０の間であり、これに対して、ユーザ・モードＵｌｖについての値は３である。

ロギングの場合と同じ態様で各活動期間を再生することを可能とするために、本発明は、ロギング時にこの決定的部分の間に実行される命令のカウントを実行する。従って、これらのタスクを後に再生ＲＳＣＨ（図３および図４を参照）する間、このログされた部分をロギングの場合と同じ状態から起動するだけで、この同じタスクについてロギング時のこの同じ部分が実行した命令の数に厳密に相当する再生命令の数までそれ自身で実行することができる。従って、この再生は、決定的部分内に結果を強制する介入なしに実行される。後者は決定的イベントのみを含むからである。

１つの決定的部分が、スケジューラによって確立された複数の活動期間にわたって延在する場合、これらの活動期間の各々は、この決定的部分の一部を含み、それ自体、完全な決定的部分として処理することができる。本明細書の残り部分では、決定的活動期間のロギングのみを説明するが、単一の決定的部分において多数の決定的活動期間が互いの後に続くことができることは明らかである。

本発明によれば、決定的活動期間の命令のこのカウントは、性能および監視カウンタを用いる。これは現在、多数のプロセッサにおける既存のハードウェア機構である。例として、Ｉｎｔｅｌ社からのＰｅｎｔｉｕｍ（R）ファミリについてのＰｅｎｔｉｕｍ（R）２以降が挙げられる。この性能および監視カウンタは、持続時間において、または多数のイベントにおいて、プロセッサの機能を測定するために設けられており、例えばアプリケーション・プロファイルの統計的分析を実行するため、その値の周期的サンプリングによって、性能を測定するために主に用いられる。また、プロセッサ製造業者は、これらの性能カウンタが保証された精度を持たず、アプリケーションの最適化のために相対的または差動的な測定のために用いなければならないと指定する。

本発明は、この性能カウンタＰＭＣの特性の１つを用いることを提案する。すなわち、引退済みと称する命令、すなわち解決したか、または実行すべき命令のリストから出た命令のカウントである。これは、性能の理由のために前もっていくつかの命令を実行させることができる様々な投機的またはキャッシュ技法とは無関係である。

しかしながら、引退済み命令のこのカウントには、Ｉｎｔｅｌ社およびＡＭＤ社からの文書において記載されている、ある制限的な特性がある。これらの特性の１つは、このカウンタのための読み取り命令（「ＲＤＰＭＣ」）が解決すべき命令に直接統合されないことである。これは、本発明と関連付けてこのカウンタを用いることに直接的な影響をもたらさない。

一方、２つの他の制限的な特性は、ロギングおよび再生のための命令のカウントにおいて不正確さを発生させる場合があり、考慮しなければならない。

不利益となる恐れのある第４の特性は、カウンタ・オーバーフローを引き起こした命令の後にいくらかの遅延を伴って、このカウンタ・オーバーフローによる実行の中断が起こる場合があるという事実である。

これらの不正確さによる制限は、一方では、ある複雑な命令が解決される前に中断されると２度カウントされる場合があることに関係し、他方では、ハードウェア中断を伴う命令によって命令の非カウントを生じさせる場合があることに関連する。この不正確さを克服するため、本発明は、活動期間の終了の正確な決定に関連する不確かさを排除することができる、補足的な確認技法を用いる。

図１に示すように、μＰｒｏＸプロセッサにおいて実行される連続的な決定的活動期間Ｓｃｈ１、Ｓｃｈ２およびＳｃｈ３は、ログ・ファイルＪμＰｒｏＸにログされかつ記録される。

プロセッサが被監視タスクＴＡを実行しているログされた活動期間Ｓｃｈ３の間、カウンタＰＭＣの値ＵＩＣＸの１つ以上の読み取り命令ＲＤＰＭＣは、引退済み命令の数ＮＪ３を供給する。この期間Ｓｃｈ３の停止（ｅｎｄ Ｓｃｈ３）時に、ロギング・エージェントＪＳＣＨは、タスクＴＡおよびそのコンテキストの状態によって出力される状態データの１つ以上のアイテムを用いる。これは、この活動期間Ｓｃｈ３の間に実行された正確な命令数に関して存在し得る不確かさを排除するために、充分に明白な態様でこの状態を表すデータの１つ以上のアイテムを計算するためである。この状態データは、この期間終了（ｅｎｄ Ｓｃｈ３）に対応する署名ＳＧ３を構成する。この署名は、具体的には、この期間の最後の命令の直後の命令ポインタの正確な値ＩＰＪＸ３、すなわちタスクＴＡの実行可能ファイルにおける最後に実行されたプログラム命令の位置の正確な識別を含む。また、この署名は、この停止（ｅｎｄ Ｓｃｈ３）時におけるタスクＴＡのコンテキストからのコール・スタックＰｉｌｅＪＸ３およびレジスタＲｅｇＪＸ３に読み取られた値から計算された制御データ（「チェックサム」）を含む。

従って、ログされた期間ＳｃｈＪ（図３）の各々について、このプロセッサのログＪμＰｒｏＸは、特に、次に関連するラインを含む。
−この期間において実行されたタスクＴＪの識別ｉｄＪ、例えばこのタスクの「ＰＩＤ」
−カウンタＰＭＣによって送信された、引退済み命令の数ＮＪの値
−この期間の終了について計算された署名ＳＧＪ

従って、図１に示したタスクＴＡ、次いでタスクＴＢ、次いでタスクＴＡという連続的なタスクについて、プロセッサμＰｒｏＸのログＪμＰｒｏＸは、以下の連続的なラインを含む。
idA: NJ3: SG3
idB: NJ2: SG2
idA: NJ1: SG1

図２に示すように、所与のμＰｒｏＸプロセッサ内のログされたアプリケーションＡＰＰＪについてログされた連続的な異なるタスクは、最初に、ロギング・エージェントＪＳＣＨによって、ＦＩＦＯ（「先入れ先出し」）タイプのロギング・キューＱＪμＰｒｏｘに送信することができる。このキューの出力におけるロギング・ラインは、ログ・ストア・タスクＴＪμＰｒｏｘによって読み取られる。このタスクは、これらのラインを順序付けられた態様でこのプロセッサのログＪμＰｒｏｘにストアすることを開始する。このストアは、ローカルに（ＭＥＭ）、または別のノードまたはバックアップ・ステーションまたは周辺装置に送信（ＴＲＡＮＳ）することによって行われる。かかるロギング・キューの使用は、特にバッファ・ゾーンとして機能して、ロギング・データのフローを規制すると共に、ログされたアプリケーションまたはこのロギングを実行しているアプリケーションを妨害することを回避する。

この利点は、特に、グローバル・アーキテクチャの場合に評価することができる。この場合、ロギング・データは、発生したときにオン・ザ・フローで（on-the-flow）、例えばスタンバイ機械上で同じ実行を再生している別のアプリケーションに送信されて、故障許容およびサービス継続を有する機能を実行する。

このカウント技法において、命令のカウントのための同期点としてシステム・コール命令を用いることが有利である場合がある。従って、これは、システム・コール・ルーチンがシステム・コール・カウンタを増分するように、これらのシステム・コール・ルーチンを装備化する（instrument）ことを伴う。従って、ハードウェア・カウンタＰＭＣによる命令のカウントは、低いままに留まる値を処理することができ、これによって性能が改善する。

図３および図４は、ログされた期間ＳｃｈＪの再生プロセッサμＰｒｏＺにおける再生技法を示す。図３は、このプロセッサにおける再生タスクＴＲの最新状態ＴＲ１〜ＴＲ４を表す。図４は、かかる再生を実装するために用いる方法のフロー図を表す。実施形態または使用パラメータに依存して、再生はロギングと同じプロセッサにおいて行うことができ、例えば、異なる再生プロセッサと同じ原理に従って、アプリケーション追跡タイプの機能管理を行う。

かかる再生の間、例えば、再生エージェントＲＳＣＨを含むように変更されている場合があるスケジューラＳＣＨによってスケジューリングした活動期間として、問題となっているタスクＴＪは、前述のプロセッサにおけるそのコンテキストを復元され、次いでこのタスクは解放され（４１）、その実行が起動される。

ロギングが実行されたものとは異なる再生コンピュータ・システムにおける復元および実行を可能とするため、タスクまたはアプリケーションにアクセス可能なリソースの全てまたは一部を、例えば仮想的な態様で、すなわちインスタンス化または再現して、再生アプリケーションに対してロギングの間と同じように見せなければならない。一般に関与するアイテムは、スレットＴＩＰまたはプロセッサＰＩＤについてのタスク識別子であり、更に再生アプリケーションがアクセスしかつホスト・システムに依存するリソースの殆どである。この仮想化は、再生タスクまたはアプリケーションの開始時に実行され、ロギングの間にストアされたデータに従って、このロギングの間と同様に変化するように再生中に変更される。

この仮想化は、カーネル・モードにおいて実行すると好都合である。これによって、特に、性能カウンタＰＭＣによる命令のカウントにおいてその動作を考慮に入れることを回避することができる。

Ｉｎｔｅｌ社からの文書は、ハードウェア中断によるエラーは、＋１命令または−１命令の相対エラーに制限されることを指定する。高々１つの単一ハードウェア中断を含むログされた決定的期間について、すなわち、その終了を生じさせたものについて、監視はカウンタＰＭＣの２つの値を考慮する必要がある。すなわち、再生期間の開始時の値および監視点における値である。従って、最大相対エラーは、＋２命令または−２命令である。

ログされたタスクＴＪの再生のための再生タスクＴＲの実行全体を通して、再生エージェントＲＳＣＨは引退した命令数を監視するため、ＲＤＰＭＣによって再生を実行するプロセッサμＰｒｏＸのカウンタＰＭＣを読み取り、この読み取り値をこのログされたタスクＴＪに対応するロギング・データＩｄＪ、ＮＪ、ＳＧＪと比較する。この監視は、一旦この再生実行における命令の順序値がＮＪ−２に等しくなると、再生タスクＴＲの実行を中断するように構成されている。この中断は、例えば、カウンタＰＭＣのオーバーフローを所望の値にプログラミングすることによって実行される。

前述の第４の制限的な特性のため、オーバーフローと中断との間のレイテンシ時間の存在は、あるマージンでオーバーフローをプログラミングする（４１）（図４）ことによって補償することができる。そのようにすれば、ＮＪ−２の所望の値の前に中断を確実に行うようにすることができるからである。このマージンは実験によって決定することができ、例えば約５０の命令とすることができる。

従って、再生期間ＳｃｈＲの最初の実行は、ＮＪ−５０とＮＪ−２との間の命令数で中断される。次いで、再生エージェントＲＳＣＨは、再生タスクＴＲの実行可能ファイルのうち、署名ＳＧＪにストアした命令ポインタの値ＩＰＪに対応するプログラム命令ＢＫＩ上に実行ブレークポイントＢＫをセットする（４２）。次いで、このブレークポイントＢＫによる中断まで実行を再起動し（４３）、再生した命令数がログされた命令数から２命令を減じた値すなわちＮＲ＝ＮＪ−２以上になるまで、カウンタＰＭＣからの命令数をテストする（４４）。

このため、ログされた期間ＳｃｈＪの実際の正確な終了位置は、４つの後続の単一命令実行Ｉｎｓｔｒｕ０〜Ｉｎｓｔｒｕ３内に存在し、その各順序値はＮＪ−１〜ＮＪ＋２である。すなわち、この同じ期間ＳｃｈＪの推定終了位置ＮＪと比べて−２および＋２の間に含まれる相対的な位置にある。

次いで、確認段階（図４）では、この実際の位置を決定することができる。この位置を決定するため、後続の単一命令実行Ｉｎｓｔｒ１〜Ｉｎｓｔｒ４の後に、署名ＳＧＪを再生タスクＴＲの状態ＴＲ１〜ＴＲ４から同じやり方で計算した値ＳＧ１〜ＳＧ４（図３）と比較する。

この確認段階の開始時において、再生エージェントは、これに先行する監視によって生ぜられた中断の直後の再生タスクＴＲの状態に従って計算した再生署名ＳＧＲの値ＳＧ０を調べる（４５）。

本発明によれば、署名ＳＧＪおよびＳＧ０が一致しない場合、タスクＴＲの実行を再起動し、このブレークポイント命令ＢＫ１の最初の新しい実行ＴＲ２において停止する（４６）。

しかしながら、この新しい停止位置ＴＲ２が疑わしい場合がある。例えば、ログされたタスクＴＪが、停止される前にこのブレークポイント命令ＢＫＩを数回実行することによって極めて短いループを実行した場合である。このブレークポイント命令ＢＫＩに対する実行の各ブレークＴＲ２、ＴＲ４において、再生エージェントは署名ＳＧＪおよびＳＧＲの一致を再び検証し（４７）、この一致が得られるまで実行を再起動する。署名が一致すると（この例ではＳＧＪ＝ＳＧ４）、これは、ブレークポイント命令ＢＫＩの最後の実行Ｉｎｓｔｒ４がログされた期間ＳｃｈＪにおいてログされた最後の動作に対応することを意味する。次いで、再生エージェントは再生期間ＳｃｈＲを終了する（４８）。

また、本発明は、セキュリティ機構を想定する、例えば、テスト（４９）において再生ＴＲを中断し、ある数の特定の命令実行の後に再生エラーを戻して（４０１）、例えば８回の単一命令実行の終了時に、エラーの場合の無限ループを回避する。

複数のログされた期間を再生するため、例えばログされたアプリケーションＡＰＰＪに対応する再生アプリケーションＡＰＰＰ（図５）の再生において、再生エージェントＲＳＣＨは、ログＪμＰｒｏＸの異なるラインを連続して読み取り、問題となっているラインに対応する活動期間を再生するためにこれらの各々を用いる。

図５に示すように、このログＪμＰｒｏＸの異なるラインは、再生プロセッサμＰｒｏＺにおいて実行されるログ読み取りタスクＴμＰｒｏＺによって、直接受信される（ＴＲＡＮＳ）か、またはローカルに読み取られる（ＭＥＭ）。

次いで、各々がログされた期間に対応するこのログＪμＰｒｏＸのラインの全ては、ログされた順序で、ＦＩＦＯタイプの再生キューＱＪμＰｒｏＺに送信される。このキューの出力において、再生エージェントＲＳＣＨは、これらのログ・ラインの各々を用いて、それが表す期間を、ログされたタスクＴＡ、ＴＢおよびＴＣに対応する、再生タスクＴＡ’、ＴＢ’およびＴＣ’によって再生させる。

再生プロセッサμＰｒｏＺ内でこれらの期間のスケジューリングを実行するため、再生エージェントＲＳＣＨは、スケジューラＳＣＨの機能を、意味構造の変化なしに標準的なシステム・ソフトウェアに存在するとおりに用いる。この態様によって、特に、同じプロセッサにおいて実行される他のＴＮＭのタスクとの互換性を維持することができる。スケジューラＳＣＨの通常の機能を妨害することなく、ロギング中と同じスケジューリングを得るため、再生エージェントＲＳＣＨは、識別子ＴＩＤまたはＰＩＤが再生しなければならないラインにストアされた識別子ｉｄＡに対応しない限り、各再生タスクＴＢ’、ＴＣ’の解放を阻止する（５５ｂ、５５ｃ）。

決定的期間のロギングおよび再生のためのこれらの技法は、前掲の特許文献に記載されているように、１つ以上の単プロセッサ・コンピュータ内で機能管理アプリケーションの性能および機能を最適化することができる。

マルチプロセッサ・コンピュータまたは並列に動作する多数のコンピュータを含むネットワーク等の並列アーキテクチャの場合には、複数のタスクがアクセス可能な共有リソースの使用によって、非決定性の原因が増す。これは、この機能管理の状況において著しい性能損失の源となる恐れがあり、またはいくつかの重要かつ有用な機能を実装することを不可能とする場合さえある。

これらの非決定性の原因の全てまたは一部を排除するため、本発明は、特に直接アクセス・タイプの共有リソースに対するアクセスを管理または制御することを可能とする方法を提案し、システムによって活動化される期間全体にわたって、各タスクが共有リソースに対して排他的アクセスを得ることができるようにする。

図６は、並列マルチプロセッサ環境の機能の一例を示す。これは、マルチプロセッサ環境において、例えばＬｉｎｕｘタイプのシステムである第１のプロセッサμＰｒｏＸおよび第２のプロセッサμＰｒｏＹを含む。これらの２つのプロセッサは各々、単一の作業メモリ空間ＲＡＭ内で、タスクＴＡおよびＴＢをそれぞれ並列に実行し、スケジューラによって調整される。各タスクＴＡおよびＴＢの活動期間の間、プロセッサμＰｒｏＸ、μＰｒｏＹにおいて、そのプログラムＥＸＥＡ、ＥＸＥＢからの命令シーケンスＳｃｈＡ、ＳｃｈＢが実行される。このシーケンスからの命令ＩｎｓｔｒＡ、ＩｎｓｔｒＢの実行中、プロセッサは、レジスタＲｅｇＡ、ＲｅｇＢ、スタックＰｉｌＡ、ＰｉｌＢ等の、内部のリソースを用いることができる。

作業メモリＲＡＭ内では、例えば「マップ」タイプの命令によって、いくつかの共有メモリ・ゾーンＳｈＭＰｉ〜ＳｈＭＰｋを定義し、それらの物理アドレスによって直接、異なるタスクＴＡおよびＴＢからアクセス可能とする。

図６は、従来技術からの状況を示す。すなわち、タスクＴＡおよびＴＢは共通の期間にわたって並列に実行され、各々は単一の共有メモリ・ゾーンＳｈＭＰｉに対するアクセスを要求する命令ＩｎｓｔｒＡおよびＩｎｓｔｒＢを含む。これらの２つのアクセス要求は、各プロセッサのメモリ・マネージャ・ユニットＭＭＵによって独立した態様で処理され、互いに無関係に、この共有メモリ・ゾーンに到着する。

システム・コール・タイプのいくつかの命令からのみアクセス可能なリソースについては、これらの命令を実行するシステム・ルーチンを装備化することができる。すなわち、これらのルーチンを変更するか、またはこれらのシステム・コールをインターセプトまたはこれらのシステム・コールに反応する要素をシステムに挿入することができる。ロギングおよび再生による機能管理の状況において、この装備化（instrumentation）は、特に、それらの挙動を記録して、後に全く同様に再生可能とすること、またはこの挙動を決定的にして記録する必要がないように変更することができる。

これとは逆に、システム・コールなしに直接、従って場合によっては任意のプログラム命令からアクセス可能なリソースについては、殆どのオペレーティング・システムおよび特にＵｎｉｘ（R）またはＬｉｎｕｘタイプのものでは、この共有メモリ・ゾーンＳｈＭＰｉのレベルにおいて、これらのアクセスの到着を制御することはできない。

この問題を解決するため、図７および図８に示すように、本発明は、他の機能のために現用されているある既存のハードウェア機能を変更または拡張するように、いくつかのシステム・ソフトウェア要素のコードを変更すること、または他のいくつかのコードを追加することを提案する。

具体的には、現行プロセッサのハードウェア特性を変更することなく、Ｕｎｉｘ（R）またはＬｉｎｕｘタイプのシステム・ソフトウェアの少数の要素を変更することによって、この問題を解決することができる。従って、わずかに変更されたかまたは変更されていないマルチタスク・アプリケーションを実行および管理するために、既存のシステム・ソフトウェアにわずかな変更のみ行うことによって、共通タイプ、従って経済的かつ充分に検査された機械を用いることができ、それらの上位互換性を損なうことなく機能を追加する。

本発明は、このため、例えばＩｎｔｅｌ社からのＰｅｎｔｉｕｍ（R）プロセッサまたはＡＭＤ社からのＡｔｈｌｏｎ（TM）のような、ＰＣタイプのアーキテクチャにおいて用いられるプロセッサ等の、多くの最新のマイクロプロセッサに既存のいくつかの機構を用いる。これらのプロセッサは、特にＰｅｎｔｉｕｍ（R）２以降のものは、メモリ管理ユニット内に仮想メモリ管理機構を統合する。この機構は、作業メモリ内に定義されたいくつかのページを使用しない場合に、それらのページをハード・ディスク上に「アンロード」するために用いられ、物理メモリ内の対応する空間を解放するためにそれらのページをそこにストアする。現に実行中のアプリケーションについては、これらのページはなお作業メモリ内にリスト化されているが、タスクがそれに実際にアクセス可能となるためには、それらはハード・ディスクから物理メモリに再び「ロード」しなければならない。

この仮想メモリを管理するため、図８に示すように、システム・ソフトウェアは仮想メモリ・マネージャＶＭＭを含む。これは、仮想化可能なメモリの各ページごとに、異なる各アプリケーション・プロセス内でページ・テーブル・エントリ（「ＰＴＥ」）を生成する。このため、各々がプロセス（すなわちその専有に係る実行コンテキストを有する）の形態で実行される２つのタスクＴＡおよびＴＢについて、ページＳｈＭＰｉ〜ＳｈＭＰｋの各々は、タスクＴＡのプロセスにおいてページ・テーブル・エントリＰＴＥｉＡ〜ＰＴＥｋＡを取得し、タスクＴＢのプロセスにおいてページ・エントリ・テーブルＰＴＥｉＢ〜ＰＴＥｋＢを取得する。

仮想メモリ・マネージャＶＭＭは、ページ・ローダ・ソフトウェアＰＬを含む。これは、ハード・ディスク上の「スワップ」ファイルにメモリ・ページをロードおよびアンロードする。例えば、Ｍｉｃｒｏｓｏｆｔ社からのＷｉｎｄｏｗｓシステム（R）では、拡張子「.swp」を有するファイルである。ＳｈＭＰｉページの各ロードまたはアンロードの間、物理メモリ内のその存在または不在の状態は、それに対応するページ・テーブル・エントリＰＴＥｉＡおよびＰＴＥｉＢにおいて、ＶＭＭマネージャによってストアされかつ維持される（３０）。これらのテーブルＰＴＥｉＡおよびＰＴＥｉＢ内では、この存在状態は、それぞれデータ・ビットＰｒｉＡおよびＰｒｉＢの形態でストアされ、存在する場合は値１であり不在の場合は値０である。

各プロセッサμＰｒｏＸおよびμＰｒｏＹ内で、メモリ・マネージャＭＭＵＸまたはＭＭＵＹは、ページ不在（page fault）中断機構ＰＦＩｎｔＸまたはＰＦＩｎｔＹを含む。これによって、実行されるプログラム命令ＩｎｓｔｒＡまたはＩｎｓｔｒＢから開始する任意のアクセス要求を渡す。プロセッサμＰｒｏＸが実行するタスクＴＡからの命令ＩｎｓｔｒＡが、メモリ・ページＳｈＭＰｉに関係するアクセスを要求すると（３３）、プロセッサの中断機構ＰＦＩｎｔＸは、対応するエントリ・テーブルＰＴＥｉＡ内にあるその存在ビットＰｒｉＡの値を読み取ることによって、このページが物理メモリＲＡＭに存在するか否かを検証する。

このビットＰｒｉＡがページの存在を示す場合、中断機構ＰＦＩｎｔＸはアクセスを許可する。逆の場合、この中断機構ＰＦＩｎｔＡはタスクＴＡの実行を中断し、エラーのパラメータを、システム・ソフトウェアの仮想メモリ・マネージャＶＭＭに含まれる「ページ不在ハンドラ」ソフトウェア・エージェントＰＦＨに送信する。次いで、このページ不在ハンドラＰＦＨが実行され、システム・ソフトウェア内でアプリケーションに関連してこのエラーの結果を管理する。

図７は、本発明に従って共有リソースに対するアクセスを管理するために、これらの既存の機構をどのように変更して適合させるかを示す。

かかる並列環境において実行されるアプリケーションＡＰＰからのこれらのアクセスを管理するため、図７に示すように、ランチャ・ソフトウェアＬＣＨを用いて、例えばＵｎｉｘ（R）またはＬｉｎｕｘタイプのシステムにおいて、このアプリケーションの実行を起動する。その起動時に、第１のタスクＴＡを有するアプリケーションＡＰＰを生成する。第１のタスクＴＡは、実行「スレッド」ＴｈｒＡ１を含むプロセスの形態であり、タスク記述子ＴＤＡを形成するデータ・テーブルを用いる。

このタスク記述子ＴＤＡ内で、ランチャは、ここでは管理ビットＭｍＡと称する、通常は用いないデータ・ビットの状態を１に変更することによって、このタスクＴＡが管理または「監視」されなければならないという事実をストアする（２１）。

ここでは共有メモリ・ページＳｈＭＰｉ、ＳｈＭＰｊおよびＳｈＭＰｋとして認められる作業メモリ内の異なる共有メモリ・ゾーンは、ページ・メモリ構造ＰＭＳｔｒＡを形成するデータ・テーブルにおいてタスクＴＡ内にリスト化されている。この構造ＰＭＳｔｒＡにおいて、ページ・テーブル・エントリＰＴＥｉＡ１〜ＰＴＥｋＡ１の形態で、共有ページを記述しかつ更新する。その各々は、前述のように仮想メモリ・マネージャＶＭＭが用いるデータ・ビットＰｒｉＡ１〜ＰｒＫＡ１を組み込んでいる。通常、このページ構造ＰＭＳｔｒＡは、タスクＴＡと同時に生成され、共有メモリに任意の変化があると、「マップ」タイプのルーチン等の、これらの変更を確立する異なるシステム・ルーチンによって更新される（２０）。

管理されたアプリケーションＡＰＰの実行中、この第１のタスクＴＡから、または同じ態様で生成した他のものから、「生成」タイプの命令ＣＲＥによって他のタスクを生成することができる。また、新しく生成された任意のタスクＴＢは、スレッドＴｈｒＢ１およびタスク記述子ＴＢ、ならびにページ・メモリ構造ＰＭＳｔｒＢを含む。その親タスクからの継承関係ＩＮＨを通して、新しいページ・メモリ構造ＰＭＳｔｒＢは、存在ビットＰｒｉＢ１〜ＰｒｋＢ１を有する異なるページ・テーブル・エントリＰＴＥｉＢ１〜ＰＴＥｋＢ１も含み、これらは同じように最新の状態に維持される。

被監視タスクＴＡから新しいタスクＴＢを生成する（ＣＲＥ）際に、新しいタスク記述子ＴＤＢは管理ビットＭｍＢも含む。その値は、親タスクからの管理ビットＭｍＡのものから継承される（ＩＮＨ）。

管理されたアプリケーションＡＰＰの実行中に、最初は単一のスレッドＴｈｒＢ１を有するプロセスの形態で機能したタスクＴＢ内で、他のスレッドを生成することができる。

既存の被監視タスクＴＢ内で、「クローン」命令等のシステム・コールによって、任意の新しいスレッドＴｈｒＢ２を生成する。通常、マルチスレッド・プロセスの形態のタスクは、そのページ構造ＰＭＳｔｒＢ内に、１組のみのエントリ・テーブルＰＴＥｉＢ１〜ＰＴＥｋＢ１を含む。本発明によれば、「クローン」システム・コール等の、新しいスレッドを生成可能な任意のシステム・ルーチンの機能は、例えば、その内部に補足的な部分ＣＳＵＰを統合することによって変更される。この変更では、既存のタスクＴＢにおける新しいスレッドＴｈｒＢ２の生成が、既存の１組のテーブルＰＴＥｉＢ１〜ＰＴＥｋＢ１を読み取ること（２２）および新しい１組のページ・テーブル・エントリＰＴＥｉＢ２〜ＰＴＥｋＢ２を生成すること（２３）を含み、これらが同じ共有ページＳｈＭＰＩ〜ＳｈＭＰｋに対応して、特に新しいスレッドＴｈｒＢ２と共に機能するように設計されている。この変更は、例えば、これらのルーチンＣＬＯＮＥの装備化によって、特許文献４に記載されているように、システム内の共有ライブラリのロードによる動的介入の技法を用いて実行可能である。

この生成は、新しいテーブルＰＴＥｉＢ２〜ＰＴＥｋＢ２がそれらの親テーブルＰＴＥｉＢ１〜ＰＴＥｋＢ１と同様の態様で最新に維持される（２４、２５）ことを保証するように実行される。そのため、この更新を管理するシステム・ルーチンＭＡＰ内にそれらを更新のために登録するか、または例えばそれらに補足的な部分ＭＳＵＰを統合することによってこれらのシステム・ルーチンＭＡＰを装備化する。

図８は、２つのプロセッサμＰｒｏＸおよびμＰｒｏＹにおいて並列に実行される２つの単一スレッド・タスクＴＡおよびＴＢを含む一例にこの構造を適用した、アクセス管理の機能を示す。ページ・テーブル・エントリＰＴＥの構造を各タスク内でクローンした各スレッドＴｈｒＢ２に拡張することは、単一スレッドであれマルチスレッドであれ、被監視タスクに属する全スレッドから来る任意のアクセスも同じ態様で管理可能とすることに留意すべきである。

ここに述べた実施形態において、本発明によるアクセス管理は、各タスク（プロセスＴＡまたはＴＢという意味および各スレッドＴｈｒＢ１またはＴｈｒＢ２という意味）に対し、共有メモリ・ページに対するアクセスを保証するように構成される。このアクセスは、活動期間の全期間にわたって排他的であり、その間にそれらのコヒーレンス（または一貫性）が、システム・ソフトウェアによって保証される。かかる期間は、ここでは活動期間として記載し、システム・ソフトウェアのスケジューラＳＣＨによって割り当てられ管理される。他のタイプのコヒーレンス期間を同じ精神で選択可能であることは明らかである。

また、アクセスが管理または制御される共有リソースは、ここでは共有メモリの形態で記載し、特定のメモリ・ゾーンとして、またはメモリ・ページとして定義した。同じ概念を、それに対応するシステム・ルーチンを同様に構成することによって他のタイプのリソースに適用することも可能である。

本発明の実装は、システム・ソフトウェアのいくつかの要素を、以下に記載するとおりに機能するように変更することを含む場合がある。もちろん、必要な変更レベルは、システム・ソフトウェアのタイプまたはバージョンに依存して様々となり得る。Ｌｉｎｕｘタイプのシステムの場合には、これらの変更は一般に、前述のような「クローン」または「マップ」タイプのルーチンの装備化を含み、更に、スケジューラＳＣＨ、ページ不在ハンドラＰＦＨおよびページ・ローダＰＬを生成するエージェント内の変更およびコード追加を含む。ここで述べたアクセス制御タイプを生成するために変更されるシステム機能は、標準的なシステムの機能と比べて完全な拡張となるという利点を有することができる。すなわち、機能を排除することがなく、または少なくとも、標準的なシステム・バージョンのために開発されたアプリケーションとの上位互換性を損なうことがない。

更に、仮想メモリ管理のためのプロセッサ内に想定されるハードウェア機構を用いるが、記載したアクセス制御は必ずしもこの仮想メモリの非活動化を必要とせず、これと両立することができる。例えば、仮想ページＳｈＭＰｉの物理メモリＲＡＭｈへのロードは、このページがすでに別のタスクＴＡによって用いられている場合には、被監視タスクＴＢによってこのページの存在ビットＰｒｉＢに反映されないように、ページ・ローダＰＬを構成または変更することができる。

図８に示すように、その活動期間ＳｃｈＡの１つの開始時に、タスクＴＡは時点ＳＣＨＡＬにおいてスケジューラＳＣＨによって解放される。このタスクを解放する前に、スケジューラＳＣＨは、このタスクＴＡの管理ビットＭｍＡをテストして（３１）、それにアクセス制御を適用しなければならないか否かを確かめる。これが当てはまる場合、スケジューラＳＣＨは次いで、このアクセス制御に関する全ての共有ページに対応するページ・テーブル・エントリＰＴＥｉＡ〜ＰＴＥｋＡの全ての存在ビットＰｒｉＡ〜ＰｒｋＡを０にセットし（３２）、このタスクＴＡによる任意のアクセス要求が、デフォルトで、このタスクＴＡを実行することができる全てのプロセッサμＰｒｏＸの中断機構ＰＦＩｎｔＸにおいてページ・エラーを引き起こすようにする。

プロセッサμＰｒｏＸ内のこの活動期間ＳｃｈＡの間、命令ＩｎｓｔｒＡは、共有メモリ・ページＳｃｈＭＰｉに対するアクセスを要求する（３３）。対応する存在ビットＰｒｉＡがゼロであるので、プロセッサμＰｒｏＸの中断機構ＰＦＩｎｔＸは、このアクセス要求の実行を停止し、システム・ソフトウェアのページ不在ハンドラＰＦＨをコールすると同時に、問題となっているページおよびタスクの識別をそれに送信する。

このエラーを処理する場合、ページ不在ハンドラＰＦＨの補足的機能ＰＦＨＳＵＰは、システム・ソフトウェアの仮想メモリ・マネージャＴＭＭ内のカーネル・メモリ構造ＫＭＳｔｒ（「カーネル・メモリ構造」）エージェントを形成するデータ・テーブル内のテストまたは変更あるいはその両方を実行する。

通常、このカーネル・メモリ構造ＫＭＳｔｒは、作業環境の全てまたは作業メモリの全てのための明白な態様で、メモリ・リソースの構造およびそれらの形成を表すデータをストアする。本発明によれば、このカーネル・メモリ構造ＫＭＳｔｒは、１組のデータ・ビットも含む。これらのビットは、ここではアクセス・ビットＫＳｉ、ＫＳｊおよびＫＳｋと称し、問題となっている共有ページＳｈＭＰｉ〜ＳｈＭＰｋの各々ごとに、このページに対するアクセスがタスクに対し現に付与されている（ビットが１）か、または付与されていない（ビットが０）という事実を表す。

ページ不在ハンドラＰＦＨが、プロセッサμＰｒｏＸによって送信されたエラーを処理する場合、これは、問題となっているＳｈＭＰｉページに対応するアクセス・ビットＫＳｉを調べる（３４）。このアクセス・ビットが任意の現行アクセスを示さない場合、このページに対するアクセスを付与したことをストアするために、このアクセス・ビットＫＳｉを変更し（３４）、更に、このタスクＴＡが今は問題となっているページＳｈＭＰＰｉに対する排他的なアクセスを有するという事実をストアするために、要求側のタスクＴＡに対応する存在ビットＰｒｉＡを変更する（ビットを１に変更する）（３５）。

カーネル・メモリ構造ＫＭＳｔｒのアクセス・ビットＫＳｉのこれらのテストおよび変更動作は、アトミックな態様で実装される動作（３４）を構成することに留意すべきである。すなわち、これは、マルチプロセッサ環境においても、完全に達成されるかまたは全く達成されないことが保証される。

一旦ページ不在ハンドラＰＦＩｎｔが要求されたページＳｈＭＰｉ上の排他性を帰属させると、命令ＩｎｓｔｒＡの実行を再起動して、このページの内容に実際にアクセスする（３６）。

この後、別のプロセッサμＰｒｏＹによって並列に実行される別の被監視タスクＴＢからの命令ＩｎｓｔｒＢが、このすでに帰属されたページＳｈＭＰｉに対するアクセスを要求すると（３７）、このプロセッサの中断機構ＰＦＩｎｔＹは、要求側タスクＴＢ用のこのページの存在ビットＰｒｉＢを調べる。タスクＴＢは被監視タスクであるので、調べられる存在ビットＰｒｉＢは不在位置にある（値は０である）。従って、中断機構ＰＦＩｎｔＹは要求側命令ＩｎｓｔｒＢを停止し、ページ不在ハンドラＰＦＨにエラーを送信する（３８）。

この時点で、このページ不在ハンドラＰＦＨは、このページのアクセス・ビットＫＳｉが１であることに注目し、すでにこのページＳｈＭＰｉ上の排他性が別のタスクに付与されていることを示す。従って、ページ不在ハンドラＰＦＨは、例えばシステム・ソフトウェア・コンテキスト変更マネージャ内でその活動期間を終了することによって、要求側タスクＴＢの全体の停止を開始する（３９）。従って、その次の活動期間の間、このタスクＴＢは、これが中断された箇所までその実行を繰り返し、もう一度この同じページＳｈＭＰｉにアクセスを試みることができる。

要求側タスクがマルチスレッド・プロセスに属するスレッドＴｈｒＢ２（図７）である場合、この単一のスレッドＴｈｒＢ２に固有の１組のページ・テーブル・エントリＰＴＥｉＢ２の存在によって、すでに排他的アクセスに割り当てられたページに対するアクセスを要求するスレッドのみを停止することができ、この排他性と衝突しない他のスレッドＴｈｒＢ１については停止しない。

各タスクの活動期間ＳｃｈＡの完了時に（ＳＣＨＡＳ）、スケジューラは、このタスクの実行を停止し、その実行コンテキストをバックアップする。

この停止時（ＳＣＨＡＳ）またはすでに割り当てたページ要求の停止（３９）の際に、本発明は、このタスクが排他的アクセスを受けた全ての共有メモリ・ページのための解放段階を想定する。従って、スケジューラＳＣＨが、管理ビットＭｍＡによって、停止中のタスクＴＡが監視されることに注目する（３０１）場合、このタスクの全てのページ・テーブル・エントリＰＴＥｉＡ〜ＰＴＥｋＡをスキャンして、異なる存在ビットＰｒｉＡ〜ＰｒｋＡの状態を調べることによって、どのページ上で排他的アクセスを有するかを確かめる。次いで、この情報に基づいて、カーネル・メモリ構造ＫＭＳｔｒにおいてそれらのアクセス・ビットＫＳｉを０にリセットすることによって、全てのこれらのページＳｈＭＰｉを解放する。

他の図示しない変形において、例えば単一のタスク記述子内にいくつかの管理ビットを想定することによって、管理または監視の概念をいくつかのタイプの管理に分離することもできる。従って、あるカテゴリのタスクに関しては、排他的アクセスから利益を得るようにタスクを監視することができる。同様に、あるカテゴリのタスクによってのみタスクを排除することも可能である。

このため、すでに割り当てたページにアクセスしようとする全てのタスクを停止することで、このページの排他性は、これを要求する第１のタスクのために得ることができ、しかも、このように停止した他のタスクの実行のコヒーレンスは損なわれない。

同時に実行されている２つのタスクによって共有される単一メモリ・ゾーンの任意の変更を回避することで、このメモリ・ゾーンの内容が変化する際のそれらの間の干渉を回避する。このメモリ・ゾーンにアクセスするタスクの各活動期間の開始時における、当該メモリ・ゾーンの所与の初期状態からの、その内容の変化は、この活動期間中のこのタスクのアクションにのみ依存する。例えば、スケジューリングされた活動期間のような、このタスクが実行する所与の命令シーケンスについては、既知の初期状態から開始することで、このタスクに関して決定的かつ反復可能なこのシーケンスの実行を行うことができる。

特に、アクセスされたメモリ・ゾーンに対する排他性の割り当てをストアするためにアトミックな動作を用いるので、この方法は、競合してアクセスしようとする複数のタスク間で共有される単一のリソースのデッドロックのリスクを回避または軽減することができる。

共有メモリ・ページＳｈＭＰｉに対するこの期間の残りの間の排他的アクセスを、アクセスしているタスクＴＡに帰属させる際に、ページ不在ハンドラＰＦＨ、ＰＦＨＳＵＰは、この帰属を表すロギング・データを用意することができると好都合である。このロギング・データは、この排他的アクセスが帰属されたタスクＴＡの識別を含み、更に、場合によっては、問題となっているタスクＴＡのコンテキストに適用されるかまたはタスクＴＡの実行における要求側命令ＩｎｓｔｒＡの位置を表す他の補足的データおよび取得した排他的アクセスの持続時間においてこのタスクＴＡが実行する命令数を含む。

システム・ソフトウェア内で、このロギング・データをアクセス・ログにおいてグループ化して、ある期間または実行中に帰属された連続的な排他的アクセスを表すことができる。このログは、具体的には、１組の順序付けられたデータを含み、例えばそれらのＰＩＤまたはＴＩＤによって、これらの排他的アクセスを取得した連続的なタスクを識別する。従って、被監視タスクがアクセスした各リソースは、その専有に係りかつこのリソースに対する排他的アクセスを取得した連続的なタスクをグループ化するログを確立することができる。

これらのアクセス制御技法（図７および図８）を、前述の決定的期間をロギングするための技法（図１〜図５）、ならびに、前掲の特許文献に記載されたチェックポイントおよびロギングおよび再生技法と組み合わせることによって、本発明は、並列アーキテクチャ・システムにおいて、前述の異なるタイプの機能管理を実装することも提案する。

従って、図９は、本発明による、マルチプロセッサ・システムＭＰ１におけるマルチタスク・アプリケーションＡＰＰＪのロギングおよび単一プロセッサ・システムＵＰ２において必要とされるその再生を示す。

ログされたアプリケーションＡＰＰＪについて、ロギング・エージェントＪＳＣＨは、各プロセッサμＰｒｏＸまたはμＰｒｏＹごとに、異なる被監視タスクＴＡ、ＴＢおよびＴＣの全ての連続的な活動期間をログする。前述のように、これは、それぞれキューＱＪμＰｒｏＸおよびＱＪμＰｒｏＹとしてそれらを別個に送信する。タスクを一旦あるプロセッサにおいて実行し、一旦別のプロセッサにおいて実行する場合、このタスクの活動期間は２つのキューに存在することに留意すべきである。

ログされたアプリケーションＡＰＰＪがアクセスする共有リソースＳｈＭＰｉ〜ＳｈＭＰｋについて、ロギング・エージェントＪＶＭＭは、これらの各リソースごとに、このリソース上に割り当てられた連続的な排他的アクセスを表すロギング・データを記録する。この排他的アクセス・ロギング・データは、仮想メモリ・マネージャＶＭＭ内において、ページ不在ハンドラＰＦＨによって、異なるタスクに割り当てる排他的アクセスと共に発生される。

このアクセス・ロギング・データの各記録は、特に、以下を含む。
−問題となっている共有リソースの一義的な識別子。例えば、共有メモリ・ゾーンのためのアドレス
−このアクセスを取得したタスクのための識別子（ＰＩＤまたはＴＩＰ）
−例えば、ここに述べたカウント技法によって取得した、この排他的アクセスの持続時間
−このカウントの不正確さを補償することを可能とする補足的データ。例えば、前述のような署名
−例えば、システム・リソースおよび異なる外部または入出力イベントの仮想化のために有用な何らかの補足的データ。

このロギング・データは、ＦＩＦＯタイプのロギング・キューＱＪＳｈＭＰｉに送信される。

実施形態に応じて、これらのキューＱＪμＰｒｏＸ、ＱＪμＰｒｏＹ、ＱＪμＭＰｉの内容を、例えば後に用いるために、１つ以上のログ・ファイルにストアすることができる。

これらのキューから、コンピュータ通信ネットワーク等の通信手段によって、異なるロギング・データを再生システムＵＰ２に送信する。

各ロギング・キューＱＪμＰｒｏＸ、ＱＪμＰｒｏＹ、ＱＪμＭＰｉからのデータは、発行キューに対応する再生キューＱＲμＰｒｏＸ、ＱＲμＰｒｏＹ、ＱＲμＭＰｉによってそれぞれ受信される。

これらの再生キューの出力において、アクセス・ロギング・データに従って、異なるログされたプロセッサμＰｒｏＸおよびμＰｒｏＹのロギング・データを組み合わせて、ログされた活動期間および割り当てられた（連続的な）排他的アクセスを組み合わせたシリアル化を復元する。

再生システム内では、この再生シリアル化を定義した後に、または再生スケジューリングの後に、再生プロセッサにおいて再生の実行を起動する。

この再生シリアル化のスケジューリングを妨害しない態様でこれらのプロセッサ間にタスクを分散させると、再生の際の性能を除いて、再生プロセッサの数は重要でないことに留意すべきである。

従って、マルチプロセッサ・システムＭＰ１におけるログされたアプリケーションＡＰＰＪから、そのアプリケーションの異なるタスクＴＡ、ＴＢおよびＴＣの決定的期間の再生を、再生マシンＵＰ２において再生タスクＴＡ’、ＴＢ’およびＴＣ’の形態で行うことができる。決定的期間のこの再生を、非決定的イベントおよび特に外部イベントのロギングおよび再生と組み合わせることで、本発明は、ログされたアプリケーションＡＰＰＪの実行を再現する再生アプリケーションＡＰＰＪを、高性能で得ることができる。

発生されるとすぐに（オン・ザ・フロー）ログされたシステムから再生システムにロギング・データを送信することによって、ログされたアプリケーションと全く同じ態様で動作し、単に時間遅延があるだけの、追従型または「シャドー」再生アプリケーションを生成することができる。この種の状況では、「アクティブ−アクティブ」構成という用語を用いることができる。この構成では、双方のアプリケーションが実行中であり、例えば、将来のプロビジョンとしてアプリケーションの状態をストアする技法とは対照的である。

かかる「アクティブ−アクティブ」構成では、再生アプリケーションＡＰＰＲが、マスタまたは１次アプリケーションのアクティブなレプリカとなると考えることができる。このアクティブなレプリカは、２つのシステムの比較性能等の要因に依存し得るわずかな時間遅延を生じ、これに対して、ロギング・データの送信および処理の時間が主に追加される。典型的な遅延は、少数のスケジューリング期間であり、一般には数ミリ秒である。

まず考えられることとして、ここに述べた技法は、オリジナルのまたはレガシー・アプリケーションに比べて小さいオーバーヘッドのみを生じ、活用状況においておそらく許容可能な種類の性能損失のみを生じる機能管理の実装を可能とする。

本発明は、好都合なことに、このタイプの「アクティブ−アクティブ」構成を、アプリケーション高信頼性化の実装に適用することができる。その場合、アクティブなレプリカは、オリジナルのミラー・アプリケーションとして用い、故障またはある特定のイベントの場合にそれを引き継ぐことができる。ミラー・システムのハードウェア実装に比べて、本発明は、用いる機械のハードウェア特性からの独立性が向上しているため、機能およびハードウェア管理においてはるかに柔軟性を高めることができる。

従って、かかる構成によって、柔軟かつ非侵入的な態様で、既存のアプリケーションに故障許容機能を導入することができ、同時に、並列アーキテクチャにおいても、性能損失を抑えることができる。

また、サービスの全てまたは一部をログされたアプリケーションからアクティブなレプリカへと再分配することによって、作業負荷の平衡化または調整（「ロード・バランシング」）のために、かかる「アクティブ−アクティブ」構成を用いる場合にも、これらの利点は存在する。これによって、例えば、ハードウェアの使用を最適化することができ、または、再配置可能（relocative）な保守を実装するためにその一部を解放することができる。

ここで述べた異なる機構は、ハードウェア部分とは切り離してソフトウェア部分を用いることに留意すべきである。そのため、ハードウェアに関して良好な独立性が得られ、これは特に、実装を簡単にし、高信頼性化し、これらがプロセッサまたはコンピュータである場合、アーキテクチャが異なる計算要素の並列処理を最良に管理することを可能とすることで、良好な性能を維持する。

更に、本発明は多くの場合、純粋にソフトウェア実装であるので、全ての利点を含みながら、標準的なハードウェアを用いることができる。

本発明は、特に、単一の計算要素において共有時間で機能するマルチタスク・アプリケーションのために開発された機能管理技法を、並列環境に拡張することができる。従って、本発明は、かかる並列環境を、ミドルウェア・タイプのアプリケーション内でこの機能管理を実装するネットワークまたはクラスタに統合することができ、例えば、「オン・デマンド」サービスを提供する分散型アプリケーションまたは可変配置（variable deployment）アプリケーションを管理することを可能とする。

明らかに、本発明は記載してきた例に限定されるものではなく、本発明の枠組みから逸脱することなく、多くの修正を行うことができる。

本発明に従って、プロセッサにおいてタスクをカウントすることによってタスクの実行のスケジューリングをロギングすることを示す図である。 本発明に従って、プロセッサにおいてタスクをカウントすることによってタスクの実行のスケジューリングをロギングすることを示す図である。 本発明に従って、プロセッサにおいて命令をカウントすることによってタスクの活動期間を再生することを示す図である。 本発明に従って、プロセッサにおいて命令をカウントすることによってタスクの活動期間を再生することを示す図である。 本発明に従って、プロセッサにおけるタスク・スケジューリングの、命令をカウントすることによるロギングから得られた、マルチタスク・アプリケーションの単一プロセッサ・システムにおける決定的再生を示す図である。 従来技術に従った、単一環境からの２つの異なるプロセッサによって並列に実行される２つのタスク間で共有されるメモリに対するアクセスの機能を示す図である。 本発明に従った、単一環境からのいくつかの異なるプロセッサ上で並列に実行される多数のタスク間で共有されるメモリ・ページに対するアクセスの制御を可能とする構造の、タスク内での生成および保守を示す図である。 本発明に従った、単一環境からの２つの異なるプロセッサ上で並列に実行される２つのタスクが共有するメモリ・ページに対するアクセスの制御の機能を示す図である。 本発明に従った、マルチプロセッサ・コンピュータ上でのマルチタスク・アプリケーションのロギングおよび単一プロセッサ機械上でのそのオン・ザ・フロー再生を示す図である。

Claims (7)

1. コンピュータ・システムにおいて、性能を監視または推定する手段を備えたプロセッサ内で、２つの非決定的動作の間の連続的な決定的動作から成る、活動期間（ＳｃｈＪ、ＳｃｈＲ）と称する所与の実行期間中に、ターゲットと称するコンピュータ・タスクを管理するための方法であって、前記手段は、相対エラーと称する＋または−の所与の可能なエラーを有するカウンタ（ＰＭＣ）を含み、
   前記カウンタを用いて、前記活動期間の少なくとも１つの所与の時点まで、実行された命令の数（ＮＲ、ＮＪ）を評価するステップと、
   前記プロセッサまたは前記コンピュータ・システムの状態から読み取られたかまたは計算された、前記活動期間の少なくとも１つの所与の時点に対応する、署名（ＳＧＪ、ＳＧＲ）と称するデータを生成するステップを含み、
   前記方法が、順序付けられた態様で、プロセッサ・ログ（ＪμＰｒｏＸ）と称する少なくとも１つのファイル内に、ログされたプロセッサと称するプロセッサ（μＰｒｏＸ）において実行される複数のタスク（ＴＡ、ＴＢ、ＴＡ）の連続的な活動期間（Ｓｃｈ１、Ｓｃｈ２、Ｓｃｈ３）のロギングを表すロギング・データをストアすることによって、前記ログされたプロセッサ（μＰｒｏＸ）の使用をログし、前記ロギング・データが、前記実行されたタスク（ＴＪ）を識別するデータ（ｉｄＪ）をこれらの各期間ごとに含み、
   前記方法が、前記ログされた期間（ＳｃｈＪ）の開始時における前記ログされたプロセッサの状態または前記ログされたシステムの状態に対応する状態から開始して、再生コンピュータ・システム（ＵＰ２）内で、再生プロセッサ（μＰｒｏＺ）と称するプロセッサによって実行される、再生タスク（ＴＲ）と称するタスクを管理することによって、前記ログされた期間（ＳｃｈＪ）の再生を、前記ロギング・データから実行し、
   前記方法が、前記再生タスク（ＴＲ）の実行の監視段階と確認段階とをさらに含み、
   前記監視段階が、
   前記カウンタ（ＰＭＣ）によって評価された前記ログされた期間の命令数（ＮＲ）を前記カウンタの前記相対エラーだけ減少させた、前記ログされた期間の命令数の推定値（ＮＪ）に等しいかまたはこれより少ない数の命令を前記再生の期間の開始から実行し、
   前記確認段階が、
   前記再生における所与の時点（ＴＲＩ０、ＴＲＩ２、ＴＲＩ４）において、前記再生タスクの実行を中断するステップ（４６）と、
   前記ログされた署名（ＳＧＪ）と前記再生中断時点に対応する署名（ＳＧＲ）との間の比較テストを行うステップ（４７）との繰り返しからなり、
   前記ログされた署名（ＳＧＪ）が、ログ・ポインタ（ＩＰＪ）と称するデータを含み、これが前記ログされた期間（ＳｃｈＪ）の終了時における前記ログされたタスクの命令ポインタ（ＩＰＪＸ３）の値を表す、方法。
2. 前記ログされたポインタ・データ（ＩＰＪ）に対応する再生命令（ＢＫＩ）上にブレークポイント（ＢＫ）を設定するステップ（４２）も含む、請求項１記載の方法。
3. 前記監視段階が、前記カウンタ（ＰＭＣ）のオーバーフローを含み、このカウンタが、前記再生期間の開始から実行しなければならない命令数（ＮＲ）を決定するために事前に初期化され、そのオーバーフローによって前記再生タスクの中断（４１）を生じさせる、請求項１記載の方法。
4. 前記カウンタのオーバーフローとこれを生じさせたタスクの中断との間にレイテンシ期間が存在する場合に充分に早期にオーバーフロー（４１）を起こすため、前記再生タスク（ＴＲ）によって実行される命令数（ＮＲ）が、前記ログされた期間の前記命令数の推定値（ＮＪ）に等しいかまたはこれより少ない数となるように、前記カウンタ（ＰＭＣ）を、一定のマージンをもって前記再生期間の開始時において初期化する、請求項３記載の方法。
5. 前記確認段階は、前記再生タスク（ＴＲ）によって実行される命令数（ＮＲ）が、前記ログされた期間の命令数（ＮＲ）を所与の命令数だけ増大させた推定値（ＮＪ）を超えた場合に、エラーを信号で知らせるセキュリティ・ステップを含む、請求項１記載の方法。
6. 前記ログされたプロセッサ（μＰｒｏＸ）においてログされた連続的な活動期間（Ｓｃｈ１、Ｓｃｈ２、Ｓｃｈ３）の１組の順序付けられたロギング・データを用いることによって、前記再生プロセッサ（μＰｒｏＺ）において、前記ログされたプロセッサの使用の再生を実行する、請求項１記載の方法。
7. 複数のログされたタスクによってアクセスされる、ターゲット・リソース（ＳｈＭＰｉ）と称する共有リソースに関連する連続的な帰属された排他的アクセスのロギングを実行し、前記方法が、これらの排他的アクセスを取得した前記連続的なタスクの少なくとも１つの識別を含む、リソース・ログ（ＪＳｈｍＰｉ）と称する少なくとも１つのファイルの送信またはストアも行う、請求項１記載の方法。

Images