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