(57)【特許請求の範囲】
【請求項１】
少なくとも２つのアプリケーション・タスク（ＴＡ、ＴＢ）の機能を管理する方法であって、前記方法は、少なくとも２つの演算ユニット（μＰｒｏＸ、μＰｒｏＹ）において複数のアプリケーション・タスクを同時に実行することのできる複数の計算手段を備えた並列構造のコンピュータ・システムにおいて前記少なくとも２つのアプリケーション・タスク（ＴＡ、ＴＢ）の実行を順次活動化によって管理するシステム・ソフトウェア内に実装され、前記少なくとも２つのアプリケーション・タスク（ＴＡ、ＴＢ）は少なくとも１つの共有リソース（ＳｈＭＰｉ）にアクセスし、
前記方法は、
第１の演算ユニット（μＰｒｏＸ）における前記少なくとも２つのアプリケーション・タスクのうちのいずれか一つ又は複数のアプリケーション・タスクの第１の継続する活動期間をロギングするステップと、
第２の演算ユニット（μＰｒｏＹ）における前記少なくとも２つのアプリケーション・タスクのうちのいずれか一つ又は複数のアプリケーション・タスクの第２の継続する活動期間をロギングするステップと、
前記少なくとも１つの共有リソースへのアクセス要求（ＩｎｓｔｒＡ）に応じて、前記少なくとも２つのアプリケーション・タスクのうちのアクセス元アプリケーション・タスクに対して前記少なくとも１つの共有リソースのうちのターゲット・リソース（ＳｈＭＰｉ）への排他的アクセスの一連の帰属をロギングするステップであって、前記排他的アクセスの一連の帰属をロギングすることが、前記アクセス要求の直後から前記アクセス元タスクの活動期間（ＳｃｈＡ）の残りの全期間を通して、前記タスクのうちの別のタスクによる前記ターゲット・リソース（ＳｈＭＰｉ）へのアクセスを全て排除するような帰属をロギングすることである、前記ロギングするステップと
を含み、
前記方法は、さらに、再生シリアライゼーションという順序付き構造において、演算ユニットのそれぞれにおける一連の活動期間を表すロギング・データと一連の帰属した排他的アクセスを表すロギング・データとを組み合わせることを含み、それにより各アプリケーション・タスク内で前記少なくとも１つの共有リソースに対する一連の活動期間の順序を保つ、
前記方法。
【請求項２】
再生シリアライゼーション・データが、ログされたアプリケーション・タスクのログされた実行を再生するために再生コンピュータ・システムにおいて使用される、請求項１に記載の方法。
【請求項３】
コンピュータ・ネットワーク内の少なくとも１つのノードにおいて実装される、請求項１又は２に記載の方法。
【請求項４】
請求項１〜３のいずれか一項に記載の方法を実行するコンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータまたはコンピュータのネットワーク上で実行されるマルチタスク・アプリケーションにおける１つ以上のソフトウェア・タスクの実行に対する管理の方法に関し、特に、外部からのトランスペアレントな非干渉型制御による管理の方法に関する。この管理には、具体的には、ロギング・データの形でこれらのタスクの実行を記録すること、ならびにロギングの間に得られた動作および結果に対応する動作および結果を提供するために、前述のロギング・データを基に上記実行を再生することが含まれる。
【０００２】
本発明は、さらに、システムが実行するソフトウェア・アプリケーションの機能の管理において前述のような方法を実装する該システムに関する。
【背景技術】
【０００３】
管理されるアプリケーションに関して非侵入的かつ透明な機能管理を実装することは、極めて有用である。これによって、特に、オリジナルの状態にある多くの既存のアプリケーション（「レガシー・アプリケーション」）を、一層柔軟に、信頼性高く、または高性能で使用可能とすることができる。
【０００４】
中間捕獲を行い、同期点または再開始点（「チェックポイント」）でアプリケーションの状態を復元することによる非侵入的な機能管理技法は、本出願人によって既に仏国特許出願第０４０７１８０号明細書の中で提示されている。補足的に、非侵入的なロギングおよび再生技法が、本出願人によって仏国特許出願第０５００６０５号明細書から仏国特許出願第０５００６１３号明細書においてすでに提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】仏国特許出願第０４０７１８０号明細書
【特許文献２】仏国特許出願第０５００６０５号明細書
【特許文献３】仏国特許出願第０５００６０６号明細書
【特許文献４】仏国特許出願第０５００６０７号明細書
【特許文献５】仏国特許出願第０５００６０８号明細書
【特許文献６】仏国特許出願第０５００６０９号明細書
【特許文献７】仏国特許出願第０５００６１０号明細書
【特許文献８】仏国特許出願第０５００６１１号明細書
【特許文献９】仏国特許出願第０５００６１２号明細書
【特許文献１０】仏国特許出願第０５００６１３号明細書
【特許文献１１】仏国特許第２８２０２２１号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、１つ以上のイベントのロギングは、ログされたアプリケーションまたはこれを実行するシステムにとって作業オーバーヘッドとなり、これをできる限り小さくすることには極めて関心が高い。
【０００７】
アプリケーションの実行を構成するイベントの中で、アプリケーションの状態に対して非決定的な挙動を有するものは、後の再生の間にそれらの結果を強制または再注入することができるように、それらの結果をロギング・データにストアしなければならない。従って、目的とすることは、非決定的として処理しなければならないイベントの数をできる限り減らすことである。
【０００８】
アプリケーションの外部イベント、またはこれを実行しているシステムの外部イベントは、本質的に非決定的な挙動を有することが多く、一般に、例えば前掲の特許文献に記載されているようにストアしなければならない。
【０００９】
実行の一部からの全てのイベントが決定的である場合、この部分は全て、例えば再開始点の形態で単にアプリケーションの開始状態をストアすることによって、経済的にログすることができる。そして、再生を行うには、例えば、アプリケーションをストアの際の再開始点状態に復元し、これらの決定的イベントの実行を起動する。その場合、決定的イベントのみから成る決定的部分のグループを含む「区分的に決定的な実行モデル」という用語を用いることができる。従って、一般に、決定的部分の境界は、非決定的イベントによって構成される。例えば、その開始時には外部メッセージが到着し、その終了時には別の非決定的イベントが起こる。
【００１０】
本発明の１つの目的は、かかる決定的部分のロギングおよび再生を簡略化または最適化することである。
【００１１】
上記に引用した文書の中には、（ヒューリスティック圧縮または予測圧縮により）記憶装置の計算コストの低減が可能となる技術を記述しているものがある。さらに、非決定論的になりえる特定のシステム・コール・ルーチンをインストルメントすることによってそれらの動作を決定論的にすることを提案している文書もある。
【００１２】
しかし、最も多数を占める内部イベントの中には、非決定論的となりえる動作、または非決定性の原因となりえる動作を有しているものがあり、具体的には、共有メモリ・ゾーンまたはセマフォ若しくはミューテックスなどの共有リソースにアクセスする内部イベントである。
【００１３】
本発明の別の目的は、ロギングまたは再生あるいはその両方において非決定論的なものとして扱わなければならないイベントの数を減らすことである。
【００１４】
さらに、ある種のコンピュータ・アーキテクチャ、特に物理的にまたは実際に並列であるとみなされる並列アーキテクチャ・システムにおいては、その性質に固有の非決定論的な要因をかかえていることがある。
【００１５】
一般に、上述の並列環境は、既存のハードウェア・エレメントからはるかに大きな計算能力を得るために設計され使用されている。たいてい、これは、これを最初から考慮して設計されている技術的アプリケーションまたは科学的アプリケーションで煩わしく複雑な計算を行う場合に適用される。
【００１６】
このような環境は、複数のプロセッサを、単一のコンピュータの中に組み入れることによって形成できる。このコンピュータは、このコンピュータに求められている計算作業を上記複数のプロセッサに分配するものである。ときには、数個のコンピュータがネットワークで組み合わされ、ユーザによる干渉がほとんどない状態で特定の作業負荷を分担するように管理されることもある。
【００１７】
これらの種々の特定のエレメント、プロセッサまたはコンピュータが、後に順序付けされる別々のタスクで同時に作業することができる場合、物理的並列性という用語が用いられる。その一方で、例えばいくつかの仮想作業ゾーンにおいて単一エレメントの作業時間を共有することでシミュレートされるような並列性もある。
【００１８】
マルチプロセッサまたはマルチコンピュータのいずれかを含み物理的並列処理能力を備えている既存の環境は、たいてい最大限の総合的計算能力を得られるように設計および最適化されている。このため、できる限り分断された状態で異なるエレメントが作業し、互いの間で協調することはほとんどない。
【００１９】
例えばコストまたはフレキシビリティの理由から、単独でまたはグループとして、大型の中央コンピュータをマイクロ・コンピュータまたはワークステーションに置き換えることが頻繁に求められている。このようなマシンは、より高い能力を求めて並列に作業するマルチプロセッサ構成を取るか、または、それ自体が外部に対して単一の並列作業環境を構成するネットワーク、すなわち外部に対する単一の応答者として動作するネットワークで並列に作業するようにグループ化されてもよい。
【００２０】
したがって、単純に重たい計算アプリケーションではなく、別個のまたはより多様なアプリケーション、特に、コーポレート・マネジメント・ドメイン、またはワークステーション・ネットワーク、または通信ネットワークにおいて一般的なトランザクション式のマルチタスク・アプリケーションを実行するのに、上述のような並列環境を使用することは有利となるであろう。上述のようなアプリケーションはかなり変化に富んだ構造を有することが多く、さらに、同一の環境下で共有リソースを使用するいくつかのタスクを含むことが非常に多い。
【００２１】
しかしながら、これらのオペレーティング・システムまたはアプリケーションは単一プロセッサ・マシン向けに設計されているため、物理的並列処理の場合のように実際に同時に実行される２つのタスク間の干渉を管理するようには設計されていないことが多い。故に、同時に実行されているいくつかのタスクが１つのデータにアクセスしなければいけないとき（「競合状態」）、あるタスクによる読み取りの結果は、この読み取りの前または後に別のタスクによる変更が加えられたか否かによって大きく異なることになるだろう。
【００２２】
さらに、大部分のマルチタスク・オペレーティング・システムでは、実際の並列処理において機能する環境の管理は想定されておらず、直接アクセスにおける共有リソースの管理については、なおさら想定されていない。共有アクセスのタイプの中で直接アクセスとみなすことができるのは、例えば「ｍａｐ」形式の命令によって初期に定義される共有メモリ・ゾーンのように、アドレシングによってプログラム命令からアクセスすることができるものである。
【００２３】
いくつかのタスクがこのタイプの共有リソースに直接アクセスを介して並列にアクセスする場合、このアクセスは、一般に、システム・ソフトウェアによって管理されることはほとんどなく、「ｏｐｅｎ」、「ｒｅａｄ」または「ｗｒｉｔｅ」などのシステム・コールを用いて「ｐｉｐｅ」または「ｓｏｃｋｅｔ」形式のメッセージをパスするリソースなど、システム・コールを必要とする他の共有リソースへのアクセスとは対照的である。したがって、並列環境において直接アクセスを介した共有リソースへのアクセスを管理するのは、たいていの場合、ほぼ全面的にアプリケーションのタスクとなる。
【００２４】
そこで、本発明の別の目的は、ロギングおよび再生機能の実装を容易化または最適化すること、および並列環境において、特にマルチタスク・アプリケーションに関して、非決定論的な要因を低減することである。
【００２５】
冗長アーキテクチャにおける機能管理に関連して、本発明の別の目的は、並列環境において実行されるマルチタスク・アプリケーションの機能の信頼性を高めることである。
【課題を解決するための手段】
【００２６】
前述の技術を根幹として、本発明は、少なくとも２つのアプリケーション・タスクの機能を、コンピュータ・システムにおいて順次活動化によって上述のタスクの実行を管理しているシステム・ソフトウェア内で管理することを提示する。このコンピュータ・システムは、少なくとも２つの演算ユニットにおいて同時にいくつかのアプリケーション・タスクを実行することのできる計算手段を備えた並列構造を備えている。少なくとも１つの共有リソースにアクセスするアプリケーション・タスクのために、本方法は、一方では以下のステップを含んでいる。
−第１の演算ユニットにおけるこれらタスクのうちのいずれかのタスクの第１の継続する活動期間をロギングするステップ、および
−第２の演算ユニットにおけるこれらタスクのうちのいずれかのタスクの第２の継続する活動期間をロギングするステップ、
−および、前記ターゲット・リソースへのアクセス要求に応じて、前記タスクのうちのいわゆるアクセス元タスクに対し前記ターゲット・リソースへの排他的アクセスの一連の帰属（attribution）をロギングするステップ、すなわち、前記アクセス要求の直後から前記アクセス元タスクの活動期間の残りの全期間を通して、上記タスクのうちの別のタスクによる前記ターゲット・リソースへのアクセスを全て排除するような帰属をロギングするステップ。
【００２７】
他方では、上記方法は、再生シリアライゼーションという順序付き構造において、演算ユニットのそれぞれにおける一連の活動期間を表すロギング・データと一連の付与された排他的アクセスを表すロギング・データとを組み合わせることを含む。この組み合わせは、各タスク内で前記共有リソースに対する一連の活動期間の順序を保つように構成されている。
【００２８】
本発明によれば、再生シリアライゼーション・データを再生コンピュータ・システム内で使用して、ログされたタスクのログされた実行を再生してもよい。
【００２９】
さらに、本方法には、再生コンピュータ・システムにおいて、ロギングの間にログされるタスクからアクセスできるソフトウェア・リソースの全てまたは一部を仮想化することが含まれてもよい。
【００３０】
したがって、本発明による方法は、コンピュータ・ネットワークの少なくとも１つのノード内に実装されてもよく、コンピュータ・ネットワークの例としては、ミドルウェア形式の１つ以上の機能管理アプリケーションにより管理されるクラスタを構成するネットワークなどが挙げられる。このように、本方法は、特に命令シーケンスのロギングおよび再生によって、機能管理に関する性能および機能性の拡張または最適化を可能にする。
【００３１】
同様に、本発明は、本方法を実装するシステムも提示しており、このシステムは並列式であるかまたは並列システムを構成しかつネットワークで使用可能な１つ以上のコンピュータ・システムに適用される。
【００３２】
本発明の他の特徴および利点は、決して制限するものではない実施形態の詳細な説明および添付の図面によって明らかになるだろう。
【図面の簡単な説明】
【００３３】
【図１】本発明に従って、プロセッサにおいてタスクをカウントすることによってタスクの実行のスケジューリングをロギングすることを示す図である。
【図２】本発明に従って、プロセッサにおいてタスクをカウントすることによってタスクの実行のスケジューリングをロギングすることを示す図である。
【図３】本発明に従って、プロセッサにおいて命令をカウントすることによってタスクの活動期間を再生することを示す図である。
【図４】本発明に従って、プロセッサにおいて命令をカウントすることによってタスクの活動期間を再生することを示す図である。
【図５】本発明に従って、プロセッサにおけるタスク・スケジューリングの、命令をカウントすることによるロギングから得られた、マルチタスク・アプリケーションの単一プロセッサ・システムにおける決定的再生を示す図である。
【図６】従来技術に従った、単一環境からの２つの異なるプロセッサによって並列に実行される２つのタスク間で共有されるメモリに対するアクセスの機能を示す図である。
【図７】本発明に従った、単一環境からのいくつかの異なるプロセッサ上で並列に実行される多数のタスク間で共有されるメモリ・ページに対するアクセスの制御を可能とする構造の、タスク内での生成および保守を示す図である。
【図８】本発明に従った、単一環境からの２つの異なるプロセッサ上で並列に実行される２つのタスクが共有するメモリ・ページに対するアクセスの制御の機能を示す図である。
【図９】本発明に従った、マルチプロセッサ・コンピュータ上でのマルチタスク・アプリケーションのロギングおよび単一プロセッサ機械上でのそのオン・ザ・フロー再生を示す図である。
【発明を実施するための形態】
【００３４】
本明細書中に記載する技法は、例えばＡＭＤ（登録商標）社からのＡｔｈｌｏｎ（商標）タイプのプロセッサ、またはＩｎｔｅl（登録商標）社からのＰｅｎｔｉｕｍ（登録商標）プロセッサ等の、ＰＣタイプのコンピュータにおいて用いられるタイプのプロセッサのある特性を用いた本発明の実施形態に対応する。もちろん、例えばワークステーションにおいて用いられる他の現行プロセッサまたは将来のプロセッサも、これらの特性または同様の特性の全てまたは一部を提供することができ、本発明を実行するために使用可能である。
【００３５】
図１および図２は、単一のμＰｒｏＸプロセッサまたは演算ユニットによって連続的に実行される、決定的内部イベントの異なる部分をロギングするための技法を示す。
【００３６】
図１に示すように、異なるタスクＴＡおよびＴＢは、スケジューラＳＣＨによって連続的に起動される、活動期間Ｓｃｈ１〜Ｓｃｈ３と称する部分によって実行することができる。スケジューラＳＣＨは、コンテキスト・マネージャと称するシステム・エージェントの一部を形成し、これらの交番または交差を管理する。
【００３７】
コンピュータ・システムまたはプロセッサ内で実行される異なるタスクのうち、一部のものが、管理対象のアプリケーションの部分である場合があり、「被監視」タスクとして認められる。これらのタスクは、タスク記述子内の通常用いられないデータ・ビットの状態（１にセットされる）によって識別され、ここではこれを管理ビットＭｍＡまたはＭｍＢ（図７を参照）と称する。被監視タスクおよび監視されない他のものは、プロセッサにおいて実行される連続的な活動期間内で交番することができる。
【００３８】
図２において文字「ｍ」によって標示される被監視タスクＴＡおよびＴＢについては、それらが決定的イベントのみで構成されるように活動期間を選択する。これらの決定的期間は、１つ以上のロギング・ソフトウェア・エージェントによって定義される。このロギング・エージェントは、機能管理アプリケーションのタスクとして、コンピュータ・システムのユーザ・メモリ空間において実行される要素を含むことができる。また、このロギング・エージェントは、システム・ソフトウェア内、例えばスケジューラ内で、変更または追加された要素を含むかまたは用いることができる。
【００３９】
アプリケーションのイベントの大部分は内部イベントであり、それらの多くは決定的であるので、管理された各タスクの大部分は決定的イベントから成る。非決定的イベントが起こるたびに、ロギング・エージェントは決定的期間を終了させる。次いで、検出された非決定的イベントは、場合によっては監視されないタスクの形態で実行され、既知の方法に従ってその結果と共にログされる。この非決定的イベントが完了すると、ロギング・エージェントは新しい決定的部分の開始を定義し、再び命令のカウントを起動する。
【００４０】
非決定的イベントのロギングおよび場合によってはその処理は、決定的な活動期間の外で、例えば、カーネル・モードＫＬｖにおける実行期間Ｋ１またはＫ２で行われる。すなわちプロセッサ特権モードの値が０の間であり、これに対して、ユーザ・モードＵｌｖについての値は３である。
【００４１】
ロギングの場合と同じ態様で各活動期間を再生することを可能とするために、本発明は、ロギング時にこの決定的部分の間に実行される命令のカウントを実行する。従って、これらのタスクを後に再生ＲＳＣＨ（図３および図４を参照）する間、このログされた部分をロギングの場合と同じ状態から起動するだけで、この同じタスクについてロギング時のこの同じ部分が実行した命令の数に厳密に相当する再生命令の数までそれ自身で実行することができる。従って、この再生は、決定的部分内に結果を強制する介入なしに実行される。後者は決定的イベントのみを含むからである。
【００４２】
１つの決定的部分が、スケジューラによって確立された複数の活動期間にわたって延在する場合、これらの活動期間の各々は、この決定的部分の一部を含み、それ自体、完全な決定的部分として処理することができる。本明細書の残り部分では、決定的活動期間のロギングのみを説明するが、単一の決定的部分において多数の決定的活動期間が互いの後に続くことができることは明らかである。
【００４３】
本発明によれば、決定的活動期間の命令のこのカウントは、性能および監視カウンタを用いる。これは現在、多数のプロセッサにおける既存のハードウェア機構である。例として、Ｉｎｔｅl（登録商標）社からのＰｅｎｔｉｕｍ（登録商標）ファミリについてのＰｅｎｔｉｕｍ（登録商標）２以降が挙げられる。この性能および監視カウンタは、持続時間において、または多数のイベントにおいて、プロセッサの機能を測定するために設けられており、例えばアプリケーション・プロファイルの統計的分析を実行するため、その値の周期的サンプリングによって、性能を測定するために主に用いられる。また、プロセッサ製造業者は、これらの性能カウンタが保証された精度を持たず、アプリケーションの最適化のために相対的または差動的な測定のために用いなければならないと指定する。
【００４４】
本発明は、この性能カウンタＰＭＣの特性の１つを用いることを提案する。すなわち、引退済みと称する命令、すなわち解決したか、または実行すべき命令のリストから出た命令のカウントである。これは、性能の理由のために前もっていくつかの命令を実行させることができる様々な投機的またはキャッシュ技法とは無関係である。
【００４５】
しかしながら、引退済み命令のこのカウントには、Ｉｎｔｅl（登録商標）社およびＡＭＤ（登録商標）社からの文書において記載されている、ある制限的な特性がある。これらの特性の１つは、このカウンタのための読み取り命令（「ＲＤＰＭＣ」）が解決すべき命令に直接統合されないことである。これは、本発明と関連付けてこのカウンタを用いることに直接的な影響をもたらさない。
【００４６】
一方、２つの他の制限的な特性は、ロギングおよび再生のための命令のカウントにおいて不正確さを発生させる場合があり、考慮しなければならない。
【００４７】
不利益となる恐れのある第４の特性は、カウンタ・オーバーフローを引き起こした命令の後にいくらかの遅延を伴って、このカウンタ・オーバーフローによる実行の中断が起こる場合があるという事実である。
【００４８】
これらの不正確さによる制限は、一方では、ある複雑な命令が解決される前に中断されると２度カウントされる場合があることに関係し、他方では、ハードウェア中断を伴う命令によって命令の非カウントを生じさせる場合があることに関連する。この不正確さを克服するため、本発明は、活動期間の終了の正確な決定に関連する不確かさを排除することができる、補足的な確認技法を用いる。
【００４９】
図１に示すように、μＰｒｏＸプロセッサにおいて実行される連続的な決定的活動期間Ｓｃｈ１、Ｓｃｈ２およびＳｃｈ３は、ログ・ファイルＪμＰｒｏＸにログされかつ記録される。
【００５０】
プロセッサが被監視タスクＴＡを実行しているログされた活動期間Ｓｃｈ３の間、カウンタＰＭＣの値ＵＩＣＸの１つ以上の読み取り命令ＲＤＰＭＣは、引退済み命令の数ＮＪ３を供給する。この期間Ｓｃｈ３の停止（ｅｎｄ Ｓｃｈ３）時に、ロギング・エージェントＪＳＣＨは、タスクＴＡおよびそのコンテキストの状態によって出力される状態データの１つ以上のアイテムを用いる。これは、この活動期間Ｓｃｈ３の間に実行された正確な命令数に関して存在し得る不確かさを排除するために、充分に明白な態様でこの状態を表すデータの１つ以上のアイテムを計算するためである。この状態データは、この期間終了（ｅｎｄ Ｓｃｈ３）に対応する署名ＳＧ３を構成する。この署名は、具体的には、この期間の最後の命令の直後の命令ポインタの正確な値ＩＰＪＸ３、すなわちタスクＴＡの実行可能ファイルにおける最後に実行されたプログラム命令の位置の正確な識別を含む。また、この署名は、この停止（ｅｎｄ Ｓｃｈ３）時におけるタスクＴＡのコンテキストからのコール・スタックＰｉｌｅＪＸ３およびレジスタＲｅｇＪＸ３に読み取られた値から計算された制御データ（「チェックサム」）を含む。
【００５１】
従って、ログされた期間ＳｃｈＪ（図３）の各々について、このプロセッサのログＪμＰｒｏＸは、特に、次に関連するラインを含む。
−この期間において実行されたタスクＴＪの識別ｉｄＪ、例えばこのタスクの「ＰＩＤ」
−カウンタＰＭＣによって送信された、引退済み命令の数ＮＪの値
−この期間の終了について計算された署名ＳＧＪ
【００５２】
従って、図１に示したタスクＴＡ、次いでタスクＴＢ、次いでタスクＴＡという連続的なタスクについて、プロセッサμＰｒｏＸのログＪμＰｒｏＸは、以下の連続的なライン
を含む。
「ｉｄＡ：  ＮＪ３：  ＳＧ３
ｉｄＢ：  ＮＪ２：  ＳＧ２
ｉｄＡ：  ＮＪ１：  ＳＧ１」
【００５３】
図２に示すように、所与のμＰｒｏＸプロセッサ内のログされたアプリケーションＡＰＰＪについてログされた連続的な異なるタスクは、最初に、ロギング・エージェントＪＳＣＨによって、ＦＩＦＯ（「先入れ先出し」）タイプのロギング・キューＱＪμＰｒｏｘに送信することができる。このキューの出力におけるロギング・ラインは、ログ・ストア・タスクＴＪμＰｒｏｘによって読み取られる。このタスクは、これらのラインを順序付けられた態様でこのプロセッサのログＪμＰｒｏｘにストアすることを開始する。このストアは、ローカルに（ＭＥＭ）、または別のノードまたはバックアップ・ステーションまたは周辺装置に送信（ＴＲＡＮＳ）することによって行われる。かかるロギング・キューの使用は、特にバッファ・ゾーンとして機能して、ロギング・データのフローを規制すると共に、ログされたアプリケーションまたはこのロギングを実行しているアプリケーションを妨害することを回避する。
【００５４】
この利点は、特に、グローバル・アーキテクチャの場合に評価することができる。この場合、ロギング・データは、発生したときにオン・ザ・フローで（on-the-flow）、例えばスタンバイ機械上で同じ実行を再生している別のアプリケーションに送信されて、故障許容およびサービス継続を有する機能を実行する。
【００５５】
このカウント技法において、命令のカウントのための同期点としてシステム・コール命令を用いることが有利である場合がある。従って、これは、システム・コール・ルーチンがシステム・コール・カウンタを増分するように、これらのシステム・コール・ルーチンを装備化する（instrument）ことを伴う。従って、ハードウェア・カウンタＰＭＣによる命令のカウントは、低いままに留まる値を処理することができ、これによって性能が改善する。
【００５６】
図３および図４は、ログされた期間ＳｃｈＪの再生プロセッサμＰｒｏＺにおける再生技法を示す。図３は、このプロセッサにおける再生タスクＴＲの最新状態ＴＲ１〜ＴＲ４を表す。図４は、かかる再生を実装するために用いる方法のフロー図を表す。実施形態または使用パラメータに依存して、再生はロギングと同じプロセッサにおいて行うことができ、例えば、異なる再生プロセッサと同じ原理に従って、アプリケーション追跡タイプの機能管理を行う。
【００５７】
かかる再生の間、例えば、再生エージェントＲＳＣＨを含むように変更されている場合があるスケジューラＳＣＨによってスケジューリングした活動期間として、問題となっているタスクＴＪは、前述のプロセッサにおけるそのコンテキストを復元され、次いでこのタスクは解放され（４１）、その実行が起動される。
【００５８】
ロギングが実行されたものとは異なる再生コンピュータ・システムにおける復元および実行を可能とするため、タスクまたはアプリケーションにアクセス可能なリソースの全てまたは一部を、例えば仮想的な態様で、すなわちインスタンス化または再現して、再生アプリケーションに対してロギングの間と同じように見せなければならない。一般に関与するアイテムは、スレットＴＩＰまたはプロセッサＰＩＤについてのタスク識別子であり、更に再生アプリケーションがアクセスしかつホスト・システムに依存するリソースの殆どである。この仮想化は、再生タスクまたはアプリケーションの開始時に実行され、ロギングの間にストアされたデータに従って、このロギングの間と同様に変化するように再生中に変更される。
【００５９】
この仮想化は、カーネル・モードにおいて実行すると好都合である。これによって、特に、性能カウンタＰＭＣによる命令のカウントにおいてその動作を考慮に入れることを回避することができる。
【００６０】
Ｉｎｔｅl（登録商標）社からの文書は、ハードウェア中断によるエラーは、＋１命令または−１命令の相対エラーに制限されることを指定する。高々１つの単一ハードウェア中断を含むログされた決定的期間について、すなわち、その終了を生じさせたものについて、監視はカウンタＰＭＣの２つの値を考慮する必要がある。すなわち、再生期間の開始時の値および監視点における値である。従って、最大相対エラーは、＋２命令または−２命令である。
【００６１】
ログされたタスクＴＪの再生のための再生タスクＴＲの実行全体を通して、再生エージェントＲＳＣＨは引退した命令数を監視するため、ＲＤＰＭＣによって再生を実行するプロセッサμＰｒｏＸのカウンタＰＭＣを読み取り、この読み取り値をこのログされたタスクＴＪに対応するロギング・データＩｄＪ、ＮＪ、ＳＧＪと比較する。この監視は、一旦この再生実行における命令の順序値がＮＪ−２に等しくなると、再生タスクＴＲの実行を中断するように構成されている。この中断は、例えば、カウンタＰＭＣのオーバーフローを所望の値にプログラミングすることによって実行される。
【００６２】
前述の第４の制限的な特性のため、オーバーフローと中断との間のレイテンシ時間の存在は、あるマージンでオーバーフローをプログラミングする（４１）（図４）ことによって補償することができる。そのようにすれば、ＮＪ−２の所望の値の前に中断を確実に行うようにすることができるからである。このマージンは実験によって決定することができ、例えば約５０の命令とすることができる。
【００６３】
従って、再生期間ＳｃｈＲの最初の実行は、ＮＪ−５０とＮＪ−２との間の命令数で中断される。次いで、再生エージェントＲＳＣＨは、再生タスクＴＲの実行可能ファイルのうち、署名ＳＧＪにストアした命令ポインタの値ＩＰＪに対応するプログラム命令ＢＫＩ上に実行ブレークポイントＢＫをセットする（４２）。次いで、このブレークポイントＢＫによる中断まで実行を再起動し（４３）、再生した命令数がログされた命令数から２命令を減じた値すなわちＮＲ＝ＮＪ−２以上になるまで、カウンタＰＭＣからの命令数をテストする（４４）。
【００６４】
このため、ログされた期間ＳｃｈＪの実際の正確な終了位置は、４つの後続の単一命令実行Ｉｎｓｔｒｕ０〜Ｉｎｓｔｒｕ３内に存在し、その各順序値はＮＪ−１〜ＮＪ＋２である。すなわち、この同じ期間ＳｃｈＪの推定終了位置ＮＪと比べて−２および＋２の間に含まれる相対的な位置にある。
【００６５】
次いで、確認段階（図４）では、この実際の位置を決定することができる。この位置を決定するため、後続の単一命令実行Ｉｎｓｔｒ１〜Ｉｎｓｔｒ４の後に、署名ＳＧＪを再生タスクＴＲの状態ＴＲ１〜ＴＲ４から同じやり方で計算した値ＳＧ１〜ＳＧ４（図３）と比較する。
【００６６】
この確認段階の開始時において、再生エージェントは、これに先行する監視によって生ぜられた中断の直後の再生タスクＴＲの状態に従って計算した再生署名ＳＧＲの値ＳＧ０を調べる（４５）。
【００６７】
本発明によれば、署名ＳＧＪおよびＳＧ０が一致しない場合、タスクＴＲの実行を再起動し、このブレークポイント命令ＢＫ１の最初の新しい実行ＴＲ２において停止する（４６）。
【００６８】
しかしながら、この新しい停止位置ＴＲ２が疑わしい場合がある。例えば、ログされたタスクＴＪが、停止される前にこのブレークポイント命令ＢＫＩを数回実行することによって極めて短いループを実行した場合である。このブレークポイント命令ＢＫＩに対する実行の各ブレークＴＲ２、ＴＲ４において、再生エージェントは署名ＳＧＪおよびＳＧＲの一致を再び検証し（４７）、この一致が得られるまで実行を再起動する。署名が一致すると（この例ではＳＧＪ＝ＳＧ４）、これは、ブレークポイント命令ＢＫＩの最後の実行Ｉｎｓｔｒ４がログされた期間ＳｃｈＪにおいてログされた最後の動作に対応することを意味する。次いで、再生エージェントは再生期間ＳｃｈＲを終了する（４８）。
【００６９】
また、本発明は、セキュリティ機構を想定する、例えば、テスト（４９）において再生ＴＲを中断し、ある数の特定の命令実行の後に再生エラーを戻して（４０１）、例えば８回の単一命令実行の終了時に、エラーの場合の無限ループを回避する。
【００７０】
複数のログされた期間を再生するため、例えばログされたアプリケーションＡＰＰＪに対応する再生アプリケーションＡＰＰＰ（図５）の再生において、再生エージェントＲＳＣＨは、ログＪμＰｒｏＸの異なるラインを連続して読み取り、問題となっているラインに対応する活動期間を再生するためにこれらの各々を用いる。
【００７１】
図５に示すように、このログＪμＰｒｏＸの異なるラインは、再生プロセッサμＰｒｏＺにおいて実行されるログ読み取りタスクＴμＰｒｏＺによって、直接受信される（ＴＲＡＮＳ）か、またはローカルに読み取られる（ＭＥＭ）。
【００７２】
次いで、各々がログされた期間に対応するこのログＪμＰｒｏＸのラインの全ては、ログされた順序で、ＦＩＦＯタイプの再生キューＱＪμＰｒｏＺに送信される。このキューの出力において、再生エージェントＲＳＣＨは、これらのログ・ラインの各々を用いて、それが表す期間を、ログされたタスクＴＡ、ＴＢおよびＴＣに対応する、再生タスクＴＡ’、ＴＢ’およびＴＣ’によって再生させる。
【００７３】
再生プロセッサμＰｒｏＺ内でこれらの期間のスケジューリングを実行するため、再生エージェントＲＳＣＨは、スケジューラＳＣＨの機能を、意味構造の変化なしに標準的なシステム・ソフトウェアに存在するとおりに用いる。この態様によって、特に、同じプロセッサにおいて実行される他のＴＮＭのタスクとの互換性を維持することができる。スケジューラＳＣＨの通常の機能を妨害することなく、ロギング中と同じスケジューリングを得るため、再生エージェントＲＳＣＨは、識別子ＴＩＤまたはＰＩＤが再生しなければならないラインにストアされた識別子ｉｄＡに対応しない限り、各再生タスクＴＢ’、ＴＣ’の解放を阻止する（５５ｂ、５５ｃ）。
【００７４】
決定的期間のロギングおよび再生のためのこれらの技法は、前掲の特許文献に記載されているように、１つ以上の単プロセッサ・コンピュータ内で機能管理アプリケーションの性能および機能を最適化することができる。
【００７５】
マルチプロセッサ・コンピュータまたは並列に動作する多数のコンピュータを含むネットワーク等の並列アーキテクチャの場合には、複数のタスクがアクセス可能な共有リソースの使用によって、非決定性の原因が増す。これは、この機能管理の状況において著しい性能損失の源となる恐れがあり、またはいくつかの重要かつ有用な機能を実装することを不可能とする場合さえある。
【００７６】
これらの非決定性の原因の全てまたは一部を排除するため、本発明は、特に直接アクセス・タイプの共有リソースに対するアクセスを管理または制御することを可能とする方法を提案し、システムによって活動化される期間全体にわたって、各タスクが共有リソースに対して排他的アクセスを得ることができるようにする。
【００７７】
図６は、並列マルチプロセッサ環境の機能の一例を示す。これは、マルチプロセッサ環境において、例えばＬｉｎｕｘ（登録商標）タイプのシステムである第１のプロセッサμＰｒｏＸおよび第２のプロセッサμＰｒｏＹを含む。これらの２つのプロセッサは各々、単一の作業メモリ空間ＲＡＭ内で、タスクＴＡおよびＴＢをそれぞれ並列に実行し、スケジューラによって調整される。各タスクＴＡおよびＴＢの活動期間の間、プロセッサμＰｒｏＸ、μＰｒｏＹにおいて、そのプログラムＥＸＥＡ、ＥＸＥＢからの命令シーケンスＳｃｈＡ、ＳｃｈＢが実行される。このシーケンスからの命令ＩｎｓｔｒＡ、ＩｎｓｔｒＢの実行中、プロセッサは、レジスタＲｅｇＡ、ＲｅｇＢ、スタックＰｉｌＡ、ＰｉｌＢ等の、内部のリソースを用いることができる。
【００７８】
作業メモリＲＡＭ内では、例えば「マップ」タイプの命令によって、いくつかの共有メモリ・ゾーンＳｈＭＰｉ〜ＳｈＭＰｋを定義し、それらの物理アドレスによって直接、異なるタスクＴＡおよびＴＢからアクセス可能とする。
【００７９】
図６は、従来技術からの状況を示す。すなわち、タスクＴＡおよびＴＢは共通の期間にわたって並列に実行され、各々は単一の共有メモリ・ゾーンＳｈＭＰｉに対するアクセスを要求する命令ＩｎｓｔｒＡおよびＩｎｓｔｒＢを含む。これらの２つのアクセス要求は、各プロセッサのメモリ・マネージャ・ユニットＭＭＵによって独立した態様で処理され、互いに無関係に、この共有メモリ・ゾーンに到着する。
【００８０】
システム・コール・タイプのいくつかの命令からのみアクセス可能なリソースについては、これらの命令を実行するシステム・ルーチンを装備化することができる。すなわち、これらのルーチンを変更するか、またはこれらのシステム・コールをインターセプトまたはこれらのシステム・コールに反応する要素をシステムに挿入することができる。ロギングおよび再生による機能管理の状況において、この装備化（instrumentation）は、特に、それらの挙動を記録して、後に全く同様に再生可能とすること、またはこの挙動を決定的にして記録する必要がないように変更することができる。
【００８１】
これとは逆に、システム・コールなしに直接、従って場合によっては任意のプログラム命令からアクセス可能なリソースについては、殆どのオペレーティング・システムおよび特にＵｎｉｘ（登録商標）またはＬｉｎｕｘ（登録商標）タイプのものでは、この共有メモリ・ゾーンＳｈＭＰｉのレベルにおいて、これらのアクセスの到着を制御することはできない。
【００８２】
この問題を解決するため、図７および図８に示すように、本発明は、他の機能のために現用されているある既存のハードウェア機能を変更または拡張するように、いくつかのシステム・ソフトウェア要素のコードを変更すること、または他のいくつかのコードを追加することを提案する。
【００８３】
具体的には、現行プロセッサのハードウェア特性を変更することなく、Ｕｎｉｘ（登録商標）またはＬｉｎｕｘ（登録商標）タイプのシステム・ソフトウェアの少数の要素を変更することによって、この問題を解決することができる。従って、わずかに変更されたかまたは変更されていないマルチタスク・アプリケーションを実行および管理するために、既存のシステム・ソフトウェアにわずかな変更のみ行うことによって、共通タイプ、従って経済的かつ充分に検査された機械を用いることができ、それらの上位互換性を損なうことなく機能を追加する。
【００８４】
本発明は、このため、例えばＩｎｔｅｌ（登録商標）社からのＰｅｎｔｉｕｍ（登録商標）プロセッサまたはＡＭＤ（登録商標）社からのＡｔｈｌｏｎ（商標）のような、ＰＣタイプのアーキテクチャにおいて用いられるプロセッサ等の、多くの最新のマイクロプロセッサに既存のいくつかの機構を用いる。これらのプロセッサは、特にＰｅｎｔｉｕｍ（登録商標）２以降のものは、メモリ管理ユニット内に仮想メモリ管理機構を統合する。この機構は、作業メモリ内に定義されたいくつかのページを使用しない場合に、それらのページをハード・ディスク上に「アンロード」するために用いられ、物理メモリ内の対応する空間を解放するためにそれらのページをそこにストアする。現に実行中のアプリケーションについては、これらのページはなお作業メモリ内にリスト化されているが、タスクがそれに実際にアクセス可能となるためには、それらはハード・ディスクから物理メモリに再び「ロード」しなければならない。
【００８５】
この仮想メモリを管理するため、図８に示すように、システム・ソフトウェアは仮想メモリ・マネージャＶＭＭを含む。これは、仮想化可能なメモリの各ページごとに、異なる各アプリケーション・プロセス内でページ・テーブル・エントリ（「ＰＴＥ」）を生成する。このため、各々がプロセス（すなわちその専有に係る実行コンテキストを有する）の形態で実行される２つのタスクＴＡおよびＴＢについて、ページＳｈＭＰｉ〜ＳｈＭＰｋの各々は、タスクＴＡのプロセスにおいてページ・テーブル・エントリＰＴＥｉＡ〜ＰＴＥｋＡを取得し、タスクＴＢのプロセスにおいてページ・エントリ・テーブルＰＴＥｉＢ〜ＰＴＥｋＢを取得する。
【００８６】
仮想メモリ・マネージャＶＭＭは、ページ・ローダ・ソフトウェアＰＬを含む。これは、ハード・ディスク上の「スワップ」ファイルにメモリ・ページをロードおよびアンロードする。例えば、Ｍｉｃｒｏｓｏｆｔ社からのＷｉｎｄｏｗｓ（登録商標）システムでは、拡張子「.swp」を有するファイルである。ＳｈＭＰｉページの各ロードまたはアンロードの間、物理メモリ内のその存在または不在の状態は、それに対応するページ・テーブル・エントリＰＴＥｉＡおよびＰＴＥｉＢにおいて、ＶＭＭマネージャによってストアされかつ維持される（３０）。これらのテーブルＰＴＥｉＡおよびＰＴＥｉＢ内では、この存在状態は、それぞれデータ・ビットＰｒｉＡおよびＰｒｉＢの形態でストアされ、存在する場合は値１であり不在の場合は値０である。
【００８７】
各プロセッサμＰｒｏＸおよびμＰｒｏＹ内で、メモリ・マネージャＭＭＵＸまたはＭＭＵＹは、ページ不在（page fault）中断機構ＰＦＩｎｔＸまたはＰＦＩｎｔＹを含む。これによって、実行されるプログラム命令ＩｎｓｔｒＡまたはＩｎｓｔｒＢから開始する任意のアクセス要求を渡す。プロセッサμＰｒｏＸが実行するタスクＴＡからの命令ＩｎｓｔｒＡが、メモリ・ページＳｈＭＰｉに関係するアクセスを要求すると（３３）、プロセッサの中断機構ＰＦＩｎｔＸは、対応するエントリ・テーブルＰＴＥｉＡ内にあるその存在ビットＰｒｉＡの値を読み取ることによって、このページが物理メモリＲＡＭに存在するか否かを検証する。
【００８８】
このビットＰｒｉＡがページの存在を示す場合、中断機構ＰＦＩｎｔＸはアクセスを許可する。逆の場合、この中断機構ＰＦＩｎｔＡはタスクＴＡの実行を中断し、エラーのパラメータを、システム・ソフトウェアの仮想メモリ・マネージャＶＭＭに含まれる「ページ不在ハンドラ」ソフトウェア・エージェントＰＦＨに送信する。次いで、このページ不在ハンドラＰＦＨが実行され、システム・ソフトウェア内でアプリケーションに関連してこのエラーの結果を管理する。
【００８９】
図７は、本発明に従って共有リソースに対するアクセスを管理するために、これらの既存の機構をどのように変更して適合させるかを示す。
【００９０】
かかる並列環境において実行されるアプリケーションＡＰＰからのこれらのアクセスを管理するため、図７に示すように、ランチャ・ソフトウェアＬＣＨを用いて、例えばＵｎｉｘ（登録商標）またはＬｉｎｕｘ（登録商標）タイプのシステムにおいて、このアプリケーションの実行を起動する。その起動時に、第１のタスクＴＡを有するアプリケーションＡＰＰを生成する。第１のタスクＴＡは、実行「スレッド」ＴｈｒＡ１を含むプロセスの形態であり、タスク記述子ＴＤＡを形成するデータ・テーブルを用いる。
【００９１】
このタスク記述子ＴＤＡ内で、ランチャは、ここでは管理ビットＭｍＡと称する、通常は用いないデータ・ビットの状態を１に変更することによって、このタスクＴＡが管理または「監視」されなければならないという事実をストアする（２１）。
【００９２】
ここでは共有メモリ・ページＳｈＭＰｉ、ＳｈＭＰｊおよびＳｈＭＰｋとして認められる作業メモリ内の異なる共有メモリ・ゾーンは、ページ・メモリ構造ＰＭＳｔｒＡを形成するデータ・テーブルにおいてタスクＴＡ内にリスト化されている。この構造ＰＭＳｔｒＡにおいて、ページ・テーブル・エントリＰＴＥｉＡ１〜ＰＴＥｋＡ１の形態で、共有ページを記述しかつ更新する。その各々は、前述のように仮想メモリ・マネージャＶＭＭが用いるデータ・ビットＰｒｉＡ１〜ＰｒＫＡ１を組み込んでいる。通常、このページ構造ＰＭＳｔｒＡは、タスクＴＡと同時に生成され、共有メモリに任意の変化があると、「マップ」タイプのルーチン等の、これらの変更を確立する異なるシステム・ルーチンによって更新される（２０）。 
【００９３】
管理されたアプリケーションＡＰＰの実行中、この第１のタスクＴＡから、または同じ態様で生成した他のものから、「生成」タイプの命令ＣＲＥによって他のタスクを生成することができる。また、新しく生成された任意のタスクＴＢは、スレッドＴｈｒＢ１およびタスク記述子ＴＢ、ならびにページ・メモリ構造ＰＭＳｔｒＢを含む。その親タスクからの継承関係ＩＮＨを通して、新しいページ・メモリ構造ＰＭＳｔｒＢは、存在ビットＰｒｉＢ１〜ＰｒｋＢ１を有する異なるページ・テーブル・エントリＰＴＥｉＢ１〜ＰＴＥｋＢ１も含み、これらは同じように最新の状態に維持される。
【００９４】
被監視タスクＴＡから新しいタスクＴＢを生成する（ＣＲＥ）際に、新しいタスク記述子ＴＤＢは管理ビットＭｍＢも含む。その値は、親タスクからの管理ビットＭｍＡのものから継承される（ＩＮＨ）。
【００９５】
管理されたアプリケーションＡＰＰの実行中に、最初は単一のスレッドＴｈｒＢ１を有するプロセスの形態で機能したタスクＴＢ内で、他のスレッドを生成することができる。
【００９６】
既存の被監視タスクＴＢ内で、「クローン」命令等のシステム・コールによって、任意の新しいスレッドＴｈｒＢ２を生成する。通常、マルチスレッド・プロセスの形態のタスクは、そのページ構造ＰＭＳｔｒＢ内に、１組のみのエントリ・テーブルＰＴＥｉＢ１〜ＰＴＥｋＢ１を含む。本発明によれば、「クローン」システム・コール等の、新しいスレッドを生成可能な任意のシステム・ルーチンの機能は、例えば、その内部に補足的な部分ＣＳＵＰを統合することによって変更される。この変更では、既存のタスクＴＢにおける新しいスレッドＴｈｒＢ２の生成が、既存の１組のテーブルＰＴＥｉＢ１〜ＰＴＥｋＢ１を読み取ること（２２）および新しい１組のページ・テーブル・エントリＰＴＥｉＢ２〜ＰＴＥｋＢ２を生成すること（２３）を含み、これらが同じ共有ページＳｈＭＰＩ〜ＳｈＭＰｋに対応して、特に新しいスレッドＴｈｒＢ２と共に機能するように設計されている。この変更は、例えば、これらのルーチンＣＬＯＮＥの装備化によって、同一出願人による仏国特許第２８２０２２１号明細書に記載されているように、システム内の共有ライブラリのロードによる動的介入の技法を用いて実行可能である。
【００９７】
この生成は、新しいテーブルＰＴＥｉＢ２〜ＰＴＥｋＢ２がそれらの親テーブルＰＴＥｉＢ１〜ＰＴＥｋＢ１と同様の態様で最新に維持される（２４、２５）ことを保証するように実行される。そのため、この更新を管理するシステム・ルーチンＭＡＰ内にそれらを更新のために登録するか、または例えばそれらに補足的な部分ＭＳＵＰを統合することによってこれらのシステム・ルーチンＭＡＰを装備化する。
【００９８】
図８は、２つのプロセッサμＰｒｏＸおよびμＰｒｏＹにおいて並列に実行される２つの単一スレッド・タスクＴＡおよびＴＢを含む一例にこの構造を適用した、アクセス管理の機能を示す。ページ・テーブル・エントリＰＴＥの構造を各タスク内でクローンした各スレッドＴｈｒＢ２に拡張することは、単一スレッドであれマルチスレッドであれ、被監視タスクに属する全スレッドから来る任意のアクセスも同じ態様で管理可能とすることに留意すべきである。
【００９９】
ここに述べた実施形態において、本発明によるアクセス管理は、各タスク（プロセスＴＡまたはＴＢという意味および各スレッドＴｈｒＢ１またはＴｈｒＢ２という意味）に対し、共有メモリ・ページに対するアクセスを保証するように構成される。このアクセスは、活動期間の全期間にわたって排他的であり、その間にそれらのコヒーレンス（または一貫性）が、システム・ソフトウェアによって保証される。かかる期間は、ここでは活動期間として記載し、システム・ソフトウェアのスケジューラＳＣＨによって割り当てられ管理される。他のタイプのコヒーレンス期間を同じ精神で選択可能であることは明らかである。
【０１００】
また、アクセスが管理または制御される共有リソースは、ここでは共有メモリの形態で記載し、特定のメモリ・ゾーンとして、またはメモリ・ページとして定義した。同じ概念を、それに対応するシステム・ルーチンを同様に構成することによって他のタイプのリソースに適用することも可能である。
【０１０１】
本発明の実装は、システム・ソフトウェアのいくつかの要素を、以下に記載するとおりに機能するように変更することを含む場合がある。もちろん、必要な変更レベルは、システム・ソフトウェアのタイプまたはバージョンに依存して様々となり得る。Ｌｉｎｕｘ（登録商標）タイプのシステムの場合には、これらの変更は一般に、前述のような「クローン」または「マップ」タイプのルーチンの装備化を含み、更に、スケジューラＳＣＨ、ページ不在ハンドラＰＦＨおよびページ・ローダＰＬを生成するエージェント内の変更およびコード追加を含む。ここで述べたアクセス制御タイプを生成するために変更されるシステム機能は、標準的なシステムの機能と比べて完全な拡張となるという利点を有することができる。すなわち、機能を排除することがなく、または少なくとも、標準的なシステム・バージョンのために開発されたアプリケーションとの上位互換性を損なうことがない。
【０１０２】
更に、仮想メモリ管理のためのプロセッサ内に想定されるハードウェア機構を用いるが、記載したアクセス制御は必ずしもこの仮想メモリの非活動化を必要とせず、これと両立することができる。例えば、仮想ページＳｈＭＰｉの物理メモリＲＡＭｈへのロードは、このページがすでに別のタスクＴＡによって用いられている場合には、被監視タスクＴＢによってこのページの存在ビットＰｒｉＢに反映されないように、ページ・ローダＰＬを構成または変更することができる。
【０１０３】
図８に示すように、その活動期間ＳｃｈＡの１つの開始時に、タスクＴＡは時点ＳＣＨＡＬにおいてスケジューラＳＣＨによって解放される。このタスクを解放する前に、スケジューラＳＣＨは、このタスクＴＡの管理ビットＭｍＡをテストして（３１）、それにアクセス制御を適用しなければならないか否かを確かめる。これが当てはまる場合、スケジューラＳＣＨは次いで、このアクセス制御に関する全ての共有ページに対応するページ・テーブル・エントリＰＴＥｉＡ〜ＰＴＥｋＡの全ての存在ビットＰｒｉＡ〜ＰｒｋＡを０にセットし（３２）、このタスクＴＡによる任意のアクセス要求が、デフォルトで、このタスクＴＡを実行することができる全てのプロセッサμＰｒｏＸの中断機構ＰＦＩｎｔＸにおいてページ・エラーを引き起こすようにする。
【０１０４】
プロセッサμＰｒｏＸ内のこの活動期間ＳｃｈＡの間、命令ＩｎｓｔｒＡは、共有メモリ・ページＳｃｈＭＰｉに対するアクセスを要求する（３３）。対応する存在ビットＰｒｉＡがゼロであるので、プロセッサμＰｒｏＸの中断機構ＰＦＩｎｔＸは、このアクセス要求の実行を停止し、システム・ソフトウェアのページ不在ハンドラＰＦＨをコールすると同時に、問題となっているページおよびタスクの識別をそれに送信する。
【０１０５】
このエラーを処理する場合、ページ不在（フォルト）ハンドラＰＦＨの補足的機能ＰＦＨＳＵＰは、システム・ソフトウェアの仮想メモリ・マネージャＴＭＭ内のカーネル・メモリ構造ＫＭＳｔｒ（「カーネル・メモリ構造」）エージェントを形成するデータ・テーブル内のテストまたは変更あるいはその両方を実行する。
【０１０６】
通常、このカーネル・メモリ構造ＫＭＳｔｒは、作業環境の全てまたは作業メモリの全てのための明白な態様で、メモリ・リソースの構造およびそれらの形成を表すデータをストアする。本発明によれば、このカーネル・メモリ構造ＫＭＳｔｒは、１組のデータ・ビットも含む。これらのビットは、ここではアクセス・ビットＫＳｉ、ＫＳｊおよびＫＳｋと称し、問題となっている共有ページＳｈＭＰｉ〜ＳｈＭＰｋの各々ごとに、このページに対するアクセスがタスクに対し現に付与されている（ビットが１）か、または付与されていない（ビットが０）という事実を表す。
【０１０７】
ページ不在ハンドラＰＦＨが、プロセッサμＰｒｏＸによって送信されたエラーを処理する場合、これは、問題となっているＳｈＭＰｉページに対応するアクセス・ビットＫＳｉを調べる（３４）。このアクセス・ビットが任意の現行アクセスを示さない場合、このページに対するアクセスを付与したことをストアするために、このアクセス・ビットＫＳｉを変更し（３４）、更に、このタスクＴＡが今は問題となっているページＳｈＭＰＰｉに対する排他的なアクセスを有するという事実をストアするために、要求側のタスクＴＡに対応する存在ビットＰｒｉＡを変更する（ビットを１に変更する）（３５）。
【０１０８】
カーネル・メモリ構造ＫＭＳｔｒのアクセス・ビットＫＳｉのこれらのテストおよび変更動作は、アトミックな態様で実装される動作（３４）を構成することに留意すべきである。すなわち、これは、マルチプロセッサ環境においても、完全に達成されるかまたは全く達成されないことが保証される。
【０１０９】
一旦ページ不在ハンドラＰＦＩｎｔが要求されたページＳｈＭＰｉ上の排他性を帰属させると、命令ＩｎｓｔｒＡの実行を再起動して、このページの内容に実際にアクセスする（３６）。
【０１１０】
この後、別のプロセッサμＰｒｏＹによって並列に実行される別の被監視タスクＴＢからの命令ＩｎｓｔｒＢが、このすでに帰属されたページＳｈＭＰｉに対するアクセスを要求すると（３７）、このプロセッサの中断機構ＰＦＩｎｔＹは、要求側タスクＴＢ用のこのページの存在ビットＰｒｉＢを調べる。タスクＴＢは被監視タスクであるので、調べられる存在ビットＰｒｉＢは不在位置にある（値は０である）。従って、中断機構ＰＦＩｎｔＹは要求側命令ＩｎｓｔｒＢを停止し、ページ不在ハンドラＰＦＨにエラーを送信する
（３８）。
【０１１１】
この時点で、このページ不在ハンドラＰＦＨは、このページのアクセス・ビットＫＳｉが１であることに注目し、すでにこのページＳｈＭＰｉ上の排他性が別のタスクに付与されていることを示す。従って、ページ不在ハンドラＰＦＨは、例えばシステム・ソフトウェア・コンテキスト変更マネージャ内でその活動期間を終了することによって、要求側タスクＴＢの全体の停止を開始する（３９）。従って、その次の活動期間の間、このタスクＴＢは、これが中断された箇所までその実行を繰り返し、もう一度この同じページＳｈＭＰｉにアクセスを試みることができる。
【０１１２】
要求側タスクがマルチスレッド・プロセスに属するスレッドＴｈｒＢ２（図７）である場合、この単一のスレッドＴｈｒＢ２に固有の１組のページ・テーブル・エントリＰＴＥｉＢ２の存在によって、すでに排他的アクセスに割り当てられたページに対するアクセスを要求するスレッドのみを停止することができ、この排他性と衝突しない他のスレッドＴｈｒＢ１については停止しない。
【０１１３】
各タスクの活動期間ＳｃｈＡの完了時に（ＳＣＨＡＳ）、スケジューラは、このタスクの実行を停止し、その実行コンテキストをバックアップする。
【０１１４】
この停止時（ＳＣＨＡＳ）またはすでに割り当てたページ要求の停止（３９）の際に、本発明は、このタスクが排他的アクセスを受けた全ての共有メモリ・ページのための解放段階を想定する。従って、スケジューラＳＣＨが、管理ビットＭｍＡによって、停止中のタスクＴＡが監視されることに注目する（３０１）場合、このタスクの全てのページ・テーブル・エントリＰＴＥｉＡ〜ＰＴＥｋＡをスキャンして、異なる存在ビットＰｒｉＡ〜ＰｒｋＡの状態を調べることによって、どのページ上で排他的アクセスを有するかを確かめる。次いで、この情報に基づいて、カーネル・メモリ構造ＫＭＳｔｒにおいてそれらのアクセス・ビットＫＳｉを０にリセットすることによって、全てのこれらのページＳｈＭＰｉを解放する。
【０１１５】
他の図示しない変形において、例えば単一のタスク記述子内にいくつかの管理ビットを想定することによって、管理または監視の概念をいくつかのタイプの管理に分離することもできる。従って、あるカテゴリのタスクに関しては、排他的アクセスから利益を得るようにタスクを監視することができる。同様に、あるカテゴリのタスクによってのみタスクを排除することも可能である。
【０１１６】
このため、すでに割り当てたページにアクセスしようとする全てのタスクを停止することで、このページの排他性は、これを要求する第１のタスクのために得ることができ、しかも、このように停止した他のタスクの実行のコヒーレンスは損なわれない。
【０１１７】
同時に実行されている２つのタスクによって共有される単一メモリ・ゾーンの任意の変更を回避することで、このメモリ・ゾーンの内容が変化する際のそれらの間の干渉を回避する。このメモリ・ゾーンにアクセスするタスクの各活動期間の開始時における、当該メモリ・ゾーンの所与の初期状態からの、その内容の変化は、この活動期間中のこのタスクのアクションにのみ依存する。例えば、スケジューリングされた活動期間のような、このタスクが実行する所与の命令シーケンスについては、既知の初期状態から開始することで、このタスクに関して決定的かつ反復可能なこのシーケンスの実行を行うことができる。
【０１１８】
特に、アクセスされたメモリ・ゾーンに対する排他性の割り当てをストアするためにアトミックな動作を用いるので、この方法は、競合してアクセスしようとする複数のタスク間で共有される単一のリソースのデッドロックのリスクを回避または軽減することができる。
【０１１９】
これらのアクセス制御技法（図７および図８）を、前述の決定的期間をロギングするための技法（図１〜図５）、ならびに、前掲の特許文献に記載されたチェックポイントおよびロギングおよび再生技法と組み合わせることによって、本発明は、並列アーキテクチャ・システムにおいて、前述の異なるタイプの機能管理を実装することも提案する。
【０１２０】
従って、図９は、本発明による、マルチプロセッサ・システムＭＰ１におけるマルチタスク・アプリケーションＡＰＰＪのロギングおよび単一プロセッサ・システムＵＰ２において必要とされるその再生を示す。
【０１２１】
ログされたアプリケーションＡＰＰＪについて、ロギング・エージェントＪＳＣＨは、各プロセッサμＰｒｏＸまたはμＰｒｏＹごとに、異なる被監視タスクＴＡ、ＴＢおよびＴＣの全ての連続的な活動期間をログする。前述のように、これは、それぞれキューＱＪμＰｒｏＸおよびＱＪμＰｒｏＹとしてそれらを別個に送信する。タスクを一旦あるプロセッサにおいて実行し、一旦別のプロセッサにおいて実行する場合、このタスクの活動期間は２つのキューに存在することに留意すべきである。
【０１２２】
ログされたアプリケーションＡＰＰＪがアクセスする共有リソースＳｈＭＰｉ〜ＳｈＭＰｋについて、ロギング・エージェントＪＶＭＭは、これらの各リソースごとに、このリソース上に割り当てられた連続的な排他的アクセスを表すロギング・データを記録する。この排他的アクセス・ロギング・データは、仮想メモリ・マネージャＶＭＭ内において、ページ不在ハンドラＰＦＨによって、異なるタスクに割り当てる排他的アクセスと共に発生される。
【０１２３】
このアクセス・ロギング・データの各記録は、特に、以下を含む。
−問題となっている共有リソースの一義的な識別子。例えば、共有メモリ・ゾーンのためのアドレス
−このアクセスを取得したタスクのための識別子（ＰＩＤまたはＴＩＰ）
−例えば、ここに述べたカウント技法によって取得した、この排他的アクセスの持続時間
−このカウントの不正確さを補償することを可能とする補足的データ。例えば、前述のような署名
−例えば、システム・リソースおよび異なる外部または入出力イベントの仮想化のために有用な何らかの補足的データ。
【０１２４】
このロギング・データは、ＦＩＦＯタイプのロギング・キューＱＪＳｈＭＰｉに送信される。
【０１２５】
実施形態に応じて、これらのキューＱＪμＰｒｏＸ、ＱＪμＰｒｏＹ、ＱＪμＭＰｉの内容を、例えば後に用いるために、１つ以上のログ・ファイルにストアすることができる。
【０１２６】
これらのキューから、コンピュータ通信ネットワーク等の通信手段によって、異なるロギング・データを再生システムＵＰ２に送信する。
【０１２７】
各ロギング・キューＱＪμＰｒｏＸ、ＱＪμＰｒｏＹ、ＱＪμＭＰｉからのデータは、発行キューに対応する再生キューＱＲμＰｒｏＸ、ＱＲμＰｒｏＹ、ＱＲμＭＰｉによってそれぞれ受信される。
【０１２８】
これらの再生キューの出力において、アクセス・ロギング・データに従って、異なるログされたプロセッサμＰｒｏＸおよびμＰｒｏＹのロギング・データを組み合わせて、ログされた活動期間および割り当てられた（連続的な）排他的アクセスを組み合わせたシリアル化を復元する。
【０１２９】
再生システム内では、この再生シリアル化を定義した後に、または再生スケジューリングの後に、再生プロセッサにおいて再生の実行を起動する。
【０１３０】
この再生シリアル化のスケジューリングを妨害しない態様でこれらのプロセッサ間にタスクを分散させると、再生の際の性能を除いて、再生プロセッサの数は重要でないことに留意すべきである。
【０１３１】
ここで述べた異なる機構は、ハードウェア部分とは切り離してソフトウェア部分を用いることに留意すべきである。そのため、ハードウェアに関して良好な独立性が得られ、これは特に、実装を簡単にし、高信頼性化し、これらがプロセッサまたはコンピュータである場合、アーキテクチャが異なる計算要素の並列処理を最良に管理することを可能とすることで、良好な性能を維持する。
【０１３２】
更に、本発明は多くの場合、純粋にソフトウェア実装であるので、全ての利点を含みながら、標準的なハードウェアを用いることができる。
【０１３３】
本発明は、特に、単一の計算要素において共有時間で機能するマルチタスク・アプリケーションのために開発された機能管理技法を、並列環境に拡張することができる。従って、本発明は、かかる並列環境を、ミドルウェア・タイプのアプリケーション内でこの機能管理を実装するネットワークまたはクラスタに統合することができ、例えば、「オン・デマンド」サービスを提供する分散型アプリケーションまたは可変配置（variable deployment）アプリケーションを管理することを可能とする。
【０１３４】
明らかに、本発明は記載してきた例に限定されるものではなく、本発明の枠組みから逸脱することなく、多くの修正を行うことができる。
【図１】
0005505914.tif 000002
【図２】
0005505914.tif 000003
【図３】
0005505914.tif 000004
【図４】
0005505914.tif 000005
【図５】
0005505914.tif 000006
【図６】
0005505914.tif 000007
【図７】
0005505914.tif 000008
【図８】
0005505914.tif 000009
【図９】
0005505914.tif 000010