JP2009507299A - 決定性処理を遂行するシステム及び方法 - Google Patents

Abstract

非決定性コンピュータシステムで決定性処理を遂行するシステム及び方法が提供される。一実施例において、システムは、１つ以上のコンピュータ命令の実行が一定の実行時間内で実行されるよう強制する。決定性エンジンは、コンピュータ命令の実行が一定の実行時間にわたって遂行されることを保証するため、必要に応じ、不定の時間量にわたり待機する。実行時間は一定であるから、その実行は決定性であり、それ故決定性挙動を要するアプリケーションにおいて使用することができる。例えば、自動テスト装置（ＡＴＥ）アプリケーションにおいてかかる決定性エンジンを使用することができる。

Description

発明の背景
１．発明の分野
本発明は、一般的には処理に関し、より具体的には非決定性コンピュータシステムにおける処理に関する。

２．関係技術の論述
自動テストシステム（ＡＴＥ）で成功の鍵を握るのは再現性である。再現可能テストシステムを得るということは、２つの同じデバイスにおける所定テストシーケンスの実行から同じ結果が出ることを意味する。したがって、もしもテストの対象となる全デバイスに適用される刺激が同じなら、そのテスト結果は信頼できるソースとしてデバイス品質の査定に用いることができる。「同じ」刺激とは、関係テスト条件（電圧、電流、温度、その他）の係数が同じであることを意味するばかりでなく、テスト条件が適用される相対的時間が同じであることをも意味する。

今日、ＡＴＥ分野におけるテスト装置のほとんどは１つ以上のコンピュータシステムを伴う。このため、テストステップを実施するコンピュータシステムは、全体的な決定性が保たれるようにこれらのテストステップを決定的に生成しなければならない。かかるコンピュータに伴う１つの問題にコストがある。テスト用として相応しい完全なコンピューティングシステム（例えば一貫性のある結果を出すもの）の設計には、高価なハードウェア設計とメンテナンスとが要求されるばかりでなく、オペレーティングシステム、ユーザインターフェイス、ドライバ、ツール、その他を含む高価なソフトウェア設計をも要求される。その結果、ＡＴＥに相応しいコンピュータシステムは、ほとんどの企業にとって、その購入とメンテナンスにあたって非常に高くつく。

かかるシステムのコストを抑える１つの方法として、既製のコンピュータコンポーネント及びシステムの使用がある。ただし上述した決定性要求のため、既製の汎用コンピュータシステムは概してかかる用途にとって相応しくない。もしも汎用コンピュータシステムをＡＴＥで使用することができるなら、ＡＴＥの所有・運転コストを抑えることができる。

発明の要旨
本発明の一態様によると、決定性処理を遂行するシステムが提供される。このシステムは、１つ以上の命令を実行するように構成される処理実体と、１つ以上の命令の実行時間を一定の値となるよう調整するように構成されるコンポーネントとを備える。一実施形態によると、コンポーネントは、実行時間を１つ以上の命令の最大実行時間となるよう調整するように構成されている。別の実施形態によると、コンポーネントは、１つ以上の命令の実行時間を、１つ以上の命令の複数の実行にわたって同じ一定値となるよう調整するように構成されている。別の実施形態によると、複数の実行は異なるコンピュータシステムで起こる。別の実施形態によると、異なるコンピュータシステムは異なる処理能力を有する。別の実施形態によると、コンポーネントは、１つ以上の命令の実行を所定の期間内に遂行するように構成されている。別の実施形態によると、コンポーネントは、実行時間を一定値に調整するためある期間にわたり待機するように構成されている。

一実施形態によると、システムはさらに時間基準を備え、ここでコンポーネントはこの時間基準を用いて相対的時間を判定するように構成されている。別の実施形態によると、コンポーネントは、プロセッササイクルのカウンタ値に基づき相対的時間を判定するように構成されている。別の実施形態によると、時間基準はインターフェイスを含み、ここでコンポーネントは、このインターフェイスを通じて処理サイクルのカウンタを入手するように構成されている。別の実施形態によると、コンポーネントは、１つ以上の命令の実行に使われる時間量を判定するように構成されており、さらに実行時間を一定値に調整するためある期間にわたり待機するように構成されている。別の実施形態によると、コンポーネントは、複数のカウンタ値に基づき経過時間を判定するように構成されている。別の実施形態によると、カウンタ値はプロセッサのタイムスタンプカウンタである。別の実施形態によると、プロセッサはＰＥＮＴＩＵＭ（登録商標）タイプのプロセッサである。別の実施形態によると、システムは自動テストシステムの一部である。

本発明の一態様によると、決定性処理を遂行するためにコンピュータ実装される方法が提供される。この方法は、コンピュータシステムで１つ以上の命令を実行する動作と、実行する動作の実行時間を測定する動作と、実行時間を一定値に調整するためある期間にわたり待機する動作とを備える。別の実施形態によると、ある期間にわたり待機する動作は、実行する動作の後に一定値の実行時間が経過するまである期間にわたり待機することを含む。別の実施形態によると、方法は、１つ以上の命令の実行を測定する動作と、測定する動作に基づき１つ以上の命令の最大実行時間を判定する動作とをさらに備える。別の実施形態によると、方法は、一定値を最大実行時間に設定する動作をさらに備える。別の実施形態によると、方法は、１つ以上の命令の最大実行時間を判定する動作をさらに備える。別の実施形態によると、方法は、一定値を最大実行時間に設定する動作をさらに備える。

一実施形態によると、方法は、１つ以上の命令の実行時間を１つ以上の命令の複数の実行にわたって同じ一定値となるよう調整する動作をさらに備える。別の実施形態によると、複数の実行は異なるコンピュータシステムで起こる。別の実施形態によると、異なるコンピュータシステムは異なる処理能力を有する。別の実施形態によると、方法は、コンピュータシステムで１つ以上の命令を実行する動作を所定の期間内に遂行する動作をさらに備える。別の実施形態によると、方法は、実行時間を一定値に調整するためある期間にわたり待機する動作をさらに備える。別の実施形態によると、方法は、相対的時間を判定する動作をさらに備える。

一実施形態によると、方法は、時間基準を提供する動作と、時間基準を用いて相対的時間を判定する動作とをさらに備える。別の実施形態によると、方法は、プロセッササイクルのカウンタ値に基づき相対的時間を判定する動作をさらに備える。別の実施形態によると、方法は、１つ以上の命令の実行に使われる時間量を判定する動作と、実行時間を一定値に調整するためある期間にわたり待機する動作とをさらに備える。別の実施形態によると、方法は、複数のカウンタ値に基づき経過時間を判定する動作をさらに備える。別の実施形態によると、カウンタ値はプロセッサのタイムスタンプカウンタである。別の実施形態によると、プロセッサはＰＥＮＴＩＵＭ（登録商標）タイプのプロセッサである。別の実施形態によると、方法は自動テストシステムによって遂行される。

本発明のさらなる特徴及び利点、ならびに本発明の様々な実施形態の構造及び作動を、添付の図面を参照しながら以下に詳述する。図面において、同様の参照番号は同様のまたは機能的に類似する要素を指す。加えて、参照番号の左端から１つ目または２つ目までの数字は、その参照番号が最初に現れる図面を識別する。

添付の図面は実寸で描かれることを意図していない。図面において、様々な図に描かれている同じまたはほぼ同じコンポーネントは同様の番号で表されている。明確にするため、全ての図面で全てのコンポーネントに標示が付されているとは限らない。

詳細な説明
本発明用途は、以降の説明に記載された、または図面に描かれた、構造の詳細とコンポーネントの配置とに限定されない。本発明はほかの実施形態が可能であり、様々な仕方で実践または遂行できる。また、ここで用いる言葉遣いと用語は説明を目的とするものであって、制限するものとみなすべきではない。ここでの「含む（ｉｎｃｌｕｄｉｎｇ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、または「有する（ｈａｖｉｎｇ）」、「包含する（ｃｏｎｔａｉｎｉｎｇ）」、「含む（ｉｎｖｏｌｖｉｎｇ）」、ならびにこれらのバリエーションの使用は、後ろに続く品目とその同等物を、ならびに付加的品目を、網羅することを意味する。

決定性処理を遂行するためのシステム及び方法が提供される。本発明の一態様によると、決定的結果を要するシステムで非決定性コンピュータシステムを実装すると有益な場合がある。例えば汎用のコンピュータシステム、プロセッサ、及び／またはソフトウェアを実装すると、かかるシステムの所有・保守コストを抑えるのに役に立つ場合がある。一実施例において、ＡＴＥシステムを実装する汎用コンピュータシステムのコストは専用システムの１０分の１である。この目的を果たすため、かかる非決定性システムが決定的に作動することを可能にするための方法が提供される。

本発明の一態様によると、テストエンジニアによって使用されるＡＴＥシステム等の決定性システムには数通りの態様が認められる。
（ａ）テストエンジニアが以降のテストステップの基準となる基準時間（例えば時間ゼロ（ｔ_０））として参照できる緩和点がある。
（ｂ）基準時間（ｔ_０）を基準とする所定の相対的時間にテストステップを開始する決定性テストスケジューラがある。

条件（ａ）は従来のシステムを用いて容易く満たされ、その実装は概して取るに足りない。例えばデバイスは、基準時間ｔ_０にて刺激から切断でき、その温度は部屋（ハンドラ）温度に設定される。同時にテストエンジニアはテストシステムにて刺激を「テスト開始」（ＳＯＴ）条件に設定できる。

しかし条件（ｂ）を満たすことはより困難である。一実施例において、条件（ｂ）を満たすための解決策は、安定的な時間基準を用いてテストステップを実行するシーケンス回路を含む。もしも純粋なシーケンス回路としてコンピュータを設計するならば、そのコンピュータのために記述されるプログラムは、テストステップを決定的に生成するシーケンサである。ただしそのようなコンピュータは通常、ステップの決定的遂行を徹底するため特別に開発されたオペレーティングシステムと対応するアプリケーションプログラムとを要する。

本発明の一態様によると、例えばもしも既製コンピュータを使って条件（ｂ）を満たそうとしたならば問題が生じる。具体的に、汎用コンピュータシステムの場合、そのハードウェア及びソフトウェア設計は最大性能の達成を試みる。ＡＴＥプログラムの実行の場合、汎用コンピュータは何としても全てのテストステップを可能な限り速やかに完了することを試みるであろう。本発明の一態様によると、条件（ｂ）は、現在の既製コンピュータと関連ソフトウェアの場合のように可能な限り速やかに遂行するのではなく、所定の時間に新しいテストステップを開始することを規定している。

現在の既製コンピュータは、例えばキャッシュメモリ、パイプライン、複数実行パス（探索的実行）、分岐予測等を含む様々なメカニズムを用いて最大性能を達成する。これらのメカニズムのほとんどは、プロセッサ状態の既往の及び／または現在のコンテキストに依拠する学習推測に基づき決定を下す。つまり、実行の履歴（またはパターン）（例えば、データにアクセスしたことがある等）に基づき次のタスクステップを予測する（例えば、何らかのデータがキャッシュメモリにロードされる、各パイプラインレベルで復号化されている命令は何か、何らかのデータがディスクから取得される等）。勿論、推測を誤ると性能が損なわれ、タスクの実行速度は落ちる。さらに、かかるメカニズムは他のプログラムの性能に、及び／またはコンピュータのオペレーティングシステム状態に、左右されるから、概して異なるランタイムに異なる動きをする。結果的に、コンピュータ性能を向上させる今日の手法のほとんどは、システム内の数々の不定要因のため、性能を予測することが、及び／または再現することが、困難なコンピュータシステムに帰結し、不定要因の多くはランタイムに定まる。

性能を予測することが困難なため、ほとんどのＡＴＥ会社はシステム設計時に上述の条件（ｂ）を無視し（これは設計コストの増大を理由に正当化される）、満足な再現性が達成されるまでテストアプリケーションを調整する問題はテストエンジニアにまかせる。勿論、テストアプリケーションを綿密に調整することは条件（ｂ）を模擬するひとつの戦略ではあるが、この戦略は面倒であり、できあがったアプリケーションはすこぶる脆弱である。基礎となるコンピュータハードウェアまたはソフトウェアの作動パラメータまたは構成に変更があると、このカスタム調整に影響が及び、決定性オペレーションを失うおそれがある。

よって、ＡＴＥシステム等の決定性アプリケーションにとっては、再現性に優れるシステムをもたらすばかりでなく、基礎となるコンピュータハードウェア及びソフトウェアから独立したシステムをももたらす手法が有益だろう。本発明の一態様によると、もしもコンピュータオペレーションの最大実行時間を予測できるならば、コンピュータオペレーションに決定的に作動することを強いることができる。より具体的に、もしもコンピュータオペレーションを最大実行時間で遂行できるなら、コンピュータシステムの実行は予測可能である。一実施例においては、ある特定のオペレーションを適切な実行時間に遂行するため、コンピュータのオペレーション実行を遅らせることができる。

本発明の一態様によると、汎用コンピュータシステムのための決定性エンジンが提供される。一実施形態によると、決定性エンジンは、命令セットの合計実行時間を一定にすることができる。所望の合計実行時間が最大実行時間に等しいかこれを上回るなら、合計実行時間を一定の値に設定できる。最大実行時間は、関与する命令を解析することによって（さらにその最大実行時間を測定することによって）、または様々なプロセッサコンテキストにおける命令セットの実行によって経験的に、判定することができる。

所望の実行時間は一定値として設定されるから、実際の実行時間が最大実行時間を超過しないと仮定すると、異なるコンピュータシステムで実行時間は同じになる。より豊富な能力とより高い性能を有する新しいプロセッサが導入されており、かかる決定性エンジンを利用するソフトウェアアプリケーションは、決定的挙動をなくさずにこれらの新しい環境に移すことができる。つまり、所望実行時間はある１つのコンピュータシステムにおける最大実行時間より長いから、命令セットの最大実行時間がこれよりも短いより有能なコンピュータシステムにソフトウェアアプリケーションを移すことができる。かくしてソフトウェアアプリケーションは異なるコンピュータシステムで実行されるときに決定的に作動でき、システムからシステムにかけてアプリケーション設計投資は保護される。能力が劣るシステムや疑わしいシステムへアプリケーションを移す場合は、設計最大実行時間を
超過しないことを確認するため検証を行うことができる。

汎用コンピュータシステム
本発明による様々な実施形態は１つ以上のコンピュータシステムで実装できる。これらのコンピュータシステムは、例えばＩｎｔｅｌ ＰＥＮＴＩＵＭ（登録商標）タイププロセッサ、Ｍｏｔｏｒｏｌａ ＰｏｗｅｒＰＣ、ＡＭＤ ＡｔｈｌｏｎまたはＴｕｒｉｏｎ（登録商標）、Ｓｕｎ ＵｌｔｒａＳＰＡＲＣ、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ ＰＡ−ＲＩＳＣ（登録商標）プロセッサに、またはタイプの異なるその他のプロセッサに、基づく汎用コンピュータ等、汎用コンピュータであってよい。本発明の様々な実施形態による決定性処理を遂行するため、１つまたは複数のどんなタイプのコンピュータシステムでも使用することができることは理解されよう。さらに、システムは単一のコンピュータ上に位置してよく、あるいは通信ネットワークによって接続された複数のコンピュータに分散してよい。

本発明の一実施形態による汎用コンピュータシステムは、テストプログラムのテストステップを遂行することを含みただしこれに限定されない、説明する決定性機能のいずれかを遂行するよう構成される。決定性機能を要する別の用途を含む別の機能をシステムが遂行できること、そして本発明が特定の機能を、または機能セットを、有することに限定されないことは理解されよう。

図１は、本発明の様々な態様を実践できる汎用コンピュータとネットワークシステムのブロック図を示す。例えば本発明の様々な態様は、図１に示す汎用コンピュータシステム１０１を含む１つ以上のコンピュータシステムで実行する特化ソフトウェアとして実装できる。コンピュータシステム１０１は、ディスクドライブ、メモリ、データを格納するその他のデバイス等、１つ以上のメモリデバイス１０５へ接続されたプロセッサ１０４を含んでよい。メモリ１０５は通例、コンピュータシステム１０１の作動中にプログラムとデータとを格納するために使われる。コンピュータシステム１０１のコンポーネントはネットワーク１１０等の相互接続メカニズムによって結合されてよく、この相互接続メカニズムは１つ以上のバス（例えば、同一マシンの中で一元化されたコンポーネント間）、及び／またはネットワーク（例えば、別個のマシンに存在するコンポーネント間）を含んでよい。相互接続メカニズムは、システム１０１のシステムコンポーネント間で通信（例えばデータ、命令）のやり取りを可能にする。

コンピュータシステム１０１はまた、１つ以上の入力／出力（Ｉ／Ｏ）装置１０６を、例えばキーボード、マウス、トラックボール、マイクロフォン、タッチスクリーン、印刷装置、ディスプレイ画面、スピーカー、その他を含む。加えてコンピュータシステム１０１は、コンピュータシステム１０１を通信ネットワークへ接続する１つ以上のインターフェイス（例えば、ネットワーク通信デバイス１０８）を、ネットワーク１１０に加えて、またはこれの代わりに、包含してよい。

ストレージシステム１０９は通例、コンピュータ読み取り可能・書き込み可能不揮発性記録媒体を含み、ここに格納される信号は、プロセッサによるプログラムの実行を、または媒体に格納された情報のプログラムによる処理を、規定する。媒体は、例えばディスクまたはフラッシュメモリであってよい。通例、作動中はプロセッサによって不揮発性記録媒体から別のメモリへデータが読み込まれ、こうすることによりプロセッサによる情報へのアクセスは媒体より速くなる。このメモリは通例、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）やスタティックメモリ（ＳＲＡＭ）等、揮発性のランダムアクセスメモリである。メモリは、図示されたとおりストレージシステム１０９に位置してよく、あるいはメモリシステム１０５に位置してよい。プロセッサ１０４は普通、集積回路メモリ１０４の中でデータを操作し、処理が完了した後にはストレージ１０９と連携する媒体へデー
タをコピーする。媒体と集積回路メモリ素子との間でデータ移動を管理するにあたっては様々なメカニズムが知られており、本発明はこれに限定されない。本発明は特定のメモリシステムまたはストレージシステムに限定されない。

コンピュータシステムは、特別にプログラムされた専用ハードウェアを、例えば特定用途向け集積回路（ＡＳＩＣ）を、含んでよい。本発明の態様は、ソフトウェア、ハードウェア、またはファームウェア、またはこれらの組み合わせで実装できる。さらに、かかる方法、動作、システム、その構成要素及びコンポーネントは、上述したコンピュータシステムの一部として、または独立コンポーネントとして、実装できる。

コンピュータシステム１０１は、本発明の様々な態様を実践できるコンピュータシステムの一種として例示されているが、本発明の態様が図１に示すコンピュータシステムでの実装に限定されないことは理解されよう。本発明の様々な態様は、図１に示されたものとは異なるアーキテクチャまたはコンポーネントを有する１つ以上のコンピュータで実践できる。

コンピュータシステム１０１は、高級コンピュータプログラミング言語を用いてプログラムできる汎用コンピュータシステムであってよい。コンピュータシステム１０１はまた、特別にプログラムされた専用ハードウェアを用いて実装できる。コンピュータシステム１０１において、プロセッサ１０４は通例、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎから入手できる周知のＰｅｎｔｉｕｍ（登録商標）クラスのプロセッサ等、市販のプロセッサである。このほかにも数多くのプロセッサが入手可能である。

かかるプロセッサは普通、オペレーティングシステムを実行し、同オペレーティングシステムは、例えばＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから入手できるＷｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステム（例えば、Ｗｉｎｄｏｗｓ ＮＴ（登録商標）、Ｗｉｎｄｏｗｓ ２０００（Ｗｉｎｄｏｗｓ ＭＥ（登録商標））、Ｗｉｎｄｏｗｓ ＸＰオペレーティングシステム）、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒから入手できるＭＡＣ ＯＳ Ｓｙｓｔｅｍ Ｘオペレーティングシステム、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓから入手できるＳｏｌａｒｉｓオペレーティングシステム、または様々な供給元から入手できるＵＮＩＸ（登録商標）オペレーティングシステムであってよい。このほかにも数多くのオペレーティングシステムを利用でき、本発明は特定のオペレーティングシステムに限定されない。

プロセッサとオペレーティングシステムとによってコンピュータプラットフォームが決まり、このコンピュータプラットフォームに向けて高級プログラミング言語によるアプリケーションプログラムが記述される。１つ以上の請求項によって指定される場合を除き、本発明がある特定のコンピュータシステムプラットフォーム、プロセッサ、オペレーティングシステム、またはネットワークに限定されないことは理解されよう。また、本発明が特定のプログラミング言語またはコンピュータシステムに限定されないことは当業者にとって明白であろう。さらに、他の適切なプログラミング言語を、そして他の適切なコンピュータシステムを、使用することができることは理解されよう。

コンピュータシステムの１つ以上の部分は、通信ネットワークへ結合された１つ以上のコンピュータシステムに分散してよい。これらのコンピュータシステムもまた汎用コンピュータシステムであってよい。例えば、１つ以上のクライアントコンピュータへサービスを提供するべく構成された、または分散システムの一部として全体的タスクを遂行するべく構成された、１つ以上のコンピュータシステム（例えばサーバ）に本発明の様々な態様を分散してよい。例えば、本発明の様々な実施形態に従って様々な機能を遂行する１つ以上のサーバシステムに分散されたコンポーネントを含む、クライアント−サーバまたは多
層システムで、本発明の様々な態様を遂行できる。これらのコンポーネントは、通信プロトコル（例えばＴＣＰ／ＩＰ）を用いて通信ネットワーク（例えばインターネット）上で伝達される実行可能コード、中間コード（例えばＩＬ）、またはインタープリタ型コード（例えばＪａｖａ（登録商標））であってよい。

本発明が特定のシステムまたはシステムのグループでの実行に限定されないことは理解されよう。また、本発明が特定の分散アーキテクチャ、ネットワーク、または通信プロトコルに限定されないことは理解されよう。

本発明の様々な実施形態は、ＳｍａｌｌＴａｌｋ、Ｊａｖａ（登録商標）、Ｃ＋＋、Ａｄａ、Ｃ＃（Ｃ−Ｓｈａｒｐ）等、オブジェクト指向プログラミング言語を用いてプログラムできる。このほかのオブジェクト指向プログラミング言語を使用することもできる。代わりに、関数型言語、スクリプト言語、アセンブリ言語、及び／または論理プログラミング言語を使用することができる。本発明の様々な態様は非プログラム型環境で実装できる（例えば、ブラウザプログラムのウィンドウで見るときにグラフィカルユーザインターフェイス（ＧＵＩ）の態様を表示する、またはその他の機能を遂行する、ＨＴＭＬ、ＸＭＬ、その他形式で作成された文書）。本発明の様々な態様は、プログラム型構成要素、または非プログラム型構成要素として、あるいはこれらの組み合わせとして、実装できる。

このシステムの様々な態様は、システム１００の中の１つ以上のシステムによって実装できる。例えば、システムはシングルまたはマルチプロセッサシステムであってよい。一実施例において、システムはパーソナルコンピュータ（ＰＣ）等のシステムで実行するソフトウェアプロセスを含む。かかるシステムは、例えば決定的挙動を要する１つ以上の機能をユーザが遂行することを可能にする。かかるシステムは、例えば数ある中でテストシステム、制御システム、航空宇宙業界で使われているシステムを含み得る。
システムアーキテクチャ例
図２は、本発明の一実施形態によるシステム例のアーキテクチャ図を示す。図２が専ら例証用であること、そして本発明の１つ以上の態様を促進するためほかのアーキテクチャを使用することができることは理解されよう。

図２に示すとおり、コンピュータシステム２００（例えば、図１を参照しながら上述した汎用コンピュータシステム）は決定性システムを実装するため使用することができる。コンピュータシステム２００は、アプリケーションプログラム２０４が決定的に作動することを可能にする決定性エンジンプログラム２０１を含んでよい。本発明の一実施形態によると、システム２００は決定性システムでなくともよく、図１を参照しながら上述した汎用コンピュータシステムであってもよい。この目的を果たすため、システム２００はオペレーティングシステム２０２と、１つ以上のプロセッサ２０３と、１つ以上のＩ／Ｏコンポーネント２０６とを含んでよい。任意に、コンピュータシステム２００は、アプリケーションプログラムのリアルタイム作動を支援するリアルタイムオペレーティングシステムを、及び／またはリアルタイムコンポーネント２０５を、含んでよい。かかるリアルタイムコンポーネントは、例えばオレゴン州ビーバートンのＴｅｎＡｓｙｓ Ｃｏｒｐｏｒａｔｉｏｎから市販されているＩＮｔｉｍｅリアルタイムプログラミングエクステンションを含む。

本発明の一実施形態による決定性エンジンは、コンピュータシステム２００でオペレーションが実行されるときを判定するため安定的な時間基準を提供する。決定性エンジンプログラムはさらに、他のプログラムに対して指示を提供することができ、オペレーションが実行されるべきときを指示することができる。

上述したとおり、ある特定のオペレーションの、またはオペレーションのセット（例え
ばコンピュータ命令）の、最大実行時間は判定できる。最大実行時間は、例えばオペレーションの実行の直接的測定によって判定（例えば多数の実行にわたって判定）でき、あるいは公知の方法を用いて発見的に判定できる。あるコンピュータシステム（例えばコンピュータシステム２００）によるオペレーションの実行が最大実行時間を超過しない場合、そのコンピュータシステムには決定的に作動することを強いることができる。

上記のコンセプトを実装するソリューションを求めるため、オペレーションを、任意の回数で繰り返すことのできるコンピュータタスクとして、そしてその実行時間を測定できるものとして、検討する。

以下の定理を立てる。
もしもオペレーション実行の時間に上限があるなら、オペレーション実行を一定の実行時間に強制することは可能である。

証明：Ｏはオペレーションを表すとする。オペレーションＯは反復可能だから、Ｔ_０（ｎ）は、オペレーションＯがｎ回目の実行に要する時間と定義できる。この定理はオペレーションＯの時間に上限があると仮定しているから、Ｔ_ｍａｘが存在し、以下の等式は真である：

ここでオペレーションは定義できると仮定し、これ以降オペレーションｗａｓｔｅと呼び、その実行時間は以下の等式によって定義する。

ここで値Ｅは、オペレーションｗａｓｔｅが実行するときに生じる固有誤差（例えばオーバーヘッド）である。もしもコンピュータシステムがオリジナルのオペレーションの実行のたびにオペレーションｗａｓｔｅを実行できるなら、合同実行時間は一定値である。

上記の定理は、既述の特性を持つオペレーションとして実装できる。つまりオペレーションは、合同実行が一定値となるよう時間を浪費するものと定義できる。よって実行時間は一定であり、それ故予測可能だから、例えば汎用コンピュータシステム等の非決定性システムでオペレーションを決定的に実行することは可能である。

よって、もしも１セットのオペレーションの実行時間を一定の実行期間内に限定できるなら、その実行は予測可能であり、それ故再現可能である。図３は、本発明の一実施形態に従い決定性処理を遂行するプロセス例３００を示しており、ここで総実行時間は一定に保たれる。プロセス３００はブロック３０１で始まる。ブロック３０２では最大実行時間
を判定する。例えば、１つ以上のオペレーションの最大実行時間を、測定により、発見的に、その他により、判定できる。ブロック３０３では１つ以上のオペレーションが実行され、経過時間の測定が行われる。ブロック３０４で、決定性エンジンはオペレーションの合計実行時間が一定値となるよう判定最大実行時間まで遅延する。プロセス３００はブロック３０５で終わる。

上述したとおり、決定性エンジンプログラムによって安定的な時間基準が提供されるため、経過時間を測定できる。一実施形態によると、決定性エンジンプログラムは、プロセッサによって、または決定性エンジンが実行するところのコンピュータシステムのその他の構成要素によって、提供される情報に基づき時間を判定できる。一実施例において、決定性エンジンは、周知のＰＥＮＴＩＵＭ（登録商標）タイプのプロセッサを内蔵するＩｎｔｅｌベースの汎用コンピュータシステムで実行する。例えば、ＰＥＮＴＩＵＭ（登録商標）クラスのプロセッサとともに導入されたＣＰＵ命令ＲＤＴＳＣ（ｒｅａｄ ｔｉｍｅｓｔａｍｐ ｃｏｕｎｔｅｒ）は、プロセッサが最後にリセットされたときから経過したクロックサイクル数を読み取る。タイムスタンプカウンタは６４ビット幅であり、コンピュータの寿命より長きにわたり十分なデータを提供する（１．０ＧＨｚで、タイムスタンプカウンタは５８４年以上たって繰り越される）。

もしもコンピュータシステム（例えば決定性エンジン）が解析対象コード部分の前後でタイムスタンプカウンタを読み取るなら、２つの測定値の差は、問題のコードの実行に費やされた総ＣＰＵクロックサイクル数を提供する。残された唯一の問題は、このクロックサイクル数をいかに時間に結び付けるかである。オペレーションＯの実行に費やされるクロックサイクル数をｋと仮定し、以下の等式はそのオペレーションを実行する時間を求める。

ここで、ｆ_ｃｐｕはＣＰＵクロック周波数である。残念ながらＣＰＵクロック周波数を取得するＣＰＵ命令はないから、この値を提供する方法は開発する。
ＣＰＵ周波数の測定
一実施例において、プログラム可能タイマーは１．１９３１８１ＭＨｚの公知の固定カウント周波数を有する。もしもコンピュータプログラムがオペレーションの前後にタイマーカウンタを読み取ることができるなら、実行されるオペレーションの実行時間を判定することは可能である。オペレーションＯの実行に費やされるタイマーカウント数をｋ_ｔとすると、そのオペレーションを実行する時間は次のとおりに判定される。

もしも説明した両方の方法が同じオペレーションＯに適用されるなら、実行時間Ｔ_０はまったく同じであり、以下の等式に帰結する。

最後に、

上記の論述に基づき、上述したオペレーションｗａｓｔｅ Ｗ（ｎ）の例を等式（２）で実装することが可能となる。
（ａ）タイムスタンプカウンタを読み取り、保存する。
（ｂ）オペレーションＯを実行する。
（ｃ）保存したタイムスタンプカウンタへＴ_ｍａｘに等しいクロックサイクル数を加える。この値はｋ_ｅｎｄと呼ぶことができる。
（ｄ）タイムスタンプカウンタを読み取る。
（ｅ）タイムスタンプカウンタの値がｋ_ｅｎｄに満たない間は（ｄ）へループする。

以下のことに注意されたい。
・等式（２）及び（３）に提示された誤差Ｅはステップ（ａ）、（ｃ）、（ｄ）、及び（ｅ）によるものである。
・ステップ（ｄ）及び（ｅ）の実行にはある程度の時間がかかるため、このループは誤差Ｅに変動（ループ誤差）を引き起こすことがある。
・シーケンス（ａ）〜（ｅ）はここで決定性オペレーションＯ_Ｄと呼ぶ。
・オペレーション（ａ）及び（ｃ）〜（ｅ）はここで、決定性エンジンによって遂行される決定性エンベロープまたは関数と呼ぶ。

図４は、本発明の一実施形態による決定性処理の遂行に使われるシステム４００の一実施例を示す。より具体的に、システム４００は上述したオペレーションの内１つ以上を実装できる決定性エンジン４０６を含む。システム４００は、決定性エンジン４０６と外部実体４０３とを含む。外部実体４０３は、例えば決定性エンジンを使って１つ以上のオペレーションを決定的に遂行させるハードウェア及び／またはソフトウェアコンポーネント（例えばアプリケーション）であってよい。

決定性システム４０６は、時間基準４０１とプロセッサ４０２とを含む。時間基準４０２は時間保守オペレーションを遂行する。プロセッサ４０２は、例えば決定性エンジン４０６の１つ以上の機能を遂行する汎用コンピュータシステムで実行するソフトウェアプログラムを含んでよい。エンジン４０６は、最大実行時間を一定値に保つことを促進するため指示を受け付けることができる、及び／または提供することができる。この目的を果たすため、プロセッサは１つ以上の指示４０４を外部実体４０３へ提供することができる。同様に、外部実体４０３は１つ以上の指示４０５をプロセッサ４０２へ提供することができる。

図４に示す実装例では、時間の経過を追跡するため時間基準４０１が提供される。時間基準４０１はまた、既知イベントからの時間による距離と（直接的に、または間接的に）相関する値を提供する。この値は時間の経過に伴い絶えず変化する。この値はここでタイムカウントと呼ぶ。

また、タイムカウントの変動に照らして時間単位をプロットする数学関数を使用することができる。換言するとこの数学関数は、２つのタイムカウント値の差をもとに、２つのタイムカウント値が得られた２つの瞬時の間にどれだけ時間が経過したかを指摘する。この数学関数はこれ以降デルタタイム関数と呼ぶ。

ある特定の時間基準の実装とデルタタイム関数の実装で、いかなる２つの連続するタイムカウント値の間の差と関連した最大タイムスパンがある。この最大タイムスパンは以下において時間基準分解能と呼ぶ。

一実施例において、時間基準４０１は外部実体へ至るインターフェイスを提供する。このインターフェイスは、プロセッサが時間基準からタイムカウント値を入手することを可能にする。プロセッサが時間基準にタイムカウントを要求するときには、プロセッサによる要求の発行とプロセッサシステムによるタイムカウントの受領との間に遅延が生じることがある。この遅延はここでインターフェイス遅延と呼ぶ。一実施形態によると、このインターフェイス遅延はどんなインターフェイス実装でも予測可能である。特定のインターフェイス実装で、最小インターフェイス遅延と最大インターフェイス遅延との差はインターフェイスジッタと呼ばれる。

図５は、本発明の一実施形態に従い決定性オペレーションを遂行するプロセス５００を示す。例えば図４を参照しながら上述したシステム４００の１つ以上の構成要素によって、プロセッサ５００に関連する１つ以上の動作を遂行できる。

プロセス５００はブロック５０１で始まる。ブロック５０２ではｈｏｌｄ／ｇｏ信号が生成され、このｈｏｌｄ／ｇｏ信号は外部実体（例えば実体４０３）によって監視できる。より具体的に、決定性エンジンによってｈｏｌｄ／ｇｏ信号を生成できる。一実施形態によると、ｈｏｌｄ／ｇｏ信号は、外部実体による処理のタイミングを制御するため、外部実体に対しインジケータとして機能する。

ブロック５０３では、決定性エンジンが外部実体から待機要求を受け取る。待機要求は、ｈｏｌｄ／ｇｏ信号が状態を変えるまでの時間量を指定できる。決定性エンジンはブロック５０４で待機期間をタイムカウント単位に変換する。決定性エンジンはブロック５０５で時間基準からタイムカウント値を入手し、ブロック５０６ではタイムカウント値に基づき経過時間（例えばタイムスパン）を判定する。

決定性エンジンはブロック５０７で待機状態に入り、経過時間が待機要求を上回るかこれと等しくなるまではこの状態を保ち、その後ブロック５０８でｈｏｌｄ／ｇｏ信号が設定される。プロセス５００はブロック５０９で終わる。

本発明の一実施形態によると、プロセッサは、例えば以下のタスクを遂行できるコンピュータを含んでよい。
１．外部実体（例えば外部実体４０３）によって監視できるｈｏｌｄ／ｇｏ信号（例えば信号４０４）を、（例えば決定性エンジン４０６によって）生成する。
２．外部実体から待機要求（例えば信号４０５）を受け取る。この待機要求は、ｈｏｌｄ／ｇｏ信号が状態を変えるまでの時間量を指示する。
３．要求された待機期間を時間単位からタイムカウント単位のそれに変換する。
４．時間基準から（例えばインターフェイスを介し）タイムカウント値を入手する
５．２つのタイムカウント値を用いてデルタタイム関数を適用し、２つのタイムカウント値の差に関連するタイムスパンを判定する。
６．次のとおりに定義された決定性ループアルゴリズムを実行する。
ａ．待機要求を受け取る
ｂ．要求された期間をタイムカウント単位に変換する
ｃ．ｈｏｌｄ／ｇｏ信号をクリアする
ｄ．初期タイムカウントを得る
ｅ．デルタタイム結果が待機要求を上回るかこれに等しくなるまで（＞＝）、下のブロックを遂行する
｛
Ｏｂｔａｉｎ ａ ｃｕｒｒｅｎｔ ｔｉｍｅ ｃｏｕｎｔ
Ａｐｐｌｙ ｄｅｌｔａ ｔｉｍｅ ｆｕｎｃｔｉｏｎ ｔｏ ｃｕｒｒｅｎｔ−ｉｎｉｔｉａｌ ｔｉｍｅ ｃｏｕｎｔ
｝
Ｓｅｔ ｈｏｌｄ／ｇｏ ｓｉｇｎａｌ

もしも逆デルタタイム関数を使用することができるなら、別の実施形態に従い決定性ループアルゴリズムの代替バージョンを下記のとおりに実装できる。
ａ．待機要求を受け取る
ｂ．要求された期間をタイムカウント単位に変換する
ｃ．ｈｏｌｄ／ｇｏ信号をクリアする
ｄ．逆デルタタイム関数を待機要求に適用する
ｅ．逆デルタタイム結果＞現在タイムカウントとなる間は下のブロックを遂行する
｛
Ｏｂｔａｉｎ ｔｈｅ ｃｕｒｒｅｎｔ ｔｉｍｅ ｃｏｕｎｔ
｝
Ｓｅｔ ｈｏｌｄ／ｇｏ ｓｉｇｎａｌ
プロセッサにおける決定性ループアルゴリズムの実行にはある程度の時間量がかかり、この時間は、プロセッサがアルゴリズムをどれくらい速く実行できるかに左右される。この時間量はここで決定性ループアルゴリズムオーバーヘッドと呼ぶ。

決定性ループアルゴリズムオーバーヘッドは２つの要素を、すなわちセットアップオーバーヘッドとループオーバーヘッドとを含む。セットアップオーバーヘッドはプロセッサシステム実装に依存し、ループに先立ち新しいタイムカウント値を取得する初期化命令に関係する。ループオーバーヘッドはプロセッサが１回の実行にかかる時間であり、インターフェイスオーバーヘッドを含み、このインターフェイスは時間基準がプロセッサの外にある場合にはプロセッサシステムに関係しない。

一実施形態によるセットアップオーバーヘッドとループオーバーヘッドはいずれも（そして結果的には決定性ループアルゴリズムオーバーヘッドは）、プロセッサ実装と決定性ループアルゴリズム実装にとって予測可能でなければならない。特定のプロセッサ実装と決定性ループアルゴリズム実装において、セットアップオーバーヘッドの最小値と最大値との差は、ここでセットアップジッタと呼ぶ。同様に、ループオーバーヘッドの最小値と最大値との差はループジッタと呼び、インターフェイスジッタを含む。合計システムジッタは、所与の実装におけるセットアップジッタとループジッタの総合効果を反映する。

前述したいかなるシステム実装で、待機要求の中で要求される期間が時間分解能＋セットアップオーバーヘッド＋ループオーバーヘッド＋ｓｅｔ ｈｏｌｄ／ｇｏ ｓｉｇｎａｌ遷移時間を上回るかこれに等しいなら、合計システムジッタに等しい精度で待機要求の
中で要求される期間内にｈｏｌｄ／ｇｏ信号の状態を変えることは可能である。

外部システムは決定性エンジンへ待機要求を送信し、ｈｏｌｄ／ｇｏ信号がアサートされるのを待つ。待機要求が決定性エンジンへ達するのに要する時間量は待機要求遅延として知られている。本発明の一実施形態によると、決定性エンジンのユーザ実装にとって待機要求遅延は予測可能でなければならない。前述した他の遅延と同様、待機要求のシグナリングと関連した待機要求ジッタもある。もしも外部システムで待機要求遅延が分かるなら、外部システムは待機要求を通じて送信される期間の数学的操作によって遅延を補償できる。

ｈｏｌｄ／ｇｏ信号が外部システムに達するのに要する時間量はｈｏｌｄ／ｇｏ信号遅延として知られている。本発明の一実施形態によると、決定性エンジンのユーザ実装にとってｈｏｌｄ／ｇｏ信号遅延は予測可能でなければならない。前述した他の遅延と同様、ｈｏｌｄ／ｇｏ信号と関連したｈｏｌｄ／ｇｏ信号ジッタもある。

外部システムがｈｏｌｄ／ｇｏ信号の状態変化に応答するのにかかる時間量はここでシステム反応レイテンシと呼ぶ。一実施形態によると、決定性エンジン（例えば外部実体４０３）のユーザ実装にとってシステム反応レイテンシは予測可能でなければならない。前述した他の遅延と同様、システム反応レイテンシと関連したシステム反応ジッタがある。

最小待機要求期間が時間分解能＋セットアップオーバーヘッド＋インターフェイス遅延＋ｓｅｔ ｈｏｌｄ／ｇｏ ｓｉｇｎａｌ遷移時間＋システム反応レイテンシを上回るなら、決定性エンジンのユーザが所与の待機要求について達成できる精度は合計システムジッタ＋システム反応ジッタに等しい。

様々な実施形態による決定性エンジンの用途は、例えばソフトウェア自動テスト装置（ＡＴＥ）分野に見出すことができ、テスト機能にかかる時間をすこぶる精密な既定の時間にするのに役立てることができる。既存自動テスト装置ソフトウェアの決定性精度は精々１０分の数マイクロ秒である。本発明の一実施形態によると、合計システムジッタが比較的小さく、システム反応ジッタが小さく、遅延とオーバーヘッドが最小限の決定性エンジンのソフトウェア実装により、ＡＴＥソフトウェアの決定的挙動は大幅に向上する。

本発明の一実施形態によると、上述した決定性エンジンは、カリフォルニア州サンタクララのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎから入手できる周知のＩｎｔｅｌ ＰＥＮＴＩＵＭ（登録商標） ＩＶプロセッサを用いて実装できる。Ｉｎｔｅｌ ＰＥＮＴＩＵＭ（登録商標） ＩＶクラスのプロセッサは、分解能が比較的高くアクセスに伴う遅延が非常に短い埋め込み時間基準を含む。この埋め込み時間基準はタイムスタンプカウンタ（ＴＳＣ）と呼ばれている。

ＴＳＣは、カウンタの初期化以降に発生したプロセッサクロックサイクル数を累積するカウンタである。ＰＥＮＴＩＵＭ（登録商標）プロセッサのクロック周波数は（ある種の状況下で）固定されていると考えることができ、これは時間基準分解能が一定で１／プロセッサ周波数に等しいことを意味する。例えば、３．０ＧＨｚの公称周波数で実行するＰＥＮＴＩＵＭ（登録商標） ＩＶプロセッサは３３３ｐｓの時間基準分解能を提供する。

さらに、ＴＳＣの内容は単一のプロセッサ命令（ＲＤＴＳＣ）で読み取ることができる。これは、インターフェイス遅延がその単一命令の実行時間となることを意味し、これは３．０ＧＨｚで実行するＰＥＮＴＩＵＭ（登録商標） ＩＶプロセッサで４０ｎｓ程度である。このプロセッサの場合、インターフェイス遅延ジッタは３ｎｓ程度である。

ＰＥＮＴＩＵＭ（登録商標） ＩＶプロセッサを使用する上述の実装で、凡その決定性ループアルゴリズムオーバーヘッドは３５６ｎｓ、セットアップオーバーヘッドは３１２ｎｓ、ループオーバーヘッドは４４ｎｓである。命令パイプラインが広く使われるＰＥＮＴＩＵＭ（登録商標） ＩＶプロセッサの内部アーキテクチャのため、標準的な実測合計システムジッタ値を検知することはできない。

一実施形態によると、決定性エンジンによって遂行されるオペレーションは、汎用コンピュータシステム上で実行するソフトウェアプログラムによって遂行できる。例えば、本発明の様々な態様を１つ以上のソフトウェアプログラムで実装できる。一実施例においては、これ以降ＳＭＸ＿Ｔｉｍｉｎｇと呼ぶ単一クラスの中で決定性エンジンを埋め込むことができる。以降の節では、かかるクラスの一実装を説明する。以下の方法が専ら実施例として提示されていること、そして本発明が特定の方法に、または方法の組み合わせに、限定されないことは理解されよう。
基本的オペレーション
ＳＭＸ＿Ｔｉｍｉｎｇは、インクルードファイル（例えばＳＭＸ＿Ｔｉｍｉｎｇ．ｈｘｘ）と支援ＤＬＬ（例えばＳＭＸ＿Ｔｉｍｉｎｇ．ｘｙｚ、ここで「ｘｙｚ」は、Ｗｉｎｄｏｗｓ（登録商標）プログラミング環境なら「ｄｌｌ」プログラムであり、ＩＮｔｉｍｅプログラミング環境なら「ｒｓｌ」プログラムである）として実装できる。インクルードファイルに包含されるクラス記述は、時間的に重要なメソッドの実装を（インラインメソッドとして）含む。ＤＬＬファイルは、クラス較正ルーチンを含むユーティリティメソッドを提供することができる。

ＳＭＸ＿Ｔｉｍｉｎｇ ＤＬＬはロード時にクラス較正を遂行し、ＣＰＵ周波数を判定する。一実施形態によると、この較正プロセスは自動的に実行し、ＣＰＵクロックが変わらない限り再び実行する必要はない。クロックは、例えばＣＰＵ保護メカニズムが電力損失を抑えるためスピードスロットルを使用しない限り、変わらない。

ひとたびクラスが較正されＣＰＵ周波数が判明したら、新しいクラスオブジェクトを作成でき、利用可能なユーティリティメソッドはどれでも使用することができる。較正プロセスは非常に重要であるため、その成功を、クラスのオブジェクトをインスタンス化する前に、またはＤＬＬで利用可能なユーティリティ関数のほとんどを使用する前に、チェックするべきである。較正プロセスの確認は容易く果たすことができ、例えば静的クラスメソッド（例えば、これ以降ＩｓＩｎｉｔｉａｌｉｚｅｄメソッドと呼ぶもの）をコールすることによって果たすことができる。これより、かかるメソッドの使用を他のルーチン例と併せてより具体的に説明する。
ＳＭＸ＿Ｔｉｍｉｎｇクラスメソッド
一実施形態によると、このクラスにおける時間的に重要なメソッドは、性能上の理由からアセンブリ言語でインライン関数として実装する。それらは単純であるため、主要なメソッドを以下に説明する。
ＳＭＸ＿Ｔｉｍｉｎｇ（ｖｏｉｄ）
一実施形態によると、タイミングクラスで作成されるオブジェクトは独自の較正係数を含む。タイミングクラス構成子はグローバル較正係数をオブジェクトの中にコピーし、かくしてオブジェクトは、必要に応じてオブジェクト単位で修正できる。
ＳＭＸ＿Ｕ６４ Ｓｔａｒｔ（ｖｏｉｄ）
Ｓｔａｒｔメソッドは現在のタイムスタンプカウンタを読み取り、そのカウンタ値をマーカー属性に保存する。このマーカー属性は、経過時間を計算するため（例えば、Ｅｌａｐｓｅｄメソッドと呼ばれるメソッドを使用）、または所定の時間が過ぎるまで待つため（例えば、ＷａｉｔＵｎｔｉｌメソッドと呼ばれるメソッドを使用）、基準として使用することができる。以下のコード例は説明した機能を実装する。

上記のコードは次のとおりに機能する。行１及び２はＣＰＵの同期をとる。実行されている命令はどれも、行４でタイムスタンプカウンタがサンプリングされる前に終了する。行６は現在のオブジェクトデータエリアのポインタを取得する。行８及び９はタイムスタンプをマーカー属性に保存する。このメソッドは終了時に、タイムスタンプカウンタをＣＰＵクロックティック数で表す符号無し６４ビット値を戻す。
ＳＭＸ＿Ｓ６４ Ｅｌａｐｓｅｄ（ｖｏｉｄ）
Ｅｌａｐｓｅｄメソッドは、現在のタイムスタンプと、Ｓｔａｒｔメソッドが最後にコールされるまでにサンプリングされるタイムスタンプとの差を計算する。所望のオーバーヘッドの除去を可能にするためオプションの較正係数があってよい。以下のコード例はＥｌａｐｓｅｄメソッドの実装を実証するものである。

このコードはＳｔａｒｔメソッドとよく似ており、違いは、サンプリングしたばかりのタイムスタンプとマーカーとして保存されたタイムスタンプとの差を計算する行８及び９と、ｅＣＦ属性に格納されたｃａｌｆａｃｔｏｒを差し引く行１１及び１２だけである。このメソッドの計算結果は符号付き６４ビット値として戻される（較正係数次第では負の値が返される）。

クラス初期化プロセス（例えば、ＤＬＬがロードされるとき、またはＣａｌｉｂｒａｔｅＴｉｍｉｎｇメソッドがコールされるとき）で計算されるコールファクタは、ＳｔａｒｔメソッドとＥｌａｐｓｅｄメソッドの相継ぐコールの間に存在するオーバーヘッドである。較正係数により、以下のコードシーケンスでＥｌａｐｓｅｄメソッドによって戻される値はゼロである。

オペレーションにどれくらいかかるかを計算するにはデフォルトの較正係数を使用するとよい。以下の実施例に示すオペレーションの前にはＳｔａｒｔメソッドのコールを、そして後ろにはＥｌａｐｓｅｄメソッドのコールを、追加できる。

デフォルトの較正係数が満足のいくものでなければ、較正係数を変更するためＳｅｔＥｌａｐｓｅｄＣａｌＦａｃｔｏｒメソッドをコールできる。
ＳＭＸ＿Ｕ６４ ＷａｉｔＵｎｔｉｌ（ＳＭＸ＿Ｕ６４ ｄｅｌｔａ）
ＷａｉｔＵｎｔｉｌメソッドは、上述したｗａｓｔｅ機能を実装するルーチンの一例である。このメソッド例は、Ｓｔａｒｔメソッドが最後にコールされたときからのフォワードデルタを計算し、タイムスタンプが算出された終了時間に等しくなるかこれを超過するまでタイトループの中で待機する。

このメソッド例では２つの変更可能オプションが、すなわち実行時間を調整するための較正係数と（平均ループ誤差）、メソッドをその値に応じてイネーブル／ディスエーブルするイネーブルフラグとが認められる。較正係数はＳｅｔＷａｉｔＵｎｔｉｌＣａｌＦａｃｔｏｒメソッドによって変えることができ、イネーブルフラグはＥｎａｂｌｅメソッドとＤｉｓａｂｌｅメソッドを使って変更できる。一実施形態によると、イネーブルフラグのデフォルト値は偽（ＷａｉｔＵｎｔｉｌメソッドはディスエーブル）である。

以下のコード例はＷａｉｔＵｎｔｉｌメソッドを実装するものである。

記載されたコードは次のとおりに作用する。行１及び２は実行フローの同期をとる。行４は現在のオブジェクト（これ）のポインタを取得する。行６乃至８は要求された待機期間をロードする。行１０及び１１はメソッドがイネーブルか否かをチェックする。行１２及び１３は、メソッドがイネーブルである場合に要求期間をゼロに変更する。行１７及び１８は、要求待機期間からプログラムされた較正係数を引く。行２０及び２１は、前の計算を、結果が負である場合に、ゼロに調整する。行２３及び２４は最終的なタイムスタンプを計算する。最後に、行２６乃至２９のループは算出タイムスタンプに達するまで待機する。戻り値は、ループ誤差をＣＰＵクロック数で表す符合無し６４ビット値である。

ＷａｉｔＵｎｔｉｌメソッドは較正のときに様々なデルタ値で実行される。このプロシージャは２つの興味深い数字を、すなわちメソッドの実行にかかる最小時間（オーバーヘッド）とループ誤差とをもたらす。デフォルトの較正係数は、オーバーヘッドとループ誤差の値の半分との和である。

ＷａｉｔＵｎｔｉｌメソッドを上記のように提案するとおりに使用するため、以下のコード例を実装できる。

上記の実施例において、もしもｃｏｍｐｕｔｅｄＤｅｌａｙに相当する時間がＲｕｎＣｏｄｅＨｅｒｅ関数の最大実行時間より大きければ、上記の抜粋は上述した決定性オペレーションＯ_Ｄである。他方、もしもＲｕｎＣｏｄｅＨｅｒｅ関数の実行時間が値ｃｏｍｐｕｔｅｄＤｅｌａｙに相当する時間より大きければ、オペレーションは決定性でなく、Ｓｔａｒｔ及びＷａｉｔＵｎｔｉｌメソッドによって遂行されるＲｕｎＣｏｄｅＨｅｒｅ関数を取り巻くエンベロープは無用である。上記のコードを決定性にするため値ｃｏｍｐｕｔｅｄＤｅｌａｙを求める方法を以下に記す。
ＳＭＸ＿Ｕ６４ ＷａｉｔＵｎｔｉｌＥｘ（ＳＭＸ＿Ｕ６４ ｄｅｌｔａ）
ＷａｉｔＵｎｔｉｌメソッドとは対照的に、ここでＷａｉｔＵｎｔｉｌＥｘメソッドと呼ぶメソッド例は、時間の浪費を援助するためオペレーティングシステム（例えば、Ｗｉｎｄｏｗｓ（登録商標）またはＩＮｔｉｍｅオペレーティングシステム関数）を使用する。かかるメソッドを使用する開発者は長い待機時間を設け（例えば１００ミリ秒）、マウスを動かす、ネットワーク上でパケットを交換する等、オペレーティングシステムに仕事をするための時間を与えつつ、消費時間のコントロールを維持することができる。上記のＷａｉｔＵｎｔｉｌメソッド例を使用すると、適切なタイムスタンプを待つタイトループはＣＰＵをロックし、見かけ上の活動はなくなり、ユーザにはＣＰＵがハングしたような誤った印象を与える。

ＷａｉｔＵｎｔｉｌＥｘメソッド例は浪費する時間を２つの部分に分ける。第１の部分は、スリープ関数の内１つを使用するオペレーティングシステムによって浪費され（例えば、Ｗｉｎｄｏｗｓ（登録商標）の場合はＳｌｅｅｐ関数、ＩＮｔｉｍｅの場合はｋｎＲｔＳｌｅｅｐ関数）、第２の部分は、合計消費時間の良好なコントロールを提供するためＷａｉｔＵｎｔｉｌメソッドによって浪費される。戻り値はＷａｉｔＵｎｔｉｌメソッドによって戻されるループ誤差である。
ＳＭＸ＿Ｕ６４ Ｗａｉｔ（ＳＭＸ＿Ｕ６４ ｃｌｋｓ）
このメソッドは、例えば次のとおりに実装できる。

このＷａｉｔメソッドは、ようするに所定のクロック数（ｃｌｋｓ）が浪費されるのを待つ。戻り値はＷａｉｔＵｎｔｉｌメソッドによって戻されるループ誤差である。
ＳＭＸ＿Ｕ６４ ＷａｉｔＥｘ（ＳＭＸ＿Ｕ６４ ｃｌｋｓ）
このメソッドは、例えば次のとおりに実装できる。

このＷａｉｔＥｘメソッドは、所定のクロック数（ｃｌｋｓ）が浪費されるのを待つ。
戻り値はＷａｉｔＵｎｔｉｌＥｘメソッドによって戻されるループ誤差である。
ＳＭＸ＿Ｕ６４ ＧｅｔＥｌａｐｓｅｄＣａｌＦａｃｔｏｒ（ｖｏｉｄ）
このメソッド例は、Ｅｌａｐｓｅｄメソッドによって較正係数として使用されるＣＰＵクロックティック数を表す符号無し６４ビット値を戻す。
ｖｏｉｄ ＳｅｔＥｌａｐｓｅｄＣａｌＦａｃｔｏｒ（ＳＭＸ＿Ｕ６４ ｎｅｗＣＦ）
このメソッドは、Ｅｌａｐｓｅｄメソッドによって使用される較正係数を、パラメータとして渡される符号無し６４ビット値に設定する。このパラメータには、ＣＰＵクロックティック数になることが見込まれる。
ｖｏｉｄ ＲｅｓｅｔＥｌａｐｓｅｄＣａｌＦａｃｔｏｒ（ｖｏｉｄ）
ＲｅｓｅｔＥｌａｐｓｅｄＣａｌＦａｃｔｏｒメソッドは、Ｅｌａｐｓｅｄメソッドによって使用される本来の較正係数を回復させる。現在の較正係数は失われる。
ＳＭＸ＿Ｕ６４ ＧｅｔＷａｉｔＵｎｔｉｌＣａｌＦａｃｔｏｒ（ｖｏｉｄ）
このメソッドは、ＷａｉｔＵｎｔｉｌメソッドによって較正係数として使われるＣＰＵクロックティック数を表す符合無し６４ビット値を戻す。
ｖｏｉｄ ＳｅｔＷａｉｔＵｎｔｉｌＣａｌＦａｃｔｏｒ（ＳＭＸ＿Ｕ６４ ｎｅｗＣＦ）
このメソッドは、ＷａｉｔＵｎｔｉｌメソッドによって使用される較正係数を、パラメータとして渡される符号無し６４ビット値に設定する。このパラメータには、ＣＰＵクロックティック数になることが見込まれる。
ｖｏｉｄ ＲｅｓｅｔＷａｉｔＵｎｔｉｌＣａｌＦａｃｔｏｒ（ｖｏｉｄ）
ＲｅｓｅｔＷａｉｔＵｎｔｉｌＣａｌＦａｃｔｏｒメソッドは、ＷａｉｔＵｎｔｉｌメソッドによって使用される本来の較正係数を回復させる。現在の較正係数は失われる。
ＳＭＸ＿Ｕ６４ ＧｅｔＣＰＵＦｒｅｑｕｅｎｃｙ（ｖｏｉｄ）
この静的メソッドは、較正プロセスで判明するＣＰＵ周波数をヘルツ単位で戻す。戻り値は符号無し６４ビット数である。
ＳＭＸ＿Ｕ６４ ＧｅｔＫｅｒｎｅｌＴｉｃｋＣｌｋ（ｖｏｉｄ）
この静的メソッドＧｅｔＫｅｒｎｅｌＴｉｃｋＣｌｋは、１カーネルティックに相当するＣＰＵクロックティック数を表す符号無し６４ビット数を戻す。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムにおけるカーネルティックは１０ｍｓであり、ＩＮｔｉｍｅ環境におけるカーネルティックは値１００ｕｓ、２００ｕｓ、２５０ｕｓ、５００ｕｓ、１ｍｓ、２ｍｓ、５ｍｓ、及び１０ｍｓのいずれかになる。
ｂｏｏｌ ＩｓＩｎｉｔｉａｌｉｚｅｄ（ｖｏｉｄ）
この静的メソッドは較正結果の検証に役立てることができる。較正に失敗するとクラスオブジェクトは常軌を逸した挙動を見せ、使用するべきではない。このメソッドは、最後の較正に問題がなければ真を戻し、さもなくば偽を戻す。
ｖｏｉｄ Ｅｎａｂｌｅ（ｖｏｉｄ）
この静的メソッドはイネーブルされた属性を真に設定する。この属性は、ＷａｉｔＵｎｔｉｌメソッドがその機能をイネーブル／ディスエーブルするのに使用することができる。このメソッドはまた、ＩＮｔｉｍｅ環境で実行する場合にカーネルスケジューラを停止させる。一実施形態によると、ＷａｉｔＵｎｔｉｌメソッドはデフォルトによりディスエーブルになる。
ｖｏｉｄ Ｄｉｓａｂｌｅ（ｖｏｉｄ）
この静的メソッドは、イネーブルされた属性を偽にリセットする。この属性は、ＷａｉｔＵｎｔｉｌメソッドがその機能をイネーブル／ディスエーブルするのに使用することができる。詳細についてはＷａｉｔＵｎｔｉｌメソッドの説明を参照せよ。このメソッドはまた、ＩＮｔｉｍｅ環境で実行する場合にカーネルスケジューラを再起動する。一実施形態によると、ＷａｉｔＵｎｔｉｌメソッドはデフォルトによる。
ｂｏｏｌ ＩｓＥｎａｂｌｅｄ（ｖｏｉｄ）
この静的メソッドはＷａｉｔＵｎｔｉｌメソッドの状態を確認し、もしもこれがイネーブルなら真を戻し、さもなくば偽を戻す。
ＳＭＸ＿Ｕ６４ ＧｅｔＬｏｏｐＥｒｒｏｒ（ｖｏｉｄ）
上記のＷａｉｔＵｎｔｉｌメソッドのコード例で見てとれるように、行２６〜２９のループは、タイムスタンプカウンタが値（マーカー＋デルタ−ｃａｌｆａｃｔｏｒ）に等しくなるか、またはループ誤差によりこれを超過すると直ちに終了する。ＷａｉｔＵｎｔｉｌメソッドは較正のときに様々なデルタパラメータ値で実行され、一連のループ誤差値をもたらす。

この静的メソッドは、較正プロセスで判明する最大ループ誤差をＣＰＵクロックティック数で表す符号無し６４ビット数を戻す。
ＳＭＸ＿Ｕ６４ ＧｅｔＷａｉｔＵｎｔｉｌＯｖｅｒｈｅａｄ（ｖｏｉｄ）
このメソッドは、ＷａｉｔＵｎｔｉｌメソッドの実行にかかる最小実行時間として判明するＣＰＵクロックティック数を表す符号無し６４ビット値を戻す。
ｖｏｉｄ ＤｉｓａｂｌｅＡｌｌＩｎｔｅｒｒｕｐｔｓ（ｖｏｉｄ）
この静的メソッドは全ての割り込みをディスエーブルし、現在イネーブルになっている割り込みを保存する。外的イベントが実行中プログラムの決定的挙動に支障をきたさないことを保証するのに役立てることができる。割り込みは、Ｉ／Ｏオペレーションやオペレーティングシステムコールの前にＲｅｓｔｏｒｅＩｎｔｅｒｒｕｐｔｓメソッドを使って復元できる。
ｖｏｉｄ ＲｅｓｔｏｒｅＩｎｔｅｒｒｕｐｔｓ（ｖｏｉｄ）
この静的メソッドは、上記のＤｉｓａｂｌｅＡｌｌＩｎｔｅｒｒｕｐｔｓメソッドがコールされたときにアクティブだった割り込みをイネーブルする。
ｂｏｏｌ ＣａｌｉｂｒａｔｅＴｉｍｉｎｇ（ｖｏｉｄ）
この静的メソッドは較正プロセスを実行し、ＥｌａｐｓｅｄメソッドとＷａｉｔＵｎｔｉｌメソッドとによって使用される較正係数と、ＣＰＵ周波数とを判定する。このメソッドは、較正に成功した場合は真を戻し、さもなくば偽を戻す。
ＳＭＸ＿Ｕ６４ Ｃｌｋ２Ｔｉｍｅ（ＳＭＸ＿Ｕ６４ ｃｌｋｓ， ｅｎｕｍ ＴｉｍｅＵｎｉｔｓ ｕｎｉｔ）
これは、ＣＰＵクロックティックを所定の時間単位に変換するために使用する静的メソッドである。使用可能な単位には、例えば秒（ＳＥＣ）、ミリ秒（ＭＩＬＬＩＳＥＣ）、マイクロ秒（ＭＩＣＲＯＳＥＣ）、ナノ秒（ＮＡＮＯＳＥＣ）、ピコ秒（ＰＩＣＯＳＥＣ）がある。
ＳＭＸ＿Ｕ６４ Ｔｉｍｅ２Ｃｌｋ（ＳＭＸ＿Ｕ６４ ｔｉｍｅ， ｅｎｕｍ ＴｉｍｅＵｎｉｔｓ ｕｎｉｔ）
これは、所定の時間単位による時間をＣＰＵクロックティックに変換するために使用する静的メソッドである。使用可能な単位には、例えば秒（ＳＥＣ）、ミリ秒（ＭＩＬＬＩＳＥＣ）、マイクロ秒（ＭＩＣＲＯＳＥＣ）、ナノ秒（ＮＡＮＯＳＥＣ）、ピコ秒（ＰＩＣＯＳＥＣ）がある。
ｖｏｉｄ ＦｌｕｓｈＣａｃｈｅｓ（ｖｏｉｄ）
これは、全てのキャッシュを消去するために使用する静的メソッドである。このメソッドは、ワーストケースシナリオを助長するためベンチマークの前に使用することができる。
決定性ドライバを作成するステップ例
決定性ドライバの作成は概して多数の時間測定を要するプロセスであり、概して時間のかかる作業である。露出するＡＰＩは、様々なパラメータで実行されているときに計時しなければならない。決定性ドライバの設計にあたってソフトウェア開発者を支援するため、これよりいくつかのガイドラインを含む決定性ドライバ作成プロセスを説明する。
ステップ１−アルゴリズムの選択
ドライバの記述者は開発過程でアルゴリズムの選択に細心の注意を払わなければならない。決定性ドライバの作成にあたっては、変動を補償するためその実行時間にある程度の「クッション」を加えることになるため、安定的で高速のアルゴリズムを選ぶことが大切
である。

実行時間が、まったく同じとまではいかなくともほぼ同じ、実行パスを作成する。これは均衡実行（ｂａｌａｎｃｅｄ ｅｘｅｃｕｔｉｏｎ）と呼ばれている。この方法は一般的に実装が困難ではあるが、達成できるなら実装するだけの価値はある。この均衡実行手法を例証する一実施例を以下に示す。

この実施例で、もしも比較に強い傾向があるなら、例えばａが大抵はｂより大きいなら、またはｂより小さいなら（不均衡実行時間）、この方法に実際的効果はなく、実行時間の最適化を優先するべきである。

均衡実行を提供するもうひとつの手法は、ｉｆ文を完全に取り除くことを含む。上記と同じオペレーションを、例えば次のとおりに実装できる。

前の場合より僅かに複雑ではあるが、上記のソリューションの実行時間は均一であり、分岐がない。条件分岐を使用する場合、例えばｉｆ文を使う場合には、条件に失格するたびに実行時間が犠牲になるので注意されたい。
ステップ２−実行時間の解析
アルゴリズムを慎重に選んだら、今度はその入力パラメータに応じた実行時間を解析する。以下の２つの実施例は、ＡＰＩの入力がその実行時間にどう影響するかを示すものである。

上記の関数の論理的解析から、ｆｕｎｃ１の実行時間がその入力とは無関係に一定であること、そしてｆｕｎｃ２の実行時間がその入力に大きく左右され不定であることが分かる。ここではｆｕｎｃ１のような関数を単純関数と呼び、ｆｕｎｃ２のような関数は複雑関数と呼ぶ。

所与のルーチンの実行時間がその入力の変化に大きく左右されない場合は、そのルーチンを単純関数として扱うとより好都合である。例えば、もしも上記の関数ｆｕｎｃ２が１０未満の値だけでコールされるなら、その実行時間を単純関数としてモデル化すると非常に好都合である。ｆｕｎｃ２がゼロ以下の入力の場合に単純関数として挙動すること、そしてその実行時間がｘの増加に伴い直線的に増加することに注意されたい。
ステップ３−ベンチマーク
残念ながら、関数の実行時間を判断するにあたって関数挙動の単純な論理的解析では不十分である。他方、適切なベンチマークプロシージャを設計するにあたって解析は重要である。前の節で示したとおり、単純関数の刺激を変える必要はないが、複雑関数にはその必要がある。数通りのサンプルベンチマークルーチンを以下に記す。
単純関数のベンチマーク
単純関数のベンチマークは以下に記すようなルーチンによって遂行できる。入力パラメータは重要でないから、有効なパラメータならどれでも選択できることに注意されたい。

上記のベンチマークルーチンの実行は次のとおりに進行する。行１はＷａｉｔＵｎｔｉｌメソッド（及び決定性エンジン）をディスエーブルし、かくして行８、９、及び１０によって形成される決定性オペレーションＯ_Ｄは通常のオペレーション（非決定性オペレーション）になる。ＷａｉｔＵｎｔｉｌメソッドはディスエーブルされるから、値ａｎｙＶａｌｕｅは重要でない。

行５は、実行時間のワーストケースを生起させるため全てのキャッシュ（コードとデー
タ）を消去する。行６及び１２は、関数ｆｕｎｃ１と行８、９、及び１０によって形成されるその決定性エンベロープを実行する時間を測定する。Ｔ_０が、行８、９、及び１０によって形成される決定性オペレーションＯ_Ｄによって費やされる合計時間を測定する点に注意されたい。

決定性エンジンはディスエーブルされるから、行１２で測定される値は、関数ｆｕｎｃ１の実行時間に、決定性エンジンに固有の少量のオーバーヘッドを加えたものに相当する（上記の等式（２）及び（３）におけるＥ）。

上記のコード断片の実行後は、サンプルの配列の中で最大値を検索できる。一実施形態によると、配列の中で実行時間がサンプリングされ、収集データに対して統計解析を行うことができる。具体的に、ピーク・トゥ・ピーク実行時間変動（ジッタ）と平均実行時間をチェックすれば、関数の挙動をよりよくつかむことができ、前に行った解析の誤りが指摘されることもある。

ベンチマーク対象の関数の実行時間の最大値が定まったら変数ｃｏｍｐｕｔｅｄＤｅｌａｙを定めることができ、予測された挙動を確認するため以下の抜粋コード例を実行できる。

サンプル配列をプロットするとフラットな線になり、場合によっては微細な変動を伴う。ＷａｉｔＵｎｔｉｌメソッドには固有の誤差があること、そしてループ誤差の範囲内で誤差が見込まれるということを憶えておかなければならない。開発者はループ誤差値を求めるため、上述したＧｅｔＬｏｏｐＥｒｒｏｒメソッドをコールできる。前の実施例で、当初の解析が正しかったことをチェックする安全措置として関数ｆｕｎｃ１が可変引数ｊとともにコールされたことに注意されたい。
複雑関数のベンチマーク
複雑関数のベンチマークは予想どおり、より複雑である。上記の関数例ｆｕｎｃ２では２次元行列を作成する必要がある。一方の次元は入力値（ｘ値）を表し、他方の次元は特定の入力値（固定ｘ）で抽出されるサンプルを表す。ｆｕｎｃ２はただひとつの従属関係（ｘパラメータ）を持つから、２つの次元を持つ行列を作成できる。一般的に、各従属変数につき１つの次元が作成され、もうひとつは全ての変数が固定された場合に抽出されるサンプルのために作成される。関数ｆｕｎｃ２のベンチマークルーチンの実施例を以下に示す。

上記のリストと単純関数に使ったそれとの主な違いは、関数ｆｕｎｃ２の入力ｘを変化させるためもうひとつのｆｏｒループが追加されたことにある。刺激は、値の範囲全体をカバーする必要はないが、ベンチマーク対象の関数で全ての実行パスを使用するべきである。ｆｕｎｃ２の挙動は、入力パラメータがゼロ以下のときとこれが正のときとで異なるから、上記のベンチマークルーチンではＭＩＮの値をゼロに満たない何らかの値に設定し、ＭＡＸの値はゼロを上回る何らかの値に設定しなければならない。実行パス当たりの適切な（最小の）点数は関数次第であり、開発者は、実行時間内で挙動パターンが監察されるまでベンチマークを遂行する必要がある。

この関数はｘ値ごとに最大値を持つから、開発者には２つのオプションがある。つまり、全ての入力ｘを特定の入力で判明する最大値に結び付ける表を作成するか、または入力ｘに対する実行時間を表す関数を作成する。第１のオプションは、入力スパンが大きく表をメモリに収めることができないことから、必ずしも可能であるとは限らない。第２のオプションは実装がより複雑ではあるが、通常はこの方法を用いる。

我々は前の解析から、関数ｆｕｎｃ２の実行時間がゼロ以下のｘ値で一定となり、ｘ値の増加に伴い増加すると推定した。この挙動を具体化する関数は次のとおりである。

上記の関数は次のとおりに実行する。もしもｘがゼロ以下なら、論理オペレーションは（）まで評価し、ｅｘｅｃｕｔｉｏｎＴｉｍｅ関数はＢ ｎｓを戻す。もしもｘの値がゼロを上回るなら、実行時間はｘの単位につきＡずつ増加する。例えば、もしもｘが１００に設定されるなら実行時間は（１００ ＊ Ａ ＋ Ｂ）ｎｓになる。Ａ及びＢの値はベンチマークの実行後に判定される。ＷａｉｔＵｎｔｉｌメソッドは実行にあたってクロックティック数による値を期待するから、ｅｘｅｃｕｔｉｏｎＴｉｍｅ関数ではＴｉｍｅ２Ｃｌｋメソッドをコールしてクロックティック数への変換が行われることに注意されたい。このベンチマークルーチンは新しいアーキテクチャを考慮に入れるため変更できる。変数ａｎｙＶａｌｕｅは、以下に示す関数コールに置き換えることができる。

実行時間を計算するための新しい関数コールに伴い全体的な実行時間が増えることに注意されたい。ｅｘｅｃｕｔｉｏｎＴｉｍｅ関数はＷａｉｔＵｎｔｉｌメソッドが作用する前にコールされるから、実行時間の増加を除けば決定性オペレーションＯ_Ｄに影響は及ばない。

ベンチマークルーチンを用意した開発者は、Ａ及びＢの値を定めることができる。１つの目標は、ｅｘｅｃｕｔｉｏｎＴｉｍｅ関数の中で差し替えられたときに、同関数によって戻される結果が常に実際の実行時間（非決定的時間）より高くなるような１対の値を作成することである。選択される１対の値がこの目標を満たすことを確認するため、単純関数ｆｕｎｃ１の場合と同様のベンチマークルーチンを再び実行してよい。

ｅｘｅｃｕｔｉｏｎＴｉｍｅ関数で計算された時間がｎｓ単位で明示的に計算され、その後クロックティック数に変換されたことに気づくであろう。これは、一実施形態によると、ＡＴＥシステムの望ましい特性のひとつが相関性だからである。

２つのシステムを比較した場合の必然的な違いのひとつにＣＰＵクロック周波数がある。たとえ仕様が一致する場合でも、各ＣＰＵの実効速度は異なる。さらに、テストアプリケーションの寿命にわたって実行時間を一定に保つ必要があるから、機能不全やインストールベースの拡張等、数多くの要因のため、当然のコンピュータアップグレードが必要となる。これを踏まえ、実行時間をクロックティック数で測定することがなぜ得策でないかを開発者は理解するであろう。
ステップ４−タイミング表の組み立て
ＳＭＸアーキテクチャでは全てのドライバが少なくとも１つのタイミング表を有する。理論上は、顧客へ出荷される異なるコンピュータごとに１つのタイミング表を作成しなければならない。

タイミング表は、データ表と、複雑関数のタイミング挙動を表す実行時間モデル（タイミング関数）と、タイミング表に関する情報を報告するいくつかの標準関数とを保持するＤＬＬとして実装する。

一実施形態によるデータ表は配列であり、ここで各要素は以下の構造例によって表される。

上記の構造例で、ｐＦｕｎｃは複雑関数によって使用されるタイミング関数のアドレスを所持するｖｏｉｄポインタであり、ｔｉｍｅは単純関数によって使用される実行時間を所持し、ｕｎｉｔはｔｉｍｅフィールドで使用する単位であり、ｃｌｏｃｋＴｉｃｋｓは、現在ＣＰＵクロック速度への対（ｔｉｍｅ、ｕｎｉｔ）の変換結果を包含する。この変換プロセスはＤＬＬがロードされるときに１度だけ行われるということに注意されたい。

タイミング関数はいくつものパラメータを持つことができるが、一実施例においては、クロックティック単位の実行時間を戻すべきである。事実、タイミング関数はすこぶる頻繁に使われるから、可能な限り高速であるべきである。実際のドライバにおいて、もしも上記のｅｘｅｃｕｔｉｏｎＴｉｍｅ関数を次のように実装したならば、より有用且つ高速のものになる。

ここで、値Ａ及びＢはＤＬＬのロード時に時間からクロックティック数に変換される。この方法を用いれば、時間のかかる変換プロセスを１回で実行できる。

以下のタイミング表は、１つの単純関数と１つの複雑関数がリストされている一実施例である。

タイミング表ＤＬＬは、タイミング表に関する情報を提供するため３つのルーチンを含むことができる。それらは一定で以下に類似してよい。

第１のルーチンはタイミング表のアドレスを戻し、第２のルーチンはタイミング表の要素サイズを戻し、最後のルーチンはタイミング表の中の列数を戻す。

標準プロシージャとして、ＤＬＬ ｍａｉｎ（ＳＭＸ＿ＤＬＬ＿ＭＡＩＮ）は時間を表す全ての定数をクロックティック数に変換するため必要とされるコードを包含する。次のリストはその実装を例証するものである。

ＳＭＸ＿Ｔｉｍｉｎｇプロジェクトでは、タイミング表の管理にあたって開発者を支援するクラスを定義できる。クラス名はＳＭＸ＿ＴｉｍｉｎｇＴａｂｌｅＭａｎａｇｅｒであり、ドライバはこれを継承し使用することができる。

決定性エンジンの用途
一実施形態による決定性エンジンの一用途は、時間の点で本質的に非決定性であるシステムで決定性の挙動を提供することである。説明したとおり、Ｉｎｔｅｌ ＰＥＮＴＩＵＭ（登録商標）クラスのプロセッサを使用するコンピュータシステムは本質的に非決定性である。ＰＥＮＴＩＵＭ（登録商標）プロセッサは数レベルのパイプラインと、分岐予測アルゴリズムと、内部キャッシュメモリとを使用するため、命令セットの実行時間はプロセッサの現在の「コンテキスト」に左右される（つまり、各々のパイプラインレベルで復号化されている命令は何か、内部キャッシュメモリの内容と配置、その他）。このため、命令セットの正確な実行時間を演繹的に決定することはできない。決定できるのは最大実行時間である。このため、ＰＥＮＴＩＵＭ（登録商標）タイプのプロセッサに基づくシステムは予測可能ではあるが決定性ではない。

本発明の一実施形態によると、所望の一定時間が最大実行時間に等しいかまたはこれを上回るなら、決定性エンジンは命令セットの実行時間を一定にできる。最大実行時間は、関与する命令を解析することによって（さらにその最大実行時間を突き止めることによって）、または様々なプロセッサコンテキストにおける命令セットの実行によって経験的に、判定することができる。

図６及び７では、本発明の様々な実施形態に従いオペレーションを決定的に実行する結果を見ることができる。図６は、非決定性システムによるコード実行例を示す。図示された実施例においては、同じコード部分の実行が３回果たされる。これらの実行は、同じコンピュータによって、または異なるコンピュータによって、遂行されてよい。図示されたとおり、３通りの実行は３通りの総実行時間ｔ_１、ｔ_２、及びｔ_３に帰結する。決定性の実行を要するソフトウェアシステムは、図６に示す実行時間を提供するコンピュータシステムに一貫性のある実行を当てにできない。

図７は、本発明の様々な態様を実装する１つ以上のシステムによるコード実行例を示す。図示された実施例においては、同じコード部分の実行が同じ総実行時間ｔで果たされる。ひとつひとつの実行の実行時間は一定であるから、コードによって遂行されるオペレーションは再現可能である。

例えば決定性エンジンは、図７に示された「ＤＥ」と呼ばれるオブジェクトの１対のＣ＋＋メソッドとしてソフトウェアで実装できる。Ｓｔａｒｔ（）メソッドは実行時間が始まる時点をしるし、Ｗａｉｔ（）メソッドは時間ｔが経過するまで決定性エンジンを拘束する。これにより、この命令セットの合計実行時間は常に一定となり、ｔに等しくなる。

事前に実行時間を把握できることが実行速度より望まれる環境には、決定性エンジンの用途が数多くある。これは、半導体自動テスト装置（ＡＴＥ）業界のシステムで、特に線
形（アナログ）及び混合信号デバイステストの場合に見られる共通の特色である。かかるシステムではいくつかの異なる入力がテスト対象デバイス（ＤＵＴ）に提供され、それらの入力に対するＤＵＴの応答を測定する。こうして得た測定値に基づきＤＵＴは機能可能と、または欠陥ありと、判断される。線形及び混合信号デバイスはアナログ信号を生成し、これを測定しなければならないから、測定を行う正確な時点が極めて重要となる。

図８は仮定的デバイス出力と、デバイスが機能可能か否かを確認するため行われる２つの測定（Ｍ_１及びＭ_２）とを示す。もしもこれらの測定が非決定性システムでソフトウェアコマンドを使って行われるなら、測定が行われる正確な時間と関連した不正確（ジッタ）が生じるであろう。もしも測定を行う同じソフトウェアを続けて数回（この例では３回）実行するなら、たとえデバイス出力が毎回まったく同じであっても、Ｍ_１とＭ_２はまず間違いなく測定ソフトウェアの実行のたびに異なる値を示すだろう。

図８は、測定実行に伴うタイミングジッタから直接的な誤差が測定値に生じることを示している。タイミングジッタの程度によっては測定誤差があまりにも大きくなり、機能可能なデバイスが誤って機能不能と判断されたり、機能不能のデバイスが誤って機能可能と判断されるおそれがある。線形及び混合信号デバイスのためのテストアプリケーションは従来よりこの種の問題に取り組んできており、いくつかのソリューションはあるが、それらはいずれも多大なテスト時間（多数の測定値の平均化）かコスト（より精緻な測定ハードウェア）を余分に伴う。

測定が行われる時間を正確にコントロールするため決定性エンジンの一実装を使用すればタイミングジッタは解消し、さもなくば極端に低下し、多大な時間的犠牲を伴わず、ことによるとさほど精緻ではない測定ハードウェアを使用し、再現性の高い結果が得られるであろう。

測定が行われる時間を指定できることの直接的結果として、テストアプリケーションソフトウェアは、それが実行するところのプロセッサ速度から独立する。例えば、ある特定の速度（例えば２．０ＧＨｚ）で実行するコンピュータプラットフォームでテストアプリケーションを開発する場合、そのアプリケーションによって遂行される測定は間接的にそのプロセッサ速度に縛られることになる。もしもそのテストアプリケーションをより速いコンピュータシステム（例えば３．０ＧＨｚ）へ移すと、おそらく測定は想定以上に速く実行され、そのようなより速い作動も間違った結果をもたらす。既存のテストアプリケーションをより高速なプロセッサシステムへ移すことは、システム開発者にとって多大な時間とコストがかかる作業である。

逆に、テストアプリケーションにおいて決定性エンジンを利用すれば、定義上、全ての測定は常に同じ所定の時点に行われる。これは、テストアプリケーションをより高速なプロセッサへ移すにあたって、アプリケーションに対する変更が不要であることを意味する。このためユーザは、テストアプリケーション全体（通常は何千もの測定を含む）の移植に取り組む代わりに、特定の測定に絞ってテスト時間の改善を図ることができる。

これまで本発明の少なくとも１つの実施形態の態様をいくつか説明してきたが、当業者が様々な変更、修正、及び改良を容易く考え付くことは理解されよう。かかる変更、修正、及び改良はこの開示の一部をなすと意図され、本発明の精神と範囲の中にあると意図される。相応に、上記の説明と図面は例証に過ぎない。

本発明の様々な態様が実装できるコンピュータシステム例を示す。 本発明の一実施形態によるシステムアーキテクチャ例を示す。 本発明の一実施形態による決定性処理を遂行するプロセスである。 本発明の一実施形態による決定性エンジン例のブロック図である。 本発明の別の実施形態による決定性処理を遂行する別のプロセスである。 非決定性システムによるコード実行例を示す。 本発明の一実施形態による１つ以上の決定性システムによるコード実行例を示す。 本発明の態様を提示する仮定的デバイス出力と測定とを示す。

Claims (34)

1. 決定性処理を遂行するシステムであって、
   １つ以上の命令を実行するように構成される処理実体と、
   前記１つ以上の命令の実行時間を一定値となるよう調整するように構成されるコンポーネントとを備える、システム。
2. 前記コンポーネントは、前記１つ以上の命令の最大実行時間を調整するように構成される、請求項１に記載のシステム。
3. 前記コンポーネントは、前記１つ以上の命令の前記実行時間を前記１つ以上の命令の複数の実行にわたって同じ一定値となるよう調整するように構成される、請求項１に記載のシステム。
4. 前記複数の実行は、異なるコンピュータシステムで起こる、請求項３に記載のシステム。
5. 前記異なるコンピュータシステムは、異なる処理能力を有する、請求項４に記載のシステム。
6. 前記コンポーネントは、前記１つ以上の命令の実行を所定の期間内に遂行するように構成される、請求項１に記載のシステム。
7. 前記コンポーネントは、前記実行時間を前記一定値に調整するためある期間にわたり待機するように構成される、請求項１に記載のシステム。
8. 時間基準をさらに備え、前記コンポーネントは前記時間基準を用いて相対的時間を判定するように構成される、請求項７に記載のシステム。
9. 前記コンポーネントは、プロセッササイクルのカウンタ値に基づき相対的時間を判定するように構成される、請求項８に記載のシステム。
10. 前記時間基準はインターフェイスを含み、前記コンポーネントは前記インターフェイスを通じて処理サイクルのカウンタを入手するように構成される、請求項８に記載のシステム。
11. 前記コンポーネントは、前記１つ以上の命令の実行に使われる時間量を判定するように構成されており、且つ前記実行時間を前記一定値に調整するためある期間にわたり待機するように構成される、請求項１に記載のシステム。
12. 前記コンポーネントは、複数のカウンタ値に基づき経過時間を判定するように構成される、請求項９に記載のシステム。
13. 前記カウンタ値は、プロセッサのタイムスタンプカウンタである、請求項９に記載のシステム。
14. 前記プロセッサは、ＰＥＮＴＩＵＭ（登録商標）タイプのプロセッサである、請求項１３に記載のシステム。
15. 前記システムは、自動テストシステムの一部である、請求項１に記載のシステム。
16. 決定性処理を遂行するためにコンピュータ実装される方法であって、
    コンピュータシステムで１つ以上の命令を実行する動作と、
    実行する前記動作の実行時間を測定する動作と、
    前記実行時間を一定値に調整するためある期間にわたり待機する動作とを備える、方法。
17. ある期間にわたり待機する前記動作は、実行する前記動作の後に前記一定値の実行時間が経過するまである期間にわたり待機することを含む、請求項１６に記載の方法。
18. 前記１つ以上の命令の実行を測定する動作と、測定する前記動作に基づき前記１つ以上の命令の最大実行時間を判定する動作とをさらに備える、請求項１６に記載の方法。
19. 前記一定値を前記最大実行時間に設定する動作をさらに備える、請求項１８に記載の方法。
20. 前記１つ以上の命令の最大実行時間を判定する動作をさらに備える、請求項１６に記載の方法。
21. 前記一定値を前記最大実行時間に設定する動作をさらに備える、請求項２０に記載の方法。
22. 前記１つ以上の命令の前記実行時間を前記１つ以上の命令の複数の実行にわたって同じ一定値となるよう調整する動作をさらに備える、請求項１６に記載の方法。
23. 前記複数の実行は、異なるコンピュータシステムで起こる、請求項２２に記載の方法。
24. 前記異なるコンピュータシステムは、異なる処理能力を有する、請求項１６に記載の方法。
25. コンピュータシステムで１つ以上の命令を実行する前記動作を所定の期間内に遂行する動作をさらに備える、請求項１６に記載の方法。
26. 前記実行時間を前記一定値に調整するためある期間にわたり待機する動作をさらに備える、請求項１６に記載の方法。
27. 相対的時間を判定する動作をさらに備える、請求項１６に記載の方法。
28. 時間基準を提供する動作と、前記時間基準を用いて前記相対的時間を判定する動作とをさらに備える、請求項２７に記載の方法。
29. プロセッササイクルのカウンタ値に基づき前記相対的時間を判定する動作をさらに備える、請求項２７に記載の方法。
30. 前記１つ以上の命令の実行に使われる時間量を判定する動作と、前記実行時間を前記一定値に調整するためある期間にわたり待機する動作とをさらに備える、請求項１６に記載の方法。
31. 複数のカウンタ値に基づき経過時間を判定する動作をさらに備える、請求項１６に記載の方法。
32. 前記カウンタ値は、プロセッサのタイムスタンプカウンタである、請求項１６に記載の方法。
33. 前記プロセッサは、ＰＥＮＴＩＵＭ（登録商標）タイプのプロセッサである、請求項３２に記載の方法。
34. 自動テストシステムによって遂行される、請求項１６に記載の方法。

Images