JP5547373B2 - 単一プロセッサまたはマルチプロセッサ・コンピュータ・システムにおけるマルチタスク・アプリケーションのロギングおよび再生を最適化する方法 - Google Patents

Description

本発明は、コンピュータまたはコンピュータのネットワーク上で実行されるマルチタスク・アプリケーションにおける１つ以上のソフトウェア・タスクの実行に対する管理の方法に関し、特に、外部からのトランスペアレントな且つ非干渉型制御による管理の方法に関する。この管理には、具体的には、ロギング・データの形でこれらのタスクの実行を記録すること、ならびにロギングの間に得られた動作および結果に対応する動作および結果を提供するために、前述のロギング・データを基に上記実行を再生することが含まれる。

本発明は、さらに、システムが実行するソフトウェア・アプリケーションの機能の管理において前述のような方法を実装する該システムに関する。

管理されるアプリケーションに関して非干渉型のトランスペアレントな機能管理を実装することは非常に有益であり、特に、より高い柔軟性、または信頼性、または性能をもたせつつ、既存の多数のアプリケーションを原状のまま（「レガシー・アプリケーション」）使用することができるようにするには、有益である。

中間におけるキャプチャ、および同期ポイントまたは再起動ポイント（「チェックポイント」）におけるアプリケーションの状態の復元による非干渉型の機能管理技術は、同一出願人によって既に仏国特許出願第０４０７１８０号明細書の中で提示されている。これと相補するように、非干渉型のロギングおよび再生の技術が、同一出願人によって仏国特許出願第０５００６０５号明細書から仏国特許出願第０５００６１３号明細書の中で詳細に提示されている。

しかしながら、１つ以上のイベントのロギングは、ログされるアプリケーションまたはそれを実行するシステムにとっては依然としてオーバーヘッド作業に相当するので、できる限りそれを最小限に抑えることに大きな関心が寄せられている。

アプリケーションの実行を構成するイベントのうちでアプリケーションの状態に対して非決定論的動作を有するものについては、後の再生において結果を強制または再注入できるようにするために、それらのイベントの結果をロギング・データ中に保存することによってログおよび再生をしなければならない。したがって、非決定論的なものとして扱わなければならないイベントの数をできる限り低減することが有利である。

アプリケーションまたはアプリケーションを実行するシステムの外部のイベントは、例えば先に引用した出願明細書にも記載されているように、本質的に非決定論的な動作を有することが多く、概して保存しなければならない。

もし、実行の一部分からのイベントが全て決定論的であれば、再起動ポイント方式などのように、単純にアプリケーションの開始状態を保存することによってこの部分を全て効率的にログすることができる。その後、再生を行うには、例えばアプリケーションを保存されている再起動ポイント状態に復元して、これらの決定論的イベントの実行を開始する。これを称して、「区分的決定論的実行モデル（ｐｉｅｃｅｗｉｓｅ ｄｅｔｅｒｍｉｎｉｓｔｉｃ ｅｘｅｃｕｔｉｏｎ ｍｏｄｅｌ）」という用語が使用される。これには、決定論的イベントのみで構成される決定論的部分のグルーピングが含まれる。このように、一般に、決定論的部分の境界線を成しているのは非決定論的イベントであり、例えば初めに外部メッセージが到着し、別の非決定論的イベントが発生して終了となる。

本発明の目的は、前述のような決定論的部分のロギングおよび再生を容易化または最適化することである。

上記に引用した文書の中には、（ヒューリスティック圧縮または予測圧縮により）記憶装置の計算コストの低減が可能となる技術を記述しているものがある。さらに、非決定論的になりえる特定のシステム・コール・ルーチンをインストルメントすることによってそれらの動作を決定論的にすることを提案している文書もある。

しかし、最も多数を占める内部イベントの中には、非決定論的となりえる動作、または非決定性の原因となりえる動作を有しているものがあり、具体的には、共有メモリ・ゾーンまたはセマフォ若しくはミューテックスなどの共有リソースにアクセスする内部イベントである。

本発明の別の目的は、ロギングまたは再生あるいはその両方において非決定論的なものとして扱わなければならないイベントの数を減らすことである。

さらに、ある種のコンピュータ・アーキテクチャ、特に物理的にまたは実際に並列であるとみなされる並列アーキテクチャ・システムにおいては、その性質に固有の非決定論的な要因をかかえていることがある。

一般に、上述の並列環境は、既存のハードウェア・エレメントからはるかに大きな計算能力を得るために設計され使用されている。たいてい、これは、これを最初から考慮して設計されている技術的アプリケーションまたは科学的アプリケーションで煩わしく複雑な計算を行う場合に適用される。

このような環境は、複数のプロセッサを、単一のコンピュータの中に組み入れることによって形成できる。このコンピュータは、このコンピュータに求められている計算作業を上記複数のプロセッサに分配するものである。ときには、数個のコンピュータがネットワークで組み合わされ、ユーザによる干渉がほとんどない状態で特定の作業負荷を分担するように管理されることもある。

これらの種々の特定のエレメント、プロセッサまたはコンピュータが、後に順序付けされる別々のタスクで同時に作業することができる場合、物理的並列性という用語が用いられる。その一方で、例えばいくつかの仮想作業ゾーンにおいて単一エレメントの作業時間を共有することでシミュレートされるような並列性もある。

マルチプロセッサまたはマルチコンピュータのいずれかを含み物理的並列処理能力を備えている既存の環境は、たいてい最大限の総合的計算能力を得られるように設計および最適化されている。このため、できる限り分断された状態で異なるエレメントが作業し、互いの間で協調することはほとんどない。

例えばコストまたはフレキシビリティの理由から、単独でまたはグループとして、大型の中央コンピュータをマイクロ・コンピュータまたはワークステーションに置き換えることが頻繁に求められている。このようなマシンは、より高い能力を求めて並列に作業するマルチプロセッサ構成を取るか、または、それ自体が外部に対して単一の並列作業環境を構成するネットワーク、すなわち外部に対する単一の応答者として動作するネットワークで並列に作業するようにグループ化されてもよい。

したがって、単純に重たい計算アプリケーションではなく、別個のまたはより多様なアプリケーション、特に、コーポレート・マネジメント・ドメイン、またはワークステーション・ネットワーク、または通信ネットワークにおいて一般的なトランザクション式のマルチタスク・アプリケーションを実行するのに、上述のような並列環境を使用することは有利となるであろう。上述のようなアプリケーションはかなり変化に富んだ構造を有することが多く、さらに、同一の環境下で共有リソースを使用するいくつかのタスクを含むことが非常に多い。

しかしながら、これらのオペレーティング・システムまたはアプリケーションは単一プロセッサ・マシン向けに設計されているため、物理的並列処理の場合のように実際に同時に実行される２つのタスク間の干渉を管理するようには設計されていないことが多い。故に、同時に実行されているいくつかのタスクが１つのデータにアクセスしなければいけないとき（「競合状態」）、あるタスクによる読み取りの結果は、この読み取りの前または後に別のタスクによる変更が加えられたか否かによって大きく異なることになるだろう。

さらに、大部分のマルチタスク・オペレーティング・システムでは、実際の並列処理において機能する環境の管理は想定されておらず、直接アクセスにおける共有リソースの管理については、なおさら想定されていない。共有アクセスのタイプの中で直接アクセスとみなすことができるのは、例えば「ｍａｐ」形式の命令によって初期に定義される共有メモリ・ゾーンのように、アドレッシングによってプログラム命令からアクセスすることができるものである。

いくつかのタスクがこのタイプの共有リソースに直接アクセスを介して並列にアクセスする場合、このアクセスは、一般に、システム・ソフトウェアによって管理されることはほとんどなく、「ｏｐｅｎ」、「ｒｅａｄ」または「ｗｒｉｔｅ」などのシステム・コールを用いて「ｐｉｐｅ」または「ｓｏｃｋｅｔ」形式のメッセージをパスするリソースなど、システム・コールを必要とする他の共有リソースへのアクセスとは対照的である。したがって、並列環境において直接アクセスを介した共有リソースへのアクセスを管理するのは、たいていの場合、ほぼ全面的にアプリケーションのタスクとなる。

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

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

前述の技術を根幹として、本発明は、少なくとも２つのアプリケーション・タスクの機能を、コンピュータ・システムにおいて順次活動化によって上述のタスクの実行を管理しているシステム・ソフトウェア内で管理することを提示する。このコンピュータ・システムは、少なくとも２つの演算ユニットにおいて同時にいくつかのアプリケーション・タスクを実行することのできる計算手段を備えた並列構造を備えている。少なくとも１つの共有リソースにアクセスするアプリケーション・タスクのために、本方法は、一方では以下のステップを含んでいる。
−第１の演算ユニットにおけるこれらタスクのうちのいずれかのタスクの第１の継続する活動期間をロギングするステップ、および
−第２の演算ユニットにおけるこれらタスクのうちのいずれかのタスクの第２の継続する活動期間をロギングするステップ、および、
−前記ターゲット・リソースへのアクセス要求に応じて、前記タスクのうちのいわゆるアクセス元タスクに対し前記ターゲット・リソースへの排他的アクセスの一連の帰属（ａｔｔｒｉｂｕｔｉｏｎ）をロギングするステップ、すなわち、前記アクセス要求の直後から前記アクセス元タスクの活動期間の残りの全期間を通して、上記タスクのうちの別のタスクによる前記ターゲット・リソースへのアクセスを全て排除するような帰属をロギングするステップ。

他方では、上記方法は、再生シリアライゼーションという順序付き構造において、演算ユニットのそれぞれにおける一連の活動期間を表すロギング・データと一連の帰属された排他的アクセスを表すロギング・データとを組み合わせることを含む。この組み合わせは、各タスク内で前記共有リソースに対する一連の活動期間の順序を保つように構成されている。

本発明によれば、再生シリアライゼーション・データを再生コンピュータ・システム内で使用して、ログされたタスクのログされた実行を再生してもよい。

さらに、本方法には、再生コンピュータ・システムにおいて、ロギングの間にログされるタスクからアクセスできるソフトウェア・リソースの全てまたは一部を仮想化することが含まれてもよい。

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

同様に、本発明は、本方法を実装するシステムも提示しており、このシステムは並列式であるかまたは並列システムを構成しかつネットワークで使用可能な１つ以上のコンピュータ・システムに適用される。

本発明の他の特徴および利点は、決して制限するものではない実施形態の詳細な説明および添付の図面によって明らかになるだろう。

以下に記載される技術は、例えばＡＭＤ社のＡｔｈｌｏｎ系のプロセッサ、またはインテル社のＰｅｎｔｉｕｍ（登録商標）プロセッサなどＰＣタイプのコンピュータに採用されているタイプのプロセッサの特定の特性を用いる本発明の実施形態に相当する。例えばワークステーションで使用されているプロセッサまたは次世代プロセッサなど最近の他のプロセッサも、当然これらの全てまたは一部の特性または類似した特性を提供でき、本発明を実装するのに採用されてもよい。

図１から図２は、単一のμＰｒｏＸプロセッサまたは演算ユニットによって逐次的に実行される決定論的な内部イベントの別々の部分をロギングする技術を示している。

図１に示されるように、スケジューラＳＣＨが逐次的に開始する活動期間Ｓｃｈ１乃至Ｓｃｈ３と称される部分によって、異なるタスクＴＡおよびＴＢが実行可能である。スケジューラＳＣＨは、上記部分の交替の管理をするコンテキスト・マネージャと称されるシステム・エージェントの一部を成している。

コンピュータ・システムまたはプロセッサ内で実行される様々なタスクの中には、管理を求められるアプリケーションの一部であるものもあり、「監視される」タスクとみなされることになる。こうしたタスクは、タスク・ディスクリプタにおいて、通常は未使用のデータ・ビットの状態（１に設定）によって識別され、ここでは管理ビットＭｍＡまたはＭｍＢと称する（図７を参照）。監視されるタスクと他の監視されないタスクは、プロセッサ内で実行される一連の活動期間の中で交互になってもよい。

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

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

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

各活動期間をロギングのときと同じように再生することができるように、本発明では、ロギングに際してこの決定論的部分の間に実行される命令のカウントを行う。したがって、後でこれらのタスクを再生ＲＳＣＨ（図３および図４を参照）するときは、このログされた部分を単純にロギングの際と同じ状態から開始するだけでよく、ロギングのときに同じ部分によって同じタスクのために実行された命令数と正確に一致する数に至るまで、再生命令を実行すればよい。故に、後の再生においては、決定論的イベントしか含んでいないため、決定論的部分の中で結果を強制するような介入をなんら受けることなく再生が行われる。

決定論的部分が、スケジューラの設定した複数の活動期間に渡るとき、これらの活動期間のそれぞれには、この決定論的部分の一部が含まれ、この一部は、それだけで完全な決定論的部分として処理されることが可能である。以下、決定論的活動期間のロギングのみが説明されることになるが、複数の決定論的活動期間が１つの決定論的部分の中で、互いに後に続くようになるであろうことは明らかである。

本発明によれば、決定論的活動期間の命令をカウントするのにパフォーマンス監視カウンタを用いており、これは、現在ではインテル社のＰｅｎｔｉｕｍ（登録商標）系のＰｅｎｔｉｕｍ（登録商標）２以降のものなど多数のプロセッサに既設のハードウェア機能である。このパフォーマンス監視カウンタは、イベントの継続期間にわたるまたは多数のイベントにおけるプロセッサの機能を計測するために設けられ、主にパフォーマンスを計測するために用いられており、例えば、数値の定期的なサンプリングによるアプリケーション・プロファイルの統計的な分析などに使用される。なお、プロセッサの製造者によれば、これらのパフォーマンス・カウンタは保証された精度は有しておらず、アプリケーション最適化のために相対的あるいは差分的な計測用として使用されるべきであることが明示されている。

本発明は、このパフォーマンス・カウンタＰＭＣの特性の１つを用いることを提示しており、具体的にはリタイアと称する命令をカウントすること、すなわち、性能上の理由から特定の命令を先行して実行させることのできる様々な投機的またはキャッシュ技術とは無関係に解決されたかまたは実行命令リストを離れた命令をカウントすることを提示している。

しかしながら、このリタイアした命令のカウントはある制限的な特性を示すことが、インテル社およびＡＭＤ社の文書に記載されている。こうした特性の１つとして、このカウンタ用の読み取り命令（「ＲＤＰＭＣ」）が、解決される命令に直接組み込まれていないことが挙げられるが、このことは、本発明に関連してこのカウンタを使用することに何ら直接的な影響を与えるものではない。

一方、他の２つの制限的な特性は、ロギングおよび再生用の命令のカウントに際して不正確さをもたらす可能性があり、考慮されるべきである。

第４の特性も不利益をもたらす可能性のあるもので、命令がカウンタ・オーバーフローを引き起こした後、このカウンタ・オーバーフローによる実行の割り込みが一定の遅れを伴って生じることである。

不正確さを招くこれらの制限は、一方では、解決する前に割り込みを掛けられると二重にカウントされてしまう可能性のある特定の複雑な命令に関連し、他方では、命令をカウントしそこなう原因となりえるハードウェア割り込みを伴う命令に関連している。この不正確さを克服するために、本発明は、補足的な確認技術を使用し、それにより活動期間の終了の的確な決定に関する疑わしさを取り除くことができる。

図１に示されるように、μＰｒｏＸプロセッサ内で実行される一連の決定論的活動期間であるＳｃｈ１、Ｓｃｈ２およびＳｃｈ３が、ログ・ファイルＪμＰｒｏＸにログおよび記録される。

ログされる活動期間Ｓｃｈ３では、監視されるタスクＴＡをプロセッサが実行しており、その間にカウンタＰＭＣの値ＵＩＣＸの１つ以上の読み取りＲＤＰＭＣが、リタイアした命令の数ＮＪ３を提供する。この期間Ｓｃｈ３の停止（Ｓｃｈ３終了）において、ロギング・エージェントＪＳＣＨは、タスクＴＡおよびそのコンテキストの状況から出力された状況データの１つ以上のアイテムを使用して、この活動期間Ｓｃｈ３の間に実行された命令の正確な数に関して存在するかもしれない疑わしさを取り除くために、この状態を十分に一義的に表しているデータの１つ以上のアイテムを算出する。この状況データは、この期間の終了（Ｓｃｈ３終了）に対応する署名ＳＧ３となる。この署名は、具体的には、この期間における最後の命令の直後の命令ポインタの正確な値ＩＰＪＸ３を含み、すなわちタスクＴＡの実行可能ファイル内における最後に実行されたプログラム命令の正確な位置を示している。この署名は、さらに、この停止（Ｓｃｈ３終了）時にタスクＴＡのコンテキストからレジスタＲｅｇＪＸ３およびコール・スタックＰｉｌｅＪＸ３に読み取られた値から算出された制御データ（「チェックサム」）も備えている。

したがって、ログされる各期間ＳｃｈＪ（図３）に関して、このプロセッサのログＪμＰｒｏＸは、特に以下のものに関連する行から成る。
−この期間に実行されるタスクＴＪの識別表示ｉｄＪ、例えばこのタスクの「ＰＩＤ」など。
−カウンタＰＭＣが送信する、取り消された命令数ＮＪの値。
−この期間の終了に関して算出された署名ＳＧＪ。

したがって、図１に示されたＴＡの次にＴＢその次にＴＡという一連のタスクについては、プロセッサμＰｒｏＸのログＪμＰｒｏＸに次のような連続する行が含まれる。
「ｉｄＡ： ＮＪ３： ＳＧＪ３
ｉｄＢ： ＮＪ２： ＳＧＪ２
ｉｄＡ： ＮＪ１： ＳＧＪ１」

図２に示されるように、任意のプロセッサμＰｒｏＸ内でログされるアプリケーションＡＰＰＪのログされる一連の異なったタスクは、ロギング・エージェントＪＳＣＨによって、最初にＦＩＦＯ（「先入れ先出し」）方式のロギング・キューＱＪμＰｒｏＸへと伝送される。このキューから出力されるロギング行がログ保存タスクＴＪμＰｒｏＸによって読み取られ、これによって、ローカルＭＥＭにか、または別のノード、バックアップ・ステーション若しくは周辺機器への伝送ＴＲＡＮＳによって、このプロセッサのログＪμＰｒｏＸへの順序付けられた上記行の保存が開始される。このようなロギング・キューの使用は、特に、バッファ・ゾーンの役割を果たし、それによりロギング・データの流れを調整し、ログされるアプリケーションまたはこのロギングを行うアプリケーションに妨害が生じるのを回避する。

この利点が特に顕著となるのはグローバル・アーキテクチャの場合であり、そこでは、耐障害性および連続性のあるサービスを備えた機能を実現するために、ロギング・データが発生されると次々に、例えば予備のマシンなどで同一の実行を再生する別のアプリケーションに伝送される。

このカウント技術においては、命令のカウントに際してシステム・コール命令を同期ポイントとして使用すると有利になるだろう。したがって、これには、システム・コール・カウンタをインクリメントするように、システム・コール・ルーチンをインストルメントすることが含まれる。その結果、ハードウェア・カウンタＰＭＣによる命令のカウントは少なくて済む値を対象にすることができ、それにより性能が向上することになる。

図３および図４は、再生プロセッサμＰｒｏＺにおけるログされた期間ＳｃｈＪの再生技術を示している。図３は、プロセッサにおける再生タスクＴＲの最新の状態ＴＲ１乃至ＴＲ４を表している。図４は、上述の再生を実施するために使用される方法のフローを図示している。実施形態または使用パラメータによっては、別個の再生プロセッサの場合と同様の原理にしたがって、例えばアプリケーション追跡型の機能管理などのためにロギングと同一のプロセッサで再生を行ってもよい。

例えば、スケジューラＳＣＨによってスケジュールされるような活動期間での再生においては、再生エージェントＲＳＣＨを含めるように変更されてもよいが、当該タスクＴＪが前述のプロセッサ内にコンテキストとともに復元されると、その後このタスクは解放４１されてタスクの実行が開始される。

ロギングが行われたのとは異なる再生コンピュータ・システムで復元および実行できるようにするためには、タスクまたはアプリケーションにとってアクセス可能なリソースの全てまたは一部を仮想化、すなわち例えば仮想的にインスタンス化または再生成することによって、再生されるアプリケーションからはロギングの際と同様に見えるようにしなければならない。通常関連するアイテムとしては、スレッドＴＩＰまたはプロセスＰＩＤに関するタスク識別子のほか、アプリケーションからアクセスできかつホスト・システムに依存する大部分のリソースなどがある。この仮想化は、再生されるタスクまたはアプリケーションの開始時に実施され、再生の間には、ロギングと同様に変化するように、ロギング中に保存されたデータに基づいて修正が加えられる。

この仮想化はカーネル・モードで行われると有利であり、それによって、特に、パフォーマンス・カウンタＰＭＣが命令カウントを行う際に、この仮想化の操作を考慮しなくても済むようにできる。

インテル社の文書では、ハードウェア割り込みを原因とするエラーは、プラスマイナス１命令の相対誤差に限られると明示している。ログされた決定論的期間に、多くて１つのハードウェア割り込みが含まれる場合、すなわちその終了の原因となる割り込みが多くても１つである場合、それを監視するには、カウンタＰＭＣの２つの値を考慮する必要がある。つまり、再生期間の開始時の値、および監視ポイントにおける値である。相対誤差の上限は、したがって、プラスマイナス２命令となる。

ログされたタスクＴＪの再生を行う再生タスクＴＲの実行中、再生エージェントＲＳＣＨは、再生を実行しているプロセッサμＰｒｏＺのカウンタＰＭＣをＲＤＰＭＣ命令で読み取り、この読み取りをログされたこのタスクに対応するロギング・データＩｄＪ、ＮＪ、ＳＧＪと対比させることによって、リタイアされた命令数を監視する。この監視は、この再生実行における順序値がＮＪ−２である命令に達したらすぐに再生タスクＴＲの実行に割り込みをかけるように構成されている。この割り込みを行うには、例えば、希望の値でカウンタＰＭＣがオーバーフローするようにプログラミングする。

既に示した第４の制限的特性のためにオーバーフローと割り込みの間に待ち時間ができるが、これは、ある程度のマージンを持たせてオーバーフロー４１（図４）をプログラミングすることで補償することができ、それにより確実に希望の値ＮＪ−２よりも前に割り込みを引き起こせるようになる。このマージンは実験によって決定してもよいし、例えば５０命令程度にしてもよい。

したがって、再生期間ＳｃｈＲの最初の実行は、命令数がＮＪ−５０からＮＪ−２の間のときに割り込みをかけられる。次に、再生エージェントＲＳＣＨが、署名ＳＧＪに保存された命令ポインタの値ＩＰＪに対応するプログラム命令ＢＫＩに応じて、再生タスクＴＲの実行可能ファイル内に実行ブレークポイントＢＫを設定４２する。次に、実行は再開され、このブレークポイントＢＫによって割り込み４３がかけられるまで継続する。このとき同時に、再生された命令の数がログされた命令の数マイナス２命令以上、すなわちＮＲ≧ＮＪ−２になるまで、カウンタＰＭＣの示す命令数を検査４４する。

ログされた期間ＳｃｈＪの実際の終了の正確な位置は、故に、順序値がそれぞれＮＪ−１乃至ＮＪ＋２である４つの連続する単位命令の実行Ｉｎｓｔｒ０乃至Ｉｎｓｔ３に置かれる、すなわち、この同じ期間ＳｃｈＪの想定された終了の位置ＮＪを基準にしてマイナス２からプラス２の間の相対的位置に置かれる。

次に、確認段階４０（図４）は、連続する単位命令の実行Ｉｎｓｔｒ１乃至Ｉｎｓｔｒ４の後で、署名ＳＧＪと、再生タスクＴＲの状態ＴＲ１乃至ＴＲ４から同様のやり方で算出される値ＳＧ１乃至ＳＧ４（図３）とを比較することにより、この実際の位置を決定する。

この確認段階の開始時に、再生エージェントは、先立つ監視の引き起こした割り込みの直後における再生タスクＴＲの状態に応じて算出された再生署名ＳＧＲの値ＳＧ０を照合４５する。

本発明によれば、もし署名ＳＧＪとＳＧ０とが一致しなかったら、ここでタスクＴＲの実行は再開され、このブレークポイント命令ＢＫＩがまた新たに実行ＴＲ２されると停止４６する。

しかしながら、例えば、ログされたタスクＴＪが、停止の前にこのブレークポイント命令ＢＫＩを何度か実行することによって非常に短いループを実行していると、この新しい停止位置ＴＲ２に関して疑わしさの残る場合もある。このブレークポイント命令ＢＫＩによる実行の各ブレークＴＲ２、ＴＲ４において、再生エージェントは、署名ＳＧＪとＳＧＲとの一致を再度検証４７し、この一致が得られるまで実行を再開する。署名が一致したとき（この例においてはＳＧＪ＝ＳＧ４）、それはブレークポイント命令ＢＫＩの最後の実行Ｉｎｓｔｒ４が、ログされた期間ＳｃｈＪでログされた最後のオペレーションと一致したことを意味する。再生エージェントは、このとき、再生期間ＳｃｈＲを終了４８させる。

本発明は、さらにセキュリティ・メカニズムも想定している。エラー発生時の無限ループを避けるために、例えば検査４９で再生ＴＲに割り込みをかけ、特定数の命令実行の後で、例えば単位命令の実行を８回したあとなどに、再生エラーを返す４０１。

ログされた複数の期間の再生をするには、例えばログされたアプリケーションＡＰＰＪに対応する再生アプリケーションＡＰＰＲ（図５）の再生の場合、再生エージェントＲＳＣＨは、ログＪμＰｒｏＸの別々の行を連続的に読み取り、そのそれぞれを使用して該当する行に対応する活動期間を再生する。

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

このログＪμＰｒｏＸの全ての行はそれぞれログされた期間に対応しており、その後ＦＩＦＯ形式の再生キューＱＪμＰｒｏＺへ、ログされた順番の通りに伝送される。このキューの出力において、再生エージェントＲＳＣＨはこれらの各ログ行を使用して、それぞれの行が示す期間を、ログされたタスクＴＡ、ＴＢおよびＴＣに対応する再生タスクＴＡ’、ＴＢ’およびＴＣ’によって再生させる。

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

上記に引用した出願明細書に記載されているように、決定論的期間をロギングおよび再生するためのこれらの技術を用いて、１つ以上の単一プロセッサ・コンピュータにおける機能管理アプリケーションの性能および機能を最適化することができる。

マルチプロセッサ・コンピュータまたは並列に作業する多数のコンピュータを備えるネットワークなど並列アーキテクチャの場合には、複数のタスクからアクセス可能な共有リソースを使用することによって非決定論的な原因が加わり、このことから、機能管理に関連して深刻な性能の低下の原因となりかねず、何らかの重要かつ有用な機能の実装が不可能になってしまう原因にもなりかねない。

これら非決定論的な原因の全てまたは一部を排除するために、本発明は共有リソース、特に直接アクセス・リソースへのアクセスを管理または制御できる方法を提示し、それにより各タスクが、システムによって活動化されている期間を通して共有リソースへの排他的なアクセスを得られるようにする。

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

作業メモリＲＡＭの中には、例えば「ｍａｐ」形式の命令などによって、いくつかの共有メモリ・ゾーンＳｈＭＰｉ乃至ＳｈＭＰｋが定義されており、別々のタスクＴＡおよびＴＢから物理アドレスで直接アクセス可能となっている。

図６は、先行技術に基づく状況を示しており、そこではタスクＴＡおよびＴＢは共通する期間にわたって並列に実行され、単一の共有メモリ・ゾーンＳｈＭＰｉへのアクセスを要求する命令ＩｎｓｔｒＡおよびＩｎｓｔｒＢをそれぞれ備えている。これらの２つのアクセス要求は、各プロセッサのメモリ・マネージャ・ユニットＭＭＵによって別々に処理され（１１、１３）、互いに無関係にこの共有メモリ・ゾーンに到達する（１２、１４）だろう。

システム・コール型式の特定の命令からのみアクセス可能なリソースに関しては、これらの命令を実行するシステム・ルーチンをインストルメントすること、すなわち、これらのルーチンを変更するか、またはこれらのシステム・コールを傍受またはこれらに反応するエレメントをシステムに挿入することができる。ロギングおよび再生による機能管理に関連しては、このインストルメンテーションにより、特に、動作を記録することが可能となって、それを後で完全に同じように再生することができるか、あるいはこの動作が決定論的となって記録する必要がなくなるように動作を変更することができる。

その一方で、システム・コールを用いず直接アクセスが可能な、ひいてはどのようなプログラム命令からもおそらく直接アクセスが可能なリソースの場合、大部分のオペレーティング・システム、特にＵｎｉｘ（登録商標）またはＬｉｎｕｘ（登録商標）系のものは、この共有メモリ・ゾーンＳｈＭＰｉのレベルでアクセスの到着を制御することはできない。

この問題を解決するために、図７および図８に示すように、本発明は、特定のシステム・ソフトウェア・エレメントのコードを変更するか、または他の特定のエレメントを追加し、それにより既存のハードウェア機能のうち現在他の機能に使用されているものを変更または拡張することを提示している。

具体的には、Ｕｎｉｘ（登録商標）またはＬｉｎｕｘ（登録商標）系のシステム・ソフトウェアにおいてごく少数のエレメントを変更することにより、現在のプロセッサのハードウェア特性を変更することなく、この問題を解決することが可能である。したがって、既存のシステム・ソフトウェアにほんのわずかな変更をもたらし、それにより上位互換性を危うくすることなく機能性を追加すること、一般的な種類であり故に経済的でありかつ保証付きのマシンを使用して少し変更されたまたは変更されていないマルチタスク・アプリケーションを実行および管理することが可能である。

本発明は、このことを、例えばインテル社のＰｅｎｔｉｕｍ（登録商標）プロセッサ、またはＡＭＤ社のＡｔｈｌｏｎなどＰＣ型式のアーキテクチャに使用されているプロセッサを始め、最近の多数のマイクロ・プロセッサに既設の特定のメカニズムに用いている。これらのプロセッサは、特にＰｅｎｔｉｕｍ（登録商標）２以降、メモリ管理ユニット内に仮想メモリ管理メカニズムを組み込んでいる。このメカニズムを使うと、作業メモリ内で定義されている特定のページが未使用時にハード・ディスク上に「アンロード」され、それをハード・ディスクに保存することによって、物理メモリ内の相当する空間が空く。現在稼働中のアプリケーションに関しては、これらのページはまだ作業メモリ内に載せられてはいるものの、タスクが実際にそのページにアクセスできるようにするためには、それらは再度ハード・ディスクから物理メモリに「ロード」されなければならない。

この仮想メモリを管理するために、図８に示すように、システム・ソフトウェアは仮想メモリ・マネージャＶＭＭを備えており、これは、様々な各アプリケーション・プロセスの中で仮想化可能なメモリの各ページ用にページ・テーブル・エントリ（「Ｐ．Ｔ．Ｅ．」）を作成する。したがって、プロセスの形で各々が実行されるすなわち固有の実行コンテキストを伴って実行される２つのタスクＴＡおよびＴＢに関しては、ＳｈＭＰｉ乃至ＳｈＭＰｋの各ページが、それぞれページ・テーブル・エントリＰＴＥｉＡ乃至ＰＴＥｋＡをタスクＴＡのプロセスで受け取り、同様にページ・テーブル・エントリＰＴＥｉＢ乃至ＰＴＥｋＢをタスクＴＢのプロセスで受け取る。

仮想メモリ・マネージャＶＭＭは、ページ・ローダ・ソフトウェアＰＬを備え、これは、ハード・ディスク上の「スワップ」ファイル、例えばマイクロソフト社のＷｉｎｄｏｗｓ (登録商標）システムにおいては拡張子「．ｓｗｐ」を伴うファイルに、メモリ・ページをロードおよびアンロードする。ＳｈＭＰｉページのロードおよびアンロードそれぞれの作業の間、物理メモリにおけるそのページの存在の有無の状況については、ＶＭＭマネージャが、対応するページ・テーブル・エントリＰＴＥｉＡおよびＰＴＥｉＢそれぞれの中に保存および管理する（３０）。この存在の有無の状況は、これらのテーブルＰＴＥｉＡおよびＰＴＥｉＢの中に、それぞれデータ・ビットＰｒｉＡおよびＰｒｉＢの形で保存され、存在していれば値は１、不在であれば値は０となる。

各プロセッサμＰｒｏＸおよびμＰｒｏＹにおいて、メモリ・マネージャＭＭＵＸまたはＭＭＵＹはページ・フォルト割り込みメカニズムＰＦＩｎｔＸまたはＰＦＩｎｔＹを備え、実行されるプログラム命令ＩｎｓｔｒＡまたはＩｎｓｔｒＢから届くあらゆるアクセス要求はここを通るようになっている。もしプロセッサμＰｒｏＸによって実行されるタスクＴＡからの命令ＩｎｓｔｒＡがメモリ・ページＳｈＭＰｉに関するアクセスを要求したら（３３）、プロセッサの割り込みメカニズムＰＦＩｎｔＸが、対応するテーブル・エントリＰＴＥｉＡにある存在ビットＰｒｉＡの値を読み取ることによって、このページが物理メモリＲＡＭに存在するかどうかを検証する。

もしこのビットＰｒｉＡがこのページの存在することを示していたら、割り込みメカニズムＰＦＩｎｔＸはアクセスを許可する。逆の場合は、この割り込みメカニズムＰＦＩｎｔＸは、タスクＴＡの実行に割り込みをかけ、エラーのパラメータをシステム・ソフトウェアの仮想メモリ・マネージャＶＭＭに備わった「ページ・フォルト・ハンドラ」ソフトウェア・エージェントＰＦＨに伝送する。次に、このフォルト・ハンドラＰＦＨが実行され、システム・ソフトウェアにおいてアプリケーションに関し、このエラーの結果の管理を行う。

図７は、本発明にしたがって共用リソースに対するアクセスを管理するためには、既存のメカニズムをどのように修正し、適用または転用するのかを図示している。

図７に示すような並列環境において実行されるアプリケーションＡＰＰからのアクセスを管理するために、例えば、Ｕｎｉｘ（登録商標）またはＬｉｎｕｘ（登録商標）系のシステムにおいて、ランチャ・ソフトウェアＬＣＨを使用してこのアプリケーションの実行を開始する。開始に際して、アプリケーションＡＰＰはプロセスの形をとる第１のタスクＴＡと共に作成され、このプロセスは実行「スレッド」ＴｈｒＡ１を備え、タスク・ディスクリプタＴＤＡを形成するデータ・テーブルを用いている。

ランチャは、管理ビットＭｍＡと称される通常は未使用のデータ・ビットの状態を１に修正することによって、このタスクＴＡが管理されるまたは「監視される」必要があるという情報をこのタスク・ディスクリプタＴＤＡの中に保存２１する。

作業メモリ内の異なる共有メモリ・ゾーンは、ここでは共有メモリ・ページＳｈＭＰｉ、ＳｈＭＰｊおよびＳｈＭＰｋとするが、タスクＴＡの中でページ・メモリ構造ＰＭＳｔｒＡを形成するデータ・テーブルに載せられている。この構造ＰＭＳｔｒＡにおいて、共有ページはページ・テーブル・エントリのＰＴＥｉＡ１乃至ＰＴＥｋＡ１の形で記載および更新され、そのそれぞれが、先に説明したように、仮想メモリ・マネージャＶＭＭによって使用されるデータ・ビットＰｒｉＡ１乃至ＰｒＫＡ１を内蔵している。通常、このページ構造ＰＭＳｔｒＡはタスクＴＡと同時に作成され、共有メモリに何らかの変更があればそれに従い、これらの変更を確実にする様々なシステム・ルーチン、例えば「ｍａｐ」型式のルーチンによって、更新される（２０）。

管理されるアプリケーションＡＰＰの実行中、「ｃｒｅａｔｅ」型式の命令ＣＲＥによって、この第１のタスクＴＡから、または同様の方法で作成されたその他のタスクから、別のタスクが作成されてもよい。新規に作成された任意のタスクＴＢにも、スレッドＴｈｒＢ１およびタスク・ディスクリプタＴＤＢが、ページ・メモリ構造ＰＭＳｔｒＢとともに備わっている。親タスクからの継承関係ＩＮＨを通じて、新しいページ・メモリ構造ＰＭＳｔｒＢも、存在ビットＰｒｉＢ１乃至ＰｒｋＢ１を有する別々のページ・テーブル・エントリＰＴＥｉＢ１乃至ＰＴＥｋＢ１を備え、これらは同様の方法で最新の状態に保たれている。

監視されているタスクＴＡからの新しいタスクＴＢの作成ＣＲＥに当たり、新規のタスク・ディスクリプタＴＤＢには管理ビットＭｍＢも備わり、その値は親タスクの管理ビットＭｍＡの値を継承ＩＮＨしたものである。

管理されるアプリケーションＡＰＰの実行の間に、当初は単一スレッドＴｈｒＢ１を有するプロセスの形で機能していたタスクＴＢの中に、他のスレッドが作成されてもよい。

既存の監視されているタスクＴＢの中に、「ｃｌｏｎｅ」命令などのシステム・コールによって任意の新しいスレッドＴｈｒＢ２が作成される。通常、マルチスレッド・プロセスの形をとるタスクは、そのページ構造ＰＭＳｔｒＢの中に、テーブル・エントリＰＴＥｉＢ１乃至ＰＴＥｋＢ１を１セットだけ備える。本発明によれば、「ｃｌｏｎｅ」システム・コールなど新しいスレッドを作成することのできる任意のシステム・ルーチンの機能は、例えば補足的な部分ＣＳＵＰをその中に組み入れることなどによって変更される。この変更が目的としているのは、既存のタスクＴＢの中での新しいスレッドＴｈｒＢ２の作成の全てに、既存のセットであるテーブルＰＴＥｉＢ１乃至ＰＴＥｋＢ１の読み取り（２２）、および新しいセットのページ・テーブル・エントリＰＴＥｉＢ２乃至ＰＴＥｋＢ２の作成（２３）を含ませ、これらを同様に共有ページＳｈＭＰｉ乃至ＳｈＭＰｋに対応させ、新しいスレッドＴｈｒＢ２に特化して機能させることである。この修正は、例えば、同一出願人による仏国特許第２８２０２２１号明細書に記載されているように、システム内の共有ライブラリのロードを通じて動的な干渉の技術を用いることによって、これらのルーチンＣＬＯＮＥをインストルメントすることなどにより行われてもよい。

この作成においては、親テーブルＰＴＥｉＢ１乃至ＰＴＥｋＢ１と同様の方法で、新しいテーブルＰＴＥｉＢ２乃至ＰＴＥｋＢ２についても確実に最新の状態を維持する（２４、２５）ようになっている。これは、この更新を管理しているシステム・ルーチンＭＡＰの中にテーブルを登録して更新するか、あるいは補足的な部分ＭＳＵＰを組み入れることなどによってこれらのシステム・ルーチンＭＡＰをインストルメントするかのいずれかによって維持される。

図８は、一例として２つのプロセッサ、μＰｒｏＸおよびμＰｒｏＹにおいて並列に実行される２つの単一スレッド型タスクＴＡおよびＴＢを含むものに上記構造を適用したアクセス管理の機能を示す。なお、各タスク内に複製される各スレッドＴｈｒＢ２にもページ・テーブル・エントリＰＴＥの構造を拡張して適用させることにより、スレッドが単一スレッド、マルチスレッドのいずれであっても、監視されているタスクに属する全てのスレッドからの各種アクセスを同様の方法で管理できるようになる。

本明細書に記載された実施形態においては、本発明によるアクセス管理は、活動期間を通して一貫性（または整合性）がシステム・ソフトウェアによって保証されている共有メモリ・ページ群への排他的アクセスを、該期間全体を通じて各タスクに、つまり、各スレッドＴｈｒＢ１またはＴｈｒＢ２にもプロセスＴＡまたはＴＢにも、保証するように構成されている。このような期間は、本明細書ではシステム・ソフトウェアのスケジューラＳＣＨによって割り当ておよび管理が行われる活動期間として記載されている。同様の趣旨で、別のタイプの一貫性ある期間が選択されてもよいことは明らかである。

同様に、アクセスが管理または制御される共有リソースについて、本明細書では、特定のメモリ・ゾーンまたはメモリ・ページとして定義される共有メモリの形で記載している。他の種類のリソースでも、それに対応するシステム・ルーチンを同様にインストルメントすれば、同じコンセプトを適用することもできる。

本発明の実施においては、システム・ソフトウェアの一部のエレメントを変更し、それらが以下に記載するような機能をもつようにしてもよい。必要とされる変更の程度は、システム・ソフトウェアの種類またはバージョンに応じて確実に異なってくるだろう。Ｌｉｎｕｘ（登録商標）系システムの場合、これらの修正には、通常、先に記載したように「ｃｌｏｎｅ」および「ｍａｐ」型式のルーチンをインストルメントすること、ならびにスケジューラＳＣＨ、ページ・フォルト・ハンドラＰＦＨおよびページ・ローダＰＬを形成しているエージェントにおいて変更およびコードの追加をすることが含まれる。本明細書に記載されたタイプのアクセス制御を形成するためにはシステムの機能性を変更するが、有利なことに、標準システムの機能性と比較して純然たる拡張として行うことができ、すなわち、機能性を除外することもなく、または少なくとも標準システム・バージョン用に開発されたアプリケーションの上位互換性を危うくすることもない。

さらに、プロセッサにおける仮想メモリ管理を想定されているハードウェア・メカニズムを使用するとはいえ、上述のアクセス制御のために必ずしもこの仮想メモリを非活動化しなくてもよく、両立可能である。例えば、仮想ページＳｈＭＰｉが既に別のタスクＴＡによって使用されている場合に、このページの物理メモリＲＡＭへのロードが、監視されているタスクＴＢによってこのページの存在ビットＰｒｉＢへ反映されないように、ページ・ローダＰＬをインストルメントまたは変更してもよい。

図８に示すように、活動期間の１つであるＳｃｈＡの開始に際して、タスクＴＡはスケジューラＳＣＨによって時点ＳＣＨＡＬにおいて解放される。スケジューラＳＣＨは、このタスクを解放する前にタスクＴＡの管理ビットＭｍＡを検査して（３１）、アクセス制御を適用すべきかどうかを確定する。アクセス制御が必要な場合、スケジューラＳＣＨは、次にこのアクセス制御に関わる全ての共有ページに対応するページ・テーブル・エントリＰＴＥｉＡ乃至ＰＴＥｋＡの全存在ビットＰｒｉＡ乃至ＰｒｋＡを０に設定し（３２）、それにより、このタスクＴＡを実行することのできる全プロセッサμＰｒｏＸ用の割り込みメカニズムＰＦＩｎｔＸにおいて、このタスクＴＡによるあらゆるアクセス要求が初期設定によってページ・エラーをもたらすようにする。

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

このエラーの処理に際し、ページ・フォルト・ハンドラＰＦＨの補足的機能ＰＦＨＳＵＰは、そのとき、システム・ソフトウェアの仮想メモリ・マネージャＶＭＭ内部にカーネル・メモリ構造ＫＭＳｔｒエージェントを形成するデータ・テーブルにおいて、検査もしくは変更またはその両方をおこなう。

通常、このカーネル・メモリ構造ＫＭＳｔｒは、メモリ・リソースの構造およびその展開を表しているデータを、全作業環境に関してまたは全作業メモリに関して一意の方法で保存する。本発明によれば、このカーネル・メモリ構造ＫＭＳｔｒは、アクセス・ビットＫＳｉ、ＫＳｊおよびＫＳｋと称する１セットのデータ・ビットをさらに備え、これは当該の共有ページＳｈＭＰｉ乃至ＳｈＭＰｋのそれぞれに関して、現在このページへのアクセスがタスクに対して認められている（ビットは１）か、または認められていない（ビットは０）かという情報を提示する。

ページ・フォルト・ハンドラＰＦＨがプロセッサμＰｒｏＸから伝送されたエラーを処理するとき、問題のページＳｈＭＰｉに対応するアクセス・ビットＫＳｉを参照（３４）する。もしこのアクセス・ビットが現在のアクセスを何も示していなかったら、このアクセス・ビットＫＳｉを修正して（３４）このページへのアクセスを許可したことを保存し、さらに、要求元タスクＴＡに対応する存在ビットＰｒｉＡを修正し（３５）（ビットは１に変更）、現在このタスクＴＡが問題のページＳｈＭＰＰｉへの排他的なアクセス権を有しているという情報を保存する。

なお、カーネル・メモリ構造ＫＭＳｔｒのアクセス・ビットＫＳｉのこれらの検査および変更オペレーションは、アトミックな方法で実施されるオペレーション３４となっており、すなわち、マルチプロセッサ環境下であっても、全面的に実施されるか、または全く実施されないかのどちらかとなる。

ページ・フォルト・ハンドラＰＦＨは、要求されたページＳｈＭＰｉに対する排他性を付与したらすぐに、このページの内容に実際にアクセスするよう命令ＩｎｓｔｒＡの実行を再開する。

その後、別のプロセッサμＰｒｏＹによって並列に実行されている別の任意の監視されているタスクＴＢからの命令ＩｎｓｔｒＢが、既に帰属されたこのページＳｈＭＰｉへのアクセスを要求した（３７）場合、このプロセッサの割り込みメカニズムＰＦＩｎｔＹも、要求元タスクＴＢのためにこのページの存在ビットＰｒｉＢを参照することになる。タスクＴＢは監視されるタスクなので、参照されている存在ビットＰｒｉＢは不在を表す位置（値は０）にある。そこで、割り込みメカニズムＰＦＩｎｔＹは、要求命令ＩｎｓｔｒＢを停止し、ページ・フォルト・ハンドラＰＦＨへエラーを伝送する（３８）だろう。

今度は、このページ・フォルト・ハンドラＰＦＨは、このページのアクセス・ビットＫＳｉが１であり、このページＳｈＭＰｉ上では別のタスクに排他性が与えられていることを示しているのに気づく。したがって、ページ・フォルト・ハンドラＰＦＨは、例えば活動期間をシステム・ソフトウェアのコンテキスト変更マネージャにおいて終了させるなどによって、要求元タスクＴＢ全体の停止を開始する（３９）。したがって、このタスクＴＢは、次の活動期間には、割り込みをかけられた正確なポイントまで実行を繰り返し、再度この同じページＳｈＭｐｉへのアクセスを試みることができるだろう。

要求元タスクが、マルチスレッド・プロセスに属するスレッドＴｈｒＢ２（図７）である場合、この単一のスレッドＴｈｒＢ２に特化した一連のページ・テーブル・エントリＰＴＥｉＢ２が存在しているため、既に排他的アクセスを割り当てられているページへのアクセスを要求したこのスレッドのみを停止し、排他性に抵触しないであろう別のスレッドＴｈｒＢ１については停止しないでおくことができる。

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

この停止ＳＣＨＡＳに際して、または既に割り当てられたページへの要求に対する停止（３９）に際して、本発明は、さらに、このタスクが排他的アクセス権を受けている全ての共有メモリ・ページに関する解放段階も想定している。したがって、スケジューラＳＣＨは、管理ビットＭｍＡを通じて停止中のタスクＴＡが監視されていることを感知（３０１）したら、このタスクの全ページ・テーブル・エントリＰＴＥｉＡ乃至ＰＴＥｋＡに目を通し、個別の存在ビットＰｒｉＡ乃至ＰｒｋＡの状態を参照することによって、どのページに対する排他的アクセス権を有しているのかを確定させる。次に、この情報に基づいて、カーネル・メモリ構造ＫＭＳｔｒの中のアクセス・ビットＫＳｉを０に再設定することで、これらのページＳｈＭＰｉを全て解放する。

他の例示されていない変形例においては、例えば単一のタスク・ディスクリプタの中にいくつかの管理ビットを想定することなどにより、管理または監視のコンセプトをいくつかの種類の管理に分離させることも可能である。このため、特定のカテゴリのタスクに関して排他的アクセスの利益を享受できるようにタスクを監視することもできる。同様に、タスクは、特定のカテゴリのタスクについてのみ除外されるようにしてもよい。

このように、既に割り当てが行われているページへのアクセスを求める全てのタスクを停止することによって、ここで停止された他のタスクの実行の一貫性を阻害することなく、最初に要求を行ったタスクがこのページの排他性を獲得することができる。

２つのタスクに共有されている単一のメモリ・ゾーンについてのあらゆる変更が同時に実行されるのを回避することによって、このメモリ・ゾーンの内容の変更の際２つのタスク間に何らかの干渉が生じるのを回避する。つまり、このメモリ・ゾーンの所定の初期状態以降、すなわちそこにアクセスするタスクの各活動期間の開始時以降のメモリ・ゾーンの内容の変化は、この活動期間におけるこのタスクの動作のみに依存することになる。したがって、例えばスケジュールされた活動期間などこのタスクによって実行されるある特定の命令のシーケンスが既知の初期状態から開始すれば、それにより決定論的でこのタスクに関して反復可能なシーケンスの実行が可能となる。

特に、アクセスされるメモリ・ゾーンにおける排他性の割り当てを保存するのにアトミックなオペレーションを使用しているため、この方法によって、競争的にアクセスを求める複数のタスク間で共有されている単一リソースのデッドロックの危険を回避または低減することが可能になる。

これらのアクセス制御技術（図７乃至図８）を上述の決定論的期間のロギング技術（図１から図５）、ならびに上記に引用した明細書に記載のチェックポインティング、ロギングおよび再生の技術を組み合わせることによって、本発明は、さらに、先に記載した様々な形式の機能管理を並列アーキテクチャ・システムにおいて実施することを提示している。

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

ログされたアプリケーションＡＰＰＪに関し、ロギング・エージェントＪＳＣＨは、各プロセッサμＰｒｏＸまたはμＰｒｏＹのために、監視されている別々のタスクＴＡ、ＴＢおよびＴＣの一連の全ての活動期間をログする。上述のように、ロギング・エージェントＪＳＣＨはそれらをそれぞれキューＱＪμＰｒｏＸおよびＱＪμＰｒｏＹとして別々に伝送する。なお、タスクが或るプロセッサで１回実行され、さらに別のプロセッサで１回実行された場合は、このタスクの活動期間は２つのキューに現れることになる。

ログされたアプリケーションＡＰＰＪによってアクセスされる共有リソースＳｈＭＰｉ乃至ＳｈＭＰｋについて、ロギング・エージェントＪＶＭＭは、各々のリソースに関してリソース上に割り当てられた一連の排他的アクセスを表すロギング・データを記録する。この排他的アクセスのロギング・データは、仮想メモリ・マネージャＶＭＭにおいて、別々のタスクに割り当てる排他的アクセスとともにページ・フォルト・ハンドラＰＦＨによって作成される。

このアクセス・ロギング・データの各記録は、具体的には次のものを含む。
−共有メモリ・ゾーンのアドレスなど当該共有リソースの一意の識別子。
−このアクセスを取得したタスクの識別子（ＰＩＤまたはＴＩＰ）。
−本明細書に記載のカウンティング技術などを通じて取得したこの排他的アクセスの継続期間。
−先に記載の署名のように、このカウンティングの不正確さを補償することのできる補足的なデータ。
−システム・リソースおよび様々な外部または入出力イベントの仮想化などに役立つ補足的なデータ。

このロギング・データは、ＦＩＦＯ形式のロギング・キューＱＪＳｈＭＰｉへと伝送される。

実施形態によっては、これらのキューＱＪμＰｒｏＸ、ＱＪμＰｒｏＹ、ＱＪＳｈＭＰｉの内容を１つ以上のログ・ファイルに保存して、例えば後から使用することなどができる。

これらのキューの中から、各種ロギング・データが、コンピュータ通信ネットワークなどの通信手段を用いて再生システムＵＰ２へと伝送される。

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

これらの再生キューの出力に際し、ログされた別個のプロセッサμＰｒｏＸおよびμＰｒｏＹのロギング・データはアクセス・ロギング・データにしたがって組み合わされ、それにより、ログされた活動期間の総合的なシリアライゼーションおよび割り当てられた（連続的な）排他的アクセスが復元されるようになる。

再生システムの内部では、この再生シリアライゼーションまたは再生スケジューリングの定義後に、再生プロセッサにおいて再生の実行が開始される。

なお、再生シリアライゼーションのスケジューリングを中断させない方法でタスクがプロセッサに分配されている以上、再生におけるパフォーマンスは別だが、再生プロセッサの数は重要視しなくてもよい。

なお、本明細書に記載された各種メカニズムでは、ソフトウェアの部分をハードウェアの部分から切り離したやり方で使用している。したがってハードウェアに対して十分な独立性が得られ、それにより特に実装の簡潔性および信頼性が高まり、さらに、プロセッサまたはコンピュータと想定される様々な計算エレメントの並列性をアーキテクチャが最良の状態で管理できるようになるため、優れた性能が保たれる。

さらに、本発明はほとんどの場合純粋にソフトウェアによって実施されるものであるため、標準的なハードウェアをそれが備えているであろう全ての利点と一緒に使用することができる。

本発明は、特に、単一の計算エレメントに関して共有された時間において機能するマルチタスク・アプリケーション用に開発された機能管理技術を、並列環境に拡張することを可能にしている。このように、本発明は、前述の並列環境をネットワークまたはクラスタと一体化させることができ、そこでは、この機能管理がミドルウェア・タイプのアプリケーションに実装され、それにより例えば「オンデマンド」のサービスを提供する分散型アプリケーションまたは可変展開型のアプリケーションを管理する。

当然ながら、本発明は、記載してきた例に制限されるものではなく、本発明の枠組みから離れることなく多数の修正を加えることが可能である。

本発明による、プロセッサにおけるタスクの実行のスケジューリングの、タスクのカウントによるロギングを示す図である。 本発明による、プロセッサにおけるタスクの実行のスケジューリングの、タスクのカウントによるロギングを示す図である。 本発明による、プロセッサにおける命令のカウントによるタスクの活動期間の再生を示す図である。 本発明による、プロセッサにおける命令のカウントによるタスクの活動期間の再生を示す図である。 本発明による、命令のカウントによってプロセッサにおけるタスク・スケジューリングのロギングから得られた、単一プロセッサにおけるマルチタスク・アプリケーションの決定論的な再生を示す図である。 先行技術による、単一の環境からの２つの異なるプロセッサにより並列に実行される２つのタスク間で共有されるメモリへのアクセス機能を示す図である。 本発明による、単一環境からのいくつかの異なるプロセッサ上で並列に実行される多数のタスク間で共有されるメモリ・ページへのアクセスの制御を可能とする構造を、タスクにおいて構築および維持することを示す図である。 本発明による、単一環境からの２つの異なるプロセッサ上で並列に実行される２つのタスクによって共有されるメモリ・ページへのアクセスを制御する機能を示す図である。 本発明による、マルチプロセッサ・コンピュータ上のマルチタスク・アプリケーションのロギング、および状況に応じて行われる単一プロセッサ・マシン上での再生を示す図である。

Claims (2)

1. 少なくとも２つのアプリケーション・タスク（ＴＡ、ＴＢ）の機能を管理する方法であって、前記方法は、少なくとも２つの演算ユニット（μＰｒｏＸ、μＰｒｏＹ）において複数のアプリケーション・タスクを同時に実行することのできる複数の計算手段を備えた並列構造のコンピュータ・システムにおいて前記少なくとも２つのアプリケーション・タスク（ＴＡ、ＴＢ）の実行を順次活動化によって管理するシステム・ソフトウェア内に実装され、前記少なくとも２つのアプリケーション・タスク（ＴＡ、ＴＢ）は少なくとも１つの共有リソース（ＳｈＭＰｉ）にアクセスし、
   前記方法は、
   第１の演算ユニット（μＰｒｏＸ）における前記ＴＡの第１の継続する活動期間をロギングするステップと、
   第２の演算ユニット（μＰｒｏＹ）における前記ＴＢの第２の継続する活動期間をロギングするステップと、
   前記少なくとも１つの共有リソースへのアクセス要求（ＩｎｓｔｒＡ）に応じて、前記ＴＡ及び前記ＴＢのうちのアクセス元アプリケーション・タスクに対して前記少なくとも１つの共有リソースのうちのターゲット・リソース（ＳｈＭＰｉ）への排他的アクセスの一連の帰属をロギングするステップであって、前記排他的アクセスの一連の帰属をロギングすることが、前記アクセス要求の直後から前記アクセス元タスクの活動期間（ＳｃｈＡ）の残りの全期間を通して、前記タスクのうちの別のタスクによる前記ターゲット・リソース（ＳｈＭＰｉ）へのアクセスを全て排除するような帰属をロギングすることである、前記ロギングするステップと
   を含み、
   前記排他的アクセスの一連の帰属をロギングするステップが、
   前記ターゲット・リソース（ＳｈＭＰｉ）の一意の識別子と、
   アクセスを取得したアプリケーション・タスクに関連付けられた識別子と、
   前記ターゲット・リソース（ＳｈＭＰｉ）へのアクセスを取得したアプリケーション・タスクによる排他的アクセスの継続期間と
   を記録するステップと、
   ＦＩＦＯキューへ前記記録されたロギング・データをロギングされた順番の通りに伝送するステップであって、当該伝送により各アプリケーション・タスク内で前記ターゲット・リソース（ＳｈＭＰｉ）に対する一連の活動期間の順序を保つ、前記伝送するステップと
   を含む、
   前記方法。
2. 請求項１に記載の方法を実行するコンピュータ・システム。

Images