(57)【特許請求の範囲】
【請求項１】
ＴＩＣＣ−パラダイムを使用するマルチコアチップ用の形式的検証された並
列ソフトウェアを構築する方法であって、
用語「ＴＩＣＣ」は「統合された計算と通信のための技術」を意味する英語の略称であり、用語「ＴＩＣＣ−パラダイム」は抽象化の集合を指すために使用され、前記抽象化は、並列ソフトウェアシステムにおけるプログラミング抽象化であると同時にコンポーネントの抽象化でもあり、関連する実装、使用、検証および保全の方法を伴っており、
前記抽象化は、ＴＩＣＣ−Ｐｐｄｅと呼ばれる並列プログラム開発および実行プラットフォーム内のオブジェクトのクラスによって定義され、
前記ＴＩＣＣ−Ｐｐｄｅにおいて定義されたクラスのインスタンスは、ＴＩＣＣ並列プログラムアプリケーション、略称Ａｐを設計および構築するためにシステム構築者によって使用され、
前記ＴＩＣＣ−Ｐｐｄｅは前記Ａｐを設計、アセンブル、検証、使用および保全するためのツールを提供し、前記ＴＩＣＣ−Ｐｐｄｅおよび前記アプリケーションＡｐにおいて共に具現化される全ての抽象化は以下（ｉ）〜（ｉｉ）を可能にし、
（ｉ）並列ソフトウェアシステム用の抽象的設計の仕様に関して、
アプリケーションＡｐ用の並列ソフトウェアシステムの設計者は、因果時間論理言語、略称ＣＴＬ言語においてＡｐが満たすべき要件を指定し、
ＣＴＬ言語は人間およびコンピュータ双方によって理解されるものであり、
Ａｐが満たすべき要件は以降Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）と呼ぶが、
設計者は、Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）を満たす、アプリケーションＡｐ用の抽象的設計を規定し、前記抽象的設計は以降Ａｐ：ｄｅｓｉｇｎ（）と呼ぶが、
前記Ａｐ：ｄｅｓｉｇｎ（）は、Ａｐに用いられる並列ソフトウェア計算ユニットであるセルと、前記セルのポート間を接続する経路のネットワークであるところのＡｐ：ｎｅｔｗｏｒｋ（）を規定することによって規定され、
用語Ａｐ：ＴＩＰｓ（）はＡｐに用いられるスレッド相互動作プロトコルの集合であり、
用語Ａｐ：ｐｏｌｌｉｎｇＯｒｄｅｒｓ（）はＡｐにおいて前記セルの各々がセルに属するポートのポーリングと送受信などの作業を行う順序を規定しており、
用語「抽象的」は、必ずしもコンピュータによって実行可能である必要はないが、コンピュータがイベントクラスの因果連鎖を用いて意図された計算の理論を相互動作を通じて構築することができるような方法で意図された計算の仕様を指すために使用され、
理論上でのあるイベントクラスの発生は理論上での他のイベントクラスの発生をもたらし、
各イベントクラスはイベントインスタンスの有り得る集合を表し、
イベントインスタンスの因果連鎖は、前記Ａｐ：ｄｅｓｉｇｎ（）によって規定される意図した計算の、トレースとも呼ばれる、モデルを構成する理論におけるイベントクラスの因果連鎖に対応し、
モデルが前記Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）における前記要件のいずれにも違反していないことを検証することによって前記Ａｐ：ｄｅｓｉｇｎ（）を対話的に検証し、かつ、前記Ａｐ：ｄｅｓｉｇｎ（）をコンピュータプログラムのその最終の検証された実装に収れんし、
（ｉｉ）意図した計算のイベントクラス理論は、許容イベント発生パターン理論、略称ＡＬＬＥＯＰ理論と呼ばれ、前記Ａｐ：ｄｅｓｉｇｎ（）から対話的に導出されたイベントクラス理論はＡｐ：ＡＬＬＥＯＰ（）と呼ばれ、前記ＴＩＣＣ−Ｐｐｄｅは前記Ａｐ：ｄｅｓｉｇｎ（）において規定された意図された計算において発生する可能性のあるイベントクラスの因果連鎖のパターンを対話的に導出し、前記ＴＩＣＣ−Ｐｐｄｅは前記Ａｐ：ｄｅｓｉｇｎ（）、前記Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）および前記Ａｐ：ＡＬＬＥＯＰｓ（）を使用して以下の（ａ）〜（ｄ）のタスクを行い、
（ａ）前記ＴＩＣＣ−Ｐｐｄｅは前記Ａｐ：ｄｅｓｉｇｎ（）から前記Ａｐ：ＡＬＬＥＯＰ（）を対話的に導出し、
前記ＴＩＣＣ−Ｐｐｄｅは、前記Ａｐ：ＡＬＬＥＯＰ（）を使用して、前記Ａｐ：ｄｅｓｉｇｎ（）が前記Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）における、ＣＴＬ言語においてＡｐが満たすべき要件であるところの、ＣＴＬアサーションのいずれにも違反していないことを対話的に形式的検証し、
用語「形式的検証する」は、コンピュータ内で意図した計算のいずれも実行する必要なく行われる検証を指すために使用され、
（ｂ）ＴＩＣＣ−Ｐｐｄｅは、設計者が、前記Ａｐ：ｄｅｓｉｇｎ（）を連続した詳細化によってコンピュータプログラムの検証された実装に収れんするのを支援し、
詳細化の各段階において、設計者および実装担当者は、前の段階全てにおいてなされた形式的検証全てが保存されるような方法で、意図した計算をより詳細に指定し、
詳細化の各段階において、設計者は前記Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）と前記Ａｐ：ｄｅｓｉｇｎ（）を更新し、
前記ＴＩＣＣ−Ｐｐｄｅは前記Ａｐ：ＡＬＬＥＯＰ（）を自動的に更新し、設計者および実装担当者が、更新された前記Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）を対話的に形式的検証することを支援し、連続した詳細化、連続した相互動作の理論の更新および連続した検証が前の段階全てで行われた全ての検証を保持し、
前記連続した詳細化のプロセスは、アプリケーションＡｐ用の並列ソフトウェアシステムの実行可能なコンピュータプログラムの完成した検証済みの実装を最終的に生じさせ、
詳細化の任意の段階における実装はＡｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）と呼ばれ、
前記ＴＩＣＣ−Ｐｐｄｅを使用して、前記Ａｐ：ｄｅｓｉｇｎ（）が詳細化の各段階における前記Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）内のいずれの要件にも違反していないことを形式的検証し、
また、前記ＴＩＣＣ−Ｐｐｄｅを使用して、完成した前記Ａｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）が前記Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）内の各要件を満たしていることを形式的検証し；
（ｃ）前記ＴＩＣＣ−Ｐｐｄｅは、Ａｐ：ＳＭＳ（）と呼ばれる前記Ａｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）用の自己監視システムを自動的に実装し、
前記Ａｐ：ＳＭＳ（）は、Ａｐにおける計算のタイミングを妨げずに、前記Ａｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）が実行している間、その実行と並行して前記Ａｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を監視し、
前記Ａｐ：ＡＬＬＥＯＰｓ（）において指定されたイベントクラスのイベントインスタンスが、前記Ａｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）が実行している間に発生するが、
ランタイム時のイベントインスタンス発生パターン、すなわちトレースの、前記Ａｐ：ＡＬＬＥＯＰｓ（）においてイベントクラスに対して指定されたものからのどのような逸脱もエラーと解釈され、
前記Ａｐ：ＡＬＬＥＯＰｓ（）において指定されたものからのイベントインスタンスのタイミングの逸脱は遅延エラーと解釈され、
クリティカルな動作は、前記Ａｐ：ＡＬＬＥＯＰｓ（）内のイベントクラスの因果連鎖の特定パターンに関して設計者によって定義され、
（ｄ）前記Ａｐを開発するのに用いられた前記ＴＩＣＣ−Ｐｐｄｅが前記Ａｐで用いられるＡｐ：ｎｅｔｗｏｒｋ（）の中のＡｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を形式的検証するのにも用いられ、前記ＴＩＣＣ−Ｐｐｄｅは検証するために前記Ａｐ：ＡＬＬＥＯＰｓ（）と、アプリケーションＡｐのトレースを意味するＡｐ：Ｔｒａｃｅｓ（）を用い、
前記ＴＩＣＣ−ＰｐｄｅはＡｐ：ｎｅｔｗｏｒｋ（）の仮想メモリに形式的検証時に得られた解を保存し、同じＴＩＣＣ−ＰｐｄｅがＡｐ実行時にも用いられることから、前記ＴＩＣＣ−Ｐｐｄｅによって用いられたすべての検証方法はＡｐの一部をなし、Ａｐはそのライフタイムを通じてＡｐ自体の処理と並行してＡｐ：ＳＭＳ（）を利用し、
また、同様にＡｐはそのライフタイムを通じてＴＩＣＣ−Ｐｐｄｅの検証方法を利用するが、Ａｐが前記検証方法を利用するのはＡｐがスリープモードに設定された後だけであり、Ａｐはスリープモードではすべての意図するサービスを提供することができないため、Ａｐ：ＳＭＳ（）とＴＩＣＣ−Ｐｐｄｅが合わさって初めて、アプリケーションＡｐに対する自己診断、自己修復、および学習能力の開発のための環境が提供され、
ＴＩＣＣ−パラダイムにおける抽象化はＴＩＣＣ−Ｐｐｄｅが上記のサービスを独立して提供できるように、すなわち、他の抽象化とは独立して各抽象化を使用してソフトウェアシステムを構築かつ実行することが可能であり、
そのようなソフトウェアシステムは上記サービス全てを提供するわけではなく、
以下では、「プログラミングの抽象化」という言い回しは、コンピュータプログラムを開発する際に使用される抽象化を指すために使用され、「部品の抽象化」という言い回しは、ＴＩＣＣ−Ｐｐｄｅ並列プログラムおよびアプリケーションＡｐにおいて使用される部品の抽象化を指すために使用される、
前記（ｉ）〜（ｉｉ）を特徴とする、並列ソフトウェアを構築する方法。
【請求項２】
セルの抽象化を使用するための以下のステップをさらに有する請求項１に記載の方法であって、
セルの抽象化は、プログラミングの抽象化であると同時にコンポーネントの抽象化でもあり、単純セルおよび合成セルの２種類のセルが存在し、用語「セル」は単純セルおよび合成セル双方を示すために使用され、合成セルはＴＩＣＣにおける経路によって相互接続されたセルのネットワークをカプセル化し、そのようなカプセル化された合成セルはより大きなシステムにおいてプラグインソフトウェアまたはハードウェアユニットとして使用でき、提供されたポートはより大きなシステム内に存在する合成セルにおけるポートにマッチし、
経路によって相互接続されたセルのネットワークはＴＩＣＣ−ｎｅｔｗｏｒｋと呼ばれ、合成セルによってカプセル化された前記ＴＩＣＣ−ｎｅｔｗｏｒｋはセル分解またはネットワーク詳細化と呼ばれ、単純セルは分解できず、アプリケーションＡｐ用の前記ＴＩＣＣ−ｎｅｔｗｏｒｋはＡｐ：ｎｅｔｗｏｒｋ（）と呼ばれ、前記Ａｐ：ｎｅｔｗｏｒｋ（）は自明な抽象化された合成セルの連続したネットワーク詳細化から得られ、ＴＩＣＣ−パラダイムにおけるセル抽象化の特徴は以下の通りであり、
（ｉ）全ての単純セルについての同じ独自のセルプロセス：
ＴＩＣＣ−Ｐｐｄｅにおけるトップレベルの単純セルクラス、略称Ｃｅｌｌは、前記Ｃｅｌｌ内部において定義されるＣｅｌｌ：ＣＩＰ（）と呼ばれる独自の抽象化セル相互動作プロセスを有し、Ｃｅｌｌ：ＣＩＰ（）は前記Ｃｅｌｌの全てのセルサブクラスＣによって継承され、
前記Ｃｅｌｌ：ＣＩＰ（）からＣによって継承されたＣＩＰプロセスはＣ：ＣＩＰ（）と呼ばれ、前記Ｃ：ＣＩＰ（）は、ＣのインスタンスがＣのポートとどのように相互動作すべきなのかを指定し、Ｃのポートとのセルの相互動作は、Ｃのポートに配信されるメッセージがどのように処理されるか、および／または新しいメッセージがＣのポートを介してどのように構築され送信されるのかによって定義され、
前記Ｃ：ＣＩＰ（）は、ＣのｐｏｌｌｉｎｇＯｒｄｅｒによって指定されるサイクルの順番でＣのポートをポーリングし、かつ各ポーリングサイクルにおいてサービスが行われるように準備された各ポートのサービスを行い、前期Ｃ：ＣＩＰ（）はポーリングサイクルを中断または中止されるまで繰り返し、
異なるサブクラスＣについてのＣ：ＣＩＰ（）は、Ｃ：ＣＩＰ（）の初期化ルーチンＣ：ｉｎｉｔ（）、Ｃおよびそのポートにおいて定義された属性、およびＣで定義されたセル相互動作プロセスにおいてのみ互いに異なり、
Ｃ：ＣＩＰ（）からＣのインスタンスｃによって継承されたセルプロセスはｃ：ＣＩＰ（）と呼ばれ、各ｃ：ＣＩＰ（）についてのコンパイルされたコードは、ＴＩＣＣ−Ｐｐｄｅによってｃに割り当てられた、ｃ．ｃｐｕと呼ばれるＣＰＵのプライベートメモリ内に維持され、前記コンパイルされたコードを使用して前記ｃ．ｃｐｕ内のセルインスタンスｃを実行し、
２つのセルインスタンスはそれらに割り当てられる同じＣＰＵを決して有さず、ｃ：ＣＩＰ（）はセルインスタンスに関連付けられたただ１つのプロセスであり、および、ＣＩＰプロセスはＴＩＣＣ−パラダイムにおける任意の並列ソフトウェアシステム内だけのプロセスであり、
プログラマは、Ｃの各インスタンスｃについて、初期化ルーチンＣ：ｉｎｉｔ（）、Ｃの属性、Ｃ、Ｃ．ｐｏｌｌｉｎｇＯｒｄｅｒ、Ｃ．ｐｏｒｔＰｒｉｏｒｉｔｙおよびＣ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに付属するポートインスタンスの属性、ならびにｃとそのポートとの間の相互動作のみを定義すればよく、前記相互動作とはｃのポートに配信されたメッセージを処理するプログラムであり、かつｃのポートを介してメッセージを構築し送信するプログラムであり、
（ｉｉ）単純セル構造：
各単純セルのサブクラスＣはそれに付属するソフトウェアポート、またはハードウェアポートサブクラスを有し、一般ポート、機能ポートおよび割り込みポートの３つのポートサブクラスが存在し、同じポートサブクラスが必要に応じて複数個１つのセルサブクラスＣに付属し、
用語Ｃ．ｐはＣに付属するポートのサブクラスを指すために使用され、ポートサブクラスＣ．ｐのインスタンスｃ．ｐは、サブクラスＣ．ｐがＣに付属するのと同じ個数Ｃのインスタンスｃに付属し、同じポートインスタンスｃ．ｐは２つ以上のセルインスタンスｃには決して付属せず、ｃはｃ．ｐの親セルと呼ばれ、各ｃ．ｐは１つの独自の通信経路にだけ接続されており、ｃ．ｐに接続された経路はｃ．ｐ．ｐａｔｈｗａｙと呼ばれ、ｃ．ｐは、ｃ．ｐ．ｐａｔｈｗａｙを使用してｃ．ｐ．ｐａｔｈｗａｙに接続された他のセルインスタンスに付属する他のポートとメッセージを交換し、
Ｃの全てのインスタンスｃはＣについて定義されたＣ：ｉｎｉｔ（）を継承し、各Ｃは、それに付属する少なくとも３つのポートサブクラスを有し、すなわち各ポートサブクラスごとに最低１つのポートを有し、各セルサブクラスＣについて定義されたポートの数および種類は、Ａｐ：ｄｅｓｉｇｎ（）が完結する時に自動的に識別され、
このようにして、合成セル分解、すなわちネットワーク詳細化は、実装において使用されるセルのサブクラスを決定し、セル分解は、プログラミング上の考慮によってではなく、アプリケーション領域の既知の知識によって決定され、したがって、設計者が、任意のアプリケーションＡｐにおいて、プログラミング上の考慮に基づくべきセルサブクラスを決定しなければならないこと、あるいはＣ：ＣＩＰ（）用のコンピュータプログラムの定義しなければならないことに何ら問題はなく、設計者は、各セルのサブクラスＣに対して、必要に応じて、Ｃに対して定義されるセルの属性、Ｃに付属するポートサブクラスの種類、Ｃ：ｉｎｉｔ（）プログラム、およびポート相互動作プロトコルで用いるｐｔｈｒｅａｄｓと呼ばれる短い逐次プログラムだけを決めればよく、
（ｉｉｉ）ｃ：ＣＩＰ（）の詳細化：
各抽象的ｃ：ＣＩＰ（）はその初期化プログラムＣ：ｉｎｉｔ（）を継承すること、及び、Ｃの各インスタンスｃのポートｃ．ｐごとに、抽象的ｃ．ｐ：ＴＩＰ（）と呼ばれる、ｃとそのポートＣ．ｐとの間の相互動作を定義するスレッド相互動作プロトコル、略称ＴＩＰが定義されることによって詳細化され、
各抽象的ｃ．ｐ：ＴＩＰ（）はｃ．ｐ：ＴＩＰ（）における計算を行う前記ｐｔｈｒｅａｄｓを指定することによって詳細化され、
前記ｃ．ｐ：ＴＩＰ（）は、ｃがそのポートｃ．ｐに配信されるメッセージをどのように処理すべきか、またはｃ．ｐを介してメッセージをどのように構築し送信するべきかを指定し、抽象的ｃ．ｐ：ＴＩＰ（）の詳細化はＴＩＰ−詳細化と呼ばれ、ＴＩＰ−詳細化は、ポートｃ．ｐにおけるｃによって行われるタスクのための前記ｐｔｈｒｅａｄｓを指定することによって定義され、
ｃ．ｐ：ＴＩＰ（）は、ｃ．ｐ：ＴＩＰ（）を実行している間にｃによって行われる全てのコンピューティングタスク用のコンピュータプログラムが定義されたときに完全にＴＩＰ−詳細化され、ｃに関連付けられた全てのｃ．ｐ：ＴＩＰ（）が完全に詳細化された時にセルプロセスｃ：ＣＩＰ（）は完全に詳細化され、
実装担当者は、新しいポートサブクラスＱを、サブクラスＱが、ＴＩＣＣ−Ｐｐｄｅにおいて既に定義された３つのポートサブクラスでは得られない、所与のアプリケーションに特有の特別なポート属性を含む時だけ定義し、
（ｉｖ）単純セルの自己起動：
各単純セルインスタンスｃは、アプリケーション内の他の単純セルインスタンス全てと並行して独立的に動作し、ｃはＴＩＣＣ−Ｐｐｄｅによってｃに割り当てられたＣＰＵによって実行され、ｃに割り当てられたＣＰＵはｃ．ｃｐｕと呼ばれ、各セルｃは最初のメッセージがそれに配信される時に、自身を起動してｃ．ｃｐｕにおいてそのｃ：ＣＩＰ（）プロセスを実行し、
ｃはまた、ｃによって送信されるメッセージを構築するために、または、ｃによって受信されたメッセージを処理するためにｃ．ｃｐｕが実行する任意のコンピュータプログラムを自身によって起動し、
ｃは全ての割り込み処理を実行するためにも自己起動し、ｃは割り込みによって中断した動作を自動的に正しく再開し、ｃはメッセージの受信に基づきスケジュールされたタスクの全てを自動的に行い、ｃ．ｃｐｕはオペレーティングシステムを使用せず、したがって、並列処理におけるプログラムスケジューリング遅延およびプログラム起動遅延全てを排除し、また、システム管理者の完全性が保証される限りにおいて、各並列プログラムを侵入者には入り込めないようにもして、
（ｖ）単純セル間の通信：
ｃに付属する各ポートｃ．ｐは、各ポートについて定義される、以降では単にプロトコルと呼ばれる通信プロトコルを有し、ｃ．ｐについて定義されたプロトコルはｃ．ｐ．ｐｒｏｔｏｃｏｌと呼ばれ、このプロトコルはｃ．ｐに接続される前記ｃ．ｐ．ｐａｔｈｗａｙに関連付けられ、
因果通信プリミティブ、略称ＣＣＰと呼ばれる機械命令は、経路内のコンポーネント間で信号を交換するために使用され、各ｃ．ｐ．ｐｒｏｔｏｃｏｌは連続して実行されるＣＣＰのシーケンスによって定義され、各ＣＣＰは実行の完了に２ナノ秒しかかからず、ｃ．ｐ．ｐｒｏｔｏｃｏｌの評価に起因して信号はｃ．ｐ．ｐａｔｈｗａｙ上を進行し、信号を交換するｃ．ｐ．ｐａｔｈｗａｙ内のコンポーネントは常に互いに対してチューンされており、すなわち、それぞれは受信する信号を常に受信し、即座に応答する準備ができており、したがって、コンポーネント間の同期セッションによって生じる信号交換時の遅延を排除し、
ｃ．ｐ．ｐｒｏｔｏｃｏｌは前記ｃ．ｐ：ＴＩＰ（）の定義においてのみ現れ、ｃに付属する任意の他のポートｃ．ｑに対するｃ．ｑ．ｐｒｏｔｏｃｏｌは、ｃ．ｐ：ＴＩＰ（）によって行われるコンピューティングタスクを定義するｐｔｈｒｅａｄｓのいずれにおいても現れず、
ｃ．ｐ．ｐａｔｈｗａｙはそれに埋め込まれたポートｃ．ｐに関連付けられた独自の仮想メモリ、ｍを有し、この仮想メモリはｃ．ｐ．ｖＭと呼ばれ、ｃ．ｐ．ｐａｔｈｗａｙ上を進行する信号は、受信ポートが予め指定されているセキュリティ条件を満たす場合にだけｃ．ｐ．ｐａｔｈｗａｙにも接続されたメッセージ受信ポートにｃ．ｐ．ｖＭに書き込まれたメッセージを最終的に配信し、
ｃ．ｐの親セルｃに割り当てられたｃ．ｃｐｕのみがｃ．ｐ．ｐｒｏｔｏｃｏｌを評価することを可能とされ、送信されるメッセージの準備ができてすぐに常に生じるｃ．ｃｐｕによるそのようなプロトコル評価は、セルｃによってｃ．ｐ．ｖＭに完全に書き込まれており、メッセージ書き込み直後のメッセージ送信というこの特徴は、ＴＩＣＣ−Ｐｐｄｅでの全ての通信におけるメッセージスケジューリング遅延を全て排除し、
ｃ．ｐ．ｐｒｏｔｏｃｏｌはｃ．ｃｐｕ以外の任意のＣＰＵによって決して評価されず、２つの別個のＣＰＵ、ｃ１．ｃｐｕおよびｃ２．ｃｐｕによって２つの別個のプロトコル、ｃ１．ｐ．ｐｒｏｔｏｃｏｌおよびｃ２．ｑ．ｐｒｏｔｏｃｏｌの２つの同時評価は、決して互いに干渉せずに、これにより同時の並列メッセージ交換が可能になり、
前記同時の並列メッセージの数はアプリケーション内のセルの数によってのみ制限され、全てのメッセージは常に全てのセルインスタンスによって非同期に交換され、各セルインスタンスは自身でその計算上の不測事態の全てを扱い、
計算上の不測事態とは、新しいコンピュータプログラムを呼び出しかつ実行する必要性、予期しない割り込みに対応する必要性、ｃ．ｃｐｕが現在実行しているプログラムを一時的に中断する必要性、もしくは、中断したプログラムを再開する必要性であり、
各メッセージは常に正確に予測可能なタイミングで配信され、メッセージ配信に対するレイテンシは数十ナノ秒〜数百ナノ秒程であり、各コンピュータプログラムは正確に予測可能なタイミング限界で常に実行され、
（ｖｉ）グループ対グループの通信：
別個のセルインスタンスに付属するポートインスタンスはポートグループに構成され、任意のポートグループ、ｐＧにおける全てのポートは常に同じポートサブクラスのインスタンスであり、同じセルインスタンスに付属する２つのポートインスタンスは同じポートグループｐＧに決して属さず、ポートインスタンスは２つ以上のポートグループに決して属さず、全ての通信は常にグループ対グループ通信であり、各経路は２つの別個のポートグループ、ｐＧおよびｑＧを相互接続し、前記別個のｐＧおよびｑＧは同じセルインスタンスに属するポートを含まず、
ポートグループｐＧに送信する各メッセージ内の各ｃ．ｐに対するｃ．ｐ．ｐｒｏｔｏｃｏｌは、ｃ．ｐの親セルｃに割り当てられたｃ．ｃｐｕによって並行に実行され、ｃ．ｐ．ｐａｔｈｗａｙ内にはエージェントが組み込まれており、ｃ．ｐ．ｐａｔｈｗａｙ内のエージェントはこの並列プロトコル実行を調和し、経路内のエージェントは、ｐＧにおける各ポートの親セルがｐＧにおける全てのポートの親セルによって生成された結合メッセージへのその貢献分の書き込みを完了した後にだけメッセージをディスパッチし、これはディスパッチ調和と呼ばれ、
同じ経路内の第２のエージェントは、その同じ経路に接続された送信先ポートグループ内の全ての安全なポートに経路の仮想メモリにおけるメッセージを同期して配信し、安全なポートは、アプリケーションＡｐのシステム管理者によって送信先ポートグループ内の各ポートについて定義されたセキュリティ条件に基づき前記第２のエージェントによって識別され、
ポートに対するセキュリティ条件は、経路、配信されるメッセージおよび前記ポートにおける仮想メモリの機能であり、メッセージは安全でない送信先ポートには配信されず、メッセージを送信した送り元のポートにはセキュリティ障害についての情報が通知され、ＴＩＣＣ−Ｐｐｄｅにおける全ての通信はグループ対グループの通信であり、点対点の通信はグループ対グループの通信の特別な場合であり、ポートグループがメッセージを自身に送信する自己ループ経路を有することも可能であり、
（ｖｉｉ）保証されたトランザクションの完了：
セルはサービス要求メッセージを別のセルに送信してトランザクションと呼ばれる応答を受け取り、アプリケーション内のセルのＣＩＰプロセスは、任意のセルから受け取ったサービス要求メッセージ全てに対するトランザクションの完了をいかなる時でも保証し、
全てのトランザクションは、正確に予測可能なタイミング限界で完了し、ポートグループ内のポートを介してサービス要求を受け取る前記ポートグループ内のポートの親セルは、受信したサービス要求の処理が成功したか否かについての結合応答を常に返送し、サービス要求メッセージを別のポートまたはポートグループに経路を介して送信するポートｃ．ｐは、ｃ．ｐが送信した最初のサービス要求に対するその返信を受け取った後にだけその次のサービス要求を送信することができ、したがって、ｃ．ｐ．ｐａｔｈｗａｙの仮想メモリは、任意の所与の時間における２つ以上のメッセージ、サービス要求メッセージおよびその応答メッセージを含むことはなく、それにより、バッファ内に維持される複数のサービス要求メッセージの必要性を排除し、これはバッファのない非同期通信と呼ばれる、
前記（ｉ）〜（ｖｉｉ）を特徴とする、方法。
【請求項３】
ポート抽象化を使用するための以下のステップをさらに有する請求項１に記載の方法であって：
ポート抽象化はプログラミング抽象化であると同時にコンポーネント抽象化でもあり、トップレベルのポート抽象化は、ＴＩＣＣ−Ｐｐｄｅにおいて全て事前に定義されるポートのクラスポート、サブクラス一般ポート、機能ポート、および割り込みポートによって定義され、実装担当者は、ポートが既に定義されたポートサブクラスにおいて得られない特別な属性を必要とする時だけ追加のポートサブクラスを定義しなければならず、
ポートについて定義される属性は以下の標準属性：Ｐｏｒｔ．ｉｎｐｕｔ、Ｐｏｒｔ．ｓｔａｔｅ、Ｐｏｒｔ．ｖＭ、Ｐｏｒｔ．ｒｄ．ｍｓｇ、Ｐｏｒｔ．ｗｒ．ｍｓｇ、Ｐｏｒｔ．ｐａｔｈｗａｙ、Ｐｏｒｔ．ｐｒｏｔｏｃｏｌ、Ｐｏｒｔ．ｓｍｍ、Ｐｏｒｔ．ｄｅｌｉｖｅｒｙ、Ｐｏｒｔ．ｃｌｏｃｋ、Ｐｏｒｔ．ｔｉｐＳｔａｒｔ、Ｐｏｒｔ．ｔｉｐＥｎｄ、Ｐｏｒｔ．ｔｉｐＩｎｖｏｋｅ、Ｐｏｒｔ．ｂｅｇｉｎｎｉｎｇＰｏｒｔｓ、Ｐｏｒｔ．ｅｎｄｉｎｇＰｏｒｔｓ、Ｐｏｒｔ．ｓｔａｃｋ、Ｐｏｒｔ．ｔｉｐＲｅｓｕｍｅ、Ｐｏｒｔ．ｒｅｓｕｍｅＳｔａｒｔ、およびＰｏｒｔ．ｒｅｓｕｍｉｎｇＰｏｒｔｓを含み、
セルインスタンスｃに付属するポートインスタンスＣ．ｐの全ての属性は、ｃを実行するように割り当てられたｃ．ｃｐｕの仮想メモリ  ｃ．ｐ．ｖＭおよびｐｒｉｖａｔｅＭｅｍｏｒｙ  ｃ．ｃｐｕ．ｐＭにおいて分散され、
ポートクラスにおいて定義された標準のメソッド、すなわち、オブジェクト指向プログラミングにおけるプログラムは、Ｐｏｒｔ：ｍＲ？（）、Ｐｏｒｔ：ｐＲ？（）、Ｐｏｒｔ：ｓｕｓｐｅｎｄＴＩＰ（ｒｅｓｕｍｉｎｇＡｄｄｒｅｓｓ）、Ｐｏｒｔ：ｆ（）＝ｅｖａｌ（Ｐｏｒｔ．ｐｒｏｔｏｃｏｌ）、Ｐｏｒｔ：ｓ（）＝ｅｖａｌ（Ｐｏｒｔ．ｐｒｏｔｏｃｏｌ）、Ｐｏｒｔ：ｓｕｓｐｅｎｄ（）、Ｐｏｒｔ．ｒｄ：ｍｓｇ（）、Ｐｏｒｔ．ｗｒ：ｍｓｇ（）、Ｐｏｒｔ．ｒｄ：ｗｒｔ（ｍｓｇ）、Ｐｏｒｔ．ｗｒ：ｗｒｔ（ｍｓｇ）、Ｐｏｒｔ．ｒｄ：ｍａｋｅ（ｍｓｇ）、Ｐｏｒｔ：ｗｒ：ｍａｋｅ（ｍｓｇ）、および、Ｐｏｒｔ．ｖＭの他のコンポーネントについて定義される同様のメソッドを含み、実装担当者は必要に応じて他のメソッドを自由に追加することができ、
ポートのサブクラスはそれらについて定義された属性およびメソッドにおいてのみ互いに異なり、ＴＩＣＣ−Ｐｐｄｅにおいてポートについて事前に定義されたサブクラスは、最も並列なプログラミングアプリケーションに適しており、ＴＩＣＣ−パラダイムにおいてポート抽象化によって行われたタスクの特徴は以下であり：
（ｉ）任意の時間に非同期通信を行うこと：
ｃによって選択された任意の時間の任意のポートｃ．ｐに対する属性ｃ．ｐ．ｓｔａｔｅ、ｃ．ｐ．ｉｎｐｕｔ、ｃ．ｐがその最新メッセージを受け取った時間を指定するｃ．ｐ．ｔｉｍｅｓｔａｍｐ、及び、ｃ．ｐ．ｃｌｏｃｋをテストすることは、セルｃがメッセージを受信しかつ処理する、またはｃ．ｃｐｕによって選択された任意の時間にメッセージを送信するために必要であり、
各ポートｃ．ｐは、上記の前記ｃ．ｐの全てへの属性へのアクセス権をｃ．ｃｐｕに常に与え、それによって、ｃ．ｃｐｕによって選択された任意の時間にポートｃ．ｐを介した非同期通信を可能にし、前記非同期通信は、メッセージが配信される時にメッセージを受信する送信先ポートが絶えずメッセージ配信に耳を傾けていることを必要とせず、
（ｉｉ）通信制御方法：
ｃ．ｐはその親セルｃに、ｃ．ｐ．ｓｔａｔｅ＝Ｓの時にだけメッセージを送信することを許可し、ｃ．ｐはその状態がＲである場合にだけ他のセルから配信されるメッセージを受け入れ、このようにして、メッセージ受信ポートおよびメッセージ送信ポートが、同じ時に前記ポートに接続された経路を介してメッセージを全く同時に交換するのを防止し、
ｃ．ｐはｃ．ｐの状態を、メッセージを送信した直後にだけＳからＲに変化させ、ｃ．ｐはｃ．ｐの状態を、応答メッセージを受信し、前記応答がｃ．ｐの親セルｃによって検知された後にだけＲからＳに変化させ、
このようにして、ｃ．ｐは、セルｃがｃ．ｐによって送信された以前のサービス要求メッセージに対する応答メッセージを検知した後にだけｃ．ｐを介して第２のメッセージを送信することができるという規則を遵守し；
（ｉｉｉ）アクセス制御方法：
ｃ．ｐは、ｃ．ｐ．ｓｔａｔｅ＝Ｓの時にだけｃ．ｃｐｕが前記ｃ．ｐ．ｖＭ内の全てのメソッドおよび全てのデータへアクセスできるようにし、そのようなアクセスを任意の他のＣＰＵには与えず、ｃ．ｐは、ｃ．ｃｐｕが意図したタスクを行うことを完了してすぐにｃ．ｃｐｕに与えたアクセスを取消し、このようにアクセスをｃ．ｃｐｕに動的に与えかつ取り消すことは、オペレーティングシステムを使用する必要なく効果的に行われ、この特徴は、ＴＩＣＣ−Ｐｐｄｅ並列ソフトウェアシステム全てにおける各ｃ．ｃｐｕの最低レベルの動作における組み込みデータ保護およびセキュリティを導入し、このことがメッセージが安全なポートにだけ配信されることと合わせて、システム管理者の完全性が保証される限り、ＴＩＣＣ−Ｐｐｄｅ並列プログラムを侵入者が入り込めないものにしており、
（ｉｖ）メモリ干渉を防止すること：
セルグループは、同じ仮想メモリを全て同時に使用することができるポートグループ内のポートの親セルのグループであり、セルグループ内のセルが同じ仮想メモリを同時に使用する時、前記セルに付属し仮想メモリを含む経路に接続されたポートは、セルグループ内のセルに対して仮想メモリの中の別個のメモリ領域を指定し、セルグループ内の各セルは、前記各セルのポートによって前記各セルに割り当てられたメモリ領域にだけ書き込みことが可能とされ、それによって、メモリ干渉を防止し、
同じ仮想メモリを使用するポートグループ内のポートの各親セルは、前記仮想メモリに保存されたプログラムを同時に実行し、前記各親セルは、前記仮想メモリによって各セルに提供されたスクラッチパッドを、前記各親セルのアクティビティを調和するのに必要な情報を掲示しかつ読み込む黒板として使用して、前記仮想メモリ内におけるプログラムを同時に実行する、
前記（ｉ）〜（ｉｖ）を特徴とする、方法。
【請求項４】
仮想メモリ抽象化によって行われる以下のタスクをさらに有する請求項１に記載の方法であって、
仮想メモリ抽象化は、プログラミング抽象化であると同時にコンポーネント抽象化でもあり、トップレベルの仮想メモリクラス、Ｍが存在し、Ｍは、Ｍの任意のインスタンス、ｍに対して、リードメモリ、用語ＲｅａｄＭｅｍｏｒｙ、ライトメモリ、用語ＷｒｉｔｅＭｅｍｏｒｙ、実行メモリ、用語ＥｘｅｃｕｔｉｏｎＭｅｍｏｒｙ、信号メモリ、用語ＳｉｇｎａｌＭｅｍｏｒｙおよびスクラッチパッド、用語Ｓｃｒａｔｃｈｐａｄと呼ばれる５つのメモリパーティションを含み、他のパーティションは必要に応じてＭに追加され、インスタンスｍのパーティションは用語ｒｅａｄＭｅｍｏｒｙ、用語ｗｒｉｔｅＭｅｍｏｒｙ、用語ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ、用語ｓｉｇｎａｌＭｅｍｏｒｙおよび用語ｓｃｒａｔｃｈｐａｄと呼ばれ、
各経路ＰはＰに埋め込まれた１つまたは２つの仮想メモリ、ｍを含み、Ｐはｍの親経路と呼ばれ、各共有メモリ経路、用語ｓｍＰは、常に１つの独自のｍだけを含み、用語ｓｍＰ．ｖＭはｓｍＰに埋め込まれた仮想メモリインスタンスを指し、分散メモリ経路、略称ｄｍＰは、埋め込まれた２つの仮想メモリインスタンスを含み、ｄｍＰに埋め込まれた仮想メモリインスタンスは、任意の仮想メモリインスタンスｍに対してｄｍＰ．ｖＭｓ［ｉ］、１≦ｉ≦２と呼ばれ、ｍ．ｒｄはｍのｒｅａｄＭｅｍｏｒｙコンポーネントを指し、同様に、ｍ．ｗｒ、ｍ．ｅｘ、ｍ．ｓｍおよびｍ．ｓｐはそれぞれ、ｍのｗｒｉｔｅＭｅｍｏｒｙ、ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ、ｓｉｇｎａｌＭｅｍｏｒｙおよびｓｃｒａｔｃｈｐａｄを指し、
さまざまな仮想メモリパーティションに対して読み書きするメソッドは、パーティションのトップレベルクラスにおいて定義され、実行メモリｍ．ｅｘは、ｍの親経路Ｐに接続されたポートの親セルによって使用される全てのメソッドを含み、各ｍ．ｅｘは、そのｍ．ｅｘに保存された各メソッドに対する実行環境を提供し、ｍ．ｒｄは、Ｐに接続されたメッセージ受信ポートに配信されたメッセージを含み、ｍ．ｅｘに保存されたプログラムのコンパイルされたコード全てがｍ．ｅｘ自身において実行され、
ｍ．ｗｒはＰに接続されたメッセージ送信元ポート、ｍ．ｗｒの親セルによって送信されたメッセージを含み、送信元ポートのｍ．ｗｒは送信先ポートのｍ．ｒｄであり、ｍ．ｗｒの中のメッセージは送信先ポートｐに配信され、ｐの親セルはｐに配信されたメッセージをそのｍ．ｒｄだけから読み込み、
ｓｉｇｎａｌＭｅｍｏｒｙ、ｍ．ｓｍは、経路Ｐに接続された各ポートｐに対する、ｐ．ｓｔａｔｅ、ｐ．ｉｎｐｕｔ、ｐ．ｄｅｌｉｖｅｒｙ、ｐ．ｃｌｏｃｋ、および、ｐ．ｐｒｏｔｏｃｏｌに対してコンパイルされたコードの値についてのデータを保持し、
ｍのスクラッチパッド、ｍ．ｓｐは、セルグループ内のセルに対するワーキングメモリを提供して、それらのアクティビティを調和させるために必要とされる情報を互いに交換し、
一方で、前記セルは全て、ｍを並行して同時に使用しており、仮想メモリは、アプリケーションによって１０キロワードから数ギガワードまでのメモリサイズを有し、ＴＩＣＣ−パラダイムにおける仮想メモリ抽象化の特徴は以下であり、
（ｉ）仮想メモリはＴＩＣＣ並列ソフトウェアアプリケーションにおけるセルによって並行に行われる動作を分離し、かつ、数個のセルが同時に同じ仮想メモリを使用する時に調和機構を提供し；
（ｉｉ）仮想メモリは、ＴＩＣＣ並列ソフトウェアアプリケーションにおける特有のセキュリティおよびデータ保護の特徴の実施を可能にし；
（ｉｉｉ）仮想メモリは、並列バッファリング機構を提供して、並列メッセージ送信およびプログラムモビリティをサポートする非同期通信をサポートし；
（ｉｖ）仮想メモリは、分散共有メモリモジュール、略称ＳＭＭを使用して共有メモリマルチプロセッサチップに対する新規なデザインを可能にし、
マルチプロセッサにおけるＣＰＵはチップの１つの層に統合されており、および、ＳＭＭをＣＰＵに相互接続するプログラマブルメモリバスネットワークはチップの第２の平行層に統合され、ＳＭＭはこの第２の層にプラグインしたハードウェアメモリコンポーネントであり、
各ＳＭＭは、それ自身のメモリアドレス指定機構、メモリ割り当ておよびガーベジコレクション機構、ならびにページング機構を提供するアクティブなコンピューティング装置であり、各ＳＭＭは例えば、ＣＰＵと並行してメモリ管理計算を行い、
１つのＳＭＭはアプリケーションＡｐ内の各仮想メモリに割り当てられ、各ＣＰＵは複数のＳＭＭに接続され、および、各ＳＭＭは複数のＣＰＵに接続される可能性があり、
このＳＭＭメモリ構成により、利用可能な技術によってのみ制限される、任意の数の共有メモリＣＰＵが、前記マルチプロセッサチップに統合されるのを可能にし、同じＳＭＭを共有するＣＰＵの数を劇的に制限し、ほとんどのＣＰＵは別個のＳＭＭを使用し、各ＣＰＵは少数のＳＭＭに接続され、ＣＰＵはＣＰＵに接続されないＳＭＭにはアクセス不可能であり、セルに付属するポートはＣＰＵによるＳＭＭへのアクセスを自動的に制御し、ポートは適切な時に、ＣＰＵによるＳＭＭ利用の相互排他を自動的に実施し、それによって、メモリ干渉を劇的に低減させ、かつ、データセキュリティ、システムセキュリティおよび不正な侵入者からの保護を劇的に高め；
ＴＩＣＣ−Ｐｐｄｅは、仮想メモリクラスおよびそのコンポーネント全てに対して組み込み定義を提供し、実装担当者は、ＴＩＣＣ−Ｐｐｄｅにおける任意の並列ソフトウェアシステムについて仮想メモリを定義する必要がない、
前記（ｉ）〜（ｉｖ）を特徴とする、方法。
【請求項５】
エージェント抽象化によって行われる以下のタスクをさらに有する請求項１に記載の方法であって：
前記経路にはポート間通信の同期と調和をつかさどるエージェントが組み込まれており、
エージェント抽象化は、プログラミング抽象化であると同時にコンポーネント抽象化でもあり、トップレベルのエージェントクラスと並列プログラミングに必要とされるエージェントのサブクラス全ては、ＴＩＣＣ−Ｐｐｄｅにおいて事前に定義され、エージェントのさまざまなクラスのインスタンスは、ＴＩＣＣ−Ｐｐｄｅ並列ソフトウェアシステムにおけるポートを相互接続する経路に埋め込まれた仮想メモリに付属し、エージェントが付属する仮想メモリはエージェントの親メモリと呼ばれ、仮想メモリの親経路Ｐも、エージェントの親経路と呼ばれ、各仮想メモリインスタンスｍはそれに付属する任意の数のエージェントを含み、ｓｍ経路およびｄｍ経路に埋め込まれた仮想メモリは通常、それらに付属する２〜４個のエージェントだけを含み、ＴＩＣＣ−パラダイムにおけるエージェント抽象化の特徴は以下であり：
（ｉ）経路のルートに埋め込まれたエージェントは前記経路における信号送信を調和しかつ同期し；
（ｉｉ）ＳＭＭに付属するエージェントはそのＳＭＭに組み込まれたメモリアドレス指定機構を駆動し、エージェントはそのエージェントに付属するポートに対してそれらエージェントの親ＳＭＭへのアクセスを可能にし、エージェントは、２次ストレージ装置および周辺装置から前記エージェントのそれぞれの親ＳＭＭにデータを直接送信し；
（ｉｉｉ）エージェントは、各エージェントの親ＳＭＭにおけるメッセージを、前記メッセージに関連付けられた予め定義されたセキュリティ条件を満足するポートにだけ配信することによってデータセキュリティを実施し；
（ｉｖ）エージェントは、前記親経路において発生するメッセージディスパッチおよびメッセージ配信イベントについて、アプリケーションＡｐの自己監視システム、Ａｐ：ＳＭＳ（）に信号を送信し、これにより、Ａｐ：ＳＭＳ（）は、Ａｐが実行している間にアプリケーションＡｐにおいて発生している通信イベントの因果律網を実時間で構築することが可能になり、Ａｐ：ＳＭＳ（）は、前記通信イベントがＡｐ：ＡＬＬＥＯＰｓ（）におけるイベントクラスパターンを満足しているかどうかを動的に確認し、このような動的な確認により、Ａｐ：ＳＭＳ（）はＡｐが実行している間に、Ａｐにおいて実時間で発生しているエラー、保留中エラーおよび重要なイベントパターンを検出することが可能になり、かつ、Ａｐ：ＳＭＳ（）はそれらを報告すること、または適切な予め定義されている是正措置を即座に開始することが可能になり、このような動的な確認はまた、並列ソフトウェアシステムにおける自己診断、自己修復および学習の今後の開発のためのインフラストラクチャを提供する、
前記（ｉ）〜（ｉｖ）を特徴とする、方法。
【請求項６】
経路の抽象化を使用するための以下のステップをさらに有する請求項１に記載の方法であって：
経路抽象化は、プログラミング抽象化であると同時にコンポーネント抽象化でもあり、各経路はポートに接続され、各経路はエージェントが付属する仮想メモリを有し、経路にはｓｍ経路とｄｍ経路の２種類の経路が存在し、ｓｍ経路は２つのポートグループを相互接続し、ポートグループ内のポートの親セルはセルグループと呼ばれ、ｄｍ経路は、１つの共有メモリマルチプロセッサ、略称ＳＭＰにおける一般ポートのポートグループを他のＳＭＰにおける機能ポートの他のポートグループのセットに相互接続し、トップレベルの経路クラスのｓｍ経路とｄｍ経路とに対するパラメータ化されたプロトコルをＴＩＣＣ−Ｐｐｄｅにおいて事前に定義し、実装担当者はそれらを定義する必要はなく、用語「経路」はｓｍ経路およびｄｍ経路双方を指すために使用され、ＴＩＣＣ−パラダイムにおける経路抽象化の特徴は以下の通りであり：
（ｉ）ｓｍ経路、略称ｓｍＰのパラメータはｓｍＰに接続されるポート、ｓｍＰのエージェント、及び、もしあればセキュリティ機能であり、ｓｍＰの包括的なプロトコルは前記パラメータを用いて定義され、ある任意のｓｍＰのインスタンスに対するプロトコルは包括的なプロトコルのパラメータに前記インスタンスのポートやエージェントに置き換えることによって得られ、置き換えられたパラメータを有するプロトコルはその後コンパイルされ、このコンパイルされたプロトコルはｃ．ｐ．ｖＭの仮想メモリに保存され、
ｃ．ｐ．ｖＭ内のこのコンパイルされたプロトコルへのポインタはｃ．ｐ．ｐｒｏｔｏｃｏｌの値として設定され、ｃ．ｐの親セルは、プロトコルを評価するためのプリミティブｅｖａｌ（ｃ．ｐ．ｐｒｏｔｏｃｏｌ）を使用して、前記ｓｍＰを介してメッセージを送信し；
（ｉｉ）ｄｍ経路、略称ｄｍＰはまた、前記ｄｍＰに接続された任意のポートｑについて同様のパラメータ化されたプロトコル定義を有し、各ｄｍＰはまた、ｄｍＰ内のコンポーネントからなるパラメータのセットによって定義され、ｄｍＰについて定義されたパラメータ化されたプロトコルは、ｄｍＰのパラメータを前記プロトコルにおいて定義されたパラメータと置き換えた後にコンパイルされ、このコンパイルされたプロトコルは仮想メモリ、ｃ．ｑ．ｖＭに保存され、ポートｃ．ｑのプロトコルであるｃ．ｑ．ｐｒｏｔｏｃｏｌの値は前記コンパイルされたプロトコルのコンパイルされたコードへのポインタであり、ポートｃ．ｐの親セルは、プロトコルを評価するためのプリミティブｅｖａｌ（ｃ．ｐ．ｐｒｏｔｏｃｏｌ）を使用して、ｄｍＰを介してメッセージを送信し、それにより、ｓｍ経路およびｄｍ経路双方を介したメッセージ交換のために同一の呼び出しプリミティブ、ｅｖａｌ（ｃ．ｐ．ｐｒｏｔｏｃｏｌ）を使用することが可能であり；
（ｉｉｉ）２つの経路インスタンスはいかなる共通のコンポーネントも共有せず、したがって、２つの別個のセルによる２つの別個のプロトコルの実行は決して互いに干渉せず、これにより、複数の並列非同期メッセージ交換が可能になり、任意の所与の時間におけるこのような並列メッセージ交換の数は、アプリケーション内の別個のセルの数によってのみ制限され、
（ｉｖ）正確に予測可能なタイミングにおけるプロトコルの実行は実時間の通信を可能にし、自己監視システムＳＭＳに伝達されるメッセージディスパッチおよび配信時間は自己監視を可能にし；
（ｖ）正確に予測可能なタイミングにおけるプロトコルの実行はまた、オペレーティングシステムを介さない、アドホックな調和および同期を可能にし、このような同期および調和はＴＩＣＣ−経路によってのみ可能であり；
（ｖｉ）任意の経路において互いに信号を交換する全てのコンポーネントは互いに対してチューンされることで、各コンポーネントは経路内の他のコンポーネントによってその各コンポーネントに送信される信号を受信しかつそれに反応する準備が常にできており、この特徴は信号送信中の同期セッションの必要性を排除し、それによって非常に高速なメッセージ交換が可能になる
前記（ｉ）〜（ｖｉ）を特徴とする、方法。
【請求項７】
プロトコル抽象化を使用するための以下のステップをさらに有する請求項１に記載の方法であって：
プロトコル抽象化は、プログラミング抽象化であると同時にコンポーネント抽象化でもあり、ＴＩＣＣ−Ｐｐｄｅにおける２つの異なった種類のプロトコル抽象化である、ｓｍ経路プロトコル抽象化およびｄｍ経路プロトコル抽象化だけが存在し、
双方の抽象化内のプロトコルは因果通信プリミティブ、略称ＣＣＰを使用して定義され、それぞれの種類のプロトコルはパラメータ化されたプロトコル抽象化として定義され、プロトコル定義はデータ宣言を決して含まず、プロトコルの評価により、前記プロトコルが適用する経路のコンポーネントに関連付けられた属性だけが変化し、２つの同時の並列プロトコル実行は互いに決して干渉せず、
プロトコルの評価は実時間のメッセージ調和、メッセージ同期、セキュリティ実施およびＳＭＳとの通信を自動的に実施し、メッセージは指定されたセキュリティ条件を満足する安全なポートだけに常に配信され、メッセージはメッセージ配信の時間を示すタイムスタンプに同期して安全なポート全てに常に配信され、コンパイルされたプロトコルそれぞれはメッセージを構築し送信する同じセルによって評価され、メッセージはそれらが構築された直後に常に送信され、それによって、メッセージスケジューリングの遅延を排除し、
プロトコルは、全てが２ギガヘルツのＴＩＣＣ−ＣＰＵを使用した場合、ｓｍ経路上で、点対点の通信に対して１０ナノ秒ほどの、およびグループ対グループの通信に対して１００ナノ秒ほどのレイテンシで、ならびに、点対グループの分散通信に対して４００ナノ秒強のデータ送信遅延で、保障された並列非同期同時メッセージ交換を非常に高速で行うことを可能にし、メッセージ配信のレイテンシは常に正確に予測可能であることを特徴とする、方法。
【請求項８】
付属およびチューンの抽象化を使用するための以下のステップをさらに有する請求項１に記載の方法であって：
付属およびチューンの抽象化は純粋にプログラミングの抽象化であって、セルが、ＴＩＣＣ−Ｐｐｄｅ並列プログラミングシステムにおける異なるクラスのコンポーネントにおいて定義された、データにアクセスしメソッドを実行する権利を調整するためにＴＩＣＣ−Ｐｐｄｅにおいて使用され、
各コンポーネントｘは、ｘに付属するまたはチューンする他のコンポーネントにおいて定義されたデータへのアクセスとメソッドの実行のみを行うように制限され、
チューンは経路内で信号を交換するコンポーネントの対に対して行われ、チューンはまた、ポートｃ．ｐとその仮想メモリ、ｃ．ｐ．ｖＭとの間で、またセルｃとｃ．ｐ．ｖＭとの間で行われて、ｃおよびｃ．ｐがｃ．ｐ．ｖＭ内のデータおよびメソッドにアクセスできるようにし、チューンおよび付属によって課されたアクセス制限は、経路がポートにインストールされかつ接続される時にＴＩＣＣ−Ｐｐｄｅによって自動的に実装され、アプリケーションのプログラマはチューンおよび付属を実装するためのどのようなプログラムも書く必要がないことを特徴とする、方法。
【請求項９】
許容イベント発生パターン、略称ＡＬＬＥＯＰの抽象化を使用するための以下のステップをさらに有する請求項１に記載の方法であって：
ＡＬＬＥＯＰはアプリケーションＡｐによって行われる計算の理論の抽象化であり、
ＴＩＣＣ−Ｐｐｄｅは、Ａｐの設計の各段階で、抽象的Ａｐ：ｄｅｓｉｇｎ（）およびＡｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の仕様からＡＬＬＥＯＰ理論を対話的に導出するためのプログラムを含み、
ＴＩＣＣ−Ｐｐｄｅは、ＡＬＬＥＯＰ理論を解釈かつ使用し、ＡＬＬＥＯＰ理論からＡｐによって行われる計算のトレースを導出するためのプログラムと、最先端のモデル確認方法を用いて、Ａｐによって行われる計算の特性がＡｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）のＣＴＬアサーションを満たしていることを形式的検証するために、ＡＬＬＥＯＰ理論から導出した前記トレースを使用するためのプログラムとを含み、
Ａｐ：ＡＬＬＥＯＰｓ（）はＡｐによって行われる全ての計算の完全な理論を規定し、Ａｐ：ＡＬＬＥＯＰｓ（）はアプリケーションＡｐの必要不可欠の部分であり；
ＴＩＣＣ−Ｐｐｄｅは、Ａｐを設計し構築する間にＡｐ：ｄｅｓｉｇｎ（）およびＡｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を検証するために設計者によって使用され、設計者はＴＩＣＣ−Ｐｐｄｅを使用して、完成したＡｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）がＡｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）における全ての要件を満足していることを形式的検証し、
ＴＩＣＣ−Ｐｐｄｅは、命題因果時間論理言語、略称ＰＣＴＬにおいて、モデル確認から得た中間結果をユーザに示し、前記ＰＣＴＬ言語は人間およびコンピュータ双方によって理解されるものであり、ＴＩＣＣ−ＰｐｄｅはユーザからＰＣＴＬで表現された手引きを受け取り、設計者および実装担当者は失敗したモデル確認プロセスのトレースを使用して、アプリケーションの設計および実装を修正し、または必要に応じてＡｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）におけるＣＴＬアサーションを修正し、ユーザの支援は失敗したモデル確認プロセスを中断または停止させる場合に必要となり、ＴＩＣＣ−Ｐｐｄｅはその際、Ａｐ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の仮想メモリ中のすべての検証解のトレースを保存し、；
ＴＩＣＣ−ＰｐｄｅはＡｐの検証解法サブシステムとして用いられ、ＴＩＣＣ−Ｐｐｄｅは、Ａｐ：ＡＬＬＥＯＰｓ（）から導出され、かつ、Ａｐ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）における要件を満足していることを検証するために使用される計算のトレース、および、このような検証を行うために使用される方法の全てを含み、
Ａｐ：ＳＭＳ（）とＴＩＣＣ−Ｐｐｄｅは協力して、Ａｐ：ＳＭＳ（）によって識別されるエラー、保留中エラーおよびクリティカルな振る舞いを自己診断し自己修復することができ、
ＴＩＣＣ−Ｐｐｄｅが定期的な自己メンテナンス時に自己診断及び事故修復している間は、Ａｐは提供するように設計されたすべてのサービスを提供することができないため、Ａｐはスリープモードで動作するように自身を設定する、
ことを特徴とする、方法。
【請求項１０】
ＴＩＣＣ−ＣＰＵによって行われる以下のタスクをさらに有する請求項１に記載の方法であって：
ＴＩＣＣ−Ｐｐｄｅ並列プログラムにおける各セルインスタンスｃは、専用ハードウェア計算ユニット、略称ＣＰＵに割り当てられて、セル相互動作プロセス、ｃ：ＣＩＰ（）において指定された全ての計算および通信を行い、セルｃに割り当てられたＣＰＵはｃ．ｃｐｕと呼ばれ、各セルｃはその専用ｃ．ｃｐｕによってのみ実行され、ｃ．ｃｐｕはｃ：ＣＩＰ（）を実行するための特別な構成を必要とし、ＴＩＣＣ−ＣＰＵは必要とされる前記特別な構成を有するＣＰＵであり、したがって、各ｃ．ｃｐｕは前記ＴＩＣＣ−ＣＰＵであり、任意のＣＰＵを構築するために使用される最先端のハードウェアは前記ＴＩＣＣ−ＣＰＵを構築するためにも使用され、前記ＴＩＣＣ−ＣＰＵの設計における斬新さはそれらを実装するために使用されるハードウェアに存在するのではなく、以下を可能にする各ｃ．ｃｐｕによって行われるタスクの組み合わせに存在し：
（ｉ）並列ソフトウェアシステム、Ａｐにおける各セルｃは、オペレーティングシステムの使用を全く必要とせずに、他のセル全てと並行にＡｐにおいて自律的に動作し；
（ｉｉ）ＴＩＣＣ−ＣＰＵのグループは、前記ＴＩＣＣ−ＣＰＵによって実行されるセルに付属するポートに接続された経路を介してソフトウェア信号を交換することによって並列処理アプリケーションＡｐにおけるＴＩＣＣ−ＣＰＵの他のグループと非同期に通信し；
（ｉｉｉ）ｃ．ｃｐｕは、必要とされるサービスのいずれかを行うためのオペレーティングシステムを使用する必要がなく、セルｃに付属するポートに接続された経路を介してソフトウェア信号を交換するための、因果通信プリミティブ、略称ＣＣＰと呼ばれる特別な機械命令を有し；
（ｉｖ）ＡｐにおけるＴＩＣＣ−ＣＰＵによって行われるタスクの全てのスケジューリング、同期および調和は、このようなソフトウェア信号の交換によって行われ；
（ｖ）ＴＩＣＣ−ＣＰＵは、分散共有メモリモジュール、略称ＳＭＭを、ＴＩＣＣ並列ソフトウェアアプリケーションＡｐ内の仮想メモリとして使用する新しい分散共有メモリ構成を可能にし、Ａｐにおける各仮想メモリはハードウェアにおいて一つのＳＭＭによって実装され、ＴＩＣＣ−ＣＰＵとＳＭＭとの間の接続はプログラマブルメモリバスネットワークによって確立され、各ＴＩＣＣ−ＣＰＵはＴＩＣＣ−ＣＰＵが接続するＳＭＭ内においてのみプログラムを実行し、ＴＩＣＣ−ＣＰＵはキャッシュメモリを有さず、ＴＩＣＣ−ＣＰＵは、ポートに接続された信号線を介してＡｐ内のＳＭＭおよび他のＴＩＣＣ−ＣＰＵとバッファなしで非同期に通信し、ＴＩＣＣ−ＣＰＵはまた、Ａｐ：ＳＭＳ（）内のコンポーネントと同様に通信し；
（ｖｉ）ＴＩＣＣ−ＣＰＵは、ソフトウェア信号交換、非同期プログラム割り込み／再開、プログラムの開始／停止、プログラムの実行のスケジューリング、同期および調和を、オペレーティングシステムの使用を必要とすることなくアドホックな同期および調和によって自動的に管理し；
（ｖｉｉ）各ｃ．ｃｐｕは、そのｃ．ｃｐｕが前記ＳＭＭに保存されたプログラムを実行するために必要であると認定された場合にだけ、接続するＳＭＭにアクセスする権利をｃに付属するポートから自動的に取得し、
ｃ．ｃｐｕは、ＳＭＭに保存されたプログラムへのポインタがｃ．ｃｐｕのプライベートメモリ、ｃ．ｃｐｕ．ｐＭに既に保存されている場合にだけそれらのプログラムを実行することができ、
前記ポインタは、ＳＭＭがｃ．ｃｐｕに接続される時にｃ．ｃｐｕ．ｐＭにインストールされ、ｃ．ｃｐｕ．ｐＭにおけるポインタのインストールはシステム管理者によって最終的に認定され、
いかなるｃ．ｃｐｕも任意のＳＭＭにおける任意の不正な侵入者のプログラムを実行することはできず、Ａｐにおける認定されたプログラムだけがＡｐにおける各ｃ．ｃｐｕによって安全に実行され、このことにより、システム管理者の完全性が保証される場合、共有メモリコンピュータ内のメモリ干渉を劇的に最小化し、かつ、実行効率、データセキュリティ、および不正侵入に対する保護を劇的に高めつつ、Ａｐ内の並列プログラム全てを効率的かつ安全に実行することができる、
前記（ｉ）〜（ｖｉｉ）を特徴とする、方法。
【請求項１１】
ＴＩＣＣ−パラダイムを使用してマルチコアチップ用の形式的検証された並列ソフトウェアを構築し実行するためのシステムであって、前記システムは、
コンピュータの集合と、前記コンピュータの集合において実行されるソフトウエアシステムもしくはハードウエアシステムから構成され、前記システムは、前記ハードウェアまたはソフトウェア内に実装される請求項１から１０のいずれか一項に記載の方法を実行することを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
優先出願番号：６１／１９５，９６５、優先日：１０／１４／２００８
セクションＩ：要約書
セクションＩＩ：背景技術
セクションＩＩＩ：発明の概要
セクションＩＶ：発明を実施するための形態
セクションＶ：特許請求の範囲
セクションＶＩ：図面の簡単な説明
用語：アルファベット順の略語
ＡＬＬＥＯＰ：許容イベント発生パターン
ＣＣＰ：因果通信プリミティブ
ＣＣＳ：通信システム用算法
ＣＩＰ：セル相互動作プロトコル
ＣＰＵ：ハードウェア計算ユニット
ＣＳＰ：通信逐次プロセス
ＣＴＬ：因果時間論理
ｄｍ経路：分散メモリ通信経路
ＥＣＴ：イベント特徴付け表
ＦＳＰ：有限状態プロセス
ｎｄＦＳＰ：非決定的ＦＳＰ
ＮＦＳＰ：非ＦＳＰ
ＯＯ：オブジェクト指向
ｓｍ経路：共有メモリ通信経路
ＳＭＳ：自己監視システム
ＴＩＣＣ：統合された計算と通信のための技術
ＴＩＣＣ−Ｐｐｄｅ：ＴＩＣＣベース並列プログラミング開発および実行プラットフォーム
ＴＩＣＣＮＥＴ：ＴＩＣＣＮＥＴベースローカルエリア通信ネット
ＴＩＰ：スレッド相互動作プロトコル
【背景技術】
【０００２】
セクションＩＩ：（背景技術）
特許の名称：マルチコアチップ用の形式的検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ Ｖ． Ｓｒｉｎｉｖａｓａｎ
顧客番号：００００３３６４１、ＰＣＴ出願
米国国コードおよび優先出願の番号：ＵＳ ６１／１９５，９６５
優先日：２００８年１０月１４日
発明者の住所：２０３１ ＳＥ Ｋｉｌｍａｌｌｉｅ Ｃｏｕｒｔ、Ｐｏｒｔ Ｓａｉｎｔ Ｌｕｃｉｅ、ＦＬ ３４９５２ 電話： ７７２ ３３７ １３８８ Ｆａｘ： ７７２ ３３７ １３８８、携帯電話： ７７２ ２８５ ６４６３ Ｅｍａｉｌ：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
【０００３】
本発明は、ローカルエリアネットワーク、ＴＩＣＣＮＥＴ（ＴＩＣＣベースのローカルエリア通信ＮＥＴ）、によって相互接続されている任意の多数の共有メモリマルチコアチップ（ＳＭＭＣ）または共有メモリマルチプロセッサ（ＳＭＰ）の任意の集合を実行（ｒｕｎ）する形式的検証された超並列ソフトウェアシステムを構築し、８０％〜１００％の効率で実行（ｒｕｎ）するために、ＴＩＣＣ（統合された計算と通信の技術、特許文献１、発明者：Ｃｈｉｔｏｏｒ Ｖ． Ｓｒｉｎｉｖａｓａｎ）をどのように使用するかを教示する。構成と動作は、（ｉ）並列ソフトウェアシステムを設計し、実装し、形式的検証する理想的な環境を提供し、（ｉｉ）セルと呼ばれる並列ソフトウェア計算ユニット間の相互動作の抽象的仕様から始めて、実装をその最終形態まで徐々に詳細化し、（ｉｉｉ）ＴＩＣＣＮＥＴを備えているＳＭＣＣネットワークの多様性の中で超並列ソフトウェアアプリケーションを開発するための適正なプログラミング抽象化とツールとを提供し、（ｉｖ）ＡＬＬｏｗｅｄ Ｅｖｅｎｔ Ｏｃｃｕｒｒｅｎｃｅ Ｐａｔｔｅｒｎ（ＡＬＬＥＯＰ）と呼ばれる定められた計算の正式なイベントベースのモデルを実装の各段階で自動的に生成し、（ｖ）ＡＬＬＥＯＰは因果時間論理言語（ＣＴＬ言語）で記述されている正しさ、タイミング、同期、調和、プログレス、ライブネス、デッドロックが無いことなどの定められている計算の特性を形式的検証するために使用されるだけでなく、（ｖｉ）実装されたアプリケーションの性能を、事前に定められている性能のエラー、起こりそうなエラー、およびアラート状態の発生を識別し報告するために、その動作と平行に、そのタイミングに干渉せずに生涯時間を通して監視する、自己監視システム（ＳＭＳ）を自動的に実装する。
【０００４】
ＴＩＣＣ−Ｐｐｄｅは、ＴＩＣＣベースの並列プログラムを開発し実行するためのソフトウェアプラットフォームである。それは、全ての将来的なアプリケーションソフトウェアをマルチコアチップを備えている様々なデスクトップおよびラップトップコンピュータで実行（ｒｕｎ）する完全に検証された並列ソフトウェアシステムに変換し、それによって今日我々が使用している技術において実現不可能な膨大な計算能力への容易なアクセスを実現する能力がある。
【０００５】
ＴＩＣＣ−Ｐｐｄｅは以下の７つの他のプログラミングパラダイムの修正されたバージョンを採用し、統合する：（ｉ）ＯＯ（オブジェクト指向）パラダイム［Ｍａｒｔｉｎ １、Ａｌａｎ ２，Ａｒｍｓｔｒｏｎｇ ３、Ｂｅｒｔｒａｎｄ ４］、（ｉｉ）アクターにおけるような並列計算［Ｈｅｗｉｔｔ、５］［Ａｇｈａ，６］［Ｃｌｉｎｇｅｒ、３７］、（ｉｉｉ）π算法におけるような相互動作の指定［Ｍｉｌｎｅｒ、７、８、９］、（ｉｖ）ＣＳＰ（通信逐次プロセス）［Ｈｏａｒｅ、１０、１１、１２］におけるような計算と通信との統合、（ｖ）ＦＳＰ（有限状態プロセス）［Ｍａｇｅｅ＆Ｋｒａｍｅｒ、１３］による設計の検証と同様な実装の検証、（ｖｉ）［Ｈｏａｒｅ、１５］と［Ｍａｎｎａ、１６、１７、１８］と同様なＮＦＳＰ（非ＦＳＰ）システムの検証、（ｖｉｉ）修正ＲＥＳＴＣＬＫ経路［Ｄａｓ、１９］を使用した通信。ＴＩＣＣ−Ｐｐｄｅで使用される通信機構、並列プログラミング構成、および検証方法は新規である。
【０００６】
これらのパラダイムの統合は、ＴＩＣＣの変形例の仕様によって可能になり、それによってハードウェアとソフトウェア計算コンポーネントが信号をプログラムに従って交換できるようになる。全ての通信、並列プロセスおよびｐスレッド（並列スレット）の相互動作、セキュリティの実施、割り込み処理、同期、協調、および自己監視は、すべてのソフトウェアとハードウェアのコンポーネントの相互分離を維持しながら、オペレーティングシステム（ＯＳ）の使用を必要とせずにプログラムに従っている信号交換によって駆動される。セルと呼ばれるアプリケーションのソフトウェア計算コンポーネントは並列に動作し、ＦＳＰ［Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ、１３］およびＣＣＳ（Ｃａｌｃｕｌｕｓ ｆｏｒ Ｃｏｍｍｕｎｉｃａｔｉｎｇ Ｓｙｓｔｅｍｓ）［Ｍｉｌｎｅｒ、１４］でのようにタイムスライスされた並行性では動作しない。各セルはそれ自体の割り当てられているハードウェアＣＰＵ内で動作し、他のセルはＣＰＵが割り当てられているセルがその動作を中断したり中止し、そのＣＰＵを解放しない限りそのＣＰＵを使用しない。ＴＩＣＣベースの並列処理には多数のＣＰＵを必要とし、受け入れることができる。並列プログラミングを簡単にし、正式な検証と動的な自己監視のためのメソッドを提供する以外に、ＴＩＣＣ−Ｐｐｄｅは（発明の概要）セクションで概説する数個の他の利点をもたらす。
【０００７】
（発明を実施するための形態）セクションは、以下の一連の例を示しており、（ｉ）構成の原理、（ｉｉ）通信と計算の性質、（ｉｉｉ）実装から自動的に導出されるＡＬＬＥＯＰによって定義されるような計算のモデル、（ｉｖ）ＡＬＬＥＯＰから自動的に導出されるＥＣＴ−ネットワーク（イベント特徴付け表ネットワーク）上での所与のＣＴＬアサーション（因果時間論理アサーション）の評価を使用した実装の検証、および（ｖ）同期、調和、データ保護、セキュリティの実施、および自己監視である。
【０００８】
ＴＩＣＣＮＥＴは、各々が３２または６４個以上のプロセッサを備えている高々２５６またはそれ以上のＳＭＭＣ（共有メモリマルチプロセッサチップ）および／またはＳＭＰ（共有メモリマルチプロセッサ）を含んでいるローカルエリアスーパーコンピューティンググリッドにおけるＳＭＭＣおよび／またはＳＭＰ間のグループ対グループ、高速メッセージ交換に使用できるＴＩＣＣベースの分散メモリハードウェア通信ネットワークである。１つのチップに統合されている複数のＳＭＭＣを備えているマルチコアチップを近い将来は予測している。ＴＩＣＣＮＥＴ自体は、チップ内のＳＭＰ間の、高速、グループ対グループ、分散メモリメッセージ交換のために、そのようなマルチコア、マルチＳＭＰチップに統合されることを仮定している。ＴＩＣＣＮＥＴ内の分散メモリ経路の構造だけを本特許出願内で説明し、ＴＩＣＣＮＥＴ内に経路をインストールし、メッセージをインストールされた経路上を送信する機構については説明しない。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許第７，２１０，１４５ Ｂ２号
【発明の概要】
【課題を解決するための手段】
【００１０】
セクションＩＩＩ：課題を解決するための手段
特許の名称マルチコアチップ用の形式的検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ Ｖ． Ｓｒｉｎｉｖａｓａｎ
顧客番号：００００３３６４１
米国国コードおよび優先出願の番号：ＵＳ ６１／１９５，９６５
優先日：２００８年１０月１４日
発明者の住所：２０３１ ＳＥ Ｋｉｌｍａｌｌｉｅ Ｃｏｕｒｔ、Ｐｏｒｔ Ｓａｉｎｔ Ｌｕｃｉｅ、ＦＬ ３４９５２ 電話： ７７２ ３３７ １３８８ Ｆａｘ： ７７２ ３３７ １３８８、携帯電話： ７７２ ２８５ ６４６３ Ｅｍａｉｌ：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
【００１１】
１．連続した詳細化による実装：ＴＩＣＣ−パラダイムは、セルと呼ばれる一式の並列ソフトウェア計算ユニットの相互動作の抽象的仕様から始める連続した詳細化によるアプリケーション実装の方法を導入する。セルはセルに付属しているポートに接続されている通信経路を通して互いにメッセージを交換することによって並列計算を実行する。存在する場合に、名前と引数だけが、呼び出され実行される実装文脈と共に実装において指定されているが、それらを実装したコンピュータプログラムが定義されていない場合にだけ、メッセージサブグラス、メソッド、ｐｔｈｒｅｄまたは条件は抽象的である。詳細化には、メッセージサブクラスの定義と、アプリケーションの所与の抽象的デザインにおける抽象的メソッド、ｐｔｈｒｅａｄ（並列スレッド）、および条件を定義するコンピュータプログラムが関わっている。詳細化は所与の抽象的仕様におけるセル間のメッセージの流れに従ってゴールに向かう態様で実施される。詳細化の各段階で、定義されたコンピュータプログラムによって実行される計算のＡＬＬＥＯＰモデルが実装の仕様から自動的に導出される。モデルは、詳細化の様々な段階において、ＣＴＬ言語（因果時間論理言語）でアサーションされている特性を確認するために使用される。実装はコンピュータプログラムが実装の全ての抽象的メソッド、ｐｔｈｒｅａｄ、および条件に対して定義されており、メッセージサブグラスが完全に定義されている場合に完全に詳細化される。
【００１２】
２．ＡＬＬＥＯＰと証明：ＡＬＬＥＯＰは（発明を実施するための形態）のセクション２で説明しているように、アプリケーションにおいて許容されるイベント発生パターンを指定する。２種類のイベントクラスが存在し、通信イベントクラスとアクションイベントクラスである。おおまかには（詳細には（発明を実施するための形態）のセクション２と５）、通信イベントクラスは、対（ｐＳ，ｔ）、（ｐＦ，ｔ）、または（ｐＤ，ｔ）であって、ここで、ｐはメッセージを経路を介して送信、転送、または受信するポート、添え字Ｓは送信、添え字Ｆは転送、添え字Ｄは配送であって、タイムマップと呼ばれるｔはアプリケーションの実行（ｒｕｎ）においてイベントクラスのインスタンスが発生する可能性のある時間点の順序を意味する。アクションイベントクラスは対、（名前，ｔ）であって、名前は変数、条件、またはアクションであって、ｔは名前の付けられた変数が設定またはアサーションされる、名前が付けられている条件がｔｒｕｅになる、または名前が付けられているアクションが実行される時間点の順序を表しているタイムマップである。アクションイベントのインスタンスは並列計算の世界状態を変化させることがあるが、通信イベントのインスタンスは通信経路内のコンポーネントの状態を変化させるだけである。
【００１３】
正しい動作のための条件：イベントクラス（Ｘ，ｔ）のイベントインスタンスを指す場合にＸ（ｔ１）と書き、イベントインスタンスＸは時刻ｔ１に発生する。ＡＬＬＥＯＰにおいて（ＸはＹの原因である）が真の場合に（Ｘ→Ｙ）と書き、条件Ｃ（Ｘ，Ｙ）が真の場合にだけ（ＸはＹの原因である）場合に（ＸＣ（Ｘ、Ｙ）→Ｙ）またはＣ（Ｘ、Ｙ）？（）（Ｘ→Ｙ）と書く。因果関係は非再帰的、推移的、非対称関係の意味であって、（Ｘ→Ｘ）は不可能、（Ｘ→Ｙ）＆（Ｙ→Ｘ）も不可能、（Ｘ→Ｙ→Ｚ）は（Ｘ→Ｚ）を意味し、（ＸＣ（Ｘ、Ｙ）→ＹＣ（Ｙ、Ｚ）→Ｚ）は（ＸＣ（Ｘ、Ｙ）＆Ｃ（Ｙ、Ｚ）→Ｚ）を意味する。因果チェーンは（Ｘ→Ｙ→Ｚ）または（ＸＣ（Ｘ、Ｙ）→ＹＣ（Ｙ、Ｚ）→Ｚ）でのように、連続した因果関係の連結である。因果関係は以下のように解釈される。
【００１４】
解釈１：アプリケーションの実行（ｒｕｎ）において、ＸのインスタンスＸ（ｔ１）がＹのインスタンスＹ（ｔ２）を発生させる場合、（Ｘ→Ｙ）が真または（ＸＣ（Ｘ、Ｙ）→Ｙ）＆＜Ｃ（Ｘ，Ｙ）＞（ｔ２）がＡＬＬＥＯＰにおいて真でなければならず、また両方の場合において（ｔ２≦ｔ１＋τ（Ｘ、Ｙ））が成立しなければならない。
【００１５】
項（Ｃ（Ｘ，Ｙ））（ｔ２）は条件Ｃ（Ｘ，Ｙ）が時刻ｔ２で真であることをアサーションしている。項τ（Ｘ，Ｙ）は２つのイベントインスタンス（Ｘ，Ｙ）の発生の間の許容される最大遅延である。実装者は、これらの最大値を設計時に予測し、完成した実装を使用した実験の後にこれらを確定する。アプリケーションの因果律網はそのアプリケーションの実行（ｒｕｎ）中に発生する可能性のある通信イベントインスタンスの全ての可能性のある因果チェーンの集合を表しており、アクションイベントは無視されている。アプリケーションの因果律網において以下の条件１が成立する場合にだけアプリケーションは正常に動作する（セクション６．５、（発明を実施するための形態））。
条件１：∀（Ｘ）∀（ｔ１）∀（Ｙ）∀（ｔ２）［Ｘ（ｔ１）→Ｙ（ｔ２）］
⇒［（Ｘ→Ｙ）∨（（ＸＣ（Ｘ、Ｙ）→Ｙ）＆〈Ｃ（Ｘ，Ｙ）〉（ｔ２））］＆
（ｔ２≦ｔ１＋τ（Ｘ、Ｙ））］
【００１６】
この条件は、アプリケーションの任意の実行（ｒｕｎ）中に発生する可能性のある全てのイベントインスタンスについて解釈１が成立しなければならないことをアサーションしている。ここでのタイミングは計算をモデル化するために使用されるイベントの特性であって、計算のパラメータではない。各計算ステップは関連付けられている１つまたは２つ以上のイベントを有している。全てのそのようなイベントは実時間の別個の点で発生する。証明構築中に、時間点はＡＬＬＥＯＰＳにおいて指定されたタイムマップに整合するようにイベントに対して要求されている。イベントのタイミングを条件１内の厳格な境界τ（Ｘ、Ｙ）内で予測する能力はＴＩＣＣ−Ｐｐｄｅの実行特性（（発明を実施するための形態）のセクション４．６）と以下で特徴４と呼ぶ高速化技法の排除の結果である。イベントの発生パターン、因果チェーン、それらに関連付けられている条件、イベントタイミング、および計算ユニットの状態はすべて証明構築において使用される。
【００１７】
ＡＬＬＥＯＰはＦＳＰ（有限状態プロセス）とＮＦＳＰ（非有限状態プロセス）の両方をモデル化する。Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ［１３］において使用されているＦＳＰモデルとは異なり、ＡＬＬＥＯＰは意図したシステム設計のモデルではなく、詳細化の様々な段階での実装の仕様から自動的に導出される実際の実装のモデルである。トレースはＡＬＬＥＯＰから自動的に導出され、ＥＣＴ（イベント特徴付け表）もトレースから自動的に導出される。ＥＣＴネットワークはトレース内の情報をＡＬＬＥＯＰの証明構築に便利な表形式で表している。ＥＣＴネットワーク上でのＣＴＬアサーション（因果時間論理アサーション）として記述されている実装の特性の相互作用の証明はシンボリック評価を通して構築される。ＣＴＬアサーションはＣｌａｒｋ［３８−４０］、Ｅｍｅｒｓｏｎ、［４１］およびＳｉｆａｋｉｓ［４２］アサーションと同様であって、［Ｍａｇｅｅ＆Ｋｒａｍｅｒ、１３］で使用されるＦＳＰ言語ともある意味で同様である。しかし、違いが存在し、それは、（発明を実施するための形態）に示している例において見ることができる。ＣＴＬアサーションで使用される特定の構文は一般に受け入れられる明確な解釈［３８−４２］を有しているかぎり重要ではない。
【００１８】
証明にはＣＴＬ言語用の推論エンジンは必要なく、証明にはＥＣＴネットワーク（ＥＣＴのネットワーク）上でＣＴＬアサーションを評価するメソッドが必要なだけである。しかし、証明には命題論理式用の推論エンジンが必要である。ＥＣＴネットワーク上でのＣＴＬ表現の評価によって証明に必要な命題推論用の文脈が得られる。ユーザが実装と証明するＣＴＬアサーションを指定し、証明に関連する可能性のある定義、原理、他のＣＴＬ表面を提供する。証明メソッドは、（発明を実施するための形態）のセクション６に示している。有限ＡＬＬＥＯＰは等価ＦＳＰモデルを有しているものである。所与のＡＬＬＥＯＰはＦＳＰとＮＦＳＰの特性の両方を有しており、後者の証明は必ずより複雑である。
【００１９】
３．動的自己監視、ＳＭＳ：ＳＭＳ（自己監視システム）はＴＩＣＣ−Ｐｐｄｅプログラム実行機構に本来備わっている組み込み部分である。したがって、アプリケーションＡのＴＩＣＣ−Ｐｐｄｅ実装がいったん完了すると、自己監視は自動的である。実装はＳＭＳのどのような部分も指定する必要がない。ＳＭＳは、Ａの生涯時間の間、実行の効率とＡのタイミングをほとんどまたは全く低下させることなく、Ａの実行（ｒｕｎ）と並列に、実行（ｒｕｎ）中にアプリケーションＡ用の因果律網を動的に生成し、Ａの因果律網はＡの実行（ｒｕｎ）中に発生する通信イベントチェーンの全ての、そしてそれらだけのネットワークである。条件１が満たされないと常にエラーが報告され、ＡＬＬＥＯＰＳの何らかのイベントクラスＸとＹについて条件１で指定された条件τ（ｘ、ｙ）が満たされない場合にだけ差し迫ったエラーが報告される。重要な振る舞いのパターンを、ＡＬＬＥＯＰノードを終端記号として使用して正規文法で定義し、定義されたパターンのいずれかが因果律網内で発生すれば常にＳＭＳにアラートを発行させることさえできる。ＳＭＳは自己診断、自己修復、および学習能力のためのインフラストラクチャを提供する。
【００２０】
４．高速並列通信：２００７年４月２４日付けの米国特許第７，２１０，１４５ Ｂ２で説明しているように、ＴＩＣＣはＲＥＳＴＣＬＫ［Ｄａｓ，１９］通信パラダイムを採用している。ＴＩＣＣ内の通信は、接続指向であって、２つのセルは通信経路によって互いに接続されているポートを有している場合にだけ互いに通信することができる。ＲＥＳＴＣＬＫをＴＩＣＣ−Ｐｐｄｅに適用することによって、経路内のコンポーネント間の信号の交換に使用されるプロトコルが変化し、ＳＭＳを組み込むように経路の構造が修正され、最も重要なことは、ＲＥＳＴＣＬＫとは異なり、保証された高速メッセージ配信による並列で、同時で、即時の非同期通信が可能になる。
【００２１】
各ポートはポートの親セルと呼ばれる１つのセルだけに付属させることが可能で（ポートの競合を防止）、各ポートは１つの経路にだけ接続することができる（メッセージ干渉の防止）。すべてソフトウェアコンポーネントである３種類のポート、サービス要求メッセージの送信に使用される一般ポート、サービス要求メッセージの受信と応答に使用される機能ポート、および割り込みメッセージの受信とそれらへの応答に使用される割り込みポートが存在する。各セルは各種類のポートを少なくとも１つ有していなければならない。
【００２２】
米国特許第７，２１０，１４５ Ｂ２号に記載されているＴＩＣＣは、アプリケーションＡの他のセルと並列に動作する通信プロセッサと呼ばれる特別なセルを使用してメッセージ交換をスケジュールし実装した。アプリケーションＡの各セルはそのセルのポートに接続されている経路を介したＡの通信プロセッサへメッセージを送信するために要求を送信した。通信プロセッサは要求で指定されている経路に関連付けられているプロトコルを実行することによってメッセージを送信した。プロトコルは、通信プロセッサによって要求が受信された順番で実行された。したがって、共有メモリ環境においてメッセージを配信するのに１ギガビット／秒のメモリバスを備えている２ギガヘルツＣＰＵを使用し２〜３００ナノ秒しかかからなくても、メッセージを配信するレイテンシは６から１０マイクロ秒にもなり、これはメッセージを送信する要求がキュー内で通信プロセッサのサービスを受けるその順番を待たなければならないせいかもしれない。アプリケーション内で並列に同時に送信できるメッセージの数はそのアプリケーション内の別個の通信プロセッサの数に限定されている。
【００２３】
この構成は、通信プロセッサが使用されない以下で概略を説明するＴＩＣＣ−Ｐｐｄｅの並列メッセージ交換機構とは対照的である。各セル自体は自身のメッセージを送信し配信し、同時に並行に送信可能なメッセージの数は、アプリケーション内の別個の経路の総数によってだけ制限される。さらに、通信は共有メモリ環境と分散メモリ環境との両方で発生する可能性がある。ＴＩＣＣ−Ｐｐｄｅの通信の特徴を以下で箇条書きにする。
【００２４】
（４−ｉ）経路とプロトコル：セルＣの各ポートＣ．ｐは独自の経路、Ｃ．ｐ経路に接続されている。ｓｍ経路（共有メモリ経路）とｄｍ経路（分散メモリ経路）の２種類の経路が存在する。経路という用語はそれらのいずれか一方を指す。メッセージを配信する経路だけが関連付けられている仮想メモリを有している。メッセージを配信しないが信号だけを配信する経路は単純な経路と呼ばれる。仮想メモリは経路がインストールされた時点で経路に対して宣言される。実際のメモリはコンパイル時または実行（ｒｕｎ）時に仮想メモリに割り当てられる。仮想メモリは交換されたメッセージを保持し、またメッセージを処理し構築するメソッドとｐｔｈｒｅａｄ（並列スレッド）も保持する。
【００２５】
各ｓｍ経路は関連付けられている唯一の仮想メモリを有している。Ｃ．ｐ．ｐａｔｈｗａｙがｓｍ経路の場合、Ｃ．ｐ．ｖＭはＣ．ｐ．ｐａｔｈｗａｙの仮想メモリを指す。Ｃ．ｐ．ｐａｔｈｗａｙがｄｍ経路の場合は、Ｃ．ｐ．ｐａｔｈｗａｙに接続されている各ポートｑ（Ｃ．ｐはポートｑの１つ）は別個の仮想メモリ、ｑ．ｖＭを有することになって、これらの別個の仮想メモリはｄｍ経路によって相互接続されている別個のＳＭＰ（級友メモリマルチプロセッサ）内に存在する。各ポートＣ．ｐは関連付けられている別個のプロトコルＣ．ｐ．ｐｒｏｔｏｃｏｌを有している。ポートＣ．ｐの親セルＣだけがＣ．ｐ．ｐｒｏｔｏｃｏｌを実行することができる。ＣはＣ．ｐ．ｐａｔｈｗａｙ上で信号を送信するためにＣ．ｐ．ｐｒｏｔｏｃｏｌを実行する。Ｃ．ｐ．ｐａｔｈｗａｙ上を進行する信号は、Ｃ．ｐ．ｖＭのメッセージがＣ．ｐ．ｐａｔｈｗａｙがｓｍ経路である場合にＣ．ｐ．ｐａｔｈｗａｙに同様に接続されている意図した受信ポートに配信されるメッセージ文脈を最終的に確立する。Ｃ．ｐ．ｐａｔｈｗａｙがｄｍ経路の場合、Ｃ．ｐ．ｖＭのメッセージはハードウェア送信線を介して同じｄｍ経路の他のポートｑの仮想メモリ、ｑ．ｖＭに送達される。ＴＩＣＣＮＥＴはアプリケーション内の全てのｄｍ経路を含んでいる通信ネットワークである。ＴＩＣＣＮＥＴの別個のｄｍ経路の数は、何千になることもある。単純な経路は、それらに関連付けられていない仮想メモリを有することはない。
【００２６】
（４−ｉｉ）プロトコルとＣＣＰ：全てのプロトコルはＣＣＰ（因果通信プリミティブ）のシーケンスによって定義されており、実行時に、プロトコルに関連付けられている経路内のコンポーネントに信号を相互に交換させ受信した信号に応答させる。各ＣＣＰはＸ：ｘ→Ｙの形態を有しており、ＸとＹとは経路に埋め込まれているコンポーネントであって、ｘは信号である。プロトコルはＣＣＰの連結によって定義されており、連結はＸ：ｘ１→Ｙ：ｘ２→Ｚの形態を有しており、Ｘ、Ｙ、およびＺはすべて同じ経路内のコンポーネントであって、ｘ１とｘ２は信号である。経路コンポーネントによって交換される信号は経路上を進行し、メッセージ配信または送信のための文脈を最終的に確立する。プロトコルのＣＣＰは（発明を実施するための形態）のセクション１と７に記述されているように、他のプログラミングステートメント内に埋め込まれて出現することもある。
【００２７】
各ＣＣＰの動作は、（発明を実施するための形態）のセクション１で説明するように、経路コンポーネント内に埋め込まれているｎｄＦＳＭ（非決定的有限状態機械）によって定義されており、１００メガビット／秒のメモリバスを備えている２ギガヘルツＣＰＵ（ハードウェア計算ユニット）内でソフトウェアに実装されているＣＣＰを実行するのに２５〜５０ナノ秒かかる。ＣＣＰは、ハードウェア機械命令としてＣＰＵ内に実装されていてもよい。ハードウェアに実装されている場合、ＣＣＰの実行は２ギガヘルツＣＰＵ内で５ナノ秒未満となる。
【００２８】
（４−ｉｉｉ）スケジューリング遅延の排除：メッセージを送信するために、セルＣはそのポートＣ．ｐの１つに関連付けられている仮想メモリ、Ｃ．ｐ．ｖＭ内に送信されるメッセージを書き込む。Ｃ．ｐ．ｖＭ内にメッセージを書き込んだすぐ後に、セルＣ自体は同様にＣ．ｐに関連付けられているプロトコルＣ．ｐ．ｐｒｏｔｏｃｏｌを実行する。Ｃ．ｐ．ｐｒｏｔｏｃｏｌの実行によって、信号がＣ．ｐ．ｐａｔｈｗａｙに沿って進行する。Ｃ．ｐ．ｐａｔｈｗａｙ経路はｓｍ経路またはｄｍ経路のことがある。メッセージを書き込むイベントとプロトコルを実行するイベントとは、同様に発生し、どのような種類の経路がポートＣ．ｐに接続されていても、プロトコルが実行されている間に経路上を進行する信号はＣ．ｐ．ｖＭ内のメッセージを最終的にその意図した受信者に配信つまり搬送する。仮想メモリの無い経路は、メッセージ無しに信号だけを意図した受信者に配信することになる。
【００２９】
プロトコルの実行中に、セルはプロトコル自体で定義されていないどのようなメソッドも使用せず、セルもセルの外部のどのようなプロセスも呼び出さない。メッセージを作製し仮想メモリに書き込むためにセルによって実施される計算と、メッセージ／信号をその意図した受信者に送達するために同じセルによって実施される計算との間には、それらの計算を定義するコンピュータプログラムの詳細を除いて違いはない。両方の計算は、厳密にそのセルに限定され、他のセルで発生していることとは完全に独立している。メッセージの作製とメッセージ／信号の送信とはセルがメッセージ／信号の送信の準備ができるとすぐに同じセルによって即座に実施されるので、スケジューリング遅延が完全に排除される。
【００３０】
（４−ｉｖ）同期遅延の排除：同期遅延は信号を交換する各経路のハードウェアとソフトウェアコンポーネントとを互いに対して常にチューンされている状態に維持することによって排除される。そのような各コンポーネントは、その経路内の他のコンポーネントによって送信された信号を受信し即座に応答する準備が常にできていることになる。この種類のチューンは、（発明を実施するための形態）のセクション１に記述されているメソッドを使用して実現される。信号交換中にチューンによって同期遅延が完全に排除される。
【００３１】
（４−ｖ）非同期通信と逐次バッファリングの排除：全てのセルは準備ができると任意の時間にメッセージ／信号を送信し配信する可能性がある。メッセージ送信セルとメッセージ受信セルのいずれも通信中にブロックされることはない。全てのメッセージ／信号交換は非同期である。（発明を実施するための形態）で説明するように、逐次バッファリングはそのような非同期メッセージ／信号交換に対応するためには使用されず、代わりに経路の仮想メモリを使用した並列バッファリング機構が使用される。
【００３２】
（４−ｖｉ）並列同時メッセージ交換：常に別個のセルが別個の経路に関連付けられている別個のプロトコルだけを同時に実行する。これは、（ａ）各セルはそれに付属しているポートにだけ関連付けられているプロトコルを実行できる、（ｂ）各セルは常に１つのプロトコルだけ実行できる、（ｃ）各ポートは唯一のセルにだけ付属している、（ｄ）経路は同じセルに付属している２つのポートの間でメッセージを送信しない、（ｅ）経路に接続されているメッセージ送信ポートの親セルとメッセージ受信ポートの親セルの両方がその経路に関連付けられているプロトコルを実行することはいかなる時にもできない、（ｆ）経路に接続されている２つ以上のメッセージ送信ポートの親セルによるその経路のプロトコルの同時の実行をその経路上のエージェントが自動的に調和させる、（ｇ）経路（ｓｍ経路またはｄｍ経路）のプロトコルの実行はその経路のコンポーネントの状態だけを変化させ、それ以外は変化させない、（ｈ）２つの経路（ｓｍ経路またはｄｍ経路）は共通のコンポーネントを共有することはない、（ｊ）各セルは他のどのようなセルとも共有されていない自身に割り当てられているＣＰＵ内で実行される、ためである。これらの特徴が共に相互干渉無しに別個のセルによるプロトコルの同時の並列の実行を保証し、それによってｓｍ経路とｄｍ経路の両方での並列メッセージ送信を可能にし、そのような並列の同時のメッセージ送信はアプリケーション内の別個の経路の数によってのみ制限される。
【００３３】
（４−ｖｉｉ）保証された高速並列通信：ＴＩＣＣ−Ｐｐｄｅにおける通信の以下の４つの特徴が２〜３００ナノ秒以下の範囲のレイテンシでの高速の並列メッセージ交換を保証する。（ａ）プロトコルの実行はいかなるプロセスによっても割り込まれない、（ｂ）複数のメッセージを別個の経路を介して並列に交換することが可能である、（ｃ）全ての同期とスケジューリングの遅延は完全に排除される、（ｄ）逐次バッファリングが非同期通信で使用されない。
【００３４】
ＣＣＰが１ギガビット／秒のメモリバスを備えている２ギガヘルツ計算ユニット内に機械命令としてハードウェア内に実装される場合、点対点メッセージはｓｍ経路を介して数十ナノ秒で交換することができる。ポートの１つのグループからポートの他のグループへのｓｍ経路を介したグループ対グループメッセージ交換は、各ポートグループ内のポートの数に依存して１００から３００ナノ秒かかることがある。グループ対グループメッセージ／信号は、ｄｍ経路を介して５００ナノ秒（推定）プラス信号送信時間未満で交換することが可能で、１つのＳＭＰ内のメッセージ送信ポートグループは常に同期してメッセージ／信号を他のＳＭＰ内の１つまたは２つ以上のメッセージ受信ポートグループに配信する。任意の所与の時間にアプリケーション内で同時に発生する可能性のある並列メッセージ／信号送信の数は、数千にもなるアプリケーションのＴＩＣＣＮＥＴ内の別個のｄｍ経路の数と、数万にもなるそのアプリケーションの共有メモリ環境内の別個のｓｍ経路の数によってのみ制限される。
【００３５】
したがって、ＲＥＳＴＣＬＫ［Ｄａｓ，１９］とは異なり、ＴＩＣＣ−Ｐｐｄｅは超並列ソフトウェアアプリケーションの共有メモリ環境と分散メモリ環境の両方でメッセージ配信が保証されているセル間の高速の同時の並列メッセージ／信号交換を可能にする。
【００３６】
５．自己調和と自己同期：グループ対グループ通信と計算はＴＩＣＣ−Ｐｐｄｅ内で信号を送信する経路内のエージェントが自動的に調和させ、同期させる。各グループ対グループｓｍ経路は一般ポートのグループを機能ポートのグループに接続する。ポートグループ内の２つのポートが同じセルに属することはない。ｓｍ経路は仮想メモリ、Ｍを１つだけ含んでいる。Ｍは付属している２つのエージェントを有している。エージェントの一方は全てのメッセージ送信ポートに接続され、他方のエージェントは全てのメッセージ受信ポートに接続されている（（発明を実施するための形態）のセクション７の図１９を参照）。グループ対グループ経路がポートグループによって送信されたメッセージを同じポートグループに配信する（図１７）ことも可能であって、そのような経路は自己ループ経路と呼ばれる。
【００３７】
ポートグループのポートの親セルはセルグループと呼ばれる。一般ポートグループ、Ｇの親セルは、図１９に示しているように、結合サービス要求メッセージを機能ポートグループ、ＦにＧのポートをＦのポートに接続している経路を通して送信することができる。経路のＧ内の全てのポートとＦ内の全てのポートに関連付けられている仮想メモリはＧ．ｖＭ＝Ｆ．ｖＭと呼ばれる。この仮想メモリはＧ内のポートによって送信されたサービス要求メッセージを保持している。経路内のエージェントは、Ｇ内のポートの全ての親セルがそれらのそれぞれの計算とＧ．ｖＭ内に書き込まれている結合サービス要求メッセージへの寄与とを完了した後で初めて、Ｇ．ｖＭ内のサービス要求メッセージをディスパッチする。これはディスパッチの調和である。いったんディスパッチされると、同じ経路内の他のエージェントはＧ．ｖＭ内のメッセージをＦ内の全てのポートにＦ内の連続しているポートの間の配信時間の差が２、３ナノ秒未満となるように同期して配信する。これが配信同期である。応答メッセージは、Ｆ内のポートの親セルによって、共同で同じ仮想メモリ、Ｆ．ｖＭ内に書き込まれる。経路内の同じ２つのエージェントがＦからＧへの応答メッセージのディスパッチ調和と配信同期とを再度実施する。一般にポートグループは１つまたは２つ以上のポートを含んでいると仮定し、記号Ｐを経路を指すのに使用する。
【００３８】
互いに通信するセルグループ内のセルはディスパッチ調和と配信同期とに参加しない。セルグループ内の各セルは、セルが送信されるメッセージの経路の仮想メモリへの書き込みを完了すると即座に、そのセルグループ内の他のセルと並列にグループ対グループ経路のプロトコルを単に実行するだけである。セルグループ内のセルによるプロトコルの実行は同期して発生しないが、セルによって実施される計算が互いに同期していないからである。経路内のエージェントはこの並列プロトコル実行を調和させ、結合サービス要求メッセージが受信側の機能ポートに１度だけ同期して配信されることを保証する。経路Ｐ内のエージェントは５、６個の他のタスクも実行し、Ｐに接続されているＳＭＳ（自己監視システム）のコンポーネントがメッセージディスパッチとメッセージ配信イベントをＰを介して送信された各メッセージに対応しているＳＭＳにインストールするように指示するために、信号をこれらのコンポーネントに送信する。さらに、Ｐ内のエージェントとはデータセキュリティを実施する。エージェントはポートがメッセージとポートとに対して事前に指定されたセキュリティ条件を満たす場合にだけそのメッセージをそのポートに配信する。
【００３９】
Ｐ内のエージェントによって実施される全てのアクティビティは、Ｐのプロトコルによって指定されている。そのようなアクティビティの全てはＰに接続されているセルグループのセルとは独立してエージェントによって実施される。システム実装者は、どのような条件と同期メソッドも自分たちのプログラムに指定する必要は無い。これを自己調和と自己同期と呼ぶ（（発明を実施するための形態）のセクション１と７で説明）。
【００４０】
セルグループ内の各セルは自身に割り当てられている、別個でアプリケーション内の他のセルと共有されていないＣＰＵ内で実行（ｒｕｎ）される。セルグループ内のセルがそれら全てに対して配信されたサービス要求メッセージを共同で処理する場合、それらはそれらのそれぞれの計算を互いに調和させる必要がある。セルグループは、サービス要求メッセージを保持している仮想メモリが提供するスクラッチパッドを通して、サービス要求に応答しながら、データを互いに交換することによって、この調和を実施する。実装者は、そのようなセルグループ内のセルによって使用されるメソッドにスクラッチパッドを通してデータを交換することによってそれらのそれぞれの計算を調和させる機構を組み込むべきである。
【００４１】
ＴＩＣＣ−Ｐｐｄｅ内のグループ対グループ通信は並列自己調和と自己同期フォーク／ジョイン操作を並列計算に実装する。
【００４２】
６．効果的な細粒度実行：ＴＩＣＣ−Ｐｐｄｅの構成によって効率的な高速実行が可能になり、（ｉ）通信、プロセス、およびｐｔｈｒｅａｄ（並列スレッド）管理、調和、同期、割り込み処理、データ保護、セキュリティの実施へのオペレーティングシステムの介入の排除、（ｉｉ）全ての通信におけるスケジューリングと同期のセッションの必要性の排除、（ｉｉｉ）非常に低い通信レイテンシ、（ｉｖ）並列同時メッセージ交換、（ｖ）非同期通信における逐次バッファの排除、（ｖｉ）正確に時間設定されたプログラムとプロトコルの実行、および（ｖｉｉ）最小化されたメモリ競合がスクラッチパッドを使用した仮想メモリ構成によって可能になる。通信レイテンシがナノ秒の範囲であるため、並列プログラムを超並列計算において１０から１００マイクロ秒の程度の細粒度で良好な効率（８０％から１００％）で実行（ｒｕｎ）することができる。
【００４３】
７．マルチコアチップに対する理想的な環境：ＴＩＣＣ−Ｐｐｄｅは５、６個のプログラミング抽象化を導入し、それらの多くはプログラミング技術にとっては新規である。抽象化に関連付けられているソフトウェアツールはさまざまなマルチコアチップにおいて実行（ｒｕｎ）可能な並列プログラムの構築を促進する。マルチコアチップ環境において並列プログラム開発と実行における抽象化とそれらに関連付けられているツールが演じる役割は以下の一覧に箇条書きにしている。
【００４４】
抽象化１：セル、ポート、および経路：これらの抽象化は新規ではないが、これらのＴＩＣＣ−Ｐｐｄｅにおける実現は新規である。これらはマルチコアチップ内の各ＣＰＵによって実施される計算を分離し保護し、チップ内の別個のＣＰＵによって同時に並列に実施される計算間の相互干渉を防止する。経路もメッセージを分離し保護し、チップ内のＣＰＵの別個のグループ間で同時に並列に交換される非同期メッセージの相互干渉を防止する。セルと経路とを定義し、インストールし、更新し、ＣＰＵのセルへの割り当てを管理し、割り当てられているＣＰＵ内でのセルの起動と、ＣＰＵによる仮想メモリへのアクセスを制御するためにツールが提供される。任意の並列プログラミングアプリケーションで使用される可能性のあるポートと経路とのサブクラスは、ＴＩＣＣ−Ｐｐｄｅにおいて予め定められている。実装者はＴＩＣＣ−Ｐｐｄｅにおいて予め定義されていない通常ではないポートと経路のサブクラスだけを定義すればよい。アプリケーションで使用される各セルのサブクラスは実装者によって定義されなければならない。
【００４５】
抽象化２：付属、チューン、およびエージェント：付属しているまたは相互にチューンされているハードウェア／ソフトウェアコンポーネントだけが互いにメソッドとデータとを共有し、互いに信号を交換することができる。これは、セル、ＣＰＵ、およびメッセージの独立を実施するだけでなく、計算の自己同期および自己調和とメッセージ／信号の交換を促進する。抽象化のプログラミングとしての付属およびチューンはプログラミングについては新規である。ソフトウェアエージェントの概念は新規ではないが、ＴＩＣＣ−Ｐｐｄｅのエージェントの特定の特性はＴＩＣＣ−Ｐｐｄｅに固有である。付属とチューンはセルと経路の定義からＴＩＣＣ−Ｐｐｄｅによって自動的に実施される。実装はそれらを指定する必要は無い。任意の並列プログラミングアプリケーションで使用される可能性のあるエージェントのサブクラスは、ＴＩＣＣ−Ｐｐｄｅにおいて予め定められている。実装者はＴＩＣＣ−Ｐｐｄｅにおいて予め定義されていない通常ではないエージェントのサブクラスだけを定義すればよい。
【００４６】
抽象化３：仮想メモリ：専用のハードウェアメモリをハードウェアシステムに関連付けるのは計算システムで一般的である。しかし、専用の仮想メモリをソフトウェアで使用されるハードウェアメモリのソフトウェア抽象化として使用するという概念は、新規である。この概念は、Ｇｏｐｉｎａｔｈ［２１］によってまず導入され（この用語は使用されていないが）、それ以降、本発明者によっていくつかの強化を伴ってＴＩＣＣ−Ｐｐｄｅにおける並列プログラム開発と実行に対して採用された。コンパイル時または実行（ｒｕｎ）時に実際のメモリが仮想メモリに割り当てられる。仮想メモリはマルチコアチップを使用した並列プログラミングとマルチコアチップの設計を単純化する。仮想メモリはメッセージを保持し、セル／メッセージの分離を強化する。さらに、それらはデータ保護、データセキュリティを実施し、メッセージを処理し作製し、メモリ干渉を最小化し（（発明を実施するための形態）、セクション６．２）、セルグループ内のセルに対してスクラッチパッドを提供しそれらの動作を調和させるために使用されるメソッドの実行環境を提供する。ＴＩＣＣ−Ｐｐｄｅは仮想メモリを定義し、宣言し、インストールし、更新するツールを提供する。任意の並列プログラミングアプリケーションで使用される可能性のある仮想メモリのサブクラスは、ＴＩＣＣ−Ｐｐｄｅにおいて予め定められている。実装者はＴＩＣＣ−Ｐｐｄｅにおいて予め定義されていない通常ではない仮想メモリのサブクラスだけを定義すればよい。
【００４７】
以下の特徴４と特徴７で説明しているように、仮想メモリによってＳＭＭＣ（共有メモリマルチコアチップ）におけるメモリ構成に対する新しいアプローチが可能になり、それはＳＭＭＣ設計を単純化し性能効率を改善する。ＳＭＭＣ内の各ＣＰＵは１０キロワードから１メガワードの範囲のサイズの最小の量のプライベートメモリを使用し、キャッシュメモリやその他の高速化機構を使用せずに実装されている。しかし、ＳＭＭＣは１０キロワードから１ギガワードのサイズの範囲のハードウェア共有メモリモジュール、ＳＭＭのプールを有している。ＴＩＣＣ−ＰｐｄｅはＳＭＭをアプリケーション内で定義されている各仮想メモリにコンパイル時または実行（ｒｕｎ）時に割り当てる。並列プログラム実行時に、セルを実行（ｒｕｎ）するＣＰＵはそれらのセルによって使用される仮想メモリに既に割り当てられているＳＭＭに動的に接続されている。アプリケーション内のポートは必要に応じて動的にスケジュール作製とＣＰＵとＳＭＭとの間のそのような接続の解除を行う。各ＳＭＭは約８から１６個のＣＰＵだけに同時にサービスを行うことができる。この構成は２５６個以上のＣＰＵを含んでいる大規模のＳＭＭＣ内のメモリ競合を動的に減少させ、データセキュリティと保護にも貢献する。
【００４８】
抽象化４：ＣＣＰとプロトコル：全ての他の抽象化の統合を実際に可能にする際だった抽象化はＣＣＰ（因果通信プリミティブ）である。ＣＣＰは通信プロトコルを定義するためにＴＩＣＣ−Ｐｐｄｅで使用され、実行される時に信号をこれらのプロトコルに関連付けられている経路上を進行させる。それらは、ハードウェア／ソフトウェアコンポーネントが信号を動的にそしてプログラムに従って交換できるようにし、したがって、それらを分離しながらも互いに協力できるようにする。ＣＣＰに起因する信号交換は、開始／完了信号が非同期ハードウェアコンポーネントの同期、調和、および管理をするように、非同期ソフトウェア／ハードウェアコンポーネントを同期し、調和させ、管理する。任意の並列プログラミングアプリケーションで使用される可能性のあるプロトコルは、ＴＩＣＣ−Ｐｐｄｅにおいて予め定められている。実装者はＴＩＣＣ−Ｐｐｄｅにおいて予め定義されていない通常ではないプロトコルだけを定義すればよい。
【００４９】
ＣＣＰは、ハードウェア／ソフトウェア相互動作、リソース割り当て、プロセス／スレッド管理、割り込み処理、同期、調和、およびセキュリティの実施を管理するためにオペレーティングシステムを使用する必要性を排除する。ＣＣＰ自体は機械命令であるため、ＴＩＣＣ−Ｐｐｄｅ内でＣＣＰは計算と通信との区別を排除する。計算を実行する同じセルが全ての必要な通信も実行する。メッセージ／信号を交換するためにオペレーティングシステムからのサポートは必要なく、プロセス／スレッドを管理するためにモニタは必要なく、ソフトウェア調和にセマフォ［２３、２４］は必要なく、ソフトウェア同期にランデブー技法［１０、１２］は必要ない。ＣＣＰの使用は通信を大きく加速し、ＴＩＣＣ−Ｐｐｄｅ並列処理アーキテクチャに必然的につながる。ＣＣＰを基本プログラミング言語プリミティブとして使用する概念はプログラミング技法に対して新規であって、その機械命令としての実装はＣＰＵの設計に対して新規である。
【００５０】
抽象化５：ＴＩＰ：ＴＩＰはスレッド相互動作プロトコルである。実装においてセルＣに付属している各ポートＣ．ｐはそのために定義されているＴＩＰ、Ｃ．ｐ：ＴＩＰ（）を有している。ＴＩＰは以下の機能を実行する：（ｉ）それらはアプリケーション内のポート間の相互動作の抽象的仕様によってソフトウェア開発を促進し、抽象的仕様を最終的な実装に次第に詳細化し、（ｉｉ）それらは各セルにおいて通信をメッセージ処理とメッセージ構築計算から分離し、（ｉｉｉ）異なるセルで実行される並列計算を分離し、（ｉｖ）詳細化の様々な段階において実装のためにモジュール化されているイベントベースのＡＬＬＥＯＰモデルの自動導出を可能にする、（ｖ）詳細化の様々な段階において実装されたシステムの正式な検証のためのＡＬＬＥＯＰの柔軟な使用を可能にし、（ｖｉ）ＳＭＳ（自己監視システム）構成を可能にする。ＴＩＣＣ−Ｐｐｄｅは、実装仕様においてＴＩＰを定義、インストール、および更新するツールを提供し、それらを詳細化し、ＡＬＬＥＯＰを導出し、所与の仕様から詳細化の各段階において追跡する。プログラミング抽象化として、ＴＩＰはプログラミング技法に対して新規である。全部で１０個の異なる種類のＴＩＰが存在する。ＴＩＣＣ−ＰｐｄｅのＴＩＰ定義フォーマットと実装中のアプリケーションにおけるＴＩＰの意図した機能とに整合した態様でアプリケーションの各ポートに対してＴＩＰを定義するのは実装者の責任である。
【００５１】
抽象化６：同期：
サイクル同期：アプリケーションの任意の２つの別個のポートｐとｑとに関連付けられている２つのＴＩＰ、ｐ：ＴＩＰ（）とｑ：ＴＩＰ（）とは、ｑ：ＴＩＰ（）の評価がｐ：ＴＩＰ（）の評価が完了した後に開始され、ｐ：ＴＩＰ（）の次の評価がｑ：ＴＩＰ（）の前回の評価の完了後に初めて開始される場合、サイクル同期される。ポートｐとｑは、アプリケーション内の任意の２つのセルに属していてもよく、同じセルに属していてもよい。サイクル同期は、アプリケーション内で動作の調和（順序付け）を課する。ＴＩＣＣ−Ｐｐｄｅはアプリケーション内の任意の２つのポートに関連付けられている２つのＴＩＰをサイクル同期する構成を提供する。
【００５２】
同期：ＴＩＰ、別個のセルのポートに属しているｐ：ＴＩＰ（）とｑ：ＴＩＰ（）とはそれらの評価が常に同時に始まる場合に同期している。ＴＩＣＣ−Ｐｐｄｅはアプリケーション内の任意の２つの別個のセルに関連付けられている２つのＴＩＰを同期する構成を提供する。
【００５３】
ＴＩＣＣ−Ｐｐｄｅは、ＴＩＰと経路の適切な定義によってサイクル同期と同期を設計または実装に導入するための系統的なメソッドを提供する。ＴＩＣＣ−Ｐｐｄｅはその点までの詳細化の変更を必要とせずに詳細化の任意の段階で後からの思いつきとしてこれらの同期を導入するメソッドも提供する（（発明を実施するための形態）のセクション６．６）。そのような後からの思いついた同期に使用されるメソッドをアドホック同期メソッドと呼ぶ。ＴＩＣＣ−Ｐｐｄｅで使用される全ての同期と調和のメソッドはプログラミング技術に対して新規であって、ＴＩＣＣ−Ｐｐｄｅに固有である。
【００５４】
抽象化7：ＣＩＰ：ＣＩＰはセル相互動作プロトコルである。ＣＩＰはセルの初期化手続きと共にセルのポートで定義されている全てのＴＩＰの集合である。ＣＩＰはセルがそのポートを循環的にポーリングする順番を指定する。２種類のＣＩＰが存在し、ポートでメッセージの存在を検知した時に即座にそのポートに対して定義されているＴＩＰを呼び出すＣＩＰと、ポートをセルに対してローカルな順序付け基準に従ってメッセージと共に順序付けポートリストに配置し、それからリストに現れるポートの順序でポートでＴＩＰボディを実行することによってポートに応答するＣＩＰである。セルがポートをまず並べ替える代わりにいくつかのポートに即座に応答し、それから他のポートを並べ替えることも可能である。
【００５５】
各ＣＩＰは並列処理システム内で他の全てのプロセスと並列に唯一のＣＰＵ内で実行（ｒｕｎ）される唯一のプロセスに関連付けられている。このＣＩＰプロセスをＣ：ＣＩＰ（）呼ぶことにする。Ｃ：ＣＩＰ（）はメッセージが配信されているＣのポートでＴＩＰを循環的に実行し、終了させられるかサスペンドされるまでその動作を継続する。Ｃ：ＣＩＰ（）を実行（ｒｕｎ）するＣＰＵはセルＣにＴＩＣＣ−Ｐｐｄｅによって関連付けられている。また、各セルは、その関連付けられているＣＰＵ内でＴＩＣＣ−Ｐｐｄｅによって起動される。ＣＩＰプロセスは、ＴＩＣＣ−Ｐｐｄｅ並列プログラム実行における唯一のプロセスである。それらのスケジューリング、ＣＰＵ内での起動、サスペンド、レジューム、同期、および調和は、オペレーティングシステムの使用を必要とせずに、全てＴＩＣＣ−Ｐｐｄｅによって管理される。サービス要求の受信を認識するためのポーリングと何らかの順序でのそれらへの応答の概念は新規ではない。全てのソフトウェアシステムで広く使用されている。しかし、ＣＩＰにおけるこのサービスの具体的な実現はＴＩＣＣ−Ｐｐｄｅに固有である。
【００５６】
抽象化８：ＴＩＣＣ−Ｎｅｔｗｏｒｋ：
これはグラフィックの形態で実装とセルに付属しているポート間の経路相互接続に使用されるセルを指定する。ＴＩＣＣ−Ｎｅｔｗｏｒｋはアプリケーション内で発生する並列計算動作の全ての同期と調和とを暗示的に指定し、実施する。実装者はアプリケーションで使用されるＴＩＣＣ−Ｎｅｔｗｏｒｋを指定する責任がある。これがいったん実施されると、実装者は並列コンピュータプログラムに調和、同期、またはアプリケーションの実行（ｒｕｎ）中の並列計算の任意の種類の監視のための任意の構成を組み込む全ての責任から完全に解放される。
【００５７】
ＴＩＣＣ−Ｎｅｔｗｏｒｋは並列プログラム実行の制御構造を指定し分析するための適切な種類の抽象化を提供する。データ構造抽象化が、逐次プログラムの構造がデータ構造とマッチする限り、逐次プログラムを最適化するために同じ逐次プログラムを異なるデータ構造定義で実行できるようにするように、ＴＩＣＣ−Ｎｅｔｗｏｒｋ構造は、アプリケーション内の各Ｃ：ＣＩＰ（）内の初期化ルーチンがＴＩＣＣ−Ｎｅｔｗｏｒｋの構造とマッチする限り、並列プログラム構造を実験し最適化するために、並列アプリケーションプログラムの同じ集合が異なるＴＩＣＣ−Ｎｅｔｗｏｒｋで実行（ｒｕｎ）できるようにする。
【００５８】
グラフィック表示を使用してシステムのコンポーネント間の相互動作の制御構造を捕らえることは新規ではない。しかし、ＴＩＣＣベースの並列ソフトウェアシステムにおいて解釈が独自のＴＩＣＣ−ｎｅｔｗｏｒｋの具体的な実現は新規である。
【００５９】
抽象化９：ＡＬＬＥＯＰとトレース：これら２つの抽象化が定義され使用される態様は新規であって、ＴＩＣＣ−Ｐｐｄｅに固有である。ＴＩＣＣ−Ｐｐｄｅは実装の仕様からＡＬＬＥＯＰを自動的に導出し、それらをソフトウェアシステムの確認に使用するツールを提供する。トレースの概念はそれ自体新規ではない。トレースという用語はプログラム実行の特定の実行（ｒｕｎ）において起こることの記述を指すために使用される。プログラミング分野が異なると、トレースの指定のために異なる統語構造またはグラフィックツールが使用される。ＴＩＣＣ−Ｐｐｄｅトレースはアプリケーションの特定の実行（ｒｕｎ）において発生する可能性のある全てを指定するだけでなく並列計算の意味論も定義する独自の特徴を有している。トレースはＡＬＬＥＯＰとアクションの入出力特性から自動的に導出される。アクションはｐｔｈｒｅａｄ（並列スレッド）または個別のプログラムステートメントまたは条件であってもよい。ＴＩＣＣ−Ｐｐｄｅはアクションの特徴付けを対話的に定義し、それらを使用してＡＬＬＥＯＰ（（発明を実施するための形態）のセクション２）から自動的にトレースを導出するツールを提供する。ＴＩＣＣ−Ｐｐｄｅは実装の特性を確認するためにトレースから自動的に導出されるＥＣＴ（イベント特徴付け表ネットワーク）ネットワークを使用するメソッドも提供する。
【００６０】
抽象化１０：ＳＭＳ、ｃａｕｓａｌａｎｔ、およびｅｂセル
因果律網はトレースの抽象化であって、トレースは、トレース内で発生する通信イベントの因果チェーンだけを有している。アプリケーションＡ用の因果律網は、Ａの実行（ｒｕｎ）と並行にＡの実行中（ｒｕｎ）に、ＴＩＣＣ−ＰｐｄｅのＳＭＳ（自己監視システム）によって構築される。アプリケーションＡ内で各経路Ｐ内のエージェントは信号がＰに沿って進行中に、信号を経路Ｐに接続されているイベントビルダーセル（ｅｂセル）と呼ばれるＳＭＳの特別なセルに送信する。各経路Ｐは専用のｅｂセルのサービスを受ける。所与のｅｂセルは５、６個の経路のサービスを行うことになる。Ｐのｅｂセルによって受信された信号は、ｅｂセルにＰで発生するメッセージディスパッチと配信イベントをアプリケーションの拡大している因果律網にインストールするように指示する。ｅｂセルは、Ｐによって配信されたメッセージがメッセージを受信したポートの親セルのポートによって処理されている間に、ディスパッチと配信イベントをインストールする。ｅｂセルの信号伝達は、経路上の信号送信と並列に発生し、ディスパッチと配信イベントのインスト−ルはＳＭＳイベントのタイミングとアプリケーションイベントのタイミングとの間の干渉を防止するために、メッセージ受信セルによって行われるメッセージ処理と並列に発生する。拡大している因果律網がＳＭＳ内のｅｂセルによって構築されている間に、並列に実行（ｒｕｎ）される４つの動作が存在し、（ｉ）アプリケーション内で実行（ｒｕｎ）される全てのセルの動作、（ｉｉ）ＳＭＳ内のｅｂセルに信号送信する経路内のエージェントの動作、（ｉｉｉ）新しいメッセージディスパッチと配信イベントを使用して拡大している因果律網を更新している間のｅｂセルの動作、および（ｉｖ）拡大している因果律網を分析するＳＭＳのｅｂセルの動作（以下の抽象化１１を参照）である。
【００６１】
各ｅｂセルはｅｂセルを実行（ｒｕｎ）しているＣＰＵのローカル時間を使用して所与のメッセージのディスパッチと配信イベントがアプリケーション内でいつ発生したのかを求める。ｅｂセルを実行している全てのＣＰＵのローカル時間は標準化されているグローバルクロックに同期しているので、ｅｂセルによって因果律網内でイベントインスタンスに関連付けられている全てのタイミングは同じグローバルクロックに同期することになる。アプリケーション内で他のセルを実行（ｒｕｎ）しているＣＰＵはグローバルクロックにも互いに対しても同期していない異なるローカルクロックを使用することがある。
【００６２】
アプリケーションの実装の仕様がそのアプリケーションに必要なＳＭＳ構造を自動的に定義する。アプリケーションに対してそのように定義されたＳＭＳ構造は、そのアプリケーションの各実行（ｒｕｎ）を動的に監視するためにＴＩＣＣ−Ｐｐｄｅによって自動的に呼び出され使用される。アプリケーションの実装者はこれを促進するためのどのようなプログラムも書く必要がない。ＴＩＣＣＮＥＴによって相互接続されている分散メモリ計算グリッド内の各ＳＭＭＣ（共有メモリマルチコアチップ）、Ｘはそれ自体の独自のローカルＳＭＳ、Ｘ：ＳＭＳ（）を有することになる。Ｘ：ＳＭＳ（）によって構築された因果律網はＸのローカル共有メモリに存在することになる。ＴＩＣＣ−Ｐｐｄｅは因果律網を分散メモリ計算グリッドの異なるＳＭＭＣに統合し、必要に応じてＴＩＣＣ−ＧＵＩ（グラフィカルユーザインターフェイス）を使用してアプリケーション内の所与のセルまたはポートを中心にしてその任意の部分を表示することができる。
【００６３】
抽象化１１：ＳＭＳとｅａセル：ＳＭＳは、アプリケーションの各実行（ｒｕｎ）中に生成される、拡張する因果律網を常に監視するイベント分析セル（ｅａセル）と呼ばれる特別なセルを使用する。目的は、条件１のように拡張する因果律網内のエラーと未解決のエラーとを識別し報告することである。ｅａセルは、因果律網内で事前に定義されたイベントパターンの発生を識別し、アラートを発生するために、因果律網を監視してもよい。ｅｂセルはｅａセルによって実施される因果律網分析を使用して自身の因果律網更新を調和させるために、ＣＣＰを使用して信号を交換することによってｅａセルと通信する。ＳＭＳはＴＩＣＣ−Ｐｐｄｅ並列プログラム実行機構の一部である。
【００６４】
まとめ：ＴＩＣＣ−Ｐｐｄｅ並列プログラムの開発、確認、実行、および自己監視において使用される前述のプログラミング抽象化とメソッドの全てはＴＩＣＣ−Ｐｐｄｅに固有である。抽象化とメソッドとは１つとなって、並列プログラム内の抽象化のインスタンスをインストールし管理するためのツールを提供し、ＴＩＣＣＮＥＴに統合されているさまざまなマルチコアチップ内で実行可能な形式的継承された並列ソフトウェアシステムを構築する。この企画に対して重大なＴＩＣＣ−Ｐｐｄｅの特徴を以下に箇条書きにする。
【００６５】
８．ＴＩＣＣ−Ｐｐｄｅの重要な特徴：
特徴１：統合環境：ＴＩＣＣ−Ｐｐｄｅは、セルへのＣＰＵ割り当て、割り当てられたＣＰＵ内でのセルの起動、並列プロセス管理、ｐｔｈｒｅａｄ（並列スレッド）管理、通信、割り込み管理、セキュリティの実施、同期と調和を、これらのサービスのどのような部分の実行にもオペレーティングシステムや他のソフトウェアを呼び出すことを必要とせずに、実施する。現在のプロトタイプ実装において、ＴＩＣＣ−Ｐｐｄｅはオペレーティングシステムをメモリ管理、キャッシュ管理、２次ストレージへのアクセス、入出力、インターネットアクセスにだけ使用する。特徴４において示しているように、ＣＰＵ設計で一般に使用されるキャッシュメモリと全ての他の種類の高速化技法はＴＩＣＣ−Ｐｐｄｅプログラムの実行（ｒｕｎ）に使用されるＳＭＭＣ（共有メモリマルチコアチップ）内では無しに済まされている。オペレーティングシステムによってＴＩＣＣ−Ｐｐｄｅに現在提供されている全てのサービスは、ＴＩＣＣ−Ｐｐｄｅ自体内に組み込むことができる。したがって、ＴＩＣＣ−ＰｐｄｅはＳＭＭＣ内または５〜６個のＳＭＭＣからなる計算グリッド内での並列プログラムの開発、確認、実行（ｒｕｎ）、および監視に理想的に適している統合並列プログラム開発、確認、実行、およびランタイム監視環境を提供する。
【００６６】
特徴２：ＴＩＣＣ−ＧＵＩ：これは、所与のセルに固定されているＴＩＣＣ−Ｎｅｔｗｏｒｋのセグメントと、所与のポートに固定されているＡＬＬＥＯＰのセグメントと、所与のポートとセルに固定されている因果律網のセグメントとのグラフィカル表現を表示する。ＴＩＣＣ−Ｎｅｔｗｏｒｋ表示の例だけを（発明を実施するための形態）のセクションに示している。ＴＩＣＣ−ＧＵＩは、ＧＵＩが受信したサービス要求に対してセル状態のポーリングを行う時点で実行（ｒｕｎ）されながら、アプリケーションの任意のセルの状態を調べる構成を提供する。表示要求が行われた時刻に正確に一致する時点でセルの状態を表示することは現実的には不可能である。しかし、ブレークポイントを設定し、特定のイベントが発生した時に状態を表示させることができる。しかし、そのようなブレークポイントをアプリケーションＡに導入することはＡ内で発生するイベントのタイミングを変えることになる。したがって、ブレークポイントは試験モードでのみ使用可能である。ＧＵＩはシステム実装を文書化することと、動的システム監視の両方に対して有用である。ＴＩＣＣ−ＧＵＩはＴＩＣＣ−Ｐｐｄｅの必要不可欠の部分である。
【００６７】
特徴３：任意のスケーラビリティ：スケーリングに起因する相互作用オーバーヘッドがプログラム実行時間と比較して短い限り、ＴＩＣＣ−Ｐｐｄｅ内の並列プログラムは任意にスケーラブルである。ＴＩＣＣ−Ｐｐｄｅ並列プログラムに固有なことは、相互作用オーバーヘッドがＴＩＣＣ−ｎｅｔｗｏｒｋの構造に相対的に正確に定義可能なことである。Ｎをセルと経路のＴＩＣＣ−Ｎｅｔｗｏｒｋとし、ｎｍａｘ（Ｎ、Ｃ）をＮにおいてそのポーリングサイクルの１つでのセルＣによって交換されるメッセージ最大数とする。ｎｍａｘ（Ｎ）をＮ：ｎｍａｘ（Ｎ）＝Ｍａｘｉｍｕｍ｛ｎｍａｘ（Ｎ，Ｃ）｜Ｃ∈Ｎ｝内のＣについての全てのｎｍａｘ（Ｎ，Ｃ）の最大数とする。ｖ（Ｎ）をネットワークＮ内のセルの数とし、Ｎ’をｖ（Ｎ’）セルを備えているＮのスケールアップ版とする。すると、任意のスケーラビリティに対する要件は：ｎｍａｘ（Ｎ’）がスケーリングファクタα＝[ｖ（Ｎ’）／ｖ（Ｎ）]に無関係なことである。この条件が満たされると、αの値は数百万になり得る。これは、本質的に、スケーリングファクタが増加してもセルあたりの通信と調和のオーバーヘッドが増加しないということである。
【００６８】
特徴４：キャッシュメモリと高速化技法の排除：キャッシュメモリはＴＩＣＣ−Ｐｐｄｅ並列プログラムの実行（ｒｕｎ）に対して無しに済ませることができる。我々のプロトタイプ実装において、キャッシュメモリはやっかいなものに過ぎない。粒度の小さい実行によって、キャッシュ補充において無駄になる時間が長すぎ、キャッシュが一貫していないことが問題になることが多い。キャッシュの非一貫性を避けるためにはメインメモリ内のデータを更新しなければならなかった。キャッシュメモリはＴＩＣＣ−Ｐｐｄｅにおける高スループットプログラム実行には必要ない。高スループットはセル内の細粒度並列プログラム実行の任意のスケーリングによって実現することができる。実際に、複数の命令ストリーム実行［２９］、先読みスケジューリング［３０］、パイプライン処理［３１］、およびキャッシュ化実行［３２］などの通常の高速化技法はＴＩＣＣ−Ｐｐｄｅの高効率と高スループットに対しては必要ない。ＴＩＣＣ−Ｐｐｄｅにおいて、各ＣＰＵは、１つのセルだけのサービスをそのセルに関連付けられている仮想メモリだけを使用してもっぱら行う。各セルは、１つのＴＩＰだけを任意の所与の時間に実行してもよく、ＴＩＰの実行は割り込み不能である（（発明を実施するための形態）、セクション５）。通信と計算の両方を含むＴＩＰの実行にかかる時間はほんの１０〜１００マイクロ秒である。同期、調和、および監視のオーバーヘッドは存在しない。したがって、ＴＩＣＣ−Ｐｐｄｅにおいて前述の高速化技法のいずれかを採用するのが有利な自然な文脈は存在しない。これには２つの利点があって、（ｉ）ＳＭＭＣ（共有メモリマルチコアチップ）におけるＣＰＵ設計を簡略化し、チップ内のＣＰＵ密度を増加させることと（ｉｉ）厳密な境界によってイベントタイミング予測を可能にすることである。
【００６９】
特徴５：自己監視を備えている確認されたサイバー物理実時間システムの開発にとって理想的な環境：所与の境界内での正確なタイミングでのソフトウェア実行はサイバー物理実時間システムの構築にとって必要であって重要な要件である。ＴＩＣＣ−Ｐｐｄｅはソフトウェアシステムの正式な確認、ＳＭＳを使用した自動自己監視、正確に定義された境界のあるイベントタイミングの予測を促進する。ＴＩＣＣ−Ｐｐｄｅが、航空機や宇宙船システムのオートパイロット、自動化マルチセンサ用途、軍事乗り物における自動化された防衛／攻撃の調和、自動化された工場、ロボット、または任意の他のそのような時間が重要な反応システムなどのサイバー物理実時間システムを開発し、確認し、展開するための理想的な環境を提供することがこれまでに明かである。医療情報システム、知能情報システム、任意のデータベースシステムなどの安全な情報システムの構築に使用することもできる。ＴＩＣＣ−Ｐｐｄｅ用の重要な最も広く使用されているアプリケーションは不正な侵入と攻撃とに対するプライバシーと保護とを保証するＳＭＭＣを備えているパーソナルコンピュータシステムの可能性がある。
【００７０】
特徴６：動的柔軟性とモビリティ：ＴＩＣＣ−Ｐｐｄｅ並列プログラムは、経路接続を動的に変更し、新しいセルと経路とを動的に導入することによって、動的に修正し、更新することができる。古いバージョンの通常の動作の変更がほとんどまたは全く無しに、並列のセルの新規のバージョンをそのままで試験することについては米国特許第７，２１０，１４５ Ｂ２号を参照。分散環境でのプログラムのモビリティは、１つのプロセッサの仮想メモリの内容全体を分散システムの他のプロセッサの他の仮想メモリに転送することによって達成される。
【００７１】
特徴７：必要なＣＰＵの特徴：
本発明においては、各ＣＰＵはそのローカルクロックがセルに付属している有限な一定数（高々１０または１５）のポートによって同時に並列にポーリングされることを可能にするのに必要な特別なハードウェア構成を有することを仮定している。ポートが親セルを実行（ｒｕｎ）しているＣＰＵのクロックがメッセージがそのポートに配信される時にメッセージ配信時刻を登録するためにＣＣＰ信号を送信することによってポーリングされるようにしてもよい。この構成は、以下のようにハードウェア内に実装されてもよく、セルＣを実行（ｒｕｎ）するＣＰＵはその現在の時刻をセルのポートＣ．ｐの仮想メモリ、Ｃ．ｐ．ｖＭにインストールされている特別に指定されている時刻レジスタ、ＲＴ（Ｃ．ｐ）（「Ｔ」は「Ｔｉｍｅ」を表す）の集合に常にブロードキャストする。各ポートＣ．ｐは配信時刻レジスタＲＤ（Ｃ．ｐ）と呼ばれ関連付けられている追加の時刻レジスタを有していてもよい。信号がポートＣ．ｐに配信されるたびに、ＲＴ（Ｃｐ）内の現在の時刻はＲＤ（Ｃ．ｐ）へ自動的にゲーティングされる。したがって、ＲＤ（Ｃ．ｐ）の時刻はＣ．ｐでの信号配信時刻をマーキングすることになる。この構成は、ＴＩＣＣ−Ｐｐｄｅで使用される全てのＣＰＵに組み込まれなければならない。このタスクのどのような部分を実行するためにもオペレーティングシステムを使用する必要は無い。
【００７２】
ポートＣ．ｐについて、メソッドＣ．ｐ：ｔｉｍｅＳｔａｍｐ（）はＣ．ｐのこのクロック読み取り機構を呼び出すために使用される。メソッドＣ．ｐ：ｔｉｍｅＳｔａｍｐ（）は、クロック時刻が読み取られるＣＰＵによって実行されるのではなく、メッセージをＣ．ｐに配信するセルを実行するＣＰＵによって実行される。したがって前述の構成が必要になる。この方法は、配信信号が任意のアプリケーションのポートＣ．ｐ（（発明を実施するための形態）のセクション７）に送信されるたびに呼び出される。アプリケーション内の全てのクロックが同期していなければならないという要件は存在しない。ｅｂセルのクロックだけがすべて共通のグローバルクロックに同期していなければならない。各セルでクロックの並列な同時の読み取りの必要があるが、それはメッセージをセルのポートに同時に、並列に配信できるからである。
【００７３】
ＣＰＵに対して２〜３の他の要件がある。ＳＭＭＣ（共有メモリマルチコアチップ）内のＣＰＵはキャッシュメモリ無しに、しかし１０キロワードから１メガワードの大きさの限定された量のプライベートメモリを使用して構成されていなければならない。各ＳＭＭＣはハードウェア共有メモリモジュールの集合をそのようなモジュールのプール内に有していなければならない。それらをＳＭＭ（共有メモリモジュール）と呼ぶ。各ＳＭＭのサイズは１０キロワードから１ギガワードの範囲であってもよい。各ＳＭＭは、セルグループのあり得る最大サイズである、高々わずか１６個のＣＰＵに同時にサービスを行うための容量を有していなければならない。ＳＭＭはコンパイル時または実行（ｒｕｎ）時にＴＩＣＣ−Ｐｐｄｅによってアプリケーション内の仮想メモリに割り当てられており、ＴＩＣＣ−Ｐｐｄｅは所与の実装仕様からさまざまな仮想メモリに割り当てられるＳＭＭのサイズを決定する。セルを実行（ｒｕｎ）する各ＣＰＵはセルが割り当てられているＳＭＭに、そのセルによって使用される仮想メモリにそれらの仮想メモリへのアクセスが許可された時に、動的に接続されてもよい。ＣＰＵをＳＭＭメモリバスに動的に接続するためにＣＰＵ設計においてプログラマブルロジックネットワークを使用してもよい。
【００７４】
このスキームが、ＳＭＭＣをデータセキュリティとメモリ競合の問題が伴う大きな数ギガワードのサイズの共有メモリに統合する必要性を排除する。本明細書で提案するスキームは実行（ｒｕｎ）時のメモリ競合を大幅に減少させる。また、１つの巨大な共有メモリが無いことと、共有の能力が非常に限定されている仮想メモリの使用によって、セキュリティ、プライバシー、およびデータ保護が強化されるが、それは（ｉ）各エージェントは仮想メモリ内のメッセージをポートにポートがメッセージとポートに対して指定された事前に指定されたセキュリティ条件を満たす場合にだけ配信する、（ｉｉ）ＴＩＣＣ−Ｐｐｄｅの各ポートはその仮想メモリ内のメッセージを保護し、その仮想メモリへのアクセスを親セルにだけ、そして親セルがメッセージの送信の準備ができた時または安全に配信されたメッセージ／信号に応答する準備ができた時にだけ許可する。さらに、ＴＩＣＣ−Ｐｐｄｅは集中スケジューリング機構と、プロセスとメソッドの集中起動ディレクトリ（動的リンクライブラリ）とを有していない。これらの特徴は併せてデータ盗難とシステム侵入に対する手強い障壁となる。
【図面の簡単な説明】
【００７５】
【図１】ＴＩＰ、プロトコル、およびＣＣＰ特徴付けを示している簡単な経路、（Ｃ．ｇ⇔Ｄ．ｇ）の図であって、セクションＩＶ、１．２．の詳細図である。
【図２】仮想メモリ、Ｍ、エージェント、ａ０とａ１、ＴＩＰ、プロトコル、およびＣＣＰ特徴付けを備えている点対点経路（Ｃ．ｇ⇔Ｄ．ｇ）の図であって、セクションＩＶ、１．２．１．の詳細図である。
【図３】エージェントａ０、ＴＩＰ、およびプロトコルを備えている簡単な点対グループ経路（Ｃ．ｇ⇔［Ｄ１．ｆ，Ｄ２．ｆ］）の図であって、エージェントは同期したサービス要求信号をＣ．ｇからポートグループ［Ｄ１．ｆ，Ｄ２．ｆ］の両方のポートに配信し、１つの調和した結合応答信号をＣ．ｇからＤ１．ｆとＤ２．ｆに返信する、セクションＩＶ、１．２．２．の詳細図である。
【図４】エージェントａ０とａ１、ＴＩＰ、およびプロトコルを備えている点対グループ経路（Ｃ．ｇ⇔［Ｄ１．ｆ，Ｄ２．ｆ］）の図であって、エージェントａ０はサービス要求信号をＣ．ｇから受信し、それをエージェントａ１に送信し、エージェントａ１は同時にそれをポートグループ［Ｄ１．ｆ，Ｄ２．ｆ］の両方のポートに配信し、［Ｄ１．ｆ，Ｄ２．ｆ］の両方のポートが応答信号返信する時に、エージェンａ１は両方の信号の受信を待ち、１つの調和した結合応答信号をＣ．ｇにａ０を通して返送する図であって、セクションＩＶ、１．２．２．の詳細図。
【図５】Ｂｉｌｌ／Ｂｅｎ問題の解法のためのセルと経路のＴＩＣＣ−Ｎｅｔｗｏｒｋの図であって、セクションＩＶ、２．１．５．の詳細図である。
【図６】Ｂｉｌｌ／Ｂｅｎ解法ＡＬＬＥＯＰとトレースのグラフィック表現であって、ＩＶ、２．１．５．の詳細図である。
【図７】話す／痒がる問題の解法のＴＩＣＣネットワークの図であって、セクションＩＶ、２．２．の詳細図である。
【図８】非独立ポートの新規のセルへの移動の図であって、セクションＩＶ、４．５．の詳細図である。
【図９】従来とＴＩＣＣのアーキテクチャの対比の図であって、セクションＩＶ、４．６．の詳細図である。
【図１０】ＯＧ解法用のＴＩＣＣネットワークの図であって、セクションＩＶ、６．１．の詳細図である。
【図１１】仮想メモリの構造の図であって、セクションＩＶ、６．２．の図である。
【図１２】ＰＣ解法用のＴＩＣＣネットワークの図であって、セクションＩＶ、６．３．の図である。
【図１３】ＤＰ解法用のＴＩＣＣネットワークの図であって、セクションＩＶ、６．４．の図である。
【図１４】構成の分岐する木の図であって、セクションＩＶ、６．４．の図である。
【図１５】連続しているポーリングサイクルにおける執事の状態の図であって、セクションＩＶ.６．４．の図である。
【図１６】アドホック調和の図であって、セクションＩＶ、６．６．の図である。
【図１７】自己ループ経路を使用しているアドホック同期の図であって、ポートＣｉ．ｆ、０≦ｉ＜ｎの全ての親セルはそれぞれのポートＣｉ．ｆで受信したメッセージの処理を同時に同期して開始し、各々が同期して配信された信号をＣｉ．ｇを通して受信する、セクションＩＶ、６．６．の図である。
【図１８】非有限状態ＡＬＬＥＯＰを備えている拡大しているＴＩＣＣネットワークの図であって、セクションＩＶ、６．７．の図である。
【図１９】ＳＭＳ用インフラストラクチャを備えているグループ対グループＴＩＣＣ経路の図であって、セクションＩＶ、７．を説明する図である。
【図２０】図１９の経路を通したグループ対グループ通信にＳＭＳによってインストールされた因果ネットの部分の図であって、セクションＩＶ、７．を説明する図である。
【図２１】図１９の経路を通したグループ対グループ通信にＳＭＳによってインストールされた因果ネットの部分の図であって、セクションＩＶ、７．を説明する図である。
【図２２】図２０と２１に示している部分の組み合わせから生じる因果律網であって、セクションＩＶ、７．の図である。
【図２３】一方通行の環状道路の構造の図であって、図を簡単にするためにＳＭＳ用の経路増加は不図示、セクションＩＶ、７．１．を説明する図。
【図２４】（特許請求の範囲）のメソッド（２．４）で説明するｄｍ経路Ｄｉの模式図、各ＳＭＰ（共有メモリマルチプロセッサ）は自身のＳＭＳ（自己監視システム）を有する模式図である。セクションＩＶ：
【発明を実施するための形態】
【００７６】
特許の名称：マルチコアチップ用の形式的検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ Ｖ． Ｓｒｉｎｉｖａｓａｎ、顧客番号：００００３３６４１
米国国コードおよび優先出願の番号：ＵＳ ６１／１９５，９６５
優先日：２００８年１０月１４日
発明者の住所：２０３１ ＳＥ Ｋｉｌｍａｌｌｉｅ Ｃｏｕｒｔ、Ｐｏｒｔ Ｓａｉｎｔ Ｌｕｃｉｅ、ＦＬ ３４９５２ 電話： ７７２ ３３７ １３８８ Ｆａｘ： ７７２ ３３７ １３８８、携帯電話： ７７２ ２８５ ６４６３ Ｅｍａｉｌ：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
【００７７】
１．因果通信プリミティブ（ＣＣＰ）とＲＥＳＴＣＬＫ経路の適用
利便と連続性のために、このセクションにおいて、米国特許第ＵＳ ７，２１０，１４５ Ｂ２号において、発明者Ｃｈｉｔｏｏｒ Ｖ． Ｓｒｉｎｉｖａｓａｎによって導入されたいくつかの概念と機構とを別の視点で説明する。また、このセクションにおいて、簡単なＴＩＰ（スレッド相互動作プロトコル）、ＣＩＰ（セル相互動作プロトコル）の構造、および簡単な通信プロトコルを説明する。
【００７８】
ハードウェアシステムにおいて、ハードウェアコンポーネントの動作を制御し、同期し、調和させるために信号を使用するのは常習である。同期ハードウェアにおいてはクロック信号が使用され、非同期ハードウェアにおいては開始と完了信号とが使用される。米国特許第ＵＳ ７，２１０，１４５ Ｂ２号で説明しているように、Ｇｏｐｉｎａｔｈ［２１］がソフトウェア／ハードウェアコンポーネント間でプログラムに従って信号を交換することを最初に提案し、［Ｄａｓ，１９］が信号が進行可能な共有メモリＲＥＳＴＣＬＫ経路の構造を最初に定義した。ＧｏｐｉｎａｔｈとＤａｓは信号を送信し、受信し、処理するために短いスレッドを使用し、オペレーティングシステム（ＯＳ）によって管理されるタイムスライスされた並行性を備えている彼らのシステムを実装した。スレッドによって定義されている信号交換機構は共有メモリ環境でのメッセージ交換の実装に使用された。分散ネットワーク上の通信は、たとえばＥＴＨＥＲＮＥＴ（登録商標）［Ｓｐｕｒｇｅｏｎ、２２］などのネットワーク機構を使用して実施された。
【００７９】
タイムスライスされた並行スレッドスケジューリングと起動によって非決定性が信号交換に導入された。メッセージは、境界のあるレイテンシ内で配信することができず、メッセージが失われることもあった。ＴＩＣＣは、ＯＯ（オブジェクト指向）プログラミング言語の文脈で共有メモリおよび分散メモリシステムの並列プログラミングへの応用に対して、数十から数百ナノ秒の範囲の境界のあるレイテンシで保証された並列メッセージ配信を実現するために、ＧｏｐｉｎａｔｈとＤａｓとによって導入された枠組みを適用し修正している。
【００８０】
ソフトウェア／ハードウェアコンポーネント間の保証された、プログラミングに従った信号の高速な交換によって、ソフトウェアはコンポーネント分離を維持しながら、ハードウェアシステム内でその実行を直接制御することが可能である。ＴＩＣＣにおいて、共有メモリ環境と分散メモリ環境の両方で、全ての通信、プロセス、およびｐｔｈｒｅａｄ（並列スレッド）スケジューリングと起動、割り込み処理、データ保護、セキュリティの実施、同期、調和、および自己監視に対して現在これを行っている。プロトタイプＴＩＣＣ−Ｐｐｄｅはオペレーティングシステムをメモリ管理、ページング、キャッシング、および入力／出力にだけ使用している。全てのオペレーティングシステムサービスをＴＩＣＣ−Ｐｐｄｅ自体に実装することが最終的に可能でなければならない。
【００８１】
１．１． ＣＣＰとプログラミングに従った信号交換
ハードウェア／ソフトウェアコンポーネント間の信号交換は、ＴＩＣＣにおいて因果通信プリミティブ、ＣＣＰと呼ばれる新規のプログラミングプリミティブを使用することによってプログラムに従って指定されている。各ＣＣＰはＸ：ｘ→Ｙの形態を有しており、ｘは開始または完了信号、ＸとＹはソフトウェアまたはハードウェアコンポーネントである。信号の各タイプは、それに対して定義されているサブタイプを有していてもよい。ＣＣＰは割り当てのようであって、信号をコンポーネントに割り当てる。しかし割り当てとは異なり、信号割り当ての効果は、一定の遅延後に初めて明白になる。ＴＩＣＣにおいて、所望の効果は究極的にはメッセージ配信またはメッセージディスパッチであり、ＣＣＰの名前の由来である。
【００８２】
ＣＣＰを使用した信号交換の指定には５、６個の利点があり、（ｉ）割り当てのように、ＣＣＰは他のプログラミングステートメント内に自由に埋め込み可能で、したがって、計算の中にプログラムに従った信号交換が可能になり、（ｉｉ）ＣＣＰはハードウェア機械命令としてＣＰＵ内に実装されていてもよく、（ｉｉｉ）プログラム実行を柔軟に実行し、（ｉｖ）通信と計算との間の区別を排除し、（ｖ）同じプロトコル起動形態を共有メモリ通信と分散メモリ通信の両方で使用し、（ｖｉ）ＴＩＣＣ信号交換機構はＲＥＳＴＣＬＫ［Ｄａｓ、１９］信号交換機構とは異なるが、最小限の変更だけでＲＥＳＴＣＬＫ経路構造を維持することを可能にする。
【００８３】
各ＣＣＰは２状態または４状態ｎｄＦＳＭ（非決定的有限状態機械）によって実装される。ＦＳＭは状態遷移がＦＳＭの各状態における全ての入力に対して定義されていないという意味でだけ非決定的である。１００メガビット／秒メモリバスを備えている２ギガヘルツＣＰＵ（ハードウェア計算ユニット）内でソフトウェアに実装されているＣＣＰを実行するのに２５〜５０ナノ秒かかる。２ギガヘルツＣＰＵ内で機械命令としてハードウェアに実装された場合、わずか５ナノ秒（予測）しかかからない。
【００８４】
ポイント対ポイントメッセージ転送にはＣＣＰによって制御されている４つの２状態ｎｄＦＳＭだけが必要で、各グループ内のセルの数に依存して（セクション７）、共有メモリ環境においてセルの１つのグループからセルの他のグループにメッセージを転送するには８個以上の２状態ＦＳＭが必要で、ＴＩＣＣＮＥＴを使用している分散メモリ環境における同様なメッセージ転送のために１０個以上の２状態および４状態ｎｄＦＳＭが必要である。ＳＭＳ機構をメッセージ転送に組み込むには、もう２つの２状態ｎｄＦＳＭ（セクション７）が必要である。したがって、ＣＣＰがハードウェア命令として実装されている場合、前述のように、ポイント対ポイントおよびグループ対グループメッセージ転送には数十から数百ナノ秒しかかからない。
【００８５】
各セルは割り当てられているＣＰＵ内で自身の通信プロトコルの全てを実行する。通信はｎｄＦＳＭによって実施されるチューリング計算［Ｔｕｒｉｎｇ、２０］に簡略化され、セルによって実施される計算の不可欠な部分となる。各セルは準備ができ次第、そのポートに接続されているハードウェア／ソフトウェア経路を介してそのメッセージを即座に送信する。同期またはスケジューリングの遅延は存在しない。複数のプロトコルを相互干渉無しに並列に動作しているセルによって実行可能である。しかし、各セルは常にプロトコルを１つだけ実行してもよい。これによって、同時のメッセージ転送が可能になる。全ての通信は非同期であって、逐次バッファを使用しない。
【００８６】
読者が（発明の概要）に概説されている利点がどのようにこれから直接得られるのかがわかる前に、これらがどのようにして可能になるのかと、各セルによって実行される計算と通信とをどのように調和させるのかを説明しなければならない。
【００８７】
１．１．経路プロトコル、ＴＩＰ、メッセージ送信、および計算
セルはそれらのポートを使用してポートを相互接続する経路を介してメッセージを互いに交換する。各ポートはポートの親セルと呼ばれる唯一のセルだけに付属させることが可能で（ポートの競合を防止）、各ポートは１つの経路にだけ接続することができる（メッセージ干渉の防止）。３種類のポートが存在し、セルがサービス要求を他のセル（）に送信する一般ポート、ｇ（これらはπ算法エージェント［Ｍｉｌｎｅｒ、７、８、９］）の出力ポートに似ている）、他のセルからサービス要求を受信する機能ポート、ｆ（これらはπ算法の入力ポートに似ている）、および他のセルから割り込みメッセージを受信する割り込みポート、ｉ（これらに対してはπ算法の類似物はない）。一般ポートと機能ポートは抽象的クラスポートのサブクラスである。割り込みポートは機構ポートのサブクラスである。各Ｃｅｌｌサブクラスは各種類のポートを少なくとも１つ有していなければならない。
各ポートは信号を接続されている経路上で送信するための通信プロトコルを保持している。このプロトコルはＸ：ｘ→Ｙ：ｙ→ｚの形態を有しているＣＣＰの連結を使用して定義され、Ｘ、Ｙ、およびＺは経路のコンポーネントであって、ｘとｙは信号である。ＣＣＰは他のプログラミング言語のステートメントに埋め込まれる可能性のあるプロトコルに現れてもよい。プロトコルは経路が変更されると動的に更新される。各経路は、ＣＣＰを実行する相互動作するｎｄＦＳＭの集合によって定義される。ポートの親セルのだけがそのポートに関連付けられているプロトコルを実行できる。
【００８８】
経路とＣＳＰチャネル：
共有メモリ環境における経路には、ＣＳＰ［Ｈｏａｒｅ、１０〜１２］チャネルのようにソフトウェアコンポーネントだけが含まれている。しかし、ＣＳＰチャネルとは異なり、ＴＩＣＣ−ＰｐｄｅのｐｔｈｒｅａｄはＣＳＰの通信逐次プロセスに対応する。経路は、（ｉ）同期メッセージ配信を行うグループ対グループ非同期通信を可能にし、（ｉｉ）ＴＩＣＣ−Ｐｐｄｅ内の相互動作しているｐｔｈｒｅａｄ間のデータ交換機構はｐｔｈｒｅａｄ内にコード化されておらず、（ｉｉｉ）経路は信号のみを送信し、（ｉｖ）メッセージが送信されると、経路は仮想メモリを含み、仮想メモリはメッセージを構築し処理するためにメッセージとｐｔｈｒｅａｄを保持する。コンパイル時または実行（ｒｕｎ）時に実際のメモリが仮想メモリに割り当てられる
【００８９】
経路上を進行する信号は、その仮想メモリ内のメッセージが、共有メモリ経路（ｓｍ経路）の場合には意図した受信者に配信され、分散メモリ経路（ｄｍ経路）の場合には意図した受信者に属する他の仮想メモリに送信される文脈を最終的に確立し、各ｓｍ経路に対して、メッセージを保持している仮想メモリは、１つ存在する場合、その経路にとって唯一でプライベートである。同様に、各ｄｍ経路について、その経路内の全ての仮想メモリその経路に対してプライベートである。経路は他の経路の仮想メモリを使用しない。ＣＳＰチャネルとは異なり、経路は送信者と受信者を妨げない。
【００９０】
仮想メモリを備えているｓｍ経路をＤａｓ経路と呼び、それはそれらがＳｏｕｒｉｐｒｉｙａ Ｄａｓ［Ｄａｓ、１９］によって初めて導入されたからである。ｓｍ経路とｄｍ経路の両方を指すために経路という用語を使用する。
【００９１】
１．２単純なｓｍ経路
いくつかの単純なｓｍ経路をまず考える。ポートの親セルは信号をそのポートに接続されている経路を通して送信するためにそのポートでプロトコルを実行する。プロトコルを実行する時に、親セルはローカルメモリと経路コンポーネントに割り当てられているメモリだけを使用する。プロトコルの実行によって、プロトコルの外側で定義されているどのようなメソッド、ｐｔｈｒｅａｄ、またはプロトコルも呼び出すことはない。オペレーティングシステム（ＯＳ）はメッセージ交換には使用されない。
【００９２】
0005704459.tif 000002
【００９３】
図１：単純なポイント対ポイント経路
図１に示している簡単な経路を考える。ここで、ソフトウェアブランチはセルＣの一般ポート、Ｃ．ｇをセルＤの機能ポート、Ｄ．ｆに接続する。図１において、サービスを要求している信号はまずＣ．ｇからＤ．ｆへのブランチを通して進行し、それから要求されたサービスの完了を示している応答信号はＤ．ｆからＣ．ｇに戻る。セルは信号をポートを通して送信する時、または信号を受信しポートで受信した信号に応答する時にだけそのポート（ソフトウェアコンポーネント）を使用する。図１に示しているように経路の２つの端部を接続している２つのセルはその経路に接続されているポートを同時に決して使用せず、経路上を進行する信号は１度に１方向だけである。これらはＴＩＣＣ内の全ての経路に当てはまる。
【００９４】
図１の各ポートは２状態非決定的有限状態機械（ｎｄＦＳＭ）を含んでおり、図に示しているように状態Ｓ（送信）とＲ（受信）を有している。全ての一般ポート、ｇは初期状態Ｓから始まり、全ての機能ポート、ｆは初期状態Ｒ（図１の２重円）から始まる。図１の経路は[Ｃ．ｇ，Ｄ．ｆ]である。この経路の初期状態は［Ｓ，Ｒ］である。この初期状態において、経路は信号をポートＣ．ｇからポートＤ．ｆへ送信する準備ができている。ここで図１に示している仕様について説明する。以下ではｇをＣ．ｇを指すために使用し、ｆをＤ．ｆを指す時に使用する。
【００９５】
図１のＣＣＰ特徴付けはＨｏａｒｅ［Ｈｏａｒｅ、１５］の事前条件／事後条件の表記で示されている。ＣＣＰの事前条件は、信号送信および信号受信ｎｄＦＳＭの状態に依存してもよい。図１の特徴の相互動作を以下でトップダウンの順番で説明する。
【００９６】
（１から４）ｑからｆへの信号送信：（１）：ポートは状態Ｓの時に、信号ｃ（完了信号）をその入力信号として親セルから受信する。（２）：状態Ｓで入力ｃが行われると、信号ｓを送信し、状態Ｒに移動し、その時にこの信号ｓを受信するｎｄＦＳＭは状態Ｒにある。受信するｎｄＦＳＭはｓをその入力信号として受け取る。（３，４）：受信するｎｄＦＳＭはその入力信号ｓが信号検知テスト：ｍＲ？（）（’ｍＲ？’は’ｍｅｓｓａｇｅＲｅａｄｙ？’を表す）を実施するその親セルに検知されると状態Ｓへ移動する。事後条件に示しているように、信号の検知は、入力信号がｓの場合はｔｒｕｅの真理値を返し、それ以外はｆａｌｓｅの信号を返し、ここでは信号ｓはメッセージ配信信号を指す。受信セルによるメッセージ配信信号の検知はメッセージ受信となる。ただし、機能ポート、ｆでの配信信号は応答メッセージが返信されるまで５、６回正常に検知されるが、それは配信信号が応答が送出されるまで変化するからである。
【００９７】
（５から１０）ｆからｑへの応答信号送信：（５）：セルＤはそのタスクを完了したことを示している完了信号ｃをｆに送信する。（６）：ｆは開始信号ｓをポートｇに送信し、その状態をＲに変化させる。これはＤからの応答信号である。（７−１０）：セルＣは２つの検知試験の一方を使用して配信信号をそのポートｇ：ｇ：ｍＲ？（）またはｇ：ｐＲ？（’ｐＲ？’は’ｐａｔｈｗａｙＲｅａｄｙ？’を表す）で受信する。ただし、一般ポートに配信された信号は検知試験ｇ：ｍＲ？（）を使用して１回だけ検知されてもよいが、それは信号が検知後、φ（空の記号）にリセットされるからである。しかし、ｇ：ｐＲ？（）試験は繰り返し正常に使用可能で、それはｇの状態が検知後にＳに変化するからである。実際に、一般ポートまたは機能ポートである任意のポートｐについて、配信信号の検知は常にｐを状態Ｓにするためである。
【００９８】
スレッド相互動作プロトコル、ＴＩＰ：図１のＴＩＰ（１）は、経路の準備ができている場合、Ｃはサービス要求の送信前に実行が必要なことを実行するためにｐｔｈｒｅａｄ、ｇ：ｘ（）を実行することを指定する。このｐｔｈｒｅａｄはセルＣ、ｇ：ｘ（）≡Ｃ：ｘ（ｇ）で定義されており、Ｃに割り当てられているプライベートメモリ内で実行される。ｇ：ｘ（）の実行直後に、Ｃはｇに接続されている経路内のコンポーネントに関連付けられているメモリ内でｇ：ｓ（）を実行する。図１において、これはポートｇとｆとに関連付けられている共有メモリとなる。これによって、図１の通信プロトコル（１）が実行され、その結果サービス要求信号がポートｆに配信される。
【００９９】
図１のＴＩＰ（２）が以下を指定する：ＤがＣによってそのポートｆに送信されたサービス要求信号をｆ：ｍＲ？（）試験を適用することによって検知すると、ＤはセルＤにおいて定義されており、Ｄのプライベートメモリ内で実行されるｐｔｈｒｅａｄ、ｆ：ｒ（）≡Ｄ：ｒ（ｆ）（‘ｒ’は’ｒｅｐｌｙ’を表している）を実行することによって受信した信号に応答を開始する。ｆ：ｒ（）の実行のすぐ後に、Ｄはｆ：ｓ（）を実行する。これによって、図１の通信プロトコル（１）が実行され、その結果サービス要求信号がポートｇに配信される。ポートｇの親セルＣによるこの応答信号の検知によって、Ｃがそのサービス要求信号をＤに送信した時に開始されたトランザクションが終了する。
【０１００】
経路の状態変化によって課される制限：トランザクションの開始時に、経路の状態は［Ｓ，Ｒ］であった。セルＤによって信号が検知された時に、経路の状態は［Ｒ，Ｓ］である。この新しい状態において、経路は応答信号を返信する準備ができている。応答信号がセルＣによって検知された時に、トランザクションは完了し、経路の状態は［Ｓ，Ｒ］に戻る。これらの状態変化は以下の制限を課す：Ｃ．ｇはトランザクションが完了した時に初めて第２のサービス要求信号を送信可能で、Ｄ．ｆは第１のサービス要求信号に応答した後で初めて第２サービス要求信号を受信することができる。連続したサービス要求信号は、連続したトランザクションが完了した時に初めて経路を通して送信することができる。
【０１０１】
サービス要求に対する必須の応答：全てのＴＩＣＣ経路について成立する一般的な規則は、各サービス要求は要求が受信されたのと同じ経路を介して必ず応答されるということである。この一般規則に対する例外は「一方通行の環状道路」（セクション８．２）において発生する。したがって、各トランザクションは専用の経路を通して発生する。応答の受信によって、一方通行環状道路においてさえ、常に経路がその初期状態にリセットされる。各信号送信セッションにおいて、経路内のｎｄＦＳＭは他のｎｄＦＳＭによって送信された信号を受信し即座に応答する準備ができている状態に常にある。これは、どれだけ複雑であっても、またどれだけ多数のｎｄＦＭＳが埋め込まれていても全てのＴＩＣＣ経路について当てはまる。これはチューンと呼ばれる。チューンによって、信号送信中の同期セッションが必要なくなり、信号送信が相当に高速化される。
【０１０２】
チューン：経路内のｎｄＦＳＭは、（ｉ）それらを適切な初期状態に設定することによって互いに対してチューンされ、（ｉｉ）チューンが、経路を通して初期化された各トランザクションが応答信号を同じ経路を通して送信することによって完了するように要求することによって、また（ｉｉｉ）経路上の現在のトランザクションが完全に完了した後で初めて新しいトランザクションがその経路を通して初期化されるように要求することによって維持される。
【０１０３】
計算と通信の統合：計算と通信は両方が同じセルによって実行される。計算の実行と通信の実行との間には区別はない。それらは、スレッド相互動作プロトコル、ＴＩＰによって呼び出され、実行される。セルの各ポートはそれに対して定義されているＴＩＰを有している。ＴＩＰはポートの親セルによって実行される。ＴＩＰはＣ．ｐ：〈ｇｕａｒｄ〉？（）｛〈ｔｉｐ−ｂｏｄｙ〉｝の形態を有しており、ｐはセルＣのポートである。Ｃ．ｐ：〈ｇｕａｒｄ〉？（）がｔｒｕｅの場合、〈ｔｉｐ−ｂｏｄｙ〉が実行され、そうでなければポートがスキップされる。ｐの親セルＣによるＣ．ｐでのＴＩＰボディの実行を指す時にＣ．ｐ：ｔｉｐ（）を使用する。各セルはそのポートを何らかの順番で循環的にポーリングする。ポーリングの順番によってセルのポートがサービスされる順番は決まらないが、それはサービスが配信信号がポートで検知された場合にだけ実施され、信号配信時間とポーリング時間とは互いに同期していないからである。通信は非同期である。
【０１０４】
１．２．１仮想メモリを備えている単純なＤａｓ経路
図２は仮想メモリ、Ｍを備えているＤａｓ経路、Ｍに接続されているポートのＴＩＰ、ポートのプロトコル、およびエージェントとポートに対するＣＣＰの特徴付けを示している。経路は２つのエージェントａ０とａ１とを有している。各ポートは、その親セルが、その状態がＳの場合にだけ、それに接続されている仮想メモリ、Ｍ内のデータへのアクセスできるようにしている。データはアクセスされるまで仮想メモリ内で保護され保存されている。図２の経路内のエージェントは必要に応じて信号が仮想メモリを迂回するようにする。
【０１０５】
図２において、ｐｔｈｒｅａｄは、ｇ：ｘ（）≡ｇ：ｍｓｇ（）：ｘ（ｇ）およびｆ：ｒ（）≡ｆ：ｍｓｇ（）：ｒ（ｆ）である。これらのｐｔｈｒｅａｄはｇとｆの親セルによって仮想メモリ、Ｍ内に書き込まれたメッセージのＭｅｓｓａｇｅサブクラス内で定義される。ここで、Ｍはｐｔｈｒｅａｄの実行環境を提供し、仮想メモリはセルＣとＤの共有メモリ環境の一部である。この種類の動作を可能にする仮想メモリの構造をセクション７．２で説明している。
【０１０６】
0005704459.tif 000003
【０１０７】
図２：仮想メモリを備えている点対点Ｄａｓ経路
図１と２のセルＤは、配信された信号を配信時に検知しないことがあり、Ｄがその時にその他のポートの１つのサービスを行っている可能性がある。最終的にセルＤがそのポートＤ．ｆをポーリングして、図１と２の第２のＴＩＰでガードＤ．ｆ：ｍｒ？（）を評価した時に、メッセージ配信信号を検知する。セルはそれらのポートのいずれかに配信された任意の信号の検知をし損なうことはない。１つのポーリングサイクルで検知し損なった信号は続くサイクルで取得される。図２に示しているＣＣＰ特徴付けは図１のものと同様である。
【０１０８】
トランザクションの正しさ：図１の場合にように、ポートｇが応答メッセージ、例えばｍ’、を検知した時間はポートｇがそのサービス要求メッセージ、たとえばｍ、を送出した時に開始されたトランザクションの最後となる。ｍ’がｇに時刻ｔ２に配信されｍがｇによって時刻ｔ１に送信されたとする。ポートｇとｆとの間のトランザクションは、メッセージｍとｍ’が事前に定義されている関係Ｒ（ｇ，ｆ）（ｍ，ｍ’）を満たしており、さらにタイミングの制限ｔ２≦ｔ１＋τｍａｘ（ｇ，ｆ）が満たされている場合にだけ正しく、ここでτｍａｘ（ｇ，ｆ）はｇとｆとの間のトランザクションを完了するのにかかる可能性のある最長時間であって、図１のようにメッセージが交換されない場合、前述のタイミング条件だけが成立しなければならない。ポートｇとｆとは、これらの条件がｇとｆとの間の全てのトランザクションについて成立している場合にだけ良好にマッチしている。実装は、経路によって接続されている実装内のポートの全ての対が良好にマッチしている場合にだけ正しい。
【０１０９】
１．２．２．フォークとジョイン操作を備えているｓｍ経路
図３はエージェントａ０を備えている単純な経路を示している。エージェントは時間同期信号をポート[Ｄ１．ｆ，Ｄ２．ｆ]の両方にブロードキャストする。別個のセルに付属しており、同じエージェントに接続されている同じ種類のポート（つまり全ての一般ポートと全ての機能ポート）がポートグループを構成する。したがって、図３と４のポート[Ｄ１．ｆ，Ｄ２．ｆ]はポートグループを構成する。全てのセルが並列に動作し全てのセル活動は信号配信と同期していないため、Ｄ１とＤ２とは信号を同時に検出して応答しないことがある。その結果、Ｄ１とＤ２とは自身の時間に各々が配信された信号を検知し、それに応答することになる。エージェントａ０は、Ｄ１．ｆとＤ２．ｆの両方から完了信号を受信した後で初めて応答信号をＣ．ｇに返信することになる。これを調和と呼ぶ。図３の第２のプロトコルの一致プロトコルメソッドａ０：ＡＰ［ｃ１，ｃ２］＊は調和を実施する。したがって、エージェントａ０は時間同期信号配信と調和した信号ディスパッチとを行う。
【０１１０】
0005704459.tif 000004
【０１１１】
図３：フォークを備える単純な点対グループ経路
図３のプロトコル（２）の実行は以下のように進行する：Ｄ１．ｆとＤ２．ｆの両方が同様なプロトコルを有しており、Ｄ１．ｆのプロトコルは「Ｄ１．ｆ：ｃ１→ａ０：ＡＰ［ｃ１，ｃ２］＊：ｓ→Ｃ．ｇ」。Ｄ２．ｆのプロトコルは「Ｄ２．ｆ：ｃ２→ａ０：ＡＰ［ｃ１，ｃ２］＊：ｓ→Ｃ．ｇ」である。Ｄ１とＤ２の両方が、それぞれのタスクの完了後に応答信号をＣ．ｇに送信するために、それぞれのＤ１．ｆとＤ２．ｆで並列に、しかし必ずしも同期せずにポートプロトコルの実行を開始する。したがって、両方が、それらのそれぞれのＣＣＰ、Ｄ１．ｆ：ｃ１→ａ０とＤ２．ｆ：ｃ２→ａ０の実行後に、一致プロトコルメソッドａ０：ＡＰ［ｃ１，ｃ２］＊並列に評価する。条件ＡＰ［ｃ１，ｃ２］＊は、ａ０が信号ｃ１とｃ２の両方を受信した後初めてｔｒｕｅになる。Ｄ１とＤ２とはａ０：ＡＰ［ｃ１，ｃ２］＊をｔｒｕｅになるまで循環的に評価し続ける。ａ０：ＡＰ［ｃ１，ｃ２］＊がｔｒｕｅになると即座にプロトコルの残りを実行（ｒｕｎ）するためにＤ１とＤ２の一方がａ０によって非決定的に選択され、他方は強制的にプロトコルの実行を停止される（これはセクション８に示しているグループ対グループプロトコルの単純化されたバージョンである）。読者は、ａ０：ＡＰ［ｃ１，ｃ２］＊に従っているプロトコルのセグメントがＤ１．ｆとＤ２．ｆの両方について同じことを確認することができる。これによって、信号がポートＣ．ｇだけに１度配信されることが保証される。したがって、ａ０：ＡＰ［ｃ１，ｃ２］＊が成立すると、図３のエージェントａ０は誰がプロトコルを実行しているかに関わらず応答シグナルｓをＣ．ｇに送信する。したがって、ａ０がセルグループ内のセルＤ１とＤ２によるプロトコルの異なるセグメントの並列実行を保証する。
【０１１２】
0005704459.tif 000005
【０１１３】
図４：仮想メモリを備えているフォーク
仮想メモリと関連付けられているＴＩＰとプロトコルを備えている同様なＤａｓ経路を図４に示している。同図において、ａ１は時間同期メッセージ配信と調和したメッセージディスパッチを実施し、ａ０はサービス要求が送信された時にメッセージディスパッチを実施し、応答メッセージが返信された時にメッセージ配信を実施する。
【０１１４】
図３と４のネットワークは同期フォーク／ジョイン動作を表し、フォークは信号がポートｇによって機能ポートグループに送信された時に発生し、ジョインは機能ポートグループのポートが応答信号を返信した時に発生する。フォークとジョインのこの表記を２つ以上のポートを含んでいる一般ポートグループが結合サービス要求を機能ポートグループに送信する状況にも拡張する。そのようなグループ対グループフォークとジョイン動作用のプロトコルをセクション７で説明する。
【０１１５】
１．３．共有メモリと分散メモリの経路
ポートを経路内のエージェントまたは他のポートに接続しているリンクはブランチと呼ばれる。エージェントを相互に接続しているリンクはｈブランチ（隠れたブランチ）と呼ばれる。ｓｍ経路、ポート、エージェント、ブランチ、ｈブランチ、および仮想メモリの全てのコンポーネントはソフトウェアコンポーネントである。それらは全て共有メモリを含んでいる経路の共有メモリ環境内で動作する。
【０１１６】
ＴＩＣＣＮＥＴのｄｍ経路内のエージェントといくつかのポートはハードウェアコンポーネントであって、各々が自身のローカルメモリ内で動作し、ｄｍ経路内のブランチとｈブランチとは信号送信線である。エージェント、ポート、および仮想メモリ以外に、ｄｍ経路は埋め込まれている特別なハードウェアスイッチとルータも有している。通信は２つの段階、（ｉ）経路の確立と（ｉｉ）信号／データ交換で発生する。スイッチとルータとは経路の確立時にだけ使用される。いったん確立されると、経路は定位置に維持され、取り除かれて新しい経路が確立されるまで繰り返し使用される。メッセージは既に確立しているｄｍ経路を通してだけ交換できる。信号／データ送信線を通した信号とデータ交換はＣＣＰ実行によって管理される。ｓｍ経路でのように、信号／データを交換するｄｍ経路内の全てのエージェントとポートは常に互いに対してチューンされている。２つのｄｍ経路はメッセージ送信中に使用されないスイッチとルーター以外にコンポーネントを共有することはない。ＴＩＣＣＮＥＴは数千の別個の相互に干渉しない点対点と点対グループｄｍ経路を収容することが可能で、数千の同時の並列のメッセージ交換をもたらす。
【０１１７】
既に説明した特性の繰り返しになるが、ｓｍ経路とｄｍ経路に共通の特性を以下に３つのカテゴリで一覧表示している。
【０１１８】
（１）．ＴＩＰフォーマットは経路構造とは無関係：（ｉ）通信プリミティブはｐ：ｓ（）（’ｓ（）’は送信を表す）とｐ：ｆ（）（’ｆ（）’は転送を表す）であって、ｐはポート、ｆ（）は受信したメッセージを場合によっては何らかの修正後に他のセルのポートに転送し、ｓ（）は新しく生成されたメッセージを送信する。プリミティブｐ：ｓ（）とｐ：ｆ（）はポートｐに関連付けられている一意のプロトコルの呼び出しと実行するために使用される。（ｉｉ）このようにポートｐに関連付けられているプロトコルはｐに接続されている経路の性質に依存しており、異なる経路については異なる。（ｉｉｉ）同じ通信プリミティブ、ｐ：ｓ（）とｐ：ｆ（）とがポートｐに接続されている経路の種類に関わらずポートｐのプロトコルを呼び出し実行するために使用される。（ｉｖ）ポートｐでのプロトコルの呼び出しと実行によって信号がポートｐに接続されている経路上を送信され、それが今度は、存在する場合は、メッセージを同様に同じ経路に接続されているその受信ポートに配信つまり送信する。（ｖ）ｐの親セルだけが、通信プリミティブｐ：ｓ（）とｐ：ｆ（）とを呼び出し実行することができる。（ｖｉ）ポートｐでのＴＩＰフォーマットはｐに接続されている経路の種類には無関係である。（ｖｉｉ）信号を交換する任意の経路の全てのコンポーネントは常に互いにチューンされたままである。これらの特性によって、共有メモリと分散メモリ通信との間のソフトウェアシステムの区別が排除され、信号送信中の同期セッションの必要性が完全に無くなる。
【０１１９】
（２）．グループ対グループメッセージ交換の同時の並列実行：ポートグループに属している別個のポートの別個の親セル（セクション１．３と７）はセルグループを構成しており、（ｉ）セルグループ内のセルはプロトコルの指定されたセグメントを同時に並列に実行し、別個のセグメントはセルグループ内の別個のセルに対応している。全てのセグメントを共に並列に実行することによって、グループ対グループ非同期メッセージ交換が経路の２つの端部に接続されているセルグループ間（図１９）の経路上に実装され、経路上のエージェントはそのような同時の並列のプロトコルセグメントの実行を調和させる（セクション１．３と７）。（ｉｉ）分散メモリ環境において、１つの共有メモリマルチプロセッサ（ＳＭＰ）内の一般ポートグループはＴＩＣＣＮＥＴｄｍ経路を通して結合メッセージをグリッド内の５〜６個の他のＳＭＰ内の機能ポートグループに送信してもよい。ブロードキャストメッセージは並列に全ての宛先機能ポートグループに配信される。ｆｕｎｃｔｉｏｎａｌＰｏｒｔはそれらの応答を送信元の一般ポートグループに多重化モードで１つずつ同じ経路を通して返送する。これはｄｍ経路内のコンポーネントの相互チューンを維持する。
【０１２０】
（３）．高速並列メッセージ交換とモビリティ：（ｉ）全ての経路において、全てのメッセージは準備ができ次第即座に送信され、（ｉｉ）経路がどんなに複雑でも、信号を交換する経路内の全てのエージェントとポートは一方から他方に送信された信号が即座に受信側によって受信され、適切な時間に応答されるように互いに対して常にチューンされている。これによって、同期セッションが必要なくなり、（ｉｉｉ）２つの経路は共通のコンポーネントを共有せず、したがって、別個のプロトコルの２つの並列の実行が互いに干渉することはない。これは、ＳＭＰ内のソフトウェアｓｍ経路とＴＩＣＣＮＥＴ内のｄｍ経路の両方にも当てはまる。そのため、（ｉｖ）並列に交換可能なメッセージの数は、経路の数によってのみ制限され、（ｖ）トランザクションの途中での経路の目標ノードへの接続の動的な変更（セクション３．２のモビリティを参照）はｄｍ経路では発生しない。そのような変更はｓｍ経路でだけ発生する。
【０１２１】
一般的な並列計算に対応しているＴＩＣＣ−Ｐｐｄｅ内の計算構成の概要を次の２〜３のサブセクションに示す。より詳細は、セクション３から５で後に示す。ＴＩＣＣ−Ｐｐｄｅ実装の例をセクション２に示し、ＡＬＬＥＯＰ証明を使用した例をセクション６に示す。
【０１２２】
１．４．ＴＩＣＣクラスとオブジェクト
ＴＩＣＣはトップレベルクラス：Ｃｅｌｌ、Ｐｏｒｔ、エージェント、仮想メモリ、Ｂｒａｎｃｈ、およびＭｅｓｓａｇｅを定義する。セル、ポート、エージェント、仮想メモリ、ブランチ、およびメッセージという表記をこれらのクラスのインスタンスであって、すべてソフトウェアコンポーネントであるオブジェクトを指すために使用する。アクター［Ｈｅｗｉｔｔ，５，６］とπ算法エージェント［Ｍｉｌｎｅｒ，７，８，９］のように、各セルは本質的に自身の割り当てられている計算ユニット（ＣＰＵ）内で実行（ｒｕｎ）される並列ソフトウェアコンポーネントである。セルとアクターおよびπ算法エージェントとの間には５〜６個の違いがある。それらは後に説明する。
【０１２３】
ポートがポートベクトルに属していない限り（セクション５．２を参照）、同じセルに属している２つのポートはブランチによって接続されず、ブランチは同じセルに属している２つのポートを同じ経路に接続しない。全ての場合で、セルの１つのポートはメッセージを同じセルの他のポートに送信することはできず、これによって可能性のあるデッドロックを防止している。しかし、別個のセルに属している別個のポートは同じエージェントへのブランチに接続されていてもよい。前述のように、そのようなポートは順序付けされているポートグループを構成し、図４の［Ｄ１．ｆ，Ｄ２．ｆ］はその例である。２つの別個のポートグループは互いに交差することはなく、同じセルに属している２つのポートが同じポートグループ内に存在することはない。スーパーコンピューティンググリッド内では、任意のセルグループの全てのセルは常に同じＳＭＰ内に存在している。セクション７からわかるように、これらの制限によって、グループ対グループ経路を通してポートグループ間でメッセージを交換することができる。
【０１２４】
１．５．セル動作、ＣＩＰ、およびポーリング
各セルはそのポートｐを何らかの順序でポーリングし、セル自体が選択した並べ替え基準に基づいて保留メッセージを使用してｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに全てのポートを並べ替える。それからｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内の各ポートｐについて、ＴＩＰボディ、ｐ：ｔｉｐ（）がｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内に現れるポートの順序で１つずつ実行される。セルは連続しているｐ：ｔｉｐ（）の実行の間の割り込み処理に対応してもよい。割り込みメッセージは、ＴＩＣＣ−Ｐｐｄｅの要件のいずれにも違反せずに、ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内のポートの順序を変更したり、ポートの優先順位を変更したり、ＣＩＰ実行のサスペンド／終了を整然と実施してもよい。サスペンドされたＣＩＰは次の割り込みメッセージが同じ割り込みポートに配信された時に自動的にリジュームされる。オペレーティングシステムはセルのアクティビティに割り込むことはできず、アプリケーション内の他のセルだけがそうすることができる。共有メモリマルチプロセッサ（ＳＭＰ）内のセルへの動的プロセッサ割り当てはＴＩＣＣによって管理される。セルのグリッド内のＳＭＰへの割り当てはユーザによって行われる。以下で定義されるＣＩＰはＳＭＰ内で動作する。
【０１２５】
各ポートで１つの、セルのポートで定義されている全てのＴＩＰの集合は、セル初期化メソッドと共に、セル相互動作プロトコルＣＩＰと呼ばれる。以下で説明する初期化と割り込みメッセージ処理はＣＩＰ動作の一般的な制御構造を示している。
割り込み処理は、割り込みメッセージがセルのポーリングサイクルの中で認識される時刻と割り込みメッセージの性質とに依存してセルごとに異なる。ＣＩＰは以下の形態を有している。
【０１２６】
ｖｏｉｄＣｅｌｌ：：ＣＩＰ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ；
ｉ：ｐＲ？（）｛ｉ：ｓ（）｝；ｉｎｉｔ（）；｝｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛
ｉ：ｍＲ？（）｛ｉ：ｓ（）．ｒ（）；｝／／ｉ：ｒ（）は以下の（１．２）で定義。ただし、応答が先に送信される
ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｃｌｅａｒ（）；
ｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）；／／ポーリングされたポートをメッセージ配信信号と共にｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに配置
／／ポートｐがｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内に現れる順序でｐ：ｔｉｐ（）を実行
ｆｏｒ（ｉｎｔ ｊ＝０；ｊ＜ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｓｉｚｅ（）；ｊ＋＋）｛
ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［ｊ］：ｔｉｐ（）；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝ （１．１）
ｐｔｈｒｅａｄ ｉ：ｒ（）＝ｉ：ｍｓｇ（）：ｒ（ｃｅｌｌ）は割り込みポート ｉの仮想メモリ内のメッセージのメッセージサブクラス内で定義される。ＩｎｔｅｒｒｕｐｔＭｓｇをこのサブクラスとすることにする。ＩｎｔｅｒｒｕｐｔＭｓｇ：：ｒ（）の定義を以下で示し、以下の第２段落で説明する。
【０１２７】
ｖｏｉｄ ＩｎｔｅｒｒｕｐｔＭｓｇ：：ｒ（ｃｅｌｌ）｛／／ｓｅｌｅｃｔＯｎｅはトップダウン走査において第１のｔｒｕｅの選択肢を選択する
ｓｅｌｅｃｔＯｎｅ｛ｃｅｌｌ：ｓｕｓｐｅｎｄｅｄ？（）｛ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄ＝ｆａｌｓｅ｝
ｓｕｓｐｅｎｄ？（）｛ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄ＝ｔｒｕｅ；ｐｒｅｐａｒｅＴｏＳｕｓｐｅｎｄ（）；｝
ｔｅｒｍｉｎａｔｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；｝
ｔｒｕｅ｛ｓｅｔＰｏｒｔＰｒｉｏｒｉｔｉｅｓ（）；｝｝ （１．２）
【０１２８】
初期化：前述のＣＩＰにおいて、ｉｎｉｔｉａｌｉｚｅ？（）はセルの局所変数ｉｎｉｔｉａｌｉｚｅの真理値であって、’ｉ’はセルの割り込みポートである。休止セルは、ｉに対して配信された最初の割り込みメッセージによってＴＩＣＣによって選択されたプロセッサ内で起動される。一般に、休止セルはそのポートのいずれかに配信された最初のメッセージによって起動される。メッセージを配信するプロトコルがこの起動を実施する（セクション７）。起動時に、ｉｎｉｔｉａｌｉｚｅ？（）がｔｒｕｅの場合、セルはｉｎｉｔｉａｌｉｚｅ＝ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅをセットし、ポートｉでの割り込みメッセージによって実際に起動した場合、ｉ：ｓ（）を実行することによってそれを開始したセルに肯定応答を返信し、それらを実行した後、ｉｎｉｔ（）で指定されている初期化を実施し、それからｗｈｉｌｅループに進む。
【０１２９】
割り込みポートサービス：ｗｈｉｌｅループ内で、セルは最初にその割り込みポートをポーリングする。割り込みメッセージが存在しない場合、ポートをスキップする。存在する場合、（１．２）に示しているｉ：ｒ（）＝ｉ：ｍｓｇ（）：ｒ（ｃｅｌｌ）を実行する。（１，２）のｓｅｌｅｃｔＯｎｅにおいては考慮すべき４つの場合が存在する。（ｉ）ｃｅｌｌ：ｓｕｓｐｅｎｄｅｄ？（）がｔｕｒｅの場合、それはセルが以前にサスペンドされていたことを意味する。この場合、ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄはｆａｌｓｅにセットされ、セルはｗｈｉｌｅループの残りを実行するために即座に進む。（ｉｉ）ｉ：ｍｓｇ（）：ｓｕｓｐｅｎｄ？（）がｔｒｕｅならば、ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄはｔｒｕｅにセットされ、セルは自身をサスペンドする準備をし、即座にその割り当てられているプロセッサを解放し、それらを実行した後、セルは休止する。セルに配信される次のｉｎｔｅｒｒｕｐｔＭｓｇが自動的にセルを使用可能なプロセッサにおいて起動する。そのように再起動すると、セルは初期化をスキップして直接ｗｈｉｌｅループ内に進むが、それはｉｎｉｔｉａｌｉｚｅ？（）がその時にはｆａｌｓｅになっているからである。（ｉｉｉ）ｉ：ｍｓｇ（）：ｔｅｒｍｉｎａｔｅ？（）がｔｒｕｅの場合、セルはｗｈｉｌｅループの現在のサイクルの最後で動作を中止し、そのプロセッサを解放するが、それはｃｅｌｌ．ｓｔｏｐＰｏｌｌｉｎｇがｔｒｕｅにセットされているからであって、（ｉｖ）（１．２）のｓｅｌｅｃｔＯｎｅの既定の場合は、ｉｎｔｅｒｒｕｐｔＭｓｇに指定されているようにセルのポートに優先度を割り当てる。これらの優先度は、続く（１．１）のｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）によって使用される。ここではサスペンド／レジューム動作はオペレーティングシステムを呼び出すことを必要とせずにＴＩＣＣによって管理される。
【０１３０】
ポーリング：セルの割り込みポートをポーリングした後、セルはセルの他のポートのポーリングを開始し、ｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）を実行することによって保留中のメッセージと共にポートをｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに並べ替え、そのリスト内でリストに現れる順序で各ｐについてｐ：ｔｉｐ（）を実行する。ｗｈｉｌｅループはｓｔｏｐＰｏｌｌｉｎｇがｔｒｕｅになるまで繰り返される。ポーリングサイクルはメッセージ配信に同期していない。ポーリングサイクル内でポートをポーリングしている時に、ポートがポートに配信済みのメッセージを有していない場合、セルはそのポートをスキップし次のポートをポーリグする。スキップされたポートは実行サイクル中に新しいメッセージを受信することがある。１つのポーリングサイクル中に保留中のメッセージを検知し損なったポートは次のポーリングサイクルで検知され、ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内に含められることになる。したがって、ポートは、ポートにメッセージが配信されるのと同じ順序でサービスされないことがある。しかし、セルの中止が早過ぎたりアプリケーションシステム内にデッドロックが存在したりしない限り、入力メッセージがセルによって検知し損なわれることはない。したがって、正常な動作条件の下では各トランザクションが完了する。これはＴＩＣＣ−Ｐｐｄｅのおいて重要な要件である。
【０１３１】
ポートサービスの他のモード：セルが保留中のメッセージをポートｐで検知した後で即座にｐ：ｔｉｐ（）を実行し、したがって並べ替えサイクルをスキップすることができる。以下の種類の同期計算を有することが可能で、セルはそのポートでメッセージを受信するまで（またはポートの準備ができるまで）待ち、メッセージが到着した時にメッセージに応答し（またはポートの準備ができた時に新しいメッセージを書いて送信し）、セルの次のポートをポーリングするために進む。そのような同期計算は、ＴＩＰ内でＣ．ｐ：〈ガード〉？（）＊の形態のガードを使用することによって指定される。’＊’は待つことが必要なことを表している。アスタリスクが付されているガードは同期ガードと呼ばれ、ｔｒｕｅになるまで繰り返し評価される。
【０１３２】
例：
セクション２において、［Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ，１３］から採用した２つの単純な例を示すために図１から４の単純なネットワークを使用する。これらの例は、ＴＩＣＣ−Ｐｐｄｅ実装の性質を示している。第１の例は、実装仕様、トレース、およびＡＬＬＥＯＰと実行（ｒｕｎ）時のＳＭＳの役割から導出された因果律網からシステムによって生成されたＡＬＬＥＯＰを紹介するために使用される。例は、モニタ［Ｈｏａｒｅ，１２］やセマフォ［Ｄｉｊｋｓｈｔｒａ，２３，２４］の必要無しにＴＩＣＣ−Ｎｅｔｗｏｒｋｓによって実行される並行性、自動調和、および時間同期も示している。第２の例は、ＴＩＣＣ−Ｐｐｄｅにおけるカプセル化の概念を導入し、非決定的ガードの使用を説明する。
【０１３３】
２．簡単な例
各例の実装仕様は、ＴＩＣＣ−ｎｅｔｗｏｒｋｓ、様々なポートのＴＩＰ、セルのＣＩＰ、セルのポートがポートングされる順序を指定している各セルのポーリングサイクルからなる。ＴＩＣＣ−ｎｅｔｗｏｒｋは計算中に発生するメッセージ交換、同期、および調和の抽象化である。それは並列計算の制御構造を指定する。このセクションにおいて例のための証明は示されておらず、セクション７においてＡＬＬＥＯＰ証明を備えている例が示されている。
【０１３４】
２．１．ＢｉｌｌとＢｅｎの例：ＡＬＬＥＯＰ、トレース、因果律網
［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］の単純なゲームから始める。ゲームのＦＳＰモデルは、Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］で示されているように、以下のようになる。
【０１３５】
｜｜ＢＩＬＬ＿ＢＥＮ＝ＢＩＬＬ｜｜ＢＥＮ；
ＢＩＬＬ＝ｐｌａｙ→ｍｅｅｔ→ＢＩＬ、ＢＥＮ＝ｗｏｒｋ→ｍｅｅｔ→ＢＥＮ （２．１）
ここで従来の意味[１２、１３]での同期はアクションの用語「ｍｅｅｔ」で発生すると仮定される。ゲームのＴＩＣＣ−Ｐｐｄｅ実装をここで示す。実装仕様から導出されたＡＬＬＥＯＰモデル、ＡＬＬＥＯＰから導出されたトレース、およびＳＭＳが生成した因果律網を示す。全ての導出はシステムによって自動的に行われる。ＡＬＬＥＯＰモデルは、実装のモデルであって、システムの意図した設計のモデルではない。したがって、それらはＦＳＰモデルよりも複雑であるが、ある意味ではそれらの構造はＦＳＰ構造と同様である。
【０１３６】
ＴＩＣＣ−ネットワークを図５に示している。各ＴＩＣＣ−ネットワークは時には構成セルとも呼ばれる少なくとも１つの環境セルＥを有している。これは、ネットワークを構成し動作を開始するのに使用される。ＴＩＣＣ−ＧＵＩ（グラフィカルユーザインターフェイス）画面が開いた時に、それはＥがその中にインストールされた状態で表示される。アプリケーションプログラマはセルサブクラスＥとＴＩＣＣ−ＧＵＩの操作の前にアプリケーションに必要な他のセルサブクラスを定義済みでなければならない。環境セルＥはＧＵＩ画面上の画像をクリックし、割り込み信号を割り込みポート、Ｅ．ｉに送信することによってユーザによって起動される。Ｅは全ての他のセルと全ての経路をＴＩＣＣ−Ｎｅｔｗｏｒｋｓ内にインストールするのに使用される。全てのインストールされたセルと経路とはＴＩＣＣ−ＧＵＩ画面に表示され、ユーザが画像の再配置を行った後の結果の画像は図５の表示のようになる。これがいったん完了すると、Ｅをクリックして、割り込み信号をそのポートＥ．ｇ１を介してネットワーク内のセルの割り込みポートにブロードキャストすることによってアプリケーションが開始され、これによってセルが起動される。
【０１３７】
0005704459.tif 000006
【０１３８】
図５：ＢｉｌｌとＢｅｎの例：「ｍｅｅｔ」で同期
以下では、「Ｂｅ」を「Ｂｅｎ」、「Ｂｉ」を「Ｂｉｌｌ」、ＭｅをＭｅｅｔｉｎｇ、「Ｂ」を「Ｂｅｎ ａｎｄ Ｂｉｌｌ」という省略を使用する。［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆおよび［Ｂｅ．ｇ，Ｂｉ．ｇ］＝Ｂ．ｇはポートグループである。ＢｅｎとＢｉｌｌの両方が同期している信号を受信し、調和している信号を図５のこれらのポートグループ：エージェント、ａ１とａ２を通して送出して、セクション１．３．２で説明したように同期と調和を実施する。セルＥのＣＩＰを以下に示す。
Ｅ：ＣＩＰ（） 定義：
ｖｏｉｄＥ：：ＣＩＰ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉｎｉｔ（）；Ｅ．ｇｌ：ｓ（）；Ｅ．ｉ：ｓ（）；
ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ；｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛
（Ｅ．ｇ：ｐＲ？（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）＊）｛ｇ：ｓ（）；ｇ：ｍＲ？（）＊｛｝｝
Ｅ．ｉ：ｍＲ？（）｛Ｅ．ｇｌ：ｓ（）；Ｅ．ｇｌ：ｍＲ？（）＊｛Ｅ．ｉ：ｓ（）；
ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝ （２−２）
【０１３９】
前述のＣＩＰは以下の動作を指定している：ユーザによって割り込みポート、Ｅ．ｉに送信される第１の割り込み信号によってＥが起動し、Ｅにｉｎｉｔ（）で定義されている初期化を実行させ、それによってアプリケーションに必要な全てのセルと経路がインストールされる。この後、Ｅは割り込み信号をゲーム内のセルの割り込みポートにそのポートｇ１を通して送信する。これによって図５のネットワーク内のセルが起動される。それからＥはそれを開始した割り込み信号に返信し、その変数を初期化し、それからそのｗｈｉｌｅループの実行に進む。ｗｈｉｌｅループ内では、その一般ポートのポーリングをまず実施する。ポートＥ．ｇが信号を送信する準備ができており、Ｅがゲームを開始する準備ができている場合、Ｅ．ｇは信号を［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆに送信する。これによってゲームが始まる。ゲームを開始すると、ＥはそのポートＥ．ｇでゲームの終了信号の受信を待つ。
【０１４０】
ゲームの終了信号を受信した後、Ｅはその割り込みポート、Ｅ．ｉをポーリングする。Ｅが割り込み信号を検知すると、Ｅはその動作の終了を開始する。これは、Ｅがユーザから受信する第２の割り込み信号になる。第１の割り込み信号はそれを開始した割り込み信号である。中止前に、Ｅは割り込み信号を全ての他のセルにそのポートｇ１を通してブロードキャストする。これは、Ｅによってブロードキャストされる第２の割り込み信号となる。第１の割り込み信号はセルを開始したものである。第２の割り込み信号を受信した各セルは、応答を返信し、それから自身を終了する。Ｅは全てのセルから、図５のエージェントａ３によって転送された、調和した応答を受信した後で初めて終了する。これは、わずかな変形によって、全てのアプリケーションによって使用される一般的な開始／停止プロセスである。
【０１４１】
Ｅ．ｉにおいて割り込み信号が存在しない場合、Ｅは（２．２）と（２．７）に示しているように、そのポーリングサイクルを繰り返してもよい。図５の他のセルは同様のＣＩＰを有している。ただし、（２．２）のポートＥ．ｇのＴＩＰはそれに埋め込まれている他のＴＩＰ、ｇ：ｍＲ？（）＊｛｝を有している。この場合、ＴＩＰボディは空である。しかし、一般的には、これはそうする必要は無い。例えば、以下のＴＩＰ（２．４）と（２．５）において、埋め込まれているＴＩＰのＴＩＰボディは空ではない。複数のそのような埋め込みがＴＩＰで発生することがある。以下の説明では、開始／終了プロセス、割り込みポートポーリング、およびサービスを省略する。
ＴＩＰ：全てのＴＩＰは一般的な構造〈ＴＩＰガード〉｛〈ＴＩＰボディ〉}を有している。
【０１４２】
Ｅ．ｇ：ＴＩＰ（）：（Ｅ．ｇ：ｐＲ？（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）＊）｛Ｅ．ｇ：ｓ（）；Ｅ．ｇ：ｍＲ（）＊｛｝｝ （２．３）
Ｂｉ．ｆ：ＴＩＰ（）：Ｂｉ．ｆ：ｍＲ？（）｛Ｂｉ．ｆ：ｐｌａｙ（）；Ｂｉ．ｇ：ｓ（）；
Ｂｉ．ｇ：ｍＲ？（）＊｛Ｂｉ．ｆ：ｓ（）；｝｝ （２．４）
Ｂｅ．ｆ：ＴＩＰ（）：Ｂｅ．ｆ：πιＲ？（）｛Ｂｅ．ｆ：ｗｏｒｋ（），−Ｂｅ．ｇ：ｓ（）；
Ｂｅ．ｇ：ｍＲ？（）＊｛Ｂｅ．ｆ：ｓ（）；｝｝ （２．５）
Ｍｅ．ｆ：ＴＩＰ（）：Ｍｅ．ｆ：ｍＲ？（）＊｛Ｍｅ．ｆ：ｍｅｅｔ（）．ｓ（）；｝ （２．６）
【０１４３】
ＢｉｌｌとＢｅｎがＥによって送信された信号を検知すると、（２．４）と（２．５）に示しているようにそれらはそれぞれのこと、ｐｌａｙとｗｏｒｋを開始する。何をしているにしてもそれを終了した後、ＢｉｌｌとＢｅｎの各々は信号をそれらのそれぞれのポートＢｉ．ｇとＢｅ．ｇとを通してＭｅ．ｆに送信する。もちろん、それらは信号を送信した時間を同期させない。エージェントａ２はＢｉ．ｇとＢｅ．ｇから信号を受信するまで待ち、それから調和した信号をＭｅ．ｆに送信する。したがって、ＭｅｅｔｉｎｇはかならずＢｉｌｌとＢｅｎの両方がその準備ができた時にだけ始まる。ミーティングが終了すると、Ｍｅ．ｆは同期した信号をエージェントａ２を通して［Ｂｉ．ｇ，Ｂｅ．ｇ］＝Ｂ．ｇに送信する（図５を参照）。ＢｉｌｌとＢｅｎとがこの信号を受信した時に、両者は調和したゲームの終了信号をａ１を通してＥ．ｇに返信する。この時点で、Ｅは、そのポートＥ．ｉで割り込み信号によってゲームが中止されていない場合、ゲームの次の反復を開始してもよい。
【０１４４】
［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］のＦＳＰの枠組みで同期と呼ばれるものは、ＴＩＣＣ−Ｐｐｄｅでは調和と呼ばれる。ＴＩＣＣ−Ｐｐｄｅにおける同期は、並列に発生するイベントの時間的な同期を常に指す。この例では、時間的同期はＥ．ｇからの信号がエージェントａ１によって［Ｂｉ．ｆ，Ｂｅ．ｆ］＝Ｂ．ｆに配信された時と、Ｍｅ．ｆからの信号が［Ｂｉ．ｇ，Ｂｅ．ｇ］＝Ｂ．ｇ配信された時に発生する。
【０１４５】
ＰＯＬＬＩＮＧ ＣＹＣＬＥＳ：//割り込みポートポーリングはここでは無視されている
Ｅ：Ｐｏｌｌｉｎｇ（）＝［Ｅ．ｇ：ｐＲ？（）→Ｅ：Ｐｏｌｌｉｎｇ（）］ （２．７）
Ｂｅ：Ｐｏｌｌｉｎｇ（）＝［Ｂｅ．ｆ：ｍＲ？（）→Ｂｅ：Ｐｏｌｌｉｎｇ（）］ （２．８）
Ｂｉ：Ｐｏｌｌｉｎｇ（）＝［Ｂｉ．ｆ：ｍＲ？（）→Ｂｉ：Ｐｏｌｌｉｎｇ（）］ （２．９）
Ｍｅ：Ｐｏｌｌｉｎｇ（）＝［Ｍｅ．ｆ：ｍＲ？（）＊→Ｍｅ：Ｐｏｌｌｉｎｇ（）］ （２．１０）
ポーリングは再帰的であるが、それはＣＩＰのｗｈｉｌｅループのためである（（２．２）を参照）。これまで説明してきた仕様によって実施される計算は以下のＡＬＬＥＯＰによって特徴付けられる。
【０１４６】
２．１．１．ＢＩＬＬ−ＢｅｎゲームのＡＬＬＥＯＰ
以下の「→」は「起因する」と読み、「・→」は「直接起因する」と読む。これらは因果結合と呼ぶ。これらはセクション５で定義する。ＡＬＬＥＯＰは、ＴＩＰ、ＴＩＣＣ−Ｎｅｔｗｏｒｋ、およびポーリングサイクル内の情報を組み合わせる。ＡＬＬＥＯＰがＴＩＰから導出された時に４つの簡単な変換が発生し、（ｉ）「；」は「・→」で置き換えられ、（ｉｉ）信号送信アクション、ＴＩＰに現れているポートｐでのｐ：ｓ（）は以下で説明するようにタイムマップに関連付けられている信号送信と信号配信のイベントに関するそれらの拡張によって置き換えられ、（ｉｉｉ）信号配信に起因する並列起動が指定され、（ｉｖ）各信号検知アクション、ｐ：ｍＲ？（）（またはｐ：ｍＲ？（）＊）はそれによってその引数として検知される信号配信イベントによって与えられる。以下で説明するＡＬＬＥＯＰはこれらの変換を示している。各ポートＡＬＬＥＯＰは２つのコンポーネント：ＡＬＬＥＯＰ−ｇｕａｒｄ（）とＡＬＬＥＯＰ−ｂｏｄｙ（）とを有しており、構造はＡＬＬＥＯＰ−ｇｕａｒｄ（）｛ＡＬＬＥＯＰ−ｂｏｄｙ（）｝であって、ＡＬＬＥＯＰ−ｇｕａｒｄ（）がｔｒｕｅの場合にＡＬＬＥＯＰ−ｂｏｄｙ（）が呼び出され、それ以外はボディがスキップされる。ポートＥ．ｇについてのポートＡＬＬＥＯＰについてまず検討する。これは、Ｅ．ｇ：ＴＩＰＱ（２．３）、図５のＴＩＣＣネットワーク、および（２．７）のポーリングサイクルから導出される。それは（２．１１）に示しており、その解釈はその後に続く。
【０１４７】
Ｅ．ｇ：ＡＬＬＥＯＰ（）＝□［Ｅ．ｇ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｅ．ｇ：ＡＬＬＥＯＰ−ｂｏｄｙ｝］
Ｅ．ｇ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｅ．ｇ：ｐＲ？（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）＊］
Ｅ．ｇ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｅ．ｇＳ［ｔ（Ｅ．ｇ，０）］
→（（〈Ｂｅ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］｜｜→．．．→Ｂｅ．ｆ：ＡＬＬＥＯＰ（））
（〈Ｂｉ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］｜｜→．．．→Ｂｉ．ｆ：ＡＬＬＥＯＰ（）））
・→Ｅ．ｇ：ｍＲ？（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊｛｝
・→Ｅ．ｇ：ＡＬＬＥＯＰ（））｝］ （２．１１）
【０１４８】
ここで、Ｅ．ｇ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）は（２．３）に示されているＥ．ｇ：ＴＩＰ−ｇｕａｒｄ（）と同一である。（２．３）のＴＩＰボディに現れる通信ステートメントＥ．ｇ：ｓ（）は、Ｅ．ｇ：ｓ（）が実行された時に発生する信号送信／配信イベントに変換されており、信号送信イベントはＥ．ｇＳ［ｔ（Ｅ．ｇ，０）］（Ｓは送信を表す）、信号配信イベントは（〈Ｂｅ．ｆＤ〉［ｔ（Ｅ．ｇ，１）と〈Ｂｉ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］（Ｄは配信を表す）である。信号送信と信号配信のイベントに現れている引数ｔ（Ｅ．ｇ，０）とｔ（Ｅ．ｇ，１）はタイムマップである。以下で説明するように、各タイムマップは時間点の増加するシーケンスにマッピングする。（２．１１）の配信イベントの両側に現れる細い線の山括弧「〈．．．〉」はイベントがタイムマップに指定されている時間点で完了していることを指定している。送信イベントＥ．ｇＳの両側にそのような山括弧がないのは、タイムマップで指定されている時間点で開始したことを意味している。したがって、イベントの両側の山括弧の有無がこれらのイベントの開始時間と終了時間とを区別している。
【０１４９】
（２．１１）の２つの信号配信イベント、Ｂｅ．ｆＤとＢｉ．ｆＤは同一のタイムマップｔ（Ｅ．ｇ，１）を有している。これは、信号がｔ（Ｅ．ｇ，１）内の同じ時間点に両方のポート［Ｂｅ．ｆ，Ｂｉ．ｆ］に配信されることを指定している。タイムマップｔ（Ｅ．ｇ，＃）、＃＝０および１、の＃の異なる値は同じポートＥ．ｇに関連付けられている時間点の２つの異なるシーケンスを一意に識別する。ＣＩＰまたはＴＩＰに現れる同じポートでの別個の通信イベントはそれらに関連付けられている＃の別個の値を有している。イベントＥ．ｇＳ、Ｂｅ．ｆＤ、およびＢｉ．ｆＤは全てポートＥ．ｇでのプロトコルの評価に起因している。
【０１５０】
タイムマップに関連付けられている時間点のシーケンスは以下のように解釈される：
シーケンス、ｔ（Ｅ．ｇ，０）＝（ｔ０，ｔ１，．．．，ｔｎ−１）、ｔ０＜ｔ１＜．．．＜ｔｎ−１は信号をＥ．ｇを介してポートグループＢ．ｆ＝［Ｂｅ．ｆ，Ｂｉ．ｆ］に送信することによってＥがゲームのｉ番目、０≦ｉ＜ｎ、の繰り返しを開始した時間点を表し、シーケンス、ｔ（Ｅ．ｇ，１）＝（ｔ０’，ｔ１’，．．．，ｔｎ−１’）、ｔｉ＜ｔｉ’＜．．．＜ｔい＋１はＢ．ｆのポートへの信号の配信が発生する対応する時間点を表す。（０≦ｉ＜ｎ）について、時刻ｔｉで開始した信号送信が時刻ｔｉ’の配信イベントの完了で終了するという意味で、ｔｉはｔｉ’に対応し、２つのシーケンスは完全に順序付けられているチェーン、ｔ０＜ｔ０’＜ｔ１＜ｔ１’＜ｔ２＜ｔ２’．．．＜ｔｎ−１＜ｔｎ−１’に組み合わされる。
【０１５１】
配信イベントが他のＡＬＬＥＯＰの並列起動の原因となる。（２．１１）の配信イベントに現れる記号「｜｜」は信号がＡＬＬＥＯＰ、Ｂｅ．ｆ：ＡＬＬＥＯＰ（）とＢｉ．ｆ：ＡＬＬＥＯＰ（）を並列に起動することを指定している。「｜｜」を伴う省略、→．．．→は信号の配信後に即座に起動が発生しないかもしれないことを示している。ＢｅｎとＢｉｌｌとは、信号配信時に配信された信号を検知する代わりに他のことをしていたかもしれない。しかし、最終的に彼らは信号を検知しそれに応答することになる。
【０１５２】
最終的に、（２．１１）の「Ｅ．ｇ：ｍＲ（）？（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊」に現れる引数「〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］」はＥ．ｇ：ｍＲ？（）＊によって検知される信号配信イベントを識別する。これはポート［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆによってＥ．ｇに返信される信号である。この信号の受信によって、Ｅが信号をＥ．ｇを通して送信することによって開始されたゲームが中止されたことがＥに示される。（２．１１）の同期信号検知動作Ｅ．ｇ：ｍＲ？（）はセルＥがこの中止信号の受信をポートＥ．ｇで待つことを指定している。（２．１１）の検知アクション、Ｅ．ｇ：ｐＲ？（）は任意の引数によって与えられるが、それは、この場合、ポートＥ．ｇの状態が信号の送信の準備ができていることをテストするだけであって、配信された信号をテストしないためである。ｐ：ｐＲ？（）がＴＩＰにおいて配信された信号の検知に使用される場合、引数がそのために提供されることになる。
【０１５３】
ＡＬＬＥＯＰ（２．１１）から（２．１４）のいずれにおいてもＥ．ｇ：ｐＲ？（）に関連付けられている並列起動は存在しない。したがって、（２．１１）のＥ．ｇ：ｐＲ？（）は引数を有していない。しかし、（２．１２）と（２．１３）のＥ．ｇ：ｍＲ（）＊｛｝は並列起動を有しており、したがって引数を有している。システムは並列起動が指定された時にＡＬＬＥＯＰガード内の信号検知動作に引数を提供する。以下で説明する他のＡＬＬＥＯＰはそれらのそれぞれのＴＩＰから同様に導出される。
【０１５４】
／／（２．４）のＢｅ．ｆ：ＴＩＰ（）、図５のネットワーク、およびポーリングサイクル（２．８）から導出。
【０１５５】
Ｂｅ．ｆ：ＡＬＬＥＯＰ（）＝□［Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｂｅ．ｆ：ｍＲ？（〈Ｂｅ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］）］
Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｂｅ．ｆ：ｗｏｒｋ（）・→Ｂｅ．ｇＳ［ｔ（Ｂｅ．ｇ，０）］
→（〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］｜｜Ｍｅ．ｆ：ＡＬＬＥＯＰ（．．．））
・→Ｂｅ．ｇ：ｍＲ？（〈Ｂｅ．ｇＤ〉［ｔ（Ｍｅ．ｆ，１）］）＊｛
Ｂｅ．ｆＳ［ｔ（Ｂｅ．ｆ，０）］｝
→（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］
｜｜Ｅ．ｇ：ｍＲ（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊｛｝）｝
→Ｂｅ．ｆ：ＡＬＬＥＯＰ（）］ （２．１２）
ただし、（２．１２）において、信号送信イベントＢｅ．ｇＳ［ｔ（Ｂｅ．ｇ，０）］内のタイムマップはポートグループＢ＝［Ｂｅ．ｇ，Ｂｉ．ｇ］を参照しないが、信号送信イベント〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］内のタイムマップはＢを参照する。これは、Ｂｅｎが信号をＢｅ．ｇを通して送信した時にＢｉｌｌと調和しないが、エージェントａ２（図５を参照）は配信イベント〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］を発生させる調和信号を送信するからである。同様なタイミング指定はイベントＢｅ．ｆＳ［ｔ（Ｂｅ．ｆ，０）］と〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］に現れている。
【０１５６】
／／（２．５）のＢｅ．ｆ：ＴＩＰ（）、図５のネットワーク、およびポーリングサイクル（２．９）から導出。
【０１５７】
Ｂｉ．ｆ：ＡＬＬＥＯＰ（）＝□［Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｂｉ．ｆ：ｍＲ？（〈Ｂｉ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］）］
Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｂｉ．ｆ：ｐｌａｙ（）・→Ｂｉ．ｇＳ［ｔ（Ｂｉ．ｇ，０）］
→（〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］｜｜Ｍｅ．ｆ：ＡＬＬＥＯＰ（．．．））
・→
Ｂｉ．ｇ：ｍＲ？（Ｂｉ．ｇＤ［ｔ（Ｍｅ．ｆ，１）］）＊｛Ｂｉ．ｆＳ［ｔ（Ｂｅ．ｆ，０）］｝
→（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］
｜｜Ｅ．ｇ：ｍＲ（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊｛｝）｝
→Ｂｉ．ｆ：ＡＬＬＥＯＰ（）］ （２．１３）
【０１５８】
別個のポートＡＬＬＥＯＰに現れる同一のタイムマップはこれらのタイムマップに関連付けられているイベントが異なるＡＬＬＥＯＰにおいて同時に発生することを示している。したがって、ＡＬＬＥＯＰ（２．１２）、（２．１３）および（２．１４）の〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］は同じ配信イベントが３つのＡＬＬＥＯＰにおいて参照されていることを示している。同様に、ＡＬＬＥＯＰ（２．１１）、（２．１２）および（２．１３）の〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］は同じ配信イベントを参照している。ただし、（２．１２）、（２．１３）および（２．１４）の並列起動に続いて省略→．．．→は存在しない。これは、信号受信セルがそれらのそれぞれのポートで信号を待っており、配信された信号を即座に検知するからである。
【０１５９】
／／（２．６）のＢｉ．ｆ：ＴＩＰ（）、図５のネットワーク、およびポーリングサイクル（２．１０）から導出。
【０１６０】
Ｍｅ．ｆ：ＡＬＬＥＯＰ（）＝□［Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｍｅ．ｆ：ｍＲ？（〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］）＊］
Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｍｅ．ｆ：ｍｅｅｔ（）・→Ｍｅ．ｆＳ［ｔ（Ｍｅ．ｆ，０）］
→（（〈Ｂｅ．ｇＤ〉ｔ（Ｍｅ．ｆ，１）］｜｜
Ｂｅ．ｇ：ｍＲ（Ｂｅ．ｇＤ［ｔ（Ｍｅ．ｆ，１）］）＊｛・→．．．・→｝）
→（〈Ｂｉ．ｇＤ〉［ｔ（Ｍｅ．ｆ，１）］｜｜
Ｂｉ．ｇ：ｍＲ（Ｂｉ．ｇＤ［ｔ（Ｍｅ．ｆ，１）｛・→．．．・→｝）＊））
・→Ｍｅ．ｆ：ＡＬＬＥＯＰ（）］ （２．１４）
【０１６１】
ＡＬＬＥＯＰをＴＩＰから導出する規則は単純である。ＡＬＬＥＯＰ構造はＦＳＰ構造と同じように見える。しかし、読者には５〜６個の違いがあることがわかる。ＡＬＬＥＯＰはイベントと因果リンクとを表している。ＦＳＰは状態と遷移とを表している。ＡＬＬＥＯＰとＦＳＰとの間の関係は後で説明する。ただし、アクションＢｅ．ｆ：ｗｏｒｋ（）、Ｂｉ．ｆ：ｐｌａｙ（）およびＭｅ．ｆ：ｍｅｅｔ（）などのＡＬＬＥＯＰで指定されるアクションは、一般にＡＬＬＥＯＰにおいて分岐因果シーケンスを一般に発生させる。２種類の分岐が存在し、一方は選択分岐であって、因果シーケンスの有限の集合から１つの選択肢が因果シーケンスに関連付けられている選択条件を評価し、ｔｒｕｅと評価された第１のものを選択することによって実行（ｒｕｎ）時に実行（ｒｕｎ）のために選択される。選択肢を分離するために記号「｜」を使用する（（４．１４）を参照）。前述のＡＬＬＥＯＰでは選択分岐は発生しない。他方の種類の分岐は、ＡＬＬＥＯＰ（２．１１）と（２．１４）のような通信の結果発生する複数の並列分岐（フォーク）である。
【０１６２】
タイムマップの半順序付け：この例の様々なタイムマップとそれらの半順序付けを次に示す：
ｔ（Ｅ．ｇ，０）、ゲームを開始するために信号がＢｉ．ｆとＢｅ．ｆに送信される＜
ｔ（Ｅ．ｇ，１）、信号がＢｉ．ｆとＢｅ．ｆに配信される＜
（ｔ（Ｂｅ．ｇ，０）、ｔ（Ｂｉ．ｇ，０））、Ｂｉ．ｇとＢｅ．ｇがミーティング開始信号をＭｅ．ｆｂ送信する＜
ｔ（Ｂ．ｇ．１）、ミーティング開始信号がエージェントａ２によってＭｅ．ｆに配信される＜
ｔ（Ｍｅ．ｆ，０）、ミーティング終了信号がＢｉ．ｇとＢｅ．ｇに送信される＜
ｔ（Ｍｅ．ｆ，１）、ミーティング終了信号がＢｉ．ｇとＢｅ．ｇに配信される＜
（ｔ（Ｂｅ．ｆ，０）、ｔ（Ｂｉ．ｆ，０））、Ｂｅ．ｆ、およびＢｉ．ｆがゲーム終了信号をＥ．ｇに送信する＜
ｔ（Ｂ．ｆ，１）］、ゲーム終了信号がエージェントａ１によってＥ．ｇに配信される（２．１５）
タイムマップの比較不能な対：
（ｔ（Ｂｅ．ｇ，０），ｔ（Ｂｉ．ｇ，０））≦ｔ（Ｂ．ｇ，０）、エージェントａ２は調和信号をＭｅ．ｆに送信する
（ｔ（Ｂｅ．ｆ，０），ｔ（Ｂｉ．ｆ，０））≦ｔ（Ｂ．ｆ，０）、エージェントａ１は調和信号をＭｅ．ｇに送信する（２．１６）
（２．１６）の比較不能なタイムマップの対が互いに交差する、つまりｔ（Ｂｅ．ｇ，０）∩ｔ（Ｂｉ．ｇ，０）≠φかつｔ（Ｂｅ．ｆ，０）∩ｔ（Ｂｉ．ｆ，０）≠φであることがあり得る。これは、ＢｅｎとＢｉｌｌとはたまに偶然に同時に信号を送信することがあることを意味する。組み合わされたＡＬＬＥＯＰは以下のようになる。
【０１６３】
ＢＩＬＬ＿ＢＥＮ：ＡＬＬＥＯＰ（）＝
□［∃（〈ｐａｒｔｉａｌ−ｏｒｄｅｒｉｎｇ−ｏｆ−ｔｉｍｅ−ｍａｐｓ〉）
（Ｅ．ｇ：ＡＬＬＥＯＰ（）｜｜Ｂｅ．ｆ：ＡＬＬＥＯＰ（．．．）｜｜Ｂｉ．ｆ：ＡＬＬＥＯＰ（．．．）｜｜Ｍｅ．ｆ：ＡＬＬＥＯＰ（．．．））
・→ＢＩＬＬ＿ＢＥＮ：ＡＬＬＥＯＰ（）］ （２．１７）
ここで、セルの並列動作は（２．１５）と（２．１６）の半順序付けによって拘束される。この拘束はネットワーク構造と信号交換タイミングとによって自動的に課される。スケジューリングは伴わない。これらのＡＬＬＥＯＰを詳細化し、実装を完了するためには、それらが何であれ、ｐｔｈｒｅｄ、Ｍｅ．ｆ：ｍｅｅｔ（）、Ｂｅ．ｆ：ｗｏｒｋ（）、Ｂｉ．ｆ：ｐｌａｙ（）と、条件Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）とを定義しなければならない。（２．１１）から（２．１４）で定義されているポートＡＬＬＥＯＰはアプリケーションによって実行される計算のモデルである。ＴＩＣＣ−Ｐｐｄｅは、実装の完全なＡＬＬＥＯＰモデルを生成するために、ＴＩＣＣネットワークとポーリング仕様とに整合しているポートＡＬＬＥＯＰの逐次／並列組み合わせを生成することができる。ＡＬＬＥＯＰモデルを使用して証明する任意の特性は、実装の有効な特性であって、単に意図した設計の特性ではない。全てのＡＬＬＥＯＰは普遍時間演算子□から始まる。この演算子はＡＬＬＥＯＰの説明では省略する。それは常に存在していると仮定しなければならない。
【０１６４】
２．１．２．ＣＩＰのＡＬＬＥＯＰ
ここで、（２．２）のＣＩＰ用のＡＬＬＥＯＰを書くことにする。ここで、割り込み信号をＥ．ｉに送信するＵｓｅｒ．ｇと呼ばれるポートを仮定している。Ｕｓｅｒは図５には示していない。
【０１６５】
Ｅ：ＣＩＰ−ＡＬＬＥＯＰ（）＝［Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）・→Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ］
Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）＝
［Ｅ：ｉｎｉｔｉａｌｉｚｅ？（）｛ｉｎｉｔ（）・→Ｅ．ｉＳ［ｔ（Ｅ．ｇ，２）］
→（〈Ｕｓｅｒ．ｇＤ〉［ｔ（Ｅ．ｇ，３）｜｜→．．．→Ｕｓｅｒ．ｇ：ＡＬＬＥＯＰ（））
・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ］
Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）＝
［（¬Ｅ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｅ．ｇ：ＡＬＬＥＯＰ（）・→Ｅ．ｉ：ＡＬＬＥＯＰ（）
・→Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
Ｅ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝）］ （２．１８）
ただし、タイムマップｔ（Ｅ．ｇ，２）とｔ（Ｅ．ｇ，３）とは（２．１８）で使用されている。これは、ｔ（Ｅ．ｇ，０）とｔ（Ｅ．ｇ，１）とが既にＥ．ｇ．：ＡＬＬＥＯＰ（）（（２．１１）を参照）で使用されており、Ｅ．ｇ：ＡＬＬＥＯＰ（）が（２．１８）のＥ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）に現れるためである。ここで、Ｅ：ｉｎｉｔｉａｌｉｚｅ？（）＝Ｅ．ｉｎｉｔｉａｌｉｚｅであって、同様に、¬Ｅ：ｓｔｏｐＰｏｌｌｉｎｇ？（）＝¬Ｅ．ｓｔｏｐＰｏｌｌｉｎｇである。オブジェクトの各ブール属性はこの種類の述語を有している。（２．１８）において、セルＥのポートはそれらのＴＩＰボディーが実行される前に並べ替えられない。
【０１６６】
ＴＩＰボディーが実行される前にポートが並べ替えられている（１．１）に示している種類のＣＩＰのＣＩＰ−ＡＬＬＥＯＰを以下の（２．１９）に示している。Ｘ．ｇがＣｅｌｌを起動する割り込み信号を送信し、（１．１）に現れるｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）が２つのコンポーネント、ポーリングと並べ替えに分割されているという以下の仮定が（２．１９）において行われている。（２．１９）のＣｅｌｌ：ｓｏｒｔＩｎｔｏ（．．．）に現れる引数において、Ｃｅｌｌ．ｐｏｒｔｓはＣｅｌｌに付属しているポートのベクトルであって、Ｃｅｌｌ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ（Ｃｅｌｌ．ｓｐＬ）は他のベクトルであって、保留中のメッセージのある並べ替えられているポートを含むことになり、引数ｓｏｒｔＲは並べ替え関係である。全てはＣｅｌｌクラスで定義されている。
Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ（）＝［Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）・→Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ］
Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）＝［Ｃｅｌｌ：ｉｎｉｔ−ＡＬＬＥＯＰ（）・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ
・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→Ｃｅｌｌ．ｉ：ｐＲ？（）｛Ｃｅｌｌ．ｉＳ［ｔ（Ｃｅｌｌ．ｉ，０）］
（〈Ｘ．ｇＤ〉ｔ（ＣｅＩｌ。ｉ，１）］
｜｜→．．．→Ｘ．ｇ：ＡＬＬＥＯＰ（））｝］
Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）＝／／以下では「ｓｐＬ」を「ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ」と読む。
【０１６７】
［（¬Ｃｅｌｌ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｃｅｌｌ．ｉ：ＡＬＬＥＯＰ（）・→Ｃｅｌｌ．ｓｐＬ：ｃｌｅａｒ（）
→ ∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））｛
Ｃｅｌｌ．ｐｏｒｔｓ［ｊ］：ｍＲ？（）｛
Ｃｅｌｌ：ｓｏｒｔＩｎｔｏ（Ｃｅｌｌ．ｐｏｒｔｓ［ｊ］，Ｃｅｌｌ．ｓｐＬ，ｓｏｒｔＲ）｝｝
・→∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（））｛Ｃｅｌｌ．ｓｐＬ［ｊ］：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝
・→Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
Ｃｅｌｌ ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ （）｝）］ （２．１９）
ここで、「∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））」と「∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））」とは指定された範囲のインデックスの列挙子として使用され、それらの、それぞれのスコープ内のアクションは各列挙されたインデックスに適用される。
【０１６８】
２．１．３．トレース
トレースとＡＬＬＥＯＰとの間の違いは以下のとおりである。（ｉ）トレースはイベントと評価が開始および／または終了する仮想的な時間点（以降では単に時間点と呼ぶ）を仮定する。（ｉｉ）トレースは事前条件と事後条件とをそれらが知られた時に〈アクション〉に関連付ける。〈アクション〉、Ａ（）の特徴付けは以下の形式である。
【０１６９】
□［∃（ｔ０＜ｔ１）｛〈ｐｒｅｃｏｎｄｉｔｉｏｎ？（）〉（ｔ０）｝［・→Ａ（）ｔ０）］
｛ｐｏｓｔｃｏｎｄｉｔｉｏｎ？（）（ｔ１）＆（ｔ１＜ｔ０＋τｍａｘ（Ａ）｝］、 （２．２０）
ここで〈アクション〉はｐｔｈｅｄ、プロトコル、プログラムステートメントいずれかであって、τｍａｘ（Ａ）はＡ（）の実行を完了するのにかかる可能性のある最長時間、・→は〈アクション〉実行記号、Ａ（）はｐｒｅｃｏｎｄｉｔｉｏｎ？（）がｔｒｕｅになった時にｔ０で同時に実行を開始し、Ａ（）の実行（ｒｕｎ）は時刻ｔ１に完了し、ｐｏｓｔｃｏｎｄｉｔｉｏｎ？（）はＡ（）の実行が完了した時にｔｒｕｅになる。（ｉｉｉ）トレースは〈アクション〉の事前条件と事後条件において存在する場合は交換されたメッセージの特徴付けも指定する。トレースは、対応するＡＬＬＥＯＰが含んでいる場合には、選択肢と並列フォークとを含んでいる分岐を含んでいてもよい。トレースステートメントで「□」記号を省略しているが、存在していると仮定している。
【０１７０】
システムがポートＡＬＬＥＯＰに対してトレースを導出した時に、システムはポートＡＬＬＥＯＰ内の別個のイベントに対して別個の仮想時間点を単に仮定しており、同一の仮想時間点はポートＡＬＬＥＯＰ内の同一のタイムマップに関連付けられるように対応している。これによって、異なるポートＡＬＬＥＯＰ内で発生するイベントの同期と調和とが反映される。トレース内での時間点の順序付けはポートＡＬＬＥＯＰ内でイベントが発生した順序によって決まる。この順序付けにおいて３つの仮定が行われ：（ｉ）・→でリンクされている連続しているアクションは次々に連続して発生し、リンクの最後のアクションはリンクの最初のアクションが終了するのと同時に始まり、（ｉｉ）各アクションは実行の完了には、既知の上限のある有限の量の非零時間がかかり（ｉｉｉ）セルがポートに信号が配信された時にその信号をそのポートで待っている場合、配信された信号は信号配信時間と同時に即座に検知され、そうでなければ、信号の検知は信号の配信のいくらか後に発生し、（ｉｖ）セルが信号をポートＣ．ｐを通して仮想時間Ｃ．ｐ．ｔに送信した時に、Ｃ．ｐがポートグループｐＧに属している場合、システムはｐＧ内のポートによって送信された信号を受信するエージェントが調和した信号をｐＧ内の全てのポートから信号を受信した後に初めてディスパッチすることを知っている。たとえば、このディスパッチは時間ｐＧ．ｔに発生する。この場合、システムは順序付けをＣｐ．ｔ≦ｐＧ．ｔをトレースに導入する。
【０１７１】
（２．１１）から（２．１４）までのポートＡＬＬＥＯＰのトレースをそれらの解釈と共に以下に示す。Ｂｅｎ−Ｂｉｌｌの解法のトレースには並列フォークが含まれている。（２．１１）のＡＬＬＥＯＰに対応する以下のトレース（２．２１）において、括弧内の表現「（．．．｜｜．．．｜｜．．．）」は並列フォークを記述している。このトレースに現れている〈アクション〉は無い。〈アクション〉、ｐｌａｙ（）、ｗｏｒｋ（）、およびｍｅｅｔ（）はトレース（２．２２）から（２．２４）に現れる。しかし、これらの〈アクション〉はそれらに対して定義されている事前／事後条件を有していない。そのため、トレースには何も現れていない。事前／事後条件とメッセージ条件とが（２．２６）に現れている。
【０１７２】
各トレースにおいて、トレースボディはトレースガードがｔｒｕｅの場合にだけ呼び出され、そうでなければスキップされる。（２．１１）のＡＬＬＥＯＰ、Ｅ．ｇ：ＡＬＬＥＯＰ（）のポートＥ．ｇのトレース、Ｅ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ０）を以下に示す。
【０１７３】
□［Ｂ（Ｅｇ．ｔ０＜Ｅｇ．ｔ１＝Ｂｆ．ｔ０＜Ｅｇ．ｔ２＜Ｅｇ．ｔ３＝Ｂｆ．ｔ１）］
Ｅ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ０）＝
｛・→Ｅ．ｇ：ｔｒａｃｅ−ｇｕａｒｄ（Ｅｇ．ｔ０）｝［・→Ｅ．ｇ：ｔｒａｃｅ−ｂｏｄｙ（Ｅｇ．ｔ１）］
Ｅ．ｇ：ｔｒａｃｅ−ｇｕａｒｄ（Ｅｇ．ｔ０）＝
［〈（Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）（Ｅｇ．ｔ０）〉（Ｅｇ．ｔ１）］
Ｅ．ｇ：ｔｒａｃｅ−ｂｏｄｙ（Ｅｇ．ｔ１）＝
［［・→Ｅ．ｇＳ（Ｅｇ．ｔ１）∈ｔ（Ｅ．ｇ，０））］
（（［〈→Ｂｅ．ｆＤ〉（Ｅｇ．ｔ２∈ｔ（Ｅ．ｇ，１））］｜｜［→Ｂｅ．ｆ：ｔｒａｃｅ（Ｅｇ．ｔ１）］）
（（［〈→Ｂｉ．ｆＤ〉（Ｅｇ．ｔ２∈ｔ（Ｅ．ｇ，１））］｜｜［→Ｂｉ．ｆ：ｔｒａｃｅ（Ｅｇ．ｔ１）］）
｛〈Ｅ．ｇ：ｍＲ（〈Ｅ．ｇＤ〉（Ｅｇ．ｔ３∈ｔ（Ｂ．ｆ，１）））＊〉（Ｅｇ．ｔ３）｝
［・→Ｅ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ３）］］ （２．２１）
【０１７４】
（２．２１）のＥ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ０）における表現「［〈（Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）（Ｅｇ．ｔ０）〉（Ｅｇ．ｔ１）］」は、条件Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）の評価は時間Ｅｇ．ｔ０に始まりＥｇ．ｔ１に終了することをアサーションしている。（２．２１）の同じ時間点Ｅｇ．ｔ２の２つのイベントへの割り当て〈→Ｂｅ．ｆＤ〉と〈→Ｂｉ．ｆＤ〉は、ポートＢｅ．ｆとＢｉ．ｆへの信号の配信が同じ時間点で同時に行われたことを示している。Ｅ．ｇ：ｔｒａｃｅ−ｂｏｄｙ内の指定「［・→Ｅ．ｇＳ（Ｅｇ．ｔ１）∈ｔ（Ｅ．ｇ，０））］」は山括弧なしの「・→Ｅ．ｇＳ」は、イベントＥ．ｇＳを発生させたアクションの評価は時刻Ｅｇ．ｔ１∈ｔ（Ｅ．ｇ，０）に開始されたことをアサーションしている。ただし、「・→Ｅ．ｇＳ」の開始時刻は、「〈（Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）（Ｅｇ．ｔ０）＞（Ｅｇ．ｔ１）」の終了時刻と同じである。「・→Ｅ．ｇＳ」の終了時刻は指定されていない。（２．２１）内の他のステートメントに関連付けられているタイミングの解釈はＡＬＬＥＯＰ内と同じであって、仮想時間点が各場合に仮定されていることが異なる。タイムマップが時間点のシーケンスを表しているように、各仮想時間点も時間点のシーケンスを表している。したがって、（２．２１）において、Ｅｇ．ｔ１∈ｔ（Ｅ．ｇ，０）はＥが（Ｂｉｌｌ｜｜Ｂｅｎ）ゲームを開始した時間点のシーケンスである。Ｂｉｌｌ−Ｂｅｎゲーム内でＡＬＬＥＯＰＳに割り当てられている他のポートトレースを以下に示す。
【０１７５】
Ｂｉ．ｆ：ｔｒａｃｅ（Ｂｉｆ．ｔ０）＝
｛Ｂｉ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｉｆ．ｔ０）｝［・→Ｂｉ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｉｆ．ｔ１）］
［∃（Ｅｇ．ｔ１＝Ｂｉｇ．ｔ０≦Ｂｉｆ．ｔ１＜Ｂｉｇ．ｔ０≦Ｂｇ．ｔ０＜Ｂｇ．ｔ１＝Ｍｅｆ．ｔ０＜
Ｂｉｇ．ｔ１＝Ｍｅｆ．ｔ３＝Ｂｉｇ．ｔ１＜Ｂｉｆ．ｔ２≦Ｂｆ．ｔ０＜Ｂｆ．ｔ１＝Ｅｇ．ｔ３）
Ｂｉ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｉｆ．ｔ０）＝
｛〈Ｂｉ．ｆ：ｍＲ？（〈Ｂｉ．ｆＤ〉（Ｂｉｆ．ｔ０∈ｔ（Ｅ．ｇ，１）））〉（Ｂｉｆ．ｔ１）｝
Ｂｉ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｉｆ．ｔ１）＝
［［・→Ｂｉ．ｆ：ｐｌａｙ（）（Ｂｉｆ．ｔ１）］
［・→Ｂｉ．ｇＳ（Ｂｉｇ．ｔ０∈ｔ（Ｂｉ．ｇ，０）≦Ｂｇ．ｔ０−ｔ（Ｂ．ｇ，０））］
（［〈→Ｍｅ．ｆＤ〉（Ｂｇ．ｔ１∈ｔ（Ｂ．ｇ，１））］｜｜［・→Ｍｅ．ｆ：ｔｒａｃｅ（Ｂｇ．ｔ１）］）
｛〈Ｂｉ．ｇ：ｍＲ？（〈Ｂｉ．ｇＤ〉（Ｂｉｇ．ｔ１∈ｔ（Ｍｅ．ｆ，１）））＊〉（Ｂｉｇ．ｔ１）｝
（［・→Ｂｉ．ｆＳ（Ｂｉｆ．ｔ２≦Ｂｆ．ｔ０∈ｔ（Ｂ．ｆ，０））］
（［〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１∈ｔ（Ｂ．ｆ，１））］
｜｜｛Ｅ．ｇ：ｍＲ（〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１））＊｝［］［・→Ｅ．ｇ：ｔｒａｃｅ（Ｂｆ．ｔ１）］））
［・→Ｂｉ．ｆ：ｔｒａｃｅ（Ｂｆ．ｔ１）］］］ （２．２２）
Ｂｅ．ｆ：ｔｒａｃｅ（Ｂｅｆ．ｔ０）＝
｛Ｂｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｅｆ．ｔ０）｝［・→Ｂｉ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｅｆ．ｔ１）］
［∃（Ｅｇ．ｔ１＝Ｂｅｆ．ｔ０≦Ｂｅｆ．ｔ１＜Ｂｅｇ．ｔ０≦Ｂｇ．ｔ０＜Ｂｇ．ｔ１＝Ｍｅｆ．ｔ０＜
Ｂｅｇ．ｔ１＝Ｍｅｆ．ｔ３＝Ｂｅｇ．ｔ１＜Ｂｅｆ．ｔ２≦Ｂｆ．ｔ０＜Ｂｆ．ｔ１＝Ｅｇ．ｔ３）
Ｂｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｅｆ．ｔ０）＝
｛（Ｂｅ．ｆ：ｍＲ？（〈Ｂｅ．ｆＤ〉（Ｂｅｆ．ｔ０∈ｔ（Ｅ．ｇ，１）））〉（Ｂｅｆ．ｔ１）｝
Ｂｅ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｅｆ．ｔ１）＝
［（［・→Ｂｅ．ｆ：ｗｏｒｋ（）（Ｂｅｆ．ｔ１）］
［・→Ｂｅ．ｇＳ（Ｂｅｇ．ｔ０∈ｔ（Ｂｅ．ｇ，０）≦Ｂｇ．ｔ０∈ｔ（Ｂ．ｇ，０））
（［〈→Ｍｅ．ｆＤ〉（Ｂｇ．ｔ１∈ｔ（Ｂ．ｇ，１））］｜｜［・→Ｍｅ．ｆ：ｔｒａｃｅ（Ｂｇ．ｔ１）］）
｛〈Ｂｅ．ｇ：ｍＲ？（〈Ｂｅ．ｇＤ〉（Ｂｅｇ．ｔ１∈ｔ（Ｍｅ．ｆ，１）））＊〉（Ｂｅｇ．ｔ１）｝
（・→Ｂｅ．ｆＳ（Ｂｅｆ．ｔ２≦Ｂｆ．ｔ０∈ｔ（Ｂ．ｆ，０））］
（［〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１∈ｔ（Ｂ．ｆ，１））］
｜｜｛Ｅ．ｇ：ｍＲ（〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１））＊｝［・→Ｅ．ｇ：ｔｒａｃｅ（Ｂｆ．ｔ１）］））
［・→Ｂｅ．ｆ：ｔｒａｃｅ（Ｂｆ．ｔ１）］］］ （２．２３）
Ｍｅ．ｆ：ｔｒａｃｅ（Ｍｅｆ．ｔ０）＝
｛Ｍｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｍｅｆ．ｔ０）｝［・→Ｍｅ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｍｅｆ．ｔ１）］
［∃（Ｍｅｆ．ｔ０＝Ｂｇ．ｔ３＝Ｍｅｆ．ｔ１＜Ｍｅｆ．ｔ２＜Ｍｅｆ．ｔ３＝Ｂｅｇ．ｔ１＝Ｂｉｇ．ｔ１）
Ｍｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｍｅｆ．ｔ０）＝
｛（Ｍｅ．ｆ：ｍＲ？（）（〈Ｍｅ．ｆＤ〉（Ｍｅｆ．ｔ０∈ｔ（Ｂ．ｇ，１）））＊〉（Ｍｅｆ．ｔ１）｝
Ｍｅ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｍｅｆ．ｔ１）＝
［（［・→Ｍｅ．ｆ：ｍｅｅｔ（）（Ｍｅｆ．ｔ１）］
［・→Ｍｅ．ｆＳ（Ｍｅｆ．ｔ２∈ｔ（Ｍｅ．ｆ，０））］
（（［〈→Ｂｅ．ｇＤ〉（Ｍｅｆ．ｔ３∈ｔ（Ｍｅ．ｆ，１））］
｜｜｛〈Ｂｅ．ｇ：ｍＲ？（〈Ｂｅ．ｇＤ〉（Ｍｅｆ．ｔ３））＊〉（Ｍｅｆ．ｔ３））｝・→．．．・→）
（［〈→Ｂｉ．ｇＤ〉（Ｍｅｆ．ｔ３∈ｔ（Ｍｅ．ｆ，１））］
｜｜｛〈Ｂｉ．ｇ：ｍＲ？（〈Ｂｉ．ｇＤ〉（Ｍｅｆ．ｔ３））＊〉（Ｍｅｆ．ｔ３））｝・→．．．・→）））
［・→Ｍｅ．ｆ：ｔｒａｃｅ（Ｍｅｆ．ｔ３）］］］ （２．２４）
【０１７６】
比較不能な時間点：
（Ｂｉｆ．ｔ１，Ｂｅｆ．ｔ１）（Ｂｉｆ．ｔ２，Ｂｅｆ．ｔ２）（Ｂｅｇ．ｔ０，Ｂｉｇ．ｔ０）（２．２５）
（２．２２）と（２．２３）の第１行の存在宣言は、Ｂｉｆ．ｔ０＝Ｅｇ．ｔ１＜Ｂｉｆ．ｔｉａｎｄＢｅｆ．ｔ０＝Ｅｇ．ｔ１＜Ｂｅｆ．ｔ１が、信号がポートＢｉ．ｆとＢｅ．ｆとに同期して仮想時間Ｅｇ．ｔ１に配信されるが、配信された信号は同期して検知されないことを示すことを指定している。それらは、比較不能な時間点Ｂｉｆ．ｔ１とＢｅｆ．ｔ１とで検知される。同様に、ＢｉｌｌとＢｅｎが信号をそれぞれ仮想時間Ｂｉｆ．ｔ２とＢｅｆ．ｔ２にＥ．ｇに送信した時に、信号を送信する時間を調和させない。しかし，両方の信号がエージェントａ１によって時間Ｂｆ．ｔ０受信された時に、ａ１は調和信号をＥ．ｇにディスパッチする。この信号ディスパッチ時間は常に＞信号送信時間である。したがって、宣言Ｂｉｆ．ｔ２≦Ｂｆ．ｔ０およびＢｅｆ．ｔ２≦Ｂｆ．ｔ０が（２．２２）および（２．２３）に現れる。同様に、（Ｂｅｇ．ｔ０，Ｂｉｇ．ｔ０）≦Ｂｇ．ｔ０もエージェントａ２が時間Ｂｇ．ｔ０において調和させる。ＢｉｌｌとＢｅｎはそれらのポートＢｉ．ｇとＢｅ．ｇとに配信された信号を信号配信の直後に時間Ｂｇ．ｔ１で検知するが、それは両者が信号の配信時に信号を待っているためである。
【０１７７】
読者は、異なるポートトレース内の互いに同一の時間点がタイムマップ内のそれらのメンバーシップによってどのように識別されるかを追跡することができなければならない。そのように識別された仮想時間点の間の同一性が、各トレースの最初の存在宣言に導入されている。等式または不等式の関係によって互いに関連付けられていない異なるセルのポートのトレースに現れる全ての時間点は比較不能な時間点である。
【０１７８】
全てのトレースがいったん生成されると、システムはＡＬＬＥＯＰにおいて指定されているタイムマップ内に現れる仮想時間点とどのタイムマップにも現れない仮想時間点を知る。それから、システムは異なるポートトレース内の同一のタイムマップ内に現れる時間点を互いに等しいと設定する。これによって、すべての調和し、同期した信号の配信が識別される。したがって、（２．２１）のトレースの場合、トレースの最初の時間点の存在宣言は、ポートＥ．ｇがエージェントａ１＝Ｂｆ．ｔ１によってそれに配信された信号を受信する仮想時間点Ｅｇ．ｔ３を宣言しており、それはａ１がその信号を配信した仮想時刻である（図５参照）。これは、ＡＬＬＥＯＰ（２．１１）、（２．１２）、および（２．１３）のタイムマップｔ（Ｂ，ｆ，１）によって指定されているポートＥ．ｇへの調和した信号配信を識別する。同様に、（２．２２）と（２．３３）において、Ｂｅｆ．ｔ０＝Ｅｇ．ｔ１＝Ｂｉｆ．ｔ０である。これはポート［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆへの同期した信号配信を指定している。仮想時間点のこれらの識別は（２．１５）に示している半順序付けに整合している。仮想時間点内の関係を設定した後、システムは配信イベント引数を全ての信号検知動作に、これらのイベントによって起動したトレースに整合するように割り当てる。メッセージの特徴付けとアクションに関連付けられている事前／事後条件とが既知の場合、ＡＬＬＥＯＰのトレースへの変換は複雑ではなく、これらを取得するにはユーザ支援が必要なこともある。
【０１７９】
このアプリケーションのポートトレースは信号検知条件だけを使用する。セクション６．４と付録ＩＩＩにおいて、トレースは様々な条件とアクションに関連付けられている事前／事後条件のある分岐アクションとを含んでいる。各トレースは、証明生成については通常のトレース内の情報の表形式への単なる再構成であるイベント特徴付け表（ＥＣＴ）を生成する。セクション６に例を示す。
【０１８０】
２．１．４．ＣＩＰのトレース
∀列挙子のあるステートメントがどのように取り扱われるかを示すために、ＣＩＰ−ＡＬＬＥＯＰ（２．１９）のトレースの部分を以下の（２．２６）に示している。（２．６）に現れる句（ｐ［ｉ］⇔ｑ［ｉ］）は、ポート［ｉ］とポートｑ［ｉ］との間に経路が存在していることをアサーションしている。インデックスまたは項目は、∀列挙子によって順番に列挙される。以下では、インデックスｉ、０≦ｉ＜ｎ−１の列挙は、インデックスｉ＋１の列挙の前であると仮定する。（２．１９）に現れる列挙子のあるＡＬＬＥＯＰステートメントを以下に便宜上再掲載している（ｓｐＬをｓｏｒｔｅｄＰｏｒｔｓＬｉｔｓと読み替える）。
・→Ｃｅｌｌ．ｓｐＬ：ｃｌｅａｒ（）
・→∀（ｉ）（０≦ｉ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））｛
Ｃｅｌｌ．ｐｏｒｔｓ［ｉ］：ｍＲ？（）｛Ｃｅｌｌ：ｓｏｒｔＩｎｔｏ（Ｃｅｌｌ．ｐｏｒｔｓ［ｉ］，Ｃｅｌｌ．ｓｐＬ，ｓｏｒｔＲ）｝｝
・→∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（））｛ｓｐＬ［ｊ］：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝ （２．１９ａ）
前述の列挙子ステートメントのトレースを以下に示す。
【０１８１】
［∀（ｉ）（（０≦ｉ ＜（Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（）−１）
（∃（Ｃｐ［ｉ］．ｔｉ＜Ｃｐ［ｉ］．ｔｉ＋１＝Ｃｐ［ｉ＋ｌ］ｔｉ＋１）
∃（ｑ［ｉ］．ｔ０＜Ｃｐ［ｉ］．ｔｉ＜ｑ［ｉ＋１］．ｔ０））／／トレースで使用される仮想時間点の宣言
∀（ｉ）（０≦ｉ＜（Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（）−１）
∃（ｓＰＬ［ｉ］．ｔｊ＜ｓＰＬ［ｉ］．ｔｊ＋１＝ｓＰＬ［ｉ＋１］ｔｉ＋１））／／仮想時間点の宣言
［∀（ｋ）（０≦ｋ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））／／ここで∀（ｋ）は以下のアクションの列挙子
∃（Ｐｏｒｔｓ ｐ［ｋ］，ｑ［ｋ］）（ｐ［ｋ］＝Ｃｅｌｌ．ｐｏｒｔｓ［ｋ］＆（ｐ［ｋ］⇔ｑ［ｋ］））
／／以下では、信号が時刻ｑ［ｋ］．ｔ０に配信され、検知が時刻Ｃｐ［ｋ］．ｔｋで完了する。
【０１８２】
｛〈ｐ［ｋ］：ｍＲ？（〈ｐ［ｋ］Ｄ〉（ｑ［ｋ］．ｔ０））〉（Ｃｐ［ｋ］．ｔｋ）｝
／＊以下の並べ替えアクションは信号検知か完了した時刻、つまりＣｐ［ｋ］．ｔｋで完了し、Ｃｐ［ｋ］．ｔｋ１で終了する：ｓｏｒｔＲは並べ替え関係である。＊／
［〈・→Ｃｅｌｌ：ｓｏｒｔｌｎｔｏ（ｐ［ｋ］，ｓｐＬ，ｓｏｒｔＲ）（Ｃｐ［ｋ］．ｔｋ）〉（Ｃｐ［ｋ］．ｔｋ＋１）］
｛（（ｋ＝０）＆ｓｐＬ［０］＝ｐ［０］）∨
（ｋ＞０＆ｓｐＬ［０］＝ｐ［ｋ］＆（ｐ［ｋ］ｓｏｒｔＲ ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［１］））∨
（ｋ＞０＆∃（ｊ＞０）（ｓｐＬ［ｊ］＝ｐ［ｋ］＆（ｓｐＬ［ｊ−ｌ］ｓｏｒｔＲ ｐ［ｋ］））｝］
／／ｓｐＬ［ｊ］：ｔｒａｃｅ−ｂｏｄｙ（）は時刻ｓＰＬ［ｊ］．ｔｊで始まり、時刻ｓＰＬ［ｊ］．ｔｊ＋１で終わる
［｛∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（））／／ここでも∀（ｊ）が列挙子として使用されている
［〈・→ｓｐＬ［ｊ］：ｔｒａｃｅ−ｂｏｄｙ（）（ｓＰＬ［ｊ］．ｔｊ）〉（ｓＰＬ［ｊ］．ｔｊ＋１）］］］ （２．２６）
【０１８３】
（２．２６）で注意すべき特徴は以下のとおりである。（ｉ）信号はポートｐ［ｋ］に時刻ｑ［ｋ］．ｔ０に配信され、配信された信号は時刻Ｃｐ［ｋ］．ｔｋに検知される。インデックスｋについての並べ替えアクション、Ｃｅｌｌ：ｓｏｒｔｌｎｔｏ（．．．）は即座に同じ時刻、Ｃｐ［ｋ］．ｔｋに始まる。インデックスｋについてのこの並べ替えアクションはインデックス（ｋ＋１）についての並べ替えが始まるＣｐ［ｋ］．ｔｋ＋１に終了する。これは最初のタイミング指定で宣言されており、宣言がＣｐ［ｋ］．ｔｋ＋１＝Ｃｐ［ｋ＋１］．ｔｋ＋１が現れている。同様なタイミング構造が他の列挙ステートメントについても現れている。（ｉｉ）事前／事後条件が［〈・→Ｃｅｌｌ：ｓｏｒｔｌｎｔｏ（ｐ［ｋ］，ｓｐＬ，ｓｏｒｔＲ）（Ｃｐ［ｋ］．ｔｋ）〉（Ｃｐ［ｋ］．ｔｋ＋１）］アクションに対して示されている。ＣＩＰ−ＡＬＬＥＯＰ（２．１９）についての前述のトレースを使用したトレースの生成は非常に単純である。
【０１８４】
２．１．５ＡＬＬＥＯＰと因果律網のグラフィック表現
このアプリケーション用のＡＬＬＥＯＰのグラフィック表現を図６Ａに示している。これは、（２．１１）から（２．１４）に記載のポートＡＬＬＥＯＰの直列並列構成を表している。図６ＡのＡＬＬＥＯＰグラフに現れるノードはイベントクラスと呼ばれるが、それはアプリケーションが繰り返して実行（ｒｕｎ）される時に各ノードの多くのインスタンスが現れることがあるためである。ノードの対の間の有向リンクはノード間の因果関係を表している。図６Ａのリンクのラベルはこれらのリンクが発生するためにはｔｒｕｅでなければならない条件を表している。ここでは信号検知条件だけが現れている。
【０１８５】
図６ＡのＡＬＬＥＯＰグラフについてのゲームの１回の実行（ｒｕｎ）においてＳＭＳによって生成される因果律網を図６Ｂに示している。図６Ｂの各ノードは、対応しているＡＬＬＥＯＰノードのインスタンスである。ＡＬＬＥＯＰは遊び、仕事、および会議のアクションイベントを示しており、因果律網はＡＬＬＥＯＰとトレースに現れる通信イベントクラスのインスタンスである通信イベントだけを示している。トレースで仮定されている仮想時間点の代わりに因果律網イベントに関連付けられている時間インスタンスはアプリケーションに関連付けられているグローバルクロック内の時間点である。それはアプリケーションの実行（ｒｕｎ）中にイベントが発生した時刻である。図６Ｃはゲームが５〜６回繰り返される時の因果律網を示している。因果律網は図６Ａに示している時刻の順序を保存しているが、図６Ａのループのリンクが図６Ｃに示しているように、反復に置き換えられている。タイムマップのように、トレース内の仮想時間点も関連付けられている時間インスタンスのシーケンスを有していることは明かである。
【０１８６】
因果律網に現れるイベントノードの集合は単にアプリケーションの実行（ｒｕｎ）中に発生し、アプリケーションのトレースに現れる全ての通信イベントとそれらのそれぞれの発生時刻との集合である。トレースが選択点を含んでいる場合、トレースに現れる全てのイベントが因果律網に対応するイベントを有しているわけではなく、選択点で選択されたイベントだけが因果律網内に対応するイベントを有することになる。トレースに現れる全ての事前／事後条件、イベントの検知、およびアクションイベントは無視される。したがって、因果律網はアプリケーションの実行（ｒｕｎ）時に発生する通信イベントに対応しているトレースの一部の抽象化である。同期している入力信号を受信するノードはそれらに関連付けられている同一のグローバル時間インスタンスを有している。同様に、調和した出力信号をエージェントを通してディスパッチするノードもそれらに関連付けられている同一のグローバルディスパッチ時間インスタンスを有している。トレースのイベントクラスに関連付けられている各別個の仮想時間点は、そのトレースから生成された因果律網内のそのイベントクラスのインスタンスに関連付けられている時間インスタンスの別個のシーケンスに対応している。したがって、句Ｅ．ｇｓ（Ｅｇ．ｔ１∈ｔ（Ｅ．ｇ，０））に現れる仮想時間点Ｅｇ．ｔ１は図６Ｃに示している時間点のシーケンスｔ（Ｅ．ｇ，０）＝ｔ０，ｔ７，ｔ１５，．．．ｔ８ｎ＋７，．．．，を表している。
【０１８７】
0005704459.tif 000007
【０１８８】
図６：｜｜ＢＩＬＬ＿ＢＥＮ解法のＡＬＬＥＯＰと因果律網
ノードは、図６Ｂと６Ｃに示しているように因果律網において有向リンクによって互いにリンクされている。リンクはノードの半順序を指定している。２種類のリンクが存在し、それらは（ｉ）ＴＩＰの実行中に発生するイベントの順序を指定する因果リンク、（ｉｉ）アプリケーションの実行（ｒｕｎ）中にセルにおいて発生する異なるＴＩＰ実行（ｒｕｎ）の順序を指定する実行リンクである。因果律網内のイベントインスタンスの半順序付けは、これらの２種類のリンクによってもたらされた半順序付けの和集合である。図６Ｃにおいて、ゲームの連続している反復の間のリンクは実行リンクである。それ以外の全てのリンクは因果リンクである。この場合、各セルは１つのＴＩＰだけを有しているが、それは割り込みポートの動作を無視しているからである。セルが複数の一般ポートと機能ポートを有している場合、より多くの実行リンクが因果律網内に現れることになる。
【０１８９】
因果リンクＸ→ＹまたはＹ・→ＹがポートＡＬＬＥＯＰ内で発生し、イベントインスタンスＸ（ｔ）またはＸが因果律網内で発生した場合、ＹのイベントインスタンスＹ（ｔ＋τ）は特定の遅延τ＞０の後に因果律網内でかならず発生する。因果リンクＸＣ（Ｘ，Ｙ）→ＹまたはＸＣ（Ｘ，Ｙ）・→ＹがポートＡＬＬＥＯＰのグラフまたはポートＡＬＬＥＯＰの文字による記述内の句Ｃ（Ｘ，Ｙ）？（）｛Ｘ→Ｙ｝またはＣ（Ｘ，Ｙ）？（）｛Ｘ・→Ｙ｝内で発生する場合、ＹのイベントインスタンスＹ（ｔ＋τ）は条件Ｃ（Ｘ，Ｙ）が時刻（ｔ＋τ）でｔｒｕｅの場合にだけ特定の遅延τ＞０後に因果律網内でかならず発生する。これは、セクション５．５で説明したように、（ｉ）セルによって実行される任意のｐｔｈｒｅａｄとプロトコルは割り込み不可能であって、（ｉｉ）ｐｔｈｒｅａｄとプロトコルの起動は自動的（セルの外部のプログラムによってスケジュールされていない）であって、（ｉｉｉ）システム障害、デッドロック、またはライブロック（システムの一部がデッドロックしている）がない限りプログレスが保証されているためである。一般的な場合、デッドロックとライブロックが無いことを証明しなければならない。
【０１９０】
自己監視システム、ＳＭＳはアプリケーションの因果律網がそのＡＬＬＥＯＰから逸脱した時にはアラートを発生するように設定されていてもよい。また、ＡＬＬＥＯＰノードの正規表現としてイベントパターンを定義することによってアラート状態を指定してもよい。したがって、イベントＹがＸ→ＹとＸ・→Ｙ内の指定された上限τ後に発生しない場合、ＳＭＳはエラーアラートを発行することになる。遅延の指定された上限後にイベントＹが発生した場合、ＳＭＳは切迫したエラーアラートを発行することになる。通常の動作条件下では、図６ＡのＡＬＬＥＯＰ内の各イベントはその事前条件と事後条件とが満たされ、最下部のノードに対応しているイベントがいったん発生した場合かならず発生し、そうでない場合、アラートが発生する。
【０１９１】
セクション７で説明したように、因果律網内のイベントは、アプリケーションが実行（ｒｕｎ）中でイベントがアプリケーション内で発生している時に、アプリケーションの動作と並行してイベントビルダーセル（ｅｂセル）と呼ばれる特定のセルによって動的にインストールされる。拡大している因果律網内のイベントパターンはイベント分析セル（ｅａセル）によって分析される。事前に指定されたアラート条件が拡大している因果律網内で発生した場合、そのパターンに関連付けられているｅａセルはアラートを生成することになる。ＳＭＳ構造はＡＬＬＥＯＰで指定されているプログレスからのどのような逸脱も検知してアラートを発行するように設定されていてもよい。ＳＭＳは、ｅａセルの選択された一般ポートとアプリケーション内の適切なセルの割り込みポートとの間の経路を設定し、これらのポートに対してＴＩＰを定義することによって、拡大している因果律網内で動的に認識されたパターンに基づいてアプリケーション内の進行中の計算に影響するように設定されていてもよい。
【０１９２】
２．１．６．コメント
ＴＩＰ実行における非決定論：別個のセル内のＴＩＰ実行（ｒｕｎ）は互いに同期していない。信号配信イベントにも同期していない。ポートのＴＩＰはポートの親セルがポートをポーリングした時にそのポートに配信信号が存在する場合にだけ実行され、それ以外はポートはスキップされる。セルの異なるポートに信号が到着する順序を予測することはできない。したがって、セルがそのポートでＴＩＰを実行する順序は予測できない。そのため、セルがそのポートの１つに配信される信号をいつ検知してそれに応答するかを予測できない。１つのポーリングサイクルにおいてポートで検知し損なった信号は次のポーリングサイクルでかならず検出されるので、信号がポートに配信された後、セルが信号に応答する限界を設定することが可能で、ΔＣmaxがセルＣのポーリングサイクルにおいて保留中のメッセージのある全てのポートをサービスするのに必要な最長時間である場合、この限界は＜２ΔＣmaxである。これが、ＴＩＣＣ−Ｎｅｔｗｏｒｋｓに固有の非決定論の原因である。
【０１９３】
ＣＰＵの共有：図５に示しているネットワークは少なくとも３つのＣＰＵが実行（ｒｕｎ）に必要である。信号をＢｉｌｌとＢｅｎに送信した後、環境Ｅはその動作をサスペンドして、そのＣＰＵを解放してもよい。Ｍｅｅｔｉｎｇが信号をＢｉｌｌとＢｅｎから受信した時に、使用可能な使用されていないＣＰＵ内で自動的に起動し、後でＥが信号をＢｉｌｌとＢｅｎとから受信した時に、同様にサスペンドしていた動作を任意の使用可能な使用されていないＣＰＵ内でレジュームしてもよい。一般に、ネットワークを実行（ｒｕｎ）するのにＣＰＵの数は少なくとも１プラス並列に実行（ｒｕｎ）されるセルの最大数である。セルがその動作をサスペンド／レジュームするようにプログラムされている場合、ＣＰＵは断続的に実行（ｒｕｎ）されるセルの間で切り替えられる。
【０１９４】
プログレス：図６のダイアグラムにおいて、ｐｔｈｒｅａｄ、ｐｌａｙ、ｗｏｒｋ、およびｍｅｅｔは無条件で常に中止されると仮定されているという暗示的な仮定がある。この仮定の下で、アプリケーションにはデッドロックやライブロックが無く、ミーティング同期がゲームの各繰り返しで発生する。セクション６で正式な証明メソッドを導入する。食事をする哲学者の例における状況を考え、実装にデッドロックとライブロックが無いことを保証するために予防策が講じられており、計算の詳細化構造がこの保証の証明可能性において役割を果たす。
【０１９５】
ＡＬＬＥＯＰとＦＳＰ：前述のように、ＡＬＬＥＯＰのノードとＴＩＰのトレースとはイベントクラスであって、ＡＬＬＥＯＰ内のループが取り除かれた場合にリンクが半順序付けを指定する。ただし、図６Ａでループしているリンクが取り除かれた場合、ＡＬＬＥＯＰは格子になる。これは特別な場合である。前述のように、ＡＬＬＥＯＰは状態と遷移を表さない。しかし、ＡＬＬＥＯＰによってモデル化されたアプリケーションの状態図の状態の数が有限の場合、ＡＬＬＥＯＰはある意味でＦＳＰと同等でなければならない。そのようなＡＬＬＥＯＰを有限ＡＬＬＥＯＰと呼ぶ。有限ＡＬＬＥＯＰ内の全ての可能性のあるチェーンの集合は正規集合である。
【０１９６】
有限ＡＬＬＥＯＰの抽象化と見なされるＦＳＰ：ＡＬＬＥＯＰ（２．１１）から（２．１４）において、セルとセル内で実行されるｐｌａｙ（）、ｗｏｒｋ（）、およびｍｅｅｔ（）にだけ注目し、信号交換イベントと信号検知動作とを無視したとする。すると、ＡＬＬＥＯＰ（２．１１）から（２．１４）からは、実装の以下のＦＳＰの記述が得られる。
【０１９７】
Ｅ＝［（ｒｅａｄｙＴｏＳｔａｒｔ→［ＢＩＬＬ｜｜ＢＥＮ］）｜（ｉｎｔｅｒｒｕｐｔ→ＳＴＯＰ）］；
ＢＩＬＬ＝ｐｌａｙ→ｍｅｅｔ→ＢＩＬ、ＢＥＮ＝ｗｏｒｋ→ｍｅｅｔ→ＢＥＮ （２．１）
Ｅは割り込み後に停止する。これは、ＡＬＬＥＯＰには示されていないが、ＣＩＰに指定されている。それをここであえて含めている。ＦＳＰの慣例により、ＦＳＰ同期はｍｅｅｔとＥで発生する。これはＴＩＣＣでは調和と呼ばれる。ＦＳＰはＴＩＣＣパラダイムで使用される場合、同期と調和を区別しない。また、アクションがそれらの同期特性に基づいて名前が変更されていない限り、ＦＳＰは別個のアクション（つまり異なる名前のアクション）の時間同期を指定する単純な枠組みを有していない。
【０１９８】
セルは複数の機能ポート、一般ポート、および割り込みポートを含んでおり、アクションが条件付きの場合、メッセージが交換され、ＴＩＰは複雑になる（セクション４で説明したように）。ＡＬＬＥＯＰに対応するＦＳＰの記述も複雑になることになる。しかしながら、固定された有限の数のポートを備えている任意のアプリケーションＡＬＬＥＯＰはその同等のＦＳＰ指定を含むように抽象的化することができる。したがって、各アプリケーションの固定された有限の数のポートを備えているＡＬＬＥＯＰは有限ＡＬＬＥＯＰである。
【０１９９】
ＦＳＰの対応する有限ＡＬＬＥＯＰへの逆変換と実装とは困難であるが、それは（ｉ）ＦＳＰは同期と調和との区別を行わない、(ii)状態の間の通信リンクを識別する、または（ｉｉｉ）トランザクションの概念を導入するためである。たとえば、（２．２７）のＦＳＰはｍｅｅｔの後にＥがＢｉｌｌとＢｅｎを通した同期して調和した通信によってゲームの終了を通知されることを指定しない。ここでは、ＦＳＰには現れない隠れた状態（ポートとエージェントの状態）が存在する。これは、ＦＳＰにはポート、エ―ジェント、トランザクション、経路、およびプロトコルの概念が無いために発生する。ＡＬＬＥＯＰのＦＳＰへの抽象化とＦＳＰのＡＬＬＥＯＰへの詳細化についてさらにコメントするためにこれらを十分には調べていない。この説明において示唆したＡＬＬＥＯＰとＦＳＰとの間の関係は重要であり、さらに追求しなければならない。
【０２００】
有限ＡＬＬＥＯＰの構造にだけ依存している全ての証明はＦＳＰ証明の簡潔さを有することになる。ユーザは証明すべきＣＴＬアサーションを定義し、また証明探索を導くアサーションを提供してもよい。システムはユーザによって提供された各アサーションが所与の実装についてそれを受け入れる前に有効であることを検証する。
【０２０１】
ＮＦＳＰ証明：計算で使用される変数の値に依存しているＡＬＬＥＯＰ証明にはＮＦＳＰ（非ＦＳＰ）証明方法が必要なことがある。そのようなＮＦＳＰ証明にはＡＬＬＥＯＰの構造上での帰納的推論が必要なことがある。セクション６でＦＳＰとＮＦＳＰの証明の単純な例を説明する。計算中にネットワークが動的に拡張するアプリケーションについては、そのＡＬＬＥＯＰは、潜在的に無限の数のＡＬＬＥＯＰノードを備えている文脈依存で一般的な再帰構造を含んでいるＮＦＳＰ ＡＬＬＥＯＰのことがある。例をセクション６．７に示している。
【０２０２】
次の例は［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］に記載されている「話すことと痒がること」の拡大版である。ここでは、非決定的ガード、並行性、カプセル化、隠蔽、および調和の使用を説明することを目的としている。
【０２０３】
２．２．話すことと痒がること：カプセル化、並行性、および調和
ある人が同時に話して痒がる。［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］においては、１人だけが存在し、その人がタイムスライスされた並行性において、話し痒がる。２人が存在するこの例の一般化版を考え、かれらの間で会話が行われ、各々が話しながら断続的に掻く。このスキームは３人以上に一般化することができる。秩序のある会話は２人以上が同時にしゃべらない時に維持される。この例は、図４に紹介されている仮想メモリを備えているＤａｓ経路を使用する。
【０２０４】
0005704459.tif 000008
【０２０５】
図７：２人が話し痒がる例
ネットワークを図７に示している。Ｐ０とＰ１は２人の人である。各人Ｐｊ、ｊ＝０，１は合成セルであって、１つの会話セルＣｊと１つの痒がるセルＩｊとを含んでいる。これら２つのセルは各人内の別個のＣＰＵ内で並列に実行（ｒｕｎ）される。各合成セルは隠された内部接続を有しており、外部ポートへの接続を有しているものもある。まず、２つのカプセル化されているセルに対して内部と外部の接続とそれらが対応しているネットワークアクティビティを考える。
【０２０６】
外部接続：ｊ＝０，１について、経路［Ｃｊ．ｆ０，Ｐｊ．ｆ０，ａ１，ａ０，Ｅ．ｇ１］が存在する（図７を参照）。ここで、ポート[Ｐ０．ｆ０，Ｐ１．ｆ０]はポートグループを構成し、ａ１は同期信号を[Ｐ０．ｆ０，Ｐ１．ｆ０]に配信し、Ｅ．ｇ１にａ０を通して[Ｐ０．ｆ０，Ｐ１．ｆ０]からの調和信号を配信する。同様に、Ｅ．ｇ０はエージェントを通してポートグループ［Ｐ０．ｉ，Ｐ１．ｉ］の割り込みポートに接続されており、今度はポートグループ［Ｐ０．ｉ，Ｐ１．ｉ］は（Ｃ０．ｉ，Ｃ１．ｉ）にそれぞれ接続されている。Ｅはこの経路を使用してセルＣｊ、ｊ＝０，１を起動する。経路［Ｃｊ．ｆ２，Ｐｊ．ｆ２，Ｐｉ，ｇ２，Ｃｉ，ｇ２］、ｉ，ｊ＝０．１、ｉ≠ｊが存在し、Ｃｊ．ｆ２とＣｉ．ｇ２との間の通信を可能にしている。同様に経路［Ｃｊ．ｆ３，Ｐｊ．ｆ３，Ｐｉ．ｇ３，Ｃｉ．ｇ３］はＣｊ．ｆ３とＣｉ．ｇ３との間の通信を可能にしている。
【０２０７】
内部接続：Ｐｊ．ｇはポート、Ｉｊ．ｉへの内部接続を有している。Ｐｊが起動すると、この接続を使用してＩｊを起動する。他の内部接続はＰｊ．ｇＯ⇔Ｉｊ．ｆ０とＰｊ．ｇ１⇔Ｉｊ．ｆ１である。ＣｊとＩｊとはこれらの２つの接続を使用してそれらの動作を調和させる。
【０２０８】
隠蔽：カプセル化されているセルの外部ポートにリンクされているポートとエージェントだけが外界からアクセス可能である。カプセル化に対して内部の経路は外界から隠されており、これを隠蔽と呼ぶ。
【０２０９】
ネットワークアクティビティ：環境Ｅは、割り込み信号をポートグループ［Ｐ０．ｉ，Ｐ１．ｉ］のポートにブロードキャストすることによって、会話セルＣｊ、ｊ＝０、１を起動する。いったん起動すると、セルは初期化し、割り込み信号の受信に肯定応答し、それからそれらのポートのポーリングを開始する。初期化中に、各セルＣｊは割り込み信号をＣｊ．ｇを通してＩｊ．ｉに送信することによって痒がるセルＩｊを起動する（図７を参照）。これによって、両方の痒がるセルは自身のそれぞれの初期化を実施後にポーリングを開始する。会話セルの起動後に、Ｅは無作為に選択された２ビット信号［ｂ０，ｂ１］をポートグループ［Ｐ０．ｆ０，Ｐ１．ｆ０］のポートにブロードキャストする。これらのビットに対する制限は両方が０や１にならないことである。エージェントａ１（図７を参照）はビットｂ０＝１（ｂ１＝１）の場合にだけ配信信号をＰ０．ｆ０（Ｐ１．ｆ０）に送信し、それ以外の場合は送信しない。
【０２１０】
１人がポートＰｊ．ｆ０で信号を受信すると、信号はＣｊ．ｆ０に進む。Ｃｊがこの信号を検知すると、話し始める。ｂ０とｂ１は両方が１になることはないので、２人は同時に話し始めることはできない。１人が話している時に、他方の人のセルはそのポートをポーリングし、おそらく話を聞く。話し始める前に、Ｃｊは信号をＩｊ．ｆ０にＣｊ．ｇ０を通して送信する（図７を参照）。Ｉｊがこの信号を検知すると、断続的に掻き始め、Ｃｊが話している間は、ブール変数Ｉｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅの両方がｔｒｕｅであるかどうかに基づいて断続的に掻き続ける。Ｉｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅの真理値は、無作為に真理値Ｉｊ．ｒａｎｄｏｍ（）によって各掻くサイクルで設定される。したがって、人は話すセッションを通して常に掻いていないかもしれない。ここでは、掻くことは常に話す間隔よりもはるかに短い間隔でだけ行われるという仮定がある。掻くセルと会話するセルとは並列に動作するので、人が話し始める時間点と掻き始める時間点とは互いに同期していないが、それらによって実施されるアクションは並列に発生する。ここでは非同期状態は、２ギガヘルツのＣＰＵでは数百ナノ秒よりも長くはない。
【０２１１】
話した後で、Ｃｊは初めて信号を経路Ｃｊ．ｇ１⇔Ｉｊ．ｆ１を通して送信する。これによって、Ｉｊが掻くことをやめるように通知する。それからＣｊは２つのことの一方を行い、それは（ｉ）Ｃｉ．ｆ２、ｉ≠ｊに経路［Ｃｊ．ｇ２，Ｐｊ．ｇ２，Ｐｉ．ｆ２，Ｃｉ．ｆ２］（図７を参照）内のポートを通して信号を送信してＰｉに会話を継続するために話し始めるようにアドバイスするか、（ｉｉ）Ｃｉ．ｆ３、経路［Ｃｊ．ｇ３，Ｐｊ．ｇ３，Ｐｉ．ｆ３，Ｃｉ．ｆ３］内のポートを通して信号を送信して会話を中止させるかの一方である。これらの排他的な信号が２つの機能ポート、Ｃｉ．ｆ２とＣｉ．ｆ３とで会話を継続または中止するために使用される方法を以下で説明する。
【０２１２】
以下のＴＩＰの１つが（∃（ｆ）（ｆ＝（Ｃｉ．ｆ２｜Ｃｉ．ｆ３））ｆ：ｍＲ？（））の形態の非決定的ガードを使用する。記号「｜」は選択肢を指定する。ここで、各セルＣｉはこのガードをそのポーリングサイクル毎に評価する。ガードはガードで指定されている選択肢の中のポートの１つがそれに対して配信された信号を有している時にだけｔｒｕｅと評価される。ガードのポートに配信される信号は非決定的ガードが正常に動作するように排他的でなければならない。信号がＣｉ．ｆ２で検知された場合、会話は継続し、信号がＣｉ．ｆ３で検知された場合、会話は中止される。会話が中止された場合、信号は、ポートがその信号の送信の準備ができている場合に、Ｃｉ．ｆ０をとしてＥ．ｇ１に返信される。Ｃｉ．ｆ０は、以前に信号をエージェントａ１を通してＥ．ｇ１から受信している場合にだけ、その信号の送信の準備ができている（図７を参照）。したがって、Ｅからの信号を受信したセルだけがそれに応答する。調和がここで発生するが、それはこの点で、エージェントａ１が信号を以前に信号を配信したポートから受信すると予測しているからである。ａ１がこの信号をＥ．ｇ１に配信すると、Ｅに会話が中止されたことを通知することになる。その点で、Ｅは、第２の割り込み信号を割り込みポート、Ｃｊ．ｉ、ｊ＝０，１に送信することによって、他の会話セッションを開始したり、ゲームを中止したりすることができる。Ｃｊは自身を停止する前に割り込み信号をＩｊ．ｉに送信することによって（図７を参照）Ｉｊを中止する。開始と中止のプロセスは以下のＴＩＰには示していない。
【０２１３】
各人のＣｅｌｌは以下のポーリングサイクルを有している。
Ｃｊ：ｐｏｌｌｉｎｇ（）＝［Ｃｊ．ｆ０：ｍＲ？（）→（∃（ｆ）（ｆ＝（Ｃｊ．ｆ２｜Ｃｊ．ｆ３））ｆ：ｍＲ？（）
→Ｃｊ：ｐｏｌｌｉｎｇ（）］
Ｉｊ：ｐｏｌｌｉｎｇ（）＝［Ｉｊ．ｆ０：ｍＲ？（）→Ｉｊ：ｐｏｌｌｉｎｇ（）］
【０２１４】
Ｃｊが会話を開始し、会話を継続するために信号をＣｉに送信したと仮定する。この信号の送信後、Ｃｊは前述のポーリングサイクルのようにそのポーリングを開始し、おそらくは同時に他の人の話を聞く（聞くプロセスはこの実装には含まれていない）。Ｃｊは会話が継続している間に複数のポーリングサイクルを経ることもある。これによって、Ｃｊ．ｆ０で受信された信号が繰り返し検知される。会話が継続する限り応答は送信されないため、図１に示しているように、Ｃｊ．ｆ０での信号の検知は検知のたびに成功する。したがって、Ｃｉが話しをしている間、Ｃｊも話しを始めようとする。これを防止するために、Ｃｊ．ｆ０で配布信号を検知した後は即座にＣｊはＣｊ．ｆ０．ｉｎｐｕｔ＝φと設定する。これによって、Ｃｊ．ｆ０での信号が繰り返し検知されることが防止される。ステートメントＣｊ．ｆ０：ｓｕｓｐｅｎｄ（）を使用して防止する。サスペンドはポートの状態を変化させないため、適切な場合には、応答はサスペンドされたポートを依然として通して送信されることになるかもしれない。
【０２１５】
この前提と以下のコメントによって、読者は以下で説明するＴＩＰを理解できるはずである。
【０２１６】
人Ｐｊ，ｊ＝０，１についての話す部分についてのＴＩＰ。
Ｃｊ．ｆ０：ｍＲ？（）｛Ｃｊ．ｆ０：ｓｕｓｐｅｎｄ（）；／／これによってＣｊ．ｆ０の位置での信号が再度検知されるのを防ぐ
Ｃｊ．ｇ０：ｐＲ？（）＊｛Ｃｊ．ｇ０：ｓ（）；｝／／掻き始めるために信号をＩｊ．ｆ０に送信
Ｃｊ：ｔｈｉｎｋ（）．ｔａｌｋ（）；
Ｃｊ：ｇ１：ｐＲ？（）＊｛Ｃｊ．ｇ１：ｓ（）；｝／／掻くのをやめるために信号をＩｊ．ｆｉに送信
／＊会話を継続するためにＣｉにＣｊ．ｇ２を通して信号を送信するか、会話を中止するためにＣｊ．ｇ３を通して信号を送信する。対話が中止されると、Ｅに準備ができていればＣｊ．ｆ０を通してそれを知らせる＊／
Ｃｊ：ｃｏｎｔｉｎｕｅ？（）｛Ｃｊ．ｇ２：ｓ（）；｝
ｅｌｓｅ｛Ｃｊ．ｇ３：ｓ（）；Ｃｊ．ｆ０：ｐＲ？（）｛Ｃｊ．ｆ０：ｓ（）；｝｝｝
（∃（ｆ）（ｆ＝Ｃｊ．ｆ２｜Ｃｊ．ｆ３）ｆ：ｍＲ？（）｛／／この点で、このガードはＣｊ．ｆ２とＦｊ．ｆ３の両方で失敗する
ガードは、Ｃｉ．ｆ２またはＣｉ．ｆ２、ｉ≠ｊで成功する
ｓｅｌｅｃｔＯｎｅ｛／／ｓｅｌｅｃｔＯｎｅはトップダウンスキャンにおいて第１のｔｒｕｅの条件を選択する
（ｆ＝Ｃｊ．ｆ２）？（）｛Ｃｊ．ｆ２：ｓ（）；／／Ｃｉ．ｇ２、ｉ≠ｊに応答
Ｃｊ．ｇ０：ｐＲ？（）＊｛Ｃｊ．ｇ０：ｓ（）；｝／／掻き始めるために信号をＩｊ．ｆ０に送信
Ｃｊ：ｔｈｉｎｋ（）．ｔａｌｋ（）；
Ｃｊ：ｇｌ：ｐＲ？（）＊｛Ｃｊ．ｇｌ：ｓ（）；｝／／掻くことを止めるために信号をＩｊ．ｆ１に送信
Ｃｊ：ｃｏｎｔｉｎｕｅ？（）｛Ｃｊ．ｇ２：ｓ（）；｝
ｅｌｓｅ｛Ｃｊ．ｇ３：ｓ（）；
Ｃｊ．ｆ０：ｐＲ？（）｛Ｃｊ．ｆ０：ｓ（）；｝｝｝
（ｆ＝Ｃｊ．ｆ３）？（）｛Ｃｊ．ｆ３：ｓ（）；Ｃｊ．ｆ０：ｐＲ？（）｛Ｃｊ．ｆ０：ｓ（）；｝｝｝｝ （２．２８）
【０２１７】
人Ｐｊ，ｊ＝０，１についての掻く部分についてのＴＩＰ。
Ｉｊ．ｆ０：ｍＲ？（）｛／＊以下では、Ｉｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅとはｔｒｕｅに初期化される。したがって、信号がＩｊ．ｆ０で検知されるとＩｊは掻き始め、ｗｈｉｌｅループ内にある間はＩｊ．ｉｔｃｈｉｎｇがｔｒｕｅである限り掻くことを継続する。しかし、ｗｈｉｌｅループの内側で、Ｉｊ．ｒａｎｄｏｍ（）は繰り返しごとに無作為の真理値をＩｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅとに割り当てる、したがって、掻くことは、Ｃｊが話している間を通して発生しないことがあるし、たとえ発生しても断続的になる。ここでは掻く間隔は離す間隔に比べてはるかに短いと仮定する。この実装は成功することが要件である。＊／
ｗｈｉｌｅ（Ｉｊ．ｃｏｎｔｉｎｕｅ？（））｛Ｉｊ：ｉｔｃｈｉｎｇ？（）｛Ｉｊ：ｓｃｒａｔｃｈ（）；｝
Ｉｊ．ｉｔｃｈｉｎｇ＝Ｉｊ．ｒａｎｄｏｍ（）；／／これが掻くことを中止させることがある
Ｉｊ．ｃｏｎｔｉｎｕｅ＝Ｉｊ．ｒａｎｄｏｍ（）；／／これがｗｈｉｌｅループを中止させることがある
Ｉｊ．ｆｌ：ｍＲ？（）｛Ｉｊ．ｃｏｎｔｉｎｕｅ＝ｆａｌｓｅ；｝｝／＊これがループを停止させる＊／
／＊ここでは２つの場合が存在し、（ｉ）Ｉｊ．ｒａｎｄｏｍ？（）がＩｊ．ｃｏｎｔｉｎｕｅをｆａｌｓｅにするか（ｉｉ）ｗｈｉｌｅループ内のＩｊ．ｆ１での信号の検知がｆａｌｓｅにする。以下の検知は両方の場合に成功するが、これは応答信号がＩｊ．ｆ１を通してまだ送信されていないためである。以下では、Ｉｊは（ｉ）の場合にだけ信号をＩｊ．ｆ１で待つことになる。＊／
Ｉｊ．ｆ１：ｍＲ？（）＊｛Ｉｊ．ｆ０：ｓ（）；／＊Ｃｊ．ｇ０に応答＊／
Ｉｊ．ｆｌ：ｓ（）；／／Ｃｊ。ｇ１に応答
／／以下によって、信号が再びＩｊ．ｆ０で検知された時に掻くことを再び開始することができる。
【０２１８】
Ｉｊ．ｉｔｃｈｉｎｇ＝Ｉｊ．ｃｏｎｔｉｎｕｅ＝ｔｒｕｅ；｝｝ （２．２９）
【０２１９】
会話は信号がＰ０．ｆ０またはＰ１．ｆ０のいずれかで受信されるたびに開始される。掻くことは、会話が開始されるか断続的に継続するたびに開始される。どれだけ正しく調和が発生するかを見つけることは読者にお任せする。ネットワークは聞くことを提供しない。聞くことを提供するためには、第３の聞くセルを会話セルとの適切な調和を伴ってカプセル化の内部に導入しなければならない。
【０２２０】
２．３．見通し
ＡＬＬＥＯＰはＴＩＣＣネットワークによって提供された構造情報を統合し、ＴＩＣＣネットワーク、ＴＩＰ、およびポーリングサイクル内の暗示的な並列計算、同期、および調和の制御構造を明示的にし、タイムマップで仮定されている時間点の半順序付けを定義しなければならない。それらは機械処理からのアクセス可能な形態で統合された情報を示す。人間にとって、それらは、経路は何をするのか？、ＴＩＰとは何か？、ポーリングサイクルとは何か？、通信パターンとは何か？のような質問に答える。これらの質問に対する答えは、経路は信号のポート間の通信を可能にし、通信の同期／調和を実施し、交換されるメッセージへのアクセスを可能にし、信号受信セル内で並列計算を起動する、のようになる。ＴＩＰはメッセージを処理／生成し、信号を送信／受信し、メッセージ処理／生成に使用されるメソッドを通信から分離する。ポーリングサイクルはセルがそのポートでのＴＩＰ実行に対応する順序を指定する。通信パターンは、関連する条件に基づく代替の因果チェーンでの選択と、信号配信による並列タスクの起動（フォーク）によって発生する。したがって、イベントパターンは、並列計算における分岐、フォーク、およびジョインの制御構造のパターンを定義する。そのようなパターンは、正規文法やＡＬＬＥＯＰノードを終端記号として使用する他の種類の文法を使用して記述することができる。しかし、ＡＬＬＥＯＰはセルによって実施される計算の詳細を指定しない。各ＡＬＬＥＯＰノードはイベントクラスを表す。ＡＬＬＥＯＰノードの複数のインスタンスは因果律網において発生することがある。
【０２２１】
同じ逐次プログラムが異なるデータ構造定義を使用して実行（ｒｕｎ）されるように、アプリケーションに対するｐｔｈｒｅａｄの同じ集合が同じアプリケーション用の異なるＴＩＣＣネットワーク内で並列に実行されることがある。したがって、逐次プログラムのデータ構造がデータ操作の抽象化であるように、データＴＩＣＣネットワークを並列計算の制御構造の抽象化と見なすことができる。
【０２２２】
トレースはＡＬＬＥＯＰに情報を追加する。トレースは仮想時間点を仮定し、それらをＡＬＬＥＯＰ指定に整合するようにＡＬＬＥＯＰで発生するイベントクラスとタイムマップとに関連付ける。したがって、それらはＡＬＬＥＯＰ内では暗示的なタイミングを明示的にする。トレースは事前／事後条件をアクションに関連付け、存在する場合は交換されるメッセージを特徴付けることによってＴＩＰによって実施される計算の意味も定義する。人間にとって、それらは、アクションは何を計算するのか？、アクションは正しく実行されているのか？、どのようなイベントが同期して発生するのか？、イベントは調和しているのか？のような質問に答える。これらの質問に対する答えは、アクションはアクションが成功するようにその実行前に成立していなければならないものを特徴付ける事前条件と、実行が終了した後で成立しなければならないものを特徴付ける事後条件とによって定義されている、のようになる。これらの事前／事後条件は、アクションによって処理／生成されるメッセージの特徴を含んでいてもよい。アクションの実装は、その事前／事後条件の両方がアクションが実行されるたびに適切な瞬間に満たされる場合に正しい。同一の仮想時間点を備えているイベントは同期して発生する。同一の仮想時間点を備えているメッセージディスパッチイベントは調和したイベントである。
【０２２３】
因果律網はアプリケーション内の通信イベントの発生とそれらの同期／調和特性にだけに注目し、全ての条件とアクションを無視したトレースの抽象化である。セクション７で説明するように、イベント分析セル（ｅａセル）は、アプリケーション内の拡大している因果律網を、因果律網がアプリケーションの実施中の動作にほとんどまたは全く干渉せずにイベントビルダーセル（ｅｂセル）によって生成されている時に、アプリケーションと並列に分析してもよい。ｅａセルによって実施される分析は、事前に定義されたイベントパターンやｅａセルによって動的に学習されたイベントパターンに基づいていてもよい。ｅａセルによって認識されるパターンをアプリケーション内で実施される計算を導くために使用することさえ可能である。
【０２２４】
アプリケーションの半順序ドメインは、そのアプリケーションが実行（ｒｕｎ）される可能性のある全ての方法においてＳＭＳが生成できる全ての可能性のある因果律網の表現に過ぎない。たまたま、このドメインはドメインからそれ自体に対する単調連続マッピングと共にＴＩＣＣ−Ｐｐｄｅの表示的意味論を定義するのに十分である。これは、論理は計算に必要なく、適切な隠蔽と代替規則とを備えている通信で十分であるというπ算法の視点と整合している。論理は、計算の正しさを定義し証明するためにのみ必要である。それは、トレースによって提供される情報がＣＴＬアサーションを証明するために必要なためである。ＥＣＴはトレース内の情報を認識し、ポーリングサイクルとＥＣＴネットワークはポートＥＣＴの逐次／並列の組み合わせを実装において提供する。それらはＣＴＬアサーションの提供に使用される。セクション６に例を示す。
【０２２５】
アプリケーションＩからＩＩＩに示した実装とセクション６に示した証明とは以前に概説した見方を示している。重要なことは、ＡＬＬＥＯＰはシステムによって実装の仕様から容易に自動的に導出されることである。トレースはアクションに対する事前／事後条件がシステムに知らされている場合、ＡＬＬＥＯＰから容易に自動的に導出される。ＴＩＣＣ−Ｐｐｄｅはアクションのための事前／事後条件を作製する対話型のツールを提供する。ＴＩＣＣ−Ｐｐｄｅの４つの特徴がこれを可能にしており、それらは（ｉ）ポートが付属しているセル、エージェントを備えている経路、および任意採用の仮想メモリについてのＴＩＣＣネットワークの構成、（ｉｉ）ＴＩＰ、ポーリングサイクル、ｐｔｈｒｅａｄ、およびプロトコルについての計算の構成、（ｉｉｉ）計算と通信との統合：計算を実行する各セルはその通信もＣＣＰを使用するプロトコルを使用してすべて実行する、（ｉｖ）セルの相互分離（セクション３．２で説明）である。
【０２２６】
３．セルと経路の詳細
３．１．付属とチューン
付属とチューンはＴＩＣＣの特別に優位な性質である。付属しているまたはチューンされたコンポーネントだけが自由に他のデータとメソッドとを共有することができる。したがって、付属しており互いにチューンされているポート、セル、エージェント、および仮想メモリは自由に他のメソッドとデータを共有することができる。
【０２２７】
エージェントａに付属している仮想メモリを指す時にａ．Ｍを使用し、Ｍに付属しているｉ番目のエージェントを指す時にＭ．ａ［ｉ］を使用し、ｐ．Ｍ＝ｐ．ａ．Ｍと設定し、ここでｐ．ａはｐがチューンされているエージェントである。ブランチまたはｈブランチ（隠れたブランチ）によって互いに接続されているコンポーネントと互いに付属しているコンポーネントだけが経路内で信号を互いに送信できる。図４と５において、ポートはそれらの親セルに付属しており、ブランチによってエージェントに接続されており、エージェントは互いにｈブランチによって接続されている（それらはｈブランチであるがそれは、エージェントの相互接続は経路が動的に修正された時に動的に変更できないためである）。したがって、経路内のエージェントとポートおよびエージェントの対は信号を交換し、セルは信号をそれらのポートに送信することができる。前述のように経路によって信号の転送は所与の時刻において一方の方向にだけ可能で、信号を交換するコンポーネントは常に互いに対してチューンされている。
【０２２８】
チューン：ポートｐをエージェントａにブランチｂによって接続すると、（i）ｐとaの初期状態を設定し、それによってそれらが互いに信号を交換できるようになり、（ｉｉ）ａ．Ｍ＝ｐ．Ｍ内のアドレスとメソッドとをｐに転送して、ｐの状態がＳの時にｐの親セルがｐ．Ｍ内のデータとｐｔｈｒｅａｄにアクセスできるようにすることによってｐがａに対してチューンされる。したがって、ｐをａにチューンすることによって、ｐとその親セルが仮想メモリ ａ．Ｍ＝ｐ．Ｍにチューンされる。セルは５〜６個のポートを有しているため、セルはそれに対してチューンされている５〜６個の仮想メモリを有することが可能で、セルの別個のポートに対して別個の仮想メモリを有している。２つのエージェントはそれらの初期状態を設定するｈブランチによってそれらを接続することによって互いにチューンされる。
【０２２９】
トランザクションの完了：前述のように、各セル内のポートの循環ポーリングはセルのポートに送信された各サービス要求が検知され応答されることを保証する。セルがサービス要求に応答している間に割り込みをかけられることはない。セルは連続したＴＩＰの実行同士の間でだけ割り込みを検知し応答する。次のサブセクションで説明するセルの分離と共にこれらの特徴が各トランザクションについてトランザクションの完了を保証し、これによって経路のコンポーネントが常に互いにチューンされた状態に維持される。
【０２３０】
３．２．セルの分離
セルはそのポートをポーリングしてポートで定義されているＴＩＰボディを実行することによって計算を実行する。セルは別個の計算ユニット内で並列に動作するために、並列な実行機構を提供し、タイムスライスされた割り込み駆動ｐｔｈｒｅｄ実行は使用しない。ｐｔｈｒｅａｄとプロトコルはセルとそのポートとに一意に関連付けられている。セルの各ポートはｐｔｈｒｅｄを有していてもよく、それに関連付けられている一意のプロトコルを有することになる。セルの分離は以下の２つの特性によって定義されている。
【０２３１】
プライベートおよびローカルｐｔｈｒｅａｄ：ｐｔｈｒｅａｄの実行に、セルはセル内で定義されているデータとプロセスまたはセルに付属しているまたはチューンされているコンポーネントだけを使用する。他のデータやプロセスはそのようなｐｔｈｒｅａｄの実行中には使用されない。特に、オペレーティングシステムはＴＩＰ実行に干渉することはできない。セルに関連付けられているｐｔｈｒｅａｄは任意の他のセルによって実行可能であるが、同じｐｔｈｒｅａｄの複製の各々を自身のプライベートメモリまたは関連付けられている仮想メモリ内で異なるセルによって並列に実行可能である。ｐｔｈｒｅａｄの実行は、ｐｔｈｒｅａｄを実行するセルの状態を変更できるだけである。セルのこれらの特徴はアクターとπ算法エージェントの特徴と同様である。
【０２３２】
ポートグループ内のポートの親セル（図１９を参照）はポートグループ内のポートの共有仮想メモリ内で同時に同じｐｔｈｒｅａｄを実行することができる。そのような実行に、それらは共通の共有変数を使用してもよい。そのような実行（ｒｕｎ）中にメモリ干渉を防止するためにｐｔｈｒｅａｄがどのように構成されるかをセクション６．２で説明する。これらの特徴とプロトコルに関する以下で示す特徴とはＴＩＣＣ−Ｐｐｄｅ構成に固有である。
【０２３３】
プライベートおよびローカルプロトコル：別個のポートはそれらに対して定義されている別個のプロトコルを有している。セルのポートで定義されているプロトコルは、ポートの親セル以外の任意にセルによって実行されない。プロトコルをそのポートで実行中に、セルはそのポートに接続されている経路上でＣＣＰとプロトコル内の他のアクションステートメントを実行する（セクション７を参照）。プロトコルの実行によって、セルがプロトコル自体で定義されていない他のスレッドやプロセスを実行することはない。経路のコンポーネントで定義されていないデータを使用することもない。別個のセルは別個のプロトコルだけを並列に実行する。
前述のように、ポートグループのポートで定義されているプロトコルのセグメントはセクション７で説明するように、ポートの親セルによって同じグループ対グループ経路（図１９）上で並列に実行される。
【０２３４】
３．３並列バッファリング、並列メッセージ送信、およびモビリティ
必要のない逐次バッファ：例えば第１の要求したサービスに対する応答が受信される前の図１と２のポートＤ．ｆのように、一般ポートは第２のサービス要求メッセージを機能ポートに送信しない。これは、ＴＩＣＣネットワーク内の全ての一般ポートと機能ポートに当てはまる。そのため、仮想メモリは２つ以上の保留中のサービス要求メッセージを保持していることはない。各保留中のサービス要求メッセージは応答が検知され応答されるまでその仮想メモリ内に保存されている。
【０２３５】
同様に、各応答メッセージはメッセージ受信セルによって検知され使用されるまで仮想メモリ内に保存されている。仮想メモリが２つ以上の応答メッセージを保持していることはない。したがって、各仮想メモリは任意の所与の時刻に高々１つのサービス要求と応答を保持ししている。別個の経路に接続されている別個のポートはそれらに関連付けられている別個の仮想メモリを有することになる。したがって、ＴＩＣＣネットワーク内の仮想メモリはサービス要求と応答に対して並列バッファリング機構を提供する。これらの特徴によって、逐次バッファが必要でなくなる。アクターシステムとは異なり、解決しなければならないバッファ競合は存在せず、シリアライザは必要ない。
【０２３６】
並列メッセージ転送：これらのいくつかについては既に説明している。それらをもう一度説明する。（ｉ）各セル自体は他のセルと並列にメッセージ交換に必要なプロトコルを実行し、（ｉｉ）２つの別個の経路が共通のコンポーネントを共有せず、（ｉｉｉ）プロトコルが経路のコンポーネントで定義されていないスレッドやプロセスを実行しないので、点対点経路上にあるかグループ対グループ経路上にあるかに関わらず、別個のプロトコルが相互干渉無しに並列に実行される。
したがって、ＴＩＣＣネットワーク内のセル間で並列に同時に交換可能なメッセージの数は、アクティブなセルの数とネットワーク内の別個の経路の数とによってだけ制限される。ＣＣＰは経路コンポーネントを他のセルから、そして互いに分離している。
【０２３７】
モビリティ：ポートに接続されている経路は以下の経路要件に違反しない限りモビリティを導入するために動的に変更することが可能である。これらの要件は、（ｉ）ポートは２つ以上の経路には接続されないこと、（ｉｉ）同じセルの２つのポートはポートがポートベクトル内に存在しない限り同じ経路に接続されないこと（セクション４．２とセクション７を参照）、（ｉｉｉ）２つの別個の経路はコンポーネントを共有しないことである。トランザクションの途中で、メッセージの送信先の経路の機能ポートを経路から接続解除し、異なる送信先の機能ポートに経路設定することができる。それから新しい送信先ポートの親セルが経路の仮想メモリ内のサービス要求メッセージを処理し、仮想メモリ内に応答メッセージを書き込み、経路を元の送信先ポートに結合し直し、それからその親セルは必要に応じて応答を修正し、それをサービスを要求した一般ポートに送信する。したがって、応答は常にサービス要求を配信したのと同じ経路を通して返信される。経路に接続されている一般ポートはトランザクションの途中で動的に変更することはできない。
【０２３８】
分散メモリシステムにおいて、プログラムのモビリティは仮想メモリの内容全体を分散システム内の他の仮想メモリに転送することによって達成される。
【０２３９】
３．４．ＴＩＣＣ、π算法、アクター、およびＣＳＰ
ＴＩＰの実行によって、ｐｔｈｒｅａｄとプロトコルが実行され、セルが互いに相互動作する。セル間の相互動作はπ算法内のエージェントとアクターとの間の相互動作と同様である。アクターとπ算法エージェントのように、ｐｔｈｒｅａｄの実行（ｒｕｎ）はセルの厳密にプライベートな動作である。しかし、５〜６個の際だった違いがある。
【０２４０】
ＴＩＣＣとアクター：アクターシステムにおいて、通信プロトコルはアクターの外部のＯＳメソッドと他のプロセスとを呼び出す。非同期通信には逐次バッファの使用が必要である。シリアライザがバッファ競合の解決に必要である。１つのアクターが送信したメッセージがいつ受信側のアクターに到着するのかを予測することはできない。通信は順序が保存されず、メッセージは送信されたのと同じ順番には送信先に届かない。
【０２４１】
ＴＩＣＣにおいては、アクターシステムとは異なり、通信は接続指向である。通信は２つのセルの間で経路が両者の間で確立している場合にだけ発生する。セルはメッセージを交換するために自身でプロトコルを実行する。メッセージ送信と配信の時間は、所与の限界によって正確に予測することができる。ＴＩＣＣ内でのプロトコル実行とｐｔｈｒｅａｄ実行との間の唯一の区別は、プロトコルは宣言を含んでいないことである。したがって、それらは、実行中にデータコンテナを作製／破壊することはできない（データを保持するメモリセルが存在し、セクション５で導入する）。メッセージの送信以外に、プロトコルはアクセス権も配信されたメッセージに対して転送する。プロトコルはセルが実施する計算の制限された形態を定義している。これによって、計算と通信との間の古典的な２分法が排除される。したがって、「統合された計算と通信のための技術」（ＴＩＣＣ）という名前となる。
【０２４２】
また、アクターシステムとは異なり、ＴＩＣＣはグループ対グループ通信、自動同期と調和、および動的ＳＭＳ（自己監視システム）に対応している。ＴＩＣＣによって並列バッファリング機構を使用することによって非同期通信における逐次バッファが必要なくなる。ＴＩＣＣ−ＰｐｄｅのＳＭＳのように、ＳＭＳをアクターシステム内で定義することはできない。トランザクションへの対応はアクターシステムには本来備わっていない。
【０２４３】
ＴＩＣＣとπ算法：ＴＩＣＣのように、π算法内の通信は接続指向である。名前が、既に確立されているリンクを通してπ算法／エージェント間で交換され、リンクは動的には確立できない。経路は信号を送信し、送信先の機能ポートへの経路の接続は、トランザクションの途中で動的に変更することができる。π算法はトランザクションの概念を使用しない。ＴＩＣＣにおける経路接続に対する動的な変更とπ算法におけるリンク接続に対する動的な変更とは異なる計算目標を達成するように見える。図３、４および２０に示しているように、経路は分岐し、各々が別個のセルに属している５〜６個の別個のポートへの同じ信号の時間が同期した配信を行う。π算法とは異なり経路はポート、プロトコル、仮想メモリ、エージェント、ブランチ、およびｈブランチを備えている構造を有している。また、π算法／エージェントとは異なり、ＴＩＣＣのセル間の相互動作は正確に時間が設定されている。
【０２４４】
重要な違いは以下のとおりであって、前述のように、経路プロトコルは、通信を、相互動作しているｎｄＦＳＭによって実行され、メッセージを送出するセルによって実行されるチューリング計算［Ｔｕｒｉｎｇ，２０］として定義しており、π算法はそのリンクに対して通信機構を指定していない。実際に、π算法形式を使用して必要な通信機構を指定することはできない。この意味で、π算法は並列計算の全てを指定していない。通信が所与のプリミティブとして仮定される場合にだけπ算法は並列計算を指定する。π算法は同期と調和の機構を有していない。π算法内でＳＭＳを定義することはできない。
【０２４５】
ＴＩＣＣとＣＳＰ：違いについては既に説明している。それを再度説明する。ｐｔｈｒｅａｄ（ＣＳＰ内の逐次プロセスに対応）は、通信ステートメントを含んでいない。通信プリミティブは逐次プロセス（ｐｔｈｒｅａｄ）にコード化されてない。ＴＩＰだけが通信ステートメントを有している。ＴＩＰは通信を相互動作している逐次プロセス（ｐｔｈｒｅａｄ）から分離している。ＣＳＰチャネルとは異なり、経路は相互動作しているｐｔｈｒｅａｄを遮断しない。また、ＣＳＰチャネルとは異なり、経路はポイント対ポイントとグループ対グループの非同期通信に対応している。ＳＭＳをＣＳＰ内で定義することはできない。
【０２４６】
ｐｔｈｒｅａｄの対ごとの独立：１つのセルサブクラスで定義されているｐｔｈｒｅａｄは、サブクラスインスタンスがセルに付属していたりチューンされていたりしない限り、他のサブクラス内で定義されている他のｐｔｈｒｅａｄを呼び出して実行しない。しかし、並列に実行（ｒｕｎ）されている２つのセルは同じｐｔｈｒｅａｄの複製を自身の別個の実行環境において実行する。１つのセルによって実行されているｐｔｈｒｅａｄは他のセルの状態を変化させることはない。異なるセルによって実行されているｐｔｈｒｅａｄの対は互いに独立した状態を維持する。しかしこれについては１つの例外がある。例外は、ポートグループ内のポートの親セルが共にサービス要求メッセージを送信するか、受信したサービス要求メッセージを共に処理する場合である。これらの場合、ポートグループ内のポートの親セルがそれらの計算を調和させる必要は無い。親セルは、メッセージを保持している仮想メモリによって提供される共通のスクラッチパッドを使用してそれを行う。ポートグループ内のポートの親セルによって実行されるｐｔｈｒｅａｄは互いに依存している。それらは併せて検証しなければならない。これによって、ほとんどのｐｔｈｒｅａｄを独立して検証することができるようになる。
【０２４７】
４．ＴＩＰとＴＩＣＣ−Ｐｐｄｅの詳細
４．１．新規の計算の生成
サービス要求をその機能ポート、Ｃ．ｆに有しているセルＣは自身で受信したサービス要求に対する応答を計算することはできない。この場合、Ｃは応答を計算するために１つまたは２つ以上の他のセル内で新しい計算を生成しなければならない。以下のフォーマットを有しているＴＩＰがこの目的のために使用される。
【０２４８】
Ｃｆ：ｍＲ？（）｛Ｃ．ｆ：ｒ（Ｃ．ｇ）；Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝
ｅｌｓｅ｛Ｃｆ：ｓ（）；｝｝ （４．１）
Ｃ．ｆ：ｓｕｓｐｅｎｄ（）は以下のように定義される。
【０２４９】
（〈Ｃｆ．ｓｔａｔｅ＝Ｓ〉（ｔ０）｝［・→Ｃｆ：ｓｕｓｐｅｎｄ（）（ｔ０）］｛〈Ｃ．ｆ．ｉｎｐｕｔ＝φ〉ｔ１）｝（４．２）
φは空の記号である。これによってＣが次のポーリングサイクルで配信信号をポートＣ．ｆで検知するのを防ぐ。これが、セクション２．２．の話して痒がる例において、異なる文脈で使用されているのを見た。（４．１）において、ｐｔｈｒｅａｄ、Ｃ．ｆ：ｒ（Ｃ．ｇ）≡Ｃｆ：ｍｓｇ（）：ｒ（Ｃ．ｆ，Ｃｇ）はポートｐｏｒｔＣ．ｆにチューンされている仮想メモリ内のメッセージのＭｅｓｓａｇｅサブクラスで定義されている。Ｃ．ｆ：ｓｐｗｎ？（）＝Ｃ．ｆ．ｓｐｗｎはＣ．ｆに関連付けられているローカルブール変数である。Ｃ．ｆ．ｓｐｗｎの真理値は、Ｃ．ｆ：ｒ（Ｃ．ｇ）において設定されている。
【０２５０】
ＴＩＰ（４．１）は、ｐｔｈｒｅａｄ、Ｃ．ｆ：ｒ（Ｃ．ｇ）の実行後、メッセージを、Ｃ．ｆ：ｓｐｗｎ？（）の値に依存して、ポートＣ．ｇを通して送出するかポートＣ．ｆを通して送出するかの２つのうちの一方を行う。ｐｔｈｒｅｄ、Ｃ．ｆ：ｒ（Ｃ．ｇ）は、Ｃ．ｆの仮想メモリ内に応答メッセージを書き込んでブール変数Ｃ．ｆ．ｓｐｗｎ＝ｆａｌｓｅを設定するか、新規のサービス要求メッセージをＣ．ｇの仮想メモリに書き込んで、Ｃ．ｆ．ｓｐｗｎ＝ｔｕｒｅを設定する。この場合、ＣはＣ．ｇを通してサービス要求を受信するセル内で新しい計算を生成し、ポートＣ．ｆでのそのアクティビティをサスペンドする。Ｃ．ｆのサスペンドによって、Ｃ．ｆでの配信信号が破壊される。したがって、ポーリングは次のポーリングサイクルにおいてＣ．ｆで失敗することになる。Ｃ．ｆのサスペンド後、Ｃは即座に次のポートのサービスに進む。Ｃ．ｆの仮想メモリ内のデータと実行状態は保存される。Ｃは後でポートＣ．ｇで応答メッセージを検知した時にだけポートＣ．ｇとＣ．ｆとでそのアクティビティを継続する。ただし、（４．２）において、Ｃ．ｆでのサスペンドはＣ．ｆ．ｓｔａｔｅを変更しない。したがって、応答がポートＣ．ｇで受信され、計算がレジュームされると、Ｃ．ｆは応答を返信する準備ができる。
【０２５１】
（４．１）のｅｌｓｅ節のある条件ステートメント、
Ｃ．ｆ：ｓｐｗｎ？（）（Ｃ．ｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝，ｅｌｓｅ｛Ｃ．ｆ：ｓ（）；｝、
は、次のように解釈される。
【０２５２】
ｓｅｌｅｃｔＯｎｅ｛Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝
¬Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｆ：ｓ（）；｝
ｔｒｕｅ｛｝／＊この場合、Ｃ．ｆ．ｓｐｗｎ＝φ＊／｝、
ここで、ｓｅｌｅｃｔＯｎｅはその条件を上から下にスキャンして、ｔｒｕｅと評価される１つを選択する。ｓｅｌｅｃｔＯｎｅには無条件のエスケープ節である最後の節が存在する。したがって、Ｃ．ｆ．ｓｐｗｎ＝φの場合、メッセージは送出されない。この場合は、セルがメッセージを送信するのに必要な条件を満たさない場合に発生する。この場合、Ｃ．ｆ．ｓｐｗｎ＝φを設定したｐｔｈｒｅａｄは、ポートＣ．ｆで受信したメッセージを使用して計算がレジュームされる場合は、Ｃ．ｆ．ｉｎｐｕｔ＝ｓをリセットし、ポートＣ．ｇで受信したメッセージを使用して計算がレジュームされる場合は、Ｃ．ｇ．ｉｎｐｕｔ＝ｓをリセットする。これによって、Ｃが次のポーリングサイクルでメッセージをＣ．ｆまたはＣ．ｇで検知し、セルが要求される条件を満足した後で、メッセージをＣ．ｆまたはＣ．ｇを通して送信することを可能にする（セクション４．１．１を参照）。
【０２５３】
次のポーリングサイクルでメッセージの受信がポートＣ．ｇで検知された場合、Ｃは（４．１）のＴＩＰと同様なボディを使用してＴＩＰを実行し、違いは、Ｃ．ｆ：ｒ（Ｃ．ｇ）の代わりに、今度はＣ．ｇ：ｒ（Ｃ．ｆ）をＣ．ｇで受信したメッセージを使用して実行することであって、ＴＩＰはメッセージ送信の同じパターンを繰り返す。
【０２５４】
Ｃｇ：ｍＲ？（）｛Ｃ．ｇ：ｒ（Ｃ．ｆ）；Ｃ．ｇ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝
ｅｌｓｅ｛Ｃ．ｆ：ｓ（）；｝｝ （４．３）
したがって、応答がポートＣ．ｆを通して返信されるまで必要な回数だけ生成は繰り返され、トランザクションが完了する。トランザクションの完了は、そのような各計算において不可欠である。ここで、Ｃ．ｆ：ｒ（Ｃ．ｇ）＝Ｃ．ｆ：ｍｓｇ（）：ｒ（Ｃ．ｇ，Ｃ．ｆ）はポートＣ．ｆで受信したメッセージのサブクラスで定義され、Ｃ．ｇ：ｒ（Ｃ．ｆ）＝Ｃ．ｇ：ｍｓｇ（）：ｒ（Ｃ．ｆ，Ｃ．ｇ）はポートＣ．ｇで受信したメッセージのサブクラスで定義される。
【０２５５】
各機能ポート、Ｃ．ｆについて、新しい計算を生成可能な一般ポート、Ｃ．ｇは一意である。Ｃの他の機能ポートはＣ．ｇを使用しない。これは、そうしない場合に発生する可能性のあるデッドロックを防止することを意図している。また、Ｃがサービス要求をＣ．ｇを通して送信する時にはいつも、ポートＣ．ｇはそのメッセージを送信する準備ができていることに注意しなければならない。
【０２５６】
Ｃ．ｇがそのサービス要求を送信するセルは、自身が同様に新しい計算を生成することもある。また、Ｃ．ｇはそのサービス要求を機能ポートグループにブロードキャストすることもある。これによって、計算をネットワーク全体に広げることになる。サービス要求がそのように送信された各セルはそれに応答しなければならず、かならず応答する。最終的に全ての生成されたトランザクションは終了し、応答メッセージがＣ．ｇによって受信される。それから、Ｃ．ｇにおけるこの応答メッセージは、ＣによってＣ．ｆで受信したサービス要求に応答するために（またはもう一度生成するために）使用される。
【０２５７】
４．１．１．選択肢のあるＡＬＬＥＯＰとトレース
以下では、ＴＩＰ（４．１）と（４．３）に指定されている生成計算内の選択点に起因する分岐によるＡＬＬＥＯＰとトレースにおける選択肢の発生を説明する。（４．１）のＴＩＰのポートＣ．ｆがそのメッセージをポートＢ．ｇから時間点ｔ（ｂ．ｇ、１）に受信し、ＴＩＰ（４．１）のポートＣ．ｇがポートＤ．ｆと通信する。ＴＩＰ（４．１）のＡＬＬＥＯＰは以下の形態である。
【０２５８】
Ｃ．ｆ：ＡＬＬＥＯＰＯ＝［Ｃ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｃ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｃ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｃ．ｆ：ｍＲ？（〈Ｃ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］）］
Ｃ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｃ．ｆ：ｒ（Ｃ．ｇ）・→／／これによってＣ．ｆ：ｓｐｗｎをｔｒｕｅ、ｆａｌｓｅ、またはφに設定
（Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｇＳ［ｔ（Ｃ．ｇ，０）］
→（〈Ｄ．ｆＤ〉［ｔ（Ｃ．ｇ，１）］
｜｜・→．．．・→Ｄ．ｆ：ＡＬＬＥＯＰ（））
・→Ｃ．ｆ：ｓｕｓｐｅｎｄ（）｝｜
¬Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｆＳ［ｔ（Ｃ．ｆ，０）］
→（〈Ｂ．ｇＤ〉［ｔ（Ｃ．ｆ，１）］
｜｜・→．．．・→Ｂ．ｇ：ＡＬＬＥＯＰ（））｝｜
ｔｒｕｅ｛｝）］ （４．４）
（４．４）において、ＡＬＬＥＯＰは括弧に囲まれている選択肢「（．．．｜．．．｜．．．）」を指定する。（４．１）のｐｔｈｒｅａｄ、Ｃ．ｆ：ｒ（ｃ．ｇ）は以下の（４．５）に示しているように選択点によって指定された選択肢を有しており、（４．５）のＣ．ｆ．ＭはＣ．ｇに対するのと同様にＣ．ｆに対してチューンされている仮想メモリである。
【０２５９】
Ｃ．ｆ：ｒ（Ｃ．ｇ）＝Ｃ．ｆ：ｍｓｇ（）：ｒ（Ｃ．ｇ，Ｃ．ｆ）＝
［〈ｃｏｍｐｕｔａｔｉｏｎｓ−ｌ〉／／これが以下で使用する条件の値を設定。
【０２６０】
ｓｅｌｅｃｔＯｎｅ｛〈Ｃ．ｆ：ｃｏｎｄｎ１〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｔｒｕｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｇ．Ｍ〉｝
〈Ｃ．ｆ：ｃｏｎｄｎ２〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｆａｌｓｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｆ．Ｍ〉｝
ｔｒｕｅ｛Ｃ．ｆ．ｓｐｗｎ＝φ；Ｃ．ｆ．ｉｎｐｕｔ＝ｓ；｝｝］ （４．５）
ただし、（４．５）においてＣ．ｆ．ｓｐｗｎがφに設定された場合、ｃ．ｆ．ｉｎｐｕｔはｓにリセットされ、Ｃは次のポーリングサイクルでポートＣ．ｆで受信したメッセージを再度検知する。これは、この場合、（４．１）に示しているｃ．ｆ：ｓｕｓｐｅｎｄ（）を実行することによってポートＣ．ｆにおける前のサービスの試みにおいてＣ．ｆ．ｉｎｐｕｔがφに設定されているからである。ｐｔｈｒｅａｄ、Ｃ．ｇ：ｒ（Ｃ．ｆ）＝Ｃ．ｇ：ｍｓｇ（）：ｒ（Ｃ．ｆ，Ｃ．ｇ）はＣ．ｆとＣ．ｇによる役割が切り替えられる同様の構造を有している。
【０２６１】
Ｃ．ｇ：ｒ（Ｃ．ｆ）＝Ｃ．ｇ：ｍｓｇ（）：ｒ（Ｃ．ｇ，Ｃ．ｆ）＝
［〈ｃｏｍｐｕｔａｔｉｏｎｓ−２〉／／これがｃｏｎｄｎ１またはｃｏｎｄｏｎ２をｔｒｕｅに設定する
ｓｅｌｅｃｔＯｎｅ｛〈Ｃ．ｇ：ｃｏｎｄｎ１〉？（）｛Ｃ．ｇ．ｓｐｗｎ＝ｔｒｕｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｇ．Ｍ〉｝
〈Ｃ．ｇ：ｃｏｎｄｎ２〉？（）｛Ｃ．ｇ．ｓｐｗｎ＝ｆａｌｓｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｆ．Ｍ〉｝
ｔｒｕｅ｛Ｃ．ｇ．ｓｐｗｎ＝φ；Ｃ．ｇ．ｉｎｐｕｔ＝ｓ；｝｝］ （４．６）
（４．５）のＡＬＬＥＯＰは選択肢の指定を備えている以下に示している構造を有している。
【０２６２】
Ｃ．ｆ：ｒ．ＡＬＬＥＯＰ（Ｃ．ｇ）＝
［・→．．．・→／／これはｃｏｎｄｏｎ１またはｃｏｎｄｎ２をｔｒｕｅに設定する（４．５）の〈ｃｏｍｐｕｔａｔｉｏｎｓ−１〉を表す。
【０２６３】
・→（〈Ｃ：ｃｏｎｄｎ１〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｔｒｕｅ・→〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｇ．Ｍ〉｝｜
〈Ｃ：ｃｏｎｄｎ２〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｆａｌｓｅ・→〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｆ．Ｍ〉｝｜
ｔｒｕｅ｛Ｃ．ｆ．ｓｐｗｎ＝φ・→Ｃ．ｆ．ｉｎｐｕｔ＝ｓ；｝｝）］ （４．７）
（４．６）のＡＬＬＥＯＰはこれと同様である。
【０２６４】
４．２．ポートベクトル
フォークとジョインはポートベクトルが使用された時に発生する。ポートベクトルｐ＝［ｐ１，ｐ２，．．．，ｐｎ］はポートのベクトルであって、全て同じ種類であって、全て同じセルに付属している。このポートベクトルに関連付けられているＴＩＰにおいて、ベクトルのポートの親セルはメッセージを確認するために（またはポートの準備ができていることを確認するために）、ｐ：ｍＲ？（）（またはｐ：ｐＲ？（））の形態のガードを使用し、ここで
ｐ：ｍＲ？（）＝［ｐ１：ｍＲ？（）＆ｐ２：ｍＲ？（）＆．．．＆ｐｎ：ｍＲ？（）］ （４．８）および
ｐ：ｐＲ？（）＝［Ｐ１：ｐＲ？Ｏ＆ｐ２：ｐＲ？（）＆．．．＆ｐｎ：ｐＲ？（）］ （４．９）
したがって、セルはそのポートベクトルでベクトルの全てのポートがそれらに対して配信された信号を有している（または全てが準備ができている）時にだけ信号に応答を開始する。ガードがポートベクトルの全てのポートに対してｔｒｕｅではない場合、ポートベクトルはスキップされ、親セルは次のポートのポーリングを開始する。図１と２において、ｇ：ｍＲ？（）テストが一般ポート、ｇにおいて実施される時に、入力信号ｓ＝ｇ．ｉｎｐｕｔがφにリセットされる。この入力信号のリセットはポートベクトルｇに属している一般ポート、ｇｉについては発生しない。これは、ｇｉ：ｍＲ？（）テストがｇの全てのポートについて成功するまで連続するポーリングサイクルにおいて繰り返されるためである。ｐ：ｍＲ？（）＊（またはｐ：ｐＲ？（）＊）を書くことによって同期ガードを指定し、ここで、ガードはそれがｔｒｕｅになるまで繰り返し評価される。ここでＴＩＰは以下の形態のいずれかを有している。
【０２６５】
Ｃ．ｆ：ｍＲ？（）｛Ｃ：ｒ（ｆ）；Ｃ．ｆ：ｓ（）；｝ （４．１０）または
Ｃ．ｆ：ｍＲ？（）｛Ｃ：ｒ１（ｇ，ｆ）；Ｃ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ：ｓｕｓｐｅｎｄ（ｇ）；｝
ｅｌｓｅ｛Ｃ．ｆ：ｓ（）｝ （４．１１）
Ｃ．ｇ＿：ｍＲ？（）｛Ｃ：ｒ２（ｆ，ｇ）；Ｃ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ：ｓｕｓｐｅｎｄ（ｆ）；｝
ｅｌｓｅ｛Ｃ．ｆ：ｓ（）；Ｃ：ｓｕｓｐｅｎｄ（ｇ）；｝｝、（４．１２）
ここで、Ｐｉ＝ｆｉ｜ｇｉについて、Ｃ．ｐ：ｓ（）＝Ｃ．ｐ１：ｓ（）；Ｃ．ｐ２：ｓ（）；．．．Ｃ．ｐｎ：ｓ（）； （４．１３）
（４．１１）において、ｇ内のポートはそれらに配信されたメッセージを有していなかった。（４．１１）において、ｇ内のポートはそれらに配信されたメッセージを有していた。この場合、応答がｆを通して返信された時に、ｇ内の各ｇｉについての設定ｇｉ．ｉｎｐｕｔ＝φはｇｉを通して受信したメッセージはリスンされ使用されていることを意味する。（４．１２）のＣ：ｓｕｓｐｅｎｄ（ｇ）がこのタスクを実行する。ここで（４．１０）と（４．１１）のｐｔｈｒｅａｄ、Ｃ：ｒ（ｆ）、Ｃ：ｒ１（ｇ、ｆ）と、（４．１２）のｐｔｈｒｅａｄ、Ｃ：ｒ２（ｆ，ｇ）はポートベクトルのポートの共通の親セルにおいて定義される。ポートベクトルＣ．ｇはＣ．ｆの排他的な使用のために確保されている。ただし、Ｃ．ｇ内の全てのポートはＣがメッセージを送信した時に、常にメッセージを送信する準備ができている。セルはＣ：ｒ（ｇ，ｆ）（またはＣ：ｒ（ｆ））で定義されている計算に依存してＣ．ｆの部分集合のメッセージだけを使用してもよい。同様に、Ｃ．ｇ内のポートの部分集合を通してのみ計算を生成するメッセージを送信してもよい。この場合、Ｃはメッセージが送信された一般ポートを、後でこれらのポートにおいてだけ応答をリスンできるように、記憶することになる。しかし、それは、ｆの各ポートに常に応答する。
【０２６６】
セクション４．４で説明する非決定的ガードの文脈を除いて、ガード表現において分離は許されない。セクション２．２で非決定的ガードを使用した例を見た。しかし、メッセージに対する分離応答はＣ：ｒ（ｇ，ｆ）（またはＣ：ｒ（ｆ））がどのようにＣ．ｆのポートで受信したメッセージを使用するかに依存して可能である。したがって、メッセージがポートベクトルのポートの１つで検知された時に、このメッセージの性質に依存して、同じベクトルの他のポートで受信されたメッセージが無視される。分離を伴うガードを指定することと、ポートベクトルのメソッドとの本質的な違いは後者の場合、応答はポートベクトル内の全てのポートがメッセージを受信し、応答を送信する準備ができた後でだけ発生することであって、分離された状態での使用の予測される計算上の不測事態はｐｔｈｒｅａｄにコード化されている。応答はポートベクトルの各機能ポートを通して常に返信される。メッセージ受信についての肯定応答は、そのメッセージが処理されていない場合でも送信される。したがって、トランザクションは常に完了する。
【０２６７】
この慣行の結果として、セルのポートベクトルのポート間の相互動作の特定のパターンを導入するためには、たとえばあるポートのメッセージが他のポートでの応答を禁止している場合、セルによってそのポートベクトルを通して受信したメッセージに応答するために使用される既にコード化されているｐｔｈｒｅｄを変更することが必要になる。このオプションを選択したが、それは分離を避けることで実装の分析が簡単になるからである。
【０２６８】
４．３．サイクル同期
ネットワーク内の２つのポートは、両者が（ｎ−１）番目の入力メッセージに対してサービスを行った（（ｎ−１）番目の出力メッセージを送出した）後で初めて両者がそれらのｎ番目の入力メッセージに対してサービスを行う（ｎ番目の出力メッセージを送出する）場合にサイクル同期していると言われる。ネットワーク内の別個のポートの集合のサイクル同期はそれらのポートでアクティビティを規定された順序で発生させる。したがって、ポートのサイクル同期はそれらのポートのアクティビティを調和させる。
【０２６９】
４．３．１．同期と調和の種類
サイクル同期：
前述のように、（４．１１）と（４．１２）において、機能ポートベクトルｆの親セルは関連付けられている一般ポートベクトルｇの一般ポートの部分集合によってのみサービス要求を生成することができる。しかし、応答メッセージは常にｆの全ての機能ポートを通して送信される。したがって、ｆのポートがサイクル同期されていても、ｇのポートはサイクル同期されていない。
【０２７０】
これはグループ対グループ通信（セクション２．２と７）で発生することの双対である。これは、Ｇ内のポートによって送信される結合サービス要求メッセージがＦ内のｆｕｎｃｔｉｏｎａｌＰｏｒｔの部分集合にだけ配信されるためである。所与の結合サービス要求メッセージが配信された機能ポートのこの特定の部分集合は送信されたメッセージとセキュリティ指定に依存してもよい（セクション２．２と７の例を参照）。メッセージ配信信号を機能ポート、Ｆにブロードキャストするエージェントはメッセージが配信された機能ポートを追跡し、それらの機能ポートだけからの応答を期待することになる。
【０２７１】
同期ジョインとフォーク：グループ対グループ通信において、フォークとジョインの原因になるメッセージのディスパッチと配信は、セクション１．３．２と８で説明したように、グループ対グループ経路内のエージェントがそれぞれ調和させ同期させる。セルグループ内の異なるセルは同期して配信されたメッセージに対して異なる時間に応答を開始するが、それは応答計算が始まる時間が同期していないからである。しかし、通信は同期しているので、これらを同期ジョインとフォークと呼ぶ。
【０２７２】
非同期ジョイントフォーク：機能ポートベクトルｆによって受信されるメッセージはジョイン操作を構成し、一般ポートベクトルｇを通して送信されるメッセージはフォーク操作を構成する。これらのメッセージは異なる時間に到着（出発）し、異なるセルから来る（に行く）。ここでは通信は非同期なので、これらを非同期ジョインとフォークと呼ぶ。しかし、非同期ジョインにおいて受信されたメッセージに対する応答の計算は常に同期している。ここで、同期はポートベクトルのメッセージ受信親セルによって行われる。
【０２７３】
セクション６．６（図１７と１８）において、生成、ポートグループ、およびポートベクトル構成が導入され、ＴＩＣＣネット−ワーク内の別個のセルの別個のポートの任意の所与の集合によって受信される非同期メッセージは特定の順序で応答計算を発生させるようにサイクル同期しているか、アプリケーション内に既に実装されているｐｔｈｒｅａｄを変更する必要なしに、応答計算をポートのメッセージ受信親セルにおいて同期して始めるように強制されている。これらをアドホック調和と同期と呼ぶ。
【０２７４】
前述のように、ＴＩＣＣ−Ｐｐｄｅ計算には並列計算のアクティビティを調和させ同期させるためにモニタ、セマフォ、ランデブー技法[１０、１２、２３、２４]は必要ない。セクション２でモニタとセマフォを使用しない同期と調和の２つの例を見たが、セクション６でさらに見ることになる。本明細書で説明する全ての同期と調和の特徴はＴＩＣＣ−Ｐｐｄｅに固有である。
【０２７５】
４．４．非決定的ガード
非決定的ガードは指定された集合から１つの選択肢を選択する。ＴＩＰは以下の形態である。
【０２７６】
∃（Ｃ．ｐｉ（Ｃ．ｐｉ＝（Ｃ．ｐ１｜Ｃ．ｐ２｜．．．｜Ｃ．ｐｎ））Ｃ．ｐｉ：ｍＲ？（）｛
ｓｅｌｅｃｔＯｎｅ｛（Ｃ．ｐｉ＝Ｃ．ｐ１）？（）｛Ｃ．ｐ１：ｔｉｐ（）；｝
（Ｃ．ｐｉ＝Ｃ．ｐ２）？（）｛Ｃ．ｐ２：ｔｉｐ（）；｝
――――――――――――
（Ｃ．ｐｉ＝Ｃ．ｐｎ）？（）｛Ｃ．ｐｎ：ｔｉｐ（）；｝｝ （４．１４）
ここでｐはｆ｜ｇを表す。配信信号のある第１のポートはガード内の選択肢の左から右への走査において選択される。選択肢が機能ポートを含んでいる場合、場合は相互に排他的でなければならない。そうでなければ、機能ポートで受信されたメッセージは応答されないことがある。前述のように、これは許されない。
【０２７７】
ＴＩＰ（４．１４）において、ガード内の選択肢ポートの１つであるＣ．ｐ１はその入力メッセージをＢ．ｑｉから受信する。それから（４．１４）のＡＬＬＥＯＰはアクティビティの選択肢の因果チェーンを備えている形態を有することになる。
【０２７８】
∃（Ｃ．ｐｉ（Ｃ．ｐｉ＝（Ｃ．ｐ１｜Ｃ．ｐ２｜．．．｜Ｃ．ｐｎ））Ｃ．ｐｉ：ｍＲ？（〈Ｃ．ｐｉＤ〉［ｔ（Ｂ．ｑｉ，＃）］｛
（（Ｃ．ｐｉ＝Ｃ．ｐ１）？（）｛Ｃ．ｐ１：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
（（Ｃ．ｐｉ＝Ｃ．ｐ２）？（）｛Ｃ．ｐ２：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
――――｜
（（Ｃ．ｐｉ＝Ｃ．ｐｎ）？（）｛Ｃ．ｐｎ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｝ （４．１５）
同期ガード∃（Ｃ．ｐｉ（Ｃ．ｐｉ＝（Ｃ．ｐ１｜Ｃ．ｐ２｜．．．｜Ｃ．ｐｎ））Ｃ．ｐｉ：ｍＲ？（））＊も有していてもよい。この場合、ガードの走査は配信信号のある１つのポートが見つかるまで繰り返される。これがうまくいくようにすることは可能であるが、それはメッセージがセルのポートにセルの動作と並列に配信されるからである。この種類の同期ガードは、セクション６．１の装飾的庭の解法、ＯＧ解法において使用される。他の存在ガードは以下の形態であって、
∃（ｉ）（１≦ｉ≦ｎ）ｇｉ：ｍＲ？（）｛ｓｅｌｅｃｔＯｎｅ｛（Ｃ．ｇｉ＝Ｃ．ｇ１）？（）｛Ｃ．ｇ１：ｔｉｐ（）；｝
（Ｃ．ｇｉ＝Ｃ．ｇ２）？（）｛Ｃ．ｇ２：ｔｉｐ（）；｝
――――
（Ｃ．ｇｉ＝Ｃ．ｇｎ）？（）｛Ｃ．ｇｎ：ｔｉｐ（）；｝ （４．１６）
一般ポートだけを含んでいる。この場合、異なる場合は相互に排他的である必要は無く、それは一般ポートに配信されるメッセージに応答する必要が無いためである。ＡＬＬＥＯＰは（４．１５）と同様である。この種類のガードは、セクション６．３のＰＣ解法、生産者／消費者解法において使用される。
【０２７９】
４．５．ポート依存性
各セルは自身の内部メモリを有している。各セルはこのメモリを使用してセル内で定義されているｐｔｈｒｅａｄを実行し、そのローカル状態を保存する。セルＣの各ポートＣ．ｆについて、ＣがＴＩＰボディ、Ｃ．ｆ：ｔｉｐ（）を実行する時に、それが実行するｐｔｈｒｅａｄは次の関数を計算してもよい。
【０２８０】
ξｆ（ｍｎ，Ｓｃ［ｆ，ｎ−１］）＝（ｍｎ’，Ｓｃ［ｆ，ｎ］） （４．１７）
ここで、ｍｎはポートＣ．ｆによって受信されるＣ．ｆの仮想メモリ内に存在するｎ番目のメッセージ、Ｓｃ［ｆ，ｎ−１］はＣ．ｆの（ｎ−１）番目のメッセージの実行の最後でのそのポートｆに相対的なＣの状態、ｍｎ’はポートＣ．ｆを通して送信されるｎ番目の応答メッセージ、Ｓｃ［ｆ，ｎ］は実行後のＣ．ｆの状態である。Ｐｐをポートｐで定義されている述語を表すために使用し、ＰｃをセルＣ：∀ｐ∀ｑ（ｐ≠ｑ⇒Ｐｐ∩Ｐｑ＝φ）＆∀ｐ（Ｐｐ∩Ｐｃ＝φ）で定義されている述語を表すために使用する。Ｓｃ［ｆ，ｎ］⊂（Ｐｆ∪Ｐｃ）は（Ｐｆ∪Ｐｃ）のｔｒｕｅの述語を含むことになる。これらの述語に関連付けられている値はセルとポートのローカルメモリに保持されている。（４．１７）において、Ｃ．ｐ：ｔｉｐ（）は（Ｐｆ∪Ｐｃ）内の述語の値だけを変更することができる。
【０２８１】
（４．１７）の形態の関数を計算する各ポートは、Ｓｃ［ｆ，ｎ］⊂Ｐｆの場合にξｆがＰｃ内の述語を変更できない場合に、セルＣの独立ポートである。ＴＩＣＣ−Ｐｐｄｅ内のセルは、２つ以上のそのような独立ポートを有していてもよい。Ｃ．ｆがＣの独立ポートである場合、Ｃ．ｆをＣ．ｆに接続されている経路と共に新しい複製セル、たとえばＣ’に移動させることが可能で、Ｃ’．ｆはＣ．ｆが受信するのと同じメッセージを受信し、Ｃ’．ｆはＣ．ｆと同じ機能を有している。この場合、Ｃ．ｆ上で独立している全てのポート（以下の（４．１８）を参照）はＣ’に移動させなければならない。Ｃに割り当てられたＣＰＵがアイドル状態にならないようにするために、複数の独立ポートをセルＣに割り当てることが可能である。割り込みポートは常に独立ポートであるが、他のセルに移動させることはできず、それは割り込みポートを通して受信されたメッセージに基づいてセル内の計算が開始／停止、サスペンド／レジュームされ、セル内のポートの順序が変更されるためである。
【０２８２】
ポートＣ．ｆ１について、Ｃ．ｆ１：ｔｉｐ（）によって計算される関数は次の形態を有している。
【０２８３】
ξｆ１（ｍｎ，Ｓｃ［ｆ１，ｎ−１］，Ｓｃ［ｆ２，ｎ−１］）＝（ｍｎ’，Ｓｃ［ｆ１，ｎ］） （４．１８）
ここでＳｃ［ｆ２，ｎ−１］は同じセルの他のポートＣ．ｆ２の状態である。この場合、ポートｆ１はポートｆ２に依存していると言う。ξｆ１はＰｆ２の述語を使用してもよいが、それらを変更することはできない。この種類のポートの依存性は以下の入れ子形態のＣ．ｆ２のＴＩＰによって実施される。
【０２８４】
Ｃ．ｆ２：ｍＲ？（）｛Ｃ．ｆ２：ｒ（）．ｓ（）；Ｃ．ｆｉ：ｍＲ？（）＊｛Ｃ．ｆｉ：ｒ（Ｃ．ｆ２）．ｓ（）｝｝ （４．１９）
ここで、ｆ２でメッセージに応答した直後に、セルはメッセージの受信をｆ１で待って応答する。任意の数のそのような入れ子をＴＩＰに有することができる。ｆ１とｆ２とが相互に依存していることも可能である。その場合、ＴＩＰは次の形態である。
【０２８５】
Ｃ．ｆ２：ｍＲ？（）｛Ｃ．ｆ２：ｒ（Ｃ．ｆ１）．ｓ（）；Ｃ．ｆ１：ｍＲ？（）＊｛Ｃ．ｆ１：ｒ（Ｃ．ｆ２）．ｓ（）｝｝ （４．２０）
ここで、ｆ２はｆ１とｆ２の初期状態を使用してそのメッセージにまず応答し、それからｆ１が追従する。次に、ｆ２はｆ２とｆ１の更新された状態を使用してそのメッセージに応答し、この繰り返しのサイクルが継続する。明らかに、（４．１９）と（４．２０）のポートｆ１とｆ２とはサイクル同期している。これらの場合、Ｃ．ｆ１：ｔｉｐ（）はＣ．ｆ２：ｔｉｐ（）内でのみ実行される。
【０２８６】
0005704459.tif 000009
【０２８７】
図８：依存ポートの移動
図８において、「修正前」のセルＣ．ｆ１は（４．１８）のようにＣ．ｆ２に依存している。「修正後」版では、Ｃ．ｆ１の経路はポートベクトルｆ＝［Ｃ’．ｆ１，Ｃ’．ｆ２］を有している他のセルＣ’のポートＣ’．ｆ１に移動している。修正前のポートＣ．ｆ１は一般ポート、Ｃ．ｇに変換されており、経路がＣ．ｇとＣ．ｆ２との間に設定されている。Ｃ．ｆ２の以下のＴＩＰとベクトル［Ｃ’．ｆ１，Ｃ’．ｆ２］はＣ．ｆ１とＣ．ｆ２との間の依存性を説明するために使用できる。
【０２８８】
(Ｃ．ｆ２：ｍＲ？（）＆Ｃ．ｇ：ｐＲ？０）｛Ｃ．ｆ２：ｒ（Ｃ．ｇ）．ｓ（）；Ｃ．ｇ：ｓ（）；｝ （４．２１）
（Ｃ．ｆ１：ｍＲ？（）＆Ｃ．ｆ２：ｍＲ？（））｛Ｃ．ｆ１：ｒ（Ｃ．ｆ２）．ｓ（）；Ｃ’．ｆ２：ｓ（）；｝ （４．２２）
ここでＣ．ｆ２はメッセージをＣ．ｇ．Ｍに書き込み、Ｃ．ｆ２に送信する。明らかに、Ｃ．ｆ２と［Ｃ’．ｆ１，Ｃ’．ｆ２］とはサイクル同期している。それは、互いに依存しているポートを分離しない。
【０２８９】
独立しているポートと依存しているポートを新しいセルへこのように移動させる可能性によって、各セルが唯一の独立機能ポートまたは機能ポートベクトルを有しており、他の全ての機能ポートはそれに依存している正規ネットワークの概念が発生する。
【０２９０】
Ｃ．ｆ：ｔｉｐ（）によって計算される関数は以下の形態を有していてもよい。
ξｆ（ｍｎ，（Ｓｃ［ｎ−１］∪Ｓｆ［ｎ−１］））＝（ｍｎ’，（Ｓｃ’［ｎ］∪Ｓｆ［ｎ］）） （４．２３）
ここでＳｃはセルＣの状態であって、ＳｆはポートＣ．ｆの状態である。ここで、共通の親セルの状態を共有しているポートＣのすべてのポートは互いに依存しているが、サイクル同期していない。前述のように、Ｃ．ｆ：ｔｉｐ（）は（Ｐｃ∪Ｐｆ）の述語だけを変更する。セクション６の食事をする哲学者の解法では、執事の全てのｆｕｎｃｔｉｏｎａｌＰｏｒｔは執事の状態に依存している。この場合、セルによって生成される出力メッセージは入力メッセージが処理される順序に依存している。セルの１つのポーリングサイクルにおいて、そのポート全部はそれらに対して配信されたメッセージを有しておらず、メッセージ検知はメッセージ配信に同期していないため、これはＴＩＣＣ−Ｐｐｄｅにおける非決定性の原因となる。前述のように、これはＴＩＣＣ−Ｐｐｄｅの並列計算に固有である。
【０２９１】
セルのｆｕｎｃｔｉｏｎａｌＰｏｒｔ、ｆと一般ポート、ｇは、（４．２）と（４．３）の生成ＴＩＰでのように、互いに依存していてもよい。ここで、ポートｆは依存性の原因となるが、それはｇが計算を生成した後で初めて配信されたメッセージを有することができるからで、ｆ：ｔｉｐ（）においてだけ行うことができる。セルはデータベースやインターネットからデータを取得するために、その機能ポートの１つに専用の一般ポートを使用することができる。セルはセクション６．３の生産者／消費者の例でのように、後で使用するためにｆｕｎｃｔｉｏｎａｌＰｏｒｔに対して専用ではないその一般ポートを使用することもできる。
【０２９２】
セクション１と４で導入したＴＩＰの形態はＴＩＣＣ−Ｐｐｄｅで使用されるＴＩＰの形態だけである。ＴＩＰはそのボディに埋め込まれている他のＴＩＰを有していてもよく、各ＴＩＰはゼロ以上のメッセージを送出する。セルによってそのポーリングサイクルにおいてポーリングされるセルのポートＴＩＰを外部ＴＩＰと呼ぶことにする。所与の任意の時刻で、常に、各セルはその全ての埋め込みＴＩＰ（内部ＴＩＰ）と共に外部ＴＩＰを１つだけ実行する。セルはその次の外部ＴＩＰを、現在のＴＩＰの実行の完了後か現在のＴＩＰのプログラムされたサスペンドの実行後に初めて実行する。外部ＴＩＰの実行は相互に排他的である。各ポートベクトルＣ．ｐはベクトル内の全てのポートに対して定義されている１つの共通のＴＩＰ、Ｃ：ｔｉｐ（ｐ）と、それら全てに対して定義されている共通の状態Ｓｃ［ｐ，ｎ］を有している。Ｃ：ｔｉｐ（ｐ）は、その機能に依存して、ＰＰまたはＰｐ∪Ｐｃの任意の述語を変更することができる。
【０２９３】
全ての場合において、ネットワーク内のセルによって並列に同時に実行されるＴＩＰの数と並列に同時に交換されるメッセージの数とは高々ネットワーク内のアクティブなセルの数である。
【０２９４】
0005704459.tif 000010
【０２９５】
図９：従来のアーキテクチャとＴＩＣＣシステムのアーキテクチャ
【０２９６】
４．６．システムアーキテクチャ
ＴＩＣＣ−Ｐｐｄｅ内のシステム構成を従来のシステム構成と対比することは有用である。図９Ａは粗粒度並列プログラミングにおける並行／並列スレッド／プロセス実行のための従来のアーキテクチャを示している。ＭＰＩ［２５，２６］、ＰＶＭ［２７］によって提供されるライブラリとＥｔｈｅｒｎｅｔ［２２］またはＭｙｒｉｎｅｔ［２８］によって提供されるネットワークが通信に使用される。アクターシステムはこのアーキテクチャを仮定している。これらのシステムでは、スケジューリング、通信、同期、調和、プロセスとスレッド管理に相当なオーバーヘッドが存在し、効率の損失が伴う。ＴＩＣＣ−Ｐｐｄｅは、スケジューリング、調和、同期、およびｐｔｈｒｅａｄ管理において時間を浪費しない。
【０２９７】
実時間パフォーマンス：ＴＩＣＣ−Ｐｐｄｅの任意のセルが実行する動作は３種類しか存在せず、（ｉ）ポートのポーリングと順受付け、（ｉｉ）ｐｔｈｒｅａｄ実行（ｒｕｎ）、および（ｉｉｉ）プロトコル実行である。２ギガヘルツのコンピュータでＴＩＣＣ−Ｐｐｄｅのポートをポーリングして並べ替えるのに１５〜３０ナノ秒しかかからない。メッセージ交換は自己スケジューリング、自己調和、および自己同期である。ｐｔｈｒｅａｄとセルの起動は自動スケジューリングされており、配信されたメッセージが検出された時や、ｓｏｒｔｅｄ−ｐｏｒｔｓ−ｌｉｓｔ（（２．１）を参照）によって指定されている順序でｐ：ｔｉｐ（）が実行される時にそれらは自動的に起動される。図９Ｂに示しているように、オペレーティングシステムはこれらの動作を実行するのには必要ない。全てのメッセージはそれらを送信する準備ができた時に即座に送信される。各セルはメッセージを準備ができた任意の時刻に他の各セルと並列に送信してもよい。
【０２９８】
これを実時間性能と呼ぶが、それは全ての利用可能な実時間がアプリケーションに関連している計算の実行に使用され、スケジューリング、調和、および同期セッション、または他の種類のオーバーヘッドに対して時間が無駄にされないためである。逐次バッファは使用されない。仮想メモリ構成は共有メモリ動作においてメモリ干渉を最小にする。これらによって、ＴＩＣＣ−Ｐｐｄｅ内の並列プログラムの効率的な実行が可能になる。図９Ａに示している従来の構成は、この種類の実時間性能を提供しない。
【０２９９】
予測可能性：複数の命令ストリーム実行（ｒｕｎ）［２９］、先読みスケジューリング［３０］、パイプライン処理［３１］、およびキャッシュされた実行［３２］などの確立されている高速化技法はスレッドの起動と実行の時間およびメッセージのディスパッチと配信の時間とを予測可能にする［Ｌｅｅ他，３３−３６］。これらの技法は、高いスループットを得るためにＴＩＣＣ−Ｐｐｄｅでは必要ない。ＴＩＣＣ−Ｐｐｄｅでは、メッセージ交換レイテンシとｐｔｈｒｅａｄ実行時間が予測可能である。ｐｔｈｒｅａｄ起動時間は限界付き制限時間内で予測可能である。タイミングは計算のイベントベースのＴＩＣＣ−Ｐｐｄｅモデル内に組み込まれている。
【０３００】
同期と調和：ＴＩＣＣ−Ｐｐｄｅはモニタ、セマフォ、またはランデブー技法［Ｈｏａｒｅ，１０，１２］［Ｄｉｊｋｓｈｔｒａ，２３，２４］を使用せずにアプリケーション内のイベントの調和と時間同期のための新規のメソッドを提供する。これらをセクション２と６の例に示しており、セクション６．６で説明する。
【０３０１】
イベントベースモデル：セクション６、７で説明するように、ＴＩＣＣ−Ｐｐｄｅの最も重要な特徴は、実装仕様から計算のイベントベースのモデルを自動的に生成することであって、これらのモデルはシンボリック評価によるシステムの静的な検証に使用され、また動的な自己監視システム（ＳＭＳ）にも使用される。これらの特徴はＴＩＣＣ−Ｐｐｄｅに固有である。イベントベースの意味論によって、ＴＩＣＣ−Ｐｐｄｅはマルチコアチップを使用し、キャッシュメモリが内場合に正確に時間が設定された動作を行う、実時間サイバー物理システムと埋め込みシステムの構築に適している。キャッシュメモリの排除と高速化技法の採用の必要性の排除とによって、マルチコアチップ内のＣＰＵの設計が簡単になる。
【０３０２】
ＡＬＬＥＯＰ証明を構築するために使用されるメソッドを説明する例に進む前に、ＴＩＣＣ内の計算と通信、イベントと因果関係、オブジェクト指向構成と表記の特徴を定義することは有用である。それを次のセクションで行う。
【０３０３】
５．名前、世界状態、評価子およびイベント
５．１．オブジェクト指向構造
名前の有限集合から始める。名前は有限なアルファベット内のシンボルの連結である。〈ｎａｍｅｓ〉がこの名前の集合を指すことにする。〈ｎａｍｅｓ〉内の各名前は何らかの一意のものを表す。名前によって表される項目はコンテナまたはオブジェクトと呼ばれる。ここでは３つの集合、〈ｎａｍｅｓ〉、〈ｃｏｎｔａｉｎｅｒｓ〉、および〈ｏｂｊｅｃｔｓ〉が存在する。〈ｎａｍｅｓ〉内の名前を指すためにメタシンボルｘ、ｙ等を使用する。ｘ、ｙ等で表されるコンテナを指すためにメタシンボルΔｘ、Δｙ等を使用する。この場合、ｘ．ｄｅｎｏｔｅｓ＝Δｘ、Δｘ．ｄｅｎｏｔｅｄＢｙ＝ｘと書き、ｘ∈〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉と呼ぶ。〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉、δｂ、δｃ等を具体的に指すためにメタシンボルｂ、ｃ等を使用する。ｂ．ｄｅｎｏｔｅｓ＝δｂ＝ｂ．ｖａｌｕｅおよびδｂ．ｄｅｎｏｔｅｄＢｙ＝｛ｂ｝＝δｂ．ｖａｌｕｅＯｆと書く。「｛ｂ｝」が使用されるが、一般に同じオブジェクトを指す名前が２つ以上存在することがある。〈ｏｂｊｅｃｔｓ〉∩〈ｃｏｎｔａｉｎｅｒｓ〉＝φおよび〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉∩〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉＝φ，（〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉∪〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉）＝〈ｎａｍｅｓ〉。表示は多−１マッピングによって定義され、〈名前〉→〈ｏｂｊｅｃｔｓ〉∪〈ｃｏｎｔａｉｎｅｒｓ〉である。δｘ≡ｘも可能であって、オブジェクトの値は名前自体と同一であってもよい。したがって、（〈ｏｂｊｅｃｔｓ〉∪〈ｃｏｎｔａｉｎｅｒｓ〉）∩〈ｎａｍｅｓ〉＝｛ｂ｜ｂ．ｖａｌｕｅ＝ｂ｝である。
【０３０４】
５〜６個のコンテナ名が同じコンテナΔｘを指している場合、これらの名前の１つ、例えば名前ｚをそのコンテナの区別されるコンテナ名に設定し、Δｘ．ｄｅｎｏｔｅｄＢｙ＝ｚと設定する。５〜６個のオブジェクト名が同じオブジェクトδｂを指す場合、δｂ．ｄｅｎｏｔｅＢｙ＝δｂ．ｖａｌｕｅＯｆ＝｛ｃ｜ｃ．ｖａｌｕｅ＝δｂ｝である。名前に対する以下の述語を定義する。ｘ：ｎａｍｅ？（）⇔ｘ∈〈ｎａｍｅｓ〉；ｘ：ｃｏｎｔａｉｎｅｒ？（）⇔ｘ．ｄｅｎｏｔｅｓｅ〈ｃｏｎｔａｉｎｅｒｓ〉。これはｘ∈〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉と言うのと同じである。ｘ：ｏｂｊｅｃｔ？（）⇔ｘ．ｄｅｎｏｔｅｓｅ〈ｏｂｊｅｃｔｓ〉。これはｘ∈〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉と言うのと同じである。３つの区別されているオブジェクトを使用し、それぞれ、ｔｒｕｅ、ｆａｌｓｅ、およびφと呼ばれ、δｔｒｕｅ＝ｔｒｕｅ、δｆａｌｓｅ＝ｆａｌｓｅおよびδφ＝φという性質があり、φは空のオブジェクトである。これらは、定数と呼ばれるが、それはこれらのオブジェクト名の値が決して変化しないためである。任意の名前ｘについて、ｘ：ｃｏｎｓｔａｎｔ？（）⇔ｘ∈〈ｃｏｎｓｔａｎｔ−ｎａｍｅｓ〉⊂〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉およびδｘ∈〈ｃｏｎｓｔａｎｔｓ〉⊂〈ｏｂｊｅｃｔｓ〉である。
【０３０５】
２つの名前が互いに同一である場合にだけ（ｘ≡ｙ）とアサーションし、（Δｘ≡Δｙ）または（δｘ≡δｙ）、つまりｘ．ｄｅｎｏｔｅｓ≡ｙ．ｄｅｎｏｔｅｓの場合には（ｘ（∽＝）ｙ）とアサーションする。（ｘ（∽＝）ｙ）を「ｘはｙと合同」と読むことができる。２つの名前ｘとｙは¬（ｘ（∽＝）ｙ）の場合に別個である。名前の２つの集合Ｓ１とＳ２について、［Ｓ１⊂Ｓ２⇔∀（ｘ∈Ｓ１）∃（ｙ∈Ｓ２）（ｘ（∽＝）ｙ）］＆［Ｓ１（∽＝）Ｓ２⇔Ｓ１⊂Ｓ２＆Ｓ２⊂Ｓ１］である。Ｓ１∩Ｓ２とＳ１∪Ｓ２とが同様に定義されている。
【０３０６】
各コンテナはオブジェクトまたは他のコンテナを含むことができるという特性を有している。Δｘ．ｃｏｎｔａｉｎｓ＝δｂまたはΔｘ．ｃｏｎｔａｉｎｓ＝Δｙ、¬（Δｘ≡Δｙ）と書く。オブジェクトは何も含むことができず、∀（δｘ）δｘ．ｃｏｎｔａｉｎｓ＝φである。Δｙ．ｃｏｎｔａｉｎｓ＝δｘの場合に、オブジェクトδｘはコンテナコンテナΔｙ内に存在すると言う。各オブジェクトは何らかのコンテナ内に存在しなければならず、自由なオブジェクトは存在しない。互いに同一であるが別個のコンテナに存在している２つのオブジェクトは互いに複製であると呼ぶ。
【０３０７】
Ｚ∈（〈ｎａｍｅｓ〉∪〈ｏｂｊｅｃｔｓ〉∪〈ｃｏｎｔａｉｎｅｒｓ〉）について、メソッドＺ：ｅｖａｌ（）：を定める。
【０３０８】
Ｚ：ｅｖａｌ（）＝［Ｚｅ〈ｏｂｊｅｃｔｓ〉？（）｛Ｚ｝｜Ｚｅ〈ｃｏｎｔａｉｎｅｒｓ〉？（）｛Ｚ．ｃｏｎｔａｉｎｓ：ｅｖａｌ（）｝
｜
Ｚ：ｏｂｊｅｃｔ？（）｛δＺ｝｜Ｚ：ｃｏｎｔａｉｎｅｒ？（）｛Δｚ：ｅｖａｌ（）｝］ （５．１）
【０３０９】
同一性：名前、オブジェクト、およびコンテナの同一性は以下のように定義される。
（（δｘ＝δｙ）⇔（δｘ≡δｙ））、（（Δｘ＝Δｙ）⇔（Δｘ≡Δｙ））および
（（ｘ＝ｙ）⇔（（ｘ≡ｙ）∨（ｘ：ｅｖａｌ（）≡ｙ：ｅｖａｌ（）≠φ））） （５．２）
同一性のこの定義は、集合Ｘについて（ｘ∈Ｘ）と定義し、集合ＸとＹについて、Ｘ＝Ｙ、Ｘ⊆Ｙ、Ｘ⊂Ｙ、Ｘ⊇Ｙ、およびＸ⊃Ｙと定義するために拡張可能である。ただし、ｘ：ｅｖａｌ（）＝φも可能である。しかし、空の値を有している名前は、互いに同一でなければ互いに等しくなることはできない。（ｘ（∽＝）ｙ）⇒（ｘ＝ｙ）であるが、逆は真ではなく、それは別個の名前は同じδｂの複製を評価するからである。
【０３１０】
コンテナΔｘをメモリセルと考え、コンテナ名ｘをこれらのメモリセルへのポインタ（アドレス）と考えることができる。各δｂを、オブジェクトｂを表しており、メモリセル内に存在しているコード化（ビット列）と考えることができる。ポインタはそのオブジェクトのコード化がそのポインタによって指されているメモリセル内に存在している場合にだけオブジェクトを指し、コンテナ（メモリセル）内のオブジェクトは他のメモリセル内に存在していることもあるそれらのオブジェクトの複製を変更する必要なしに修正可能である。用語「ｄｅｎｏｔｅｓ」、「ｖａｌｕｅＯｆ」、および「ｃｏｎｔａｎｓ」を属性と呼ぶ。用語「ｏｂｊｅｃｔ？（）」、「ｃｏｎｓｔａｎｔ？（）」、および「ｃｏｎｔａｉｎｅｒ？（）」を述語と呼び、「ｅｖａｌ（）」をメソッドと呼ぶ。名前に対して定義されているより多くの属性、述語、およびメソッドを以下の説明でそれらが出現した時に紹介する。
【０３１１】
順序付け：順序のある関係を備えているＳ⊂〈ｏｂｊｅｃｔｓ〉について、＜は要素、名前ｘとｙについて定義されている。
【０３１２】
（ｘ＜ｙ）⇔［ｘ：ｅｖａｌ（）∈Ｓ＆ｙ：ｅｖａｌ（）∈Ｓ＆ｘ：ｅｖａｌ（）＜ｙ：ｅｖａｌ（）］ （５．３）
φ∈Ｓのこともあり得る。通常の定義が（ｘ≦ｙ）、（ｘ＞ｙ）、および（ｘ≧ｙ）に当てはまる。
【０３１３】
構造体：ｂはインデックス付きの構造体を有しており、名前ｘについて、ｘ：ｅｖａｌ（）＝δｂの場合ｘ［ｉ］＝δｂ［ｉ］＝ｂ［ｉ］、ｉはｂのインデックスの範囲、そうでなければｘ［ｉ］＝φである。しかし、ｘ［ｉ］＝φはｉがｂのインデックスの範囲外にあることを意味せず、それはｂ［ｉ］＝φがあり得るからである。ｘ［ｉ］自身はインデックス付き構造体ｘ［ｉ］［ｊ］を有していてもよい。ｂがそれに対して定義されている属性ａｔｂｔを有する構造体の場合、ｘ．ａｔｂｔ＝ｂ．ａｔｂｔ＝δｂ．ａｔｂｔｄであって、ｂ．ａｔｂｔが定義されていない場合ｘ．ａｔｂｔ＝φである。ｂ．ａｔｂｔ自体が属性ａｔｂｔｉを有することも可能である。すると、ｘ．ａｔｂｔ．ａｔｂｔｉ＝ｂ．ａｔｂｔ．ａｔｂｔｉ＝δｂ．ａｔｂｔ．ａｔｂｔｉである。
【０３１４】
名前のグループ化：各名前ｘはそれに対して定義されているメソッドｘ：ｎａｍｅｓ（）を有しており、ｘ：ｎａｍｅｓ（）はｘに関連付けられている全ての名前の集合である。それは、ｘについて定義されている全ての属性、述語、およびメソッドについてｘ、ｘ．ａｔｔｒｉｂｕｔｅ、ｘ：ｐｒｅｄｉｃａｔｅ？およびｘ：ｍｅｔｈｏｄ（）を含み、さらに他の名前も含む。｛ｘ｝⊂ｘ：ｎａｍｅｓ（）であるため、空ではない。２つの別個の名前ｘとｙについて、ｘ：ｎａｍｅｓ（）∩ｙ：ｎａｍｅｓ（）≠φ；φ：ｎａｍｅｓ（）＝｛φ｝があり得る。任意のｘについて、［ｘ：ｎａｍｅｓ（）］と書かれるｘ：ｎａｍｅｓ（）の閉包を以下に示す。
【０３１５】
［ｘ：ｎａｍｅｓ（）］＝∪｛［ｙ：ｎａｍｅｓ（）］｜ｙ∈ｘ：ｎａｍｅｓ（）＆¬（ｙ（∽＝）ｘ）｝∪｛ｘ｝ （５．４）
【０３１６】
名前の型の設定：名前は、整数、数、文字列、集合、構造体、クラス等、それに関連付けられている型を有していてもよい。〈ｔｙｐｅ〉は全ての型名の集合である。メソッドｘ：ｔｙｐｅ（）は、名前ｘの型を取得するのに使用され、ｘ：ｔｙｐｅ（）＝Δｘ：ｔｙｐｅ（）＝ｘ：ｅｖａｌ（）：ｔｙｐｅ（）、およびｂ：ｔｙｐｅ（）＝δｂ：ｔｙｐｅ（）；φ：ｔｙｐｅ（）＝φである。各型は〈ｎａｍｅ〉内の名前の部分集合を指し、ｎａｍｅｓ（）＝｛ｘ｜ｘ：ｔｙｐｅ（）≡ｔｙｐｅ｝⊂ｚ〈ｎａｍｅ〉である。明らかに、ｔｙｐｅ：ｔｙｐｅ（）＝Δｔｙｐｅ：ｔｙｐｅ（）＝Δｔｙｐｅ．ｃｏｎｔａｉｎｓ：ｔｙｐｅ（）＝ｓｅｔである。（ｔｙｐｅｉ⊂ｔｙｐｅ２）⇔（Δｔｙｐｅ１．ｃｏｎｔａｉｎｓ⊂Δｔｙｐｅ２．ｃｏｎｔａｉｎｓ）の場合にだけｔｙｐｅ１はｔｙｐｅ２のサブ型である。したがって、（整数⊂数）が成り立つ。ｔｙｐｅ１とｔｙｐｅ２とは（ｔｙｐｅ１∩ｔｙｐｅ２）＝φの場合に別個である。一方が他方のサブ型でない２つの型は別個でなければならない。継承については、型／サブ型の階層、抽象的型等において通常ではない規約を使用する。
【０３１７】
システムＳのオブジェクト指向構造：ＷＳ（ｔ）をシステムＳの時刻ｔでの世界状態とする。
【０３１８】
ＷＳ（ｔ）＝（｛（ｘ，Δｘ）｜ｘ：ｃｏｎｔａｉｎｅｒ？（）＆ｘ．ｄｅｎｏｔｅｓ＝Δｘ＆ｘ∈Ｓ：ｎａｍｅｓ（）（ｔ）｝∪
｛（ｂ，δｂ）｜ｂ：ｏｂｊｅｃｔ？（）＆ｂ．ｄｅｎｏｔｅｓ＝δｂ＆ｂ∈Ｓ：ｎａｍｅｓ（）（ｔ）｝∪
｛（Δｘ，Δｘ．ｃｏｎｔａｉｎｓ）｜∃ｘ∃ｂ∃ｙ［（（ｘ，Δｘ），（ｙ，Δｙ），（ｂ，δｂ）∈ＷＳ（ｔ））＆
（ｘ，ｙ，ｂ∈Ｓ：ｎａｍｅｓ（）（ｔ））＆¬（Δｘ≡Δｙ）＆
（Δｘ．ｃｏｎｔａｉｎｓ＝δｂ∨
Δｘ．ｃｏｎｔａｉｎｓ＝Δｙ）］｝） （５．５）
【０３１９】
離散的な時刻だけを使用し、各時間点ｔは正の整数である。（ｔ１＜ｔ２）であれば、ＷＳ（ｔ’）が存在し、（ｔ１＜ｔ’＜ｔ２）であるような他の時間点ｔ’が存在しない場合に限り、ＷＳ（ｔ１）はＷＳ（ｔ２）の直前である。（ｘ，Δｘ）∈ＷＳ（ｔ）および∃（ｂ）（ｂ．ｄｅｎｏｔｅｓ＝ｘ：ｅｖａｌ（））をアサーションするためにｘ（ｔ）を使用する。したがってｘは常にコンテナ名である。ｘ：ｅｖａｌ（）＝φのこともあり得る。評価子（サブセクション５．３）が世界状態ＷＳ（ｔ）からトリプレット（ｘ，Δｘ，ｘｉｅｖａｌ（））にアクセスした場合、アクセス述語ｘ（ｔ）はｔｒｕｅであると言う。他のイベント述語は、ＷＳ（ｔ）で（ｘ＝ｙ）がｔｒｕｅであることがわかったことをアサーションする（ｘ＝ｙ）（ｔ）および、同様に、（ｘ＜ｙ）（ｔ）、（ｘ＞ｙ）（ｔ）、（ｘ≦ｙ）（ｔ）、または（ｘ＞ｙ）（ｔ）である。述語関連の集合も使用され、（ｘ∈Ｙ）（ｔ），（Ｘ⊂Ｙ）（ｔ）等である。述語には順序付けがあり、（ｔ１＜ｔ２）の場合にだけｘ（ｔ１）＜ｘ（ｔ２）である。ただし、（ｘ＜ｙ）（ｔ）はｘ（ｔ１）＜（ｔ２）と同じではない。（（ｘ＜ｙ）（ｔ１）＜（ｘ１＜ｙ１）（ｔ２））のこともあり得る。時間パラメータは重要ではない場合は省略される。
【０３２０】
Ｓ：ｃｅｌｌｓ（）がシステムＳ内のすべてのセルの集合を示すとする。セルＣのポートＣ．ｐについて、Ｃ．ｐ．ｐａｔｈｗａｙはＣ．ｐに接続されている一意の経路、Ｃ．ｐ．ｐａｔｈｗａｙ．ｖＭ＝Ｍ＝Ｃ．ｐ．ＭはＣ．ｐ．ｐａｔｈｗａｙの一意の仮想メモリ、Ｍ．ａｇ［ｉ］はＭに付属しているｉ番目のエージェント、Ｍ．ｐｒｔ［ｉ］はＭに対してチューンされているｉ番目のポート、ｃ．ｐ．ｎｄＦｓｍはＣ．ｐで定義されているｄｎＦＳＭ、Ｃｐ．ａ．ｎｄＦｓｍはＣ．ｐ．ａで定義されているｎｄＦＳＭ、Ｃ．ｖＭｓ＝｛Ｃ．ｐ．Ｍ｜（Ｃ．ｐ．ａｔｔａｃｈｅｄＴｏ Ｃ）｝である。Ｃ．ｐがｄｍ経路に接続されている場合、Ｃ．ｐ．ｐａｔｈｗａｙ．ｖＭはｄｍ経路Ｃ．ｐ．ＭｅＣｐ．ｐａｔｈｗａｙ．ｖＭ内の全ての仮想メモリのベクトルである。最後に、ａ．ｐｒｔ［ｉ］はエージェントａに対してチューンされているｉ番目のポートであって、ａ．ｎｘｔ［ｉ］はエージェントａに対してチューンされているｉ番目の次のエージェントである。ベクトルＭ．ｐｒｔ＝∪［Ｍ．ａｇ［ｉ］．ｐｒｔ｜０≦ｉ＜Ｍ．ａｇ：ｓｉｚｅ（）］である。エージェント、仮想メモリ、およびポートは経路コンポーネントである。以下の名前がＣ．ｐ，ｐａｔｈｗａｙに関連付けられている。
【０３２１】
Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）＝
Ｃ．ｐ．Ｍ：ｎａｍｅｓ（）∪∪｛Ｃ．ｐ．Ｍ．ａｇ［ｉ］：ｎａｍｅｓ（）｜０≦ｉ＜Ｃ．ｐ．Ｍ．Ａｇ：ｓｉｚｅ（）｝∪
ｕ｛Ｃ．ｐ．Ｍ．ｐｒｔ［ｉ］．ｎｄＦＳＭ：ｎａｍｅｓ（）｜０≦ｉ＜Ｃ．ｐ．Ｍ．ｐｒｔ：ｓｉｚｅ（）｝ （５．６）
ここでＣ．ｐ．Ｍ：ｎａｍｅｓ（）はＣ．ｐ．Ｍ内に存在しているメッセージ内で定義されている全ての名前を含んでいる。ただし、全てのＣ．ｐ．Ｍ：ｎａｍｅｓ（）がＣ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）内には存在せず、Ｃ．ｐ．Ｍ．ｐｒｔ［ｉ］．ｎｄＦＳＭ：ｎａｍｅｓ（）だけが含まれている。セクション６．２で説明するように、各仮想メモリは４つのコンポーネントを有している。ｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙと呼ばれるそれらの２つはメッセージを含んでいる。所与の任意の時刻において、これら２つのコンポーネントは高々１つのメッセージを有している。セルＣに付属している各ポートＣ．ｐについて、
Ｃ．ｐ．ｎｄＦｓｍｉｎａｍｅｓ（）⊂Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（） ５．７）
Ｃ．ｐ．ｎｄＦｓｍｉｎａｍｅｓ（）⊂Ｃ．ｐ：ｎａｍｅｓ（）⊂Ｃ：ｎａｍｅｓ（） （５．８）
したがって、Ｃ：ｎａｍｅｓ（）とＣ．ｐ：ｎａｍｅｓ（）とはＣ．ｐ．ｐａｔｈｗａｙ内の全ての名前を含んでおらず、Ｃ．ｐ．ｎｄＦｓｍｉｎａｍｅｓ（）だけを含んでいる。任意の２つの経路、別個のセルＣ１、Ｃ２、任意の２つのポートｐとｑについて以下が成立する。
【０３２２】
Ｃ１：ｎａｍｅｓ（）∩Ｃ２：ｎａｍｅｓ（）＝φ （５．９）
（ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）（∽＝）ｑ．ｐａｔｈｗａｙ：ｎａｍｅｓ（））⇔（ｐ⇔ｑ） （５．１０）
¬（ｐ⇔ｑ）⇔（（ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）∩ｑ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）＝φ） （５．１１）
ここで（ｐ⇔ｑ）はｐとｑとが経路によって接続されていることをアサーションする。ただし、合同関係「（∽＝）」が（５．１０）で使用されている。（５．１１）の場合、経路は別個であると言う。別個のセルと別個の経路はコンテナを共有しない。システムＳのＳ：ｎａｍｅｓ（）の名前の不変の（つまりコンパイル時）オブジェクト指向構造を以下のように定義する。
【０３２３】
Ｓ：ｎａｍｅｓ（）＝
∪｛Ｃ：ｎａｍｅｓ（）｜Ｃ∈Ｓ：ｃｅｌｌｓ（）｝∪
∪｛Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）｜Ｃ∈Ｓ：ｃｅｌｌｓ（）＆（ｐａｔｔａｃｈｅｄＴｏＣ）｝ （５．１２）
世界状態はｃｅｌｌ：ｎａｍｅｓ（）とｐｏｒｔ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）に区分され、ｐｏｒｔ．ｎｄＦｓｍ：ｎａｍｅｓ（）においてだけ互いに重なる。この重なりによって、経路に接続されており、セルに付属しているポート間の通信を可能にする。この構造の詳細化を使用して、メソッドの定義を促進する。ｄｍ経路の場合、経路のｎｄＦｓｍ：ｎａｍｅｓ（）で示されるコンテナは信号線によって互いに接続されており、仮想メモリ内のコンテナはデータ線によって接続されている。信号とデータはコンテナ間でこれらの線を介して交換され、プロトコル内のＣＣＰが調和させる。
【０３２４】
５．２．条件とＣＴＬステートメント
信号を試験する述語と述語表現を指すために用語「ガード」を使用し、ポートとエージェントの状態を記述する述語と述語表現とを指すために用語「状態」を使用し、全ての述語と述語表現とを指すために「条件」を使用する。条件は論理結合子と量化子を備えている述語を含んでいる任意の適切に定義されている１階表現つまり述語のブール表現である。すべての条件は、添え字「？（）」で終了する。量化子は無限の集合を対象としている。条件はｘ：ｎａｍｅｓ（）の名前によって定義されている世界で常に評価され、ｘはセル、ポート、エージェント、仮想メモリ、またはメッセージである。
【０３２５】
ＣＴＬステートメント（因果時間論理ステートメント）は、通常の論理結合子、時間モード演算子、□（常に）、◇（最終的に）、因果結合子→、・→（以下で説明）を備えており、量化子、∀と∃を使用し、通常の構文を備えている、質、順序、アクセス、イベントインスタンス述語の任意の組み合わせである。否定は、個別の述語とイベントインスタンスとにだけ現れ、表現全体に対しては現れない。否定されたイベントインスタンスは、「イベントインスタンスは発生してはならない」と解釈される。以下で説明するように、イベントインスタンスは定数の状態を有しており、２つのイベントインスタンスは互いに同一な場合にだけ互いに等しい。量化された変数、ｉｎ、∀、および∃はＣＴＬステートメントに現れるインスタンス、仮想時間点、および他のオブジェクトを対象としている。通常、量化子は、既知の有限集合を対象としている。ここではＣＴＬステートメントの構文については説明しない。以前のセクションでＡＬＬＥＯＰとトレースの記述に使用したステートメントはＣＴＬステートメントである。さらなる例が後のセクションに現れる。証明には、ＣＴＬステートメントで論理推論を実施することは伴わないが、所与のＥＣＴネットワーク上でのＣＴＬステートメントのシンボル評価だけを伴う。ＥＣＴネットワークの例をセクション６に示す。
【０３２６】
５．３．評価子、イベント、因果関係
評価子と呼ばれる構造化されている定数がある。システムは、任意のしかし有限の数の評価子Ｅ［ｉ］、０≦ｉ＜Ｎを有していてもよい。説明の中で明示的に評価子に触れる必要は無い。しかし概念は重要である。ＴＩＣＣ−Ｐｐｄｅにおいて、各セルに関連付けられている評価子（ＣＰＵ）が存在し、全ての評価子がメッセージ交換によってのみ相互動作しながら並列に動作する。ＥＣをセルＣの評価子とする。評価子は、名前、コンテナ、オブジェクト、コード化の生成／破壊、コード化の修正、コード化のコンテナ内への配置、コンテナの他のコンテナへの配置、オブジェクト／コンテナの１つのコンテナから他のコンテナへの移動、コンテナの１つの名前から他の名前への移動、アクセス権のコンテナへの設定、オブジェクト（そのコード化）への世界状態からのアクスによって計算を実施する。アクションイベントとアクセスイベントとが存在する。したがって、評価子によって実施される計算によって、アクセスとアクションイベントとが発生する。評価子ＥＣが名前ＸにＷＳからアクセスした場合、トリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））をＥＣ：ａｃｃｅｓｓｅｄＩｔｅｍｓリストに追加する。評価の最後に、ＥＣ：ａｃｃｅｓｓｅｄＩｔｅｍｓ内の要素を使用してＷＳの整合した更新を実施し、それからそのプライベートＥＣ：ａｃｃｅｓｓｅｄＩｔｅｍｓリストを破壊する。
【０３２７】
名前ｘは、ｘ（ｔ）がｔｒｕｅ（ｆａｌｓｅ）の場合に世界状態ＷＳ（ｔ）において生成（破壊）されるが、直後のＷＳ（ｔ’）においては、ｘ（ｔ’）はｆａｌｓｅ（ｔｒｕｅ）である。一般的な規約では、述語は、述語がＷＳ（ｔ１）でｔｒｕｅのようなｔ１≦ｔ２が存在し、述語がＷＳ（ｔ’）でｆａｌｓｅのようなｔ１＜ｔ’≦ｔ２が存在する場合、ＷＳ（ｔ２）においてｔｒｕｅである。したがって、破壊されるまで世界状態に名前が存在し、述語は変更されるまでその真理値を維持する。
【０３２８】
アクセス権、データ保護、および通信
通信と計算との間の唯一の差は、通信プロトコルはポート、エージェント、および仮想メモリに関連付けられているすでに定義されているコンテナ内のオブジェクト（データ）を生成／修正するだけである。コンテナの生成／破壊はできない。これは、それらが宣言を含んでいないからである。仮想メモリ内のメッセージや他のデータを修正することはできない。したがって、通信は信号以外にアクセス権を評価子に転送することが異なる以外に、通信は計算の制限された形態に過ぎない。評価子ＥＣについては、ＥＣ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）は全ての名前の集合を指定し、ＥＣは時刻ｔにアクセス可能である。ＥＣ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）は以下のように定義される。
【０３２９】
ＥＣ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）＝
ＥＣ．：ｎａｍｅｓ（）∪Ｃ：ｎａｍｅｓ（）∪
∪｛（Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）（ｔ）｜（Ｃ．ｐ．ｓｔａｔｅ＝Ｓ）（ｔ）｝ （５．１３）
Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）は時間の関数であるが、それは、経路の仮想メモリが異なるメッセージを異なる時刻に含んでおり、また、経路は動的に変化するからである。Ｃ．ｐ．ｐａｔｈｗａｙ内の名前についてのアクセス権は、Ｃ．ｐが状態Ｓにある時にだけＥＣに転送される。図１と２に示しているように、メッセージが検知されるかポートがメッセージの送出の準備ができている時にポートは常にその状態をＳに変更する。したがってＴＩＣＣにおいて、通信は、必要な時に適切な時刻に、自動的にアクセス権を評価子に転送する。これらのアクセス権はＣ．ｐの状態がＳから他の何らかの状態に変化した場合に、自動的に取り消される。
【０３３０】
評価子はアクション、イベント、および名前を評価できる特性を有している。アクションは常にメソッド、プロトコル、または条件であるか、宣言、割り当て条件（ｉｆ−ｔｈｅｎ−ｅｌｓｅやｓｅｌｅｃｔＯｎｅなど）、またはｗｈｉｌｅループなどの単にプログラミング言語内のステートメントである。セル、メッセージ、ポート、エージェント、または仮想メモリ内で定義されているメソッド内に現れる宣言ｙ：Ａ（）は、宣言されている名前ｘについてトリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））をｙ．Ａ：ｗｏｒｌｄ（）（ｔ）に導入する。名前をｙ．Ａ：ｗｏｒｌｄ（）（ｔ）から破壊し取り除くために宣言も使用する。さらに、ｙ．Ａ：ｗｏｒｌｄ（）（ｔ）は｛（ｘ，Δｘ，ｘ：ｅｖａｌ（））｜∃（Ｘ）（Ｘｃ（ｙ：ｎａｍｅｓ（）∪Ａ：ｎａｍｅｓ（））＆（ｘ∈Ｘ：ｎａｍｅｓ（）））｝を含んでおり、ｙ．Ａ：ｗｏｒｌｄ（）（ｔ）はｙ．Ａ（）のコードを含むことになり、またｙ．Ａ（）が実行された時に動的に生成される名前を含んでもよい。プロトコルはアクションであるが宣言を含まずＣＣＰを含むところが異なる。メソッドはＣＣＰを通常含まない。
【０３３１】
アクセス評価について→aを、アクション評価のために→ｅを以下の表記と共に使用する。
【０３３２】
時刻ｔ：［〈→ａｘ〉（ｔ）］にアクセスが完了 アクセスが時刻ｔ：［→ａｘ（ｔ）］に始まる （５．１４）
時刻ｔ：［〈→ｅｘ〉（ｔ）］にＥｖａｌが完了 Ｅｖａｌが時刻ｔ：［→ｅｘ（ｔ）］に始まる （５．１５）
時刻ｔ：〈ｘ：Ｃ？（）〉（ｔ）にＥｖａｌが完了： Ｅｖａｌが時刻ｔ：ｘ：Ｃ？（）（ｔ１）に始まる：［→ｅｘ（ｔ）］ （５．１５）
評価子を名前ｘ、アクションｘ：Ａ（）、または条件ｘ：Ｃ？（）に適用すると、新しいイベント（以下で説明）が発生し、それが今度は他の評価と他のイベントの発生の原因となる。そのため、→ａと→ｅとを因果関係と呼ぶ。それらは、非再帰的、非対称、および推移的である。評価はイベントを発生させるだけでなく、以下で説明するようにｃｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔも評価する。
【０３３３】
時間インスタンスについての注記：２つの時間インスタンスｔ１とｔ２とが比較不能なことがあり得るが、それはそれらが異なる評価子の互いに同期していないローカルクロックで計測されているからである。しかし、各クロック時刻はグローバル時刻への一意の１−１マッピングを有している。ｘ．ｔ１、ｙ．ｔ２を使用して２つの異なるオブジェクトｘとｙに関連付けられているローカル時間点を参照する。不等式（ｘ．ｔ１＜ｙ．ｔ２）はｘとｙの両方が同じセルに属している場合に、ｘとｙのローカル時間で成立する。そうでなければ、（ｘ．ｔ１＜ｙ．ｔ２）は時間点ｘ．ｔ１とｙ．ｔ２の指定されたグローバルクロック内のグローバル時間へのマッピングにのみに相対的に成立する。５〜６個のローカルクロック時間点は同じグローバル時間点にマッピングすることが可能で、したがって、５〜６個のイベントが異なる別個のセルで各々が異なるローカル時刻で、しかし全てが同じグローバル時刻で発生する。全ての時間点は整数＞０にマッピングされる別個の時間点である。
【０３３４】
アクセス評価：前述のように、表記ｘ（ｔ）を評価子が世界状態ＷＳ（ｔ）からトリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））を取得するイベントを示すために使用している。明らかに評価子Ｅはｘに、それに対するアクセス権、つまりｘ∈Ｅｃ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）、を有していた場合にだけアクセスできる。したがって、評価子がｘにアクセスすると、閉包、［ｘ：ｎａｍｅｓ（）］内の全ての名前にアクセスできることになる。以下では、評価子→ａと→ｅを定義する。必要に応じて評価を行う評価子を明示的に指すように、Ｅ→ａとＥ→ｅと書く。アクセス評価はここで以下のように定義できる。
【０３３５】
□∃（τ＞０）［｛（ｘ，Δｘ）∈ＷＳ（ｔ）＆ｘ∈Ｅ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）｝［Ｅ→ａｘ（ｔ）］
｛ＷＳ（ｔ）＝ＷＳ（ｔ＋τ）＆ｘ（ｔ＋τ）｝］、ここで
ｘ（ｔ＋τ）＝［〈ｘ，Δｘ，ｘｉｅｖａｌ（）〉∈Ｅ．ａｃｃｅｓｓｅｄＩｔｅｍｓ）（ｔ＋τ）＆
（［ｘ：ｎａｍｅｓ（）］⊂Ｅ．ｈａｓＡｃｃｅｓｓＴｏ）（ｔ＋τ）］ （５．１７）
アクセスを完了するには何らかの時間τ＞０が常にかかる。アクセスが成功すれば、それによってイベントｘ（ｔ＋τ）がｔｒｕｅになる。ここで、アクションは世界状態ＷＳを変化させることはなく、ローカル状態Ｅだけが変化する。ｘが時刻（ｔ＋τ）にいったんアクセスされると、（ｘ，Δｘ，ｘ：ｅｖａｌ（））がＥ．ａｃｃｅｓｓｅｄＩｔｅｍｓに時刻（ｔ＋τ）に入り、Ｅは閉包〈［ｘ：ｎａｍｅｓ（）］＞（ｔ＋τ）内の全ての名前へのアクセス権を得る。（５．１７）の事前条件が満たされない場合は、アクセスの試みはφを返す。世界状態の述語は変更されない限り常にその真理値を保持しているという規約を使用するので、（５．１７）でフレームステートメントＷＳ（ｔ）＝ＷＳ（ｔ＋τ）を指定する必要は無い。ここで、評価子のローカル状態は世界状態とは別個であると仮定し、したがって、前述のようにトリプレット内のコンポーネントが関係構造を世界状態内で構成しても、Ｅ．ａｃｃｅｓｓｅｄＩｔｅｍｓに現れるトリプレットは世界状態には表れることがない。
【０３３６】
アクション評価：アクション評価、Ｅ→ｅは以下のように定義される：名前ｘについて、
［Ｅ→ｅｘ（ｔ）］＝［Ｅ→ａｘ（ｔ）］＝ｘ（ｔ）、またアクションｘ：Ａ（）については、（５．１８）
｛〈ｘ．Ａ：ｐｒｅＣ？（）＆∃（Ｓ）∀（ｙ∈Ｓ）［（Ｓ⊆ｘ．Ａ：ｗｏｒｌｄ（））＆
〈（（ｙ，Δｙ，ｙ：ｅｖａｌ（））∈Ｅ．ａｃｃｅｓｓｅｄＩｔｅｍｓ）〉（ｔ）］｝
Ｅ→ｅｘ：Ａ（．．．）（ｔ）］｛（ｘ．Ａ．ｏｕｔｐｕｔ（ｔ＋τ）＆ｘ．Ａ：ｐｓｔＣ？（）（ｔ＋τ）｝ （５．１９）
ここで、ｘ．Ａ：ｐｒｅＣ？（）は、ｘ．Ａ（）の事前条件の一部である。その他の部分は、ｘ．Ａ：ｗｏｒｌｄ（）の全ての必要な名前にアクセスしなければならないということである。同様に、ｘ．Ａ：ｐｓｔｃ？（）はアクションの事後条件の一部である。これは世界状態ＷＳのｘ：Ａ（）の実行によって発生する変更を指定する。事後条件のその他の部分は、ｘ．Ａ．ｏｕｔｐｕｔであって、Ｘ：Ａ（）によって生成された出力である。それはφの可能性もある。条件ｘ．Ａ：ｐｒｅＣ？（）と事前条件の全ての指定されたアクセスとはｘ：Ａ（）の評価が成功するにはｔｒｕｅでなければならない。評価は成功して世界状態（ｔ＋τ）で事後条件が成立すれば正しい。アクセスイベントと状態チェックの発生が世界状態を変更しないため、評価は事前条件がｔｒｕｅである同じ世界で実施することができる。このアクションの評価の文脈は、ｘ．Ａ：ｗｏｒｌｄ（）（ｔ）の部分集合Ｓである。
【０３３７】
以降では、上付き文字Ｅと下付き文字ａとｅとを、Ｅ→ａとＥ→ｅとで省略し、→ａは矢印に含まれると仮定し単に→と書く。定数Ｃについて、常に（→ｅＣ）＝（→ａＣ）＝δＣであって、既定で、何らかの定数が全ての世界状態に常に存在していることが暗示的に仮定されている。以降では、アクセス評価Ｅ→ａを参照する機会はない。
【０３３８】
ｐｔｈｒｅａｄはメソッドで、アクションの部分集合である。メソッドは４種類のプログラミングステートメント、宣言、割り当て、条件（ｉｆ−ｔｈｅｎ−ｅｌｓｅやｓｅｌｅｃｔｏＯｎｅなどのような）、およびｗｈｉｌｅループを使用して定義される。宣言によってコンテナとオブジェクトが生成／破壊され、新しく生成されたコンテナのコンテンツが設定され、トリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））がメソッド、ｗｏｒｌｄ（）にコンパイル時／実行時に導入されたり削除されたりする。メソッド定義内の他のステートメントによってオブジェクトとコンテナが修正されたり、コンテンツがあるコンテナから別のコンテナに移動したり、名前の表示が変更されることがある。メソッドは、その実行中にｗｏｒｌｄ（）内のローカル状態だけを変更する。評価子はその実行の最後に、ローカル状態を使用して世界状態ＷＳ（ｔ）の整合性のある更新を実施する。ＷＳ（ｔ）は（５．１１）に定義されているように区分されているので、セルの分離（セクション３．２）はＷＳ（ｔ）に対する複数の並列の更新が並列に動作しているセルによって相互干渉無しに行われることを保証する。メソッドの定義に現れるプログラムステートメントの意味は容易に定義することができる。意図した意味を読者が知っていると仮定して、プログラムステートメントを非正式に使用する。プロトコルで使用されるＣＣＰの特徴を図１と２に示している。ｐｔｈｒｅａｄとプロトコルで使用されるほとんどのステートメントについて、ＴＩＣＣ−Ｐｐｄｅは所与の文脈において関連付けられている事前と事後の条件を自動的に生成することができるが、特定の事前条件とループ不変式の定義にはユーザ相互動作が必要なこともある。
【０３３９】
５．４．表記と定義：ＡＬＬＥＯＰノードの評価
セクション２でＡＬＬＥＯＰとトレースで発生するアクションと通信のイベントの例を見た。以下では、ＡｃｔｉｏｎＥｖｅｎｔクラスにシンボルＸ、Ｙ、Ｚを使用し、ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔクラスにシンボルＸ［ｔ（）］、Ｙ［ｔ（）］、Ｚ［ｔ（）］を使用する。これらのイベントクラスはＡＬＬＥＯＰノードを参照する。それらはＥｖｅｎｔと呼ばれるトップレベルクラスのサブクラスである。イベントインスタンスを示すためにシンボルＸ（ｔ）、Ｙ（ｔ）、Ｚ（ｔ）を使用し、Ｘ（ｔ）は時刻ｔに発生したインスタンスｘを示す（図６Ｂを参照）。ｘ（ｔ）がＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔサブクラス、Ｘ［ｔ（〈ｐｏｒｔ〉，＃）］のインスタンスの場合、ｔ∈ｔ（〈ｐｏｒｔ〉，＃）．ｘ（〈ｐｏｒｔ〉．ｔ＃）はトレース内の仮想時間点〈ｐｏｒｔ〉．ｔ＃＝ｔ（〈ｐｏｒｔ〉，＃）でのＸ［ｔ（〈ｐｏｒｔ〉，＃）］のインスタンスの発生を指す（たとえば、（２．１８）のトレースを参照）。アプリケーションの実行（ｒｕｎ）中に、ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔサブクラス、Ｘ［ｔ（〈ｐｏｒｔ〉，＃）］の複数のインスタンスが因果律網内で発生することがある。その因果律網内でそれらのインスタンスが発生する時間点の集合は、アプリケーションのその実行についての厳密に増加する時間点のシーケンスｔ（〈ｐｏｒｔ〉，＃）＝〈ｐｏｒｔ〉．ｔ＃を構成する（図６Ｃを参照）。
【０３４０】
通信イベント：セクション２で使用された「送信」コマンドの「転送」バリエーションを以下で導入する。以下では、ｐ，ｑ＝（ｇ｜ｆ），ｐ≠ｑである。
【０３４１】
ｐＤ［ｔ（ｑ，＃）］：ポートｑによってｔ（ｑ，＃）内の時間点においてポートｐにメッセージが配信される。
【０３４２】
ｐＳ［ｔ（ｐ，＃）］：ｐによってｔ（ｐ，＃）内の時間点においてメッセージが送信される。
【０３４３】
ｐＦ［ｔ（ｐ，＃）］：ｐによってｔ（ｐ，＃）内の時間点においてメッセージが転送される。
転送によって、受信したメッセージが（場合によっては何らかの修正を伴って）送信され、送信によって新規に作成されたメッセージが送信される。正確な区別はセクション６．２で説明する。以下では、［→ｐＳ｜Ｆ（ｔ０）］は時刻ｔ０に始まったポートｐでのメッセージ（送信｜転送）プロセスにおける第１のイベントを指し、［→ｐＳ｜Ｆ（ｔ１）］は時刻ｔ１（ｔ０＜ｔ１）でのそのイベントの終了を指す。以下の特徴がプロトコル実行とガード評価中のＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔ評価について成立する。
【０３４４】
∃［（ｔ０＜ｔ１）
１．｛〈ｇ：ｐＲ？（）〉（ｔ０）｝［→ｇＳ｜Ｆ（ｔ０）］｛〈ｇ．ｓｔａｔｅ＝Ｒ＆ｇ．ｉｎｐｕｔ＝ｃ｜ｆ〉（ｔ１）｝
２．｛〈ｆ．ｓｔａｔｅ＝Ｒ〉（ｔ０）｝［→ｆＤ（ｔ０）］｛〈ｆ．ｉｎｐｕｔ＝ｓ＆ｆ．ｓｔａｔｅ＝Ｒ〉（ｔｉ）｝
３．｛〈ｆ．ｉｎｐｕｔ＝ｓ〉（ｔ０）｝［→ｆ：ｍＲ？（）（ｔ０）］｛〈ｔｒｕｅ＆ｆ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝
４．｛〈ｆ．ｉｎｐｕｔ＝ｓ∨ｆ．ｓｔａｔｅ＝Ｓ〉（ｔ０）｝［→ｆ：ｐＲ？（）（ｔ０）］
｛〈ｔｒｕｅ＆ｆ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝］
５．｛〈ｇ．ｉｎｐｕｔ＝ｓ〉（ｔ０）｝［→ｇ：ｍＲ？（）（ｔ０）］
｛〈ｔｒｕｅ＆ｇ．ｉｎｐｕｔ＝φ＆ｇ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝
６．｛〈ｇ．ｉｎｐｕｔ＝ｓ∨ｇ．ｓｔａｔｅ＝Ｓ〉（ｔ０）｝［→ｇ：ｐＲ？（）（ｔ０）］
｛〈ｔｒｕｅ＆ｇ．ｉｎｐｕｔ＝φ＆ｇ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝］ （５．２０）
前述のステートメントはプロトコル実行の最初と最後に何が発生するかと、配信信号が検知された時に何が発生するかを記述している。行（１）は最初に、ポートｇの親セルが信号ｃ｜ｆをポートｇにｇがメッセージの送信の準備ができている場合に送信することを指定している。行（６）は、状態がＳの場合または入力がｓの場合にｇの準備ができることを示している。信号が送信された直後に、ポートｇの段階がＲに変化し、ｇ．ｉｎｐｕｔがｃ｜ｆに等しくなる。状態Ｒの間は、ｇは第２の信号を送信できない。同様に、行（２）はプロトコル実行においてメッセージ配信の時刻に何が発生するかを記述しており、ここで「→ｆＤ（ｔ０）」はポートｆでの配信イベントである。これは時刻ｔ０で始まり、時刻ｆ．ｉｎｐｕｔ＝ｓがｔｒｕｅになった時に終了する。行（３、４、５、および６）はポートｆとｇの既に配信されている信号が後に検知された時に何が発生するかを記述している。ただし、行（５と６）で、ｇ．ｉｎｐｕｔがφにリセットされる。したがって、配信された信号は、ポートｇで１度だけ検知される。前述のように、このリセットｇ．ｉｎｐｕｔ＝φは、一般ポートベクトルに属している一般ポートについては発生しない。全ての場合において、信号の検知後に、ポートは状態Ｓになり、それによってポートの親セルがそのポートの仮想メモリ内のデータにアクセスできるようにする。ポートが信号の送出の準備がいったんできると、行（１）と行（３）で定義しているように信号が送出されるまで準備できた状態のままである。
【０３４５】
ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔの評価については他の解釈がある。ＳＭＳ（セクション７）はイベント評価を使用して、ＡＬＬＥＯＰノードのインスタンスをアプリケーションの実行（ｒｕｎ）中にアプリケーションの拡大している因果律網にインストールする。これは、以下の（５．２１）と（５．２２）で定義されている。図１９はイベント構築セルｅｂを示している。ｅｂが評価子、→をＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔに適用すると、ｅｂはそのイベントのインスタンスを特定に時間点で作製し、それを因果律網にインストールする。各ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔはそれに関連付けられている２つの時間点を有しており、一方はイベント自体が発生した時間（これは重要）で、他方はそのインスタンスが因果律網内にインストールされる時間（これは重要ではない）である。これら２つの時間点の使用を以下で説明する。
【０３４６】
以下の（５．２１）と（５．２２）において、［ｅｂ．ｆ１，ｅｂ．ｆ２］は図１９のイベントビルダーセルｅｂのポートベクトルであって、Ｃｉ．ｇｉとＣｊ．ｇｊ、０≦ｉ＜ｎ、０≦ｊ＜ｍとはメッセージを交換するポートである。セルＣｉはメッセージを送信し、それをポートＤｊ．ｆｊに転送するためにＣｉ．ｇｉでプロトコルを評価する。このプロトコルの実行はＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔ、Ｃｉ．ｇｉＳ（ｔＳ）と〈Ｄｊ．ｆｊＤ〉（ｔｄ）の評価のきっかけとなり、ここでｔＳはメッセージ送信が始まった時刻であり、ｔｄはメッセージ配信が完了した時刻である。前述のＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔの評価が以下のように定義される。
【０３４７】
□[∃（ｔ１＜ｔ２）∃（ｔｓ＜ｔｄ）]
｛〈ｅｂ．ｆ１：ｍＲ？（）＆ｅｂ．ｆ２：ｍＲ？（）〉（ｔ１）｝
［→（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））（ｔ１）］
｛〈Ｃｉ．ｇｉＳ（ｔＳ）＆〈Ｄｊ．ｆｊＤ〉（ｔｄ）〉（ｔ２）｝ （５．２１）
プロトコル実行（ｒｕｎ）中に、ｅｂセルにＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔのインスタンス（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））を生成するように指示する信号がポート［ｅｂ．ｆｌ，ｅｂ．ｆ２］に送信される。これがどのように行われるかをセクション７で説明する。（５．２１）において、ｅｂはポート［ｅｂ．ｆｌ，ｅｂ．ｆ２］で時刻ｔ１に受信した信号の検知を完了する。これはｅｂが（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））の評価を開始する時刻でもある。これによって、イベントインスタンス（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））が時刻ｔ２に因果律網内にインストールされる。ここで、ｔＳはＣｉ．ｇｉＳによって送信された信号に対応する調和した信号が経路内のエージェントによって転送される時刻であって、ｔｄは同期した配信信号がＤｊ．ｆｊＤにおいて送信される時刻である。
【０３４８】
□[∃（ｔ１＜ｔ２）∃（ｔｓ＜ｔｄ）]
｛〈ｅｂ．ｆ１：ｍＲ？（）＆ｅｂ．ｆ２：ｍＲ？（）〉（ｔ１）｝
［→（Ｄｊ．ｆｊＳ（ｔＳ）、〈Ｃｉ．ｇｉＤ〉（ｔｄ））（ｔ１）］
｛〈Ｄｊ．ｆｊＳ（ｔＳ）＆〈Ｃｉ．ｇｉＤ〉（ｔｄ）〉（ｔ２）｝ （５．２２）
（５．２２）は応答メッセージ送信のために因果律網内にインストールされたイベントを記述している。以降ではイベントが発生した時間点だけをＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンスに関連付け、インスタンスが因果律網内にインストールされた時間点は示さない。これは、時間点をＡｃｔｉｏｎＥｖｅｎｔインスタンスに関連付ける方法と整合している。
【０３４９】
Ｅｖｅｎｔクラスとイベントインスタンスの同等性：
（Ｘ＝Ｙ）⇔（Ｘ≡Ｙ）かつＸ［ｔ１（．．．）］＝Ｙ［ｔ２（．．．）］⇔（Ｘ≡Ｙ）＆（ｔ１（．．．）≡ｔ２（．．．）） （５．２３）
（Ｘ＝Ｙ）⇔（Ｘ≡Ｙ）かつＸ（ｔ１）＝Ｙ（ｔ２）⇔（Ｘ≡Ｙ）＆（ｔ１＝ｔ２） （５．２４）
しがたって、Ｅｖｅｎｔクラスとイベントインスタンスとは定数の状態を有しており、それらは同一である場合にだけ等しい。しかし、イベントＸの評価は定数の評価とは異なる。
【０３５０】
同時性と並列性：ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔの並列評価は複数の評価子が使用された時に常に発生する。（５．２）に記述されているＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔ評価については、以下が成立する。
【０３５１】
（［Ｅ１→Ｘ［ｔ１（．．．）］］｜｜［Ｅ２→Ｙ［ｔ２（．．．）］］）⇔（Ｅ１≠Ｅ２）（５．２５）
（［〈Ｅ１→Ｘ（ｃ１．ｔ１）〉（ｃ２．ｔ２）］＆［〈Ｅ２→Ｙ（ｃ２．ｔ１）〉（ｃ２．ｔ２）］⇔
［（Ｅ１≠Ｅ２）＆（ＸＹ）＆（ＸＹ）＆Ｘ（ｃ１．ｔ２）＆Ｙ（ｃ２．ｔ２）
＆ｃ１．ｔ２∈ｔ１（．．．）＆ｃ２．ｔ２∈ｔ２（．．．）］ （５．２６）
（５．２５）において、ｔ１（．．．）とｔ２（．．．）はＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔが２つの異なる評価子において発生する２つのタイムマップである。評価はローカル時間点ｃ１．ｔ１とｃ２．ｔ１で２つの評価子内で始まり、ｃ１．ｔ２とｃ２．ｔ２でそれぞれ完了し、ｃ１．ｔ１＜ｃ１．ｔ２かつｃ２．ｔ１＜ｃ２．ｔ２である。ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンスＸ（ｃ１．ｔ２）とＹ（ｃ２．ｔ２）は評価が完了した時間点で発生する。２つの評価が発生した時間間隔［ｃ１．ｔ１，ｃ１．ｔ２）と[ｃ２．ｔ１，ｃ２．ｔ２]はグローバル時間において重なることもある。一般に、２つの評価が始まったローカル時間点の対（ｃ１．ｔ１，ｃ２．ｔ１）と評価が完了した（ｃ１．ｔ２，ｃ２．ｔ２）は比較不能、つまりそれらは任意の順番に発生することがある。そして並列評価は（〈→Ｘ〉（ｃ１．ｔ２）｜｜〈→Ｙ〉（ｃ２．ｔ２））と書かれる。２つのイベントが同期していたり、調和していたりする場合、グローバル時間においてｔ１（．．．）≡ｔ２（．．．）かつｃ１．ｔ２＝ｃ２．ｔ２である。そして並列評価は［→〈（Ｘ｜｜Ｙ）〉（ｃ１．ｔ２＝ｃ２．ｔ２）］と書かれる。同様な並列評価がＡｃｔｉｏｎＥｖｅｎｔでも発生する。唯一の違いは、タイムマップがＡｃｔｉｏｎＥｖｅｎｔには関連付けられていないが、仮想時間点がＡｃｔｉｏｎＥｖｅｎｔクラスには関連付けられており、評価（インスタンス）が発生する時間点が指定され、所与のＡｃｔｉｏｎＥｖｅｎｔクラスは複数のインスタンスを時間点の厳密に増加するシーケンス内の異なる時刻に有していてもよい。
【０３５２】
因果：以下では、ＸとＹはＥｖｅｎｔサブクラスである。評価子の記号、→を以下の意味で因果記号として使用し、イベントの発生は１つまたは２つ以上の他のイベントを発生させ、「Ｘ→Ｙ」は「ＸはＹの原因」と読み、ＸＣ（Ｘ，Ｙ）→Ｙを条件Ｃ（Ｘ，Ｙ）がｔｒｕｅの場合「ＸはＹの原因」と読む。
【０３５３】
Ｘ→Ｙ⇔□［∀（ｔ）∃（τ＞０）（Ｘ（ｔ）⇔Ｙ（ｔ＋τ）＆τ≦τｍａｘ（Ｘ，Ｙ）］ （５．２７ａ）
ＸＣ（Ｘ，Ｙ）→Ｙ⇔□［∀（ｔ）∃（τ＞０）（Ｘ（ｔ）⇔
Ｙ（ｔ＋τ）＆〈Ｃ（Ｘ，Ｙ）〉（ｔ＋τ）＆τ≦τｍａｘ（Ｘ，Ｙ）］ （５．２７ｂ）
Ｘ→φ≡ＳＴＯＰ（何も起こらない） （５．２８）
ここでτｍａｘ（Ｘ，Ｙ）は２つのイベントインスタンスの発生の間の最大許容可能遅延である。
【０３５４】
直接の因果：
Ｘ→Ｙ⇔［（Ｘ・→Ｙ）∨∃ｅ（Ｘ・→e→Ｙ）］ （５．２９）
Ｘ・→Ｙ⇔¬∃ｅ（Ｘ・→ｅ→Ｙ） （５．３０）
（５．３０）のＸ・→ＹにおいてＸとＹとの間にはイベントは発生しない。したがって、評価子・→は分割不可能、つまり割り込みできない。
【０３５５】
５．５．因果チェーンと詳細化
因果チェーン：
□［Ｘ→．．．→Ｙ⇔（（Ｘ→Ｙ）｜∃（Ｚ）（Ｘ→Ｚ→．．．→Ｙ））］ （５．３１）
□［（Ｘ◇Ｙ）⇔（Ｘ→Ｙ）∨（Ｚ）（（Ｘ→Ｚ）⇒（Ｚ◇Ｙ））］ （５．３２）
【０３５６】
直接の因果チェーン：
Ｘ・→．．．・→Ｙ⇔（（Ｘ・→Ｙ）｜∃（Ｚ）（Ｘ・→Ｚ・→．．．・→Ｙ））
□演算子は（５．３３）でのように省略されていても仮定しなければならない。ｐｔｈｒｅａｄやプロトコルの実行内のイベントの因果チェーン（または直接の因果チェーン）はステートメント（５．３１）と（５．３３）のいずれかの側の選択肢に分岐し、（４．５）、（４．６）、（４．１４）、（４．１６）および（７．４）に示しているように、異なる終端イベントを引き起こす。フォークがプロトコル実行に発生すると、図６のダイアグラムに示しているように、因果チェーンは１つの共通のＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔに最終的にジョインする並列な分岐を含むことになる。これは以下で導入する全ての詳細化で成り立つ。便宜上、以下の説明では並列直接因果チェーンを使用する。因果チェーンは全ての場合に選択肢のある分岐および／またはフォークを含んでいることを仮定している。
【０３５７】
→の詳細化：
ＲｅｆｉｎｅｍｅｎｔＯｆ（Ｘ→Ｙ）＝
［（Ｘ・→Ｙ）∨∃（ｅ）（Ｘ・→ＲｅｆｉｎｅｍｅｎｔＯｆ（ｅ→Ｙ））］ （５．３４）
（Ｘ→Ｙ）の詳細化は（Ｘ→Ｙ）＝（Ｘ・→ｅ１・→ｅ２・→．．．・→ｅｎ・→Ｙ）のような直接因果チェーン、ｅ１・→ｅ２・→．．．・→ｅｎである。εｉ＝ｅｉ１・→ｅｉ２・→．．．・→ｅｉｋ（ｉ）、０≦ｉ≦ｎを指すためにεｉを使用する場合、ｎ≧０について一般的な場合は以下のようになる。
【０３５８】
ＲｅｆｉｎｅｍｅｎｔＯｆ［（Ｘ→（Ｙ０｜Ｙ１｜．．．｜Ｙｎ）］＝
［（Ｘε０Ｙ０）｜（Ｘε１Ｙ１）｜．．．｜（ＸεｎＹｎ］、 （５．３４ａ）
ＲｅｆｉｎｅｍｅｎｔＯｆ［（Ｘ→（Ｙ０｜｜Ｙ１｜｜．．．｜｜Ｙｎ）］＝
［（Ｘε０Ｙ０）｜｜（Ｘε１Ｙ１｜）｜．．．｜｜（ＸεｎＹｎ］、 （５．３４ｂ）
ここでεｉ、０≦ｉ＜ｎは、直接因果チェーンであって、シンボル「｜」が選択肢を指定しており、シンボル「｜｜」は並列因果チェーンを分離している。
【０３５９】
ｐｔｈｒｅａｄとプロトコル：プロトコルの終端イベントはプロトコル実行中の信号交換によって常に一意に定められる。ポートｐからポートｑへのメッセージ送信の詳細化は、以下の形態である（便宜上、以下の全てのステートメントではリニア詳細化を仮定している）。
【０３６０】
ｐＳ［ｔ１（．．．）］→ｑＤ［ｔ２（．．．）］＝ｐＳ［ｔ１（．．．）］・→プロトコル・→ｑＤ［ｔ２（．．．）］＝
ｐＳ［ｔ１（．．．）］・→ｅｃ０・→ｅｃ１・→．．．・→ｅｃｋ・→ｑＤ［ｔ２（．．．）］ （５．３５）
これは、ポートｐのプロトコル内のＣＣＰと他のＡｃｔｉｏｎＥｖｅｎｔの割り込み不能シーケンスである。配信されたメッセージが検知された後で、応答メッセージがセルＣによって送信される前に実行されるｐｔｈｒｅａｄの詳細化は以下の形態を有することになる。
【０３６１】
Ｃ．ｐ：ｍＲ？（Ｃ．ｐＤ［ｔ１（．．．）］・→ｐｔｈｒｅａｄ・→Ｃ．ｐＳ［ｔ２（．．．）］＝
Ｃ．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｅｐ０・→ｅｐ１・→．．．・→ｅｐｎ・→Ｃ．ｐＳ［ｔ２（．．．）］＝ （５．３６）
これはＡｃｔｉｏｎＥｖｅｎｔの割り込み不能シーケンスでもある。これはｐｔｈｒｅａｄ実行中に発生する。以下の詳細化
Ｃ１．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｐｔｈｒｅａｄ・→Ｃ１．ｐＳ［ｔ２（．．．）］
・→プロトコル・→Ｃ２．ｑＤ［ｔ３（．．．）］ （５．３７）
は、Ｃ１．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｅｐ０・→ｅｐ１・→．．．・→ｅｐｎ・→Ｃ１．ｐＳ［ｔ２（．．．）］・→ｅｃ０・→ｅｃ１・→．．．・→ｅｃｋ・→Ｃ２．ｑＤ［ｔ３（．．．）］の形態を有しており、ＡＬＬＥＯＰにおいて、以下のように書かれるが、
Ｃ１．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｅｐ０・→ｅｐ１・→．．．・→ｅｐｎ
Ｃ１．ｐＳ［ｔ２（．．．）］→Ｃ２．ｑＤ［ｔ３（．．．）｜｜．．．）］｝ （５．３８）
それはプロトコルの詳細化がＡＬＬＥＯＰにおいては示されていないためである。
【０３６２】
同期：同期した並列フォークは以下で発生する。ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔのインスタンスＺ１とＺ２は（５．３９）において同時に発生する。
【０３６３】
［（Ｘ→Ｚ１［ｔ１（．．．）］）］｜｜Ｘ→Ｚ２［ｔ１（．．．）］＝Ｘ→（Ｚ１｜｜Ｚ２）［ｔ１（．．．）］
⇔∀（ｔ）∃（τ＞０）（［Ｘ（ｔ）⇔（Ｚ１（ｔ＋τ）｜｜Ｚ２（ｔ＋τ））、ｔ１＋τ∈ｔ１（．．．）（５．３９）
【０３６４】
同期フォークの一般化：
Ｘ→（Ｚ１｜｜Ｚ２｜｜．．．｜｜Ｚｎ）［ｔ（．．．）］ （５．４０）
【０３６５】
調和：並列調和が以下で発生する。
（［Ｘ［ｔ１（．．．）］｜｜Ｙ［ｔ２（．．．）］）→Ｚ［ｔ３（．．．）］）⇔
∀（ｔ１，ｔ２，ｔ３）∃（τ＞０）（ｔ１∈ｔ１（．．．）＆ｔ２∈ｔ２（．．．）＆ｔ３∈ｔ３（．．．））＆
［Ｘ（ｔ１）＆Ｙ（ｔ２）］⇔Ｚ（ｔ３＝ｍａｘ（ｔ１，ｔ２）＋τ） （５．４１）
ここで、イベントＸとＹは異なる比較不能時刻に発生する可能性があり、ｍａｘ（ｔ１，ｔ２）はローカル時間のグローバル時間へのマッピングに相対的に定義される。ＺはＸとＹの両方がそれぞれのタスクを完了した後で初めて発生する。
【０３６６】
調和の一般化：ここで、イベントＺ［ｔ（．．．）］は全てのイベントＸ１、Ｘ２、．．．、Ｘｎが既に発生している場合にだけ発生する。
【０３６７】
（Ｘ１［ｔ１（．．．）］｜｜Ｘ２［ｔ２（．．．）］｜｜．．．｜｜Ｘｎ［ｔｎ（．．．）］）→Ｚ［ｔ（．．．）］ （５．４２）
【０３６８】
調和と同期の一般化：イベントＺ１、Ｚ２、．．．ＺｎはイベントＸ１、Ｘ２、．．．、Ｘｎがすべて発生した後に、すべて同時に発生する。
【０３６９】
（Ｘ１［ｔ１（．．．）］｜｜Ｘ２［ｔ２（．．．）］｜｜．．．｜｜Ｘｎ［ｔｎ（．．．）］）→（Ｚ１｜｜Ｚ２｜｜．．．｜｜Ｚｎ）［ｔ（．．．）］ （５．４３）
【０３７０】
イベントの選択肢：（Ｘ｜Ｙ）、ＸまたはＹのいずれかが発生する。
【０３７１】
一般化された選択肢：（Ｘ１｜Ｘ２Ｕ｜．．．｜Ｘｎ） （５．４４）
ここでＸｉは因果チェーンであってもよい。イベント選択肢表現における選択は、常に対が互いに排他的でなければならない。
【０３７２】
ガードとポーリング：ガードは図１と２に定義しており、ポーリングの例は（２．７）から（２．１０）に示している。図１と２に示しているように、検知によってポートの状態が変化する。これは、条件の評価は世界状態を変化させないという一般規則の例外である。ＴＩＣＣ−Ｐｐｄｅの動作に対する以下の制限がポーリングに関連している。
【０３７３】
□［∀（Ｐｏｒｔｓ ｐ）∀（Ｐｏｒｔｓ ｑ）（（ｐ≠ｑ）＆（ｐ：ｐａｒｅｎｔ（）＝ｑ：ｐａｒｅｎｔ（）））
⇒¬（∃（ｔ）（［・→ｐ：ｍＲ？（）（ｔ）］＆［・→ｑ：ｍＲ？（）（ｔ）］））］ （５．４５）
また、他のガードについても同様である。したがって、セルはそのポートの２つのポーリングを同時に開始したり終了したりしない。セルにおいては並列性または時間スライスの並行性は存在しない。全ての割り込みはトランザクションの完了の要件に反することにないプログラムされた割り込みである。セルのポーリングサイクルでポートのポーリングがいったん始まると、以下の７つの考える結果が各ポートで発生し、それらは、（ｉ）ポートはメッセージが存在しないためスキップされる、（ｉｉ）セルはメッセージを待ち、それから，以下の項目（ｖ）と（ｖｉ）または（ｖｉｉ）のようにそれを処理する、（ｉｉｉ）ポートベクトルの場合は、ポートベクトルの全てにポートにメッセージが存在する場合、セルは（ｖ）と（ｖｉ）または（ｖｉｉ）を実行し、そうではない場合、ポートベクトルをスキップする、（ｉｖ）ポート選択肢の場合は、いずれか１つのポート選択肢にメッセージが存在する場合、セルは（ｖ）と（ｖｉ）または（ｖｉｉ）を実行し、そうではない場合、ポート選択肢をスキップする、（ｖ）ポート（またはポートベクトル）にメッセージが存在する場合、セルはセルのｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内にそれを追加することによって、ポート（またはポートベクトル）のサービスをスケジュールする、（ｖｉ）セルはメッセージの検知後即座にポート（またはポートベクトル）のサービスを行う、または（ｖｉｉ）サービスのプログラムされたサスペンドが発生し、サービスは次のポーリングサイクルでレジュームする、である。
【０３７４】
世界状態の一貫性：各世界状態Ｗ（ｔ）は時刻ｔの計算の状態を表している。任意の時間点ｔにおいて、世界状態Ｗ（ｔ）は一貫している。証明システムは世界状態を維持しＥＣＴ評価中の仮定された時間点で更新する。ＥＣＴ評価中（図６に示している）にＣＴＬアサーションとＥＣＴとの間に矛盾を検出した場合、アサーションは有効ではない。そのような矛盾は、設計または実装のエラーを示す。ＳＭＳによる因果律網生成中に遭遇するＡＬＬＥＯＰの矛盾はシステム動作のエラーを示している。
【０３７５】
・→上での条件の移行：フォーマット「→Ｃ？（）｛Ｘ｝」、Ｘは通信またはアクションイベント、をＡＬＬＥＯＰフォーマットと呼び、フォーマット、
「｛〈ｐｒｅ−Ｃ？（）＆Ｃ？（）〉（ｔ０）｝［→Ｘ（ｔ０）］
｛〈Ｘ．ｏｕｔｐｕｔ＆ｐｓｔ−Ｃ？（））（ｔ１）｝」、ｔ１≦ｔ０＋τｍａｘ、
をトレースフォーマットと呼ぶ。後者はＣ？（）｛Ｘ｝の構文を記述している。実行は半閉間隔［ｔ０，ｔ１）の時間点の間であって、τｍａｘは最大の許容可能遅延である。以下では、条件の評価は、世界を変えず、アクションは事前条件がｔｒｕｅになる時刻ｔ０において同じ世界において評価されると仮定し、ガードはこの規則から除外される。以下の（５．４６）の文脈ｘとｙはセルＣまたはポートＣ．ｐのいずれかである。全ての状態チェックとアクション評価とは１つのセルＣの文脈で発生する。ｘ：ｎａｍｅｓ（）（ｔ）⊆Ｃ：ｎａｍｅｓ（）（ｔ）が成立する。この文脈は、その中に、メソッドの評価中に評価子によって維持されている変数のローカルコード実行スタックを有している。
【０３７６】
［∃（ｔ１）∃（ｔ２）∃（τ１＞０）∃（τ２＞０）
｛〈ｘ．Ａ１：ｐｒｅ−Ｃ１？（）＆ｘ：Ｃ？（）〉（ｔ１）｝
［・→ｘ：Ａ１（）（ｔ１）］｛〈ｚ１＆ｘ．Ａ１：ｐｓｔ−Ｃ１？（））（ｔ１＋τ１）｝
｛〈ｙ．Ａ２：ｐｒｅ−Ｃ２？（）＆ｙ：Ｃ？（）〉（ｔ２）｝
［・→ｙ：Ａ２（）（ｔ２）］｛〈ｚ２＆ｙ．Ａ２：ｐｓｔ−Ｃ２？（）〉（ｔ２＋τ２）｝
⇔（ｔ２＝ｔ１＋τ１）＆（（ｘ．Ａ１：ｐｒｅ−Ｃ１？（）⇒ｙ．Ａ２：ｐｒｅ−Ｃ２？（））（ｔ２））］ （５．４６）
前述のように、アクション評価はそのｐｒｅ−Ｃ１？（）がｆａｌｓｅである場合に未定義であって、Ｃ？（）がｆａｌｓｅである場合にスキップされる。・→でリンクされている２つの連続しているアクションｘ：Ａ１（）とｙ：Ａ２（）の実行中に、ｙ：Ａ２（）の実行はｘ：Ａ１（）の実行の終了と同時に始まり、さらに、事後条件ｘ．Ａ１（）はｙ：Ａ２（）の事前条件を論理的に意味する。Ａ１が終了する時刻とＡ２が始まる時刻との間にはわずかな遅延が通常存在する。しかし、この遅延中にセルＣの世界は変化しないが、それはセルＣ内で２つのそのようなアクションの間に他のアクションが発生しないからで、また、他のセルで発生するアクションはセルＣの状態には影響しないが、それはセルの分離のためである（セクション３．２）。したがって、この遅延は無視される。
【０３７７】
ポーリングサイクルにおいて、（Ｃ．ｆ［ｉ］：ｍＲ？（）→Ｃ．ｆ［ｊ］：ｍＲ？（））、ｉ≠ｊのフォーマットの指定を使用した。これは、以下の意味において、（Ｃ．ｆ［ｉ］：ｍＲ？（）・→．．．・→Ｃ．ｆ［ｊ］：ｍＲ？（））と解釈される。
【０３７８】
∃（ｔ０＜ｔ１＜ｔ２＜ｔ３＜ｔ４）
（｛Ｃ．ｆ［ｉ］：ｍＲ？（）（ｔ０）／＊始まる＊／＆〈Ｃ．ｆ［ｉ］：ｍＲ？（）〉ｔ（ｔ１）／＊終わる＊／｝
［・→Ｃ．ｆ［ｉ］：ｔｉｐ（）（ｔ１）／＊始まる＊／］［（・→Ｃ．ｆ［ｉ］：ｔｉｐ（））（ｔ２）／＊終わる＊／
（｛Ｃ．ｆ［ｉ］：ｍＲ？（）（ｔ２）／＊始まる＊／＆〈Ｃ．ｆ［ｉ］：ｍＲ？（）〉ｔ（ｔ４）／＊終わる＊／｝
［・→Ｃ．ｆ［ｉ］：ｔｉｐ（）（ｔ３）／＊始まる＊／］［（・→Ｃ．ｆ［ｉ］：ｔｉｐ（））（ｔ４）／＊終わる＊／ （５．４７）
言い換えると、Ｃ．ｆ［ｉ］とＣ．ｆ［ｊ］のサービスは、Ｃ．ｆ［ｊ］：ｍＲ？（）（ｔ２）、つまりＣ．ｆ［ｊ］：ｍＲ？（）の評価は［〈・→Ｃ．ｆ［ｉ］：ｔｉｐ（）〉］が終了した時に時間点ｔ２で始まるという制限の下で、（［ｔ１，ｔ２）∩［ｔ３，ｔ４））＝φであるように半閉区間間隔［ｔ１，ｔ２）と［ｔ３，ｔ４）で発生する。ここで、Ｃ．ｆ［ｉ］のサービスは、Ｃ．ｆ［ｉ］：ｍＲ？（）（ｔ０）がｔｒｕｅと評価された場合にだけ発生し、それ以外はポートはスキップされ、ポーリングは即座にＣ．ｆ［ｊ］に進む。したがって、ポーリングサイクルは、ポーリングの順序だけを指定し、ポーリングされるポートがサービスを受ける順序は指定しない。ＴＩＰの並列トリガは互いに連続しているが、それは通信がセクション２の例で記述されていたからで、唯一の要件は、メッセージが送信された時にメッセージを特徴付ける条件が、メッセージが配信され配信されたメッセージが検知され使用されるまで不変であることである。
【０３７９】
サンプルＡＬＬＥＯＰ証明を説明する例の考察に進む。全ての証明において、全てのｐｔｈｒｅａｄと条件の実装は既に個別に検証されていると仮定する。これは可能であるが、それは、ｐｔｈｒｅａｄは相互に独立しており、独立しているｐｔｈｒｅａｄは共に検証され、条件は常にセルに対してローカルだからである。［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］において紹介されている「装飾的庭の問題」の一般化されたバージョンから始める。正式なＡＬＬＥＯＰ証明が、「排他」と「条件同期」について、この例に対して示されている（［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］で使用されている用語）。解法は、［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］の「駐車場」問題にも当てはまる。
【０３８０】
６．ＡＬＬＥＯＰ証明を使用した例
６．１．装飾的庭：排他と条件同期
ここでの目的は、ＥＣＴネットワークの構造を表示し、証明を生成するためにそれらがシステムにどのように使用されるかを示すことである。装飾的庭の問題についてのＦＳＰ指定については、Ｍａｇｅｅ＆Ｋｒａｍｅｒ、［１３］を参照。問題は以下のとおりである。装飾的庭の公園は５〜６個のゲートを有しており各々が回転改札口を有している。ＭａｇｅｅとＫｒａｍｅｒでのように、公園の２つの端部の２つの入口のゲートを仮定するが、ＭａｇｅｅとＫｒａｍｅｒとは異なり、２つの出口のゲートも仮定する。ゲートは、公園が開いている時には開いており、入園者がすべて公園から帰った後で閉園している時には閉じている。開園している時にはいつでも、人々は任意の入口ゲートを通って入園し任意の出口ゲートを通って出園することができる。いつも庭にいる人の正確な数を保持している必要があり、数が予め定められている最大値を超えることは許されない。
【０３８１】
ＴＩＣＣネットワークを図１０に示している。それは、２つの入口回転改札口Ｅｔ［０］とＥｔ［１］と、２つの出口回転改札口Ｘｔ［０］とＸｔ［１］とを有している。外部割り込みに基づいて公演のゲートを開閉する１つの環境Ｅが存在する。１つのカウンタが存在する。人が入口または出口の回転改札口Ｔｉ［ｊ］とＸｔ［ｊ］、ｊ＝０、１に到着すると、センサＳｅ［ｊ］とＳｘ［ｊ］が人をそれぞれの回転改札口で検知すると仮定する。そのセンサと共に各回転改札口はカプセル化されているセルである。人を検知すると、センサはポートＥｔ［ｊ］．ｆｔまたはＸｔ［ｊ］．ｆｔ、ｊ＝０，１にそれらのそれぞれの一般ポート、Ｓｅ［ｊ］．ｇまたはＳｘ［ｊ］．ｇを通して合図する。経路、Ｓｅ［ｊ］．ｇ⇔Ｅｔ［ｊ］．ｆｔとＳｘ［ｊ］．ｇ⇔Ｘｔ［ｊ］．ｆｔはカプセル化に対して内部である。センサは機能ポート、ｆｔ（ｔは回転改札口を表す）にこれらの隠蔽された経路を通して合図する。便宜上、図１０ではセンサを回転改札口の外側に示している。
【０３８２】
0005704459.tif 000011
【０３８３】
図１０：装飾的な庭の解法用のネットワーク：排他および条件同期
Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）およびＸｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）はポートＥｔ［ｊ］．ｆｔとＸｔ［ｊ］．ｆｔとがセンサによって送信された信号をそれぞれ検知した時にｔｒｕｅになる。これらの述語の定義は付録Ｉを参照。以下のＴＩＰは、センサが人を検知した時にカプセル化の内部で実行される。
【０３８４】
Ｓｅ．ｇ：ＴＩＰ（）＝Ｅｔ［ｊ］：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛Ｓｅ．ｇ：ｐＲ？（）＊｛Ｓｅ．ｇ：ｓ（）；｝｝
Ｓｘ．ｇ：ＴＩＰ（）＝Ｘｔ［ｊ］：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛Ｓｘ．ｇ：ｐＲ？（）＊｛Ｓｘ．ｇ：ｓ（）；｝｝ （６．１）
【０３８５】
カウンタは５つの機能ポート、Ｃ．ｆ［ｊ］、０≦ｊ＜５を有している。これらの式は以下のように使用される。
【０３８６】
ｊ＝０，１について：ポートＥｔ［ｊ］．ｆｔで信号を検知すると、回転改札口はカウンタに経路Ｅｔ［ｊ］．ｇ⇔Ｃ．ｆ［ｊ］（図１０を参照）を通して合図する。カウンタＣが信号をＣ．ｆ［ｊ］、０≦ｊ＜１で検知すると、以下を実行する。（ｉ）Ｃは、ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘの場合にカウンタを１だけ増加させ、Ｃ．ｆ［ｊ］⇔Ｅｔ［ｊ］．ｇを通してＥｔ［ｊ］にゲートの人が入るかもしれないことを通知し、Ｅｔ［ｊ］．ｇで信号を受信すると、回転改札口は鍵を解除し、Ｅｔ［ｊ］．ｆｔの人を公園に入れる。
（ｉｉ）ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＝ｍａｘの場合は、ＣはＣ．ｆ［ｊ］⇔Ｅｔ［ｊ］．ｆを通してＥｔ［ｊ］に公園が満員であることを通知し、Ｅｔ［ｊ］．ｆでの信号を受信すると、回転改札口は回転改札口の鍵を解除せずに「公園は満員」と表示する。これら２つの選択肢アクションの一方を実行するために、Ｅｔ［ｊ］は同期非決定的ポーリング∃（ｐ）（ｐ＝（Ｅｔ［ｊ］．ｇ｜Ｅｔ［ｊ］．ｆ））ｐ：ｍＲ？（））＊を実行し、したがってカウンタからの応答をこれらのポートの１つで待つ。
【０３８７】
ｊ＝２，３について：出口改札口、Ｘｔ［ｉ］．ｇ、ｉ＝０，１はそのポートＣ．ｆ［ｉ＋２］で経路Ｘｔ［ｉ］．ｇｏＣ．ｆ［ｉ＋２＝ｊ］を通してカウンタに合図する。Ｃ．ｆ［ｉ＋２］で信号を検知すると、カウンタはカウントを１つだけ減少させ、回転改札口の鍵を解除し、回転改札口を解錠して人を出園させるために経路Ｃ．ｆ［ｉ＋２］⇔Ｘｔ［ｉ］．ｇを通して合図する。Ｘｔ［ｉ］は、同期ポーリングＸｔ［ｉ］．ｇ：ｍＲ？（）＊を実行することによって、Ｘｔ［ｉ］．ｇでこの応答を待つ。ｊ＝４については、ポートＣ．ｆ［４］が表示ユニットからの要求を受信し、ｃｏｕｎｔｅｒ．ｃｏｕｎｔの現在の値をユニットに送信するためにカウンタによって使用される。表示ユニットはカウントに対する要求を外部割り込みに基づいて送信する（図１０を参照）。
【０３８８】
複数の人が複数の回転改札口を使用して同時に並列に入園したり出園したりすることがある。しかし、各回転改札口は、１度に１人しか入園または出園させない。プログラムは自己スケジューリング、自己調和、および自己同期している。ＴＩＣＣネットワークとＴＩＰとは実行制御構造を定める信号交換を定める。付録Ｉの装飾的庭の解法は、複数の駐車場入口と出口を備えており、車が出る前に駐車料金を払わなければならないことが異なる［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］で定義されている駐車場の例にも適用されることは明かである。
【０３８９】
信号交換とカウントにかかる時間は１キロの長さの１メガビット／秒の信号線と２ギガヘルツＣＰＵを仮定すると２〜３マイクロ秒未満でなければならない。したがって、実質的に無限の数の入口と出口の回転改札口を有することができる。このネットワークに基づいているＴＩＣＣ−Ｐｐｄｅ実装用のＣＩＰ、ＡＬＬＥＯＰ、およびトレースを付録Ｉに示している。これを装飾的庭の解法と呼ぶ。
【０３９０】
付録Ｉに示している実装を完成するには、ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）、ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）、ｄｅｎｙＥｎｔｒｙ（）、ｌｅｔＰｅｒｓｏｎｌｎ（）、ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）、ｐｅｒｓｏｎＩｎＰａｒｋ（）、およびｄｉｓｐｌａｙＣｏｕｎｔ（）を定義しなければならない。それによって、付録ＩのＡＬＬＥＯＰとトレースは完全な実装をモデル化する。実装は、モニタ、セマフォ［Ｈｏａｒｅ，１０，１２］［Ｄｉｊｋｓｔｒａ，２３，２４］、ロック、スケジューラ、または同期制御プリミティブを必要としない。
【０３９１】
この構成において、回転改札口によって呼び出される２つのカウンタアクティビティは互いに干渉しないが、それはカウンタが第１の機能ポートのサービスが完了した後で初めて第２の機能ポートをサービスするからであることは明かである。公園内の人の数はｍａｘを超えないことも明かである。実装が要件を満たすことを示すために実装の仕様からこれらを形式的証明したい。特に、以下を証明したい。
【０３９２】
ステートメント１）庭園に入る各人はカウンタに１回だけ加算される。
【０３９３】
ステートメント２）庭園を出る各人はカウンタから１回だけ減算される。
【０３９４】
ステートメント３）庭園内の人の合計はｍａｘを超えない。
ユーザは前述のステートメント１とステートメント２に対して以下の解釈をＣＴＬステートメントとして定義する。ＣＴＬステートメント内のイベントは、条件またはアクションのいずれかによって指定される。ＣＴＬステートメントの量化は、ステートメント内で発生する前提とする時間点、オブジェクト、およびイベントを対象とする。
【０３９５】
□［∃（ｃｔｌ．ｔ０＜ｃｔｌ．ｔ１＜ｃｔｌ．ｔ２＜ｃｔｌ．ｔ３）＆
（ｃｔｌ．ｔ４＜ｃｔｌ．ｔ５＜ｃｔｌ．ｔ６＜ｃｔｌ．ｔ７）＆
（（ｃｔｌ．ｔ２＜ｃｔｌ．ｔ５）｜（ｃｔｌ．ｔ６＜ｃｔｌ．ｔ２））
∃！（Ａ１＝ｃｏｕｎｔｅｒ＋＋）∃！（Ａ２＝ｃｏｕｎｔｅｒ−−）
ＥｎｔｅｒｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ＝
［｛〈ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）〉（ｃｔｌ．ｔ０）｝
→．．．→［〈・→Ａ１（ｃｔｌ．ｔ１）／＊開始する＊／〉ｃｔｌ．ｔ２）／＊終了する＊／］）
→．．．→｛ｐｅｒｓｏｎＩｎＰａｒｋ？（）（ｃｔｌ．ｔ３）｝］＆ （６．２）
ＬｅａｖｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ＝
｛〈ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｃｔｌ．ｔ４）｝
→．．．→［〈・→Ａ２（ｃｔｌ．ｔ５）／＊開始する＊／〉（ｃｔｌ．ｔ６）／＊終了する＊／］）
→．．．→｛ｐｅｒｓｏｎＩｎＰａｒｋ？（）（ｃｔｌ．ｔ７）｝］＆ （６．３）
付録Ｉの以下の定義を便宜上再掲載する。
【０３９６】
Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）
⇔Ｅｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｅｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｅ［ｊ］．ｇ，１）］） （Ｉ．４）
Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）
⇔Ｘｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｘｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｘ［ｊ］．ｇ，１）］） （Ｉ．１１）
前述のＣＴＬステートメントにおいて、ｃｌｔ．ｔ２は（６．２）においてカウンタの呼び出しが終了する時刻であって、ｃｌｔ．ｔ５は（６．３）においてカウンタの呼び出しが始まる時刻である。制限（ｃｔｌ．ｔ２＜ｃｔｌ．ｔ５）は、（６．３）のカウンタ呼び出しが（６．２）のカウンタ呼び出しの終了の後でなければならないことをアサーションしている。同様に、（ｃｔｌ．ｔ６＜ｃｔｌ．ｔ２）は、他の可能性、つまり（６．３）の呼び出しの終了後に（６．２）の呼び出しが始まることをアサーションしている。どちらも場合も、２つのステートメントにおいてカウンタがアクティブな半閉間隔、つまり［ｃｔｌ．ｔ１，ｃｔｌ．ｔ２）と［ｃｔｌ．ｔ５，ｃｔｌ．ｔ６）は重なってはならない。量化、∃！（Ａｌ＝ｃｏｕｎｔｅｒ＋＋）∃！（Ａ２＝ｃｏｕｎｔｅｒ−−）は、各ステートメントにおいて、カウンタイベントの一意の１回だけの発生があることをアサーションする。ｃｏｕｎｔｅｒ＋＋の各呼び出しはカウントを１だけ増加させ、ｃｏｕｎｔｅｒ−−の各呼び出しはカウントを１だけ減少させることをここで仮定している。したがって、（６．２）と（６．３）は、ゲートにいる人は、カウンタが１だけ１回だけ増加した後で始めて公園に入ることを許され、カウンタが１だけ１回だけ減少した後で始めて公園から出ることを許されることをアサーションしている。（６．２）と（６．３）の開始と終了イベントは以下のとおりである。
【０３９７】
開始イベント 終了イベント
（６．２）において：〈ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）〉（ｃｔｌ．ｔ０） ｐｅｒｓｏｎｌｎＰａｒｋ？（）（ｃｔｌ．ｔ３）
（６．３）において：〈ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｃｔｌ．ｔ４） ¬ｐｅｒｓｏｎｌｎＰａｒｋ？（）（ｃｔｌ．ｔ７）
ただし、開始イベントが終了する時間点の対（ｃｔｌ．ｔ０，ｃｔｌ．ｔ４）と終了イベントが始まる時間点の対（ｃｔｌ．ｔ３，ｃｔｌ．ｔ７）とは比較不能である。したがって、人は同時に入園と出園とを行ってもよい。この例については、（６．２）と（６．３）の第２の省略→．．．→を◇に置き換えることによってステートメントの意味は変化しないが、それは各場合において、開始イベントから終了イベントに到達する道が１つだけであるためである。証明する問題は以下のとおりである。
【０３９８】
Ｔｒａｃｅｓ（横向きのＴ）ＥｎｔｅｒｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ＆ＬｅａｖｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ （６．４）
ここでＴｒａｃｅｓは実装の全てのトレースの集合であって、（横向きのＴ）は論理的な帰結関係である。この点で、前述のＣＴＬのアサーションは、庭園にどれだけの入口と出口とがあるかは述べていない。これは、実装を分析することによって発見されるべきことである。このステートメントは公園の入口と出口の数に関わらず成立しなければならない。
【０３９９】
６．１．１．装飾的庭の解法のためのＥＣＴネットワーク
表Ｉ：入口のゲートのためのＥＣＴネットワーク
【０４００】
【表１】
0005704459.tif 000012
イメージ ID=000012
【０４０１】
ＥＣＴネットワークを表ＩとＩＩに示している。ポーリングサイクルとポートトレースについての情報がＥＣＴネットワークにおいて表形式に再構成されて示されており、ネットワークはＡＬＬＥＯＰに整合しているトレ―スの直列／並列の組み合わせを示している。ＥＣＴとトレースの両方が同じ情報を有している。読者が表ＩとＩＩの全ての詳細を理解することは期待していない。これら表の構造の概要を以下に示す。
【０４０２】
表ＩのネットワークはＥｔ［ｊ］とＣ．ｆ［ｊ］、ｊ＝０，１との間に相互動作を示しており、表ＩＩのネットワークはＸｔ［ｊ］とＣ．ｆ［ｊ＋２］、ｊ＝０，１との間に相互動作を示している。ネットワーク内の各ＥＣＴブロックでは、イベントは上から下へ時間的に昇順に第１の列に現れている。イベントは条件またはアクションのいずれかである。それらの関連付けられている仮想時間点が上から下へ昇順に第２の列に現れている。ＥＣＴブロック間の矢印を備えている有向分岐は、選択点に起因する選択肢を有することもある順次制御転送か、信号配信に起因する並列制御転送（フォーク）かのいずれかである。選択点に選択肢のある逐次制御転送を示している分岐は「｜」マークが付けられ、並列制御転送を示している分岐には「｜｜」が付けられている。例ではフォークは現れていない。「｜｜」で示されている分岐上の省略「→．．．→」は、分岐矢印の端のブロックの起動が信号の配信と同時には発生せずに、後に発生することがあることを示している。
【０４０３】
表Ｉの上部のブロックＥｔ［ｊ］．ｆｔ：ＥＣＴ（ｅ［ｊ］．ｔ０）は２つの選択肢のブロックに分岐する。これらの３つのブロックは併せて、Ｅｔ［ｊ］が人の入園を検知した時に何が発生するかを記述している。述語Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）は前述のように信号がＥｔ［ｊ］．ｆｔで受信されている時にだけｔｒｕｅである。Ｅｔ［ｊ］．ｆｔで信号を検知すると、Ｅｔ［ｊ］は人が入園できるかどうかをチェックするために信号をＥｔ［ｊ］．ｇを通してＣ．ｆ［ｊ］に送信し、入園できる場合はその人をカウントする。公園内の人の数が許容されるｍａｘに既に達している場合は、人は入ることはできない。この合図は表Ｉにおいて、ブロック１のイベント［〈・矢印Ｃ．ｆ［ｊ］Ｄ〉］からブロック４のイベント〈Ｅｔ［ｊ］．ｇ：ｍＲ？（）〉までの並列起動を指定する分岐によって表されている。
【０４０４】
【表２】
0005704459.tif 000013
イメージ ID=000013
【０４０５】
この信号の送信後、Ｅｔ［ｊ］は付録ＩのＴＩＰ（Ｉ．３）に示している同期非決定的ガード（Ｅｔ［ｊ］．ｇ：ｍＲ？（）｜Ｅｔ［ｊ］．ｆ：ｍＲ？（））＊で応答を待つ。応答信号が受信された時に発生する２つの可能な選択肢を表のブロック１の下部に示している。選択は応答信号がＥｔ［ｊ］．ｇまたはＥｔ［ｊ］．ｆのいずれで受信されたかに基づいて２つの選択肢の因果チェーンに分岐している。分岐している因果チェーンの両方は、ここではＥｔ［ｊ］．ｆｔでの動作の次のサイクルの逐次起動で終了する。Ｅｔ［ｊ］．ｆｔの後で始まる次のサイクルは応答信号をＳｅ［ｊ］．ｇをセンサポートに送信する。したがって、次の人は、現在の人が完全にサービスされた後に初めて認識される。処理は次の人がゲートに来た時に繰り返される。したがって、表Ｉの仮想時間点はイベントが発生する時間インスタンスのシーケンスを示している。ブロック１で開始したプロセスの完全な各サイクルは、表Ｉに示しているようにブロック５が信号をブロック２に送信した後か、ブロック６が信号をブロック３に送信した後で終了する。表Ｉのブロック４、５、および６はカウンタで何が発生するかを記述している。システムは以下で説明するようにこのネットワークからその証明に必要な情報を取り出す。
【０４０６】
表Ｉのブロック４はその内部に入る２つの起動矢印を有しており、一方は左側の∃（ｉ）Ｃ．ｆ［ｉ］から来る逐次起動であり、他方は右側のＥｔ［ｊ］．ｇから来る並列起動である。逐次起動は、ポートＣ．ｆ［ｊ］が他のポートＣ．ｆ［ｉ］でのサービスの完了後初めてサービスを受けることを示している。もちろん、ｉ＝ｊ、つまり次にサービスを受ける人が同じゲートを通って入園することも可能である。この逐次起動が行われる時刻は、Ｃに信号が配信されているかどうかをテストするために、Ｃ．ｆ［ｊ］：ｍＲ？（）を実行してＣ．ｆ［ｊ］をポーリングする時である。Ｃは配信された信号を逐次と並列の起動が一致した時にだけ検知することができる。
【０４０７】
Ｅｔ［ｊ］．ｇｊからの並列起動が到着する前にＣ．ｆ［ｉ］からの逐次起動が最初に来ると、Ｃ．ｆ［ｊ］での信号検知は失敗し、ＣはポートＣ．ｆ［ｊ］をスキップし、次のポートのポーリングを開始する（ポートをスキップする場合を表Ｉに示しておらず、仮定している）。Ｃがあるポーリングサイクルでポートをスキップすると、信号が存在すればその信号を次のポーリングサイクルで取得する。Ｅｔ［ｊ］．ｇからの並列起動が最初に来ると、ＣはＣ．ｆ［ｊ］のポーリング時に信号を検知する。いずれの場合にも、Ｃは起動信号に即座には応答しない。これを、表Ｉの並列起動分岐に省略によって示している。
【０４０８】
配信信号検知に対する逐次と並列の制御転送の一致のこの要件は親セルからそれらのポーリングサイクルにおいてポーリングされる全てのポートで成立する。逐次制御転送は信号検知が埋め込まれているＴＩＰで他のＴＩＰ実行の一部として発生する場合に明示的であって、埋め込まれているＴＩＰでの検知は同期ガードのみを使用する。
【０４０９】
Ｃ．ｆ［ｊ］で信号を検知した後に、Ｃは表Ｉのブロック４の最後の選択点に到達する。ここで、選択は（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）の真理値によって定まる。選択後の以降のイベントの因果チェーンは、（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）がｔｒｕｅかｆａｌｓｅかによってＥｔ［ｊ］．ｇまたはＥｔ［ｊ］．ｆのいずれかを並列起動する。Ｅｔ［ｊ］はこれらの並列起動のいずれか一方に即座に応答するが、それは、付録ＩのＴＩＰ（Ｉ．３）に示しているように、Ｅｔ［ｊ］．ｇとＥｔ［ｊ］．ｆで、非決定的ガード（Ｅｔ［ｊ］．ｇ：ｍＲ？（）｜Ｅｔ［ｊ］．ｆ：ｍＲ？（））＊で、これらの信号を待っているからである。
【０４１０】
そのタスクをＣ．ｆ［ｊ］で完了した後、Ｃは表Ｉの下部に示しているように∃（ｉ）ｃ．ｆ［ｉ］を逐次起動する。これは、付録Ｉに定義されているポーリングサイクルに続く。同様に、表ＩＩは出口回転改札口Ｘｔ［ｊ］とＣｆ［ｊ＋２］との間の相互動作に関連付けられているＥＣＴブロックを示している。読者は、証明に必要な情報だけを選択して、セクション６．１．２の証明の構築を説明する時に、これらの表のイベントの流れをたどることができる。この点で、読者に付録Ｉを参照するように提案する。
【０４１１】
まとめ：表ＩとＩＩのＥＣＴブロック間の逐次起動がネットワークにおけるイベントの実行の順序付けを表している。これらは、ポーリングサイクルとセル内でＴＩＰが実行される順序によって定まる。各ブロック内の上から下へのＥＣＴ内のイベントの流れはイベントの因果順序を表している。因果順序はＴＩＰ実行中のイベントの流れによって定まる。ネットワークは付録ＩのポートＡＬＬＥＯＰとポーリングサイクル定義に整合しているポートＥＣＴの逐次／並列構成を示している。
【０４１２】
６．１．２．ＡＬＬＥＯＰ証明の構造
証明システムはＥＣＴネットワークを探索し、（ｉ）ＣＴＬアサーションにおいて前提とされている時間点の間のマッチの対応を識別し、（ｉｉ）ＣＴＬアサーション内の開始イベントから終了イベントまでのＥＣＴネットワーク内の因果チェーンを見つけ出し、（ｉｉｉ）主張が満足されていることを証明するために因果チェーンを分析する。この例では、探索は単純である。選択点と複数の並列起動（フォーク）のせいで発生する複雑さはない。そのような探索で発生する複雑さのいくつかはセクション６．４のＤＰ解法に現れる。
【０４１３】
証明システムは、ＣＴＬステートメント内に現れるイベントについて、ＣＴＬステートメントにおいて指定されたものと表ＩとＩＩのＥＣＴネットワーク内の仮想時間点との間の以下のマッチ時間点を表示する。
【０４１４】
ステートメント（６．２）についてのマッチ時間点、ｊ＝０，１
ｃｔｌ．ｔ０＝ｅｔ［ｊ］．ｔ０：Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）；（イベント開始）
ｃｔｌ．ｔ１＝ｃｆ［ｊ］．ｔ２：［・→ｃｏｕｎｔｅｒ＋＋］ｂｅｇｉｎｓ；
ｃｔｌ．ｔ２＝ｃｆ［ｊ］．ｔ３：［・→ｃｏｕｎｔｅｒ＋＋］ｅｎｄｓ；
ｃｔｌ．ｔ３＝えｔ［ｊ］．ｔ１：Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）；（イベント終了） （６．５）
ステートメント（６．３）についてのマッチ時間点、ｊ＝０，１
ｃｔｌ．ｔ４＝ｘｔ［ｊ］．ｔ０：Ｘｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）；（イベント開始）
ｃｔｌ．ｔ５＝ｃｆ［ｊ＋２］．ｔ２：［・→ｃｏｕｎｔｅｒ＋＋］ｂｅｇｉｎｓ；
ｃｔｌ．ｔ６＝ｃｆ［ｊ＋２］．ｔ３：［・→ｃｏｕｎｔｅｒ＋＋］ｅｎｄｓ；
ｃｔｌ．ｔ７＝ｘｔ［ｊ］．ｔ１：¬Ｘｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）；（イベント終了） （６．６）
（６．２）と（６．３）のイベントにそれぞれマッチする２つの可能性のある開始／終了イベントが存在し、（６．５）と（６．６）に示しているように、一方はｊ＝０についてであり、他方はｆ＝１についてである。システムはｊ＝０，１について（６．５）と（６．６）に対応するＥＣＴ内の開始イベントと終了イベントとの間の以下の因果チェーンも表示する。因果チェーンはトレースフォーマットで表される。
【０４１５】
［｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）〉（ｅｔ．ｔ０）｝［・→Ｓｅ．ｇＳ（ｓｅ［ｊ］ｇ．ｔ０）］
〈Ｅｔ［ｊ］．ｆｔ：ｍＲ？（〉Ｅｔ［ｊ］．ｆｔＤ〉（ｅ［ｊ］ｆｔ．ｔ０）））（ｅ［ｊ］ｆｔ．ｔ１）｝
［・→Ｅｔ［ｊ］．ｇＳ（ｅ［ｊ］ｇ．ｔ０）］［→〈Ｃ．ｆ［ｊ］Ｄ〉（ｅ［ｊ］ｇ．ｔ１＝ｃｆ［ｊ］．ｔ０）］
／／ここで並列起動が始まる
｜｜［・→．．．・→｛〈Ｃ．ｆ［ｊ］：ｍＲ？（）〉（ｃｆ［ｊ］．ｔ１）｝
｛（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）（ｃｆ［ｊ］．ｔ２）｝
［・→ｃｏｕｎｔｅｒ＋＋（ｃｆ［ｊ］．ｔ２）］
｛（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）（ｃｆ［ｊ］．ｔ３）｝
［・→Ｃ．ｆ［ｊ］Ｓ（ｃｆ［ｊ］．ｔ３）］・→
［〈→Ｅｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｇ．ｔ２）］・→．．．・→］
／／サービス要求を伴ってカウンタの次のポートまで続く
／／アクティビティはＣ．ｆ［ｊ］からの信号に応答してＥｔ［ｊ］でリジューム
｛〈Ｅｔ［ｊ］．ｇ：ｍＲ？（〈→Ｅｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｇ．ｔ２））＊〉（ｅ［ｊ］ｇ．ｔ２）｝
［・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）（ｅ［ｊ］ｇ．ｔ２）］
｛（Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（））（ｅｔ［ｊ］．ｔ１）｝
［・→Ｅｔ［ｊ］．ｆｔＳ（ｅｔ［ｊ］．ｔ１＜ｅ［ｊ］ｆｔ．ｔ２）］
［〈→Ｓｅ［ｊ］．ｇＤ）（ｅ［ｊ］ｆｔ．ｔ３）］］ （６．７）
ここで、入園が拒否された場合は無視するが、それはＣＴＬステートメントがそれを必要としないからである。
【０４１６】
［｛〈Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｘｔ．ｔ０）｝［・→Ｓｘ．ｇＳ（ｓｘ［ｊ］ｇ．ｔ０）］
〈Ｘｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｘｔ［ｊ］．ｆｔＤ〉（ｘ［ｊ］ｆｔ．ｔ０））〉（ｘ［ｊ］ｆｔ．ｔ１）｝
［・→Ｘｔ［ｊ］．ｇＳ（ｘ［ｊ］ｇ．ｔ０）］［→〈Ｃ．ｆ［ｊ＋２］Ｄ〉（ｘ［ｊ］ｇ．ｔ１＝ｃｆ［ｊ＋２］．ｔ０）］
｜｜［・→．．．・→｛〈Ｃ．ｆ［ｊ＋２］：ｍＲ？（）〉（ｃｆ［ｊ＋２］．ｔ２）｝
［・→ｃｏｕｎｔｅｒ――（ｃｆ［ｊ＋２］．ｔ２）］
｛〈ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ〉（ｃｆ［ｊ＋２］．ｔ３）｝
［・→Ｃ．ｆ［ｊ＋２］Ｓ（ｃｆ［ｊ＋２］．ｔ３）｝
［〈→Ｘｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｘ［ｊ］ｇ．ｔ２）］
｛〈Ｘｔ［ｊ］．ｇ：ｍＲ？（〈→Ｘｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｘ［ｊ］ｇ．ｔ２））＊〉（ｅ［ｊ］ｇ．ｔ２）｝
［・→Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）（ｘ［ｊ］ｇ．ｔ２）］
｛〈¬Ｘｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）〉（ｅｔ［ｊ］．ｔ１）｝
［・→Ｘｔ［ｊ］．ｆｔＳ（ｘ［ｊ］ｇ．ｔ３＜ｘ［ｊ］ｆｔ．ｔ１）］
［〈→Ｓｘ［ｊ］．ｇＤ）（ｘ［ｊ］ｆｔ．ｔ２）］ （６．８）
【０４１７】
システムがトレースを構築する時に、トレース内で発生するＥＣＴネットワーク内のイベントにマークを付け、イベントとそのタイミングを追跡する。このプロセスをＥＣＴネットワーク上でのＣＴＬステートメントシンボリック評価と呼ぶ。読者は表ＩとＩＩから続くトレース（６．７）と（６．８）を検証することができる。トレースの構築時に、同じ仮想時間点で発生する全ての条件を集めて結合状態にして、条件がチェーン括弧内に入れられ、信号検知動作に対して検知する配信信号を指定する引数が与えられ、それはイベントの検知直前にＥＣＴブロックで発生する。アクションイベントは角括弧内に入れられる。システムは、仮想時間点がイベントの開始と終了の時間を指定しているかどうかを追跡する。タイミングがネットワーク内のＥＣＴブロックの第２の列から取り出される。
【０４１８】
この点で、ユーザは要件に不完全な指定があることに気付く。（６．７）において、カウンタは半閉間隔［ｃｆ［ｊ］．ｔ２，ｃｆ［ｊ］．ｔ３）、ｊ＝０，１の間はアクティブである。（６．３）においては、カウンタは間隔［ｃｆ［ｊ＋２］．ｔ２，ｃｆ［ｊ＋２］．ｔ３）の間はアクティブである。カウンタがアクティブな時間間隔が交差しないことが［ｃｆ［ｊ］．ｔ２，ｃｆ［ｊ］．ｔ３）、ｊ＝０，１と［ｃｆ［ｊ＋２］．ｔ２，ｃｆ［ｊ＋２］．ｔ３）、ｊ＝０，１についても成立すべきことは指定されていない。ユーザは入口と出口の両方の回転改札口で全てのｊについて成立しなければならないことを指定することによって、ここでの状況を明確にする。
【０４１９】
システムはユーザによって現在更新されているＣＴＬアサーション（６．２）と（６．３）が満たされることを検証するために、（６．７）と（６．８）のトレースをここで分析しなければならない。プログレスを保証するために全てのＥＣＴネットワークによって満たされなければならない３つの一般的な要件がある。
【０４２０】
すべてのＥＣＴネットワークによって一般要件は以下とおりである：
ＧＲ−１。ＣＴＬステートメント内で前提とされている時間点はトレース内にマッチする点を有していなければならない。
【０４２１】
ＧＲ−２。セルによってそのポーリングサイクル内にポーリングされる各ポートは２つの起動を有していなければならず、一方は逐次起動であり、他方は並列起動であって、並列起動は検知された信号を配信する。
【０４２２】
ＧＲ−３。同期ポーリングのある各ポートは、ポーリングサイクル中にポーリングされるか、埋め込みＴＩＰでポーリングされるかに関わらず、最終的に並列起動によって配信された信号を有していなければならない。
【０４２３】
前述の３つの要件は全て表ＩとＩＩのネットワークによって満たされている。この例では以下の２つの追加の要件がある：（ａ）イベントのカウントは各因果チェーンにおいて１回だけ発生しなければならない、と（ｂ）２つのカウントの呼び出しは重なっていてはならない、である。７（６．７）と（６．８）の直接因果チェーンはポートＣ．ｆ［ｊ］、０≦ｊ＜４について、カウンタ＋＋またはカウンタ−−が各因果チェーンにおいて１回だけ発生することを示している。これは要件（ａ）を満たす。システムは要件（ｂ）も満たされていることを認識する。これは、表ＩとＩＩの［∃（ｉ）（０≦ｉ＜５）Ｃ．ｆ［ｉ］］の逐次起動からわかる。ｉ＝４については、Ｃは表示ユニットからのｃｏｕｎｔｅｒ．ｃｏｕｎｔに対する要求に応答し、これはカウンタによるカウントを呼び出さない。したがって、Ｃ．ｆ［ｊ］、０≦ｊ＜４について、カウンタによるカウントの第２の呼び出しは第１の呼び出しが完全にサービスを受けた後で初めて発生する。したがって、Ｃのカウンタがカウントをしている間隔は重ならない。これで、ユーザによって更新されたｓｔｍｔ１とｓｔｍｔ２の証明が完了する。
【０４２４】
公園内の人の総数が常にｍａｘ以下であることを証明することによって、ｓｔｍｔ３が有効であることを確認する。これは、Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ，［１３］の条件同期に対応する。これは、ＮＦＳＰ証明であって、以下の種類の帰納的推論を要求する。
【０４２５】
基礎：ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＝０≦ｍａｘ。
【０４２６】
帰納的推論の仮説：ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＝Ｎ≦ｍａｘ。
【０４２７】
帰納的推論のステップ：［（Ｅｔ［０］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）∨Ｅｔ［１］：ｐｅｒｓｏｎＩｎＰａｒｋ？（））⇒
ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）＆
（¬Ｘｔ［０］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）∨¬Ｘｔ［１］：ｐｅｒｓｏｎＩｎＰａｒｋ？（））］））⇒
ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ） （６．９）
ユーザは、以下のＣＴＬアサーションを提供することによってシステムが帰納的推論のステップを証明するように導く
［∀（ｉ，ｊ）（０≦ｊ＜１）∃（ｅ［ｊ］．ｔ０＜ｅ［ｊ］．ｔ１）∃（ｘ［ｊ］ｔ０＜ｘ［ｊ］．ｔ１）
［｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）〉（ｅ［ｊ］．ｔ０）｝→．．．→
［〈・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）〉（ｅ［ｊ］ｇ．ｔ１）］
｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ＆ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ〉（ｅ［ｊ］．ｔ１）｝］＆ （６．１０）
［｛〈Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｘ［ｉ］．ｔ０）｝→．．．→
［〈・→Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＯｕｔ（）〉（ｘ［ｉ］．ｔ１）］
｛〈¬Ｘｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ＆ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ〉（ｘ［ｉ］．ｔ１）｝］］ （６．１１）
【０４２８】
システムは付録Ｉに示しているｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）とｐｅｒｓｏｎＬｅａｖｉｎｇ？（）の定義を使用し、回転改札口の対の全ての考え得る順序について表ＩとＩＩのＥＣＴ上で（６．１０）と（６．１１）とを評価することによってそれらを確認するが、それは、各対（ｅ［ｊ］．ｔ０＜ｅ［ｊ］．ｔ１）および（ｃｘ［ｉ］．ｔ０＜ｘ［ｉ］．ｔ１）、０≦ｊ≦１における開始と終了の時間点は比較不能だからである。たとえば、ゲートＥｔ［０］．ｆｔの人の入場が許可され、その人が庭に入る前に、ゲートＥｇ［１］．ｆｔの人も入場が許可され、この第２の人が第１の人の前に実際に庭に入ることは大いにあり得ることで、それは人が庭に入ったり出たりする時刻は比較不能だからである。その間に、他の人が庭から出ることもあり得る。人がどのような順序で庭に入ったり出たりしようが、Ｅｔ［ｊ］．ｆｔとＸｔ［ｊ］．ｆｔの人が庭に入ったり出たりした後でｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘが成立する。これは、因果チェーン（６．７）と（６．８）とによって確認される。必要なだけ入口と出口のゲートをインストールすることが可能で、機能的推論は依然として成り立つ。帰納的推論による証明にはユーザの誘導が必要である。
【０４２９】
システムが、トレースとポーリングサイクルの情報を、ＥＣＴブロックの所与のＣＴＬステートメント内の時間点にマッチする時間点を見つけるのに便利なネットワークに構成し、ＣＴＬステートメントの開始と終了イベントにマッチするトレースを構築することは明かである。ＥＣＴネットワーク内で識別された因果チェーンは容易にトレースフォーマットに変換される。
【０４３０】
６．１．３ コメント
ここで証明された主張は、実装の属性であるが、それはＡＬＬＥＯＰとトレースが実装から自動的に生成されたからである。ただし、あるセルから別のセルへ制御を転送すると、ＣＴＬステートメントのＥＣＴ上でのシンボル評価は並列に行われるが、それはＣＰＵを各セルに割り当てているからである。この例では、ＥＣＴが単純であって、並列評価は必要ない。ここでは逐次合成だけが発生するが、それは各入口と出口について、回転改札口はカウンタがそのタスクを完了するまで待ち、１つのゲートを通した各入園と出園のサービスはカウンタによって逐次行われるからである。ここで必要な唯一の論理的な帰納的推論は、前述の（Ｉ．４）と（Ｉ．１１）を組み入れるためだけである。ほとんどのｐｔｈｒｅａｄは対について独立しており、独立して正しいと証明可能で、従属ｐｔｈｒｅａｄはまとめて正しいことが独立して証明され、ＣＴＬステートメントの証明には、実装のＥＣＴネットワーク内の因果シーケンスの追跡と、所与のＣＴＬアサーション内の条件が満足されていることを検証するための因果チェーンの分析だけが伴う。
【０４３１】
ＣＴＬステートメントを満たす因果チェーンはそれらのステートメントを確認する。ＣＴＬステートメントが有効ではない場合、この証明方法は反例を提供する。終了イベントに到達できず、ＡＬＬＥＯＰが有限ＡＬＬＥＯＰの場合、証明は反例で終了することになる。非有限ＡＬＬＥＯＰについては、証明は終了せず、ユーザの介入が必要なことがある。必要な因果チェーンを見つけた後、システムはイベントの排他属性と半順序付けを確認するために逐次および並列起動を分析する。証明方法は対話的である。証明の各段階で、システムはその発見したものをユーザに示し、見つけたものを元にして所与のＣＴＬステートメントを修正するか、証明の探索を導くことができる新規のアサーションを提供するかのいずれかの機会をユーザに与える。この例では、マッチする時間点と因果チェーンの識別は容易である。セルの追跡が伴うより複雑な証明はセクション６．４のＤＰ解法で発生する。全ての場合において、ユーザはセクション６．５で説明するように有効性が実装の正しさを証明するＣＴＬステートメントの集合を選択する責任がある。複雑な実装については、これは重大な問題である。
【０４３２】
この例は、仮想メモリ無しに点対点信号交換だけを使用した。残りの例は仮想メモリをその経路で使用する。そのため、まず仮想メモリの構造とそれに関連付けられている動作を紹介する。
【０４３３】
６．２．仮想メモリの構造
図１１は仮想メモリの模式図である。４つのコンポーネント、スクラッチパッドＳＰ、ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ、Ｅ、ｗｒｉｔｅＭｅｍｏｒｙ、Ｗ、およびｒｅａｄＭｅｍｏｒｙ、Ｒを有している。ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙはｐｔｈｒｅａｄを保持しており、それらのための実行環境を提供する。実行メモリ内のデータの各項目には存在していればメインメモリまたはデータベース内のその身元を参照しているキーによってフラグを立てることが可能であると仮定している。セルのグループが同じ仮想メモリ、Ｍを使用する場合、グループ内の各セルはポートグループに属しているポートを有していなければならず、そのポートグループ内の全てのポートはＭに付属している同じエージェントに対してチューンされていなければならない。そのようなセルグループ内のセルは、ＭのｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙによって提供されるｐｔｈｒｅａｄの実行時にＭのスクラッチパッドＳＰを使用してデータを交換することができる。データベースやメインメモリのデータは仮想メモリにコピーされた後で初めてセルグループによって共有することができる。
【０４３４】
ｗｒｉｔｅＭｅｍｏｒｙは送出されたメッセージを保持しており、ｒｅａｄＭｅｍｏｒｙは配信されたメッセージを保持している。ｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙはメッセージがメッセージを配信するエージェントによって配信される前に切り替えられる。したがって、各受信者はｒｅａｄＭｅｍｏｒｙからのその入力メッセージを読む。ポートｐはｒｅａｄＭｅｍｏｒｙ内のメッセージを送信コマンドｐ：ｓ（）の代わりに経路によって接続されているポートｑに転送コマンドｐ：ｆ（）を使用して転送することができる。転送コマンドが使用される場合、ｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙは切り替えられない。転送コマンドは、セクション６．４に示すＤＰ解法（食事をする哲学者）において使用される。送信／転送コマンドを区別するプロトコルをセクション７で説明する。
【０４３５】
0005704459.tif 000014
【０４３６】
図１１：仮想メモリ
前述のように、各ポートｐはＭに付属しているエージェントへのブランチを通して接続されている仮想メモリ、Ｍにチューンされている。「ｐの仮想メモリ」はそのようにｐに対してチューンされている仮想メモリを指す。ｐの仮想メモリのｒｅａｄＭｅｍｏｒｙ、ｗｒｉｔｅＭｅｍｏｒｙ、スクラッチパッド、およびｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙをそれぞれ指すようにメモリｐ．ｒｄ、ｐ．ｗｒ、ｐ．ｓｐ、およびｐ．ｅｘと書く。ｐがブランクインスタンス、ｍｓｇ（ｍｓｇのコンテナ）を仮想メモリ、Ｍに何らかの既定のデータ値と共に書くことを示すためにｐ．ｗｒ：ｗｒ（ｍｓｇ）＝ｐ：ｗｒ（ｍｓｇ）と書く。Ｍの他のコンポーネントについてと同様に、Ｍｓｇのコンテナを仮想メモリのｒｅａｄＭｅｍｏｒｙに書き込むためにｐ．ｒｄ：ｗｒ（ｍｓｇ）を使用する。それぞれＭのｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙ内のメッセージを指すためにｐ．ｒｄ：ｍｓｇ（）＝ｐ：ｍｓｇ（），ａｎｄｐ．ｗｒ：ｍｓｇ（）と書く。仮想メモリ内に既にコンテナが存在していない場合、Ｍｓｇのインスタンスを指定されたデータと共にｐのｗｒｉｔｅＭｅｍｏｒｙに書き込むためにｐ：ｍａｋｅ（ｍｓｇ，［〈ｄａｔａＳｐｅｃｉｆｉｃａｔｉｏｎｓ〉］）を使用する。仮想メモリ内にコンテナが存在する場合、ｍａｋｅコマンドが指定されたデータでそれを満たす。ｐ．ｒｄ：ｍａｋｅ（ｍｓｇ，［〈ｄａｔａＳｐｅｃｉｆｉｃａｔｉｏｎｓ〉］）はｒｅａｄＭｅｍｏｒｙに対して同じことを行う。これらのｍａｋｅおよびｗｒｉｔｅメソッドは、仮想メモリのＲｅａｄＭｅｍｏｒｙ／ＷｒｉｔｅＭｅｍｏｒｙ／ｓｃｒａｔｃｈｐａｄ／ＥｘｅｃｕｔｉｏｎＭｅｍｏｒｙ内で定義されている。
【０４３７】
ほとんどのアプリケーションで、必要なメッセージサブクラスのコンテナは初期化時に仮想メモリ内にインストールされる。したがって、通常、ｍａｋｅコマンドだけが使用される。Ｍｅｓｓａｇｅサブクラスとそれらの中で定義されているメソッドのコンパイルされたコードとは仮想メモリのｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ内に保持されている。したがって、仮想メモリ内のＭｅｓｓａｇｅサブクラスの全てのメソッドとデータは、これらの仮想メモリにポートがチューンされているセルによって、それらのポートが状態Ｓにある時に利用可能である。２つ以上の仮想メモリが同じＭｅｓｓａｇｅサブクラスのコードを含んでいてもよい。
【０４３８】
ｐ：ｍｓｇ（）：ｅｍｐｔｙ？（）を使用して、ポートｐのｒｅａｄＭｅｍｏｒｙが空かどうか、つまり何らかのデータを含んでいないかをチェックし、ｗｒ：ｍｓｇ（）：ｅｍｐｔｙ？（）を使用して、ポートｐのｗｒｉｔｅＭｅｍｏｒｙ内のメッセージに対して同じことをチェックする。同様に、ｐ：ｍｓｇ（）．ａｔｔｒｉｂｕｔｅ：ｅｍｐｔｙ？（）およびｐ．ｗｒ：ｍｓｇ（）．ａｔｔｒｉｂｕｔｅ：ｅｍｐｔｙ？（）がメッセージの指定された属性がｐの仮想メモリのｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙにおいて空であることを確認するために使用される。指示されているメモリが空であること、つまりコンテナが存在していないことをチェックするためにｐ．ｒｄ：ｅｍｐｔｙ？（）ａｎｄｐ．ｗｒ：ｅｍｐｔｙ？（）を使用する。仮想メモリのｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙの内容をクリアするためにｐ：ｃｌｅａｒ（）を使用する。同様に、ｒｅａｄＭｅｍｏｒｙまたはｗｒｉｔｅＭｅｍｏｒｙだけをクリアするためにｐ．ｒｄ：ｃｌｅａｒ（）とｐ．ｗｒ：ｃｌｅａｒ（）を使用する。同様に、スクラッチパッドとｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙについてもアサーションが定義されている。
【０４３９】
図１９は一般ポートグループＧのポートを機能ポートグループＦのポートに接続しているグループ対グループの経路の構造を説明している。この図のポートグループのポートの全ての親セルは図に示している同じ仮想メモリ、Ｍを使用している。仮想メモリ、Ｍを使用するセルグループの各セルはメモリのデータをそれにアクセスした時にだけ読むことができる。アクセスはポートグループのポートによって制御される。任意の所与の時刻に、ポートグループＧのポートの親セルがＭにアクセスするか、グループＦのポートの親セルがＭにアクセスするかのいずれかであって、それら両方が同時にＭにアクセスすることはできない。仮想メモリ、Ｍにチューンされている任意のポートグループに属しているポートの親セルは、共通に共有されているデータとｐｔｈｒｅａｄにアクセスしそれらを使用してＭのｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙのｐｔｈｒｅａｄを同時に実行することができる。
【０４４０】
同じ仮想メモリ、Ｍを使用したポートグループのポートの親セルによるそのような同時の並列実行の調和は、以下によって促進され、それらは（ｉ）仮想メモリ内の共有データへの同時のリードアクセスの便宜、（ｉｉ）データ更新の調和が必要なｐｔｈｒｅａｄロックの使用の便宜、および（ｉｉｉ）計算を調和させるための並列実行中の共有スクラッチパッドメモリを通した通信の便宜である。ｐｔｈｒｅａｄロックが使用されると、同時の並列実行を行うセルグループのセルにだけ適用される。メモリ競合の可能性はセルグループ内のセルの数を限定することによって限定される。実際には、セルグループ内のセルの数は１０または２０を超えることはないと予測する。データの上書きを防止しデータを保護するために、セルグループのセルが書き込める仮想メモリの領域は限定されている。同じ仮想メモリにチューンされているポートグループ内のポートは、それらのポートの親セルがデータを書き込むことができる重なっていないメモリ領域のアドレスを保持していてもよい。これらの便宜は、メモリ競合を効果的に最小化するために使用可能である。
【０４４１】
この点で、ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンス上での条件移行のための規則を導入する。ｐ：ｓ（）を使用したメッセージ送信の場合、以下のメッセージ特徴付け条件はｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙとの間で切り替えられる。ｐ：ｆ（）を使用したメッセージ転送の場合、条件は切り替えられない。
【０４４２】
□［｛（ｐ．ｒｄ：＜Ｃ１？＞？（）＆ｐ．ｗｒ：＜Ｃ２＞？（））（ｔ１）｝［ｐＳ（ｔ１）｝→〈ｑＤ〉（ｔ２）］
｛（ｑ．ｒｄ：＜Ｃ２＞？（）＆ｑ．ｗｒ：＜Ｃ１＞？（））（ｔ２）｝］ （６．１２）
□［｛（ｐ．ｒｄ：＜Ｃ１？＞？（）＆ｐ．ｗｒ：＜Ｃ２＞？（））（ｔ１）｝［ｐＦ（ｔ１）｝→〈ｑＤ〉（ｔ２）］
｛（ｑ．ｒｄ：＜Ｃ１＞？（）＆ｑ．ｗｒ：＜Ｃ２＞？（））（ｔ２）｝］ （６．１３）
（６．１３）のｐＦの上付き文字Ｆはメッセージが転送されていることを示している。
【０４４３】
次の２つのサブセクションは、ＰＣ（生産者／消費者）解法、ＤＰ解法、およびそれらに関するＡＬＬＥＯＰ証明を示している。解法は、セマフォ［Ｄｉｊｋｓｔｒａ，２３，２４］、モニタ［Ｈｏａｒｅ，１２］、または逐次バッファを使用する必要なしに実装されている（これについては５〜６回記述しているが、繰り返す価値があり、セマフォとモニタはプログラミング技術において十分に確立した機構であり、不可欠と考えられている。それらは４０年以上も使用されている！）
【０４４４】
６．３．生産者／消費者の解法：ＰＣ解法
ここでの我々の目的は並列バッファの使用を示すことである。ＰＣ解法のネットワークを図１２に示しており、解法を付録ＩＩに示している。それは、ｎ人の生産者Ｐ［ｉ］、０≦ｉ＜ｎと卸売業者Ｄに接続されているｍ人の消費者Ｃ［ｊ］，０≦ｊ＜ｍを有している。環境セルＥは、外部割り込み信号に基づいたアプリケーションの開始／停止に使用される。生産者に対してチューンされている仮想メモリはＤに送る製品の並列バッファを提供する。消費者ポートＣ［ｊ］．ｇに対してチューンされている仮想メモリは製品を消費者に送るために使用される。実装のＣＩＰ、ＴＩＰ、ポーリングサイクル、およびＡＬＬＥＯＰについては付録ＩＩを参照。以下を証明したい。
【０４４５】
（Ｓｔｍｔ１）製造された各製品は卸売業者に配送される。
【０４４６】
（Ｓｔｍｔ２）製品に対する要求のある各消費者が製品を得る。
（Ｓｔｍｔ１）と（Ｓｔｍｔ２）についてのＣＴＬステートメント：
（Ｓｔｍｔ１）：□［∀ｊ∀ｘ［ｘ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）◇（Ｄ．ｇｊ：ｍｓｇ（）．ｃｏｎｔｅｎｔ＝ｘ）］ （６．１４）
（Ｓｔｍｔ２）：□［∀ｊ（Ｃ［ｊ］．ｇＳ◇Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ）］ （６．１５）
（６．１４）において、生産者Ｐ［ｊ］は製品を製造し、卸売業者は最終的にそれをそのポートＤ．ｇｊで受け取る。（６．１５）において、消費者Ｃ［ｊ］はＣ［ｊ］．ｇＳを実行することによって製品に対する要求を送信し、最終的に製品を得る。システムによって実行される最初のタスクは、ｊに対する普遍例化∀ｊと製品に対する∀ｘによって、セクション５の規則（５．３２）と表ＩＩＩのＥＣＴネットワークとを使用し、時間点を前提として、モード演算子□と◇を除去することによって（６．１４）と（６．１５）とを変換することである。結果のＣＴＬステートメントを（６．１６）と（６．１７）に示す。このタスクはこの例では簡単になるが、それは各ｊについて１つの一意の因果チェーンだけが存在するからである。
【０４４７】
0005704459.tif 000015
【０４４８】
図１２：ＰＣ解法用のネットワーク
変換されたＣＴＬステートメント
（Ｓｔｍｔ１ａ）：□［∃（ｃｔｌ．ｔ０＜ｃｔｌ．ｔ１＜ｃｔｌ．ｔ２
［・→ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）（ｃｔｌ．ｔ０）］
［・→Ｐ［ｊ］．ｆ．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ（ｃｔｌ．ｔ１）］
→．．．→（Ｄ．ｇ［ｊ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔ＝ｐｒｏｄｕｃｔ〉（ｃｔｌ．ｔ２）］ （６．１６）
Ｓｔｍｔ２ａ）：［∀（ｃｔｌ．ｔ３）∃（ｃｔｌ．ｔ３＜ｃｔｌ．ｔ４＜ｃｔｌ．ｔ５）
／／消費者Ｃｊ］は要求を送出
Ｃ［ｊ］．ｇＳ（ｃｔｌ．ｔ３）→（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｃｔｌ．ｔ４）
→．．．→Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ（ｃｔｌ．ｔ５）］ （６．１７）
【０４４９】
ＰＣ解法のＥＣＴネットワークを表ＩＩＩに示している。このネットワークに埋め込まれている情報は多すぎて読者には容易に理解できない。証明の説明が進むにつれて必要な情報を取り上げる。セクション６．１で説明した一般的な要件ＧＲ−１とＧＲ−２は表ＩＩＩのＥＣＴネットワーク内ネットワークによって満たされている。しかし、即座にＧＲ−３が満たされていることにならない。ブロック３の第３行の（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊によって実施される配送された製品の検索が毎回成功することを証明しなければならない。
【０４５０】
ステートメント（６．１６）と（６．１７）の表ＩＩＩのＥＣＴ上での評価によって以下のマッチ時間点が生じる（表ＩＩＩのブロック内の時間点に対応するイベントの参照を以下に示し、各ブロックにおいて行番号は上から下である）。
【０４５１】
ｃｔｌ．ｔ０＝ｐ［ｊ］ｆ．ｔ２：Ｐ［ｊ］が製品を製造する：第３行，ブロック５
ｃｔｌ．ｔ１＝ｐ［ｊ］ｆ．ｔ３；それをｗｒｉｔｅＭｅｍｏｒｙに格納する：第４行、ブロック５
ｃｔｌ．ｔ２＝ｐ［ｊ］ｆ．ｔ５；それをＤ．ｇ［ｊ］に配送：最後の行、ブロック５ （６．１８）
（６．１７）について、：ｃｔｌ．ｔ３＝（ｃ［ｊ］Ｉ．ｔ２｜ｃ［ｊ］ｇ．ｔ３）；Ｃ［ｊ］が製品に対する要求を送信、
第３行、ブロック１と最後の行、ブロック２
ｃｔｌ．ｔ４＝ｄｇ［ｋ］ｔ．ｔ０；Ｄが検索を開始：第３行、ブロック３
ｃｔｌ．ｔ５＝ｃ［ｊ］ｇ．ｔ２；消費者はそれを得る：第５行、ブロック２ （６．１９）
表ＩＩＩ：ＰＣ解法ＥＣＴネットワーク
【０４５２】
【表３】
0005704459.tif 000016
イメージ ID=000016
【０４５３】
システムはＣＴＬステートメント内のイベントの流れに対応している表ＩＩＩのＥＣＴネットワーク内のイベントの流れを特定し、それらをトレースフォーマットにする。それを以下に示し、トレース（６．２０）は生産者Ｐ（ｊ）が新規の製品の注文を検知した時刻から製品が卸売業者ポートＤ．ｇ［ｊ］に配信された時刻までのイベントの流れを示している。
【０４５４】
Ｐ［ｊ］．ｆ：ｔｒａｃｅ（ｐ［ｊ］ｆ．ｔ０）＝
｛〈Ｐ［ｊ］．ｆ：ｍＲ？（〈Ｐ［ｊ］．ｆＤ〉（ｐ［ｊ］ｆ．ｔ０）〉（ｐ［ｊ］ｆ．ｔ１）｝
［・→ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）（ｐ［ｊ］ｆ．ｔ２）］
［・→Ｐ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ（ｐ［ｊ］ｆ．ｔ３）］
［・→Ｐ［ｊ］．ｆＳ（ｐ［ｊ］ｆ．ｔ４）］
（［→〈Ｄ．ｇ［ｊ］Ｄ〉（Ｐ［ｊ］ｆ．ｔ５）］
｜｜｛（Ｄ．ｇ［ｊ］．ｒｄ．ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ）（ｐ［ｊ］ｆ．ｔ５）｝
→．．．→｛（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｄｇ［ｋ］ｔ．ｔ０，ｐ［ｊ］ｆ．ｔ５）｝）
→Ｐ［ｊ］．ｆ：ｔｒａｃｅ（ｐ［ｊ］ｆ．ｔ５）］ （６．２０）
トレース（６．２０）は以下を指定している：ポートＰ［ｊ］．ｆでメッセージの受信を検知すると、Ｐ［ｊ］は製品を製造し、Ｐ［ｊ］．ｆのｗｒｉｔｅＭｅｍｏｒｙ内に入れ、それをＤ．ｇ［ｊ］に送り、Ｄ．ｇ［ｊ］はそれをそのｒｅａｄＭｅｍｏｒｙでいくらか後に受け取る。これが（６．１６）を確認する。ただし、（６．２０）の最後から２番目の行の２つの時間点（ｄｇ［ｋ］ｔ．ｔ０，ｐ［ｊ］ｆ．ｔ５）は比較不能である。したがって、製品の配送と製品の検索とは同期していない。
【０４５５】
以下のトレース（６．２１）はＣ［ｊ］が製品を要求した時刻からＣ［ｊ］が製品を入手した時刻までのイベント因果チェーンを表示する。
【０４５６】
Ｃ［ｊ］．ｇ：ｔｒａｃｅ（ｃ［ｊ］ｇ．ｔ０）＝
｛〈Ｃ［ｊ］．ｇ：ｕｓｅｄＵｐ？（）＊〉（ｃ［ｊ］ｇ．ｔ３）｝［・→Ｃ［ｊ］．ｇＳ（ｃ［ｊ］ｇ．ｔ３）］
（［〈→Ｄ．ｆ［ｊ］Ｄ〉（ｃ［ｊ］ｇ．ｔ４）］
｜｜［→．．．→｛〈Ｄ．ｆ［ｊ］：ｍＲ？（〈Ｄ．ｆ［ｊ］Ｄ〉（ｃ［ｊ］ｇ．ｔ４＝ｄｆ［ｊ］．ｔ０）））（ｄｆ［ｊ］．ｔ１｝
｛〈（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｄｇ［ｋ］ｔ．ｔ０）〉（ｄｇ［ｋ］．ｔ１｝
{〈∃（ｐｒｏｄｕｃｔ）Ｄ．ｇ［ｋ］．ｒｄ．ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝
ｐｒｏｄｕｃｔ〉（ｄｇ［ｋ］ｔ．ｔ０）｝
［・→Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）（ｄｇ［ｋ］ｔ．ｔ１）］
｛〈Ｄ．ｇ［ｋ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ＆
Ｄ．ｆ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ〉（ｄｇ［ｋ］ｔ．ｔ２）｝
［・→Ｄ．ｇ［ｋ］ｓ（ｄｇ［ｋ］ｔ．ｔ２）］／／新規の製品の注文を送信
（［〈→Ｐ［ｋ］．ｆＤ〉（ｄｇ［ｋ］ｔ．ｔ３）］／／生産者に注文が配信される
｜｜→．．．→Ｐ［ｊ］．ｆ：ｔｒａｃｅ（ｐ［ｊ］ｆ．ｔ０≧ｄｇ［ｋ］ｔ．ｔ３）
［・→Ｄ．ｆ［ｊ］Ｓ（ｄｆ［ｊ］ｔ．ｔ３）］／／消費者に製品を発送
（［〈・→Ｃ［ｊ］．ｇＤ〉（ｄｆ［ｊ］ｔ．ｔ４）］／／製品を消費者に配送
／／Ｄは次の機能ポートのポーリングに進む
［・→∃（ｉ）（０≦ｉ＜ｍ）Ｄ．ｆ［ｉ］：ｔｒａｃｅ（ｄｆ［ｉ］．ｔｏ＝ｄｆ［ｊ］ｔ．ｔ４）］）］
／／消費者Ｃ［ｊ］に何が起こったかに戻る。以下では、消費者が配送を検知
｛〈Ｃ［ｊ］．ｇ：ｍＲ？（〈Ｃ．ｇ［ｊ］Ｄ〉（ｃ［ｊ］ｇ．ｔｏ＝ｄｆ［ｊ］ｔ．ｔ４））〉（ｃ［ｊ］ｇ．ｔ１）｝
｛〈Ｃ［ｊ］．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ〉（ｃ［ｊ］ｇ．ｔ１）｝
［・→Ｃ［ｊ］．ｇ：ｐｉｃｋＵｐ（）（ｃ［ｊ］ｇ．ｔ１）］
｛（Ｃ［ｊ］．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ＆Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ〉（ｃ［ｊ］ｇ．ｔ２）｝ （６．２１）
（６．２１）のイベントの流れは、検索∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊，が毎回成功する場合にだけ保証される。Ｄ．ｇ［ｋ］はＰ［ｋ］．ｆからの配送を受け取る。（６．２１）の検索、
｛〈（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｄｇ［ｋ］ｔ．ｔ０）〉（ｄｇ［ｋ］．ｔ１｝
は時刻ｄｇ［ｋ］ｔ．ｔ０に始まり、製品がＤ．ｆ［ｊ］に移動する時刻ｄｇ［ｋ］ｔ．ｔ１に終了する（表Ｉのブロック３の行５を参照）。この検索はｄｇ［ｋ］ｔ．ｔ１の前にＤ．ｇ［ｋ］に製品を配達したＰ［ｋ］．ｆ、０≦ｋ＜ｎが存在し、この製品がｄｇ［ｋ］ｔ．ｔ１の前に既に使用されていない場合にだけ毎回成功する。
【０４５７】
帰納的証明は次のように進行する。検索はその初期化中に卸売業者Ｄが行った注文のせいで最初の顧客については成功する。表ＩＩＩのブロック４と５の最後の行を参照。Ｎ番目の試みで成功すると仮定する。（Ｎ＋１）番目の試みは成功するが、それは製品がＮ番目の試みにおいて、たとえはポートＤ．ｇ［ｉ］において使用されると、新規の注文が製造者Ｐ［ｉ］に対して行われるからである。ブロック２の第８行と（６．２１）のＤ．ｇ［ｋ］ｓ（ｄｇ［ｋ］ｔ．ｔ２）の後のコメントを参照。製品が見つかるまで検索が継続するので、Ｐ［ｉ］がその注文に応答した時に確実に成功するか、検索によって他のポートＤ．ｇ［ｊ］において未使用の製品を見つけることがあり得る。システムは、ユーザによって提供されたアサーションを確認することによってこれを対話的に証明する。詳細をここで説明しない。そのため、（６．２１）については、各消費者は要求した製品を受け取る。
【０４５８】
これはセクション６．１の要件ＧＲ−３を満たす。しかし、プログレスを保証するには、以下の仮定が必要である。
【０４５９】
公理：□（∃（ｉ，ｔ）［・→Ｃ［ｉ］．ｇＳ（ｔ）］） （６．２２）
つまり、製品に対する要求のある顧客が常に存在し、それは各製品が最終的に使用されることになると言うのと同じである。そうでなければ、ビジネスは停止し、卸売業者はポーリングサイクルを実行しながらその空のポートを回り続けるだけである。また、製品について十分な要求がない場合、製品が回り続けるだけのことがあり得る。指定した長さの時間を超えて回り続ける場合、製造者をサスペンドするために製品ＣＩＰを再定義することができる。要求が発生し、後に注文が配信されると自動的に動作をリジュームする。
【０４６０】
コメント：証明の構築において直面する問題の１つは、ＦＳＰ記述の正規表現における単純な「スター演算」が要件を確認できる状況では帰納的推論による証明に頼らなければならないことである。これが発生するのは、「状態」を有していないからだけでなく、並列動作中の本質的な非同期のためである。ほとんどの場合、帰納的証明は、非常に自明であって、うまくいけばシステムが証明を自動的に構築する戦略を考え出すことが可能である。
【０４６１】
６．４．食事をする哲学者の解法：ＤＰ解法
ＤＰ解法ネットワークを図１３に示している。ゲームを開始し停止する図には示していない環境セルが存在する。執事、つまり要求されるとフォークを配り、食料を供給し続けるｂｔｌｒ（図１３ではＢが付けられている）が存在する。哲学者はｂｔｌｒから２本のフォークを受け取った後でだけ食事を始めることができる。図に示しているように、テーブル上には５本のフォーク、ｂｔｌｒ．ｆｒｋ［ｊ］があり、５人の哲学者、Ｐ［ｊ］、０≦ｊ＜５が存在する。各哲学者Ｐ［ｊ］は左隣の哲学者Ｐ［ｊ（○＋）５４］とｂｔｌｒ．ｆｒｋ［ｊ］を共有し、右隣の哲学者Ｐ［ｊ（○＋）５１］とｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］を共有する。したがって、２人の隣り合った哲学者は同時に食事をすることはできない。
【０４６２】
哲学者Ｐ［ｊ］は空のメッセージを機能ポート、ｂｔｌｒ．ｆ［ｊ］に送信することによって、フォークの要求を送信する。両方のフォーク、ｂｔｌｒ．ｆｒｋ［ｊ］とｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］が使用可能な場合、ｂｔｌｒはフォークをｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙのコンテナに入れ、送出する。いったんこれが行われると、フォークはＰ［ｊ］が食事を終えてフォークを返却するまでＰ［ｊ（○＋）５１］とＰ［ｊ（○＋）５４］には利用できなくなる。Ｐ［ｊ］がフォークを要求した時に哲学者Ｐ［ｊ（○＋）５４］が食事中であったり、Ｐ［ｊ（○＋）５１］が食事中であったり、Ｐ［ｊ（○＋）５１］が左のフォークｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］を予約して待っている場合、Ｐ［ｊ］はフォークを利用できない。この場合、ｂｔｌｒはＰ［ｊ］の左のフォークｂｔｌｒ．ｆｒｋ［ｊ］を予約して、Ｐ［ｊ］は両方のフォークが利用可能になるまで待つ。ｂｔｌｒ．ｆｒｋ［ｊ］がいったん予約されると、Ｐ［ｊ］が食べ終わる前にＰ［ｊ（○＋）５４］は食事を（再び）開始できない。Ｐ［ｊ］によって食事が終わった後にフォークが返却された時に初めてｂｔｌｒ．ｆｒｋ［ｊ］は予約を解除される。
【０４６３】
0005704459.tif 000017
【０４６４】
図１３：ＤＰ解法用のネットワーク
各哲学者Ｐ［ｊ］は食事が終われば常にフォークを返却し、考える状態Ｔ［ｊ］に入る。しばらく考えたあと、彼／彼女は再び空腹になって、フォークを注文する。執事は、哲学者たちのサービスを循環する順序Ｐ［０］→Ｐ［ｌ］→Ｐ［２］→Ｐ［３］→Ｐ［４］→Ｐ［０］→．．．→でゲームが終了するまで行う。ゲームの任意の時点で、Ｐ［ｊ］は３つの考え得る状態：Ｅ［ｊ］（食事）、Ｔ［ｊ］（思索）、またはＷ［ｊ］（フォークを待っている）の１つとなることができる。ゲームは全ての哲学者が状態Ｔ［ｊ］にあって、全てのフォークがテーブル上にあり任意の哲学者が利用可能であって、食べ物の準備ができている時に始まる。フォークの要求を送信し、要求が最初に検知された哲学者Ｐ［ｊ］は、全ての哲学者がフォークに対する要求を同時に送信しても最初にｂｔｌｒのサービスを受け、最初にフォークを取得する。Ｐ［ｊ］がフォークを取得した後、Ｐ［ｊ（○＋）５２］がフォークを要求していた場合に、次にフォークを取得するかもしれない。それから両方が食事を始め、状態Ｅ［ｊ］とＥ［ｊ（○＋）５２］にそれぞれなるかもしれない。ｋ≠ｊかつｋ≠ｊ（○＋）５２の他の哲学者については、フォークを注文しているので、状態Ｗ［ｋ］になるか、フォークを注文していなければ思索を続ける。
【０４６５】
ＣＩＰ、ＴＩＰ、ＡＬＬＥＯＰは付録ＩＩＩで説明する。トレースは表ＩＶとＶのネットワークで表される。ゲームは以下の２つの公理を満たし、それらがプログレスを保証する。
（Ａｘ１）：∀（ｊ）［□（Ｅ［ｊ］◇（Ｔ［ｊ］＆ｂｔｌｒ．ｆｒｋ［ｊ］．ｏｎＴｂｌ＆ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５ｌ］．ｏｎＴｂｌ
＆¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ）］ （６．２３）
（Ａｘ２）：∀（ｊ）［□（Ｔ［ｊ］◇Ｐ［ｊ］：ｈｕｎｇｒｙ（）］ （６．２４）
（６．２３）は各食事中の哲学者は常に最終的にはフォークを返却し、思索状態に入ると言っている。（６．２４）は各思索中の哲学者は最終的に空腹になると言っている。
【０４６６】
状態Ｅ［ｊ］、Ｔ「ｊ」およびＷ［ｊ］は以下のように定義される。
【０４６７】
∀（ｔ）（Ｔ［ｊ］（ｔ）⇔
∃（ｔ０≦ｔ＜ｔ１）［・→Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）（ｔ０）］［〈・→Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）〉（ｔ１）］） （６２５）
∀（ｔ）（Ｅ［ｊ］（ｔ）⇔
∃（ｔ０≦ｔ＜ｔ１）［・→Ｐ［ｊ］：ｅａｔｉｎｇ（）（ｔ０）］［〈・→Ｐ［ｊ］：ｅａｔｉｎｇ（）〉（ｔ１）］） （６．２６）
∀（ｔ）（Ｗ［ｊ］（ｔ））⇔
∃（ｔ０＜ｔ１＜ｔ２＜ｔ３）＆（ｔ１＜ｔ＜ｔ３）
［Ｐ［ｊ］．ｇ：ｍＲ（）＊（ｔ０）＆ｂｔｌｒ．ｆ［ｊ］．ｒｓｒｖｄ（ｔ１）＆
〈¬ｂｔｌｒ．ｆ［ｊ］．ｒｓｒｖｄ〉（ｔ２）＆〈Ｐ［ｊ］．ｇ：ｍＲ（）＊（）〉（ｔ３）］ （６．２７）
前述のステートメントのアクションの開始と終了のタイミングＷ［ｊ］は、Ｐ［ｊ］とｂｔｌｒ．ｆ［ｊ］の合成状態
表Ｖ：ｂｔｒｌ．ｆ［ｊ］ＥＣＴ
【０４６８】
【表４】
0005704459.tif 000018
イメージ ID=000018
【０４６９】
ゲームの初期状態は以下のとおりである。
［∃（ｔ０）∀（ｊ）（〈Ｔ（ｊ）＆ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ（ｊ）＆
ｂｔｌｒ．ｆｄＣｏｎｔａｉｎｅｒ：ｆｕｌｌ？（）〉（ｔ０））］ （６．２８）
【０４７０】
∀（ｊ）Ｗ（ｊ）はここでの唯一のデッドロック状態であって、それは任意のｊ、０≦ｊ＜５について、Ｐ［ｊ（○＋）５４］はＰ［ｊ］が食事を終了してから食事を始めることができるからである。したがって、哲学者のだれもが食事を始めることができない。以下では２つの主張について証明を行い、それらは、（ｉ）（６．２８）の初期状態でゲームが始まる場合、ゲームはデッドロック状態には決して到達しないことと（ｉｉ）各哲学者は空腹になる毎に自分の食べる順番が回ってくるという意味で解法は公平であることである。
【０４７１】
システムの可能性のある状態の記述を簡単にするために、以下の規約に従う。
¬Ｔ［ｊ］＝（Ｅ［ｊ］｜Ｗ［ｊ］）；¬Ｅ［ｊ］＝（Ｔ［ｊ］｜Ｗ［ｊ］）；
¬Ｗ［ｊ］＝（Ｅ［ｊ］｜Ｔ［ｊ］）；および？？［ｊ］＝（Ｅ［ｊ］｜Ｔ［ｊ］｜Ｗ［ｊ］） （６．２９）
以下で説明している状態をｂｔｒｌのポーリングサイクルの最後と最初でｔｒｕｅと考えることができる。そのような状態を構成と呼ぶ。したがって、∀（ｊ）Ｔ（ｊ）と∀（ｊ）Ｗ（ｊ）とは構成である。ユーザは以下のＣＴＬステートメントを、（６．２９）の表記を使用して状態Ｔ［ｊ］、Ｗ［ｊ］、およびＥ［ｊ］について定式化する。
【０４７２】
□［∀（ｊ）Ｗ（ｊ）◇∀（ｋ）Ｗ（ｋ）］／／デッドロック状態から出ることがない （６．３０）
□［∀（ｊ）Ｔ（ｊ）◇［（∃（ｉ）（¬Ｅ（ｉ（○＋）５４）＆Ｅ（ｉ）＆¬Ｅ（ｉ（○＋）５１）＆
（¬Ｅ（ｉ（○＋）５２）｜Ｅ（ｉ（○＋）５２））＆¬Ｅ（ｉ（○＋）５３））｜∀（ｋ）Ｔ（ｋ）］ （６．３１）
□［∀（ｊ）（Ｗ［ｊ］◇Ｅ［ｊ］）］ （６．３２）
【０４７３】
アサーション（６．３０）はデッドロック構成を特徴付けている。（６．３１）において最終的に、１人または２人のいずれかの哲学者が食事をするか、全ての哲学者が思索する。（６．３２）は待っている各哲学者が最終的に食事をするとアサーションしている。理解されるように、ここでの検索にはマッチ時間点を見つけることは伴わず、哲学者の状態を追跡することが伴う。
【０４７４】
これらのアサーションを証明するために使用されるＥＣＴネットワークを表ＩＶとＶに示している。それらは、付録ＩＩＩのＡＬＬＥＯＰから導出されるトレースから得られる。ここで、各ＥＣＴネットワークはネットワークの初期状態を定義するブロックを有している。これは、ネットワークが開始された時、つまりシンボリック評価が始まった時の述語の真理値を指定している。選択点の述語が初期状態において指定されていないか、ＥＣＴ評価において以前に評価されている述語内に存在してないか、定義から推論できない場合、その選択点から始まる全ての因果チェーンはＥＣＴ評価トレース内に可能性のある選択肢として含まれる。任意のポーリングされたＴＩＰに対応するＥＣＴ評価の開始前に、システムは付録ＩＩＩ、（Ｉｌｌ．３５）に示している区別されている述語の定義を使用してその点までに行われた評価の結果を使用して初期状態を更新する。ＥＣＴ評価の規約は、述語はその真理値を変更されるまで保持するということである。
【０４７５】
執事ＥＣＴは５〜６個の選択点と並列起動とを有しているが、フォークは有していない。全ての哲学者と執事は並列に実行（ｒｕｎ）されるので、それらのＥＣＴのシンボリック評価は必要に応じて並列に行われる。証明が最も容易なアサーション（６．３０）から始める。初期状態は以下のとおりであって、
∀（ｊ）［Ｗ（ｊ）＆¬ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）＆ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）＆
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）］ （６．３３）
表Ｖに示しているものの代わりである。これらの初期条件は表ＶのＥＣＴブロック（１３）の最後に現れる。これは、Ｗ［ｊ］が発生する唯一のＥＣＴブロックである。初期状態を表ＶのＥＣＴ表の述語（６．３３）評価に設定することで、（１）→（２）→（４）（６）→（８）→（１３）→（１７）とマーキングされているブロックを含んでいる評価経路をたどって再びＷ［ｊ］につながる。評価が継続するにつれて、ポーリングサイクルについては、ＥＣＴ評価の以下のシーケンスを得る。
【０４７６】
ｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ（○＋）５ｌ］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ（○＋）５２］：ＥＣＴ（．．．）
→ｂｔｌｒ．ｆ［ｊ（○＋）５３］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ（○＋）５４］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（．．．）
→．．．→ （６．３４）
【０４７７】
ここで、全てのｊについて、トレースは必然的に表ＶのＥＣＴブロック（１３）につながるが、これはＷ［ｊ］が全てのｊに対してｔｒｕｅだからである。したがて、構成は変化しない。システムはｂｔｌｒ．ｆ［ｊ］で始まりｂｔｌｒ．ｆ［ｊ（○＋）５４］で終わる１つの完全なポーリングサイクルに対応している評価を経た後にこれを認識する。ただし、ＥＣＴブロック（１３）の状態Ｗ［ｊ］において、ｂｔｒｌはＰ［ｊ］には応答メッセージを返送しない。図１と２に示しているガードの定義によって、ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）は、応答メッセージが返信されるまで各ポーリングサイクルにおいてｔｒｕｅと評価し、それはもちろんこのデッドロック構成では発生しない。これが（６．３０）を証明する。
【０４７８】
ここで、（６．３１）の証明を考える。以降では、ポーリングサイクルの最後の構成を指すためにＺを使用する。規則（５．３２）によって、ＣＴＬアサーション（６．３１）は以下のように変換される。
【０４７９】
∀（Ｚ）（∀（ｊ）Ｔ（ｊ）→．．．→Ｚ）⇒（Ｚ◇ＥＺ） （６．３５）
ここでＥＺは終了構成である。
【０４８０】
ＥＺ＝［∀（ｋ）Ｔ（ｋ）｜（∃（ｉ）（¬Ｅ（ｉ（○＋）５４）＆Ｅ（ｉ）＆¬Ｅ（ｉ（○＋）５１）＆
（¬Ｅ（ｉ（○＋）５２）｜Ｅ（ｉ（○＋）５２））＆¬Ｅ（ｉ（○＋）５３））］ （６．３６）
【０４８１】
最初のタスクは、初期状態から始めて、各ｊについて評価前にｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（）の初期状態を更新し、述語の値が得られない表Ｖの各選択点で全ての選択肢の因果チェーンをたどって、執事の１つのポーリングサイクル後に構成Ｚがどのようになるかを見つけることである。システムは以下のように素早くＺ＝ＥＺを見つけ出す。表ＩＶにおいて、各哲学者Ｐ［ｊ］、０≦ｊ＜５は空腹になり、Ｐ［ｊ］．ｇＳ（ｐ［ｊ］ｇ．ｔ０）を実行し、それを時間点ｐ［ｊ］ｇ．ｔ１＝ｂｆ［ｊ］．ｔ０、０≦ｊ＜５においてｂｔｌｒ．ｆ［ｊ］に配信することによってフォークの要求を執事に送信する。これらのメッセージ配信時刻は比較不能であるが、それは哲学者が並列に実行（ｒｕｎ）されているからである。執事がメッセージ配信を検知するためにｂｔｌｒ．ｆ［ｊ］をポーリングするポーリング時刻はｂｆ［ｊ］．ｔ１、０≦ｊ＜５であって、付録ＩＩＩのポーリングサイクルの定義に従ってｂｆ［ｊ］．ｔ１＜ｂｆ［ｊ（○＋）５１］．ｔ１である。ここでの唯一の要件は、メッセージ配信がメッセージ検知の前に発生することである。哲学者Ｐ［ｊ］が、ｂｔｒｌがそのポートｂｔｌｒ．ｆ［ｊ］をポーリングする前にたまたま要求を送信していた場合、ｂｔｒｌはそのポートでメッセージの受信を検知し、そうでなければ検知しない。
【０４８２】
したがって、全ての哲学者が要求を同時に送信したり、執事のポーリングサイクル中にだれもが要求を送信しなかったり、ある者は送信しある者は送信しなかったりすることがあり得る。執事と哲学者の動作は同期していないため、ｂｔｒｌがその機能ポートをポーリングしている時に、そのポートのいくつかで何らかの時刻にメッセージ受信を検知したり、ポーリングサイクルでメッセージを検知しなかったり、ポーリングサイクルで全てのポートでメッセージを検知したりするかもしれない。したがって、ｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（）の各選択点から始まる全ての可能性のある選択肢の因果チェーンを含めることには意味がある。表ＶのＥＣＴブロック（６）と（７）に現れるｂｔｌｒ．ｆ［ｊ］：ｍｓｇ（）：ｅｍｐｔｙ？（）の場合、ユーザは以下の定義を提供する。
【０４８３】
∀（ｊ）［□（Ｐ［ｊ］：ｈｕｎｇｒｙ？（）＆ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（））⇔
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｍｓｇ（）：ｅｍｐｔｙ？（）］ （６．３７）
システムは表ＩＶとＶのＥＣＴを使用してこの定義を検証し、この定義を使用して表Ｖで（６）と（７）とマーキングされたＥＣＴブロックにおける条件ｂｔｌｒ．ｆ［ｊ］：ｍｓｇ（）：ｅｍｐｔｙ？（）によって選択点で取るべき分岐を決定する。システムは必要に応じて定義を使用して初期状態も更新する。通常、述語の評価中または初期状態の更新中にだけＥＣＴ評価において論理的な推論の必要性が生じる。
【０４８４】
アサーション（６．３５）と（６．３６）は、表Ｖの選択点における因果チェーンの選択の基準は一切与えない。したがって、システムは表Ｖの各選択点において初期状態の述語と所与の定義とに整合している全ての可能性のある因果チェーンを分析して、（６．３５）のＺが（６．３６）のＥＺに等しいことを見つける。これは、図１４の木にまとめられ、執事のポーリングサイクル後の可能性のある構成が木のブランチのいずれか１つにおける状態によって指定されている。読者は、図１４の各ブランチが、全ての哲学者は思索しているか哲学者たちの１人または２人が食事をしているというＺ内のパターンを満たしていることに気付くであろう。したがって、初期状態から始まる第１のポーリングサイクルの後の構成は、以下を満たす。
【０４８５】
□［∀（ｊ）Ｔ（ｊ）→→ＥＺ］ （６．３８）
そのため、（６．３５）を証明するために、システムは
□［ＥＺ→．．．→Ｚ１］ （６．３９）
がｔｒｕｅであるような構成Ｚ１を、以下のようにして見つけようとする。まず、ｉ＝ｊと設定することによって（６．３６）の変数ｉの存在インスタンス化を生成し、以下のように続行する。可能性のある初期構成は以下のようである。
【０４８６】
［¬Ｅ（ｊ（○＋）５４）Ｅ（ｊ）¬Ｅ（ｊ（○＋）５１）¬Ｅ（ｊ（○＋）５２）¬Ｅ（ｊ（○＋）５３）］または
［¬Ｅ（ｊ（○＋）５４）Ｅ（ｊ）¬Ｅ（ｊ（○＋）５１）Ｅ（ｊ（○＋）５２）¬Ｅ（ｊ（○＋）５３）］ （６．４０）
（６．２９）で与えられている定義に従って（６．４０）における否定状態についての置き換を行うことによって（２４＋２３）の可能性のある初期構成となる。各初期構成につて、システムはその構成についてｔｒｕｅでなければならない初期条件をＥＣＴとユーザによって与えられた区別されている述語の定義から見つけ出して、適切な場合はそれらを初期条件に含める。その後、各初期状態について、所与の初期条件に整合している全ての考えられる因果チェーンをたどるＥＣＴを評価して、全ての初期条件と¬ＥＸ＝∀（ｊ）Ｗ（ｊ）についてＺ１＝ＥＺ（（６．３）のＺ１と（６．３６）のＥＺ）が成立することを見つけ出す。これが（６．３５）、（６．３６）、および（６．３１）を証明する。
【０４８７】
0005704459.tif 000019
【０４８８】
図１４：１回目のポーリングサイクルの終了時における構成の分岐している木
ただし、そうすることによって、システムは実装から食事をする哲学者の解法の状態図を効果的に構築する。ここで、マッチする時間点を探索する必要はなく、ポーリングサイクルにおいて到達する可能性のある構成だけを探索すればよい。システムによって計算された状態図から得られる以下の補助定理を示す。この補助定理は（６．３２）の証明に有用である。
【０４８９】
補助定理１：□∀（ｊ）［Ｗ［ｊ］⇒（？？［ｊ（○＋）５４］Ｗ［ｊ］¬Ｔ［ｊ（○＋）５１］∨Ｅ［ｊ（○＋）５４］Ｗ［ｊ］？？［ｊ（○＋）５１］
∨Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］）］ （６．４１）
これは、Ｐ［ｊ］が状態Ｗ［ｊ］にある時に、Ｐ［ｊ］の右と左の哲学者の状態がどうであるかを指定する。（６．４１）の表記を拡張するために状態が置き換えられると、８つの考え得る別個のトリプレットを得る。これらのトリプレットは以下のとおりである。
【０４９０】
Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｅ［ｊ（○＋）５１］、Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］、Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｅ［ｊ（○＋）５１］、
Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５ｌ］、Ｅ［ｊ（○＋）５４］Ｗ［ｊ］Ｅ［ｊ（○＋）５１］、Ｅ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］、
Ｅ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］、Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］ （６．４２）
システムは指定されたトリプレットが既に構築した状態図に整合していることを容易に確認する。状態図が既に構築されている場合、システムは任意に選択されたｊについてＷ［ｊ］に対して適切な初期状態を設定し、表ＩＶとＶのＥＣＴを評価することによって、各トリプレットを確認することができる。（６．４２）の各トリプレットについて、（６．４２）で指定されていない状態は指定されたトリプレットに整合する任意の状態とすることができる。
【０４９１】
（６．３２）の証明は、食事をしている各哲学者はフォークを返却し（公理Ａｘ １、（６．２４））、思索をしている哲学者は最終的に空腹になり（公理Ａｘ ２（６．２５））、Ｐ［ｊ］が待っている時に、ｂｔｌｒ．ｆｒｋ［ｊ］はＰ［ｊ］によって予約されているのでＰ［ｊ（○＋）５４］は食事を始められないという事実から得られ。Ｐ［ｊ（○＋）５４］が既に食事をしていた場合、Ｐ［ｊ］は待ち、Ｐ［ｊ（○＋）５４］が食事を終えた後、Ｐ［ｊ（○＋）５４］がフォークを返したサイクルの直後に続く１回目のポーリングサイクルにおいて、Ｐ［ｊ］は食事をする機会がある。Ｐ［ｊ（○＋）５４］が長時間食事をしているためにＰ［ｊ］が執事の数回のポーリングサイクルにわたって待たなければならない場合、Ａｘ １）６．２４）によって、Ｐ［ｊ（○＋）５１］はフォークを返した後で再び食事を開始するかもしれない。これはＰ［ｊ］が自分のフォークを手に入れるまでに５〜６回発生する可能性がある。しかし、Ｐ［ｊ］は最終的に自分のフォークを取得するが、それはＰ［ｊ］が食事を終えるまでＰ［ｊ（○＋）５４］が再び食事を始めることができないためである。これを図１５に示している。ここでは、議論は正規表現を使用するＦＳＰの議論と同様である。
【０４９２】
（６．４２）のＴ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］およびＷ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］の場合について考える。ポーリングは、ｂｔｌｒ．ｆ［ｊ］で始まる。Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］の場合、唯一の可能性は、¬Ｅ［ｊ（○＋）５４］Ｅ［ｊ］（○＋）５Ｅ［ｊ（○＋）５ｌ］に変化することである。Ｐ［ｊ］は食事を始めているので、証明は終了する。Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］の場合、以下が成立し、これは、少なくとも１人の食事をしている哲学者がいなければならないという（６．３５）と（６．３６）に従う。ユーザは以下のアサーションを提供する。
【０４９３】
□∀（ｊ）［Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］⇒（Ｗ［ｊ］Ｗ［ｊ（○＋）５１］Ｅ［ｊ（○＋）５２］∨
Ｗ［ｊ］Ｗ［ｊ（○＋）５１］¬Ｅ［ｊ（○＋）５２］Ｅ［ｊ（○＋）５３］）］ （６．４３）
この証明は（６．３６）、（６．３９）および図１４の構成を使用して容易に確認される。（Ｗ［ｊ］Ｗ［ｊ（○＋）５１］Ｅ［ｊ（○＋）５２］の場合、Ａｘ ２（６．２５）によって、以下のトランザクションのシーケンスＷ［ｊ］Ｗ［ｊ（○＋）５１］Ｅ［ｊ（○＋）５２］→Ｗ［ｊ］Ｗ［ｊ（○＋）５１］Ｔ［ｊ（○＋）５２］→Ｗ［ｊ］Ｅ［ｊ（○＋）５１］Ｔ［ｊ（○＋）５２］→Ｅ［ｊ］Ｔ［ｊ（○＋）５１］？？［ｊ（○＋）５２］につながらなければならない。そのため、Ｐ［ｊ］は最終的に食事をする。前述の遷移は、システムによって全て確認される。Ｗ［ｊ（○＋）５１］¬Ｅ［ｊ（○＋）５２］Ｅ［ｊ（○＋）５３］の場合も同様の遷移が発生する。
【０４９４】
各場合について、システムは適切な初期状態から初めて、Ｐ［ｊ］に対して避けられない（唯一可能な）状態としてポーリングサイクルにおいて状態Ｅ［ｊ］が得られるまで連続したポーリングサイクルを経てＥＣＴを評価する。各ポーリングサイクルにおいて、各ｊについてのｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（）評価の前に初期状態が更新される。これは、ＦＳＰの状態探索と同様である。この特定の問題においては、システムは以前に到達した構成が再び発生するとそのポーリングサイクルの繰り返しを停止する。これはこの場合に発生し得るが、それは解法が有限ＡＬＬＥＯＰを有しているためである。この探索は各場合において成功する。しかし、この種類の探索には困難がある。
【０４９５】
Ｅ［ｊ］が到達不能の場合、非有限ＡＬＬＥＯＰについて、ユーザが適切な終了条件を指定するか、システムが矛盾に遭遇するか、ユーザがシステムを停止しトレースを調べるかしない限りシステムが終了しない可能性がある。
【０４９６】
備考：ＡＬＬＥＯＰ証明はＡＬＬＥＯＰとＥＣＴネットワークを実装から導出し、所与のＣＴＬアサーションをＥＣＴネットワ―ク上で評価し、結果として得られる因果チェーンを分析することによって構築される。システムはＥＣＴネットワーク内で見出した因果チェーンをトレースの形態で示す。証明の構築は対話的である。すべての場合において、ユーザは確認するＣＴＬアサーションと因果チェーン（トレース）分析を導くアサーションを提供する。システムはユーザによって提供された各アサーションを確認し、適切な場合は、既に確認されているアサーションを使用して新しいトレースを見出す。この証明プロセスを２〜３個の簡単な例に対して示した。説明を簡単にするために、システムによって探索中に発見されたトレースを示していない。
【０４９７】
５種類の相互に関連するアクティビティがＥＣＴ評価に存在し、それらは（ｉ）所与のＣＴＬアサーションに整合している開始と終了の構成を設定する、（ｉｉ）必要に応じてＣＴＬアサーションとＥＣＴとの間でマッチする時間点を探す、（ｉｉｉ）ＥＣＴネットワークの選択点で条件の真理値を探す、（ｉｖ）開始構成から終了構成につながる全てのトレースを探す、（ｖ）ＣＴＬアサーション内の主張を確認するためにトレースを分析する、である。有限ＡＬＬＥＯＰの場合、前述の項目（ｖ）についてだけはユーザ介入が必要なことがある。非有限ＡＬＬＥＯＰの場合、（ｉｖ）と（ｖ）の両方が必要な場合がある。
【０４９８】
これらの証明の証明理論は、システムが自身で全ての証明可能なＣＴＬアサーションを確定的に証明できないという意味では完全な証明理論ではない。これは、（ｉｖ）と（ｖ）についてユーザ相互動作に依存しているためである。より経験を積むと、典型的なＡＬＬＥＯＰパターンを識別したり、可能な場合はＥＦＰ構造と有限ＡＬＬＥＯＰ構造との間に対応関係を確立したりすることによって、次第により大きな範囲へと証明構築を自動化することができる。証明理論が、ＴＩＣＣ−Ｐｐｄｅがどのように構成されているのかと、それがどのように動作するのかと、証明されている物の計算的な意味とに無関係であると言うことはできない。証明理論を定義する前に、ＴＩＣＣ−Ｐｐｄｅプログラミングシステムに対する表示的不動点意味論を定義する。これは、証明される物の計算的な意味を定義する。
【０４９９】
次のセクションは、所与のアプリケーションＡｐに対する確認すべきＣＴＬアサーションを生成するためにユーザを導く基準を導入する。
【０５００】
６．５．実装の修正
Ａｐ：Ｐｔｈｒｅａｄｓ（）、Ａｐ：ＡＬＬＥＯＰｓ（）、Ａｐ：ＥＣＴｓ（）およびＡｐ：因果律網（）がそれぞれＡｐの実装のアプリケーションＡｐのｐｔｈｒｅａｄ、ＡＬＬＥＯＰ、ＥＣＴ、および因果律網を表すとする。因果律網はセクション７で説明したようにＳＭＳによって自動的に生成される。Ａｐ：Ｐｔｈｒｅａｄｓ（）内のｐｔｈｒｅａｄはユーザによって定義される。それらは対で互いに独立している。また、各ｐｔｈｒｅａｄは基本的なプログラミングステートメントだけを含んでいる短い逐次プログラムである。これらは、各ｐｔｈｒｅａｄの正しさを他のｐｔｈｒｅａｄとは独立して証明することを可能にする。設計者と実装者にはｐｔｈｒｅａｄ特徴付けを提供する責任がある。ＡＬＬＥＯＰとＥＣＴは実装の仕様からシステムによって自動的に生成される。m
【０５０１】
実行（ｒｕｎ）中にＡｐに対して生成された因果律網がイベントパターンとＡｐ：ＡＬＬＥＯＰｓ（）内の半順序付けに違反せず、Ａｐ：因果律網（）内の全てのイベントが指定された期限内に発生する場合、（Ａｐ：因果律網（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））と書く。セクション７で説明したＳＭＳはＡｐ：因果律網（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））が成立するかどうかをチェックするためにこの監視を継続して実行する。
【０５０２】
トランザクションと経路によって接続されている２つのポートが良好にマッチしているという概念の正しさは図２のすぐ後の段落で定義されている。アプリケーションＡｐ内の経路によって接続されているＡｐ内のポートの全ての対が良好にマッチしている場合にだけ、Ａｐ：Ｃｏｒｒｅｃｔ（）が有効であると定義する。Ａｐ：Ｒｅｑｕｉｒｅｍｅｎｔｓ（）を設計が始まる前に構築されそれ以来更新されているアプリケーションＡｐ用の設計要件とする。Ａｐ内のトランザクションの正しさ、Ａｐ：Ｒｅｑｕｉｒｅｍｅｎｔｓ（）の定義、およびトランザクションの完了の期限の定義はすべて設計者と実装者によってＴＩＣＣ−Ｐｐｄｅとの対話によって作製することができる。もちろん、（Ａｐ：因果律網（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））が所与の実行（ｒｕｎ）について実装に対して成立するが、実装は正しくないこともあり得る。この可能性を避けるために、実装に対して以下の確認基準が成立するとする。
【０５０３】
［（Ａｐ：因果律網（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））＆
（Ａｐ：ＡＬＬＥＯＰｓ（） ｓａｔｉｓｆｉｅｓ Ａｐ：Ｒｅｑｕｉｒｅｍｅｎｔｓ（））］⇔Ａｐ：Ｃｏｒｒｅｃｔ（） （６．４４）
明らかに、（６．４４）の真偽はＡｐに対して確認されたＣＴＬアサーションの設定に依存している。（６．４４）のＡｐ：Ｃｏｒｒｅｃｔ（）の概念と以前に定義されている正しさの概念は、所与の実装に対して確認すべきＣＴＬアサーションの集合を選択するために使用できるという意味で確認基準を定義している。示した簡単な例について確認したＣＴＬアサーションはこれらの実装について（６．４４）を満たす。その有効性がＡｐの実装の正しさを確立するＣＴＬアサーションの集合の特定は（６．４４）とＡｐ：Ｃｏｒｒｅｃｔ（）の定義によって導かれる。設計者がこれを行うとここでは仮定している。
【０５０４】
明らかに、システムの実装の確認が、それが（６．４４）を満足するということであれば、ＳＭＳを使用して動的な監視によってそのシステムの性能の正しさを確認することは意味がある。この場合、確認されたアサーションを実行（ｒｕｎ）時に発生するエラーを診断するための戦略を指定する手引きとして使用したり、確認されたアサーションを自己修正のための戦略を指定したりするために使用することもできる。これらは、将来の研究に対して重要なトピックである。ＴＩＣＣ−Ｐｐｄｅの独自の特徴は、システムの性能をその生涯時間にわたって動的に監視するために必要なＳＭＳを自動的に提供することと、ＣＴＬアサーションを通してシステム実装を確認する方法を提供することである。全ての確認と正しさのチェックとは究極的にはＡＬＬＥＯＰに依存しているため、ここで示す証明をＡＬＬＥＯＰ証明と呼ぶ。
【０５０５】
確認プロセス中に、マッチする時間点を探しながら、システムはＡＬＬＥＯＰによって比較不能であるが、ＣＴＬアサーションによって同期しているか（同時に発生する）、調和している（イベントの１つが他のイベントのかならず後に発生する）イベントを識別する。イベントの対は、同期と調和がイベントが現れる確認されたＣＴＬアサーションのいずれをも否定しない場合にだけ、そのような同期や調和の候補とすべきである。次のサブセクションにおいて、ｐｔｈｒｅａｄの再プログラミングを必要とせずに、必要に応じて必要な同期と調和を既に完成した実装に導入するＴＩＣＣ−Ｐｐｄｅで使用可能なアドホック同期と調和メソッドを導入する。
【０５０６】
ＴＩＣＣ−Ｐｐｄｅにおけるシステム実装の重要なタスクはプログラミングではない。ｐｔｈｒｅａｄと条件のプログラミングと比較的些細な機械的なタスクである。困難な重要なタスクは（ｉ）ＴＩＣＣネットワークの設定、（ｉｉ）ＴＩＰの定義、（ｉｉｉ）必要なｐｔｈｒｅａｄの特徴付け、および（ｉｖ）確認すべきＣＴＬアサーションの識別である。ＴＩＣＣネットワークの構造は、代替の構成がテストされたり調査されたりする媒体を提供する。ＴＩＣＣパラダイムは、システム設計と実行の技術の性質をプログラミングの技術から必要なサブシステムの特定、サブシステム間の相互動作の指定、および正しさの提供の技術に変化させる。
【０５０７】
６．６．限界テストおよびアドホック調和と同期
限界テスト：ＥＣＴの分岐している木と時間点の半順序付けとをシステムのさまざまな有用な特性の確認に使用することができる。実時間システムにおいて提供する有用な１つの特徴は時間点の必要な半順序付けがＴＩＰ実行時間の変化に関わらず常に保存されていることである。これは限界テストによって行われる。
【０５０８】
ポートＣ．ｐのＴＩＰについて、時間限界（τＰｍｉｎ，τＰｍａｘ）を定義し、τＰｍｉｎは時間メッセージがｐに配信された時刻から開始してｐでのＴＩＰの実行の完了に必要な最短時間間隔であって、τＰｍｉｎはポートＣ．ｐの親セルＣが１つのポーリングサイクルを完了するのに必要な最大時間間隔であって、τＰｍａｘ＜（τＰｍｉｎ＋２ΔＣｍａｘ）であって、ΔＣｍａｘはポートＣ．ｐの親セルＣが１つのポーリングサイクルと保留中のメッセージのある全てのポートのサービスを完了し、ポートＣ．ｐのサービスに戻るのに必要な最大時間である。これは、Ｃが１つのポーリングサイクルでＣ．ｐメッセージを検知し損ない、次のポーリングでそれを取得する時に発生する。２ΔＣｍａｘがここで使用されるが、それはＣ．ｐが次のポーリングサイクルでサービスされる最後のポートになる可能性が十分にあるからである。
【０５０９】
２つのトレースが存在して、一方はポートＣ．ｐに向かい、他方はポートＤ．ｑに向かい、セルＣとＤは因果チェーンで接続されていないと仮定する。それぞれポートＣ．ｐとＤ．ｑでの対のイベントＸｐ（ｔｐ）とＸｑ（ｔｑ）の発生がｔｐ＜ｔｐであることが必要であると仮定する。（ｐ［０］，．．．，ｐ［ｒ−ｌ］＝ｐ）をＸｐに向かう因果チェーン内のポートとし、（ｑ［０］，．．．，ｑ［ｍ−ｌ］＝ｑ）をＸｑに向かう因果チェーン内のポートとする。ｔｎ（ｐ［０］）とｔｎ（ｑ［０］）をｎ番目のメッセージがそれぞれポートｐ［０］とｑ［０］に配信される時刻とし、τｐ［ｊ］ｍａｘはｐ［ｊ］：ｔｉｐ（）の実行を完了するのに必要な最大時間であって、τｑ［ｊ］ｍａｘはｑ［ｊ］：ｔｉｐ（）の実行を完了するのに必要な最小時間であって、ｔｐとｔｑはイベントＸｐとＸｑが発生する時刻である。ポートシーケンスの対に対して以下が成立する。
【０５１０】
ｔｐ≦（ｔｎ（ｐ［Ｏ］）＋Σ｛τｐ［ｊ］ｍａｘ｜０≦ｊ＜ｒ｝）＜（ｔｎ（ｑ［０］）＋Σ｛τｑ［ｉ］ｍｉｎ｜０≦ｉ＜ｍ｝）＜ｔｑ （６．４５）
ここでイベントＸｐとＸｑはサイクル同期している必要がある。
【０５１１】
アドホック調和：ここで条件（６．４５）が満たされていないと仮定する。広範囲な再プログラムを実施せずにそれをどのように実施できるだろうか。具体的には、実装のＡＬＬＥＯＰの因果チェーンによって互いに接続されていないポートＣ１．ｆ１とＣ２．ｆ１を有している２つのセルＣ１とＣ２を仮定する。システムの正しい動作にはＣ２．ｆ１のＴＩＰがＣ１．ｆ１のＴＩＰが実行された後で初めて実行されなければならないと仮定する。この要件を□［［〈・→Ｃ１．ｆ１：ｔｉｐ（）〉（ｔ１）／＊評価完了＊／］＆［・→Ｃ２．ｆ１：ｔｉｐ（）（ｔ２）／＊評価開始＊／］⇒（ｔ１＜ｔ２）］と書く。この問題は図１６に示しているように生成とポートベクトルを使用することによってＴＩＣＣ−Ｐｐｄｅ内で容易に解かれる。
【０５１２】
0005704459.tif 000020
【０５１３】
図１６：アドホックの調和の図
２つの他のポートＣ１．ｇとＣ２．ｆ２を仮定し、［Ｃ２．ｆ１，Ｃ２．ｆ２］をポートベクトルと定義し、図１６に示しているようにＣ１．ｇをＣ２．ｆ２に接続しているブランチをインストールする。ここでＣ２はＣ２．ｆ２がＣ１．ｇから信号を受信した後で初めてＣ２．ｆ１でメッセージのサービスを行う。Ｃ１．ｇはＣ１．ｆ１：ｔｉｐ（）を実行した後にこの信号を送信する。Ｃ１．ｆ１とＣ２．ｆ１のＴＩＰは以下のフォーマットを有することになる。
【０５１４】
（Ｃ１．ｆ１：ｍＲ？（）＆Ｃ１．ｇ：ｐＲ？（）＊）｛Ｃ１．ｆ１：ｒ（）．ｓ（）；Ｃ１．ｇ：ｓ（）｝
（Ｃ２．ｆ１：ｍＲ？（）＆Ｃ２：ｆ２：ｍＲ？（）＊）｛Ｃ２．ｆ１：ｒ（）．ｓ（）；Ｃ２．ｆ２：ｓ（）｝ （６．４６）
これによって、Ｃ１．ｆ１とＣ２．ｆ１とはサイクル同期され、要件は常に満たされる。実際に、この構成はポートの対を調和させるだけでなく、以下のように、セクション７のグループ対グループ信号交換を使用してグループ対グループ相互動作をサイクル同期させるのにも使用される。
【０５１５】
（［〈・→Ｃ１．ｆ：ｔｉｐ（）〉（ｃ１．ｔ），〈Ｃ２．ｆ：ｔｉｐ（）〉（ｃ２．ｔ），．．．，〈Ｃｎ．ｆ：ｔｉｐ（）〉（ｃｎ．ｔ）／＊評価が完了＊／］
＆［・→Ｄ１．ｆ：ｔｉｐ（）（ｄ１．ｔ），Ｄ２．ｆ：ｔｉｐ（）（ｄ２．ｔ），．．．，Ｄｍ．ｆ：ｔｉｐ（）（ｄｍ．ｔ）／＊評価開始＊／］
⇒［∀（ｔ１∈｛ｃ１．ｔ，ｃ２．ｔ，．．．，ｃｎ．ｔ｝）∀（ｔ２∈｛ｄ１．ｔ，ｄ２．ｔ，．．．，ｄｍ．ｔ｝）］
（ｔ１＜ｔ２）］
ここで、必要なサイクル同期を組み込むために実装で必要な唯一の修正は（ｉ）必要なグループ対グループ経路の設定と（ｉｉ）ＴＩＰ定義の変更である。実装の残りは変更されないままである。ここでの構成は、時間信号がサブシステムのアクティビティの調和に非同期ハードウェアシステムで使用される態様と非常に似ている。
【０５１６】
0005704459.tif 000021
【０５１７】
図１７：アドホック調和
アドホック同期：ＴＩＣＣ−Ｐｐｄｅにおいて、異なるセルのポーリングサイクルは互いに同期されない。しかし、たまに、経路チェーンによって互いに接続されておらずセルグループ内にはないポートのサービスを同期させる必要がある。それらを分離されているセルと呼ぶ。したがって、分離されているセルＣｊ、０≦ｊ＜ｎに対して同期を実施したいと考える。
【０５１８】
［・→（Ｃ０．ｆ：ｔｉｐ（），．．．，Ｃｎ−１．ｆ：ｔｉｐ（））（ｔ）］ （６．４８）
これは、図１７に示している自己ループ経路をインストールすることによって行われる。図１７に示しているように、ポートＣｊ．ｇ、０≦ｊ＜ｎはセルＣｊに付属しており、各ポートＣｊ．ｇは自己ループ経路に接続されている。各Ｃｊ．ｆのＴＩＰは以下のフォーマットを有している。
【０５１９】
Ｃｊ．ｆ：ｍＲ？（）｛Ｃｊ．ｇ：ｓ（）；Ｃｊ：ｇ：ｍＲ？（）＊｛Ｃｊ．ｆ：ｒ（）．ｓ（）｝｝ （６．４９）
ここでセルＣｊ．ｇはメッセージをＣｊ．ｆを通して受信すると即座に、信号を自己ループ経路を通して自身に送信する。全てのセルＣｊが信号をそれらのそれぞれのポートＣｊ．ｇを通して送信した後で、同期している信号がエージェントａ０によって全てのＣｊ．ｇに送信される（このためのプロトコルはセクション７に記述されている）。各ＣｊはそのポートＣｊ．ｆで受信したメッセージにこの同期した信号を受信した直後に応答する。図１７のエージェントａ０に接続されているセルの１つがグローバルクロックであってもよい。その場合、すべてのセルはグローバル時間またはシステム内の他の任意のイベントに同期しているポートＣｊ．ｆでそれらのそれぞれのメッセージに応答する。これはクロック同期によるランデブー技法の使用とほとんど同じであるが、はるかにより柔軟で、同期機構をｐｔｈｒｅａｄ内にプログラムする必要は無く、自己ループネットワークのみをインストールし、ＴＩＰを修正するだけでよい。
【０５２０】
同期と調和とはここでは後からの思いつきとして行われている。これらの種類のアドホック同期と調和とは、広範囲な再プログラミングを行うこと無しに、π算法、アクターシステム、ＣＰＵ、または任意の他の現在利用可能な並列プログラミングパラダイムにおいては行うことはできない。このセクションを任意の数のノードを含むことができるＮＦＳＰ ＡＬＬＥＯＰについての何らかのコメントで締めくくる。
【０５２１】
６．７ 動的に増大している非有限状態ＡＬＬＥＯＰの例
そのための簡単なネットワークを図１８に示している。それはｎ個のセルを有している。各セルＣ［ｉ］はｃｓｍ（通信システムマネージャ）に接続されている。セルがインストールされた時に、その関連付けられているｃｓｍへのプライベート経路がセルの指定されたｃｓｍＰｏｒｔ（一般ポートのサブクラス）から自動的に設定される。新規のセルや経路を動的にインストールする必要のあるセルは、サービス要求メッセージを、適切なセルｃｅｌｌ：ｉｎｓｔａｌｌＣｅｌｌ＆Ｐａｔｈｗａｙ（）または（ｃｅｌｌ：ｉｎｓｔａｌｌＣｅｌｌ（）；ｃｅｌｌ：ｉｎｓｔａｌｌＰａｔｈｗａｙ（）；）メソッドを呼び出すことによって、その関連付けられているｃｓｍに送信する。これらのメソッドはＴＩＣＣ−Ｐｐｄｅシステムによって提供されている。セルＸは、Ｘを破壊したり経路を破壊したりするために、要求をそのｃｓｍに送信することができる。セルはｃｓｍを使用して他のセルや経路をインストールするが、それはそれらが１００から２５０ミリ秒かかる高価な動作だからである。要求をｃｓｍにそのｃｓｍＰｏｒｔを通して送信した後、セルは他のポートのサービスをおこない、次のポーリングサイクルでｃｓｍからの応答を受信するためにｃｓｍＰｏｒｔに戻り適切な既にプログラムされているアクションを行う。ｃｓｍは要求しているセルが適切な特権を有している場合にだけ要求のサービスを行う。いずれにしても、ｃｓｍは要求しているセルに応答メッセージを返信する。
【０５２２】
0005704459.tif 000022
【０５２３】
図１８：ＮＦＳＰ ＡＬＬＥＯＰのあるネットワーク
アプリケーションが開始された時に、図１８のネットワークはセルＣ［０］、Ｘ、およびｃｓｍだけを有している。Ｘはメッセージをその機能ポート、Ｃ［０］．ｆに送信することによってＣ「０」を起動する。最初に、Ｃ［０］のｃｓｍＰｏｒｔは図１８に示しているようにエージェントａ１にチューンされている。起動されると、その初期化の一部として、Ｃ［０］はそのｃｓｍにＣ［１］をインストールするように要求し、そのポートＣ［０］．ｇをＣ［１］．ｆに経路を通して接続する。Ｃ［０］がｃｓｍからタスクが完了したという応答を受け取ると、Ｃ［０］．ｃｓｍＰｏｒｔをエージェントａ１から切断し、メッセージをＣ［１｝．ｆにＣ［０］．ｇを通して送信し、自身の割り当てられているＣＰＵを解放することによって自身をサスペンドする。Ｃ［１］．ｆに送信されたメッセージは条件を含んでおり、以下で説明するようにＣ［１］によって使用される。
【０５２４】
Ｃ［１］．ｆに送信されたメッセージは使用可能なＣＰＵの中の１つで実行（ｒｕｎ）するためにＣ［１］を起動する。起動されると、Ｃ［１］は今度は同じことをして、そのｃｓｍＰｏｒｔをエージェントａ１に対してチューンし、次のセルＣ［２］をインストールして起動し、それからＣ［１］．ｃｓｍＰｏｒｔをａ１から接続解除し、それから受信したメッセージが止めない限り自身をサスペンドする。したがって、新しくインストールされたセルがさらに別のセルをインストールし起動し続け、受信した条件が止めない限り自身をサスペンドする。これによって、条件によって停止されない限りネットワークが拡大する。
【０５２５】
例えば、何らかのｎ＞１に対して、セルＣ［ｎ］において条件によって拡大が停止されると、Ｃ［ｎ］は新規のセルをインストールする代わりに、そのポートＣ［ｎ］．ｆで受信したメッセージに対して、応答をＣ［ｎ−１］．ｇに送信することによって応答し、それから自身を破壊し、したがって割り当てられているＣＰＵを解放する。Ｃ［ｎ］．ｆからの応答メッセージがＣ［ｎ−１］．ｇに配信された時に、Ｃ［ｎ−１］はそのサスペンドされた動作を使用可能なＣＰＵの１つにおいてレジュームし、Ｃ［ｎ］が行ったばかりのことを繰り返す。したがって、新規にインストールされた各セルが１つずつＣ［０］までそのトランザクションを完了し自身を破壊し、Ｘとｃｓｍはネットワーク内に残っているただ２つのセルとなる。その時点で、Ｃ［０］はそのポートＣ［０］．ｆを通してＸ．ｇから最初に受信したサービス要求に応答し、したがってトランザクションを完了する。
【０５２６】
この例における定義の詳細、つまりセルと経路、ＴＩＰ、ＡＬＬＥＯＰ、およびトレースを動的に生成し破壊するための構成を示すことは重要ではない。以下の因果シーケンスがトレース内で発生することに注意するだけで十分である。それは、Ｘ．ｇがＣ［０］．ｆに送信したメッセージによって始まり、Ｃ［ｎ］．ｆまで継続し、それから逆のプロセスを始める。因果チェーンを以下に示す。
【０５２７】
／＊新規のセルの漸進的な生成と起動時の通信イベント＊／
Ｘ．ｇＳ［］→Ｃ［０］．ｆＤ［］→．．．→Ｃ［０］．ｇｓ［］→Ｃ［１］．ｆＤ［］→．．．→Ｃ［１］．ｇＳ［］→Ｃ［２］．ｆＤ
→．．．→Ｃ［２］．ｇＳ［］→Ｃ［３］．ｆＤ［］→．．．→→．．．→Ｃ［ｎ−１］．ｇＳ［］→Ｃ［ｎ］．ｆＤ［］→．．．→
／＊新規のセルの自身の破壊を伴うトランザクションの漸進的な完了時の通信イベント＊／
Ｃ［ｎ］．ｆＳ［］→Ｃ［ｎ−１］．ｇＤ［］→．．．→Ｃ［ｎ−１］．ｆＳ［］→Ｃ［ｎ−２］．ｇＤ［］→．．．→→．．．→
Ｃ［２］．ｆＳ［］→Ｃ［１］．ｇＤ［］→．．．→Ｃ［０］．ｆＳ［］→Ｘ．ｇＤ［］，ｎ＞０ （６．５０）
‘Ｘ．ｇ’＝’ｇ’、’Ｃ［ｉ］．ｆ’＝’ｆｘ’および’Ｃ［ｉ］．ｇ’＝’ｇ’、０≦ｉ≦ｎと設定することによって、（６．５０）は以下のように簡単になる。
【０５２８】
ｇＳｆ０Ｄ［（ｇ０Ｓｆ１Ｄ）（ｇ１Ｓｆ２Ｄ）．．．（ｇｎ−１ＳｆｎＤ）］［（ｆｎＳｇｎ−１Ｄ）（ｆｎ−１Ｓｇｎ−２Ｄ）．．．（ｆ１Ｓｇ０Ｄ）ｆ０ＳｇＤ （６．５１）
ここで、ｇＳｆ０Ｄ＝α、ｇｉＳｆｉ＋１Ｄ＝βｉ、ｆｉ＋１ＳｇｉＤ＝βｉ−１、０≦ｉ≦ｎおよびｆ０ＳｇＤ＝α−１と設定して、文脈依存シーケンスを得る。
【０５２９】
α［β０β１．．．βｎ］［βｎ−１．．．β１−１βｎ−１］、ｎ≧０ （６．５２）
したがって、これに対するＡＬＬＥＯＰは明らかに有限ＡＬＬＥＯＰではないが、有限の記述を有することになる。一般に、動的ネットワークに割り当てられたＡＬＬＥＯＰは一般帰納的である。
【０５３０】
ここで、（ｉ）アプリケーションと並列に実行（ｒｕｎ）されながらアプリケーションの動的に拡大している因果律網を生成するＳＭＳ機構、（ｉｉ）メッセージが事前に指定されているセキュリティ要件を満たすポートにだけ配信されるデータ依存セキュリティチェック用の機構、および（ｉｉｉ）自動同期と調和のための機構を含んでいるグループ対グループメッセージ送信プロトコルに進む。
【０５３１】
７．グループ対グループ通信と自己監視システムのためのプロトコル
ＡＬＬＥＯＰモデルを使用してＥＣＴ評価と自己監視システム（ＳＭＳ）用の組み込み機構を通してＣＴＬアサーションを証明することはＴＩＣＣ−Ｐｐｄｅの不可欠な部分である。それらはＴＩＣＣ−Ｐｐｄｅに固有である。ＳＭＳのインフラストラクチャがメッセージ交換プロトコルにどのように一体化されているのかを説明しないと、この提示は不十分である。このセクションでグループ対グループのＤａｓ経路の変形例を例としてそれを行う。
【０５３２】
ｄｍ経路については、グループ対グループメッセージ交換はサービス要求を計算グリッドの１つのマルチプロセッサのポートグループ内の一般ポートの親セルから異なるグリッド内の他のマルチプロセッサのｆｕｎｃｔｉｏｎａｌＰｏｒｔのポートグループに配信する。応答メッセージは逐次機能ポートグループによって多重化モードで送信される。応答メッセージは受信したメッセージが互いに整合していない場合、再計算が要求されるという規定と共にサービス要求を送信した一般ポートグループによって１つにまとめられる。グリッド内の各マルチプロセッサはそのマルチプロセッサ内で動作しているセルだけに関係するＳＭＳ 因果律網を動的にインストールする。Ｄｍ経路は、４状態ハードウェアエージェント、４状態ソフトウェアポートを使用し、ハードウェアルータとスイッチも使用する。したがって、プロトコルはここで説明するものより複雑である。
【０５３３】
ｓｍ経路内でのメッセージ送信の３つのモードに対する３種類の完了信号を提供しており、ｓは送信モード、ｆは転送モード、およびｈは計算を中断する中断モードである。中断モードは一般ポートによってのみ使用される。中断モードでは、サービス要求メッセージは送信されず、経路は取り除かれる。セルグループ内のセルは情報を仮想メモリ、Ｍのスクラッチパッドを通して交換することによって送信する信号の種類を調和させる。
【０５３４】
0005704459.tif 000023
【０５３５】
図１９：自己監視のあるグループ対グループのｓｍ経路
共有メモリ環境において、前述のように、経路の仮想メモリのｒｅａｄＭｅｍｏｒｙ／ｗｒｉｔｅＭｅｍｏｒｙは送信モードにおいて切り替えられ、転送モードにおいて切り替えられない。送信と転送との間の選択は、ＴＩＰによって決定され、ｐｔｈｒｅａｄによって設定されたブールフラグに基づいている。ｐｔｈｒｅａｄは送信されるメッセージをＴＩＰがメッセージを転送するか送信するかによってｒｅａｄＭｅｍｏｒｙまたはｗｒｉｔｅＭｅｍｏｒｙに書き込み、ＴＩＰが正しい選択を行うように必要に応じて適切なブールフラグを設定する。したがって、ｐｔｈｒｅａｄとＴＩＰは何をするかについて互いに整合していなければならない。分散メモリメッセージ交換においては、転送モードや中断モードはなく、代わりに経路を取り除き、ネットワークルータとスイッチがそれらのアクティブな状態になり、新しい経路の確立プロセスを開始するための新しい信号を待つためのデータの終了信号、ｅとアボート信号、ａが存在する。
【０５３６】
グループ対グループメッセージパッシング用の修正されたＤａｓ経路を図１９に示している。メッセージは一般ポートのグループＧ＝［ｇ０，ｇ１，．．．，ｇｎ−１］と機能ポートのグループＦ＝［ｆ０，ｆ１，．．．，ｆｍ−１］との間で交換される。経路は４つのエージェント、ａ０、ａ１、ａ２、およびａ３を有している。それらは図に示しているようにｈブランチによって互いに接続されている。４つのエージェント全ては仮想メモリ、Ｍに付属している。図を明確にするために、Ｍに付属しているオフセット内でａ２とａ３とを図１９に示している。エージェントａ０はポートグループＧに対してチューンされており、ａ１はポートグループＦに対してチューンされており、ａ２は機能ポート、ｅｂ．ｆ１に対してチューンされており、ａ３はＥｖｅｎｔＢｕｉｌｄｅｒセルであるｅｂセルの機能ポート、ｅｂ．ｆ２に対してチューンされておりエージェントａ０．ｎｘｔ＝［ａ１，ａ２］およびａ１．ｎｘｔ＝［ａ０，ａ３］である機能ポートベクトル、［ｅｂ．ｆ１，ｅｂ．ｆ２］はｅｂセルに付属しているこのセルによって実行されるタスクをすぐに説明する。各ｅｂセルは、図１９のポート［ｅｂ．ｆ１，ｅｂ．ｆ２］とエージェントａ２とａ３のように機能ポートベクトル内の独立している１対のポートと関連付けられているエージェントとを通して各経路に接続されている５〜６個の別個の経路に対するサービスを行う。アプリケーションはそのような５〜６個のｅｂセルを有することがある。
【０５３７】
ポートグループＧとＦ内の各ポートは図１９に示している経路の一方の端部からその他方の端部へのメッセージの送信に必要なそのプロトコルに関連付けられている。ポートグループのポートの親セルがその計算を完了し、メッセージの送信の準備ができると、セルはそのポートに関連付けられているプロトコルの実行を開始する。したがって、ポートグループのポートの全ての親セルはそれらのそれぞれのポートで並列に相互に比較不能な時間点でプロトコルの評価を開始する。経路上のエージェントはメッセージ送信を調和させる。
【０５３８】
図１９のエージェントａｉ、ｉ＝０，１は各々がそれに対して定義されている３つの属性を有しており、１つはａｉに対してチューンされている任意のポートａｉ．ｓｅｌｅｃｔｅｄＰｏｒｔ、２番目はｆａｌｓｅに初期化されるブール属性ａｉ．ｄＣ（「ｄＣ」は「ｄｅｌｉｖｅｒｙＣｏｍｐｌｅｔｅ」を表す）、３番目は完了信号ベクトルと呼ばれるベクトル、Ｖｅｃｔｏｒ，ａｉ．ｃｓｖである。それは、ａｉに対してチューンされている各ポートに対して、そのポートから受信した信号を保存するための１つのベクトル要素とａｉ．ｎｘｔ［１］から受信した信号用の１つの要素とを有している。各要素は、４つの可能性のある値＞０、ｉ．ｃｓＶ［ｊ］＝ｃ｜ｆ｜ｈ｜ｉｇｎｏｒｅ＞０、ｃは送信、ｆは転送、ｈは中断、０≦ｊ＜ａｉ．ｃｓＶ：ｓｉｚｅ（）−１の１つを仮定しており、これらの信号はａｉにチューンされているポートによって送信される。最後の要素、ａｉ．ｃｓＶ［ａｉ．ｃｓＶ：ｓｉｚｅ（）−１］はａｉ．ｎｘｔ［１］によって送信された信号ｃを保存する。ａｉがａｉ．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅ、０≦ｊ＜ａｉ．ｃｓＶ：ｓｉｚｅ（）−１を設定するための４番目の信号が存在する。ａｉ．ｃｓＶがどのように使用されるかをすぐに説明する。
【０５３９】
Ｇの一般ポートは結合サービス要求をＦのｆｕｎｃｔｉｏｎａｌＰｏｒｔに送信していると仮定する。一般ポートグループは［Ｃｉ．ｇｉ｜０≦ｉ＜ｎ−ｌ］、ここでｎ−１＝Ｇ：ｓｉｚｅ（）およびａ０．ｃｓＶ：ｓｉｚｅ（）＝ｎである。図１９の一般ポートグループのＣｉ．ｇｉでのプロトコルは以下のフォーマットを有している（「.」をプロトコルの連続している逐次コンポーネントの連結を指定するために使用）。Ｃｉ．ｇｉ：ｐｒｏｔｏｃｏｌ（）は２つの連結されているコンポーネント、Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）とＣｉ．ｇｉ：ｓｕｆｆｉｘ（）を有している。以下のステートメント（７．２ａ）はＣｉ．ｇｉ：ｐｒｅｆｉｘ（）が何をするのかを記述している。Ｃｉ．ｇｉ：ｓｕｆｆｉｘ（）が何をするのかは後で説明する。以下では、ｍ−１＝Ｆ：ｓｉｚｅ（）とａ１．ｃｓＶ：ｓｉｚｅ（）＝ｍである。
【０５４０】
Ｃｉ．ｇｉ：ｐｒｏｔｏｃｏｌ（）＝Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）．Ｃｉ．ｇｉ：ｓｕｆｆｉｘ（）； （７．１）
Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）＝
［（ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ≠Ｃ０．ｇ０）？（）｛ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ＝Ｃ０．ｇ０｝
（ａ０．ｃｓＶ［０］≠０）？（）｛ａ０．ｃｓＶ［０．．．ｎ−２］＝０；ａｌ．ｃｓＶ［０．．．ｍ−２］＝０；｝
ａ１．ｄＣ？（）｛ａ１．ｄＣ＝ｆａｌｓｅ；｝．（Ｃｉ＝ｘｉ→ｇｉ：ｘｉ→ａ０）
（ａ０：ｓｅｌｅｃｔｅｄＰｏｒｔ≠Ｃｉ．ｇｉ）？（）｛ａ１：ｄＣ？（）＊｛｝；｝］ （７．２ａ）
Ｃｉ．ｇｉ：ｓｕｆｆｉｘ（）＝［ＡＰＩ［ａ０．ｃｓＶ［０．．．ｎ］］？（）＊｛Ｃｉ．ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）；｝］ （７．２ｂ）
【０５４１】
親セルＣｉがメッセージを送信する準備ができた時に、グループＧの他のポートの親セルと並列にＣｉ．ｇｉ：ｐｒｅｆｉｘ（）を実行する。この並列実行は同期しておらず、異なる親セルＣｉはこれを異なる時刻に実行するかもしれない。Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）の実行中に、Ｃｉが既に設定されていない場合、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ＝Ｃ０．ｇ０とまず設定し、それからまだ初期化されていない場合ベクトルａ０．ｃｓＶとａｌ．ｃｓＶが初期化されるが、これらのベクトルの最後の要素は初期化されない。Ｃｉはそれからまだｆａｌｓｅでない場合ａ１．ｄＣ＝ｆａｌｓｅと設定する。２つまたは３つ以上のセルＣｉがこれらの初期化を同時に実施することが可能である。相互干渉は存在しないので、ｐｔｈｒｅａｄ−ｌｏｃｋは必要ない。
【０５４２】
初期化後、各セルは３つの可能性のある完了信号、ｘｉ＝ｃ｜ｆ｜ｈ＞０の１つをポートＣｉ．ｇｉに送信し、ポートはこの信号をａ０に転送する。その後、Ｃｉは表現、（ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ≠Ｃｉ．ｇｉ）？（）｛ａ１：ｄＣ？（）＊｛｝；｝を評価する。これによって、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔの親セル以外の全てのセルＣｉはａ１：ｄＣがｔｒｕｅになるまで待ち、つまりそれらはプロトコルのさらなる実行を停止する。ａ１：ｄＣがｔｒｕｅになると、セルＣｉはサービスを行う順序で次のポートの処理を開始する。その間に、ａ１：ｄＣがｔｒｕｅになる前に、全ての他のセルがａ１：ｄＣ？（）がｔｒｕｅになるのを待っている間に、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔの親セルＣ０はＣ０．ｇ０：ｓｕｆｆｉｘ（）の実行を開始し、これはＣ０．ｇ０：ｓｕｆｆｉｘ（）を実行する唯一のセルとなる。
【０５４３】
エージェントａ０は、ａ０．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅである各Ｃｊ．ｇｊ∈Ｇからの完了信号ｘｊ＞０と、ａ０．ｃｓＶ［ｎ−ｌ］＞０について、ａ０．ｎｘｔ［１］＝ａ２からの１つの信号Ｃの受信を待つ。ａ０がポートＣｊ．ｇｊからｘｊ＞０を受信すると、Ｃｊがその計算を完了したことがわかる。ａ２からＣ＞０を受信すると、前のメッセージ交換中にｅｂが同じ経路を通して何をしたかに関わらず、完了したことがわかる。これらの信号は、（７．２）のガードａ０：ＡＰｌ［ａ０．ｃｓＶ［０．．．ｎ−１］］？（）＊の引数になる。Ｃ０はこのガードを実行するが、それはこれがプロトコルの実行を依然として継続している唯一のセルｄだからである。全てのその要素が＞０である場合でだけ、つまり全ての待っている完了信号を受信した後にだけガードはｔｒｕｅと評価される。それは、それがｔｒｕｅになるまで繰り返し実行される。それがｔｒｕｅになると、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔの親セルＣ０はＣ０．ｇ０：ｓｕｆｆｉｘ−ｂｏｄｙ（）を実行する。ｓｕｆｆｉｘ−ｂｏｄｙはＧ内の全ての一般ポート、Ｃｊ．ｇｊについて同じである。そのため、ｓｅｌｅｃｔｅｄＰｏｒｔとしてどの一般ポートが選択されるかは問題ではない。ｓｕｆｆｉｘ−ｂｏｄｙが何をするのかはすぐに説明する。ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）を定義する前に、さらに変数とメソッドとを定義しなければならない。それらはすべてｓｍ経路内のエージェントとポートとに関連付けられており、それをこれから行う。
【０５４４】
セキュリティ指定：以下では、ａ１．Ｍはａ１に付属している仮想メモリを指している。エージェントａ１はメッセージをそれに対してチューンされているポートＤｊ．ｆｊに、ポートＤｊ．ｆｊが指定されたセキュリティ条件ａ１：Ｓｙ（Ｄｊ．ｆｊ，ａ１．Ｍ）？（）、０≦ｊ＜ｍ−１＝Ｆ：ｓｉｚｅ（）を満足する場合に限り配信する。任意のｊについてａ１：Ｓｙ（Ｄｊ．ｆｊ，ａ１．Ｍ）？（）がｆａｌｓｅの場合、ａｌ．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅが設定される、つまりｊ番目のポートが無視される。ユーザが異なる経路に対して異なるセキュリティ機能を定義することも可能である。メッセージが全ての安全なポートに配信される時に、変数ａ１．ｄＣがｔｒｕｅに設定される。
【０５４５】
他の経路変数とメソッド：変数ａ０．ｃｃＳは第２の一致プロトコルメソッド、以下の（７．４−（ｉ））で使用されるＡＰ２によって計算された合成完了信号（ｃｃｓ）の値を保持している。ＡＰ２は（７．３）で定義されている。メソッドａ０：ｒｅｓｅｔＰａｔｈｗａｙ（）はａ０が現れているｓｍ経路をその初期状態にリセットするために（７．４）で使用される。メソッド例外（ｆ）はポートｆ∈Ｆでそのポートでのセキュリティ障害についてオブザーバに警告するために例外を発行する。メソッドａ０：ｓｗＭｅｍ（）はａ０の読み／書きメモリを切り替える。メソッドｆ：ｔｉｍｅｓｔａｍｐ（）はメッセージがいつｆに配信されたかを示している親セルのローカル時間でｆでのタイムスタンプを設定する、条件ｆ：ａｃｔｉｖｅ？（）はｆの親セルがＣＰＵにおいて既に実行（ｒｕｎ）されているかどうかを確認し、メソッドｆ：ａｃｔｉｖａｔｅ（）ｆの親セルを利用可能なＣＰＵにおいて起動する。前述のように、ＴＩＣＣ−Ｐｐｄｅ自体が全てのＣＰＵの割り当てとセルの起動とを管理する。
【０５４６】
ここで、ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）を定義する準備ができており、第２の一致プロトコル関数ａ０：ＡＰ２［ａ０：ｃｓＶ［０．．．ｎ−２］］を使用する。ただし、これにはエージェントａ２から受信した信号ａ０：ｃｓＶ［ｎ−１］は含まれない。これは、ａ０がＧの一般ポートから受信した完了信号を確認し、合成完了信号ａ０．ｃｃＳ＝ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］を設定するだけであって、ここで、
ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ｃ ｉｆ∃ｉ（０≦ｉ＜ｎ−ｌ）（ａ０．ｃｓＶ［ｉ］＝ｃ） ｅｌｓｅ
ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ｆ ｉｆ［（∃ｉ（０≦ｉ＜ｎ−ｌ）（ａ０．ｃｓＶ［ｉ］＝ｆ））＆
（∀ｉ（０≦ｉ＜ｎ−ｌ）（ａ０．ｃｓＶ［ｉ］＝（ｆ｜ｉｇｎｏｒｅ）））］
ｅｌｓｅ ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ｈ （７．３）
ただし、ａ２からの完了信号であるａ０．ｃｓＶ［ｎ−ｉ］はここでは使用されない。ここで、ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）を示し、それが何をするのか説明する。
【０５４７】
（ｉ）ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）＝／／ａ０：ｓｅｌｅｃｔｅｄＰｏｒｔの親セルによって実行（ｒｕｎ）される
［ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ａ０．ｃｃＳ；／／エージェントａ２からの信号ｃはここでは除外
／／ａ０．ｃｃｓ＝ｈの場合は、プロトコルの実行をやめ、メッセージ送信を中止する
（ａ０．ｃｃＳ＝ｈ）？（）｛ａ０：ｒｅｓｅｔＰａｔｈｗａｙ（）；ａ１．ｄｃ＝ｔｒｕｅ｝
ｅｌｓｅ ｔｒｕｅ｛ａ１：ｃｋＳｅｃｕｒｉｔｙ＆Ｐｒｏｃｅｅｄ（）；｝］
（ｉｉ）ａ１：ｃｋＳｅｃｕｒｉｔｙ＆Ｐｒｏｃｅｅｄ（）＝／／ａ０：ｓｅｌｅｃｔｅｄＰｏｒｔの親セルによって実行される
//ａ１．ｃｓＶを設定して、安全ではないポートを無視し、そのような各ポートについて違反メッセージを生成する
［∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（））？（）｛¬ａ１：Ｓ（ｆｊ，ａ１．Ｍ）？（）｛ａ１．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅ；
ａ１：ｅｘｃｅｐｔｉｏｎ（ｆｊ）；｝｝
／／Ｆの全ての機能ポートが安全ではない場合、プロトコルの実行をやめる
ここでは∀ｊは列挙子として使用される
（∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（）＆（ａ１．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅ））？（）｛ａ０：ｒｅｓｅｔＰａｔｈｗａｙ（）；
ａ１．ｄＣ＝ｔｒｕｅ｝
ｅｌｓｅｔｒｕｅ｛ａ０：ｓｅｎｄＳｉｇｎａｌｓ（）；ａ１：ａｃｔｉｖａｔｅ＆ＤｅｌｉｖｅｒＳｉｇｎａｌｓ（）；｝］
（ｉｉｉ）ａ０：ｓｅｎｄＳｉｇｎａｌｓ（）＝／／ａ０：ｓｅｉｅｃｔｅｄＰｏｒｔの親セルによって実行される
／／ａ２またはａ３から以前受信した信号をゼロに初期化
ａ０．ｃｓＶ［ｎ−１］＝０；ａｌ．ｃｓＶ［ｍ−ｌ］＝０；
／／ａ０．ｃｃｓ＝ｃの場合、メモリを切り替え、ｃをｅｂ．ｆ１に配信し、ｅｂのローカル時間でタイムスタンプを設定する
（ａ０．ｃｃＳ＝ｃ）？（）｛ａ０：ｓｗＭｅｍ（）；ａ０：ｓ→ａ１；
ａ０：ｃ→ａ２：ｃ→ｅｂ．ｆ１：ｔｉｍｅｓｔａｍｐ（）；｝
／＊そうでなければ、メモリを切り替えず、ｆをｅｂ．ｆ１に配信し、タイムスタンプを設定する＊／
ｅｌｓｅｔｒｕｅ｛ａ０：ｓ→ａ１；ａ０：ｆ→ａ２：ｆ→ｅｂ．ｆｘ：ｔｉｍｅｓｔａｍｐ（）；｝］
（ｉｖ）ａ１：ａｃｔｉｖａｔｅ＆ＤｅｌｉｖｅｒＳｉｇｎａｌｓ（）＝／／ａ０：ｓｅｉｅｃｔｅｄＰｏｒｔの親セルによって実行（ｒｕｎ）
／／以下では、∀ｊは列挙子として使用される。安全な機能ポートの休止中の親セルを起動
［（∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（））｛（ａ１．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅ）？（）＆¬ｆｊ：ａｃｔｉｖｅ？（））？（）｛
ｆｊ：ａｃｔｉｖａｔｅ（）；｝｝
／／信号ｓを配信し、タイムスタップを安全なポートｆｊの親セルのローカル時間に設定
［（∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（））｛（ａ１．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅ）？（）｛
ａ１：ｓ→ｆｊ，：ｔｉｍｅＳｔａｍｐ（）；｝｝
／／ａ１．ｄｃ＝ｔｒｕｅと設定し、配信完了信号ｓをｅｂ．ｆ２に配信。タイムスタンプをｅｂのローカル時間に設定
ａ１：ｓ→ａ３：ｓ→ｅｂ．ｆ２：ｔｉｍｅｓｔａｍｐ（）；ａ１．ｄＣ＝ｔｒｕｅ；］ （７．４）
【０５４８】
同じｓｕｆｆｉｘ−ｂｏｄｙを各ｇｉ∈Ｇに関連付けることによって、ポートグループＧに対する動的変更の調和が簡単になる。新しいトランザクションが始まる前にポートをＧに動的に追加したり削除したりすることができる。ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）が何をするか考える。
【０５４９】
（７．４−（ｉ））：（ａ０．ｃｃＳ＝ｈ）の場合、経路はリセットされ、ａ１．ｄＣはｔｒｕｅに設定される。この場合、メッセージは送信されない。（ａ０．ｃｃＳ≠ｈ）の場合、Ｃ０は（７．４−（ｉｉ））から始まるプロトコルの残りの実行（ｒｕｎ）を開始し、この実行の最後にａ１．ｄｃをｔｒｕｅに設定する。以下が発生する。
【０５５０】
（７．４）−（ｉｉ））：セキュリティチェックがまず実行され、ベクトルａ１．ｃｓＶが安全ではない機能ポートについてｉｇｏｎｏｒｅ信号によって更新され、例外（セキュリティ障害を通知するメッセージ）が生成される。全ての機能ポートが安全ではない場合、プロトコルの実行は破棄される。そうでなければ継続する。
【０５５１】
（７．４−（ｉｉｉ））：まず、ａ２とａ３から以前受信したａ０：ｃｓＶ［ｎ−ｌ］とａ１：ｃｓＶ［ｍ−ｌ］の信号をリセットする。エージェントａ０は以下を実行する。（ａ０．ｃｃＳ＝ｃ）（（７．３）を参照）の場合、読み／書きメモリは切り替えられ、開始信号ｓがａ１に送信され、信号ｃがｅｂ．ｆ１に配信され、そうでなければ、読み／書きメモリは切り替えられず、転送信号ｆがｅｂ．ｆ１に配信され信号ｓがａ１に送信される。いずれの場合も、信号配信タイムスタンプはｅｂのローカル時間で設定される。このタイムスタンプは以下の（７．６）のｅｂ．ｔｓによって参照されるメッセージディスパッチの時刻としてｅｂセルによって解釈される。全てのｅｂセルはグローバル時間に同期しているため、このメッセージディスパッチ時間はグローバル時間である。
【０５５２】
（７．４−（ｉｖ））：まず安全な各機能ポート、ｆ［ｊ］∈Ｆについて、その親セルが既に起動されているかどうかチェックする。起動されていない場合、親セルを起動する。ＴＩＣＣ−Ｐｐｄｅでのセルの起動は比較的高価である。２ギガヘルツコンピュータにおいてセルを起動するのに約２．５マイクロ秒かかる。これがこの動作を記述しているステートメントが（（７．３）−（ｉｖ））において分離されている理由である。通常、初めてメッセージがポートに配信された時に起動は１回だけ実施され、この部分を分離することによって、送信すべき配信信号を全ての安全なポートに素早く連続して送信することができる。配信信号をすべての安全なポートに送信した後、信号ｓをタイムスタンプと共にポートｅｂ．ｆ２にエージェントａを通して配信し、それからａ１：ｄＣをｔｒｕｅに設定する。ｅｂはこのタイムスタンプをメッセージ配信時刻と解釈し、（７．６）ではｅｂ．ｔｄと表される。
【０５５３】
ＣＣＰが機械命令として実装され、タイムスタンプの設定にハードウェア支援が利用可能な場合、信号は安全なポートに２ギガヘルツＣＰＵにおいて３ナノ秒未満の連続したポートの間の間隔で配信される（推定）。安全な各機能ポート、ｆについては、ポートｆで設定された信号配信タイムスタンプは親セルのローカル時間である。全ての安全なポートへのメッセージ配信が完了するか、プロトコル実行が破棄されると、ａ１．ｄＣはｔｒｕｅに設定される。機能ポートの親セルによる配信された信号の処理を全てのａ１：ｄＣがｔｒｕｅになってから、つまりメッセージが全ての安全な機能ポートに配信された後で始まるように構成することができる。これは、ｆ：ｍＲ？（）とｇ：ｐＲ？（）以下のように修正することによって実装される。
｛〈ｆ：ｉｎｐｕｔ＝ｓ＆ａ１．ｄＣ＝ｔｒｕｅ〉（ｔ）｝［・→ｆ：ｍＲ？（）（ｔ）］｛（ｔｒｕｅ＆ｆ：ｓｔａｔｅ＝Ｓ）（ｔ’）｝
｛〈（ｇ：ｉｎｐｕｔ＝ｓ∨ｇ：ｓｔａｔｅ＝Ｓ）＆ａ０．ｄＣ＝ｔｒｕｅ）（ｔ）｝［・→ｇ：ｐＲ？（）（ｔ）］
｛〈ｔｒｕｅ＆ｇ：ｉｎｐｕｔ＝φ＆ｇ：ｓｔａｔｅ＝Ｓ〉（ｔ’）｝ （７．５）
【０５５４】
その間に、ｅｂがｅｂ．ｆ１で信号ｃ｜ｆをｅｂ．ｆ２で信号ｓをローカル時間ｅｂ．ｔｓとｅｂ．ｔｄでそれぞれ検知すると、式（５．２１）において指定されているように、グループ対グループメッセージ配信に関連付けられている以下のｃｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔをインストールする。
【０５５５】
Ｃ．ｇｉＳ｜Ｆ（ｅｂ．ｔｓ）ｆｏｒ（０≦ｉ＜ｎ），かつ〈Ｄ．ｆｊＤ〉（ｅｂ．ｔｄ）、（０≦ｊ＜ｍ） （７．６）
それらを因果律網に統合した後、以下に示すプロトコルをそれぞれｅｂ．ｆ１とｅｂ．ｆ２で実行して完了信号ｃをａ０とａ１に返信する。
【０５５６】
（ｅｂ．ｆ１：ｃ→ａ２：ｃ→ａ０）および（ｅｂ．ｆ２：ｃ→ａ３：ｃ→ａ１） （７．７）
この全ては、図１９のポートＤｊ．ｆｊの親セルがそれらに配信されたばかりのサービス要求に対する応答を処理している間に行われる。２つのｅｂセルがＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔを拡大している因果律網内の同じ場所にインストールすることはないので、ｅｂセルがｅｂセルのアクティビティを並列に実行している時に異なるｅｂセル間に相互干渉は発生しない。
【０５５７】
0005704459.tif 000024
【０５５８】
図２０：一般ポートから安全な機能ポートへのメッセージ配信におけるイベント
【０５５９】
0005704459.tif 000025
【０５６０】
図２１：安全な機能ポートから一般ポートへの応答配信におけるイベント
ｅｂセルは仮想メモリへアクセスするので、ａ１．ｃｓＶにアクセスしてメッセージが配信されたｆｕｎｃｔｉｏｎａｌＰｏｒｔを識別することができる。ＡＬＬＥＯＰを使用して、イベントインスタンスをインストールしなければならない拡大している因果律網内の位置を求めることができる。これらのデータを使用してｅｂセルはＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔを因果律網にインストールする。そのように因果律網にインストールされた因果律網の一部を図２０に示している。ここで、ｇｉｓ、０≦ｉ＜ｎ−１のディスパッチ時刻は信号がｅｂ．ｆ１に配信された時刻のｔｓに設定される。機能ポートへの配信時刻は信号がｅｂ．ｆ２に配信されたｔｄに通常記録される。
【０５６１】
図２１は応答メッセージ送信用にインストールされたネットワークを示している。図２０と２１のｇｉＳの上付き文字Ｓはメッセージが既に転送されている場合Ｆとなる。
【０５６２】
ただし、メッセージ送信とメッセージ配信イベントインスタンスはすべてｅｂセルによってＡＬＬＥＯＰの知識から予期されている。実際に、予期されたイベントノードが事前に指定された期限内に現れない場合、拡張する因果律網を常に監視しているｅａセル（ＥｖｅｎｔＡｎａｌｙｚｅｒセル、以下で説明）は、ｅｂセルと並列に可能性のあるシステム障害についてのエラー報告をオブザーバに発行する。ｅｂセルは、イベントインスタンスをインストール中にｅｂ．ｆ１とｅｂ．ｆ２に接続されている経路の仮想メモリにアクセスできるので、メッセージ送信と受信セルにおいて成立しなければならないトレース内で条件をチェックすることさえができる。しかし、これはメッセージ送信を不当に遅延させ、実行（ｒｕｎ）時には実用的ではないことがある。しかし、これはテストモードで行うことができる。
【０５６３】
サービス要求を受信したＦ内の機能ポートの親セルがメッセージ配信信号を機能ポートで検知した時に、ｆ｜ｃ信号をａ１に送信することによって応答メッセージを返信するために関連付けられているｐｔｈｒｅａｄとプロトコルを実行する。この時点で、ａ１はポートｅｂ．ｆｅと全ての安全なｆｕｎｃｔｉｏｎａｌＰｏｒｔだけから信号を予期しているが、それは安全ではないポートに対してｉｇｎｏｒｅ信号が既にａ１．ｃｓＶにおいて設定されているためである。応答メッセージを返送（転送）するプロトコルは、（７．１）、（７．２ａ）、（７．２ｂ）、および（７．４）に示しているプロトコルと同様で、以下の相違があり、それらは、ａ１：ｓｅｌｅｃｔｅｄＰｏｒｔがａ１．ｃｓＶの第１の安全なポート、つまりａ１．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅである第１のポート、ｆｊ∈Ｆに設定されていることである。Ｇの一般ポートに応答メッセージを配信するためにはセキュリティチェックは行われず、Ｇの各ポートは応答を受信する。
【０５６４】
0005704459.tif 000026
【０５６５】
図２２：ｅｂセルによって図２０と２１のトランザクションにインストールされた因果律網の部分
応答メッセージの搬送中に、（７．７）に記述しているように、ａ１は信号ｓをａ０に送信し、全ての安全なポートＤ．ｆｊから完了信号を受信し、ａ３から完了信号を受信した後で信号ｃ｜ｆをａ３にだけ送信する。エージェントａ３はｅｂに、応答メッセージがＧの一般ポートにディスパッチされていることを知らせるために、信号ｃ｜ｆをｅｂ．ｆ２に転送する。応答信号を一般ポートに配信した後、ａ０は信号ｓをａ２の送信し、ａ２はｅｂに応答メッセージがＧの一般ポート配信されたことを知らせるためにそれをｅｂ．ｆ１に転送する。ｅｂがこれらの信号を両方のポートｅｂ．ｆ１とｅｂ．ｆ２で検知した場合、図２１に示しているＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンスを安全な各ｆｊに対して拡大している因果律網の適切な場所にインストールする。このインストールを完了した後、ｅｂは（７．７）に示しているプロトコルを使用して完了信号ｃをｅｂ．ｆ１とｅｂ．ｆ２を通してエージェントａ０とａ１に送信する。図２０と２１の因果律網の部分を併せて図２２に示している。
【０５６６】
エージェントａ０、ａ１とポートｇとｆに対するｎｄＦＳＭについて既に説明した（図１から４を参照）。ｓｍ経路内の全てのエージェントとポートは同一の２状態ｎｄＦＳＭである。明らかに、プロトコルは点対点通信に対する方がより簡単であるが、それは選択されたポートが存在せず、ａｉ．ｃｓＶ、ｉ＝０，１は各々が２つの要素しか有していないためである。プロトコルは高々（６＋ｍ−１）個のＣＣＰを使用し、ｍ−１はＦのポートの数である。これは、ａ０に完了信号を送信するためにＣｉ．ｇｉの親セルによって並列に実行されるｎ−１個のＣＣＰを数えていない。グループ対グループ通信は比較的高価であるが、従来のグループ対グループ通信よりもはるかに安価である。
【０５６７】
前述のように、アプリケーションは５〜６個のｅｂセルをそのネットワーク内に有している。２つのｅｂが同じｓｍ経路のサービスを行うことはない。ｅｂセル以外に、アプリケーションは５〜６個のｅａセル、ＥｖｅｎｔＡｎａｌｙｚｅｒセルも有している。ｅａセルは拡大している因果律網のＡＬＬＥＯＰとの整合性をチェックし、事前に指定したイベントパターンの発生についてオブザーバにアラートを発行するために因果律網内でそれらの発生を探す。ほとんどの場合、監視されるイベントパターンはＡＬＬＥＯＰノードを終端記号として使用する正規表現によって指定することができる。
【０５６８】
ＴＩＣＣ−Ｐｐｄｅのこの種類の用法は、処理ユニット（ＣＰＵ）の実質的に無限の供給を必要とする。マルチコアチップとナノテクノロジーの到来により、必要なＣＰＵはすぐに容易に入手可能になる。ＴＩＣＣ−Ｐｐｄｅは任意の数の処理ユニットを使用する自然な環境を提供するだけでなく、各アプリケーションに対して自己監視システム（ＳＭＳ）を自動的に構築するために利用可能な処理ユニットを効率的に利用する。ＡＬＬＥＯＰは、アプリケーションの実行（ｒｕｎ）中に発生する可能性のあるイベントパターンを指定する。指定されたパターンからの逸脱は、ＳＭＳによってエラーと解釈される。因果律網内のイベントパターンが正しく、計算された値が誤りであることももちろんあり得る。しかし、この可能性は、セクション６．５で説明したように実装中または実装後に生成される正しさの証明によって排除される。これらの特徴はＴＩＣＣ−Ｐｐｄｅに固有である。
【０５６９】
７．１.一方通行の環状道路
これまで、応答はサービス要求が送信されたのと同じ経路を通して送信されるという規約を使用してきた。たまに、異なる逐次計算が１つのセルによって異なる他のセルにおいて生成された場合、これはｐｔｈｒｅａｄを複雑にし、セルに付属しているセルの数を増加させる原因となる。これは逐次計算の効率を低下させる原因にもなる。図２３に示している修正されたＤａｓ経路はこの問題を回避している（図を簡単にするために、ｅｂセルとｅａセルを使用したＳＭＳ用の経路増加はこの図には示していない）。
【０５７０】
0005704459.tif 000027
【０５７１】
図２３：一方通行の環状道路
ここで、図２３の一般ポートグループ、Ｇ１内のポートがそれらの結合サービス要求メッセージを機能ポートグループＦ１のポートに送信する。Ｇ１がこれを行った時に、そのポートは応答を受け取るために休止する。この応答をＦ３のポートから受信する。Ｆ１のポートはＧ１のポートによって送信された要求を受信し、他のサービス要求として見なすことができるそれらの結合応答をＦ２内のポートに送信する。Ｆ１がこれを行う時に、次のサービス要求メッセージをＧ１から受信するためにそのポートは休止する。この時計回りのメッセージパッシングはＧ１の最後のポートがＦ３のポートから応答を受信するまで図２３の経路ループを通して進行する。Ｇ１はこの応答をＦ３から受信した後で初めて次のサービス要求をＦ１に送信することができる。任意の数のエージェントを図２３の仮想メモリに付属させることができる。図２３の修正されたＤａｓ経路を合成ｓｍ経路と呼ぶが、それはこれが１つの仮想メモリとそれに関連付けられている５〜６個のエージェントとを有しているからである。この構成は並列ネットワークにおいて逐次計算を実行するのに有用である。合成経路の周囲の任意の１つのグループ内のセルは受信したメッセージを処理する時に並列に動作する。
【０５７２】
８．結論
ここではさまざまな他のパラダイムの概念を組み合わせた並列プログラミングパラダイムを導入した。ＴＩＣＣは並列プログラム開発と実行プラットフォームＴＩＣＣ−Ｐｐｄｅにおいて１つとなって動作するためにそれら全部に必要な糊を提供する。ＴＩＣＣ−Ｐｐｄｅは、（ｉ）並列処理ＴＩＣＣネットワークを定義し、（ｉｉ）ＴＩＰとＣＩＰを使用して抽象的にそれらのネットワークのコンポーネント間の相互動作を指定し、（ｉｉｉ）ｐｔｈｒｅａｄの連続した詳細化によって実装を完成し、（ｉｖ）実装から自動的にＡＬＬＥＯＰモデルを導出し、（ｖ）アクションの特徴付けを使用してＡＬＬＥＯＰモデルからトレースを自動的に導出し、（ｖｉ）トレースからＥＣＴネットワークを構築し、（ｖｉｉ）ＥＣＴネットワークを使用してＣＴＬアサーションと呼ばれるＦＳＰとＮＦＳＰの両方のレベルで実装の有効な特性の対話的な証明を生成し、（ｖｉｉｉ）ランタイム自己監視システム（ＳＭＳ）を完成した各実装に自動的に組み込み、（ｉｘ）限界試験とアドホック同期と調和を実施する方法を提供し、（ｘ）ＴＩＣＣ−Ｐｐｄｅは多数の処理ユニットを必要とし使用する。それは、統合されたＴＩＣＣＮＥＴを使用して様々なマルチコアチップ内でプログラムを効率的に開発し実行（ｒｕｎ）するために必要な抽象化とツールを提供する。これらは、全てのソフトウェアシステム、特に実時間サイバー物理システムとアクセス不能な任意の環境で実行（ｒｕｎ）されているシステムの設計、実装、検証、および実行（ｒｕｎ）のために有用なツールである。それらはＴＩＣＣ−Ｐｐｄｅに固有である。将来、全てのソフトウェアシステムは並列ソフトウェアシステムとなると信じている。
【０５７３】
アクターシステムにおいては、アクターシステムの意味論の定義にメッセージ交換の意味論も原理的に含めることが可能である。もちろん、はるかに複雑な分析も行う。しかし、π算法において、通信の意味論は算法の意味論にそのように含めることはできず、それはπ算法の枠組み内にリンクを通した名前の通信の機構を定義できないからである。それは所与のプリミティブとして仮定しなければならない。
【０５７４】
ＴＩＣＣ−Ｐｐｄｅにおいて、同期と調和は通信システムに組み込まれている。各メッセージ交換について、厳密な境界内でメッセージ送信イベントがいつ始まり、メッセージがいつ配信されるかを予測することができる。同様に、各アクションイベントについて、実行を開始する時刻と実行を完了する時刻とは適度に厳密な境界内で予測可能である。それらをアクターシステムやπ算法において行うことはできない。我々はあるドメインのイベントの集合からそれ自体への単調連続マッピングを示すことによってＴＩＣＣ−Ｐｐｄｅの意味論を定義し、マッピングは確認された実装の実行（ｒｕｎ）によって定義される。したがって、所望の結果だけが得られるという保証がある。確認された実装は意味論の定義の一部となる。
【０５７５】
ＴＩＣＣ−ＰｐｄｅにおけるＴＩＰ相互動作仕様はπ算法相互動作の定義に類似しており、通信機構がポートに関連付けられているプロトコルによってＴＩＰにおいて明示的に指定されているところが異なっている。通信はＣＳＰと類似している態様で計算に統合されているが、はるかに高い柔軟性、パワー、非同期通信コンポーネントの相互分離を備えている。ＴＩＣＣ−Ｐｐｄｅプログラムは自己同期、自己調和、および自己起動である。それらは、プログラムを正しく動作するようにするモニタ、セマフォ、スケジューラ、シンクロナイザ、コーディネータ、シリアライザ、または任意の他の装飾を必要としない。
【０５７６】
ＴＩＣＣ−Ｐｐｄｅは任意の数の処理ユニットが使用できると仮定している。実行（ｒｕｎ）できる処理ユニットの数は、発明の概要で説明した必要とするスケーラビリティ条件が満たされる限り数百万であってもよい。簡単に言えば、スケーラビリティ条件は任意の１つのポーリングサイクルにおいてセルによってサービスを受けるポートの数はシステム内のセルの数には無関係である。セクション６で説明した解法はどれもこの基準の下で任意にスケーラブルではない。これは、マルチコアとナノスケール技術が提供可能な処理ユニットの予測される爆発的な数を利用する機会を提供する。ＴＩＣＣ−Ｐｐｄｅにおいて提案したプログラミング方法論は理想的にはそのような技術を利用するのに適している。
【０５７７】
可能な限り、現在のプロトタイプ実装はオペレーティングシステムの必要性を排除している。原理的には、ＴＩＣＣ−Ｐｐｄｅにおいてオペレーティングシステムの必要性を完全に排除することができる。それはまだ行っていない。ＴＩＣＣは、ＣＣＰがハードウェアに命令として実装されており、マルチコアチップが同様にチップに統合されているＴＩＣＣＮＥＴを通して相互接続されている場合、数百ナノ秒の範囲のレイテンシでの高速通信の構成を、共有メモリと分散メモリの通信の両方に対して提供する。所与の時刻に並列に交換可能なメッセージの数は、その時点でシステム内で実行（ｒｕｎ）されているアクティブなセルの数とＴＩＣＣＮＥＴ内の使用可能な経路の数とによってだけ制限される。
【０５７８】
ＦＳＰ［１５］とＣＴＬ［４０〜４４｝を使用した設計仕様のモデルベースの証明はシステム設計において際だったそして重要な役割を果たしている。それらは、設計を検証し、実装が満足すべき特性を確認するために必要である。ＦＳＰの問題は、抽象的ＦＳＰ仕様は連続した詳細化によって実装に直接変換できないことである。これによって、異なるツールを使用して実装を検証する必要があり、このタスクは設計の検証よりも複雑である。
【０５７９】
Ｃｌａｒｋ他［３８−４０］、［Ｅｍｅｒｓｏｎ，４１］によるモデルベースの検証はハードウェア設計仕様を検証し、ハードウェア実装を検証しないが、それは調和とレーシング条件の問題が検証システムの一部とは思えないからである。しかしながら、Ｃｌａｒｋ他によって導入された検証方法はハードウェア設計者が設計を確認するために広く使用されている。レーシングのないハードウェアシステムの設計と検証を可能にするＧＥＳＥＬ［Ｓｃｈａｕｍｏｎｔ他，４６］などのハードウェア記述言語が存在する。しかし、それらが広く使用されているかどうかは明かではない。ＴＩＣＣ−Ｐｐｄｅの仕様の方法論は、レーシングのない非同期ハードウェアシステムの実装の仕様設定と検証に使用可能である。実装の全てのタイミング、同期、および調和の要件は暗示的には仕様の一部である。それらは、検証中に対応される。唯一の制限は、コンポーネントは非同期に相互動作しなければならないことである。これによって、ＴＩＣＣ−Ｐｐｄｅはクロックパルス駆動同期ハードウェア設計には適していない。ＴＩＣＣパラダイムの使用の利点は、意図した計算の抽象的な仕様が抽象的設計のＦＳＰ仕様のようであることであるが、それらはそれを連続した詳細化を通して実装に直接リダクションする方法も提供する。
【０５８０】
ＴＩＣＣパラダイムの使用は、実装を確認するためのモデルベースの正式な検証を既に検証されている部分的な実装の連続した詳細化に組み合わせることを可能にする。そのような検証能力を提供する以外に、ＴＩＣＣパラダイムは、ハードウェアかソフトウェアかにかかわらず、コンポーネントが非同期に相互動作し、ＣＣＰに基づいている通信機構を使用するかぎり、アプリケーションの生涯時間を通して性能を監視するために自動的にＳＭＳ（自己監視システム）を完成した実装に自動的に組み込む。ＴＩＣＣ−Ｐｐｄｅはシステム開発の焦点をプログラミングからネットワーク構成、相互動作の仕様、および検証にシフトする。
【０５８１】
ＴＩＣＣパラダイムにおけるソフトウェア／ハードウェアコンポーネント間の相互動作のモードは、従来の並列ソフトウェアシステム、タイムスライス並行ソフトウェアシステム、または同期ハードウェアシステムのモードと同じではない。ＴＩＣＣネットワークの設計、ＴＩＰとＣＩＰの定義、ｐｔｈｒｅａｄの特徴付けの開発、および確認すべきＣＴＬアサーションの識別は重要であり困難な問題である。それらには、システム設計者とプログラマを訓練する方法に対する新しいアプローチが必要である。設計者をプログラミングについてだけでなく、コンポーネント相互動作分析、論理、および検証技法についても訓練しなければならない。
【０５８２】
ここで示したアイデアには計算とソフトウェア／ハードウェア工学の新たな時代を開始する潜在力がある。個人が自分のデスクトップとラップトップコンピュータを使用する方法、コンピュータが科学技術用途において設計され使用される方法、社会、教育、ビジネス、および政府の組織がコンピュータを使用する方法に大きく影響する可能性がある。ユーザをプライバシーの侵害と悪意のある攻撃から保護する複雑で確認された安全な自己修正ソフトウェアを作成することさえできる。
付録Ｉ
装飾的な庭の解法ＴＩＰ、ＡＬＬＥＯＰ、およびトレース
【０５８３】
環境セル：
Ｅ．ｉ：ＴＩＰ（）＝［（ｉ：ｍＲ？（）＆ｇ：ｐＲ？（））｛ｇ：ｓ（）／＊すべてのセルを開始＊／
ｉ：ｓ（）；／＊ユーザへの肯定応答＊／｝（Ｉ．１）
【０５８４】
入口回転改札口入口センサ：
Ｓｅ［ｊ：０．．．１］ ．ｇ：ＴｌＰ（） ＝
Ｓｅ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛
Ｓｅ［ｊ］．ｇ：ｓ（）；／／ｓｉｇｎａｌｓＥｔ［ｊ］．ｆｔ
Ｓｅ［ｊ］．ｇ：ｐＲ？（）＊｛Ｓｅ［ｊ］．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅ＝ｆａｌｓｅ；｝｝ （Ｉ．２）
人がゲート（回転改札口）に近づくと、ゲートのセンサがＳｅ．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅ＝ｔｒｕｅと設定される。人を公園に入れた後、または公園が満員であるので人の入園を拒否した後、人はゲートを離れる。その点で、入口回転改札口の機能ポート、Ｅｔ［ｊ］．ｆｔは応答をＳｅ．ｇに返信する。センサがこの応答を受信すると、センサはＳｅ．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅをｆａｌｓｅにリセットする。次の人がゲートに到着すると、センサは再びｔｒｕｅに設定されることになる。したがって、第２の人は第１の人がゲートを離れて初めて入園する。
【０５８５】
入口の回転改札口：
Ｅｔ［ｊ：０．．．１］．ｆｔ：ＴｌＰ（）＝
／＊信号をＥｔ［ｊ］．ｆｔで検知すると、Ｅｔ［ｊ］は経路Ｅｔ［ｊ］．ｇ⇔Ｃｆ［ｊ］を通してカウンタｃに合図する。そうした後で、以下の非決定的ポーリングを実施することによってｃからの応答を待つ＊／
［Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）｛／／この述語はＳｅ［ｊ］．ｇから信号を受信する、（Ｉ．４）を参照
Ｅｔ［ｊ］．ｇ：ｓ（）；／／入園許可を得るための信号Ｃｆ［ｊ］
／／応答を待つ
（∃（Ｐ）（Ｐ＝（Ｅｔ［ｊ］．ｇ｜Ｅｔ［ｊ］．ｆ））ｐ：ｍＲ？（））＊｛
ｓｅｌｅｃｔＯｎｅ｛（ｐ＝Ｅｔ［ｊ］．ｇ）？（）｛Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）；｝
（Ｐ＝Ｅｔ［ｊ］．ｆ）？（）｛Ｅｔ［ｊ］．ｆ：ｄｅｎｙＥｎｔｒｙ（）．ｓ（）；｝｝
／＊Ｅｔ［ｊ］．ｇが信号を送信する準備ができたときに、応答信号をＳｅ［ｊ］．ｇに送信する
Ｅｔ［ｊ］．ｇ：ｐＲ？（）＊｛Ｅｔ［ｊ］．ｆｔ：ｓ（）；｝｝ （Ｉ．３）
【０５８６】
定義：
Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）⇔Ｅｔ［ｊ］．ｆｔ．ｉｎｐｕｔ＝ｓ
⇔Ｅｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｅｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｅ．ｇ，１）］） （Ｉ．４）
この述語は、開示の便宜上使用されている。信号がＥｔ［ｊ］．ｆｔにＳｅ［ｊ］．ｇによって配信され、Ｅｔ［ｊ］がその信号を検知した場合にだけｔｒｕｅである。Ｅｔ［ｊ］．ｆｔがＳｅ［ｊ］．ｇに応答すると、Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）はｆａｌｓｅになるが、それはＥｔ［ｊ］．ｆｔ．ｉｎｐｕｔ＝ｓがもはやｔｒｕｅにならないからである。
【０５８７】
｛Ｅｔ［ｊ］．ｇ：ｍＲ？（）＊｝［・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）］｛Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）｝ （Ｉ．５）
｛Ｅｔ［ｊ］．ｆ：ｍＲ？（）＊｝［・→Ｅｔ［ｊ］．ｆ：ｄｅｎｙＥｎｔｒｙ（）］｛¬Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）｝ （Ｉ．６）
【０５８８】
出口回転改札口センサ：
Ｓｘ［ｊ：０．．．１］．ｇ：ＴｌＰ（）＝
Ｓｘ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛
Ｓｘ［ｊ］．ｇ：ｓ（）；／／ｓｉｇｎａｌｓｘｔ［ｊ］．ｆｔ
Ｓｘ［ｊ］．ｇ：ｐＲ？（）＊｛Ｓｘ［ｊ］．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅ＝ｆａｌｓｅ；｝｝（Ｉ．７）
【０５８９】
出口の回転改札口：
ｘｔ［ｊ：０．．．１］．ｆｔ：ＴｌＰ（）＝
（Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）｛Ｘｔ［ｊ］．ｇ：ｓ（）；｝／／ｓｉｇｎａｌｓ Ｘｔ［ｊ］．ｆｔ
Ｘｔ［ｊ］．ｆｔ：ｍＲ？（））｛Ｘｔ［ｊ］．ｇ：ｓ（）；／＊信号カウンタ＊／
Ｘｔ［ｊ］．ｇ：ｍＲ（）＊｛
ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）；｝
Ｘｔ［ｊ］．ｆｔ：ｓ（）；｝ （Ｉ．９）
【０５９０】
定義：
｛Ｘｔ［ｊ］．ｆｔ：ｍＲ？（）｝
［・→Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）］｛¬Ｘｔ［ｊ］．ｇ：ｐｅｒｓｏｎＩｎＰａｒｋ？（）｝ （Ｉ．１０）
Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）⇔Ｘｔ［ｊ］．ｆｔ．ｉｎｐｕｔ＝ｓ
⇔Ｘｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｘｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｘ．ｇ，１）］） （Ｉ．１１）
【０５９１】
カウンタ：公園に余裕がある場合、つまりｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘの場合、ポートＣ．ｆ［ｊ：０．．．１］で信号検知すると、カウンタを増加させ、Ｃｆ［ｊ］⇔Ｅｔ［ｊ］．ｇを通してＥｔ［ｊ］．ｇに応答して、入園を許可し、そうでなければ、ｃ．ｇ［ｊ］⇔Ｅｔ［ｊ］．ｆを通して入園を拒否し、応答を待ち、それからＣ．ｆ［ｊ］を通して受信した信号に肯定応答する。セルＣが起動された時にカウンタはゼロに初期化され、ｍａｘ＞０が設定される。
【０５９２】
Ｃ．ｆ［ｊ：０．．．１］：ＴＩＰ（）＝
Ｃ．ｆ［ｊ：０．．．１］：ＴＩＰ（）＝｛／／Ｅｔ［ｊ］．ｇからの人が入園しようとしているという通知を検知する
／＊ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）？（）がｔｒｕｅならばカウンタを増加させ、信号をＥｔ［ｊ］．ｇに返信して入園を許可する。これはＥｔ［ｊ］．ｇから受信した信号にも肯定応答する＊／
（ｃｏｕｎｔｅｒ，ｃｏｕｎｔ＜ｍａｘ）？（）｛ｃｏｕｎｔｅｒ＋＋；Ｃ．ｆ［ｊ］：ｓ｝
／＊そうでなければＥｔ［ｊ］．ｆに信号をそのポートＣ．ｇ［ｊ］から送信して入園を拒否する。
【０５９３】
Ｅｔ［ｊ］．ｇから受信した信号には肯定応答しない＊／
ｅｌｓｅ ｔｒｕｅ｛Ｃｇ［ｊ］：ｓ（）；
／＊Ｅｔ［ｊ］．ｆからの肯定応答を受信すると、以前にＥｔ［ｊ］．ｇから受信した信号の肯定応答を返信する＊／
Ｃ．ｇ［ｊ］：ｍＲ？（）＊｛Ｃ．ｆ［ｊ］：ｓ（）；｝｝（Ｉ．１２）
ポートＣ．ｆ［ｊ：２．．．３］で信号を検知するとカウンタを減少させ、Ｘｔ［ｊ］．ｇｎに応答してゲートの人が出園できるようにする。
【０５９４】
Ｃ．ｆ［ｊ：２．．．３］：ＴＩＰ（）＝Ｃ．ｆ［ｊ］：ｍＲ？（）｛ｃｏｕｎｔｅｒ−−；Ｃ．ｆ［ｊ］：ｓ（）；｝ （Ｉ．１３）
ｃｏｕｎｔｅｒ．ｃｏｕｎｔをＣ．ｆ［４］で信号を検知すると表示ユニットに送信する。
【０５９５】
Ｃ．ｆ［４］：ＴＩＰ（）＝
Ｃ．ｆ［４］：ｍＲ？（）｛Ｃ．ｆ［４］：ｍａｋｅ（Ｃ．ｆ［４］．ｒｄ：ｍｓｇ（）．ｃｏｕｎｔ＝ｃｏｕｎｔｅｒ．ｃｏｕｎｔ）；
Ｃ．ｆ［４］：ｆ（）；｝ （Ｉ．１４）
【０５９６】
定義：
｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）？（）｝［・→ｃｏｕｎｔｅｒ＋＋］｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）？（）｝ （Ｉ．１５）
｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）？（）｝［・→ｃｏｕｎｔｅｒ――］｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）？（）｝ （Ｉ．１６）
【０５９７】
表示ユニット：その割り込みポートで信号を検知すると、カウントの要求をカウンタに転送する。それを受信したらカウントを表示。
【０５９８】
Ｄ．ｉ：ＴＩＰ（）＝
Ｄ．ｉ：ｍＲ？（）｛Ｄ．ｉ：ｓ（）；Ｄ．ｇ：ｆ（）；Ｄ．ｇ：ｍＲ？（）＊｛Ｄ．ｇ：ｄｉｓｐｌａｙＣｏｕｎｔ（）．ｓ（）；｝｝ （Ｉ．１７）
【０５９９】
定義：
｛Ｄ．ｇ：ｍＲ？０＊＆（∃（ｉｎｔｅｇｅｒ ｃ）（Ｄ．ｇ：ｒｄ．ｍｓｇ（）．ｃｏｕｎｔ＝ｃ）｝
［・→Ｄ．ｇ：ｄｉｓｐｌａｙＣｏｕｎｔ（）］｛Ｄ．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｕｎｔ＝ｃ｝ （Ｉ．１８）
【０６００】
ポーリングサイクル：表示ユニットを除く割り込みポートを無視する。
Ｅ：Ｐｏｌｌｉｎｇ（）：［Ｅ．ｉ：ｍＲ？（）→Ｅ：Ｐｏｌｌｉｎｇ（）］ （Ｉ．１９）
Ｓｅ［ｊ］：Ｐｏｌｌｉｎｇ（）：［Ｓｅ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）→Ｓｅ［ｊ］：ＰｏｌｌｉｎｇＯ］ （Ｉ．２０）
Ｓｘ［ｊ］：Ｐｏｌｌｉｎｇ（）：［Ｓｘ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）→Ｓｘ［ｊ］：Ｐｏｌｌｉｎｇ（）］ （Ｉ．２１）
Ｅｔ［ｊ：０．．．１］：Ｐｏｌｌｉｎｇ（）：［Ｅｔ［ｊ］．ｆｔ：ｍＲ？（）→Ｅｔ［ｊ］：Ｐｏｌｌｉｎｇ（）］ （Ｉ．２２）
Ｘｔ［ｋ：０．．．１］：Ｐｏｌｌｉｎｇ（）：［Ｘｔ［ｋ］．ｆｔ：ｍＲ？（）→Ｘｔ［ｋ］：Ｐｏｌｌｉｎｇ（）］ （Ｉ．２３）
ＣＰｏｌｌｉｎｇ（）：［Ｃ．ｆ［０］：ｍＲ？（）→Ｃ．ｆ［１］：ｍＲ？（）→Ｃ．ｆ［２］：ｍＲ？（）→
Ｃ．ｆ［３］：ｍＲ？（）→Ｃ．ｆ［４］：ｍＲ？（）→Ｃ：Ｐｏｌｌｉｎｇ］ （Ｉ．２４）
Ｄ：Ｐｏｌｌｉｎｇ（）：［Ｄ．ｉ：ｍＲ？（）→Ｄ：Ｐｏｌｌｉｎｇ（）］ （Ｉ．２５）
ＣＩＰをセルに対して定義する必要はないが、それは明白だからである。前述の定義から、システムは以下のＡＬＬＥＯＰとトレースを計算する。
【０６０１】
ＡＬＬＥＯＰ：
Ｅｔ［ｊ：０．．．１］：ＡＬＬＥＱＰ（）：
Ｅｔ［ｊ：０．．．１］：ＡＬＬＥＯＰ（）＝［Ｅｔ［ｊ］．ｆｔ：ＡＬＬＥＯＰ（）・→Ｅｔ［ｊ］：ＡＬＬＥＯＰ（）］ （Ｉ．２６）
Ｅｔ［ｊ：０．．．１］．ｆｔ：ＡＬＬＥＯＰ（）＝
［Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）｛
Ｅｔ［ｊ］．ｇｓ［ｔ（Ｅｔ［ｊ］．ｇ，０）］→
（〈ｃ．ｆ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｇ，１）］｜｜→．．．→Ｃ．ｆ［ｊ］：ＡＬＬＥＯＰ（．．．））・→
非決定的ポーリングからの選択肢をここに入れる
（Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇ０〉［ｔ（Ｃ．ｆ［ｊ］，１）］）＊｛Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）｝
｜
Ｅｔ［ｊ］．ｆ）ｍＲ？（〈Ｅｔ［ｊ］．ｆＤ〉［ｔ（Ｃ．ｇ［ｊ］，１）］）＊｛Ｅｔ［ｊ］．ｆ：ＤｅｎｙＥｎｔｒｙ（）・→
Ｅｔ［ｊ］．ｆＳ［ｔ（Ｅｔ［ｊ］．ｆ，Ｏ）］→
（〈Ｃ．ｇ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｆ，１）］
｜｜Ｃ．ｇ［ｊ］：ｍＲ？（〈Ｃ．ｇ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｆ，１）］）＊．→．．．→｝）｝
・→Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，３）］）＊｛Ｅｔ［ｊ］．ｆｔＳ［ｔ（Ｅｔ［ｊ］．ｆｔ，０）］
（→〈Ｓｅ［ｊ］．ｇ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｆｔ，１）］
｜｜［Ｓｅ［ｊ］．ｇ：ｐＲ？（〈Ｓｅ［ｊ］．ｇＤ〉［ｔ（Ｅｔ［ｊ］．ｆｔ，ｌ）］）・→．．．・→］）｝］ （Ｉ．２７）
【０６０２】
Ｘｔ［ｊ：０．．．１］ ：ＡＬＬＥＯＰ（）：
Ｘｔ［ｊ］：ＡＬＬＥＯＰ（）＝［Ｘｔ［ｊ］．ｆｔ：ＡＬＬＥＯＰ（）・→Ｘｔ［ｊ］：ＡＬＬＥＯＰ（）］ （Ｉ．２８）
Ｘｔ［ｊ］．ｆｔ：ＡＬＬＥＯＰ（）＝
［Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）｛
Ｘｔ．ｇＳ［ｔ（Ｘｔ［ｊ］．ｇ，０）］→／＊Ｃ．ｆ［ｊ＋２］へ信号を配信＊／
（〈Ｃ．ｆ［ｊ＋２］Ｄ〉［ｔ（Ｘｔ［ｊ］．ｇ，１）］｜｜→．．．→Ｃ．ｆ［ｊ＋２］：ＡＬＬＥＯＰ（））｝
／／ｃｏｕｎｔを減少させた後
Ｘｔ［ｊ］．ｇ：ｍＲ（（Ｘｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ＋２］，１）］）＊｛
Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）｝
Ｘｔ［ｊ］．ｆｔＳ［ｔ（Ｘｔ［ｊ］．ｆｔ，０）］］→〈Ｓｘ［ｊ］．ｇＤ〉［ｔ（Ｘｔ［ｊ］．ｆｔ，ｌ）］］ （Ｉ．２９）
【０６０３】
Ｃ ＡＬＬＥＯＰ（）：カウンタＡＬＬＥＯＰ
Ｃ：ＡＬＬＥＯＰ（）＝［Ｃ．ｆ［０］：ＡＬＬＥＯＰ（）・→Ｃ．ｆ［１］：ＡＬＬＥＯＰ（）・→Ｃ．ｆ［２］：ＡＬＬＥＯＰ（）
・→Ｃ．ｆ［３］：ＡＬＬＥＯＰ（）・→Ｃ．ｆ［４］：ＡＬＬＥＯＰ（）
・→Ｃ：ＡＬＬＥＯＰ（）］ （Ｉ．３０）
Ｃ．ｆ［ｊ：０．．．１］：ＡＬＬＥＯＰ（）＝
［Ｃ．ｆ［ｊ］：ｍＲ？（〈Ｃ．ｆ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｇ，１）］）｛
（（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）｛ｃｏｕｎｔｅｒ＋＋・→
Ｃ．ｆ［ｊ］Ｓ［ｔ（Ｃ．ｆ［ｊ］，０）］→
（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，１）］／／Ｅｔ［ｊ］．ｇは信号を即座に受信
｜｜Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，１）］）＊｛・→．．．・→｝・→．．．・→）｝｜
¬（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）｛ｃｏｕｎｔｅｒ−−・→
Ｃｇ［ｊ］Ｓ［ｔ（Ｃ．ｇ［ｊ］，０）］→
（Ｅｔ［ｊ］．ｆＤ［ｔ（Ｃ．ｇ［ｊ］，１）］
｜｜Ｅｔ［ｊ］．ｆ：ｍＲ？（〈Ｅｔ［ｊ］．ｆＤ〉［ｔ（Ｃ．ｇ［ｊ］，１）］）＊｛・→．．．・→｝・→．．．・→）
・→Ｃ．ｇ［ｊ］：ｍＲ？（）＊｛／／Ｅｔ［ｊ］．ｆからの応答を待つ
Ｃ．ｆ［ｊ］で受信した信号について肯定応答と返信
ｃ．ｆ［ｊ］Ｓ［ｔ（ｃ．ｆ［ｊ］，２）］→
（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，３）］／／Ｅｔ［ｊ］．ｇは肯定応答を即座に受信
｜｜Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，３）］）＊｛・→．．．・→｝）｝｝］ （Ｉ．３１）
Ｃ．ｆ［ｊ：２．．．３］：ＡＬＬＥＯＰ（）＝
［／／ｘｔ［ｊ−２］．ｇから人が出園するのを検知
Ｃ．ｆ［ｊ］：ｍＲ？（〈Ｃ．ｆ［ｊ］Ｄ〉［ｔ（Ｘｔ［ｊ−２］．ｇ，ｌ）］）｛ｃｏｕｎｔｅｒ――
・→Ｃｆ［ｊ］Ｓ［ｔ（Ｃ．ｆ［ｊ］，０）］／／ｘｔ［ｊ−２］．ｇに応答
→（〈Ｘｔ［ｊ−２］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，ｌ）］
／／Ｘｔ［ｊ−２］はＣ．ｆ［ｊ］からの応答を待ち、適切なアクションを行う
（〈Ｘｔ［ｊ−２］．ｇ：ｍＲ？（〈Ｘｔ［ｊ−２］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，１）］）＊｛．・→．．．・→｝）］ （Ｉ．３２）
Ｃ．ｆ［４］：ＡＬＬＥＯＰ（）＝
［Ｃ．ｆ［４］：ｍＲ？（〈Ｃ．ｆ［４］Ｄ〈［ｔ（Ｄ．ｇ，１）］）｛
・→Ｃ．ｆ［４］．ｒｄ：ｍａｋｅ（ｆ［４］：ｍｓｇ（）．ｃｏｕｎｔ＝ｃｏｕｎｔｅｒ．ｃｏｕｎｔ）
・→Ｃ．ｆ［４］Ｆ［ｔ（Ｃ．ｆ［４］，０）／／メッセージを転送
→（〈Ｄ．ｇＤ〉［ｔ（Ｃ．ｆ［４］，１）］
／／ＤはＣ．ｆ［４］からの応答を待ち、適切なアクションを行う
｜｜Ｄ．ｇ：ｍＲ？（〈Ｄ．ｇＤ〉［ｔ（Ｃ．ｆ［４］，１）］）＊｛・→．．．・→｝）｝］ （Ｉ．３３）
【０６０４】
Ｄ：ＡＬＬＥＯＰ（）：表示ユニットＡＬＬＥＯＰ。ここでＵはカウントを要求する外部ユーザ
Ｄ：ＡＬＬＥＯＰ（）＝［Ｄ．ｉ：ＡＬＬＥＯＰ（）・→Ｄ：ＡＬＬＥＯＰ（）］ （Ｉ．３４）
Ｄ．ｉ：ＡＬＬＥＯＰ（）＝
［Ｄ．ｉ：ｍＲ？（（Ｄ．ｉＤ〉［ｔ（Ｕ．ｇ，１）］）＊｛
Ｄ．ｉＳ［ｔ（Ｄ．ｉ，０）］→Ｕ．ｇＤ［ｔ（Ｄ．ｉ，１）］／／ユーザの信号を確認
・→Ｄ．ｇＦ［ｔ（Ｄ．ｇ，０）］／／カウントを要求
→（〈Ｃ．ｆ［４］Ｄ〉［ｔ（Ｄ．ｇ，１）］｜｜→．．．→Ｃ．ｆ［４］：ＡＬＬＥＯＰ（））
／／応答の受信時のカウントを表示
・→Ｄ．ｇ：ｍＲ？（〈Ｄ．ｇＤ〉［ｔ＜Ｃ．ｆ［４］，１）］）＊｛Ｄ．ｇ：ｄｉｓｐｌａｙＣｏｕｎｔ（）｝ （Ｉ．３５）
ただし、（Ｉ．３５）において、Ｄ．ｇを通して受信したメッセージに対しては応答は必要ではない。ＯＧ解法に対する結合ＡＬＬＥＯＰは以下のとおり：
装飾的な庭：ＡＬＬＥＯＰ（）＝
□
（Ｅｔ［０］：ＡＬＬＥＯＰ（）｜｜Ｅｔ［１］：ＡＬＬＥＯＰ（）｜｜Ｄ：ＡＬＬＥＯＰ（）｜｜
Ｘｔ［０］：ＡＬＬＥＯＰ（）｜｜Ｘｔ［１］：ＡＬＬＥＯＰ（）｜｜ＣＡＬＬＥＯＰ（））］ （Ｉ．３６）
【０６０５】
トレース：入口の回転改札口Ｅｔ［ｊ］のトレースだけを示す。
入口の回転改札口のトレース：以下のトレースは、（Ｉ．２７）のＥｔ［ｊ：０．．．１］．ｆｔ：ＡＬＬＥＯＰ（）から導出されている。このトレース内の情報は、セクション６．１の表ＩのＥＣＴネットワークの上部の３つのブロックに示されている。表１はＣ．ｆ［ｊ：０．．．１］：ｔｒａｃｅ（ｃｆ［ｊ］．ｔ０）および、Ｅｔ［ｊ］．ｆｔ：ｔｒａｃｅ（ｅ［ｊ］ｆｔ．ｔ０）とＣ．ｆ［ｊ］：ｔｒａｃｅ（ｃｆ［ｊ］．ｔ０）との間の相互動作の情報も示している。読者が以下のトレースと表Ｉの上部の３つのブロックの情報を比較すること提案する。これによって、読者はトレースとＥＣＴとの間の対応を理解できる。それは退屈であるが、複雑ではない。
Ｅｔ［ｊ：０．．．１］．ｆｔ：ｔｒａｃｅ（ｅ［ｊ］ｆｔ．ｔ０）＝
［∃（ｅ［ｊ］ｆｔ．ｔ０＜ｅ［ｊ］ｆｔ．ｔ１＜ｅ［ｊ］ｇ．ｔ０＜｛ｅ［ｊ］ｑ．ｔ１，ｅ［ｊ］ｆ．ｔ０）＜
（ｅ［ｊ］．ｔ４，（ｅ［ｊ］．ｔ２＜ｅ［ｊ］ｆ．ｔ５＜ｅ［ｊ］ｆ．ｔ６））
／／センサポート、Ｓｅ［ｊ］．ｇから信号を受信し、人を入園させる
｛Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）（ｅ［ｊ］ｆｔ．ｔ０））｝
／／カウンタのＣ．ｆ［ｊ］に信号を送信して入園する人について知らせる
［・→Ｅｔ［ｊ］．ｇＳ（ｅ［ｊ］ｇ．ｔ０∈ｔ（Ｅｔ［ｊ］．ｇ，０））］
／／信号をＣ．ｆ［ｊ］に配信し、Ｃ．ｆ［ｊ］を並列に起動
（［〈→Ｃ．ｆ［ｊ］Ｄ〉（ｅ［ｊ］ｇ．ｔ１∈ｔ（Ｅｔ［ｊ］．ｇ，１））］
｜｜→．．．→Ｃ．ｆ［ｊ］：ｔｒａｃｅ（ｅ［ｊ］ｇ．ｔ１＝ｃｆ［ｊ］．ｔ０））
／＊この時点で、Ｅｔ［ｊ］は非決定的検知、ＴＩＰ（Ｉ．３）の∃（ｐ）（Ｅｔ［ｊ］．ｇ｜Ｅｔ［ｊ］．ｆ）ｐ：ｉｔｉＲ？（）＊の実施を待つ。この検知が成功した時の結果を以下に示す。ケース（ｉ）：Ｃ．ｆ［ｊ］からＥｔ［ｊ］．ｇで信号を受信。これによって入場を許可し、同時にＣ．ｆ［ｊ］に以前に送信された信号をＥｔ［ｊ］．ｇに肯定応答＊／
（｛〈Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｇ．ｔ２∈ｔ（Ｃ．ｆ［ｊ］，１）））＊〉（ｅ［ｊ］ｇ．ｔ２）｝
［・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）（ｅ［ｊ］ｇ．ｔ２）］｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ（）〉（ｅ［ｊ］．ｔ１）｝
｜／＊ケース（ｉｉ）：Ｃ．ｇ［ｊ］から信号をＥｔ［ｊ］で受信。これによって入園を拒否。この時点で以前にＣ．ｆｊ］にＥｔ［ｊ］．ｇを通して送信した信号に対する肯定応答は受信されていない＊／
｛（Ｅｔ［ｊ］．ｆ：ｍＲ？（〈Ｅｔ［ｊ］．ｆＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｆ．ｔ０∈ｔ（Ｃ．ｆ［ｊ］，１）））＊〉（ｅ［ｊ］ｆ．ｔ０）｝
［・→Ｅｔ［ｊ］．ｆ：ｄｅｎｙＥｎｔｒｙ（）（ｅ［ｊ］ｆ．ｔ０）］｛〈¬Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ（）〉（ｅ［ｊ］．ｔ３）｝）
／／Ｅｔ［ｊ］．ｆはＣ．ｇ［ｊ］にそのポートからの信号の受信についての肯定応答を送信
［・→Ｅｔ［ｊ］．ｆＳ（ｅ［ｊ］ｆ．ｔ１∈ｔ（Ｅｔ［ｊ］．ｆ，０））］
／＊並列起動と応答によって信号を検知したＣ．ｇ［ｊ］に肯定応答信号を配信＊／
（［（→Ｃ．ｇ［ｊ］Ｄ）（ｅ［ｊ］ｆ．ｔ２＝ｃｇ［ｊ］．ｔ２∈ｔ（Ｅｔ［ｊ］．ｆ，１））］｜｜
→．．．→（〈Ｃｇ［ｊ］：ｍＲ？（〈Ｃ．ｇ［ｊ］Ｄ〉（ｅ［ｊ］ｆ．ｔ２＝ｃｇ［ｊ］．ｔ２））＊〉（ｃｇ［ｊ］．ｔ２）｝・→．．．・→）
／＊Ｅｔ［ｊ］．ｇは、以前に人の入園についてＳｅ［ｊ］によって知らされた時にＣ．ｆ［ｊ］に送信された信号Ｅｔ［ｊ］．ｇについてＣ．ｆ［ｊ］から肯定応答を受信＊／
Ｅｔ［ｊ］．ｇ：ｐＲ？（〈→Ｅｔ［ｊ］．ｇＤ〉（ｅ［ｊ］ｇ．ｔ３＝ｃｆ［ｊ］．ｔ５））＊〉（ｅ［ｊ］ｇ．ｔ３）））
／／最終的に、肯定応答をセンサポートＳｅ［ｊ］．ｇに返信
｛〈Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉（ｅ［ｊ］ｇ．ｔ３）｝
［・→Ｅｔ［ｊ］．ｆｔＳ（ｅ［ｊ］．ｔ１｜ｅ［ｊ］ｆ．ｔ５）］［〈→Ｓｅ［ｊ］．ｇＤ〉（ｅ［ｊ］．ｆｔ．ｔ６）］）］ （Ｉ．３７）
この実装の他のトレースは表ＩとＩＩのＥＣＴネットワークから推定できる。
付録ＩＩ
ＰＣの解法：ＴＩＰ、ＣＩＰ、ＡＬＬＥＯＰ、およびトレース
【０６０６】
ここで、実装の全てのセルクラスについてＣＩＰを定義することによって実装を説明する。この例ではそうすることが比較的都合がよい。また、これは実装を定義する異なるスタイルも示している。
【０６０７】
生産者のＣＩＰとＴＩＰ：
初期化後、各ポーリングサイクルにおいて、生産者Ｐ［ｊ］はその割り込みポート、Ｐ［ｊ］．ｉにおいて信号を探す。信号がＰ［ｊ］．ｉに存在すれは、Ｐ［ｊ］はその動作を終了する。そうでなければ、そのポートＰ［ｊ］．ｆのポーリングに進み、Ｐ［ｊ］．ｆで信号を検知するたびに新しい製品を作り、（ＩＩ．２）のＰ［ｊ］：ｔｉｐ（）で定義されているようにそれを卸売業者のポートＤ．ｇ［ｊ］に送出する。
【０６０８】
ｖｏｉｄＰｒｏｄｕｃｅｒ：：ＣＩＰ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉ：ｓ（）；ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｍｔｉａｌｉｚｅ＝ｆａｌｓｅ；｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛ｉ：ｍＲ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；ｉ：ｓ（）；｝
ｆ：ｍＲ？（）｛ｆ：ｔｉｐ（）；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝ （ＩＩ．１）
Ｐ［ｊ］．ｆ：ＴＩＰ（）＝［Ｐ［ｊ］．ｆ：ｍＲ？（）｛Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）；
Ｐ［ｊ］．ｆ．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝Ｐ［ｊ］．ｐｒｏｄｕｃｔ）；
Ｐ［ｊ］．ｆ：ｓ（）；｝｝］ （ＩＩ．２）
【０６０９】
定義：
∃（ｔ０＜ｔ１）｛〈Ｐ［ｊ］．ｆ：ｍＲ？（）〉（ｔ０）｝［・→Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）（ｔ０）］
｛∃（Ｐｒｏｄｕｃｔ ｐ）（Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝ｐ）（ｔ１）｝（ＩＩ．３）
【０６１０】
消費者のＣＩＰとＴＩＰ：
ｖｏｉｄＣｏｎｓｕｍｅｒ：：ＣＩＰ（）｛
／＊初期化中に、各消費者、Ｃ［ｊ］、０≦ｊ＜ｍは空のパッケージをそのポートｃ［ｊ］．ｇのｒｅａｄＭｅｍｏｒｙに書き込んで、新規の製品を要求するためにそれを卸売業者ポートＤ．ｆ［ｊ］に送信する。ただし、ｒｅａｄＭｅｍｏｒｙ内のパッケージは、Ｄ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内に受信される。そのｗｈｉｌｅループにおいて、Ｃ［ｊ］はその割り込みポート、Ｃ［ｊ］．ｉでメッセージを受信すると自身を終了する。そうでなければ、新規の製品をＣ［ｊ］．ｇを通して受け取り、製品を消費すると、他の新規の製品を要求するために、そのｒｅａｄＭｅｍｏｒｙ内の空のパッケージを卸売業者ポートＤ．ｆ［ｊ］に送る。卸売業者ＤはそのポートＤ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内で空のパッケージを受け取る。空のパッケージを受け取ると、Ｄは新しい製品を探し、それをＤ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のパッケージに入れ、Ｃ［ｊ］．ｇに送る。パッケージは製品を要求しまた受け取るために消費者によって繰り返し利用される＊／
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉ：ｐＲ？（）｛ｉ：ｓ（）｝；ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝．ｆａｌｓｅ；
ｇ．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）；ｇ：ｓ（）；｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛ｉ：ｍＲ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；ｉ：ｓ（）；｝
ｇ：ｍＲ？（）｛ｇ：ｔｉｐ（）；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅＯ；｝ （ＩＩ．４）
Ｃ［ｊ］．ｇ：ＴＩＰ（）＝［Ｃ［ｊ］．ｇ：ｍＲ？（）｛Ｃ［ｊ］：ｐｉｃｋＵｐ（）；
／＊ｓｔｏｐＰｏｌｌｉｎｇがｆａｌｓｅの時にだけ新規の製品に対する要求を送信＊／
（¬ｓｔｏｐＰｏｌｌｉｎｇ？（）＆Ｃ［ｊ］：ｕｓｅｄＵｐ？（）＊）｛Ｃ［ｊ］．ｇ：ｓ（）；｝｝］ （ＩＩ．５）
【０６１１】
定義：
［∃（ｔ０＜ｔ１）∃（Ｐｒｏｄｕｃｔｐ）｛〈Ｃ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐ〉（ｔ０）｝［・→Ｃ［ｊ］：ｐｉｃｋＵｐ（）（ｔ０）］
｛〈Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ＝ｐ＆Ｃ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ〉（ｔ１）｝］ （ＩＩ．６）
Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔはＣｏｎｓｕｍｅｒクラスにおいて定義された属性である。（ＩＩ．５）のＣ［ｊ］：ｕｓｅｄＵｐ？（）を設計者によって適切な態様でＣｏｎｓｕｍｅｒクラスにおいて定義しなければならない。
【０６１２】
卸売業者のＣＩＰとＴＩＰ：
ｖｏｉｄＤｉｓｔｒｉｂｕｔｏｒ：：ＣＩＰ（）｛／／ｎは生産者の数
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉ：ｐＲ？（）｛ｉ：ｓ（）；｝／／起動を確認
ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝．ｆａｌｓｅ；／／自身を初期化
ｇ：ｓ（）；／／全ての製品と消費者を起動、図１２のネットワークを参照
／＊そのポートＤ．ｇ［ｊ］、０≦ｊ＜ｎの各々のｒｅａｄＭｅｍｏｒｙ内に空のパッケージを書き込み、新規の製品を注文するためにそれを生産者Ｐ［ｊ］の機能ポート、Ｐ［ｊ］．ｆに送る。Ｐ［ｊ］はその空のパッケージをＰ［ｊ］．ｆのｗｒｉｔｅＭｅｍｏｒｙで受け取る。この注文を受け取ると、Ｐ［ｊ］は新規の製品を生産し、それをＰ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のパッケージに入れ、Ｄ．ｇ［ｊ］に送る＊／
ｆｏｒ（ｉｎｔｊ＝０；ｊ＜ｎ；ｊ＋＋；）｛
ｇ［ｊ］．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）；ｇ［ｊ］：ｓ（）；｝｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛
／＊割り込み信号を受信すると、終了信号を全ての消費者に送信し、ｓｔｏｐＰｏｌｌｉｎｇをｔｒｕｅに設定＊／
ｉ：ｍＲ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；ｇ：ｓ（）；ｉ：ｓ（）；｝
ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄ＝ｆａｌｓｅ；Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｃｌｅａｒ（）；
／＊消費者はそれらから要求を受信した順序でサービスを受ける＊／
ｆｏｒ（ｉｎｔ ｊ＝０；ｊ＜ｍ；ｊ＋＋）｛
ｆ［ｊ］：ｍＲ？（）｛Ｄ：ｓｏｒｔＩｎｔｏ（Ｄ．ｆ［ｊ］，Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ）；｝
ｆｏｒ（ｉｎｔｉ＝０；ｉ＜Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｓｉｚｅ（）；ｉ＋＋）｛
Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［ｉ］：ｔｉｐ（）；ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄ＝ｔｒｕｅ；｝
/*割り込み信号を受信しても、ｉ：ｍＲ？（）はｔｒｕｅのままである。この場合、ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄがｆａｌｓｅであれば、つまり、消費者が現在のポーリングサイクルでサービスを受けていない場合、全ての消費者と生産者から終了したという応答を受信した後で自身を終了する。サービスを受けた消費者が存在する場合、サービスを受ける消費者がいなくなるまでポーリングサイクルを繰り返す＊／
（ｓｔｏｐＰｏｌｌｉｎｇ？（）＆¬ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄ？（））｛
ｇ：ｐＲ？（）＊｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝｝｝｝ （ＩＩ．７）
Ｄ．ｆ［ｊ：０．．．ｍ−１］：ＴＩＰ（）＝［Ｄ．ｆ［ｊ］：ｍＲ？（）｛（∃ｋ（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊｛
Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）；
Ｄ．ｇ［ｋ］：ｓ（）；Ｄ．ｆ［ｊ］：ｓ（）；｝｝］ （ＩＩ．８）
【０６１３】
定義：
｛〈∃（ｘ）（ｘ＝Ｄ．ｇ［ｋ］：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ〉（ｔ０）｝［・→Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）（ｔ０）］
｛〈Ｄ．ｆ［ｊ］：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｘ＆Ｄ．ｇ［ｋ］：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ〉（ｔ１）｝ （ＩＩ．９）
【０６１４】
ＡＬＬＥＯＰ：以下のＡＬＬＥＯＰにおいて、便宜上、全ての割り込みポートのポーリング、メッセージパッシング、および終了プロセスを無視する。
【０６１５】
消費者Ｃ［ｊ：０．．．（ｍ−１）］ ＡＬＬＥＯＰ：
Ｃ［ｊ：０．．ｍ−１］：ＡＬＬＥＯＰ（）＝［Ｃ［ｊ］：ＩＮＩＴ−ＡＬＬＥＯＰ（）・→Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）］ （ＩＩ．１０）
Ｃ［ｊ］：ＩＮＩＴ−ＡＬＬＥＯＰ（）＝［Ｃ［ｊ］：ｉｎｉｔｉａｌｉｚｅ？（）｛
ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→Ｃ［ｊ］．ｇ．ｗｒ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）；
・→Ｃ［ｊ］．ｇＳ［ｔ（Ｃ［ｊ］．ｇ，０）］／／製品に対する要求を送信
→（〈Ｄ．ｆ［ｊ］Ｄ〉［ｔ（Ｃ［ｊ］．ｇ，１）］｜｜Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（））｝］ （ＩＩ．１１）
Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）＝［¬Ｃ［ｊ］：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｃ［ｊ］．ｇ：ＡＬＬＥＯＰ（）
・→Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）｝］ （ＩＩ．１２）
Ｃ［ｊ］．ｇ：ＡＬＬＥＯＰＯ＝［Ｃ［ｊ］．ｇ：ｍＲ？（〈Ｃ［ｊ］．ｇＤ〉［ｔ（Ｄ．ｆ［ｊ］，１）］）｛ｇ：ｐｉｃｋｕｐ（）
・→Ｃ［ｊ］：ｕｓｅｄＵｐ？（）＊｛ｇＳ［ｔ（Ｃ［ｊ］．ｇ，２）］
→（〈Ｄ．ｆ［ｊ］Ｄ〉［ｔ（Ｃ［ｊ］．ｇ，３）］｜｜Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（））｝｝］ （ＩＩ．１３）
【０６１６】
生産者Ｐ［ｊ：０．．．（ｎ−１）］ ＡＬＬＥＯＰ：
Ｐ［ｊ］：ＡＬＬＥＯＰ（．．．）＝［Ｐ［ｊ］：ＩＮＩＴ−ＡＬＬＥＯＰＯ・→Ｐ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）］ （ＩＩ．１４）
Ｐ［ｊ｝：ＩＮＩＴ−ＡＬＬＥＯＰ（）＝
［Ｐ［ｊ］：ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｍｔｉａｌｉｚｅ＝ｆａｌｓｅ｝］ （ＩＩＩ．１５）
Ｐ［ｊ］：Ｂ０ＤＹ−ＡＬＬＥＯＰ（）＝［¬Ｐ［ｊ］ＳｔｏｐＰｏｌｌｉｎｇ？（）｛Ｐ［ｊ］．ｆ：ＡＬＬＥＯＰ（）
・→Ｐ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）｝］ （ＩＩ．１６）
Ｐ［ｊ］．ｆ：ＡＬＬＥＯＰ（）＝
Ｐ［ｊ］．ｆ：ｍＲ？（〈Ｐ［ｊ］．ｆＤ〉［ｔ（Ｄ．ｇ［ｊ］，ｌ）］｜〈Ｐ［ｊ］．ｆＤ〉［（ｔ（Ｄ．ｇ［ｊ］，３）］）｛
・→Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）
・→Ｐ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝Ｐ［ｊ］．ｐｒｏｄｕｃｔ）
→Ｐ［ｊ］．ｆＳ［ｔ（Ｐ［ｊ］．ｆ，０）］
→（〈Ｄ．ｇ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｆ，１）］
｜｜Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（．．．））｝］ （ＩＩ．１７）
【０６１７】
卸売業者ＡＬＬＥＯＰ：
Ｄ：ＡＬＬＥＯＰ（．．．）＝［Ｄ：ＩＮＩＴ−ＡＬＬＥＯＰ（）・→Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（）］ （ＩＩ．１８）
Ｄ：ＩＮＩＴ−ＡＬＬＥＯＰ（）＝
［ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
／／新規の製品を生産者に注文。割り込みポートのメッセージ送信は無視されている
∀（ｊ）（０≦ｊ＜ｎ）｛・→Ｄ．ｇ［ｊ］．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）
・→Ｄ．ｇ［ｊ］Ｓ［ｔ（Ｄ．ｇ［ｊ］，Ｏ）］
→（〈Ｐ［ｊ］．ｆＤ〉［ｔ（Ｄ．ｇ［ｊ］，ｌ）］｜｜Ｐ［ｊ］：Ｂ０ＤＹ−ＡＬＬＥＯＰ（））｝｝］ （ＩＩ．１９）
Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（）＝
［¬Ｄ：ｓｔｏｐＰｏｌｌｉｎｇ｛
∀（ｊ）（０≦ｊ＜ｍ）｛Ｄ．ｆ［ｊ］：ｍＲ？（〈Ｄ．ｆ［ｊ］Ｄ〉［（ｔ（Ｃ［ｊ］．ｇ，ｌ）｜（ｔ（Ｃ［ｊ］．ｇ，３）］）｛
・→Ｄ：ｓｏｒｔＩｎｔｏ（Ｄ．ｆ［ｊ］，Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ）｝・→
（ｆｏｒ（ｊ＝０；ｊ＜ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｓｉｚｅ（）；ｊ＋＋））｛
ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［ｊ］：ｔｉｐ−ＡＬＬＥＯＰ（）｝
・→Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（）｝］ （ＩＩ．２０）
Ｄ．ｆ［ｊ］：ＡＬＬＥＯＰ（）＝［Ｄ．ｆ［ｊ］：ｍＲ？（〈Ｄ．ｆ［ｊ］Ｄ〉［（ｔ（Ｃ［ｊ］．ｇ，１）Ｉ（ｔ（Ｃ［ｊ］．ｇ，３）］）｛
Ｄ．ｆ［ｊ］：ｔｉｐ−ＡＬＬＥＯＰ（）｝］ （ＩＩ．２１）
Ｄ．ｆ［ｊ］：ｔｉｐ−ＡＬＬＥＯＰ（）＝
［（∃ｋ（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（〈Ｄ．ｇ［ｋ］Ｄ〉［ｔ（Ｐ［ｋ］．ｆ，１）］））＊｛
・→Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）
・→Ｄ．ｇ［ｋ］Ｓ［ｔ（Ｄ．ｇ［ｋ］，２）］
→（〈Ｐ［ｋ］．ｆＤ〉［ｔ（Ｄ．ｇ［ｋ］，３）］｜｜Ｐ［ｋ］：ＢＯＤＹ−ＡＬＬＥＯＰ（））
・→Ｄ．ｆ［ｊ］Ｓ［ｔ（Ｄ．ｆ［ｊ］，０）］
→（〈Ｃ［ｊ］．ｇＤ〉［ｔ（Ｄ．ｆ［ｊ］，１）］｜｜Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（））｝｝］ （ＩＩ．２２）
ＰＣの解法：ＡＬＬＥＯＰ（）＝
□［∃（〈ｐａｒｔｉａｌ−ｏｒｄｅｒｉｎｇ−ｏｆ−ｔｉｍｉｎｇ−ｆｕｎｃｔｉｏｎｓ〉］
∀（ｊ）（０≦ｊ＜ｍ）∀（ｋ）（０≦ｋ＜ｎ）（｜｜Ｃ［ｊ］：ＡＬＬＥＯＰ（）
｜｜Ｐ［ｋ］：ＡＬＬＥＯＰ（）｜｜Ｄ：ＡＬＬＥＯＰ（））］ （ＩＩ．２３）
【０６１８】
トレース：ここでトレースを示していないが、それは合成トレースがセクション６．３の表ＩＩＩに示しているＥＣＴネットワークに現れるからである。トレースによって提供されるすべての情報はＥＣＴネットワーク内にカプセル化されている。
付録ＩＩＩ
ＤＰの解法：ＣＩＰ、ＴＩＰ、ＡＬＬＥＯＰ、およびトレース
【０６１９】
Ｂｔｌｒ ＣＩＰとＴＩＰ：ＢｔｌｒはＢｕｔｌｅｒクラスを表しており、ｂｔｒｌはＢｔｒｌのインスタンスを表している。ここでも、割り込みポートサービスポーリング、割り込みメッセージ処理、開始／終了プロセスを無視する。
ｖｏｉｄ Ｂｔｌｒ：：ＣＩＰ（）｛ＩＮＩＴＯ；ＢＯＤＹ（）｝（ＩＩＩ．１）
ｖｏｉｄ Ｂｔｌｒ：：ＩＮＩＴ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔＵｐＴｂｌ（）；ｓｔｏｐＰｏｌｌｉｎｇ＝ｓｔｏｐＰｅｎｄｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝．ｆａｌｓｅ；
ｇ：ｓ（）；／／信号を全ての哲学者に彼らを起動するためにブロードキャスト｝
ｉ：ｓ（）；／／起動した割り込み信号の受信を確認応答｝（ＩＩＩ．２）
ｖｏｉｄＢｔｌｒ：：Ｂ０ＤＹ（）｛
ｗｈｉｌｅ（¬ｉｓｔｏｐＰｏｌｌｉｎｇ）｛
／／ｂｔｌｒ．ｆ［ｊ］：ＴＩＰ（）に指定されているように、そのｆｕｎｃｔｉｏｎａｌＰｏｒｔ、ｂｔｒｌ．ｆ［ｊ］をポーリングし、メッセージに応答
ｆｏｒ（ｉｎｔ ｊ＝０；ｊ＜５；ｊ＋＋；）｛ｂｔｌｒ．ｆ［ｊ］：ＴＩＰ（）；｝
／＊その環境から割り込み信号を割り込みポート、ｂｔｌｒ．ｉで受信すると終了。終了は、以下で説明するように、ｂｔｌｒ．ｉ：ＴＩＰ（）で指定されているように、フォークを待っている全ての哲学者にサービスを行った後でかつ全ての哲学者も終了した後で初めて発生＊／
ｂｔｌｒ．ｉ：ｍＲ？（）｛ｂｔｌｒ．ｉ：ＴＩＰ（）；｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅＯ；｝（ＩＩＩ．３）
Ｂｔｌｒ．ｆ［ｊ：０．．．４］：ＴＩＰ（）＝
［／／Ｐ［ｊ］．ｇからのメッセージを聞き、メッセージがあれば応答
ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）｛ｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ）；／／こればＢｔｌｒクラスで定義されているｐｔｈｒｅａｄ
／＊ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）＝ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄはｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ） ｐｔｈｒｅａｄ内で設定されている。ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅまたはｆａｌｓｅの場合にだけ応答。ｔｒｕｅの場合はメッセージを送信し、ｆａｌｓｅの場合にはメッセージを転送し、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φの場合は応答しない。＊／
ｂｔｌｒ．ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）｛ｆ［ｊ］：ｓ（）；｝ｅｌｓｅ｛ｆ［ｊ］：ｆ（）；｝］（ＩＩＩ．４）
【０６２０】
ｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ）の定義
ｖｏｉｄＢｔｌｒ：：ｒｅｓｐｏｎｓｅ（ｉｎｔｊ）｛／／このｐｔｈｒｅａｄはｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）がｔｒｕｅの場合にだけ実行される。
【０６２１】
｛ｓｅｌｅｃｔＯｎｅ｛
／＊ｂｔｌｒ．ｆ［ｊ］のｒｅａｄＭｅｍｏｒｙが空の場合、それは哲学者Ｐ［ｊ］がフォークを要求していることを意味している。フォークが利用可能な場合、フォークをｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のコンテナに梱包して、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅに設定する。これによって、（ＩＩＩ．３）のｂｔｌｒ．ｆ［ｊ］：ＴＩＰ（）のボディに定義されているように、ｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のメッセージが送出される。フォークが使用可能でない場合、ｂｔｌｒ．ｆｒｋ［ｊ］：ｒｓｒｖｄ＝ｔｒｕｅｎかつｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φに設定。この場合、メッセージは送信されない。Ｐ［ｊ］はフォークを待つ。フォークは最終的に利用可能になった時に次のポーリングサイクルで送られる。応答が送信されないため、ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）はフォークが送られるまで全ての続くポーリングサイクルでｔｒｕｅと評価される。
【０６２２】
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）｛ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）；
ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅ；｝
ｅｌｓｅ｛ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ＝ｔｒｕｅ；
ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φ；｝
／＊以下では、ｂｔｌｒ．ｆ［ｊ］のｒｅａｄＭｅｍｏｒｙは空ではない。Ｐ［ｊ］によって返却されるフォークを含むことになる。ｂｔｌｒはフォークをテーブルに戻し、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｆａｌｓｅと設定する。これによって、応答がｒｅａｄＭｅｍｏｒｙ内のからのコンテナと共にｂｔｌｒ．ｆ［ｊ］：ｔｉｐ（）によってＰ［ｊ］．ｇに転送される＊／
¬ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）；
ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝．ｆａｌｓｅ；｝｝（ＩＩＩ．５）
ｂｔｌｒ．ｉ：ＴＩＰ（）＝
［／＊ｂｔｒｌ．ｉに割り込みメッセージが存在する場合にだけ以下が実行される。ｂｔｌｒ．ｐｅｎｄｍｇｓｔｏｐ＝ｆａｌｓｅの場合、信号をｂｔｌｒ．ｇを通して全ての哲学者にブロードキャストする。これによって、哲学者にゲームを終了するように求める。この場合、ｂｔｔｌ．ｉの割り込み信号には応答しないが、代わりにｂｔｌｒ．ｐｅｎｄｍｇｓｔｏｐ＝ｔｒｕｅと設定し、ゲームに対して保留中の停止が存在していることを示し、即座に機能ポート、ｂｔｌｒ．ｆ［ｊ］のサービスに進む。応答が送信されていないので、ｂｔｌｒ．ｉ：ｍＲ？（）はｂｔｒｌの次のポーリングサイクルにおいてｔｒｕｅと評価され、その時点で、ｂｔｌｒ．ｐｅｎｄｍｇｓｔｏｐはｔｒｕｅである。これによって、以下のｅｌｓｅ節が実行される。このｅｌｓｅ節において、ｂｔｌｒは全ての哲学者から終了したことを示している応答の受信を待つ。この応答が受信されると、ｂｔｌｒはｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅと設定し、肯定応答をｂｔｌｒ．ｉを通して受信した割り込み信号に送信する。ゲームは次のポーリングサイクルで停止する＊／
ｂｔｌｒ．ｉ：ｍＲ？（）｛ｓｅｌｅｃｔＯｎｅ｛
¬ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ｛ｂｔｌｒ．ｇ：ｓ（）；ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｔｒｕｅ；｝
¬ｂｔｌｒ：ａｌｌＦｒｋｓＯｎＴｂｌ？（）｛ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｆａｌｓｅ；
ｂｔｌｒ．ｇ：ｍＲ？（）＊｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；
ｉ：ｓ（）；｝｝｝｝］ （ＩＩＩ．６）
ただし、ｂｔｌｒは割り込み信号が検知されたポーリングサイクルで保留中のサービス要求のある全ての哲学者のサービスを行う。全てのフォークがテーブル上にあり、終了した全ての哲学者から肯定応答を受信した後で初めてゲームを終了する。
【０６２３】
ｂｔｌｒ：ＢＯＤＹ（）のｗｈｉｌｅループのループ不変式は□（¬∀（ｊ）Ｗ（ｊ））であって、Ｗ（ｊ）は哲学者Ｐ［ｊ］がフォークを待っていることを意味している。∀（ｊ）Ｗ（ｊ）はデッドロック状態である。この状態にゲーム中に到達することはない。これに対する証明はセクション６．４に示している。以下で特徴付ける全てのアクションと条件はＢｔｌｒクラスで定義されている。全てのアクションについて実装をここでは示していない。それらの特徴付けを以下に示す。
【０６２４】
定義：Ｂｔｌｒアクションと条件の特徴付け。
□［ｂｔｌｒ．ｆｒｋ［ｊ］：ｒｓｒｖｄ？（）⇔ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ＝ｔｒｕｅ］ （ＩＩＩ．７）
□［ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）⇔（ｂｔｌｒ．ｆｒｋ［ｊ］：ｏｎＴｂｌ＆ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５ｌ］．ｏｎＴｂｌ＆
¬ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］．ｒｓｒｖｄ）］ （ＩＩＩ．８）
∃（ｔ０＜ｔ１）［／／ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）の特徴付け
｛〈ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）〉（ｔ０）｝［・→ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）（ｔ０）］
｛〈ｂｔｌｒ．ｆ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｂｔｌｒ．ｆｒｋ［ｊ］，ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］］＆
¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｏｎＴｂｌ＆¬ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］．ｏｎＴｂｌ＆
¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ〉（ｔ１）｝ （ＩＩＩ．９）
／／ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）の定義
｛〈ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｂｔｌｒ．ｆｒｋ［ｊ］，ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］］〉（ｔ０）｝
［・→ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）（ｔ０）］
｛〈ｂｔｌｒ．ｆｒｋ［ｊ］．ｏｎＴｂｌ＆ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］．ｏｎＴｂｌ＆
¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ）（ｔ１）Ｓｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝φ〉（ｔ１）｝ （ＩＩＩ．１０）
／／ｂｔｌｒ：ｒｐｌｎｓｈＦｄ（）の特徴付け
｛〈ｂｔｌｒ．ｆｏｏｄＣｏｎｔａｉｎｅｒ：ｅｍｐｔｙ？（）〉（ｔ０）｝［→ｂｔｌｒ：ｒｐｌｎｓｈＦｄ（）（ｔ０）］
｛（ｂｔｌｒ．ｆｏｏｄＣｏｎｔａｉｎｅｒ：ｆｕｌｌ？（）（ｔ１）｝ （ＩＩＩ．１１）
／／ｂｔｌｒ：ｓｔＵｐＴｂｌ（）の特徴付け
｛ｔｒｕｅ｝［→ｂｔｌｒ：ｓｔＵｐＴｂｌ（）（ｔ０）］
｛（∀（ｊ）（ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ（ｊ））ＳｆｏｏｄＣｏｎｔａｉｎｅｒ：ｆｕｌｌ？（））（ｔ１）｝］ （ＩＩＩ．１２）
【０６２５】
哲学者ＣＩＰとＴＩＰ：
ｖｏｉｄ Ｐ：：ＣＩＰ（）｛ＩＮＩＴＯ；ＢＯＤＹ（）；｝ （ＩＩＩ．１３）
ｖｏｉｄ Ｐ：：ＩＮＩＴ（）｛
／／Ｐ［ｊ］．ｇのｗｒｉｔｅＭｅｍｏｒｙは空のまま。パッケージの空のインスタンスがｒｅａｄＭｅｍｏｒｙにインストールされる。
【０６２６】
ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ；ｈａｓｆｏｒｋｓ＝φ；
ｉ：ｓ（）；ｇ．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔａｉｎｓ＝φ｝｝ （ＩＩＩ．１４）
ｖｏｉｄ Ｐ：：ＢＯＤＹ（）｛
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛／／Ｐが思索をやめると空腹が始まる
Ｐ：ｔｈｉｎｋｉｎｇ（）；Ｐ．ｇ：ＴＩＰ（）；
／／割り込みの受信でゲームが停止し、そうでなければ思索に戻る
Ｐ．ｉ：ｍＲ？（）｛Ｐ．ｉ：ｓ（）；ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝（ ＩＩＩ．１５）
Ｐ．ｇ：ＴＩＰ（）＝／／空腹になって、Ｐ．ｇがメッセージの送信の準備ができていればフォークの要求を送信
［Ｐ：ｈｕｎｇｒｙ？（）｛Ｐ．ｇ：ｐＲ？（）＊｛Ｐ．ｇ：ｓ（）；
／＊フォーク要求をＰ．ｇを通して送信した後、フォークの到着を待ち、到着したらそれらを取り出し、食事を始める。食事後、フォークを梱包し、それらをｂｔｌｒに転送＊／
Ｐ．ｇ：ｍＲ？（）＊｛Ｐ．ｇ：ｐｉｃｋＵｐＦｒｋｓ（）；Ｐ：ｅａｔｉｎｇ（）；Ｐ．ｇ：ｐａｃｋＦｒｋｓ（）．ｆ（）；｝｝ （ＩＩＩ．１６）
【０６２７】
定義：哲学者のアクションと条件の特徴付け、０≦ｊ＜５：
∃（ｔ０＜ｔｉ＜ｔ１）［
／／ｐ［ｊ］．ｇ：ｐｉｃｋＵｐＦｏｒｋｓ（）の特徴付け
｛〈Ｐ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｆｒｋ［ｊ］，ｆｒｋ［ｊ（○＋）５１］］〉（ｔ０）｝
［・→Ｐ［ｊ］．ｇ：ｐｉｃｋＵｐＦｏｒｋｓ（）（ｔ０）］｛〈Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉（ｔ１）｝ （ＩＩＩ．１７）
／／Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）の定義
［Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）⇔Ｐ［ｊ］．ｈａｓＦｏｒｋｓ＝［ｂｔｌｒ．ｆｒｋ［ｊ］，ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］］）＆
Ｐ［ｊ］．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ）］ （ＩＩＩ．１８）
／／Ｐ［ｊ］：ｅａｔｉｎｇ（）の特徴付け
｛〈Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉ｔ０）｝［・→Ｐ［ｊ］：ｅａｔｉｎｇ（）（ｔ０）］
｛〈¬Ｐ［ｊ］：ｈｕｎｇｒｙ？＆Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉（ｔ１）｝ （ＩＩＩ．１９）
／／Ｐ［ｊ］：ｐａｃｋＦｒｋｓ（）の特徴付け
｛〈Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉（ｔ０）｝［・→Ｐ［ｊ］：ｐａｃｋＦｒｋｓ（）（ｔ０）］
｛〈Ｐ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｆｒｋ［ｊ］，ｆｒｋ［ｊ（○＋）５１］］＆
¬Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉ｔ１）｝ （ＩＩＩ．２０）
／／Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）の特徴付け
｛〈¬Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉ｔ０）｝［・→Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）（ｔ１）］
｛〈¬Ｐ［ｊ］：ｔｈｉｎｋｉｎｇＯＳＰ［ｊ］：ｈｕｎｇｒｙ？〉（ｔ２）｝ （ＩＩＩ．２１）
【０６２８】
ＡＬＬＥＯＰ：以下では、「｜」は選択肢を分離する。
Ｂｔｌｒ ＡＬＬＥＯＰ：
ｂｔｌｒ：ＡＬＬＥＯＰ（）＝［ｂｔｌｒ．ｉｎｉｔ：ＡＬＬＥＯＰ（）・→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）］ （ＩＩＩ．２２）
ｂｔｌｒ．ｉｎｉｔ：ＡＬＬＥＯＰ（）＝／／Ｅはｂｔｌｒを開始する環境セルである
［ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔＵｐＴｂｌ（）／／表の設定
・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｓｔｏｐＰｅｎｄｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→ｇｓ［ｔ（ｂｔｌｒ．ｇ，０）］／／全ての哲学者を開始
→（∀（ｊ）（０≦ｊ＜５）（〈Ｐ［ｊ］．ｉＤ〉［ｔ（ｂｔｌｒ．ｇ，１）］｜｜→．．．→Ｐ［ｊ］．ｉｎｉｔ：ＡＬＬＥＯＰ（））
・→ｂｔｌｒ．ｉＳ［ｔ（ｂｔｌｒ．ｉ，０）］
→（〈Ｅ．ｇＤ〉［ｔ（ｂｔｌｒ．ｉ，１）］｜｜→．．．→Ｅ．ｇ：ＡＬＬＥＯＰ（））｝
・→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）］ （ＩＩＩ．２３）
ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）＝
［（¬ｓｔｏｐＰｏｌｌｉｎｇ？（）｛∀（ｊ）（０≦ｊ＜５）［ｂｔｌｒ．ｆ［ｊ］：ＡＬＬＥＯＰ（）］・→ｂｔｌｒ．ｉ：ＡＬＬＥＯＰ（）］
・→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）｝｜
ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝］ （ＩＩＩ．２４）
ｂｔｌｒ：ｆ［ｊ：０．．．４］：ＡＬＬＥＯＰ（）＝
／＊信号がなければ次のポートのポーリングをスキップし、そうでなければ以下を実行。この選択肢は通常指定されていない。ここでは仮定されている。＊／
［¬ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）｛ｂｔｌｒ：ｆ［ｊ（○＋）５１］：ＡＬＬＥＯＰ（）｝
｜
／＊時刻ｔ（Ｐ［ｊ］．ｆ，１）に受信されたメッセージはフォークの要求である。この場合ｒｅａｄＭｅｍｏｒｙは空である。時刻ｔ（Ｐ［ｊ］．ｆ，３）に受信されたメッセージはＰ［ｊ］によって返却されたフォークをｒｅａｄＭｅｍｏｒｙに含んでいる。Ｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ）はこれらのメッセージを次のＡＬＬＥＯＰに記述されているように処理し、ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）をｔｒｕｅ、ｆａｌｓｅ、またはφに設定する。＊／
ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（〈ｂｔｌｒ．ｆ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｆ，１）｜ｔ（Ｐ［ｊ］．ｆ，３）］）｛
・→ｂｔｌｒ：ｒｅｓｐｏｎｓｅＡＬＬＥＯＰ（ｊ）
・→（ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）｛ｆ［ｊ］Ｓ［ｔ（ｂｔｌｒ．ｆ［ｊ］，０）］
（〈Ｐ［ｊ］．ｇＤ〉［ｂｔｌｒ．ｆ［ｊ］，Ｉ）］
｜｜→．．．→Ｐ［ｊ］．ｇ：ＡＬＬＥＯＰ（））｝
｜
¬ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）｛ｆ［ｊ］Ｆ［ｔ（ｂｔｌｒ．ｆ［ｊ］，０）］
（〈Ｐ［ｊ］．ｇＤ〉［ｂｔｌｒ．ｆ［ｊ］，１）］｜｜→．．．→Ｐ［ｊ］．ｇ：ＡＬＬＥＯＰ（））｝
｜
ｔｒｕｅ｛｝）｝｝
ｂｔｌｒ：ｆ［ｊ（○＋）５ｌ］：ＡＬＬＥＯＰ（）／／次のポートのポーリングに進む］（ＩＩＩ．２５）
ｂｔｌｒ：ｒｅｓｐｏｎｓｅＡＬＬＥＯＰ（ｊ：０．．．４）＝
／＊Ｐ［ｊ］．ｇからのメッセージが空の場合、Ｐ［ｊ］はフォークを要求している。この場合、フォークが利用可能な場合、フォークをｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のコンテナに梱包し、それをＰ［ｊ］．ｇに送信するために、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅと設定する。そうでなければ、左のフォーク、ｂｔｌｒ．ｆｒｋ［ｊ］を予約し、Ｐ［ｊ］．ｇにメッセージを返信しないために、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φを設定する。ただし、ｂｔｌｒの次のポーリングサイクルにおいて、ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）はｔｕｒｅと判定され、同じ応答アクティビティが繰り返されることになる。このアクティビティのサイクルはフォークが利用可能になって、Ｐ［ｊ］．ｇに送られるまで継続する。メッセージが空ではない場合、Ｐ［ｊ］．ｇはフォークを返却中である。この場合、フォークをテーブルに戻し、空のコンテナをＰ［ｊ］．ｇに転送するためにｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｆａｌｓｅと設定する＊／
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛／／
（ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）｛ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）・→ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅ；｝
｜
¬ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）｛ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ＝ｔｒｕｅ
・→ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φ；｝）｝
｜
¬ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）
・→ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝．ｆａｌｓｅ；｝）））］（ＩＩＩ．２６）
ｂｔｌｒ．ｉ：ＡＬＬＥＯＰ（）＝
／＊Ｅは執事を開始した環境セルである。Ｅ．ｇは割り込み信号をｂｔｌｒ．ｉに送信する。Ｅ．ｇ用ＡＬＬＥＯＰはここでは示していない。割り込み信号を検知すると、ｂｔｌｒ．ｐｅｎｄｍｇＳｔｏｐがｆａｌｓｅの場合、ｂｔｌｒはｔｒｕｅに設定し、信号はポート、ｂｔｌｒ．ｇから全ての哲学者の割り込みポートにブロードキャストされ食事が終わったことを忠告する。＊／
［ｂｔｌｒ．ｉ：ｍＲ？（〈ｂｔｌｒ．ｉＤ〉［ｔ（Ｅ．ｇ，３）］）｛
（¬ｂｔｌｒ：ｐｅｎｄｉｎｇＳｔｏｐ？（）｛ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｔｒｕｅ
・→ｇＳ［ｔ（ｂｔｌｒ．ｇ，２）］
∀（ｊ）（（０≦ｊ＜５）［〈→Ｐ［ｊ］．ｉＤ〉［ｂｔｌｒ．ｇ，３］
｜｜→．．．→Ｐ［ｊ］．ｉ：ＡＬＬＥＯＰ（））］｝
｜
／＊ｂｔｌｒ．ｐｅｎｄｍｇＳｔｏｐで全てのフォークがテーブル上にある場合、全ての哲学者からの応答を待つ。応答を受信すると、Ｅ．ｇからの割り込み信号の受信に肯定応答し、それから終了の準備をする。次のポーリングサイクルで終了する。ｂｔｌｒ：ｆｒｋｓＯｎＴｂｌ？（）は全ての哲学者が食事を終えてフォークを返却したことを示す。＊／
（ｂｔｌｒ：ｐｅｎｄｉｎｇＳｔｏｐ？（）Ｓｂｔｌｒ：ａｌｌＦｒｋｓＯｎＴｂｌ？（））｛
ｂｔｌｒ．ｇ：ｍＲ（）＊｛・→ｉＳ［ｔ（ｂｔｌｒ．ｉ，２）］
→（〈Ｅ．ｇＤ〉［ｔ（ｂｔｌｒ．ｉ，３）］｜｜→．．．→Ｅ．ｇ：ＡＬＬＥＯＰ（））｝
・→ｂｔｌｒ．ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ
・→ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｆａｌｓｅ｝）｝］ （ＩＩＩ．２７）
前述のように、ｂｔｌｒは全ての待っている哲学者がサービスを受けて全ての哲学者が食事を止めてフォークを返却した後で初めて動作を終了する。
【０６２９】
哲学者ＡＬＬＥＯＰ：
Ｐ［ｊ：０．．．４］：ＡＬＬＥＯＰ（）＝［Ｐ［ｊ］．ｉｎｉｔ：ＡＬＬＥＯＰＯ・→Ｐ［ｊ］．ｂｏｄｙ：ＡＬＬＥＯＰ（）］ （ＩＩＩ．２８）
Ｐ［ｊ：０．．．４］．ｉｎｉｔ：ＡＬＬＥＯＰ（）＝
［Ｐ［ｊ］：ｉｎｉｔｉａｌｉｚｅ？（）｛Ｐ［ｊ］．ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ→Ｐ［ｊ］．ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→Ｐ［ｊ］．ｈａｓＦｏｒｋｓ＝φ・→Ｐ［ｊ］．ｉｓ［ｔ（Ｐ［ｊ］．ｉ，０）］
→（〈ｂｔｌｒ．ｇＤ〉［Ｐ［ｊ］．ｉ，１）］｜｜→．．．→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（））｝
・→Ｐ［ｊ］．ｇ．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔａｉｎｓ＝φ）｝
・→Ｐ［ｊ］．ｂｏｄｙ：ＡＬＬＥＯＰＯ］ （ＩＩＩ．２９）
Ｐ［ｊ：０．．．４］．ｂｏｄｙ：ＡＬＬＥＯＰＯ＝
［（¬Ｐ［ｊ］：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｐ［ｊ］．ｇ：ＡＬＬＥＯＰ（）・→Ｐ［ｊ］．ｉ：ＡＬＬＥＯＰ（）｝
・→Ｐ［ｊ］．ｂｏｄｙ：ＡＬＬＥＯＰ（）｝｜
Ｐ［ｊ］：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝）］ （ＩＩＩ．３０）
Ｐ［ｊ：０．．．４］．ｇ：ＡＬＬＥＯＰＯ＝
［Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）・→
Ｐ［ｊ］：ｈｕｎｇｒｙ？（）｛Ｐ［ｊ］．ｇ：ｐＲ？（）＊｛Ｐ［ｊ］：ｇＳ［ｔ（Ｐ［ｊ］．ｇ，０）］
→（〈ｂｔｌｒ．ｆ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｇ，１）］｜｜→．．．→ｂｔｌｒ．ｆ［ｊ］：ＡＬＬＥＯＰＯ）
・→Ｐ［ｊ］．ｇ：ｍＲ？（）＊｛Ｐ［ｊ］．ｇ：ｐｉｃｋＵｐＦｏｒｋｓ（）・→Ｐ［ｊ］：ｅａｔｉｎｇ（）
／＊食事後、フォークをＰ［ｊ］．ｇのｒｅａｄＭｅｍｏｒｙ内のコンテナに梱包し、それをｂｔｌｒ．ｆ［ｊ］に転送する。＊／
・→Ｐ［ｊ］．ｇ：ｐａｃｋＦｒｋｓ（）
・→Ｐ［ｊ］．ｇＦ［ｔ（Ｐ［ｊ］．ｇ，２）］
→（〈ｂｔｌｒ．ｆ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｇ，３）］
｜｜→．．．→ｂｔｌｒ．ｆ［ｊ］：ＡＬＬＥＯＰ（））｝｝］ （ＩＩＩ．３１）
Ｐ［ｊ］．ｉ：ＡＬＬＥＯＰ（）＝
／＊（Ｉ．３０）において、Ｐ［ｊ］は食事を終えてフォークを返却した後で初めて割り込みポートをポーリングする。＊／
［Ｐ［ｊ］．ｉ：ｍＲ？（〈Ｐ［ｊ］．ｉＤ〉［ｔ（ｂｔｌｒ．ｇ，３）］）｛ｉＳ［ｔ（Ｐ［ｊ］．ｉ，２）］
→（ｂｔｌｒ．ｇＤ［ｔ（Ｐ［ｊ］．ｉ，３）］｜｜ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（））
・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ｝］ （ＩＩＩ．３２）
待っている哲学者は食事を終えた後で初めて終了信号に応答する。したがって、ゲームが終了する前に、各哲学者は満足していることになる。
【０６３０】
ポーリングサイクル：
ｂｔｌｒ：Ｐｏｌｌｉｎｇ（）＝［ｂｔｌｒ．ｆ［０］：ｍＲ？（）→ｂｔｌｒ．ｆ［１］：ｍＲ？（）→ｂｔｌｒ．ｆ［２］：ｍＲ？（）
→ｂｔｌｒ．ｆ［３］：ｍＲ？（）→ｂｔｌｒ．ｆ［４］：ｍＲ？（）→ｂｔｌｒ．ｉ：ｍＲ？（）
→ｂｔｌｒ：Ｐｏｌｌｉｎｇ（）］ （ＩＩＩ．３３）
Ｐ［ｊ：０．．．４］：Ｐｏｌｌｉｎｇ（）＝［Ｐ［ｊ］．ｇ：ｐＲ（）＊→Ｐ［ｊ］．ｉ：ｍＲ？（）→Ｐ［ｊ］：Ｐｏｌｌｉｎｇ（）］ （ＩＩＩ．３４）
【０６３１】
区別されている述語と初期状態：
区別されている述語の集合は、ＴＩＰ用のＥＴＣ評価が始まる前に初期状態の指定に使用される。一般的に、区別されている述語にはＴＩＰの選択点において行われる選択を決める条件が含まれる。したがって、任意の非標準ガードと仮想メモリ内のメッセージのステータスがこの集合に含まれる。例えば、この例においては、機能ポートでのサービス要求が次のＴＩＰが始まる前に応答されない場合、任意の非標準ガードと仮想メモリ内のメッセージのステータスがこの集合に含まれる。ＥＣＴのシンボリック評価の規則は、選択点において選択を決める述語が初期状態またはＥＣＴ評価で以前に使用された述語内で指定されていない場合、その選択点から始まる全ての因果チェーンを可能性のある選択肢としてシンボリック評価内に含めなければならない。
【０６３２】
ＤＰ解法については、区別されている述語には以下の条件が含まれる。
【０６３３】
ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ），Ｅ［ｊ］，Ｔ［ｊ］ａｎｄＷ［ｊ］，ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）および
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）、０≦ｊ＜５． （ＩＩＩ．３５）
哲学者の状態Ｔ［ｊ］、Ｗ「ｊ」およびＥ［ｊ］はセクション６．４で定義される。ゲームの公理と初期状態もここで定義する。セクション６．４で示している証明にはＰ［ｊ］．ｇ：ｔｒａｃｅ（ｐ［ｊ］．ｇ．ｔ０）およびｂｔｌｒ．ｆ［ｊ］：ｔｒａｃｅ（ｂｆ［ｊ］．ｔ０）だけが必要である。これらのトレースから導出されたＥＣＴネットワークをセクション６．４の表ＩＶとＶに示している。便利さとわかりやすさために、互いに追従している、つまり並列起動によって互いに起動するネットワークを読みやすいブロックに分割している。読者は、各ＥＣＴブロックにおいて、アクションに対して定義されている事前と事後の条件がブロック内に含まれていることがわかる。証明に必要な情報がこれらの２つの表から選択される。
【０６３４】
これで、ＤＰ解法の実装と定義が完了する。請求項を示す前に、請求項がよりわかりやすくなるように、請求項で使用されるいくつかの用語を定義する。
【０６３５】
マルチコアチップ用の形式的検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ Ｖ．Ｓｒｉｎｉｖａｓａｎ、顧客番号：３３６４１
優先出願番号：６１／１９５，９６５、優先日：２００８年１０月１４日
電話：７７２３３７１３８８、ファックス：７７２３３７１３９９、携帯電話：７７２２８６６４６３、電子メール：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
特許請求の範囲に対する前文
特許請求の範囲の詳述に使用される名前、属性、データ、メソッド、条件、抽象的、詳細化、実行（ｒｕｎ）、アクション、イベントおよび通信イベントという用語は、この前文において定義されている：
（ｉ）名前は所与のアルファベット記号の任意の有限の文字列である。
（ｉｉ）データは値を表すために通常使用される２進数ビット０と１の任意の有限の文字列である。
（ｉｉｉ）属性は、オブジェクトインスタンスｘの特性を定義するために使用される任意の名前で、ｘ．属性はオブジェクトｘのその属性の値を参照するために使用され、ｘ．属性はオブジェクトインスタンスｘのクラスＸにおいて定義される。
(ｉｖ)メソッドはｘ：名前（〈引数〉）の形態であって〈引数〉はオプションで、各メソッドはコンピュータプログラムであって、メソッドｘ：名前（〈引数〉）に対するコンピュータプログラムは、オブジェクトインスタンスｘのクラスＸにおいて定義される。メソッドはそれに対してコンピュータプログラムが定義されていない場合に抽象的である。
(ｖ)条件は引数のないｘ：名前？（）の形態であって、各条件はコンピュータプログラムであって、メソッドｘ：名前？（）に対するコンピュータプログラムは、オブジェクトインスタンスｘのクラスＸにおいて定義される。条件の評価は、真理値、ｔｒｕｅまたはｆａｌｓｅ、あるいは真理値、ｔｒｕｅ、ｆａｌｓｅ、または未知を返すことになる。条件はそれに対してコンピュータプログラムが定義されていない場合に抽象的である。
（ｖｉ）抽象的：ソフトウェアコンポーネントは抽象的なメソッドおよび／または条件を含んでいる場合に抽象的である。
（ｖｉｉ）詳細化：ソフトウェアコンポーネントにおける抽象的なメソッドと条件とに対してコンピュータプログラムを定義することは、そのソフトウェアコンポーネントの詳細化と呼ばれる。ソフトウェアコンポーネントにおいてコンピュータプログラムが全てのメソッドと条件とに対して定義されている場合、そのソフトウェアコンポーネントは完全に詳細化される。
（ｖｉｉ）実行（ｒｕｎ）：アプリケーションＡに対する完全に詳細化されている並列コンピュータプログラムの実行は、Ａの実行（ｒｕｎ）と呼ばれ、Ａ内の各並列コンピュータプログラムは別個の専用ＣＰＵ（ＣｏｍＰｕｔｉｎｇＵｎｉｔ）によって実行され、Ａが実行（ｒｕｎ）されている間にＡ内の並列コンピュータプログラムはメッセージ交換を通して互いに相互動作し、これはＡ内の並列プログラム内の相互動作の唯一のモードである。
(ｉｘ）アクションイベント：アクションイベントは（名前、ｔ）の形態であって、アクションイベントは、プログラミング言語におけるステートメントの実行またはメソッドまたは条件の実行に起因し、名前はその実行に起因するイベントの名前であって、ｔはそのイベントの発生の時刻である。
（ｘ）通信イベント：通信イベントは形態（名前Ｓ、ｔ）、（名前Ｄ、ｔ）、または（名前Ｆ、ｔ）（「Ｓ」は「Ｓｅｎｄ（送信）」、「Ｄ」は「Ｄｅｌｉｖｅｒ（配信）」、「Ｆ」は「Ｆｏｒｗａｒｄ（転送）」を表し）の形態であって、通信イベントの発生はＴＩＣＣ−Ｐｐｄｅプログラミング言語における通信ステートメントの実行に起因し、名前は通信において交換されるメッセージを送信／受信、または転送するセルに付属しているポートの名前であって、ｔはその通信イベントの発生の時間である。
【図１】
0005704459.tif 000028
【図２】
0005704459.tif 000029
【図３】
0005704459.tif 000030
【図４】
0005704459.tif 000031
【図５】
0005704459.tif 000032
【図６】
0005704459.tif 000033
【図７】
0005704459.tif 000034
【図８】
0005704459.tif 000035
【図９】
0005704459.tif 000036
【図１０】
0005704459.tif 000037
【図１１】
0005704459.tif 000038
【図１２】
0005704459.tif 000039
【図１３】
0005704459.tif 000040
【図１４】
0005704459.tif 000041
【図１５】
0005704459.tif 000042
【図１６】
0005704459.tif 000043
【図１７】
0005704459.tif 000044
【図１８】
0005704459.tif 000045
【図１９】
0005704459.tif 000046
【図２０−２１】
0005704459.tif 000047
【図２２】
0005704459.tif 000048
【図２３】
0005704459.tif 000049
【図２４】
0005704459.tif 000050