(57)【要約】  本発明は、分散および共有メモリマルチコアチップ内で効果的に実行（ｒｕｎ）される正式に検証された超並列プログラムを実装する方法を教示する。それはセルと呼ばれる並列ソフトウェアコンポーネント間の相互動作の初期のアブストラクトなステートメントからのプログラムの開発とそれらの最終的な実装への漸進的なリファインとを可能にする。リファインの各段階において、計算におけるイベントのパターンの正式な記述が実装から自動的に導出される。この正式な記述は２つの目的に使用される。１つ目は正しさ、タイミング、プログレス、排他、デッドロック／ライブロックが無いことなどを証明することである。２つ目は性能、保留中のエラー、および重要な振る舞いのパターンを識別し報告するために、自動的に各アプリケーションにそのタイミングに干渉せずにアプリケーションを並列に常に監視する自己監視システム（ＳＭＳ）を組み込むことである。本発明は、メモリ干渉を最小にし、データを保護し、実行効率を高くする、マルチプロセッサ用に共有メモリを構成する方法も教示する。【選択図】なし【特許請求の範囲】
【請求項１】
発明者Ｃｈｉｔｏｏｒ  Ｖ．Ｓｒｉｎｉｖａｓａｎの米国特許第７，２１０，１４５Ｂ２号、ＴＩＣＣＴＭ、統合された計算と通信のための技術の修正されたバージョンに基づいているＴＩＣＣＴＭ−Ｐｐｄｅ、統合並列プログラム開発および実行プラットフォームの教示するメソッドは：
メソッド（１．１）、アプリケーションＡの並列コンピュータプログラムの実装用：ＴＩＣＣＴＭ−ＰｐｄｅはアプリケーションＡ用の並列コンピュータプログラムを実装するメソッドを提供し、セルと呼ばれるアブストラクトソフトウェア計算単位内の相互動作のアブストラクト仕様から始め、それらに関連付けられている全ての相互動作仕様と共に一式のセルは、Ａ：ＤＥＳＩＧＮ（）と呼ばれるアプリケーションＡの並列プログラムに対するアブストラクトデザインであって、最終的な完全にリファインされた実装となるまでセルとＡ：ＤＥＳＩＧＮ（）内の相互動作とを次第にリファインし、任意のリファインの段階におけるアプリケーションＡ内の並列コンピュータプログラムはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）と呼ばれ、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の全てのセルに集合はＡ：ｃｅｌｌｓ（）と呼ばれ、Ａ：ｃｅｌｌｓ（）内の各セルはメッセージ交換を通してのみ他のセルと相互動作し、各セルは、自身の専用ハードウェアＣＰＵ（ハードウェアＣｏｍＰｕｔｉｎｇ  Ｕｎｉｔ）内で実行（ｒｕｎ）されており、このＣＰＵはＡ：ｃｅｌｌｓ（）内の他のどのようなセルとも共有されておらず、
メソッド（１．２）、ＴＩＣＣＴＭ−Ｐｐｄｅに固有のメッセージ交換用：ＴＩＣＣＴＭ並列プログラムパラダイムと全ての他の並列プログラミングパラダイムとの違いは、ＴＩＣＣＴＭ−ＰｐｄｅがＡ：ｃｅｌｌｓ（）の間の点対点とグループ対グループの通信を管理する方法であって、各セル自体が、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内で同時に発生する他のそのようなメッセージ交換と並列に、計算したメッセージをその意図した目的セルに配信できるようにし、高々２、３百ナノ秒程度の正確に予測可能なレイテンシによって意図した宛先にメッセージ配信を可能にし、２ギガヘルツＣＰＵを仮定し、メッセージスケジューリングまたは同期セッションを必要とせず、
メソッド（１．３）、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の正式な確認用：Ａ：ＤＥＳＩＧＮ（）段間を含むリファインの各段階で、ＴＩＣＣＴＭ−Ｐｐｄｅは、リファインのその段階まで、自動的にイベントベースの計算のモデルを生成し、このモデルは、ＡＬＬＥＯＰｓ（ＡＬＬｏｗｅｄＥｖｅｎｔＯｃｃｕｒｒｅｎｃｅＰａｔｔｅｒｎｓ）と呼ばれ、Ａ：ＤＥＳＩＧＮ（）のＡＬＬＥＯＰｓはＡ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）と呼ばれ、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）用のＡＬＬＥＯＰｓはＡ：ＡＬＬＥＯＰＳ（）と呼ばれ、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）とＡ：ＡＬＬＥＯＰＳ（）とを使用して、正式な検証によってリファインの任意の段階において設計と実装とを確認し、正式な検証用の確認基準は、因果時間論理（ＣＴＬ）言語で表明としてユーザによって指定されており、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）またはＡ：ＡＬＬＥＯＰＳ（）を使用してユーザによるＣＴＬ表明の有効性の証明を探索し、証明の探索中にユーザと対話し、ユーザは必要な場合、証明探索を導くために追加のＣＴＬ表明を提供し、
メソッド（１．４）、ＴＩＣＣＴＭ−ＰｐｄｅＳＭＳ（自己監視システム）を使用した自動自己監視によって完全にリファインされたＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の実行（ｒｕｎ）用：Ａ：ＡＬＬＥＯＰＳ（）は、その生涯時間を通して、アプリケーションＡと並列にＡが実行（ｒｕｎ）されている間に、正しい動作のために、完全にリファインされているＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の自動動的監視用のＴＩＣＣＴＭ−Ｐｐｄｅによっても使用され、アプリケーションＡ内で計算イベントのタイミングへの干渉がほとんどまたは全く無く、エラー、保留中エラー、および事前に定義されたアラートイベントパターンの発生を識別して報告し、ＴＩＣＣＴＭ−Ｐｐｄｅの通信機構内に組み込まれているこの動的監視はＳＭＳ（自己監視システム）自動的に実施され、
メソッド（１．５）、任意のスケーラブルなＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の超並列マルチコンピュータハードウェアシステムにおける実行（ｒｕｎ）用：任意の多数のＣＰＵ（ハードウェア計算ユニット）において、８０％から１００％の範囲の効率でスケーラブルなＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を実行（ｒｕｎ）し、そのようなＣＰＵは、
（ｉ）３２以上のＣＰＵを備えている任意のＳＭＰ（共有メモリマルチプロセッサ）におけるＣＰＵであって、ＳＭＰ内のＣＰＵはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内に実装されているＴＩＣＣＴＭ−Ｐｐｄｅのソフトウェア共有メモリ通信経路（ｓｍ経路）を使用して互いに通信するＣＰＵか、
（ｉｉ）計算ノードが３２以上のＣＰＵを備えているＳＭＰである任意のＤＭＰ（分散メモリマルチプロセッサ）内のＣＰＵであって、ＤＭＰ内のＳＭＰはＴＩＣＣＴＭ−Ｐｐｄｅのハードウェア分散メモリ通信経路（ｄｍ経路）を使用して互いに通信し、ｄｍ経路はＴＩＣＣＮＥＴＴＭと呼ばれるローカルエリアネットワーク内に埋め込まれているＣＰＵか、
（ｉｉｉ）３２以上のＣＰＵを含んでいるＳＭＰとして実装されている任意のマルチコアチップ内のＣＰＵであって、チップ内のすべてのＣＰＵは共通のメモリを共有しており、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内に実装されているソフトウェアｓｍ経路を通して互いに通信するＣＰＵか、
（ｉｖ）任意のしかし固定されている数のＳＭＰを含んでいるＤＭＰとして実装されているマルチコアＣＰＵ内のＣＰＵであって、各ＳＭＰは１６から６４のＣＰＵを含んでおり、各ＳＭＰは自身の共有メモリを備えており、チップ内の別個のＳＭＰは同様にチップに統合されているＴＩＣＣＮＥＴＴＭ内のｄｍ経路を使用して互いに通信するＣＰＵか、
（ｖ）ＳＣＧ（スーパーコンピューティンググリッド）内のＣＰＵであって、ＳＣＧ内の各計算ノードは、ＳＭＰまたはＤＭＰのいずれかであって、ＳＣＧは任意のしかし固定されている数のそのようなＳＭＰとＤＭＰとを含んでおり、ＳＣＧ内のＳＭＰとＤＭＰはローカルエリアＴＩＣＣＮＥＴＴＭ内のｄｍ経路によってＳＣＧ内に組み込まれているＣＰＵであって、
メソッド（１．６）、アブストラクトデザイン、連続リファイン、リファインの各段階での正式な検証による確認、およびＳＭＳを使用した自動ランタイム自己監視による同じ実装のメソッドを使用する組み込みＳＭＳ（自己監視システム）を備えている実時間サイバー物理並列ソフトウェアシステム用のスケーラブルなＣＰＰＳＳ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の構築用、
メソッド（１．７）、アブストラクトデザイン、連続リファイン、リファインの各段階での正式な検証による確認、およびＳＭＳを使用した自動ランタイム自己監視による同じ実装のメソッドを使用する組み込みＳＭＳ（自己監視システム）を備えている非同期ハードウェアシステムまたは埋め込みシステム用のスケーラブルなＡＨＳ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の構築用、である、メソッド。
【請求項２】
Ａ：ＤＥＳＩＧＮ（）を指定し、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋを構築する以下のメソッドをさらに有する請求項１に記載のメソッドであって、
メソッド（２．１）、Ａ：ＤＥＳＩＧＮ（）の指定用：Ａ：ＤＥＳＩＧＮ（）はＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の並列計算の制御構造のアブストラクト仕様であって、Ａ：ＤＥＳＩＧＮ（）はアプリケーションＡ内の全てのメッセージとＡによって実施される計算中に発生する可能性のあるアクションと通信イベントとの因果チェーンとの同期と調和とを非明示的に指定し、Ａ：ＤＥＳＩＧＮ（）は３つのアブストラクトソフトウェアコンポーネント（ｉ）、（ｉｉ）、および（ｉｉｉ）を有し、これらの３つのコンポーネントとＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内の経路とを以下に説明し、
（ｉ）Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）（以降ではネットワークと呼ぶ）はノードとブランチとを備えているグラフであって、ブランチはノードを相互接続しており、このグラフのノードはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のアブストラクトセルであって、このグラフのブランチはネットワーク内のセルに付属しているソフトウェア通信ポート（以降ではポートと呼ぶ）間を相互接続するアブストラクト通信経路（以降では経路と呼ぶ）であって、ネットワーク内の全てのセルの集合はＡ：ｃｅｌｌｓ（）と呼ばれ、ネットワーク内の全てのポートの集合はＡ：ｐｏｒｔｓ（）と呼ばれ、ネットワーク内の全ての経路の集合はＡ：ｐａｔｈｗａｙｓ（）と呼ばれ、Ａ：ｃｅｌｌｓ（）内の各セルは、Ａ：ｃｅｌｌｓ（）の全ての他のセルと並列に自身の割り当てられた各ハードウェアＣＰＵ（ＣｏｍＰｕｔｉｎｇＵｎｉｔ）内で実行（ｒｕｎ）されることを意図しており、ネットワーク内の各セルはセルに付属しているポートを通してポートに接続されている経路を介してネットワーク内の他のセルとメッセージを交換することによって通信を実施することを意図しており、セルが有することができるポートの数には制限が無いが、ポートは２つ以上のセルには付属せず、ネットワークのセルによっては、ネットワークが動作している環境からの入力を受け取り、この環境自体はネットワーク内で環境セルによって表されており、
（ｉｉ）Ａ：ｐａｔｈｗａｙｓ（）：経路はネットワーク内の異なるセルに付属しているソフトウェアポートを相互接続し、ポートはセルによって接続されている経路を通したメッセージの送受信に使用され、各ポートはポートの親セルと呼ばれる１つの一意のセルにだけ付属しおり、それによってＡ：ｃｅｌｌｓ（）内のセルからのポートの接続を防止し、各ポートは１つの経路にだけ接続されており、それによって並列メッセージ配信中のメッセージの干渉を防止し、多くのポートが同じ経路に接続されて、グループ対グループ通信を可能にし、経路に接続されている各ポートは個別のセルに付属しており、ポートグループは同じ経路に接続されている１つまたは２つ以上のポートのグループであって、同じセルに付属している２つのポートはポートグループ内には存在せず、共通のポートを含んでいる２つの別個のポートグループは存在せず、経路は経路に接続されているポートグループ内のグループ対グループ通信を可能にし、ポートグループはそのポートグループに接続されている自己ループ経路を介してメッセージをそれ自体に送信することが可能であって、そのようなグループ対グループメッセージ交換において、メッセージ送信ポートグループはポートグループ内のポートの親セルからの調和した結合メッセージをメッセージ受信ポートグループに常に送信し、メッセージ送信ポートグループからのそのような結合メッセージは常に調和しており、同時にメッセージ受信ポートグループに並列に配信されており、グループ対グループ通信におけるメッセージ転送のそのような調和と同期は経路内に埋め込まれているエージェントによって自動的に実施され、
（ｉｉｉ）Ａ：ＴＩＰＳ（）：セル間の相互動作はアブストラクトスレッド相互作用プリミティブ（ＴＩＰ）によって指定され、各ＴＩＰはセルがそのポートのいずれか１つに配信されたメッセージをどのように検知するのか、配信されたメッセージをどのように処理し応答するのかのアブストラクト仕様を提供し、ＴＩＰがＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内の他のセル上の計算を生成することが可能で、応答メッセージの計算と送信の前にこれらの他のセルから応答を収集し、Ａ：ｃｅｌｌｓ（）内の各セルの各ポートはそれに対して定義されているアブストラクトＴＩＰを有しており、あらゆる並列プログラムの実装に必要なのは５種類の異なるＴＩＰだけであって、セルによるそのポートのいずれか１つでのメッセージの検知は、セルにそのポートで定義されている完全にリファインされたＴＩＰを実行することによって確実に常にそのメッセージの処理と応答を行わせ、必要に応じてＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内の他の５〜６個のセル上に計算を展開し、応答メッセージを計算するためにＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内のセルから応答を収集し、セルの各ポートに配信される各メッセージはセルによって確実に検知され、セルによってそのセルのいずれか１つのポートで受信される各サービス要求メッセージはセルによって確実に応答が行われ、したがって、セルによって実施される計算はメッセージ受信によって駆動され、Ａ：ＤＥＳＩＧＮ（）内で定義されている全てのアブストラクトＴＩＰの集合はＡ：ＴＩＰＳ（）と呼ばれ、
（ｉｖ）計算はＣに付属しているポートで定義されているＴＩＰを循環的に実行することによって各セルＣによって実施され、ポートＣで定義されているＴＩＰはＣ：ＴＩＰＳ（）と呼ばれ、各セルで実施される循環計算はセル相互作用プロトコル（ＣＩＰ）によって同様にアブストラクト形態で指定され、セルＣに対して定義されたＣＩＰはＣ：ＣＩＰ（）と呼ばれ、Ａ：ＤＥＳＩＧＮ（）内のセルについて定義されている全てのＣＩＰの集合はＡ：ＣＩＰＳ（）と呼ばれ、この点までの全ての仕様はアブストラクトであって、アブストラクト仕様はＡ：ＤＥＳＩＧＮ（）内で使用されるメソッドと条件に対するプレースホルダを識別するだけであって、Ａ：ＤＥＳＩＧＮ（）はＡ：ｃｅｌｌｓ（）内のセルとアプリケーションＡの実行（ｒｕｎ）中にアプリケーションＡ内で発生する可能性のあるアクションと通信イベントとの因果チェーンと間のメッセージ交換の調和と同期とを明示的に指定し、
メソッド（２．３）、ｓｍ経路の構造：メッセージを配信する各ｓｍ経路（共有メモリ経路）Ｓは、Ｓに埋め込まれているｖｉｒｔｕａｌＭｅｍｏｒｙＭと呼ばれる独自のソフトウェアメモリコンポーネントを有しており、ｓｍ経路Ｓに埋め込まれているｖｉｒｔｕａｌＭｅｍｏｒｙＭはＳ．ｖＭと呼ばれ、２つの別個のｓｍ経路が同じｖｉｒｔｕａｌＭｅｍｏｒｙを使用することはなく、ｖｉｒｔｕａｌＭｅｍｏｒｙはｓｍ経路の定義中に宣言され、コンパイル時または実行（ｒｕｎ）時に実際のメモリがｖｉｒｔｕａｌＭｅｍｏｒｙに割り当てられ、Ｓ．ｖＭはＳに接続されている１つまたは２つ以上のポートのポートグループ内のポートに配信されたメッセージを保持し、Ｓ．ｖＭはＳに接続されているポートの親セルによって書き込まれたメッセージも保持し、さらに、Ｓ．ｖＭは、Ｓ．ｖＭ内でＳに接続されているポートの親セルによるメッセージを処理し、新しいメッセージをＳ．ｖＭに書き込むコンピュータプログラムコードを保持し、各Ｓ．ｖＭは付属しているソフトウェアエージェントを有しており、２つ以上のｖｉｒｔｕａｌＭｅｍｏｒｙに付属しているエージェントは存在せず、Ｓ．ｖＭに付属している全てのエージェントの集合はＳ．ａｇｅｎｔｓと呼ばれ、Ｓ．ａｇｅｎｔｓ内のエージェントはＳによって経路Ｓを介したメッセージ転送の経路設定、調和、および同期に使用され、メッセージのセキュリティを実施し、ＴＩＣＣＴＭ−ＰｐｄｅのＳＭＳ（自己監視システム）を実行（ｒｕｎ）する機構を駆動するために、各ポートはＳ．ｖＭに付属している１つの独自のエージェントに接続されることによってＳに接続されており、Ｓ．ａｇｅｎｔｓ内のいずれか１つのエージェントに接続されている全てのポートはポートグループｐＧを構成しており、ポートグループが１つのポートだけを含んでいることも可能で、ｐＧ内の別個のポートは別個のセルに付属しており、同じセルの２つのポートはポートグループ内には存在せず、別個のポートグループはＳ．ａｇｅｎｔｓ内の別個のエージェントに接続されており、Ｃ．ｐはセルＣに付属しているｐＧ内のポートであって、Ｃ．ｐに付属している経路ＳはＣｐ．ｐａｔｈｗａｙと呼ばれ、Ｃｐ．ｐａｔｈｗａｙ＝Ｓであって、Ｃ．ｐ．ｐａｔｈｗａｙのｖｉｒｔｕａｌＭｅｍｏｒｙＭはＣ．ｐ．ｖＭと呼ばれ、Ｃ．ｐ．ｖＭ＝Ｓ．ｖＭ＝ｐＧ．ｖＭであって、ｐＧ内の全てのポートはそれらに関連付けられている同じｖｉｒｔｕａｌＭｅｍｏｒｙを有しており、２つの経路が同じポートに接続されることは決して無く、同じセルに付属している２つのポートＣ．ｐとＣ．ｑとは、［Ｃ．ｐ、Ｃ．ｑ］がセルのポートベクトルと呼ばれるポートのベクトルに属していない限り、同じ経路に接続されることはなく、各ポートＣ．ｐは、親セルＣのみがｐＧ．ｖＭ＝Ｃ．ｐ．ｖＭ内のデータとメソッドへアクセスできるようにし、経路Ｓに接続されているポートの親セル以外のＡ：ｃｅｌｌｓ（）内の他のセルはＳ．ｖＭ内のデータとメソッドとにアクセスすることはできず、信号を交換する経路内のコンポーネントは互いに対してチューンされており、そのようなチューンよって、経路内の各コンポーネントは経路内の他のコンポーネントによって送信された信号を常に受信し、即座に応答する準備ができるようにし、それによってメッセージの転送が相当に高速化し、各ポートＣｐは接続が確立された時に自身に接続されているエージェントに対して自動的にチューンされ、Ｃ．ｐ．ｖＭに付属して、信号を交換しているエージェントも同時に互いにチューンされ、Ｃ．ｐがＣ．ｐ．ｖＭに付属しているエージェントに対してチューンされる時に、Ｃ．ｐとその親セルＣもＣ．ｐ．ｖＭに対してチューンされ、これらのチューンは経路がそのポートに接続された時に自動的に発生し、Ｓ：ｐｏｒｔｓ（）の和集合はＳに接続されている全てのポートの集合であって、Ｓ．ａｇｅｎｔｓ（）はＳ内の全てのエージェントの集合であって、Ｓ．ｖＭは経路Ｓのコンポーネントと呼ばれ、ｓｍ経路内の全てのコンポーネントはソフトウェアコンポーネントであって、２つのｓｍ経路はどのようなコンポーネントを共有することもなく、それによって同時の並列メッセージ転送中のメッセージの干渉を排除し、（発明を実施するための形態）の図２、１７、１９、および２３は、点対点、自己ループ、グループ対グループ、リング経路の例をそれぞれ示しており、（発明を実施するための形態）の図１と３とは、ｖｉｒｔｕａｌＭｅｍｏｒｙの無いｓｍ経路を示しており、そのようなｓｍ経路は信号だけ交換し、メッセージは交換せず、ＴＩＣＣＴＭ−Ｐｐｄｅはｓｍ経路をＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内にインストールし修正するメソッドを提供し、
メソッド（２．４）、ｄｍ経路の構造：ＴＩＣＣＮＥＴＴＭ内の０≦ｉ＜Ｎについてのｄｍ経路（分散メモリ経路）Ｄｉの構造を（図面の簡単な説明）の一覧内の図２４に示しており、ＤｉはＳＭＰ内のポートグループｐＧｉ０に接続されており、分散計算ネットワークのＳＭＰ［ｊ］、０≦ｊ＜ｎ、は、ｎ個のＳＭＰからなり、ＳＭＰ［ｊ］の添え字ｊは、ｊ＝ｆ（ｉ，０）と記述されるｐＧｉ０における下付き文字ｉと０の関数であって、したがって、ＳＭＰ［ｊ］はＳＭＰ［ｆ（ｉ，０）］と書かれ、経路Ｄｉは、ＳＭＰ［ｆ（ｉ，０）］のポートグループｐＧｉ０を、同じ分散計算ネットワークの他の別個のＳＭＰ、ＳＭＰ［ｆ（ｉ，ｋ）］、１≦ｋ＜ｍｉ＜ｎ、ｆ（ｉ，ｋ）≠ｆ（ｉ，０）の他のポートグループｐＧｉｋへ接続し、各ＳＭＰ、ＳＭＰ［ｆ（ｉ，ｋ）］、０≦ｊ＜ｍｉ、はｖｉｒｔｕａｌＭｅｍｏｒｙｐＧｉｋ．ｖｍをそのローカル共有メモリ内に有しており、ｄｍ経路Ｄｉ内の全てのｖｉｒｔｕａｌＭｅｍｏｒｙは、Ｄｉ.ｖｍｓと呼ばれ、ｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐＧｉｋ．ｖｍもＤｉ．ｖｍｓ［ｋ］と呼ばれ、Ｄｉ．ｖｍｓ＝｛Ｄｉ．ｖｍ［ｋ］｜０≦ｋ＜ｍｉ｝、各ｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｄｉ．ｖｍｓ［ｋ］に付属している２個のエージェントａ０［ｉ，ｋ］とａ１［ｉ，ｋ］とが存在し、ａ０［ｉ，ｋ］はソフトウェアエージェントであって、ａ１［ｉ，ｋ］はハードウェアエージェントであって、ｐＧｉｋ内のすべてのポートはソフトウェアエージェントａ０［ｉ，ｋ］に対してチューンされており、ａ１［ｉ，ｋ］はＤｉのハードウェア信号とデータ線に接続されており、ハードウェア信号とデータ線は前記図２４に示しているように全てのエージェントａｉ［ｉ，ｋ］、０≦ｊ＜ｍｉ、を相互接続し、ＳＭＰ［ｆ（ｉ，０）］の［ＰＧｉｏ⇔ａ０［ｉ，０］⇔ａ１［ｉ，０］］経路セグメントを全ての経路セグメント｛ａ１［ｉ，ｋ］⇔ａ０［ｉ，ｋ］⇔ｐＧｉｋ］｜１≦ｋ＜ｍｉ｝の集合にリンクし、セグメント［ＰＧｉ０⇔ａ０［ｉ，０］⇔ａ１［ｉ，０］］はメッセージ送信プローブと呼ばれ、セグメント｛［ａ１［ｉ，ｋ］⇔ａ０［ｉ，ｋ］⇔ｐＧｉｋ］｜１≦ｋ＜ｍｉ｝はメッセージ受信プローブと呼ばれ、各ＳＭＰはそれをＴＩＣＣＮＥＴＴＭに接続する複数のメッセージ送信とメッセージ受信のプローブを有し、結果としてｄｍ経路は以下のように記述され、
Ｄｉ＝［ｐＧｉ０⇔ａ０［ｉ，０］⇔ａ１［ｉ，Ｏ］⇔｛［ａ１［ｉ，ｋ］⇔ａ０［ｉ，ｋ］⇔ｐＧｉｋ］｜１≦ｋ＜ｍｉ｝］
ポートグループｐＧｉ０はプローブ［ＰＧｉ０⇔ａ０［ｉ，０］⇔ａ１［ｉ，０］］とａ１［ｉ，０］に接続されているハードウェア信号およびデータ線を通してメッセージを並列に｛ａ１［ｉ，ｋ］⇔ａ０［ｉ，ｋ］⇔ｐＧｉｋ］｜１≦ｋ＜ｍｉ｝内のメッセージ受信プローブ内のエージェントａ１［ｉ，ｋ］にブロードキャストし、メッセージ受信プローブはメッセージを各ポートグループｐＧｉｋに同時に配信し、ポートグループ｛ｐＧｉｋ｜１≦ｋ＜ｍｉ｝は多重化モードで１つずつ順番に応答メッセージをｐＧｉ０に返送し、コンポーネントを共有している２つのｄｍ経路は存在せず、数千ものそのような別個のｄｍ経路Ｄｉ、０≦ｉ＜ｎ＞１０００がＴＩＣＣＮＥＴＴＭ内に存在し、ＴＩＣＣＮＥＴＴＭはそのようなｄｍ経路を動的にインストールし、また取り除く機構を提供し、インストールされた各ｄｍ経路は取り除かれて、新しい経路がインストールされるまでＴＩＣＣＮＥＴＴＭ内に止まり、ＴＩＣＣＮＥＴＴＭ内の全てのｄｍ経路はメッセージを相互干渉無しに並列に同時に交換することが可能で、ＴＩＣＣＮＥＴＴＭは、５００ナノ秒プラス信号送信時間のオーダーのレイテンシで保証された高速の並列メッセージ配送を提供し、ＴＩＣＣＴＭ−Ｐｐｄｅはｄｍ経路をＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内にインストールし、インストールされた経路を取り除き、および／またはそれらを修正するメソッドを提供し、
アプリケーションＡ、全てのそのｓｍ経路およびｄｍ経路内の全てのエージェントの集合はＡ：ａｇｅｎｔｓ（）と呼ばれ、アプリケーションＡ内の全てのｖｉｒｔｕａｌＭｅｍｏｒｙの集合はＡ：ｖｉｒｔｕａｌＭｅｍｏｒｉｅｓ（）と呼ばれ、アプリケーションＡ内の全ての経路の集合はＡ：ｐａｔｈｗａｙｓ（）と呼ばれ、
メソッド（２．５）、ｖｉｒｔｕａｌＭｅｍｏｒｙの構造、各ｖｉｒｔｕａｌＭｅｍｏｒｙＭは４つのコンポーネント（ｉ）ｒｅａｄＭｅｍｏｒｙＭ．ｒｄ、（ｉｉ）ｗｒｉｔｅＭｅｍｏｒｙＭ．ｗｒ、（ｉｉｉ）ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙＭ．ｅｘ、および（ｉｖ）ｓｃｒａｔｃｈｐａｄＭ．ｓｃｐを有しており、ｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｐ．ｖＭ＝Ｍを備えているＣ．ｐ．経路については、Ｃｐ．ｒｄ＝Ｍ．ｒｄ、Ｃ．ｐ．ｗｒ＝Ｍ．ｗｒ、Ｃｐ．ｅｘ＝Ｍ．ｅｘ、Ｃ．ｐ．ｓｃｐ＝Ｍ．ｓｃｐであって、Ｃ．ｐ．ｒｄは、Ｃ．ｐ経路によってＣ．ｐに配信されたメッセージを読むためにＣ．ｐの親セルＣによって使用され、Ｃ．ｐ．ｗｒは新しいメッセージを書いてＣ．ｐ．経路を通して送信するためにＣによって使用され、Ｍの読み／書きメモリは、メッセージの配信前に切り替えられ、Ｃ．ｐ．ｅｘはＣ．ｐ．ｒｄとＣ．ｐ．ｗｒにおいてメッセージを処理し、メッセージをＣ．ｐ．ｗｒに書き込むメソッドを実行（ｒｕｎ）するためにＣによって使用され、別個の親セルＣｉとＣｊとに付属しているポートグループｐＧ内の任意の２つの別個のポートＣｉ．ｐとＣｊ．ｐについて、Ｃｉ．ｐ．ｖＭ＝Ｃｊ．ｐ．ｖＭ＝ｐＧ．ｖＭ＝Ｍであって、Ｍはポートグループ内の全てのポートの共通のｖｉｒｔｕａｌＭｅｍｏｒｙであって、Ｃｉ．Ｐ．ｓｃｐ＝Ｃｊ．ｐ．ｓｃｐ＝＝ｐＧ．ｓｃｐ＝Ｍ．ｓｃｐはｐＧのポートの親セルによって使用される共通のスクラッチパッドメモリであって、Ｍ．ｓｃｐは、それぞれの計算を調和させ結合応答を返送するために、Ｍ内のメッセージを並列に処理しながらデータを互いに交換するためにｐＧ内の全てのポートＣｉ．ｐの親セルＣｉによって使用され、ＭはＭ内に存在する全てのコンピュータプログラムコードに対する実行環境を提供し、ＴＩＣＣＴＭ−ＰｐｄｅはｖｉｒｔｕａｌＭｅｍｏｒｙを経路内にインストールし修正するメソッドを提供し、
メソッド（２．６）、ＣＣＰとプロトコル：Ａ：ｐｏｒｔｓ（）内の各ポートＣ．ｐと経路Ｃ．ｐ．ｐａｔｈｗａｙとはそれに対して定義されているＣ．ｐ．ｐｒｏｔｏｃｏｌと呼ばれるソフトウェアプロトコルを有しており、各Ｃ．ｐ．ｐｒｏｔｏｃｏｌは、（発明を実施するための形態）のセクション１．１で導入されるＣＣＰ（因果通信プリミティブ）と呼ばれるＴＩＣＣＴＭ−Ｐｐｄｅに固有の特別なプログラミングプリミティブの連結を含んでおり、各ＣＣＰはＸ：ｘ→Ｙの形態を有しており、ＸとＹとは経路内のセル、ポート、またはエージェントであって、ｘは開始または完了信号であって、ＣＣＰの連結はＸ：ｘ→Ｙ：ｙ→Ｚの形態を有しており、Ｘ、Ｙ，およびＺは、同じ経路内の全てのコンポーネントであって、ｘとｙは信号であって、各タイプの信号は、それに対して定義されているサブタイプを有することが可能で、Ｃ．ｐ．ｐｒｏｔｏｃｏｌにおけるＣＣＰの実行によってＣ．ｐ．ｐａｔｈｗａｙ内のコンポーネントが互いに信号を交換できるようになり、そのように交換された信号は、Ｃ．ｐ．ｐａｔｈｗａｙ上を進行して，最終的に文脈を構築し、前記コンテテキストはＣ．ｐ．ｖＭ内のメッセージが同じｓｍ経路内のＣ．ｐ．ｐａｔｈｗａｙに接続されている意図した受信ポートに配信されようにし、文脈はＣ．ｐ．ｖＭ内のメッセージをｄｍ経路内のハードウェア信号およびデータ線を介して意図した受信ポートグループのｖｉｒｔｕａｌＭｅｍｏｒｙに搬送し、プロトコル内に現れるＣＣＰは、（発明を実施するための形態）のセクション１、図３と４、およびセクション７のステートメント（７．１）から（７．４）で説明しているように、他のプログラミング言語のステートメント内に埋め込まれていることもあって、データ宣言を含んでいるＴＩＣＣＴＭ−Ｐｐｄｅのプロトコルは無く、それら全てはＣＣＰを含んでおり、Ｃ．ｐ．ｐｒｏｔｏｃｏｌは、ポートＣ．ｐの親セルＣによってのみ呼び出され実行され、ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムに使用される可能性のある全ての種類の経路を介してメッセージ交換のために予めパッケージされコンパイルされたプロトコルを提供し、実装者は、ＴＩＣＣＴＭ−Ｐｐｄｅで使用されているプロトコル定義フォーマットと整合した態様でアプリケーションＡで必要な可能性のある通常以外のプロトコルだけ定義する責任があり、ＴＩＣＣＴＭ−ＰｐｄｅはＣＣＰを使用してプロトコルを定義するメソッドを提供し、
メソッド（２．７）、経路内のコンポーネントのチューン用：Ｃ．ｐ．ｐａｔｈｗａｙ内のコンポーネントはセルＣの任意のポートＣ．ｐに接続されており、ｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｐ．ｖＭ内のメッセージを意図した受け手に搬送し、配信するために信号を交換し、Ｃ．ｐ．ｐａｔｈｗａｙ内のコンポーネントは常に互いに対してチューンされており、チューンによってＣ．ｐ．ｐａｔｈｗａｙ内のコンポーネントがＣ．ｐ．ｐａｔｈｗａｙ内の他のコンポーネントによって送信された信号を受け取り即座に応答する準備が常にできているようにし、チューンによって、信号交換中の同期セッションの必要性が無くなり、それによってメッセージ交換が相当に加速され、Ｃ．ｐ．ｐａｔｈｗａｙ内のコンポーネントに対するポートＣ．ｐのチューンは、Ｃ．ｐ．ｐａｔｈｗａｙがＣ．ｐに接続された時にＴＩＣＣＴＭ−Ｐｐｄｅ内で自動的に達成され、Ｃ．ｐ．ｐａｔｈｗａｙ内のコンポーネントに対するＣ．ｐのチューンによってＣ．ｐの親セルもＣ．ｐ．ｐａｔｈｗａｙの独自のｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｃ．ｐ．ｖＭに対してチューンされ、アプリケーションＡの実装を経路内のコンポーネントに対してチューンしたり、経路を介したメッセージや信号の交換のスケジュールや同期を行ったりする必要は無く、経路を介したメッセージ交換のスケジューリングはＴＩＰ実行中に自動的に実施され、経路コンポーネント間の信号交換のスケジューリングはプロトコル内のＣＣＰによって自動的に実施され、メッセージのディスパッチの調和とメッセージの配信の同期とは経路上のエージェントによって実施され、経路内のエージェントは、メッセージ送信中とメッセージのセキュリティを執行中に、ＴＩＣＣＴＭ−ＰｐｄｅのＳＭＳを駆動するために信号交換機構も管理し、（発明を実施するための形態）のセクション７で説明しているように、ＳＭＳを駆動するための全てのチューン、調和、同期、およびサポートは、ＴＩＣＣＴＭ−Ｐｐｄｅプロトコルの組み込み機能であって、これらの機能の全ては、経路がインストールされて自動的に、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）のそれらのそれぞれのポートに接続された時にＴＩＣＣＴＭ−Ｐｐｄｅによって自動的に有効にされ、実装者は、任意のアプリケーションの任意のインストールされた経路のこれらの機能のいずれも、実装したり、呼び出したり、実行するためには何もしなくてよく、ＴＩＣＣＴＭ−Ｐｐｄｅはアブストラクト経路内に経路コンポーネントをインストールして、これらのコンポーネントを互いに対してチューンするメソッドを提供し、
メソッド（２．８）、データ保護と並列バッファ用：ポートグループ内の各ポートＣ．ｐは、その親セルＣがそのｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｐ．ｖＭにアクセスし使用できるようにし、前記親セルがＣ．ｐに配信されたメッセージを検知したか、Ｃ．ｐがメッセージを送信する準備ができたことを検知した場合に限り、同じ親セルに付属しているポートベクトルＣ．ｐ＝[Ｃ．ｐ１、Ｃ．ｐ２、．．．Ｃ．ｐｎ]の複数のポートは、必要に応じて親セルＣの全てのｖｉｒｔｕａｌＭｅｍｏｒｉｅｓＣ．ｐ．ｖＭ、１≦ｉ＜ｎ、への同時のアクセスを可能にし、したがって、ポートはそのそれぞれの親セルが必要な時にだけｖｉｒｔｕａｌＭｅｍｏｒｙにアクセスできるようにし、経路に接続されているメッセージ送信ポートの親セルとメッセージ受信ポートの親セルとがその経路のｖｉｒｔｕａｌＭｅｍｏｒｙを同時に使用することは不可能であって、経路に接続されていない任意のポートのどの親セルもその経路のｖｉｒｔｕａｌＭｅｍｏｒｙにアクセスすることは不可能であって、それによってｖｉｒｔｕａｌＭｅｍｏｒｙ内のデータを不正なアクセスと使用から保護し、またｖｉｒｔｕａｌＭｅｍｏｒｙ内のデータの削除を防止し、データを各ｖｉｒｔｕａｌＭｅｍｏｒｙ内で前記データが意図したユーザに使用されるまで保持し、したがって、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のｖｉｒｔｕａｌＭｅｍｏｒｙは保護された並列バッファリングを実現し、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のすべての非同期並列通信をサポートし、１０メガバイトから１ギガバイトの範囲のサイズの独立しているハードウェア共有メモリモジュールを設計し、モジュールをコンパイルまたは実行（ｒｕｎ）時間中にｖｉｒｔｕａｌＭｅｍｏｒｙに動的に割り当てることが可能であって、セルのポートがその親セルがｖｉｒｔｕａｌＭｅｍｏｒｙにアクセスできるようにした時にだけ、実行（ｒｕｎ）しているＣＰＵを動的にｖｉｒｔｕａｌＭｅｍｏｒｙに接続し、そのようなメモリ構成によって、アプリケーション内の全てのデータとソフトウェアに対して本質的なセキュリティ、プライバシー、保護が実現され、プライバシーと保護はシステム内にシステムの最下位レベルにおいて組み込まれており、ＴＩＣＣＴＭ−Ｐｐｄｅは任意のアプリケーションにおいて自動データ保護のためのメソッドを提供し、
メソッド（２．９）、保証された高速並列通信：ソフトウェア内に実装されているＣＣＰは２ギガヘルツＣＰＵ内での実行に２５から５０ナノ秒かかり、ＣＰＵ内に機械命令としてＣＣＰを実装することが可能で、機械命令として実装されたＣＣＰは実行に約５ナノ秒しかかからず、ｓｍ経路を介した点対点通信には高々６つのＣＣＰの実行（ＳＭＳを駆動するエージェントを含む）しか必要なく、ｓｍ経路を介したグループ対グループ通信には、各ポートグループ内のポートの数に依存して、１４以上のＣＣＰ実行が必要であって、ｄｍ経路を介したグループ対グループ通信にはｄｍ経路に接続されているポートグループの数に依存して３０以上のＣＣＰ実行が必要であって、プロトコルの実行によってそのプロトコル自体において定義されていないデータ、プログラム、プロセス、スレッドが呼び出されることは一切無く、そのようなプロトコルの実行によって、そのプロトコルの経路内で既に定義されているデータのみが変更され、それ以外は変更されず、したがって、確かにオペレーティングシステムや他の任意の監視システムがいかなるプロトコルのいかなる部分もスケジュールしたり、同期したり、または実行することが無く、プロトコルの実行はその実行中に割り込まれることは決して無く、Ｃが送信するメッセージのＣ．ｐ．ｖＭへの書き込みが完了すると即座に、Ａ：ｐｏｒｔｓ（）の各ポートＣ．ｐでプロトコル全体、Ｃ．ｐ．ｐｒｏｔｏｃｏｌがＣ．ｐの親セルＣによってのみ割り込まれることなく実行され、メッセージ送信のそのような自動で即座のスケジューリング、信号を交換する経路内のコンポーネントの相互チューン、非同期通信における逐次バッファリングの必要性を無くすことによって、高々２、３百ナノ秒の程度のレイテンシでの非常に高速の保証された即座の非同期通信が可能になり、プロトコルが２ギガヘルツＣＰＵによって実行され、ＣＣＰが機械命令として実装されている場合、ｓｍ経路とｄｍ経路との両方が同時の非同期並列メッセージ転送を可能にし、アプリケーション内で同時に発生するそのような非同期並列メッセージ転送の数は、そのアプリケーションにインストールされている別個の経路の数によってのみ制限され、これらの数は、何十から何千またはそれ以上の範囲であって、ＴＩＣＣＴＭ−Ｐｐｄｅは保証された自動高速並列通信のためのメソッドを提供し、
メソッド（２．１０）、各ポートグループ内の他の１つまたは２つ以上のポートとのグループ対グループメッセージ交換の自動調和：ポートグループｐＧ内のポートＣｉ．ｐ、０≦ｉ＜ｎ≧０、は、他のポートグループｑＧ内の別個のポートＤｊ．ｑ、０≦ｊ＜ｍ≧０、に共通のグループ対グループ経路ｐＧ．ｐａｔｈｗａｙ≡ｑＧ．ｐａｔｈｗａｙによって接続されており、ｑＧ内のポートの全ての親セルＤの集合は、ｐＧ内のポートの全ての親セルの集合とは区別されるか、ｐＧ≡ｑＧがｔｒｕｅであるかのいずれかであって、各Ｃｉ．ｐ．ｐａｔｈｗａｙ、０≦ｉ＜ｎ、はｐＧ．ｐａｔｈｗａｙの一部であって、各Ｄｊ．ｑ．ｐａｔｈｗａｙ、０≦ｊ＜ｍ、はｑＧ．ｐａｔｈｗａｙ≡ｐＧ．ｐａｔｈｗａｙの一部であって、これらの経路は、（発明を実施するための形態）の図１９または１７に示している図または（図面の簡単な説明）の図２４に示している図と同様であって、ポートグループｐＧのｇｅｎｅｒａｌＰｏｒｔｓＣｉ．ｐのＣｉの親セルは、ｐＧ内のポートＤｊ．ｑへｐＧ．ｐａｔｈｗａｙを介して結合サービス要求メッセージ、ｍを送信するために、非同期に、そして互いに並列にプロトコルＣｉ．ｐ．ｐｒｏｔｏｃｏｌを実行し、同じグループ対グループｐＧ．ｐａｔｈｗａｙ上での親セルＣｉによるＣｉ．ｐ．ｐｒｏｔｏｃｏｌの同時の非同期並列実行をｐＧ．ｐａｔｈｗａｙ内のエージェントが自動的に調和させ、前記エージェントは、ｐＧのポートからｑＧの各ポートへの結合サービス要求メッセージｍの同時の同期した並列の１回だけの配信を保証し、前記エージェントはポートがメッセージに対する予め定められているセキュリティ条件を満たす場合にだけそのメッセージをそのポートに配信し、前記エージェントは、ＳＭＳ（自己監視システム）へ信号も送信して、ｐＧ．ｐａｔｈｗａｙを介して送信されたメッセージについてメッセージディスパッチおよびメッセージ配信イベントをＳＭＳ内にインストールするためにＳＭＳを起動し、グループ対グループプロトコルＣｉ．ｐ．ｐｒｏｔｏｃｏｌは、Ｃｉ．ｐがメッセージｍを送信した後にポートＣｉ．ｐを即座にロックし、それによってｐＧ内の各Ｃｉ．ｐが第２のサービス要求メッセージを送信するのを防止し、ｐＧ内の各Ｃｉ．ｐは、Ｃｉ．ｐがｐＧ内の全てのＤｊ．ｑからサービス要求メッセージ、ｍに対して結合応答メッセージ、ｍ’を受信した後で初めて第２のサービス要求メッセージを送信することが可能で、各Ｃｉは、Ｃｉが第２のサービス要求メッセージを送信可能になる前に、Ｃｉ．ｐにおけるｍ’の受信を検出することがさらに必要であって、ｍ’は、Ｄｊ．ｑがメッセージｍを受信したのと同じグループ対グループ経路、ｑＧ．ｐａｔｈｗａｙ≡ｐＧ．ｐａｔｈｗａｙを介してｐＧ内のＤｊ．ｑによって常に返送され、したがって、ＴＩＣＣＴＭ−Ｐｐｄｅはグループ対グループメッセージ交換の自動調和のためのメソッドを提供し、
メソッド（２．１１）、ＴＩＣＣＴＭ−Ｐｐｄｅ経路の独自性：ＴＩＣＣＴＭ−Ｐｐｄｅは以下の６つの経路の特性に対してに対してメソッドを提供し：
（ｉ）全ての経路は相互干渉無しに互いに並列にメッセージを同時に搬送し配信することが可能あり、
（ｉｉ）全ての経路はＴＩＣＣＴＭ−ＰｐｄｅのＳＭＳ（自己監視システム）を駆動する組み込みインフラストラクチャを含んでおり、
（ｉｉｉ）全ての経路はメッセージスケジューリングやメッセージ送信中の同期セッションを必要とせずにメッセージの準備できれば即座にメッセージを同時に送信し、
（ｉｖ）各経路において信号を交換する全てのソフトウェアまたはハードウェアコンポーネントは、常に互いに対してチューンされており、チューンによって、各コンポーネントがその経路内の他のコンポーネントからの信号を受信し応答する準備が常にできており、それによってメッセージ配送を際だって加速し、
（ｖ）各経路は１つのポートグループ内のポートの親セルから調和した結合メッセージを送信し、その結合メッセージを同じポートグループ内のポートまたは同じ経路に接続されている他のポートグループ内のポートに並列に同期して配信し、
（ｉｖ）各経路は、２ギガヘルツＣＰＵを仮定した場合に、限界が正確に予測可能な２〜３００ナノ秒以下のレイテンシでのポートグループ内のポートへの保証された高速同期メッセージ配送を実現し、
ＴＩＣＣＴＭ−Ｐｐｄｅ経路のこれらの６つの特性を併わせることで、ＴＩＣＣＴＭ−Ｐｐｄｅ経路が独自で、ＴＩＣＣＴＭで使用される経路も含めて全ての他のコンピュータ通信システムで使用される通信経路とは異なることになり、ＴＩＣＣＴＭ−Ｐｐｄｅは前述の独自の特徴を備えている経路をインストールし使用するメソッドを提供し、
メソッド（２．１２）、Ａ：ｃｅｌｌｓ（）の定義用：メソッドはセルと呼ばれるソフトウェア計算ユニットの集合を定義し、Ａ：ｃｅｌｌｓ（）はアプリケーションＡ内の全てのセルの集合であって、各セルはセルのクラスのインスタンスであって、セルのクラスは、Ｃｅｌｌと呼ぶトップレベルアブストラクトＴＩＣＣＴＭ−Ｐｐｄｅクラスのサブクラスであって、以降でＣｅｌｌサブクラスと呼ばれ、Ａ：ｃｅｌｌｓ（）内の各セルは、Ａ：ｃｅｌｌｓ（）の全ての他のセルと並列に実行（ｒｕｎ）され、各セルはそのセルに固有の指定された別個のＣＰＵ（ＣｏｍＰｕｔｉｎｇＵｎｉｔ）内で実行（ｒｕｎ）され、２つのセルが同じＣＰＵを共有することはなく、ＴＩＣＣＴＭ−Ｐｐｄｅはセルへの全てのＣＰＵ割り当てとそれぞれの割り当てられたＣＰＵ内で実行（ｒｕｎ）するためのセルの起動を管理し、セルと通信経路とは様々なマルチコアチップの任意の多数のＣＰＵ内で効率的に実行（ｒｕｎ）されるように特に設計されており、セルは、さまざまなマルチコアチップ内で時間が制限されているサイバー物理並列ソフトウェアシステムを実行（ｒｕｎ）するように特に設計もされており、ＴＩＣＣＴＭ−Ｐｐｄｅの設計、検証、および自己監視方法は任意の非同期ハードウェアシステムのハードウェアコンポーネントの設計、検証、および実行（ｒｕｎ）にも使用され、ＴＩＣＣＴＭ−Ｐｐｄｅセルは、ＴＩＣＣＴＭセルの特別な仕様であって、アプリケーションＡに必要な全てのＴＩＣＣＴＭ−ＰｐｄｅのＣｅｌｌサブクラス（以降ではＣｅｌｌサブクラスと呼ぶ）を、ＴＩＣＣＴＭ−ＰｐｄｅのＣｅｌｌサブクラス定義フォーマットと整合するように定義することは実装者の責任であって、ＴＩＣＣＴＭ−ＰｐｄｅはＣｅｌｌサブクラスを定義し、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）にセルインスタンスをインストールするメソッドを提供し、
メソッド（２．８）、Ａ：ｐｏｒｔｓ（）の定義用：ソフトウェアポートはＡ：ｃｅｌｌｓ（）内のセルに付属しており、Ａ：ｃｅｌｌｓ（）内のセルは、それらに付属しているポートをメッセージの送信／受信に使用し、各ポートはポートのクラスのインスタンスであって、ポートのクラスは、以降でポート−サブグラスと呼ぶＴＩＣＣＴＭ−ＰｐｄｅのＰｏｒｔと呼ぶトップレベルアブストラクトポートクラスのサブグラスであって、各ポートはＡ：ｃｅｌｌｓ（）内の１つのセルＣだけに付属しており、Ｃ．ｐはセルＣに付属している任意のポートであって、Ａ：ｐｏｒｔｓ（）はＡ：ｃｅｌｌｓ（）内のセルに付属している全てのポートの集合であって、Ｃ：ｐｏｒｔｓ（）はセルＣに付属しているポートの集合であって、Ａ：ｃｅｌｌｓ（）内の各ＣについてのＣ：ｐｏｒｔｓ（）は、Ｃ．ｇと呼ばれる少なくとも１つのｇｅｎｅｒａｌＰｏｒｔ、Ｃ．ｆと呼ばれる少なくとも１つのｆｕｎｃｔｉｏｎＰｏｒｔと、Ｃ．ｉと呼ばれる少なくとも１つのｉｎｔｅｒｒｕｐｔＰｏｒｔを有しており、各Ｃ．ｇはＧｅｎｅｒａｌＰｏｒｔと呼ばれるポートのサブグラスのインスタンスであって、Ｃ．ｇはサービス要求メッセージの送信と，応答の受信のためにＣによって使用され、各Ｃ．ｇはＦｕｎｃｔｉｏｎＰｏｒｔと呼ばれるポートのサブグラスのインスタンスであって、Ｃ．ｆはサービス要求メッセージの受信と応答とのためにＣによって使用され、各Ｃ．ｉはＩｎｔｅｒｒｕｐｔＰｏｒｔと呼ばれるポートのサブグラスのインスタンスであって、ＩｎｔｅｒｒｕｐｔＰｏｒｔ自体は、ＦｕｎｃｔｉｏｎＰｏｒｔのサブクラスであって、ＩｎｔｅｒｒｕｐｔＰｏｒｔＣ．ｉは、Ａ：ｃｅｌｌｓ（）内の他のセルから割り込みメッセージを受信し、受信したメッセージに応答するためにＣによって使用され、Ａ：ｃｅｌｌｓ（）内のセルによって実行（ｒｕｎ）されない任意のプロセスはどのようなセルの動作にも割り込むことはできず、ＴＩＣＣＴＭ−Ｐｐｄｅは任意のＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムで使用される可能性のある全てのポート−サブグラスの定義を含んでおり、各ポートはポート−サブグラスのインスタンスであって、ＴＩＣＣＴＭ−Ｐｐｄｅはポートサブグラスを定義し、ポートインスタンスをインストールし、ポートインスタンスをセルに付属させるためのメソッドを提供し、アプリケーションＡに特有であって、ＴＩＣＣＴＭ−Ｐｐｄｅにおいて既に定義されていない特別なポートサブグラスだけをＴＩＣＣＴＭ−Ｐｐｄｅのポートサブグラス定義フォーマットに整合している方法で定義するのは実装者の責任であって、
メソッド（２．９）、Ａ：ａｇｅｎｔｓ（）の定義用：ソフトウェアエージェントを定義するメソッドであって、エージェントはＡ：ｐａｔｈｗａｙｓ（）のｖｉｒｔｕａｌＭｅｍｏｒｙに付属しており、各エージェントはエージェントのクラスのインスタンスであって、エージェントのクラスは、以降でエージェントサブグラスと呼ぶＴＩＣＣＴＭ−ＰｐｄｅのＡｇｅｎｔと呼ぶトップレベルアブストラクトエージェントクラスのサブグラスであって、各エージェントはエージェントの親ｖｉｒｔｕａｌＭｅｍｏｒｙと呼ばれる唯一のｖｉｒｔｕａｌＭｅｍｏｒｙに付属しており、Ａ：ｐａｔｈｗａｙｓ（）の経路のエージェントと競合するのを防止し、Ａ：ｐｏｒｔｓ（）はＡ：ｐａｔｈｗａｙｓ（）内のｖｉｒｔｕａｌＭｅｍｏｒｙに付属している全てのエージェントの集合であって、ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムで使用される可能性のある全てのエージェント−サブグラスの定義を含んでおり、各エージェントはエージェント−サブグラスのインスタンスであって、ＴＩＣＣＴＭ−Ｐｐｄｅはエージェント−サブグラスを定義し、エージェントインスタンスをインストールし、エージェントをｖｉｒｔｕａｌＭｅｍｏｒｙに付属させるメソッドを提供し、アプリケーションＡに特有であって、ＴＩＣＣＴＭ−Ｐｐｄｅにおいて既に定義されていない特別なエージェントサブグラスだけをＴＩＣＣＴＭ−Ｐｐｄｅのエージェントサブグラス定義フォーマットに整合している方法で定義するのは実装者の責任であって、
メソッド（２．１０）、Ａ：ｖｉｒｔｕａｌＭｅｍｏｒｉｅｓ（）の定義用：ｖｉｒｔｕａｌＭｅｍｏｒｉｙと呼ばれるソフトウェアオブジェクトを定義するメソッドであって、各ｖｉｒｔｕａｌＭｅｍｏｒｙはｖｉｒｔｕａｌＭｅｍｏｒｙのクラスのインスタンスであって、ｖｉｒｔｕａｌＭｅｍｏｒｙのクラスは、以降でＶｉｒｔｕａｌＭｅｍｏｒｙサブグラスと呼ぶＴＩＣＣＴＭ−ＰｐｄｅのＶｉｒｔｕａｌＭｅｍｏｒｙと呼ぶトップレベルアブストラクトｖｉｒｔｕａｌＭｅｍｏｒｙクラスのサブグラスであって、ｖｉｒｔｕａｌＭｅｍｏｒｙの各インスタンスはｖｉｒｔｕａｌＭｅｍｏｒｙの親経路と呼ばれる唯一のｓｍ−ｐａｔｈｗａｙに一意に関連付けられており、したがってＡ：ｐａｔｈｗａｙｓ（）のｓｍ−経路のｖｉｒｔｕａｌＭｅｍｏｒｙと競合するのを防止し、各ｄｍ−経路は分散計算システム内のＳＭＰのグループを相互接続しており、そのような各ｄｍ−経路はそのｄｍ経路に接続されているＳＭＰと同じ数のｖｉｒｔｕａｌＭｅｍｏｒｙを含んでおり、Ａ：ｐｏｒｔｓ（）はＡ：ｐａｔｈｗａｙｓ（）に埋め込まれている全てのｖｉｒｔｕａｌＭｅｍｏｒｙの集合であって、ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムで使用される可能性のある全てのＶｉｒｔｕａｌＭｅｍｏｒｙサブグラスの定義を含んでおり、ＴＩＣＣＴＭ−ＰｐｄｅはＶｉｒｔｕａｌＭｅｍｏｒｙサブグラスを定義し、ｖｉｒｔｕａｌＭｅｍｏｒｙインスタンスを経路インスタンス内にインストールするメソッドを提供し、ハードウェアメモリをｖｉｒｔｕａｌＭｅｍｏｒｙに動的に割り当て、アプリケーションＡに特有であって、ＴＩＣＣＴＭ−Ｐｐｄｅにおいて既に定義されていない特別なＶｉｒｔｕａｌＭｅｍｏｒｙサブグラスだけをＴＩＣＣＴＭ−ＰｐｄｅのＶｉｒｔｕａｌＭｅｍｏｒｙサブグラス定義フォーマットに整合している方法で定義するのは実装者の責任であって、
メソッド（２．１１）、Ａ：ｐａｔｈｗａｙｓ（）の定義用：各経路は経路のクラスのインスタンスであって、経路のクラスは、以降でＰａｔｈｗａｙサブグラスと呼ぶＴＩＣＣＴＭ−ＰｐｄｅのＰａｔｈｗａｙと呼ぶトップレベルアブストラクト経路クラスのサブグラスであって、共有メモリ環境内の経路はソフトウェアコンポーネントだけを含んでおり、そのような共有メモリ経路はｓｍ−経路と呼ばれ、分散メモリ環境内の経路はソフトウェアコンポーネントとハードウェアコンポーネントの両方を含んでおり、そのような分散メモリ経路はｄｍ経路と呼ばれ、用語経路はｓｍ経路とｄｍ経路の両方を指すのに使用され、アプリ−ションＡ内の全ての経路の集合はＡ：ｐａｔｈｗａｙｓ（）と呼ばれ、ＴＩＣＣＴＭ−Ｐｐｄｅは並列プログラミングで使用される可能性のある経路について全てのＰａｔｈｗａｙサブグラスの定義を提供し、各経路はＰａｔｈｗａｙサブグラスのインスタンスであって、ＴＩＣＣＴＭ−ＰｐｄｅはＰａｔｈｗａｙサブグラスを定義し、経路インスタンスをインストールし、経路インスタンスをＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内のセルに付属しているポートに接続し、実装者は、所与のアプリケーションに特有であって、ＴＩＣＣＴＭ−Ｐｐｄｅにおいて既に定義されていないＰａｔｈｗａｙサブグラスだけを定義しなければならず、実装者は、ＴＩＣＣＴＭ−ＰｐｄｅのＰａｔｈｗａｙサブグラスの規則のように、全ての必要な新しいＰａｔｈｗａｙサブグラスを定義する必要があって、
メソッド（２．１２）、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の定義用：ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ＤＥＳＩＧＮ（）のＣｅｌｌサブクラスのアブストラクトな、または完全にリファインされている定義のセルインスタンスをインストールするメソッドを提供し、そのようにインストールされたセルはＡ：ｃｅｌｌｓ（）に属し、メソッドはＰｏｒｔサブクラスのアブストラクトな、または完全にリファインされている定義のインスタンスをインストールし、ポートインスタンスをＡ：ｃｅｌｌｓ（）内のセルインスタンスに付属させ、Ａ：ｃｅｌｌｓ（）内のセルに付属している全てのポートの集合はＡ：ｐｏｒｔｓ（）と呼ばれ、メソッドはＰａｔｈｗａｙサブクラスのアブストラクトな、または完全にリファインされている定義のインスタンスをインストールし、それらをＡ：ｐｏｒｔｓ（）のポートに接続し、アプリケーションＡの構成にインストールされている全てのそのような経路インスタンスの集合はＡ：ｐａｔｈｗａｙｓ（）と呼ばれ、メッセージを送信するＡ：ｐａｔｈｗａｙｓ（）内の各ｓｍ−経路Ｓは、ＴＩＣＣＴＭ−Ｐｐｄｅ内のアブストラクトなまたは完全にリファインされているｖｉｒｔｕａｌＭｅｍｏｒｙインスタンスのＳ．ｖＭと呼ばれる一意のインスタンスを有しており、Ｓ．ｖＭはＳに埋め込まれているｖｉｒｔｕａｌＭｅｍｏｒｙであって、各ｄｍ経路Ｄはそのｄｍ経路に接続されている各ＳＭＰに１つのｖｉｒｔｕａｌＭｅｍｏｒｙを含んでおり、Ｄに埋め込まれているｖｉｒｔｕａｌＭｅｍｏｒｙの数はＤに接続されているＳＭＰの数に等しく、Ｄ．ｖＭはｄｍ経路Ｄに埋め込まれている全てのｖｉｒｔｕａｌＭｅｍｏｒｙの集合であって、各経路内の各ｖｉｒｔｕａｌＭｅｍｏｒｙには、アブストラクトな、または完全にリファインされているＡｇｅｎｔサブクラスの一意のエージェントが付属しており、Ａ：ｐａｔｈｗａｙｓ（）内の経路のｖｉｒｔｕａｌＭｅｍｏｒｙに付属している全てのそのようなエージェントインスタンスの集合はＡ：ａｇｅｎｔｓ（）と呼ばれ、Ａ：ｐａｔｈｗａｙｓ（）内の経路は、Ａ：ｃｅｌｌｓ（）内のセルに付属しているポートを相互接続し、各ポートは唯一の経路内の唯一のエージェントだけに接続されており、Ａ：ｐａｔｈｗａｙｓ（）内の任意のｓｍ経路ＳのコンポーネントはＳ：ｐｏｒｔｓ（）、Ｓ：ａｇｅｎｔｓ（）、およびＳ．ｖＭであって、Ａ：ｐａｔｈｗａｙｓ（）内の任意のｄｍ経路ＤのコンポーネントはＤ：ｐｏｒｔｓ（）、Ｄ：ａｇｅｎｔｓ（）、およびＤ．ｖＭであって、２つの別個の経路がコンポーネントを共有することはなく、それによって並列メッセージ交換中のメッセージ干渉を防止しており、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）（以降ではネットワークと呼ぶ）はノードがＡ：ｃｅｌｌｓ（）内のセルであって、ブランチがセルに付属しているポートを相互接続しているＡ：ｐａｔｈｗａｙｓ（）内の経路であるグラフであって、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋ（）を定義するメソッドを提供し、
メソッド（２．１３）、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の構築用：Ｃｏｎｆｉｇｕｒｅｔｏｒ（またはＥｎｖｉｒｏｎｍｅｎｔ）と呼ばれるＣｅｌｌサブクラスの１つまたは２つ以上の区別されているセルがアプリケーションＡについて定義され、Ａ：ＤＥＳＩＧＮ（）は各ＳＭＰ内にコンフィギュレータ（または環境）と呼ばれるＣｏｎｆｉｇｕｒｅｔｏｒの少なくとも１つのインスタンスを有しており、コンフィギュレータは、アプリケーションＡのユーザからのキュー上に既に定義されているＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の開始サブネットワークを各ＳＭＰにインストールして、開始サブネットワーク内のセルに割り当てられているＣＰＵ内で実行（ＲＵＮ）されるアプリケーションＡを開始するようにプログラムされており、各ＳＭＰ内の開始サブネットワーク内のセルは、そのＳＭＰに属しているＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の部分をそれぞれの初期化ルーチンを使用して並列にインストールするようにプログラムされており、ＴＩＣＣＴＭ−Ｐｐｄｅは、ネットワーク内にセル、ポート、エージェント、ｖｉｒｔｕａｌＭｅｍｏｒｙ、および経路のアブストラクトな、または完全にリファインされているサブクラスの全ての必要なインスタンスをインストールするメソッドを提供し、それらを互いに対して接続し、付属させチューンするメソッドは全てのＴＩＣＣＴＭ−Ｐｐｄｅ接続性規則を満足し、各ＳＭＰ内で前記開始サブネットワークと共にアプリケーションＡが開始されるとネットワークが正しく構築されるようにセルサブクラス内で適切に定義されている初期化ルーチンをプログラムするのは実装者の責任であって、各ＳＭＰ内で並列ネットワーク構築中にデッドロックの発生を防止するように初期化ルーチン用にプログラムを開発することも実装者の責任であって、ネットワークの並列構築は、ＴＩＣＣＴＭ−Ｐｐｄｅが自動的に調和させ、ＴＩＣＣＴＭ−Ｐｐｄｅは既に定義されているＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）を構築するメソッドを提供し、
メソッド（２．１４）、Ａ：ＴＩＣＣ−ｎｅｔｗｏｒｋ（）の表示用：ＴＩＣＣＴＭ−ＧＵＩ（グラフィカルユーザインターフェイス）はＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）をディスプレイ画面上に表示するために使用され、各ＳＭＰはそれ自体の専用の表示画面を有しており、アプリケーションＡに対してＴＩＣＣＴＭ−ＧＵＩ画面を開くことによって、ＴＩＣＣＴＭ−ＧＵＩは各ＳＭＰの表示画面上にアプリケーションＡの構成の画像を表示し、ユーザはコンフィギュレータの表示されている画像をクリックし、表示されているメニューからインストールオプションを選択することによって、そのＳＭＰのコンフィギュレータにセルの初期化ルーチンの実行（ｒｕｎ）を開始するのに十分なＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の開始サブネット内の全てのセルと経路とをそのＳＭＰの開始サブネットにインストールさせ、開始サブネット内の各セルは、ＴＩＣＣＴＭ−Ｐｐｄｅによってそれに割り当てられている前記ＳＭＰのＣＰＵ内で実行（ｒｕｎ）され、開始サブネット内のセルが他のセルと他の経路をＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内にインストールすると、新しくインストールされた各セルは前記ＳＭＰ内の割り当てられたＣＰＵ内で実行（ｒｕｎ）されるようにＴＩＣＣＴＭ−Ｐｐｄｅによって自動的に起動され、そのような新しくインストールされた各セルは自身の初期化ルーチンを実施してさらに他のセルと経路とを前記ＳＭＰ内に存在しているネットワークにインストールし、したがって、ネットワークは全てのＳＭＰ内でネットワーク全体が構築されるまで並列に拡大し、必要なネットワークが正しく構築されるように衝突とデッドロックとを防止するように初期化ルーチンを定義するのは実装者の責任であって、ＴＩＣＣＴＭ−ＧＵＩは各ＳＭＰ内にインストールされたネットワークまたはユーザによって指定されたセル上に固定されたネットワークの一部を表示し、１つのＳＭＰ内の小さいアプリケーション用のそのようなネットワーク画像の例は、（発明を実施するための形態）を通して示されており、ＴＩＣＣＴＭ−ＧＵＩは、ＴＩＣＣＴＭ−Ｐｐｄｅの組み込みサブシステムであって、ＴＩＣＣＴＭ−Ｐｐｄｅは任意のアプリケーションＡ内にインストールされているＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の任意の部分を表示するメソッドを提供し、
メソッド（２．１５）、Ａ：ｍｅｓｓａｇｅｓ（）の定義用：メッセージはＡ：ｐａｔｈｗａｙｓ（）の経路のｖｉｒｔｕａｌＭｅｍｏｒｙに保持され、各メッセージはメッセージクラスのインスタンスであって、メッセージのクラスは、Ｍｅｓｓａｇｅと呼ばれるＴＩＣＣＴＭ−ＰｐｄｅのトップレベルアブストラクトメッセージクラスのＭｓｇと呼ばれるＭｓｇサブグラスであって、ＭｓｇはＭｅｓｓａｇｅの任意のＭｓｇサブクラスを指し、各Ｍｓｇ定義はＭｓｇのメッセージインスタンスｍに現れる可能性のあるＭｓｇ−フォーマットとデータフォーマットとを指定し、各Ｍｓｇ定義はメッセージを処理しＭｓｇインスタンスの新しいメッセージを生成するＭｓｇメソッドも指定し、Ａ：ｐａｔｈｗａｙｓ（）内の経路は、ＭｓｇサブグラスのインスタンスをＡ：ｃｅｌｌｓ（）内のセルＣに付属しているポートＣ．ｐに配信し、アプリケーションＡに対して定義されている全てのＭｓｇサブクラスの集合はＡ：ｍｅｓｓａｇｅｓ（）と呼ばれ、ＴＩＣＣＴＭ−Ｐｐｄｅ内のメッセージサブクラス定義フォーマットに整合するようにアプリケーションＡで必要な全てのＭｓｇサブクラスを定義するのは実装者の責任であって、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ｍｅｓｓａｇｅｓ（）を定義するメソッドを提供し、
メソッド（２．１６）、Ｍｓｇ−メソッドの定義：Ａ：ｃｅｌｌｓ（）内のセルＣに付属しているポートＣ．ｐのＣ．ｐ．ｐａｔｈｗａｙに埋め込まれているｖｉｒｔｕａｌＭｅｍｏｒｙ、ＭはＣ．ｐ．ｖＭであって、Ｃ．ｐ．ｖＭのｒｅａｄＭｅｍｏｒｙはＣ．ｐ．ｒｄであって、Ｃ．ｐ．ｗｒはｗｒｉｔｅＭｅｍｏｒｙであって、Ｃ．ｐ．ｒｄはＭｓｇサブクラスＭｓｇのメッセージインスタンスｍを保持しており、Ｃ．ｐ：ｍｓｇ（）という句はこのメッセージインスタンスｍを指し、Ｃ．ｐ．ｗｒは他のＭｓｇサブグラスＭｓｇ’の場合もあるメッセージインスタンスｍ’を保持し、Ｃ．ｐ．ｗｒ：ｍｓｇ（）はこのメッセージインスタンスｍ’を指し、Ｃ．ｐの親セルＣを実行（ｒｕｎ）するＣＰＵはＭｓｇサブクラスＭｓｇとＭｓｇ’において定義されているＭｓｇメソッドを実行し、ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙＣ．ｐ．ｅｘはＭｓｇサブクラスで定義されている各Ｍｓｇメソッドに対して実行環境を提供し、ＭｓｇサブクラスＭｓｇとＭｓｇ’で定義されているＭｓｇ−メソッドとＭｓｇ’メソッドはそれぞれ、フォーマットＭｓｇ：〈ｍｎ〉（〈ｐｏｒｔｓ〉）とＭｓｇ’：〈ｍｎ’〉（〈ｐｏｒｔｓ’〉）を有しており、〈ｍｎ〉と〈ｍｎ’〉はそれぞれ前記ＭｓｇメソッドとＭｓｇ’メソッドとの一意の別個の名前であって、それぞれ、引数〈ｐｏｒｔｓ〉と〈ｐｏｒｔｓ’〉とに現れるすべてのポートＣ．ｑはポートＣ．ｐの親セルに付属しており、セルＣを実行（ｒｕｎ）するＣＰＵはＣ．ｐ：〈ｍｎ〉（〈ｐｏｒｔｓ〉）およびＣ．ｐ：〈ｍｎ’〉（〈ｐｏｒｔｓ’〉）をそれぞれ使用してＣ．ｐ．ｖＭ内のそれぞれのメソッドを呼び出し実行し、これらのメソッドはセルＣに関連付けられている以下のコンポーネント内でのみ定義されているデータと他のメソッドを使用し、ポートＣ．ｐと他のポートＣ．ｑとは〈ｐｏｒｔｓ〉または〈ｐｏｒｔｓ’〉に現れ、コンポーネントは（ｉ）セルＣ、（ｉｉ）ポートＣ．ｐ、（ｉｉｉ）ｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｐ．ｖＭ内に存在しているメッセージＣ．ｐ：ｍｓｇ（）およびＣ．ｐ．ｗｒ：ｍｓｇ（）、（ｉｖ）引数〈ｐｏｒｔｓ〉または〈ｐｏｒｔｓ’〉内に現れるポートＣ．ｑ、および（ｖ）ｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｐ．ｖＭ内に存在しているメッセージＣｑ：ｍｓｇ（）およびＣ．ｑ．ｗｒ：ｍｓｇ（）であって、セルＣのＭｓｇサブクラスまたはＣｅｌｌサブクラスで定義されている任意のメソッドを実行する任意のセルＣはＣに付属しているかＣに対してチューンされているかのいずれかのＣのポートに接続されている経路内の他のソフトウェアコンポーネントで定義されているデータと他のメソッドだけを使用することが可能で、チューンと付属させることとは推移的で対称な関係であって、この要件によってＡ：ｃｅｌｌｓ（）の全ての他のセルから各セルＣを分離し、経路に接続されているメッセージ送信ポートとメッセージ受信ポートの親セルはその経路のｖｉｒｔｕａｌＭｅｍｏｒｙを同時に使用することは決してなく、ＴＩＣＣＴＭ−Ｐｐｄｅは前述の規則によってＭｓｇ−メソッドを定義するメソッドを提供し、
メソッド（２．１７）、Ａ：ｐｔｈｒｅａｄｓ（）の定義用：任意のＭｓｇサブクラス、Ｍｓｇで定義されるＭｓｇ−メソッド、Ｍｓｇ：〈ｍｎ〉（〈ｐｏｒｔｓ〉）または任意のＣｅｌｌサブグラスで同様に定義されるセルメソッド、Ｃ：〈ｍｎ〉（〈ｐｏｒｔｓ〉）はｐｔｈｒｅａｄ（並列スレッド）と呼ばれるが、それはそのようなメソッドが２ギガヘルツＣＰＵでの実行の完了に１０〜１００マイクロ秒以上かからない短い逐次コンピュータプログラムであるためで、ｐｔｈｒｅａｄはＡ：ｃｅｌｌｓ（）内のセルによって並列に実行され、アプリケーションＡに対して定義されている全てのそのようなｐｔｈｒｅａｄの集合はＡ：ｐｔｈｒｅａｄｓ（）と呼ばれ、Ａ：ｐｔｈｒｅａｄｓ（）内の各ｐｔｈｒｅａｄは、ポートグループのポート親セルによってそれらの共通のｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍ内で並列に、そしてそれらのそれぞれの並列計算を調和させるために、前記ｐｔｈｒｅａｄの並列実行中にデータ交換のためにＭ．ｓｃｐを使用して実行されているｐｔｈｒｅａｄ以外のＡ：ｐｔｈｒｅａｄｓ（）内の全ての他のｐｔｈｒｅａｄとは独立しており、ＴＩＰはｐｔｈｒｅａｄをセル間の全ての他の通信から分離し、ｐｔｈｒｅａｄとＭｓｇ−サブグラスを含んでいるＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の全てのアブストラクトソフトウェアユニットを完全にリファインするのは実装者の責任であって、しかし、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の正式な確認はＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）のリファインの任意の段階で可能であって、ＴＩＣＣＴＭ−Ｐｐｄｅは前述の規則によってｐｔｒｅａｄのリファインを定義するメソッドを提供する、メソッド。
【請求項３】
請求項１または２に記載のメソッドであって、完全にリファインされているＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を生成するために連続しているリファインによってＡ：ＤＥＳＩＧＮ（）を実装するための以下のメソッドをさらに有するメソッドであって、
メソッド（３．１）、ＴＩＰ（スレッド相互動作プロトコル）と呼ばれるプログラミングアブストラクトの定義用：ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＰを使用してＡ：ｃｅｌｌｓ（）内のセル間の相互動作のアブストラクト仕様を定義するメソッドを提供し、各ＴＩＰはセルＣのポートＣ．ｐで定義され、ポートＣ．ｐで定義されたＴＩＰはＣ．ｐ：ＴＩＰ（）と呼ばれ、Ａ：ｃｅｌｌｓ（）内の各セルＣに付属している各ポートで定義されたＣ．ｐ：ＴｌＰ（）が存在し、セルＣに対して定義されている全てのＴＩＰの集合はＡ：ＴＩＰＳ（）と呼ばれ、アプリケーションＡに対して定義されている全てＴＩＰの集合はＡ：ＴＩＰＳ（）と呼ばれ、Ｃ．ｐ：ＴＩＰ（）はアブストラクトにセルＣがどのようにそのポートＣ．ｐでメッセージを受信し、受信したメッセージを処理し、それに対して応答するのかを指定し、Ａ：ｃｅｌｌｓ（）内のセル間の相互作用は、Ａ：ＴＩＣＣ−ｎｅｔｗｏｒｋ（）内の経路を介したメッセージ交換のみを通して発生し、ＴＩＣＣＴＭ−Ｐｐｄｅとメッセージ交換に基づいている他の同様なシステムとの本質的な違いはＴＩＣＣＴＭ−Ｐｐｄｅが通信を管理する方法であって、ＴＩＣＣＴＭ−Ｐｐｄｅの各セル自体はメッセージスケジューリングと同期のセッションを必要とせずに全てのメッセージを配信し、２ギガヘルツのＣＰＵを使用して高々２〜３００ナノ秒の正確に予測可能なレイテンシで非常に高速な即座の非同期並列メッセージ配信を保証し、全ての並列プログラミングの必要性を満たすのに必要な異なる種類のＴＩＰは５つだけあって、簡単なＴＩＰは以下の形式を有し、
非同期ＴＩＰ：Ｃ．ｐ：ＴＩＰ（）＝Ｃ．ｐ：ｇｕａｒｄ？（）｛Ｃ．ｐ：ｔｉｐ（）；｝  （Ｃ．１）または
同期ＴＩＰ：Ｃ．ｐ：ＴＩＰ（）＝Ｃ．ｐ：ｇｕａｒｄ？（）＊｛Ｃ．ｐ：ｔｉｐ（）；｝  （Ｃ．２）
Ｃ．ｐはセルＣに付属しているソフトウェアポートであって、Ｃ．ｐはＣ．ｐ．ｐａｔｈｗａｙと呼ばれる経路のｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｃ．ｐ．ｖＭに付属している１つのエージェントだけに接続されており、Ｃ．ｐ：ＴＩＰ（）はＴＩＰボディと呼ばれ、ポートＣ．ｐの位置でのＣ．ｐ：ｇｕａｒｄ？（）またはＣ．ｐ：ｇｕａｒｄ？（）＊の実行はセルＣによるポートのポーリングと呼ばれ、セルＣがそのポートをポーリングする順番はＣのポーリングサイクルと呼ばれ、即座に応答を計算する簡単なＴＩＰの例は以下のとおりであって、
Ｃ．ｆ：ＴＩＰ（）＝Ｃ．ｆ：ｍＲ？（）｛Ｃ．ｆ：ｒ（）．ｓ（）；｝＝Ｃｆ：ｍＲ？（）｛Ｃ．ｆ：ｒ（）；Ｃ．ｆ：ｓ（）；｝  （Ｃ．３）
Ｃｇ：ＴＩＰ（）＝Ｃｇ：ｐＲ？（）｛Ｃｇ：ｘ（）．ｓ（）；｝＝Ｃｇ：ｐＲ？（）｛Ｃｇ：ｘ（）；Ｃ．ｇ：ｓ（）；｝  （Ｃ．４）
ＴＩＰ（Ｃ．３）と（Ｃ．４）の解釈は、以下のメソッド（３．２）からメソッド（３．５）に記述されており、ＴＩＰの様々な種類の多くの例が（発明を実施するための形態）を通して示されており、Ａ：ｐｏｒｔｓ（）の各ポートについてＴＩＣＣＴＭ−ＰｐｄｅのＴＩＰ定義フォーマットとアプリケーションＡの意図している設計要件に整合するようにＣ．ｐ：ＴＩＰ（）を定義するのは実装者の責任であって、ＴＩＣＣＴＭ−Ｐｐｄｅは簡単なＴＩＰを定義するメソッドを提供し、
メソッド（３．２）、非同期ガード：ステートメント（Ｃ．１）のＣｐ：ｇｕａｒｄ？（）は１つの形式Ｃｐ：ｍＲ？（）（’ｍＲ’は’ｍｅｓｓａｇｅＲｅａｄｙ’を表す）とＣ．ｐ：ｐＲ？（）（’ｐＲ’は’ｐａｔｈｗａｙＲｅａｄｙ’を表す）を有している非同期ガードであって、非同期ガードはＴＩＣＣＴＭ−Ｐｐｄｅによって提供され、任意の実装で使用可能な組み込みコンピュータプログラムとして実装されている条件であって、実装者は、ＴＩＣＣＴＭ−Ｐｐｄｅでまだ定義されていない所与のアプリケーションＡに対して特有の自身のガードを自由に定義し、ガードはアプリケーションＡ内のポートによって交換される信号または信号のサブタイプに常に基づいており、非同期ガードはＡ：ｃｅｌｌｓ（）内のセルＣによってそのポートＣ．ｐをポーリングして、Ｃ．ｐがメッセージを有しているかどうか、またはＣ．ｐがメッセージを送信する準備ができているかどうかを確認するために使用され、ガードは真理値、ｔｒｕｅまたはｆａｌｓｅを返し、ステートメント（Ｃ．１）のＴＩＰ−ボディ、Ｃ．ｐ：ｔｉｐ（）はガードが真理値のｔｒｕｅを返した時にだけ実行され、ＴＩＰボディはガードがｆａｌｓｅを返した場合スキップされ、非同期ガードを備えているＴＩＰは非同期ＴＩＰと呼ばれ、ＴＩＣＣＴＭ−Ｐｐｄｅは非同期ガードを定義するメソッドを提供し、
メソッド（３．３）、同期ガード：ステートメント（Ｃ．２）のＣ．ｐ：ｇｕａｒｄ？（）＊は同期ガードであって、親セルＣはＣ．ｐ：ｇｕａｒｄ？（）＊がｔｒｕｅを返した場合にだけＴＩＰ−ボディを実行し、それ以外はＣ．ｐで待ち、Ｃ．ｐ：ｇｕａｒｄ？（）＊が真理値のｔｒｕｅを返すまでＣ．ｐ：ｇｕａｒｄ？（）＊を繰り返し実行し、Ｃ．ｐ：ｇｕａｒｄ？（）＊がｔｒｕｅになるとステートメント（Ｃ．２）のＴＩＰボディを実行し、それからその次のポートのポーリングに進み、記号’＊’は同期ガードに現れて、ガードを実装するコンピュータプログラムのガードがｔｒｕｅを返すまでのこの種類の反復した実行が必要なことをＴＩＣＣＴＭ−Ｐｐｄｅに対して示し、同期ガードを備えているＴＩＰは同期ＴＩＰと呼ばれ、ＴＩＣＣＴＭ−Ｐｐｄｅは同期ガードを定義するメソッドを提供し、
メソッド（３．４）、ｆｕｎｃｔｉｏｎＰｏｒｔでの簡単なＴＩＰの実行用：ステートメント（Ｃ．３）のＣ．ｆはセルＣに付属しているｆｕｎｃｔｉｏｎＰｏｒｔであって、ＣはＣ．ｆの唯一の親セルであって、ＣはＣ．ｆを使用可能な唯一のセルであって、Ｃ．ｆは結合サービス要求メッセージｍを１つまたは２つ以上の他のポートＣ．ｑから受信し、Ｃ．ｆによって受信されるメッセージｍはｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｆ．ｖＭ≡ＭのｒｅａｄＭｅｍｏｒｙ、Ｃ．ｆ．ｒｄに保存され、ｖｉｒｔｕａｌＭｅｍｏｒｙ、ＭはＣ．ｆ．ｐａｔｈｗａｙに埋め込まれており、Ｃ．ｆ：ｍｓｇ（）＝Ｃ．ｆ．ｒｄ：ｍｓｇ（）という句はＣ．ｆ．ｒｄ内のメッセージを示しており、Ｃ．ｆに配信されるＣ．ｆ：ｍｓｇ（）は前述のステートメント（Ｃ．３）のガードＣｆ：ｍＲ？（）の評価によってセルＣによって検知され、評価は、（Ｃ．３）に現れるＴＩＰボディＣｆ：ｒ（）．ｓ（）；＝Ｃ．ｆ：ｒ（）；Ｃ．ｆ：ｓ（）；を実行することによってセルＣをＣ．ｆ：ｍｓｇ（）に応答させる真理値のｔｒｕｅを返し、Ｃ．ｆ：ｒ（）（’ｒ’は’ｒｅｓｐｏｎｄ’を意味する）はサービス要求メッセージＣ．ｆ：ｍｓｇ（）を処理し、応答メッセージをｗｒｉｔｅＭｅｍｏｒｙに書き込みためにＣによって使用されるｐｔｈｒｅａｄ（並列スレッド）のアブストラクションであって、Ｃ．ｆ．ｖＭのＣ．ｆ．ｗｒ、ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ、Ｃ．ｆ．ｖＭのＣ．ｆ．ｅｘはこのＴＩＰボディの評価の実行環境を提供し、実装者は、任意の名前をＣ．ｆ：ｔｉｐ（）内のｐｔｈｒｅａｄｒ（）に対して自由に使用可能で、実装者によって使用される名前は、ｒ（）の設計意図を反映しており、Ｃ．ｆの親セルＣは、Ｃ．ｆ：ｒ（）のすぐ後にＣ．ｆ：ｓ（）を評価し、Ｃ．ｆ．ｗｒ内の応答メッセージをＣ．ｆがそのサービス要求メッセージを受信したポートＣ．ｑに対して即座に送信するためにＣ．ｆ．ｐｒｏｔｏｃｏｌを呼び出して実行し、このプロトコルの実行によって、Ｃ．ｑがｒｅａｄＭｅｍｏｒｙ、Ｃ．ｑ．ｒｄのＣ．ｆ．ｗｒに書き込まれている応答メッセージを受信するようにＣ．ｆ．ｖＭの読み／書きメモリがメッセージ配信前に切り替えられ、ＣはＣ．ｆ．ｒｄで受信したメッセージを、場合によっては修正して、１つまたは２つ以上の送信者に転送するために、Ｃ．ｆ：ｓ（）の代わりにＣ．ｆ：ｆ（）を実行することも可能であって、ｃ．ｆ：ｆ（）は、読み／書きメモリを切り替え、セルＣ自体は、メッセージスケジューリングまたは同期セッションを必要とせずに、応答メッセージを送信または転送するためにポートＣ．ｆに関連付けられているプロトコルＣ．ｆ．ｐｒｏｔｏｃｏｌを実行し、ＴＩＣＣＴＭ−Ｐｐｄｅは、ｆｕｎｃｔｉｏｎＰｏｒｔにおいて全ての種類のＴＩＰを実行するためのメソッドを提供し、
メソッド（３．５）、ｇｅｎｅｒａｌＰｏｒｔでの簡単なＴＩＰの実行用：ステートメント（Ｃ．４）のＣ．ｇはセルＣのｇｅｎｅｒａｌＰｏｒｔであって、ＣはＣ．ｇの唯一の親セルであって、ＣはＣ．ｇを使用可能な唯一のセルであって、ｇｅｎｅｒａｌＰｏｒｔＣ．ｇはサービス要求メッセージを送信し、応答メッセージを受信するためにセルＣによって使用され、セルＣは、Ｃ．ｇ．ｐａｔｈｗａｙが（Ｃ．４）のガードＣ．ｇ：ｐＲ？（）によってチェックされ、メッセージを送信する準備ができている場合にだけ（Ｃ．４）のＣｇ：ｘ（）（’ｘ’は’ｃｏｎｓｔｒｕｃｔ’を表す）を実行し、Ｃ．ｇ：ｘ（）はＣ．ｇ．ｖＭのｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ、Ｃｇ．ｅｘにおいてＣによって実行されるｐｔｈｒｅａｄのアブストラクションであって、Ｃ．ｇ：ｘ（）は、Ｃ．ｇ．ｗｒ内のサービス要求メッセージを計算し、構築し、書き込むために実行され、その後即座にＣ自体がＣ．ｇ：ｓ（）を実行して、１つまたは２つ以上のポートＣ．ｐにＣ．ｇ．ｗｒ内のそのサービス要求メッセージを送信するためにＣ．ｇ．ｐｒｏｔｏｃｏｌを呼び出して実行し、Ｃ．ｇ．ｖＭの読み／書きメモリは、各Ｃ．ｐがサービス要求メッセージをそのｒｅａｄＭｅｍｏｒｙＣ．ｐ．ｒｄにおいて受け取るようにメッセージの配信の前に切り替えられ、ＣはＣ．ｇ．ｒｄで受信したメッセージを、読み／書きメモリの切り替え無しに、場合によっては修正して、１つまたは２つ以上の送信者に転送するために、Ｃ．ｇ：ｓ（）の代わりにＣ．ｇ：ｆ（）を実行することも可能であって、セルＣ自体は、メッセージスケジューリングまたは同期セッションを必要とせずに、メッセージを送信または転送するためにポートＣ．ｇに関連付けられているプロトコルＣ．ｇ．ｐｒｏｔｏｃｏｌを実行し、ＴＩＣＣ−ＰｐｄｅＴＭは、ｇｅｎｅｒａｌＰｏｒｔにおいて全ての種類のＴＩＰを実行するためのメソッドを提供し、
メソッド（３．６）、５種類のＴＩＰの定義用：５種類のＴＩＰは、（ｉ）ステートメント（Ｃ．１）から（Ｃ．４）で導入される単純なＴＩＰ、（ｉｉ）サービス要求に応答するためにＡ：ｃｅｌｌｓ（）の他のセルにおいて計算を生成する生成タスクＴＩＰであって、生成ＴＩＰは（発明を実施するための形態）のセクション４．１と４．２、ステートメント（４．１）から（４．３）とステートメント（４．１１）から（４．１３）で導入され、（ｉｉｉ）（発明を実施するための形態）のセクション４．２、ステートメント（４．８）から（４．１３）で導入されるポートベクトルのサービスを行うＴＩＰ、（ｉｖ）（発明を実施するための形態）のセクション４．４、ステートメント（４．１４）から（４．１６）で導入される非決定的ガードと実存的ガードとを有しているＴＩＰ、（ｖ）（発明を実施するための形態）のセクション４．５、ステートメント（４．１８）から（４．２３）で導入される他の埋め込みＴＩＰをそのＴＩＰボディに含むＴＩＰであって、任意の埋め込みＴＩＰはこれら５種類のＴＩＰのいずれか１つであって、したがって、全ての前述の種類のＴＩＰは任意の組み合わせで１つのＴＩＰのＴＩＰボディに現れることが可能であって、これら５種類のＴＩＰは任意のＴＩＣＣＴＭ−Ｐｐｄｅソフトウェアまたはハードウェアシステムを設計し、構築するのに必要であって、ＴＩＣＣＴＭ−Ｐｐｄｅはすべての種類のＴＩＰを定義するメソッドを提供し、
メソッド（３．７）、トランザクション用：ポートグループｐＧのポートＣｉ．ｐ、０≦ｉ＜ｎ、は、Ｃｉ．ｐ．ｐｒｏｔｏｃｏｌ、０≦ｉ＜ｎの同時の調和した並列実行によって、結合サービス要求メッセージｍをポートグループｑＧの全てのポートＤｊ．ｑ、０≦ｊ＜ｍに同期して配信し、各ＣｉによるＣｉ．ｐ．ｐｒｏｔｏｃｏｌのこの並列実行をｐＧ．ｐａｔｈｗａｙ内のエージェントが自動的に調和させ、各ポートＣｉ．ｐはＣｉがＣｉ．ｐ．ｐｒｏｔｏｃｏｌの実行を開始した後、即座にロックされ、各ポートＤｊ．ｑは、Ｄｊ．ｑの親セルＤｊがＤｊ．ｑに配信されたメッセージｍを検知した時に即座にロックされ、第２のサービス要求メッセージがＤｊ．ｑに送信されたり、Ｄｊ．ｑによって受信されたりするのを防止し、ポートＤｊ．ｑは第１のサービス要求メッセージｍが処理され親セルＤｊによって結合応答メッセージｍ’をｑＧの全てのポートを介して送信することによって応答された後で初めて第２のサービス要求メッセージの配信を受信し、ポートＣｉ．ｐは、親セルＣｉがｑＧによって送信された結合応答メッセージを検出した後で初めて第２のサービス要求メッセージを送信し、各親セルＤｊは、同じグループ対グループ経路ｑＧ．ｐａｔｈｗａｙ≡ｐＧ．ｐａｔｈｗａｙ上で応答メッセージｍ’を送信するために、プロトコルＤｊ．ｑ．ｐｒｏｔｏｃｏｌをポートグループｐＧの他の親セルと並列に非同期に実行し、親セルＤｊによる前記プロトコルのこの並列実行をｑＧ．ｐａｔｈｗａｙのエージェントが調和させ、前記エージェントは結合応答メッセージｍ’のｐＧ内の各ポートＣｉ．ｐへの１回だけの同時の配信を保証し、親セルＣｉによってポートＣｉ．ｐで受信されたこの応答メッセージｍ’を検知することは、各ＣｉについてのＣｉ．ｐがそのサービス要求メッセージｍをＤｊ．ｑに送信した時に開始されたトランザクションの完了となり、したがって、Ａ：ｐｏｒｔｓ（）内の各ポートは、連続したトランザクションの完了の後で初めて連続してサービス要求メッセージを送信し、同様に、Ａ：ｐｏｒｔｓ（）内の各ポートは、連続したトランザクションの完了の後で初めて連続したサービス要求メッセージを受信し、各ポートは応答メッセージをそのポートがそのサービス要求メッセージを受信したのと同じ経路を通して常に返送し、ＴＩＣＣＴＭ−Ｐｐｄｅは相互干渉の無い全ての並列トランザクションの保証された整然とした完了のための方法を提供し、
メソッド（３．８）、トランザクションの正しさの定義用：Ａ：ｐｏｒｔｓ（）内の任意の２つのポートｐとｑとの間のトランザクションは［ｐ（ｓｒｍ（ｔ１））⇔ｑ（ｒｍ（ｔ２））］と記述され、ｐ（ｓｒｍ（ｔ１））はポートｐによって時刻ｔ１において送信されたサービス要求メッセージであって、ｑ（ｒｍ（ｔ２））はポートｑによって時刻ｔ２において送信された応答メッセージであって、前記トランザクションは、全てのメッセージｐ（ｓｒｍ（ｔ１））とｑ（ｒｍ（ｔ２））とについて関係Ｒ（ｐ、ｑ）（ｓｒｍ（ｔ１）、ｒｍ（ｔ２））が成立した場合に正しく実行され、Ｒ（ｐ、ｑ）はポート対（ｐ、ｑ）に特有の関係の名前であって、さらに、タイミング制限（ｔ２−ｔ１≦τｍａｘ（ｐ、ｑ））も成立し、τｍａｘ（ｐ、ｑ）はｐとｑとの間のトランザクションが完了する前に発生する可能性のある遅延の上限であって、ポートｐとｑとはｐとｑとの間の各トランザクションが正しく実行される場合に限り良好にマッチしており、ポートのこの良好にマッチしている特性はＴＩＰ、ｐ：ＴＩＰ（）とｑ：ＴＩＰ（）に依存し、この良好にマッチしている特性は、ＴＩＣＣＴＭ−Ｐｐｄｅの重要な特性でもあって、良好にマッチしている特性はこれらの請求項内で５〜６回参照され、トランザクションに関連付けられているタイミングと限界とはｐｔｈｒｅａｄとＴＩＰ内の条件とが実装された後に設計と検証時に推定され、完全にリファインされているＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）はポートの全ての対がＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内の経路によって良好にマッチしている場合にだけ正しく、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のポートの対の良好にマッチしている特性が満たされていることを検証するメソッドを提供し、
メソッド（３．９）、ＣＩＰと呼ばれるアブストラクションの定義用：Ｃ：ＣＩＰ（）（Ｃのセル相互作用プロトコル）と呼ばれるコンピュータプログラムはＡ：ｃｅｌｌｓ（）内の各セルに対する実装によって指定され、Ｃ：ＣＩＰ（）はセルＣの初期化ルーチンを指定し、この初期化はＣが開始された時にだけ１回だけ実施され、ＣがそのポートＣ．ｐをポーリングし、Ｃ：ＴＩＰＳ（）内のＣ．ｐ：ＴｌＰ（）を１つずつ循環的に実行する順番を指定し、この循環ポーリングとＴＩＰ実行は、セルＣのポーリングサイクルと呼ばれ、ＣはＣがその動作を終了するか、ＣのｉｎｔｅｒｒｕｐｔＰｏｒｔの１つでＡ：ｃｅｌｌｓ（）の他のセルからの割り込みメッセージを受信した結果、Ｃがその動作を中断するまでそのポーリングサイクルを継続し、Ｃはそのポーリングサイクルにおいて連続したＴＩＰ続行同士の間でだけ中断され、ＴＩＰ実行をその実行の途中で中断することは不可能であって、中断されたＣは実行を次のメッセージがＣの任意のポートに配信された時に後でレジュームし、任意のポートＣ．ｐについてＣ．ｐ：ＴＩＰ（）の実行はＣ．ｐへのメッセージの配信に同期しており、セルＣによるＣ．ｐのポーリングは、Ｃ．ｐがポーリングサイクル内でポーリングされる時刻の前に、Ｃ．ｐがメッセージを配信された時にだけ成功し、１つのポーリングサイクルで検知し損なったＣ．ｐの位置でのメッセージは次のポーリングサイクルにおいて取得され、セルＣの各Ｃ：ＣＩＰ（）はＡ：ｃｅｌｌｓ（）内の全ての他のセルＣのＣ：ＣＩＰ（）と並列に実行（ｒｕｎ）され、各セルは、自身の独自のそして別個の指定されたＣＰＵ内で実行（ｒｕｎ）され、Ａ：ｃｅｌｌｓ（）内の別個のセルのポーリングサイクルは必ずしも互いに同期している必要は無く、ＴＩＣＣＴＭ−Ｐｐｄｅは、アプリケーションＡの実装中の任意の点で、その点までのいかなるリファインの変更も必要とせずに、Ａ：ｃｅｌｌｓ（）内の別個のセルのポーリングサイクルを調和させ同期させるために、（発明を実施するための形態）のセクション６．６に記述されているように、アドホックな同期と調和のメソッドとを提供し、Ａ：ＣＩＰＳ（）はＡ：ｃｅｌｌｓ（）内の各セルＣの全てのコンピュータプログラムＣ：ＣＩＰＳ（）の集合であって、Ａ：ｃｅｌｌ（）の各セルについてＴＩＣＣ−ＰｐｄｅＴＭのＣＩＰ定義フォーマットとＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のセルＣの意図している機能に整合するようにＣ：ＣＩＰ（）を定義するのは実装者の責任であって、ＴＩＣＣＴＭ−ＰｐｄｅはＣＩＰを定義するメソッドを提供し、
メソッド（３．１０）、ＣＩＰのポーリングサイクルにおける２つの可能性のある実行モード：Ｃ．ｐは、以下の２つの可能性のあるコースアクションの１つに従うように、セルＣによってポーリングされた時に真理値のｔｒｕｅを返し、コースアクションは、（ｉ）ＴＩＰボディ、Ｃ．ｐ：ｔｉｐ（）を即座に実行し、受信したメッセージに応答するか、（ｉｉ）Ｃ．ｐをセルＣのｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに挿入し、並べ替えはセルを実行（ｒｕｎ）しているＣＰＵのローカルクロックのメッセージ配信時間を示しているポートの位置でのタイムスタンプに基づいて通常実施され、そのようなタイムスタップはメッセージをポートに配信するプロトコルによるポートへのメッセージ配信の時間に設定されるか、セルＣに対してローカルな並べ替えの関係に従っており、ポーリングと並べ替えの完了後、全てのそのポートＣは、ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内の各Ｃ．ｐについてのＣ．ｐ：ｔｉｐ（）をリスト内に現れる順番で実行し、Ｃ．ｐはセルＣにポーリングされた時に真理値のｆａｌｓｅを返し、またＣに２つの可能なコースアクションの１つに従うようにし、コースアクションは（ｉ）Ｃ．ｐのガードが非同期ガードである場合ポートＣ．ｐをスキップし、即座にその次のポートのポーリングに進むか、（ｉｉ）Ｃ．ｐのガードが同期ガードの場合、ポートＣ．ｐでメッセージの到着を待ち、メッセージの到着後Ｃ．ｐ：ｔｉｐ（）を実行し、それから次のポートのポーリングに進むかであって、ＴＩＰのガードが真理値のｔｒｕｅを返した後、ＣＩＰがそのポートのいくつかでＴＩＰボディを実行し、後の実行用にｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内の他のポートを並べ替えることも可能であって、ＴＩＣＣＴＭ−ＰｐｄｅはＣＩＰによるＴＩＰの並べ替えられている／並べ替えられていない実行および同期／非同期実行を指定するメソッドを提供し、
メソッド（３．１１）、ポートグループの定義と使用用：ポートグループはＡ：ｃｅｌｌｓ（）内の別個のセルに属しているポートの集合であって、２つのポートグループが任意のポートを共通に有していることはなく、ポートグループは、別個のセルに付属している別個のポートグループを経路内のエージェントに接続することによって定義され、各グループ対グループ経路内のエージェントは、全ての親セルが結合メッセージにそれぞれの貢献分の書き込みを完了した後、メッセージ送信ポートグループ内のポートの前記親セルによって共同で書き込まれたメッセージをディスパッチし、ディスパッチされたメッセージは、メッセージ受信ポートグループ内の全てのポートに同期して配信され、したがってポートグループ内のポート間のメッセージのディスパッチと配信は常に同期しており、ポートグループを接続する経路内のエージェントは前記経路内の全てのメッセージディスパッチと配信とを調和させ、エージェントもＳＭＳ（自己監視システム）内で対応するメッセージディスパッチと配信イベントのインストールを調和させ、受信したメッセージはメッセージ受信ポートグループ内の全てのポートに同期して配信されるが、メッセージ受信ポートグループ内のポートの各親セルは受信した前記メッセージを自身の時間で検知し応答し、したがって、ポートグループはアプリケーションＡ内の並列プロセスの同期フォークとジョインとを実装するＴＩＣＣＴＭ−Ｐｐｄｅ内の機構を提供し、ＴＩＣＣＴＭ−Ｐｐｄｅはポートグループを定義し、グループ対グループ経路をインストールし、そのような経路上でのメッセージ交換のためのプロトコルを提供する機構を提供し、ＴＩＣＣＴＭ−Ｐｐｄｅはポートグループを定義し使用するメソッドを提供し、
メソッド（３．１２）、ポートベクトルの定義と使用用：セルはそれに対して定義されている１つまたは２つ以上のポートベクトルを有しており、各ポートベクトルは同じセルに付属している２つまたは３つ以上のポートからなり、ポートベクトル内のポートは全て同じ種類であって、全てのｇｅｎｅｒａｌＰｏｒｔまたは全てのｆｕｎｃｔｉｏｎＰｏｒｔのいずれかであって、表記Ｃｐは、セルＣのポートベクトルを指すために使用され、Ｃ．ｐ＝［Ｃ．ｐ１、Ｃ．ｐ２、．．．、Ｃｐ．ｋ］、ｋ≧２、Ｃ．ｐの親セルはそのポーリングサイクルの各１つにおいてＣ．ｐ内のポートをポーリングし、各Ｃ．ｐｉ、１≦ｉ≦ｋは別個の経路Ｃ．ｐｉ．ｐａｔｈｗａｙに接続されており、各Ｃ．ｐｉ、１≦ｉ≦ｋはメッセージをＣ．ｐｉ．ｐａｔｈｗａｙを介して互いに独立してＣ以外の別個のセルから受信し、各ポーリングサイクルにおいて、親セルはＣ．ｐの全てのポートがメッセージを受信した後で初めてポートＣ．ｐｉで受信したメッセージに応答し、そうでなければ、親セルはそのポーリングサイクルでポートベクトルＣ．ｐ内の全てのポートをスキップし、ポートベクトルＣ．ｐにおける最も単純なＴＩＰは以下の形態を有し、
非同期Ｃ．ｐ：ＴＩＰ（）＝（Ｃ．ｐ１：ｍＲ？（）＆Ｃ．ｐ２：ｍＲ？（）＆．．．＆Ｃ．ｐｋ：ｍＲ？（））｛Ｃ：ｒ（ｐ）；Ｃ．ｐ１：ｓ（）；．．．；Ｃ．ｐｋ：ｓ（）；｝  （Ｃ．５）または
同期Ｃ．ｐ：ＴＩＰ（）＝（Ｃ．ｐ１：ｍＲ？（）＆Ｃ.ｐ２：ｍＲ？（）＆．．．＆Ｃ．ｐｋ：ｍＲ？（））＊｛Ｃ：ｒ（ｐ）；Ｃ．ｐ１：ｓ（）；．．．；Ｃ．ｐｋ：ｓ（）；）  （Ｃ．６）、
ここで、Ｃ：ｒ（ｐ）はセルＣのプライベートメモリにおいて定義され実行されるｐｔｈｒｅａｄであって、Ｃ：ｒ（ｐ）は各ポートＣ．ｐｉ、１≦ｉ≦ｋで受信したメッセージを使用し、受信したメッセージは、別個のｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｐｉ．ｖＭ、１≦ｉ≦ｋに存在し、各Ｃ．ｐ：ＴＩＰ（）はＣ．ｐ内の各ポートに無条件に応答し、Ｃ．ｐ：ＴＩＰ（）は５種類のＴＩＰの任意の１つであり、ポートベクトルは、（発明を実施するための形態）のセクション６．６で説明するように、並列ｐｔｈｒｅａｄ計算の非同期フォークとジョインを実装し、セルによって実行される計算のアドホックな同期と調和とを実装するためにアプリケーション内で使用され、ＴＩＣＣＴＭ−Ｐｐｄｅはポートベクトルを定義し使用するメソッドを提供し、
メソッド（３．１３）、グループ対グループトランザクション用：Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の各経路はポートグループｐＧの１つまたは２つ以上のメッセージ送信ポートに接続されており、ｇＰ内の各ポートは別個の親セルに属しており、ｐＧ内のすべてのポートはグループ対グループ経路ｐＧ．ｐａｔｈｗａｙ内の同じエージェントａ０に接続されており、ｐＧ．ｐａｔｈｗａｙはｐＧ内のポートを他のポートグループｑＧ内の１つまたは２つ以上の他のポートのグループに接続し、ｐＧ内の全てのポートは、（発明を実施するための形態）のセクション７の図１９に示しているように、ｑＧ．ｐａｔｈｗａｙ≡ｐＧ．ｐａｔｈｗａｙ内の他のエージェントａ１に接続されており、（発明を実施するための形態）の図１７に示しているようにｐＧ≡ｑＧおよびａ０≡ａ１であることも可能であって、前記経路はそれぞれメッセージ送信ポートグループｐＧの親セルから、またはｑＧからメッセージ受信ポートグループｑＧまたはｐＧの親セルへ１方向だけにメッセージを常に送信し、ポートグループ内のｐＧ内のポートは常に結合サービス要求メッセージをポートグループｑＧ内のポートに送信し、ｑＧ内のポートは結合応答メッセージをポートグループｐＧとｑＧの同じｑＧ．ｐａｔｈｗａｙを通してｐＧ内のポートに常に返信し、したがって、ポートグループｐＧまたはｑＧ内のポートの全ての親セルによって共同で書かれ共同で同期して受信される結合メッセージだけを常に交換し、ｐＧ．ｐａｔｈｗａｙ≡ｑＧ．ｐａｔｈｗａｙ内のエージェントは前記経路を上での全てのそのような結合メッセージの調和したディスパッチと同期配信とを自動的に保証し、エージェントはポートグループｐＧまたはｑＧ内の各ポートによって送信または受信された各メッセージについてＳＭＳ（自己監視システム）内の対応しているメッセージディスパッチおよび配信イベントのインストールも自動的に調和させ、ｑＧ内の各ポートの親セルはサービス要求メッセージをそのポーリングサイクルの１つのそれ自体の時刻で検知し応答し、異なるセルのポーリングサイクルは必ずしも互いにまたはメッセージ配信時間に同期しておらず、ｑＧ内の各ポートは同じｑＧ．ｐａｔｈｗａｙ≡ｐＧ．ｐａｔｈｗａｙを介してｐＧ内のポートに応答を返し、ｐＧ内の全てのポートはそれらに関連付けられている同じｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐＧ．ｖＭ≡ｑＧ．ｖＭを有しており、ｐＧ内のポートとｑＧ内のポートとの間のメッセージ交換トランザクションは、ｐＧ内のポートの全ての親セルがｑＧ内のポートの親セルによって送信された結合応答メッセージを受信し検知した時に初めて完了し、ｐＧ内の各ポートがｑＧ内の各ポートに良好にマッチしている場合にｐＧはｑＧに良好にマッチしおり、したがって、ＴＩＣＣＴＭ−Ｐｐｄｅは良好にマッチしているグループ対グループ相互作用を定義し使用するメソッドを提供し、
メソッド（３．１４）、タイミングが予測可能な保証されたタイムリーなトランザクション完了用、ＴＩＣＣＴＭ−Ｐｐｄｅは以下によって予測可能な時間限界を備えているアプリケーションＡ内の各トランザクションのタイムリーな完了を可能にし、（ｉ）どのセルＣもそのポートＣ．ｐのいずれに配信されたサービス要求メッセージも検知し損なわないことを保証し、（ｉｉ）ＣがポートＣ．ｐでサービス要求の受信を検知した後、Ａ：ｃｅｌｌｓ（）内のセルＣの各ポートＣ．ｐでＣ．ｐ：ｔｉｐ（）のＴＩＰボディを自動的に起動し、（ｉｉｉ）Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内またはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）外の任意のプロセスまたはセルがいったん起動されるとＣ．ｐ：ｔｉｐ（）の実行に割り込みをかけることを可能にし、（ｉｖ）任意のポートＣ．ｐでサービス要求メッセージの受信によって開始される各トランザクションの完了を保証し、（ｖ）マルチ命令ストリーム実行、先読みスケジューリング、パイプライン処理、およびキャッシュされた実行またはＣＰＵ内の命令スケジューリングの任意の他の種類の装飾などの高速化技法を使用することに起因する可能性のあるＣＰＵ内の命令スケジューリング遅延を排除することによって、Ａ：ｃｅｌｌｓ（）内の各セルＣの各ポートＣ．ｐで受信した各サービス要求に対して予測可能なタイムリーな応答を保証し、これらの高速化技法は、高スループットを得るために必ずしもＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラム内に存在している必要は無く、高スループットは、低粒度の並列プロセスの任意のスケーリングによってＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラム内で達成され、任意のＣ．ｐ：ｔｉｐ（）の実行は１０〜１００マイクロ秒を超えずに完了し、（ｖｉ）トランザクションの完了は常にＴＩＰの実行のみが原因となり、（ｖｉｉ）トランザクションスケジューリングと調和とはＡ：ｃｅｌｌｓ（）内のセルのポーリングサイクル内のポートの順序付けとＡ：ｐｏｒｔｓ（）内のポートに配信されるメッセージの順序付けに起因するＴＩＰ実行の順序付けとに常に自動的に起因し、（ｖｉｉｉ）トランザクション同期はグループ対グループトランザクション内のメッセージ配信の自動同期と（発明を実施するための形態）のセクション６．６に記載されているアドホック同期技法の使用とに常に起因し、（ｉｘ）Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の全てのＴＩＰ実行は、自己同期と自己調和であって、（ｘ）実装はＡ：ｐｏｒｔｓ（）内の各ポートＣ．ｐについてのＣ．ｐ：ＴＩＰ（）の定義についてだけ責任を負い、様々な種類のＴＩＰについてのＴＩＣＣＴＭ−Ｐｐｄｅによって提供されるＴＩＰフォーマットは経路によって接続されるポートの各対が良好にマッチしており、Ａ：ｃｅｌｌｓ（）内の各セルＣについてのＣ：ＣＩＰ（）をＴＩＣＣＴＭ−ＰｐｄｅのＣＩＰ定義フォーマットと各Ｃ：ＣＩＰ（）の意図した機能に整合していることを保証し、（ｉｘ）Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内の全てのメッセージ交換は、自己同期と自己調和であって、（ｘｉｉ）これらの特徴の全ては１つになって、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の全てのトランザクションについてタイミングが予測可能な保証されたタイムリーなトランザクションの完了を実現し、したがって、ＴＩＣＣＴＭ−Ｐｐｄｅは保証されたタイムリーなトランザクションの完了のためのメソッドを提供し、
メソッド（３．１５）、チューンの保存用：保証されたタイムリーなトランザクションの完了は、今度は、互いに信号を交換するＡ：ｐａｔｈｗａｙｓ（）内の各経路内のコンポーネントの相互チューンを維持し保証し、一方向のメッセージ送信中の信号交換による経路内のコンポーネントの状態の変化によって、経路内の全てのコンポーネントは他方の方向のメッセージ送信の準備ができ、他方の方向のメッセージ送信は経路内の全てのコンポーネントの前記状態をそれらの良好にチューンされた初期状態に自動的にリセットし、したがって、ＴＩＣＣＴＭ−Ｐｐｄｅは保存をチューンするメソッドを提供し、
メソッド（３．１６）、ｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージの結合処理の調和用、ポートグループｐＧ内の全てのポートＣｉ．ｐはそれらに対して同期して配信された同一のメッセージを常に有しており、このメッセージはｒｅａｄＭｅｍｏｒｙ、Ｃｉ．ｐ．ｒｄ≡ｐＧ．ｒｄ内に存在しており、メッセージとｒｅａｄＭｅｍｏｒｙの両方がｐＧ内の全てのポートＣ．ｐに対して共通であって、ｐＧ内のポートの数は通常高々１０〜２０であって、ｐＧ内のポートの親セルがそれらの同期して配信された同じメッセージを処理し応答するために、それらのそれぞれを並列に実行し、ｐＧ内のＣｉ．ｐの親セルはそのポーリングサイクルの１つにおいてやがて自身の中の受信したメッセージに応答し、Ｃｉ．ｐの親セルは必ずしも受信したメッセージに同期して応答せず、しかし、各親セルＣｉは同じｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐＧ．ｖＭ≡Ｃｉ．ｐ．ｖＭ内のＣｉ．ｐ：ｔｉｐ（）をポートグループｐＧ内の全ての他のポートの親セルと並列に実行し、ｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐＧ．ｖＭ≡Ｃｉ．ｐ．ｖＭは、ポートＣｉ．ｐの全ての親セルＣｉに対して、そのような並列Ｃｉ．ｐ：ｔｉｐ（）実行時にデータを互いに交換するために、共通のスクラッチパッドメモリｐＧ．ｓｃｐ≡Ｃｉ．ｐ．ｓｃｐを提供し、親セルＣｉはＣｉ．ｐ：ｔｉｐ（）の実行時にｐＧ．ｓｃｐを通して前記データを互いに交換することによって正しい調和を達成し、ｐＧ内のポートＣｉ．ｐについてＣｉ．ｐ：ｔｉｐ（）内のｐｔｈｒｅａｄに対してｐＧ．ｓｃｐを使用してそのような調和を可能にするコンピュータプログラムを書いて、共通に共有されているデータの調和した更新を保護するために必要な箇所にｐｔｈｒｅａｄロックをインストールするのは実装者の責任であって、ポートグループのポートの親セルによって並列に実行されるそのようなｐｔｈｒｅａｄは、互いに依存している可能性のあるＡ：ｐｔｈｒｅａｄｓ（）内のｐｔｈｒｅａｄだけであって、したがって、ＴＩＣＣＴＭ−Ｐｐｄｅはセルグループ内のセルによる調和した合同並列処理の機構を提供し、
メソッド（３．１７）、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の完了用：Ａ：ＤＥＳＩＧＮ（）内のアブストラクトＴＩＰとＣＩＰとＡ：ｍｅｓｓａｇｅｓ（）内のアブストラクトＭｓｇサブクラスの連続しているリファインによってＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を完了するためのメソッドであって、そのようなリファインはアブストラクトｐｔｈｒｅａｄ、アブストラクト条件、およびアブストラクトＭｓｇサブクラスを実装するコンピュータプログラムからなり、全てのｐｔｈｒｅａｄはＴＩＣＣＴＭ−Ｐｐｄｅの規則に従って定義されており、全てのＭｓｇサブグラスはＴＩＣＣＴＭ−ＰｐｄｅのトップレベルアブストラクトＭｅｓｓａｇｅクラスで与えられているフォーマットを満たすように定義されており、リファインの任意の段階でＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）で定義されている全てのｐｔｈｒｅａｄ、条件、およびＭｓｇサブグラスの集合はそれぞれ、Ａ：ｐｔｈｒｅａｄｓ（）、Ａ：ｃｏｎｄｉｔｉｏｎｓ（）、およびＡ：ｍｅｓｓａｇｅｓ（）と呼ばれ、リファインの各段階において、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）はリファインのその段階までに定義されているＡ：ＴＩＣＣ−Ｎｅｔｗｏｒｋ（）、Ａ：ＴＩＰＳ（）、Ａ：ＣＩＰＳ（）、Ａ：ｍｅｓｓａｇｅｓ（）、Ａ：ｐｔｈｒｅａｄｓ（）、Ａ：ｃｏｎｄｉｔｉｏｎｓ（）、およびＡ：ｄｅｆｉｎｉｔｉｏｎｓ（）を含み、Ａ：ｄｅｆｉｎｉｔｉｏｎｓ（）は以下のメソッド（３．２０）において定義されており、ＴＩＣＣＴＭ−Ｐｐｄｅはアブストラクト仕様を連続してリファインしてＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を完了するメソッドを提供し、
メソッド（３．１８）、別個のセルに関連付けられているＴＩＰの相互の独立とそれらのＴＩＰに現れるｐｔｈｒｅａｄと条件との独立：Ａ：ｃｅｌｌｓ（）内の全てのセルＣのポートＣ．ｐの各ＴＩＰボディＣ．ｐ：ｔｉｐ（）またはポートベクトルＣ．ｐ：ｔｉｐ（）のＴＩＰボディは親セルＣによってのみ実行され、Ｃ．ｐ：ＴＩＰ（）とＣ．ｐ：ＴＩＰ（）に現れる全てのポートは同じ親セルＣに付属しており、ｖｉｒｔｕａｌＭｅｍｏｒｙＣ．ｐ．ｖＭはＣ．ｐ：ｔｉｐ（）を実行する実行環境を提供し、親セルＣのプライベートメモリはポートベクトルＴＩＰＣ．ｐ：ＴＩＰ（）を実行する実行環境を提供し、Ｃ．ｐ：ｔｉｐ（）またはＣ．ｐ：ＴＩＰ（）の実行時に、セルはセルＣで定義されているデータと他のメソッドと、Ｃ．ｐ：ｔｉｐ（）またはＣ．ｐ：ＴＩＰ（）に現れるポートと、Ｃ．ｐ：ｔｉｐ（）またはＣ．ｐ：ＴＩＰ（）に現れるポートに接続されている経路内のソフトウェアコンポーネント内で定義されており互いに対してチューンされているか付属しているメソッドのみを使用し、実行されたｐｔｈｒｅａｄは親セルＣおよび実行中に使用されるポートに関連付けられているデータのみを変更し、したがって、ポートグループのポートの親セルによる並列実行を調和させるためにスクラッチパッドメモリを通してデータを共有するｐｔｈｒｅａｄを除いて、別個のセルによるすべてのｐｔｈｒｅａｄとＴＩＰの実行は互いに独立しており、リファインの任意の段階で、前記ｐｔｈｒｅａｄと条件のコンピュータブログラムの確認用とスクラッチパッドを通してデータを共有するｐｔｈｒｅａｄと条件のコンピュータプログラムの共同確認用の以下のメソッド（３．２０）で記述されるｐｔｈｒｅａｄと条件の入力／出力の特徴付けを使用し、ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＰとｐｔｈｒｅａｄとを定義するコンピュータプログラムを確認するためにＴＩＰとｐｔｈｒｅａｄの相互独立を利用するメソッドを提供し、
メソッド（３．１９）、ソフトウェアコンポーネントの状態を記述するために使用される述語：任意のソフトウェアコンポーネントｘの状態は形式（ｘ．属性＝データ）、（ｘ．属性１＜ｙ．属性２）、（ｘ．属性１≦ｙ．属性２）、（ｘ．属性１∈ｙ．属性２）、または（ｘ．属性１⊂ｙ．属性２）等を有している述語のブール組み合わせによって定義され、ｘとｙとはセルＣまたはセルＣのポートＣ．ｐ、またはＣ．ｐ．ｐａｔｈｗａｙの任意のコンポーネントまたはＣｐ．ｒｄ：ｍｓｇ（）またはＣ．ｐ．ｗｒ：ｍｓｇ（）の任意のデータ項目であって、Ｃｐ．ｒｄ：ｍｓｇ（）はＣｐ．ｒｄ内のメッセージであって、Ｃ．ｐ．ｗｒ：ｍｓｇ（）はＣ．ｐ．ｗｒ内のメッセージであって、状態は入力／出力特徴付けの定義に使用され、コンピュータプログラムはｐｔｈｒｅａｄを定義し、状態はコンピュータプログラムによって実装される条件の定義にも使用され、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のソフトウェアコンポーネントの状態を特徴付けるメソッドを提供し、
メソッド（３．２０）、ｐｔｈｒｅａｄと条件の入力／出力特徴付け：任意のｐｔｈｒｅａｄ、ｐ（）に対して、その特徴付けは以下の形態であって、
｛〈ｐｒｅ−Ｃ？（）〉（ｔ１）＆〈ｍ：Ｃ？（）〉（ｔ１）｝［〈→ｐ（）（ｔ１）〉（ｔ２）］
｛ｐｏｓｔ−Ｃ？（）（ｔ２）＆ｍ’：Ｃ？（）（ｔ２）＆Ｒ（ｍ，ｍ’）（ｔ２）＆（（ｔ２）≦（ｔ１＋τｍａｘ（ｐ））｝、（Ｃ．７）
ｐｒｅ−Ｃ？（）とｐｏｓｔ−Ｃ？（）とはｐ（）に関連付けられている事前条件と事後条件であって、これらの条件はｐｔｈｒｅａｄｐ（）が実行されるソフトウェアコンポーネントの状態を指定し、ｍ：Ｃ？（）はｐ（）によって処理される入力メッセージｍを特徴付ける条件であって、ｍ’：Ｃ？（）はｐ（）によって生成される出力メッセージｍ’を特徴付ける条件であって、Ｒ（ｍ、ｍ’）は満たされるべきｍとｍ’との間の関係であって、’→’はｐ（）の実行を示す記号であって、ｐ（）の実行はｐｒｅ−Ｃ？（）とｍ：ｃ？（）とがｔｒｕｅになる時刻ｔ１と同時に開始され、ｐ（）の実行は全てのｐｏｓｔ−Ｃ？（）、ｍ’：Ｃ？（）、Ｒ（ｍ，ｍ’）および（（ｔ２）＜（ｔ１＋τｍａｘ（ｐ））がすべてｔｒｕｅになる時刻ｔ２で終了し、τｍａｘ（ｐ）はｐ（）の実行の完了にかかる最大時間であって、（Ｃ．７）の各条件は状態が評価される１つまたは２つ以上のソフトウェアコンポーネントの状態のブール組み合わせであって、状態はメソッド（３．１９）で定義されているようなものであって、ソフトウェアコンポーネントは全て互いに対して付属しているか、互いに対してチューンされているかのいずれかであって、ｐ（）についてのコンピュータプログラムは、ｐ（）の（Ｃ．７）で与えられる特徴付けがｐ（）が実行されるたびにｔｒｕｅの場合にだけ正しく、条件に対するコンピュータプログラムの定義は、そのコンピュータプログラムの評価がｔｒｕｅを返し、前記条件を定義している述語のブール組み合わせがｔｒｕｅの場合にだけ正しく、リファインプロセス中に定義されるＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の全てのｐｔｈｒｅａｄと条件との特徴付けの集合は、Ａ：ｄｅｆｉｎｉｔｉｏｎｓ（）と呼ばれ、ＴＩＣＣＴＭ−Ｐｐｄｅは実装内で使用される全てのｐｔｈｒｅａｄとメソッドとを特徴付ける対話ツールを提供し、
メソッド（３．２１）、セルの独立とプログラムのモビリティ：ＴＩＰの重要な特性は、ポートで定義されるＴＩＰのフォーマットがそれらのポートに接続されている経路の種類には無関係なことであって、したがって、ＴＩＰは通信を計算に統合しながら同時に通信を計算から分離し、全ての通信に対するプロトコルは計算を実行する同じセルによって実行され、メッセージを処理し構築するためにセルによって実行される計算とメッセージを送信するために同じセルによって実施される計算とには、メッセージを処理し構築するために使用されるｐｔｈｒｅａｄとメッセージを送信するために使用されるプロトコルとを定義するコンピュータプログラム内の違いを除いて、違いはなく、ＴＩＰは、前記処理中に共通なスクラッチパッドメモリを使用してポートグループ内の全てのポートに配信されたメッセージを共に処理するポートグループ内のポートの親セルではない全てのセルについてＡ：ｃｅｌｌｓ（）内の各セルＣによって実施される計算をＡ：ｃｅｌｌｓ（）内の他のセルによって実施される並列計算から分離もし、ポートのプロトコルはポートのｖｉｒｔｕａｌＭｅｍｏｒｙ内で常に実施され、セルＣの状態を定義するデータは、セルＣのプライベートメモリ内に保持されており、セルＣに付属しているポートの状態を定義しているデータはそれらのポートのそれぞれのｖｉｒｔｕａｌＭｅｍｏｒｙ内に保持されており、したがって、ｖｉｒｔｕａｌＭｅｍｏｒｙとセルＣのメモリとはそれらを使用するセルのプライベート実行環境を提供し、ポートグループのポートの親セルではないＡ：ｃｅｌｌｓ（）内の２つの別個のセルは同じｐｔｈｒｅａｄまたは同じプロトコルのコピーを別個のｖｉｒｔｕａｌＭｅｍｏｒｙまたはセルの別個のプライベートメモリ内で同時に並列に実行可能で、ポートグループのポートの親セルはポートグループ内の全てのポートによって共通に共有されている同じｖｉｒｔｕａｌＭｅｍｏｒｙ内で同じｐｔｈｒｅａｄを並列に同時に実行可能であって、ｐｔｈｒｅａｄとプロトコルの実行はこれらの実行を行うセルの状態とプロトコルに関連付けられている経路の状態だけを必ず変化させ、それによってＡ：ｃｅｌｌｓ（）内の前記セルによって実施される並列計算を互いに分離し、セルの独立によって、Ｃ１．ｐとＣ２．ｐとに関連付けられている別個のｖｉｒｔｕａｌＭｅｍｏｒｙを備えているセルＣ１とＣ２の２つのポートＣ１．ｐとＣ２．ｐとの間で並列計算システム内のプログラムモビリティが実現され、プログラムのモビリティはｖｉｒｔｕａｌＭｅｍｏｒｙＣ１．ｐ．ｖＭの全体の内容をＣ１．ｐ．ｖＭのコピーされている親セルＣ１の状態と共にｖｉｒｔｕａｌＭｅｍｏｒｙＣ２．ｐ．ｖＭに搬送することによって達成され、ＴＩＣＣＴＭ−Ｐｐｄｅはセルの独立とプログラムモビリティとに必要な条件が実装において破られていないことを保証するツールを提供し、ＴＩＣＣＴＭ−Ｐｐｄｅ内のアプリケーションの設計と実装とは自動的にセルの独立を実施し、プログラムモビリティを可能にし、
メソッド（３．２２）、セルの独立および従属ポート：Ａ：ｃｅｌｌｓ（）内のセルＣは複数のｇｅｎｅｒａｌＰｏｒｔ、ｆｕｎｃｔｉｏｎＰｏｒｔ、およびｉｎｔｅｒｒｕｐｔＰｏｒｔを有しており、セルＣのポートＣ．ｐまたはポートベクトルＣ．ｐはＣ．ｐ：ＴＩＰ（）またはＣＴＩＰ（Ｃｐ）の実行中に実施される計算がＣ．ｐまたはＣ．ｐに配信されるメッセージとＣ．ｐまたはＣ．ｐの状態にだけに依存している場合にだけ独立しており、全てのセルＣがそのような独立ポートまたはポートベクトルを２つ以上有することが可能であって、全ての他の場合において、Ｃのポートは互いに依存しており、ポートＣ．ｑに依存しているポートＣ．ｐに対する最も単純なＣ．ｐ：ＴＩＰ（）はＣ．ｐ：ｍＲ？（）｛Ｃ．ｐ：ｒ（Ｃ．ｑ）．ｓ（）；｝の形態を有しており、ｐｔｈｒｅａｄＣ．ｐ：ｒ（Ｃ．ｑ）はポートＣ．ｐで受信したメッセージを処理し応答するために使用され、ｐｔｈｒｅａｄＣ．ｐ：ｒ（Ｃ．ｑ）はその引数としてＣ．ｑを有しており、この引数によって、Ｃ．ｐで受信したメッセージに応答しながら、Ｃ．ｐ：ｒ（Ｃ．ｑ）がＣ．ｑとＣ．ｑ．ｖＭ内のメッセージの現在の状態ばかりでなくＣ．ｐとＣ．ｐ．ｖＭ内のメッセージの状態も使用することを可能にし、２つ以上のポートがそのような応答メソッドＣ．ｐ：ｒ（Ｃ．ｑ）の引数に現れてもよく、従属ポートでのＴＩＰの実行は（発明を実施するための形態）のセクション４．５に記載されているように調和しており、前記セクション４．５に記載されているように、特定の場合には従属および独立ポートを１つのセルからそのセルの他の複製へと移動させることが可能で、ＴＩＣＣＴＭ−Ｐｐｄｅは全てのポートの従属性に容易に対応できるようにＴＩＰを定義するメソッドを提供し、
メソッド（３．２３）、割り込み処理用：オペレーティングシステムがＡ：ｃｅｌｌｓ（）内の任意のセルＣによって実施されている計算に割り込むことはなく、セルＣはそのｉｎｔｅｒｒｕｐｔＰｏｒｔでの割り込みメッセージの受信によってのみ割り込まれ、そのような割り込みメッセージはＡ：ｃｅｌｌｓ（）内の他のセルによってセルＣに送信され、セルＣのｉｎｔｅｒｒｕｐｔＰｏｒｔでのメッセージの受信は、セルＣによって各ポーリングサイクルにおいて１度だけサービスを受けるか、各ｉｎｔｅｒｒｕｐｔＰｏｒｔがそれに対して割り込みメッセージが配信された時にセルＣをＣＣＰ（因果通信プリミティブ）を使用して実行（ｒｕｎ）しているＣＰＵに信号伝達し、ＣＰＵは連続しているＴＩＰ実行同士の間でだけそれに応答し、これは許容され、１０〜１００マイクロ秒の程度の低粒度ＴＩＰ実行のせいで、数百から数ナノ秒の範囲の低メッセージ交換レイテンシによってそのような低粒度の実行が可能であって、したがって連続しているＴＩＰ実行同士の間でだけ対応されるものの、割り込みに比較的素早く対応し、割り込みメッセージはセルＣのｉｎｔｅｒｒｕｐｔＰｏｒｔで受信され、セルＣに以下のいずれか１つを実行させ：（ｉ）セルＣの動作を現在のＴＩＰ実行の最後に中断し、中断された動作はセルＣの任意のポートでの次のメッセージの受信によって自動的に再開され、セル内での計算のそのような中断と再開の機構は、オペレーティングシステムの介入無しに自動的にセルＣ自体によって対応する、（ｉｉ）セルＣ内でＴＩＰ実行の順序を動的に変更する、または（ｉｉｉ）セルＣの動作を終了し、セルＣに割り当てられているＣＰＵを解放する、これらの全ては、連続しているＴＩＰの実行同士の間でだけ発生し、セルＣが送信前にそのポートで受信した、保留中でサービスをまだ受けていない全てのサービス要求メッセージに対してサービス行うようにするのは実装者の責任であって、ＴＩＣＣＴＭ−Ｐｐｄｅは、全ての割り込みが素早く対応されつつ、ＴＩＰ実行が割り込まれないようにメソッドを提供し、
メソッド（３．２４）、プログラムされたサスペンド用：セルＣ内のポートＣ．ｐの位置でのＣ．ｐ：ＴＩＰ（）内のｐｔｈｒｅａｄはＣ．ｐ：ＴＩＰ（）実行の途中でその実行をサスペンドするようにプログラムされており、セルＣはＣ．ｐ：ＴＩＰ（）でのその計算をサスペンドした後、即座に次のポートのポーリングに進み、そのようなプログラムされたサスペンドが発生するのは、Ｃ．ｐ：ＴＩＰ（）の実行を進行させる条件がサスペンドの時点で満たされないためであって、ポートＣ．ｐでサスペンドされた計算は前記必要な条件が満たされた時にセルＣの続くポーリングサイクルで自動的にレジュームし、ＴＩＣＣＴＭ−Ｐｐｄｅはそのようなプログラムされたサスペンドを実装するツールを提供し、
メソッド（３．２５）、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）における並列計算の開始：Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の設定に使用されるコンフィギュレータセルとも呼ばれる環境セルは、アプリケーションＡの計算の開始にも使用され、計算はユーザがＴＩＣＣＴＭ−ＧＵＩによって表示されている環境セルの画像をクリックし、表示されているメニューから計算を開始するオプションを選択することによって開始され、環境セルは、Ａ：ｃｅｌｌｓ（）の指定された開始セルの指定されたポートに予め定められているメッセージを送信することによって、この選択されたオプションに応答し、プロトコルは前記メッセージを指定されたセルに配信して、メッセージの配信前に自動的に指定されたセルを起動し、前記指定されたセルはＴＩＣＣＴＭ−Ｐｐｄｅによってそれらに割り当てられているＣＰＵ内で実行され、いったん起動されると、前記指定されたセルは必要に応じて自身を初期化し、そのような初期化中に必要に応じてＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の残りをインストールし、その後、前記指定されたセルの各々が、それらの、それぞれのポーリングサイクルを開始し、それらのポーリングサイクル中に、配信されたメッセージを検知し、それらに応答し、残りのＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）上で計算を生成し、ＴＩＣＣＴＭ−Ｐｐｄｅは前述のように並列計算を開始するツールを提供し、
メソッド（３．２６）並列計算の停止：Ａ：ｃｅｌｌｓ（）内のセルはそれらのそれぞれの割り当てられたＣＰＵ内で実行（ｒｕｎ）されるのに対して、Ａ：ｃｅｌｌｓ（）内の特定の指定されたセルは、計算を中止し、割り込みメッセージを環境セルに送信して環境セルに計算の中止を要求し、これらの中止要求は、環境セルのｉｎｔｅｒｒｕｐｔＰｏｒｔベクトルの異なるｉｎｔｅｒｒｕｐｔＰｏｒｔに到達し、割り込みメッセージは前記ポートベクトルのｉｎｔｅｒｒｕｐｔＰｏｒｔに異なる時刻に到達し、環境セルは全てのｉｎｔｅｒｒｕｐｔＰｏｒｔが割り込みメッセージを受信した後で前記ｉｎｔｅｒｒｕｐｔＰｏｒｔで初めて受信した割り込みメッセージに応答し、前記ベクトル内の全てのｉｎｔｅｒｒｕｐｔＰｏｒｔが割り込みメッセージを受信した時に、環境セルは終了割り込みメッセージをアプリケーションＡ内の全ての他のセルにｇｅｎｅｒａｌＰｏｒｔの１つを通してブロードキャストし、Ａ：ｃｅｌｌｓ（）内の各セルは終了割り込みメッセージを受信してこの終了割り込みメッセージの受信の検知時に自身を終了し、そのような各セルはそのポートで全てのまだサービスされていない保留メッセージをサービスし、終了前に終了割り込みメッセージを受信したことを知らせる応答メッセージを環境セルに返信した後に初めて終了し、Ａ：ｃｅｌｌｓ（）内のセルを環境セルに接続している経路上のエージェントは、そのような全ての応答を調和させ、Ａ：ｃｅｌｌｓ（）内の終了割り込みメッセージを受信した全てのセルがその割り込みメッセージに応答した後で初めて１つの肯定通知メッセージを環境セルに転送し、Ａ：ｃｅｌｌｓ（）内の他の全てのセルからこの肯定通知メッセージの受信時に、環境セルは必要に応じて自身を終了し、ＴＩＣＣ−ＰｐｄｅＴＭは前述のように並列計算を終了するツールを提供し、
メソッド（３．２７）、特権の定義用：Ａ：ｃｅｌｌｓ（）内の各セルは新しいポートＣ．ｑを自身に動的にインストールし、他のセルＣをＡ：ｃｅｌｌｓ（）にインストールし、前記ポートＣ．ｑと新しくインストールされたセルＣのポートＣ．ｐとの間に経路をインストールする能力を有しており、セルＣはそのような新しいセルと経路とをインストールする要求をアプリケーションＡ内のコンフィギュレータセルに送信し、アプリケーションが２つ以上のコンフィギュレータセルを有することが可能で、そのような要求を受信するコンフィギュレータは、そのようなインストールを要求した１つまたは２つ以上のセルがインストールを実施させるのに必要な特権を有しているかどうかをまず確認し、必要な特権が満たされている場合にだけインストール要求に対してサービスを行い、それから要求しているセルに対して適切な応答を返し、必要な特権が満たされていない場合、要求しているセルに特権違反について知らせ、新しいセルまたは新しい経路のインストールはインストール内のポートの数に依存して約２５０から３００マイクロ秒かかり、新しいポートのインストールは２ギガヘルツＣＰＵで約３０から５０マイクロ秒かかり、コンフィギュレータは特権に違反があった時に特権違反報告を発行し、実装者には、ＴＩＣＣＴＭ−Ｐｐｄｅの特権定義フォーマットを満たす態様で、アプリケーションＡにおいてセルをコンフィギュレータに接続するポートに関連付けられているＡ：ｃｅｌｌｓ（）内のセルについて特権を定義する責任があり、様々な種類の予備のセル、ポート、エージェント、ｖｉｒｔｕａｌＭｅｍｏｒｙ、および経路を予めインストールし、それらをアプリケーションのコンフィギュレータによって必要に応じて使用されるリザーブプール内に保持し、それによってそのようなコンポーネントの動的なインストールを相当に高速化することが可能であって、ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内のポートに関連付けられている特権を定義するツールを提供し、
メソッド（３．２８）、セキュリティ機能の定義用：（発明を実施するための形態）のセクション７で定義されているように、経路内のエージェントはポートが予め指定されているメッセージについてのセキュリティ条件を満たす場合にだけそのメッセージをそのポートに配信し、エージェントはそのポートで指定されているセキュリティ条件に違反した場合にセキュリティ違反報告を発行し、全てのメッセージ交換レイテンシは、そのようなセキュリティ確認に必要な時間が含まれており、アプリケーションＡの実装者にはＴＩＣＣＴＭ−Ｐｐｄｅの指定に従って必要なセキュリティ機能を定義する責任があって、ＴＩＣＣＴＭ−Ｐｐｄｅはセキュリティ機能を定義するツールを提供し、
メソッド（３．２９）、２次ストレージ装置とインターネットから外部データへのアクセス：各アプリケーションＡは２次ストレージ装置および／またはインターネットのデータへアクセするための専用のＡ：ｃｅｌｌｓ（）内の特定の数のセルを有しており、それらをそのようなデータを要求しているポートのｖｉｒｔｕａｌＭｅｍｏｒｙに配信し、セルはそのようなデータに対する要求をコンフィギュレータに送信し、コンフィギュレータはそのようなデータを要求したセルの特権を確認した後にデータ要求をそのようなデータを得るための専用のセルに転送するか、セルは専用の新しいｇｅｎｅｒａｌＰｏｒｔを自身にインストールし、ｇｅｎｅｒａｌＰｏｒｔからそのようなデータを得るための専用のセルへの経路を設定し、そのようなｇｅｎｅｒａｌＰｏｒｔと経路のインストールのための特権は、そのようなセルに対して事前に許可されており、セルは要求されたデータに対する事前に指定されたセキュリティ機能が満たされた場合にだけ新しく確立された経路を通してデータに対する要求を送信し、それに対して必要なデータを取得し、ＴＩＣＣＴＭ−Ｐｐｄｅは外部データにアクセスするツールを提供し、
メソッド（３．３０）、ブレークポイントを使用した実行（ｒｕｎ）中のアプリケーションの動的監視用：実行（ｒｕｎ）中のアプリケーションを監視するためにＴＩＣＣＴＭ−ＧＵＩを使用してＳＭＳ（自己監視システム）の動作を調べることは確かに可能であるが、そのような監視はＳＭＳによって登録されているイベントに関連付けられているデータをユーザに示すことはなく、したがって、ＳＭＳに登録されているイベントに関連付けられているデータを調べるためにユーザがブレークポイントをＴＩＰＣ．ｐ：ＴＩＰ（）に挿入する必要があり、ブレークポイントのインストールは本明細書では実行（ｒｕｎ）中のアプリケーションＡを動的に監視するためにＣ．ｐ：ＴＩＰ（）＝Ｃ．ｐ：ｇｕａｒｄ？（）｛Ｃ．ｐ：ｒ（）．ｓ（）；｝の形態を有している単純なＴＩＰについて示しており、そのようなブレークポイントの導入には、以下で示している修正されたＣ．ｐ：ＴＩＰ（）でのように、節Ｃ．ｇ：ｐＲ？（）｛Ｃ．ｇ：ｂ（）．ｓ（）；｝へのＣ．ｐ：ｔｉｐ（）の追加が必要であって、
修正されているＣ．ｐ：ＴＩＰ（）＝Ｃ．ｐ：ｇｕａｒｄ？（）｛Ｃ．ｐ：ｒ（）．ｓ（）；Ｃ．ｇ：ｐＲ？（）｛Ｃ．ｇ：ｂ（Ｃ，Ｃｐ）．ｓ（）；｝｝
Ｃ．ｇはセルＣの自由な未使用ｇｅｎｅｒａｌＰｏｒｔであって、経路、Ｃ．ｇ．ｐａｔｈｗａｙはポートＣ．ｇとＴＩＣＣＴＭ−ＧＵＩのコンフィギュレータのｆｕｎｃｔｉｏｎＰｏｒｔとの間に動的に確立され、ｐｔｈｒｅａｄＣｇ：ｂ（Ｃ，Ｃ．ｐ）はブレークポイントメソッドであって、Ｃｇ：ｂ（Ｃ，Ｃ．ｐ）はｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｃ．ｇ．ｖＭにセルＣとポートＣ．ｐの状態を読み書きし、また、Ｃｇ：ｂ（Ｃ，Ｃ．ｐ）の実行時に、Ｃ．ｐ：ＴＩＰ（）に関連付けられているメッセージをＣ．ｇ．ｖＭに書き込み、セルＣはＣ．ｇ．ｖＭメッセージに書き込まれているメッセージをＴＩＣＣＴＭ−ＧＵＩのコンフィギュレータに送信し、ＴＩＣＣＴＭ−ＧＵＩのコンフィギュレータは、受信したデータを画面に表示させ、そのようなブレークポイントを全ての種類のＴＩＰに挿入可能であって、このようにブレークポイントを使用することによって、アプリケーションＡ内で発生するイベントのタイミング混乱させることになり、そのためそのようなブレークポイントはアプリケーションＡの試験モードでだけ使用され、ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＰ内でそのようなブレークポイントを定義しインストールするツールを提供し、
メソッド（３．３１）、Ａ：ＴＩＣＣ−ｎｅｔｗｏｒｋ（）のサブネットワークのカプセル化用：ＴＩＣＣＴＭ−ＰｐｄｅはアプリケーションＡのサブシステムＢに関連付けられているＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）のサブネットワークを合成セルにカプセル化するメソッドを提供し、アプリケーションＡのサブシステムＢについて合成セルにカプセル化されたネットワークはＢ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）と呼ばれ、Ｂ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）をカプセル化する合成セルは合成セルＢと呼ばれ、Ｂは内部ポートと外部ポートの２種類のポートを有しており、
内部ポートはＢ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内のセルに付属しているポートであって、外部ポートは合成セルＢに付属しているポートであって、Ｂの外部ポートにブランチによって接続されている内部ポートを有しているＢ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内のセルの部分集合が存在し、各内部ポートはポートＢの１つの外部ポートにだけそのように接続されており、合成セルＢの内部のポートグループ内の内部ポートをＢ外部ポートに合成セルＢの内部エージェントを通して接続することが可能であって、外部ポートは受信した信号を接続されている内部ポートに即座に送信し、Ｂの外部ポートに接続されているＢ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内の別個の親セルは並列に外部ポートから受信した信号を検知し応答し、Ｂの外部ポートにそのように接続されているＢの全ての他の内部ポートは内部ＴＩＣＣＴＭ−Ｐｐｄｅｓｍ経路によって互いに接続されており、合成セルＢはＢの外部ポートに接続されている内部ポート以外のＢ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋの全てのコンポーネントをＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ内の他のセルから隠し、合成セルＢの各外部ポートＢ．ｐのＴＩＰ、Ｂ．ｐ：ＴＩＰ（）の集合はＢ．ｐに接続されている内部ポートで定義されているＴＩＰ、Ｃ．ｐ：ＴＩＰ（）の集合と同一であって、それぞれが自身の組み込みＳＭＳ（自己監視システム）を備えているそのようなカプセル化された合成セルＢは、ソフトウェアコンポーネントとして使用され、より大きなソフトウェアシステムにプラグインすることが可能で、合成セルＢの各外部ポートＢ．ｐを経路によってＢの外部のより大きなソフトウェアシステムのセルＤのポートＤ．ｑに接続し、ポートの各対（Ｂ．ｐ，Ｄ．ｑ）が良好にマッチしていることを確認し、そのようにカプセル化されたコンポーネントをより大きなネットワークへプラグインする能力によって、ソフトウェアサブシステムの再使用が可能になり、そのような合成セルの例は、（発明を実施するための形態）のセクション２．２に示しており、ＴＩＣＣＴＭ−ＰｐｄｅはＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）のサブシステムをカプセル化するツールを提供する、メソッド。
【請求項４】
Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を効率的に実行（ｒｕｎ）するためにマルチコアチップ内のＣＰＵの設計に関する以下の追加のメソッドをさらに有する、請求項１、２、または３に記載のメソッドであって、
メソッド（４．１）、ＣＰＵ設計と特別なＣＰＵ要求の簡略化用：ＴＩＣＣＴＭ−Ｐｐｄｅは、（発明を実施するための形態）のセクション４．６で説明したようなキャッシュ実行、複数の命令ストリーム実行、命令の先読みスケジューリング、パイプライン化処理などの高速化技法の使用の必要性を排除することによってＣＰＵの設計を簡略化し、しかし、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ｃｅｌｌｓ（）内のセルを実行（ｒｕｎ）する各ＣＰＵにおいて少数の特別な構成を必要とし、前記特別な構成は、（ｉ）ＣＰＵによって実行（ｒｕｎ）されているセルに付属しているポートに配信されるメッセージにタイムスタンプを付与することを可能にする各ＣＰＵ内のハードウェアクロックであって、タイムスタンプは、メッセージが前記ポートに配信された時に付与され、メッセージは前記セルのポートに並列に配信され、前記セルの複数のポートへの複数の同時メッセージ配信が可能であって、そのような複数のポートへの複数の同時のメッセージ配信には、メッセージ配信時にタイムスタンプを設定するために、前記セルの前記ポートによって同時に問い合わせされるハードウェアクロック用の構成が必要であって、（ｉｉ）そのようなＣＰＵの各々にＣＣＰ（因果通信プリミティブ）を実装するように要求し、（ｉｉｉ）ｉｎｔｅｒｒｕｐｔＰｏｒｔがＣＣＰ（因果通信プリミティブ）を使用して前記ｉｎｔｅｒｒｕｐｔＰｏｒｔの親セルを実行（ｒｕｎ）しているＣＰＵと直接通信できるように割り込み処理構成を要求し、ＣＰＵは前記セルの連続しているＴＩＰ実行の間でだけＣＣＰによって送信された受信した割り込み信号に応答し、（ｉｖ）単一のチップ内に複数のＳＭＰ（共有メモリマルチプロセッサ）を備えている各ＤＭＰ（分散メモリマルチプロセッサ）マルチチップにそのチップに統合されているＴＩＣＣＮＥＴＴＭも含めるように要求し、前記ＴＩＣＣＮＥＴＴＭはそのチップ内のＳＭＰを相互接続し、これらの要件は、ＣＰＵ設計を複雑化することはなく、しかし、チップ設計を複雑にし、簡略化されたＣＰＵ設計はマルチコアチップ内で達成可能なＣＰＵ密度を増加させ、したがって、並列計算を組織化し実行するためにＴＩＣＣＴＭ−Ｐｐｄｅによって提供されるツールは実行効率に妥協せずにＣＰＵ設計を簡単にし、
メソッド（４．２）、ｖｉｒｔｕａｌＭｅｍｏｒｙ構成の利用：１０キロワードから１メガワードを超えない小さいプライベートメモリだけを備えているＳＭＰ内の各ＣＰＵを設計し、しかし、各ＣＰＵに独立しているハードウェアメモリモジュールの集合のいずれか１つに動的に接続する能力をプログラマブルロジックネットワークを使用して実装し、これらのメモリモジュールはＳＭＭ（共有メモリモジュール）と呼ばれ、ＳＭＭはそのようなハードウェア装置のプール内に保持されており、プール内の各ＳＭＭは１０キロワードから１ギガワードの範囲のメモリ容量を有しており、プール内の各ＳＭＭは高々１６個のＣＰＵが同時にそれにアクセスできるようにし、ＳＭＭのｖｉｒｔｕａｌＭｅｍｏｒｙへの割り当ては、コンパイル時または実行（ｒｕｎ）時に行われ、アプリケーションＡのＡ：ｃｅｌｌｓ（）内の各セルＣの各ポートＣ．ｐは、親セルＣに割り当てられているＣＰＵをｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｃ．ｐ．ｖＭに割り当てられているＳＭＭに、Ｃ．ｐがセルＣにＣ．ｐ．ｖＭへのアクセスを許可した時にだけ、動的に接続し、アクセスが中止された時にＳＭＭからＣＰＵを接続解除し、場合によっては、また同じＣＰＵをセルＣの次のポートのサービスに関連付けられている他のＳＭＭに接続し、このスキームによって、メモリ干渉が減少した高速な共有メモリアクセスが可能になり、２５６以上程度の多数のＣＰＵを備えているマルチコアチップ内で実行（ｒｕｎ）されている並列共有メモリソフトウェアシステム内のメモリ競合を動的に最小化し、固有のデータ保護と、データプライバシーとシステムセキュリティを任意のアプリケーションに提供し、しかしこのスキームは、各ＳＭＭに対して１つの、複数のメモリバスを備えているメモリ構成を要求し、各ＳＭＭはそれらに接続されている独立して実行（ｒｕｎ）されているＣＰＵによって独立して同時にアドレス指定可能であって、プログラマブルロジックネットワークが実行（ｒｕｎ）時にＣＰＵとＳＭＭとの間に接続を効率的に動的に変更し、ＳＭＭは数十または数百から数ギガワードのサイズの大きな共有メモリを備えているＳＭＰ内の構成ＣＰＵの全ての有害な遺産をこれを限りに排除し、ＣＰＵ設計を単純化し、しかしチップ設計を複雑化し、同時に、本来的により高い効率、ソフトウェアセキュリティ、プライバシー、および保護に貢献し、したがって、ＴＩＣＣＴＭ−Ｐｐｄｅは任意のスケーラブルな安全で保護されている並列計算を可能にし、
メソッド（４．３）、非同期ハードウェアサブシステムのカプセル化用、設計、リファインを通した実装、正式な確認、および自己監視の同じ技法を任意の非同期ハードウェアシステムの実装に使用することが可能で、ＴＩＣＣＴＭ−Ｐｐｄｅカプセル化技法をサブシステムの合成セルへのカプセル化に使用することが可能で、そのような合成セルの各々は、自身のＳＭＳ（自己監視システム）を有しており、全てのカプセル化されたコンポーネントをハードウェアシステム内の他のコンポーネントから隠し、そのような各合成セル自体はハードウェアシステムコンポーネントとして使用され、合成セルの全ての外部ポートが接続されているより大きなシステムのポートに良好にマッチしている状態でより大きなハードウェアシステムにプラグインされ、それによってＴＩＣＣＮＥＴＴＭが埋め込まれているマルチコアチップの構成を促進し、したがって、ＴＩＣＣＴＭ−Ｐｐｄｅによって提供されるソフトウェアカプセル化方法はハードウェアシステムにも適用可能である、メソッド。
【請求項５】
請求項１、２、３、または４に記載のメソッドであって、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を正式に確認する以下のメソッドをさらに有し、
メソッド（５．１）、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）からのＡ：ＡＬＬＥＯＰＳ（）の導出用：メソッドは、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）のリファインの各段階でＡ：ＤＥＳＩＧＮ（）とＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）から設計と実装で指定された計算のＡＬＬＥＯＰ（許容イベント発生パターン）モデルを自動的に導出し、これらのモデルはＡ：ＤＥＳＩＧＮ（）とＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内で暗示的な全てのイベントクラスを明示的にし、前記イベントクラスの因果チェーンを示し、モデルは、設計と実装において指定されている計算内で発生する可能性のあるイベントクラスのパターンも示し、ＡＬＬＥＯＰＳ内の各イベントクラスの複数のイベントインスタンスはＡの実行（ｒｕｎ）中に計算内で発生し、ＡＬＬＥＯＰＳには２種類のイベントクラスが存在し、一方の種類は形態Ｘのアクションイベントクラスと呼ばれ、アクションイベントはプログラミング言語におけるステートメントの評価か、条件の評価か、ｐｔｈｒｅａｄの評価であって、他方の種類のイベントクラスは、通信イベントクラスと呼ばれ、メッセージを送信するポートＣ．ｐについてはＣ．ｐＳ［ｔ（Ｃｐ，＃）］、メッセージを転送するポートＣ．ｐについてはＣ．ｐＦ［ｔ（Ｃ．ｐ，＃）］、メッセージを他のポートＣ’．ｑに配信するＣ．ｐについてはＣ’．ｑＤ［ｔ（Ｃ．ｐ，＃）］の形態を有しており、通信イベントクラスに現れる項ｔ（Ｃｐ，＃）はタイムマップと呼ばれ、ｔ（Ｃｐ，＃）は、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の実行（ｒｕｎ）時に、前記イベントクラスＣ．ｐＳ、Ｃ．ｐＦ、またはＣ．ｑＤのインスタンスが発生する時間インスタンスｔ１＜ｔ２＜．．．＜ｔｎ、ｎ＞０のシーケンスを指し、数の記号＃は０≦＃＜ｎ≧０であって、（ｎ−１）はポートＣ．ｐを含んでいるタイムマップがＣＩＰ（セル相互動作プロトコル）内で発生する回数の総数であって、記号ＸとＹとは以降では任意の前記イベントクラスを指すのに使用され、ＡＬＬＥＯＰ内のアクションイベントクラスまたは通信イベントクラスＸとＹのいくつかの対は、ＸＣ（Ｘ、Ｙ）→Ｙの形態を有している重み付き有向因果リンクによってリンクされており、ＡＬＬＥＯＰ内のイベントクラスの他の対は重み付け無しの因果リンクＸ（ｔ）→Ｙ（ｔ）でリンクされており、ＡＬＬＥＯＰのイベントクラスのさらに他の対は因果リングでリンクされておらず、重みＣ（Ｘ，Ｙ）を備えている因果リンクは以下のように解釈され、ＡＬＬＥＯＰ内の各イベントクラスの複数のインスタンスｘ（ｔ）、ｔ＝ｔ１＜ｔ２＜．．．＜ｔｎ、ｎ＞１はＡが実行（ｒｕｎ）されている時に発生し、ＴＩＣＣＴＭ−Ｐｐｄｅは（発明を実施するための形態）のセクション２で定義し図示しているように、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）からＡ：ＡＬＬＥＯＰＳ（）を自動的に導出するメソッドを提供し、
メソッド（５．２）、ポートＡＬＬＥＯＰの導出用：メソッドはポートＡＬＬＥＯＰ、Ｃ．ｐ：ＡＬＬＥＯＰ（）をＣ．ｐ：ＴＩＰ（）から自動的に導出し、ポートＡＬＬＥＯＰはＡ：ＴＩＰＳ（）内のＣ．ｐ：ＴＩＰ（）についてのＡＬＬＥＯＰモデルであって、Ｃ．ｐ：ＡＬＬＥＯＰ（）は以下の形態を有し、
Ｃ．ｐ：ＡＬＬＥＯＰ（）＝Ｃ．ｐ：ＡＬＬＥＯＰ−ｇｕａｒｄ？（）｛Ｃ．ｐ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝  （Ｃ．８）
Ｃ．ｐ：ＴＩＰ（）からのＣ．ｐ：ＡＬＬＥＯＰ（）の自動導出メソッドは、記述されているメソッドを説明するために、ＢＩＬＬ−ＢＥＮアプリケーションと呼ばれるサンプルアプリケーションを使用して（発明を実施するための形態）のセクション２に記述されており、Ｃ．ｐ：ＡＬＬＥＯＰ（）は、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）のＡＬＬＥＯＰの便利にモジュラー化されている記述を提供し、
メソッド（５．３）、ＡＬＬＥＯＰグラフの構築用：ＢＩＬＬ−ＢＥＮ：ＡＬＬＥＯＰＳ（）内の全てのポートＡＬＬＥＯＰＣ．ｐ：ＡＬＬＥＯＰ（）のグラフを（発明を実施するための形態）のセクション２の図６Ａに示しており、グラフは、ポートＡＬＬＥＯＰの対、ＢＩＬＬ−ＢＥＮ：セル（）の別個のセルＣ１とＣ２に付属しているポートＣ１．ｐとＣ２．ｑのＣ１．ｐ：ＡＬＬＥＯＰ（）とＣ２．ｑ：ＡＬＬＥＯＰ（）を重み付き有向因果リンクｃ（Ｘ，Ｙ）→または重み無しの有向因果リンク→を使用して、ＢＩＬＬ−ＢＥＮ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）とＢＩＬＬ−ＢＥＮ：ＴＩＰＳ（）のＴＩＰにおいて指定されている経路相互接続に整合するように、リンクすることによって得られ、因果リンクは、非再帰的、推移的、非対称の因果関係を表し、これらの有向因果リンクを解釈するメソッドは、以下のメソッド（５．４）において説明され、相互接続している因果リンクと通信イベントクラスに関連付けられているタイムマップを備えているポートＡＬＬＥＯＰの全てのイベントクラスは、ＴＩＣＣＴＭ−ＰｐｄｅによってＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の仕様から自動的に導出され、前記図６ＡのグラフはＢＩＬＬ−ＢＥＮ：ＡＬＬＥＯＰＳ（）を表しており、ＴＩＣＣＴＭ−Ｐｐｄｅは任意のアプリケーションＡについてＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）からＡ：ＡＬＬＥＯＰＳ（）を同様に自動的に導出し、任意のアプリケーションＡについて前記図６Ａに示しているようなＡ：ＡＬＬＥＯＰＳ（）のグラフ表現を構築するメソッドを提供し、
メソッド（５．４）、ＡＬＬＥＯＰグラフ内の因果リンクの解釈用：各重み付き有向因果リンクは条件付き因果リンクを表しているメソッド（５．３）で導入されたＡＬＬＥＯＰグラフに現れるＸｃ（Ｘ，Ｙ）→Ｙの形態を有し、Ｘ→Ｙの形態の各有向因果リンクは無条件因果リングを表している前記ＡＬＬＥＯＰグラフ内に現れ、これらの因果リンクは以下のように解釈され：Ｘ（ｔ１）→Ｙ（ｔ２）のように書かれる、イベントクラスＸの時刻ｔ１のイベントインスタンスＸ（ｔ１）の発生がイベントクラスＹのイベントＹ（ｔ２）をＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の実行（ｒｕｎ）における後の時刻ｔ２に発生させた場合、Ｙ（ｔ２）がＹのインスタンスであって、条件付き因果リンクの場合はＣ（Ｘ、Ｙ）が時刻ｔ２においてｔｒｕｅであって、無条件因果リンクの場合はインスタンスＹのインスタンスＹ（ｔ２）が無条件に発生するように、条件付き因果リンクＸＣ（Ｘ，Ｙ）→Ｙまたは無条件因果リンクＸ→ＹがＡ：ＡＬＬＥＯＰＳ（）のグラフ表現に存在しなければならず、τ（Ｘ、Ｙ）は２つのイベントＸ（ｔ１）とＹ（ｔ２）の発生の間の最大許容遅延であって、ＴＩＣＣＴＭ−Ｐｐｄｅにおける並列プログラムの実行特性によって、イベントの発生を正確に定義された時間限界で予測することが可能になって、上限τ（Ｘ，Ｙ）がＡの実装者によってｐｔｈｒｅａｄとプロトコルの意図したまたは計測された実行（ｒｕｎ）時間からまず予測され、その後、完成したＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を使用した実験後に確認され、ＴＩＣＣＴＭ−Ｐｐｄｅは正確にＡＬＬＥＯＰグラフを解釈するツールを提供し、
メソッド（５．５）、ｃａｕｓａｌｎｅｔの構築用：Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の実行（ｒｕｎ）中にＴＩＣＣＴＭ−ＰｐｄｅのＳＭＳ（自己監視システム）によって自動的に生成された因果リンクを備えているＡＬＬＥＯＰの通信イベントクラスだけのイベントインスタンスのネットワークはその実行（ｒｕｎ）時のＡのｃａｕｓａｌｎｅｔと呼ばれ、アプリケーションＡの任意の実行（ｒｕｎ）時に発生する可能性のある全ての考え得るｃａｕｓａｌｎｅｔの集合の表現はＡ：ＣａｕｓａｌＮｅｔ（）と呼ばれ、ＢＩＬＬ−ＢＥＮの例についてのｃａｕｓａｌｎｅｔを（発明を実施するための形態）の図６Ｂと６Ｃに示しており、Ａの異なる実行（ｒｕｎ）は異なるｃａｕｓａｌｎｅｔを生成するが、これは異なる条件が異なる実行（ｒｕｎ）においてｔｒｕｅになるためで、全てのＡＬＬＥＯＰノードがＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の所与の実行（ｒｕｎ）においてｃａｕｓａｌｎｅｔ内で発生するインスタンスを有しているわけではなく、
（Ａ：ＣａｕｓａｌＮｅｔ（）ｓａｔｉｓｆｉｅｓＡ：ＡＬＬＥＯＰＳ（））は以下の論理条件がｔｒｕｅの場合にだけｔｒｕｅであって、
（Ａ：ＣａｕｓａｌＮｅｔ（）  ｓａｔｉｓｆｉｅｓ  Ａ：ＡＬＬＥＯＰＳ（））⇔
［∀（Ｃｏｍｍｕｎｉｃａｔｉｏｎ−Ｅｖｅｎｔ  Ｘ［ｔ（Ｃ．ｐ，＃）］）（Ｘ［ｔ（Ｃ．ｐ，＃）］  ｏｃｃｕｒｒｉｎｇＩｎ  Ａ：ＡＬＬＥＯＰＳ（））
∃（Ｘ，Ｙ）∃（ＴＩＭＥｔ１，ｔ２）（Ｘ（ｔ１）  ｉｎｓｔａｎｃｅＯｆ  Ｘ）＆
（（Ｘ（ｔ１）→Ｙ（ｔ２））  ｏｃｃｕｒｒｉｎｇ−ｉｎ  Ａ：ＣａｕｓａｌＮｅｔ（））］
［∃Ｃｏｍｍｕｎｉｃａｔｉｏｎ−Ｅｖｅｎｔ  Ｙ［ｔ（Ｃ．ｑ，＃）］）∃（ＴＩＭＥ−ＩＮＴＥＲＶＡＬ  τ（Ｘ，Ｙ））
（（Ｘ［ｔ（Ｃ．ｐ，＃）］→．．．→Ｙ［ｔ（Ｃ’．ｑ，＃）］）  ｏｃｃｕｒｓＩｎ  Ａ：ＡＬＬＥＯＰＳ（））＆
（Ｙ（ｔ２）  ｉｎｓｔａｎｃｅＯｆ  Ｙ［ｔ（Ｃ．ｑ，＃）］）＆
（ｔ２＜ｔ１＋τ（Ｘ［ｔ（Ｃ．ｐ、＃）］，Ｙ［ｔ（Ｃ．ｑ，＃）］））］  （Ｃ．９）
ステートメント（Ｃ．９）はアプリケーションＡのＡ：ＣａｕｓａｌＮｅｔ（）が、Ａ：ＡＬＬＥＯＰＳ（）内の通信イベントクラスＸ［ｔ（Ｃｐ，＃）］の各通信イベントインスタンスＸ（ｔ１）がＡ：ＡＬＬＥＯＰＳ（）を満たし、各因果リンク（Ｘ（ｔ１）→Ｙ（ｔ２））がＡ：ＣａｕｓａｌＮｅｔ（)内で発生することを表明し、通信イベントクラスＹ［ｔ（Ｃ．ｑ，＃）］が、Ｙ（ｔ２）がＹ［ｔ（Ｃ．ｑ，＃）］、ｔ２≦ｔ１＋τ（Ｘ［ｔ（Ｃ．ｑ，＃）］、Ｙ［ｔ（Ｃ．ｑ、＃）］）のインスタンスであるように、因果チェーン（Ｘ［ｔ（Ｃ．ｐ，＃）］→．．．→Ｙ［ｔ（Ｃ．ｑ，＃）］）を備えているＡ：ＡＬＬＥＯＰＳ（）のグラフ内に存在し、因果チェーン（Ｘ［ｔ（Ｃ．ｐ，＃）］→．．．→Ｙ［ｔ（Ｃ．ｑ，＃）］）は、ＡＬＬＥＯＰ内にイベントクラスＹ［ｔ（Ｃ．ｑ，＃）］にイベントクラスＸ［ｔ（Ｃ．ｐ，＃）］から向かう因果リンクによってリンクされている１つまたは２つ以上のイベントクラスのシーケンスが存在することを意味し、正確に指定された時間の限界内でｃａｕｓａｌｎｅｔ内のイベントの発生を予測する能力によって、ＴＩＣＣＴＭ−Ｐｐｄｅプラットフォームを自己監視アプリケーションを使用して実時間サイバー物理並列ソフトウェアシステムの設計、開発、実装、確認、および実行（ｒｕｎ）に使用することが可能になって、ＴＩＣＣＴＭ−Ｐｐｄｅはｃａｕｓａｌｎｅｔを構築し、前記ｃａｕｓａｌｎｅｔが（Ｃ．９）の意味でそれらに関連付けられているＡＬＬＥＯＰを満足することを検証するツールを提供し、
メソッド（５．６）、Ａ：ＡＬＬＥＯＰＳ（）からのＡ：ＴＲＡＣＥＳ（）の自動導出用：トレースは一般にプログラムが実行（ｒｕｎ）された時に何が発生したかを記述し、異なるプログラミング分野はトレースの記述に異なるフォーマットを使用し、ＴＩＣＣＴＭ−Ｐｐｄｅ内のトレースは、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）が実行（ｒｕｎ）中に発生するものを記述するだけではなく、アプリケーションＡの実行（ｒｕｎ）中に発生するアクションイベントの意味論を指定し、ステートメント（Ｃ．７）と（発明を実施するための形態）のセクション２とセクション５に記述され、（発明を実施するための形態）の付録ＩからＩＩＩに示している定義に図示されているように、意味論は、所与の実行（ｒｕｎ）時に発生する可能性のある選択肢イベントの集合における選択肢が発生する条件によって指定されており、各アクションイベントについて、そのアクションイベントが発生するにはｔｒｕｅでなければならないアプリケーションＡ内の論理的な事前条件と、アクションイベントが発生した後でｔｒｕｅでなければならないアプリケーションＡ内の論理的な事後条件とを指定しており、ポートＡｌｌＥＯＰＣ．ｐ：ＡＬＬＥＯＰ（）のトレースは、Ｃｐ：ｔｒａｃｅ（ｔｐ）と呼ばれ、ｔｐはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の実行（ｒｕｎ）時にＣｐ：ｔｒａｃｅ（ｔｐ）内のイベントが発生し始める可能性のある仮想時刻であって、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の仕様とＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）で与えられるＡ：ｄｅｆｉｎｉｔｉｏｎｓ（）の仕様とを使用してＡ：ＡＬＬＥＯＰＳ（）から自動的にＡ：ＴＲＡＣＥＳ（）を導出する方法を提供し、ＴＩＣＣＴＭ−ＰｐｄｅはトレースをＡＬＬＥＯＰから自動的に導出するツールを提供し、
メソッド（５．７）、Ａ：ＴＲＡＣＥＳ（）からのＡ：ＥＣＴ−ｎｅｔｗｏｒｋ（）の自動導出用：ポートＥＣＴ（ポートイベント特徴付け表）、Ｃ．ｐ：ＥＣＴ（ｔｐ）は、Ａ：ｐｏｒｔｓ（）内のポートＣ．ｐについて、Ｃ．ｐ：ｔｒａｃｅ（ｔｐ）からＴＩＣＣＴＭ−Ｐｐｄｅによって自動的に導出され、Ｃ．ｐ：ＥＣＴ（ｔｐ）はＣ．ｐ：ｔｒａｃｅ（ｔｐ）内で発生するイベントをＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の実装者によって与えられるＣＴＬ表明（因果時間言語表明）を正式に提供するのに便利な表形式で表し、ＥＣＴネットワークは指定された初期条件を備えており、Ａ：ＣＩＰＳ（）のＣＩＰで定義されているポーリングの順番とＡ：ＡＬＬＥＯＰＳ（）のＣ．ｐ：ＡＬＬＥＯＰ（）で定義されているメッセージ交換に従って相互接続されている、ポートＥＣＴ、Ｃ．ｐ：ＥＣＴ（ｔｐ）の任意の集合のネットワークであって、（発明を実施するための形態）のセクション６の表ＩからＶに示しているように、Ａ：ＥＣＴ−ｎｅｔｗｏｒｋ（）はＡ：ｐｏｒｔｓ（）の全てのＣ．ｐに対するＣ．ｐ：ＥＣＴ（ｔｐ）を含んでいるネットワークであって、ＴＩＣＣ−ＰｐｄｅＴＭはＥＣＴネットワークからトレースを自動的に導出するツールを提供し、
メソッド（５．８）、検証の設計用：ＴＩＣＣＴＭ−Ｐｐｄｅは、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）、Ａ：ＴＩＰＳ（）、およびＡ：ＣＩＰＳ（）のアブストラクト定義を使用してＡ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）と呼ばれるＡ：ＤＥＳＩＧＮ（）のＡＬＬＥＯＰモデルを自動的に導出し、Ａ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）は、Ａ：ＤＥＳＩＧＮ（）内で暗示的な全てのアクションと通信イベントクラスとイベントクラスの因果チェーンと明示的にし、Ａ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）をＡ：ＤＥＳＩＧＮ（）から導出するメソッドが定義され、（発明を実施するための形態）のセクション２に図示されており、Ａ：ｄｅｓｉｇｎＴＲＡＣＥＳ（）はＡ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）から自動的に導出され、Ａ：ｄｅｓｉｇｎＴＲＡＣＥＳ（）をＡ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）から自動的に導出するメソッドは前記セクション２でも定義され図示されており、Ａ：ｄｅｓｉｇｎＴＲＡＣＥＳ（）は使用者が一時的にタイミングとタイミング限界とを全てのイベントクラスに関連付け、Ａ：ｄｅｓｉｇｎＴＲＡＣＥＳ（）内のイベントクラスだけでなくイベントクラスの因果チェーンの同期と調和を検証することを可能にし、Ａ：ｄｅｓｉｇｎＥＣＴ−ｎｅｔｗｏｒｋ（）はＡ：ｄｅｓｉｇｎＴＲＡＣＥＳ（）から自動的に導出され、Ａ：ｄｅｓｉｇｎＥＣＴ−ｎｅｔｗｏｒｋ（）は設計を正式に確認するために使用され、確認基準は実装者によってＣＴＬ言語の表明として提供され、すべてのそのような確認されたＣＴＬ表明の集合はＡ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）と呼ばれ、ＴＩＣＣＴＭ−ＰｐｄｅはＡ：ＤＥＳＩＧＮ（）を確認するためにＡ：ｄｅｓｉｇｎＥＣＴ−ｎｅｔｗｏｒｋ（）を使用してＡ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）内でＣＴＬ表明用の正式な証明を生成し、ＴＩＣＣＴＭ−Ｐｐｄｅは正式な証明の作成中にユーザと対話し、ユーザは、必要な場合、追加のＣＴＬ表明を提供することによって証明探索用の手引きを提供し、これらを行うためのメソッドは（発明を実施するための形態）のセクション６に図示されており、正式な確認方法は必要なＣＴＬ表明がＡ：ＤＥＳＩＧＮ（）内で有効ではないことがわかった時に反例を対話的に生成するために使用され、実装者は必要に応じて反例を使用して設計を改定し、設計を再確認し、そのような確認はＡ：ＤＥＳＩＧＮ（）にデッドロックやライブロックが無いことを保証し、Ａ：ＤＥＳＩＧＮ（）内のプログレスを保証するためにも使用され、デッドロックは発生した場合にアプリケーションＡ内に全ての動作を停止させ、ライブロックは発生した場合には、Ａのサブシステムを、他のサブシステムがそれらのタスクを実施するために正常に動作しているのに対して、フリーズさせて関連付けられているタスクの実行を妨げ、プログレスは、アプリケーションＡの実行（ｒｕｎ）中に、発生しているイベントクラスのイベントインスタンスの因果チェーンが（Ｃ．９）で定義されているようなＡ：ｄｅｓｉｇｎＡＬＬＥＯＰＳ（）の仕様を常に満足することを保証し、ＴＩＣＣＴＭ−ＰｐｄｅはＥＣＴネットワーク上でＣＴＬ表明を評価することによって所与の設計を対話的に検証するためのツールを提供し、
メソッド（５．９）、ｐｔｈｒｅａｄの正しさの検証用：共通のスクラッチパッドを使用して相互作用するｐｔｈｒｅａｄ用のコンピュータプログラムの各集合は、正しいことがまとめて正式に検証され、全ての他のｐｔｈｒｅａｄに対するコンピュータプログラムは正しいことが独立して正式に検証され、ｐｔｈｒｅａｄまたは条件を実装する各コンピュータプログラムはコンピュータプログラムがステートメント（Ｃ．７）で与えられる入力／出力特徴を満足することが正式に検証され、これは、各ｐｔｈｒｅａｄが約１０から１００マイクロ秒だけ実行（ｒｕｎ）される短いコンピュータプログラムであることから可能であって、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の正しさを証明するには、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の全てのｐｔｈｒｅａｄの正しさが必要であって、ＴＩＣＣ−ＰｐｄｅＴＭはｐｔｈｒｅａｄを対話的に検証するツールを提供し、
メソッド（５．１０）、実装者によって与えられるＣＴＬ表明の証明用：ＴＩＣＣＴＭ−ＰｐｄｅはＣＴＬ表明（因果時間ロジック表明）の対話型の証明を生成するメソッドを提供し、ＣＴＬ表明の構造は（発明を実施するための形態）のセクション５．２の最後の段落で非正式に定義されており、ＣＴＬ表明は（発明を実施するための形態）のセクション６に記述されており、ＣＴＬ表明の具体的な構文はＣＴＬ表明の明確な解釈が存在することほど重要ではなく、実装者によって与えられるＣＴＬ表明はＥＣＴネットワーク上でそれらを評価することによって確認され、ＥＣＴネットワーク上でのＣＴＬ表明の評価によって、（発明を実施するための形態）のセクション６で定義され説明されているマッチ基準に従って所与のＣＴＬ表明にマッチするＥＣＴネットワーク内のイベントの因果チェーンが生成され、所与のＣＴＬ表明にマッチするＥＣＴネットワーク内でイベントインスタンスの因果チェーンを生成するプロセスは証明確認プロセスと呼ばれ、証明確認の手引きはユーザによって提供され、そのような対話型の証明確認ためのメソッドは（発明を実施するための形態）のセクション６で説明されており、ＥＣＴネットワークを使用して確認されたＣＴＬ表明はＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の有効な特性であるが、それは証明確認で使用されるＥＣＴネットワークが全て自動的にＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）からすべて自動的に導出されるからで、有効なＣＴＬ表明はＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の経路によって接続されているポートの各対の良好にマッチした特性を最終的に検証し、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の経路によって接続されているポートの対の良好にマッチしている特性は以下の証明に従い：（ｉ）ｐｔｈｒｅａｄの正しさの正式な証明、（ｉｉ）Ａ：ＣａｕｓａｌＮｅｔ（）内の各ｃａｕｓａｌｎｅｔを示しているＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のプログレスの正式な証明は前述のステートメント（Ｃ．９）で定義されているようにＡ：ＡＬＬＥＯＰＳ（）を常に満足し、（ｉｉｉ）Ａ：ＤＥＳＩＧＮ（）についてのＡ：ｒｅｑｕｉｒｅｍｅｎｔ（）内のＣＴＬ表明の正式な証明、（ｉｖ）Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）にデッドロックが無いという正式な証明、（ｖ）Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）にはライブロックが無いという正式な証明、そのような証明の例は（発明を実施するための形態）のセクション６に示しており、（ｖｉ）プログレスＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の正式な証明、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の確認は、究極的には全ての確認されたＣＴＬ表明の全ての集合に依存しており、ＴＩＣＣ−ＰｐｄｅＴＭはＥＣＴネットワークにわたってＣＴＬ表明を対話的に検証するためのツールを提供し、
メソッド（５．１１）、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を確認するＣＴＬ表明を識別するための実装者への手引きの提供用：Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を確認するために必要なＣＴＬ表明を定義するための実装者への手引きは、Ａ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）と以下のステートメント（Ｃ．９）で指定されている要件とによって提供され、Ａ：ｒｅｑｕｉｒｅｍｅｎｔｓ（）はアプリケーションＡの設計と実装の前の実装者によるＣＴＬ言語でのアプリケーションＡに対する要件の論理的な指定であって、設計とリファイン中に更新可能であって、ステートメント（Ｃ．９）はＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の正しさを検証するのに必要なＣＴＬ表明を指定するために手引きを提供し、
［（Ａ：ＣａｕｓａｌＮｅｔ（）ｓａｔｉｓｆｉｅｓＡ：ＡＬＬＥＯＰＳ（））＆
（Ａ：ＡＬＬＥＯＰＳ（）ｓａｔｉｓｆｉｅｓＡ：ｒｅｑｕｉｒｅｍｅｎｔｓ（））］⇔
ｐｌｅｍｅｎｔａｔｉｏｎ（）ｉｓ−ｃｏｒｒｅｃｔ）  （Ｃ．１０）
実装者は基準（Ｃ．１０）と、経路によって相互接続されているポートの全ての対は、必要なＣＴＬ表明の確認を見落としていないことを確認するために良好にマッチしていなければならないという要件とを使用し、ＴＩＣＣＴＭ−Ｐｐｄｅは良好にマッチしていると確認されていない経路によって接続されているポートを識別することによってユーザを支援する方法を提供し、ＴＩＣＣＴＭ−Ｐｐｄｅは実装者が所与のＣＴＬ表明がＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）においてなぜ有効ではないのかを説明する反例を対話的に識別することも支援し、実装者は反例を使用して、必要に応じてＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）を改訂し、改訂された実装を再確認することが可能であって、
メソッド（５．１２）、アドホックな同期と調和用：Ａ：ｃｅｌｌｓ（）の２つの別個のセルに関連付けられており、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）のｃａｕｓａｌｎｅｔ内で発生する２つのイベントＸ（ｔ１）とＹ（ｔ２）とは、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）のある実行（ｒｕｎ）においては（ｔ１≦ｔ２）がｔｒｕｅであって、他の実行（ｒｕｎ）においては（ｔ１＞ｔ２）がｔｒｕｅであるという意味で両立せず、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の正しい動作には２つのそのような両立しないイベントＸ（ｔ１）とＹ（ｔ２）が調和しているか同期しているかのいずれかが必要であることがあり得て、イベントＸ（ｔ１）とＹ（ｔ２）の調和とは、他方が発生した後にだけそれらの一方が常に発生することを意味し、例えば、（ｔ１≦ｔ２）がＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の全ての実行（ｒｕｎ）において成立することが必要であって、イベントＸ（ｔ１）とＹ（ｔ２）の同期は（ｔ１＝ｔ２）がＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の全ての実行（ｒｕｎ）において成立しなければならないことを意味し、ＴＩＣＣＴＭ−Ｐｐｄｅはそのような両立しないイベントをＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）のどのようなリファインの変更も必要とせずに調和させ同期させるアドホックなメソッドを提供し、そのようなアドホックな同期と調和のメソッドには、特定の新しい経路が両立しないイベントが発生したセルの特定の新しくインストールされたポート間に確立されることだけが必要であって、（発明を実施するための形態）のセクション６．６に記述されているように前記セルに関連付けられているポートのＴＩＰを定義したり再定義したりし、そのようなアドホックな調和と同期とがＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の共通部分の内両立しないイベントの任意の２つのグループの間でも可能であって、これらのアドホックな同期と調和の方法は、ＴＩＣＣＴＭ−Ｐｐｄｅに固有であって、他のどのような並列プログラミングパラダイムでもリファインを大幅な改訂無しに実装できず、ＴＩＣＣＴＭ−Ｐｐｄｅはそのようなアドホックな同期と調和のための方法を提供する、メソッド。
【請求項６】
請求項１、２、３、４または５に記載のメソッドであって、アプリケーションの実行時にアプリケーションと並列に因果を動的に構築し分析するための以下のＳＭＳメソッドを有し、
メソッド（６．１）、ＳＭＳ（自己監視システム）の駆動用：前述のステートメント（Ｃ．１０）がＴＩＣＣＴＭ−Ｐｐｄｅ内のＳＭＳの動作のための基礎を提供し、ＣＣＰ（因果通信プリミティブ）を使用して信号をＳＭＳのＥｖｅｎｔＢｕｉｌｄｅｒセル（ｅｂセル）に付属しているポートに送信する経路に埋め込まれているエージェントは、（発明を実施するための形態）のセクション７に記載されているように、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）が実行（ｒｕｎ）中に、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の拡大しているｃａｕｓａｌｎｅｔ内にメッセージディスパッチおよびメッセージ配信イベントを自動的にインストールし、各ｅｂセルはｅｂセルに付属しているポートベクトル内のポートの別個の対によって経路に接続されており、経路内のエージェントから信号を受信するポートベクトル内の１つのポートは、経路で発生したメッセージディスパッチイベントを示し、ポートベクトルの他のポートは、（発明を実施するための形態）の図１９に示しているように、同じ経路内の対応するメッセージ配信イベントを示している経路の他のエージェントから信号を受信し、前記ポートベクトル内の両方のポートへの信号の配信の検知時に、ポートベクトルの親ｅｂセルは、拡大しているｃａｕｓａｌｎｅｔ内のメッセージディスパッチと配信イベントインスタンス対応する対をインストールし、ｃａｕｓａｌｎｅｔのそのような更新は、配信されたメッセージを受信したポートＣ．ｐの親セルＣがＣ．ｐ：ｔｉｐ（）を実行中に発生し、拡大しているｃａｕｓａｌｎｅｔ内の前記イベントインスタンスのインストールにかかる時間はＣ．ｐ：ｔｉｐ（）の実行（ｒｕｎ）に必要な時間の５０分の１から１００分の１であって、各ｅｂセルは約１０から１５の経路のサービスを行うことが可能で、全てのセルのポーリングサイクルの非同期実行による遅延を許容し、拡大しているｃａｕｓａｌｎｅｔの複数のｅｂセルによる並列更新は可能であって、それは各ｅｂセルがｃａｕｓａｌｎｅｔの別個の交差していないブランチ内でのみ新しい通信イベントをインストールすることになるからであって、ＴＩＣＣＴＭ−Ｐｐｄｅはｅｂセルとｅａセルによって実施される並列計算を自動的に調和させるツールを提供し、ｅｂセルはＣＣＰを使用して信号を交換することによってｅａセルと通信し、
メソッド（６．２）、拡大しているｃａｕｓａｌｎｅｔ内のイベントの分析用：Ａ：ｃｅｌｌｓ（）内のＥｖｅｎｔＡｎａｌｙｚｅｒセル（ｅａセル）は拡大しているｃａｕｓａｌｎｅｔがＡ：ＡＬＬＥＯＰＳ（）を満足するかどうかを自動的に確認し、ｅｂセルはｃａｕｓａｌｎｅｔ内に新規の通信イベントをインストールするたびにｅａセルに合図し、ｅａセルはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）の拡大しているｃａｕｓａｌｎｅｔ内の構造が前述のステートメント（Ｃ．９）を満たさないことによってＡ：ＡＬＬＥＯＰＳ（）の構造に違反するたびにエラーを報告し、拡大しているｃａｕｓａｌｎｅｔ内の何らかのイベントについて、イベントの発生のタイミングの指定された上限に違反した時に切迫したエラーを報告するか、拡大しているｃａｕｓａｌｎｅｔ内の事前に定義されているＡＬＬＥＯＰＳイベントパターンの発生を識別した時にアラートを発行し、１つまたは２つ以上のｅａセルは、事前に定義されているアラートパターンの発生について拡大しているｃａｕｓａｌｎｅｔを監視するために専用に設けられており、Ａ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の各ｅｂセルについて少なくとも１つのｅａセルが存在し、Ａ：ｃｅｌｌｓ（）はＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内のイベントのタイミングと干渉しないようにＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内の動作を保証するのに必要なだけのｅｂセルとｅａセルとを含んでおり、全てのｅｂセルとｅａセルとは並列に動作し、Ａ：ｃｅｌｌｓ（）内の全ての他のセルと並列に動作し、Ａ：ｃｅｌｌｓ（）内のどのようなセルの動作ともほとんどまたは全く干渉せず、ＴＩＣＣ−ＰｐｄｅＴＭはｅｂセルとｅａセルとがＣＣＰを使用して信号を交換することによって互いに通信できるようにすることによって、ｅｂセルとｅａセルによって実施される並列計算を自動的に調和させるツールを提供し、
メソッド（６．３）、自己診断と自己修復用：ＳＭＳはＡ：ｉｍｐｌｅｍｅｎｔａｔｉｏｎ（）内で自己診断と自己修復機能を最終的に構築するための基礎を提供し、ｅａセルはエラーまたは差し迫ったエラーを識別し、エラーのあるセルと直接通信し、エラーのあるセルに関連付けられているイベントを含んでいる確認されているＣＴＬ表明を使用して誤っているセルを診断し修復するか、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）の残りの部分の正常な動作に干渉せずにそれらを新しいセルに動的に交換し、ｅａセルは事前に定義されているアラートパターンを識別し、必要に応じて所定の態様で識別された並列計算を動的に変更することによってアラートに応答する、メソッド。
【請求項７】
請求項１、２、３、４、５または６に記載のメソッドであって、ＴＩＣＣ−Ｐｐｄｅによって導入された以下の１２のプログラミングアブストラクションをさらに有し、アブストラクト設計、連続したリファインによる設計の実装を可能にし、プログラミングアブストラクションは自動自己監視をしながらの任意のスケーラブルな超並列計算システムの効果的な実行（ｒｕｎ）を可能にし、１２のアブストラクションは以下のとおりであって、
アブストラクション（７．１）、セル：セルは並列プログラミングソフトウェアシステムの計算ユニットのソフトウェアアブストラクションであって、セルは並列ソフトウェアシステム設計と実装の連続したリファインによるアブストラクト仕様を可能にし、各セルは専用のＣＰＵ（ハードウェア計算ユニット）内で実行（ｒｕｎ）され、セルは互いにメッセージを交換し、それらのポートを使用してセルのポートを相互接続している通信経路を介してメッセージを送受信することによって並列計算を実施し、アプリケーションＡ内の経路によって相互接続されているセルのグラフはＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）と呼ばれ、セルは完全に自己完結であって、その動作の支援にオペレーティングシステムを使用せず、ＴＩＣＣＴＭ−Ｐｐｄｅはセル自体が、セル自体で定義されていないどのようなソフトウェアやセルに付属していたりセルに対してチューンされていたりするソフトウェアコンポーネントの支援も無しに、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）を構築するのに必要な全ての計算を実行し、互いに交換するメッセージを処理／構築するｐｔｈｒｅａｄを呼び出して実行し、メッセージの送信/受信のためにプロトコルを呼び出し実行できるようにし、割り込みメッセージの受信時に動作をサスペンドし／リジュームするツールを提供し、
アブストラクション（７．２）、経路：経路は通信チャネルのアブストラクションであって、ｓｍ経路とｄｍ経路の２種類の経路が存在し、ｓｍ経路はＳＭＰ（共有メモリマルチプロセッサ）内で実行されているセルのポートを相互接続し、ｄｍ経路はＤＭＰ（分散メモリマルチプロセッサ）内で実行されているセルのポートを相互接続し、ＤＭＰの計算ノードはＳＭＰであって、ＳＭＰまたはＤＭＰ内の各ポートは、ポートの親セルと呼ばれる唯一のセルにだけ付属しており、
各セルは付属している複数のポートを有しており、セルの各ポートは唯一の経路にだけ接続されており、別個のセルに付属している複数のポートが同じ経路に接続されて、グループ対グループ通信を可能にし、経路はエージェントと埋め込まれているｖｉｒｔｕａｌＭｅｍｏｒｙとを含んでおり、同じエージェントとｖｉｒｔｕａｌＭｅｍｏｒｙとが２つ以上の経路には埋め込まれることはなく、エージェントは埋め込まれている経路上でのメッセージトラフィックの経路設定、同期、および調和を実施し、エージェントは信号をＳＭＳ構造（自己監視システム）に送信して埋め込まれている経路で発生するメッセージディスパッチおよびメッセージ配信のイベントをインストールし、任意の経路Ｐについて、Ｐ：ｐｏｒｔｓ（）はＰに接続されているポートの集合であって、Ｐ：ａｇｅｎｔｓ（）とＰ：ｖｉｒｔｕａｌＭｅｍｏｒｉｅｓ（）はＰ内に埋め込まれているエージェントとｖｉｒｔｕａｌＭｅｍｏｒｙの集合であって、３つの集合Ｐ：ｐｏｒｔｓ（）、Ｐ：ａｇｅｎｔｓ（）、およびＰ：ｖｉｒｔｕａｌＭｅｍｏｒｉｅｓ（）の和集合は経路Ｐの経路コンポーネントであって、２つの別個の経路が共通のコンポーネントを有することはなく、それによってメッセージ干渉無しにＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内の同時の並列メッセージ交換を可能にしており、ＴＩＣＣＴＭ−Ｐｐｄｅは、アプリケーションＡの実行（ｒｕｎ）中に、セルと経路とをＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内に動的にインストールするツールを提供し、
アブストラクション（７．３）、ｖｉｒｔｕａｌＭｅｍｏｒｙ：ｖｉｒｔｕａｌＭｅｍｏｒｙと呼ばれるソフトウェアアブストラクションは経路がインストールされ、アプリケーションのコンパイル時または実行（ｒｕｎ）時に実際のハードウェアメモリ領域またはメモリモジュールがｖｉｒｔｕａｌＭｅｍｏｒｙに割り当てられた時に宣言され、各ｓｍ経路Ｓは埋め込まれている唯一の一意のｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｓ．ｖＭを有しており、任意のｓｍ経路に接続されている全てのポートＰｉは同じＳＭＰ（共有メモリマルチプロセッサ）内に存在しており、任意のｓｍ経路に接続されている全てのポートｐｉは関連付けられている同じｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｐｉ．ｖＭ＝Ｓ．ｖＭを有しており、各ｄｍ経路Ｄは、ＤＭＰ（分散メモリマルチプロセッサ）内の別個のＳＭＰ、ＳＭＰ［ｊ］内に存在しているポートグループ、ｐＧ［ｊ］を相互接続し、各ｄｍ経路Ｄは埋め込まれている２つ以上のｖｉｒｔｕａｌＭｅｍｏｒｙを有しており、１つのｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐＧ［ｊ］．ｖＭは各ＳＭＰ［ｊ］内のポートグループｐＧ［ｊ］に対してチューンされており、ｐＧ［ｊ］．ｖＭはｐＧ［ｊ］内の全てのｑｊについてｑｊ．ｖＭと同一であって、ｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐｉ．ｖＭとｑｊ．ｖＭとは前記経路を介して送信されたメッセージを保持しており、前記ｖｉｒｔｕａｌＭｅｍｏｒｙは、メッセージを処理し生成するために、それぞれポートｐｉとｑｊの親セルによって使用されるｐｔｈｒｅａｄとメソッドも保持しており、さらに、前記ｖｉｒｔｕａｌＭｅｍｏｒｙはメッセージをそれぞれ経路ＳとＤ上で送信するプロトコルｐｉ．ｐｒｏｔｏｃｏｌとｑｊ．ｐｒｏｔｏｃｏｌを保持しており、ｖｉｒｔｕａｌＭｅｍｏｒｙと経路とは保持している全てのｐｔｈｒｅａｄ、メソッドおよびプロトコルの実行環境を提供し、ｖｉｒｔｕａｌＭｅｍｏｒｙ構成はデータセキュリティ、プライバシー、完全性、セルによって実行される並列計算の独立性、並列プログラムの効率的な実行とマルチコアチップ用の共有メモリマルチプロセッサ構成の簡略化に貢献し、
アブストラクション（７．４）、プロトコル：各経路に接続されている各ポートｐはそれに対して定義されているプロトコルｐ．ｐｒｏｔｏｃｏｌを有しており、ｐの親セルだけがｐ．ｐｒｏｔｏｃｏｌの実行を許され、ポートｐの親セルによるｐ．ｐｒｏｔｏｃｏｌの実行によって、経路コンポーネントによる信号の交換が行われ、経路コンポーネントによって交換される信号は経路上を進行し、ｐ．ｖＭ内のメッセージがｓｍ経路内のその意図した受信者に配信されるか、ｄｍ経路内のハードウェア信号送信線を介してその意図した受信者に送信される文脈を最終的に確立し、ｄｍ経路内に埋め込まれているハードウェアエージェントはメッセージの送信、調和、同期、および前記エージェントが埋め込まれているｄｍ経路上での経路設定のためのプロトコルの実行にも関わっており、プロトコルはアプリケーション内の経路の数によってのみ制限されているアプリケーション内の複数の同時の並列メッセージ交換を可能にし、
アブストラクション（７．５）、ＣＣＰ（因果通信プリミティブ）：ＣＣＰは経路内のコンポーネント間で信号をプログラムによって交換するために使用され、各ＣＣＰは、Ｘ：ｘ→Ｙの形態を有しているＴＩＣＣＴＭ−Ｐｐｄｅプログラミング言語内のステートメントであって、Ｘ、Ｙは経路内に埋め込まれているコンポーネントであって、ｘはＣＣＰによってＸからＹへ送信される信号であって、コンポーネントＸ、Ｙによって送信／受信される信号はＸ、Ｙに埋め込まれているｎｄＦＳＭ（非決定的有限状態機械）の状態を制御し、ＣＣＰはソフトウェアまたはハードウェアのいずれかにおいて実装されており、ハードウェアＣＣＰはＣＰＵ内の機械命令として実装されており、各プロトコルはＣＣＰの連結で定義され、そのような連結は、Ｘ：ｘ１→Ｙ：ｘ２→Ｚの形態を有しており、Ｘ、Ｙ、Ｚは同じ経路内の全てのコンポーネントであって、プロトコルに現れるＣＣＰはＴＩＣＣＴＭ−Ｐｐｄｅの他のプログラミングステートメント内に埋め込まれることがあって、ソフトウェアＣＣＰは２ギガヘルツＣＰＵ内で実行するには２５〜５０ナノ秒しかかからず、ハードウェアＣＣＰは２ギガヘルツＣＰＵ内で実行するには５ナノ秒しかかからず、ＣＣＰはＴＩＣＣＴＭ−Ｐｐｄｅによって導入された中心的で最も重要なアブストラクションであって、ＣＣＰはＴＩＣＣＴＭ−Ｐｐｄｅ内で並列プログラム構成を可能にすることに唯一責任があり、
アブストラクション（７．６）、チューンと付属：信号を交換している任意の経路Ｐの全てのコンポーネントは常に互いにチューンされており、チューンによってそのようなコンポーネントの各々は経路の他のコンポーネントからの信号を受信し即座に応答する準備が常にできており、それによって２ギガヘルツＣＰＵを使用して高々２〜３００ナノ秒のレイテンシの範囲で経路Ｐを介した保証された高速メッセージ交換を可能にし、チューンは、再帰的な対称の関係であって、任意のセルＣはＣ内で定義されているメソッドまたはｐｔｈｒｅａｄまたはＣに付属しているポートに接続されている任意の経路に埋め込まれているコンポーネントだけを実行可能であって、ＣはＣに付属しているコンポーネント内で定義されているデータまたは前記経路のコンポーネント内で定義されているデータだけを使用し、付属は、再帰的、対称、推移的な関係であって、チューンと付属とは、ＴＩＣＣＴＭ−Ｐｐｄｅ内の並列ソフトウエアのモジュラーオブジェクト指向構成に貢献し、
アブストラクション（７．７）、ポート：ポートはソフトウェアアブストラクションであって、各ポートｐはその唯一の親セルに付属しており、ポートｐはそれに関連付けられている唯一のｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐ．ｖＭを有しており、ポートｐの親セルはｐを使用してｐ．ｖＭ内のメッセージをｐに接続されている経路を通して他のセルに送信し、他のセルから同じ経路を通してメッセージを受信し、各ポートｐは前記データとメソッドとへのアクセスをその親セルにだけ、そして親セルがこれらのデータとメソッドを使用する準備ができた時にだけ許可することによってｐ．ｖＭ内のデータとメソッドとを保護し、各ポートｐはそれに埋め込まれている２つの状態Ｓ（送信）とＲ（受信）とを備えている有限状態機械ｐ．ｎｄＦＳＭを有しており、状態は親セルｐによって実施されるメッセージの送信／受信動作を調和させ、状態はｐの親セルによるｖｉｒｔｕａｌＭｅｍｏｒｙｐ．ｖＭへのアクセスを制御するのに使用され、調和とアクセス制御メソッドは（発明を実施するための形態）のセクション１の図１から４に記載されており、ｐの親セルはｐ．ｎｄＦＳＭがＳの時にだけメッセージをポートｐを通して送信するためにｖｉｒｔｕａｌＭｅｍｏｒｙ、ｐ．ｖＭにアクセスし、ポートｐはｐ．ｎｄＦＳＭがＲの時にだけメッセージを受信し、ｄｍ経路内のポートは４つの状態Ｓ、Ｓ’、Ｒ、Ｒ’を有しているｎｄＦＳＭを含んでおり、２つのメッセージ送信状態と２つのメッセージ受信状態を有しており、ポートはその親セルについてだけメッセージを送信または受信し、ポートはｖｉｒｔｕａｌＭｅｍｏｒｙへのアクセスも制御し、したがってｖｉｒｔｕａｌＭｅｍｏｒｙ内のデータとメソッドとを保護し、さらに、ｖｉｒｔｕａｌＭｅｍｏｒｙに動的に割り当てられており、ＣＰＵによって必要に応じて使用されるハードウェア共有メモリモジュールの分散構成を可能にし、
アブストラクション（７．８）、エージェント：ｓｍ経路内のエージェントはソフトウェアアブストラクションであって、エージェントは経路内に埋め込まれており、各エージェントａは、状態Ｓ（送信）とＲ（受信）とを備えており、それに埋め込まれている２状態ｎｄＦＳＭ、ａ．ｎｄＦＳＭを有しており、エージェントはそれらの状態を使用して、埋め込まれている経路上でメッセージ送信の経路を設定し、同期し、調和させ、それらは、（発明を実施するための形態）のセクション１の図２から４に記載されているように埋め込まれており、エージェントは、（発明を実施するための形態）のセクション６の図１９に示しているように前記エージェントが埋め込まれている経路内で発生するメッセージディスパッチとメッセージ配信イベントとを、実行（ｒｕｎ）中のアプリケーションのｃａｕｓａｌｎｅｔ内に動的にインストールするためにＳＭＳのコンポーネントに合図もし、ｄｍ経路は４つの状態Ｓ、Ｓ’、Ｒ、Ｒ’を有しているハードウェアエージェントを含んでおり、エージェントは全ての通信を自動的に同期させ、調和させ、セキュリティを実施し、自己監視システムを駆動し、したがってＴＩＣＣＴＭ−Ｐｐｄｅ内で独自で中心的な役割を果たし、
アブストラクション（７．９）、ＴＩＰ（スレッド相互動作プリミティブ）：ＴＩＰはアプリケーションＡ内のポートｐの親セルがｐに配信されたメッセージどのようにを受信し応答するのか、または親セルがポートｐのメッセージを送信する準備ができていることをどのようにチェックし、メッセージを構築し、それをポートｐを通して送信するのかを指定するソフトウェアアブストラクションであって、アプリケーションＡ内の各セルに付属している各ポートはそれに対して定義されているＴＩＰを有しており、他のＴＩＰに埋め込まれているＴＩＰも存在し、セルのポートで定義されている全てのＴＩＰの集合はセルがアプリケーションＡ内の並列計算を実施するために使用され、並列計算の全てを指定するために必要な５種類のＴＩＰが存在し、各種類の中には２つのタイプのＴＩＰが存在し、同期ＴＩＰと非同期ＴＩＰであって、ＴＩＰは、最も複雑な計算ほどに複雑になる可能性のあるセル間の相互動作のコンパクトなモジュラー指定を提供し、ＴＩＰによって提供される相互動作のモジュラー特徴付けによってアプリケーションの実装の正式な検証と確認が促進され、
アブストラクション（７．１０）、ＣＩＰ（セル相互動作プロトコル）：ＣＩＰはセルがそれ自体をどのように初期化し、そのポートをどのようにポーリングし、そのポートに配信されたメッセージをどのように処理し、それらにどのように応答するかを指定するか、新しいメッセージを作製しそのポートの１つまたは２つ以上を通して送信するソフトウェアアブストラクションであって、ＣＩＰはＴＩＣＣＴＭ−Ｐｐｄｅ内の全ての並列計算を可能にする基本的なエンジンを提供し、
アブストラクション（７．１１）、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）：Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）はアプリケーションＡ内の並列プログラム実行の制御構造のアブストラクションであって、Ａ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）は、逐次プログラムとデータ構造とが適切に定義されている場合に同じ逐次プログラムが異なるデータ構造定義において実行（ｒｕｎ）されるのと全く同様に、アプリケーションＡの並列プログラムの実行中に発生する全ての計算と通信アクティビティの同期と調和とを暗示的に指定し、ＣＩＰ（セル相互動作プロトコル）内の初期化ルーチンが適切に定義され、それによって実行制御構造内の変更によってプログラム最適化を可能にしている場合、アプリケーションＡのｐｔｈｒｅａｄの同じ集合、Ａ：ｐｔｈｒｅａｄｓ（）は異なるＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋ（）内で実行（ｒｕｎ）可能であって、
アブストラクション（７．１２）：自己監視システム、ＳＭＳ：ＳＭＳはＴＩＣＣＴＭ−Ｐｐｄｅに固有なアブストラクションであって、ＳＭＳは、アプリケーションＡの実行（ｒｕｎ）中に性能のエラー、保留中のエラー、およびイベントの事前に定義されたパターンの発生を検出し報告するために、アプリケーションで発生するイベントのタイミングに干渉せずにアプリケーションと並列に実行（ｒｕｎ）中に実行（ｒｕｎ）中のアプリケーションＡの性能を監視するためのＴＩＣＣＴＭ−Ｐｐｄｅで使用される機構のソフトウェアアブストラクションであって、ＳＮＳは、実行（ｒｕｎ）中のアプリケーションの拡大しているｃａｕｓａｌｎｅｔを構築し常に監視するために、ｅｂセル（イベントビルダーセル）とｅａセル（イベント分析セル）と呼ばれるセルアブストラクションを使用する、メソッド。
【請求項８】
ＴＩＣＣＴＭ−Ｐｐｄｅに導入された５つの検証−アブストラクションをさらに有する請求項１、２、３、４、５、６、または７に記載のメソッドとアブストラクションであって、検証−アブストラクションは、ＴＩＣＣＴＭ−Ｐｐｄｅが請求項７に記載のアブストラクションを使用して実装された並列プログラムを正式に確認し、それらを自動自己監視と共に実行（ｒｕｎ）するのを可能にし、５つの検証−アブストラクションは、以下のとおりであって、
アブストラクション（８．１）、イベントクラス：イベントクラスはアプリケーションＡの実行（ｒｕｎ）中に発生する計算および通信イベントのアブストラクションであって、イベントクラスは対（名前、ｔ）の組であって、通信イベントクラスとアクションイベントクラスの２種類のイベントクラスが存在し、アクションイベントクラス内のクラス名はＴＩＣＣＴＭプログラミング言語内のステートメント、ｐｔｈｒｅａｄ、またはアプリケーションＡを実装する並列プログラム内の条件を表し、通信イベントクラス内のクラス名は形式ｐＳ、ｐＦ、ｐＤの１つを有しており、ここでｐはアプリケーションＡのポートの名前であって、上付き文字Ｓはポートｐがメッセージを送信することを示し、上付き文字Ｆはポートｐがメッセージを転送することを示し、上付き文字Ｄはメッセージがポートｐに配信されることを示し、ｔはアプリケーションＡの実行（ｒｕｎ）中にイベントインスタンスが発生する可能性のある時間点の順序を表し、ｔは名前の付けられているイベントクラスのタイムマップと呼ばれ、
アブストラクション（８．２）、許容イベント発生パターン、ＡＬＬＥＯＰ：ＡＬＬＥＯＰは計算依存性のアブストラクションを表しており、前記依存性は、イベントクラス間の２値因果関係によって表され、ＡＬＬＥＯＰはイベントクラスの対の間の因果関係を表している条件付きまたは無条件の有向矢印によって接続されている互いに接続されているイベントクラスのネットワークであって、因果チェーンは有向矢印（因果関係）によって接続されているイベントのシーケンスであって、因果関係は非再帰的、推移的、非対称な関係であって、イベントクラスの因果チェーンのネットワークは、アプリケーションＡの実行（ｒｕｎ）中にアプリケーションＡの並列プログラムで発生する計算イベントインスタンスのパターンを反映しており、ｐ：ｐｏｒｔ−ＡＬＬＥＯＰ（）はｐ：ＴＩＰ（）内で発生するイベントクラスの全ての因果チェーンの集合であって、Ｃ：ｃｅｌｌ−ＡＬＬＥＯＰ（）はＣ：ＣＩＰ（）内で発生するイベントクラスの全ての因果チェーンの集合であって、Ａ：ＡＬＬＥＯＰ（）はアプリケーションＡ内で発生するイベントクラスの全ての因果チェーンの集合であって、
アブストラクション（８．３）、イベントインスタンスとトレース：イベント、（名前、ｔｉ）、ｉ＝１，２．．．，ｎ．．．は、アプリケーションの実行（ｒｕｎ）中に時間インスタンスｔ＝［ｔ１、ｔ２、．．．、ｔｎ、．．．］、ｎ＞０で発生するイベントクラス（名前、ｔ）のインスタンスであって、ｎ＝０の時にはイベントクラス（名前、ｔ）のインスタンスは存在せず、それぞれのイベントクラス（Ｘ，ｔｘ）と（Ｙ，ｔｙ）のイベントインスタンスＸ（ｔｉ）とＹ（ｔｊ）の対は、その対応するイベントクラスがＡＬＬＥＯＰ内のそのような矢印で接続されている場合にだけ、因果関係を表している条件付きまたは無条件有向矢印によって互いに接続されており、アプリケーションＡの任意の実行（ｒｕｎ）時に発生する可能性のあるイベントインスタンスの全ての考え得る因果チェーンの集合の表現はＡ：ＴＲＡＣＥＳ（）と呼ばれ、Ａ：ＴＲＡＣＥＳ（）はＡ：ＡＬＬＥＯＰＳ（）から自動的に導出され、ｐ：ｐｏｒｔ−ｔｒａｃｅ（ｔｐ）は、ｐ：ｐｏｒｔ−ＡＬＬＥＯＰ（）から自動的に導出されたトレースであって、Ｃ：ｃｅｌｌ−ｔｒａｃｅ（ｔｃ）は、Ｃ：ｃｅｌｌ−ＡＬＬＥＯＰ（）から自動的に導出されたトレースであって、
アブストラクション（８．４）、ＥＣＴネットワーク：ｐ：ｐｏｒｔ−ＥＣＴ（ｔｐ）は、表形式に構成されている、ｐ：ｐｏｒｔ−ｔｒａｃｅ（ｔｐ）内で発生する全てのイベントインスタンスの因果チェーンを表しているイベント特徴付けの表であって、ｐ：ｐｏｒｔ−ＥＣＴ（ｔｐ）のネットワークはアプリケーションのポートのポートＥＣＴネットワーク内の集合であって、ポートはＡ：ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋに整合した態様で相互接続されており、そのようなＥＣＴネットワークはＴＩＣＣＴＭ−Ｐｐｄｅによる正式な対話的な証明生成を促進し、Ｃ：ｃｅｌｌ−ＥＣＴ（ｔｃ）はＣ：ｃｅｌｌ−ｔｒａｃｅ（ｔｃ）に対応しているＥＣＴネットワークであって、Ａ：ＥＣＴ−ｎｅｔｗｏｒｋ（）はＡ：ＴＲＡＣＥＳ（）に対応しているＥＣＴネットワークであって、
アブストラクション（８．５）、ｃａｕｓａｌｎｅｔ：ｐ：ｃａｕｓａｌｎｅｔ（ｔｐ）はｐ：ｐｏｒｔ−ｔｒａｃｅ（ｔｐ）内で発生した通信イベントインスタンスの因果チェーンにだけを含んでいるｐ：ｐｏｒｔ−ｔｒａｃｅ（ｔｐ）のアブストラクションであって、Ｃ：ｃａｕｓａｌｎｅｔ（ｔｃ）はＣ：ｐｏｒｔ−ｔｒａｃｅ（ｔｃ）内の通信イベントインスタンスの因果チェーンだけを含んでいるＣ：ｐｏｒｔ−ｔｒａｃｅ（ｔｃ）のアブストラクションであって、Ａ：ｃａｕｓａｌｎｅｔ（）はＡ：ＴＲＡＣＥＳ（）の通信イベントインスタンスの因果チェーンだけを含んでいるＡ：ＴＲＡＣＥＳ（）のアブストラクションであって、ＳＭＳ（自己監視システム）は実行（ｒｕｎ）中にアプリケーションＡで自動的にｃａｕｓａｌｎｅｔを生成し、実行（ｒｕｎ）と並行してエラー、保留中のエラー、およびイベントインスタンスの事前に定義されているパターンの発生を識別するために動的に拡大しているｃａｕｓａｌｎｅｔを自動的に監視する、メソッドとアブストラクション
【請求項９】
請求項１、２、３、４、５、６、７または８に記載のメソッドとアブストラクションであって、アプリケーションＡの自己監視を使用して設計、開発、検証、および実行（ｒｕｎ）のための統合された環境を提供するために以下のメソッドをさらに有し、
ＴＩＣＣ−ＰｐｄｅＴＭ自体は、セルへのＣＰＵ割り当て、セルに割り当てられたＣＰＵ内でのセルの起動、並列プロセス管理、ｐｔｈｒｅａｄ管理、通信、割り込み管理、セキュリティの実施、同期と調和を、これらのサービスのどのような部分の実行にもオペレーティングシステムや他のソフトウェアの呼び出しを必要とせずに、実施し、ＴＩＣＣＴＭ−Ｐｐｄｅは現在のプロトタイプ実装においては、メモリ管理、キャッシュ管理、および２次ストレージ装置とインターネットへのアクセスのためにだけオペレーティングシステムを使用し、オペレーティングシステムによって現在提供されている全てのサービスを全ての必要なオペレーティングシステムのサービスを並列に提供しながら、ＴＩＣＣＴＭ−Ｐｐｄｅ自体に実装し、それによって自己監視を備えた並列ソフトウェアシステムの統合された設計、開発、検証、および実行（ｒｕｎ）のための環境を提供することが可能である、メソッドとアブストラクション。
【請求項１０】
請求項１、２、３、４、５、６、７、８または９に記載のメソッドとアブストラクションであって、並列プログラミングアプリケーションＡを設計、実装、および実行（ｒｕｎ）する以下のメソッドさらに有し、
任意のアプリケーションの任意の並列コンピュータプログラムは請求項１から９に記載の任意のまたはすべてのメソッドとアブストラクションとを使用し、プログラムに従った信号交換を使用して並列ソフトウェアシステムを、組織化し、制御し、正式な確認と自己監視ありでまたはなしで、または部分的な確認と部分的な自己監視だけで、ハードウェアまたはソフトウェアに実装する、メソッドとアブストラクション。
【発明の詳細な説明】
【技術分野】
【０００１】
優先出願番号：６１／１９５，９６５、優先日：１０／１４／２００８
セクションＩ：要約書
セクションＩＩ：背景技術
セクションＩＩＩ：発明の概要
セクションＩＶ：発明を実施するための形態
セクションＶ：特許請求の範囲
セクションＶＩ：図面の簡単な説明
用語：アルファベット順の略語
ＡＬＬＥＯＰ：許容イベント発生パターン
ＣＣＰ：因果通信プリミティブ
ＣＣＳ：通信システム用算法
ＣＩＰ：セル相互動作プロトコル
ＣＰＵ：ハードウェア計算ユニット
ＣＳＰ：通信逐次プロセス
ＣＴＬ：因果時間論理
ｄｍ経路：分散メモリ通信経路
ＥＣＴ：イベント特徴付け表
ＦＳＰ：有限状態プロセス
ｎｄＦＳＰ：非決定的ＦＳＰ
ＮＦＳＰ：非ＦＳＰ
ＯＯ：オブジェクト指向
ｓｍ経路：共有メモリ通信経路
ＳＭＳ：自己監視システム
ＴＩＣＣＴＭ：統合された計算と通信のための技術
ＴＩＣＣＴＭ−Ｐｐｄｅ：ＴＩＣＣＴＭベース並列プログラミング開発および実行プラットフォーム
ＴＩＣＣＮＥＴＴＭ：ＴＩＣＣＮＥＴＴＭベースローカルエリア通信ネット
ＴＩＰ：スレッド相互動作プロトコル
【背景技術】
【０００２】
セクションＩＩ：（背景技術）
特許の名称：マルチコアチップ用の正式に検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ  Ｖ．  Ｓｒｉｎｉｖａｓａｎ
顧客番号：００００３３６４１、ＰＣＴ出願
米国国コードおよび優先出願の番号：ＵＳ  ６１／１９５，９６５
優先日：２００８年１０月１４日
発明者の住所：２０３１  ＳＥ  Ｋｉｌｍａｌｌｉｅ  Ｃｏｕｒｔ、Ｐｏｒｔ  Ｓａｉｎｔ  Ｌｕｃｉｅ、ＦＬ  ３４９５２  電話：  ７７２  ３３７  １３８８  Ｆａｘ：  ７７２  ３３７  １３８８、携帯電話：  ７７２  ２８５  ６４６３  Ｅｍａｉｌ：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
【０００３】
本発明は、ローカルエリアネットワーク、ＴＩＣＣＮＥＴＴＭ（ＴＩＣＣＴＭベースのローカルエリア通信ＮＥＴ）、によって相互接続されている任意の多数の共有メモリマルチコアチップ（ＳＭＭＣ）または共有メモリマルチプロセッサ（ＳＭＰ）の任意の集合を実行（ｒｕｎ）する正式に確認された超並列ソフトウェアシステムを構築し、８０％〜１００％の効率で実行（ｒｕｎ）するために、ＴＩＣＣ（統合された計算と通信の技術、特許文献１、発明者：Ｃｈｉｔｏｏｒ  Ｖ．  Ｓｒｉｎｉｖａｓａｎ）をどのように使用するかを教示する。構成と動作は、（ｉ）並列ソフトウェアシステムを設計し、実装し、正式に検証する理想的な環境を提供し、（ｉｉ）セルと呼ばれる並列ソフトウェア計算ユニット間の相互動作のアブストラクト仕様から始めて、実装をその最終形態まで徐々にリファインし、（ｉｉｉ）ＴＩＣＣＮＥＴＴＭを備えているＳＭＣＣネットワークの多様性の中で超並列ソフトウェアアプリケーションを開発するための適正なプログラミングアブストラクションとツールとを提供し、（ｉｖ）ＡＬＬｏｗｅｄ  Ｅｖｅｎｔ  Ｏｃｃｕｒｒｅｎｃｅ  Ｐａｔｔｅｒｎ（ＡＬＬＥＯＰ）と呼ばれる定められた計算の正式なイベントベースのモデルを実装の各段階で自動的に生成し、（ｖ）ＡＬＬＥＯＰは因果時間論理言語（ＣＴＬ言語）で記述されている正しさ、タイミング、同期、調和、プログレス、ライブネス、デッドロックが無いことなどの定められている計算の特性を正式に検証するために使用されるだけでなく、（ｖｉ）実装されたアプリケーションの性能を、事前に定められている性能のエラー、起こりそうなエラー、およびアラート状態の発生を識別し報告するために、その動作と平行に、そのタイミングに干渉せずに生涯時間を通して監視する、自己監視システム（ＳＭＳ）を自動的に実装する。
【０００４】
ＴＩＣＣＴＭ−Ｐｐｄｅは、ＴＩＣＣＴＭベースの並列プログラムを開発し実行するためのソフトウェアプラットフォームである。それは、全ての将来的なアプリケーションソフトウェアをマルチコアチップを備えている様々なデスクトップおよびラップトップコンピュータで実行（ｒｕｎ）する完全に検証された並列ソフトウェアシステムに変換し、それによって今日我々が使用している技術において実現不可能な膨大な計算能力への容易なアクセスを実現する能力がある。
【０００５】
ＴＩＣＣＴＭ−Ｐｐｄｅは以下の７つの他のプログラミングパラダイムの修正されたバージョンを採用し、統合する：（ｉ）ＯＯ（オブジェクト指向）パラダイム［Ｍａｒｔｉｎ  １、Ａｌａｎ  ２，Ａｒｍｓｔｒｏｎｇ  ３、Ｂｅｒｔｒａｎｄ  ４］、（ｉｉ）アクターにおけるような並列計算［Ｈｅｗｉｔｔ、５］［Ａｇｈａ，６］［Ｃｌｉｎｇｅｒ、３７］、（ｉｉｉ）π算法におけるような相互動作の指定［Ｍｉｌｎｅｒ、７、８、９］、（ｉｖ）ＣＳＰ（通信逐次プロセス）［Ｈｏａｒｅ、１０、１１、１２］におけるような計算と通信との統合、（ｖ）ＦＳＰ（有限状態プロセス）［Ｍａｇｅｅ＆Ｋｒａｍｅｒ、１３］による設計の検証と同様な実装の検証、（ｖｉ）［Ｈｏａｒｅ、１５］と［Ｍａｎｎａ、１６、１７、１８］と同様なＮＦＳＰ（非ＦＳＰ）システムの検証、（ｖｉｉ）修正ＲＥＳＴＣＬＫ経路［Ｄａｓ、１９］を使用した通信。ＴＩＣＣＴＭ−Ｐｐｄｅで使用される通信機構、並列プログラミング構成、および検証方法は新規である。
【０００６】
これらのパラダイムの統合は、ＴＩＣＣＴＭの変形例の仕様によって可能になり、それによってハードウェアとソフトウェア計算コンポーネントが信号をプログラムに従って交換できるようになる。全ての通信、並列プロセスおよびｐスレッド（並列スレット）の相互動作、セキュリティの実施、割り込み処理、同期、協調、および自己監視は、すべてのソフトウェアとハードウェアのコンポーネントの相互分離を維持しながら、オペレーティングシステム（ＯＳ）の使用を必要とせずにプログラムに従っている信号交換によって駆動される。セルと呼ばれるアプリケーションのソフトウェア計算コンポーネントは並列に動作し、ＦＳＰ［Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ、１３］およびＣＣＳ（Ｃａｌｃｕｌｕｓ  ｆｏｒ  Ｃｏｍｍｕｎｉｃａｔｉｎｇ  Ｓｙｓｔｅｍｓ）［Ｍｉｌｎｅｒ、１４］でのようにタイムスライスされた並行性では動作しない。各セルはそれ自体の割り当てられているハードウェアＣＰＵ内で動作し、他のセルはＣＰＵが割り当てられているセルがその動作を中断したり中止し、そのＣＰＵを解放しない限りそのＣＰＵを使用しない。ＴＩＣＣＴＭベースの並列処理には多数のＣＰＵを必要とし、受け入れることができる。並列プログラミングを簡単にし、正式な検証と動的な自己監視のためのメソッドを提供する以外に、ＴＩＣＣＴＭ−Ｐｐｄｅは（発明の概要）セクションで概説する数個の他の利点をもたらす。
【０００７】
（発明を実施するための形態）セクションは、以下の一連の例を示しており、（ｉ）構成の原理、（ｉｉ）通信と計算の性質、（ｉｉｉ）実装から自動的に導出されるＡＬＬＥＯＰによって定義されるような計算のモデル、（ｉｖ）ＡＬＬＥＯＰから自動的に導出されるＥＣＴ−ネットワーク（イベント特徴付け表ネットワーク）上での所与のＣＴＬ表明（因果時間論理表明）の評価を使用した実装の検証、および（ｖ）同期、調和、データ保護、セキュリティの実施、および自己監視である。
【０００８】
ＴＩＣＣＮＥＴＴＭは、各々が３２または６４個以上のプロセッサを備えている高々２５６またはそれ以上のＳＭＭＣ（共有メモリマルチプロセッサチップ）および／またはＳＭＰ（共有メモリマルチプロセッサ）を含んでいるローカルエリアスーパーコンピューティンググリッドにおけるＳＭＭＣおよび／またはＳＭＰ間のグループ対グループ、高速メッセージ交換に使用できるＴＩＣＣＴＭベースの分散メモリハードウェア通信ネットワークである。１つのチップに統合されている複数のＳＭＭＣを備えているマルチコアチップを近い将来は予測している。ＴＩＣＣＮＥＴＴＭ自体は、チップ内のＳＭＰ間の、高速、グループ対グループ、分散メモリメッセージ交換のために、そのようなマルチコア、マルチＳＭＰチップに統合されることを仮定している。ＴＩＣＣＮＥＴＴＭ内の分散メモリ経路の構造だけを本特許出願内で説明し、ＴＩＣＣＮＥＴＴＭ内に経路をインストールし、メッセージをインストールされた経路上を送信する機構については説明しない。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】米国特許第７，２１０，１４５  Ｂ２号
【発明の概要】
【課題を解決するための手段】
【００１０】
セクションＩＩＩ：課題を解決するための手段
特許の名称マルチコアチップ用の正式に検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ  Ｖ．  Ｓｒｉｎｉｖａｓａｎ
顧客番号：００００３３６４１
米国国コードおよび優先出願の番号：ＵＳ  ６１／１９５，９６５
優先日：２００８年１０月１４日
発明者の住所：２０３１  ＳＥ  Ｋｉｌｍａｌｌｉｅ  Ｃｏｕｒｔ、Ｐｏｒｔ  Ｓａｉｎｔ  Ｌｕｃｉｅ、ＦＬ  ３４９５２  電話：  ７７２  ３３７  １３８８  Ｆａｘ：  ７７２  ３３７  １３８８、携帯電話：  ７７２  ２８５  ６４６３  Ｅｍａｉｌ：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
【００１１】
１．連続したリファインによる実装：ＴＩＣＣＴＭ−パラダイムは、セルと呼ばれる一式の並列ソフトウェア計算ユニットの相互動作のアブストラクト仕様から始める連続したリファインによるアプリケーション実装の方法を導入する。セルはセルに付属しているポートに接続されている通信経路を通して互いにメッセージを交換することによって並列計算を実行する。存在する場合に、名前と引数だけが、呼び出され実行される実装文脈と共に実装において指定されているが、それらを実装したコンピュータプログラムが定義されていない場合にだけ、メッセージサブグラス、メソッド、ｐｔｈｒｅｄまたは条件はアブストラクトである。リファインには、メッセージサブクラスの定義と、アプリケーションの所与のアブストラクトデザインにおけるアブストラクトメソッド、ｐｔｈｒｅａｄ（並列スレッド）、および条件を定義するコンピュータプログラムが関わっている。リファインは所与のアブストラクト仕様におけるセル間のメッセージの流れに従ってゴールに向かう態様で実施される。リファインの各段階で、定義されたコンピュータプログラムによって実行される計算のＡＬＬＥＯＰモデルが実装の仕様から自動的に導出される。モデルは、リファインの様々な段階において、ＣＴＬ言語（因果時間論理言語）で表明されている特性を確認するために使用される。実装はコンピュータプログラムが実装の全てのアブストラクトメソッド、ｐｔｈｒｅａｄ、および条件に対して定義されており、メッセージサブグラスが完全に定義されている場合に完全にリファインされる。
【００１２】
２．ＡＬＬＥＯＰと証明：ＡＬＬＥＯＰは（発明を実施するための形態）のセクション２で説明しているように、アプリケーションにおいて許容されるイベント発生パターンを指定する。２種類のイベントクラスが存在し、通信イベントクラスとアクションイベントクラスである。おおまかには（詳細には（発明を実施するための形態）のセクション２と５）、通信イベントクラスは、対（ｐＳ，ｔ）、（ｐＦ，ｔ）、または（ｐＤ，ｔ）であって、ここで、ｐはメッセージを経路を介して送信、転送、または受信するポート、添え字Ｓは送信、添え字Ｆは転送、添え字Ｄは配送であって、タイムマップと呼ばれるｔはアプリケーションの実行（ｒｕｎ）においてイベントクラスのインスタンスが発生する可能性のある時間点の順序を意味する。アクションイベントクラスは対、（名前，ｔ）であって、名前は変数、条件、またはアクションであって、ｔは名前の付けられた変数が設定または表明される、名前が付けられている条件がｔｒｕｅになる、または名前が付けられているアクションが実行される時間点の順序を表しているタイムマップである。アクションイベントのインスタンスは並列計算の世界状態を変化させることがあるが、通信イベントのインスタンスは通信経路内のコンポーネントの状態を変化させるだけである。
【００１３】
正しい動作のための条件：イベントクラス（Ｘ，ｔ）のイベントインスタンスを指す場合にＸ（ｔ１）と書き、イベントインスタンスＸは時刻ｔ１に発生する。ＡＬＬＥＯＰにおいて（ＸはＹの原因である）が真の場合に（Ｘ→Ｙ）と書き、条件Ｃ（Ｘ，Ｙ）が真の場合にだけ（ＸはＹの原因である）場合に（ＸＣ（Ｘ、Ｙ）→Ｙ）またはＣ（Ｘ、Ｙ）？（）（Ｘ→Ｙ）と書く。因果関係は非再帰的、推移的、非対称関係の意味であって、（Ｘ→Ｘ）は不可能、（Ｘ→Ｙ）＆（Ｙ→Ｘ）も不可能、（Ｘ→Ｙ→Ｚ）は（Ｘ→Ｚ）を意味し、（ＸＣ（Ｘ、Ｙ）→ＹＣ（Ｙ、Ｚ）→Ｚ）は（ＸＣ（Ｘ、Ｙ）＆Ｃ（Ｙ、Ｚ）→Ｚ）を意味する。因果チェーンは（Ｘ→Ｙ→Ｚ）または（ＸＣ（Ｘ、Ｙ）→ＹＣ（Ｙ、Ｚ）→Ｚ）でのように、連続した因果関係の連結である。因果関係は以下のように解釈される。
【００１４】
解釈１：アプリケーションの実行（ｒｕｎ）において、ＸのインスタンスＸ（ｔ１）がＹのインスタンスＹ（ｔ２）を発生させる場合、（Ｘ→Ｙ）が真または（ＸＣ（Ｘ、Ｙ）→Ｙ）＆＜Ｃ（Ｘ，Ｙ）＞（ｔ２）がＡＬＬＥＯＰにおいて真でなければならず、また両方の場合において（ｔ２≦ｔ１＋τ（Ｘ、Ｙ））が成立しなければならない。
【００１５】
項（Ｃ（Ｘ，Ｙ））（ｔ２）は条件Ｃ（Ｘ，Ｙ）が時刻ｔ２で真であることを表明している。項τ（Ｘ，Ｙ）は２つのイベントインスタンス（Ｘ，Ｙ）の発生の間の許容される最大遅延である。実装者は、これらの最大値を設計時に予測し、完成した実装を使用した実験の後にこれらを確定する。アプリケーションのｃａｕｓａｌｎｅｔはそのアプリケーションの実行（ｒｕｎ）中に発生する可能性のある通信イベントインスタンスの全ての可能性のある因果チェーンの集合を表しており、アクションイベントは無視されている。アプリケーションのｃａｕｓａｌｎｅｔにおいて以下の条件１が成立する場合にだけアプリケーションは正常に動作する（セクション６．５、（発明を実施するための形態））。
条件１：∀（Ｘ）∀（ｔ１）∀（Ｙ）∀（ｔ２）［Ｘ（ｔ１）→Ｙ（ｔ２）］
⇒［（Ｘ→Ｙ）∨（（ＸＣ（Ｘ、Ｙ）→Ｙ）＆〈Ｃ（Ｘ，Ｙ）〉（ｔ２））］＆
（ｔ２≦ｔ１＋τ（Ｘ、Ｙ））］
【００１６】
この条件は、アプリケーションの任意の実行（ｒｕｎ）中に発生する可能性のある全てのイベントインスタンスについて解釈１が成立しなければならないことを表明している。ここでのタイミングは計算をモデル化するために使用されるイベントの特性であって、計算のパラメータではない。各計算ステップは関連付けられている１つまたは２つ以上のイベントを有している。全てのそのようなイベントは実時間の別個の点で発生する。証明構築中に、時間点はＡＬＬＥＯＰＳにおいて指定されたタイムマップに整合するようにイベントに対して要求されている。イベントのタイミングを条件１内の厳格な境界τ（Ｘ、Ｙ）内で予測する能力はＴＩＣＣＴＭ−Ｐｐｄｅの実行特性（（発明を実施するための形態）のセクション４．６）と以下で特徴４と呼ぶ高速化技法の排除の結果である。イベントの発生パターン、因果チェーン、それらに関連付けられている条件、イベントタイミング、および計算ユニットの状態はすべて証明構築において使用される。
【００１７】
ＡＬＬＥＯＰはＦＳＰ（有限状態プロセス）とＮＦＳＰ（非有限状態プロセス）の両方をモデル化する。Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ［１３］において使用されているＦＳＰモデルとは異なり、ＡＬＬＥＯＰは意図したシステム設計のモデルではなく、リファインの様々な段階での実装の仕様から自動的に導出される実際の実装のモデルである。トレースはＡＬＬＥＯＰから自動的に導出され、ＥＣＴ（イベント特徴付け表）もトレースから自動的に導出される。ＥＣＴネットワークはトレース内の情報をＡＬＬＥＯＰの証明構築に便利な表形式で表している。ＥＣＴネットワーク上でのＣＴＬ表明（因果時間論理表明）として記述されている実装の特性の相互作用の証明はシンボリック評価を通して構築される。ＣＴＬ表明はＣｌａｒｋ［３８−４０］、Ｅｍｅｒｓｏｎ、［４１］およびＳｉｆａｋｉｓ［４２］表明と同様であって、［Ｍａｇｅｅ＆Ｋｒａｍｅｒ、１３］で使用されるＦＳＰ言語ともある意味で同様である。しかし、違いが存在し、それは、（発明を実施するための形態）に示している例において見ることができる。ＣＴＬ表明で使用される特定の構文は一般に受け入れられる明確な解釈［３８−４２］を有しているかぎり重要ではない。
【００１８】
証明にはＣＴＬ言語用の推論エンジンは必要なく、証明にはＥＣＴネットワーク（ＥＣＴのネットワーク）上でＣＴＬ表明を評価するメソッドが必要なだけである。しかし、証明には命題論理式用の推論エンジンが必要である。ＥＣＴネットワーク上でのＣＴＬ表現の評価によって証明に必要な命題推論用の文脈が得られる。ユーザが実装と証明するＣＴＬ表明を指定し、証明に関連する可能性のある定義、原理、他のＣＴＬ表面を提供する。証明メソッドは、（発明を実施するための形態）のセクション６に示している。有限ＡＬＬＥＯＰは等価ＦＳＰモデルを有しているものである。所与のＡＬＬＥＯＰはＦＳＰとＮＦＳＰの特性の両方を有しており、後者の証明は必ずより複雑である。
【００１９】
３．動的自己監視、ＳＭＳ：ＳＭＳ（自己監視システム）はＴＩＣＣＴＭ−Ｐｐｄｅプログラム実行機構に本来備わっている組み込み部分である。したがって、アプリケーションＡのＴＩＣＣＴＭ−Ｐｐｄｅ実装がいったん完了すると、自己監視は自動的である。実装はＳＭＳのどのような部分も指定する必要がない。ＳＭＳは、Ａの生涯時間の間、実行の効率とＡのタイミングをほとんどまたは全く低下させることなく、Ａの実行（ｒｕｎ）と並列に、実行（ｒｕｎ）中にアプリケーションＡ用のｃａｕｓａｌｎｅｔを動的に生成し、ＡのｃａｕｓａｌｎｅｔはＡの実行（ｒｕｎ）中に発生する通信イベントチェーンの全ての、そしてそれらだけのネットワークである。条件１が満たされないと常にエラーが報告され、ＡＬＬＥＯＰＳの何らかのイベントクラスＸとＹについて条件１で指定された条件τ（ｘ、ｙ）が満たされない場合にだけ差し迫ったエラーが報告される。重要な振る舞いのパターンを、ＡＬＬＥＯＰノードを終端記号として使用して正規文法で定義し、定義されたパターンのいずれかがｃａｕｓａｌｎｅｔ内で発生すれば常にＳＭＳにアラートを発行させることさえできる。ＳＭＳは自己診断、自己修復、および学習能力のためのインフラストラクチャを提供する。
【００２０】
４．高速並列通信：２００７年４月２４日付けの米国特許第７，２１０，１４５  Ｂ２で説明しているように、ＴＩＣＣＴＭはＲＥＳＴＣＬＫ［Ｄａｓ，１９］通信パラダイムを採用している。ＴＩＣＣＴＭ内の通信は、接続指向であって、２つのセルは通信経路によって互いに接続されているポートを有している場合にだけ互いに通信することができる。ＲＥＳＴＣＬＫをＴＩＣＣＴＭ−Ｐｐｄｅに適用することによって、経路内のコンポーネント間の信号の交換に使用されるプロトコルが変化し、ＳＭＳを組み込むように経路の構造が修正され、最も重要なことは、ＲＥＳＴＣＬＫとは異なり、保証された高速メッセージ配信による並列で、同時で、即時の非同期通信が可能になる。
【００２１】
各ポートはポートの親セルと呼ばれる１つのセルだけに付属させることが可能で（ポートの競合を防止）、各ポートは１つの経路にだけ接続することができる（メッセージ干渉の防止）。すべてソフトウェアコンポーネントである３種類のポート、サービス要求メッセージの送信に使用されるｇｅｎｅｒａｌＰｏｒｔ、サービス要求メッセージの受信と応答に使用されるｆｕｎｃｔｉｏｎＰｏｒｔ、および割り込みメッセージの受信とそれらへの応答に使用されるｉｎｔｅｒｒｕｐｔＰｏｒｔが存在する。各セルは各種類のポートを少なくとも１つ有していなければならない。
【００２２】
米国特許第７，２１０，１４５  Ｂ２号に記載されているＴＩＣＣＴＭは、アプリケーションＡの他のセルと並列に動作する通信プロセッサと呼ばれる特別なセルを使用してメッセージ交換をスケジュールし実装した。アプリケーションＡの各セルはそのセルのポートに接続されている経路を介したＡの通信プロセッサへメッセージを送信するために要求を送信した。通信プロセッサは要求で指定されている経路に関連付けられているプロトコルを実行することによってメッセージを送信した。プロトコルは、通信プロセッサによって要求が受信された順番で実行された。したがって、共有メモリ環境においてメッセージを配信するのに１ギガビット／秒のメモリバスを備えている２ギガヘルツＣＰＵを使用し２〜３００ナノ秒しかかからなくても、メッセージを配信するレイテンシは６から１０マイクロ秒にもなり、これはメッセージを送信する要求がキュー内で通信プロセッサのサービスを受けるその順番を待たなければならないせいかもしれない。アプリケーション内で並列に同時に送信できるメッセージの数はそのアプリケーション内の別個の通信プロセッサの数に限定されている。
【００２３】
この構成は、通信プロセッサが使用されない以下で概略を説明するＴＩＣＣＴＭ−Ｐｐｄｅの並列メッセージ交換機構とは対照的である。各セル自体は自身のメッセージを送信し配信し、同時に並行に送信可能なメッセージの数は、アプリケーション内の別個の経路の総数によってだけ制限される。さらに、通信は共有メモリ環境と分散メモリ環境との両方で発生する可能性がある。ＴＩＣＣＴＭ−Ｐｐｄｅの通信の特徴を以下で箇条書きにする。
【００２４】
（４−ｉ）経路とプロトコル：セルＣの各ポートＣ．ｐは独自の経路、Ｃ．ｐ経路に接続されている。ｓｍ経路（共有メモリ経路）とｄｍ経路（分散メモリ経路）の２種類の経路が存在する。経路という用語はそれらのいずれか一方を指す。メッセージを配信する経路だけが関連付けられているｖｉｒｔｕａｌＭｅｍｏｒｙを有している。メッセージを配信しないが信号だけを配信する経路は単純な経路と呼ばれる。ＶｉｒｔｕａｌＭｅｍｏｒｙは経路がインストールされた時点で経路に対して宣言される。実際のメモリはコンパイル時または実行（ｒｕｎ）時にｖｉｒｔｕａｌＭｅｍｏｒｙに割り当てられる。ｖｉｒｔｕａｌＭｅｍｏｒｙは交換されたメッセージを保持し、またメッセージを処理し構築するメソッドとｐｔｈｒｅａｄ（並列スレッド）も保持する。
【００２５】
各ｓｍ経路は関連付けられている唯一のｖｉｒｔｕａｌＭｅｍｏｒｙを有している。Ｃ．ｐ．ｐａｔｈｗａｙがｓｍ経路の場合、Ｃ．ｐ．ｖＭはＣ．ｐ．ｐａｔｈｗａｙのｖｉｒｔｕａｌＭｅｍｏｒｙを指す。Ｃ．ｐ．ｐａｔｈｗａｙがｄｍ経路の場合は、Ｃ．ｐ．ｐａｔｈｗａｙに接続されている各ポートｑ（Ｃ．ｐはポートｑの１つ）は別個のｖｉｒｔｕａｌＭｅｍｏｒｙ、ｑ．ｖＭを有することになって、これらの別個のｖｉｒｔｕａｌＭｅｍｏｒｙはｄｍ経路によって相互接続されている別個のＳＭＰ（級友メモリマルチプロセッサ）内に存在する。各ポートＣ．ｐは関連付けられている別個のプロトコルＣ．ｐ．ｐｒｏｔｏｃｏｌを有している。ポートＣ．ｐの親セルＣだけがＣ．ｐ．ｐｒｏｔｏｃｏｌを実行することができる。ＣはＣ．ｐ．ｐａｔｈｗａｙ上で信号を送信するためにＣ．ｐ．ｐｒｏｔｏｃｏｌを実行する。Ｃ．ｐ．ｐａｔｈｗａｙ上を進行する信号は、Ｃ．ｐ．ｖＭのメッセージがＣ．ｐ．ｐａｔｈｗａｙがｓｍ経路である場合にＣ．ｐ．ｐａｔｈｗａｙに同様に接続されている意図した受信ポートに配信されるメッセージ文脈を最終的に確立する。Ｃ．ｐ．ｐａｔｈｗａｙがｄｍ経路の場合、Ｃ．ｐ．ｖＭのメッセージはハードウェア送信線を介して同じｄｍ経路の他のポートｑのｖｉｒｔｕａｌＭｅｍｏｒｙ、ｑ．ｖＭに送達される。ＴＩＣＣＮＥＴＴＭはアプリケーション内の全てのｄｍ経路を含んでいる通信ネットワークである。ＴＩＣＣＮＥＴＴＭの別個のｄｍ経路の数は、何千になることもある。単純な経路は、それらに関連付けられていないｖｉｒｔｕａｌＭｅｍｏｒｙを有することはない。
【００２６】
（４−ｉｉ）プロトコルとＣＣＰ：全てのプロトコルはＣＣＰ（因果通信プリミティブ）のシーケンスによって定義されており、実行時に、プロトコルに関連付けられている経路内のコンポーネントに信号を相互に交換させ受信した信号に応答させる。各ＣＣＰはＸ：ｘ→Ｙの形態を有しており、ＸとＹとは経路に埋め込まれているコンポーネントであって、ｘは信号である。プロトコルはＣＣＰの連結によって定義されており、連結はＸ：ｘ１→Ｙ：ｘ２→Ｚの形態を有しており、Ｘ、Ｙ、およびＺはすべて同じ経路内のコンポーネントであって、ｘ１とｘ２は信号である。経路コンポーネントによって交換される信号は経路上を進行し、メッセージ配信または送信のための文脈を最終的に確立する。プロトコルのＣＣＰは（発明を実施するための形態）のセクション１と７に記述されているように、他のプログラミングステートメント内に埋め込まれて出現することもある。
【００２７】
各ＣＣＰの動作は、（発明を実施するための形態）のセクション１で説明するように、経路コンポーネント内に埋め込まれているｎｄＦＳＭ（非決定的有限状態機械）によって定義されており、１００メガビット／秒のメモリバスを備えている２ギガヘルツＣＰＵ（ハードウェア計算ユニット）内でソフトウェアに実装されているＣＣＰを実行するのに２５〜５０ナノ秒かかる。ＣＣＰは、ハードウェア機械命令としてＣＰＵ内に実装されていてもよい。ハードウェアに実装されている場合、ＣＣＰの実行は２ギガヘルツＣＰＵ内で５ナノ秒未満となる。
【００２８】
（４−ｉｉｉ）スケジューリング遅延の排除：メッセージを送信するために、セルＣはそのポートＣ．ｐの１つに関連付けられているｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｃ．ｐ．ｖＭ内に送信されるメッセージを書き込む。Ｃ．ｐ．ｖＭ内にメッセージを書き込んだすぐ後に、セルＣ自体は同様にＣ．ｐに関連付けられているプロトコルＣ．ｐ．ｐｒｏｔｏｃｏｌを実行する。Ｃ．ｐ．ｐｒｏｔｏｃｏｌの実行によって、信号がＣ．ｐ．ｐａｔｈｗａｙに沿って進行する。Ｃ．ｐ．ｐａｔｈｗａｙ経路はｓｍ経路またはｄｍ経路のことがある。メッセージを書き込むイベントとプロトコルを実行するイベントとは、同様に発生し、どのような種類の経路がポートＣ．ｐに接続されていても、プロトコルが実行されている間に経路上を進行する信号はＣ．ｐ．ｖＭ内のメッセージを最終的にその意図した受信者に配信つまり搬送する。ｖｉｒｔｕａｌＭｅｍｏｒｙの無い経路は、メッセージ無しに信号だけを意図した受信者に配信することになる。
【００２９】
プロトコルの実行中に、セルはプロトコル自体で定義されていないどのようなメソッドも使用せず、セルもセルの外部のどのようなプロセスも呼び出さない。メッセージを作製しｖｉｒｔｕａｌＭｅｍｏｒｙに書き込むためにセルによって実施される計算と、メッセージ／信号をその意図した受信者に送達するために同じセルによって実施される計算との間には、それらの計算を定義するコンピュータプログラムの詳細を除いて違いはない。両方の計算は、厳密にそのセルに限定され、他のセルで発生していることとは完全に独立している。メッセージの作製とメッセージ／信号の送信とはセルがメッセージ／信号の送信の準備ができるとすぐに同じセルによって即座に実施されるので、スケジューリング遅延が完全に排除される。
【００３０】
（４−ｉｖ）同期遅延の排除：同期遅延は信号を交換する各経路のハードウェアとソフトウェアコンポーネントとを互いに対して常にチューンされている状態に維持することによって排除される。そのような各コンポーネントは、その経路内の他のコンポーネントによって送信された信号を受信し即座に応答する準備が常にできていることになる。この種類のチューンは、（発明を実施するための形態）のセクション１に記述されているメソッドを使用して実現される。信号交換中にチューンによって同期遅延が完全に排除される。
【００３１】
（４−ｖ）非同期通信と逐次バッファリングの排除：全てのセルは準備ができると任意の時間にメッセージ／信号を送信し配信する可能性がある。メッセージ送信セルとメッセージ受信セルのいずれも通信中にブロックされることはない。全てのメッセージ／信号交換は非同期である。（発明を実施するための形態）で説明するように、逐次バッファリングはそのような非同期メッセージ／信号交換に対応するためには使用されず、代わりに経路のｖｉｒｔｕａｌＭｅｍｏｒｙを使用した並列バッファリング機構が使用される。
【００３２】
（４−ｖｉ）並列同時メッセージ交換：常に別個のセルが別個の経路に関連付けられている別個のプロトコルだけを同時に実行する。これは、（ａ）各セルはそれに付属しているポートにだけ関連付けられているプロトコルを実行できる、（ｂ）各セルは常に１つのプロトコルだけ実行できる、（ｃ）各ポートは唯一のセルにだけ付属している、（ｄ）経路は同じセルに付属している２つのポートの間でメッセージを送信しない、（ｅ）経路に接続されているメッセージ送信ポートの親セルとメッセージ受信ポートの親セルの両方がその経路に関連付けられているプロトコルを実行することはいかなる時にもできない、（ｆ）経路に接続されている２つ以上のメッセージ送信ポートの親セルによるその経路のプロトコルの同時の実行をその経路上のエージェントが自動的に調和させる、（ｇ）経路（ｓｍ経路またはｄｍ経路）のプロトコルの実行はその経路のコンポーネントの状態だけを変化させ、それ以外は変化させない、（ｈ）２つの経路（ｓｍ経路またはｄｍ経路）は共通のコンポーネントを共有することはない、（ｊ）各セルは他のどのようなセルとも共有されていない自身に割り当てられているＣＰＵ内で実行される、ためである。これらの特徴が共に相互干渉無しに別個のセルによるプロトコルの同時の並列の実行を保証し、それによってｓｍ経路とｄｍ経路の両方での並列メッセージ送信を可能にし、そのような並列の同時のメッセージ送信はアプリケーション内の別個の経路の数によってのみ制限される。
【００３３】
（４−ｖｉｉ）保証された高速並列通信：ＴＩＣＣＴＭ−Ｐｐｄｅにおける通信の以下の４つの特徴が２〜３００ナノ秒以下の範囲のレイテンシでの高速の並列メッセージ交換を保証する。（ａ）プロトコルの実行はいかなるプロセスによっても割り込まれない、（ｂ）複数のメッセージを別個の経路を介して並列に交換することが可能である、（ｃ）全ての同期とスケジューリングの遅延は完全に排除される、（ｄ）逐次バッファリングが非同期通信で使用されない。
【００３４】
ＣＣＰが１ギガビット／秒のメモリバスを備えている２ギガヘルツ計算ユニット内に機械命令としてハードウェア内に実装される場合、点対点メッセージはｓｍ経路を介して数十ナノ秒で交換することができる。ポートの１つのグループからポートの他のグループへのｓｍ経路を介したグループ対グループメッセージ交換は、各ポートグループ内のポートの数に依存して１００から３００ナノ秒かかることがある。グループ対グループメッセージ／信号は、ｄｍ経路を介して５００ナノ秒（推定）プラス信号送信時間未満で交換することが可能で、１つのＳＭＰ内のメッセージ送信ポートグループは常に同期してメッセージ／信号を他のＳＭＰ内の１つまたは２つ以上のメッセージ受信ポートグループに配信する。任意の所与の時間にアプリケーション内で同時に発生する可能性のある並列メッセージ／信号送信の数は、数千にもなるアプリケーションのＴＩＣＣＮＥＴＴＭ内の別個のｄｍ経路の数と、数万にもなるそのアプリケーションの共有メモリ環境内の別個のｓｍ経路の数によってのみ制限される。
【００３５】
したがって、ＲＥＳＴＣＬＫ［Ｄａｓ，１９］とは異なり、ＴＩＣＣＴＭ−Ｐｐｄｅは超並列ソフトウェアアプリケーションの共有メモリ環境と分散メモリ環境の両方でメッセージ配信が保証されているセル間の高速の同時の並列メッセージ／信号交換を可能にする。
【００３６】
５．自己調和と自己同期：グループ対グループ通信と計算はＴＩＣＣＴＭ−Ｐｐｄｅ内で信号を送信する経路内のエージェントが自動的に調和させ、同期させる。各グループ対グループｓｍ経路はｇｅｎｅｒａｌＰｏｒｔのグループをｆｕｎｃｔｉｏｎＰｏｒｔのグループに接続する。ポートグループ内の２つのポートが同じセルに属することはない。ｓｍ経路はｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍを１つだけ含んでいる。Ｍは付属している２つのエージェントを有している。エージェントの一方は全てのメッセージ送信ポートに接続され、他方のエージェントは全てのメッセージ受信ポートに接続されている（（発明を実施するための形態）のセクション７の図１９を参照）。グループ対グループ経路がポートグループによって送信されたメッセージを同じポートグループに配信する（図１７）ことも可能であって、そのような経路は自己ループ経路と呼ばれる。
【００３７】
ポートグループのポートの親セルはセルグループと呼ばれる。ｇｅｎｅｒａｌＰｏｒｔグループ、Ｇの親セルは、図１９に示しているように、結合サービス要求メッセージをｆｕｎｃｔｉｏｎＰｏｒｔグループ、ＦにＧのポートをＦのポートに接続している経路を通して送信することができる。経路のＧ内の全てのポートとＦ内の全てのポートに関連付けられているｖｉｒｔｕａｌＭｅｍｏｒｙはＧ．ｖＭ＝Ｆ．ｖＭと呼ばれる。このｖｉｒｔｕａｌＭｅｍｏｒｙはＧ内のポートによって送信されたサービス要求メッセージを保持している。経路内のエージェントは、Ｇ内のポートの全ての親セルがそれらのそれぞれの計算とＧ．ｖＭ内に書き込まれている結合サービス要求メッセージへの寄与とを完了した後で初めて、Ｇ．ｖＭ内のサービス要求メッセージをディスパッチする。これはディスパッチの調和である。いったんディスパッチされると、同じ経路内の他のエージェントはＧ．ｖＭ内のメッセージをＦ内の全てのポートにＦ内の連続しているポートの間の配信時間の差が２、３ナノ秒未満となるように同期して配信する。これが配信同期である。応答メッセージは、Ｆ内のポートの親セルによって、共同で同じｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｆ．ｖＭ内に書き込まれる。経路内の同じ２つのエージェントがＦからＧへの応答メッセージのディスパッチ調和と配信同期とを再度実施する。一般にポートグループは１つまたは２つ以上のポートを含んでいると仮定し、記号Ｐを経路を指すのに使用する。
【００３８】
互いに通信するセルグループ内のセルはディスパッチ調和と配信同期とに参加しない。セルグループ内の各セルは、セルが送信されるメッセージの経路のｖｉｒｔｕａｌＭｅｍｏｒｙへの書き込みを完了すると即座に、そのセルグループ内の他のセルと並列にグループ対グループ経路のプロトコルを単に実行するだけである。セルグループ内のセルによるプロトコルの実行は同期して発生しないが、セルによって実施される計算が互いに同期していないからである。経路内のエージェントはこの並列プロトコル実行を調和させ、結合サービス要求メッセージが受信側のｆｕｎｃｔｉｏｎＰｏｒｔに１度だけ同期して配信されることを保証する。経路Ｐ内のエージェントは５、６個の他のタスクも実行し、Ｐに接続されているＳＭＳ（自己監視システム）のコンポーネントがメッセージディスパッチとメッセージ配信イベントをＰを介して送信された各メッセージに対応しているＳＭＳにインストールするように指示するために、信号をこれらのコンポーネントに送信する。さらに、Ｐ内のエージェントとはデータセキュリティを実施する。エージェントはポートがメッセージとポートとに対して事前に指定されたセキュリティ条件を満たす場合にだけそのメッセージをそのポートに配信する。
【００３９】
Ｐ内のエージェントによって実施される全てのアクティビティは、Ｐのプロトコルによって指定されている。そのようなアクティビティの全てはＰに接続されているセルグループのセルとは独立してエージェントによって実施される。システム実装者は、どのような条件と同期メソッドも自分たちのプログラムに指定する必要は無い。これを自己調和と自己同期と呼ぶ（（発明を実施するための形態）のセクション１と７で説明）。
【００４０】
セルグループ内の各セルは自身に割り当てられている、別個でアプリケーション内の他のセルと共有されていないＣＰＵ内で実行（ｒｕｎ）される。セルグループ内のセルがそれら全てに対して配信されたサービス要求メッセージを共同で処理する場合、それらはそれらのそれぞれの計算を互いに調和させる必要がある。セルグループは、サービス要求メッセージを保持しているｖｉｒｔｕａｌＭｅｍｏｒｙが提供するスクラッチパッドを通して、サービス要求に応答しながら、データを互いに交換することによって、この調和を実施する。実装者は、そのようなセルグループ内のセルによって使用されるメソッドにスクラッチパッドを通してデータを交換することによってそれらのそれぞれの計算を調和させる機構を組み込むべきである。
【００４１】
ＴＩＣＣＴＭ−Ｐｐｄｅ内のグループ対グループ通信は並列自己調和と自己同期フォーク／ジョイン操作を並列計算に実装する。
【００４２】
６．効果的な低粒度実行：ＴＩＣＣＴＭ−Ｐｐｄｅの構成によって効率的な高速実行が可能になり、（ｉ）通信、プロセス、およびｐｔｈｒｅａｄ（並列スレッド）管理、調和、同期、割り込み処理、データ保護、セキュリティの実施へのオペレーティングシステムの介入の排除、（ｉｉ）全ての通信におけるスケジューリングと同期のセッションの必要性の排除、（ｉｉｉ）非常に低い通信レイテンシ、（ｉｖ）並列同時メッセージ交換、（ｖ）非同期通信における逐次バッファの排除、（ｖｉ）正確に時間設定されたプログラムとプロトコルの実行、および（ｖｉｉ）最小化されたメモリ競合がスクラッチパッドを使用したｖｉｒｔｕａｌＭｅｍｏｒｙ構成によって可能になる。通信レイテンシがナノ秒の範囲であるため、並列プログラムを超並列計算において１０から１００マイクロ秒の程度の低粒度で良好な効率（８０％から１００％）で実行（ｒｕｎ）することができる。
【００４３】
７．マルチコアチップに対する理想的な環境：ＴＩＣＣＴＭ−Ｐｐｄｅは５、６個のプログラミングアブストラクションを導入し、それらの多くはプログラミング技術にとっては新規である。アブストラクションに関連付けられているソフトウェアツールはさまざまなマルチコアチップにおいて実行（ｒｕｎ）可能な並列プログラムの構築を促進する。マルチコアチップ環境において並列プログラム開発と実行におけるアブストラクションとそれらに関連付けられているツールが演じる役割は以下の一覧に箇条書きにしている。
【００４４】
アブストラクション１：セル、ポート、および経路：これらのアブストラクションは新規ではないが、これらのＴＩＣＣＴＭ−Ｐｐｄｅにおける実現は新規である。これらはマルチコアチップ内の各ＣＰＵによって実施される計算を分離し保護し、チップ内の別個のＣＰＵによって同時に並列に実施される計算間の相互干渉を防止する。経路もメッセージを分離し保護し、チップ内のＣＰＵの別個のグループ間で同時に並列に交換される非同期メッセージの相互干渉を防止する。セルと経路とを定義し、インストールし、更新し、ＣＰＵのセルへの割り当てを管理し、割り当てられているＣＰＵ内でのセルの起動と、ＣＰＵによるｖｉｒｔｕａｌＭｅｍｏｒｙへのアクセスを制御するためにツールが提供される。任意の並列プログラミングアプリケーションで使用される可能性のあるポートと経路とのサブクラスは、ＴＩＣＣＴＭ−Ｐｐｄｅにおいて予め定められている。実装者はＴＩＣＣＴＭ−Ｐｐｄｅにおいて予め定義されていない通常ではないポートと経路のサブクラスだけを定義すればよい。アプリケーションで使用される各セルのサブクラスは実装者によって定義されなければならない。
【００４５】
アブストラクション２：付属、チューン、およびエージェント：付属しているまたは相互にチューンされているハードウェア／ソフトウェアコンポーネントだけが互いにメソッドとデータとを共有し、互いに信号を交換することができる。これは、セル、ＣＰＵ、およびメッセージの独立を実施するだけでなく、計算の自己同期および自己調和とメッセージ／信号の交換を促進する。アブストラクションのプログラミングとしての付属およびチューンはプログラミングについては新規である。ソフトウェアエージェントの概念は新規ではないが、ＴＩＣＣＴＭ−Ｐｐｄｅのエージェントの特定の特性はＴＩＣＣＴＭ−Ｐｐｄｅに固有である。付属とチューンはセルと経路の定義からＴＩＣＣＴＭ−Ｐｐｄｅによって自動的に実施される。実装はそれらを指定する必要は無い。任意の並列プログラミングアプリケーションで使用される可能性のあるエージェントのサブクラスは、ＴＩＣＣ−ＰｐｄｅＴＭにおいて予め定められている。実装者はＴＩＣＣ−ＰｐｄｅＴＭにおいて予め定義されていない通常ではないエージェントのサブクラスだけを定義すればよい。
【００４６】
アブストラクション３：ｖｉｒｔｕａｌＭｅｍｏｒｙ：専用のハードウェアメモリをハードウェアシステムに関連付けるのは計算システムで一般的である。しかし、専用のｖｉｒｔｕａｌＭｅｍｏｒｙをソフトウェアで使用されるハードウェアメモリのソフトウェアアブストラクションとして使用するという概念は、新規である。この概念は、Ｇｏｐｉｎａｔｈ［２１］によってまず導入され（この用語は使用されていないが）、それ以降、本発明者によっていくつかの強化を伴ってＴＩＣＣＴＭ−Ｐｐｄｅにおける並列プログラム開発と実行に対して採用された。コンパイル時または実行（ｒｕｎ）時に実際のメモリがｖｉｒｔｕａｌＭｅｍｏｒｙに割り当てられる。ｖｉｒｔｕａｌＭｅｍｏｒｙはマルチコアチップを使用した並列プログラミングとマルチコアチップの設計を単純化する。ｖｉｒｔｕａｌＭｅｍｏｒｙはメッセージを保持し、セル／メッセージの分離を強化する。さらに、それらはデータ保護、データセキュリティを実施し、メッセージを処理し作製し、メモリ干渉を最小化し（（発明を実施するための形態）、セクション６．２）、セルグループ内のセルに対してスクラッチパッドを提供しそれらの動作を調和させるために使用されるメソッドの実行環境を提供する。ＴＩＣＣＴＭ−ＰｐｄｅはｖｉｒｔｕａｌＭｅｍｏｒｙを定義し、宣言し、インストールし、更新するツールを提供する。任意の並列プログラミングアプリケーションで使用される可能性のあるｖｉｒｔｕａｌＭｅｍｏｒｙのサブクラスは、ＴＩＣＣ−ＰｐｄｅＴＭにおいて予め定められている。実装者はＴＩＣＣ−ＰｐｄｅＴＭにおいて予め定義されていない通常ではないｖｉｒｔｕａｌＭｅｍｏｒｙのサブクラスだけを定義すればよい。
【００４７】
以下の特徴４と特徴７で説明しているように、ｖｉｒｔｕａｌＭｅｍｏｒｙによってＳＭＭＣ（共有メモリマルチコアチップ）におけるメモリ構成に対する新しいアプローチが可能になり、それはＳＭＭＣ設計を単純化し性能効率を改善する。ＳＭＭＣ内の各ＣＰＵは１０キロワードから１メガワードの範囲のサイズの最小の量のプライベートメモリを使用し、キャッシュメモリやその他の高速化機構を使用せずに実装されている。しかし、ＳＭＭＣは１０キロワードから１ギガワードのサイズの範囲のハードウェア共有メモリモジュール、ＳＭＭのプールを有している。ＴＩＣＣＴＭ−ＰｐｄｅはＳＭＭをアプリケーション内で定義されている各ｖｉｒｔｕａｌＭｅｍｏｒｙにコンパイル時または実行（ｒｕｎ）時に割り当てる。並列プログラム実行時に、セルを実行（ｒｕｎ）するＣＰＵはそれらのセルによって使用されるｖｉｒｔｕａｌＭｅｍｏｒｙに既に割り当てられているＳＭＭに動的に接続されている。アプリケーション内のポートは必要に応じて動的にスケジュール作製とＣＰＵとＳＭＭとの間のそのような接続の解除を行う。各ＳＭＭは約８から１６個のＣＰＵだけに同時にサービスを行うことができる。この構成は２５６個以上のＣＰＵを含んでいる大規模のＳＭＭＣ内のメモリ競合を動的に減少させ、データセキュリティと保護にも貢献する。
【００４８】
アブストラクション４：ＣＣＰとプロトコル：全ての他のアブストラクションの統合を実際に可能にする際だったアブストラクションはＣＣＰ（因果通信プリミティブ）である。ＣＣＰは通信プロトコルを定義するためにＴＩＣＣＴＭ−Ｐｐｄｅで使用され、実行される時に信号をこれらのプロトコルに関連付けられている経路上を進行させる。それらは、ハードウェア／ソフトウェアコンポーネントが信号を動的にそしてプログラムに従って交換できるようにし、したがって、それらを分離しながらも互いに協力できるようにする。ＣＣＰに起因する信号交換は、開始／完了信号が非同期ハードウェアコンポーネントの同期、調和、および管理をするように、非同期ソフトウェア／ハードウェアコンポーネントを同期し、調和させ、管理する。任意の並列プログラミングアプリケーションで使用される可能性のあるプロトコルは、ＴＩＣＣ−ＰｐｄｅＴＭにおいて予め定められている。実装者はＴＩＣＣＴＭ−Ｐｐｄｅにおいて予め定義されていない通常ではないプロトコルだけを定義すればよい。
【００４９】
ＣＣＰは、ハードウェア／ソフトウェア相互動作、リソース割り当て、プロセス／スレッド管理、割り込み処理、同期、調和、およびセキュリティの実施を管理するためにオペレーティングシステムを使用する必要性を排除する。ＣＣＰ自体は機械命令であるため、ＴＩＣＣＴＭ−Ｐｐｄｅ内でＣＣＰは計算と通信との区別を排除する。計算を実行する同じセルが全ての必要な通信も実行する。メッセージ／信号を交換するためにオペレーティングシステムからのサポートは必要なく、プロセス／スレッドを管理するためにモニタは必要なく、ソフトウェア調和にセマフォ［２３、２４］は必要なく、ソフトウェア同期にランデブー技法［１０、１２］は必要ない。ＣＣＰの使用は通信を大きく加速し、ＴＩＣＣＴＭ−Ｐｐｄｅ並列処理アーキテクチャに必然的につながる。ＣＣＰを基本プログラミング言語プリミティブとして使用する概念はプログラミング技法に対して新規であって、その機械命令としての実装はＣＰＵの設計に対して新規である。
【００５０】
アブストラクション５：ＴＩＰ：ＴＩＰはスレッド相互動作プロトコルである。実装においてセルＣに付属している各ポートＣ．ｐはそのために定義されているＴＩＰ、Ｃ．ｐ：ＴＩＰ（）を有している。ＴＩＰは以下の機能を実行する：（ｉ）それらはアプリケーション内のポート間の相互動作のアブストラクト仕様によってソフトウェア開発を促進し、アブストラクト仕様を最終的な実装に次第にリファインし、（ｉｉ）それらは各セルにおいて通信をメッセージ処理とメッセージ構築計算から分離し、（ｉｉｉ）異なるセルで実行される並列計算を分離し、（ｉｖ）リファインの様々な段階において実装のためにモジュール化されているイベントベースのＡＬＬＥＯＰモデルの自動導出を可能にする、（ｖ）リファインの様々な段階において実装されたシステムの正式な検証のためのＡＬＬＥＯＰの柔軟な使用を可能にし、（ｖｉ）ＳＭＳ（自己監視システム）構成を可能にする。ＴＩＣＣＴＭ−Ｐｐｄｅは、実装仕様においてＴＩＰを定義、インストール、および更新するツールを提供し、それらをリファインし、ＡＬＬＥＯＰを導出し、所与の仕様からリファインの各段階において追跡する。プログラミングアブストラクションとして、ＴＩＰはプログラミング技法に対して新規である。全部で１０個の異なる種類のＴＩＰが存在する。ＴＩＣＣＴＭ−ＰｐｄｅのＴＩＰ定義フォーマットと実装中のアプリケーションにおけるＴＩＰの意図した機能とに整合した態様でアプリケーションの各ポートに対してＴＩＰを定義するのは実装者の責任である。
【００５１】
アブストラクション６：同期：
サイクル同期：アプリケーションの任意の２つの別個のポートｐとｑとに関連付けられている２つのＴＩＰ、ｐ：ＴＩＰ（）とｑ：ＴＩＰ（）とは、ｑ：ＴＩＰ（）の評価がｐ：ＴＩＰ（）の評価が完了した後に開始され、ｐ：ＴＩＰ（）の次の評価がｑ：ＴＩＰ（）の前回の評価の完了後に初めて開始される場合、サイクル同期される。ポートｐとｑは、アプリケーション内の任意の２つのセルに属していてもよく、同じセルに属していてもよい。サイクル同期は、アプリケーション内で動作の調和（順序付け）を課する。ＴＩＣＣＴＭ−Ｐｐｄｅはアプリケーション内の任意の２つのポートに関連付けられている２つのＴＩＰをサイクル同期する構成を提供する。
【００５２】
同期：ＴＩＰ、別個のセルのポートに属しているｐ：ＴＩＰ（）とｑ：ＴＩＰ（）とはそれらの評価が常に同時に始まる場合に同期している。ＴＩＣＣＴＭ−Ｐｐｄｅはアプリケーション内の任意の２つの別個のセルに関連付けられている２つのＴＩＰを同期する構成を提供する。
【００５３】
ＴＩＣＣＴＭ−Ｐｐｄｅは、ＴＩＰと経路の適切な定義によってサイクル同期と同期を設計または実装に導入するための系統的なメソッドを提供する。ＴＩＣＣＴＭ−Ｐｐｄｅはその点までのリファインの変更を必要とせずにリファインの任意の段階で後からの思いつきとしてこれらの同期を導入するメソッドも提供する（（発明を実施するための形態）のセクション６．６）。そのような後からの思いついた同期に使用されるメソッドをアドホック同期メソッドと呼ぶ。ＴＩＣＣＴＭ−Ｐｐｄｅで使用される全ての同期と調和のメソッドはプログラミング技術に対して新規であって、ＴＩＣＣＴＭ−Ｐｐｄｅに固有である。
【００５４】
アブストラクション7：ＣＩＰ：ＣＩＰはセル相互動作プロトコルである。ＣＩＰはセルの初期化手続きと共にセルのポートで定義されている全てのＴＩＰの集合である。ＣＩＰはセルがそのポートを循環的にポーリングする順番を指定する。２種類のＣＩＰが存在し、ポートでメッセージの存在を検知した時に即座にそのポートに対して定義されているＴＩＰを呼び出すＣＩＰと、ポートをセルに対してローカルな順序付け基準に従ってメッセージと共に順序付けポートリストに配置し、それからリストに現れるポートの順序でポートでＴＩＰボディを実行することによってポートに応答するＣＩＰである。セルがポートをまず並べ替える代わりにいくつかのポートに即座に応答し、それから他のポートを並べ替えることも可能である。
【００５５】
各ＣＩＰは並列処理システム内で他の全てのプロセスと並列に唯一のＣＰＵ内で実行（ｒｕｎ）される唯一のプロセスに関連付けられている。このＣＩＰプロセスをＣ：ＣＩＰ（）呼ぶことにする。Ｃ：ＣＩＰ（）はメッセージが配信されているＣのポートでＴＩＰを循環的に実行し、終了させられるかサスペンドされるまでその動作を継続する。Ｃ：ＣＩＰ（）を実行（ｒｕｎ）するＣＰＵはセルＣにＴＩＣＣＴＭ−Ｐｐｄｅによって関連付けられている。また、各セルは、その関連付けられているＣＰＵ内でＴＩＣＣＴＭ−Ｐｐｄｅによって起動される。ＣＩＰプロセスは、ＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラム実行における唯一のプロセスである。それらのスケジューリング、ＣＰＵ内での起動、サスペンド、レジューム、同期、および調和は、オペレーティングシステムの使用を必要とせずに、全てＴＩＣＣＴＭ−Ｐｐｄｅによって管理される。サービス要求の受信を認識するためのポーリングと何らかの順序でのそれらへの応答の概念は新規ではない。全てのソフトウェアシステムで広く使用されている。しかし、ＣＩＰにおけるこのサービスの具体的な実現はＴＩＣＣＴＭ−Ｐｐｄｅに固有である。
【００５６】
アブストラクション８：ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋ：
これはグラフィックの形態で実装とセルに付属しているポート間の経路相互接続に使用されるセルを指定する。ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋはアプリケーション内で発生する並列計算動作の全ての同期と調和とを暗示的に指定し、実施する。実装者はアプリケーションで使用されるＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋを指定する責任がある。これがいったん実施されると、実装者は並列コンピュータプログラムに調和、同期、またはアプリケーションの実行（ｒｕｎ）中の並列計算の任意の種類の監視のための任意の構成を組み込む全ての責任から完全に解放される。
【００５７】
ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋは並列プログラム実行の制御構造を指定し分析するための適切な種類のアブストラクションを提供する。データ構造アブストラクションが、逐次プログラムの構造がデータ構造とマッチする限り、逐次プログラムを最適化するために同じ逐次プログラムを異なるデータ構造定義で実行できるようにするように、ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋ構造は、アプリケーション内の各Ｃ：ＣＩＰ（）内の初期化ルーチンがＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋの構造とマッチする限り、並列プログラム構造を実験し最適化するために、並列アプリケーションプログラムの同じ集合が異なるＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋで実行（ｒｕｎ）できるようにする。
【００５８】
グラフィック表示を使用してシステムのコンポーネント間の相互動作の制御構造を捕らえることは新規ではない。しかし、ＴＩＣＣＴＭベースの並列ソフトウェアシステムにおいて解釈が独自のＴＩＣＣＴＭ−ｎｅｔｗｏｒｋの具体的な実現は新規である。
【００５９】
アブストラクション９：ＡＬＬＥＯＰとトレース：これら２つのアブストラクションが定義され使用される態様は新規であって、ＴＩＣＣＴＭ−Ｐｐｄｅに固有である。ＴＩＣＣＴＭ−Ｐｐｄｅは実装の仕様からＡＬＬＥＯＰを自動的に導出し、それらをソフトウェアシステムの確認に使用するツールを提供する。トレースの概念はそれ自体新規ではない。トレースという用語はプログラム実行の特定の実行（ｒｕｎ）において起こることの記述を指すために使用される。プログラミング分野が異なると、トレースの指定のために異なる統語構造またはグラフィックツールが使用される。ＴＩＣＣＴＭ−Ｐｐｄｅトレースはアプリケーションの特定の実行（ｒｕｎ）において発生する可能性のある全てを指定するだけでなく並列計算の意味論も定義する独自の特徴を有している。トレースはＡＬＬＥＯＰとアクションの入出力特性から自動的に導出される。アクションはｐｔｈｒｅａｄ（並列スレッド）または個別のプログラムステートメントまたは条件であってもよい。ＴＩＣＣＴＭ−Ｐｐｄｅはアクションの特徴付けを対話的に定義し、それらを使用してＡＬＬＥＯＰ（（発明を実施するための形態）のセクション２）から自動的にトレースを導出するツールを提供する。ＴＩＣＣＴＭ−Ｐｐｄｅは実装の特性を確認するためにトレースから自動的に導出されるＥＣＴ（イベント特徴付け表ネットワーク）ネットワークを使用するメソッドも提供する。
【００６０】
アブストラクション１０：ＳＭＳ、ｃａｕｓａｌａｎｔ、およびｅｂセル
ｃａｕｓａｌｎｅｔはトレースのアブストラクションであって、トレースは、トレース内で発生する通信イベントの因果チェーンだけを有している。アプリケーションＡ用のｃａｕｓａｌｎｅｔは、Ａの実行（ｒｕｎ）と並行にＡの実行中（ｒｕｎ）に、ＴＩＣＣＴＭ−ＰｐｄｅのＳＭＳ（自己監視システム）によって構築される。アプリケーションＡ内で各経路Ｐ内のエージェントは信号がＰに沿って進行中に、信号を経路Ｐに接続されているイベントビルダーセル（ｅｂセル）と呼ばれるＳＭＳの特別なセルに送信する。各経路Ｐは専用のｅｂセルのサービスを受ける。所与のｅｂセルは５、６個の経路のサービスを行うことになる。Ｐのｅｂセルによって受信された信号は、ｅｂセルにＰで発生するメッセージディスパッチと配信イベントをアプリケーションの拡大しているｃａｕｓａｌｎｅｔにインストールするように指示する。ｅｂセルは、Ｐによって配信されたメッセージがメッセージを受信したポートの親セルのポートによって処理されている間に、ディスパッチと配信イベントをインストールする。ｅｂセルの信号伝達は、経路上の信号送信と並列に発生し、ディスパッチと配信イベントのインスト−ルはＳＭＳイベントのタイミングとアプリケーションイベントのタイミングとの間の干渉を防止するために、メッセージ受信セルによって行われるメッセージ処理と並列に発生する。拡大しているｃａｕｓａｌｎｅｔがＳＭＳ内のｅｂセルによって構築されている間に、並列に実行（ｒｕｎ）される４つの動作が存在し、（ｉ）アプリケーション内で実行（ｒｕｎ）される全てのセルの動作、（ｉｉ）ＳＭＳ内のｅｂセルに信号送信する経路内のエージェントの動作、（ｉｉｉ）新しいメッセージディスパッチと配信イベントを使用して拡大しているｃａｕｓａｌｎｅｔを更新している間のｅｂセルの動作、および（ｉｖ）拡大しているｃａｕｓａｌｎｅｔを分析するＳＭＳのｅｂセルの動作（以下のアブストラクション１１を参照）である。
【００６１】
各ｅｂセルはｅｂセルを実行（ｒｕｎ）しているＣＰＵのローカル時間を使用して所与のメッセージのディスパッチと配信イベントがアプリケーション内でいつ発生したのかを求める。ｅｂセルを実行している全てのＣＰＵのローカル時間は標準化されているグローバルクロックに同期しているので、ｅｂセルによってｃａｕｓａｌｎｅｔ内でイベントインスタンスに関連付けられている全てのタイミングは同じグローバルクロックに同期することになる。アプリケーション内で他のセルを実行（ｒｕｎ）しているＣＰＵはグローバルクロックにも互いに対しても同期していない異なるローカルクロックを使用することがある。
【００６２】
アプリケーションの実装の仕様がそのアプリケーションに必要なＳＭＳ構造を自動的に定義する。アプリケーションに対してそのように定義されたＳＭＳ構造は、そのアプリケーションの各実行（ｒｕｎ）を動的に監視するためにＴＩＣＣＴＭ−Ｐｐｄｅによって自動的に呼び出され使用される。アプリケーションの実装者はこれを促進するためのどのようなプログラムも書く必要がない。ＴＩＣＣＮＥＴＴＭによって相互接続されている分散メモリ計算グリッド内の各ＳＭＭＣ（共有メモリマルチコアチップ）、Ｘはそれ自体の独自のローカルＳＭＳ、Ｘ：ＳＭＳ（）を有することになる。Ｘ：ＳＭＳ（）によって構築されたｃａｕｓａｌｎｅｔはＸのローカル共有メモリに存在することになる。ＴＩＣＣＴＭ−Ｐｐｄｅはｃａｕｓａｌｎｅｔを分散メモリ計算グリッドの異なるＳＭＭＣに統合し、必要に応じてＴＩＣＣＴＭ−ＧＵＩ（グラフィカルユーザインターフェイス）を使用してアプリケーション内の所与のセルまたはポートを中心にしてその任意の部分を表示することができる。
【００６３】
アブストラクション１１：ＳＭＳとｅａセル：ＳＭＳは、アプリケーションの各実行（ｒｕｎ）中に生成される、拡張するｃａｕｓａｌｎｅｔを常に監視するイベント分析セル（ｅａセル）と呼ばれる特別なセルを使用する。目的は、条件１のように拡張するｃａｕｓａｌｎｅｔ内のエラーと未解決のエラーとを識別し報告することである。ｅａセルは、ｃａｕｓａｌｎｅｔ内で事前に定義されたイベントパターンの発生を識別し、アラートを発生するために、ｃａｕｓａｌｎｅｔを監視してもよい。ｅｂセルはｅａセルによって実施されるｃａｕｓａｌｎｅｔ分析を使用して自身のｃａｕｓａｌｎｅｔ更新を調和させるために、ＣＣＰを使用して信号を交換することによってｅａセルと通信する。ＳＭＳはＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラム実行機構の一部である。
【００６４】
まとめ：ＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムの開発、確認、実行、および自己監視において使用される前述のプログラミングアブストラクションとメソッドの全てはＴＩＣＣＴＭ−Ｐｐｄｅに固有である。アブストラクションとメソッドとは１つとなって、並列プログラム内のアブストラクションのインスタンスをインストールし管理するためのツールを提供し、ＴＩＣＣＮＥＴＴＭに統合されているさまざまなマルチコアチップ内で実行可能な正式に継承された並列ソフトウェアシステムを構築する。この企画に対して重大なＴＩＣＣＴＭ−Ｐｐｄｅの特徴を以下に箇条書きにする。
【００６５】
８．ＴＩＣＣＴＭ−Ｐｐｄｅの重要な特徴：
特徴１：統合環境：ＴＩＣＣＴＭ−Ｐｐｄｅは、セルへのＣＰＵ割り当て、割り当てられたＣＰＵ内でのセルの起動、並列プロセス管理、ｐｔｈｒｅａｄ（並列スレッド）管理、通信、割り込み管理、セキュリティの実施、同期と調和を、これらのサービスのどのような部分の実行にもオペレーティングシステムや他のソフトウェアを呼び出すことを必要とせずに、実施する。現在のプロトタイプ実装において、ＴＩＣＣＴＭ−Ｐｐｄｅはオペレーティングシステムをメモリ管理、キャッシュ管理、２次ストレージへのアクセス、入出力、インターネットアクセスにだけ使用する。特徴４において示しているように、ＣＰＵ設計で一般に使用されるキャッシュメモリと全ての他の種類の高速化技法はＴＩＣＣＴＭ−Ｐｐｄｅプログラムの実行（ｒｕｎ）に使用されるＳＭＭＣ（共有メモリマルチコアチップ）内では無しに済まされている。オペレーティングシステムによってＴＩＣＣＴＭ−Ｐｐｄｅに現在提供されている全てのサービスは、ＴＩＣＣＴＭ−Ｐｐｄｅ自体内に組み込むことができる。したがって、ＴＩＣＣＴＭ−ＰｐｄｅはＳＭＭＣ内または５〜６個のＳＭＭＣからなる計算グリッド内での並列プログラムの開発、確認、実行（ｒｕｎ）、および監視に理想的に適している統合並列プログラム開発、確認、実行、およびランタイム監視環境を提供する。
【００６６】
特徴２：ＴＩＣＣＴＭ−ＧＵＩ：これは、所与のセルに固定されているＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋのセグメントと、所与のポートに固定されているＡＬＬＥＯＰのセグメントと、所与のポートとセルに固定されているｃａｕｓａｌｎｅｔのセグメントとのグラフィカル表現を表示する。ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋ表示の例だけを（発明を実施するための形態）のセクションに示している。ＴＩＣＣＴＭ−ＧＵＩは、ＧＵＩが受信したサービス要求に対してセル状態のポーリングを行う時点で実行（ｒｕｎ）されながら、アプリケーションの任意のセルの状態を調べる構成を提供する。表示要求が行われた時刻に正確に一致する時点でセルの状態を表示することは現実的には不可能である。しかし、ブレークポイントを設定し、特定のイベントが発生した時に状態を表示させることができる。しかし、そのようなブレークポイントをアプリケーションＡに導入することはＡ内で発生するイベントのタイミングを変えることになる。したがって、ブレークポイントは試験モードでのみ使用可能である。ＧＵＩはシステム実装を文書化することと、動的システム監視の両方に対して有用である。ＴＩＣＣ−ＧＵＩはＴＩＣＣ−Ｐｐｄｅの必要不可欠の部分である。
【００６７】
特徴３：任意のスケーラビリティ：スケーリングに起因する相互作用オーバーヘッドがプログラム実行時間と比較して短い限り、ＴＩＣＣＴＭ−Ｐｐｄｅ内の並列プログラムは任意にスケーラブルである。ＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムに固有なことは、相互作用オーバーヘッドがＴＩＣＣＴＭ−ｎｅｔｗｏｒｋの構造に相対的に正確に定義可能なことである。Ｎをセルと経路のＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋとし、ｎｍａｘ（Ｎ、Ｃ）をＮにおいてそのポーリングサイクルの１つでのセルＣによって交換されるメッセージ最大数とする。ｎｍａｘ（Ｎ）をＮ：ｎｍａｘ（Ｎ）＝Ｍａｘｉｍｕｍ｛ｎｍａｘ（Ｎ，Ｃ）｜Ｃ∈Ｎ｝内のＣについての全てのｎｍａｘ（Ｎ，Ｃ）の最大数とする。ｖ（Ｎ）をネットワークＮ内のセルの数とし、Ｎ’をｖ（Ｎ’）セルを備えているＮのスケールアップ版とする。すると、任意のスケーラビリティに対する要件は：ｎｍａｘ（Ｎ’）がスケーリングファクタα＝[ｖ（Ｎ’）／ｖ（Ｎ）]に無関係なことである。この条件が満たされると、αの値は数百万になり得る。これは、本質的に、スケーリングファクタが増加してもセルあたりの通信と調和のオーバーヘッドが増加しないということである。
【００６８】
特徴４：キャッシュメモリと高速化技法の排除：キャッシュメモリはＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムの実行（ｒｕｎ）に対して無しに済ませることができる。我々のプロトタイプ実装において、キャッシュメモリはやっかいなものに過ぎない。粒度の小さい実行によって、キャッシュ補充において無駄になる時間が長すぎ、キャッシュが一貫していないことが問題になることが多い。キャッシュの非一貫性を避けるためにはメインメモリ内のデータを更新しなければならなかった。キャッシュメモリはＴＩＣＣＴＭ−Ｐｐｄｅにおける高スループットプログラム実行には必要ない。高スループットはセル内の低粒度並列プログラム実行の任意のスケーリングによって実現することができる。実際に、複数の命令ストリーム実行［２９］、先読みスケジューリング［３０］、パイプライン処理［３１］、およびキャッシュ化実行［３２］などの通常の高速化技法はＴＩＣＣＴＭ−Ｐｐｄｅの高効率と高スループットに対しては必要ない。ＴＩＣＣＴＭ−Ｐｐｄｅにおいて、各ＣＰＵは、１つのセルだけのサービスをそのセルに関連付けられているｖｉｒｔｕａｌＭｅｍｏｒｙだけを使用してもっぱら行う。各セルは、１つのＴＩＰだけを任意の所与の時間に実行してもよく、ＴＩＰの実行は割り込み不能である（（発明を実施するための形態）、セクション５）。通信と計算の両方を含むＴＩＰの実行にかかる時間はほんの１０〜１００マイクロ秒である。同期、調和、および監視のオーバーヘッドは存在しない。したがって、ＴＩＣＣＴＭ−Ｐｐｄｅにおいて前述の高速化技法のいずれかを採用するのが有利な自然な文脈は存在しない。これには２つの利点があって、（ｉ）ＳＭＭＣ（共有メモリマルチコアチップ）におけるＣＰＵ設計を簡略化し、チップ内のＣＰＵ密度を増加させることと（ｉｉ）厳密な境界によってイベントタイミング予測を可能にすることである。
【００６９】
特徴５：自己監視を備えている確認されたサイバー物理実時間システムの開発にとって理想的な環境：所与の境界内での正確なタイミングでのソフトウェア実行はサイバー物理実時間システムの構築にとって必要であって重要な要件である。ＴＩＣＣＴＭ−Ｐｐｄｅはソフトウェアシステムの正式な確認、ＳＭＳを使用した自動自己監視、正確に定義された境界のあるイベントタイミングの予測を促進する。ＴＩＣＣＴＭ−Ｐｐｄｅが、航空機や宇宙船システムのオートパイロット、自動化マルチセンサ用途、軍事乗り物における自動化された防衛／攻撃の調和、自動化された工場、ロボット、または任意の他のそのような時間が重要な反応システムなどのサイバー物理実時間システムを開発し、確認し、展開するための理想的な環境を提供することがこれまでに明かである。医療情報システム、知能情報システム、任意のデータベースシステムなどの安全な情報システムの構築に使用することもできる。ＴＩＣＣＴＭ−Ｐｐｄｅ用の重要な最も広く使用されているアプリケーションは不正な侵入と攻撃とに対するプライバシーと保護とを保証するＳＭＭＣを備えているパーソナルコンピュータシステムの可能性がある。
【００７０】
特徴６：動的柔軟性とモビリティ：ＴＩＣＣＴＭ−Ｐｐｄｅ並列プログラムは、経路接続を動的に変更し、新しいセルと経路とを動的に導入することによって、動的に修正し、更新することができる。古いバージョンの通常の動作の変更がほとんどまたは全く無しに、並列のセルの新規のバージョンをそのままで試験することについては米国特許第７，２１０，１４５  Ｂ２号を参照。分散環境でのプログラムのモビリティは、１つのプロセッサのｖｉｒｔｕａｌＭｅｍｏｒｙの内容全体を分散システムの他のプロセッサの他のｖｉｒｔｕａｌＭｅｍｏｒｙに転送することによって達成される。
【００７１】
特徴７：必要なＣＰＵの特徴：
本発明においては、各ＣＰＵはそのローカルクロックがセルに付属している有限な一定数（高々１０または１５）のポートによって同時に並列にポーリングされることを可能にするのに必要な特別なハードウェア構成を有することを仮定している。ポートが親セルを実行（ｒｕｎ）しているＣＰＵのクロックがメッセージがそのポートに配信される時にメッセージ配信時刻を登録するためにＣＣＰ信号を送信することによってポーリングされるようにしてもよい。この構成は、以下のようにハードウェア内に実装されてもよく、セルＣを実行（ｒｕｎ）するＣＰＵはその現在の時刻をセルのポートＣ．ｐのｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｃ．ｐ．ｖＭにインストールされている特別に指定されている時刻レジスタ、ＲＴ（Ｃ．ｐ）（「Ｔ」は「Ｔｉｍｅ」を表す）の集合に常にブロードキャストする。各ポートＣ．ｐは配信時刻レジスタＲＤ（Ｃ．ｐ）と呼ばれ関連付けられている追加の時刻レジスタを有していてもよい。信号がポートＣ．ｐに配信されるたびに、ＲＴ（Ｃｐ）内の現在の時刻はＲＤ（Ｃ．ｐ）へ自動的にゲーティングされる。したがって、ＲＤ（Ｃ．ｐ）の時刻はＣ．ｐでの信号配信時刻をマーキングすることになる。この構成は、ＴＩＣＣＴＭ−Ｐｐｄｅで使用される全てのＣＰＵに組み込まれなければならない。このタスクのどのような部分を実行するためにもオペレーティングシステムを使用する必要は無い。
【００７２】
ポートＣ．ｐについて、メソッドＣ．ｐ：ｔｉｍｅＳｔａｍｐ（）はＣ．ｐのこのクロック読み取り機構を呼び出すために使用される。メソッドＣ．ｐ：ｔｉｍｅＳｔａｍｐ（）は、クロック時刻が読み取られるＣＰＵによって実行されるのではなく、メッセージをＣ．ｐに配信するセルを実行するＣＰＵによって実行される。したがって前述の構成が必要になる。この方法は、配信信号が任意のアプリケーションのポートＣ．ｐ（（発明を実施するための形態）のセクション７）に送信されるたびに呼び出される。アプリケーション内の全てのクロックが同期していなければならないという要件は存在しない。ｅｂセルのクロックだけがすべて共通のグローバルクロックに同期していなければならない。各セルでクロックの並列な同時の読み取りの必要があるが、それはメッセージをセルのポートに同時に、並列に配信できるからである。
【００７３】
ＣＰＵに対して２〜３の他の要件がある。ＳＭＭＣ（共有メモリマルチコアチップ）内のＣＰＵはキャッシュメモリ無しに、しかし１０キロワードから１メガワードの大きさの限定された量のプライベートメモリを使用して構成されていなければならない。各ＳＭＭＣはハードウェア共有メモリモジュールの集合をそのようなモジュールのプール内に有していなければならない。それらをＳＭＭ（共有メモリモジュール）と呼ぶ。各ＳＭＭのサイズは１０キロワードから１ギガワードの範囲であってもよい。各ＳＭＭは、セルグループのあり得る最大サイズである、高々わずか１６個のＣＰＵに同時にサービスを行うための容量を有していなければならない。ＳＭＭはコンパイル時または実行（ｒｕｎ）時にＴＩＣＣＴＭ−Ｐｐｄｅによってアプリケーション内のｖｉｒｔｕａｌＭｅｍｏｒｙに割り当てられており、ＴＩＣＣＴＭ−Ｐｐｄｅは所与の実装仕様からさまざまなｖｉｒｔｕａｌＭｅｍｏｒｙに割り当てられるＳＭＭのサイズを決定する。セルを実行（ｒｕｎ）する各ＣＰＵはセルが割り当てられているＳＭＭに、そのセルによって使用されるｖｉｒｔｕａｌＭｅｍｏｒｙにそれらのｖｉｒｔｕａｌＭｅｍｏｒｙへのアクセスが許可された時に、動的に接続されてもよい。ＣＰＵをＳＭＭメモリバスに動的に接続するためにＣＰＵ設計においてプログラマブルロジックネットワークを使用してもよい。
【００７４】
このスキームが、ＳＭＭＣをデータセキュリティとメモリ競合の問題が伴う大きな数ギガワードのサイズの共有メモリに統合する必要性を排除する。本明細書で提案するスキームは実行（ｒｕｎ）時のメモリ競合を大幅に減少させる。また、１つの巨大な共有メモリが無いことと、共有の能力が非常に限定されているｖｉｒｔｕａｌＭｅｍｏｒｙの使用によって、セキュリティ、プライバシー、およびデータ保護が強化されるが、それは（ｉ）各エージェントはｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージをポートにポートがメッセージとポートに対して指定された事前に指定されたセキュリティ条件を満たす場合にだけ配信する、（ｉｉ）ＴＩＣＣＴＭ−Ｐｐｄｅの各ポートはそのｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージを保護し、そのｖｉｒｔｕａｌＭｅｍｏｒｙへのアクセスを親セルにだけ、そして親セルがメッセージの送信の準備ができた時または安全に配信されたメッセージ／信号に応答する準備ができた時にだけ許可する。さらに、ＴＩＣＣＴＭ−Ｐｐｄｅは集中スケジューリング機構と、プロセスとメソッドの集中起動ディレクトリ（動的リンクライブラリ）とを有していない。これらの特徴は併せてデータ盗難とシステム侵入に対する手強い障壁となる。
【図面の簡単な説明】
【００７５】
【図１】ＴＩＰ、プロトコル、およびＣＣＰ特徴付けを示している簡単な経路、（Ｃ．ｇ⇔Ｄ．ｇ）の図であって、セクションＩＶ、１．２．の詳細図である。
【図２】ｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍ、エージェント、ａ０とａ１、ＴＩＰ、プロトコル、およびＣＣＰ特徴付けを備えている点対点経路（Ｃ．ｇ⇔Ｄ．ｇ）の図であって、セクションＩＶ、１．２．１．の詳細図である。
【図３】エージェントａ０、ＴＩＰ、およびプロトコルを備えている簡単な点対グループ経路（Ｃ．ｇ⇔［Ｄ１．ｆ，Ｄ２．ｆ］）の図であって、エージェントは同期したサービス要求信号をＣ．ｇからポートグループ［Ｄ１．ｆ，Ｄ２．ｆ］の両方のポートに配信し、１つの調和した結合応答信号をＣ．ｇからＤ１．ｆとＤ２．ｆに返信する、セクションＩＶ、１．２．２．の詳細図である。
【図４】エージェントａ０とａ１、ＴＩＰ、およびプロトコルを備えている点対グループ経路（Ｃ．ｇ⇔［Ｄ１．ｆ，Ｄ２．ｆ］）の図であって、エージェントａ０はサービス要求信号をＣ．ｇから受信し、それをエージェントａ１に送信し、エージェントａ１は同時にそれをポートグループ［Ｄ１．ｆ，Ｄ２．ｆ］の両方のポートに配信し、［Ｄ１．ｆ，Ｄ２．ｆ］の両方のポートが応答信号返信する時に、エージェンａ１は両方の信号の受信を待ち、１つの調和した結合応答信号をＣ．ｇにａ０を通して返送する図であって、セクションＩＶ、１．２．２．の詳細図。
【図５】Ｂｉｌｌ／Ｂｅｎ問題の解法のためのセルと経路のＴＩＣＣ−Ｎｅｔｗｏｒｋの図であって、セクションＩＶ、２．１．５．の詳細図である。
【図６】Ｂｉｌｌ／Ｂｅｎ解法ＡＬＬＥＯＰとトレースのグラフィック表現であって、ＩＶ、２．１．５．の詳細図である。
【図７】話す／痒がる問題の解法のＴＩＣＣネットワークの図であって、セクションＩＶ、２．２．の詳細図である。
【図８】非独立ポートの新規のセルへの移動の図であって、セクションＩＶ、４．５．の詳細図である。
【図９】従来とＴＩＣＣのアーキテクチャの対比の図であって、セクションＩＶ、４．６．の詳細図である。
【図１０】ＯＧ解法用のＴＩＣＣネットワークの図であって、セクションＩＶ、６．１．の詳細図である。
【図１１】ｖｉｒｔｕａｌＭｅｍｏｒｙの構造の図であって、セクションＩＶ、６．２．の図である。
【図１２】ＰＣ解法用のＴＩＣＣネットワークの図であって、セクションＩＶ、６．３．の図である。
【図１３】ＤＰ解法用のＴＩＣＣネットワークの図であって、セクションＩＶ、６．４．の図である。
【図１４】構成の分岐する木の図であって、セクションＩＶ、６．４．の図である。
【図１５】連続しているポーリングサイクルにおける執事の状態の図であって、セクションＩＶ.６．４．の図である。
【図１６】アドホック調和の図であって、セクションＩＶ、６．６．の図である。
【図１７】自己ループ経路を使用しているアドホック同期の図であって、ポートＣｉ．ｆ、０≦ｉ＜ｎの全ての親セルはそれぞれのポートＣｉ．ｆで受信したメッセージの処理を同時に同期して開始し、各々が同期して配信された信号をＣｉ．ｇを通して受信する、セクションＩＶ、６．６．の図である。
【図１８】非有限状態ＡＬＬＥＯＰを備えている拡大しているＴＩＣＣネットワークの図であって、セクションＩＶ、６．７．の図である。
【図１９】ＳＭＳ用インフラストラクチャを備えているグループ対グループＴＩＣＣ経路の図であって、セクションＩＶ、７．を説明する図である。
【図２０】図１９の経路を通したグループ対グループ通信にＳＭＳによってインストールされた因果ネットの部分の図であって、セクションＩＶ、７．を説明する図である。
【図２１】図１９の経路を通したグループ対グループ通信にＳＭＳによってインストールされた因果ネットの部分の図であって、セクションＩＶ、７．を説明する図である。
【図２２】図２０と２１に示している部分の組み合わせから生じるｃａｕｓａｌｎｅｔであって、セクションＩＶ、７．の図である。
【図２３】一方通行の環状道路の構造の図であって、図を簡単にするためにＳＭＳ用の経路増加は不図示、セクションＩＶ、７．１．を説明する図。
【図２４】（特許請求の範囲）のメソッド（２．４）で説明するｄｍ経路Ｄｉの模式図、各ＳＭＰ（共有メモリマルチプロセッサ）は自身のＳＭＳ（自己監視システム）を有する模式図である。セクションＩＶ：
【発明を実施するための形態】
【００７６】
特許の名称：マルチコアチップ用の正式に検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ  Ｖ．  Ｓｒｉｎｉｖａｓａｎ、顧客番号：００００３３６４１
米国国コードおよび優先出願の番号：ＵＳ  ６１／１９５，９６５
優先日：２００８年１０月１４日
発明者の住所：２０３１  ＳＥ  Ｋｉｌｍａｌｌｉｅ  Ｃｏｕｒｔ、Ｐｏｒｔ  Ｓａｉｎｔ  Ｌｕｃｉｅ、ＦＬ  ３４９５２  電話：  ７７２  ３３７  １３８８  Ｆａｘ：  ７７２  ３３７  １３８８、携帯電話：  ７７２  ２８５  ６４６３  Ｅｍａｉｌ：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
【００７７】
１．因果通信プリミティブ（ＣＣＰ）とＲＥＳＴＣＬＫ経路の適用
利便と連続性のために、このセクションにおいて、米国特許第ＵＳ  ７，２１０，１４５  Ｂ２号において、発明者Ｃｈｉｔｏｏｒ  Ｖ．  Ｓｒｉｎｉｖａｓａｎによって導入されたいくつかの概念と機構とを別の視点で説明する。また、このセクションにおいて、簡単なＴＩＰ（スレッド相互動作プロトコル）、ＣＩＰ（セル相互動作プロトコル）の構造、および簡単な通信プロトコルを説明する。
【００７８】
ハードウェアシステムにおいて、ハードウェアコンポーネントの動作を制御し、同期し、調和させるために信号を使用するのは常習である。同期ハードウェアにおいてはクロック信号が使用され、非同期ハードウェアにおいては開始と完了信号とが使用される。米国特許第ＵＳ  ７，２１０，１４５  Ｂ２号で説明しているように、Ｇｏｐｉｎａｔｈ［２１］がソフトウェア／ハードウェアコンポーネント間でプログラムに従って信号を交換することを最初に提案し、［Ｄａｓ，１９］が信号が進行可能な共有メモリＲＥＳＴＣＬＫ経路の構造を最初に定義した。ＧｏｐｉｎａｔｈとＤａｓは信号を送信し、受信し、処理するために短いスレッドを使用し、オペレーティングシステム（ＯＳ）によって管理されるタイムスライスされた並行性を備えている彼らのシステムを実装した。スレッドによって定義されている信号交換機構は共有メモリ環境でのメッセージ交換の実装に使用された。分散ネットワーク上の通信は、たとえばＥＴＨＥＲＮＥＴ［Ｓｐｕｒｇｅｏｎ、２２］などのネットワーク機構を使用して実施された。
【００７９】
タイムスライスされた並行スレッドスケジューリングと起動によって非決定性が信号交換に導入された。メッセージは、境界のあるレイテンシ内で配信することができず、メッセージが失われることもあった。ＴＩＣＣＴＭは、ＯＯ（オブジェクト指向）プログラミング言語の文脈で共有メモリおよび分散メモリシステムの並列プログラミングへの応用に対して、数十から数百ナノ秒の範囲の境界のあるレイテンシで保証された並列メッセージ配信を実現するために、ＧｏｐｉｎａｔｈとＤａｓとによって導入された枠組みを適用し修正している。
【００８０】
ソフトウェア／ハードウェアコンポーネント間の保証された、プログラミングに従った信号の高速な交換によって、ソフトウェアはコンポーネント分離を維持しながら、ハードウェアシステム内でその実行を直接制御することが可能である。ＴＩＣＣＴＭにおいて、共有メモリ環境と分散メモリ環境の両方で、全ての通信、プロセス、およびｐｔｈｒｅａｄ（並列スレッド）スケジューリングと起動、割り込み処理、データ保護、セキュリティの実施、同期、調和、および自己監視に対して現在これを行っている。プロトタイプＴＩＣＣＴＭ−Ｐｐｄｅはオペレーティングシステムをメモリ管理、ページング、キャッシング、および入力／出力にだけ使用している。全てのオペレーティングシステムサービスをＴＩＣＣＴＭ−Ｐｐｄｅ自体に実装することが最終的に可能でなければならない。
【００８１】
１．１．  ＣＣＰとプログラミングに従った信号交換
ハードウェア／ソフトウェアコンポーネント間の信号交換は、ＴＩＣＣＴＭにおいて因果通信プリミティブ、ＣＣＰと呼ばれる新規のプログラミングプリミティブを使用することによってプログラムに従って指定されている。各ＣＣＰはＸ：ｘ→Ｙの形態を有しており、ｘは開始または完了信号、ＸとＹはソフトウェアまたはハードウェアコンポーネントである。信号の各タイプは、それに対して定義されているサブタイプを有していてもよい。ＣＣＰは割り当てのようであって、信号をコンポーネントに割り当てる。しかし割り当てとは異なり、信号割り当ての効果は、一定の遅延後に初めて明白になる。ＴＩＣＣＴＭにおいて、所望の効果は究極的にはメッセージ配信またはメッセージディスパッチであり、ＣＣＰの名前の由来である。
【００８２】
ＣＣＰを使用した信号交換の指定には５、６個の利点があり、（ｉ）割り当てのように、ＣＣＰは他のプログラミングステートメント内に自由に埋め込み可能で、したがって、計算の中にプログラムに従った信号交換が可能になり、（ｉｉ）ＣＣＰはハードウェア機械命令としてＣＰＵ内に実装されていてもよく、（ｉｉｉ）プログラム実行を柔軟に実行し、（ｉｖ）通信と計算との間の区別を排除し、（ｖ）同じプロトコル起動形態を共有メモリ通信と分散メモリ通信の両方で使用し、（ｖｉ）ＴＩＣＣＴＭ信号交換機構はＲＥＳＴＣＬＫ［Ｄａｓ、１９］信号交換機構とは異なるが、最小限の変更だけでＲＥＳＴＣＬＫ経路構造を維持することを可能にする。
【００８３】
各ＣＣＰは２状態または４状態ｎｄＦＳＭ（非決定的有限状態機械）によって実装される。ＦＳＭは状態遷移がＦＳＭの各状態における全ての入力に対して定義されていないという意味でだけ非決定的である。１００メガビット／秒メモリバスを備えている２ギガヘルツＣＰＵ（ハードウェア計算ユニット）内でソフトウェアに実装されているＣＣＰを実行するのに２５〜５０ナノ秒かかる。２ギガヘルツＣＰＵ内で機械命令としてハードウェアに実装された場合、わずか５ナノ秒（予測）しかかからない。
【００８４】
ポイント対ポイントメッセージ転送にはＣＣＰによって制御されている４つの２状態ｎｄＦＳＭだけが必要で、各グループ内のセルの数に依存して（セクション７）、共有メモリ環境においてセルの１つのグループからセルの他のグループにメッセージを転送するには８個以上の２状態ＦＳＭが必要で、ＴＩＣＣＮＥＴＴＭを使用している分散メモリ環境における同様なメッセージ転送のために１０個以上の２状態および４状態ｎｄＦＳＭが必要である。ＳＭＳ機構をメッセージ転送に組み込むには、もう２つの２状態ｎｄＦＳＭ（セクション７）が必要である。したがって、ＣＣＰがハードウェア命令として実装されている場合、前述のように、ポイント対ポイントおよびグループ対グループメッセージ転送には数十から数百ナノ秒しかかからない。
【００８５】
各セルは割り当てられているＣＰＵ内で自身の通信プロトコルの全てを実行する。通信はｎｄＦＳＭによって実施されるチューリング計算［Ｔｕｒｉｎｇ、２０］に簡略化され、セルによって実施される計算の不可欠な部分となる。各セルは準備ができ次第、そのポートに接続されているハードウェア／ソフトウェア経路を介してそのメッセージを即座に送信する。同期またはスケジューリングの遅延は存在しない。複数のプロトコルを相互干渉無しに並列に動作しているセルによって実行可能である。しかし、各セルは常にプロトコルを１つだけ実行してもよい。これによって、同時のメッセージ転送が可能になる。全ての通信は非同期であって、逐次バッファを使用しない。
【００８６】
読者が（発明の概要）に概説されている利点がどのようにこれから直接得られるのかがわかる前に、これらがどのようにして可能になるのかと、各セルによって実行される計算と通信とをどのように調和させるのかを説明しなければならない。
【００８７】
１．１．経路プロトコル、ＴＩＰ、メッセージ送信、および計算
セルはそれらのポートを使用してポートを相互接続する経路を介してメッセージを互いに交換する。各ポートはポートの親セルと呼ばれる唯一のセルだけに付属させることが可能で（ポートの競合を防止）、各ポートは１つの経路にだけ接続することができる（メッセージ干渉の防止）。３種類のポートが存在し、セルがサービス要求を他のセル（）に送信するｇｅｎｅｒａｌＰｏｒｔ、ｇ（これらはπ算法エージェント［Ｍｉｌｎｅｒ、７、８、９］）の出力ポートに似ている）、他のセルからサービス要求を受信するｆｕｎｃｔｉｏｎＰｏｒｔ、ｆ（これらはπ算法の入力ポートに似ている）、および他のセルから割り込みメッセージを受信するｉｎｔｅｒｒｕｐｔＰｏｒｔ、ｉ（これらに対してはπ算法の類似物はない）。ＧｅｎｅｒａｌＰｏｒｔとＦｕｎｃｔｉｏｎＰｏｒｔはアブストラクトクラスＰｏｒｔのサブクラスである。ｉｎｔｅｒｒｕｐｔＰｏｒｔはＦｕｎｃｔｉｏｎａｌＰｏｒｔのサブクラスである。各Ｃｅｌｌサブクラスは各種類のポートを少なくとも１つ有していなければならない。
各ポートは信号を接続されている経路上で送信するための通信プロトコルを保持している。このプロトコルはＸ：ｘ→Ｙ：ｙ→ｚの形態を有しているＣＣＰの連結を使用して定義され、Ｘ、Ｙ、およびＺは経路のコンポーネントであって、ｘとｙは信号である。ＣＣＰは他のプログラミング言語のステートメントに埋め込まれる可能性のあるプロトコルに現れてもよい。プロトコルは経路が変更されると動的に更新される。各経路は、ＣＣＰを実行する相互動作するｎｄＦＳＭの集合によって定義される。ポートの親セルのだけがそのポートに関連付けられているプロトコルを実行できる。
【００８８】
経路とＣＳＰチャネル：
共有メモリ環境における経路には、ＣＳＰ［Ｈｏａｒｅ、１０〜１２］チャネルのようにソフトウェアコンポーネントだけが含まれている。しかし、ＣＳＰチャネルとは異なり、ＴＩＣＣＴＭ−ＰｐｄｅのｐｔｈｒｅａｄはＣＳＰの通信逐次プロセスに対応する。経路は、（ｉ）同期メッセージ配信を行うグループ対グループ非同期通信を可能にし、（ｉｉ）ＴＩＣＣＴＭ−Ｐｐｄｅ内の相互動作しているｐｔｈｒｅａｄ間のデータ交換機構はｐｔｈｒｅａｄ内にコード化されておらず、（ｉｉｉ）経路は信号のみを送信し、（ｉｖ）メッセージが送信されると、経路はｖｉｒｔｕａｌＭｅｍｏｒｙを含み、ｖｉｒｔｕａｌＭｅｍｏｒｙはメッセージを構築し処理するためにメッセージとｐｔｈｒｅａｄを保持する。コンパイル時または実行（ｒｕｎ）時に実際のメモリがｖｉｒｔｕａｌＭｅｍｏｒｙに割り当てられる
【００８９】
経路上を進行する信号は、そのｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージが、共有メモリ経路（ｓｍ経路）の場合には意図した受信者に配信され、分散メモリ経路（ｄｍ経路）の場合には意図した受信者に属する他のｖｉｒｔｕａｌＭｅｍｏｒｙに送信される文脈を最終的に確立し、各ｓｍ経路に対して、メッセージを保持しているｖｉｒｔｕａｌＭｅｍｏｒｙは、１つ存在する場合、その経路にとって唯一でプライベートである。同様に、各ｄｍ経路について、その経路内の全てのｖｉｒｔｕａｌＭｅｍｏｒｙその経路に対してプライベートである。経路は他の経路のｖｉｒｔｕａｌＭｅｍｏｒｙを使用しない。ＣＳＰチャネルとは異なり、経路は送信者と受信者を妨げない。
【００９０】
ｖｉｒｔｕａｌＭｅｍｏｒｙを備えているｓｍ経路をＤａｓ経路と呼び、それはそれらがＳｏｕｒｉｐｒｉｙａ  Ｄａｓ［Ｄａｓ、１９］によって初めて導入されたからである。ｓｍ経路とｄｍ経路の両方を指すために経路という用語を使用する。
【００９１】
１．２単純なｓｍ経路
いくつかの単純なｓｍ経路をまず考える。ポートの親セルは信号をそのポートに接続されている経路を通して送信するためにそのポートでプロトコルを実行する。プロトコルを実行する時に、親セルはローカルメモリと経路コンポーネントに割り当てられているメモリだけを使用する。プロトコルの実行によって、プロトコルの外側で定義されているどのようなメソッド、ｐｔｈｒｅａｄ、またはプロトコルも呼び出すことはない。オペレーティングシステム（ＯＳ）はメッセージ交換には使用されない。
【００９２】
2012506076.tif 000002
【００９３】
図１：単純なポイント対ポイント経路
図１に示している簡単な経路を考える。ここで、ソフトウェアブランチはセルＣのｇｅｎｅｒａｌＰｏｒｔ、Ｃ．ｇをセルＤのｆｕｎｃｔｉｏｎＰｏｒｔ、Ｄ．ｆに接続する。図１において、サービスを要求している信号はまずＣ．ｇからＤ．ｆへのブランチを通して進行し、それから要求されたサービスの完了を示している応答信号はＤ．ｆからＣ．ｇに戻る。セルは信号をポートを通して送信する時、または信号を受信しポートで受信した信号に応答する時にだけそのポート（ソフトウェアコンポーネント）を使用する。図１に示しているように経路の２つの端部を接続している２つのセルはその経路に接続されているポートを同時に決して使用せず、経路上を進行する信号は１度に１方向だけである。これらはＴＩＣＣＴＭ内の全ての経路に当てはまる。
【００９４】
図１の各ポートは２状態非決定的有限状態機械（ｎｄＦＳＭ）を含んでおり、図に示しているように状態Ｓ（送信）とＲ（受信）を有している。全てのｇｅｎｅｒａｌＰｏｒｔ、ｇは初期状態Ｓから始まり、全てのｆｕｎｃｔｉｏｎＰｏｒｔ、ｆは初期状態Ｒ（図１の２重円）から始まる。図１の経路は[Ｃ．ｇ，Ｄ．ｆ]である。この経路の初期状態は［Ｓ，Ｒ］である。この初期状態において、経路は信号をポートＣ．ｇからポートＤ．ｆへ送信する準備ができている。ここで図１に示している仕様について説明する。以下ではｇをＣ．ｇを指すために使用し、ｆをＤ．ｆを指す時に使用する。
【００９５】
図１のＣＣＰ特徴付けはＨｏａｒｅ［Ｈｏａｒｅ、１５］の事前条件／事後条件の表記で示されている。ＣＣＰの事前条件は、信号送信および信号受信ｎｄＦＳＭの状態に依存してもよい。図１の特徴の相互動作を以下でトップダウンの順番で説明する。
【００９６】
（１から４）ｑからｆへの信号送信：（１）：ポートは状態Ｓの時に、信号ｃ（完了信号）をその入力信号として親セルから受信する。（２）：状態Ｓで入力ｃが行われると、信号ｓを送信し、状態Ｒに移動し、その時にこの信号ｓを受信するｎｄＦＳＭは状態Ｒにある。受信するｎｄＦＳＭはｓをその入力信号として受け取る。（３，４）：受信するｎｄＦＳＭはその入力信号ｓが信号検知テスト：ｍＲ？（）（’ｍＲ？’は’ｍｅｓｓａｇｅＲｅａｄｙ？’を表す）を実施するその親セルに検知されると状態Ｓへ移動する。事後条件に示しているように、信号の検知は、入力信号がｓの場合はｔｒｕｅの真理値を返し、それ以外はｆａｌｓｅの信号を返し、ここでは信号ｓはメッセージ配信信号を指す。受信セルによるメッセージ配信信号の検知はメッセージ受信となる。ただし、ｆｕｎｃｔｉｏｎＰｏｒｔ、ｆでの配信信号は応答メッセージが返信されるまで５、６回正常に検知されるが、それは配信信号が応答が送出されるまで変化するからである。
【００９７】
（５から１０）ｆからｑへの応答信号送信：（５）：セルＤはそのタスクを完了したことを示している完了信号ｃをｆに送信する。（６）：ｆは開始信号ｓをポートｇに送信し、その状態をＲに変化させる。これはＤからの応答信号である。（７−１０）：セルＣは２つの検知試験の一方を使用して配信信号をそのポートｇ：ｇ：ｍＲ？（）またはｇ：ｐＲ？（’ｐＲ？’は’ｐａｔｈｗａｙＲｅａｄｙ？’を表す）で受信する。ただし、ｇｅｎｅｒａｌＰｏｒｔに配信された信号は検知試験ｇ：ｍＲ？（）を使用して１回だけ検知されてもよいが、それは信号が検知後、φ（空の記号）にリセットされるからである。しかし、ｇ：ｐＲ？（）試験は繰り返し正常に使用可能で、それはｇの状態が検知後にＳに変化するからである。実際に、一般ポートまたは機能ポートである任意のポートｐについて、配信信号の検知は常にｐを状態Ｓにするためである。
【００９８】
スレッド相互動作プロトコル、ＴＩＰ：図１のＴＩＰ（１）は、経路の準備ができている場合、Ｃはサービス要求の送信前に実行が必要なことを実行するためにｐｔｈｒｅａｄ、ｇ：ｘ（）を実行することを指定する。このｐｔｈｒｅａｄはセルＣ、ｇ：ｘ（）≡Ｃ：ｘ（ｇ）で定義されており、Ｃに割り当てられているプライベートメモリ内で実行される。ｇ：ｘ（）の実行直後に、Ｃはｇに接続されている経路内のコンポーネントに関連付けられているメモリ内でｇ：ｓ（）を実行する。図１において、これはポートｇとｆとに関連付けられている共有メモリとなる。これによって、図１の通信プロトコル（１）が実行され、その結果サービス要求信号がポートｆに配信される。
【００９９】
図１のＴＩＰ（２）が以下を指定する：ＤがＣによってそのポートｆに送信されたサービス要求信号をｆ：ｍＲ？（）試験を適用することによって検知すると、ＤはセルＤにおいて定義されており、Ｄのプライベートメモリ内で実行されるｐｔｈｒｅａｄ、ｆ：ｒ（）≡Ｄ：ｒ（ｆ）（‘ｒ’は’ｒｅｐｌｙ’を表している）を実行することによって受信した信号に応答を開始する。ｆ：ｒ（）の実行のすぐ後に、Ｄはｆ：ｓ（）を実行する。これによって、図１の通信プロトコル（１）が実行され、その結果サービス要求信号がポートｇに配信される。ポートｇの親セルＣによるこの応答信号の検知によって、Ｃがそのサービス要求信号をＤに送信した時に開始されたトランザクションが終了する。
【０１００】
経路の状態変化によって課される制限：トランザクションの開始時に、経路の状態は［Ｓ，Ｒ］であった。セルＤによって信号が検知された時に、経路の状態は［Ｒ，Ｓ］である。この新しい状態において、経路は応答信号を返信する準備ができている。応答信号がセルＣによって検知された時に、トランザクションは完了し、経路の状態は［Ｓ，Ｒ］に戻る。これらの状態変化は以下の制限を課す：Ｃ．ｇはトランザクションが完了した時に初めて第２のサービス要求信号を送信可能で、Ｄ．ｆは第１のサービス要求信号に応答した後で初めて第２サービス要求信号を受信することができる。連続したサービス要求信号は、連続したトランザクションが完了した時に初めて経路を通して送信することができる。
【０１０１】
サービス要求に対する必須の応答：全てのＴＩＣＣＴＭ経路について成立する一般的な規則は、各サービス要求は要求が受信されたのと同じ経路を介して必ず応答されるということである。この一般規則に対する例外は「一方通行の環状道路」（セクション８．２）において発生する。したがって、各トランザクションは専用の経路を通して発生する。応答の受信によって、一方通行環状道路においてさえ、常に経路がその初期状態にリセットされる。各信号送信セッションにおいて、経路内のｎｄＦＳＭは他のｎｄＦＳＭによって送信された信号を受信し即座に応答する準備ができている状態に常にある。これは、どれだけ複雑であっても、またどれだけ多数のｎｄＦＭＳが埋め込まれていても全てのＴＩＣＣＴＭ経路について当てはまる。これはチューンと呼ばれる。チューンによって、信号送信中の同期セッションが必要なくなり、信号送信が相当に高速化される。
【０１０２】
チューン：経路内のｎｄＦＳＭは、（ｉ）それらを適切な初期状態に設定することによって互いに対してチューンされ、（ｉｉ）チューンが、経路を通して初期化された各トランザクションが応答信号を同じ経路を通して送信することによって完了するように要求することによって、また（ｉｉｉ）経路上の現在のトランザクションが完全に完了した後で初めて新しいトランザクションがその経路を通して初期化されるように要求することによって維持される。
【０１０３】
計算と通信の統合：計算と通信は両方が同じセルによって実行される。計算の実行と通信の実行との間には区別はない。それらは、スレッド相互動作プロトコル、ＴＩＰによって呼び出され、実行される。セルの各ポートはそれに対して定義されているＴＩＰを有している。ＴＩＰはポートの親セルによって実行される。ＴＩＰはＣ．ｐ：〈ｇｕａｒｄ〉？（）｛〈ｔｉｐ−ｂｏｄｙ〉｝の形態を有しており、ｐはセルＣのポートである。Ｃ．ｐ：〈ｇｕａｒｄ〉？（）がｔｒｕｅの場合、〈ｔｉｐ−ｂｏｄｙ〉が実行され、そうでなければポートがスキップされる。ｐの親セルＣによるＣ．ｐでのＴＩＰボディの実行を指す時にＣ．ｐ：ｔｉｐ（）を使用する。各セルはそのポートを何らかの順番で循環的にポーリングする。ポーリングの順番によってセルのポートがサービスされる順番は決まらないが、それはサービスが配信信号がポートで検知された場合にだけ実施され、信号配信時間とポーリング時間とは互いに同期していないからである。通信は非同期である。
【０１０４】
１．２．１ｖｉｒｔｕａｌＭｅｍｏｒｙを備えている単純なＤａｓ経路
図２はｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍを備えているＤａｓ経路、Ｍに接続されているポートのＴＩＰ、ポートのプロトコル、およびエージェントとポートに対するＣＣＰの特徴付けを示している。経路は２つのエージェントａ０とａ１とを有している。各ポートは、その親セルが、その状態がＳの場合にだけ、それに接続されているｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍ内のデータへのアクセスできるようにしている。データはアクセスされるまでｖｉｒｔｕａｌＭｅｍｏｒｙ内で保護され保存されている。図２の経路内のエージェントは必要に応じて信号がｖｉｒｔｕａｌＭｅｍｏｒｙを迂回するようにする。
【０１０５】
図２において、ｐｔｈｒｅａｄは、ｇ：ｘ（）≡ｇ：ｍｓｇ（）：ｘ（ｇ）およびｆ：ｒ（）≡ｆ：ｍｓｇ（）：ｒ（ｆ）である。これらのｐｔｈｒｅａｄはｇとｆの親セルによってｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍ内に書き込まれたメッセージのＭｅｓｓａｇｅサブクラス内で定義される。ここで、Ｍはｐｔｈｒｅａｄの実行環境を提供し、ｖｉｒｔｕａｌＭｅｍｏｒｙはセルＣとＤの共有メモリ環境の一部である。この種類の動作を可能にするｖｉｒｔｕａｌＭｅｍｏｒｙの構造をセクション７．２で説明している。
【０１０６】
2012506076.tif 000003
【０１０７】
図２：ｖｉｒｔｕａｌＭｅｍｏｒｙを備えている点対点Ｄａｓ経路
図１と２のセルＤは、配信された信号を配信時に検知しないことがあり、Ｄがその時にその他のポートの１つのサービスを行っている可能性がある。最終的にセルＤがそのポートＤ．ｆをポーリングして、図１と２の第２のＴＩＰでガードＤ．ｆ：ｍｒ？（）を評価した時に、メッセージ配信信号を検知する。セルはそれらのポートのいずれかに配信された任意の信号の検知をし損なうことはない。１つのポーリングサイクルで検知し損なった信号は続くサイクルで取得される。図２に示しているＣＣＰ特徴付けは図１のものと同様である。
【０１０８】
トランザクションの正しさ：図１の場合にように、ポートｇが応答メッセージ、例えばｍ’、を検知した時間はポートｇがそのサービス要求メッセージ、たとえばｍ、を送出した時に開始されたトランザクションの最後となる。ｍ’がｇに時刻ｔ２に配信されｍがｇによって時刻ｔ１に送信されたとする。ポートｇとｆとの間のトランザクションは、メッセージｍとｍ’が事前に定義されている関係Ｒ（ｇ，ｆ）（ｍ，ｍ’）を満たしており、さらにタイミングの制限ｔ２≦ｔ１＋τｍａｘ（ｇ，ｆ）が満たされている場合にだけ正しく、ここでτｍａｘ（ｇ，ｆ）はｇとｆとの間のトランザクションを完了するのにかかる可能性のある最長時間であって、図１のようにメッセージが交換されない場合、前述のタイミング条件だけが成立しなければならない。ポートｇとｆとは、これらの条件がｇとｆとの間の全てのトランザクションについて成立している場合にだけ良好にマッチしている。実装は、経路によって接続されている実装内のポートの全ての対が良好にマッチしている場合にだけ正しい。
【０１０９】
１．２．２．フォークとジョイン操作を備えているｓｍ経路
図３はエージェントａ０を備えている単純な経路を示している。エージェントは時間同期信号をポート[Ｄ１．ｆ，Ｄ２．ｆ]の両方にブロードキャストする。別個のセルに付属しており、同じエージェントに接続されている同じ種類のポート（つまり全てのｇｅｎｅｒａｌＰｏｒｔと全てのｆｕｎｃｔｉｏｎＰｏｒｔ）がポートグループを構成する。したがって、図３と４のポート[Ｄ１．ｆ，Ｄ２．ｆ]はポートグループを構成する。全てのセルが並列に動作し全てのセル活動は信号配信と同期していないため、Ｄ１とＤ２とは信号を同時に検出して応答しないことがある。その結果、Ｄ１とＤ２とは自身の時間に各々が配信された信号を検知し、それに応答することになる。エージェントａ０は、Ｄ１．ｆとＤ２．ｆの両方から完了信号を受信した後で初めて応答信号をＣ．ｇに返信することになる。これを調和と呼ぶ。図３の第２のプロトコルの一致プロトコルメソッドａ０：ＡＰ［ｃ１，ｃ２］＊は調和を実施する。したがって、エージェントａ０は時間同期信号配信と調和した信号ディスパッチとを行う。
【０１１０】
2012506076.tif 000004
【０１１１】
図３：フォークを備える単純な点対グループ経路
図３のプロトコル（２）の実行は以下のように進行する：Ｄ１．ｆとＤ２．ｆの両方が同様なプロトコルを有しており、Ｄ１．ｆのプロトコルは「Ｄ１．ｆ：ｃ１→ａ０：ＡＰ［ｃ１，ｃ２］＊：ｓ→Ｃ．ｇ」。Ｄ２．ｆのプロトコルは「Ｄ２．ｆ：ｃ２→ａ０：ＡＰ［ｃ１，ｃ２］＊：ｓ→Ｃ．ｇ」である。Ｄ１とＤ２の両方が、それぞれのタスクの完了後に応答信号をＣ．ｇに送信するために、それぞれのＤ１．ｆとＤ２．ｆで並列に、しかし必ずしも同期せずにポートプロトコルの実行を開始する。したがって、両方が、それらのそれぞれのＣＣＰ、Ｄ１．ｆ：ｃ１→ａ０とＤ２．ｆ：ｃ２→ａ０の実行後に、一致プロトコルメソッドａ０：ＡＰ［ｃ１，ｃ２］＊並列に評価する。条件ＡＰ［ｃ１，ｃ２］＊は、ａ０が信号ｃ１とｃ２の両方を受信した後初めてｔｒｕｅになる。Ｄ１とＤ２とはａ０：ＡＰ［ｃ１，ｃ２］＊をｔｒｕｅになるまで循環的に評価し続ける。ａ０：ＡＰ［ｃ１，ｃ２］＊がｔｒｕｅになると即座にプロトコルの残りを実行（ｒｕｎ）するためにＤ１とＤ２の一方がａ０によって非決定的に選択され、他方は強制的にプロトコルの実行を停止される（これはセクション８に示しているグループ対グループプロトコルの単純化されたバージョンである）。読者は、ａ０：ＡＰ［ｃ１，ｃ２］＊に従っているプロトコルのセグメントがＤ１．ｆとＤ２．ｆの両方について同じことを確認することができる。これによって、信号がポートＣ．ｇだけに１度配信されることが保証される。したがって、ａ０：ＡＰ［ｃ１，ｃ２］＊が成立すると、図３のエージェントａ０は誰がプロトコルを実行しているかに関わらず応答シグナルｓをＣ．ｇに送信する。したがって、ａ０がセルグループ内のセルＤ１とＤ２によるプロトコルの異なるセグメントの並列実行を保証する。
【０１１２】
2012506076.tif 000005
【０１１３】
図４：ｖｉｒｔｕａｌＭｅｍｏｒｙを備えているフォーク
ｖｉｒｔｕａｌＭｅｍｏｒｙと関連付けられているＴＩＰとプロトコルを備えている同様なＤａｓ経路を図４に示している。同図において、ａ１は時間同期メッセージ配信と調和したメッセージディスパッチを実施し、ａ０はサービス要求が送信された時にメッセージディスパッチを実施し、応答メッセージが返信された時にメッセージ配信を実施する。
【０１１４】
図３と４のネットワークは同期フォーク／ジョイン動作を表し、フォークは信号がポートｇによってｆｕｎｃｔｉｏｎＰｏｒｔグループに送信された時に発生し、ジョインはｆｕｎｃｔｉｏｎＰｏｒｔグループのポートが応答信号を返信した時に発生する。フォークとジョインのこの表記を２つ以上のポートを含んでいるｇｅｎｅｒａｌＰｏｒｔグループが結合サービス要求をｆｕｎｃｔｉｏｎＰｏｒｔグループに送信する状況にも拡張する。そのようなグループ対グループフォークとジョイン動作用のプロトコルをセクション７で説明する。
【０１１５】
１．３．共有メモリと分散メモリの経路
ポートを経路内のエージェントまたは他のポートに接続しているリンクはブランチと呼ばれる。エージェントを相互に接続しているリンクはｈブランチ（隠れたブランチ）と呼ばれる。ｓｍ経路、ポート、エージェント、ブランチ、ｈブランチ、およびｖｉｒｔｕａｌＭｅｍｏｒｙの全てのコンポーネントはソフトウェアコンポーネントである。それらは全て共有メモリを含んでいる経路の共有メモリ環境内で動作する。
【０１１６】
ＴＩＣＣＮＥＴＴＭのｄｍ経路内のエージェントといくつかのポートはハードウェアコンポーネントであって、各々が自身のローカルメモリ内で動作し、ｄｍ経路内のブランチとｈブランチとは信号送信線である。エージェント、ポート、およびｖｉｒｔｕａｌＭｅｍｏｒｙ以外に、ｄｍ経路は埋め込まれている特別なハードウェアスイッチとルータも有している。通信は２つの段階、（ｉ）経路の確立と（ｉｉ）信号／データ交換で発生する。スイッチとルータとは経路の確立時にだけ使用される。いったん確立されると、経路は定位置に維持され、取り除かれて新しい経路が確立されるまで繰り返し使用される。メッセージは既に確立しているｄｍ経路を通してだけ交換できる。信号／データ送信線を通した信号とデータ交換はＣＣＰ実行によって管理される。ｓｍ経路でのように、信号／データを交換するｄｍ経路内の全てのエージェントとポートは常に互いに対してチューンされている。２つのｄｍ経路はメッセージ送信中に使用されないスイッチとルーター以外にコンポーネントを共有することはない。ＴＩＣＣＮＥＴＴＭは数千の別個の相互に干渉しない点対点と点対グループｄｍ経路を収容することが可能で、数千の同時の並列のメッセージ交換をもたらす。
【０１１７】
既に説明した特性の繰り返しになるが、ｓｍ経路とｄｍ経路に共通の特性を以下に３つのカテゴリで一覧表示している。
【０１１８】
（１）．ＴＩＰフォーマットは経路構造とは無関係：（ｉ）通信プリミティブはｐ：ｓ（）（’ｓ（）’は送信を表す）とｐ：ｆ（）（’ｆ（）’は転送を表す）であって、ｐはポート、ｆ（）は受信したメッセージを場合によっては何らかの修正後に他のセルのポートに転送し、ｓ（）は新しく生成されたメッセージを送信する。プリミティブｐ：ｓ（）とｐ：ｆ（）はポートｐに関連付けられている一意のプロトコルの呼び出しと実行するために使用される。（ｉｉ）このようにポートｐに関連付けられているプロトコルはｐに接続されている経路の性質に依存しており、異なる経路については異なる。（ｉｉｉ）同じ通信プリミティブ、ｐ：ｓ（）とｐ：ｆ（）とがポートｐに接続されている経路の種類に関わらずポートｐのプロトコルを呼び出し実行するために使用される。（ｉｖ）ポートｐでのプロトコルの呼び出しと実行によって信号がポートｐに接続されている経路上を送信され、それが今度は、存在する場合は、メッセージを同様に同じ経路に接続されているその受信ポートに配信つまり送信する。（ｖ）ｐの親セルだけが、通信プリミティブｐ：ｓ（）とｐ：ｆ（）とを呼び出し実行することができる。（ｖｉ）ポートｐでのＴＩＰフォーマットはｐに接続されている経路の種類には無関係である。（ｖｉｉ）信号を交換する任意の経路の全てのコンポーネントは常に互いにチューンされたままである。これらの特性によって、共有メモリと分散メモリ通信との間のソフトウェアシステムの区別が排除され、信号送信中の同期セッションの必要性が完全に無くなる。
【０１１９】
（２）．グループ対グループメッセージ交換の同時の並列実行：ポートグループに属している別個のポートの別個の親セル（セクション１．３と７）はセルグループを構成しており、（ｉ）セルグループ内のセルはプロトコルの指定されたセグメントを同時に並列に実行し、別個のセグメントはセルグループ内の別個のセルに対応している。全てのセグメントを共に並列に実行することによって、グループ対グループ非同期メッセージ交換が経路の２つの端部に接続されているセルグループ間（図１９）の経路上に実装され、経路上のエージェントはそのような同時の並列のプロトコルセグメントの実行を調和させる（セクション１．３と７）。（ｉｉ）分散メモリ環境において、１つの共有メモリマルチプロセッサ（ＳＭＰ）内のｇｅｎｅｒａｌＰｏｒｔグループはＴＩＣＣＮＥＴＴＭｄｍ経路を通して結合メッセージをグリッド内の５〜６個の他のＳＭＰ内のｆｕｎｃｔｉｏｎＰｏｒｔグループに送信してもよい。ブロードキャストメッセージは並列に全ての宛先ｆｕｎｃｔｉｏｎＰｏｒｔグループに配信される。ｆｕｎｃｔｉｏｎａｌＰｏｒｔはそれらの応答を送信元のｇｅｎｅｒａｌＰｏｒｔグループに多重化モードで１つずつ同じ経路を通して返送する。これはｄｍ経路内のコンポーネントの相互チューンを維持する。
【０１２０】
（３）．高速並列メッセージ交換とモビリティ：（ｉ）全ての経路において、全てのメッセージは準備ができ次第即座に送信され、（ｉｉ）経路がどんなに複雑でも、信号を交換する経路内の全てのエージェントとポートは一方から他方に送信された信号が即座に受信側によって受信され、適切な時間に応答されるように互いに対して常にチューンされている。これによって、同期セッションが必要なくなり、（ｉｉｉ）２つの経路は共通のコンポーネントを共有せず、したがって、別個のプロトコルの２つの並列の実行が互いに干渉することはない。これは、ＳＭＰ内のソフトウェアｓｍ経路とＴＩＣＣＮＥＴＴＭ内のｄｍ経路の両方にも当てはまる。そのため、（ｉｖ）並列に交換可能なメッセージの数は、経路の数によってのみ制限され、（ｖ）トランザクションの途中での経路の目標ノードへの接続の動的な変更（セクション３．２のモビリティを参照）はｄｍ経路では発生しない。そのような変更はｓｍ経路でだけ発生する。
【０１２１】
一般的な並列計算に対応しているＴＩＣＣＴＭ−Ｐｐｄｅ内の計算構成の概要を次の２〜３のサブセクションに示す。より詳細は、セクション３から５で後に示す。ＴＩＣＣＴＭ−Ｐｐｄｅ実装の例をセクション２に示し、ＡＬＬＥＯＰ証明を使用した例をセクション６に示す。
【０１２２】
１．４．ＴＩＣＣクラスとオブジェクト
ＴＩＣＣＴＭはトップレベルクラス：Ｃｅｌｌ、Ｐｏｒｔ、Ａｇｅｎｔ、ＶｉｒｔｕａｌＭｅｍｏｒｙ、Ｂｒａｎｃｈ、およびＭｅｓｓａｇｅを定義する。セル、ポート、エージェント、ｖｉｒｔｕａｌＭｅｍｏｒｙ、ブランチ、およびメッセージという表記をこれらのクラスのインスタンスであって、すべてソフトウェアコンポーネントであるオブジェクトを指すために使用する。アクター［Ｈｅｗｉｔｔ，５，６］とπ算法エージェント［Ｍｉｌｎｅｒ，７，８，９］のように、各セルは本質的に自身の割り当てられている計算ユニット（ＣＰＵ）内で実行（ｒｕｎ）される並列ソフトウェアコンポーネントである。セルとアクターおよびπ算法エージェントとの間には５〜６個の違いがある。それらは後に説明する。
【０１２３】
ポートがポートベクトルに属していない限り（セクション５．２を参照）、同じセルに属している２つのポートはブランチによって接続されず、ブランチは同じセルに属している２つのポートを同じ経路に接続しない。全ての場合で、セルの１つのポートはメッセージを同じセルの他のポートに送信することはできず、これによって可能性のあるデッドロックを防止している。しかし、別個のセルに属している別個のポートは同じエージェントへのブランチに接続されていてもよい。前述のように、そのようなポートは順序付けされているポートグループを構成し、図４の［Ｄ１．ｆ，Ｄ２．ｆ］はその例である。２つの別個のポートグループは互いに交差することはなく、同じセルに属している２つのポートが同じポートグループ内に存在することはない。スーパーコンピューティンググリッド内では、任意のセルグループの全てのセルは常に同じＳＭＰ内に存在している。セクション７からわかるように、これらの制限によって、グループ対グループ経路を通してポートグループ間でメッセージを交換することができる。
【０１２４】
１．５．セル動作、ＣＩＰ、およびポーリング
各セルはそのポートｐを何らかの順序でポーリングし、セル自体が選択した並べ替え基準に基づいて保留メッセージを使用してｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに全てのポートを並べ替える。それからｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内の各ポートｐについて、ＴＩＰボディ、ｐ：ｔｉｐ（）がｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内に現れるポートの順序で１つずつ実行される。セルは連続しているｐ：ｔｉｐ（）の実行の間の割り込み処理に対応してもよい。割り込みメッセージは、ＴＩＣＣＴＭ−Ｐｐｄｅの要件のいずれにも違反せずに、ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内のポートの順序を変更したり、ポートの優先順位を変更したり、ＣＩＰ実行のサスペンド／終了を整然と実施してもよい。サスペンドされたＣＩＰは次の割り込みメッセージが同じｉｎｔｅｒｒｕｐｔＰｏｒｔに配信された時に自動的にリジュームされる。オペレーティングシステムはセルのアクティビティに割り込むことはできず、アプリケーション内の他のセルだけがそうすることができる。共有メモリマルチプロセッサ（ＳＭＰ）内のセルへの動的プロセッサ割り当てはＴＩＣＣＴＭによって管理される。セルのグリッド内のＳＭＰへの割り当てはユーザによって行われる。以下で定義されるＣＩＰはＳＭＰ内で動作する。
【０１２５】
各ポートで１つの、セルのポートで定義されている全てのＴＩＰの集合は、セル初期化メソッドと共に、セル相互動作プロトコルＣＩＰと呼ばれる。以下で説明する初期化と割り込みメッセージ処理はＣＩＰ動作の一般的な制御構造を示している。
割り込み処理は、割り込みメッセージがセルのポーリングサイクルの中で認識される時刻と割り込みメッセージの性質とに依存してセルごとに異なる。ＣＩＰは以下の形態を有している。
【０１２６】
ｖｏｉｄＣｅｌｌ：：ＣＩＰ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ；
ｉ：ｐＲ？（）｛ｉ：ｓ（）｝；ｉｎｉｔ（）；｝｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛
ｉ：ｍＲ？（）｛ｉ：ｓ（）．ｒ（）；｝／／ｉ：ｒ（）は以下の（１．２）で定義。ただし、応答が先に送信される
ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｃｌｅａｒ（）；
ｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）；／／ポーリングされたポートをメッセージ配信信号と共にｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに配置
／／ポートｐがｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内に現れる順序でｐ：ｔｉｐ（）を実行
ｆｏｒ（ｉｎｔ  ｊ＝０；ｊ＜ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｓｉｚｅ（）；ｊ＋＋）｛
ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［ｊ］：ｔｉｐ（）；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝  （１．１）
ｐｔｈｒｅａｄ  ｉ：ｒ（）＝ｉ：ｍｓｇ（）：ｒ（ｃｅｌｌ）はｉｎｔｅｒｒｕｐｔＰｏｒｔ  ｉのｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージのメッセージサブクラス内で定義される。ＩｎｔｅｒｒｕｐｔＭｓｇをこのサブクラスとすることにする。ＩｎｔｅｒｒｕｐｔＭｓｇ：：ｒ（）の定義を以下で示し、以下の第２段落で説明する。
【０１２７】
ｖｏｉｄ  ＩｎｔｅｒｒｕｐｔＭｓｇ：：ｒ（ｃｅｌｌ）｛／／ｓｅｌｅｃｔＯｎｅはトップダウン走査において第１のｔｒｕｅの選択肢を選択する
ｓｅｌｅｃｔＯｎｅ｛ｃｅｌｌ：ｓｕｓｐｅｎｄｅｄ？（）｛ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄ＝ｆａｌｓｅ｝
ｓｕｓｐｅｎｄ？（）｛ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄ＝ｔｒｕｅ；ｐｒｅｐａｒｅＴｏＳｕｓｐｅｎｄ（）；｝
ｔｅｒｍｉｎａｔｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；｝
ｔｒｕｅ｛ｓｅｔＰｏｒｔＰｒｉｏｒｉｔｉｅｓ（）；｝｝  （１．２）
【０１２８】
初期化：前述のＣＩＰにおいて、ｉｎｉｔｉａｌｉｚｅ？（）はセルの局所変数ｉｎｉｔｉａｌｉｚｅの真理値であって、’ｉ’はセルのｉｎｔｅｒｒｕｐｔＰｏｒｔである。休止セルは、ｉに対して配信された最初の割り込みメッセージによってＴＩＣＣＴＭによって選択されたプロセッサ内で起動される。一般に、休止セルはそのポートのいずれかに配信された最初のメッセージによって起動される。メッセージを配信するプロトコルがこの起動を実施する（セクション７）。起動時に、ｉｎｉｔｉａｌｉｚｅ？（）がｔｒｕｅの場合、セルはｉｎｉｔｉａｌｉｚｅ＝ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅをセットし、ポートｉでの割り込みメッセージによって実際に起動した場合、ｉ：ｓ（）を実行することによってそれを開始したセルに肯定応答を返信し、それらを実行した後、ｉｎｉｔ（）で指定されている初期化を実施し、それからｗｈｉｌｅループに進む。
【０１２９】
ｉｎｔｅｒｒｕｐｔＰｏｒｔサービス：ｗｈｉｌｅループ内で、セルは最初にそのｉｎｔｅｒｒｕｐｔＰｏｒｔをポーリングする。割り込みメッセージが存在しない場合、ポートをスキップする。存在する場合、（１．２）に示しているｉ：ｒ（）＝ｉ：ｍｓｇ（）：ｒ（ｃｅｌｌ）を実行する。（１，２）のｓｅｌｅｃｔＯｎｅにおいては考慮すべき４つの場合が存在する。（ｉ）ｃｅｌｌ：ｓｕｓｐｅｎｄｅｄ？（）がｔｕｒｅの場合、それはセルが以前にサスペンドされていたことを意味する。この場合、ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄはｆａｌｓｅにセットされ、セルはｗｈｉｌｅループの残りを実行するために即座に進む。（ｉｉ）ｉ：ｍｓｇ（）：ｓｕｓｐｅｎｄ？（）がｔｒｕｅならば、ｃｅｌｌ．ｓｕｓｐｅｎｄｅｄはｔｒｕｅにセットされ、セルは自身をサスペンドする準備をし、即座にその割り当てられているプロセッサを解放し、それらを実行した後、セルは休止する。セルに配信される次のｉｎｔｅｒｒｕｐｔＭｓｇが自動的にセルを使用可能なプロセッサにおいて起動する。そのように再起動すると、セルは初期化をスキップして直接ｗｈｉｌｅループ内に進むが、それはｉｎｉｔｉａｌｉｚｅ？（）がその時にはｆａｌｓｅになっているからである。（ｉｉｉ）ｉ：ｍｓｇ（）：ｔｅｒｍｉｎａｔｅ？（）がｔｒｕｅの場合、セルはｗｈｉｌｅループの現在のサイクルの最後で動作を中止し、そのプロセッサを解放するが、それはｃｅｌｌ．ｓｔｏｐＰｏｌｌｉｎｇがｔｒｕｅにセットされているからであって、（ｉｖ）（１．２）のｓｅｌｅｃｔＯｎｅの既定の場合は、ｉｎｔｅｒｒｕｐｔＭｓｇに指定されているようにセルのポートに優先度を割り当てる。これらの優先度は、続く（１．１）のｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）によって使用される。ここではサスペンド／レジューム動作はオペレーティングシステムを呼び出すことを必要とせずにＴＩＣＣＴＭによって管理される。
【０１３０】
ポーリング：セルのＩｎｔｅｒｒｕｐｔＰｏｒｔをポーリングした後、セルはセルの他のポートのポーリングを開始し、ｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）を実行することによって保留中のメッセージと共にポートをｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔに並べ替え、そのリスト内でリストに現れる順序で各ｐについてｐ：ｔｉｐ（）を実行する。ｗｈｉｌｅループはｓｔｏｐＰｏｌｌｉｎｇがｔｒｕｅになるまで繰り返される。ポーリングサイクルはメッセージ配信に同期していない。ポーリングサイクル内でポートをポーリングしている時に、ポートがポートに配信済みのメッセージを有していない場合、セルはそのポートをスキップし次のポートをポーリグする。スキップされたポートは実行サイクル中に新しいメッセージを受信することがある。１つのポーリングサイクル中に保留中のメッセージを検知し損なったポートは次のポーリングサイクルで検知され、ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内に含められることになる。したがって、ポートは、ポートにメッセージが配信されるのと同じ順序でサービスされないことがある。しかし、セルの中止が早過ぎたりアプリケーションシステム内にデッドロックが存在したりしない限り、入力メッセージがセルによって検知し損なわれることはない。したがって、正常な動作条件の下では各トランザクションが完了する。これはＴＩＣＣＴＭ−Ｐｐｄｅのおいて重要な要件である。
【０１３１】
ポートサービスの他のモード：セルが保留中のメッセージをポートｐで検知した後で即座にｐ：ｔｉｐ（）を実行し、したがって並べ替えサイクルをスキップすることができる。以下の種類の同期計算を有することが可能で、セルはそのポートでメッセージを受信するまで（またはポートの準備ができるまで）待ち、メッセージが到着した時にメッセージに応答し（またはポートの準備ができた時に新しいメッセージを書いて送信し）、セルの次のポートをポーリングするために進む。そのような同期計算は、ＴＩＰ内でＣ．ｐ：〈ガード〉？（）＊の形態のガードを使用することによって指定される。’＊’は待つことが必要なことを表している。アスタリスクが付されているガードは同期ガードと呼ばれ、ｔｒｕｅになるまで繰り返し評価される。
【０１３２】
例：
セクション２において、［Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ，１３］から採用した２つの単純な例を示すために図１から４の単純なネットワークを使用する。これらの例は、ＴＩＣＣＴＭ−Ｐｐｄｅ実装の性質を示している。第１の例は、実装仕様、トレース、およびＡＬＬＥＯＰと実行（ｒｕｎ）時のＳＭＳの役割から導出されたｃａｕｓａｌｎｅｔからシステムによって生成されたＡＬＬＥＯＰを紹介するために使用される。例は、モニタ［Ｈｏａｒｅ，１２］やセマフォ［Ｄｉｊｋｓｈｔｒａ，２３，２４］の必要無しにＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋｓによって実行される並行性、自動調和、および時間同期も示している。第２の例は、ＴＩＣＣＴＭ−Ｐｐｄｅにおけるカプセル化の概念を導入し、非決定的ガードの使用を説明する。
【０１３３】
２．簡単な例
各例の実装仕様は、ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋｓ、様々なポートのＴＩＰ、セルのＣＩＰ、セルのポートがポートングされる順序を指定している各セルのポーリングサイクルからなる。ＴＩＣＣＴＭ−ｎｅｔｗｏｒｋは計算中に発生するメッセージ交換、同期、および調和のアブストラクションである。それは並列計算の制御構造を指定する。このセクションにおいて例のための証明は示されておらず、セクション７においてＡＬＬＥＯＰ証明を備えている例が示されている。
【０１３４】
２．１．ＢｉｌｌとＢｅｎの例：ＡＬＬＥＯＰ、トレース、ｃａｕｓａｌｎｅｔ
［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］の単純なゲームから始める。ゲームのＦＳＰモデルは、Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］で示されているように、以下のようになる。
【０１３５】
｜｜ＢＩＬＬ＿ＢＥＮ＝ＢＩＬＬ｜｜ＢＥＮ；
ＢＩＬＬ＝ｐｌａｙ→ｍｅｅｔ→ＢＩＬ、ＢＥＮ＝ｗｏｒｋ→ｍｅｅｔ→ＢＥＮ  （２．１）
ここで従来の意味[１２、１３]での同期はアクションの用語「ｍｅｅｔ」で発生すると仮定される。ゲームのＴＩＣＣＴＭ−Ｐｐｄｅ実装をここで示す。実装仕様から導出されたＡＬＬＥＯＰモデル、ＡＬＬＥＯＰから導出されたトレース、およびＳＭＳが生成したｃａｕｓａｌｎｅｔを示す。全ての導出はシステムによって自動的に行われる。ＡＬＬＥＯＰモデルは、実装のモデルであって、システムの意図した設計のモデルではない。したがって、それらはＦＳＰモデルよりも複雑であるが、ある意味ではそれらの構造はＦＳＰ構造と同様である。
【０１３６】
ＴＩＣＣＴＭ−ネットワークを図５に示している。各ＴＩＣＣＴＭ−ネットワークは時には構成セルとも呼ばれる少なくとも１つの環境セルＥを有している。これは、ネットワークを構成し動作を開始するのに使用される。ＴＩＣＣＴＭ−ＧＵＩ（グラフィカルユーザインターフェイス）画面が開いた時に、それはＥがその中にインストールされた状態で表示される。アプリケーションプログラマはセルサブクラスＥとＴＩＣＣＴＭ−ＧＵＩの操作の前にアプリケーションに必要な他のセルサブクラスを定義済みでなければならない。環境セルＥはＧＵＩ画面上の画像をクリックし、割り込み信号をＩｎｔｅｒｒｕｐｔＰｏｒｔ、Ｅ．ｉに送信することによってユーザによって起動される。Ｅは全ての他のセルと全ての経路をＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋｓ内にインストールするのに使用される。全てのインストールされたセルと経路とはＴＩＣＣＴＭ−ＧＵＩ画面に表示され、ユーザが画像の再配置を行った後の結果の画像は図５の表示のようになる。これがいったん完了すると、Ｅをクリックして、割り込み信号をそのポートＥ．ｇ１を介してネットワーク内のセルのＩｎｔｅｒｒｕｐｔＰｏｒｔにブロードキャストすることによってアプリケーションが開始され、これによってセルが起動される。
【０１３７】
2012506076.tif 000006
【０１３８】
図５：ＢｉｌｌとＢｅｎの例：「ｍｅｅｔ」で同期
以下では、「Ｂｅ」を「Ｂｅｎ」、「Ｂｉ」を「Ｂｉｌｌ」、ＭｅをＭｅｅｔｉｎｇ、「Ｂ」を「Ｂｅｎ  ａｎｄ  Ｂｉｌｌ」という省略を使用する。［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆおよび［Ｂｅ．ｇ，Ｂｉ．ｇ］＝Ｂ．ｇはポートグループである。ＢｅｎとＢｉｌｌの両方が同期している信号を受信し、調和している信号を図５のこれらのポートグループ：Ａｇｅｎｔ、ａ１とａ２を通して送出して、セクション１．３．２で説明したように同期と調和を実施する。セルＥのＣＩＰを以下に示す。
Ｅ：ＣＩＰ（）  定義：
ｖｏｉｄＥ：：ＣＩＰ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉｎｉｔ（）；Ｅ．ｇｌ：ｓ（）；Ｅ．ｉ：ｓ（）；
ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ；｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛
（Ｅ．ｇ：ｐＲ？（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）＊）｛ｇ：ｓ（）；ｇ：ｍＲ？（）＊｛｝｝
Ｅ．ｉ：ｍＲ？（）｛Ｅ．ｇｌ：ｓ（）；Ｅ．ｇｌ：ｍＲ？（）＊｛Ｅ．ｉ：ｓ（）；
ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝  （２−２）
【０１３９】
前述のＣＩＰは以下の動作を指定している：ユーザによってＩｎｔｅｒｒｕｐｔＰｏｒｔ、Ｅ．ｉに送信される第１の割り込み信号によってＥが起動し、Ｅにｉｎｉｔ（）で定義されている初期化を実行させ、それによってアプリケーションに必要な全てのセルと経路がインストールされる。この後、Ｅは割り込み信号をゲーム内のセルのＩｎｔｅｒｒｕｐｔＰｏｒｔにそのポートｇ１を通して送信する。これによって図５のネットワーク内のセルが起動される。それからＥはそれを開始した割り込み信号に返信し、その変数を初期化し、それからそのｗｈｉｌｅループの実行に進む。ｗｈｉｌｅループ内では、そのｇｅｎｅｒａｌＰｏｒｔのポーリングをまず実施する。ポートＥ．ｇが信号を送信する準備ができており、Ｅがゲームを開始する準備ができている場合、Ｅ．ｇは信号を［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆに送信する。これによってゲームが始まる。ゲームを開始すると、ＥはそのポートＥ．ｇでゲームの終了信号の受信を待つ。
【０１４０】
ゲームの終了信号を受信した後、ＥはそのｉｎｔｅｒｒｕｐｔＰｏｒｔ、Ｅ．ｉをポーリングする。Ｅが割り込み信号を検知すると、Ｅはその動作の終了を開始する。これは、Ｅがユーザから受信する第２の割り込み信号になる。第１の割り込み信号はそれを開始した割り込み信号である。中止前に、Ｅは割り込み信号を全ての他のセルにそのポートｇ１を通してブロードキャストする。これは、Ｅによってブロードキャストされる第２の割り込み信号となる。第１の割り込み信号はセルを開始したものである。第２の割り込み信号を受信した各セルは、応答を返信し、それから自身を終了する。Ｅは全てのセルから、図５のエージェントａ３によって転送された、調和した応答を受信した後で初めて終了する。これは、わずかな変形によって、全てのアプリケーションによって使用される一般的な開始／停止プロセスである。
【０１４１】
Ｅ．ｉにおいて割り込み信号が存在しない場合、Ｅは（２．２）と（２．７）に示しているように、そのポーリングサイクルを繰り返してもよい。図５の他のセルは同様のＣＩＰを有している。ただし、（２．２）のポートＥ．ｇのＴＩＰはそれに埋め込まれている他のＴＩＰ、ｇ：ｍＲ？（）＊｛｝を有している。この場合、ＴＩＰボディは空である。しかし、一般的には、これはそうする必要は無い。例えば、以下のＴＩＰ（２．４）と（２．５）において、埋め込まれているＴＩＰのＴＩＰボディは空ではない。複数のそのような埋め込みがＴＩＰで発生することがある。以下の説明では、開始／終了プロセス、ｉｎｔｅｒｒｕｐｔＰｏｒｔポーリング、およびサービスを省略する。
ＴＩＰ：全てのＴＩＰは一般的な構造〈ＴＩＰガード〉｛〈ＴＩＰボディ〉}を有している。
【０１４２】
Ｅ．ｇ：ＴＩＰ（）：（Ｅ．ｇ：ｐＲ？（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）＊）｛Ｅ．ｇ：ｓ（）；Ｅ．ｇ：ｍＲ（）＊｛｝｝  （２．３）
Ｂｉ．ｆ：ＴＩＰ（）：Ｂｉ．ｆ：ｍＲ？（）｛Ｂｉ．ｆ：ｐｌａｙ（）；Ｂｉ．ｇ：ｓ（）；
Ｂｉ．ｇ：ｍＲ？（）＊｛Ｂｉ．ｆ：ｓ（）；｝｝  （２．４）
Ｂｅ．ｆ：ＴＩＰ（）：Ｂｅ．ｆ：πιＲ？（）｛Ｂｅ．ｆ：ｗｏｒｋ（），−Ｂｅ．ｇ：ｓ（）；
Ｂｅ．ｇ：ｍＲ？（）＊｛Ｂｅ．ｆ：ｓ（）；｝｝  （２．５）
Ｍｅ．ｆ：ＴＩＰ（）：Ｍｅ．ｆ：ｍＲ？（）＊｛Ｍｅ．ｆ：ｍｅｅｔ（）．ｓ（）；｝  （２．６）
【０１４３】
ＢｉｌｌとＢｅｎがＥによって送信された信号を検知すると、（２．４）と（２．５）に示しているようにそれらはそれぞれのこと、ｐｌａｙとｗｏｒｋを開始する。何をしているにしてもそれを終了した後、ＢｉｌｌとＢｅｎの各々は信号をそれらのそれぞれのポートＢｉ．ｇとＢｅ．ｇとを通してＭｅ．ｆに送信する。もちろん、それらは信号を送信した時間を同期させない。エージェントａ２はＢｉ．ｇとＢｅ．ｇから信号を受信するまで待ち、それから調和した信号をＭｅ．ｆに送信する。したがって、ＭｅｅｔｉｎｇはかならずＢｉｌｌとＢｅｎの両方がその準備ができた時にだけ始まる。ミーティングが終了すると、Ｍｅ．ｆは同期した信号をエージェントａ２を通して［Ｂｉ．ｇ，Ｂｅ．ｇ］＝Ｂ．ｇに送信する（図５を参照）。ＢｉｌｌとＢｅｎとがこの信号を受信した時に、両者は調和したゲームの終了信号をａ１を通してＥ．ｇに返信する。この時点で、Ｅは、そのポートＥ．ｉで割り込み信号によってゲームが中止されていない場合、ゲームの次の反復を開始してもよい。
【０１４４】
［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］のＦＳＰの枠組みで同期と呼ばれるものは、ＴＩＣＣＴＭ−Ｐｐｄｅでは調和と呼ばれる。ＴＩＣＣＴＭ−Ｐｐｄｅにおける同期は、並列に発生するイベントの時間的な同期を常に指す。この例では、時間的同期はＥ．ｇからの信号がエージェントａ１によって［Ｂｉ．ｆ，Ｂｅ．ｆ］＝Ｂ．ｆに配信された時と、Ｍｅ．ｆからの信号が［Ｂｉ．ｇ，Ｂｅ．ｇ］＝Ｂ．ｇ配信された時に発生する。
【０１４５】
ＰＯＬＬＩＮＧ  ＣＹＣＬＥＳ：//ｉｎｔｅｒｒｕｐｔＰｏｒｔポーリングはここでは無視されている
Ｅ：Ｐｏｌｌｉｎｇ（）＝［Ｅ．ｇ：ｐＲ？（）→Ｅ：Ｐｏｌｌｉｎｇ（）］  （２．７）
Ｂｅ：Ｐｏｌｌｉｎｇ（）＝［Ｂｅ．ｆ：ｍＲ？（）→Ｂｅ：Ｐｏｌｌｉｎｇ（）］  （２．８）
Ｂｉ：Ｐｏｌｌｉｎｇ（）＝［Ｂｉ．ｆ：ｍＲ？（）→Ｂｉ：Ｐｏｌｌｉｎｇ（）］  （２．９）
Ｍｅ：Ｐｏｌｌｉｎｇ（）＝［Ｍｅ．ｆ：ｍＲ？（）＊→Ｍｅ：Ｐｏｌｌｉｎｇ（）］  （２．１０）
ポーリングは再帰的であるが、それはＣＩＰのｗｈｉｌｅループのためである（（２．２）を参照）。これまで説明してきた仕様によって実施される計算は以下のＡＬＬＥＯＰによって特徴付けられる。
【０１４６】
２．１．１．ＢＩＬＬ−ＢｅｎゲームのＡＬＬＥＯＰ
以下の「→」は「起因する」と読み、「・→」は「直接起因する」と読む。これらは因果結合と呼ぶ。これらはセクション５で定義する。ＡＬＬＥＯＰは、ＴＩＰ、ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋ、およびポーリングサイクル内の情報を組み合わせる。ＡＬＬＥＯＰがＴＩＰから導出された時に４つの簡単な変換が発生し、（ｉ）「；」は「・→」で置き換えられ、（ｉｉ）信号送信アクション、ＴＩＰに現れているポートｐでのｐ：ｓ（）は以下で説明するようにタイムマップに関連付けられている信号送信と信号配信のイベントに関するそれらの拡張によって置き換えられ、（ｉｉｉ）信号配信に起因する並列起動が指定され、（ｉｖ）各信号検知アクション、ｐ：ｍＲ？（）（またはｐ：ｍＲ？（）＊）はそれによってその引数として検知される信号配信イベントによって与えられる。以下で説明するＡＬＬＥＯＰはこれらの変換を示している。各ポートＡＬＬＥＯＰは２つのコンポーネント：ＡＬＬＥＯＰ−ｇｕａｒｄ（）とＡＬＬＥＯＰ−ｂｏｄｙ（）とを有しており、構造はＡＬＬＥＯＰ−ｇｕａｒｄ（）｛ＡＬＬＥＯＰ−ｂｏｄｙ（）｝であって、ＡＬＬＥＯＰ−ｇｕａｒｄ（）がｔｒｕｅの場合にＡＬＬＥＯＰ−ｂｏｄｙ（）が呼び出され、それ以外はボディがスキップされる。ポートＥ．ｇについてのポートＡＬＬＥＯＰについてまず検討する。これは、Ｅ．ｇ：ＴＩＰＱ（２．３）、図５のＴＩＣＣＴＭネットワーク、および（２．７）のポーリングサイクルから導出される。それは（２．１１）に示しており、その解釈はその後に続く。
【０１４７】
Ｅ．ｇ：ＡＬＬＥＯＰ（）＝□［Ｅ．ｇ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｅ．ｇ：ＡＬＬＥＯＰ−ｂｏｄｙ｝］
Ｅ．ｇ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｅ．ｇ：ｐＲ？（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）＊］
Ｅ．ｇ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｅ．ｇＳ［ｔ（Ｅ．ｇ，０）］
→（（〈Ｂｅ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］｜｜→．．．→Ｂｅ．ｆ：ＡＬＬＥＯＰ（））
（〈Ｂｉ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］｜｜→．．．→Ｂｉ．ｆ：ＡＬＬＥＯＰ（）））
・→Ｅ．ｇ：ｍＲ？（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊｛｝
・→Ｅ．ｇ：ＡＬＬＥＯＰ（））｝］  （２．１１）
【０１４８】
ここで、Ｅ．ｇ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）は（２．３）に示されているＥ．ｇ：ＴＩＰ−ｇｕａｒｄ（）と同一である。（２．３）のＴＩＰボディに現れる通信ステートメントＥ．ｇ：ｓ（）は、Ｅ．ｇ：ｓ（）が実行された時に発生する信号送信／配信イベントに変換されており、信号送信イベントはＥ．ｇＳ［ｔ（Ｅ．ｇ，０）］（Ｓは送信を表す）、信号配信イベントは（〈Ｂｅ．ｆＤ〉［ｔ（Ｅ．ｇ，１）と〈Ｂｉ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］（Ｄは配信を表す）である。信号送信と信号配信のイベントに現れている引数ｔ（Ｅ．ｇ，０）とｔ（Ｅ．ｇ，１）はタイムマップである。以下で説明するように、各タイムマップは時間点の増加するシーケンスにマッピングする。（２．１１）の配信イベントの両側に現れる細い線の山括弧「〈．．．〉」はイベントがタイムマップに指定されている時間点で完了していることを指定している。送信イベントＥ．ｇＳの両側にそのような山括弧がないのは、タイムマップで指定されている時間点で開始したことを意味している。したがって、イベントの両側の山括弧の有無がこれらのイベントの開始時間と終了時間とを区別している。
【０１４９】
（２．１１）の２つの信号配信イベント、Ｂｅ．ｆＤとＢｉ．ｆＤは同一のタイムマップｔ（Ｅ．ｇ，１）を有している。これは、信号がｔ（Ｅ．ｇ，１）内の同じ時間点に両方のポート［Ｂｅ．ｆ，Ｂｉ．ｆ］に配信されることを指定している。タイムマップｔ（Ｅ．ｇ，＃）、＃＝０および１、の＃の異なる値は同じポートＥ．ｇに関連付けられている時間点の２つの異なるシーケンスを一意に識別する。ＣＩＰまたはＴＩＰに現れる同じポートでの別個の通信イベントはそれらに関連付けられている＃の別個の値を有している。イベントＥ．ｇＳ、Ｂｅ．ｆＤ、およびＢｉ．ｆＤは全てポートＥ．ｇでのプロトコルの評価に起因している。
【０１５０】
タイムマップに関連付けられている時間点のシーケンスは以下のように解釈される：
シーケンス、ｔ（Ｅ．ｇ，０）＝（ｔ０，ｔ１，．．．，ｔｎ−１）、ｔ０＜ｔ１＜．．．＜ｔｎ−１は信号をＥ．ｇを介してポートグループＢ．ｆ＝［Ｂｅ．ｆ，Ｂｉ．ｆ］に送信することによってＥがゲームのｉ番目、０≦ｉ＜ｎ、の繰り返しを開始した時間点を表し、シーケンス、ｔ（Ｅ．ｇ，１）＝（ｔ０’，ｔ１’，．．．，ｔｎ−１’）、ｔｉ＜ｔｉ’＜．．．＜ｔい＋１はＢ．ｆのポートへの信号の配信が発生する対応する時間点を表す。（０≦ｉ＜ｎ）について、時刻ｔｉで開始した信号送信が時刻ｔｉ’の配信イベントの完了で終了するという意味で、ｔｉはｔｉ’に対応し、２つのシーケンスは完全に順序付けられているチェーン、ｔ０＜ｔ０’＜ｔ１＜ｔ１’＜ｔ２＜ｔ２’．．．＜ｔｎ−１＜ｔｎ−１’に組み合わされる。
【０１５１】
配信イベントが他のＡＬＬＥＯＰの並列起動の原因となる。（２．１１）の配信イベントに現れる記号「｜｜」は信号がＡＬＬＥＯＰ、Ｂｅ．ｆ：ＡＬＬＥＯＰ（）とＢｉ．ｆ：ＡＬＬＥＯＰ（）を並列に起動することを指定している。「｜｜」を伴う省略、→．．．→は信号の配信後に即座に起動が発生しないかもしれないことを示している。ＢｅｎとＢｉｌｌとは、信号配信時に配信された信号を検知する代わりに他のことをしていたかもしれない。しかし、最終的に彼らは信号を検知しそれに応答することになる。
【０１５２】
最終的に、（２．１１）の「Ｅ．ｇ：ｍＲ（）？（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊」に現れる引数「〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］」はＥ．ｇ：ｍＲ？（）＊によって検知される信号配信イベントを識別する。これはポート［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆによってＥ．ｇに返信される信号である。この信号の受信によって、Ｅが信号をＥ．ｇを通して送信することによって開始されたゲームが中止されたことがＥに示される。（２．１１）の同期信号検知動作Ｅ．ｇ：ｍＲ？（）はセルＥがこの中止信号の受信をポートＥ．ｇで待つことを指定している。（２．１１）の検知アクション、Ｅ．ｇ：ｐＲ？（）は任意の引数によって与えられるが、それは、この場合、ポートＥ．ｇの状態が信号の送信の準備ができていることをテストするだけであって、配信された信号をテストしないためである。ｐ：ｐＲ？（）がＴＩＰにおいて配信された信号の検知に使用される場合、引数がそのために提供されることになる。
【０１５３】
ＡＬＬＥＯＰ（２．１１）から（２．１４）のいずれにおいてもＥ．ｇ：ｐＲ？（）に関連付けられている並列起動は存在しない。したがって、（２．１１）のＥ．ｇ：ｐＲ？（）は引数を有していない。しかし、（２．１２）と（２．１３）のＥ．ｇ：ｍＲ（）＊｛｝は並列起動を有しており、したがって引数を有している。システムは並列起動が指定された時にＡＬＬＥＯＰガード内の信号検知動作に引数を提供する。以下で説明する他のＡＬＬＥＯＰはそれらのそれぞれのＴＩＰから同様に導出される。
【０１５４】
／／（２．４）のＢｅ．ｆ：ＴＩＰ（）、図５のネットワーク、およびポーリングサイクル（２．８）から導出。
【０１５５】
Ｂｅ．ｆ：ＡＬＬＥＯＰ（）＝□［Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｂｅ．ｆ：ｍＲ？（〈Ｂｅ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］）］
Ｂｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｂｅ．ｆ：ｗｏｒｋ（）・→Ｂｅ．ｇＳ［ｔ（Ｂｅ．ｇ，０）］
→（〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］｜｜Ｍｅ．ｆ：ＡＬＬＥＯＰ（．．．））
・→Ｂｅ．ｇ：ｍＲ？（〈Ｂｅ．ｇＤ〉［ｔ（Ｍｅ．ｆ，１）］）＊｛
Ｂｅ．ｆＳ［ｔ（Ｂｅ．ｆ，０）］｝
→（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］
｜｜Ｅ．ｇ：ｍＲ（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊｛｝）｝
→Ｂｅ．ｆ：ＡＬＬＥＯＰ（）］  （２．１２）
ただし、（２．１２）において、信号送信イベントＢｅ．ｇＳ［ｔ（Ｂｅ．ｇ，０）］内のタイムマップはポートグループＢ＝［Ｂｅ．ｇ，Ｂｉ．ｇ］を参照しないが、信号送信イベント〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］内のタイムマップはＢを参照する。これは、Ｂｅｎが信号をＢｅ．ｇを通して送信した時にＢｉｌｌと調和しないが、エージェントａ２（図５を参照）は配信イベント〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］を発生させる調和信号を送信するからである。同様なタイミング指定はイベントＢｅ．ｆＳ［ｔ（Ｂｅ．ｆ，０）］と〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］に現れている。
【０１５６】
／／（２．５）のＢｅ．ｆ：ＴＩＰ（）、図５のネットワーク、およびポーリングサイクル（２．９）から導出。
【０１５７】
Ｂｉ．ｆ：ＡＬＬＥＯＰ（）＝□［Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｂｉ．ｆ：ｍＲ？（〈Ｂｉ．ｆＤ〉［ｔ（Ｅ．ｇ，１）］）］
Ｂｉ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｂｉ．ｆ：ｐｌａｙ（）・→Ｂｉ．ｇＳ［ｔ（Ｂｉ．ｇ，０）］
→（〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］｜｜Ｍｅ．ｆ：ＡＬＬＥＯＰ（．．．））
・→
Ｂｉ．ｇ：ｍＲ？（Ｂｉ．ｇＤ［ｔ（Ｍｅ．ｆ，１）］）＊｛Ｂｉ．ｆＳ［ｔ（Ｂｅ．ｆ，０）］｝
→（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］
｜｜Ｅ．ｇ：ｍＲ（〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］）＊｛｝）｝
→Ｂｉ．ｆ：ＡＬＬＥＯＰ（）］  （２．１３）
【０１５８】
別個のポートＡＬＬＥＯＰに現れる同一のタイムマップはこれらのタイムマップに関連付けられているイベントが異なるＡＬＬＥＯＰにおいて同時に発生することを示している。したがって、ＡＬＬＥＯＰ（２．１２）、（２．１３）および（２．１４）の〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］は同じ配信イベントが３つのＡＬＬＥＯＰにおいて参照されていることを示している。同様に、ＡＬＬＥＯＰ（２．１１）、（２．１２）および（２．１３）の〈Ｅ．ｇＤ〉［ｔ（Ｂ．ｆ，１）］は同じ配信イベントを参照している。ただし、（２．１２）、（２．１３）および（２．１４）の並列起動に続いて省略→．．．→は存在しない。これは、信号受信セルがそれらのそれぞれのポートで信号を待っており、配信された信号を即座に検知するからである。
【０１５９】
／／（２．６）のＢｉ．ｆ：ＴＩＰ（）、図５のネットワーク、およびポーリングサイクル（２．１０）から導出。
【０１６０】
Ｍｅ．ｆ：ＡＬＬＥＯＰ（）＝□［Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｍｅ．ｆ：ｍＲ？（〈Ｍｅ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］）＊］
Ｍｅ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｍｅ．ｆ：ｍｅｅｔ（）・→Ｍｅ．ｆＳ［ｔ（Ｍｅ．ｆ，０）］
→（（〈Ｂｅ．ｇＤ〉ｔ（Ｍｅ．ｆ，１）］｜｜
Ｂｅ．ｇ：ｍＲ（Ｂｅ．ｇＤ［ｔ（Ｍｅ．ｆ，１）］）＊｛・→．．．・→｝）
→（〈Ｂｉ．ｇＤ〉［ｔ（Ｍｅ．ｆ，１）］｜｜
Ｂｉ．ｇ：ｍＲ（Ｂｉ．ｇＤ［ｔ（Ｍｅ．ｆ，１）｛・→．．．・→｝）＊））
・→Ｍｅ．ｆ：ＡＬＬＥＯＰ（）］  （２．１４）
【０１６１】
ＡＬＬＥＯＰをＴＩＰから導出する規則は単純である。ＡＬＬＥＯＰ構造はＦＳＰ構造と同じように見える。しかし、読者には５〜６個の違いがあることがわかる。ＡＬＬＥＯＰはイベントと因果リンクとを表している。ＦＳＰは状態と遷移とを表している。ＡＬＬＥＯＰとＦＳＰとの間の関係は後で説明する。ただし、アクションＢｅ．ｆ：ｗｏｒｋ（）、Ｂｉ．ｆ：ｐｌａｙ（）およびＭｅ．ｆ：ｍｅｅｔ（）などのＡＬＬＥＯＰで指定されるアクションは、一般にＡＬＬＥＯＰにおいて分岐因果シーケンスを一般に発生させる。２種類の分岐が存在し、一方は選択分岐であって、因果シーケンスの有限の集合から１つの選択肢が因果シーケンスに関連付けられている選択条件を評価し、ｔｒｕｅと評価された第１のものを選択することによって実行（ｒｕｎ）時に実行（ｒｕｎ）のために選択される。選択肢を分離するために記号「｜」を使用する（（４．１４）を参照）。前述のＡＬＬＥＯＰでは選択分岐は発生しない。他方の種類の分岐は、ＡＬＬＥＯＰ（２．１１）と（２．１４）のような通信の結果発生する複数の並列分岐（フォーク）である。
【０１６２】
タイムマップの半順序付け：この例の様々なタイムマップとそれらの半順序付けを次に示す：
ｔ（Ｅ．ｇ，０）、ゲームを開始するために信号がＢｉ．ｆとＢｅ．ｆに送信される＜
ｔ（Ｅ．ｇ，１）、信号がＢｉ．ｆとＢｅ．ｆに配信される＜
（ｔ（Ｂｅ．ｇ，０）、ｔ（Ｂｉ．ｇ，０））、Ｂｉ．ｇとＢｅ．ｇがミーティング開始信号をＭｅ．ｆｂ送信する＜
ｔ（Ｂ．ｇ．１）、ミーティング開始信号がエージェントａ２によってＭｅ．ｆに配信される＜
ｔ（Ｍｅ．ｆ，０）、ミーティング終了信号がＢｉ．ｇとＢｅ．ｇに送信される＜
ｔ（Ｍｅ．ｆ，１）、ミーティング終了信号がＢｉ．ｇとＢｅ．ｇに配信される＜
（ｔ（Ｂｅ．ｆ，０）、ｔ（Ｂｉ．ｆ，０））、Ｂｅ．ｆ、およびＢｉ．ｆがゲーム終了信号をＥ．ｇに送信する＜
ｔ（Ｂ．ｆ，１）］、ゲーム終了信号がエージェントａ１によってＥ．ｇに配信される（２．１５）
タイムマップの比較不能な対：
（ｔ（Ｂｅ．ｇ，０），ｔ（Ｂｉ．ｇ，０））≦ｔ（Ｂ．ｇ，０）、エージェントａ２は調和信号をＭｅ．ｆに送信する
（ｔ（Ｂｅ．ｆ，０），ｔ（Ｂｉ．ｆ，０））≦ｔ（Ｂ．ｆ，０）、エージェントａ１は調和信号をＭｅ．ｇに送信する（２．１６）
（２．１６）の比較不能なタイムマップの対が互いに交差する、つまりｔ（Ｂｅ．ｇ，０）∩ｔ（Ｂｉ．ｇ，０）≠φかつｔ（Ｂｅ．ｆ，０）∩ｔ（Ｂｉ．ｆ，０）≠φであることがあり得る。これは、ＢｅｎとＢｉｌｌとはたまに偶然に同時に信号を送信することがあることを意味する。組み合わされたＡＬＬＥＯＰは以下のようになる。
【０１６３】
ＢＩＬＬ＿ＢＥＮ：ＡＬＬＥＯＰ（）＝
□［∃（〈ｐａｒｔｉａｌ−ｏｒｄｅｒｉｎｇ−ｏｆ−ｔｉｍｅ−ｍａｐｓ〉）
（Ｅ．ｇ：ＡＬＬＥＯＰ（）｜｜Ｂｅ．ｆ：ＡＬＬＥＯＰ（．．．）｜｜Ｂｉ．ｆ：ＡＬＬＥＯＰ（．．．）｜｜Ｍｅ．ｆ：ＡＬＬＥＯＰ（．．．））
・→ＢＩＬＬ＿ＢＥＮ：ＡＬＬＥＯＰ（）］  （２．１７）
ここで、セルの並列動作は（２．１５）と（２．１６）の半順序付けによって拘束される。この拘束はネットワーク構造と信号交換タイミングとによって自動的に課される。スケジューリングは伴わない。これらのＡＬＬＥＯＰをリファインし、実装を完了するためには、それらが何であれ、ｐｔｈｒｅｄ、Ｍｅ．ｆ：ｍｅｅｔ（）、Ｂｅ．ｆ：ｗｏｒｋ（）、Ｂｉ．ｆ：ｐｌａｙ（）と、条件Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ？（）とを定義しなければならない。（２．１１）から（２．１４）で定義されているポートＡＬＬＥＯＰはアプリケーションによって実行される計算のモデルである。ＴＩＣＣＴＭ−Ｐｐｄｅは、実装の完全なＡＬＬＥＯＰモデルを生成するために、ＴＩＣＣＴＭネットワークとポーリング仕様とに整合しているポートＡＬＬＥＯＰの逐次／並列組み合わせを生成することができる。ＡＬＬＥＯＰモデルを使用して証明する任意の特性は、実装の有効な特性であって、単に意図した設計の特性ではない。全てのＡＬＬＥＯＰは普遍時間演算子□から始まる。この演算子はＡＬＬＥＯＰの説明では省略する。それは常に存在していると仮定しなければならない。
【０１６４】
２．１．２．ＣＩＰのＡＬＬＥＯＰ
ここで、（２．２）のＣＩＰ用のＡＬＬＥＯＰを書くことにする。ここで、割り込み信号をＥ．ｉに送信するＵｓｅｒ．ｇと呼ばれるポートを仮定している。Ｕｓｅｒは図５には示していない。
【０１６５】
Ｅ：ＣＩＰ−ＡＬＬＥＯＰ（）＝［Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）・→Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ］
Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）＝
［Ｅ：ｉｎｉｔｉａｌｉｚｅ？（）｛ｉｎｉｔ（）・→Ｅ．ｉＳ［ｔ（Ｅ．ｇ，２）］
→（〈Ｕｓｅｒ．ｇＤ〉［ｔ（Ｅ．ｇ，３）｜｜→．．．→Ｕｓｅｒ．ｇ：ＡＬＬＥＯＰ（））
・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ］
Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）＝
［（¬Ｅ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｅ．ｇ：ＡＬＬＥＯＰ（）・→Ｅ．ｉ：ＡＬＬＥＯＰ（）
・→Ｅ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
Ｅ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝）］  （２．１８）
ただし、タイムマップｔ（Ｅ．ｇ，２）とｔ（Ｅ．ｇ，３）とは（２．１８）で使用されている。これは、ｔ（Ｅ．ｇ，０）とｔ（Ｅ．ｇ，１）とが既にＥ．ｇ．：ＡＬＬＥＯＰ（）（（２．１１）を参照）で使用されており、Ｅ．ｇ：ＡＬＬＥＯＰ（）が（２．１８）のＥ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）に現れるためである。ここで、Ｅ：ｉｎｉｔｉａｌｉｚｅ？（）＝Ｅ．ｉｎｉｔｉａｌｉｚｅであって、同様に、¬Ｅ：ｓｔｏｐＰｏｌｌｉｎｇ？（）＝¬Ｅ．ｓｔｏｐＰｏｌｌｉｎｇである。オブジェクトの各ブール属性はこの種類の述語を有している。（２．１８）において、セルＥのポートはそれらのＴＩＰボディーが実行される前に並べ替えられない。
【０１６６】
ＴＩＰボディーが実行される前にポートが並べ替えられている（１．１）に示している種類のＣＩＰのＣＩＰ−ＡＬＬＥＯＰを以下の（２．１９）に示している。Ｘ．ｇがＣｅｌｌを起動する割り込み信号を送信し、（１．１）に現れるｐｏｌｌ＆ＳｏｒｔＰｏｒｔｓ（）が２つのコンポーネント、ポーリングと並べ替えに分割されているという以下の仮定が（２．１９）において行われている。（２．１９）のＣｅｌｌ：ｓｏｒｔＩｎｔｏ（．．．）に現れる引数において、Ｃｅｌｌ．ｐｏｒｔｓはＣｅｌｌに付属しているポートのベクトルであって、Ｃｅｌｌ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ（Ｃｅｌｌ．ｓｐＬ）は他のベクトルであって、保留中のメッセージのある並べ替えられているポートを含むことになり、引数ｓｏｒｔＲは並べ替え関係である。全てはＣｅｌｌクラスで定義されている。
Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ（）＝［Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）・→Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ］
Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｉｎｉｔ（）＝［Ｃｅｌｌ：ｉｎｉｔ−ＡＬＬＥＯＰ（）・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ
・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→Ｃｅｌｌ．ｉ：ｐＲ？（）｛Ｃｅｌｌ．ｉＳ［ｔ（Ｃｅｌｌ．ｉ，０）］
（〈Ｘ．ｇＤ〉ｔ（ＣｅＩｌ。ｉ，１）］
｜｜→．．．→Ｘ．ｇ：ＡＬＬＥＯＰ（））｝］
Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）＝／／以下では「ｓｐＬ」を「ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ」と読む。
【０１６７】
［（¬Ｃｅｌｌ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｃｅｌｌ．ｉ：ＡＬＬＥＯＰ（）・→Ｃｅｌｌ．ｓｐＬ：ｃｌｅａｒ（）
→  ∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））｛
Ｃｅｌｌ．ｐｏｒｔｓ［ｊ］：ｍＲ？（）｛
Ｃｅｌｌ：ｓｏｒｔＩｎｔｏ（Ｃｅｌｌ．ｐｏｒｔｓ［ｊ］，Ｃｅｌｌ．ｓｐＬ，ｓｏｒｔＲ）｝｝
・→∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（））｛Ｃｅｌｌ．ｓｐＬ［ｊ］：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝
・→Ｃｅｌｌ：ＣＩＰ−ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
Ｃｅｌｌ  ：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ  （）｝）］  （２．１９）
ここで、「∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））」と「∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））」とは指定された範囲のインデックスの列挙子として使用され、それらの、それぞれのスコープ内のアクションは各列挙されたインデックスに適用される。
【０１６８】
２．１．３．トレース
トレースとＡＬＬＥＯＰとの間の違いは以下のとおりである。（ｉ）トレースはイベントと評価が開始および／または終了する仮想的な時間点（以降では単に時間点と呼ぶ）を仮定する。（ｉｉ）トレースは事前条件と事後条件とをそれらが知られた時に〈アクション〉に関連付ける。〈アクション〉、Ａ（）の特徴付けは以下の形式である。
【０１６９】
□［∃（ｔ０＜ｔ１）｛〈ｐｒｅｃｏｎｄｉｔｉｏｎ？（）〉（ｔ０）｝［・→Ａ（）ｔ０）］
｛ｐｏｓｔｃｏｎｄｉｔｉｏｎ？（）（ｔ１）＆（ｔ１＜ｔ０＋τｍａｘ（Ａ）｝］、  （２．２０）
ここで〈アクション〉はｐｔｈｅｄ、プロトコル、プログラムステートメントいずれかであって、τｍａｘ（Ａ）はＡ（）の実行を完了するのにかかる可能性のある最長時間、・→は〈アクション〉実行記号、Ａ（）はｐｒｅｃｏｎｄｉｔｉｏｎ？（）がｔｒｕｅになった時にｔ０で同時に実行を開始し、Ａ（）の実行（ｒｕｎ）は時刻ｔ１に完了し、ｐｏｓｔｃｏｎｄｉｔｉｏｎ？（）はＡ（）の実行が完了した時にｔｒｕｅになる。（ｉｉｉ）トレースは〈アクション〉の事前条件と事後条件において存在する場合は交換されたメッセージの特徴付けも指定する。トレースは、対応するＡＬＬＥＯＰが含んでいる場合には、選択肢と並列フォークとを含んでいる分岐を含んでいてもよい。トレースステートメントで「□」記号を省略しているが、存在していると仮定している。
【０１７０】
システムがポートＡＬＬＥＯＰに対してトレースを導出した時に、システムはポートＡＬＬＥＯＰ内の別個のイベントに対して別個の仮想時間点を単に仮定しており、同一の仮想時間点はポートＡＬＬＥＯＰ内の同一のタイムマップに関連付けられるように対応している。これによって、異なるポートＡＬＬＥＯＰ内で発生するイベントの同期と調和とが反映される。トレース内での時間点の順序付けはポートＡＬＬＥＯＰ内でイベントが発生した順序によって決まる。この順序付けにおいて３つの仮定が行われ：（ｉ）・→でリンクされている連続しているアクションは次々に連続して発生し、リンクの最後のアクションはリンクの最初のアクションが終了するのと同時に始まり、（ｉｉ）各アクションは実行の完了には、既知の上限のある有限の量の非零時間がかかり（ｉｉｉ）セルがポートに信号が配信された時にその信号をそのポートで待っている場合、配信された信号は信号配信時間と同時に即座に検知され、そうでなければ、信号の検知は信号の配信のいくらか後に発生し、（ｉｖ）セルが信号をポートＣ．ｐを通して仮想時間Ｃ．ｐ．ｔに送信した時に、Ｃ．ｐがポートグループｐＧに属している場合、システムはｐＧ内のポートによって送信された信号を受信するエージェントが調和した信号をｐＧ内の全てのポートから信号を受信した後に初めてディスパッチすることを知っている。たとえば、このディスパッチは時間ｐＧ．ｔに発生する。この場合、システムは順序付けをＣｐ．ｔ≦ｐＧ．ｔをトレースに導入する。
【０１７１】
（２．１１）から（２．１４）までのポートＡＬＬＥＯＰのトレースをそれらの解釈と共に以下に示す。Ｂｅｎ−Ｂｉｌｌの解法のトレースには並列フォークが含まれている。（２．１１）のＡＬＬＥＯＰに対応する以下のトレース（２．２１）において、括弧内の表現「（．．．｜｜．．．｜｜．．．）」は並列フォークを記述している。このトレースに現れている〈アクション〉は無い。〈アクション〉、ｐｌａｙ（）、ｗｏｒｋ（）、およびｍｅｅｔ（）はトレース（２．２２）から（２．２４）に現れる。しかし、これらの〈アクション〉はそれらに対して定義されている事前／事後条件を有していない。そのため、トレースには何も現れていない。事前／事後条件とメッセージ条件とが（２．２６）に現れている。
【０１７２】
各トレースにおいて、トレースボディはトレースガードがｔｒｕｅの場合にだけ呼び出され、そうでなければスキップされる。（２．１１）のＡＬＬＥＯＰ、Ｅ．ｇ：ＡＬＬＥＯＰ（）のポートＥ．ｇのトレース、Ｅ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ０）を以下に示す。
【０１７３】
□［Ｂ（Ｅｇ．ｔ０＜Ｅｇ．ｔ１＝Ｂｆ．ｔ０＜Ｅｇ．ｔ２＜Ｅｇ．ｔ３＝Ｂｆ．ｔ１）］
Ｅ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ０）＝
｛・→Ｅ．ｇ：ｔｒａｃｅ−ｇｕａｒｄ（Ｅｇ．ｔ０）｝［・→Ｅ．ｇ：ｔｒａｃｅ−ｂｏｄｙ（Ｅｇ．ｔ１）］
Ｅ．ｇ：ｔｒａｃｅ−ｇｕａｒｄ（Ｅｇ．ｔ０）＝
［〈（Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）（Ｅｇ．ｔ０）〉（Ｅｇ．ｔ１）］
Ｅ．ｇ：ｔｒａｃｅ−ｂｏｄｙ（Ｅｇ．ｔ１）＝
［［・→Ｅ．ｇＳ（Ｅｇ．ｔ１）∈ｔ（Ｅ．ｇ，０））］
（（［〈→Ｂｅ．ｆＤ〉（Ｅｇ．ｔ２∈ｔ（Ｅ．ｇ，１））］｜｜［→Ｂｅ．ｆ：ｔｒａｃｅ（Ｅｇ．ｔ１）］）
（（［〈→Ｂｉ．ｆＤ〉（Ｅｇ．ｔ２∈ｔ（Ｅ．ｇ，１））］｜｜［→Ｂｉ．ｆ：ｔｒａｃｅ（Ｅｇ．ｔ１）］）
｛〈Ｅ．ｇ：ｍＲ（〈Ｅ．ｇＤ〉（Ｅｇ．ｔ３∈ｔ（Ｂ．ｆ，１）））＊〉（Ｅｇ．ｔ３）｝
［・→Ｅ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ３）］］  （２．２１）
【０１７４】
（２．２１）のＥ．ｇ：ｔｒａｃｅ（Ｅｇ．ｔ０）における表現「［〈（Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）（Ｅｇ．ｔ０）〉（Ｅｇ．ｔ１）］」は、条件Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）の評価は時間Ｅｇ．ｔ０に始まりＥｇ．ｔ１に終了することを表明している。（２．２１）の同じ時間点Ｅｇ．ｔ２の２つのイベントへの割り当て〈→Ｂｅ．ｆＤ〉と〈→Ｂｉ．ｆＤ〉は、ポートＢｅ．ｆとＢｉ．ｆへの信号の配信が同じ時間点で同時に行われたことを示している。Ｅ．ｇ：ｔｒａｃｅ−ｂｏｄｙ内の指定「［・→Ｅ．ｇＳ（Ｅｇ．ｔ１）∈ｔ（Ｅ．ｇ，０））］」は山括弧なしの「・→Ｅ．ｇＳ」は、イベントＥ．ｇＳを発生させたアクションの評価は時刻Ｅｇ．ｔ１∈ｔ（Ｅ．ｇ，０）に開始されたことを表明している。ただし、「・→Ｅ．ｇＳ」の開始時刻は、「〈（Ｅ．ｇ：ｐＲ（）＆Ｅ：ｒｅａｄｙＴｏＳｔａｒｔ（）＊）（Ｅｇ．ｔ０）＞（Ｅｇ．ｔ１）」の終了時刻と同じである。「・→Ｅ．ｇＳ」の終了時刻は指定されていない。（２．２１）内の他のステートメントに関連付けられているタイミングの解釈はＡＬＬＥＯＰ内と同じであって、仮想時間点が各場合に仮定されていることが異なる。タイムマップが時間点のシーケンスを表しているように、各仮想時間点も時間点のシーケンスを表している。したがって、（２．２１）において、Ｅｇ．ｔ１∈ｔ（Ｅ．ｇ，０）はＥが（Ｂｉｌｌ｜｜Ｂｅｎ）ゲームを開始した時間点のシーケンスである。Ｂｉｌｌ−Ｂｅｎゲーム内でＡＬＬＥＯＰＳに割り当てられている他のポートトレースを以下に示す。
【０１７５】
Ｂｉ．ｆ：ｔｒａｃｅ（Ｂｉｆ．ｔ０）＝
｛Ｂｉ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｉｆ．ｔ０）｝［・→Ｂｉ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｉｆ．ｔ１）］
［∃（Ｅｇ．ｔ１＝Ｂｉｇ．ｔ０≦Ｂｉｆ．ｔ１＜Ｂｉｇ．ｔ０≦Ｂｇ．ｔ０＜Ｂｇ．ｔ１＝Ｍｅｆ．ｔ０＜
Ｂｉｇ．ｔ１＝Ｍｅｆ．ｔ３＝Ｂｉｇ．ｔ１＜Ｂｉｆ．ｔ２≦Ｂｆ．ｔ０＜Ｂｆ．ｔ１＝Ｅｇ．ｔ３）
Ｂｉ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｉｆ．ｔ０）＝
｛〈Ｂｉ．ｆ：ｍＲ？（〈Ｂｉ．ｆＤ〉（Ｂｉｆ．ｔ０∈ｔ（Ｅ．ｇ，１）））〉（Ｂｉｆ．ｔ１）｝
Ｂｉ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｉｆ．ｔ１）＝
［［・→Ｂｉ．ｆ：ｐｌａｙ（）（Ｂｉｆ．ｔ１）］
［・→Ｂｉ．ｇＳ（Ｂｉｇ．ｔ０∈ｔ（Ｂｉ．ｇ，０）≦Ｂｇ．ｔ０−ｔ（Ｂ．ｇ，０））］
（［〈→Ｍｅ．ｆＤ〉（Ｂｇ．ｔ１∈ｔ（Ｂ．ｇ，１））］｜｜［・→Ｍｅ．ｆ：ｔｒａｃｅ（Ｂｇ．ｔ１）］）
｛〈Ｂｉ．ｇ：ｍＲ？（〈Ｂｉ．ｇＤ〉（Ｂｉｇ．ｔ１∈ｔ（Ｍｅ．ｆ，１）））＊〉（Ｂｉｇ．ｔ１）｝
（［・→Ｂｉ．ｆＳ（Ｂｉｆ．ｔ２≦Ｂｆ．ｔ０∈ｔ（Ｂ．ｆ，０））］
（［〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１∈ｔ（Ｂ．ｆ，１））］
｜｜｛Ｅ．ｇ：ｍＲ（〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１））＊｝［］［・→Ｅ．ｇ：ｔｒａｃｅ（Ｂｆ．ｔ１）］））
［・→Ｂｉ．ｆ：ｔｒａｃｅ（Ｂｆ．ｔ１）］］］  （２．２２）
Ｂｅ．ｆ：ｔｒａｃｅ（Ｂｅｆ．ｔ０）＝
｛Ｂｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｅｆ．ｔ０）｝［・→Ｂｉ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｅｆ．ｔ１）］
［∃（Ｅｇ．ｔ１＝Ｂｅｆ．ｔ０≦Ｂｅｆ．ｔ１＜Ｂｅｇ．ｔ０≦Ｂｇ．ｔ０＜Ｂｇ．ｔ１＝Ｍｅｆ．ｔ０＜
Ｂｅｇ．ｔ１＝Ｍｅｆ．ｔ３＝Ｂｅｇ．ｔ１＜Ｂｅｆ．ｔ２≦Ｂｆ．ｔ０＜Ｂｆ．ｔ１＝Ｅｇ．ｔ３）
Ｂｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｂｅｆ．ｔ０）＝
｛（Ｂｅ．ｆ：ｍＲ？（〈Ｂｅ．ｆＤ〉（Ｂｅｆ．ｔ０∈ｔ（Ｅ．ｇ，１）））〉（Ｂｅｆ．ｔ１）｝
Ｂｅ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｂｅｆ．ｔ１）＝
［（［・→Ｂｅ．ｆ：ｗｏｒｋ（）（Ｂｅｆ．ｔ１）］
［・→Ｂｅ．ｇＳ（Ｂｅｇ．ｔ０∈ｔ（Ｂｅ．ｇ，０）≦Ｂｇ．ｔ０∈ｔ（Ｂ．ｇ，０））
（［〈→Ｍｅ．ｆＤ〉（Ｂｇ．ｔ１∈ｔ（Ｂ．ｇ，１））］｜｜［・→Ｍｅ．ｆ：ｔｒａｃｅ（Ｂｇ．ｔ１）］）
｛〈Ｂｅ．ｇ：ｍＲ？（〈Ｂｅ．ｇＤ〉（Ｂｅｇ．ｔ１∈ｔ（Ｍｅ．ｆ，１）））＊〉（Ｂｅｇ．ｔ１）｝
（・→Ｂｅ．ｆＳ（Ｂｅｆ．ｔ２≦Ｂｆ．ｔ０∈ｔ（Ｂ．ｆ，０））］
（［〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１∈ｔ（Ｂ．ｆ，１））］
｜｜｛Ｅ．ｇ：ｍＲ（〈・→Ｅ．ｇＤ〉（Ｂｆ．ｔ１））＊｝［・→Ｅ．ｇ：ｔｒａｃｅ（Ｂｆ．ｔ１）］））
［・→Ｂｅ．ｆ：ｔｒａｃｅ（Ｂｆ．ｔ１）］］］  （２．２３）
Ｍｅ．ｆ：ｔｒａｃｅ（Ｍｅｆ．ｔ０）＝
｛Ｍｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｍｅｆ．ｔ０）｝［・→Ｍｅ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｍｅｆ．ｔ１）］
［∃（Ｍｅｆ．ｔ０＝Ｂｇ．ｔ３＝Ｍｅｆ．ｔ１＜Ｍｅｆ．ｔ２＜Ｍｅｆ．ｔ３＝Ｂｅｇ．ｔ１＝Ｂｉｇ．ｔ１）
Ｍｅ．ｆ：ｔｒａｃｅ−ｇｕａｒｄ（Ｍｅｆ．ｔ０）＝
｛（Ｍｅ．ｆ：ｍＲ？（）（〈Ｍｅ．ｆＤ〉（Ｍｅｆ．ｔ０∈ｔ（Ｂ．ｇ，１）））＊〉（Ｍｅｆ．ｔ１）｝
Ｍｅ．ｆ：ｔｒａｃｅ−ｂｏｄｙ（Ｍｅｆ．ｔ１）＝
［（［・→Ｍｅ．ｆ：ｍｅｅｔ（）（Ｍｅｆ．ｔ１）］
［・→Ｍｅ．ｆＳ（Ｍｅｆ．ｔ２∈ｔ（Ｍｅ．ｆ，０））］
（（［〈→Ｂｅ．ｇＤ〉（Ｍｅｆ．ｔ３∈ｔ（Ｍｅ．ｆ，１））］
｜｜｛〈Ｂｅ．ｇ：ｍＲ？（〈Ｂｅ．ｇＤ〉（Ｍｅｆ．ｔ３））＊〉（Ｍｅｆ．ｔ３））｝・→．．．・→）
（［〈→Ｂｉ．ｇＤ〉（Ｍｅｆ．ｔ３∈ｔ（Ｍｅ．ｆ，１））］
｜｜｛〈Ｂｉ．ｇ：ｍＲ？（〈Ｂｉ．ｇＤ〉（Ｍｅｆ．ｔ３））＊〉（Ｍｅｆ．ｔ３））｝・→．．．・→）））
［・→Ｍｅ．ｆ：ｔｒａｃｅ（Ｍｅｆ．ｔ３）］］］  （２．２４）
【０１７６】
比較不能な時間点：
（Ｂｉｆ．ｔ１，Ｂｅｆ．ｔ１）（Ｂｉｆ．ｔ２，Ｂｅｆ．ｔ２）（Ｂｅｇ．ｔ０，Ｂｉｇ．ｔ０）（２．２５）
（２．２２）と（２．２３）の第１行の存在宣言は、Ｂｉｆ．ｔ０＝Ｅｇ．ｔ１＜Ｂｉｆ．ｔｉａｎｄＢｅｆ．ｔ０＝Ｅｇ．ｔ１＜Ｂｅｆ．ｔ１が、信号がポートＢｉ．ｆとＢｅ．ｆとに同期して仮想時間Ｅｇ．ｔ１に配信されるが、配信された信号は同期して検知されないことを示すことを指定している。それらは、比較不能な時間点Ｂｉｆ．ｔ１とＢｅｆ．ｔ１とで検知される。同様に、ＢｉｌｌとＢｅｎが信号をそれぞれ仮想時間Ｂｉｆ．ｔ２とＢｅｆ．ｔ２にＥ．ｇに送信した時に、信号を送信する時間を調和させない。しかし，両方の信号がエージェントａ１によって時間Ｂｆ．ｔ０受信された時に、ａ１は調和信号をＥ．ｇにディスパッチする。この信号ディスパッチ時間は常に＞信号送信時間である。したがって、宣言Ｂｉｆ．ｔ２≦Ｂｆ．ｔ０およびＢｅｆ．ｔ２≦Ｂｆ．ｔ０が（２．２２）および（２．２３）に現れる。同様に、（Ｂｅｇ．ｔ０，Ｂｉｇ．ｔ０）≦Ｂｇ．ｔ０もエージェントａ２が時間Ｂｇ．ｔ０において調和させる。ＢｉｌｌとＢｅｎはそれらのポートＢｉ．ｇとＢｅ．ｇとに配信された信号を信号配信の直後に時間Ｂｇ．ｔ１で検知するが、それは両者が信号の配信時に信号を待っているためである。
【０１７７】
読者は、異なるポートトレース内の互いに同一の時間点がタイムマップ内のそれらのメンバーシップによってどのように識別されるかを追跡することができなければならない。そのように識別された仮想時間点の間の同一性が、各トレースの最初の存在宣言に導入されている。等式または不等式の関係によって互いに関連付けられていない異なるセルのポートのトレースに現れる全ての時間点は比較不能な時間点である。
【０１７８】
全てのトレースがいったん生成されると、システムはＡＬＬＥＯＰにおいて指定されているタイムマップ内に現れる仮想時間点とどのタイムマップにも現れない仮想時間点を知る。それから、システムは異なるポートトレース内の同一のタイムマップ内に現れる時間点を互いに等しいと設定する。これによって、すべての調和し、同期した信号の配信が識別される。したがって、（２．２１）のトレースの場合、トレースの最初の時間点の存在宣言は、ポートＥ．ｇがエージェントａ１＝Ｂｆ．ｔ１によってそれに配信された信号を受信する仮想時間点Ｅｇ．ｔ３を宣言しており、それはａ１がその信号を配信した仮想時刻である（図５参照）。これは、ＡＬＬＥＯＰ（２．１１）、（２．１２）、および（２．１３）のタイムマップｔ（Ｂ，ｆ，１）によって指定されているポートＥ．ｇへの調和した信号配信を識別する。同様に、（２．２２）と（２．３３）において、Ｂｅｆ．ｔ０＝Ｅｇ．ｔ１＝Ｂｉｆ．ｔ０である。これはポート［Ｂｅ．ｆ，Ｂｉ．ｆ］＝Ｂ．ｆへの同期した信号配信を指定している。仮想時間点のこれらの識別は（２．１５）に示している半順序付けに整合している。仮想時間点内の関係を設定した後、システムは配信イベント引数を全ての信号検知動作に、これらのイベントによって起動したトレースに整合するように割り当てる。メッセージの特徴付けとアクションに関連付けられている事前／事後条件とが既知の場合、ＡＬＬＥＯＰのトレースへの変換は複雑ではなく、これらを取得するにはユーザ支援が必要なこともある。
【０１７９】
このアプリケーションのポートトレースは信号検知条件だけを使用する。セクション６．４と付録ＩＩＩにおいて、トレースは様々な条件とアクションに関連付けられている事前／事後条件のある分岐アクションとを含んでいる。各トレースは、証明生成については通常のトレース内の情報の表形式への単なる再構成であるイベント特徴付け表（ＥＣＴ）を生成する。セクション６に例を示す。
【０１８０】
２．１．４．ＣＩＰのトレース
∀列挙子のあるステートメントがどのように取り扱われるかを示すために、ＣＩＰ−ＡＬＬＥＯＰ（２．１９）のトレースの部分を以下の（２．２６）に示している。（２．６）に現れる句（ｐ［ｉ］⇔ｑ［ｉ］）は、ポート［ｉ］とポートｑ［ｉ］との間に経路が存在していることを表明している。インデックスまたは項目は、∀列挙子によって順番に列挙される。以下では、インデックスｉ、０≦ｉ＜ｎ−１の列挙は、インデックスｉ＋１の列挙の前であると仮定する。（２．１９）に現れる列挙子のあるＡＬＬＥＯＰステートメントを以下に便宜上再掲載している（ｓｐＬをｓｏｒｔｅｄＰｏｒｔｓＬｉｔｓと読み替える）。
・→Ｃｅｌｌ．ｓｐＬ：ｃｌｅａｒ（）
・→∀（ｉ）（０≦ｉ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））｛
Ｃｅｌｌ．ｐｏｒｔｓ［ｉ］：ｍＲ？（）｛Ｃｅｌｌ：ｓｏｒｔＩｎｔｏ（Ｃｅｌｌ．ｐｏｒｔｓ［ｉ］，Ｃｅｌｌ．ｓｐＬ，ｓｏｒｔＲ）｝｝
・→∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（））｛ｓｐＬ［ｊ］：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝  （２．１９ａ）
前述の列挙子ステートメントのトレースを以下に示す。
【０１８１】
［∀（ｉ）（（０≦ｉ  ＜（Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（）−１）
（∃（Ｃｐ［ｉ］．ｔｉ＜Ｃｐ［ｉ］．ｔｉ＋１＝Ｃｐ［ｉ＋ｌ］ｔｉ＋１）
∃（ｑ［ｉ］．ｔ０＜Ｃｐ［ｉ］．ｔｉ＜ｑ［ｉ＋１］．ｔ０））／／トレースで使用される仮想時間点の宣言
∀（ｉ）（０≦ｉ＜（Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（）−１）
∃（ｓＰＬ［ｉ］．ｔｊ＜ｓＰＬ［ｉ］．ｔｊ＋１＝ｓＰＬ［ｉ＋１］ｔｉ＋１））／／仮想時間点の宣言
［∀（ｋ）（０≦ｋ＜Ｃｅｌｌ．ｐｏｒｔｓ：ｓｉｚｅ（））／／ここで∀（ｋ）は以下のアクションの列挙子
∃（Ｐｏｒｔｓ  ｐ［ｋ］，ｑ［ｋ］）（ｐ［ｋ］＝Ｃｅｌｌ．ｐｏｒｔｓ［ｋ］＆（ｐ［ｋ］⇔ｑ［ｋ］））
／／以下では、信号が時刻ｑ［ｋ］．ｔ０に配信され、検知が時刻Ｃｐ［ｋ］．ｔｋで完了する。
【０１８２】
｛〈ｐ［ｋ］：ｍＲ？（〈ｐ［ｋ］Ｄ〉（ｑ［ｋ］．ｔ０））〉（Ｃｐ［ｋ］．ｔｋ）｝
／＊以下の並べ替えアクションは信号検知か完了した時刻、つまりＣｐ［ｋ］．ｔｋで完了し、Ｃｐ［ｋ］．ｔｋ１で終了する：ｓｏｒｔＲは並べ替え関係である。＊／
［〈・→Ｃｅｌｌ：ｓｏｒｔｌｎｔｏ（ｐ［ｋ］，ｓｐＬ，ｓｏｒｔＲ）（Ｃｐ［ｋ］．ｔｋ）〉（Ｃｐ［ｋ］．ｔｋ＋１）］
｛（（ｋ＝０）＆ｓｐＬ［０］＝ｐ［０］）∨
（ｋ＞０＆ｓｐＬ［０］＝ｐ［ｋ］＆（ｐ［ｋ］ｓｏｒｔＲ  ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［１］））∨
（ｋ＞０＆∃（ｊ＞０）（ｓｐＬ［ｊ］＝ｐ［ｋ］＆（ｓｐＬ［ｊ−ｌ］ｓｏｒｔＲ  ｐ［ｋ］））｝］
／／ｓｐＬ［ｊ］：ｔｒａｃｅ−ｂｏｄｙ（）は時刻ｓＰＬ［ｊ］．ｔｊで始まり、時刻ｓＰＬ［ｊ］．ｔｊ＋１で終わる
［｛∀（ｊ）（０≦ｊ＜Ｃｅｌｌ．ｓｐＬ：ｓｉｚｅ（））／／ここでも∀（ｊ）が列挙子として使用されている
［〈・→ｓｐＬ［ｊ］：ｔｒａｃｅ−ｂｏｄｙ（）（ｓＰＬ［ｊ］．ｔｊ）〉（ｓＰＬ［ｊ］．ｔｊ＋１）］］］  （２．２６）
【０１８３】
（２．２６）で注意すべき特徴は以下のとおりである。（ｉ）信号はポートｐ［ｋ］に時刻ｑ［ｋ］．ｔ０に配信され、配信された信号は時刻Ｃｐ［ｋ］．ｔｋに検知される。インデックスｋについての並べ替えアクション、Ｃｅｌｌ：ｓｏｒｔｌｎｔｏ（．．．）は即座に同じ時刻、Ｃｐ［ｋ］．ｔｋに始まる。インデックスｋについてのこの並べ替えアクションはインデックス（ｋ＋１）についての並べ替えが始まるＣｐ［ｋ］．ｔｋ＋１に終了する。これは最初のタイミング指定で宣言されており、宣言がＣｐ［ｋ］．ｔｋ＋１＝Ｃｐ［ｋ＋１］．ｔｋ＋１が現れている。同様なタイミング構造が他の列挙ステートメントについても現れている。（ｉｉ）事前／事後条件が［〈・→Ｃｅｌｌ：ｓｏｒｔｌｎｔｏ（ｐ［ｋ］，ｓｐＬ，ｓｏｒｔＲ）（Ｃｐ［ｋ］．ｔｋ）〉（Ｃｐ［ｋ］．ｔｋ＋１）］アクションに対して示されている。ＣＩＰ−ＡＬＬＥＯＰ（２．１９）についての前述のトレースを使用したトレースの生成は非常に単純である。
【０１８４】
２．１．５ＡＬＬＥＯＰとｃａｕｓａｌｎｅｔのグラフィック表現
このアプリケーション用のＡＬＬＥＯＰのグラフィック表現を図６Ａに示している。これは、（２．１１）から（２．１４）に記載のポートＡＬＬＥＯＰの直列並列構成を表している。図６ＡのＡＬＬＥＯＰグラフに現れるノードはイベントクラスと呼ばれるが、それはアプリケーションが繰り返して実行（ｒｕｎ）される時に各ノードの多くのインスタンスが現れることがあるためである。ノードの対の間の有向リンクはノード間の因果関係を表している。図６Ａのリンクのラベルはこれらのリンクが発生するためにはｔｒｕｅでなければならない条件を表している。ここでは信号検知条件だけが現れている。
【０１８５】
図６ＡのＡＬＬＥＯＰグラフについてのゲームの１回の実行（ｒｕｎ）においてＳＭＳによって生成されるｃａｕｓａｌｎｅｔを図６Ｂに示している。図６Ｂの各ノードは、対応しているＡＬＬＥＯＰノードのインスタンスである。ＡＬＬＥＯＰは遊び、仕事、および会議のアクションイベントを示しており、ｃａｕｓａｌｎｅｔはＡＬＬＥＯＰとトレースに現れる通信イベントクラスのインスタンスである通信イベントだけを示している。トレースで仮定されている仮想時間点の代わりにｃａｕｓａｌｎｅｔイベントに関連付けられている時間インスタンスはアプリケーションに関連付けられているグローバルクロック内の時間点である。それはアプリケーションの実行（ｒｕｎ）中にイベントが発生した時刻である。図６Ｃはゲームが５〜６回繰り返される時のｃａｕｓａｌｎｅｔを示している。ｃａｕｓａｌｎｅｔは図６Ａに示している時刻の順序を保存しているが、図６Ａのループのリンクが図６Ｃに示しているように、反復に置き換えられている。タイムマップのように、トレース内の仮想時間点も関連付けられている時間インスタンスのシーケンスを有していることは明かである。
【０１８６】
ｃａｕｓａｌｎｅｔに現れるイベントノードの集合は単にアプリケーションの実行（ｒｕｎ）中に発生し、アプリケーションのトレースに現れる全ての通信イベントとそれらのそれぞれの発生時刻との集合である。トレースが選択点を含んでいる場合、トレースに現れる全てのイベントがｃａｕｓａｌｎｅｔに対応するイベントを有しているわけではなく、選択点で選択されたイベントだけがｃａｕｓａｌｎｅｔ内に対応するイベントを有することになる。トレースに現れる全ての事前／事後条件、イベントの検知、およびアクションイベントは無視される。したがって、ｃａｕｓａｌｎｅｔはアプリケーションの実行（ｒｕｎ）時に発生する通信イベントに対応しているトレースの一部のアブストラクションである。同期している入力信号を受信するノードはそれらに関連付けられている同一のグローバル時間インスタンスを有している。同様に、調和した出力信号をエージェントを通してディスパッチするノードもそれらに関連付けられている同一のグローバルディスパッチ時間インスタンスを有している。トレースのイベントクラスに関連付けられている各別個の仮想時間点は、そのトレースから生成されたｃａｕｓａｌｎｅｔ内のそのイベントクラスのインスタンスに関連付けられている時間インスタンスの別個のシーケンスに対応している。したがって、句Ｅ．ｇｓ（Ｅｇ．ｔ１∈ｔ（Ｅ．ｇ，０））に現れる仮想時間点Ｅｇ．ｔ１は図６Ｃに示している時間点のシーケンスｔ（Ｅ．ｇ，０）＝ｔ０，ｔ７，ｔ１５，．．．ｔ８ｎ＋７，．．．，を表している。
【０１８７】
2012506076.tif 000007
【０１８８】
図６：｜｜ＢＩＬＬ＿ＢＥＮ解法のＡＬＬＥＯＰとｃａｕｓａｌｎｅｔ
ノードは、図６Ｂと６Ｃに示しているようにｃａｕｓａｌｎｅｔにおいて有向リンクによって互いにリンクされている。リンクはノードの半順序を指定している。２種類のリンクが存在し、それらは（ｉ）ＴＩＰの実行中に発生するイベントの順序を指定する因果リンク、（ｉｉ）アプリケーションの実行（ｒｕｎ）中にセルにおいて発生する異なるＴＩＰ実行（ｒｕｎ）の順序を指定する実行リンクである。ｃａｕｓａｌｎｅｔ内のイベントインスタンスの半順序付けは、これらの２種類のリンクによってもたらされた半順序付けの和集合である。図６Ｃにおいて、ゲームの連続している反復の間のリンクは実行リンクである。それ以外の全てのリンクは因果リンクである。この場合、各セルは１つのＴＩＰだけを有しているが、それはＩｎｔｅｒｒｕｐｔＰｏｒｔの動作を無視しているからである。セルが複数のｇｅｎｅｒａｌＰｏｒｔとｆｕｎｃｔｉｏｎＰｏｒｔを有している場合、より多くの実行リンクがｃａｕｓａｌｎｅｔ内に現れることになる。
【０１８９】
因果リンクＸ→ＹまたはＹ・→ＹがポートＡＬＬＥＯＰ内で発生し、イベントインスタンスＸ（ｔ）またはＸがｃａｕｓａｌｎｅｔ内で発生した場合、ＹのイベントインスタンスＹ（ｔ＋τ）は特定の遅延τ＞０の後にｃａｕｓａｌｎｅｔ内でかならず発生する。因果リンクＸＣ（Ｘ，Ｙ）→ＹまたはＸＣ（Ｘ，Ｙ）・→ＹがポートＡＬＬＥＯＰのグラフまたはポートＡＬＬＥＯＰの文字による記述内の句Ｃ（Ｘ，Ｙ）？（）｛Ｘ→Ｙ｝またはＣ（Ｘ，Ｙ）？（）｛Ｘ・→Ｙ｝内で発生する場合、ＹのイベントインスタンスＹ（ｔ＋τ）は条件Ｃ（Ｘ，Ｙ）が時刻（ｔ＋τ）でｔｒｕｅの場合にだけ特定の遅延τ＞０後にｃａｕｓａｌｎｅｔ内でかならず発生する。これは、セクション５．５で説明したように、（ｉ）セルによって実行される任意のｐｔｈｒｅａｄとプロトコルは割り込み不可能であって、（ｉｉ）ｐｔｈｒｅａｄとプロトコルの起動は自動的（セルの外部のプログラムによってスケジュールされていない）であって、（ｉｉｉ）システム障害、デッドロック、またはライブロック（システムの一部がデッドロックしている）がない限りプログレスが保証されているためである。一般的な場合、デッドロックとライブロックが無いことを証明しなければならない。
【０１９０】
自己監視システム、ＳＭＳはアプリケーションのｃａｕｓａｌｎｅｔがそのＡＬＬＥＯＰから逸脱した時にはアラートを発生するように設定されていてもよい。また、ＡＬＬＥＯＰノードの正規表現としてイベントパターンを定義することによってアラート状態を指定してもよい。したがって、イベントＹがＸ→ＹとＸ・→Ｙ内の指定された上限τ後に発生しない場合、ＳＭＳはエラーアラートを発行することになる。遅延の指定された上限後にイベントＹが発生した場合、ＳＭＳは切迫したエラーアラートを発行することになる。通常の動作条件下では、図６ＡのＡＬＬＥＯＰ内の各イベントはその事前条件と事後条件とが満たされ、最下部のノードに対応しているイベントがいったん発生した場合かならず発生し、そうでない場合、アラートが発生する。
【０１９１】
セクション７で説明したように、ｃａｕｓａｌｎｅｔ内のイベントは、アプリケーションが実行（ｒｕｎ）中でイベントがアプリケーション内で発生している時に、アプリケーションの動作と並行してイベントビルダーセル（ｅｂセル）と呼ばれる特定のセルによって動的にインストールされる。拡大しているｃａｕｓａｌｎｅｔ内のイベントパターンはイベント分析セル（ｅａセル）によって分析される。事前に指定されたアラート条件が拡大しているｃａｕｓａｌｎｅｔ内で発生した場合、そのパターンに関連付けられているｅａセルはアラートを生成することになる。ＳＭＳ構造はＡＬＬＥＯＰで指定されているプログレスからのどのような逸脱も検知してアラートを発行するように設定されていてもよい。ＳＭＳは、ｅａセルの選択されたｇｅｎｅｒａｌＰｏｒｔとアプリケーション内の適切なセルのｉｎｔｅｒｒｕｐｔＰｏｒｔとの間の経路を設定し、これらのポートに対してＴＩＰを定義することによって、拡大しているｃａｕｓａｌｎｅｔ内で動的に認識されたパターンに基づいてアプリケーション内の進行中の計算に影響するように設定されていてもよい。
【０１９２】
２．１．６．コメント
ＴＩＰ実行における非決定論：別個のセル内のＴＩＰ実行（ｒｕｎ）は互いに同期していない。信号配信イベントにも同期していない。ポートのＴＩＰはポートの親セルがポートをポーリングした時にそのポートに配信信号が存在する場合にだけ実行され、それ以外はポートはスキップされる。セルの異なるポートに信号が到着する順序を予測することはできない。したがって、セルがそのポートでＴＩＰを実行する順序は予測できない。そのため、セルがそのポートの１つに配信される信号をいつ検知してそれに応答するかを予測できない。１つのポーリングサイクルにおいてポートで検知し損なった信号は次のポーリングサイクルでかならず検出されるので、信号がポートに配信された後、セルが信号に応答する限界を設定することが可能で、ΔＣmaxがセルＣのポーリングサイクルにおいて保留中のメッセージのある全てのポートをサービスするのに必要な最長時間である場合、この限界は＜２ΔＣmaxである。これが、ＴＩＣＣＴＭ−Ｎｅｔｗｏｒｋｓに固有の非決定論の原因である。
【０１９３】
ＣＰＵの共有：図５に示しているネットワークは少なくとも３つのＣＰＵが実行（ｒｕｎ）に必要である。信号をＢｉｌｌとＢｅｎに送信した後、環境Ｅはその動作をサスペンドして、そのＣＰＵを解放してもよい。Ｍｅｅｔｉｎｇが信号をＢｉｌｌとＢｅｎから受信した時に、使用可能な使用されていないＣＰＵ内で自動的に起動し、後でＥが信号をＢｉｌｌとＢｅｎとから受信した時に、同様にサスペンドしていた動作を任意の使用可能な使用されていないＣＰＵ内でレジュームしてもよい。一般に、ネットワークを実行（ｒｕｎ）するのにＣＰＵの数は少なくとも１プラス並列に実行（ｒｕｎ）されるセルの最大数である。セルがその動作をサスペンド／レジュームするようにプログラムされている場合、ＣＰＵは断続的に実行（ｒｕｎ）されるセルの間で切り替えられる。
【０１９４】
プログレス：図６のダイアグラムにおいて、ｐｔｈｒｅａｄ、ｐｌａｙ、ｗｏｒｋ、およびｍｅｅｔは無条件で常に中止されると仮定されているという暗示的な仮定がある。この仮定の下で、アプリケーションにはデッドロックやライブロックが無く、ミーティング同期がゲームの各繰り返しで発生する。セクション６で正式な証明メソッドを導入する。食事をする哲学者の例における状況を考え、実装にデッドロックとライブロックが無いことを保証するために予防策が講じられており、計算のリファイン構造がこの保証の証明可能性において役割を果たす。
【０１９５】
ＡＬＬＥＯＰとＦＳＰ：前述のように、ＡＬＬＥＯＰのノードとＴＩＰのトレースとはイベントクラスであって、ＡＬＬＥＯＰ内のループが取り除かれた場合にリンクが半順序付けを指定する。ただし、図６Ａでループしているリンクが取り除かれた場合、ＡＬＬＥＯＰは格子になる。これは特別な場合である。前述のように、ＡＬＬＥＯＰは状態と遷移を表さない。しかし、ＡＬＬＥＯＰによってモデル化されたアプリケーションの状態図の状態の数が有限の場合、ＡＬＬＥＯＰはある意味でＦＳＰと同等でなければならない。そのようなＡＬＬＥＯＰを有限ＡＬＬＥＯＰと呼ぶ。有限ＡＬＬＥＯＰ内の全ての可能性のあるチェーンの集合は正規集合である。
【０１９６】
有限ＡＬＬＥＯＰのアブストラクションと見なされるＦＳＰ：ＡＬＬＥＯＰ（２．１１）から（２．１４）において、セルとセル内で実行されるｐｌａｙ（）、ｗｏｒｋ（）、およびｍｅｅｔ（）にだけ注目し、信号交換イベントと信号検知動作とを無視したとする。すると、ＡＬＬＥＯＰ（２．１１）から（２．１４）からは、実装の以下のＦＳＰの記述が得られる。
【０１９７】
Ｅ＝［（ｒｅａｄｙＴｏＳｔａｒｔ→［ＢＩＬＬ｜｜ＢＥＮ］）｜（ｉｎｔｅｒｒｕｐｔ→ＳＴＯＰ）］；
ＢＩＬＬ＝ｐｌａｙ→ｍｅｅｔ→ＢＩＬ、ＢＥＮ＝ｗｏｒｋ→ｍｅｅｔ→ＢＥＮ  （２．１）
Ｅは割り込み後に停止する。これは、ＡＬＬＥＯＰには示されていないが、ＣＩＰに指定されている。それをここであえて含めている。ＦＳＰの慣例により、ＦＳＰ同期はｍｅｅｔとＥで発生する。これはＴＩＣＣＴＭでは調和と呼ばれる。ＦＳＰはＴＩＣＣＴＭパラダイムで使用される場合、同期と調和を区別しない。また、アクションがそれらの同期特性に基づいて名前が変更されていない限り、ＦＳＰは別個のアクション（つまり異なる名前のアクション）の時間同期を指定する単純な枠組みを有していない。
【０１９８】
セルは複数のｆｕｎｃｔｉｏｎＰｏｒｔ、ｇｅｎｅｒａｌＰｏｒｔ、およびｉｎｔｅｒｒｕｐｔＰｏｒｔを含んでおり、アクションが条件付きの場合、メッセージが交換され、ＴＩＰは複雑になる（セクション４で説明したように）。ＡＬＬＥＯＰに対応するＦＳＰの記述も複雑になることになる。しかしながら、固定された有限の数のポートを備えている任意のアプリケーションＡＬＬＥＯＰはその同等のＦＳＰ指定を含むようにアブストラクト化することができる。したがって、各アプリケーションの固定された有限の数のポートを備えているＡＬＬＥＯＰは有限ＡＬＬＥＯＰである。
【０１９９】
ＦＳＰの対応する有限ＡＬＬＥＯＰへの逆変換と実装とは困難であるが、それは（ｉ）ＦＳＰは同期と調和との区別を行わない、(ii)状態の間の通信リンクを識別する、または（ｉｉｉ）トランザクションの概念を導入するためである。たとえば、（２．２７）のＦＳＰはｍｅｅｔの後にＥがＢｉｌｌとＢｅｎを通した同期して調和した通信によってゲームの終了を通知されることを指定しない。ここでは、ＦＳＰには現れない隠れた状態（ポートとエージェントの状態）が存在する。これは、ＦＳＰにはポート、エ―ジェント、トランザクション、経路、およびプロトコルの概念が無いために発生する。ＡＬＬＥＯＰのＦＳＰへのアブストラクションとＦＳＰのＡＬＬＥＯＰへのリファインについてさらにコメントするためにこれらを十分には調べていない。この説明において示唆したＡＬＬＥＯＰとＦＳＰとの間の関係は重要であり、さらに追求しなければならない。
【０２００】
有限ＡＬＬＥＯＰの構造にだけ依存している全ての証明はＦＳＰ証明の簡潔さを有することになる。ユーザは証明すべきＣＴＬ表明を定義し、また証明探索を導く表明を提供してもよい。システムはユーザによって提供された各表明が所与の実装についてそれを受け入れる前に有効であることを検証する。
【０２０１】
ＮＦＳＰ証明：計算で使用される変数の値に依存しているＡＬＬＥＯＰ証明にはＮＦＳＰ（非ＦＳＰ）証明方法が必要なことがある。そのようなＮＦＳＰ証明にはＡＬＬＥＯＰの構造上での帰納的推論が必要なことがある。セクション６でＦＳＰとＮＦＳＰの証明の単純な例を説明する。計算中にネットワークが動的に拡張するアプリケーションについては、そのＡＬＬＥＯＰは、潜在的に無限の数のＡＬＬＥＯＰノードを備えている文脈依存で一般的な再帰構造を含んでいるＮＦＳＰ  ＡＬＬＥＯＰのことがある。例をセクション６．７に示している。
【０２０２】
次の例は［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］に記載されている「話すことと痒がること」の拡大版である。ここでは、非決定的ガード、並行性、カプセル化、隠蔽、および調和の使用を説明することを目的としている。
【０２０３】
２．２．話すことと痒がること：カプセル化、並行性、および調和
ある人が同時に話して痒がる。［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］においては、１人だけが存在し、その人がタイムスライスされた並行性において、話し痒がる。２人が存在するこの例の一般化版を考え、かれらの間で会話が行われ、各々が話しながら断続的に掻く。このスキームは３人以上に一般化することができる。秩序のある会話は２人以上が同時にしゃべらない時に維持される。この例は、図４に紹介されているｖｉｒｔｕａｌＭｅｍｏｒｙを備えているＤａｓ経路を使用する。
【０２０４】
2012506076.tif 000008
【０２０５】
図７：２人が話し痒がる例
ネットワークを図７に示している。Ｐ０とＰ１は２人の人である。各人Ｐｊ、ｊ＝０，１は合成セルであって、１つの会話セルＣｊと１つの痒がるセルＩｊとを含んでいる。これら２つのセルは各人内の別個のＣＰＵ内で並列に実行（ｒｕｎ）される。各合成セルは隠された内部接続を有しており、外部ポートへの接続を有しているものもある。まず、２つのカプセル化されているセルに対して内部と外部の接続とそれらが対応しているネットワークアクティビティを考える。
【０２０６】
外部接続：ｊ＝０，１について、経路［Ｃｊ．ｆ０，Ｐｊ．ｆ０，ａ１，ａ０，Ｅ．ｇ１］が存在する（図７を参照）。ここで、ポート[Ｐ０．ｆ０，Ｐ１．ｆ０]はポートグループを構成し、ａ１は同期信号を[Ｐ０．ｆ０，Ｐ１．ｆ０]に配信し、Ｅ．ｇ１にａ０を通して[Ｐ０．ｆ０，Ｐ１．ｆ０]からの調和信号を配信する。同様に、Ｅ．ｇ０はエージェントを通してポートグループ［Ｐ０．ｉ，Ｐ１．ｉ］のＩｎｔｅｒｒｕｐｔＰｏｒｔに接続されており、今度はポートグループ［Ｐ０．ｉ，Ｐ１．ｉ］は（Ｃ０．ｉ，Ｃ１．ｉ）にそれぞれ接続されている。Ｅはこの経路を使用してセルＣｊ、ｊ＝０，１を起動する。経路［Ｃｊ．ｆ２，Ｐｊ．ｆ２，Ｐｉ，ｇ２，Ｃｉ，ｇ２］、ｉ，ｊ＝０．１、ｉ≠ｊが存在し、Ｃｊ．ｆ２とＣｉ．ｇ２との間の通信を可能にしている。同様に経路［Ｃｊ．ｆ３，Ｐｊ．ｆ３，Ｐｉ．ｇ３，Ｃｉ．ｇ３］はＣｊ．ｆ３とＣｉ．ｇ３との間の通信を可能にしている。
【０２０７】
内部接続：Ｐｊ．ｇはポート、Ｉｊ．ｉへの内部接続を有している。Ｐｊが起動すると、この接続を使用してＩｊを起動する。他の内部接続はＰｊ．ｇＯ⇔Ｉｊ．ｆ０とＰｊ．ｇ１⇔Ｉｊ．ｆ１である。ＣｊとＩｊとはこれらの２つの接続を使用してそれらの動作を調和させる。
【０２０８】
隠蔽：カプセル化されているセルの外部ポートにリンクされているポートとエージェントだけが外界からアクセス可能である。カプセル化に対して内部の経路は外界から隠されており、これを隠蔽と呼ぶ。
【０２０９】
ネットワークアクティビティ：環境Ｅは、割り込み信号をポートグループ［Ｐ０．ｉ，Ｐ１．ｉ］のポートにブロードキャストすることによって、会話セルＣｊ、ｊ＝０、１を起動する。いったん起動すると、セルは初期化し、割り込み信号の受信に肯定応答し、それからそれらのポートのポーリングを開始する。初期化中に、各セルＣｊは割り込み信号をＣｊ．ｇを通してＩｊ．ｉに送信することによって痒がるセルＩｊを起動する（図７を参照）。これによって、両方の痒がるセルは自身のそれぞれの初期化を実施後にポーリングを開始する。会話セルの起動後に、Ｅは無作為に選択された２ビット信号［ｂ０，ｂ１］をポートグループ［Ｐ０．ｆ０，Ｐ１．ｆ０］のポートにブロードキャストする。これらのビットに対する制限は両方が０や１にならないことである。エージェントａ１（図７を参照）はビットｂ０＝１（ｂ１＝１）の場合にだけ配信信号をＰ０．ｆ０（Ｐ１．ｆ０）に送信し、それ以外の場合は送信しない。
【０２１０】
１人がポートＰｊ．ｆ０で信号を受信すると、信号はＣｊ．ｆ０に進む。Ｃｊがこの信号を検知すると、話し始める。ｂ０とｂ１は両方が１になることはないので、２人は同時に話し始めることはできない。１人が話している時に、他方の人のセルはそのポートをポーリングし、おそらく話を聞く。話し始める前に、Ｃｊは信号をＩｊ．ｆ０にＣｊ．ｇ０を通して送信する（図７を参照）。Ｉｊがこの信号を検知すると、断続的に掻き始め、Ｃｊが話している間は、ブール変数Ｉｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅの両方がｔｒｕｅであるかどうかに基づいて断続的に掻き続ける。Ｉｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅの真理値は、無作為に真理値Ｉｊ．ｒａｎｄｏｍ（）によって各掻くサイクルで設定される。したがって、人は話すセッションを通して常に掻いていないかもしれない。ここでは、掻くことは常に話す間隔よりもはるかに短い間隔でだけ行われるという仮定がある。掻くセルと会話するセルとは並列に動作するので、人が話し始める時間点と掻き始める時間点とは互いに同期していないが、それらによって実施されるアクションは並列に発生する。ここでは非同期状態は、２ギガヘルツのＣＰＵでは数百ナノ秒よりも長くはない。
【０２１１】
話した後で、Ｃｊは初めて信号を経路Ｃｊ．ｇ１⇔Ｉｊ．ｆ１を通して送信する。これによって、Ｉｊが掻くことをやめるように通知する。それからＣｊは２つのことの一方を行い、それは（ｉ）Ｃｉ．ｆ２、ｉ≠ｊに経路［Ｃｊ．ｇ２，Ｐｊ．ｇ２，Ｐｉ．ｆ２，Ｃｉ．ｆ２］（図７を参照）内のポートを通して信号を送信してＰｉに会話を継続するために話し始めるようにアドバイスするか、（ｉｉ）Ｃｉ．ｆ３、経路［Ｃｊ．ｇ３，Ｐｊ．ｇ３，Ｐｉ．ｆ３，Ｃｉ．ｆ３］内のポートを通して信号を送信して会話を中止させるかの一方である。これらの排他的な信号が２つのｆｕｎｃｔｉｏｎＰｏｒｔ、Ｃｉ．ｆ２とＣｉ．ｆ３とで会話を継続または中止するために使用される方法を以下で説明する。
【０２１２】
以下のＴＩＰの１つが（∃（ｆ）（ｆ＝（Ｃｉ．ｆ２｜Ｃｉ．ｆ３））ｆ：ｍＲ？（））の形態の非決定的ガードを使用する。記号「｜」は選択肢を指定する。ここで、各セルＣｉはこのガードをそのポーリングサイクル毎に評価する。ガードはガードで指定されている選択肢の中のポートの１つがそれに対して配信された信号を有している時にだけｔｒｕｅと評価される。ガードのポートに配信される信号は非決定的ガードが正常に動作するように排他的でなければならない。信号がＣｉ．ｆ２で検知された場合、会話は継続し、信号がＣｉ．ｆ３で検知された場合、会話は中止される。会話が中止された場合、信号は、ポートがその信号の送信の準備ができている場合に、Ｃｉ．ｆ０をとしてＥ．ｇ１に返信される。Ｃｉ．ｆ０は、以前に信号をエージェントａ１を通してＥ．ｇ１から受信している場合にだけ、その信号の送信の準備ができている（図７を参照）。したがって、Ｅからの信号を受信したセルだけがそれに応答する。調和がここで発生するが、それはこの点で、エージェントａ１が信号を以前に信号を配信したポートから受信すると予測しているからである。ａ１がこの信号をＥ．ｇ１に配信すると、Ｅに会話が中止されたことを通知することになる。その点で、Ｅは、第２の割り込み信号をＩｎｔｅｒｒｕｐｔＰｏｒｔ、Ｃｊ．ｉ、ｊ＝０，１に送信することによって、他の会話セッションを開始したり、ゲームを中止したりすることができる。Ｃｊは自身を停止する前に割り込み信号をＩｊ．ｉに送信することによって（図７を参照）Ｉｊを中止する。開始と中止のプロセスは以下のＴＩＰには示していない。
【０２１３】
各人のＣｅｌｌは以下のポーリングサイクルを有している。
Ｃｊ：ｐｏｌｌｉｎｇ（）＝［Ｃｊ．ｆ０：ｍＲ？（）→（∃（ｆ）（ｆ＝（Ｃｊ．ｆ２｜Ｃｊ．ｆ３））ｆ：ｍＲ？（）
→Ｃｊ：ｐｏｌｌｉｎｇ（）］
Ｉｊ：ｐｏｌｌｉｎｇ（）＝［Ｉｊ．ｆ０：ｍＲ？（）→Ｉｊ：ｐｏｌｌｉｎｇ（）］
【０２１４】
Ｃｊが会話を開始し、会話を継続するために信号をＣｉに送信したと仮定する。この信号の送信後、Ｃｊは前述のポーリングサイクルのようにそのポーリングを開始し、おそらくは同時に他の人の話を聞く（聞くプロセスはこの実装には含まれていない）。Ｃｊは会話が継続している間に複数のポーリングサイクルを経ることもある。これによって、Ｃｊ．ｆ０で受信された信号が繰り返し検知される。会話が継続する限り応答は送信されないため、図１に示しているように、Ｃｊ．ｆ０での信号の検知は検知のたびに成功する。したがって、Ｃｉが話しをしている間、Ｃｊも話しを始めようとする。これを防止するために、Ｃｊ．ｆ０で配布信号を検知した後は即座にＣｊはＣｊ．ｆ０．ｉｎｐｕｔ＝φと設定する。これによって、Ｃｊ．ｆ０での信号が繰り返し検知されることが防止される。ステートメントＣｊ．ｆ０：ｓｕｓｐｅｎｄ（）を使用して防止する。サスペンドはポートの状態を変化させないため、適切な場合には、応答はサスペンドされたポートを依然として通して送信されることになるかもしれない。
【０２１５】
この前提と以下のコメントによって、読者は以下で説明するＴＩＰを理解できるはずである。
【０２１６】
人Ｐｊ，ｊ＝０，１についての話す部分についてのＴＩＰ。
Ｃｊ．ｆ０：ｍＲ？（）｛Ｃｊ．ｆ０：ｓｕｓｐｅｎｄ（）；／／これによってＣｊ．ｆ０の位置での信号が再度検知されるのを防ぐ
Ｃｊ．ｇ０：ｐＲ？（）＊｛Ｃｊ．ｇ０：ｓ（）；｝／／掻き始めるために信号をＩｊ．ｆ０に送信
Ｃｊ：ｔｈｉｎｋ（）．ｔａｌｋ（）；
Ｃｊ：ｇ１：ｐＲ？（）＊｛Ｃｊ．ｇ１：ｓ（）；｝／／掻くのをやめるために信号をＩｊ．ｆｉに送信
／＊会話を継続するためにＣｉにＣｊ．ｇ２を通して信号を送信するか、会話を中止するためにＣｊ．ｇ３を通して信号を送信する。対話が中止されると、Ｅに準備ができていればＣｊ．ｆ０を通してそれを知らせる＊／
Ｃｊ：ｃｏｎｔｉｎｕｅ？（）｛Ｃｊ．ｇ２：ｓ（）；｝
ｅｌｓｅ｛Ｃｊ．ｇ３：ｓ（）；Ｃｊ．ｆ０：ｐＲ？（）｛Ｃｊ．ｆ０：ｓ（）；｝｝｝
（∃（ｆ）（ｆ＝Ｃｊ．ｆ２｜Ｃｊ．ｆ３）ｆ：ｍＲ？（）｛／／この点で、このガードはＣｊ．ｆ２とＦｊ．ｆ３の両方で失敗する
ガードは、Ｃｉ．ｆ２またはＣｉ．ｆ２、ｉ≠ｊで成功する
ｓｅｌｅｃｔＯｎｅ｛／／ｓｅｌｅｃｔＯｎｅはトップダウンスキャンにおいて第１のｔｒｕｅの条件を選択する
（ｆ＝Ｃｊ．ｆ２）？（）｛Ｃｊ．ｆ２：ｓ（）；／／Ｃｉ．ｇ２、ｉ≠ｊに応答
Ｃｊ．ｇ０：ｐＲ？（）＊｛Ｃｊ．ｇ０：ｓ（）；｝／／掻き始めるために信号をＩｊ．ｆ０に送信
Ｃｊ：ｔｈｉｎｋ（）．ｔａｌｋ（）；
Ｃｊ：ｇｌ：ｐＲ？（）＊｛Ｃｊ．ｇｌ：ｓ（）；｝／／掻くことを止めるために信号をＩｊ．ｆ１に送信
Ｃｊ：ｃｏｎｔｉｎｕｅ？（）｛Ｃｊ．ｇ２：ｓ（）；｝
ｅｌｓｅ｛Ｃｊ．ｇ３：ｓ（）；
Ｃｊ．ｆ０：ｐＲ？（）｛Ｃｊ．ｆ０：ｓ（）；｝｝｝
（ｆ＝Ｃｊ．ｆ３）？（）｛Ｃｊ．ｆ３：ｓ（）；Ｃｊ．ｆ０：ｐＲ？（）｛Ｃｊ．ｆ０：ｓ（）；｝｝｝｝  （２．２８）
【０２１７】
人Ｐｊ，ｊ＝０，１についての掻く部分についてのＴＩＰ。
Ｉｊ．ｆ０：ｍＲ？（）｛／＊以下では、Ｉｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅとはｔｒｕｅに初期化される。したがって、信号がＩｊ．ｆ０で検知されるとＩｊは掻き始め、ｗｈｉｌｅループ内にある間はＩｊ．ｉｔｃｈｉｎｇがｔｒｕｅである限り掻くことを継続する。しかし、ｗｈｉｌｅループの内側で、Ｉｊ．ｒａｎｄｏｍ（）は繰り返しごとに無作為の真理値をＩｊ．ｉｔｃｈｉｎｇとＩｊ．ｃｏｎｔｉｎｕｅとに割り当てる、したがって、掻くことは、Ｃｊが話している間を通して発生しないことがあるし、たとえ発生しても断続的になる。ここでは掻く間隔は離す間隔に比べてはるかに短いと仮定する。この実装は成功することが要件である。＊／
ｗｈｉｌｅ（Ｉｊ．ｃｏｎｔｉｎｕｅ？（））｛Ｉｊ：ｉｔｃｈｉｎｇ？（）｛Ｉｊ：ｓｃｒａｔｃｈ（）；｝
Ｉｊ．ｉｔｃｈｉｎｇ＝Ｉｊ．ｒａｎｄｏｍ（）；／／これが掻くことを中止させることがある
Ｉｊ．ｃｏｎｔｉｎｕｅ＝Ｉｊ．ｒａｎｄｏｍ（）；／／これがｗｈｉｌｅループを中止させることがある
Ｉｊ．ｆｌ：ｍＲ？（）｛Ｉｊ．ｃｏｎｔｉｎｕｅ＝ｆａｌｓｅ；｝｝／＊これがループを停止させる＊／
／＊ここでは２つの場合が存在し、（ｉ）Ｉｊ．ｒａｎｄｏｍ？（）がＩｊ．ｃｏｎｔｉｎｕｅをｆａｌｓｅにするか（ｉｉ）ｗｈｉｌｅループ内のＩｊ．ｆ１での信号の検知がｆａｌｓｅにする。以下の検知は両方の場合に成功するが、これは応答信号がＩｊ．ｆ１を通してまだ送信されていないためである。以下では、Ｉｊは（ｉ）の場合にだけ信号をＩｊ．ｆ１で待つことになる。＊／
Ｉｊ．ｆ１：ｍＲ？（）＊｛Ｉｊ．ｆ０：ｓ（）；／＊Ｃｊ．ｇ０に応答＊／
Ｉｊ．ｆｌ：ｓ（）；／／Ｃｊ。ｇ１に応答
／／以下によって、信号が再びＩｊ．ｆ０で検知された時に掻くことを再び開始することができる。
【０２１８】
Ｉｊ．ｉｔｃｈｉｎｇ＝Ｉｊ．ｃｏｎｔｉｎｕｅ＝ｔｒｕｅ；｝｝  （２．２９）
【０２１９】
会話は信号がＰ０．ｆ０またはＰ１．ｆ０のいずれかで受信されるたびに開始される。掻くことは、会話が開始されるか断続的に継続するたびに開始される。どれだけ正しく調和が発生するかを見つけることは読者にお任せする。ネットワークは聞くことを提供しない。聞くことを提供するためには、第３の聞くセルを会話セルとの適切な調和を伴ってカプセル化の内部に導入しなければならない。
【０２２０】
２．３．見通し
ＡＬＬＥＯＰはＴＩＣＣＴＭネットワークによって提供された構造情報を統合し、ＴＩＣＣＴＭネットワーク、ＴＩＰ、およびポーリングサイクル内の暗示的な並列計算、同期、および調和の制御構造を明示的にし、タイムマップで仮定されている時間点の半順序付けを定義しなければならない。それらは機械処理からのアクセス可能な形態で統合された情報を示す。人間にとって、それらは、経路は何をするのか？、ＴＩＰとは何か？、ポーリングサイクルとは何か？、通信パターンとは何か？のような質問に答える。これらの質問に対する答えは、経路は信号のポート間の通信を可能にし、通信の同期／調和を実施し、交換されるメッセージへのアクセスを可能にし、信号受信セル内で並列計算を起動する、のようになる。ＴＩＰはメッセージを処理／生成し、信号を送信／受信し、メッセージ処理／生成に使用されるメソッドを通信から分離する。ポーリングサイクルはセルがそのポートでのＴＩＰ実行に対応する順序を指定する。通信パターンは、関連する条件に基づく代替の因果チェーンでの選択と、信号配信による並列タスクの起動（フォーク）によって発生する。したがって、イベントパターンは、並列計算における分岐、フォーク、およびジョインの制御構造のパターンを定義する。そのようなパターンは、正規文法やＡＬＬＥＯＰノードを終端記号として使用する他の種類の文法を使用して記述することができる。しかし、ＡＬＬＥＯＰはセルによって実施される計算の詳細を指定しない。各ＡＬＬＥＯＰノードはイベントクラスを表す。ＡＬＬＥＯＰノードの複数のインスタンスはｃａｕｓａｌｎｅｔにおいて発生することがある。
【０２２１】
同じ逐次プログラムが異なるデータ構造定義を使用して実行（ｒｕｎ）されるように、アプリケーションに対するｐｔｈｒｅａｄの同じ集合が同じアプリケーション用の異なるＴＩＣＣＴＭネットワーク内で並列に実行されることがある。したがって、逐次プログラムのデータ構造がデータ操作のアブストラクションであるように、データＴＩＣＣＴＭネットワークを並列計算の制御構造のアブストラクションと見なすことができる。
【０２２２】
トレースはＡＬＬＥＯＰに情報を追加する。トレースは仮想時間点を仮定し、それらをＡＬＬＥＯＰ指定に整合するようにＡＬＬＥＯＰで発生するイベントクラスとタイムマップとに関連付ける。したがって、それらはＡＬＬＥＯＰ内では暗示的なタイミングを明示的にする。トレースは事前／事後条件をアクションに関連付け、存在する場合は交換されるメッセージを特徴付けることによってＴＩＰによって実施される計算の意味も定義する。人間にとって、それらは、アクションは何を計算するのか？、アクションは正しく実行されているのか？、どのようなイベントが同期して発生するのか？、イベントは調和しているのか？のような質問に答える。これらの質問に対する答えは、アクションはアクションが成功するようにその実行前に成立していなければならないものを特徴付ける事前条件と、実行が終了した後で成立しなければならないものを特徴付ける事後条件とによって定義されている、のようになる。これらの事前／事後条件は、アクションによって処理／生成されるメッセージの特徴を含んでいてもよい。アクションの実装は、その事前／事後条件の両方がアクションが実行されるたびに適切な瞬間に満たされる場合に正しい。同一の仮想時間点を備えているイベントは同期して発生する。同一の仮想時間点を備えているメッセージディスパッチイベントは調和したイベントである。
【０２２３】
ｃａｕｓａｌｎｅｔはアプリケーション内の通信イベントの発生とそれらの同期／調和特性にだけに注目し、全ての条件とアクションを無視したトレースのアブストラクションである。セクション７で説明するように、イベント分析セル（ｅａセル）は、アプリケーション内の拡大しているｃａｕｓａｌｎｅｔを、ｃａｕｓａｌｎｅｔがアプリケーションの実施中の動作にほとんどまたは全く干渉せずにイベントビルダーセル（ｅｂセル）によって生成されている時に、アプリケーションと並列に分析してもよい。ｅａセルによって実施される分析は、事前に定義されたイベントパターンやｅａセルによって動的に学習されたイベントパターンに基づいていてもよい。ｅａセルによって認識されるパターンをアプリケーション内で実施される計算を導くために使用することさえ可能である。
【０２２４】
アプリケーションの半順序ドメインは、そのアプリケーションが実行（ｒｕｎ）される可能性のある全ての方法においてＳＭＳが生成できる全ての可能性のあるｃａｕｓａｌｎｅｔの表現に過ぎない。たまたま、このドメインはドメインからそれ自体に対する単調連続マッピングと共にＴＩＣＣＴＭ−Ｐｐｄｅの表示的意味論を定義するのに十分である。これは、論理は計算に必要なく、適切な隠蔽と代替規則とを備えている通信で十分であるというπ算法の視点と整合している。論理は、計算の正しさを定義し証明するためにのみ必要である。それは、トレースによって提供される情報がＣＴＬ表明を証明するために必要なためである。ＥＣＴはトレース内の情報を認識し、ポーリングサイクルとＥＣＴネットワークはポートＥＣＴの逐次／並列の組み合わせを実装において提供する。それらはＣＴＬ表明の提供に使用される。セクション６に例を示す。
【０２２５】
アプリケーションＩからＩＩＩに示した実装とセクション６に示した証明とは以前に概説した見方を示している。重要なことは、ＡＬＬＥＯＰはシステムによって実装の仕様から容易に自動的に導出されることである。トレースはアクションに対する事前／事後条件がシステムに知らされている場合、ＡＬＬＥＯＰから容易に自動的に導出される。ＴＩＣＣＴＭ−Ｐｐｄｅはアクションのための事前／事後条件を作製する対話型のツールを提供する。ＴＩＣＣＴＭ−Ｐｐｄｅの４つの特徴がこれを可能にしており、それらは（ｉ）ポートが付属しているセル、エージェントを備えている経路、および任意採用のｖｉｒｔｕａｌＭｅｍｏｒｙについてのＴＩＣＣＴＭネットワークの構成、（ｉｉ）ＴＩＰ、ポーリングサイクル、ｐｔｈｒｅａｄ、およびプロトコルについての計算の構成、（ｉｉｉ）計算と通信との統合：計算を実行する各セルはその通信もＣＣＰを使用するプロトコルを使用してすべて実行する、（ｉｖ）セルの相互分離（セクション３．２で説明）である。
【０２２６】
３．セルと経路の詳細
３．１．付属とチューン
付属とチューンはＴＩＣＣＴＭの特別に優位な性質である。付属しているまたはチューンされたコンポーネントだけが自由に他のデータとメソッドとを共有することができる。したがって、付属しており互いにチューンされているポート、セル、エージェント、およびｖｉｒｔｕａｌＭｅｍｏｒｙは自由に他のメソッドとデータを共有することができる。
【０２２７】
エージェントａに付属しているｖｉｒｔｕａｌＭｅｍｏｒｙを指す時にａ．Ｍを使用し、Ｍに付属しているｉ番目のエージェントを指す時にＭ．ａ［ｉ］を使用し、ｐ．Ｍ＝ｐ．ａ．Ｍと設定し、ここでｐ．ａはｐがチューンされているエージェントである。ブランチまたはｈブランチ（隠れたブランチ）によって互いに接続されているコンポーネントと互いに付属しているコンポーネントだけが経路内で信号を互いに送信できる。図４と５において、ポートはそれらの親セルに付属しており、ブランチによってエージェントに接続されており、エージェントは互いにｈブランチによって接続されている（それらはｈブランチであるがそれは、エージェントの相互接続は経路が動的に修正された時に動的に変更できないためである）。したがって、経路内のエージェントとポートおよびエージェントの対は信号を交換し、セルは信号をそれらのポートに送信することができる。前述のように経路によって信号の転送は所与の時刻において一方の方向にだけ可能で、信号を交換するコンポーネントは常に互いに対してチューンされている。
【０２２８】
チューン：ポートｐをエージェントａにブランチｂによって接続すると、（i）ｐとaの初期状態を設定し、それによってそれらが互いに信号を交換できるようになり、（ｉｉ）ａ．Ｍ＝ｐ．Ｍ内のアドレスとメソッドとをｐに転送して、ｐの状態がＳの時にｐの親セルがｐ．Ｍ内のデータとｐｔｈｒｅａｄにアクセスできるようにすることによってｐがａに対してチューンされる。したがって、ｐをａにチューンすることによって、ｐとその親セルがｖｉｒｔｕａｌＭｅｍｏｒｙ  ａ．Ｍ＝ｐ．Ｍにチューンされる。セルは５〜６個のポートを有しているため、セルはそれに対してチューンされている５〜６個のｖｉｒｔｕａｌＭｅｍｏｒｙを有することが可能で、セルの別個のポートに対して別個のｖｉｒｔｕａｌＭｅｍｏｒｙを有している。２つのエージェントはそれらの初期状態を設定するｈブランチによってそれらを接続することによって互いにチューンされる。
【０２２９】
トランザクションの完了：前述のように、各セル内のポートの循環ポーリングはセルのポートに送信された各サービス要求が検知され応答されることを保証する。セルがサービス要求に応答している間に割り込みをかけられることはない。セルは連続したＴＩＰの実行同士の間でだけ割り込みを検知し応答する。次のサブセクションで説明するセルの分離と共にこれらの特徴が各トランザクションについてトランザクションの完了を保証し、これによって経路のコンポーネントが常に互いにチューンされた状態に維持される。
【０２３０】
３．２．セルの分離
セルはそのポートをポーリングしてポートで定義されているＴＩＰボディを実行することによって計算を実行する。セルは別個の計算ユニット内で並列に動作するために、並列な実行機構を提供し、タイムスライスされた割り込み駆動ｐｔｈｒｅｄ実行は使用しない。ｐｔｈｒｅａｄとプロトコルはセルとそのポートとに一意に関連付けられている。セルの各ポートはｐｔｈｒｅｄを有していてもよく、それに関連付けられている一意のプロトコルを有することになる。セルの分離は以下の２つの特性によって定義されている。
【０２３１】
プライベートおよびローカルｐｔｈｒｅａｄ：ｐｔｈｒｅａｄの実行に、セルはセル内で定義されているデータとプロセスまたはセルに付属しているまたはチューンされているコンポーネントだけを使用する。他のデータやプロセスはそのようなｐｔｈｒｅａｄの実行中には使用されない。特に、オペレーティングシステムはＴＩＰ実行に干渉することはできない。セルに関連付けられているｐｔｈｒｅａｄは任意の他のセルによって実行可能であるが、同じｐｔｈｒｅａｄの複製の各々を自身のプライベートメモリまたは関連付けられているｖｉｒｔｕａｌＭｅｍｏｒｙ内で異なるセルによって並列に実行可能である。ｐｔｈｒｅａｄの実行は、ｐｔｈｒｅａｄを実行するセルの状態を変更できるだけである。セルのこれらの特徴はアクターとπ算法エージェントの特徴と同様である。
【０２３２】
ポートグループ内のポートの親セル（図１９を参照）はポートグループ内のポートの共有ｖｉｒｔｕａｌＭｅｍｏｒｙ内で同時に同じｐｔｈｒｅａｄを実行することができる。そのような実行に、それらは共通の共有変数を使用してもよい。そのような実行（ｒｕｎ）中にメモリ干渉を防止するためにｐｔｈｒｅａｄがどのように構成されるかをセクション６．２で説明する。これらの特徴とプロトコルに関する以下で示す特徴とはＴＩＣＣＴＭ−Ｐｐｄｅ構成に固有である。
【０２３３】
プライベートおよびローカルプロトコル：別個のポートはそれらに対して定義されている別個のプロトコルを有している。セルのポートで定義されているプロトコルは、ポートの親セル以外の任意にセルによって実行されない。プロトコルをそのポートで実行中に、セルはそのポートに接続されている経路上でＣＣＰとプロトコル内の他のアクションステートメントを実行する（セクション７を参照）。プロトコルの実行によって、セルがプロトコル自体で定義されていない他のスレッドやプロセスを実行することはない。経路のコンポーネントで定義されていないデータを使用することもない。別個のセルは別個のプロトコルだけを並列に実行する。
前述のように、ポートグループのポートで定義されているプロトコルのセグメントはセクション７で説明するように、ポートの親セルによって同じグループ対グループ経路（図１９）上で並列に実行される。
【０２３４】
３．３並列バッファリング、並列メッセージ送信、およびモビリティ
必要のない逐次バッファ：例えば第１の要求したサービスに対する応答が受信される前の図１と２のポートＤ．ｆのように、ｇｅｎｅｒａｌＰｏｒｔは第２のサービス要求メッセージをｆｕｎｃｔｉｏｎＰｏｒｔに送信しない。これは、ＴＩＣＣＴＭネットワーク内の全てのｇｅｎｅｒａｌＰｏｒｔとｆｕｎｃｔｉｏｎＰｏｒｔに当てはまる。そのため、ｖｉｒｔｕａｌＭｅｍｏｒｙは２つ以上の保留中のサービス要求メッセージを保持していることはない。各保留中のサービス要求メッセージは応答が検知され応答されるまでそのｖｉｒｔｕａｌＭｅｍｏｒｙ内に保存されている。
【０２３５】
同様に、各応答メッセージはメッセージ受信セルによって検知され使用されるまでｖｉｒｔｕａｌＭｅｍｏｒｙ内に保存されている。ｖｉｒｔｕａｌＭｅｍｏｒｙが２つ以上の応答メッセージを保持していることはない。したがって、各ｖｉｒｔｕａｌＭｅｍｏｒｙは任意の所与の時刻に高々１つのサービス要求と応答を保持ししている。別個の経路に接続されている別個のポートはそれらに関連付けられている別個のｖｉｒｔｕａｌＭｅｍｏｒｙを有することになる。したがって、ＴＩＣＣＴＭネットワーク内のｖｉｒｔｕａｌＭｅｍｏｒｙはサービス要求と応答に対して並列バッファリング機構を提供する。これらの特徴によって、逐次バッファが必要でなくなる。アクターシステムとは異なり、解決しなければならないバッファ競合は存在せず、シリアライザは必要ない。
【０２３６】
並列メッセージ転送：これらのいくつかについては既に説明している。それらをもう一度説明する。（ｉ）各セル自体は他のセルと並列にメッセージ交換に必要なプロトコルを実行し、（ｉｉ）２つの別個の経路が共通のコンポーネントを共有せず、（ｉｉｉ）プロトコルが経路のコンポーネントで定義されていないスレッドやプロセスを実行しないので、点対点経路上にあるかグループ対グループ経路上にあるかに関わらず、別個のプロトコルが相互干渉無しに並列に実行される。
したがって、ＴＩＣＣＴＭネットワーク内のセル間で並列に同時に交換可能なメッセージの数は、アクティブなセルの数とネットワーク内の別個の経路の数とによってだけ制限される。ＣＣＰは経路コンポーネントを他のセルから、そして互いに分離している。
【０２３７】
モビリティ：ポートに接続されている経路は以下の経路要件に違反しない限りモビリティを導入するために動的に変更することが可能である。これらの要件は、（ｉ）ポートは２つ以上の経路には接続されないこと、（ｉｉ）同じセルの２つのポートはポートがポートベクトル内に存在しない限り同じ経路に接続されないこと（セクション４．２とセクション７を参照）、（ｉｉｉ）２つの別個の経路はコンポーネントを共有しないことである。トランザクションの途中で、メッセージの送信先の経路のｆｕｎｃｔｉｏｎＰｏｒｔを経路から接続解除し、異なる送信先のｆｕｎｃｔｉｏｎＰｏｒｔに経路設定することができる。それから新しい送信先ポートの親セルが経路のｖｉｒｔｕａｌＭｅｍｏｒｙ内のサービス要求メッセージを処理し、ｖｉｒｔｕａｌＭｅｍｏｒｙ内に応答メッセージを書き込み、経路を元の送信先ポートに結合し直し、それからその親セルは必要に応じて応答を修正し、それをサービスを要求したｇｅｎｅｒａｌＰｏｒｔに送信する。したがって、応答は常にサービス要求を配信したのと同じ経路を通して返信される。経路に接続されているｇｅｎｅｒａｌＰｏｒｔはトランザクションの途中で動的に変更することはできない。
【０２３８】
分散メモリシステムにおいて、プログラムのモビリティはｖｉｒｔｕａｌＭｅｍｏｒｙの内容全体を分散システム内の他のｖｉｒｔｕａｌＭｅｍｏｒｙに転送することによって達成される。
【０２３９】
３．４．ＴＩＣＣＴＭ、π算法、アクター、およびＣＳＰ
ＴＩＰの実行によって、ｐｔｈｒｅａｄとプロトコルが実行され、セルが互いに相互動作する。セル間の相互動作はπ算法内のエージェントとアクターとの間の相互動作と同様である。アクターとπ算法エージェントのように、ｐｔｈｒｅａｄの実行（ｒｕｎ）はセルの厳密にプライベートな動作である。しかし、５〜６個の際だった違いがある。
【０２４０】
ＴＩＣＣとアクター：アクターシステムにおいて、通信プロトコルはアクターの外部のＯＳメソッドと他のプロセスとを呼び出す。非同期通信には逐次バッファの使用が必要である。シリアライザがバッファ競合の解決に必要である。１つのアクターが送信したメッセージがいつ受信側のアクターに到着するのかを予測することはできない。通信は順序が保存されず、メッセージは送信されたのと同じ順番には送信先に届かない。
【０２４１】
ＴＩＣＣＴＭにおいては、アクターシステムとは異なり、通信は接続指向である。通信は２つのセルの間で経路が両者の間で確立している場合にだけ発生する。セルはメッセージを交換するために自身でプロトコルを実行する。メッセージ送信と配信の時間は、所与の限界によって正確に予測することができる。ＴＩＣＣＴＭ内でのプロトコル実行とｐｔｈｒｅａｄ実行との間の唯一の区別は、プロトコルは宣言を含んでいないことである。したがって、それらは、実行中にデータコンテナを作製／破壊することはできない（データを保持するメモリセルが存在し、セクション５で導入する）。メッセージの送信以外に、プロトコルはアクセス権も配信されたメッセージに対して転送する。プロトコルはセルが実施する計算の制限された形態を定義している。これによって、計算と通信との間の古典的な２分法が排除される。したがって、「統合された計算と通信のための技術」（ＴＩＣＣＴＭ）という名前となる。
【０２４２】
また、アクターシステムとは異なり、ＴＩＣＣＴＭはグループ対グループ通信、自動同期と調和、および動的ＳＭＳ（自己監視システム）に対応している。ＴＩＣＣＴＭによって並列バッファリング機構を使用することによって非同期通信における逐次バッファが必要なくなる。ＴＩＣＣＴＭ−ＰｐｄｅのＳＭＳのように、ＳＭＳをアクターシステム内で定義することはできない。トランザクションへの対応はアクターシステムには本来備わっていない。
【０２４３】
ＴＩＣＣＴＭとπ算法：ＴＩＣＣＴＭのように、π算法内の通信は接続指向である。名前が、既に確立されているリンクを通してπ算法／エージェント間で交換され、リンクは動的には確立できない。経路は信号を送信し、送信先のｆｕｎｃｔｉｏｎＰｏｒｔへの経路の接続は、トランザクションの途中で動的に変更することができる。π算法はトランザクションの概念を使用しない。ＴＩＣＣＴＭにおける経路接続に対する動的な変更とπ算法におけるリンク接続に対する動的な変更とは異なる計算目標を達成するように見える。図３、４および２０に示しているように、経路は分岐し、各々が別個のセルに属している５〜６個の別個のポートへの同じ信号の時間が同期した配信を行う。π算法とは異なり経路はポート、プロトコル、ｖｉｒｔｕａｌＭｅｍｏｒｙ、エージェント、ブランチ、およびｈブランチを備えている構造を有している。また、π算法／エージェントとは異なり、ＴＩＣＣＴＭのセル間の相互動作は正確に時間が設定されている。
【０２４４】
重要な違いは以下のとおりであって、前述のように、経路プロトコルは、通信を、相互動作しているｎｄＦＳＭによって実行され、メッセージを送出するセルによって実行されるチューリング計算［Ｔｕｒｉｎｇ，２０］として定義しており、π算法はそのリンクに対して通信機構を指定していない。実際に、π算法形式を使用して必要な通信機構を指定することはできない。この意味で、π算法は並列計算の全てを指定していない。通信が所与のプリミティブとして仮定される場合にだけπ算法は並列計算を指定する。π算法は同期と調和の機構を有していない。π算法内でＳＭＳを定義することはできない。
【０２４５】
ＴＩＣＣＴＭとＣＳＰ：違いについては既に説明している。それを再度説明する。ｐｔｈｒｅａｄ（ＣＳＰ内の逐次プロセスに対応）は、通信ステートメントを含んでいない。通信プリミティブは逐次プロセス（ｐｔｈｒｅａｄ）にコード化されてない。ＴＩＰだけが通信ステートメントを有している。ＴＩＰは通信を相互動作している逐次プロセス（ｐｔｈｒｅａｄ）から分離している。ＣＳＰチャネルとは異なり、経路は相互動作しているｐｔｈｒｅａｄを遮断しない。また、ＣＳＰチャネルとは異なり、経路はポイント対ポイントとグループ対グループの非同期通信に対応している。ＳＭＳをＣＳＰ内で定義することはできない。
【０２４６】
ｐｔｈｒｅａｄの対ごとの独立：１つのセルサブクラスで定義されているｐｔｈｒｅａｄは、サブクラスインスタンスがセルに付属していたりチューンされていたりしない限り、他のサブクラス内で定義されている他のｐｔｈｒｅａｄを呼び出して実行しない。しかし、並列に実行（ｒｕｎ）されている２つのセルは同じｐｔｈｒｅａｄの複製を自身の別個の実行環境において実行する。１つのセルによって実行されているｐｔｈｒｅａｄは他のセルの状態を変化させることはない。異なるセルによって実行されているｐｔｈｒｅａｄの対は互いに独立した状態を維持する。しかしこれについては１つの例外がある。例外は、ポートグループ内のポートの親セルが共にサービス要求メッセージを送信するか、受信したサービス要求メッセージを共に処理する場合である。これらの場合、ポートグループ内のポートの親セルがそれらの計算を調和させる必要は無い。親セルは、メッセージを保持しているｖｉｒｔｕａｌＭｅｍｏｒｙによって提供される共通のスクラッチパッドを使用してそれを行う。ポートグループ内のポートの親セルによって実行されるｐｔｈｒｅａｄは互いに依存している。それらは併せて検証しなければならない。これによって、ほとんどのｐｔｈｒｅａｄを独立して検証することができるようになる。
【０２４７】
４．ＴＩＰとＴＩＣＣＴＭ−Ｐｐｄｅの詳細
４．１．新規の計算の生成
サービス要求をそのｆｕｎｃｔｉｏｎＰｏｒｔ、Ｃ．ｆに有しているセルＣは自身で受信したサービス要求に対する応答を計算することはできない。この場合、Ｃは応答を計算するために１つまたは２つ以上の他のセル内で新しい計算を生成しなければならない。以下のフォーマットを有しているＴＩＰがこの目的のために使用される。
【０２４８】
Ｃｆ：ｍＲ？（）｛Ｃ．ｆ：ｒ（Ｃ．ｇ）；Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝
ｅｌｓｅ｛Ｃｆ：ｓ（）；｝｝  （４．１）
Ｃ．ｆ：ｓｕｓｐｅｎｄ（）は以下のように定義される。
【０２４９】
（〈Ｃｆ．ｓｔａｔｅ＝Ｓ〉（ｔ０）｝［・→Ｃｆ：ｓｕｓｐｅｎｄ（）（ｔ０）］｛〈Ｃ．ｆ．ｉｎｐｕｔ＝φ〉ｔ１）｝（４．２）
φは空の記号である。これによってＣが次のポーリングサイクルで配信信号をポートＣ．ｆで検知するのを防ぐ。これが、セクション２．２．の話して痒がる例において、異なる文脈で使用されているのを見た。（４．１）において、ｐｔｈｒｅａｄ、Ｃ．ｆ：ｒ（Ｃ．ｇ）≡Ｃｆ：ｍｓｇ（）：ｒ（Ｃ．ｆ，Ｃｇ）はポートｐｏｒｔＣ．ｆにチューンされているｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージのＭｅｓｓａｇｅサブクラスで定義されている。Ｃ．ｆ：ｓｐｗｎ？（）＝Ｃ．ｆ．ｓｐｗｎはＣ．ｆに関連付けられているローカルブール変数である。Ｃ．ｆ．ｓｐｗｎの真理値は、Ｃ．ｆ：ｒ（Ｃ．ｇ）において設定されている。
【０２５０】
ＴＩＰ（４．１）は、ｐｔｈｒｅａｄ、Ｃ．ｆ：ｒ（Ｃ．ｇ）の実行後、メッセージを、Ｃ．ｆ：ｓｐｗｎ？（）の値に依存して、ポートＣ．ｇを通して送出するかポートＣ．ｆを通して送出するかの２つのうちの一方を行う。ｐｔｈｒｅｄ、Ｃ．ｆ：ｒ（Ｃ．ｇ）は、Ｃ．ｆのｖｉｒｔｕａｌＭｅｍｏｒｙ内に応答メッセージを書き込んでブール変数Ｃ．ｆ．ｓｐｗｎ＝ｆａｌｓｅを設定するか、新規のサービス要求メッセージをＣ．ｇのｖｉｒｔｕａｌＭｅｍｏｒｙに書き込んで、Ｃ．ｆ．ｓｐｗｎ＝ｔｕｒｅを設定する。この場合、ＣはＣ．ｇを通してサービス要求を受信するセル内で新しい計算を生成し、ポートＣ．ｆでのそのアクティビティをサスペンドする。Ｃ．ｆのサスペンドによって、Ｃ．ｆでの配信信号が破壊される。したがって、ポーリングは次のポーリングサイクルにおいてＣ．ｆで失敗することになる。Ｃ．ｆのサスペンド後、Ｃは即座に次のポートのサービスに進む。Ｃ．ｆのｖｉｒｔｕａｌＭｅｍｏｒｙ内のデータと実行状態は保存される。Ｃは後でポートＣ．ｇで応答メッセージを検知した時にだけポートＣ．ｇとＣ．ｆとでそのアクティビティを継続する。ただし、（４．２）において、Ｃ．ｆでのサスペンドはＣ．ｆ．ｓｔａｔｅを変更しない。したがって、応答がポートＣ．ｇで受信され、計算がレジュームされると、Ｃ．ｆは応答を返信する準備ができる。
【０２５１】
（４．１）のｅｌｓｅ節のある条件ステートメント、
Ｃ．ｆ：ｓｐｗｎ？（）（Ｃ．ｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝，ｅｌｓｅ｛Ｃ．ｆ：ｓ（）；｝、
は、次のように解釈される。
【０２５２】
ｓｅｌｅｃｔＯｎｅ｛Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝
¬Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｆ：ｓ（）；｝
ｔｒｕｅ｛｝／＊この場合、Ｃ．ｆ．ｓｐｗｎ＝φ＊／｝、
ここで、ｓｅｌｅｃｔＯｎｅはその条件を上から下にスキャンして、ｔｒｕｅと評価される１つを選択する。ｓｅｌｅｃｔＯｎｅには無条件のエスケープ節である最後の節が存在する。したがって、Ｃ．ｆ．ｓｐｗｎ＝φの場合、メッセージは送出されない。この場合は、セルがメッセージを送信するのに必要な条件を満たさない場合に発生する。この場合、Ｃ．ｆ．ｓｐｗｎ＝φを設定したｐｔｈｒｅａｄは、ポートＣ．ｆで受信したメッセージを使用して計算がレジュームされる場合は、Ｃ．ｆ．ｉｎｐｕｔ＝ｓをリセットし、ポートＣ．ｇで受信したメッセージを使用して計算がレジュームされる場合は、Ｃ．ｇ．ｉｎｐｕｔ＝ｓをリセットする。これによって、Ｃが次のポーリングサイクルでメッセージをＣ．ｆまたはＣ．ｇで検知し、セルが要求される条件を満足した後で、メッセージをＣ．ｆまたはＣ．ｇを通して送信することを可能にする（セクション４．１．１を参照）。
【０２５３】
次のポーリングサイクルでメッセージの受信がポートＣ．ｇで検知された場合、Ｃは（４．１）のＴＩＰと同様なボディを使用してＴＩＰを実行し、違いは、Ｃ．ｆ：ｒ（Ｃ．ｇ）の代わりに、今度はＣ．ｇ：ｒ（Ｃ．ｆ）をＣ．ｇで受信したメッセージを使用して実行することであって、ＴＩＰはメッセージ送信の同じパターンを繰り返す。
【０２５４】
Ｃｇ：ｍＲ？（）｛Ｃ．ｇ：ｒ（Ｃ．ｆ）；Ｃ．ｇ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ．ｆ：ｓｕｓｐｅｎｄ（）；｝
ｅｌｓｅ｛Ｃ．ｆ：ｓ（）；｝｝  （４．３）
したがって、応答がポートＣ．ｆを通して返信されるまで必要な回数だけ生成は繰り返され、トランザクションが完了する。トランザクションの完了は、そのような各計算において不可欠である。ここで、Ｃ．ｆ：ｒ（Ｃ．ｇ）＝Ｃ．ｆ：ｍｓｇ（）：ｒ（Ｃ．ｇ，Ｃ．ｆ）はポートＣ．ｆで受信したメッセージのサブクラスで定義され、Ｃ．ｇ：ｒ（Ｃ．ｆ）＝Ｃ．ｇ：ｍｓｇ（）：ｒ（Ｃ．ｆ，Ｃ．ｇ）はポートＣ．ｇで受信したメッセージのサブクラスで定義される。
【０２５５】
各ｆｕｎｃｔｉｏｎＰｏｒｔ、Ｃ．ｆについて、新しい計算を生成可能なｇｅｎｅｒａｌＰｏｒｔ、Ｃ．ｇは一意である。Ｃの他のｆｕｎｃｔｉｏｎＰｏｒｔはＣ．ｇを使用しない。これは、そうしない場合に発生する可能性のあるデッドロックを防止することを意図している。また、Ｃがサービス要求をＣ．ｇを通して送信する時にはいつも、ポートＣ．ｇはそのメッセージを送信する準備ができていることに注意しなければならない。
【０２５６】
Ｃ．ｇがそのサービス要求を送信するセルは、自身が同様に新しい計算を生成することもある。また、Ｃ．ｇはそのサービス要求をｆｕｎｃｔｉｏｎＰｏｒｔグループにブロードキャストすることもある。これによって、計算をネットワーク全体に広げることになる。サービス要求がそのように送信された各セルはそれに応答しなければならず、かならず応答する。最終的に全ての生成されたトランザクションは終了し、応答メッセージがＣ．ｇによって受信される。それから、Ｃ．ｇにおけるこの応答メッセージは、ＣによってＣ．ｆで受信したサービス要求に応答するために（またはもう一度生成するために）使用される。
【０２５７】
４．１．１．選択肢のあるＡＬＬＥＯＰとトレース
以下では、ＴＩＰ（４．１）と（４．３）に指定されている生成計算内の選択点に起因する分岐によるＡＬＬＥＯＰとトレースにおける選択肢の発生を説明する。（４．１）のＴＩＰのポートＣ．ｆがそのメッセージをポートＢ．ｇから時間点ｔ（ｂ．ｇ、１）に受信し、ＴＩＰ（４．１）のポートＣ．ｇがポートＤ．ｆと通信する。ＴＩＰ（４．１）のＡＬＬＥＯＰは以下の形態である。
【０２５８】
Ｃ．ｆ：ＡＬＬＥＯＰＯ＝［Ｃ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）｛Ｃ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝］
Ｃ．ｆ：ＡＬＬＥＯＰ−ｇｕａｒｄ（）＝［Ｃ．ｆ：ｍＲ？（〈Ｃ．ｆＤ〉［ｔ（Ｂ．ｇ，１）］）］
Ｃ．ｆ：ＡＬＬＥＯＰ−ｂｏｄｙ（）＝［Ｃ．ｆ：ｒ（Ｃ．ｇ）・→／／これによってＣ．ｆ：ｓｐｗｎをｔｒｕｅ、ｆａｌｓｅ、またはφに設定
（Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｇＳ［ｔ（Ｃ．ｇ，０）］
→（〈Ｄ．ｆＤ〉［ｔ（Ｃ．ｇ，１）］
｜｜・→．．．・→Ｄ．ｆ：ＡＬＬＥＯＰ（））
・→Ｃ．ｆ：ｓｕｓｐｅｎｄ（）｝｜
¬Ｃ．ｆ：ｓｐｗｎ？（）｛Ｃ．ｆＳ［ｔ（Ｃ．ｆ，０）］
→（〈Ｂ．ｇＤ〉［ｔ（Ｃ．ｆ，１）］
｜｜・→．．．・→Ｂ．ｇ：ＡＬＬＥＯＰ（））｝｜
ｔｒｕｅ｛｝）］  （４．４）
（４．４）において、ＡＬＬＥＯＰは括弧に囲まれている選択肢「（．．．｜．．．｜．．．）」を指定する。（４．１）のｐｔｈｒｅａｄ、Ｃ．ｆ：ｒ（ｃ．ｇ）は以下の（４．５）に示しているように選択点によって指定された選択肢を有しており、（４．５）のＣ．ｆ．ＭはＣ．ｇに対するのと同様にＣ．ｆに対してチューンされているｖｉｒｔｕａｌＭｅｍｏｒｙである。
【０２５９】
Ｃ．ｆ：ｒ（Ｃ．ｇ）＝Ｃ．ｆ：ｍｓｇ（）：ｒ（Ｃ．ｇ，Ｃ．ｆ）＝
［〈ｃｏｍｐｕｔａｔｉｏｎｓ−ｌ〉／／これが以下で使用する条件の値を設定。
【０２６０】
ｓｅｌｅｃｔＯｎｅ｛〈Ｃ．ｆ：ｃｏｎｄｎ１〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｔｒｕｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｇ．Ｍ〉｝
〈Ｃ．ｆ：ｃｏｎｄｎ２〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｆａｌｓｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｆ．Ｍ〉｝
ｔｒｕｅ｛Ｃ．ｆ．ｓｐｗｎ＝φ；Ｃ．ｆ．ｉｎｐｕｔ＝ｓ；｝｝］  （４．５）
ただし、（４．５）においてＣ．ｆ．ｓｐｗｎがφに設定された場合、ｃ．ｆ．ｉｎｐｕｔはｓにリセットされ、Ｃは次のポーリングサイクルでポートＣ．ｆで受信したメッセージを再度検知する。これは、この場合、（４．１）に示しているｃ．ｆ：ｓｕｓｐｅｎｄ（）を実行することによってポートＣ．ｆにおける前のサービスの試みにおいてＣ．ｆ．ｉｎｐｕｔがφに設定されているからである。ｐｔｈｒｅａｄ、Ｃ．ｇ：ｒ（Ｃ．ｆ）＝Ｃ．ｇ：ｍｓｇ（）：ｒ（Ｃ．ｆ，Ｃ．ｇ）はＣ．ｆとＣ．ｇによる役割が切り替えられる同様の構造を有している。
【０２６１】
Ｃ．ｇ：ｒ（Ｃ．ｆ）＝Ｃ．ｇ：ｍｓｇ（）：ｒ（Ｃ．ｇ，Ｃ．ｆ）＝
［〈ｃｏｍｐｕｔａｔｉｏｎｓ−２〉／／これがｃｏｎｄｎ１またはｃｏｎｄｏｎ２をｔｒｕｅに設定する
ｓｅｌｅｃｔＯｎｅ｛〈Ｃ．ｇ：ｃｏｎｄｎ１〉？（）｛Ｃ．ｇ．ｓｐｗｎ＝ｔｒｕｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｇ．Ｍ〉｝
〈Ｃ．ｇ：ｃｏｎｄｎ２〉？（）｛Ｃ．ｇ．ｓｐｗｎ＝ｆａｌｓｅ；〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｆ．Ｍ〉｝
ｔｒｕｅ｛Ｃ．ｇ．ｓｐｗｎ＝φ；Ｃ．ｇ．ｉｎｐｕｔ＝ｓ；｝｝］  （４．６）
（４．５）のＡＬＬＥＯＰは選択肢の指定を備えている以下に示している構造を有している。
【０２６２】
Ｃ．ｆ：ｒ．ＡＬＬＥＯＰ（Ｃ．ｇ）＝
［・→．．．・→／／これはｃｏｎｄｏｎ１またはｃｏｎｄｎ２をｔｒｕｅに設定する（４．５）の〈ｃｏｍｐｕｔａｔｉｏｎｓ−１〉を表す。
【０２６３】
・→（〈Ｃ：ｃｏｎｄｎ１〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｔｒｕｅ・→〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｇ．Ｍ〉｝｜
〈Ｃ：ｃｏｎｄｎ２〉？（）｛Ｃ．ｆ．ｓｐｗｎ＝ｆａｌｓｅ・→〈ｗｒｉｔｅ−ｍｓｇ−ｉｎ−Ｃ．ｆ．Ｍ〉｝｜
ｔｒｕｅ｛Ｃ．ｆ．ｓｐｗｎ＝φ・→Ｃ．ｆ．ｉｎｐｕｔ＝ｓ；｝｝）］  （４．７）
（４．６）のＡＬＬＥＯＰはこれと同様である。
【０２６４】
４．２．ポートベクトル
フォークとジョインはポートベクトルが使用された時に発生する。ポートベクトルｐ＝［ｐ１，ｐ２，．．．，ｐｎ］はポートのベクトルであって、全て同じ種類であって、全て同じセルに付属している。このポートベクトルに関連付けられているＴＩＰにおいて、ベクトルのポートの親セルはメッセージを確認するために（またはポートの準備ができていることを確認するために）、ｐ：ｍＲ？（）（またはｐ：ｐＲ？（））の形態のガードを使用し、ここで
ｐ：ｍＲ？（）＝［ｐ１：ｍＲ？（）＆ｐ２：ｍＲ？（）＆．．．＆ｐｎ：ｍＲ？（）］  （４．８）および
ｐ：ｐＲ？（）＝［Ｐ１：ｐＲ？Ｏ＆ｐ２：ｐＲ？（）＆．．．＆ｐｎ：ｐＲ？（）］  （４．９）
したがって、セルはそのポートベクトルでベクトルの全てのポートがそれらに対して配信された信号を有している（または全てが準備ができている）時にだけ信号に応答を開始する。ガードがポートベクトルの全てのポートに対してｔｒｕｅではない場合、ポートベクトルはスキップされ、親セルは次のポートのポーリングを開始する。図１と２において、ｇ：ｍＲ？（）テストがｇｅｎｅｒａｌＰｏｒｔ、ｇにおいて実施される時に、入力信号ｓ＝ｇ．ｉｎｐｕｔがφにリセットされる。この入力信号のリセットはポートベクトルｇに属しているｇｅｎｅｒａｌＰｏｒｔ、ｇｉについては発生しない。これは、ｇｉ：ｍＲ？（）テストがｇの全てのポートについて成功するまで連続するポーリングサイクルにおいて繰り返されるためである。ｐ：ｍＲ？（）＊（またはｐ：ｐＲ？（）＊）を書くことによって同期ガードを指定し、ここで、ガードはそれがｔｒｕｅになるまで繰り返し評価される。ここでＴＩＰは以下の形態のいずれかを有している。
【０２６５】
Ｃ．ｆ：ｍＲ？（）｛Ｃ：ｒ（ｆ）；Ｃ．ｆ：ｓ（）；｝  （４．１０）または
Ｃ．ｆ：ｍＲ？（）｛Ｃ：ｒ１（ｇ，ｆ）；Ｃ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ：ｓｕｓｐｅｎｄ（ｇ）；｝
ｅｌｓｅ｛Ｃ．ｆ：ｓ（）｝  （４．１１）
Ｃ．ｇ＿：ｍＲ？（）｛Ｃ：ｒ２（ｆ，ｇ）；Ｃ：ｓｐｗｎ？（）｛Ｃ．ｇ：ｓ（）；Ｃ：ｓｕｓｐｅｎｄ（ｆ）；｝
ｅｌｓｅ｛Ｃ．ｆ：ｓ（）；Ｃ：ｓｕｓｐｅｎｄ（ｇ）；｝｝、（４．１２）
ここで、Ｐｉ＝ｆｉ｜ｇｉについて、Ｃ．ｐ：ｓ（）＝Ｃ．ｐ１：ｓ（）；Ｃ．ｐ２：ｓ（）；．．．Ｃ．ｐｎ：ｓ（）；  （４．１３）
（４．１１）において、ｇ内のポートはそれらに配信されたメッセージを有していなかった。（４．１１）において、ｇ内のポートはそれらに配信されたメッセージを有していた。この場合、応答がｆを通して返信された時に、ｇ内の各ｇｉについての設定ｇｉ．ｉｎｐｕｔ＝φはｇｉを通して受信したメッセージはリスンされ使用されていることを意味する。（４．１２）のＣ：ｓｕｓｐｅｎｄ（ｇ）がこのタスクを実行する。ここで（４．１０）と（４．１１）のｐｔｈｒｅａｄ、Ｃ：ｒ（ｆ）、Ｃ：ｒ１（ｇ、ｆ）と、（４．１２）のｐｔｈｒｅａｄ、Ｃ：ｒ２（ｆ，ｇ）はポートベクトルのポートの共通の親セルにおいて定義される。ポートベクトルＣ．ｇはＣ．ｆの排他的な使用のために確保されている。ただし、Ｃ．ｇ内の全てのポートはＣがメッセージを送信した時に、常にメッセージを送信する準備ができている。セルはＣ：ｒ（ｇ，ｆ）（またはＣ：ｒ（ｆ））で定義されている計算に依存してＣ．ｆの部分集合のメッセージだけを使用してもよい。同様に、Ｃ．ｇ内のポートの部分集合を通してのみ計算を生成するメッセージを送信してもよい。この場合、Ｃはメッセージが送信されたｇｅｎｅｒａｌＰｏｒｔを、後でこれらのポートにおいてだけ応答をリスンできるように、記憶することになる。しかし、それは、ｆの各ポートに常に応答する。
【０２６６】
セクション４．４で説明する非決定的ガードの文脈を除いて、ガード表現において分離は許されない。セクション２．２で非決定的ガードを使用した例を見た。しかし、メッセージに対する分離応答はＣ：ｒ（ｇ，ｆ）（またはＣ：ｒ（ｆ））がどのようにＣ．ｆのポートで受信したメッセージを使用するかに依存して可能である。したがって、メッセージがポートベクトルのポートの１つで検知された時に、このメッセージの性質に依存して、同じベクトルの他のポートで受信されたメッセージが無視される。分離を伴うガードを指定することと、ポートベクトルのメソッドとの本質的な違いは後者の場合、応答はポートベクトル内の全てのポートがメッセージを受信し、応答を送信する準備ができた後でだけ発生することであって、分離された状態での使用の予測される計算上の不測事態はｐｔｈｒｅａｄにコード化されている。応答はポートベクトルの各ｆｕｎｃｔｉｏｎＰｏｒｔを通して常に返信される。メッセージ受信についての肯定応答は、そのメッセージが処理されていない場合でも送信される。したがって、トランザクションは常に完了する。
【０２６７】
この慣行の結果として、セルのポートベクトルのポート間の相互動作の特定のパターンを導入するためには、たとえばあるポートのメッセージが他のポートでの応答を禁止している場合、セルによってそのポートベクトルを通して受信したメッセージに応答するために使用される既にコード化されているｐｔｈｒｅｄを変更することが必要になる。このオプションを選択したが、それは分離を避けることで実装の分析が簡単になるからである。
【０２６８】
４．３．サイクル同期
ネットワーク内の２つのポートは、両者が（ｎ−１）番目の入力メッセージに対してサービスを行った（（ｎ−１）番目の出力メッセージを送出した）後で初めて両者がそれらのｎ番目の入力メッセージに対してサービスを行う（ｎ番目の出力メッセージを送出する）場合にサイクル同期していると言われる。ネットワーク内の別個のポートの集合のサイクル同期はそれらのポートでアクティビティを規定された順序で発生させる。したがって、ポートのサイクル同期はそれらのポートのアクティビティを調和させる。
【０２６９】
４．３．１．同期と調和の種類
サイクル同期：
前述のように、（４．１１）と（４．１２）において、ｆｕｎｃｔｉｏｎＰｏｒｔベクトルｆの親セルは関連付けられているｇｅｎｅｒａｌＰｏｒｔベクトルｇのｇｅｎｅｒａｌＰｏｒｔの部分集合によってのみサービス要求を生成することができる。しかし、応答メッセージは常にｆの全てのｆｕｎｃｔｉｏｎＰｏｒｔを通して送信される。したがって、ｆのポートがサイクル同期されていても、ｇのポートはサイクル同期されていない。
【０２７０】
これはグループ対グループ通信（セクション２．２と７）で発生することの双対である。これは、Ｇ内のポートによって送信される結合サービス要求メッセージがＦ内のｆｕｎｃｔｉｏｎａｌＰｏｒｔの部分集合にだけ配信されるためである。所与の結合サービス要求メッセージが配信されたｆｕｎｃｔｉｏｎＰｏｒｔのこの特定の部分集合は送信されたメッセージとセキュリティ指定に依存してもよい（セクション２．２と７の例を参照）。メッセージ配信信号をｆｕｎｃｔｉｏｎＰｏｒｔ、Ｆにブロードキャストするエージェントはメッセージが配信されたｆｕｎｃｔｉｏｎＰｏｒｔを追跡し、それらのｆｕｎｃｔｉｏｎＰｏｒｔだけからの応答を期待することになる。
【０２７１】
同期ジョインとフォーク：グループ対グループ通信において、フォークとジョインの原因になるメッセージのディスパッチと配信は、セクション１．３．２と８で説明したように、グループ対グループ経路内のエージェントがそれぞれ調和させ同期させる。セルグループ内の異なるセルは同期して配信されたメッセージに対して異なる時間に応答を開始するが、それは応答計算が始まる時間が同期していないからである。しかし、通信は同期しているので、これらを同期ジョインとフォークと呼ぶ。
【０２７２】
非同期ジョイントフォーク：ｆｕｎｃｔｉｏｎＰｏｒｔベクトルｆによって受信されるメッセージはジョイン操作を構成し、ｇｅｎｅｒａｌＰｏｒｔベクトルｇを通して送信されるメッセージはフォーク操作を構成する。これらのメッセージは異なる時間に到着（出発）し、異なるセルから来る（に行く）。ここでは通信は非同期なので、これらを非同期ジョインとフォークと呼ぶ。しかし、非同期ジョインにおいて受信されたメッセージに対する応答の計算は常に同期している。ここで、同期はポートベクトルのメッセージ受信親セルによって行われる。
【０２７３】
セクション６．６（図１７と１８）において、生成、ポートグループ、およびポートベクトル構成が導入され、ＴＩＣＣＴＭネット−ワーク内の別個のセルの別個のポートの任意の所与の集合によって受信される非同期メッセージは特定の順序で応答計算を発生させるようにサイクル同期しているか、アプリケーション内に既に実装されているｐｔｈｒｅａｄを変更する必要なしに、応答計算をポートのメッセージ受信親セルにおいて同期して始めるように強制されている。これらをアドホック調和と同期と呼ぶ。
【０２７４】
前述のように、ＴＩＣＣＴＭ−Ｐｐｄｅ計算には並列計算のアクティビティを調和させ同期させるためにモニタ、セマフォ、ランデブー技法[１０、１２、２３、２４]は必要ない。セクション２でモニタとセマフォを使用しない同期と調和の２つの例を見たが、セクション６でさらに見ることになる。本明細書で説明する全ての同期と調和の特徴はＴＩＣＣＴＭ−Ｐｐｄｅに固有である。
【０２７５】
４．４．非決定的ガード
非決定的ガードは指定された集合から１つの選択肢を選択する。ＴＩＰは以下の形態である。
【０２７６】
∃（Ｃ．ｐｉ（Ｃ．ｐｉ＝（Ｃ．ｐ１｜Ｃ．ｐ２｜．．．｜Ｃ．ｐｎ））Ｃ．ｐｉ：ｍＲ？（）｛
ｓｅｌｅｃｔＯｎｅ｛（Ｃ．ｐｉ＝Ｃ．ｐ１）？（）｛Ｃ．ｐ１：ｔｉｐ（）；｝
（Ｃ．ｐｉ＝Ｃ．ｐ２）？（）｛Ｃ．ｐ２：ｔｉｐ（）；｝
――――――――――――
（Ｃ．ｐｉ＝Ｃ．ｐｎ）？（）｛Ｃ．ｐｎ：ｔｉｐ（）；｝｝  （４．１４）
ここでｐはｆ｜ｇを表す。配信信号のある第１のポートはガード内の選択肢の左から右への走査において選択される。選択肢がｆｕｎｃｔｉｏｎＰｏｒｔを含んでいる場合、場合は相互に排他的でなければならない。そうでなければ、ｆｕｎｃｔｉｏｎＰｏｒｔで受信されたメッセージは応答されないことがある。前述のように、これは許されない。
【０２７７】
ＴＩＰ（４．１４）において、ガード内の選択肢ポートの１つであるＣ．ｐ１はその入力メッセージをＢ．ｑｉから受信する。それから（４．１４）のＡＬＬＥＯＰはアクティビティの選択肢の因果チェーンを備えている形態を有することになる。
【０２７８】
∃（Ｃ．ｐｉ（Ｃ．ｐｉ＝（Ｃ．ｐ１｜Ｃ．ｐ２｜．．．｜Ｃ．ｐｎ））Ｃ．ｐｉ：ｍＲ？（〈Ｃ．ｐｉＤ〉［ｔ（Ｂ．ｑｉ，＃）］｛
（（Ｃ．ｐｉ＝Ｃ．ｐ１）？（）｛Ｃ．ｐ１：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
（（Ｃ．ｐｉ＝Ｃ．ｐ２）？（）｛Ｃ．ｐ２：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｜
――――｜
（（Ｃ．ｐｉ＝Ｃ．ｐｎ）？（）｛Ｃ．ｐｎ：ＡＬＬＥＯＰ−ｂｏｄｙ（）｝｝  （４．１５）
同期ガード∃（Ｃ．ｐｉ（Ｃ．ｐｉ＝（Ｃ．ｐ１｜Ｃ．ｐ２｜．．．｜Ｃ．ｐｎ））Ｃ．ｐｉ：ｍＲ？（））＊も有していてもよい。この場合、ガードの走査は配信信号のある１つのポートが見つかるまで繰り返される。これがうまくいくようにすることは可能であるが、それはメッセージがセルのポートにセルの動作と並列に配信されるからである。この種類の同期ガードは、セクション６．１の装飾的庭の解法、ＯＧ解法において使用される。他の存在ガードは以下の形態であって、
∃（ｉ）（１≦ｉ≦ｎ）ｇｉ：ｍＲ？（）｛ｓｅｌｅｃｔＯｎｅ｛（Ｃ．ｇｉ＝Ｃ．ｇ１）？（）｛Ｃ．ｇ１：ｔｉｐ（）；｝
（Ｃ．ｇｉ＝Ｃ．ｇ２）？（）｛Ｃ．ｇ２：ｔｉｐ（）；｝
――――
（Ｃ．ｇｉ＝Ｃ．ｇｎ）？（）｛Ｃ．ｇｎ：ｔｉｐ（）；｝  （４．１６）
ｇｅｎｅｒａｌＰｏｒｔだけを含んでいる。この場合、異なる場合は相互に排他的である必要は無く、それはｇｅｎｅｒａｌＰｏｒｔに配信されるメッセージに応答する必要が無いためである。ＡＬＬＥＯＰは（４．１５）と同様である。この種類のガードは、セクション６．３のＰＣ解法、生産者／消費者解法において使用される。
【０２７９】
４．５．ポート依存性
各セルは自身の内部メモリを有している。各セルはこのメモリを使用してセル内で定義されているｐｔｈｒｅａｄを実行し、そのローカル状態を保存する。セルＣの各ポートＣ．ｆについて、ＣがＴＩＰボディ、Ｃ．ｆ：ｔｉｐ（）を実行する時に、それが実行するｐｔｈｒｅａｄは次の関数を計算してもよい。
【０２８０】
ξｆ（ｍｎ，Ｓｃ［ｆ，ｎ−１］）＝（ｍｎ’，Ｓｃ［ｆ，ｎ］）  （４．１７）
ここで、ｍｎはポートＣ．ｆによって受信されるＣ．ｆのｖｉｒｔｕａｌＭｅｍｏｒｙ内に存在するｎ番目のメッセージ、Ｓｃ［ｆ，ｎ−１］はＣ．ｆの（ｎ−１）番目のメッセージの実行の最後でのそのポートｆに相対的なＣの状態、ｍｎ’はポートＣ．ｆを通して送信されるｎ番目の応答メッセージ、Ｓｃ［ｆ，ｎ］は実行後のＣ．ｆの状態である。Ｐｐをポートｐで定義されている述語を表すために使用し、ＰｃをセルＣ：∀ｐ∀ｑ（ｐ≠ｑ⇒Ｐｐ∩Ｐｑ＝φ）＆∀ｐ（Ｐｐ∩Ｐｃ＝φ）で定義されている述語を表すために使用する。Ｓｃ［ｆ，ｎ］⊂（Ｐｆ∪Ｐｃ）は（Ｐｆ∪Ｐｃ）のｔｒｕｅの述語を含むことになる。これらの述語に関連付けられている値はセルとポートのローカルメモリに保持されている。（４．１７）において、Ｃ．ｐ：ｔｉｐ（）は（Ｐｆ∪Ｐｃ）内の述語の値だけを変更することができる。
【０２８１】
（４．１７）の形態の関数を計算する各ポートは、Ｓｃ［ｆ，ｎ］⊂Ｐｆの場合にξｆがＰｃ内の述語を変更できない場合に、セルＣの独立ポートである。ＴＩＣＣＴＭ−Ｐｐｄｅ内のセルは、２つ以上のそのような独立ポートを有していてもよい。Ｃ．ｆがＣの独立ポートである場合、Ｃ．ｆをＣ．ｆに接続されている経路と共に新しい複製セル、たとえばＣ’に移動させることが可能で、Ｃ’．ｆはＣ．ｆが受信するのと同じメッセージを受信し、Ｃ’．ｆはＣ．ｆと同じ機能を有している。この場合、Ｃ．ｆ上で独立している全てのポート（以下の（４．１８）を参照）はＣ’に移動させなければならない。Ｃに割り当てられたＣＰＵがアイドル状態にならないようにするために、複数の独立ポートをセルＣに割り当てることが可能である。ＩｎｔｅｒｒｕｐｔＰｏｒｔは常に独立ポートであるが、他のセルに移動させることはできず、それはＩｎｔｅｒｒｕｐｔＰｏｒｔを通して受信されたメッセージに基づいてセル内の計算が開始／停止、サスペンド／レジュームされ、セル内のポートの順序が変更されるためである。
【０２８２】
ポートＣ．ｆ１について、Ｃ．ｆ１：ｔｉｐ（）によって計算される関数は次の形態を有している。
【０２８３】
ξｆ１（ｍｎ，Ｓｃ［ｆ１，ｎ−１］，Ｓｃ［ｆ２，ｎ−１］）＝（ｍｎ’，Ｓｃ［ｆ１，ｎ］）  （４．１８）
ここでＳｃ［ｆ２，ｎ−１］は同じセルの他のポートＣ．ｆ２の状態である。この場合、ポートｆ１はポートｆ２に依存していると言う。ξｆ１はＰｆ２の述語を使用してもよいが、それらを変更することはできない。この種類のポートの依存性は以下の入れ子形態のＣ．ｆ２のＴＩＰによって実施される。
【０２８４】
Ｃ．ｆ２：ｍＲ？（）｛Ｃ．ｆ２：ｒ（）．ｓ（）；Ｃ．ｆｉ：ｍＲ？（）＊｛Ｃ．ｆｉ：ｒ（Ｃ．ｆ２）．ｓ（）｝｝  （４．１９）
ここで、ｆ２でメッセージに応答した直後に、セルはメッセージの受信をｆ１で待って応答する。任意の数のそのような入れ子をＴＩＰに有することができる。ｆ１とｆ２とが相互に依存していることも可能である。その場合、ＴＩＰは次の形態である。
【０２８５】
Ｃ．ｆ２：ｍＲ？（）｛Ｃ．ｆ２：ｒ（Ｃ．ｆ１）．ｓ（）；Ｃ．ｆ１：ｍＲ？（）＊｛Ｃ．ｆ１：ｒ（Ｃ．ｆ２）．ｓ（）｝｝  （４．２０）
ここで、ｆ２はｆ１とｆ２の初期状態を使用してそのメッセージにまず応答し、それからｆ１が追従する。次に、ｆ２はｆ２とｆ１の更新された状態を使用してそのメッセージに応答し、この繰り返しのサイクルが継続する。明らかに、（４．１９）と（４．２０）のポートｆ１とｆ２とはサイクル同期している。これらの場合、Ｃ．ｆ１：ｔｉｐ（）はＣ．ｆ２：ｔｉｐ（）内でのみ実行される。
【０２８６】
2012506076.tif 000009
【０２８７】
図８：依存ポートの移動
図８において、「修正前」のセルＣ．ｆ１は（４．１８）のようにＣ．ｆ２に依存している。「修正後」版では、Ｃ．ｆ１の経路はポートベクトルｆ＝［Ｃ’．ｆ１，Ｃ’．ｆ２］を有している他のセルＣ’のポートＣ’．ｆ１に移動している。修正前のポートＣ．ｆ１はｇｅｎｅｒａｌＰｏｒｔ、Ｃ．ｇに変換されており、経路がＣ．ｇとＣ．ｆ２との間に設定されている。Ｃ．ｆ２の以下のＴＩＰとベクトル［Ｃ’．ｆ１，Ｃ’．ｆ２］はＣ．ｆ１とＣ．ｆ２との間の依存性を説明するために使用できる。
【０２８８】
(Ｃ．ｆ２：ｍＲ？（）＆Ｃ．ｇ：ｐＲ？０）｛Ｃ．ｆ２：ｒ（Ｃ．ｇ）．ｓ（）；Ｃ．ｇ：ｓ（）；｝  （４．２１）
（Ｃ．ｆ１：ｍＲ？（）＆Ｃ．ｆ２：ｍＲ？（））｛Ｃ．ｆ１：ｒ（Ｃ．ｆ２）．ｓ（）；Ｃ’．ｆ２：ｓ（）；｝  （４．２２）
ここでＣ．ｆ２はメッセージをＣ．ｇ．Ｍに書き込み、Ｃ．ｆ２に送信する。明らかに、Ｃ．ｆ２と［Ｃ’．ｆ１，Ｃ’．ｆ２］とはサイクル同期している。それは、互いに依存しているポートを分離しない。
【０２８９】
独立しているポートと依存しているポートを新しいセルへこのように移動させる可能性によって、各セルが唯一の独立ｆｕｎｃｔｉｏｎＰｏｒｔまたはｆｕｎｃｔｉｏｎＰｏｒｔベクトルを有しており、他の全てのｆｕｎｃｔｉｏｎＰｏｒｔはそれに依存している正規ネットワークの概念が発生する。
【０２９０】
Ｃ．ｆ：ｔｉｐ（）によって計算される関数は以下の形態を有していてもよい。
ξｆ（ｍｎ，（Ｓｃ［ｎ−１］∪Ｓｆ［ｎ−１］））＝（ｍｎ’，（Ｓｃ’［ｎ］∪Ｓｆ［ｎ］））  （４．２３）
ここでＳｃはセルＣの状態であって、ＳｆはポートＣ．ｆの状態である。ここで、共通の親セルの状態を共有しているポートＣのすべてのポートは互いに依存しているが、サイクル同期していない。前述のように、Ｃ．ｆ：ｔｉｐ（）は（Ｐｃ∪Ｐｆ）の述語だけを変更する。セクション６の食事をする哲学者の解法では、執事の全てのｆｕｎｃｔｉｏｎａｌＰｏｒｔは執事の状態に依存している。この場合、セルによって生成される出力メッセージは入力メッセージが処理される順序に依存している。セルの１つのポーリングサイクルにおいて、そのポート全部はそれらに対して配信されたメッセージを有しておらず、メッセージ検知はメッセージ配信に同期していないため、これはＴＩＣＣＴＭ−Ｐｐｄｅにおける非決定性の原因となる。前述のように、これはＴＩＣＣＴＭ−Ｐｐｄｅの並列計算に固有である。
【０２９１】
セルのｆｕｎｃｔｉｏｎａｌＰｏｒｔ、ｆとｇｅｎｅｒａｌＰｏｒｔ、ｇは、（４．２）と（４．３）の生成ＴＩＰでのように、互いに依存していてもよい。ここで、ポートｆは依存性の原因となるが、それはｇが計算を生成した後で初めて配信されたメッセージを有することができるからで、ｆ：ｔｉｐ（）においてだけ行うことができる。セルはデータベースやインターネットからデータを取得するために、そのｆｕｎｃｔｉｏｎＰｏｒｔの１つに専用のｇｅｎｅｒａｌＰｏｒｔを使用することができる。セルはセクション６．３の生産者／消費者の例でのように、後で使用するためにｆｕｎｃｔｉｏｎａｌＰｏｒｔに対して専用ではないそのｇｅｎｅｒａｌＰｏｒｔを使用することもできる。
【０２９２】
セクション１と４で導入したＴＩＰの形態はＴＩＣＣＴＭ−Ｐｐｄｅで使用されるＴＩＰの形態だけである。ＴＩＰはそのボディに埋め込まれている他のＴＩＰを有していてもよく、各ＴＩＰはゼロ以上のメッセージを送出する。セルによってそのポーリングサイクルにおいてポーリングされるセルのポートＴＩＰを外部ＴＩＰと呼ぶことにする。所与の任意の時刻で、常に、各セルはその全ての埋め込みＴＩＰ（内部ＴＩＰ）と共に外部ＴＩＰを１つだけ実行する。セルはその次の外部ＴＩＰを、現在のＴＩＰの実行の完了後か現在のＴＩＰのプログラムされたサスペンドの実行後に初めて実行する。外部ＴＩＰの実行は相互に排他的である。各ポートベクトルＣ．ｐはベクトル内の全てのポートに対して定義されている１つの共通のＴＩＰ、Ｃ：ｔｉｐ（ｐ）と、それら全てに対して定義されている共通の状態Ｓｃ［ｐ，ｎ］を有している。Ｃ：ｔｉｐ（ｐ）は、その機能に依存して、ＰＰまたはＰｐ∪Ｐｃの任意の述語を変更することができる。
【０２９３】
全ての場合において、ネットワーク内のセルによって並列に同時に実行されるＴＩＰの数と並列に同時に交換されるメッセージの数とは高々ネットワーク内のアクティブなセルの数である。
【０２９４】
2012506076.tif 000010
【０２９５】
図９：従来のアーキテクチャとＴＩＣＣＴＭシステムのアーキテクチャ
【０２９６】
４．６．システムアーキテクチャ
ＴＩＣＣＴＭ−Ｐｐｄｅ内のシステム構成を従来のシステム構成と対比することは有用である。図９Ａは粗粒度並列プログラミングにおける並行／並列スレッド／プロセス実行のための従来のアーキテクチャを示している。ＭＰＩ［２５，２６］、ＰＶＭ［２７］によって提供されるライブラリとＥｔｈｅｒｎｅｔ［２２］またはＭｙｒｉｎｅｔ［２８］によって提供されるネットワークが通信に使用される。アクターシステムはこのアーキテクチャを仮定している。これらのシステムでは、スケジューリング、通信、同期、調和、プロセスとスレッド管理に相当なオーバーヘッドが存在し、効率の損失が伴う。ＴＩＣＣＴＭ−Ｐｐｄｅは、スケジューリング、調和、同期、およびｐｔｈｒｅａｄ管理において時間を浪費しない。
【０２９７】
実時間パフォーマンス：ＴＩＣＣＴＭ−Ｐｐｄｅの任意のセルが実行する動作は３種類しか存在せず、（ｉ）ポートのポーリングと順受付け、（ｉｉ）ｐｔｈｒｅａｄ実行（ｒｕｎ）、および（ｉｉｉ）プロトコル実行である。２ギガヘルツのコンピュータでＴＩＣＣＴＭ−Ｐｐｄｅのポートをポーリングして並べ替えるのに１５〜３０ナノ秒しかかからない。メッセージ交換は自己スケジューリング、自己調和、および自己同期である。ｐｔｈｒｅａｄとセルの起動は自動スケジューリングされており、配信されたメッセージが検出された時や、ｓｏｒｔｅｄ−ｐｏｒｔｓ−ｌｉｓｔ（（２．１）を参照）によって指定されている順序でｐ：ｔｉｐ（）が実行される時にそれらは自動的に起動される。図９Ｂに示しているように、オペレーティングシステムはこれらの動作を実行するのには必要ない。全てのメッセージはそれらを送信する準備ができた時に即座に送信される。各セルはメッセージを準備ができた任意の時刻に他の各セルと並列に送信してもよい。
【０２９８】
これを実時間性能と呼ぶが、それは全ての利用可能な実時間がアプリケーションに関連している計算の実行に使用され、スケジューリング、調和、および同期セッション、または他の種類のオーバーヘッドに対して時間が無駄にされないためである。逐次バッファは使用されない。ｖｉｒｔｕａｌＭｅｍｏｒｙ構成は共有メモリ動作においてメモリ干渉を最小にする。これらによって、ＴＩＣＣＴＭ−Ｐｐｄｅ内の並列プログラムの効率的な実行が可能になる。図９Ａに示している従来の構成は、この種類の実時間性能を提供しない。
【０２９９】
予測可能性：複数の命令ストリーム実行（ｒｕｎ）［２９］、先読みスケジューリング［３０］、パイプライン処理［３１］、およびキャッシュされた実行［３２］などの確立されている高速化技法はスレッドの起動と実行の時間およびメッセージのディスパッチと配信の時間とを予測可能にする［Ｌｅｅ他，３３−３６］。これらの技法は、高いスループットを得るためにＴＩＣＣＴＭ−Ｐｐｄｅでは必要ない。ＴＩＣＣＴＭ−Ｐｐｄｅでは、メッセージ交換レイテンシとｐｔｈｒｅａｄ実行時間が予測可能である。ｐｔｈｒｅａｄ起動時間は限界付き制限時間内で予測可能である。タイミングは計算のイベントベースのＴＩＣＣＴＭ−Ｐｐｄｅモデル内に組み込まれている。
【０３００】
同期と調和：ＴＩＣＣＴＭ−Ｐｐｄｅはモニタ、セマフォ、またはランデブー技法［Ｈｏａｒｅ，１０，１２］［Ｄｉｊｋｓｈｔｒａ，２３，２４］を使用せずにアプリケーション内のイベントの調和と時間同期のための新規のメソッドを提供する。これらをセクション２と６の例に示しており、セクション６．６で説明する。
【０３０１】
イベントベースモデル：セクション６、７で説明するように、ＴＩＣＣＴＭ−Ｐｐｄｅの最も重要な特徴は、実装仕様から計算のイベントベースのモデルを自動的に生成することであって、これらのモデルはシンボリック評価によるシステムの静的な検証に使用され、また動的な自己監視システム（ＳＭＳ）にも使用される。これらの特徴はＴＩＣＣＴＭ−Ｐｐｄｅに固有である。イベントベースの意味論によって、ＴＩＣＣＴＭ−Ｐｐｄｅはマルチコアチップを使用し、キャッシュメモリが内場合に正確に時間が設定された動作を行う、実時間サイバー物理システムと埋め込みシステムの構築に適している。キャッシュメモリの排除と高速化技法の採用の必要性の排除とによって、マルチコアチップ内のＣＰＵの設計が簡単になる。
【０３０２】
ＡＬＬＥＯＰ証明を構築するために使用されるメソッドを説明する例に進む前に、ＴＩＣＣＴＭ内の計算と通信、イベントと因果関係、オブジェクト指向構成と表記の特徴を定義することは有用である。それを次のセクションで行う。
【０３０３】
５．名前、世界状態、評価子およびイベント
５．１．オブジェクト指向構造
名前の有限集合から始める。名前は有限なアルファベット内のシンボルの連結である。〈ｎａｍｅｓ〉がこの名前の集合を指すことにする。〈ｎａｍｅｓ〉内の各名前は何らかの一意のものを表す。名前によって表される項目はコンテナまたはオブジェクトと呼ばれる。ここでは３つの集合、〈ｎａｍｅｓ〉、〈ｃｏｎｔａｉｎｅｒｓ〉、および〈ｏｂｊｅｃｔｓ〉が存在する。〈ｎａｍｅｓ〉内の名前を指すためにメタシンボルｘ、ｙ等を使用する。ｘ、ｙ等で表されるコンテナを指すためにメタシンボルΔｘ、Δｙ等を使用する。この場合、ｘ．ｄｅｎｏｔｅｓ＝Δｘ、Δｘ．ｄｅｎｏｔｅｄＢｙ＝ｘと書き、ｘ∈〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉と呼ぶ。〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉、δｂ、δｃ等を具体的に指すためにメタシンボルｂ、ｃ等を使用する。ｂ．ｄｅｎｏｔｅｓ＝δｂ＝ｂ．ｖａｌｕｅおよびδｂ．ｄｅｎｏｔｅｄＢｙ＝｛ｂ｝＝δｂ．ｖａｌｕｅＯｆと書く。「｛ｂ｝」が使用されるが、一般に同じオブジェクトを指す名前が２つ以上存在することがある。〈ｏｂｊｅｃｔｓ〉∩〈ｃｏｎｔａｉｎｅｒｓ〉＝φおよび〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉∩〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉＝φ，（〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉∪〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉）＝〈ｎａｍｅｓ〉。表示は多−１マッピングによって定義され、〈名前〉→〈ｏｂｊｅｃｔｓ〉∪〈ｃｏｎｔａｉｎｅｒｓ〉である。δｘ≡ｘも可能であって、オブジェクトの値は名前自体と同一であってもよい。したがって、（〈ｏｂｊｅｃｔｓ〉∪〈ｃｏｎｔａｉｎｅｒｓ〉）∩〈ｎａｍｅｓ〉＝｛ｂ｜ｂ．ｖａｌｕｅ＝ｂ｝である。
【０３０４】
５〜６個のコンテナ名が同じコンテナΔｘを指している場合、これらの名前の１つ、例えば名前ｚをそのコンテナの区別されるコンテナ名に設定し、Δｘ．ｄｅｎｏｔｅｄＢｙ＝ｚと設定する。５〜６個のオブジェクト名が同じオブジェクトδｂを指す場合、δｂ．ｄｅｎｏｔｅＢｙ＝δｂ．ｖａｌｕｅＯｆ＝｛ｃ｜ｃ．ｖａｌｕｅ＝δｂ｝である。名前に対する以下の述語を定義する。ｘ：ｎａｍｅ？（）⇔ｘ∈〈ｎａｍｅｓ〉；ｘ：ｃｏｎｔａｉｎｅｒ？（）⇔ｘ．ｄｅｎｏｔｅｓｅ〈ｃｏｎｔａｉｎｅｒｓ〉。これはｘ∈〈ｃｏｎｔａｉｎｅｒ−ｎａｍｅｓ〉と言うのと同じである。ｘ：ｏｂｊｅｃｔ？（）⇔ｘ．ｄｅｎｏｔｅｓｅ〈ｏｂｊｅｃｔｓ〉。これはｘ∈〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉と言うのと同じである。３つの区別されているオブジェクトを使用し、それぞれ、ｔｒｕｅ、ｆａｌｓｅ、およびφと呼ばれ、δｔｒｕｅ＝ｔｒｕｅ、δｆａｌｓｅ＝ｆａｌｓｅおよびδφ＝φという性質があり、φは空のオブジェクトである。これらは、定数と呼ばれるが、それはこれらのオブジェクト名の値が決して変化しないためである。任意の名前ｘについて、ｘ：ｃｏｎｓｔａｎｔ？（）⇔ｘ∈〈ｃｏｎｓｔａｎｔ−ｎａｍｅｓ〉⊂〈ｏｂｊｅｃｔ−ｎａｍｅｓ〉およびδｘ∈〈ｃｏｎｓｔａｎｔｓ〉⊂〈ｏｂｊｅｃｔｓ〉である。
【０３０５】
２つの名前が互いに同一である場合にだけ（ｘ≡ｙ）と表明し、（Δｘ≡Δｙ）または（δｘ≡δｙ）、つまりｘ．ｄｅｎｏｔｅｓ≡ｙ．ｄｅｎｏｔｅｓの場合には（ｘ（∽＝）ｙ）と表明する。（ｘ（∽＝）ｙ）を「ｘはｙと合同」と読むことができる。２つの名前ｘとｙは¬（ｘ（∽＝）ｙ）の場合に別個である。名前の２つの集合Ｓ１とＳ２について、［Ｓ１⊂Ｓ２⇔∀（ｘ∈Ｓ１）∃（ｙ∈Ｓ２）（ｘ（∽＝）ｙ）］＆［Ｓ１（∽＝）Ｓ２⇔Ｓ１⊂Ｓ２＆Ｓ２⊂Ｓ１］である。Ｓ１∩Ｓ２とＳ１∪Ｓ２とが同様に定義されている。
【０３０６】
各コンテナはオブジェクトまたは他のコンテナを含むことができるという特性を有している。Δｘ．ｃｏｎｔａｉｎｓ＝δｂまたはΔｘ．ｃｏｎｔａｉｎｓ＝Δｙ、¬（Δｘ≡Δｙ）と書く。オブジェクトは何も含むことができず、∀（δｘ）δｘ．ｃｏｎｔａｉｎｓ＝φである。Δｙ．ｃｏｎｔａｉｎｓ＝δｘの場合に、オブジェクトδｘはコンテナコンテナΔｙ内に存在すると言う。各オブジェクトは何らかのコンテナ内に存在しなければならず、自由なオブジェクトは存在しない。互いに同一であるが別個のコンテナに存在している２つのオブジェクトは互いに複製であると呼ぶ。
【０３０７】
Ｚ∈（〈ｎａｍｅｓ〉∪〈ｏｂｊｅｃｔｓ〉∪〈ｃｏｎｔａｉｎｅｒｓ〉）について、メソッドＺ：ｅｖａｌ（）：を定める。
【０３０８】
Ｚ：ｅｖａｌ（）＝［Ｚｅ〈ｏｂｊｅｃｔｓ〉？（）｛Ｚ｝｜Ｚｅ〈ｃｏｎｔａｉｎｅｒｓ〉？（）｛Ｚ．ｃｏｎｔａｉｎｓ：ｅｖａｌ（）｝
｜
Ｚ：ｏｂｊｅｃｔ？（）｛δＺ｝｜Ｚ：ｃｏｎｔａｉｎｅｒ？（）｛Δｚ：ｅｖａｌ（）｝］  （５．１）
【０３０９】
同一性：名前、オブジェクト、およびコンテナの同一性は以下のように定義される。
（（δｘ＝δｙ）⇔（δｘ≡δｙ））、（（Δｘ＝Δｙ）⇔（Δｘ≡Δｙ））および
（（ｘ＝ｙ）⇔（（ｘ≡ｙ）∨（ｘ：ｅｖａｌ（）≡ｙ：ｅｖａｌ（）≠φ）））  （５．２）
同一性のこの定義は、集合Ｘについて（ｘ∈Ｘ）と定義し、集合ＸとＹについて、Ｘ＝Ｙ、Ｘ⊆Ｙ、Ｘ⊂Ｙ、Ｘ⊇Ｙ、およびＸ⊃Ｙと定義するために拡張可能である。ただし、ｘ：ｅｖａｌ（）＝φも可能である。しかし、空の値を有している名前は、互いに同一でなければ互いに等しくなることはできない。（ｘ（∽＝）ｙ）⇒（ｘ＝ｙ）であるが、逆は真ではなく、それは別個の名前は同じδｂの複製を評価するからである。
【０３１０】
コンテナΔｘをメモリセルと考え、コンテナ名ｘをこれらのメモリセルへのポインタ（アドレス）と考えることができる。各δｂを、オブジェクトｂを表しており、メモリセル内に存在しているコード化（ビット列）と考えることができる。ポインタはそのオブジェクトのコード化がそのポインタによって指されているメモリセル内に存在している場合にだけオブジェクトを指し、コンテナ（メモリセル）内のオブジェクトは他のメモリセル内に存在していることもあるそれらのオブジェクトの複製を変更する必要なしに修正可能である。用語「ｄｅｎｏｔｅｓ」、「ｖａｌｕｅＯｆ」、および「ｃｏｎｔａｎｓ」を属性と呼ぶ。用語「ｏｂｊｅｃｔ？（）」、「ｃｏｎｓｔａｎｔ？（）」、および「ｃｏｎｔａｉｎｅｒ？（）」を述語と呼び、「ｅｖａｌ（）」をメソッドと呼ぶ。名前に対して定義されているより多くの属性、述語、およびメソッドを以下の説明でそれらが出現した時に紹介する。
【０３１１】
順序付け：順序のある関係を備えているＳ⊂〈ｏｂｊｅｃｔｓ〉について、＜は要素、名前ｘとｙについて定義されている。
【０３１２】
（ｘ＜ｙ）⇔［ｘ：ｅｖａｌ（）∈Ｓ＆ｙ：ｅｖａｌ（）∈Ｓ＆ｘ：ｅｖａｌ（）＜ｙ：ｅｖａｌ（）］  （５．３）
φ∈Ｓのこともあり得る。通常の定義が（ｘ≦ｙ）、（ｘ＞ｙ）、および（ｘ≧ｙ）に当てはまる。
【０３１３】
構造体：ｂはインデックス付きの構造体を有しており、名前ｘについて、ｘ：ｅｖａｌ（）＝δｂの場合ｘ［ｉ］＝δｂ［ｉ］＝ｂ［ｉ］、ｉはｂのインデックスの範囲、そうでなければｘ［ｉ］＝φである。しかし、ｘ［ｉ］＝φはｉがｂのインデックスの範囲外にあることを意味せず、それはｂ［ｉ］＝φがあり得るからである。ｘ［ｉ］自身はインデックス付き構造体ｘ［ｉ］［ｊ］を有していてもよい。ｂがそれに対して定義されている属性ａｔｂｔを有する構造体の場合、ｘ．ａｔｂｔ＝ｂ．ａｔｂｔ＝δｂ．ａｔｂｔｄであって、ｂ．ａｔｂｔが定義されていない場合ｘ．ａｔｂｔ＝φである。ｂ．ａｔｂｔ自体が属性ａｔｂｔｉを有することも可能である。すると、ｘ．ａｔｂｔ．ａｔｂｔｉ＝ｂ．ａｔｂｔ．ａｔｂｔｉ＝δｂ．ａｔｂｔ．ａｔｂｔｉである。
【０３１４】
名前のグループ化：各名前ｘはそれに対して定義されているメソッドｘ：ｎａｍｅｓ（）を有しており、ｘ：ｎａｍｅｓ（）はｘに関連付けられている全ての名前の集合である。それは、ｘについて定義されている全ての属性、述語、およびメソッドについてｘ、ｘ．ａｔｔｒｉｂｕｔｅ、ｘ：ｐｒｅｄｉｃａｔｅ？およびｘ：ｍｅｔｈｏｄ（）を含み、さらに他の名前も含む。｛ｘ｝⊂ｘ：ｎａｍｅｓ（）であるため、空ではない。２つの別個の名前ｘとｙについて、ｘ：ｎａｍｅｓ（）∩ｙ：ｎａｍｅｓ（）≠φ；φ：ｎａｍｅｓ（）＝｛φ｝があり得る。任意のｘについて、［ｘ：ｎａｍｅｓ（）］と書かれるｘ：ｎａｍｅｓ（）の閉包を以下に示す。
【０３１５】
［ｘ：ｎａｍｅｓ（）］＝∪｛［ｙ：ｎａｍｅｓ（）］｜ｙ∈ｘ：ｎａｍｅｓ（）＆¬（ｙ（∽＝）ｘ）｝∪｛ｘ｝  （５．４）
【０３１６】
名前の型の設定：名前は、整数、数、文字列、集合、構造体、クラス等、それに関連付けられている型を有していてもよい。〈ｔｙｐｅ〉は全ての型名の集合である。メソッドｘ：ｔｙｐｅ（）は、名前ｘの型を取得するのに使用され、ｘ：ｔｙｐｅ（）＝Δｘ：ｔｙｐｅ（）＝ｘ：ｅｖａｌ（）：ｔｙｐｅ（）、およびｂ：ｔｙｐｅ（）＝δｂ：ｔｙｐｅ（）；φ：ｔｙｐｅ（）＝φである。各型は〈ｎａｍｅ〉内の名前の部分集合を指し、ｎａｍｅｓ（）＝｛ｘ｜ｘ：ｔｙｐｅ（）≡ｔｙｐｅ｝⊂ｚ〈ｎａｍｅ〉である。明らかに、ｔｙｐｅ：ｔｙｐｅ（）＝Δｔｙｐｅ：ｔｙｐｅ（）＝Δｔｙｐｅ．ｃｏｎｔａｉｎｓ：ｔｙｐｅ（）＝ｓｅｔである。（ｔｙｐｅｉ⊂ｔｙｐｅ２）⇔（Δｔｙｐｅ１．ｃｏｎｔａｉｎｓ⊂Δｔｙｐｅ２．ｃｏｎｔａｉｎｓ）の場合にだけｔｙｐｅ１はｔｙｐｅ２のサブ型である。したがって、（整数⊂数）が成り立つ。ｔｙｐｅ１とｔｙｐｅ２とは（ｔｙｐｅ１∩ｔｙｐｅ２）＝φの場合に別個である。一方が他方のサブ型でない２つの型は別個でなければならない。継承については、型／サブ型の階層、アブストラクト型等において通常ではない規約を使用する。
【０３１７】
システムＳのオブジェクト指向構造：ＷＳ（ｔ）をシステムＳの時刻ｔでの世界状態とする。
【０３１８】
ＷＳ（ｔ）＝（｛（ｘ，Δｘ）｜ｘ：ｃｏｎｔａｉｎｅｒ？（）＆ｘ．ｄｅｎｏｔｅｓ＝Δｘ＆ｘ∈Ｓ：ｎａｍｅｓ（）（ｔ）｝∪
｛（ｂ，δｂ）｜ｂ：ｏｂｊｅｃｔ？（）＆ｂ．ｄｅｎｏｔｅｓ＝δｂ＆ｂ∈Ｓ：ｎａｍｅｓ（）（ｔ）｝∪
｛（Δｘ，Δｘ．ｃｏｎｔａｉｎｓ）｜∃ｘ∃ｂ∃ｙ［（（ｘ，Δｘ），（ｙ，Δｙ），（ｂ，δｂ）∈ＷＳ（ｔ））＆
（ｘ，ｙ，ｂ∈Ｓ：ｎａｍｅｓ（）（ｔ））＆¬（Δｘ≡Δｙ）＆
（Δｘ．ｃｏｎｔａｉｎｓ＝δｂ∨
Δｘ．ｃｏｎｔａｉｎｓ＝Δｙ）］｝）  （５．５）
【０３１９】
離散的な時刻だけを使用し、各時間点ｔは正の整数である。（ｔ１＜ｔ２）であれば、ＷＳ（ｔ’）が存在し、（ｔ１＜ｔ’＜ｔ２）であるような他の時間点ｔ’が存在しない場合に限り、ＷＳ（ｔ１）はＷＳ（ｔ２）の直前である。（ｘ，Δｘ）∈ＷＳ（ｔ）および∃（ｂ）（ｂ．ｄｅｎｏｔｅｓ＝ｘ：ｅｖａｌ（））を表明するためにｘ（ｔ）を使用する。したがってｘは常にコンテナ名である。ｘ：ｅｖａｌ（）＝φのこともあり得る。評価子（サブセクション５．３）が世界状態ＷＳ（ｔ）からトリプレット（ｘ，Δｘ，ｘｉｅｖａｌ（））にアクセスした場合、アクセス述語ｘ（ｔ）はｔｒｕｅであると言う。他のイベント述語は、ＷＳ（ｔ）で（ｘ＝ｙ）がｔｒｕｅであることがわかったことを表明する（ｘ＝ｙ）（ｔ）および、同様に、（ｘ＜ｙ）（ｔ）、（ｘ＞ｙ）（ｔ）、（ｘ≦ｙ）（ｔ）、または（ｘ＞ｙ）（ｔ）である。述語関連の集合も使用され、（ｘ∈Ｙ）（ｔ），（Ｘ⊂Ｙ）（ｔ）等である。述語には順序付けがあり、（ｔ１＜ｔ２）の場合にだけｘ（ｔ１）＜ｘ（ｔ２）である。ただし、（ｘ＜ｙ）（ｔ）はｘ（ｔ１）＜（ｔ２）と同じではない。（（ｘ＜ｙ）（ｔ１）＜（ｘ１＜ｙ１）（ｔ２））のこともあり得る。時間パラメータは重要ではない場合は省略される。
【０３２０】
Ｓ：ｃｅｌｌｓ（）がシステムＳ内のすべてのセルの集合を示すとする。セルＣのポートＣ．ｐについて、Ｃ．ｐ．ｐａｔｈｗａｙはＣ．ｐに接続されている一意の経路、Ｃ．ｐ．ｐａｔｈｗａｙ．ｖＭ＝Ｍ＝Ｃ．ｐ．ＭはＣ．ｐ．ｐａｔｈｗａｙの一意のｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍ．ａｇ［ｉ］はＭに付属しているｉ番目のエージェント、Ｍ．ｐｒｔ［ｉ］はＭに対してチューンされているｉ番目のポート、ｃ．ｐ．ｎｄＦｓｍはＣ．ｐで定義されているｄｎＦＳＭ、Ｃｐ．ａ．ｎｄＦｓｍはＣ．ｐ．ａで定義されているｎｄＦＳＭ、Ｃ．ｖＭｓ＝｛Ｃ．ｐ．Ｍ｜（Ｃ．ｐ．ａｔｔａｃｈｅｄＴｏ  Ｃ）｝である。Ｃ．ｐがｄｍ経路に接続されている場合、Ｃ．ｐ．ｐａｔｈｗａｙ．ｖＭはｄｍ経路Ｃ．ｐ．ＭｅＣｐ．ｐａｔｈｗａｙ．ｖＭ内の全てのｖｉｒｔｕａｌＭｅｍｏｒｙのベクトルである。最後に、ａ．ｐｒｔ［ｉ］はエージェントａに対してチューンされているｉ番目のポートであって、ａ．ｎｘｔ［ｉ］はエージェントａに対してチューンされているｉ番目の次のエージェントである。ベクトルＭ．ｐｒｔ＝∪［Ｍ．ａｇ［ｉ］．ｐｒｔ｜０≦ｉ＜Ｍ．ａｇ：ｓｉｚｅ（）］である。エージェント、ｖｉｒｔｕａｌＭｅｍｏｒｙ、およびポートは経路コンポーネントである。以下の名前がＣ．ｐ，ｐａｔｈｗａｙに関連付けられている。
【０３２１】
Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）＝
Ｃ．ｐ．Ｍ：ｎａｍｅｓ（）∪∪｛Ｃ．ｐ．Ｍ．ａｇ［ｉ］：ｎａｍｅｓ（）｜０≦ｉ＜Ｃ．ｐ．Ｍ．Ａｇ：ｓｉｚｅ（）｝∪
ｕ｛Ｃ．ｐ．Ｍ．ｐｒｔ［ｉ］．ｎｄＦＳＭ：ｎａｍｅｓ（）｜０≦ｉ＜Ｃ．ｐ．Ｍ．ｐｒｔ：ｓｉｚｅ（）｝  （５．６）
ここでＣ．ｐ．Ｍ：ｎａｍｅｓ（）はＣ．ｐ．Ｍ内に存在しているメッセージ内で定義されている全ての名前を含んでいる。ただし、全てのＣ．ｐ．Ｍ：ｎａｍｅｓ（）がＣ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）内には存在せず、Ｃ．ｐ．Ｍ．ｐｒｔ［ｉ］．ｎｄＦＳＭ：ｎａｍｅｓ（）だけが含まれている。セクション６．２で説明するように、各ｖｉｒｔｕａｌＭｅｍｏｒｙは４つのコンポーネントを有している。ｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙと呼ばれるそれらの２つはメッセージを含んでいる。所与の任意の時刻において、これら２つのコンポーネントは高々１つのメッセージを有している。セルＣに付属している各ポートＣ．ｐについて、
Ｃ．ｐ．ｎｄＦｓｍｉｎａｍｅｓ（）⊂Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）  ５．７）
Ｃ．ｐ．ｎｄＦｓｍｉｎａｍｅｓ（）⊂Ｃ．ｐ：ｎａｍｅｓ（）⊂Ｃ：ｎａｍｅｓ（）  （５．８）
したがって、Ｃ：ｎａｍｅｓ（）とＣ．ｐ：ｎａｍｅｓ（）とはＣ．ｐ．ｐａｔｈｗａｙ内の全ての名前を含んでおらず、Ｃ．ｐ．ｎｄＦｓｍｉｎａｍｅｓ（）だけを含んでいる。任意の２つの経路、別個のセルＣ１、Ｃ２、任意の２つのポートｐとｑについて以下が成立する。
【０３２２】
Ｃ１：ｎａｍｅｓ（）∩Ｃ２：ｎａｍｅｓ（）＝φ  （５．９）
（ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）（∽＝）ｑ．ｐａｔｈｗａｙ：ｎａｍｅｓ（））⇔（ｐ⇔ｑ）  （５．１０）
¬（ｐ⇔ｑ）⇔（（ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）∩ｑ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）＝φ）  （５．１１）
ここで（ｐ⇔ｑ）はｐとｑとが経路によって接続されていることを表明する。ただし、合同関係「（∽＝）」が（５．１０）で使用されている。（５．１１）の場合、経路は別個であると言う。別個のセルと別個の経路はコンテナを共有しない。システムＳのＳ：ｎａｍｅｓ（）の名前の不変の（つまりコンパイル時）オブジェクト指向構造を以下のように定義する。
【０３２３】
Ｓ：ｎａｍｅｓ（）＝
∪｛Ｃ：ｎａｍｅｓ（）｜Ｃ∈Ｓ：ｃｅｌｌｓ（）｝∪
∪｛Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）｜Ｃ∈Ｓ：ｃｅｌｌｓ（）＆（ｐａｔｔａｃｈｅｄＴｏＣ）｝  （５．１２）
世界状態はｃｅｌｌ：ｎａｍｅｓ（）とｐｏｒｔ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）に区分され、ｐｏｒｔ．ｎｄＦｓｍ：ｎａｍｅｓ（）においてだけ互いに重なる。この重なりによって、経路に接続されており、セルに付属しているポート間の通信を可能にする。この構造のリファインを使用して、メソッドの定義を促進する。ｄｍ経路の場合、経路のｎｄＦｓｍ：ｎａｍｅｓ（）で示されるコンテナは信号線によって互いに接続されており、ｖｉｒｔｕａｌＭｅｍｏｒｙ内のコンテナはデータ線によって接続されている。信号とデータはコンテナ間でこれらの線を介して交換され、プロトコル内のＣＣＰが調和させる。
【０３２４】
５．２．条件とＣＴＬステートメント
信号を試験する述語と述語表現を指すために用語「ガード」を使用し、ポートとエージェントの状態を記述する述語と述語表現とを指すために用語「状態」を使用し、全ての述語と述語表現とを指すために「条件」を使用する。条件は論理結合子と量化子を備えている述語を含んでいる任意の適切に定義されている１階表現つまり述語のブール表現である。すべての条件は、添え字「？（）」で終了する。量化子は無限の集合を対象としている。条件はｘ：ｎａｍｅｓ（）の名前によって定義されている世界で常に評価され、ｘはセル、ポート、エージェント、ｖｉｒｔｕａｌＭｅｍｏｒｙ、またはメッセージである。
【０３２５】
ＣＴＬステートメント（因果時間論理ステートメント）は、通常の論理結合子、時間モード演算子、□（常に）、◇（最終的に）、因果結合子→、・→（以下で説明）を備えており、量化子、∀と∃を使用し、通常の構文を備えている、質、順序、アクセス、イベントインスタンス述語の任意の組み合わせである。否定は、個別の述語とイベントインスタンスとにだけ現れ、表現全体に対しては現れない。否定されたイベントインスタンスは、「イベントインスタンスは発生してはならない」と解釈される。以下で説明するように、イベントインスタンスは定数の状態を有しており、２つのイベントインスタンスは互いに同一な場合にだけ互いに等しい。量化された変数、ｉｎ、∀、および∃はＣＴＬステートメントに現れるインスタンス、仮想時間点、および他のオブジェクトを対象としている。通常、量化子は、既知の有限集合を対象としている。ここではＣＴＬステートメントの構文については説明しない。以前のセクションでＡＬＬＥＯＰとトレースの記述に使用したステートメントはＣＴＬステートメントである。さらなる例が後のセクションに現れる。証明には、ＣＴＬステートメントで論理推論を実施することは伴わないが、所与のＥＣＴネットワーク上でのＣＴＬステートメントのシンボル評価だけを伴う。ＥＣＴネットワークの例をセクション６に示す。
【０３２６】
５．３．評価子、イベント、因果関係
評価子と呼ばれる構造化されている定数がある。システムは、任意のしかし有限の数の評価子Ｅ［ｉ］、０≦ｉ＜Ｎを有していてもよい。説明の中で明示的に評価子に触れる必要は無い。しかし概念は重要である。ＴＩＣＣＴＭ−Ｐｐｄｅにおいて、各セルに関連付けられている評価子（ＣＰＵ）が存在し、全ての評価子がメッセージ交換によってのみ相互動作しながら並列に動作する。ＥＣをセルＣの評価子とする。評価子は、名前、コンテナ、オブジェクト、コード化の生成／破壊、コード化の修正、コード化のコンテナ内への配置、コンテナの他のコンテナへの配置、オブジェクト／コンテナの１つのコンテナから他のコンテナへの移動、コンテナの１つの名前から他の名前への移動、アクセス権のコンテナへの設定、オブジェクト（そのコード化）への世界状態からのアクスによって計算を実施する。アクションイベントとアクセスイベントとが存在する。したがって、評価子によって実施される計算によって、アクセスとアクションイベントとが発生する。評価子ＥＣが名前ＸにＷＳからアクセスした場合、トリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））をＥＣ：ａｃｃｅｓｓｅｄＩｔｅｍｓリストに追加する。評価の最後に、ＥＣ：ａｃｃｅｓｓｅｄＩｔｅｍｓ内の要素を使用してＷＳの整合した更新を実施し、それからそのプライベートＥＣ：ａｃｃｅｓｓｅｄＩｔｅｍｓリストを破壊する。
【０３２７】
名前ｘは、ｘ（ｔ）がｔｒｕｅ（ｆａｌｓｅ）の場合に世界状態ＷＳ（ｔ）において生成（破壊）されるが、直後のＷＳ（ｔ’）においては、ｘ（ｔ’）はｆａｌｓｅ（ｔｒｕｅ）である。一般的な規約では、述語は、述語がＷＳ（ｔ１）でｔｒｕｅのようなｔ１≦ｔ２が存在し、述語がＷＳ（ｔ’）でｆａｌｓｅのようなｔ１＜ｔ’≦ｔ２が存在する場合、ＷＳ（ｔ２）においてｔｒｕｅである。したがって、破壊されるまで世界状態に名前が存在し、述語は変更されるまでその真理値を維持する。
【０３２８】
アクセス権、データ保護、および通信
通信と計算との間の唯一の差は、通信プロトコルはポート、エージェント、およびｖｉｒｔｕａｌＭｅｍｏｒｙに関連付けられているすでに定義されているコンテナ内のオブジェクト（データ）を生成／修正するだけである。コンテナの生成／破壊はできない。これは、それらが宣言を含んでいないからである。ｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージや他のデータを修正することはできない。したがって、通信は信号以外にアクセス権を評価子に転送することが異なる以外に、通信は計算の制限された形態に過ぎない。評価子ＥＣについては、ＥＣ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）は全ての名前の集合を指定し、ＥＣは時刻ｔにアクセス可能である。ＥＣ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）は以下のように定義される。
【０３２９】
ＥＣ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）＝
ＥＣ．：ｎａｍｅｓ（）∪Ｃ：ｎａｍｅｓ（）∪
∪｛（Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）（ｔ）｜（Ｃ．ｐ．ｓｔａｔｅ＝Ｓ）（ｔ）｝  （５．１３）
Ｃ．ｐ．ｐａｔｈｗａｙ：ｎａｍｅｓ（）は時間の関数であるが、それは、経路のｖｉｒｔｕａｌＭｅｍｏｒｙが異なるメッセージを異なる時刻に含んでおり、また、経路は動的に変化するからである。Ｃ．ｐ．ｐａｔｈｗａｙ内の名前についてのアクセス権は、Ｃ．ｐが状態Ｓにある時にだけＥＣに転送される。図１と２に示しているように、メッセージが検知されるかポートがメッセージの送出の準備ができている時にポートは常にその状態をＳに変更する。したがってＴＩＣＣＴＭにおいて、通信は、必要な時に適切な時刻に、自動的にアクセス権を評価子に転送する。これらのアクセス権はＣ．ｐの状態がＳから他の何らかの状態に変化した場合に、自動的に取り消される。
【０３３０】
評価子はアクション、イベント、および名前を評価できる特性を有している。アクションは常にメソッド、プロトコル、または条件であるか、宣言、割り当て条件（ｉｆ−ｔｈｅｎ−ｅｌｓｅやｓｅｌｅｃｔＯｎｅなど）、またはｗｈｉｌｅループなどの単にプログラミング言語内のステートメントである。セル、メッセージ、ポート、エージェント、またはｖｉｒｔｕａｌＭｅｍｏｒｙ内で定義されているメソッド内に現れる宣言ｙ：Ａ（）は、宣言されている名前ｘについてトリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））をｙ．Ａ：ｗｏｒｌｄ（）（ｔ）に導入する。名前をｙ．Ａ：ｗｏｒｌｄ（）（ｔ）から破壊し取り除くために宣言も使用する。さらに、ｙ．Ａ：ｗｏｒｌｄ（）（ｔ）は｛（ｘ，Δｘ，ｘ：ｅｖａｌ（））｜∃（Ｘ）（Ｘｃ（ｙ：ｎａｍｅｓ（）∪Ａ：ｎａｍｅｓ（））＆（ｘ∈Ｘ：ｎａｍｅｓ（）））｝を含んでおり、ｙ．Ａ：ｗｏｒｌｄ（）（ｔ）はｙ．Ａ（）のコードを含むことになり、またｙ．Ａ（）が実行された時に動的に生成される名前を含んでもよい。プロトコルはアクションであるが宣言を含まずＣＣＰを含むところが異なる。メソッドはＣＣＰを通常含まない。
【０３３１】
アクセス評価について→aを、アクション評価のために→ｅを以下の表記と共に使用する。
【０３３２】
時刻ｔ：［〈→ａｘ〉（ｔ）］にアクセスが完了  アクセスが時刻ｔ：［→ａｘ（ｔ）］に始まる  （５．１４）
時刻ｔ：［〈→ｅｘ〉（ｔ）］にＥｖａｌが完了  Ｅｖａｌが時刻ｔ：［→ｅｘ（ｔ）］に始まる  （５．１５）
時刻ｔ：〈ｘ：Ｃ？（）〉（ｔ）にＥｖａｌが完了：  Ｅｖａｌが時刻ｔ：ｘ：Ｃ？（）（ｔ１）に始まる：［→ｅｘ（ｔ）］  （５．１５）
評価子を名前ｘ、アクションｘ：Ａ（）、または条件ｘ：Ｃ？（）に適用すると、新しいイベント（以下で説明）が発生し、それが今度は他の評価と他のイベントの発生の原因となる。そのため、→ａと→ｅとを因果関係と呼ぶ。それらは、非再帰的、非対称、および推移的である。評価はイベントを発生させるだけでなく、以下で説明するようにｃｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔも評価する。
【０３３３】
時間インスタンスについての注記：２つの時間インスタンスｔ１とｔ２とが比較不能なことがあり得るが、それはそれらが異なる評価子の互いに同期していないローカルクロックで計測されているからである。しかし、各クロック時刻はグローバル時刻への一意の１−１マッピングを有している。ｘ．ｔ１、ｙ．ｔ２を使用して２つの異なるオブジェクトｘとｙに関連付けられているローカル時間点を参照する。不等式（ｘ．ｔ１＜ｙ．ｔ２）はｘとｙの両方が同じセルに属している場合に、ｘとｙのローカル時間で成立する。そうでなければ、（ｘ．ｔ１＜ｙ．ｔ２）は時間点ｘ．ｔ１とｙ．ｔ２の指定されたグローバルクロック内のグローバル時間へのマッピングにのみに相対的に成立する。５〜６個のローカルクロック時間点は同じグローバル時間点にマッピングすることが可能で、したがって、５〜６個のイベントが異なる別個のセルで各々が異なるローカル時刻で、しかし全てが同じグローバル時刻で発生する。全ての時間点は整数＞０にマッピングされる別個の時間点である。
【０３３４】
アクセス評価：前述のように、表記ｘ（ｔ）を評価子が世界状態ＷＳ（ｔ）からトリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））を取得するイベントを示すために使用している。明らかに評価子Ｅはｘに、それに対するアクセス権、つまりｘ∈Ｅｃ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）、を有していた場合にだけアクセスできる。したがって、評価子がｘにアクセスすると、閉包、［ｘ：ｎａｍｅｓ（）］内の全ての名前にアクセスできることになる。以下では、評価子→ａと→ｅを定義する。必要に応じて評価を行う評価子を明示的に指すように、Ｅ→ａとＥ→ｅと書く。アクセス評価はここで以下のように定義できる。
【０３３５】
□∃（τ＞０）［｛（ｘ，Δｘ）∈ＷＳ（ｔ）＆ｘ∈Ｅ．ｈａｓＡｃｃｅｓｓＴｏ（ｔ）｝［Ｅ→ａｘ（ｔ）］
｛ＷＳ（ｔ）＝ＷＳ（ｔ＋τ）＆ｘ（ｔ＋τ）｝］、ここで
ｘ（ｔ＋τ）＝［〈ｘ，Δｘ，ｘｉｅｖａｌ（）〉∈Ｅ．ａｃｃｅｓｓｅｄＩｔｅｍｓ）（ｔ＋τ）＆
（［ｘ：ｎａｍｅｓ（）］⊂Ｅ．ｈａｓＡｃｃｅｓｓＴｏ）（ｔ＋τ）］  （５．１７）
アクセスを完了するには何らかの時間τ＞０が常にかかる。アクセスが成功すれば、それによってイベントｘ（ｔ＋τ）がｔｒｕｅになる。ここで、アクションは世界状態ＷＳを変化させることはなく、ローカル状態Ｅだけが変化する。ｘが時刻（ｔ＋τ）にいったんアクセスされると、（ｘ，Δｘ，ｘ：ｅｖａｌ（））がＥ．ａｃｃｅｓｓｅｄＩｔｅｍｓに時刻（ｔ＋τ）に入り、Ｅは閉包〈［ｘ：ｎａｍｅｓ（）］＞（ｔ＋τ）内の全ての名前へのアクセス権を得る。（５．１７）の事前条件が満たされない場合は、アクセスの試みはφを返す。世界状態の述語は変更されない限り常にその真理値を保持しているという規約を使用するので、（５．１７）でフレームステートメントＷＳ（ｔ）＝ＷＳ（ｔ＋τ）を指定する必要は無い。ここで、評価子のローカル状態は世界状態とは別個であると仮定し、したがって、前述のようにトリプレット内のコンポーネントが関係構造を世界状態内で構成しても、Ｅ．ａｃｃｅｓｓｅｄＩｔｅｍｓに現れるトリプレットは世界状態には表れることがない。
【０３３６】
アクション評価：アクション評価、Ｅ→ｅは以下のように定義される：名前ｘについて、
［Ｅ→ｅｘ（ｔ）］＝［Ｅ→ａｘ（ｔ）］＝ｘ（ｔ）、またアクションｘ：Ａ（）については、（５．１８）
｛〈ｘ．Ａ：ｐｒｅＣ？（）＆∃（Ｓ）∀（ｙ∈Ｓ）［（Ｓ⊆ｘ．Ａ：ｗｏｒｌｄ（））＆
〈（（ｙ，Δｙ，ｙ：ｅｖａｌ（））∈Ｅ．ａｃｃｅｓｓｅｄＩｔｅｍｓ）〉（ｔ）］｝
Ｅ→ｅｘ：Ａ（．．．）（ｔ）］｛（ｘ．Ａ．ｏｕｔｐｕｔ（ｔ＋τ）＆ｘ．Ａ：ｐｓｔＣ？（）（ｔ＋τ）｝  （５．１９）
ここで、ｘ．Ａ：ｐｒｅＣ？（）は、ｘ．Ａ（）の事前条件の一部である。その他の部分は、ｘ．Ａ：ｗｏｒｌｄ（）の全ての必要な名前にアクセスしなければならないということである。同様に、ｘ．Ａ：ｐｓｔｃ？（）はアクションの事後条件の一部である。これは世界状態ＷＳのｘ：Ａ（）の実行によって発生する変更を指定する。事後条件のその他の部分は、ｘ．Ａ．ｏｕｔｐｕｔであって、Ｘ：Ａ（）によって生成された出力である。それはφの可能性もある。条件ｘ．Ａ：ｐｒｅＣ？（）と事前条件の全ての指定されたアクセスとはｘ：Ａ（）の評価が成功するにはｔｒｕｅでなければならない。評価は成功して世界状態（ｔ＋τ）で事後条件が成立すれば正しい。アクセスイベントと状態チェックの発生が世界状態を変更しないため、評価は事前条件がｔｒｕｅである同じ世界で実施することができる。このアクションの評価の文脈は、ｘ．Ａ：ｗｏｒｌｄ（）（ｔ）の部分集合Ｓである。
【０３３７】
以降では、上付き文字Ｅと下付き文字ａとｅとを、Ｅ→ａとＥ→ｅとで省略し、→ａは矢印に含まれると仮定し単に→と書く。定数Ｃについて、常に（→ｅＣ）＝（→ａＣ）＝δＣであって、既定で、何らかの定数が全ての世界状態に常に存在していることが暗示的に仮定されている。以降では、アクセス評価Ｅ→ａを参照する機会はない。
【０３３８】
ｐｔｈｒｅａｄはメソッドで、アクションの部分集合である。メソッドは４種類のプログラミングステートメント、宣言、割り当て、条件（ｉｆ−ｔｈｅｎ−ｅｌｓｅやｓｅｌｅｃｔｏＯｎｅなどのような）、およびｗｈｉｌｅループを使用して定義される。宣言によってコンテナとオブジェクトが生成／破壊され、新しく生成されたコンテナのコンテンツが設定され、トリプレット（ｘ，Δｘ，ｘ：ｅｖａｌ（））がメソッド、ｗｏｒｌｄ（）にコンパイル時／実行時に導入されたり削除されたりする。メソッド定義内の他のステートメントによってオブジェクトとコンテナが修正されたり、コンテンツがあるコンテナから別のコンテナに移動したり、名前の表示が変更されることがある。メソッドは、その実行中にｗｏｒｌｄ（）内のローカル状態だけを変更する。評価子はその実行の最後に、ローカル状態を使用して世界状態ＷＳ（ｔ）の整合性のある更新を実施する。ＷＳ（ｔ）は（５．１１）に定義されているように区分されているので、セルの分離（セクション３．２）はＷＳ（ｔ）に対する複数の並列の更新が並列に動作しているセルによって相互干渉無しに行われることを保証する。メソッドの定義に現れるプログラムステートメントの意味は容易に定義することができる。意図した意味を読者が知っていると仮定して、プログラムステートメントを非正式に使用する。プロトコルで使用されるＣＣＰの特徴を図１と２に示している。ｐｔｈｒｅａｄとプロトコルで使用されるほとんどのステートメントについて、ＴＩＣＣＴＭ−Ｐｐｄｅは所与の文脈において関連付けられている事前と事後の条件を自動的に生成することができるが、特定の事前条件とループ不変式の定義にはユーザ相互動作が必要なこともある。
【０３３９】
５．４．表記と定義：ＡＬＬＥＯＰノードの評価
セクション２でＡＬＬＥＯＰとトレースで発生するアクションと通信のイベントの例を見た。以下では、ＡｃｔｉｏｎＥｖｅｎｔクラスにシンボルＸ、Ｙ、Ｚを使用し、ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔクラスにシンボルＸ［ｔ（）］、Ｙ［ｔ（）］、Ｚ［ｔ（）］を使用する。これらのイベントクラスはＡＬＬＥＯＰノードを参照する。それらはＥｖｅｎｔと呼ばれるトップレベルクラスのサブクラスである。イベントインスタンスを示すためにシンボルＸ（ｔ）、Ｙ（ｔ）、Ｚ（ｔ）を使用し、Ｘ（ｔ）は時刻ｔに発生したインスタンスｘを示す（図６Ｂを参照）。ｘ（ｔ）がＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔサブクラス、Ｘ［ｔ（〈ｐｏｒｔ〉，＃）］のインスタンスの場合、ｔ∈ｔ（〈ｐｏｒｔ〉，＃）．ｘ（〈ｐｏｒｔ〉．ｔ＃）はトレース内の仮想時間点〈ｐｏｒｔ〉．ｔ＃＝ｔ（〈ｐｏｒｔ〉，＃）でのＸ［ｔ（〈ｐｏｒｔ〉，＃）］のインスタンスの発生を指す（たとえば、（２．１８）のトレースを参照）。アプリケーションの実行（ｒｕｎ）中に、ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔサブクラス、Ｘ［ｔ（〈ｐｏｒｔ〉，＃）］の複数のインスタンスがｃａｕｓａｌｎｅｔ内で発生することがある。そのｃａｕｓａｌｎｅｔ内でそれらのインスタンスが発生する時間点の集合は、アプリケーションのその実行についての厳密に増加する時間点のシーケンスｔ（〈ｐｏｒｔ〉，＃）＝〈ｐｏｒｔ〉．ｔ＃を構成する（図６Ｃを参照）。
【０３４０】
通信イベント：セクション２で使用された「送信」コマンドの「転送」バリエーションを以下で導入する。以下では、ｐ，ｑ＝（ｇ｜ｆ），ｐ≠ｑである。
【０３４１】
ｐＤ［ｔ（ｑ，＃）］：ポートｑによってｔ（ｑ，＃）内の時間点においてポートｐにメッセージが配信される。
【０３４２】
ｐＳ［ｔ（ｐ，＃）］：ｐによってｔ（ｐ，＃）内の時間点においてメッセージが送信される。
【０３４３】
ｐＦ［ｔ（ｐ，＃）］：ｐによってｔ（ｐ，＃）内の時間点においてメッセージが転送される。
転送によって、受信したメッセージが（場合によっては何らかの修正を伴って）送信され、送信によって新規に作成されたメッセージが送信される。正確な区別はセクション６．２で説明する。以下では、［→ｐＳ｜Ｆ（ｔ０）］は時刻ｔ０に始まったポートｐでのメッセージ（送信｜転送）プロセスにおける第１のイベントを指し、［→ｐＳ｜Ｆ（ｔ１）］は時刻ｔ１（ｔ０＜ｔ１）でのそのイベントの終了を指す。以下の特徴がプロトコル実行とガード評価中のＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔ評価について成立する。
【０３４４】
∃［（ｔ０＜ｔ１）
１．｛〈ｇ：ｐＲ？（）〉（ｔ０）｝［→ｇＳ｜Ｆ（ｔ０）］｛〈ｇ．ｓｔａｔｅ＝Ｒ＆ｇ．ｉｎｐｕｔ＝ｃ｜ｆ〉（ｔ１）｝
２．｛〈ｆ．ｓｔａｔｅ＝Ｒ〉（ｔ０）｝［→ｆＤ（ｔ０）］｛〈ｆ．ｉｎｐｕｔ＝ｓ＆ｆ．ｓｔａｔｅ＝Ｒ〉（ｔｉ）｝
３．｛〈ｆ．ｉｎｐｕｔ＝ｓ〉（ｔ０）｝［→ｆ：ｍＲ？（）（ｔ０）］｛〈ｔｒｕｅ＆ｆ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝
４．｛〈ｆ．ｉｎｐｕｔ＝ｓ∨ｆ．ｓｔａｔｅ＝Ｓ〉（ｔ０）｝［→ｆ：ｐＲ？（）（ｔ０）］
｛〈ｔｒｕｅ＆ｆ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝］
５．｛〈ｇ．ｉｎｐｕｔ＝ｓ〉（ｔ０）｝［→ｇ：ｍＲ？（）（ｔ０）］
｛〈ｔｒｕｅ＆ｇ．ｉｎｐｕｔ＝φ＆ｇ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝
６．｛〈ｇ．ｉｎｐｕｔ＝ｓ∨ｇ．ｓｔａｔｅ＝Ｓ〉（ｔ０）｝［→ｇ：ｐＲ？（）（ｔ０）］
｛〈ｔｒｕｅ＆ｇ．ｉｎｐｕｔ＝φ＆ｇ．ｓｔａｔｅ＝Ｓ〉（ｔ１）｝］  （５．２０）
前述のステートメントはプロトコル実行の最初と最後に何が発生するかと、配信信号が検知された時に何が発生するかを記述している。行（１）は最初に、ポートｇの親セルが信号ｃ｜ｆをポートｇにｇがメッセージの送信の準備ができている場合に送信することを指定している。行（６）は、状態がＳの場合または入力がｓの場合にｇの準備ができることを示している。信号が送信された直後に、ポートｇの段階がＲに変化し、ｇ．ｉｎｐｕｔがｃ｜ｆに等しくなる。状態Ｒの間は、ｇは第２の信号を送信できない。同様に、行（２）はプロトコル実行においてメッセージ配信の時刻に何が発生するかを記述しており、ここで「→ｆＤ（ｔ０）」はポートｆでの配信イベントである。これは時刻ｔ０で始まり、時刻ｆ．ｉｎｐｕｔ＝ｓがｔｒｕｅになった時に終了する。行（３、４、５、および６）はポートｆとｇの既に配信されている信号が後に検知された時に何が発生するかを記述している。ただし、行（５と６）で、ｇ．ｉｎｐｕｔがφにリセットされる。したがって、配信された信号は、ポートｇで１度だけ検知される。前述のように、このリセットｇ．ｉｎｐｕｔ＝φは、ｇｅｎｅｒａｌＰｏｒｔベクトルに属しているｇｅｎｅｒａｌＰｏｒｔについては発生しない。全ての場合において、信号の検知後に、ポートは状態Ｓになり、それによってポートの親セルがそのポートのｖｉｒｔｕａｌＭｅｍｏｒｙ内のデータにアクセスできるようにする。ポートが信号の送出の準備がいったんできると、行（１）と行（３）で定義しているように信号が送出されるまで準備できた状態のままである。
【０３４５】
ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔの評価については他の解釈がある。ＳＭＳ（セクション７）はイベント評価を使用して、ＡＬＬＥＯＰノードのインスタンスをアプリケーションの実行（ｒｕｎ）中にアプリケーションの拡大しているｃａｕｓａｌｎｅｔにインストールする。これは、以下の（５．２１）と（５．２２）で定義されている。図１９はイベント構築セルｅｂを示している。ｅｂが評価子、→をＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔに適用すると、ｅｂはそのイベントのインスタンスを特定に時間点で作製し、それをｃａｕｓａｌｎｅｔにインストールする。各ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔはそれに関連付けられている２つの時間点を有しており、一方はイベント自体が発生した時間（これは重要）で、他方はそのインスタンスがｃａｕｓａｌｎｅｔ内にインストールされる時間（これは重要ではない）である。これら２つの時間点の使用を以下で説明する。
【０３４６】
以下の（５．２１）と（５．２２）において、［ｅｂ．ｆ１，ｅｂ．ｆ２］は図１９のイベントビルダーセルｅｂのポートベクトルであって、Ｃｉ．ｇｉとＣｊ．ｇｊ、０≦ｉ＜ｎ、０≦ｊ＜ｍとはメッセージを交換するポートである。セルＣｉはメッセージを送信し、それをポートＤｊ．ｆｊに転送するためにＣｉ．ｇｉでプロトコルを評価する。このプロトコルの実行はＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔ、Ｃｉ．ｇｉＳ（ｔＳ）と〈Ｄｊ．ｆｊＤ〉（ｔｄ）の評価のきっかけとなり、ここでｔＳはメッセージ送信が始まった時刻であり、ｔｄはメッセージ配信が完了した時刻である。前述のＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔの評価が以下のように定義される。
【０３４７】
□[∃（ｔ１＜ｔ２）∃（ｔｓ＜ｔｄ）]
｛〈ｅｂ．ｆ１：ｍＲ？（）＆ｅｂ．ｆ２：ｍＲ？（）〉（ｔ１）｝
［→（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））（ｔ１）］
｛〈Ｃｉ．ｇｉＳ（ｔＳ）＆〈Ｄｊ．ｆｊＤ〉（ｔｄ）〉（ｔ２）｝  （５．２１）
プロトコル実行（ｒｕｎ）中に、ｅｂセルにＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔのインスタンス（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））を生成するように指示する信号がポート［ｅｂ．ｆｌ，ｅｂ．ｆ２］に送信される。これがどのように行われるかをセクション７で説明する。（５．２１）において、ｅｂはポート［ｅｂ．ｆｌ，ｅｂ．ｆ２］で時刻ｔ１に受信した信号の検知を完了する。これはｅｂが（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））の評価を開始する時刻でもある。これによって、イベントインスタンス（Ｃｉ．ｇｉＳ（ｔＳ）、〈Ｄｊ．ｆｊＤ〉（ｔｄ））が時刻ｔ２にｃａｕｓａｌｎｅｔ内にインストールされる。ここで、ｔＳはＣｉ．ｇｉＳによって送信された信号に対応する調和した信号が経路内のエージェントによって転送される時刻であって、ｔｄは同期した配信信号がＤｊ．ｆｊＤにおいて送信される時刻である。
【０３４８】
□[∃（ｔ１＜ｔ２）∃（ｔｓ＜ｔｄ）]
｛〈ｅｂ．ｆ１：ｍＲ？（）＆ｅｂ．ｆ２：ｍＲ？（）〉（ｔ１）｝
［→（Ｄｊ．ｆｊＳ（ｔＳ）、〈Ｃｉ．ｇｉＤ〉（ｔｄ））（ｔ１）］
｛〈Ｄｊ．ｆｊＳ（ｔＳ）＆〈Ｃｉ．ｇｉＤ〉（ｔｄ）〉（ｔ２）｝  （５．２２）
（５．２２）は応答メッセージ送信のためにｃａｕｓａｌｎｅｔ内にインストールされたイベントを記述している。以降ではイベントが発生した時間点だけをＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンスに関連付け、インスタンスがｃａｕｓａｌｎｅｔ内にインストールされた時間点は示さない。これは、時間点をＡｃｔｉｏｎＥｖｅｎｔインスタンスに関連付ける方法と整合している。
【０３４９】
Ｅｖｅｎｔクラスとイベントインスタンスの同等性：
（Ｘ＝Ｙ）⇔（Ｘ≡Ｙ）かつＸ［ｔ１（．．．）］＝Ｙ［ｔ２（．．．）］⇔（Ｘ≡Ｙ）＆（ｔ１（．．．）≡ｔ２（．．．））  （５．２３）
（Ｘ＝Ｙ）⇔（Ｘ≡Ｙ）かつＸ（ｔ１）＝Ｙ（ｔ２）⇔（Ｘ≡Ｙ）＆（ｔ１＝ｔ２）  （５．２４）
しがたって、Ｅｖｅｎｔクラスとイベントインスタンスとは定数の状態を有しており、それらは同一である場合にだけ等しい。しかし、イベントＸの評価は定数の評価とは異なる。
【０３５０】
同時性と並列性：ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔの並列評価は複数の評価子が使用された時に常に発生する。（５．２）に記述されているＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔ評価については、以下が成立する。
【０３５１】
（［Ｅ１→Ｘ［ｔ１（．．．）］］｜｜［Ｅ２→Ｙ［ｔ２（．．．）］］）⇔（Ｅ１≠Ｅ２）（５．２５）
（［〈Ｅ１→Ｘ（ｃ１．ｔ１）〉（ｃ２．ｔ２）］＆［〈Ｅ２→Ｙ（ｃ２．ｔ１）〉（ｃ２．ｔ２）］⇔
［（Ｅ１≠Ｅ２）＆（ＸＹ）＆（ＸＹ）＆Ｘ（ｃ１．ｔ２）＆Ｙ（ｃ２．ｔ２）
＆ｃ１．ｔ２∈ｔ１（．．．）＆ｃ２．ｔ２∈ｔ２（．．．）］  （５．２６）
（５．２５）において、ｔ１（．．．）とｔ２（．．．）はＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔが２つの異なる評価子において発生する２つのタイムマップである。評価はローカル時間点ｃ１．ｔ１とｃ２．ｔ１で２つの評価子内で始まり、ｃ１．ｔ２とｃ２．ｔ２でそれぞれ完了し、ｃ１．ｔ１＜ｃ１．ｔ２かつｃ２．ｔ１＜ｃ２．ｔ２である。ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンスＸ（ｃ１．ｔ２）とＹ（ｃ２．ｔ２）は評価が完了した時間点で発生する。２つの評価が発生した時間間隔［ｃ１．ｔ１，ｃ１．ｔ２）と[ｃ２．ｔ１，ｃ２．ｔ２]はグローバル時間において重なることもある。一般に、２つの評価が始まったローカル時間点の対（ｃ１．ｔ１，ｃ２．ｔ１）と評価が完了した（ｃ１．ｔ２，ｃ２．ｔ２）は比較不能、つまりそれらは任意の順番に発生することがある。そして並列評価は（〈→Ｘ〉（ｃ１．ｔ２）｜｜〈→Ｙ〉（ｃ２．ｔ２））と書かれる。２つのイベントが同期していたり、調和していたりする場合、グローバル時間においてｔ１（．．．）≡ｔ２（．．．）かつｃ１．ｔ２＝ｃ２．ｔ２である。そして並列評価は［→〈（Ｘ｜｜Ｙ）〉（ｃ１．ｔ２＝ｃ２．ｔ２）］と書かれる。同様な並列評価がＡｃｔｉｏｎＥｖｅｎｔでも発生する。唯一の違いは、タイムマップがＡｃｔｉｏｎＥｖｅｎｔには関連付けられていないが、仮想時間点がＡｃｔｉｏｎＥｖｅｎｔクラスには関連付けられており、評価（インスタンス）が発生する時間点が指定され、所与のＡｃｔｉｏｎＥｖｅｎｔクラスは複数のインスタンスを時間点の厳密に増加するシーケンス内の異なる時刻に有していてもよい。
【０３５２】
因果：以下では、ＸとＹはＥｖｅｎｔサブクラスである。評価子の記号、→を以下の意味で因果記号として使用し、イベントの発生は１つまたは２つ以上の他のイベントを発生させ、「Ｘ→Ｙ」は「ＸはＹの原因」と読み、ＸＣ（Ｘ，Ｙ）→Ｙを条件Ｃ（Ｘ，Ｙ）がｔｒｕｅの場合「ＸはＹの原因」と読む。
【０３５３】
Ｘ→Ｙ⇔□［∀（ｔ）∃（τ＞０）（Ｘ（ｔ）⇔Ｙ（ｔ＋τ）＆τ≦τｍａｘ（Ｘ，Ｙ）］  （５．２７ａ）
ＸＣ（Ｘ，Ｙ）→Ｙ⇔□［∀（ｔ）∃（τ＞０）（Ｘ（ｔ）⇔
Ｙ（ｔ＋τ）＆〈Ｃ（Ｘ，Ｙ）〉（ｔ＋τ）＆τ≦τｍａｘ（Ｘ，Ｙ）］  （５．２７ｂ）
Ｘ→φ≡ＳＴＯＰ（何も起こらない）  （５．２８）
ここでτｍａｘ（Ｘ，Ｙ）は２つのイベントインスタンスの発生の間の最大許容可能遅延である。
【０３５４】
直接の因果：
Ｘ→Ｙ⇔［（Ｘ・→Ｙ）∨∃ｅ（Ｘ・→e→Ｙ）］  （５．２９）
Ｘ・→Ｙ⇔¬∃ｅ（Ｘ・→ｅ→Ｙ）  （５．３０）
（５．３０）のＸ・→ＹにおいてＸとＹとの間にはイベントは発生しない。したがって、評価子・→は分割不可能、つまり割り込みできない。
【０３５５】
５．５．因果チェーンとリファイン
因果チェーン：
□［Ｘ→．．．→Ｙ⇔（（Ｘ→Ｙ）｜∃（Ｚ）（Ｘ→Ｚ→．．．→Ｙ））］  （５．３１）
□［（Ｘ◇Ｙ）⇔（Ｘ→Ｙ）∨（Ｚ）（（Ｘ→Ｚ）⇒（Ｚ◇Ｙ））］  （５．３２）
【０３５６】
直接の因果チェーン：
Ｘ・→．．．・→Ｙ⇔（（Ｘ・→Ｙ）｜∃（Ｚ）（Ｘ・→Ｚ・→．．．・→Ｙ））
□演算子は（５．３３）でのように省略されていても仮定しなければならない。ｐｔｈｒｅａｄやプロトコルの実行内のイベントの因果チェーン（または直接の因果チェーン）はステートメント（５．３１）と（５．３３）のいずれかの側の選択肢に分岐し、（４．５）、（４．６）、（４．１４）、（４．１６）および（７．４）に示しているように、異なる終端イベントを引き起こす。フォークがプロトコル実行に発生すると、図６のダイアグラムに示しているように、因果チェーンは１つの共通のＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔに最終的にジョインする並列な分岐を含むことになる。これは以下で導入する全てのリファインで成り立つ。便宜上、以下の説明では並列直接因果チェーンを使用する。因果チェーンは全ての場合に選択肢のある分岐および／またはフォークを含んでいることを仮定している。
【０３５７】
→のリファイン：
ＲｅｆｉｎｅｍｅｎｔＯｆ（Ｘ→Ｙ）＝
［（Ｘ・→Ｙ）∨∃（ｅ）（Ｘ・→ＲｅｆｉｎｅｍｅｎｔＯｆ（ｅ→Ｙ））］  （５．３４）
（Ｘ→Ｙ）のリファインは（Ｘ→Ｙ）＝（Ｘ・→ｅ１・→ｅ２・→．．．・→ｅｎ・→Ｙ）のような直接因果チェーン、ｅ１・→ｅ２・→．．．・→ｅｎである。εｉ＝ｅｉ１・→ｅｉ２・→．．．・→ｅｉｋ（ｉ）、０≦ｉ≦ｎを指すためにεｉを使用する場合、ｎ≧０について一般的な場合は以下のようになる。
【０３５８】
ＲｅｆｉｎｅｍｅｎｔＯｆ［（Ｘ→（Ｙ０｜Ｙ１｜．．．｜Ｙｎ）］＝
［（Ｘε０Ｙ０）｜（Ｘε１Ｙ１）｜．．．｜（ＸεｎＹｎ］、  （５．３４ａ）
ＲｅｆｉｎｅｍｅｎｔＯｆ［（Ｘ→（Ｙ０｜｜Ｙ１｜｜．．．｜｜Ｙｎ）］＝
［（Ｘε０Ｙ０）｜｜（Ｘε１Ｙ１｜）｜．．．｜｜（ＸεｎＹｎ］、  （５．３４ｂ）
ここでεｉ、０≦ｉ＜ｎは、直接因果チェーンであって、シンボル「｜」が選択肢を指定しており、シンボル「｜｜」は並列因果チェーンを分離している。
【０３５９】
ｐｔｈｒｅａｄとプロトコル：プロトコルの終端イベントはプロトコル実行中の信号交換によって常に一意に定められる。ポートｐからポートｑへのメッセージ送信のリファインは、以下の形態である（便宜上、以下の全てのステートメントではリニアリファインを仮定している）。
【０３６０】
ｐＳ［ｔ１（．．．）］→ｑＤ［ｔ２（．．．）］＝ｐＳ［ｔ１（．．．）］・→プロトコル・→ｑＤ［ｔ２（．．．）］＝
ｐＳ［ｔ１（．．．）］・→ｅｃ０・→ｅｃ１・→．．．・→ｅｃｋ・→ｑＤ［ｔ２（．．．）］  （５．３５）
これは、ポートｐのプロトコル内のＣＣＰと他のＡｃｔｉｏｎＥｖｅｎｔの割り込み不能シーケンスである。配信されたメッセージが検知された後で、応答メッセージがセルＣによって送信される前に実行されるｐｔｈｒｅａｄのリファインは以下の形態を有することになる。
【０３６１】
Ｃ．ｐ：ｍＲ？（Ｃ．ｐＤ［ｔ１（．．．）］・→ｐｔｈｒｅａｄ・→Ｃ．ｐＳ［ｔ２（．．．）］＝
Ｃ．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｅｐ０・→ｅｐ１・→．．．・→ｅｐｎ・→Ｃ．ｐＳ［ｔ２（．．．）］＝  （５．３６）
これはＡｃｔｉｏｎＥｖｅｎｔの割り込み不能シーケンスでもある。これはｐｔｈｒｅａｄ実行中に発生する。以下のリファイン
Ｃ１．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｐｔｈｒｅａｄ・→Ｃ１．ｐＳ［ｔ２（．．．）］
・→プロトコル・→Ｃ２．ｑＤ［ｔ３（．．．）］  （５．３７）
は、Ｃ１．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｅｐ０・→ｅｐ１・→．．．・→ｅｐｎ・→Ｃ１．ｐＳ［ｔ２（．．．）］・→ｅｃ０・→ｅｃ１・→．．．・→ｅｃｋ・→Ｃ２．ｑＤ［ｔ３（．．．）］の形態を有しており、ＡＬＬＥＯＰにおいて、以下のように書かれるが、
Ｃ１．ｐ：ｍＲ？（Ｃ１．ｐＤ［ｔ１（．．．）］・→ｅｐ０・→ｅｐ１・→．．．・→ｅｐｎ
Ｃ１．ｐＳ［ｔ２（．．．）］→Ｃ２．ｑＤ［ｔ３（．．．）｜｜．．．）］｝  （５．３８）
それはプロトコルのリファインがＡＬＬＥＯＰにおいては示されていないためである。
【０３６２】
同期：同期した並列フォークは以下で発生する。ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔのインスタンスＺ１とＺ２は（５．３９）において同時に発生する。
【０３６３】
［（Ｘ→Ｚ１［ｔ１（．．．）］）］｜｜Ｘ→Ｚ２［ｔ１（．．．）］＝Ｘ→（Ｚ１｜｜Ｚ２）［ｔ１（．．．）］
⇔∀（ｔ）∃（τ＞０）（［Ｘ（ｔ）⇔（Ｚ１（ｔ＋τ）｜｜Ｚ２（ｔ＋τ））、ｔ１＋τ∈ｔ１（．．．）（５．３９）
【０３６４】
同期フォークの一般化：
Ｘ→（Ｚ１｜｜Ｚ２｜｜．．．｜｜Ｚｎ）［ｔ（．．．）］  （５．４０）
【０３６５】
調和：並列調和が以下で発生する。
（［Ｘ［ｔ１（．．．）］｜｜Ｙ［ｔ２（．．．）］）→Ｚ［ｔ３（．．．）］）⇔
∀（ｔ１，ｔ２，ｔ３）∃（τ＞０）（ｔ１∈ｔ１（．．．）＆ｔ２∈ｔ２（．．．）＆ｔ３∈ｔ３（．．．））＆
［Ｘ（ｔ１）＆Ｙ（ｔ２）］⇔Ｚ（ｔ３＝ｍａｘ（ｔ１，ｔ２）＋τ）  （５．４１）
ここで、イベントＸとＹは異なる比較不能時刻に発生する可能性があり、ｍａｘ（ｔ１，ｔ２）はローカル時間のグローバル時間へのマッピングに相対的に定義される。ＺはＸとＹの両方がそれぞれのタスクを完了した後で初めて発生する。
【０３６６】
調和の一般化：ここで、イベントＺ［ｔ（．．．）］は全てのイベントＸ１、Ｘ２、．．．、Ｘｎが既に発生している場合にだけ発生する。
【０３６７】
（Ｘ１［ｔ１（．．．）］｜｜Ｘ２［ｔ２（．．．）］｜｜．．．｜｜Ｘｎ［ｔｎ（．．．）］）→Ｚ［ｔ（．．．）］  （５．４２）
【０３６８】
調和と同期の一般化：イベントＺ１、Ｚ２、．．．ＺｎはイベントＸ１、Ｘ２、．．．、Ｘｎがすべて発生した後に、すべて同時に発生する。
【０３６９】
（Ｘ１［ｔ１（．．．）］｜｜Ｘ２［ｔ２（．．．）］｜｜．．．｜｜Ｘｎ［ｔｎ（．．．）］）→（Ｚ１｜｜Ｚ２｜｜．．．｜｜Ｚｎ）［ｔ（．．．）］  （５．４３）
【０３７０】
イベントの選択肢：（Ｘ｜Ｙ）、ＸまたはＹのいずれかが発生する。
【０３７１】
一般化された選択肢：（Ｘ１｜Ｘ２Ｕ｜．．．｜Ｘｎ）  （５．４４）
ここでＸｉは因果チェーンであってもよい。イベント選択肢表現における選択は、常に対が互いに排他的でなければならない。
【０３７２】
ガードとポーリング：ガードは図１と２に定義しており、ポーリングの例は（２．７）から（２．１０）に示している。図１と２に示しているように、検知によってポートの状態が変化する。これは、条件の評価は世界状態を変化させないという一般規則の例外である。ＴＩＣＣＴＭ−Ｐｐｄｅの動作に対する以下の制限がポーリングに関連している。
【０３７３】
□［∀（Ｐｏｒｔｓ  ｐ）∀（Ｐｏｒｔｓ  ｑ）（（ｐ≠ｑ）＆（ｐ：ｐａｒｅｎｔ（）＝ｑ：ｐａｒｅｎｔ（）））
⇒¬（∃（ｔ）（［・→ｐ：ｍＲ？（）（ｔ）］＆［・→ｑ：ｍＲ？（）（ｔ）］））］  （５．４５）
また、他のガードについても同様である。したがって、セルはそのポートの２つのポーリングを同時に開始したり終了したりしない。セルにおいては並列性または時間スライスの並行性は存在しない。全ての割り込みはトランザクションの完了の要件に反することにないプログラムされた割り込みである。セルのポーリングサイクルでポートのポーリングがいったん始まると、以下の７つの考える結果が各ポートで発生し、それらは、（ｉ）ポートはメッセージが存在しないためスキップされる、（ｉｉ）セルはメッセージを待ち、それから，以下の項目（ｖ）と（ｖｉ）または（ｖｉｉ）のようにそれを処理する、（ｉｉｉ）ポートベクトルの場合は、ポートベクトルの全てにポートにメッセージが存在する場合、セルは（ｖ）と（ｖｉ）または（ｖｉｉ）を実行し、そうではない場合、ポートベクトルをスキップする、（ｉｖ）ポート選択肢の場合は、いずれか１つのポート選択肢にメッセージが存在する場合、セルは（ｖ）と（ｖｉ）または（ｖｉｉ）を実行し、そうではない場合、ポート選択肢をスキップする、（ｖ）ポート（またはポートベクトル）にメッセージが存在する場合、セルはセルのｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ内にそれを追加することによって、ポート（またはポートベクトル）のサービスをスケジュールする、（ｖｉ）セルはメッセージの検知後即座にポート（またはポートベクトル）のサービスを行う、または（ｖｉｉ）サービスのプログラムされたサスペンドが発生し、サービスは次のポーリングサイクルでレジュームする、である。
【０３７４】
世界状態の一貫性：各世界状態Ｗ（ｔ）は時刻ｔの計算の状態を表している。任意の時間点ｔにおいて、世界状態Ｗ（ｔ）は一貫している。証明システムは世界状態を維持しＥＣＴ評価中の仮定された時間点で更新する。ＥＣＴ評価中（図６に示している）にＣＴＬ表明とＥＣＴとの間に矛盾を検出した場合、表明は有効ではない。そのような矛盾は、設計または実装のエラーを示す。ＳＭＳによるｃａｕｓａｌｎｅｔ生成中に遭遇するＡＬＬＥＯＰの矛盾はシステム動作のエラーを示している。
【０３７５】
・→上での条件の移行：フォーマット「→Ｃ？（）｛Ｘ｝」、Ｘは通信またはアクションイベント、をＡＬＬＥＯＰフォーマットと呼び、フォーマット、
「｛〈ｐｒｅ−Ｃ？（）＆Ｃ？（）〉（ｔ０）｝［→Ｘ（ｔ０）］
｛〈Ｘ．ｏｕｔｐｕｔ＆ｐｓｔ−Ｃ？（））（ｔ１）｝」、ｔ１≦ｔ０＋τｍａｘ、
をトレースフォーマットと呼ぶ。後者はＣ？（）｛Ｘ｝の構文を記述している。実行は半閉間隔［ｔ０，ｔ１）の時間点の間であって、τｍａｘは最大の許容可能遅延である。以下では、条件の評価は、世界を変えず、アクションは事前条件がｔｒｕｅになる時刻ｔ０において同じ世界において評価されると仮定し、ガードはこの規則から除外される。以下の（５．４６）の文脈ｘとｙはセルＣまたはポートＣ．ｐのいずれかである。全ての状態チェックとアクション評価とは１つのセルＣの文脈で発生する。ｘ：ｎａｍｅｓ（）（ｔ）⊆Ｃ：ｎａｍｅｓ（）（ｔ）が成立する。この文脈は、その中に、メソッドの評価中に評価子によって維持されている変数のローカルコード実行スタックを有している。
【０３７６】
［∃（ｔ１）∃（ｔ２）∃（τ１＞０）∃（τ２＞０）
｛〈ｘ．Ａ１：ｐｒｅ−Ｃ１？（）＆ｘ：Ｃ？（）〉（ｔ１）｝
［・→ｘ：Ａ１（）（ｔ１）］｛〈ｚ１＆ｘ．Ａ１：ｐｓｔ−Ｃ１？（））（ｔ１＋τ１）｝
｛〈ｙ．Ａ２：ｐｒｅ−Ｃ２？（）＆ｙ：Ｃ？（）〉（ｔ２）｝
［・→ｙ：Ａ２（）（ｔ２）］｛〈ｚ２＆ｙ．Ａ２：ｐｓｔ−Ｃ２？（）〉（ｔ２＋τ２）｝
⇔（ｔ２＝ｔ１＋τ１）＆（（ｘ．Ａ１：ｐｒｅ−Ｃ１？（）⇒ｙ．Ａ２：ｐｒｅ−Ｃ２？（））（ｔ２））］  （５．４６）
前述のように、アクション評価はそのｐｒｅ−Ｃ１？（）がｆａｌｓｅである場合に未定義であって、Ｃ？（）がｆａｌｓｅである場合にスキップされる。・→でリンクされている２つの連続しているアクションｘ：Ａ１（）とｙ：Ａ２（）の実行中に、ｙ：Ａ２（）の実行はｘ：Ａ１（）の実行の終了と同時に始まり、さらに、事後条件ｘ．Ａ１（）はｙ：Ａ２（）の事前条件を論理的に意味する。Ａ１が終了する時刻とＡ２が始まる時刻との間にはわずかな遅延が通常存在する。しかし、この遅延中にセルＣの世界は変化しないが、それはセルＣ内で２つのそのようなアクションの間に他のアクションが発生しないからで、また、他のセルで発生するアクションはセルＣの状態には影響しないが、それはセルの分離のためである（セクション３．２）。したがって、この遅延は無視される。
【０３７７】
ポーリングサイクルにおいて、（Ｃ．ｆ［ｉ］：ｍＲ？（）→Ｃ．ｆ［ｊ］：ｍＲ？（））、ｉ≠ｊのフォーマットの指定を使用した。これは、以下の意味において、（Ｃ．ｆ［ｉ］：ｍＲ？（）・→．．．・→Ｃ．ｆ［ｊ］：ｍＲ？（））と解釈される。
【０３７８】
∃（ｔ０＜ｔ１＜ｔ２＜ｔ３＜ｔ４）
（｛Ｃ．ｆ［ｉ］：ｍＲ？（）（ｔ０）／＊始まる＊／＆〈Ｃ．ｆ［ｉ］：ｍＲ？（）〉ｔ（ｔ１）／＊終わる＊／｝
［・→Ｃ．ｆ［ｉ］：ｔｉｐ（）（ｔ１）／＊始まる＊／］［（・→Ｃ．ｆ［ｉ］：ｔｉｐ（））（ｔ２）／＊終わる＊／
（｛Ｃ．ｆ［ｉ］：ｍＲ？（）（ｔ２）／＊始まる＊／＆〈Ｃ．ｆ［ｉ］：ｍＲ？（）〉ｔ（ｔ４）／＊終わる＊／｝
［・→Ｃ．ｆ［ｉ］：ｔｉｐ（）（ｔ３）／＊始まる＊／］［（・→Ｃ．ｆ［ｉ］：ｔｉｐ（））（ｔ４）／＊終わる＊／  （５．４７）
言い換えると、Ｃ．ｆ［ｉ］とＣ．ｆ［ｊ］のサービスは、Ｃ．ｆ［ｊ］：ｍＲ？（）（ｔ２）、つまりＣ．ｆ［ｊ］：ｍＲ？（）の評価は［〈・→Ｃ．ｆ［ｉ］：ｔｉｐ（）〉］が終了した時に時間点ｔ２で始まるという制限の下で、（［ｔ１，ｔ２）∩［ｔ３，ｔ４））＝φであるように半閉区間間隔［ｔ１，ｔ２）と［ｔ３，ｔ４）で発生する。ここで、Ｃ．ｆ［ｉ］のサービスは、Ｃ．ｆ［ｉ］：ｍＲ？（）（ｔ０）がｔｒｕｅと評価された場合にだけ発生し、それ以外はポートはスキップされ、ポーリングは即座にＣ．ｆ［ｊ］に進む。したがって、ポーリングサイクルは、ポーリングの順序だけを指定し、ポーリングされるポートがサービスを受ける順序は指定しない。ＴＩＰの並列トリガは互いに連続しているが、それは通信がセクション２の例で記述されていたからで、唯一の要件は、メッセージが送信された時にメッセージを特徴付ける条件が、メッセージが配信され配信されたメッセージが検知され使用されるまで不変であることである。
【０３７９】
サンプルＡＬＬＥＯＰ証明を説明する例の考察に進む。全ての証明において、全てのｐｔｈｒｅａｄと条件の実装は既に個別に検証されていると仮定する。これは可能であるが、それは、ｐｔｈｒｅａｄは相互に独立しており、独立しているｐｔｈｒｅａｄは共に検証され、条件は常にセルに対してローカルだからである。［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］において紹介されている「装飾的庭の問題」の一般化されたバージョンから始める。正式なＡＬＬＥＯＰ証明が、「排他」と「条件同期」について、この例に対して示されている（［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］で使用されている用語）。解法は、［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］の「駐車場」問題にも当てはまる。
【０３８０】
６．ＡＬＬＥＯＰ証明を使用した例
６．１．装飾的庭：排他と条件同期
ここでの目的は、ＥＣＴネットワークの構造を表示し、証明を生成するためにそれらがシステムにどのように使用されるかを示すことである。装飾的庭の問題についてのＦＳＰ指定については、Ｍａｇｅｅ＆Ｋｒａｍｅｒ、［１３］を参照。問題は以下のとおりである。装飾的庭の公園は５〜６個のゲートを有しており各々が回転改札口を有している。ＭａｇｅｅとＫｒａｍｅｒでのように、公園の２つの端部の２つの入口のゲートを仮定するが、ＭａｇｅｅとＫｒａｍｅｒとは異なり、２つの出口のゲートも仮定する。ゲートは、公園が開いている時には開いており、入園者がすべて公園から帰った後で閉園している時には閉じている。開園している時にはいつでも、人々は任意の入口ゲートを通って入園し任意の出口ゲートを通って出園することができる。いつも庭にいる人の正確な数を保持している必要があり、数が予め定められている最大値を超えることは許されない。
【０３８１】
ＴＩＣＣＴＭネットワークを図１０に示している。それは、２つの入口回転改札口Ｅｔ［０］とＥｔ［１］と、２つの出口回転改札口Ｘｔ［０］とＸｔ［１］とを有している。外部割り込みに基づいて公演のゲートを開閉する１つの環境Ｅが存在する。１つのカウンタが存在する。人が入口または出口の回転改札口Ｔｉ［ｊ］とＸｔ［ｊ］、ｊ＝０、１に到着すると、センサＳｅ［ｊ］とＳｘ［ｊ］が人をそれぞれの回転改札口で検知すると仮定する。そのセンサと共に各回転改札口はカプセル化されているセルである。人を検知すると、センサはポートＥｔ［ｊ］．ｆｔまたはＸｔ［ｊ］．ｆｔ、ｊ＝０，１にそれらのそれぞれのｇｅｎｅｒａｌＰｏｒｔ、Ｓｅ［ｊ］．ｇまたはＳｘ［ｊ］．ｇを通して合図する。経路、Ｓｅ［ｊ］．ｇ⇔Ｅｔ［ｊ］．ｆｔとＳｘ［ｊ］．ｇ⇔Ｘｔ［ｊ］．ｆｔはカプセル化に対して内部である。センサはｆｕｎｃｔｉｏｎＰｏｒｔ、ｆｔ（ｔは回転改札口を表す）にこれらの隠蔽された経路を通して合図する。便宜上、図１０ではセンサを回転改札口の外側に示している。
【０３８２】
2012506076.tif 000011
【０３８３】
図１０：装飾的な庭の解法用のネットワーク：排他および条件同期
Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）およびＸｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）はポートＥｔ［ｊ］．ｆｔとＸｔ［ｊ］．ｆｔとがセンサによって送信された信号をそれぞれ検知した時にｔｒｕｅになる。これらの述語の定義は付録Ｉを参照。以下のＴＩＰは、センサが人を検知した時にカプセル化の内部で実行される。
【０３８４】
Ｓｅ．ｇ：ＴＩＰ（）＝Ｅｔ［ｊ］：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛Ｓｅ．ｇ：ｐＲ？（）＊｛Ｓｅ．ｇ：ｓ（）；｝｝
Ｓｘ．ｇ：ＴＩＰ（）＝Ｘｔ［ｊ］：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛Ｓｘ．ｇ：ｐＲ？（）＊｛Ｓｘ．ｇ：ｓ（）；｝｝  （６．１）
【０３８５】
カウンタは５つのｆｕｎｃｔｉｏｎＰｏｒｔ、Ｃ．ｆ［ｊ］、０≦ｊ＜５を有している。これらの式は以下のように使用される。
【０３８６】
ｊ＝０，１について：ポートＥｔ［ｊ］．ｆｔで信号を検知すると、回転改札口はカウンタに経路Ｅｔ［ｊ］．ｇ⇔Ｃ．ｆ［ｊ］（図１０を参照）を通して合図する。カウンタＣが信号をＣ．ｆ［ｊ］、０≦ｊ＜１で検知すると、以下を実行する。（ｉ）Ｃは、ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘの場合にカウンタを１だけ増加させ、Ｃ．ｆ［ｊ］⇔Ｅｔ［ｊ］．ｇを通してＥｔ［ｊ］にゲートの人が入るかもしれないことを通知し、Ｅｔ［ｊ］．ｇで信号を受信すると、回転改札口は鍵を解除し、Ｅｔ［ｊ］．ｆｔの人を公園に入れる。
（ｉｉ）ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＝ｍａｘの場合は、ＣはＣ．ｆ［ｊ］⇔Ｅｔ［ｊ］．ｆを通してＥｔ［ｊ］に公園が満員であることを通知し、Ｅｔ［ｊ］．ｆでの信号を受信すると、回転改札口は回転改札口の鍵を解除せずに「公園は満員」と表示する。これら２つの選択肢アクションの一方を実行するために、Ｅｔ［ｊ］は同期非決定的ポーリング∃（ｐ）（ｐ＝（Ｅｔ［ｊ］．ｇ｜Ｅｔ［ｊ］．ｆ））ｐ：ｍＲ？（））＊を実行し、したがってカウンタからの応答をこれらのポートの１つで待つ。
【０３８７】
ｊ＝２，３について：出口改札口、Ｘｔ［ｉ］．ｇ、ｉ＝０，１はそのポートＣ．ｆ［ｉ＋２］で経路Ｘｔ［ｉ］．ｇｏＣ．ｆ［ｉ＋２＝ｊ］を通してカウンタに合図する。Ｃ．ｆ［ｉ＋２］で信号を検知すると、カウンタはカウントを１つだけ減少させ、回転改札口の鍵を解除し、回転改札口を解錠して人を出園させるために経路Ｃ．ｆ［ｉ＋２］⇔Ｘｔ［ｉ］．ｇを通して合図する。Ｘｔ［ｉ］は、同期ポーリングＸｔ［ｉ］．ｇ：ｍＲ？（）＊を実行することによって、Ｘｔ［ｉ］．ｇでこの応答を待つ。ｊ＝４については、ポートＣ．ｆ［４］が表示ユニットからの要求を受信し、ｃｏｕｎｔｅｒ．ｃｏｕｎｔの現在の値をユニットに送信するためにカウンタによって使用される。表示ユニットはカウントに対する要求を外部割り込みに基づいて送信する（図１０を参照）。
【０３８８】
複数の人が複数の回転改札口を使用して同時に並列に入園したり出園したりすることがある。しかし、各回転改札口は、１度に１人しか入園または出園させない。プログラムは自己スケジューリング、自己調和、および自己同期している。ＴＩＣＣＴＭネットワークとＴＩＰとは実行制御構造を定める信号交換を定める。付録Ｉの装飾的庭の解法は、複数の駐車場入口と出口を備えており、車が出る前に駐車料金を払わなければならないことが異なる［Ｍａｇｅｅ＆Ｋｒａｍｅｒ，１３］で定義されている駐車場の例にも適用されることは明かである。
【０３８９】
信号交換とカウントにかかる時間は１キロの長さの１メガビット／秒の信号線と２ギガヘルツＣＰＵを仮定すると２〜３マイクロ秒未満でなければならない。したがって、実質的に無限の数の入口と出口の回転改札口を有することができる。このネットワークに基づいているＴＩＣＣＴＭ−Ｐｐｄｅ実装用のＣＩＰ、ＡＬＬＥＯＰ、およびトレースを付録Ｉに示している。これを装飾的庭の解法と呼ぶ。
【０３９０】
付録Ｉに示している実装を完成するには、ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）、ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）、ｄｅｎｙＥｎｔｒｙ（）、ｌｅｔＰｅｒｓｏｎｌｎ（）、ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）、ｐｅｒｓｏｎＩｎＰａｒｋ（）、およびｄｉｓｐｌａｙＣｏｕｎｔ（）を定義しなければならない。それによって、付録ＩのＡＬＬＥＯＰとトレースは完全な実装をモデル化する。実装は、モニタ、セマフォ［Ｈｏａｒｅ，１０，１２］［Ｄｉｊｋｓｔｒａ，２３，２４］、ロック、スケジューラ、または同期制御プリミティブを必要としない。
【０３９１】
この構成において、回転改札口によって呼び出される２つのカウンタアクティビティは互いに干渉しないが、それはカウンタが第１のｆｕｎｃｔｉｏｎＰｏｒｔのサービスが完了した後で初めて第２のｆｕｎｃｔｉｏｎＰｏｒｔをサービスするからであることは明かである。公園内の人の数はｍａｘを超えないことも明かである。実装が要件を満たすことを示すために実装の仕様からこれらを正式に証明したい。特に、以下を証明したい。
【０３９２】
ステートメント１）庭園に入る各人はカウンタに１回だけ加算される。
【０３９３】
ステートメント２）庭園を出る各人はカウンタから１回だけ減算される。
【０３９４】
ステートメント３）庭園内の人の合計はｍａｘを超えない。
ユーザは前述のステートメント１とステートメント２に対して以下の解釈をＣＴＬステートメントとして定義する。ＣＴＬステートメント内のイベントは、条件またはアクションのいずれかによって指定される。ＣＴＬステートメントの量化は、ステートメント内で発生する前提とする時間点、オブジェクト、およびイベントを対象とする。
【０３９５】
□［∃（ｃｔｌ．ｔ０＜ｃｔｌ．ｔ１＜ｃｔｌ．ｔ２＜ｃｔｌ．ｔ３）＆
（ｃｔｌ．ｔ４＜ｃｔｌ．ｔ５＜ｃｔｌ．ｔ６＜ｃｔｌ．ｔ７）＆
（（ｃｔｌ．ｔ２＜ｃｔｌ．ｔ５）｜（ｃｔｌ．ｔ６＜ｃｔｌ．ｔ２））
∃！（Ａ１＝ｃｏｕｎｔｅｒ＋＋）∃！（Ａ２＝ｃｏｕｎｔｅｒ−−）
ＥｎｔｅｒｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ＝
［｛〈ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）〉（ｃｔｌ．ｔ０）｝
→．．．→［〈・→Ａ１（ｃｔｌ．ｔ１）／＊開始する＊／〉ｃｔｌ．ｔ２）／＊終了する＊／］）
→．．．→｛ｐｅｒｓｏｎＩｎＰａｒｋ？（）（ｃｔｌ．ｔ３）｝］＆  （６．２）
ＬｅａｖｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ＝
｛〈ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｃｔｌ．ｔ４）｝
→．．．→［〈・→Ａ２（ｃｔｌ．ｔ５）／＊開始する＊／〉（ｃｔｌ．ｔ６）／＊終了する＊／］）
→．．．→｛ｐｅｒｓｏｎＩｎＰａｒｋ？（）（ｃｔｌ．ｔ７）｝］＆  （６．３）
付録Ｉの以下の定義を便宜上再掲載する。
【０３９６】
Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）
⇔Ｅｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｅｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｅ［ｊ］．ｇ，１）］）  （Ｉ．４）
Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）
⇔Ｘｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｘｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｘ［ｊ］．ｇ，１）］）  （Ｉ．１１）
前述のＣＴＬステートメントにおいて、ｃｌｔ．ｔ２は（６．２）においてカウンタの呼び出しが終了する時刻であって、ｃｌｔ．ｔ５は（６．３）においてカウンタの呼び出しが始まる時刻である。制限（ｃｔｌ．ｔ２＜ｃｔｌ．ｔ５）は、（６．３）のカウンタ呼び出しが（６．２）のカウンタ呼び出しの終了の後でなければならないことを表明している。同様に、（ｃｔｌ．ｔ６＜ｃｔｌ．ｔ２）は、他の可能性、つまり（６．３）の呼び出しの終了後に（６．２）の呼び出しが始まることを表明している。どちらも場合も、２つのステートメントにおいてカウンタがアクティブな半閉間隔、つまり［ｃｔｌ．ｔ１，ｃｔｌ．ｔ２）と［ｃｔｌ．ｔ５，ｃｔｌ．ｔ６）は重なってはならない。量化、∃！（Ａｌ＝ｃｏｕｎｔｅｒ＋＋）∃！（Ａ２＝ｃｏｕｎｔｅｒ−−）は、各ステートメントにおいて、カウンタイベントの一意の１回だけの発生があることを表明する。ｃｏｕｎｔｅｒ＋＋の各呼び出しはカウントを１だけ増加させ、ｃｏｕｎｔｅｒ−−の各呼び出しはカウントを１だけ減少させることをここで仮定している。したがって、（６．２）と（６．３）は、ゲートにいる人は、カウンタが１だけ１回だけ増加した後で始めて公園に入ることを許され、カウンタが１だけ１回だけ減少した後で始めて公園から出ることを許されることを表明している。（６．２）と（６．３）の開始と終了イベントは以下のとおりである。
【０３９７】
開始イベント    終了イベント
（６．２）において：〈ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）〉（ｃｔｌ．ｔ０）    ｐｅｒｓｏｎｌｎＰａｒｋ？（）（ｃｔｌ．ｔ３）
（６．３）において：〈ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｃｔｌ．ｔ４）    ¬ｐｅｒｓｏｎｌｎＰａｒｋ？（）（ｃｔｌ．ｔ７）
ただし、開始イベントが終了する時間点の対（ｃｔｌ．ｔ０，ｃｔｌ．ｔ４）と終了イベントが始まる時間点の対（ｃｔｌ．ｔ３，ｃｔｌ．ｔ７）とは比較不能である。したがって、人は同時に入園と出園とを行ってもよい。この例については、（６．２）と（６．３）の第２の省略→．．．→を◇に置き換えることによってステートメントの意味は変化しないが、それは各場合において、開始イベントから終了イベントに到達する道が１つだけであるためである。証明する問題は以下のとおりである。
【０３９８】
Ｔｒａｃｅｓ（横向きのＴ）ＥｎｔｅｒｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ＆ＬｅａｖｉｎｇＧａｒｄｅｎ−ＣｏｕｎｔｅｄＯｎｃｅ  （６．４）
ここでＴｒａｃｅｓは実装の全てのトレースの集合であって、（横向きのＴ）は論理的な帰結関係である。この点で、前述のＣＴＬの表明は、庭園にどれだけの入口と出口とがあるかは述べていない。これは、実装を分析することによって発見されるべきことである。このステートメントは公園の入口と出口の数に関わらず成立しなければならない。
【０３９９】
６．１．１．装飾的庭の解法のためのＥＣＴネットワーク
表Ｉ：入口のゲートのためのＥＣＴネットワーク
【０４００】
【表１】
2012506076.tif 000012
【０４０１】
ＥＣＴネットワークを表ＩとＩＩに示している。ポーリングサイクルとポートトレースについての情報がＥＣＴネットワークにおいて表形式に再構成されて示されており、ネットワークはＡＬＬＥＯＰに整合しているトレ―スの直列／並列の組み合わせを示している。ＥＣＴとトレースの両方が同じ情報を有している。読者が表ＩとＩＩの全ての詳細を理解することは期待していない。これら表の構造の概要を以下に示す。
【０４０２】
表ＩのネットワークはＥｔ［ｊ］とＣ．ｆ［ｊ］、ｊ＝０，１との間に相互動作を示しており、表ＩＩのネットワークはＸｔ［ｊ］とＣ．ｆ［ｊ＋２］、ｊ＝０，１との間に相互動作を示している。ネットワーク内の各ＥＣＴブロックでは、イベントは上から下へ時間的に昇順に第１の列に現れている。イベントは条件またはアクションのいずれかである。それらの関連付けられている仮想時間点が上から下へ昇順に第２の列に現れている。ＥＣＴブロック間の矢印を備えている有向分岐は、選択点に起因する選択肢を有することもある順次制御転送か、信号配信に起因する並列制御転送（フォーク）かのいずれかである。選択点に選択肢のある逐次制御転送を示している分岐は「｜」マークが付けられ、並列制御転送を示している分岐には「｜｜」が付けられている。例ではフォークは現れていない。「｜｜」で示されている分岐上の省略「→．．．→」は、分岐矢印の端のブロックの起動が信号の配信と同時には発生せずに、後に発生することがあることを示している。
【０４０３】
表Ｉの上部のブロックＥｔ［ｊ］．ｆｔ：ＥＣＴ（ｅ［ｊ］．ｔ０）は２つの選択肢のブロックに分岐する。これらの３つのブロックは併せて、Ｅｔ［ｊ］が人の入園を検知した時に何が発生するかを記述している。述語Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）は前述のように信号がＥｔ［ｊ］．ｆｔで受信されている時にだけｔｒｕｅである。Ｅｔ［ｊ］．ｆｔで信号を検知すると、Ｅｔ［ｊ］は人が入園できるかどうかをチェックするために信号をＥｔ［ｊ］．ｇを通してＣ．ｆ［ｊ］に送信し、入園できる場合はその人をカウントする。公園内の人の数が許容されるｍａｘに既に達している場合は、人は入ることはできない。この合図は表Ｉにおいて、ブロック１のイベント［〈・矢印Ｃ．ｆ［ｊ］Ｄ〉］からブロック４のイベント〈Ｅｔ［ｊ］．ｇ：ｍＲ？（）〉までの並列起動を指定する分岐によって表されている。
【０４０４】
【表２】
2012506076.tif 000013
【０４０５】
この信号の送信後、Ｅｔ［ｊ］は付録ＩのＴＩＰ（Ｉ．３）に示している同期非決定的ガード（Ｅｔ［ｊ］．ｇ：ｍＲ？（）｜Ｅｔ［ｊ］．ｆ：ｍＲ？（））＊で応答を待つ。応答信号が受信された時に発生する２つの可能な選択肢を表のブロック１の下部に示している。選択は応答信号がＥｔ［ｊ］．ｇまたはＥｔ［ｊ］．ｆのいずれで受信されたかに基づいて２つの選択肢の因果チェーンに分岐している。分岐している因果チェーンの両方は、ここではＥｔ［ｊ］．ｆｔでの動作の次のサイクルの逐次起動で終了する。Ｅｔ［ｊ］．ｆｔの後で始まる次のサイクルは応答信号をＳｅ［ｊ］．ｇをセンサポートに送信する。したがって、次の人は、現在の人が完全にサービスされた後に初めて認識される。処理は次の人がゲートに来た時に繰り返される。したがって、表Ｉの仮想時間点はイベントが発生する時間インスタンスのシーケンスを示している。ブロック１で開始したプロセスの完全な各サイクルは、表Ｉに示しているようにブロック５が信号をブロック２に送信した後か、ブロック６が信号をブロック３に送信した後で終了する。表Ｉのブロック４、５、および６はカウンタで何が発生するかを記述している。システムは以下で説明するようにこのネットワークからその証明に必要な情報を取り出す。
【０４０６】
表Ｉのブロック４はその内部に入る２つの起動矢印を有しており、一方は左側の∃（ｉ）Ｃ．ｆ［ｉ］から来る逐次起動であり、他方は右側のＥｔ［ｊ］．ｇから来る並列起動である。逐次起動は、ポートＣ．ｆ［ｊ］が他のポートＣ．ｆ［ｉ］でのサービスの完了後初めてサービスを受けることを示している。もちろん、ｉ＝ｊ、つまり次にサービスを受ける人が同じゲートを通って入園することも可能である。この逐次起動が行われる時刻は、Ｃに信号が配信されているかどうかをテストするために、Ｃ．ｆ［ｊ］：ｍＲ？（）を実行してＣ．ｆ［ｊ］をポーリングする時である。Ｃは配信された信号を逐次と並列の起動が一致した時にだけ検知することができる。
【０４０７】
Ｅｔ［ｊ］．ｇｊからの並列起動が到着する前にＣ．ｆ［ｉ］からの逐次起動が最初に来ると、Ｃ．ｆ［ｊ］での信号検知は失敗し、ＣはポートＣ．ｆ［ｊ］をスキップし、次のポートのポーリングを開始する（ポートをスキップする場合を表Ｉに示しておらず、仮定している）。Ｃがあるポーリングサイクルでポートをスキップすると、信号が存在すればその信号を次のポーリングサイクルで取得する。Ｅｔ［ｊ］．ｇからの並列起動が最初に来ると、ＣはＣ．ｆ［ｊ］のポーリング時に信号を検知する。いずれの場合にも、Ｃは起動信号に即座には応答しない。これを、表Ｉの並列起動分岐に省略によって示している。
【０４０８】
配信信号検知に対する逐次と並列の制御転送の一致のこの要件は親セルからそれらのポーリングサイクルにおいてポーリングされる全てのポートで成立する。逐次制御転送は信号検知が埋め込まれているＴＩＰで他のＴＩＰ実行の一部として発生する場合に明示的であって、埋め込まれているＴＩＰでの検知は同期ガードのみを使用する。
【０４０９】
Ｃ．ｆ［ｊ］で信号を検知した後に、Ｃは表Ｉのブロック４の最後の選択点に到達する。ここで、選択は（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）の真理値によって定まる。選択後の以降のイベントの因果チェーンは、（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）がｔｒｕｅかｆａｌｓｅかによってＥｔ［ｊ］．ｇまたはＥｔ［ｊ］．ｆのいずれかを並列起動する。Ｅｔ［ｊ］はこれらの並列起動のいずれか一方に即座に応答するが、それは、付録ＩのＴＩＰ（Ｉ．３）に示しているように、Ｅｔ［ｊ］．ｇとＥｔ［ｊ］．ｆで、非決定的ガード（Ｅｔ［ｊ］．ｇ：ｍＲ？（）｜Ｅｔ［ｊ］．ｆ：ｍＲ？（））＊で、これらの信号を待っているからである。
【０４１０】
そのタスクをＣ．ｆ［ｊ］で完了した後、Ｃは表Ｉの下部に示しているように∃（ｉ）ｃ．ｆ［ｉ］を逐次起動する。これは、付録Ｉに定義されているポーリングサイクルに続く。同様に、表ＩＩは出口回転改札口Ｘｔ［ｊ］とＣｆ［ｊ＋２］との間の相互動作に関連付けられているＥＣＴブロックを示している。読者は、証明に必要な情報だけを選択して、セクション６．１．２の証明の構築を説明する時に、これらの表のイベントの流れをたどることができる。この点で、読者に付録Ｉを参照するように提案する。
【０４１１】
まとめ：表ＩとＩＩのＥＣＴブロック間の逐次起動がネットワークにおけるイベントの実行の順序付けを表している。これらは、ポーリングサイクルとセル内でＴＩＰが実行される順序によって定まる。各ブロック内の上から下へのＥＣＴ内のイベントの流れはイベントの因果順序を表している。因果順序はＴＩＰ実行中のイベントの流れによって定まる。ネットワークは付録ＩのポートＡＬＬＥＯＰとポーリングサイクル定義に整合しているポートＥＣＴの逐次／並列構成を示している。
【０４１２】
６．１．２．ＡＬＬＥＯＰ証明の構造
証明システムはＥＣＴネットワークを探索し、（ｉ）ＣＴＬ表明において前提とされている時間点の間のマッチの対応を識別し、（ｉｉ）ＣＴＬ表明内の開始イベントから終了イベントまでのＥＣＴネットワーク内の因果チェーンを見つけ出し、（ｉｉｉ）主張が満足されていることを証明するために因果チェーンを分析する。この例では、探索は単純である。選択点と複数の並列起動（フォーク）のせいで発生する複雑さはない。そのような探索で発生する複雑さのいくつかはセクション６．４のＤＰ解法に現れる。
【０４１３】
証明システムは、ＣＴＬステートメント内に現れるイベントについて、ＣＴＬステートメントにおいて指定されたものと表ＩとＩＩのＥＣＴネットワーク内の仮想時間点との間の以下のマッチ時間点を表示する。
【０４１４】
ステートメント（６．２）についてのマッチ時間点、ｊ＝０，１
ｃｔｌ．ｔ０＝ｅｔ［ｊ］．ｔ０：Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）；（イベント開始）
ｃｔｌ．ｔ１＝ｃｆ［ｊ］．ｔ２：［・→ｃｏｕｎｔｅｒ＋＋］ｂｅｇｉｎｓ；
ｃｔｌ．ｔ２＝ｃｆ［ｊ］．ｔ３：［・→ｃｏｕｎｔｅｒ＋＋］ｅｎｄｓ；
ｃｔｌ．ｔ３＝えｔ［ｊ］．ｔ１：Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）；（イベント終了）  （６．５）
ステートメント（６．３）についてのマッチ時間点、ｊ＝０，１
ｃｔｌ．ｔ４＝ｘｔ［ｊ］．ｔ０：Ｘｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）；（イベント開始）
ｃｔｌ．ｔ５＝ｃｆ［ｊ＋２］．ｔ２：［・→ｃｏｕｎｔｅｒ＋＋］ｂｅｇｉｎｓ；
ｃｔｌ．ｔ６＝ｃｆ［ｊ＋２］．ｔ３：［・→ｃｏｕｎｔｅｒ＋＋］ｅｎｄｓ；
ｃｔｌ．ｔ７＝ｘｔ［ｊ］．ｔ１：¬Ｘｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）；（イベント終了）  （６．６）
（６．２）と（６．３）のイベントにそれぞれマッチする２つの可能性のある開始／終了イベントが存在し、（６．５）と（６．６）に示しているように、一方はｊ＝０についてであり、他方はｆ＝１についてである。システムはｊ＝０，１について（６．５）と（６．６）に対応するＥＣＴ内の開始イベントと終了イベントとの間の以下の因果チェーンも表示する。因果チェーンはトレースフォーマットで表される。
【０４１５】
［｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）〉（ｅｔ．ｔ０）｝［・→Ｓｅ．ｇＳ（ｓｅ［ｊ］ｇ．ｔ０）］
〈Ｅｔ［ｊ］．ｆｔ：ｍＲ？（〉Ｅｔ［ｊ］．ｆｔＤ〉（ｅ［ｊ］ｆｔ．ｔ０）））（ｅ［ｊ］ｆｔ．ｔ１）｝
［・→Ｅｔ［ｊ］．ｇＳ（ｅ［ｊ］ｇ．ｔ０）］［→〈Ｃ．ｆ［ｊ］Ｄ〉（ｅ［ｊ］ｇ．ｔ１＝ｃｆ［ｊ］．ｔ０）］
／／ここで並列起動が始まる
｜｜［・→．．．・→｛〈Ｃ．ｆ［ｊ］：ｍＲ？（）〉（ｃｆ［ｊ］．ｔ１）｝
｛（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）（ｃｆ［ｊ］．ｔ２）｝
［・→ｃｏｕｎｔｅｒ＋＋（ｃｆ［ｊ］．ｔ２）］
｛（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）（ｃｆ［ｊ］．ｔ３）｝
［・→Ｃ．ｆ［ｊ］Ｓ（ｃｆ［ｊ］．ｔ３）］・→
［〈→Ｅｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｇ．ｔ２）］・→．．．・→］
／／サービス要求を伴ってカウンタの次のポートまで続く
／／アクティビティはＣ．ｆ［ｊ］からの信号に応答してＥｔ［ｊ］でリジューム
｛〈Ｅｔ［ｊ］．ｇ：ｍＲ？（〈→Ｅｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｇ．ｔ２））＊〉（ｅ［ｊ］ｇ．ｔ２）｝
［・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）（ｅ［ｊ］ｇ．ｔ２）］
｛（Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（））（ｅｔ［ｊ］．ｔ１）｝
［・→Ｅｔ［ｊ］．ｆｔＳ（ｅｔ［ｊ］．ｔ１＜ｅ［ｊ］ｆｔ．ｔ２）］
［〈→Ｓｅ［ｊ］．ｇＤ）（ｅ［ｊ］ｆｔ．ｔ３）］］  （６．７）
ここで、入園が拒否された場合は無視するが、それはＣＴＬステートメントがそれを必要としないからである。
【０４１６】
［｛〈Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｘｔ．ｔ０）｝［・→Ｓｘ．ｇＳ（ｓｘ［ｊ］ｇ．ｔ０）］
〈Ｘｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｘｔ［ｊ］．ｆｔＤ〉（ｘ［ｊ］ｆｔ．ｔ０））〉（ｘ［ｊ］ｆｔ．ｔ１）｝
［・→Ｘｔ［ｊ］．ｇＳ（ｘ［ｊ］ｇ．ｔ０）］［→〈Ｃ．ｆ［ｊ＋２］Ｄ〉（ｘ［ｊ］ｇ．ｔ１＝ｃｆ［ｊ＋２］．ｔ０）］
｜｜［・→．．．・→｛〈Ｃ．ｆ［ｊ＋２］：ｍＲ？（）〉（ｃｆ［ｊ＋２］．ｔ２）｝
［・→ｃｏｕｎｔｅｒ――（ｃｆ［ｊ＋２］．ｔ２）］
｛〈ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ〉（ｃｆ［ｊ＋２］．ｔ３）｝
［・→Ｃ．ｆ［ｊ＋２］Ｓ（ｃｆ［ｊ＋２］．ｔ３）｝
［〈→Ｘｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｘ［ｊ］ｇ．ｔ２）］
｛〈Ｘｔ［ｊ］．ｇ：ｍＲ？（〈→Ｘｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｘ［ｊ］ｇ．ｔ２））＊〉（ｅ［ｊ］ｇ．ｔ２）｝
［・→Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）（ｘ［ｊ］ｇ．ｔ２）］
｛〈¬Ｘｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）〉（ｅｔ［ｊ］．ｔ１）｝
［・→Ｘｔ［ｊ］．ｆｔＳ（ｘ［ｊ］ｇ．ｔ３＜ｘ［ｊ］ｆｔ．ｔ１）］
［〈→Ｓｘ［ｊ］．ｇＤ）（ｘ［ｊ］ｆｔ．ｔ２）］  （６．８）
【０４１７】
システムがトレースを構築する時に、トレース内で発生するＥＣＴネットワーク内のイベントにマークを付け、イベントとそのタイミングを追跡する。このプロセスをＥＣＴネットワーク上でのＣＴＬステートメントシンボリック評価と呼ぶ。読者は表ＩとＩＩから続くトレース（６．７）と（６．８）を検証することができる。トレースの構築時に、同じ仮想時間点で発生する全ての条件を集めて結合状態にして、条件がチェーン括弧内に入れられ、信号検知動作に対して検知する配信信号を指定する引数が与えられ、それはイベントの検知直前にＥＣＴブロックで発生する。アクションイベントは角括弧内に入れられる。システムは、仮想時間点がイベントの開始と終了の時間を指定しているかどうかを追跡する。タイミングがネットワーク内のＥＣＴブロックの第２の列から取り出される。
【０４１８】
この点で、ユーザは要件に不完全な指定があることに気付く。（６．７）において、カウンタは半閉間隔［ｃｆ［ｊ］．ｔ２，ｃｆ［ｊ］．ｔ３）、ｊ＝０，１の間はアクティブである。（６．３）においては、カウンタは間隔［ｃｆ［ｊ＋２］．ｔ２，ｃｆ［ｊ＋２］．ｔ３）の間はアクティブである。カウンタがアクティブな時間間隔が交差しないことが［ｃｆ［ｊ］．ｔ２，ｃｆ［ｊ］．ｔ３）、ｊ＝０，１と［ｃｆ［ｊ＋２］．ｔ２，ｃｆ［ｊ＋２］．ｔ３）、ｊ＝０，１についても成立すべきことは指定されていない。ユーザは入口と出口の両方の回転改札口で全てのｊについて成立しなければならないことを指定することによって、ここでの状況を明確にする。
【０４１９】
システムはユーザによって現在更新されているＣＴＬ表明（６．２）と（６．３）が満たされることを検証するために、（６．７）と（６．８）のトレースをここで分析しなければならない。プログレスを保証するために全てのＥＣＴネットワークによって満たされなければならない３つの一般的な要件がある。
【０４２０】
すべてのＥＣＴネットワークによって一般要件は以下とおりである：
ＧＲ−１。ＣＴＬステートメント内で前提とされている時間点はトレース内にマッチする点を有していなければならない。
【０４２１】
ＧＲ−２。セルによってそのポーリングサイクル内にポーリングされる各ポートは２つの起動を有していなければならず、一方は逐次起動であり、他方は並列起動であって、並列起動は検知された信号を配信する。
【０４２２】
ＧＲ−３。同期ポーリングのある各ポートは、ポーリングサイクル中にポーリングされるか、埋め込みＴＩＰでポーリングされるかに関わらず、最終的に並列起動によって配信された信号を有していなければならない。
【０４２３】
前述の３つの要件は全て表ＩとＩＩのネットワークによって満たされている。この例では以下の２つの追加の要件がある：（ａ）イベントのカウントは各因果チェーンにおいて１回だけ発生しなければならない、と（ｂ）２つのカウントの呼び出しは重なっていてはならない、である。７（６．７）と（６．８）の直接因果チェーンはポートＣ．ｆ［ｊ］、０≦ｊ＜４について、カウンタ＋＋またはカウンタ−−が各因果チェーンにおいて１回だけ発生することを示している。これは要件（ａ）を満たす。システムは要件（ｂ）も満たされていることを認識する。これは、表ＩとＩＩの［∃（ｉ）（０≦ｉ＜５）Ｃ．ｆ［ｉ］］の逐次起動からわかる。ｉ＝４については、Ｃは表示ユニットからのｃｏｕｎｔｅｒ．ｃｏｕｎｔに対する要求に応答し、これはカウンタによるカウントを呼び出さない。したがって、Ｃ．ｆ［ｊ］、０≦ｊ＜４について、カウンタによるカウントの第２の呼び出しは第１の呼び出しが完全にサービスを受けた後で初めて発生する。したがって、Ｃのカウンタがカウントをしている間隔は重ならない。これで、ユーザによって更新されたｓｔｍｔ１とｓｔｍｔ２の証明が完了する。
【０４２４】
公園内の人の総数が常にｍａｘ以下であることを証明することによって、ｓｔｍｔ３が有効であることを確認する。これは、Ｍａｇｇｉｅ＆Ｋｒａｍｅｒ，［１３］の条件同期に対応する。これは、ＮＦＳＰ証明であって、以下の種類の帰納的推論を要求する。
【０４２５】
基礎：ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＝０≦ｍａｘ。
【０４２６】
帰納的推論の仮説：ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＝Ｎ≦ｍａｘ。
【０４２７】
帰納的推論のステップ：［（Ｅｔ［０］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）∨Ｅｔ［１］：ｐｅｒｓｏｎＩｎＰａｒｋ？（））⇒
ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）＆
（¬Ｘｔ［０］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）∨¬Ｘｔ［１］：ｐｅｒｓｏｎＩｎＰａｒｋ？（））］））⇒
ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）  （６．９）
ユーザは、以下のＣＴＬ表明を提供することによってシステムが帰納的推論のステップを証明するように導く
［∀（ｉ，ｊ）（０≦ｊ＜１）∃（ｅ［ｊ］．ｔ０＜ｅ［ｊ］．ｔ１）∃（ｘ［ｊ］ｔ０＜ｘ［ｊ］．ｔ１）
［｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）〉（ｅ［ｊ］．ｔ０）｝→．．．→
［〈・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）〉（ｅ［ｊ］ｇ．ｔ１）］
｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ＆ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ〉（ｅ［ｊ］．ｔ１）｝］＆  （６．１０）
［｛〈Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）〉（ｘ［ｉ］．ｔ０）｝→．．．→
［〈・→Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＯｕｔ（）〉（ｘ［ｉ］．ｔ１）］
｛〈¬Ｘｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ＆ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ〉（ｘ［ｉ］．ｔ１）｝］］  （６．１１）
【０４２８】
システムは付録Ｉに示しているｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）とｐｅｒｓｏｎＬｅａｖｉｎｇ？（）の定義を使用し、回転改札口の対の全ての考え得る順序について表ＩとＩＩのＥＣＴ上で（６．１０）と（６．１１）とを評価することによってそれらを確認するが、それは、各対（ｅ［ｊ］．ｔ０＜ｅ［ｊ］．ｔ１）および（ｃｘ［ｉ］．ｔ０＜ｘ［ｉ］．ｔ１）、０≦ｊ≦１における開始と終了の時間点は比較不能だからである。たとえば、ゲートＥｔ［０］．ｆｔの人の入場が許可され、その人が庭に入る前に、ゲートＥｇ［１］．ｆｔの人も入場が許可され、この第２の人が第１の人の前に実際に庭に入ることは大いにあり得ることで、それは人が庭に入ったり出たりする時刻は比較不能だからである。その間に、他の人が庭から出ることもあり得る。人がどのような順序で庭に入ったり出たりしようが、Ｅｔ［ｊ］．ｆｔとＸｔ［ｊ］．ｆｔの人が庭に入ったり出たりした後でｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘが成立する。これは、因果チェーン（６．７）と（６．８）とによって確認される。必要なだけ入口と出口のゲートをインストールすることが可能で、機能的推論は依然として成り立つ。帰納的推論による証明にはユーザの誘導が必要である。
【０４２９】
システムが、トレースとポーリングサイクルの情報を、ＥＣＴブロックの所与のＣＴＬステートメント内の時間点にマッチする時間点を見つけるのに便利なネットワークに構成し、ＣＴＬステートメントの開始と終了イベントにマッチするトレースを構築することは明かである。ＥＣＴネットワーク内で識別された因果チェーンは容易にトレースフォーマットに変換される。
【０４３０】
６．１．３  コメント
ここで証明された主張は、実装の属性であるが、それはＡＬＬＥＯＰとトレースが実装から自動的に生成されたからである。ただし、あるセルから別のセルへ制御を転送すると、ＣＴＬステートメントのＥＣＴ上でのシンボル評価は並列に行われるが、それはＣＰＵを各セルに割り当てているからである。この例では、ＥＣＴが単純であって、並列評価は必要ない。ここでは逐次合成だけが発生するが、それは各入口と出口について、回転改札口はカウンタがそのタスクを完了するまで待ち、１つのゲートを通した各入園と出園のサービスはカウンタによって逐次行われるからである。ここで必要な唯一の論理的な帰納的推論は、前述の（Ｉ．４）と（Ｉ．１１）を組み入れるためだけである。ほとんどのｐｔｈｒｅａｄは対について独立しており、独立して正しいと証明可能で、従属ｐｔｈｒｅａｄはまとめて正しいことが独立して証明され、ＣＴＬステートメントの証明には、実装のＥＣＴネットワーク内の因果シーケンスの追跡と、所与のＣＴＬ表明内の条件が満足されていることを検証するための因果チェーンの分析だけが伴う。
【０４３１】
ＣＴＬステートメントを満たす因果チェーンはそれらのステートメントを確認する。ＣＴＬステートメントが有効ではない場合、この証明方法は反例を提供する。終了イベントに到達できず、ＡＬＬＥＯＰが有限ＡＬＬＥＯＰの場合、証明は反例で終了することになる。非有限ＡＬＬＥＯＰについては、証明は終了せず、ユーザの介入が必要なことがある。必要な因果チェーンを見つけた後、システムはイベントの排他属性と半順序付けを確認するために逐次および並列起動を分析する。証明方法は対話的である。証明の各段階で、システムはその発見したものをユーザに示し、見つけたものを元にして所与のＣＴＬステートメントを修正するか、証明の探索を導くことができる新規の表明を提供するかのいずれかの機会をユーザに与える。この例では、マッチする時間点と因果チェーンの識別は容易である。セルの追跡が伴うより複雑な証明はセクション６．４のＤＰ解法で発生する。全ての場合において、ユーザはセクション６．５で説明するように有効性が実装の正しさを証明するＣＴＬステートメントの集合を選択する責任がある。複雑な実装については、これは重大な問題である。
【０４３２】
この例は、ｖｉｒｔｕａｌＭｅｍｏｒｙ無しに点対点信号交換だけを使用した。残りの例はｖｉｒｔｕａｌＭｅｍｏｒｙをその経路で使用する。そのため、まずｖｉｒｔｕａｌＭｅｍｏｒｙの構造とそれに関連付けられている動作を紹介する。
【０４３３】
６．２．ｖｉｒｔｕａｌＭｅｍｏｒｙの構造
図１１はｖｉｒｔｕａｌＭｅｍｏｒｙの模式図である。４つのコンポーネント、スクラッチパッドＳＰ、ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ、Ｅ、ｗｒｉｔｅＭｅｍｏｒｙ、Ｗ、およびｒｅａｄＭｅｍｏｒｙ、Ｒを有している。ｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙはｐｔｈｒｅａｄを保持しており、それらのための実行環境を提供する。実行メモリ内のデータの各項目には存在していればメインメモリまたはデータベース内のその身元を参照しているキーによってフラグを立てることが可能であると仮定している。セルのグループが同じｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍを使用する場合、グループ内の各セルはポートグループに属しているポートを有していなければならず、そのポートグループ内の全てのポートはＭに付属している同じエージェントに対してチューンされていなければならない。そのようなセルグループ内のセルは、ＭのｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙによって提供されるｐｔｈｒｅａｄの実行時にＭのスクラッチパッドＳＰを使用してデータを交換することができる。データベースやメインメモリのデータはｖｉｒｔｕａｌＭｅｍｏｒｙにコピーされた後で初めてセルグループによって共有することができる。
【０４３４】
ｗｒｉｔｅＭｅｍｏｒｙは送出されたメッセージを保持しており、ｒｅａｄＭｅｍｏｒｙは配信されたメッセージを保持している。ｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙはメッセージがメッセージを配信するエージェントによって配信される前に切り替えられる。したがって、各受信者はｒｅａｄＭｅｍｏｒｙからのその入力メッセージを読む。ポートｐはｒｅａｄＭｅｍｏｒｙ内のメッセージを送信コマンドｐ：ｓ（）の代わりに経路によって接続されているポートｑに転送コマンドｐ：ｆ（）を使用して転送することができる。転送コマンドが使用される場合、ｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙは切り替えられない。転送コマンドは、セクション６．４に示すＤＰ解法（食事をする哲学者）において使用される。送信／転送コマンドを区別するプロトコルをセクション７で説明する。
【０４３５】
2012506076.tif 000014
【０４３６】
図１１：ｖｉｒｔｕａｌ  Ｍｅｍｏｒｙ
前述のように、各ポートｐはＭに付属しているエージェントへのブランチを通して接続されているｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍにチューンされている。「ｐのｖｉｒｔｕａｌＭｅｍｏｒｙ」はそのようにｐに対してチューンされているｖｉｒｔｕａｌＭｅｍｏｒｙを指す。ｐのｖｉｒｔｕａｌＭｅｍｏｒｙのｒｅａｄＭｅｍｏｒｙ、ｗｒｉｔｅＭｅｍｏｒｙ、スクラッチパッド、およびｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙをそれぞれ指すようにメモリｐ．ｒｄ、ｐ．ｗｒ、ｐ．ｓｐ、およびｐ．ｅｘと書く。ｐがブランクインスタンス、ｍｓｇ（ｍｓｇのコンテナ）をｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍに何らかの既定のデータ値と共に書くことを示すためにｐ．ｗｒ：ｗｒ（ｍｓｇ）＝ｐ：ｗｒ（ｍｓｇ）と書く。Ｍの他のコンポーネントについてと同様に、ＭｓｇのコンテナをｖｉｒｔｕａｌＭｅｍｏｒｙのｒｅａｄＭｅｍｏｒｙに書き込むためにｐ．ｒｄ：ｗｒ（ｍｓｇ）を使用する。それぞれＭのｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙ内のメッセージを指すためにｐ．ｒｄ：ｍｓｇ（）＝ｐ：ｍｓｇ（），ａｎｄｐ．ｗｒ：ｍｓｇ（）と書く。ｖｉｒｔｕａｌＭｅｍｏｒｙ内に既にコンテナが存在していない場合、Ｍｓｇのインスタンスを指定されたデータと共にｐのｗｒｉｔｅＭｅｍｏｒｙに書き込むためにｐ：ｍａｋｅ（ｍｓｇ，［〈ｄａｔａＳｐｅｃｉｆｉｃａｔｉｏｎｓ〉］）を使用する。ｖｉｒｔｕａｌＭｅｍｏｒｙ内にコンテナが存在する場合、ｍａｋｅコマンドが指定されたデータでそれを満たす。ｐ．ｒｄ：ｍａｋｅ（ｍｓｇ，［〈ｄａｔａＳｐｅｃｉｆｉｃａｔｉｏｎｓ〉］）はｒｅａｄＭｅｍｏｒｙに対して同じことを行う。これらのｍａｋｅおよびｗｒｉｔｅメソッドは、ｖｉｒｔｕａｌＭｅｍｏｒｙのＲｅａｄＭｅｍｏｒｙ／ＷｒｉｔｅＭｅｍｏｒｙ／ｓｃｒａｔｃｈｐａｄ／ＥｘｅｃｕｔｉｏｎＭｅｍｏｒｙ内で定義されている。
【０４３７】
ほとんどのアプリケーションで、必要なメッセージサブクラスのコンテナは初期化時にｖｉｒｔｕａｌＭｅｍｏｒｙ内にインストールされる。したがって、通常、ｍａｋｅコマンドだけが使用される。Ｍｅｓｓａｇｅサブクラスとそれらの中で定義されているメソッドのコンパイルされたコードとはｖｉｒｔｕａｌＭｅｍｏｒｙのｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙ内に保持されている。したがって、ｖｉｒｔｕａｌＭｅｍｏｒｙ内のＭｅｓｓａｇｅサブクラスの全てのメソッドとデータは、これらのｖｉｒｔｕａｌＭｅｍｏｒｙにポートがチューンされているセルによって、それらのポートが状態Ｓにある時に利用可能である。２つ以上のｖｉｒｔｕａｌＭｅｍｏｒｙが同じＭｅｓｓａｇｅサブクラスのコードを含んでいてもよい。
【０４３８】
ｐ：ｍｓｇ（）：ｅｍｐｔｙ？（）を使用して、ポートｐのｒｅａｄＭｅｍｏｒｙが空かどうか、つまり何らかのデータを含んでいないかをチェックし、ｗｒ：ｍｓｇ（）：ｅｍｐｔｙ？（）を使用して、ポートｐのｗｒｉｔｅＭｅｍｏｒｙ内のメッセージに対して同じことをチェックする。同様に、ｐ：ｍｓｇ（）．ａｔｔｒｉｂｕｔｅ：ｅｍｐｔｙ？（）およびｐ．ｗｒ：ｍｓｇ（）．ａｔｔｒｉｂｕｔｅ：ｅｍｐｔｙ？（）がメッセージの指定された属性がｐのｖｉｒｔｕａｌＭｅｍｏｒｙのｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙにおいて空であることを確認するために使用される。指示されているメモリが空であること、つまりコンテナが存在していないことをチェックするためにｐ．ｒｄ：ｅｍｐｔｙ？（）ａｎｄｐ．ｗｒ：ｅｍｐｔｙ？（）を使用する。ｖｉｒｔｕａｌＭｅｍｏｒｙのｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙの内容をクリアするためにｐ：ｃｌｅａｒ（）を使用する。同様に、ｒｅａｄＭｅｍｏｒｙまたはｗｒｉｔｅＭｅｍｏｒｙだけをクリアするためにｐ．ｒｄ：ｃｌｅａｒ（）とｐ．ｗｒ：ｃｌｅａｒ（）を使用する。同様に、スクラッチパッドとｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙについても表明が定義されている。
【０４３９】
図１９はｇｅｎｅｒａｌＰｏｒｔグループＧのポートをｆｕｎｃｔｉｏｎＰｏｒｔグループＦのポートに接続しているグループ対グループの経路の構造を説明している。この図のポートグループのポートの全ての親セルは図に示している同じｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍを使用している。ｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍを使用するセルグループの各セルはメモリのデータをそれにアクセスした時にだけ読むことができる。アクセスはポートグループのポートによって制御される。任意の所与の時刻に、ポートグループＧのポートの親セルがＭにアクセスするか、グループＦのポートの親セルがＭにアクセスするかのいずれかであって、それら両方が同時にＭにアクセスすることはできない。ｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍにチューンされている任意のポートグループに属しているポートの親セルは、共通に共有されているデータとｐｔｈｒｅａｄにアクセスしそれらを使用してＭのｅｘｅｃｕｔｉｏｎＭｅｍｏｒｙのｐｔｈｒｅａｄを同時に実行することができる。
【０４４０】
同じｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍを使用したポートグループのポートの親セルによるそのような同時の並列実行の調和は、以下によって促進され、それらは（ｉ）ｖｉｒｔｕａｌＭｅｍｏｒｙ内の共有データへの同時のリードアクセスの便宜、（ｉｉ）データ更新の調和が必要なｐｔｈｒｅａｄロックの使用の便宜、および（ｉｉｉ）計算を調和させるための並列実行中の共有スクラッチパッドメモリを通した通信の便宜である。ｐｔｈｒｅａｄロックが使用されると、同時の並列実行を行うセルグループのセルにだけ適用される。メモリ競合の可能性はセルグループ内のセルの数を限定することによって限定される。実際には、セルグループ内のセルの数は１０または２０を超えることはないと予測する。データの上書きを防止しデータを保護するために、セルグループのセルが書き込めるｖｉｒｔｕａｌＭｅｍｏｒｙの領域は限定されている。同じｖｉｒｔｕａｌＭｅｍｏｒｙにチューンされているポートグループ内のポートは、それらのポートの親セルがデータを書き込むことができる重なっていないメモリ領域のアドレスを保持していてもよい。これらの便宜は、メモリ競合を効果的に最小化するために使用可能である。
【０４４１】
この点で、ＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンス上での条件移行のための規則を導入する。ｐ：ｓ（）を使用したメッセージ送信の場合、以下のメッセージ特徴付け条件はｒｅａｄＭｅｍｏｒｙとｗｒｉｔｅＭｅｍｏｒｙとの間で切り替えられる。ｐ：ｆ（）を使用したメッセージ転送の場合、条件は切り替えられない。
【０４４２】
□［｛（ｐ．ｒｄ：＜Ｃ１？＞？（）＆ｐ．ｗｒ：＜Ｃ２＞？（））（ｔ１）｝［ｐＳ（ｔ１）｝→〈ｑＤ〉（ｔ２）］
｛（ｑ．ｒｄ：＜Ｃ２＞？（）＆ｑ．ｗｒ：＜Ｃ１＞？（））（ｔ２）｝］  （６．１２）
□［｛（ｐ．ｒｄ：＜Ｃ１？＞？（）＆ｐ．ｗｒ：＜Ｃ２＞？（））（ｔ１）｝［ｐＦ（ｔ１）｝→〈ｑＤ〉（ｔ２）］
｛（ｑ．ｒｄ：＜Ｃ１＞？（）＆ｑ．ｗｒ：＜Ｃ２＞？（））（ｔ２）｝］  （６．１３）
（６．１３）のｐＦの上付き文字Ｆはメッセージが転送されていることを示している。
【０４４３】
次の２つのサブセクションは、ＰＣ（生産者／消費者）解法、ＤＰ解法、およびそれらに関するＡＬＬＥＯＰ証明を示している。解法は、セマフォ［Ｄｉｊｋｓｔｒａ，２３，２４］、モニタ［Ｈｏａｒｅ，１２］、または逐次バッファを使用する必要なしに実装されている（これについては５〜６回記述しているが、繰り返す価値があり、セマフォとモニタはプログラミング技術において十分に確立した機構であり、不可欠と考えられている。それらは４０年以上も使用されている！）
【０４４４】
６．３．生産者／消費者の解法：ＰＣ解法
ここでの我々の目的は並列バッファの使用を示すことである。ＰＣ解法のネットワークを図１２に示しており、解法を付録ＩＩに示している。それは、ｎ人の生産者Ｐ［ｉ］、０≦ｉ＜ｎと卸売業者Ｄに接続されているｍ人の消費者Ｃ［ｊ］，０≦ｊ＜ｍを有している。環境セルＥは、外部割り込み信号に基づいたアプリケーションの開始／停止に使用される。生産者に対してチューンされているｖｉｒｔｕａｌＭｅｍｏｒｙはＤに送る製品の並列バッファを提供する。消費者ポートＣ［ｊ］．ｇに対してチューンされているｖｉｒｔｕａｌＭｅｍｏｒｙは製品を消費者に送るために使用される。実装のＣＩＰ、ＴＩＰ、ポーリングサイクル、およびＡＬＬＥＯＰについては付録ＩＩを参照。以下を証明したい。
【０４４５】
（Ｓｔｍｔ１）製造された各製品は卸売業者に配送される。
【０４４６】
（Ｓｔｍｔ２）製品に対する要求のある各消費者が製品を得る。
（Ｓｔｍｔ１）と（Ｓｔｍｔ２）についてのＣＴＬステートメント：
（Ｓｔｍｔ１）：□［∀ｊ∀ｘ［ｘ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）◇（Ｄ．ｇｊ：ｍｓｇ（）．ｃｏｎｔｅｎｔ＝ｘ）］  （６．１４）
（Ｓｔｍｔ２）：□［∀ｊ（Ｃ［ｊ］．ｇＳ◇Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ）］  （６．１５）
（６．１４）において、生産者Ｐ［ｊ］は製品を製造し、卸売業者は最終的にそれをそのポートＤ．ｇｊで受け取る。（６．１５）において、消費者Ｃ［ｊ］はＣ［ｊ］．ｇＳを実行することによって製品に対する要求を送信し、最終的に製品を得る。システムによって実行される最初のタスクは、ｊに対する普遍例化∀ｊと製品に対する∀ｘによって、セクション５の規則（５．３２）と表ＩＩＩのＥＣＴネットワークとを使用し、時間点を前提として、モード演算子□と◇を除去することによって（６．１４）と（６．１５）とを変換することである。結果のＣＴＬステートメントを（６．１６）と（６．１７）に示す。このタスクはこの例では簡単になるが、それは各ｊについて１つの一意の因果チェーンだけが存在するからである。
【０４４７】
2012506076.tif 000015
【０４４８】
図１２：ＰＣ解法用のネットワーク
変換されたＣＴＬステートメント
（Ｓｔｍｔ１ａ）：□［∃（ｃｔｌ．ｔ０＜ｃｔｌ．ｔ１＜ｃｔｌ．ｔ２
［・→ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）（ｃｔｌ．ｔ０）］
［・→Ｐ［ｊ］．ｆ．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ（ｃｔｌ．ｔ１）］
→．．．→（Ｄ．ｇ［ｊ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔ＝ｐｒｏｄｕｃｔ〉（ｃｔｌ．ｔ２）］  （６．１６）
Ｓｔｍｔ２ａ）：［∀（ｃｔｌ．ｔ３）∃（ｃｔｌ．ｔ３＜ｃｔｌ．ｔ４＜ｃｔｌ．ｔ５）
／／消費者Ｃｊ］は要求を送出
Ｃ［ｊ］．ｇＳ（ｃｔｌ．ｔ３）→（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｃｔｌ．ｔ４）
→．．．→Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ（ｃｔｌ．ｔ５）］  （６．１７）
【０４４９】
ＰＣ解法のＥＣＴネットワークを表ＩＩＩに示している。このネットワークに埋め込まれている情報は多すぎて読者には容易に理解できない。証明の説明が進むにつれて必要な情報を取り上げる。セクション６．１で説明した一般的な要件ＧＲ−１とＧＲ−２は表ＩＩＩのＥＣＴネットワーク内ネットワークによって満たされている。しかし、即座にＧＲ−３が満たされていることにならない。ブロック３の第３行の（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊によって実施される配送された製品の検索が毎回成功することを証明しなければならない。
【０４５０】
ステートメント（６．１６）と（６．１７）の表ＩＩＩのＥＣＴ上での評価によって以下のマッチ時間点が生じる（表ＩＩＩのブロック内の時間点に対応するイベントの参照を以下に示し、各ブロックにおいて行番号は上から下である）。
【０４５１】
ｃｔｌ．ｔ０＝ｐ［ｊ］ｆ．ｔ２：Ｐ［ｊ］が製品を製造する：第３行，ブロック５
ｃｔｌ．ｔ１＝ｐ［ｊ］ｆ．ｔ３；それをｗｒｉｔｅＭｅｍｏｒｙに格納する：第４行、ブロック５
ｃｔｌ．ｔ２＝ｐ［ｊ］ｆ．ｔ５；それをＤ．ｇ［ｊ］に配送：最後の行、ブロック５  （６．１８）
（６．１７）について、：ｃｔｌ．ｔ３＝（ｃ［ｊ］Ｉ．ｔ２｜ｃ［ｊ］ｇ．ｔ３）；Ｃ［ｊ］が製品に対する要求を送信、
第３行、ブロック１と最後の行、ブロック２
ｃｔｌ．ｔ４＝ｄｇ［ｋ］ｔ．ｔ０；Ｄが検索を開始：第３行、ブロック３
ｃｔｌ．ｔ５＝ｃ［ｊ］ｇ．ｔ２；消費者はそれを得る：第５行、ブロック２  （６．１９）
表ＩＩＩ：ＰＣ解法ＥＣＴネットワーク
【０４５２】
【表３】
2012506076.tif 000016
【０４５３】
システムはＣＴＬステートメント内のイベントの流れに対応している表ＩＩＩのＥＣＴネットワーク内のイベントの流れを特定し、それらをトレースフォーマットにする。それを以下に示し、トレース（６．２０）は生産者Ｐ（ｊ）が新規の製品の注文を検知した時刻から製品が卸売業者ポートＤ．ｇ［ｊ］に配信された時刻までのイベントの流れを示している。
【０４５４】
Ｐ［ｊ］．ｆ：ｔｒａｃｅ（ｐ［ｊ］ｆ．ｔ０）＝
｛〈Ｐ［ｊ］．ｆ：ｍＲ？（〈Ｐ［ｊ］．ｆＤ〉（ｐ［ｊ］ｆ．ｔ０）〉（ｐ［ｊ］ｆ．ｔ１）｝
［・→ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）（ｐ［ｊ］ｆ．ｔ２）］
［・→Ｐ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ（ｐ［ｊ］ｆ．ｔ３）］
［・→Ｐ［ｊ］．ｆＳ（ｐ［ｊ］ｆ．ｔ４）］
（［→〈Ｄ．ｇ［ｊ］Ｄ〉（Ｐ［ｊ］ｆ．ｔ５）］
｜｜｛（Ｄ．ｇ［ｊ］．ｒｄ．ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ）（ｐ［ｊ］ｆ．ｔ５）｝
→．．．→｛（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｄｇ［ｋ］ｔ．ｔ０，ｐ［ｊ］ｆ．ｔ５）｝）
→Ｐ［ｊ］．ｆ：ｔｒａｃｅ（ｐ［ｊ］ｆ．ｔ５）］  （６．２０）
トレース（６．２０）は以下を指定している：ポートＰ［ｊ］．ｆでメッセージの受信を検知すると、Ｐ［ｊ］は製品を製造し、Ｐ［ｊ］．ｆのｗｒｉｔｅＭｅｍｏｒｙ内に入れ、それをＤ．ｇ［ｊ］に送り、Ｄ．ｇ［ｊ］はそれをそのｒｅａｄＭｅｍｏｒｙでいくらか後に受け取る。これが（６．１６）を確認する。ただし、（６．２０）の最後から２番目の行の２つの時間点（ｄｇ［ｋ］ｔ．ｔ０，ｐ［ｊ］ｆ．ｔ５）は比較不能である。したがって、製品の配送と製品の検索とは同期していない。
【０４５５】
以下のトレース（６．２１）はＣ［ｊ］が製品を要求した時刻からＣ［ｊ］が製品を入手した時刻までのイベント因果チェーンを表示する。
【０４５６】
Ｃ［ｊ］．ｇ：ｔｒａｃｅ（ｃ［ｊ］ｇ．ｔ０）＝
｛〈Ｃ［ｊ］．ｇ：ｕｓｅｄＵｐ？（）＊〉（ｃ［ｊ］ｇ．ｔ３）｝［・→Ｃ［ｊ］．ｇＳ（ｃ［ｊ］ｇ．ｔ３）］
（［〈→Ｄ．ｆ［ｊ］Ｄ〉（ｃ［ｊ］ｇ．ｔ４）］
｜｜［→．．．→｛〈Ｄ．ｆ［ｊ］：ｍＲ？（〈Ｄ．ｆ［ｊ］Ｄ〉（ｃ［ｊ］ｇ．ｔ４＝ｄｆ［ｊ］．ｔ０）））（ｄｆ［ｊ］．ｔ１｝
｛〈（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｄｇ［ｋ］ｔ．ｔ０）〉（ｄｇ［ｋ］．ｔ１｝
{〈∃（ｐｒｏｄｕｃｔ）Ｄ．ｇ［ｋ］．ｒｄ．ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝
ｐｒｏｄｕｃｔ〉（ｄｇ［ｋ］ｔ．ｔ０）｝
［・→Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）（ｄｇ［ｋ］ｔ．ｔ１）］
｛〈Ｄ．ｇ［ｋ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ＆
Ｄ．ｆ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ〉（ｄｇ［ｋ］ｔ．ｔ２）｝
［・→Ｄ．ｇ［ｋ］ｓ（ｄｇ［ｋ］ｔ．ｔ２）］／／新規の製品の注文を送信
（［〈→Ｐ［ｋ］．ｆＤ〉（ｄｇ［ｋ］ｔ．ｔ３）］／／生産者に注文が配信される
｜｜→．．．→Ｐ［ｊ］．ｆ：ｔｒａｃｅ（ｐ［ｊ］ｆ．ｔ０≧ｄｇ［ｋ］ｔ．ｔ３）
［・→Ｄ．ｆ［ｊ］Ｓ（ｄｆ［ｊ］ｔ．ｔ３）］／／消費者に製品を発送
（［〈・→Ｃ［ｊ］．ｇＤ〉（ｄｆ［ｊ］ｔ．ｔ４）］／／製品を消費者に配送
／／Ｄは次のｆｕｎｃｔｉｏｎＰｏｒｔのポーリングに進む
［・→∃（ｉ）（０≦ｉ＜ｍ）Ｄ．ｆ［ｉ］：ｔｒａｃｅ（ｄｆ［ｉ］．ｔｏ＝ｄｆ［ｊ］ｔ．ｔ４）］）］
／／消費者Ｃ［ｊ］に何が起こったかに戻る。以下では、消費者が配送を検知
｛〈Ｃ［ｊ］．ｇ：ｍＲ？（〈Ｃ．ｇ［ｊ］Ｄ〉（ｃ［ｊ］ｇ．ｔｏ＝ｄｆ［ｊ］ｔ．ｔ４））〉（ｃ［ｊ］ｇ．ｔ１）｝
｛〈Ｃ［ｊ］．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐｒｏｄｕｃｔ〉（ｃ［ｊ］ｇ．ｔ１）｝
［・→Ｃ［ｊ］．ｇ：ｐｉｃｋＵｐ（）（ｃ［ｊ］ｇ．ｔ１）］
｛（Ｃ［ｊ］．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ＆Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ〉（ｃ［ｊ］ｇ．ｔ２）｝  （６．２１）
（６．２１）のイベントの流れは、検索∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊，が毎回成功する場合にだけ保証される。Ｄ．ｇ［ｋ］はＰ［ｋ］．ｆからの配送を受け取る。（６．２１）の検索、
｛〈（∃（ｋ）（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊（ｄｇ［ｋ］ｔ．ｔ０）〉（ｄｇ［ｋ］．ｔ１｝
は時刻ｄｇ［ｋ］ｔ．ｔ０に始まり、製品がＤ．ｆ［ｊ］に移動する時刻ｄｇ［ｋ］ｔ．ｔ１に終了する（表Ｉのブロック３の行５を参照）。この検索はｄｇ［ｋ］ｔ．ｔ１の前にＤ．ｇ［ｋ］に製品を配達したＰ［ｋ］．ｆ、０≦ｋ＜ｎが存在し、この製品がｄｇ［ｋ］ｔ．ｔ１の前に既に使用されていない場合にだけ毎回成功する。
【０４５７】
帰納的証明は次のように進行する。検索はその初期化中に卸売業者Ｄが行った注文のせいで最初の顧客については成功する。表ＩＩＩのブロック４と５の最後の行を参照。Ｎ番目の試みで成功すると仮定する。（Ｎ＋１）番目の試みは成功するが、それは製品がＮ番目の試みにおいて、たとえはポートＤ．ｇ［ｉ］において使用されると、新規の注文が製造者Ｐ［ｉ］に対して行われるからである。ブロック２の第８行と（６．２１）のＤ．ｇ［ｋ］ｓ（ｄｇ［ｋ］ｔ．ｔ２）の後のコメントを参照。製品が見つかるまで検索が継続するので、Ｐ［ｉ］がその注文に応答した時に確実に成功するか、検索によって他のポートＤ．ｇ［ｊ］において未使用の製品を見つけることがあり得る。システムは、ユーザによって提供された表明を確認することによってこれを対話的に証明する。詳細をここで説明しない。そのため、（６．２１）については、各消費者は要求した製品を受け取る。
【０４５８】
これはセクション６．１の要件ＧＲ−３を満たす。しかし、プログレスを保証するには、以下の仮定が必要である。
【０４５９】
公理：□（∃（ｉ，ｔ）［・→Ｃ［ｉ］．ｇＳ（ｔ）］）  （６．２２）
つまり、製品に対する要求のある顧客が常に存在し、それは各製品が最終的に使用されることになると言うのと同じである。そうでなければ、ビジネスは停止し、卸売業者はポーリングサイクルを実行しながらその空のポートを回り続けるだけである。また、製品について十分な要求がない場合、製品が回り続けるだけのことがあり得る。指定した長さの時間を超えて回り続ける場合、製造者をサスペンドするために製品ＣＩＰを再定義することができる。要求が発生し、後に注文が配信されると自動的に動作をリジュームする。
【０４６０】
コメント：証明の構築において直面する問題の１つは、ＦＳＰ記述の正規表現における単純な「スター演算」が要件を確認できる状況では帰納的推論による証明に頼らなければならないことである。これが発生するのは、「状態」を有していないからだけでなく、並列動作中の本質的な非同期のためである。ほとんどの場合、帰納的証明は、非常に自明であって、うまくいけばシステムが証明を自動的に構築する戦略を考え出すことが可能である。
【０４６１】
６．４．食事をする哲学者の解法：ＤＰ解法
ＤＰ解法ネットワークを図１３に示している。ゲームを開始し停止する図には示していない環境セルが存在する。執事、つまり要求されるとフォークを配り、食料を供給し続けるｂｔｌｒ（図１３ではＢが付けられている）が存在する。哲学者はｂｔｌｒから２本のフォークを受け取った後でだけ食事を始めることができる。図に示しているように、テーブル上には５本のフォーク、ｂｔｌｒ．ｆｒｋ［ｊ］があり、５人の哲学者、Ｐ［ｊ］、０≦ｊ＜５が存在する。各哲学者Ｐ［ｊ］は左隣の哲学者Ｐ［ｊ（○＋）５４］とｂｔｌｒ．ｆｒｋ［ｊ］を共有し、右隣の哲学者Ｐ［ｊ（○＋）５１］とｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］を共有する。したがって、２人の隣り合った哲学者は同時に食事をすることはできない。
【０４６２】
哲学者Ｐ［ｊ］は空のメッセージをｆｕｎｃｔｉｏｎＰｏｒｔ、ｂｔｌｒ．ｆ［ｊ］に送信することによって、フォークの要求を送信する。両方のフォーク、ｂｔｌｒ．ｆｒｋ［ｊ］とｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］が使用可能な場合、ｂｔｌｒはフォークをｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙのコンテナに入れ、送出する。いったんこれが行われると、フォークはＰ［ｊ］が食事を終えてフォークを返却するまでＰ［ｊ（○＋）５１］とＰ［ｊ（○＋）５４］には利用できなくなる。Ｐ［ｊ］がフォークを要求した時に哲学者Ｐ［ｊ（○＋）５４］が食事中であったり、Ｐ［ｊ（○＋）５１］が食事中であったり、Ｐ［ｊ（○＋）５１］が左のフォークｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］を予約して待っている場合、Ｐ［ｊ］はフォークを利用できない。この場合、ｂｔｌｒはＰ［ｊ］の左のフォークｂｔｌｒ．ｆｒｋ［ｊ］を予約して、Ｐ［ｊ］は両方のフォークが利用可能になるまで待つ。ｂｔｌｒ．ｆｒｋ［ｊ］がいったん予約されると、Ｐ［ｊ］が食べ終わる前にＰ［ｊ（○＋）５４］は食事を（再び）開始できない。Ｐ［ｊ］によって食事が終わった後にフォークが返却された時に初めてｂｔｌｒ．ｆｒｋ［ｊ］は予約を解除される。
【０４６３】
2012506076.tif 000017
【０４６４】
図１３：ＤＰ解法用のネットワーク
各哲学者Ｐ［ｊ］は食事が終われば常にフォークを返却し、考える状態Ｔ［ｊ］に入る。しばらく考えたあと、彼／彼女は再び空腹になって、フォークを注文する。執事は、哲学者たちのサービスを循環する順序Ｐ［０］→Ｐ［ｌ］→Ｐ［２］→Ｐ［３］→Ｐ［４］→Ｐ［０］→．．．→でゲームが終了するまで行う。ゲームの任意の時点で、Ｐ［ｊ］は３つの考え得る状態：Ｅ［ｊ］（食事）、Ｔ［ｊ］（思索）、またはＷ［ｊ］（フォークを待っている）の１つとなることができる。ゲームは全ての哲学者が状態Ｔ［ｊ］にあって、全てのフォークがテーブル上にあり任意の哲学者が利用可能であって、食べ物の準備ができている時に始まる。フォークの要求を送信し、要求が最初に検知された哲学者Ｐ［ｊ］は、全ての哲学者がフォークに対する要求を同時に送信しても最初にｂｔｌｒのサービスを受け、最初にフォークを取得する。Ｐ［ｊ］がフォークを取得した後、Ｐ［ｊ（○＋）５２］がフォークを要求していた場合に、次にフォークを取得するかもしれない。それから両方が食事を始め、状態Ｅ［ｊ］とＥ［ｊ（○＋）５２］にそれぞれなるかもしれない。ｋ≠ｊかつｋ≠ｊ（○＋）５２の他の哲学者については、フォークを注文しているので、状態Ｗ［ｋ］になるか、フォークを注文していなければ思索を続ける。
【０４６５】
ＣＩＰ、ＴＩＰ、ＡＬＬＥＯＰは付録ＩＩＩで説明する。トレースは表ＩＶとＶのネットワークで表される。ゲームは以下の２つの公理を満たし、それらがプログレスを保証する。
（Ａｘ１）：∀（ｊ）［□（Ｅ［ｊ］◇（Ｔ［ｊ］＆ｂｔｌｒ．ｆｒｋ［ｊ］．ｏｎＴｂｌ＆ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５ｌ］．ｏｎＴｂｌ
＆¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ）］  （６．２３）
（Ａｘ２）：∀（ｊ）［□（Ｔ［ｊ］◇Ｐ［ｊ］：ｈｕｎｇｒｙ（）］  （６．２４）
（６．２３）は各食事中の哲学者は常に最終的にはフォークを返却し、思索状態に入ると言っている。（６．２４）は各思索中の哲学者は最終的に空腹になると言っている。
【０４６６】
状態Ｅ［ｊ］、Ｔ「ｊ」およびＷ［ｊ］は以下のように定義される。
【０４６７】
∀（ｔ）（Ｔ［ｊ］（ｔ）⇔
∃（ｔ０≦ｔ＜ｔ１）［・→Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）（ｔ０）］［〈・→Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）〉（ｔ１）］）  （６２５）
∀（ｔ）（Ｅ［ｊ］（ｔ）⇔
∃（ｔ０≦ｔ＜ｔ１）［・→Ｐ［ｊ］：ｅａｔｉｎｇ（）（ｔ０）］［〈・→Ｐ［ｊ］：ｅａｔｉｎｇ（）〉（ｔ１）］）  （６．２６）
∀（ｔ）（Ｗ［ｊ］（ｔ））⇔
∃（ｔ０＜ｔ１＜ｔ２＜ｔ３）＆（ｔ１＜ｔ＜ｔ３）
［Ｐ［ｊ］．ｇ：ｍＲ（）＊（ｔ０）＆ｂｔｌｒ．ｆ［ｊ］．ｒｓｒｖｄ（ｔ１）＆
〈¬ｂｔｌｒ．ｆ［ｊ］．ｒｓｒｖｄ〉（ｔ２）＆〈Ｐ［ｊ］．ｇ：ｍＲ（）＊（）〉（ｔ３）］  （６．２７）
前述のステートメントのアクションの開始と終了のタイミングＷ［ｊ］は、Ｐ［ｊ］とｂｔｌｒ．ｆ［ｊ］の合成状態
表Ｖ：ｂｔｒｌ．ｆ［ｊ］ＥＣＴ
【０４６８】
【表４】
2012506076.tif 000018
【０４６９】
ゲームの初期状態は以下のとおりである。
［∃（ｔ０）∀（ｊ）（〈Ｔ（ｊ）＆ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ（ｊ）＆
ｂｔｌｒ．ｆｄＣｏｎｔａｉｎｅｒ：ｆｕｌｌ？（）〉（ｔ０））］  （６．２８）
【０４７０】
∀（ｊ）Ｗ（ｊ）はここでの唯一のデッドロック状態であって、それは任意のｊ、０≦ｊ＜５について、Ｐ［ｊ（○＋）５４］はＰ［ｊ］が食事を終了してから食事を始めることができるからである。したがって、哲学者のだれもが食事を始めることができない。以下では２つの主張について証明を行い、それらは、（ｉ）（６．２８）の初期状態でゲームが始まる場合、ゲームはデッドロック状態には決して到達しないことと（ｉｉ）各哲学者は空腹になる毎に自分の食べる順番が回ってくるという意味で解法は公平であることである。
【０４７１】
システムの可能性のある状態の記述を簡単にするために、以下の規約に従う。
¬Ｔ［ｊ］＝（Ｅ［ｊ］｜Ｗ［ｊ］）；¬Ｅ［ｊ］＝（Ｔ［ｊ］｜Ｗ［ｊ］）；
¬Ｗ［ｊ］＝（Ｅ［ｊ］｜Ｔ［ｊ］）；および？？［ｊ］＝（Ｅ［ｊ］｜Ｔ［ｊ］｜Ｗ［ｊ］）  （６．２９）
以下で説明している状態をｂｔｒｌのポーリングサイクルの最後と最初でｔｒｕｅと考えることができる。そのような状態を構成と呼ぶ。したがって、∀（ｊ）Ｔ（ｊ）と∀（ｊ）Ｗ（ｊ）とは構成である。ユーザは以下のＣＴＬステートメントを、（６．２９）の表記を使用して状態Ｔ［ｊ］、Ｗ［ｊ］、およびＥ［ｊ］について定式化する。
【０４７２】
□［∀（ｊ）Ｗ（ｊ）◇∀（ｋ）Ｗ（ｋ）］／／デッドロック状態から出ることがない  （６．３０）
□［∀（ｊ）Ｔ（ｊ）◇［（∃（ｉ）（¬Ｅ（ｉ（○＋）５４）＆Ｅ（ｉ）＆¬Ｅ（ｉ（○＋）５１）＆
（¬Ｅ（ｉ（○＋）５２）｜Ｅ（ｉ（○＋）５２））＆¬Ｅ（ｉ（○＋）５３））｜∀（ｋ）Ｔ（ｋ）］  （６．３１）
□［∀（ｊ）（Ｗ［ｊ］◇Ｅ［ｊ］）］  （６．３２）
【０４７３】
表明（６．３０）はデッドロック構成を特徴付けている。（６．３１）において最終的に、１人または２人のいずれかの哲学者が食事をするか、全ての哲学者が思索する。（６．３２）は待っている各哲学者が最終的に食事をすると表明している。理解されるように、ここでの検索にはマッチ時間点を見つけることは伴わず、哲学者の状態を追跡することが伴う。
【０４７４】
これらの表明を証明するために使用されるＥＣＴネットワークを表ＩＶとＶに示している。それらは、付録ＩＩＩのＡＬＬＥＯＰから導出されるトレースから得られる。ここで、各ＥＣＴネットワークはネットワークの初期状態を定義するブロックを有している。これは、ネットワークが開始された時、つまりシンボリック評価が始まった時の述語の真理値を指定している。選択点の述語が初期状態において指定されていないか、ＥＣＴ評価において以前に評価されている述語内に存在してないか、定義から推論できない場合、その選択点から始まる全ての因果チェーンはＥＣＴ評価トレース内に可能性のある選択肢として含まれる。任意のポーリングされたＴＩＰに対応するＥＣＴ評価の開始前に、システムは付録ＩＩＩ、（Ｉｌｌ．３５）に示している区別されている述語の定義を使用してその点までに行われた評価の結果を使用して初期状態を更新する。ＥＣＴ評価の規約は、述語はその真理値を変更されるまで保持するということである。
【０４７５】
執事ＥＣＴは５〜６個の選択点と並列起動とを有しているが、フォークは有していない。全ての哲学者と執事は並列に実行（ｒｕｎ）されるので、それらのＥＣＴのシンボリック評価は必要に応じて並列に行われる。証明が最も容易な表明（６．３０）から始める。初期状態は以下のとおりであって、
∀（ｊ）［Ｗ（ｊ）＆¬ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）＆ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）＆
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）］  （６．３３）
表Ｖに示しているものの代わりである。これらの初期条件は表ＶのＥＣＴブロック（１３）の最後に現れる。これは、Ｗ［ｊ］が発生する唯一のＥＣＴブロックである。初期状態を表ＶのＥＣＴ表の述語（６．３３）評価に設定することで、（１）→（２）→（４）（６）→（８）→（１３）→（１７）とマーキングされているブロックを含んでいる評価経路をたどって再びＷ［ｊ］につながる。評価が継続するにつれて、ポーリングサイクルについては、ＥＣＴ評価の以下のシーケンスを得る。
【０４７６】
ｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ（○＋）５ｌ］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ（○＋）５２］：ＥＣＴ（．．．）
→ｂｔｌｒ．ｆ［ｊ（○＋）５３］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ（○＋）５４］：ＥＣＴ（．．．）→ｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（．．．）
→．．．→  （６．３４）
【０４７７】
ここで、全てのｊについて、トレースは必然的に表ＶのＥＣＴブロック（１３）につながるが、これはＷ［ｊ］が全てのｊに対してｔｒｕｅだからである。したがて、構成は変化しない。システムはｂｔｌｒ．ｆ［ｊ］で始まりｂｔｌｒ．ｆ［ｊ（○＋）５４］で終わる１つの完全なポーリングサイクルに対応している評価を経た後にこれを認識する。ただし、ＥＣＴブロック（１３）の状態Ｗ［ｊ］において、ｂｔｒｌはＰ［ｊ］には応答メッセージを返送しない。図１と２に示しているガードの定義によって、ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）は、応答メッセージが返信されるまで各ポーリングサイクルにおいてｔｒｕｅと評価し、それはもちろんこのデッドロック構成では発生しない。これが（６．３０）を証明する。
【０４７８】
ここで、（６．３１）の証明を考える。以降では、ポーリングサイクルの最後の構成を指すためにＺを使用する。規則（５．３２）によって、ＣＴＬ表明（６．３１）は以下のように変換される。
【０４７９】
∀（Ｚ）（∀（ｊ）Ｔ（ｊ）→．．．→Ｚ）⇒（Ｚ◇ＥＺ）  （６．３５）
ここでＥＺは終了構成である。
【０４８０】
ＥＺ＝［∀（ｋ）Ｔ（ｋ）｜（∃（ｉ）（¬Ｅ（ｉ（○＋）５４）＆Ｅ（ｉ）＆¬Ｅ（ｉ（○＋）５１）＆
（¬Ｅ（ｉ（○＋）５２）｜Ｅ（ｉ（○＋）５２））＆¬Ｅ（ｉ（○＋）５３））］  （６．３６）
【０４８１】
最初のタスクは、初期状態から始めて、各ｊについて評価前にｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（）の初期状態を更新し、述語の値が得られない表Ｖの各選択点で全ての選択肢の因果チェーンをたどって、執事の１つのポーリングサイクル後に構成Ｚがどのようになるかを見つけることである。システムは以下のように素早くＺ＝ＥＺを見つけ出す。表ＩＶにおいて、各哲学者Ｐ［ｊ］、０≦ｊ＜５は空腹になり、Ｐ［ｊ］．ｇＳ（ｐ［ｊ］ｇ．ｔ０）を実行し、それを時間点ｐ［ｊ］ｇ．ｔ１＝ｂｆ［ｊ］．ｔ０、０≦ｊ＜５においてｂｔｌｒ．ｆ［ｊ］に配信することによってフォークの要求を執事に送信する。これらのメッセージ配信時刻は比較不能であるが、それは哲学者が並列に実行（ｒｕｎ）されているからである。執事がメッセージ配信を検知するためにｂｔｌｒ．ｆ［ｊ］をポーリングするポーリング時刻はｂｆ［ｊ］．ｔ１、０≦ｊ＜５であって、付録ＩＩＩのポーリングサイクルの定義に従ってｂｆ［ｊ］．ｔ１＜ｂｆ［ｊ（○＋）５１］．ｔ１である。ここでの唯一の要件は、メッセージ配信がメッセージ検知の前に発生することである。哲学者Ｐ［ｊ］が、ｂｔｒｌがそのポートｂｔｌｒ．ｆ［ｊ］をポーリングする前にたまたま要求を送信していた場合、ｂｔｒｌはそのポートでメッセージの受信を検知し、そうでなければ検知しない。
【０４８２】
したがって、全ての哲学者が要求を同時に送信したり、執事のポーリングサイクル中にだれもが要求を送信しなかったり、ある者は送信しある者は送信しなかったりすることがあり得る。執事と哲学者の動作は同期していないため、ｂｔｒｌがそのｆｕｎｃｔｉｏｎＰｏｒｔをポーリングしている時に、そのポートのいくつかで何らかの時刻にメッセージ受信を検知したり、ポーリングサイクルでメッセージを検知しなかったり、ポーリングサイクルで全てのポートでメッセージを検知したりするかもしれない。したがって、ｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（）の各選択点から始まる全ての可能性のある選択肢の因果チェーンを含めることには意味がある。表ＶのＥＣＴブロック（６）と（７）に現れるｂｔｌｒ．ｆ［ｊ］：ｍｓｇ（）：ｅｍｐｔｙ？（）の場合、ユーザは以下の定義を提供する。
【０４８３】
∀（ｊ）［□（Ｐ［ｊ］：ｈｕｎｇｒｙ？（）＆ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（））⇔
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｍｓｇ（）：ｅｍｐｔｙ？（）］  （６．３７）
システムは表ＩＶとＶのＥＣＴを使用してこの定義を検証し、この定義を使用して表Ｖで（６）と（７）とマーキングされたＥＣＴブロックにおける条件ｂｔｌｒ．ｆ［ｊ］：ｍｓｇ（）：ｅｍｐｔｙ？（）によって選択点で取るべき分岐を決定する。システムは必要に応じて定義を使用して初期状態も更新する。通常、述語の評価中または初期状態の更新中にだけＥＣＴ評価において論理的な推論の必要性が生じる。
【０４８４】
表明（６．３５）と（６．３６）は、表Ｖの選択点における因果チェーンの選択の基準は一切与えない。したがって、システムは表Ｖの各選択点において初期状態の述語と所与の定義とに整合している全ての可能性のある因果チェーンを分析して、（６．３５）のＺが（６．３６）のＥＺに等しいことを見つける。これは、図１４の木にまとめられ、執事のポーリングサイクル後の可能性のある構成が木のブランチのいずれか１つにおける状態によって指定されている。読者は、図１４の各ブランチが、全ての哲学者は思索しているか哲学者たちの１人または２人が食事をしているというＺ内のパターンを満たしていることに気付くであろう。したがって、初期状態から始まる第１のポーリングサイクルの後の構成は、以下を満たす。
【０４８５】
□［∀（ｊ）Ｔ（ｊ）→→ＥＺ］  （６．３８）
そのため、（６．３５）を証明するために、システムは
□［ＥＺ→．．．→Ｚ１］  （６．３９）
がｔｒｕｅであるような構成Ｚ１を、以下のようにして見つけようとする。まず、ｉ＝ｊと設定することによって（６．３６）の変数ｉの存在インスタンス化を生成し、以下のように続行する。可能性のある初期構成は以下のようである。
【０４８６】
［¬Ｅ（ｊ（○＋）５４）Ｅ（ｊ）¬Ｅ（ｊ（○＋）５１）¬Ｅ（ｊ（○＋）５２）¬Ｅ（ｊ（○＋）５３）］または
［¬Ｅ（ｊ（○＋）５４）Ｅ（ｊ）¬Ｅ（ｊ（○＋）５１）Ｅ（ｊ（○＋）５２）¬Ｅ（ｊ（○＋）５３）］  （６．４０）
（６．２９）で与えられている定義に従って（６．４０）における否定状態についての置き換を行うことによって（２４＋２３）の可能性のある初期構成となる。各初期構成につて、システムはその構成についてｔｒｕｅでなければならない初期条件をＥＣＴとユーザによって与えられた区別されている述語の定義から見つけ出して、適切な場合はそれらを初期条件に含める。その後、各初期状態について、所与の初期条件に整合している全ての考えられる因果チェーンをたどるＥＣＴを評価して、全ての初期条件と¬ＥＸ＝∀（ｊ）Ｗ（ｊ）についてＺ１＝ＥＺ（（６．３）のＺ１と（６．３６）のＥＺ）が成立することを見つけ出す。これが（６．３５）、（６．３６）、および（６．３１）を証明する。
【０４８７】
2012506076.tif 000019
【０４８８】
図１４：１回目のポーリングサイクルの終了時における構成の分岐している木
ただし、そうすることによって、システムは実装から食事をする哲学者の解法の状態図を効果的に構築する。ここで、マッチする時間点を探索する必要はなく、ポーリングサイクルにおいて到達する可能性のある構成だけを探索すればよい。システムによって計算された状態図から得られる以下の補助定理を示す。この補助定理は（６．３２）の証明に有用である。
【０４８９】
補助定理１：□∀（ｊ）［Ｗ［ｊ］⇒（？？［ｊ（○＋）５４］Ｗ［ｊ］¬Ｔ［ｊ（○＋）５１］∨Ｅ［ｊ（○＋）５４］Ｗ［ｊ］？？［ｊ（○＋）５１］
∨Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］）］  （６．４１）
これは、Ｐ［ｊ］が状態Ｗ［ｊ］にある時に、Ｐ［ｊ］の右と左の哲学者の状態がどうであるかを指定する。（６．４１）の表記を拡張するために状態が置き換えられると、８つの考え得る別個のトリプレットを得る。これらのトリプレットは以下のとおりである。
【０４９０】
Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｅ［ｊ（○＋）５１］、Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］、Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｅ［ｊ（○＋）５１］、
Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５ｌ］、Ｅ［ｊ（○＋）５４］Ｗ［ｊ］Ｅ［ｊ（○＋）５１］、Ｅ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］、
Ｅ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］、Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］  （６．４２）
システムは指定されたトリプレットが既に構築した状態図に整合していることを容易に確認する。状態図が既に構築されている場合、システムは任意に選択されたｊについてＷ［ｊ］に対して適切な初期状態を設定し、表ＩＶとＶのＥＣＴを評価することによって、各トリプレットを確認することができる。（６．４２）の各トリプレットについて、（６．４２）で指定されていない状態は指定されたトリプレットに整合する任意の状態とすることができる。
【０４９１】
（６．３２）の証明は、食事をしている各哲学者はフォークを返却し（公理Ａｘ  １、（６．２４））、思索をしている哲学者は最終的に空腹になり（公理Ａｘ  ２（６．２５））、Ｐ［ｊ］が待っている時に、ｂｔｌｒ．ｆｒｋ［ｊ］はＰ［ｊ］によって予約されているのでＰ［ｊ（○＋）５４］は食事を始められないという事実から得られ。Ｐ［ｊ（○＋）５４］が既に食事をしていた場合、Ｐ［ｊ］は待ち、Ｐ［ｊ（○＋）５４］が食事を終えた後、Ｐ［ｊ（○＋）５４］がフォークを返したサイクルの直後に続く１回目のポーリングサイクルにおいて、Ｐ［ｊ］は食事をする機会がある。Ｐ［ｊ（○＋）５４］が長時間食事をしているためにＰ［ｊ］が執事の数回のポーリングサイクルにわたって待たなければならない場合、Ａｘ  １）６．２４）によって、Ｐ［ｊ（○＋）５１］はフォークを返した後で再び食事を開始するかもしれない。これはＰ［ｊ］が自分のフォークを手に入れるまでに５〜６回発生する可能性がある。しかし、Ｐ［ｊ］は最終的に自分のフォークを取得するが、それはＰ［ｊ］が食事を終えるまでＰ［ｊ（○＋）５４］が再び食事を始めることができないためである。これを図１５に示している。ここでは、議論は正規表現を使用するＦＳＰの議論と同様である。
【０４９２】
（６．４２）のＴ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］およびＷ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］の場合について考える。ポーリングは、ｂｔｌｒ．ｆ［ｊ］で始まる。Ｔ［ｊ（○＋）５４］Ｗ［ｊ］Ｔ［ｊ（○＋）５１］の場合、唯一の可能性は、¬Ｅ［ｊ（○＋）５４］Ｅ［ｊ］（○＋）５Ｅ［ｊ（○＋）５ｌ］に変化することである。Ｐ［ｊ］は食事を始めているので、証明は終了する。Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］の場合、以下が成立し、これは、少なくとも１人の食事をしている哲学者がいなければならないという（６．３５）と（６．３６）に従う。ユーザは以下の表明を提供する。
【０４９３】
□∀（ｊ）［Ｗ［ｊ（○＋）５４］Ｗ［ｊ］Ｗ［ｊ（○＋）５１］⇒（Ｗ［ｊ］Ｗ［ｊ（○＋）５１］Ｅ［ｊ（○＋）５２］∨
Ｗ［ｊ］Ｗ［ｊ（○＋）５１］¬Ｅ［ｊ（○＋）５２］Ｅ［ｊ（○＋）５３］）］  （６．４３）
この証明は（６．３６）、（６．３９）および図１４の構成を使用して容易に確認される。（Ｗ［ｊ］Ｗ［ｊ（○＋）５１］Ｅ［ｊ（○＋）５２］の場合、Ａｘ  ２（６．２５）によって、以下のトランザクションのシーケンスＷ［ｊ］Ｗ［ｊ（○＋）５１］Ｅ［ｊ（○＋）５２］→Ｗ［ｊ］Ｗ［ｊ（○＋）５１］Ｔ［ｊ（○＋）５２］→Ｗ［ｊ］Ｅ［ｊ（○＋）５１］Ｔ［ｊ（○＋）５２］→Ｅ［ｊ］Ｔ［ｊ（○＋）５１］？？［ｊ（○＋）５２］につながらなければならない。そのため、Ｐ［ｊ］は最終的に食事をする。前述の遷移は、システムによって全て確認される。Ｗ［ｊ（○＋）５１］¬Ｅ［ｊ（○＋）５２］Ｅ［ｊ（○＋）５３］の場合も同様の遷移が発生する。
【０４９４】
各場合について、システムは適切な初期状態から初めて、Ｐ［ｊ］に対して避けられない（唯一可能な）状態としてポーリングサイクルにおいて状態Ｅ［ｊ］が得られるまで連続したポーリングサイクルを経てＥＣＴを評価する。各ポーリングサイクルにおいて、各ｊについてのｂｔｌｒ．ｆ［ｊ］：ＥＣＴ（）評価の前に初期状態が更新される。これは、ＦＳＰの状態探索と同様である。この特定の問題においては、システムは以前に到達した構成が再び発生するとそのポーリングサイクルの繰り返しを停止する。これはこの場合に発生し得るが、それは解法が有限ＡＬＬＥＯＰを有しているためである。この探索は各場合において成功する。しかし、この種類の探索には困難がある。
【０４９５】
Ｅ［ｊ］が到達不能の場合、非有限ＡＬＬＥＯＰについて、ユーザが適切な終了条件を指定するか、システムが矛盾に遭遇するか、ユーザがシステムを停止しトレースを調べるかしない限りシステムが終了しない可能性がある。
【０４９６】
備考：ＡＬＬＥＯＰ証明はＡＬＬＥＯＰとＥＣＴネットワークを実装から導出し、所与のＣＴＬ表明をＥＣＴネットワ―ク上で評価し、結果として得られる因果チェーンを分析することによって構築される。システムはＥＣＴネットワーク内で見出した因果チェーンをトレースの形態で示す。証明の構築は対話的である。すべての場合において、ユーザは確認するＣＴＬ表明と因果チェーン（トレース）分析を導く表明を提供する。システムはユーザによって提供された各表明を確認し、適切な場合は、既に確認されている表明を使用して新しいトレースを見出す。この証明プロセスを２〜３個の簡単な例に対して示した。説明を簡単にするために、システムによって探索中に発見されたトレースを示していない。
【０４９７】
５種類の相互に関連するアクティビティがＥＣＴ評価に存在し、それらは（ｉ）所与のＣＴＬ表明に整合している開始と終了の構成を設定する、（ｉｉ）必要に応じてＣＴＬ表明とＥＣＴとの間でマッチする時間点を探す、（ｉｉｉ）ＥＣＴネットワークの選択点で条件の真理値を探す、（ｉｖ）開始構成から終了構成につながる全てのトレースを探す、（ｖ）ＣＴＬ表明内の主張を確認するためにトレースを分析する、である。有限ＡＬＬＥＯＰの場合、前述の項目（ｖ）についてだけはユーザ介入が必要なことがある。非有限ＡＬＬＥＯＰの場合、（ｉｖ）と（ｖ）の両方が必要な場合がある。
【０４９８】
これらの証明の証明理論は、システムが自身で全ての証明可能なＣＴＬ表明を確定的に証明できないという意味では完全な証明理論ではない。これは、（ｉｖ）と（ｖ）についてユーザ相互動作に依存しているためである。より経験を積むと、典型的なＡＬＬＥＯＰパターンを識別したり、可能な場合はＥＦＰ構造と有限ＡＬＬＥＯＰ構造との間に対応関係を確立したりすることによって、次第により大きな範囲へと証明構築を自動化することができる。証明理論が、ＴＩＣＣＴＭ−Ｐｐｄｅがどのように構成されているのかと、それがどのように動作するのかと、証明されている物の計算的な意味とに無関係であると言うことはできない。証明理論を定義する前に、ＴＩＣＣＴＭ−Ｐｐｄｅプログラミングシステムに対する表示的不動点意味論を定義する。これは、証明される物の計算的な意味を定義する。
【０４９９】
次のセクションは、所与のアプリケーションＡｐに対する確認すべきＣＴＬ表明を生成するためにユーザを導く基準を導入する。
【０５００】
６．５．実装の修正
Ａｐ：Ｐｔｈｒｅａｄｓ（）、Ａｐ：ＡＬＬＥＯＰｓ（）、Ａｐ：ＥＣＴｓ（）およびＡｐ：ＣａｕｓａｌＮｅｔ（）がそれぞれＡｐの実装のアプリケーションＡｐのｐｔｈｒｅａｄ、ＡＬＬＥＯＰ、ＥＣＴ、およびｃａｕｓａｌｎｅｔを表すとする。ｃａｕｓａｌｎｅｔはセクション７で説明したようにＳＭＳによって自動的に生成される。Ａｐ：Ｐｔｈｒｅａｄｓ（）内のｐｔｈｒｅａｄはユーザによって定義される。それらは対で互いに独立している。また、各ｐｔｈｒｅａｄは基本的なプログラミングステートメントだけを含んでいる短い逐次プログラムである。これらは、各ｐｔｈｒｅａｄの正しさを他のｐｔｈｒｅａｄとは独立して証明することを可能にする。設計者と実装者にはｐｔｈｒｅａｄ特徴付けを提供する責任がある。ＡＬＬＥＯＰとＥＣＴは実装の仕様からシステムによって自動的に生成される。m
【０５０１】
実行（ｒｕｎ）中にＡｐに対して生成されたｃａｕｓａｌｎｅｔがイベントパターンとＡｐ：ＡＬＬＥＯＰｓ（）内の半順序付けに違反せず、Ａｐ：ＣａｕｓａｌＮｅｔ（）内の全てのイベントが指定された期限内に発生する場合、（Ａｐ：ＣａｕｓａｌＮｅｔ（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））と書く。セクション７で説明したＳＭＳはＡｐ：ＣａｕｓａｌＮｅｔ（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））が成立するかどうかをチェックするためにこの監視を継続して実行する。
【０５０２】
トランザクションと経路によって接続されている２つのポートが良好にマッチしているという概念の正しさは図２のすぐ後の段落で定義されている。アプリケーションＡｐ内の経路によって接続されているＡｐ内のポートの全ての対が良好にマッチしている場合にだけ、Ａｐ：Ｃｏｒｒｅｃｔ（）が有効であると定義する。Ａｐ：Ｒｅｑｕｉｒｅｍｅｎｔｓ（）を設計が始まる前に構築されそれ以来更新されているアプリケーションＡｐ用の設計要件とする。Ａｐ内のトランザクションの正しさ、Ａｐ：Ｒｅｑｕｉｒｅｍｅｎｔｓ（）の定義、およびトランザクションの完了の期限の定義はすべて設計者と実装者によってＴＩＣＣＴＭ−Ｐｐｄｅとの対話によって作製することができる。もちろん、（Ａｐ：ＣａｕｓａｌＮｅｔ（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））が所与の実行（ｒｕｎ）について実装に対して成立するが、実装は正しくないこともあり得る。この可能性を避けるために、実装に対して以下の確認基準が成立するとする。
【０５０３】
［（Ａｐ：ＣａｕｓａｌＮｅｔ（）ｓａｔｉｓｆｉｅｓＡｐ：ＡＬＬＥＯＰｓ（））＆
（Ａｐ：ＡＬＬＥＯＰｓ（）  ｓａｔｉｓｆｉｅｓ  Ａｐ：Ｒｅｑｕｉｒｅｍｅｎｔｓ（））］⇔Ａｐ：Ｃｏｒｒｅｃｔ（）  （６．４４）
明らかに、（６．４４）の真偽はＡｐに対して確認されたＣＴＬ表明の設定に依存している。（６．４４）のＡｐ：Ｃｏｒｒｅｃｔ（）の概念と以前に定義されている正しさの概念は、所与の実装に対して確認すべきＣＴＬ表明の集合を選択するために使用できるという意味で確認基準を定義している。示した簡単な例について確認したＣＴＬ表明はこれらの実装について（６．４４）を満たす。その有効性がＡｐの実装の正しさを確立するＣＴＬ表明の集合の特定は（６．４４）とＡｐ：Ｃｏｒｒｅｃｔ（）の定義によって導かれる。設計者がこれを行うとここでは仮定している。
【０５０４】
明らかに、システムの実装の確認が、それが（６．４４）を満足するということであれば、ＳＭＳを使用して動的な監視によってそのシステムの性能の正しさを確認することは意味がある。この場合、確認された表明を実行（ｒｕｎ）時に発生するエラーを診断するための戦略を指定する手引きとして使用したり、確認された表明を自己修正のための戦略を指定したりするために使用することもできる。これらは、将来の研究に対して重要なトピックである。ＴＩＣＣＴＭ−Ｐｐｄｅの独自の特徴は、システムの性能をその生涯時間にわたって動的に監視するために必要なＳＭＳを自動的に提供することと、ＣＴＬ表明を通してシステム実装を確認する方法を提供することである。全ての確認と正しさのチェックとは究極的にはＡＬＬＥＯＰに依存しているため、ここで示す証明をＡＬＬＥＯＰ証明と呼ぶ。
【０５０５】
確認プロセス中に、マッチする時間点を探しながら、システムはＡＬＬＥＯＰによって比較不能であるが、ＣＴＬ表明によって同期しているか（同時に発生する）、調和している（イベントの１つが他のイベントのかならず後に発生する）イベントを識別する。イベントの対は、同期と調和がイベントが現れる確認されたＣＴＬ表明のいずれをも否定しない場合にだけ、そのような同期や調和の候補とすべきである。次のサブセクションにおいて、ｐｔｈｒｅａｄの再プログラミングを必要とせずに、必要に応じて必要な同期と調和を既に完成した実装に導入するＴＩＣＣＴＭ−Ｐｐｄｅで使用可能なアドホック同期と調和メソッドを導入する。
【０５０６】
ＴＩＣＣＴＭ−Ｐｐｄｅにおけるシステム実装の重要なタスクはプログラミングではない。ｐｔｈｒｅａｄと条件のプログラミングと比較的些細な機械的なタスクである。困難な重要なタスクは（ｉ）ＴＩＣＣＴＭネットワークの設定、（ｉｉ）ＴＩＰの定義、（ｉｉｉ）必要なｐｔｈｒｅａｄの特徴付け、および（ｉｖ）確認すべきＣＴＬ表明の識別である。ＴＩＣＣＴＭネットワークの構造は、代替の構成がテストされたり調査されたりする媒体を提供する。ＴＩＣＣＴＭパラダイムは、システム設計と実行の技術の性質をプログラミングの技術から必要なサブシステムの特定、サブシステム間の相互動作の指定、および正しさの提供の技術に変化させる。
【０５０７】
６．６．限界テストおよびアドホック調和と同期
限界テスト：ＥＣＴの分岐している木と時間点の半順序付けとをシステムのさまざまな有用な特性の確認に使用することができる。実時間システムにおいて提供する有用な１つの特徴は時間点の必要な半順序付けがＴＩＰ実行時間の変化に関わらず常に保存されていることである。これは限界テストによって行われる。
【０５０８】
ポートＣ．ｐのＴＩＰについて、時間限界（τＰｍｉｎ，τＰｍａｘ）を定義し、τＰｍｉｎは時間メッセージがｐに配信された時刻から開始してｐでのＴＩＰの実行の完了に必要な最短時間間隔であって、τＰｍｉｎはポートＣ．ｐの親セルＣが１つのポーリングサイクルを完了するのに必要な最大時間間隔であって、τＰｍａｘ＜（τＰｍｉｎ＋２ΔＣｍａｘ）であって、ΔＣｍａｘはポートＣ．ｐの親セルＣが１つのポーリングサイクルと保留中のメッセージのある全てのポートのサービスを完了し、ポートＣ．ｐのサービスに戻るのに必要な最大時間である。これは、Ｃが１つのポーリングサイクルでＣ．ｐメッセージを検知し損ない、次のポーリングでそれを取得する時に発生する。２ΔＣｍａｘがここで使用されるが、それはＣ．ｐが次のポーリングサイクルでサービスされる最後のポートになる可能性が十分にあるからである。
【０５０９】
２つのトレースが存在して、一方はポートＣ．ｐに向かい、他方はポートＤ．ｑに向かい、セルＣとＤは因果チェーンで接続されていないと仮定する。それぞれポートＣ．ｐとＤ．ｑでの対のイベントＸｐ（ｔｐ）とＸｑ（ｔｑ）の発生がｔｐ＜ｔｐであることが必要であると仮定する。（ｐ［０］，．．．，ｐ［ｒ−ｌ］＝ｐ）をＸｐに向かう因果チェーン内のポートとし、（ｑ［０］，．．．，ｑ［ｍ−ｌ］＝ｑ）をＸｑに向かう因果チェーン内のポートとする。ｔｎ（ｐ［０］）とｔｎ（ｑ［０］）をｎ番目のメッセージがそれぞれポートｐ［０］とｑ［０］に配信される時刻とし、τｐ［ｊ］ｍａｘはｐ［ｊ］：ｔｉｐ（）の実行を完了するのに必要な最大時間であって、τｑ［ｊ］ｍａｘはｑ［ｊ］：ｔｉｐ（）の実行を完了するのに必要な最小時間であって、ｔｐとｔｑはイベントＸｐとＸｑが発生する時刻である。ポートシーケンスの対に対して以下が成立する。
【０５１０】
ｔｐ≦（ｔｎ（ｐ［Ｏ］）＋Σ｛τｐ［ｊ］ｍａｘ｜０≦ｊ＜ｒ｝）＜（ｔｎ（ｑ［０］）＋Σ｛τｑ［ｉ］ｍｉｎ｜０≦ｉ＜ｍ｝）＜ｔｑ  （６．４５）
ここでイベントＸｐとＸｑはサイクル同期している必要がある。
【０５１１】
アドホック調和：ここで条件（６．４５）が満たされていないと仮定する。広範囲な再プログラムを実施せずにそれをどのように実施できるだろうか。具体的には、実装のＡＬＬＥＯＰの因果チェーンによって互いに接続されていないポートＣ１．ｆ１とＣ２．ｆ１を有している２つのセルＣ１とＣ２を仮定する。システムの正しい動作にはＣ２．ｆ１のＴＩＰがＣ１．ｆ１のＴＩＰが実行された後で初めて実行されなければならないと仮定する。この要件を□［［〈・→Ｃ１．ｆ１：ｔｉｐ（）〉（ｔ１）／＊評価完了＊／］＆［・→Ｃ２．ｆ１：ｔｉｐ（）（ｔ２）／＊評価開始＊／］⇒（ｔ１＜ｔ２）］と書く。この問題は図１６に示しているように生成とポートベクトルを使用することによってＴＩＣＣＴＭ−Ｐｐｄｅ内で容易に解かれる。
【０５１２】
2012506076.tif 000020
【０５１３】
図１６：アドホックの調和の図
２つの他のポートＣ１．ｇとＣ２．ｆ２を仮定し、［Ｃ２．ｆ１，Ｃ２．ｆ２］をポートベクトルと定義し、図１６に示しているようにＣ１．ｇをＣ２．ｆ２に接続しているブランチをインストールする。ここでＣ２はＣ２．ｆ２がＣ１．ｇから信号を受信した後で初めてＣ２．ｆ１でメッセージのサービスを行う。Ｃ１．ｇはＣ１．ｆ１：ｔｉｐ（）を実行した後にこの信号を送信する。Ｃ１．ｆ１とＣ２．ｆ１のＴＩＰは以下のフォーマットを有することになる。
【０５１４】
（Ｃ１．ｆ１：ｍＲ？（）＆Ｃ１．ｇ：ｐＲ？（）＊）｛Ｃ１．ｆ１：ｒ（）．ｓ（）；Ｃ１．ｇ：ｓ（）｝
（Ｃ２．ｆ１：ｍＲ？（）＆Ｃ２：ｆ２：ｍＲ？（）＊）｛Ｃ２．ｆ１：ｒ（）．ｓ（）；Ｃ２．ｆ２：ｓ（）｝  （６．４６）
これによって、Ｃ１．ｆ１とＣ２．ｆ１とはサイクル同期され、要件は常に満たされる。実際に、この構成はポートの対を調和させるだけでなく、以下のように、セクション７のグループ対グループ信号交換を使用してグループ対グループ相互動作をサイクル同期させるのにも使用される。
【０５１５】
（［〈・→Ｃ１．ｆ：ｔｉｐ（）〉（ｃ１．ｔ），〈Ｃ２．ｆ：ｔｉｐ（）〉（ｃ２．ｔ），．．．，〈Ｃｎ．ｆ：ｔｉｐ（）〉（ｃｎ．ｔ）／＊評価が完了＊／］
＆［・→Ｄ１．ｆ：ｔｉｐ（）（ｄ１．ｔ），Ｄ２．ｆ：ｔｉｐ（）（ｄ２．ｔ），．．．，Ｄｍ．ｆ：ｔｉｐ（）（ｄｍ．ｔ）／＊評価開始＊／］
⇒［∀（ｔ１∈｛ｃ１．ｔ，ｃ２．ｔ，．．．，ｃｎ．ｔ｝）∀（ｔ２∈｛ｄ１．ｔ，ｄ２．ｔ，．．．，ｄｍ．ｔ｝）］
（ｔ１＜ｔ２）］
ここで、必要なサイクル同期を組み込むために実装で必要な唯一の修正は（ｉ）必要なグループ対グループ経路の設定と（ｉｉ）ＴＩＰ定義の変更である。実装の残りは変更されないままである。ここでの構成は、時間信号がサブシステムのアクティビティの調和に非同期ハードウェアシステムで使用される態様と非常に似ている。
【０５１６】
2012506076.tif 000021
【０５１７】
図１７：アドホック調和
アドホック同期：ＴＩＣＣＴＭ−Ｐｐｄｅにおいて、異なるセルのポーリングサイクルは互いに同期されない。しかし、たまに、経路チェーンによって互いに接続されておらずセルグループ内にはないポートのサービスを同期させる必要がある。それらを分離されているセルと呼ぶ。したがって、分離されているセルＣｊ、０≦ｊ＜ｎに対して同期を実施したいと考える。
【０５１８】
［・→（Ｃ０．ｆ：ｔｉｐ（），．．．，Ｃｎ−１．ｆ：ｔｉｐ（））（ｔ）］  （６．４８）
これは、図１７に示している自己ループ経路をインストールすることによって行われる。図１７に示しているように、ポートＣｊ．ｇ、０≦ｊ＜ｎはセルＣｊに付属しており、各ポートＣｊ．ｇは自己ループ経路に接続されている。各Ｃｊ．ｆのＴＩＰは以下のフォーマットを有している。
【０５１９】
Ｃｊ．ｆ：ｍＲ？（）｛Ｃｊ．ｇ：ｓ（）；Ｃｊ：ｇ：ｍＲ？（）＊｛Ｃｊ．ｆ：ｒ（）．ｓ（）｝｝  （６．４９）
ここでセルＣｊ．ｇはメッセージをＣｊ．ｆを通して受信すると即座に、信号を自己ループ経路を通して自身に送信する。全てのセルＣｊが信号をそれらのそれぞれのポートＣｊ．ｇを通して送信した後で、同期している信号がエージェントａ０によって全てのＣｊ．ｇに送信される（このためのプロトコルはセクション７に記述されている）。各ＣｊはそのポートＣｊ．ｆで受信したメッセージにこの同期した信号を受信した直後に応答する。図１７のエージェントａ０に接続されているセルの１つがグローバルクロックであってもよい。その場合、すべてのセルはグローバル時間またはシステム内の他の任意のイベントに同期しているポートＣｊ．ｆでそれらのそれぞれのメッセージに応答する。これはクロック同期によるランデブー技法の使用とほとんど同じであるが、はるかにより柔軟で、同期機構をｐｔｈｒｅａｄ内にプログラムする必要は無く、自己ループネットワークのみをインストールし、ＴＩＰを修正するだけでよい。
【０５２０】
同期と調和とはここでは後からの思いつきとして行われている。これらの種類のアドホック同期と調和とは、広範囲な再プログラミングを行うこと無しに、π算法、アクターシステム、ＣＰＵ、または任意の他の現在利用可能な並列プログラミングパラダイムにおいては行うことはできない。このセクションを任意の数のノードを含むことができるＮＦＳＰ  ＡＬＬＥＯＰについての何らかのコメントで締めくくる。
【０５２１】
６．７  動的に増大している非有限状態ＡＬＬＥＯＰの例
そのための簡単なネットワークを図１８に示している。それはｎ個のセルを有している。各セルＣ［ｉ］はｃｓｍ（通信システムマネージャ）に接続されている。セルがインストールされた時に、その関連付けられているｃｓｍへのプライベート経路がセルの指定されたｃｓｍＰｏｒｔ（ｇｅｎｅｒａｌＰｏｒｔのサブクラス）から自動的に設定される。新規のセルや経路を動的にインストールする必要のあるセルは、サービス要求メッセージを、適切なセルｃｅｌｌ：ｉｎｓｔａｌｌＣｅｌｌ＆Ｐａｔｈｗａｙ（）または（ｃｅｌｌ：ｉｎｓｔａｌｌＣｅｌｌ（）；ｃｅｌｌ：ｉｎｓｔａｌｌＰａｔｈｗａｙ（）；）メソッドを呼び出すことによって、その関連付けられているｃｓｍに送信する。これらのメソッドはＴＩＣＣＴＭ−Ｐｐｄｅシステムによって提供されている。セルＸは、Ｘを破壊したり経路を破壊したりするために、要求をそのｃｓｍに送信することができる。セルはｃｓｍを使用して他のセルや経路をインストールするが、それはそれらが１００から２５０ミリ秒かかる高価な動作だからである。要求をｃｓｍにそのｃｓｍＰｏｒｔを通して送信した後、セルは他のポートのサービスをおこない、次のポーリングサイクルでｃｓｍからの応答を受信するためにｃｓｍＰｏｒｔに戻り適切な既にプログラムされているアクションを行う。ｃｓｍは要求しているセルが適切な特権を有している場合にだけ要求のサービスを行う。いずれにしても、ｃｓｍは要求しているセルに応答メッセージを返信する。
【０５２２】
2012506076.tif 000022
【０５２３】
図１８：ＮＦＳＰ  ＡＬＬＥＯＰのあるネットワーク
アプリケーションが開始された時に、図１８のネットワークはセルＣ［０］、Ｘ、およびｃｓｍだけを有している。ＸはメッセージをそのｆｕｎｃｔｉｏｎＰｏｒｔ、Ｃ［０］．ｆに送信することによってＣ「０」を起動する。最初に、Ｃ［０］のｃｓｍＰｏｒｔは図１８に示しているようにエージェントａ１にチューンされている。起動されると、その初期化の一部として、Ｃ［０］はそのｃｓｍにＣ［１］をインストールするように要求し、そのポートＣ［０］．ｇをＣ［１］．ｆに経路を通して接続する。Ｃ［０］がｃｓｍからタスクが完了したという応答を受け取ると、Ｃ［０］．ｃｓｍＰｏｒｔをエージェントａ１から切断し、メッセージをＣ［１｝．ｆにＣ［０］．ｇを通して送信し、自身の割り当てられているＣＰＵを解放することによって自身をサスペンドする。Ｃ［１］．ｆに送信されたメッセージは条件を含んでおり、以下で説明するようにＣ［１］によって使用される。
【０５２４】
Ｃ［１］．ｆに送信されたメッセージは使用可能なＣＰＵの中の１つで実行（ｒｕｎ）するためにＣ［１］を起動する。起動されると、Ｃ［１］は今度は同じことをして、そのｃｓｍＰｏｒｔをエージェントａ１に対してチューンし、次のセルＣ［２］をインストールして起動し、それからＣ［１］．ｃｓｍＰｏｒｔをａ１から接続解除し、それから受信したメッセージが止めない限り自身をサスペンドする。したがって、新しくインストールされたセルがさらに別のセルをインストールし起動し続け、受信した条件が止めない限り自身をサスペンドする。これによって、条件によって停止されない限りネットワークが拡大する。
【０５２５】
例えば、何らかのｎ＞１に対して、セルＣ［ｎ］において条件によって拡大が停止されると、Ｃ［ｎ］は新規のセルをインストールする代わりに、そのポートＣ［ｎ］．ｆで受信したメッセージに対して、応答をＣ［ｎ−１］．ｇに送信することによって応答し、それから自身を破壊し、したがって割り当てられているＣＰＵを解放する。Ｃ［ｎ］．ｆからの応答メッセージがＣ［ｎ−１］．ｇに配信された時に、Ｃ［ｎ−１］はそのサスペンドされた動作を使用可能なＣＰＵの１つにおいてレジュームし、Ｃ［ｎ］が行ったばかりのことを繰り返す。したがって、新規にインストールされた各セルが１つずつＣ［０］までそのトランザクションを完了し自身を破壊し、Ｘとｃｓｍはネットワーク内に残っているただ２つのセルとなる。その時点で、Ｃ［０］はそのポートＣ［０］．ｆを通してＸ．ｇから最初に受信したサービス要求に応答し、したがってトランザクションを完了する。
【０５２６】
この例における定義の詳細、つまりセルと経路、ＴＩＰ、ＡＬＬＥＯＰ、およびトレースを動的に生成し破壊するための構成を示すことは重要ではない。以下の因果シーケンスがトレース内で発生することに注意するだけで十分である。それは、Ｘ．ｇがＣ［０］．ｆに送信したメッセージによって始まり、Ｃ［ｎ］．ｆまで継続し、それから逆のプロセスを始める。因果チェーンを以下に示す。
【０５２７】
／＊新規のセルの漸進的な生成と起動時の通信イベント＊／
Ｘ．ｇＳ［］→Ｃ［０］．ｆＤ［］→．．．→Ｃ［０］．ｇｓ［］→Ｃ［１］．ｆＤ［］→．．．→Ｃ［１］．ｇＳ［］→Ｃ［２］．ｆＤ
→．．．→Ｃ［２］．ｇＳ［］→Ｃ［３］．ｆＤ［］→．．．→→．．．→Ｃ［ｎ−１］．ｇＳ［］→Ｃ［ｎ］．ｆＤ［］→．．．→
／＊新規のセルの自身の破壊を伴うトランザクションの漸進的な完了時の通信イベント＊／
Ｃ［ｎ］．ｆＳ［］→Ｃ［ｎ−１］．ｇＤ［］→．．．→Ｃ［ｎ−１］．ｆＳ［］→Ｃ［ｎ−２］．ｇＤ［］→．．．→→．．．→
Ｃ［２］．ｆＳ［］→Ｃ［１］．ｇＤ［］→．．．→Ｃ［０］．ｆＳ［］→Ｘ．ｇＤ［］，ｎ＞０  （６．５０）
‘Ｘ．ｇ’＝’ｇ’、’Ｃ［ｉ］．ｆ’＝’ｆｘ’および’Ｃ［ｉ］．ｇ’＝’ｇ’、０≦ｉ≦ｎと設定することによって、（６．５０）は以下のように簡単になる。
【０５２８】
ｇＳｆ０Ｄ［（ｇ０Ｓｆ１Ｄ）（ｇ１Ｓｆ２Ｄ）．．．（ｇｎ−１ＳｆｎＤ）］［（ｆｎＳｇｎ−１Ｄ）（ｆｎ−１Ｓｇｎ−２Ｄ）．．．（ｆ１Ｓｇ０Ｄ）ｆ０ＳｇＤ  （６．５１）
ここで、ｇＳｆ０Ｄ＝α、ｇｉＳｆｉ＋１Ｄ＝βｉ、ｆｉ＋１ＳｇｉＤ＝βｉ−１、０≦ｉ≦ｎおよびｆ０ＳｇＤ＝α−１と設定して、文脈依存シーケンスを得る。
【０５２９】
α［β０β１．．．βｎ］［βｎ−１．．．β１−１βｎ−１］、ｎ≧０  （６．５２）
したがって、これに対するＡＬＬＥＯＰは明らかに有限ＡＬＬＥＯＰではないが、有限の記述を有することになる。一般に、動的ネットワークに割り当てられたＡＬＬＥＯＰは一般帰納的である。
【０５３０】
ここで、（ｉ）アプリケーションと並列に実行（ｒｕｎ）されながらアプリケーションの動的に拡大しているｃａｕｓａｌｎｅｔを生成するＳＭＳ機構、（ｉｉ）メッセージが事前に指定されているセキュリティ要件を満たすポートにだけ配信されるデータ依存セキュリティチェック用の機構、および（ｉｉｉ）自動同期と調和のための機構を含んでいるグループ対グループメッセージ送信プロトコルに進む。
【０５３１】
７．グループ対グループ通信と自己監視システムのためのプロトコル
ＡＬＬＥＯＰモデルを使用してＥＣＴ評価と自己監視システム（ＳＭＳ）用の組み込み機構を通してＣＴＬ表明を証明することはＴＩＣＣＴＭ−Ｐｐｄｅの不可欠な部分である。それらはＴＩＣＣＴＭ−Ｐｐｄｅに固有である。ＳＭＳのインフラストラクチャがメッセージ交換プロトコルにどのように一体化されているのかを説明しないと、この提示は不十分である。このセクションでグループ対グループのＤａｓ経路の変形例を例としてそれを行う。
【０５３２】
ｄｍ経路については、グループ対グループメッセージ交換はサービス要求を計算グリッドの１つのマルチプロセッサのポートグループ内のｇｅｎｅｒａｌＰｏｒｔの親セルから異なるグリッド内の他のマルチプロセッサのｆｕｎｃｔｉｏｎａｌＰｏｒｔのポートグループに配信する。応答メッセージは逐次ｆｕｎｃｔｉｏｎＰｏｒｔグループによって多重化モードで送信される。応答メッセージは受信したメッセージが互いに整合していない場合、再計算が要求されるという規定と共にサービス要求を送信したｇｅｎｅｒａｌＰｏｒｔグループによって１つにまとめられる。グリッド内の各マルチプロセッサはそのマルチプロセッサ内で動作しているセルだけに関係するＳＭＳ  ｃａｕｓａｌｎｅｔを動的にインストールする。Ｄｍ経路は、４状態ハードウェアエージェント、４状態ソフトウェアポートを使用し、ハードウェアルータとスイッチも使用する。したがって、プロトコルはここで説明するものより複雑である。
【０５３３】
ｓｍ経路内でのメッセージ送信の３つのモードに対する３種類の完了信号を提供しており、ｓは送信モード、ｆは転送モード、およびｈは計算を中断する中断モードである。中断モードはｇｅｎｅｒａｌＰｏｒｔによってのみ使用される。中断モードでは、サービス要求メッセージは送信されず、経路は取り除かれる。セルグループ内のセルは情報をｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍのスクラッチパッドを通して交換することによって送信する信号の種類を調和させる。
【０５３４】
2012506076.tif 000023
【０５３５】
図１９：自己監視のあるグループ対グループのｓｍ経路
共有メモリ環境において、前述のように、経路のｖｉｒｔｕａｌＭｅｍｏｒｙのｒｅａｄＭｅｍｏｒｙ／ｗｒｉｔｅＭｅｍｏｒｙは送信モードにおいて切り替えられ、転送モードにおいて切り替えられない。送信と転送との間の選択は、ＴＩＰによって決定され、ｐｔｈｒｅａｄによって設定されたブールフラグに基づいている。ｐｔｈｒｅａｄは送信されるメッセージをＴＩＰがメッセージを転送するか送信するかによってｒｅａｄＭｅｍｏｒｙまたはｗｒｉｔｅＭｅｍｏｒｙに書き込み、ＴＩＰが正しい選択を行うように必要に応じて適切なブールフラグを設定する。したがって、ｐｔｈｒｅａｄとＴＩＰは何をするかについて互いに整合していなければならない。分散メモリメッセージ交換においては、転送モードや中断モードはなく、代わりに経路を取り除き、ネットワークルータとスイッチがそれらのアクティブな状態になり、新しい経路の確立プロセスを開始するための新しい信号を待つためのデータの終了信号、ｅとアボート信号、ａが存在する。
【０５３６】
グループ対グループメッセージパッシング用の修正されたＤａｓ経路を図１９に示している。メッセージはｇｅｎｅｒａｌＰｏｒｔのグループＧ＝［ｇ０，ｇ１，．．．，ｇｎ−１］とｆｕｎｃｔｉｏｎＰｏｒｔのグループＦ＝［ｆ０，ｆ１，．．．，ｆｍ−１］との間で交換される。経路は４つのエージェント、ａ０、ａ１、ａ２、およびａ３を有している。それらは図に示しているようにｈブランチによって互いに接続されている。４つのエージェント全てはｖｉｒｔｕａｌＭｅｍｏｒｙ、Ｍに付属している。図を明確にするために、Ｍに付属しているオフセット内でａ２とａ３とを図１９に示している。エージェントａ０はポートグループＧに対してチューンされており、ａ１はポートグループＦに対してチューンされており、ａ２はｆｕｎｃｔｉｏｎＰｏｒｔ、ｅｂ．ｆ１に対してチューンされており、ａ３はＥｖｅｎｔＢｕｉｌｄｅｒセルであるｅｂセルのｆｕｎｃｔｉｏｎＰｏｒｔ、ｅｂ．ｆ２に対してチューンされておりエージェントａ０．ｎｘｔ＝［ａ１，ａ２］およびａ１．ｎｘｔ＝［ａ０，ａ３］であるｆｕｎｃｔｉｏｎＰｏｒｔベクトル、［ｅｂ．ｆ１，ｅｂ．ｆ２］はｅｂセルに付属しているこのセルによって実行されるタスクをすぐに説明する。各ｅｂセルは、図１９のポート［ｅｂ．ｆ１，ｅｂ．ｆ２］とエージェントａ２とａ３のようにｆｕｎｃｔｉｏｎＰｏｒｔベクトル内の独立している１対のポートと関連付けられているエージェントとを通して各経路に接続されている５〜６個の別個の経路に対するサービスを行う。アプリケーションはそのような５〜６個のｅｂセルを有することがある。
【０５３７】
ポートグループＧとＦ内の各ポートは図１９に示している経路の一方の端部からその他方の端部へのメッセージの送信に必要なそのプロトコルに関連付けられている。ポートグループのポートの親セルがその計算を完了し、メッセージの送信の準備ができると、セルはそのポートに関連付けられているプロトコルの実行を開始する。したがって、ポートグループのポートの全ての親セルはそれらのそれぞれのポートで並列に相互に比較不能な時間点でプロトコルの評価を開始する。経路上のエージェントはメッセージ送信を調和させる。
【０５３８】
図１９のエージェントａｉ、ｉ＝０，１は各々がそれに対して定義されている３つの属性を有しており、１つはａｉに対してチューンされている任意のポートａｉ．ｓｅｌｅｃｔｅｄＰｏｒｔ、２番目はｆａｌｓｅに初期化されるブール属性ａｉ．ｄＣ（「ｄＣ」は「ｄｅｌｉｖｅｒｙＣｏｍｐｌｅｔｅ」を表す）、３番目は完了信号ベクトルと呼ばれるベクトル、Ｖｅｃｔｏｒ，ａｉ．ｃｓｖである。それは、ａｉに対してチューンされている各ポートに対して、そのポートから受信した信号を保存するための１つのベクトル要素とａｉ．ｎｘｔ［１］から受信した信号用の１つの要素とを有している。各要素は、４つの可能性のある値＞０、ｉ．ｃｓＶ［ｊ］＝ｃ｜ｆ｜ｈ｜ｉｇｎｏｒｅ＞０、ｃは送信、ｆは転送、ｈは中断、０≦ｊ＜ａｉ．ｃｓＶ：ｓｉｚｅ（）−１の１つを仮定しており、これらの信号はａｉにチューンされているポートによって送信される。最後の要素、ａｉ．ｃｓＶ［ａｉ．ｃｓＶ：ｓｉｚｅ（）−１］はａｉ．ｎｘｔ［１］によって送信された信号ｃを保存する。ａｉがａｉ．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅ、０≦ｊ＜ａｉ．ｃｓＶ：ｓｉｚｅ（）−１を設定するための４番目の信号が存在する。ａｉ．ｃｓＶがどのように使用されるかをすぐに説明する。
【０５３９】
ＧのｇｅｎｅｒａｌＰｏｒｔは結合サービス要求をＦのｆｕｎｃｔｉｏｎａｌＰｏｒｔに送信していると仮定する。ｇｅｎｅｒａｌＰｏｒｔグループは［Ｃｉ．ｇｉ｜０≦ｉ＜ｎ−ｌ］、ここでｎ−１＝Ｇ：ｓｉｚｅ（）およびａ０．ｃｓＶ：ｓｉｚｅ（）＝ｎである。図１９のｇｅｎｅｒａｌＰｏｒｔグループのＣｉ．ｇｉでのプロトコルは以下のフォーマットを有している（「.」をプロトコルの連続している逐次コンポーネントの連結を指定するために使用）。Ｃｉ．ｇｉ：ｐｒｏｔｏｃｏｌ（）は２つの連結されているコンポーネント、Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）とＣｉ．ｇｉ：ｓｕｆｆｉｘ（）を有している。以下のステートメント（７．２ａ）はＣｉ．ｇｉ：ｐｒｅｆｉｘ（）が何をするのかを記述している。Ｃｉ．ｇｉ：ｓｕｆｆｉｘ（）が何をするのかは後で説明する。以下では、ｍ−１＝Ｆ：ｓｉｚｅ（）とａ１．ｃｓＶ：ｓｉｚｅ（）＝ｍである。
【０５４０】
Ｃｉ．ｇｉ：ｐｒｏｔｏｃｏｌ（）＝Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）．Ｃｉ．ｇｉ：ｓｕｆｆｉｘ（）；  （７．１）
Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）＝
［（ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ≠Ｃ０．ｇ０）？（）｛ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ＝Ｃ０．ｇ０｝
（ａ０．ｃｓＶ［０］≠０）？（）｛ａ０．ｃｓＶ［０．．．ｎ−２］＝０；ａｌ．ｃｓＶ［０．．．ｍ−２］＝０；｝
ａ１．ｄＣ？（）｛ａ１．ｄＣ＝ｆａｌｓｅ；｝．（Ｃｉ＝ｘｉ→ｇｉ：ｘｉ→ａ０）
（ａ０：ｓｅｌｅｃｔｅｄＰｏｒｔ≠Ｃｉ．ｇｉ）？（）｛ａ１：ｄＣ？（）＊｛｝；｝］  （７．２ａ）
Ｃｉ．ｇｉ：ｓｕｆｆｉｘ（）＝［ＡＰＩ［ａ０．ｃｓＶ［０．．．ｎ］］？（）＊｛Ｃｉ．ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）；｝］  （７．２ｂ）
【０５４１】
親セルＣｉがメッセージを送信する準備ができた時に、グループＧの他のポートの親セルと並列にＣｉ．ｇｉ：ｐｒｅｆｉｘ（）を実行する。この並列実行は同期しておらず、異なる親セルＣｉはこれを異なる時刻に実行するかもしれない。Ｃｉ．ｇｉ：ｐｒｅｆｉｘ（）の実行中に、Ｃｉが既に設定されていない場合、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ＝Ｃ０．ｇ０とまず設定し、それからまだ初期化されていない場合ベクトルａ０．ｃｓＶとａｌ．ｃｓＶが初期化されるが、これらのベクトルの最後の要素は初期化されない。Ｃｉはそれからまだｆａｌｓｅでない場合ａ１．ｄＣ＝ｆａｌｓｅと設定する。２つまたは３つ以上のセルＣｉがこれらの初期化を同時に実施することが可能である。相互干渉は存在しないので、ｐｔｈｒｅａｄ−ｌｏｃｋは必要ない。
【０５４２】
初期化後、各セルは３つの可能性のある完了信号、ｘｉ＝ｃ｜ｆ｜ｈ＞０の１つをポートＣｉ．ｇｉに送信し、ポートはこの信号をａ０に転送する。その後、Ｃｉは表現、（ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔ≠Ｃｉ．ｇｉ）？（）｛ａ１：ｄＣ？（）＊｛｝；｝を評価する。これによって、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔの親セル以外の全てのセルＣｉはａ１：ｄＣがｔｒｕｅになるまで待ち、つまりそれらはプロトコルのさらなる実行を停止する。ａ１：ｄＣがｔｒｕｅになると、セルＣｉはサービスを行う順序で次のポートの処理を開始する。その間に、ａ１：ｄＣがｔｒｕｅになる前に、全ての他のセルがａ１：ｄＣ？（）がｔｒｕｅになるのを待っている間に、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔの親セルＣ０はＣ０．ｇ０：ｓｕｆｆｉｘ（）の実行を開始し、これはＣ０．ｇ０：ｓｕｆｆｉｘ（）を実行する唯一のセルとなる。
【０５４３】
エージェントａ０は、ａ０．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅである各Ｃｊ．ｇｊ∈Ｇからの完了信号ｘｊ＞０と、ａ０．ｃｓＶ［ｎ−ｌ］＞０について、ａ０．ｎｘｔ［１］＝ａ２からの１つの信号Ｃの受信を待つ。ａ０がポートＣｊ．ｇｊからｘｊ＞０を受信すると、Ｃｊがその計算を完了したことがわかる。ａ２からＣ＞０を受信すると、前のメッセージ交換中にｅｂが同じ経路を通して何をしたかに関わらず、完了したことがわかる。これらの信号は、（７．２）のガードａ０：ＡＰｌ［ａ０．ｃｓＶ［０．．．ｎ−１］］？（）＊の引数になる。Ｃ０はこのガードを実行するが、それはこれがプロトコルの実行を依然として継続している唯一のセルｄだからである。全てのその要素が＞０である場合でだけ、つまり全ての待っている完了信号を受信した後にだけガードはｔｒｕｅと評価される。それは、それがｔｒｕｅになるまで繰り返し実行される。それがｔｒｕｅになると、ａ０．ｓｅｌｅｃｔｅｄＰｏｒｔの親セルＣ０はＣ０．ｇ０：ｓｕｆｆｉｘ−ｂｏｄｙ（）を実行する。ｓｕｆｆｉｘ−ｂｏｄｙはＧ内の全てのｇｅｎｅｒａｌＰｏｒｔ、Ｃｊ．ｇｊについて同じである。そのため、ｓｅｌｅｃｔｅｄＰｏｒｔとしてどのｇｅｎｅｒａｌＰｏｒｔが選択されるかは問題ではない。ｓｕｆｆｉｘ−ｂｏｄｙが何をするのかはすぐに説明する。ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）を定義する前に、さらに変数とメソッドとを定義しなければならない。それらはすべてｓｍ経路内のエージェントとポートとに関連付けられており、それをこれから行う。
【０５４４】
セキュリティ指定：以下では、ａ１．Ｍはａ１に付属しているｖｉｒｔｕａｌＭｅｍｏｒｙを指している。エージェントａ１はメッセージをそれに対してチューンされているポートＤｊ．ｆｊに、ポートＤｊ．ｆｊが指定されたセキュリティ条件ａ１：Ｓｙ（Ｄｊ．ｆｊ，ａ１．Ｍ）？（）、０≦ｊ＜ｍ−１＝Ｆ：ｓｉｚｅ（）を満足する場合に限り配信する。任意のｊについてａ１：Ｓｙ（Ｄｊ．ｆｊ，ａ１．Ｍ）？（）がｆａｌｓｅの場合、ａｌ．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅが設定される、つまりｊ番目のポートが無視される。ユーザが異なる経路に対して異なるセキュリティ機能を定義することも可能である。メッセージが全ての安全なポートに配信される時に、変数ａ１．ｄＣがｔｒｕｅに設定される。
【０５４５】
他の経路変数とメソッド：変数ａ０．ｃｃＳは第２の一致プロトコルメソッド、以下の（７．４−（ｉ））で使用されるＡＰ２によって計算された合成完了信号（ｃｃｓ）の値を保持している。ＡＰ２は（７．３）で定義されている。メソッドａ０：ｒｅｓｅｔＰａｔｈｗａｙ（）はａ０が現れているｓｍ経路をその初期状態にリセットするために（７．４）で使用される。メソッド例外（ｆ）はポートｆ∈Ｆでそのポートでのセキュリティ障害についてオブザーバに警告するために例外を発行する。メソッドａ０：ｓｗＭｅｍ（）はａ０の読み／書きメモリを切り替える。メソッドｆ：ｔｉｍｅｓｔａｍｐ（）はメッセージがいつｆに配信されたかを示している親セルのローカル時間でｆでのタイムスタンプを設定する、条件ｆ：ａｃｔｉｖｅ？（）はｆの親セルがＣＰＵにおいて既に実行（ｒｕｎ）されているかどうかを確認し、メソッドｆ：ａｃｔｉｖａｔｅ（）ｆの親セルを利用可能なＣＰＵにおいて起動する。前述のように、ＴＩＣＣＴＭ−Ｐｐｄｅ自体が全てのＣＰＵの割り当てとセルの起動とを管理する。
【０５４６】
ここで、ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）を定義する準備ができており、第２の一致プロトコル関数ａ０：ＡＰ２［ａ０：ｃｓＶ［０．．．ｎ−２］］を使用する。ただし、これにはエージェントａ２から受信した信号ａ０：ｃｓＶ［ｎ−１］は含まれない。これは、ａ０がＧのｇｅｎｅｒａｌＰｏｒｔから受信した完了信号を確認し、合成完了信号ａ０．ｃｃＳ＝ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］を設定するだけであって、ここで、
ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ｃ  ｉｆ∃ｉ（０≦ｉ＜ｎ−ｌ）（ａ０．ｃｓＶ［ｉ］＝ｃ）  ｅｌｓｅ
ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ｆ  ｉｆ［（∃ｉ（０≦ｉ＜ｎ−ｌ）（ａ０．ｃｓＶ［ｉ］＝ｆ））＆
（∀ｉ（０≦ｉ＜ｎ−ｌ）（ａ０．ｃｓＶ［ｉ］＝（ｆ｜ｉｇｎｏｒｅ）））］
ｅｌｓｅ  ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ｈ  （７．３）
ただし、ａ２からの完了信号であるａ０．ｃｓＶ［ｎ−ｉ］はここでは使用されない。ここで、ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）を示し、それが何をするのか説明する。
【０５４７】
（ｉ）ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）＝／／ａ０：ｓｅｌｅｃｔｅｄＰｏｒｔの親セルによって実行（ｒｕｎ）される
［ａ０：ＡＰ２［ａ０．ｃｓＶ［０．．．ｎ−２］］＝ａ０．ｃｃＳ；／／エージェントａ２からの信号ｃはここでは除外
／／ａ０．ｃｃｓ＝ｈの場合は、プロトコルの実行をやめ、メッセージ送信を中止する
（ａ０．ｃｃＳ＝ｈ）？（）｛ａ０：ｒｅｓｅｔＰａｔｈｗａｙ（）；ａ１．ｄｃ＝ｔｒｕｅ｝
ｅｌｓｅ  ｔｒｕｅ｛ａ１：ｃｋＳｅｃｕｒｉｔｙ＆Ｐｒｏｃｅｅｄ（）；｝］
（ｉｉ）ａ１：ｃｋＳｅｃｕｒｉｔｙ＆Ｐｒｏｃｅｅｄ（）＝／／ａ０：ｓｅｌｅｃｔｅｄＰｏｒｔの親セルによって実行される
//ａ１．ｃｓＶを設定して、安全ではないポートを無視し、そのような各ポートについて違反メッセージを生成する
［∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（））？（）｛¬ａ１：Ｓ（ｆｊ，ａ１．Ｍ）？（）｛ａ１．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅ；
ａ１：ｅｘｃｅｐｔｉｏｎ（ｆｊ）；｝｝
／／Ｆの全てのｆｕｎｃｔｉｏｎＰｏｒｔが安全ではない場合、プロトコルの実行をやめる
ここでは∀ｊは列挙子として使用される
（∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（）＆（ａ１．ｃｓＶ［ｊ］＝ｉｇｎｏｒｅ））？（）｛ａ０：ｒｅｓｅｔＰａｔｈｗａｙ（）；
ａ１．ｄＣ＝ｔｒｕｅ｝
ｅｌｓｅｔｒｕｅ｛ａ０：ｓｅｎｄＳｉｇｎａｌｓ（）；ａ１：ａｃｔｉｖａｔｅ＆ＤｅｌｉｖｅｒＳｉｇｎａｌｓ（）；｝］
（ｉｉｉ）ａ０：ｓｅｎｄＳｉｇｎａｌｓ（）＝／／ａ０：ｓｅｉｅｃｔｅｄＰｏｒｔの親セルによって実行される
／／ａ２またはａ３から以前受信した信号をゼロに初期化
ａ０．ｃｓＶ［ｎ−１］＝０；ａｌ．ｃｓＶ［ｍ−ｌ］＝０；
／／ａ０．ｃｃｓ＝ｃの場合、メモリを切り替え、ｃをｅｂ．ｆ１に配信し、ｅｂのローカル時間でタイムスタンプを設定する
（ａ０．ｃｃＳ＝ｃ）？（）｛ａ０：ｓｗＭｅｍ（）；ａ０：ｓ→ａ１；
ａ０：ｃ→ａ２：ｃ→ｅｂ．ｆ１：ｔｉｍｅｓｔａｍｐ（）；｝
／＊そうでなければ、メモリを切り替えず、ｆをｅｂ．ｆ１に配信し、タイムスタンプを設定する＊／
ｅｌｓｅｔｒｕｅ｛ａ０：ｓ→ａ１；ａ０：ｆ→ａ２：ｆ→ｅｂ．ｆｘ：ｔｉｍｅｓｔａｍｐ（）；｝］
（ｉｖ）ａ１：ａｃｔｉｖａｔｅ＆ＤｅｌｉｖｅｒＳｉｇｎａｌｓ（）＝／／ａ０：ｓｅｉｅｃｔｅｄＰｏｒｔの親セルによって実行（ｒｕｎ）
／／以下では、∀ｊは列挙子として使用される。安全なｆｕｎｃｔｉｏｎＰｏｒｔの休止中の親セルを起動
［（∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（））｛（ａ１．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅ）？（）＆¬ｆｊ：ａｃｔｉｖｅ？（））？（）｛
ｆｊ：ａｃｔｉｖａｔｅ（）；｝｝
／／信号ｓを配信し、タイムスタップを安全なポートｆｊの親セルのローカル時間に設定
［（∀ｊ（０≦ｊ＜Ｆ：ｓｉｚｅ（））｛（ａ１．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅ）？（）｛
ａ１：ｓ→ｆｊ，：ｔｉｍｅＳｔａｍｐ（）；｝｝
／／ａ１．ｄｃ＝ｔｒｕｅと設定し、配信完了信号ｓをｅｂ．ｆ２に配信。タイムスタンプをｅｂのローカル時間に設定
ａ１：ｓ→ａ３：ｓ→ｅｂ．ｆ２：ｔｉｍｅｓｔａｍｐ（）；ａ１．ｄＣ＝ｔｒｕｅ；］  （７．４）
【０５４８】
同じｓｕｆｆｉｘ−ｂｏｄｙを各ｇｉ∈Ｇに関連付けることによって、ポートグループＧに対する動的変更の調和が簡単になる。新しいトランザクションが始まる前にポートをＧに動的に追加したり削除したりすることができる。ｇｉ：ｓｕｆｆｉｘ−ｂｏｄｙ（）が何をするか考える。
【０５４９】
（７．４−（ｉ））：（ａ０．ｃｃＳ＝ｈ）の場合、経路はリセットされ、ａ１．ｄＣはｔｒｕｅに設定される。この場合、メッセージは送信されない。（ａ０．ｃｃＳ≠ｈ）の場合、Ｃ０は（７．４−（ｉｉ））から始まるプロトコルの残りの実行（ｒｕｎ）を開始し、この実行の最後にａ１．ｄｃをｔｒｕｅに設定する。以下が発生する。
【０５５０】
（７．４）−（ｉｉ））：セキュリティチェックがまず実行され、ベクトルａ１．ｃｓＶが安全ではないｆｕｎｃｔｉｏｎＰｏｒｔについてｉｇｏｎｏｒｅ信号によって更新され、例外（セキュリティ障害を通知するメッセージ）が生成される。全てのｆｕｎｃｔｉｏｎＰｏｒｔが安全ではない場合、プロトコルの実行は破棄される。そうでなければ継続する。
【０５５１】
（７．４−（ｉｉｉ））：まず、ａ２とａ３から以前受信したａ０：ｃｓＶ［ｎ−ｌ］とａ１：ｃｓＶ［ｍ−ｌ］の信号をリセットする。エージェントａ０は以下を実行する。（ａ０．ｃｃＳ＝ｃ）（（７．３）を参照）の場合、読み／書きメモリは切り替えられ、開始信号ｓがａ１に送信され、信号ｃがｅｂ．ｆ１に配信され、そうでなければ、読み／書きメモリは切り替えられず、転送信号ｆがｅｂ．ｆ１に配信され信号ｓがａ１に送信される。いずれの場合も、信号配信タイムスタンプはｅｂのローカル時間で設定される。このタイムスタンプは以下の（７．６）のｅｂ．ｔｓによって参照されるメッセージディスパッチの時刻としてｅｂセルによって解釈される。全てのｅｂセルはグローバル時間に同期しているため、このメッセージディスパッチ時間はグローバル時間である。
【０５５２】
（７．４−（ｉｖ））：まず安全な各ｆｕｎｃｔｉｏｎＰｏｒｔ、ｆ［ｊ］∈Ｆについて、その親セルが既に起動されているかどうかチェックする。起動されていない場合、親セルを起動する。ＴＩＣＣＴＭ−Ｐｐｄｅでのセルの起動は比較的高価である。２ギガヘルツコンピュータにおいてセルを起動するのに約２．５マイクロ秒かかる。これがこの動作を記述しているステートメントが（（７．３）−（ｉｖ））において分離されている理由である。通常、初めてメッセージがポートに配信された時に起動は１回だけ実施され、この部分を分離することによって、送信すべき配信信号を全ての安全なポートに素早く連続して送信することができる。配信信号をすべての安全なポートに送信した後、信号ｓをタイムスタンプと共にポートｅｂ．ｆ２にエージェントａを通して配信し、それからａ１：ｄＣをｔｒｕｅに設定する。ｅｂはこのタイムスタンプをメッセージ配信時刻と解釈し、（７．６）ではｅｂ．ｔｄと表される。
【０５５３】
ＣＣＰが機械命令として実装され、タイムスタンプの設定にハードウェア支援が利用可能な場合、信号は安全なポートに２ギガヘルツＣＰＵにおいて３ナノ秒未満の連続したポートの間の間隔で配信される（推定）。安全な各ｆｕｎｃｔｉｏｎＰｏｒｔ、ｆについては、ポートｆで設定された信号配信タイムスタンプは親セルのローカル時間である。全ての安全なポートへのメッセージ配信が完了するか、プロトコル実行が破棄されると、ａ１．ｄＣはｔｒｕｅに設定される。ｆｕｎｃｔｉｏｎＰｏｒｔの親セルによる配信された信号の処理を全てのａ１：ｄＣがｔｒｕｅになってから、つまりメッセージが全ての安全なｆｕｎｃｔｉｏｎＰｏｒｔに配信された後で始まるように構成することができる。これは、ｆ：ｍＲ？（）とｇ：ｐＲ？（）以下のように修正することによって実装される。
｛〈ｆ：ｉｎｐｕｔ＝ｓ＆ａ１．ｄＣ＝ｔｒｕｅ〉（ｔ）｝［・→ｆ：ｍＲ？（）（ｔ）］｛（ｔｒｕｅ＆ｆ：ｓｔａｔｅ＝Ｓ）（ｔ’）｝
｛〈（ｇ：ｉｎｐｕｔ＝ｓ∨ｇ：ｓｔａｔｅ＝Ｓ）＆ａ０．ｄＣ＝ｔｒｕｅ）（ｔ）｝［・→ｇ：ｐＲ？（）（ｔ）］
｛〈ｔｒｕｅ＆ｇ：ｉｎｐｕｔ＝φ＆ｇ：ｓｔａｔｅ＝Ｓ〉（ｔ’）｝  （７．５）
【０５５４】
その間に、ｅｂがｅｂ．ｆ１で信号ｃ｜ｆをｅｂ．ｆ２で信号ｓをローカル時間ｅｂ．ｔｓとｅｂ．ｔｄでそれぞれ検知すると、式（５．２１）において指定されているように、グループ対グループメッセージ配信に関連付けられている以下のｃｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔをインストールする。
【０５５５】
Ｃ．ｇｉＳ｜Ｆ（ｅｂ．ｔｓ）ｆｏｒ（０≦ｉ＜ｎ），かつ〈Ｄ．ｆｊＤ〉（ｅｂ．ｔｄ）、（０≦ｊ＜ｍ）  （７．６）
それらをｃａｕｓａｌｎｅｔに統合した後、以下に示すプロトコルをそれぞれｅｂ．ｆ１とｅｂ．ｆ２で実行して完了信号ｃをａ０とａ１に返信する。
【０５５６】
（ｅｂ．ｆ１：ｃ→ａ２：ｃ→ａ０）および（ｅｂ．ｆ２：ｃ→ａ３：ｃ→ａ１）  （７．７）
この全ては、図１９のポートＤｊ．ｆｊの親セルがそれらに配信されたばかりのサービス要求に対する応答を処理している間に行われる。２つのｅｂセルがＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔを拡大しているｃａｕｓａｌｎｅｔ内の同じ場所にインストールすることはないので、ｅｂセルがｅｂセルのアクティビティを並列に実行している時に異なるｅｂセル間に相互干渉は発生しない。
【０５５７】
2012506076.tif 000024
【０５５８】
図２０：ｇｅｎｅｒａｌＰｏｒｔから安全なｆｕｎｃｔｉｏｎＰｏｒｔへのメッセージ配信におけるイベント
【０５５９】
2012506076.tif 000025
【０５６０】
図２１：安全なｆｕｎｃｔｉｏｎＰｏｒｔからｇｅｎｅｒａｌＰｏｒｔへの応答配信におけるイベント
ｅｂセルはｖｉｒｔｕａｌＭｅｍｏｒｙへアクセスするので、ａ１．ｃｓＶにアクセスしてメッセージが配信されたｆｕｎｃｔｉｏｎａｌＰｏｒｔを識別することができる。ＡＬＬＥＯＰを使用して、イベントインスタンスをインストールしなければならない拡大しているｃａｕｓａｌｎｅｔ内の位置を求めることができる。これらのデータを使用してｅｂセルはＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔをｃａｕｓａｌｎｅｔにインストールする。そのようにｃａｕｓａｌｎｅｔにインストールされたｃａｕｓａｌｎｅｔの一部を図２０に示している。ここで、ｇｉｓ、０≦ｉ＜ｎ−１のディスパッチ時刻は信号がｅｂ．ｆ１に配信された時刻のｔｓに設定される。ｆｕｎｃｔｉｏｎＰｏｒｔへの配信時刻は信号がｅｂ．ｆ２に配信されたｔｄに通常記録される。
【０５６１】
図２１は応答メッセージ送信用にインストールされたネットワークを示している。図２０と２１のｇｉＳの上付き文字Ｓはメッセージが既に転送されている場合Ｆとなる。
【０５６２】
ただし、メッセージ送信とメッセージ配信イベントインスタンスはすべてｅｂセルによってＡＬＬＥＯＰの知識から予期されている。実際に、予期されたイベントノードが事前に指定された期限内に現れない場合、拡張するｃａｕｓａｌｎｅｔを常に監視しているｅａセル（ＥｖｅｎｔＡｎａｌｙｚｅｒセル、以下で説明）は、ｅｂセルと並列に可能性のあるシステム障害についてのエラー報告をオブザーバに発行する。ｅｂセルは、イベントインスタンスをインストール中にｅｂ．ｆ１とｅｂ．ｆ２に接続されている経路のｖｉｒｔｕａｌＭｅｍｏｒｙにアクセスできるので、メッセージ送信と受信セルにおいて成立しなければならないトレース内で条件をチェックすることさえができる。しかし、これはメッセージ送信を不当に遅延させ、実行（ｒｕｎ）時には実用的ではないことがある。しかし、これはテストモードで行うことができる。
【０５６３】
サービス要求を受信したＦ内のｆｕｎｃｔｉｏｎＰｏｒｔの親セルがメッセージ配信信号をｆｕｎｃｔｉｏｎＰｏｒｔで検知した時に、ｆ｜ｃ信号をａ１に送信することによって応答メッセージを返信するために関連付けられているｐｔｈｒｅａｄとプロトコルを実行する。この時点で、ａ１はポートｅｂ．ｆｅと全ての安全なｆｕｎｃｔｉｏｎａｌＰｏｒｔだけから信号を予期しているが、それは安全ではないポートに対してｉｇｎｏｒｅ信号が既にａ１．ｃｓＶにおいて設定されているためである。応答メッセージを返送（転送）するプロトコルは、（７．１）、（７．２ａ）、（７．２ｂ）、および（７．４）に示しているプロトコルと同様で、以下の相違があり、それらは、ａ１：ｓｅｌｅｃｔｅｄＰｏｒｔがａ１．ｃｓＶの第１の安全なポート、つまりａ１．ｃｓＶ［ｊ］≠ｉｇｎｏｒｅである第１のポート、ｆｊ∈Ｆに設定されていることである。ＧのｇｅｎｅｒａｌＰｏｒｔに応答メッセージを配信するためにはセキュリティチェックは行われず、Ｇの各ポートは応答を受信する。
【０５６４】
2012506076.tif 000026
【０５６５】
図２２：ｅｂセルによって図２０と２１のトランザクションにインストールされたｃａｕｓａｌｎｅｔの部分
応答メッセージの搬送中に、（７．７）に記述しているように、ａ１は信号ｓをａ０に送信し、全ての安全なポートＤ．ｆｊから完了信号を受信し、ａ３から完了信号を受信した後で信号ｃ｜ｆをａ３にだけ送信する。エージェントａ３はｅｂに、応答メッセージがＧのｇｅｎｅｒａｌＰｏｒｔにディスパッチされていることを知らせるために、信号ｃ｜ｆをｅｂ．ｆ２に転送する。応答信号をｇｅｎｅｒａｌＰｏｒｔに配信した後、ａ０は信号ｓをａ２の送信し、ａ２はｅｂに応答メッセージがＧのｇｅｎｅｒａｌＰｏｒｔ配信されたことを知らせるためにそれをｅｂ．ｆ１に転送する。ｅｂがこれらの信号を両方のポートｅｂ．ｆ１とｅｂ．ｆ２で検知した場合、図２１に示しているＣｏｍｍｕｎｉｃａｔｉｏｎＥｖｅｎｔインスタンスを安全な各ｆｊに対して拡大しているｃａｕｓａｌｎｅｔの適切な場所にインストールする。このインストールを完了した後、ｅｂは（７．７）に示しているプロトコルを使用して完了信号ｃをｅｂ．ｆ１とｅｂ．ｆ２を通してエージェントａ０とａ１に送信する。図２０と２１のｃａｕｓａｌｎｅｔの部分を併せて図２２に示している。
【０５６６】
エージェントａ０、ａ１とポートｇとｆに対するｎｄＦＳＭについて既に説明した（図１から４を参照）。ｓｍ経路内の全てのエージェントとポートは同一の２状態ｎｄＦＳＭである。明らかに、プロトコルは点対点通信に対する方がより簡単であるが、それは選択されたポートが存在せず、ａｉ．ｃｓＶ、ｉ＝０，１は各々が２つの要素しか有していないためである。プロトコルは高々（６＋ｍ−１）個のＣＣＰを使用し、ｍ−１はＦのポートの数である。これは、ａ０に完了信号を送信するためにＣｉ．ｇｉの親セルによって並列に実行されるｎ−１個のＣＣＰを数えていない。グループ対グループ通信は比較的高価であるが、従来のグループ対グループ通信よりもはるかに安価である。
【０５６７】
前述のように、アプリケーションは５〜６個のｅｂセルをそのネットワーク内に有している。２つのｅｂが同じｓｍ経路のサービスを行うことはない。ｅｂセル以外に、アプリケーションは５〜６個のｅａセル、ＥｖｅｎｔＡｎａｌｙｚｅｒセルも有している。ｅａセルは拡大しているｃａｕｓａｌｎｅｔのＡＬＬＥＯＰとの整合性をチェックし、事前に指定したイベントパターンの発生についてオブザーバにアラートを発行するためにｃａｕｓａｌｎｅｔ内でそれらの発生を探す。ほとんどの場合、監視されるイベントパターンはＡＬＬＥＯＰノードを終端記号として使用する正規表現によって指定することができる。
【０５６８】
ＴＩＣＣＴＭ−Ｐｐｄｅのこの種類の用法は、処理ユニット（ＣＰＵ）の実質的に無限の供給を必要とする。マルチコアチップとナノテクノロジーの到来により、必要なＣＰＵはすぐに容易に入手可能になる。ＴＩＣＣＴＭ−Ｐｐｄｅは任意の数の処理ユニットを使用する自然な環境を提供するだけでなく、各アプリケーションに対して自己監視システム（ＳＭＳ）を自動的に構築するために利用可能な処理ユニットを効率的に利用する。ＡＬＬＥＯＰは、アプリケーションの実行（ｒｕｎ）中に発生する可能性のあるイベントパターンを指定する。指定されたパターンからの逸脱は、ＳＭＳによってエラーと解釈される。ｃａｕｓａｌｎｅｔ内のイベントパターンが正しく、計算された値が誤りであることももちろんあり得る。しかし、この可能性は、セクション６．５で説明したように実装中または実装後に生成される正しさの証明によって排除される。これらの特徴はＴＩＣＣＴＭ−Ｐｐｄｅに固有である。
【０５６９】
７．１.一方通行の環状道路
これまで、応答はサービス要求が送信されたのと同じ経路を通して送信されるという規約を使用してきた。たまに、異なる逐次計算が１つのセルによって異なる他のセルにおいて生成された場合、これはｐｔｈｒｅａｄを複雑にし、セルに付属しているセルの数を増加させる原因となる。これは逐次計算の効率を低下させる原因にもなる。図２３に示している修正されたＤａｓ経路はこの問題を回避している（図を簡単にするために、ｅｂセルとｅａセルを使用したＳＭＳ用の経路増加はこの図には示していない）。
【０５７０】
2012506076.tif 000027
【０５７１】
図２３：一方通行の環状道路
ここで、図２３のｇｅｎｅｒａｌＰｏｒｔグループ、Ｇ１内のポートがそれらの結合サービス要求メッセージをｆｕｎｃｔｉｏｎＰｏｒｔグループＦ１のポートに送信する。Ｇ１がこれを行った時に、そのポートは応答を受け取るために休止する。この応答をＦ３のポートから受信する。Ｆ１のポートはＧ１のポートによって送信された要求を受信し、他のサービス要求として見なすことができるそれらの結合応答をＦ２内のポートに送信する。Ｆ１がこれを行う時に、次のサービス要求メッセージをＧ１から受信するためにそのポートは休止する。この時計回りのメッセージパッシングはＧ１の最後のポートがＦ３のポートから応答を受信するまで図２３の経路ループを通して進行する。Ｇ１はこの応答をＦ３から受信した後で初めて次のサービス要求をＦ１に送信することができる。任意の数のエージェントを図２３のｖｉｒｔｕａｌＭｅｍｏｒｙに付属させることができる。図２３の修正されたＤａｓ経路を合成ｓｍ経路と呼ぶが、それはこれが１つのｖｉｒｔｕａｌＭｅｍｏｒｙとそれに関連付けられている５〜６個のエージェントとを有しているからである。この構成は並列ネットワークにおいて逐次計算を実行するのに有用である。合成経路の周囲の任意の１つのグループ内のセルは受信したメッセージを処理する時に並列に動作する。
【０５７２】
８．結論
ここではさまざまな他のパラダイムの概念を組み合わせた並列プログラミングパラダイムを導入した。ＴＩＣＣＴＭは並列プログラム開発と実行プラットフォームＴＩＣＣＴＭ−Ｐｐｄｅにおいて１つとなって動作するためにそれら全部に必要な糊を提供する。ＴＩＣＣＴＭ−Ｐｐｄｅは、（ｉ）並列処理ＴＩＣＣＴＭネットワークを定義し、（ｉｉ）ＴＩＰとＣＩＰを使用してアブストラクトにそれらのネットワークのコンポーネント間の相互動作を指定し、（ｉｉｉ）ｐｔｈｒｅａｄの連続したリファインによって実装を完成し、（ｉｖ）実装から自動的にＡＬＬＥＯＰモデルを導出し、（ｖ）アクションの特徴付けを使用してＡＬＬＥＯＰモデルからトレースを自動的に導出し、（ｖｉ）トレースからＥＣＴネットワークを構築し、（ｖｉｉ）ＥＣＴネットワークを使用してＣＴＬ表明と呼ばれるＦＳＰとＮＦＳＰの両方のレベルで実装の有効な特性の対話的な証明を生成し、（ｖｉｉｉ）ランタイム自己監視システム（ＳＭＳ）を完成した各実装に自動的に組み込み、（ｉｘ）限界試験とアドホック同期と調和を実施する方法を提供し、（ｘ）ＴＩＣＣＴＭ−Ｐｐｄｅは多数の処理ユニットを必要とし使用する。それは、統合されたＴＩＣＣＮＥＴＴＭを使用して様々なマルチコアチップ内でプログラムを効率的に開発し実行（ｒｕｎ）するために必要なアブストラクションとツールを提供する。これらは、全てのソフトウェアシステム、特に実時間サイバー物理システムとアクセス不能な任意の環境で実行（ｒｕｎ）されているシステムの設計、実装、検証、および実行（ｒｕｎ）のために有用なツールである。それらはＴＩＣＣ−ＰｐｄｅＴＭに固有である。将来、全てのソフトウェアシステムは並列ソフトウェアシステムとなると信じている。
【０５７３】
アクターシステムにおいては、アクターシステムの意味論の定義にメッセージ交換の意味論も原理的に含めることが可能である。もちろん、はるかに複雑な分析も行う。しかし、π算法において、通信の意味論は算法の意味論にそのように含めることはできず、それはπ算法の枠組み内にリンクを通した名前の通信の機構を定義できないからである。それは所与のプリミティブとして仮定しなければならない。
【０５７４】
ＴＩＣＣＴＭ−Ｐｐｄｅにおいて、同期と調和は通信システムに組み込まれている。各メッセージ交換について、厳密な境界内でメッセージ送信イベントがいつ始まり、メッセージがいつ配信されるかを予測することができる。同様に、各アクションイベントについて、実行を開始する時刻と実行を完了する時刻とは適度に厳密な境界内で予測可能である。それらをアクターシステムやπ算法において行うことはできない。我々はあるドメインのイベントの集合からそれ自体への単調連続マッピングを示すことによってＴＩＣＣＴＭ−Ｐｐｄｅの意味論を定義し、マッピングは確認された実装の実行（ｒｕｎ）によって定義される。したがって、所望の結果だけが得られるという保証がある。確認された実装は意味論の定義の一部となる。
【０５７５】
ＴＩＣＣＴＭ−ＰｐｄｅにおけるＴＩＰ相互動作仕様はπ算法相互動作の定義に類似しており、通信機構がポートに関連付けられているプロトコルによってＴＩＰにおいて明示的に指定されているところが異なっている。通信はＣＳＰと類似している態様で計算に統合されているが、はるかに高い柔軟性、パワー、非同期通信コンポーネントの相互分離を備えている。ＴＩＣＣＴＭ−Ｐｐｄｅプログラムは自己同期、自己調和、および自己起動である。それらは、プログラムを正しく動作するようにするモニタ、セマフォ、スケジューラ、シンクロナイザ、コーディネータ、シリアライザ、または任意の他の装飾を必要としない。
【０５７６】
ＴＩＣＣＴＭ−Ｐｐｄｅは任意の数の処理ユニットが使用できると仮定している。実行（ｒｕｎ）できる処理ユニットの数は、発明の概要で説明した必要とするスケーラビリティ条件が満たされる限り数百万であってもよい。簡単に言えば、スケーラビリティ条件は任意の１つのポーリングサイクルにおいてセルによってサービスを受けるポートの数はシステム内のセルの数には無関係である。セクション６で説明した解法はどれもこの基準の下で任意にスケーラブルではない。これは、マルチコアとナノスケール技術が提供可能な処理ユニットの予測される爆発的な数を利用する機会を提供する。ＴＩＣＣＴＭ−Ｐｐｄｅにおいて提案したプログラミング方法論は理想的にはそのような技術を利用するのに適している。
【０５７７】
可能な限り、現在のプロトタイプ実装はオペレーティングシステムの必要性を排除している。原理的には、ＴＩＣＣＴＭ−Ｐｐｄｅにおいてオペレーティングシステムの必要性を完全に排除することができる。それはまだ行っていない。ＴＩＣＣＴＭは、ＣＣＰがハードウェアに命令として実装されており、マルチコアチップが同様にチップに統合されているＴＩＣＣＮＥＴＴＭを通して相互接続されている場合、数百ナノ秒の範囲のレイテンシでの高速通信の構成を、共有メモリと分散メモリの通信の両方に対して提供する。所与の時刻に並列に交換可能なメッセージの数は、その時点でシステム内で実行（ｒｕｎ）されているアクティブなセルの数とＴＩＣＣＮＥＴＴＭ内の使用可能な経路の数とによってだけ制限される。
【０５７８】
ＦＳＰ［１５］とＣＴＬ［４０〜４４｝を使用した設計仕様のモデルベースの証明はシステム設計において際だったそして重要な役割を果たしている。それらは、設計を検証し、実装が満足すべき特性を確認するために必要である。ＦＳＰの問題は、アブストラクトＦＳＰ仕様は連続したリファインによって実装に直接変換できないことである。これによって、異なるツールを使用して実装を検証する必要があり、このタスクは設計の検証よりも複雑である。
【０５７９】
Ｃｌａｒｋ他［３８−４０］、［Ｅｍｅｒｓｏｎ，４１］によるモデルベースの検証はハードウェア設計仕様を検証し、ハードウェア実装を検証しないが、それは調和とレーシング条件の問題が検証システムの一部とは思えないからである。しかしながら、Ｃｌａｒｋ他によって導入された検証方法はハードウェア設計者が設計を確認するために広く使用されている。レーシングのないハードウェアシステムの設計と検証を可能にするＧＥＳＥＬ［Ｓｃｈａｕｍｏｎｔ他，４６］などのハードウェア記述言語が存在する。しかし、それらが広く使用されているかどうかは明かではない。ＴＩＣＣＴＭ−Ｐｐｄｅの仕様の方法論は、レーシングのない非同期ハードウェアシステムの実装の仕様設定と検証に使用可能である。実装の全てのタイミング、同期、および調和の要件は暗示的には仕様の一部である。それらは、検証中に対応される。唯一の制限は、コンポーネントは非同期に相互動作しなければならないことである。これによって、ＴＩＣＣＴＭ−Ｐｐｄｅはクロックパルス駆動同期ハードウェア設計には適していない。ＴＩＣＣＴＭパラダイムの使用の利点は、意図した計算のアブストラクトな仕様がアブストラクト設計のＦＳＰ仕様のようであることであるが、それらはそれを連続したリファインを通して実装に直接リダクションする方法も提供する。
【０５８０】
ＴＩＣＣＴＭパラダイムの使用は、実装を確認するためのモデルベースの正式な検証を既に検証されている部分的な実装の連続したリファインに組み合わせることを可能にする。そのような検証能力を提供する以外に、ＴＩＣＣＴＭパラダイムは、ハードウェアかソフトウェアかにかかわらず、コンポーネントが非同期に相互動作し、ＣＣＰに基づいている通信機構を使用するかぎり、アプリケーションの生涯時間を通して性能を監視するために自動的にＳＭＳ（自己監視システム）を完成した実装に自動的に組み込む。ＴＩＣＣＴＭ−Ｐｐｄｅはシステム開発の焦点をプログラミングからネットワーク構成、相互動作の仕様、および検証にシフトする。
【０５８１】
ＴＩＣＣＴＭパラダイムにおけるソフトウェア／ハードウェアコンポーネント間の相互動作のモードは、従来の並列ソフトウェアシステム、タイムスライス並行ソフトウェアシステム、または同期ハードウェアシステムのモードと同じではない。ＴＩＣＣＴＭネットワークの設計、ＴＩＰとＣＩＰの定義、ｐｔｈｒｅａｄの特徴付けの開発、および確認すべきＣＴＬ表明の識別は重要であり困難な問題である。それらには、システム設計者とプログラマを訓練する方法に対する新しいアプローチが必要である。設計者をプログラミングについてだけでなく、コンポーネント相互動作分析、論理、および検証技法についても訓練しなければならない。
【０５８２】
ここで示したアイデアには計算とソフトウェア／ハードウェア工学の新たな時代を開始する潜在力がある。個人が自分のデスクトップとラップトップコンピュータを使用する方法、コンピュータが科学技術用途において設計され使用される方法、社会、教育、ビジネス、および政府の組織がコンピュータを使用する方法に大きく影響する可能性がある。ユーザをプライバシーの侵害と悪意のある攻撃から保護する複雑で確認された安全な自己修正ソフトウェアを作成することさえできる。
付録Ｉ
装飾的な庭の解法ＴＩＰ、ＡＬＬＥＯＰ、およびトレース
【０５８３】
環境セル：
Ｅ．ｉ：ＴＩＰ（）＝［（ｉ：ｍＲ？（）＆ｇ：ｐＲ？（））｛ｇ：ｓ（）／＊すべてのセルを開始＊／
ｉ：ｓ（）；／＊ユーザへの肯定応答＊／｝（Ｉ．１）
【０５８４】
入口回転改札口入口センサ：
Ｓｅ［ｊ：０．．．１］  ．ｇ：ＴｌＰ（）  ＝
Ｓｅ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛
Ｓｅ［ｊ］．ｇ：ｓ（）；／／ｓｉｇｎａｌｓＥｔ［ｊ］．ｆｔ
Ｓｅ［ｊ］．ｇ：ｐＲ？（）＊｛Ｓｅ［ｊ］．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅ＝ｆａｌｓｅ；｝｝  （Ｉ．２）
人がゲート（回転改札口）に近づくと、ゲートのセンサがＳｅ．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅ＝ｔｒｕｅと設定される。人を公園に入れた後、または公園が満員であるので人の入園を拒否した後、人はゲートを離れる。その点で、入口回転改札口のｆｕｎｃｔｉｏｎＰｏｒｔ、Ｅｔ［ｊ］．ｆｔは応答をＳｅ．ｇに返信する。センサがこの応答を受信すると、センサはＳｅ．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅをｆａｌｓｅにリセットする。次の人がゲートに到着すると、センサは再びｔｒｕｅに設定されることになる。したがって、第２の人は第１の人がゲートを離れて初めて入園する。
【０５８５】
入口の回転改札口：
Ｅｔ［ｊ：０．．．１］．ｆｔ：ＴｌＰ（）＝
／＊信号をＥｔ［ｊ］．ｆｔで検知すると、Ｅｔ［ｊ］は経路Ｅｔ［ｊ］．ｇ⇔Ｃｆ［ｊ］を通してカウンタｃに合図する。そうした後で、以下の非決定的ポーリングを実施することによってｃからの応答を待つ＊／
［Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）｛／／この述語はＳｅ［ｊ］．ｇから信号を受信する、（Ｉ．４）を参照
Ｅｔ［ｊ］．ｇ：ｓ（）；／／入園許可を得るための信号Ｃｆ［ｊ］
／／応答を待つ
（∃（Ｐ）（Ｐ＝（Ｅｔ［ｊ］．ｇ｜Ｅｔ［ｊ］．ｆ））ｐ：ｍＲ？（））＊｛
ｓｅｌｅｃｔＯｎｅ｛（ｐ＝Ｅｔ［ｊ］．ｇ）？（）｛Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）；｝
（Ｐ＝Ｅｔ［ｊ］．ｆ）？（）｛Ｅｔ［ｊ］．ｆ：ｄｅｎｙＥｎｔｒｙ（）．ｓ（）；｝｝
／＊Ｅｔ［ｊ］．ｇが信号を送信する準備ができたときに、応答信号をＳｅ［ｊ］．ｇに送信する
Ｅｔ［ｊ］．ｇ：ｐＲ？（）＊｛Ｅｔ［ｊ］．ｆｔ：ｓ（）；｝｝  （Ｉ．３）
【０５８６】
定義：
Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）⇔Ｅｔ［ｊ］．ｆｔ．ｉｎｐｕｔ＝ｓ
⇔Ｅｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｅｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｅ．ｇ，１）］）  （Ｉ．４）
この述語は、開示の便宜上使用されている。信号がＥｔ［ｊ］．ｆｔにＳｅ［ｊ］．ｇによって配信され、Ｅｔ［ｊ］がその信号を検知した場合にだけｔｒｕｅである。Ｅｔ［ｊ］．ｆｔがＳｅ［ｊ］．ｇに応答すると、Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）はｆａｌｓｅになるが、それはＥｔ［ｊ］．ｆｔ．ｉｎｐｕｔ＝ｓがもはやｔｒｕｅにならないからである。
【０５８７】
｛Ｅｔ［ｊ］．ｇ：ｍＲ？（）＊｝［・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）］｛Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）｝  （Ｉ．５）
｛Ｅｔ［ｊ］．ｆ：ｍＲ？（）＊｝［・→Ｅｔ［ｊ］．ｆ：ｄｅｎｙＥｎｔｒｙ（）］｛¬Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ？（）｝  （Ｉ．６）
【０５８８】
出口回転改札口センサ：
Ｓｘ［ｊ：０．．．１］．ｇ：ＴｌＰ（）＝
Ｓｘ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）｛
Ｓｘ［ｊ］．ｇ：ｓ（）；／／ｓｉｇｎａｌｓｘｔ［ｊ］．ｆｔ
Ｓｘ［ｊ］．ｇ：ｐＲ？（）＊｛Ｓｘ［ｊ］．ｇ．ｐｅｒｓｏｎＡｔＧａｔｅ＝ｆａｌｓｅ；｝｝（Ｉ．７）
【０５８９】
出口の回転改札口：
ｘｔ［ｊ：０．．．１］．ｆｔ：ＴｌＰ（）＝
（Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）｛Ｘｔ［ｊ］．ｇ：ｓ（）；｝／／ｓｉｇｎａｌｓ  Ｘｔ［ｊ］．ｆｔ
Ｘｔ［ｊ］．ｆｔ：ｍＲ？（））｛Ｘｔ［ｊ］．ｇ：ｓ（）；／＊信号カウンタ＊／
Ｘｔ［ｊ］．ｇ：ｍＲ（）＊｛
ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）；｝
Ｘｔ［ｊ］．ｆｔ：ｓ（）；｝  （Ｉ．９）
【０５９０】
定義：
｛Ｘｔ［ｊ］．ｆｔ：ｍＲ？（）｝
［・→Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）］｛¬Ｘｔ［ｊ］．ｇ：ｐｅｒｓｏｎＩｎＰａｒｋ？（）｝  （Ｉ．１０）
Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）⇔Ｘｔ［ｊ］．ｆｔ．ｉｎｐｕｔ＝ｓ
⇔Ｘｔ［ｊ］．ｆｔ：ｍＲ？（〈Ｘｔ［ｊ］．ｆｔＤ〉［ｔ（Ｓｘ．ｇ，１）］）  （Ｉ．１１）
【０５９１】
カウンタ：公園に余裕がある場合、つまりｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘの場合、ポートＣ．ｆ［ｊ：０．．．１］で信号検知すると、カウンタを増加させ、Ｃｆ［ｊ］⇔Ｅｔ［ｊ］．ｇを通してＥｔ［ｊ］．ｇに応答して、入園を許可し、そうでなければ、ｃ．ｇ［ｊ］⇔Ｅｔ［ｊ］．ｆを通して入園を拒否し、応答を待ち、それからＣ．ｆ［ｊ］を通して受信した信号に肯定応答する。セルＣが起動された時にカウンタはゼロに初期化され、ｍａｘ＞０が設定される。
【０５９２】
Ｃ．ｆ［ｊ：０．．．１］：ＴＩＰ（）＝
Ｃ．ｆ［ｊ：０．．．１］：ＴＩＰ（）＝｛／／Ｅｔ［ｊ］．ｇからの人が入園しようとしているという通知を検知する
／＊ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）？（）がｔｒｕｅならばカウンタを増加させ、信号をＥｔ［ｊ］．ｇに返信して入園を許可する。これはＥｔ［ｊ］．ｇから受信した信号にも肯定応答する＊／
（ｃｏｕｎｔｅｒ，ｃｏｕｎｔ＜ｍａｘ）？（）｛ｃｏｕｎｔｅｒ＋＋；Ｃ．ｆ［ｊ］：ｓ｝
／＊そうでなければＥｔ［ｊ］．ｆに信号をそのポートＣ．ｇ［ｊ］から送信して入園を拒否する。
【０５９３】
Ｅｔ［ｊ］．ｇから受信した信号には肯定応答しない＊／
ｅｌｓｅ  ｔｒｕｅ｛Ｃｇ［ｊ］：ｓ（）；
／＊Ｅｔ［ｊ］．ｆからの肯定応答を受信すると、以前にＥｔ［ｊ］．ｇから受信した信号の肯定応答を返信する＊／
Ｃ．ｇ［ｊ］：ｍＲ？（）＊｛Ｃ．ｆ［ｊ］：ｓ（）；｝｝（Ｉ．１２）
ポートＣ．ｆ［ｊ：２．．．３］で信号を検知するとカウンタを減少させ、Ｘｔ［ｊ］．ｇｎに応答してゲートの人が出園できるようにする。
【０５９４】
Ｃ．ｆ［ｊ：２．．．３］：ＴＩＰ（）＝Ｃ．ｆ［ｊ］：ｍＲ？（）｛ｃｏｕｎｔｅｒ−−；Ｃ．ｆ［ｊ］：ｓ（）；｝  （Ｉ．１３）
ｃｏｕｎｔｅｒ．ｃｏｕｎｔをＣ．ｆ［４］で信号を検知すると表示ユニットに送信する。
【０５９５】
Ｃ．ｆ［４］：ＴＩＰ（）＝
Ｃ．ｆ［４］：ｍＲ？（）｛Ｃ．ｆ［４］：ｍａｋｅ（Ｃ．ｆ［４］．ｒｄ：ｍｓｇ（）．ｃｏｕｎｔ＝ｃｏｕｎｔｅｒ．ｃｏｕｎｔ）；
Ｃ．ｆ［４］：ｆ（）；｝  （Ｉ．１４）
【０５９６】
定義：
｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）？（）｝［・→ｃｏｕｎｔｅｒ＋＋］｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）？（）｝  （Ｉ．１５）
｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ≦ｍａｘ）？（）｝［・→ｃｏｕｎｔｅｒ――］｛ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）？（）｝  （Ｉ．１６）
【０５９７】
表示ユニット：そのＩｎｔｅｒｒｕｐｔＰｏｒｔで信号を検知すると、カウントの要求をカウンタに転送する。それを受信したらカウントを表示。
【０５９８】
Ｄ．ｉ：ＴＩＰ（）＝
Ｄ．ｉ：ｍＲ？（）｛Ｄ．ｉ：ｓ（）；Ｄ．ｇ：ｆ（）；Ｄ．ｇ：ｍＲ？（）＊｛Ｄ．ｇ：ｄｉｓｐｌａｙＣｏｕｎｔ（）．ｓ（）；｝｝  （Ｉ．１７）
【０５９９】
定義：
｛Ｄ．ｇ：ｍＲ？０＊＆（∃（ｉｎｔｅｇｅｒ  ｃ）（Ｄ．ｇ：ｒｄ．ｍｓｇ（）．ｃｏｕｎｔ＝ｃ）｝
［・→Ｄ．ｇ：ｄｉｓｐｌａｙＣｏｕｎｔ（）］｛Ｄ．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｕｎｔ＝ｃ｝  （Ｉ．１８）
【０６００】
ポーリングサイクル：表示ユニットを除くＩｎｔｅｒｒｕｐｔＰｏｒｔを無視する。
Ｅ：Ｐｏｌｌｉｎｇ（）：［Ｅ．ｉ：ｍＲ？（）→Ｅ：Ｐｏｌｌｉｎｇ（）］  （Ｉ．１９）
Ｓｅ［ｊ］：Ｐｏｌｌｉｎｇ（）：［Ｓｅ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）→Ｓｅ［ｊ］：ＰｏｌｌｉｎｇＯ］  （Ｉ．２０）
Ｓｘ［ｊ］：Ｐｏｌｌｉｎｇ（）：［Ｓｘ［ｊ］．ｇ：ｐｅｒｓｏｎＡｔＧａｔｅ？（）→Ｓｘ［ｊ］：Ｐｏｌｌｉｎｇ（）］  （Ｉ．２１）
Ｅｔ［ｊ：０．．．１］：Ｐｏｌｌｉｎｇ（）：［Ｅｔ［ｊ］．ｆｔ：ｍＲ？（）→Ｅｔ［ｊ］：Ｐｏｌｌｉｎｇ（）］  （Ｉ．２２）
Ｘｔ［ｋ：０．．．１］：Ｐｏｌｌｉｎｇ（）：［Ｘｔ［ｋ］．ｆｔ：ｍＲ？（）→Ｘｔ［ｋ］：Ｐｏｌｌｉｎｇ（）］  （Ｉ．２３）
ＣＰｏｌｌｉｎｇ（）：［Ｃ．ｆ［０］：ｍＲ？（）→Ｃ．ｆ［１］：ｍＲ？（）→Ｃ．ｆ［２］：ｍＲ？（）→
Ｃ．ｆ［３］：ｍＲ？（）→Ｃ．ｆ［４］：ｍＲ？（）→Ｃ：Ｐｏｌｌｉｎｇ］  （Ｉ．２４）
Ｄ：Ｐｏｌｌｉｎｇ（）：［Ｄ．ｉ：ｍＲ？（）→Ｄ：Ｐｏｌｌｉｎｇ（）］  （Ｉ．２５）
ＣＩＰをセルに対して定義する必要はないが、それは明白だからである。前述の定義から、システムは以下のＡＬＬＥＯＰとトレースを計算する。
【０６０１】
ＡＬＬＥＯＰ：
Ｅｔ［ｊ：０．．．１］：ＡＬＬＥＱＰ（）：
Ｅｔ［ｊ：０．．．１］：ＡＬＬＥＯＰ（）＝［Ｅｔ［ｊ］．ｆｔ：ＡＬＬＥＯＰ（）・→Ｅｔ［ｊ］：ＡＬＬＥＯＰ（）］  （Ｉ．２６）
Ｅｔ［ｊ：０．．．１］．ｆｔ：ＡＬＬＥＯＰ（）＝
［Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）｛
Ｅｔ［ｊ］．ｇｓ［ｔ（Ｅｔ［ｊ］．ｇ，０）］→
（〈ｃ．ｆ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｇ，１）］｜｜→．．．→Ｃ．ｆ［ｊ］：ＡＬＬＥＯＰ（．．．））・→
非決定的ポーリングからの選択肢をここに入れる
（Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇ０〉［ｔ（Ｃ．ｆ［ｊ］，１）］）＊｛Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）｝
｜
Ｅｔ［ｊ］．ｆ）ｍＲ？（〈Ｅｔ［ｊ］．ｆＤ〉［ｔ（Ｃ．ｇ［ｊ］，１）］）＊｛Ｅｔ［ｊ］．ｆ：ＤｅｎｙＥｎｔｒｙ（）・→
Ｅｔ［ｊ］．ｆＳ［ｔ（Ｅｔ［ｊ］．ｆ，Ｏ）］→
（〈Ｃ．ｇ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｆ，１）］
｜｜Ｃ．ｇ［ｊ］：ｍＲ？（〈Ｃ．ｇ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｆ，１）］）＊．→．．．→｝）｝
・→Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，３）］）＊｛Ｅｔ［ｊ］．ｆｔＳ［ｔ（Ｅｔ［ｊ］．ｆｔ，０）］
（→〈Ｓｅ［ｊ］．ｇ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｆｔ，１）］
｜｜［Ｓｅ［ｊ］．ｇ：ｐＲ？（〈Ｓｅ［ｊ］．ｇＤ〉［ｔ（Ｅｔ［ｊ］．ｆｔ，ｌ）］）・→．．．・→］）｝］  （Ｉ．２７）
【０６０２】
Ｘｔ［ｊ：０．．．１］  ：ＡＬＬＥＯＰ（）：
Ｘｔ［ｊ］：ＡＬＬＥＯＰ（）＝［Ｘｔ［ｊ］．ｆｔ：ＡＬＬＥＯＰ（）・→Ｘｔ［ｊ］：ＡＬＬＥＯＰ（）］  （Ｉ．２８）
Ｘｔ［ｊ］．ｆｔ：ＡＬＬＥＯＰ（）＝
［Ｘｔ［ｊ］：ｐｅｒｓｏｎＬｅａｖｉｎｇ？（）｛
Ｘｔ．ｇＳ［ｔ（Ｘｔ［ｊ］．ｇ，０）］→／＊Ｃ．ｆ［ｊ＋２］へ信号を配信＊／
（〈Ｃ．ｆ［ｊ＋２］Ｄ〉［ｔ（Ｘｔ［ｊ］．ｇ，１）］｜｜→．．．→Ｃ．ｆ［ｊ＋２］：ＡＬＬＥＯＰ（））｝
／／ｃｏｕｎｔを減少させた後
Ｘｔ［ｊ］．ｇ：ｍＲ（（Ｘｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ＋２］，１）］）＊｛
Ｘｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＬｅａｖｅ（）｝
Ｘｔ［ｊ］．ｆｔＳ［ｔ（Ｘｔ［ｊ］．ｆｔ，０）］］→〈Ｓｘ［ｊ］．ｇＤ〉［ｔ（Ｘｔ［ｊ］．ｆｔ，ｌ）］］  （Ｉ．２９）
【０６０３】
Ｃ  ＡＬＬＥＯＰ（）：カウンタＡＬＬＥＯＰ
Ｃ：ＡＬＬＥＯＰ（）＝［Ｃ．ｆ［０］：ＡＬＬＥＯＰ（）・→Ｃ．ｆ［１］：ＡＬＬＥＯＰ（）・→Ｃ．ｆ［２］：ＡＬＬＥＯＰ（）
・→Ｃ．ｆ［３］：ＡＬＬＥＯＰ（）・→Ｃ．ｆ［４］：ＡＬＬＥＯＰ（）
・→Ｃ：ＡＬＬＥＯＰ（）］  （Ｉ．３０）
Ｃ．ｆ［ｊ：０．．．１］：ＡＬＬＥＯＰ（）＝
［Ｃ．ｆ［ｊ］：ｍＲ？（〈Ｃ．ｆ［ｊ］Ｄ〉［ｔ（Ｅｔ［ｊ］．ｇ，１）］）｛
（（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）｛ｃｏｕｎｔｅｒ＋＋・→
Ｃ．ｆ［ｊ］Ｓ［ｔ（Ｃ．ｆ［ｊ］，０）］→
（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，１）］／／Ｅｔ［ｊ］．ｇは信号を即座に受信
｜｜Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，１）］）＊｛・→．．．・→｝・→．．．・→）｝｜
¬（ｃｏｕｎｔｅｒ．ｃｏｕｎｔ＜ｍａｘ）｛ｃｏｕｎｔｅｒ−−・→
Ｃｇ［ｊ］Ｓ［ｔ（Ｃ．ｇ［ｊ］，０）］→
（Ｅｔ［ｊ］．ｆＤ［ｔ（Ｃ．ｇ［ｊ］，１）］
｜｜Ｅｔ［ｊ］．ｆ：ｍＲ？（〈Ｅｔ［ｊ］．ｆＤ〉［ｔ（Ｃ．ｇ［ｊ］，１）］）＊｛・→．．．・→｝・→．．．・→）
・→Ｃ．ｇ［ｊ］：ｍＲ？（）＊｛／／Ｅｔ［ｊ］．ｆからの応答を待つ
Ｃ．ｆ［ｊ］で受信した信号について肯定応答と返信
ｃ．ｆ［ｊ］Ｓ［ｔ（ｃ．ｆ［ｊ］，２）］→
（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，３）］／／Ｅｔ［ｊ］．ｇは肯定応答を即座に受信
｜｜Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，３）］）＊｛・→．．．・→｝）｝｝］  （Ｉ．３１）
Ｃ．ｆ［ｊ：２．．．３］：ＡＬＬＥＯＰ（）＝
［／／ｘｔ［ｊ−２］．ｇから人が出園するのを検知
Ｃ．ｆ［ｊ］：ｍＲ？（〈Ｃ．ｆ［ｊ］Ｄ〉［ｔ（Ｘｔ［ｊ−２］．ｇ，ｌ）］）｛ｃｏｕｎｔｅｒ――
・→Ｃｆ［ｊ］Ｓ［ｔ（Ｃ．ｆ［ｊ］，０）］／／ｘｔ［ｊ−２］．ｇに応答
→（〈Ｘｔ［ｊ−２］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，ｌ）］
／／Ｘｔ［ｊ−２］はＣ．ｆ［ｊ］からの応答を待ち、適切なアクションを行う
（〈Ｘｔ［ｊ−２］．ｇ：ｍＲ？（〈Ｘｔ［ｊ−２］．ｇＤ〉［ｔ（Ｃ．ｆ［ｊ］，１）］）＊｛．・→．．．・→｝）］  （Ｉ．３２）
Ｃ．ｆ［４］：ＡＬＬＥＯＰ（）＝
［Ｃ．ｆ［４］：ｍＲ？（〈Ｃ．ｆ［４］Ｄ〈［ｔ（Ｄ．ｇ，１）］）｛
・→Ｃ．ｆ［４］．ｒｄ：ｍａｋｅ（ｆ［４］：ｍｓｇ（）．ｃｏｕｎｔ＝ｃｏｕｎｔｅｒ．ｃｏｕｎｔ）
・→Ｃ．ｆ［４］Ｆ［ｔ（Ｃ．ｆ［４］，０）／／メッセージを転送
→（〈Ｄ．ｇＤ〉［ｔ（Ｃ．ｆ［４］，１）］
／／ＤはＣ．ｆ［４］からの応答を待ち、適切なアクションを行う
｜｜Ｄ．ｇ：ｍＲ？（〈Ｄ．ｇＤ〉［ｔ（Ｃ．ｆ［４］，１）］）＊｛・→．．．・→｝）｝］  （Ｉ．３３）
【０６０４】
Ｄ：ＡＬＬＥＯＰ（）：表示ユニットＡＬＬＥＯＰ。ここでＵはカウントを要求する外部ユーザ
Ｄ：ＡＬＬＥＯＰ（）＝［Ｄ．ｉ：ＡＬＬＥＯＰ（）・→Ｄ：ＡＬＬＥＯＰ（）］  （Ｉ．３４）
Ｄ．ｉ：ＡＬＬＥＯＰ（）＝
［Ｄ．ｉ：ｍＲ？（（Ｄ．ｉＤ〉［ｔ（Ｕ．ｇ，１）］）＊｛
Ｄ．ｉＳ［ｔ（Ｄ．ｉ，０）］→Ｕ．ｇＤ［ｔ（Ｄ．ｉ，１）］／／ユーザの信号を確認
・→Ｄ．ｇＦ［ｔ（Ｄ．ｇ，０）］／／カウントを要求
→（〈Ｃ．ｆ［４］Ｄ〉［ｔ（Ｄ．ｇ，１）］｜｜→．．．→Ｃ．ｆ［４］：ＡＬＬＥＯＰ（））
／／応答の受信時のカウントを表示
・→Ｄ．ｇ：ｍＲ？（〈Ｄ．ｇＤ〉［ｔ＜Ｃ．ｆ［４］，１）］）＊｛Ｄ．ｇ：ｄｉｓｐｌａｙＣｏｕｎｔ（）｝  （Ｉ．３５）
ただし、（Ｉ．３５）において、Ｄ．ｇを通して受信したメッセージに対しては応答は必要ではない。ＯＧ解法に対する結合ＡＬＬＥＯＰは以下のとおり：
装飾的な庭：ＡＬＬＥＯＰ（）＝
□
（Ｅｔ［０］：ＡＬＬＥＯＰ（）｜｜Ｅｔ［１］：ＡＬＬＥＯＰ（）｜｜Ｄ：ＡＬＬＥＯＰ（）｜｜
Ｘｔ［０］：ＡＬＬＥＯＰ（）｜｜Ｘｔ［１］：ＡＬＬＥＯＰ（）｜｜ＣＡＬＬＥＯＰ（））］  （Ｉ．３６）
【０６０５】
トレース：入口の回転改札口Ｅｔ［ｊ］のトレースだけを示す。
入口の回転改札口のトレース：以下のトレースは、（Ｉ．２７）のＥｔ［ｊ：０．．．１］．ｆｔ：ＡＬＬＥＯＰ（）から導出されている。このトレース内の情報は、セクション６．１の表ＩのＥＣＴネットワークの上部の３つのブロックに示されている。表１はＣ．ｆ［ｊ：０．．．１］：ｔｒａｃｅ（ｃｆ［ｊ］．ｔ０）および、Ｅｔ［ｊ］．ｆｔ：ｔｒａｃｅ（ｅ［ｊ］ｆｔ．ｔ０）とＣ．ｆ［ｊ］：ｔｒａｃｅ（ｃｆ［ｊ］．ｔ０）との間の相互動作の情報も示している。読者が以下のトレースと表Ｉの上部の３つのブロックの情報を比較すること提案する。これによって、読者はトレースとＥＣＴとの間の対応を理解できる。それは退屈であるが、複雑ではない。
Ｅｔ［ｊ：０．．．１］．ｆｔ：ｔｒａｃｅ（ｅ［ｊ］ｆｔ．ｔ０）＝
［∃（ｅ［ｊ］ｆｔ．ｔ０＜ｅ［ｊ］ｆｔ．ｔ１＜ｅ［ｊ］ｇ．ｔ０＜｛ｅ［ｊ］ｑ．ｔ１，ｅ［ｊ］ｆ．ｔ０）＜
（ｅ［ｊ］．ｔ４，（ｅ［ｊ］．ｔ２＜ｅ［ｊ］ｆ．ｔ５＜ｅ［ｊ］ｆ．ｔ６））
／／センサポート、Ｓｅ［ｊ］．ｇから信号を受信し、人を入園させる
｛Ｅｔ［ｊ］：ｐｅｒｓｏｎＥｎｔｅｒｉｎｇ？（）（ｅ［ｊ］ｆｔ．ｔ０））｝
／／カウンタのＣ．ｆ［ｊ］に信号を送信して入園する人について知らせる
［・→Ｅｔ［ｊ］．ｇＳ（ｅ［ｊ］ｇ．ｔ０∈ｔ（Ｅｔ［ｊ］．ｇ，０））］
／／信号をＣ．ｆ［ｊ］に配信し、Ｃ．ｆ［ｊ］を並列に起動
（［〈→Ｃ．ｆ［ｊ］Ｄ〉（ｅ［ｊ］ｇ．ｔ１∈ｔ（Ｅｔ［ｊ］．ｇ，１））］
｜｜→．．．→Ｃ．ｆ［ｊ］：ｔｒａｃｅ（ｅ［ｊ］ｇ．ｔ１＝ｃｆ［ｊ］．ｔ０））
／＊この時点で、Ｅｔ［ｊ］は非決定的検知、ＴＩＰ（Ｉ．３）の∃（ｐ）（Ｅｔ［ｊ］．ｇ｜Ｅｔ［ｊ］．ｆ）ｐ：ｉｔｉＲ？（）＊の実施を待つ。この検知が成功した時の結果を以下に示す。ケース（ｉ）：Ｃ．ｆ［ｊ］からＥｔ［ｊ］．ｇで信号を受信。これによって入場を許可し、同時にＣ．ｆ［ｊ］に以前に送信された信号をＥｔ［ｊ］．ｇに肯定応答＊／
（｛〈Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｇ．ｔ２∈ｔ（Ｃ．ｆ［ｊ］，１）））＊〉（ｅ［ｊ］ｇ．ｔ２）｝
［・→Ｅｔ［ｊ］．ｇ：ｌｅｔＰｅｒｓｏｎＩｎ（）（ｅ［ｊ］ｇ．ｔ２）］｛〈Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ（）〉（ｅ［ｊ］．ｔ１）｝
｜／＊ケース（ｉｉ）：Ｃ．ｇ［ｊ］から信号をＥｔ［ｊ］で受信。これによって入園を拒否。この時点で以前にＣ．ｆｊ］にＥｔ［ｊ］．ｇを通して送信した信号に対する肯定応答は受信されていない＊／
｛（Ｅｔ［ｊ］．ｆ：ｍＲ？（〈Ｅｔ［ｊ］．ｆＤ〉（ｃｆ［ｊ］．ｔ４＝ｅ［ｊ］ｆ．ｔ０∈ｔ（Ｃ．ｆ［ｊ］，１）））＊〉（ｅ［ｊ］ｆ．ｔ０）｝
［・→Ｅｔ［ｊ］．ｆ：ｄｅｎｙＥｎｔｒｙ（）（ｅ［ｊ］ｆ．ｔ０）］｛〈¬Ｅｔ［ｊ］：ｐｅｒｓｏｎＩｎＰａｒｋ（）〉（ｅ［ｊ］．ｔ３）｝）
／／Ｅｔ［ｊ］．ｆはＣ．ｇ［ｊ］にそのポートからの信号の受信についての肯定応答を送信
［・→Ｅｔ［ｊ］．ｆＳ（ｅ［ｊ］ｆ．ｔ１∈ｔ（Ｅｔ［ｊ］．ｆ，０））］
／＊並列起動と応答によって信号を検知したＣ．ｇ［ｊ］に肯定応答信号を配信＊／
（［（→Ｃ．ｇ［ｊ］Ｄ）（ｅ［ｊ］ｆ．ｔ２＝ｃｇ［ｊ］．ｔ２∈ｔ（Ｅｔ［ｊ］．ｆ，１））］｜｜
→．．．→（〈Ｃｇ［ｊ］：ｍＲ？（〈Ｃ．ｇ［ｊ］Ｄ〉（ｅ［ｊ］ｆ．ｔ２＝ｃｇ［ｊ］．ｔ２））＊〉（ｃｇ［ｊ］．ｔ２）｝・→．．．・→）
／＊Ｅｔ［ｊ］．ｇは、以前に人の入園についてＳｅ［ｊ］によって知らされた時にＣ．ｆ［ｊ］に送信された信号Ｅｔ［ｊ］．ｇについてＣ．ｆ［ｊ］から肯定応答を受信＊／
Ｅｔ［ｊ］．ｇ：ｐＲ？（〈→Ｅｔ［ｊ］．ｇＤ〉（ｅ［ｊ］ｇ．ｔ３＝ｃｆ［ｊ］．ｔ５））＊〉（ｅ［ｊ］ｇ．ｔ３）））
／／最終的に、肯定応答をセンサポートＳｅ［ｊ］．ｇに返信
｛〈Ｅｔ［ｊ］．ｇ：ｍＲ？（〈Ｅｔ［ｊ］．ｇＤ〉（ｅ［ｊ］ｇ．ｔ３）｝
［・→Ｅｔ［ｊ］．ｆｔＳ（ｅ［ｊ］．ｔ１｜ｅ［ｊ］ｆ．ｔ５）］［〈→Ｓｅ［ｊ］．ｇＤ〉（ｅ［ｊ］．ｆｔ．ｔ６）］）］  （Ｉ．３７）
この実装の他のトレースは表ＩとＩＩのＥＣＴネットワークから推定できる。
付録ＩＩ
ＰＣの解法：ＴＩＰ、ＣＩＰ、ＡＬＬＥＯＰ、およびトレース
【０６０６】
ここで、実装の全てのセルクラスについてＣＩＰを定義することによって実装を説明する。この例ではそうすることが比較的都合がよい。また、これは実装を定義する異なるスタイルも示している。
【０６０７】
生産者のＣＩＰとＴＩＰ：
初期化後、各ポーリングサイクルにおいて、生産者Ｐ［ｊ］はそのＩｎｔｅｒｒｕｐｔＰｏｒｔ、Ｐ［ｊ］．ｉにおいて信号を探す。信号がＰ［ｊ］．ｉに存在すれは、Ｐ［ｊ］はその動作を終了する。そうでなければ、そのポートＰ［ｊ］．ｆのポーリングに進み、Ｐ［ｊ］．ｆで信号を検知するたびに新しい製品を作り、（ＩＩ．２）のＰ［ｊ］：ｔｉｐ（）で定義されているようにそれを卸売業者のポートＤ．ｇ［ｊ］に送出する。
【０６０８】
ｖｏｉｄＰｒｏｄｕｃｅｒ：：ＣＩＰ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉ：ｓ（）；ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｍｔｉａｌｉｚｅ＝ｆａｌｓｅ；｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛ｉ：ｍＲ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；ｉ：ｓ（）；｝
ｆ：ｍＲ？（）｛ｆ：ｔｉｐ（）；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝  （ＩＩ．１）
Ｐ［ｊ］．ｆ：ＴＩＰ（）＝［Ｐ［ｊ］．ｆ：ｍＲ？（）｛Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）；
Ｐ［ｊ］．ｆ．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝Ｐ［ｊ］．ｐｒｏｄｕｃｔ）；
Ｐ［ｊ］．ｆ：ｓ（）；｝｝］  （ＩＩ．２）
【０６０９】
定義：
∃（ｔ０＜ｔ１）｛〈Ｐ［ｊ］．ｆ：ｍＲ？（）〉（ｔ０）｝［・→Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝Ｐ［ｊ］：ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）（ｔ０）］
｛∃（Ｐｒｏｄｕｃｔ  ｐ）（Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝ｐ）（ｔ１）｝（ＩＩ．３）
【０６１０】
消費者のＣＩＰとＴＩＰ：
ｖｏｉｄＣｏｎｓｕｍｅｒ：：ＣＩＰ（）｛
／＊初期化中に、各消費者、Ｃ［ｊ］、０≦ｊ＜ｍは空のパッケージをそのポートｃ［ｊ］．ｇのｒｅａｄＭｅｍｏｒｙに書き込んで、新規の製品を要求するためにそれを卸売業者ポートＤ．ｆ［ｊ］に送信する。ただし、ｒｅａｄＭｅｍｏｒｙ内のパッケージは、Ｄ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内に受信される。そのｗｈｉｌｅループにおいて、Ｃ［ｊ］はその割り込みポート、Ｃ［ｊ］．ｉでメッセージを受信すると自身を終了する。そうでなければ、新規の製品をＣ［ｊ］．ｇを通して受け取り、製品を消費すると、他の新規の製品を要求するために、そのｒｅａｄＭｅｍｏｒｙ内の空のパッケージを卸売業者ポートＤ．ｆ［ｊ］に送る。卸売業者ＤはそのポートＤ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内で空のパッケージを受け取る。空のパッケージを受け取ると、Ｄは新しい製品を探し、それをＤ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のパッケージに入れ、Ｃ［ｊ］．ｇに送る。パッケージは製品を要求しまた受け取るために消費者によって繰り返し利用される＊／
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉ：ｐＲ？（）｛ｉ：ｓ（）｝；ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝．ｆａｌｓｅ；
ｇ．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）；ｇ：ｓ（）；｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛ｉ：ｍＲ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；ｉ：ｓ（）；｝
ｇ：ｍＲ？（）｛ｇ：ｔｉｐ（）；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅＯ；｝  （ＩＩ．４）
Ｃ［ｊ］．ｇ：ＴＩＰ（）＝［Ｃ［ｊ］．ｇ：ｍＲ？（）｛Ｃ［ｊ］：ｐｉｃｋＵｐ（）；
／＊ｓｔｏｐＰｏｌｌｉｎｇがｆａｌｓｅの時にだけ新規の製品に対する要求を送信＊／
（¬ｓｔｏｐＰｏｌｌｉｎｇ？（）＆Ｃ［ｊ］：ｕｓｅｄＵｐ？（）＊）｛Ｃ［ｊ］．ｇ：ｓ（）；｝｝］  （ＩＩ．５）
【０６１１】
定義：
［∃（ｔ０＜ｔ１）∃（Ｐｒｏｄｕｃｔｐ）｛〈Ｃ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｐ〉（ｔ０）｝［・→Ｃ［ｊ］：ｐｉｃｋＵｐ（）（ｔ０）］
｛〈Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔ＝ｐ＆Ｃ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ〉（ｔ１）｝］  （ＩＩ．６）
Ｃ［ｊ］．ｈａｓＰｒｏｄｕｃｔはＣｏｎｓｕｍｅｒクラスにおいて定義された属性である。（ＩＩ．５）のＣ［ｊ］：ｕｓｅｄＵｐ？（）を設計者によって適切な態様でＣｏｎｓｕｍｅｒクラスにおいて定義しなければならない。
【０６１２】
卸売業者のＣＩＰとＴＩＰ：
ｖｏｉｄＤｉｓｔｒｉｂｕｔｏｒ：：ＣＩＰ（）｛／／ｎは生産者の数
ｉｎｉｔｉａｌｉｚｅ？（）｛ｉ：ｐＲ？（）｛ｉ：ｓ（）；｝／／起動を確認
ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝．ｆａｌｓｅ；／／自身を初期化
ｇ：ｓ（）；／／全ての製品と消費者を起動、図１２のネットワークを参照
／＊そのポートＤ．ｇ［ｊ］、０≦ｊ＜ｎの各々のｒｅａｄＭｅｍｏｒｙ内に空のパッケージを書き込み、新規の製品を注文するためにそれを生産者Ｐ［ｊ］のｆｕｎｃｔｉｏｎＰｏｒｔ、Ｐ［ｊ］．ｆに送る。Ｐ［ｊ］はその空のパッケージをＰ［ｊ］．ｆのｗｒｉｔｅＭｅｍｏｒｙで受け取る。この注文を受け取ると、Ｐ［ｊ］は新規の製品を生産し、それをＰ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のパッケージに入れ、Ｄ．ｇ［ｊ］に送る＊／
ｆｏｒ（ｉｎｔｊ＝０；ｊ＜ｎ；ｊ＋＋；）｛
ｇ［ｊ］．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）；ｇ［ｊ］：ｓ（）；｝｝
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛
／＊割り込み信号を受信すると、終了信号を全ての消費者に送信し、ｓｔｏｐＰｏｌｌｉｎｇをｔｒｕｅに設定＊／
ｉ：ｍＲ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；ｇ：ｓ（）；ｉ：ｓ（）；｝
ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄ＝ｆａｌｓｅ；Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｃｌｅａｒ（）；
／＊消費者はそれらから要求を受信した順序でサービスを受ける＊／
ｆｏｒ（ｉｎｔ  ｊ＝０；ｊ＜ｍ；ｊ＋＋）｛
ｆ［ｊ］：ｍＲ？（）｛Ｄ：ｓｏｒｔＩｎｔｏ（Ｄ．ｆ［ｊ］，Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ）；｝
ｆｏｒ（ｉｎｔｉ＝０；ｉ＜Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｓｉｚｅ（）；ｉ＋＋）｛
Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［ｉ］：ｔｉｐ（）；ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄ＝ｔｒｕｅ；｝
/*割り込み信号を受信しても、ｉ：ｍＲ？（）はｔｒｕｅのままである。この場合、ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄがｆａｌｓｅであれば、つまり、消費者が現在のポーリングサイクルでサービスを受けていない場合、全ての消費者と生産者から終了したという応答を受信した後で自身を終了する。サービスを受けた消費者が存在する場合、サービスを受ける消費者がいなくなるまでポーリングサイクルを繰り返す＊／
（ｓｔｏｐＰｏｌｌｉｎｇ？（）＆¬ｃｏｎｓｕｍｅｒＳｅｒｖｉｃｅｄ？（））｛
ｇ：ｐＲ？（）＊｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝｝｝｝  （ＩＩ．７）
Ｄ．ｆ［ｊ：０．．．ｍ−１］：ＴＩＰ（）＝［Ｄ．ｆ［ｊ］：ｍＲ？（）｛（∃ｋ（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（））＊｛
Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）；
Ｄ．ｇ［ｋ］：ｓ（）；Ｄ．ｆ［ｊ］：ｓ（）；｝｝］  （ＩＩ．８）
【０６１３】
定義：
｛〈∃（ｘ）（ｘ＝Ｄ．ｇ［ｋ］：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ〉（ｔ０）｝［・→Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）（ｔ０）］
｛〈Ｄ．ｆ［ｊ］：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝ｘ＆Ｄ．ｇ［ｋ］：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ〉（ｔ１）｝  （ＩＩ．９）
【０６１４】
ＡＬＬＥＯＰ：以下のＡＬＬＥＯＰにおいて、便宜上、全てのＩｎｔｅｒｒｕｐｔＰｏｒｔのポーリング、メッセージパッシング、および終了プロセスを無視する。
【０６１５】
消費者Ｃ［ｊ：０．．．（ｍ−１）］  ＡＬＬＥＯＰ：
Ｃ［ｊ：０．．ｍ−１］：ＡＬＬＥＯＰ（）＝［Ｃ［ｊ］：ＩＮＩＴ−ＡＬＬＥＯＰ（）・→Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）］  （ＩＩ．１０）
Ｃ［ｊ］：ＩＮＩＴ−ＡＬＬＥＯＰ（）＝［Ｃ［ｊ］：ｉｎｉｔｉａｌｉｚｅ？（）｛
ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→Ｃ［ｊ］．ｇ．ｗｒ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）；
・→Ｃ［ｊ］．ｇＳ［ｔ（Ｃ［ｊ］．ｇ，０）］／／製品に対する要求を送信
→（〈Ｄ．ｆ［ｊ］Ｄ〉［ｔ（Ｃ［ｊ］．ｇ，１）］｜｜Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（））｝］  （ＩＩ．１１）
Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）＝［¬Ｃ［ｊ］：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｃ［ｊ］．ｇ：ＡＬＬＥＯＰ（）
・→Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）｝］  （ＩＩ．１２）
Ｃ［ｊ］．ｇ：ＡＬＬＥＯＰＯ＝［Ｃ［ｊ］．ｇ：ｍＲ？（〈Ｃ［ｊ］．ｇＤ〉［ｔ（Ｄ．ｆ［ｊ］，１）］）｛ｇ：ｐｉｃｋｕｐ（）
・→Ｃ［ｊ］：ｕｓｅｄＵｐ？（）＊｛ｇＳ［ｔ（Ｃ［ｊ］．ｇ，２）］
→（〈Ｄ．ｆ［ｊ］Ｄ〉［ｔ（Ｃ［ｊ］．ｇ，３）］｜｜Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（））｝｝］  （ＩＩ．１３）
【０６１６】
生産者Ｐ［ｊ：０．．．（ｎ−１）］  ＡＬＬＥＯＰ：
Ｐ［ｊ］：ＡＬＬＥＯＰ（．．．）＝［Ｐ［ｊ］：ＩＮＩＴ−ＡＬＬＥＯＰＯ・→Ｐ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）］  （ＩＩ．１４）
Ｐ［ｊ｝：ＩＮＩＴ−ＡＬＬＥＯＰ（）＝
［Ｐ［ｊ］：ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｍｔｉａｌｉｚｅ＝ｆａｌｓｅ｝］  （ＩＩＩ．１５）
Ｐ［ｊ］：Ｂ０ＤＹ−ＡＬＬＥＯＰ（）＝［¬Ｐ［ｊ］ＳｔｏｐＰｏｌｌｉｎｇ？（）｛Ｐ［ｊ］．ｆ：ＡＬＬＥＯＰ（）
・→Ｐ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（）｝］  （ＩＩ．１６）
Ｐ［ｊ］．ｆ：ＡＬＬＥＯＰ（）＝
Ｐ［ｊ］．ｆ：ｍＲ？（〈Ｐ［ｊ］．ｆＤ〉［ｔ（Ｄ．ｇ［ｊ］，ｌ）］｜〈Ｐ［ｊ］．ｆＤ〉［（ｔ（Ｄ．ｇ［ｊ］，３）］）｛
・→Ｐ［ｊ］．ｐｒｏｄｕｃｔ＝ｐｒｏｄｕｃｅＰｒｏｄｕｃｔ（）
・→Ｐ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝Ｐ［ｊ］．ｐｒｏｄｕｃｔ）
→Ｐ［ｊ］．ｆＳ［ｔ（Ｐ［ｊ］．ｆ，０）］
→（〈Ｄ．ｇ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｆ，１）］
｜｜Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（．．．））｝］  （ＩＩ．１７）
【０６１７】
卸売業者ＡＬＬＥＯＰ：
Ｄ：ＡＬＬＥＯＰ（．．．）＝［Ｄ：ＩＮＩＴ−ＡＬＬＥＯＰ（）・→Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（）］  （ＩＩ．１８）
Ｄ：ＩＮＩＴ−ＡＬＬＥＯＰ（）＝
［ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
／／新規の製品を生産者に注文。ＩｎｔｅｒｒｕｐｔＰｏｒｔのメッセージ送信は無視されている
∀（ｊ）（０≦ｊ＜ｎ）｛・→Ｄ．ｇ［ｊ］．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔｅｎｔｓ＝φ）
・→Ｄ．ｇ［ｊ］Ｓ［ｔ（Ｄ．ｇ［ｊ］，Ｏ）］
→（〈Ｐ［ｊ］．ｆＤ〉［ｔ（Ｄ．ｇ［ｊ］，ｌ）］｜｜Ｐ［ｊ］：Ｂ０ＤＹ−ＡＬＬＥＯＰ（））｝｝］  （ＩＩ．１９）
Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（）＝
［¬Ｄ：ｓｔｏｐＰｏｌｌｉｎｇ｛
∀（ｊ）（０≦ｊ＜ｍ）｛Ｄ．ｆ［ｊ］：ｍＲ？（〈Ｄ．ｆ［ｊ］Ｄ〉［（ｔ（Ｃ［ｊ］．ｇ，ｌ）｜（ｔ（Ｃ［ｊ］．ｇ，３）］）｛
・→Ｄ：ｓｏｒｔＩｎｔｏ（Ｄ．ｆ［ｊ］，Ｄ．ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ）｝・→
（ｆｏｒ（ｊ＝０；ｊ＜ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ：ｓｉｚｅ（）；ｊ＋＋））｛
ｓｏｒｔｅｄＰｏｒｔｓＬｉｓｔ［ｊ］：ｔｉｐ−ＡＬＬＥＯＰ（）｝
・→Ｄ：ＢＯＤＹ−ＡＬＬＥＯＰ（）｝］  （ＩＩ．２０）
Ｄ．ｆ［ｊ］：ＡＬＬＥＯＰ（）＝［Ｄ．ｆ［ｊ］：ｍＲ？（〈Ｄ．ｆ［ｊ］Ｄ〉［（ｔ（Ｃ［ｊ］．ｇ，１）Ｉ（ｔ（Ｃ［ｊ］．ｇ，３）］）｛
Ｄ．ｆ［ｊ］：ｔｉｐ−ＡＬＬＥＯＰ（）｝］  （ＩＩ．２１）
Ｄ．ｆ［ｊ］：ｔｉｐ−ＡＬＬＥＯＰ（）＝
［（∃ｋ（０≦ｋ＜ｎ）Ｄ．ｇ［ｋ］：ｍＲ？（〈Ｄ．ｇ［ｋ］Ｄ〉［ｔ（Ｐ［ｋ］．ｆ，１）］））＊｛
・→Ｄ．ｇ［ｋ］：ｍｏｖｅＰｒｏｄｕｃｔ（Ｄ．ｆ［ｊ］）
・→Ｄ．ｇ［ｋ］Ｓ［ｔ（Ｄ．ｇ［ｋ］，２）］
→（〈Ｐ［ｋ］．ｆＤ〉［ｔ（Ｄ．ｇ［ｋ］，３）］｜｜Ｐ［ｋ］：ＢＯＤＹ−ＡＬＬＥＯＰ（））
・→Ｄ．ｆ［ｊ］Ｓ［ｔ（Ｄ．ｆ［ｊ］，０）］
→（〈Ｃ［ｊ］．ｇＤ〉［ｔ（Ｄ．ｆ［ｊ］，１）］｜｜Ｃ［ｊ］：ＢＯＤＹ−ＡＬＬＥＯＰ（））｝｝］  （ＩＩ．２２）
ＰＣの解法：ＡＬＬＥＯＰ（）＝
□［∃（〈ｐａｒｔｉａｌ−ｏｒｄｅｒｉｎｇ−ｏｆ−ｔｉｍｉｎｇ−ｆｕｎｃｔｉｏｎｓ〉］
∀（ｊ）（０≦ｊ＜ｍ）∀（ｋ）（０≦ｋ＜ｎ）（｜｜Ｃ［ｊ］：ＡＬＬＥＯＰ（）
｜｜Ｐ［ｋ］：ＡＬＬＥＯＰ（）｜｜Ｄ：ＡＬＬＥＯＰ（））］  （ＩＩ．２３）
【０６１８】
トレース：ここでトレースを示していないが、それは合成トレースがセクション６．３の表ＩＩＩに示しているＥＣＴネットワークに現れるからである。トレースによって提供されるすべての情報はＥＣＴネットワーク内にカプセル化されている。
付録ＩＩＩ
ＤＰの解法：ＣＩＰ、ＴＩＰ、ＡＬＬＥＯＰ、およびトレース
【０６１９】
Ｂｔｌｒ  ＣＩＰとＴＩＰ：ＢｔｌｒはＢｕｔｌｅｒクラスを表しており、ｂｔｒｌはＢｔｒｌのインスタンスを表している。ここでも、ＩｎｔｅｒｒｕｐｔＰｏｒｔサービスポーリング、割り込みメッセージ処理、開始／終了プロセスを無視する。
ｖｏｉｄ  Ｂｔｌｒ：：ＣＩＰ（）｛ＩＮＩＴＯ；ＢＯＤＹ（）｝（ＩＩＩ．１）
ｖｏｉｄ  Ｂｔｌｒ：：ＩＮＩＴ（）｛
ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔＵｐＴｂｌ（）；ｓｔｏｐＰｏｌｌｉｎｇ＝ｓｔｏｐＰｅｎｄｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝．ｆａｌｓｅ；
ｇ：ｓ（）；／／信号を全ての哲学者に彼らを起動するためにブロードキャスト｝
ｉ：ｓ（）；／／起動した割り込み信号の受信を確認応答｝（ＩＩＩ．２）
ｖｏｉｄＢｔｌｒ：：Ｂ０ＤＹ（）｛
ｗｈｉｌｅ（¬ｉｓｔｏｐＰｏｌｌｉｎｇ）｛
／／ｂｔｌｒ．ｆ［ｊ］：ＴＩＰ（）に指定されているように、そのｆｕｎｃｔｉｏｎａｌＰｏｒｔ、ｂｔｒｌ．ｆ［ｊ］をポーリングし、メッセージに応答
ｆｏｒ（ｉｎｔ  ｊ＝０；ｊ＜５；ｊ＋＋；）｛ｂｔｌｒ．ｆ［ｊ］：ＴＩＰ（）；｝
／＊その環境から割り込み信号をＩｎｔｅｒｒｕｐｔＰｏｒｔ、ｂｔｌｒ．ｉで受信すると終了。終了は、以下で説明するように、ｂｔｌｒ．ｉ：ＴＩＰ（）で指定されているように、フォークを待っている全ての哲学者にサービスを行った後でかつ全ての哲学者も終了した後で初めて発生＊／
ｂｔｌｒ．ｉ：ｍＲ？（）｛ｂｔｌｒ．ｉ：ＴＩＰ（）；｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅＯ；｝（ＩＩＩ．３）
Ｂｔｌｒ．ｆ［ｊ：０．．．４］：ＴＩＰ（）＝
［／／Ｐ［ｊ］．ｇからのメッセージを聞き、メッセージがあれば応答
ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）｛ｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ）；／／こればＢｔｌｒクラスで定義されているｐｔｈｒｅａｄ
／＊ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）＝ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄはｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ）  ｐｔｈｒｅａｄ内で設定されている。ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅまたはｆａｌｓｅの場合にだけ応答。ｔｒｕｅの場合はメッセージを送信し、ｆａｌｓｅの場合にはメッセージを転送し、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φの場合は応答しない。＊／
ｂｔｌｒ．ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）｛ｆ［ｊ］：ｓ（）；｝ｅｌｓｅ｛ｆ［ｊ］：ｆ（）；｝］（ＩＩＩ．４）
【０６２０】
ｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ）の定義
ｖｏｉｄＢｔｌｒ：：ｒｅｓｐｏｎｓｅ（ｉｎｔｊ）｛／／このｐｔｈｒｅａｄはｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）がｔｒｕｅの場合にだけ実行される。
【０６２１】
｛ｓｅｌｅｃｔＯｎｅ｛
／＊ｂｔｌｒ．ｆ［ｊ］のｒｅａｄＭｅｍｏｒｙが空の場合、それは哲学者Ｐ［ｊ］がフォークを要求していることを意味している。フォークが利用可能な場合、フォークをｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のコンテナに梱包して、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅに設定する。これによって、（ＩＩＩ．３）のｂｔｌｒ．ｆ［ｊ］：ＴＩＰ（）のボディに定義されているように、ｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のメッセージが送出される。フォークが使用可能でない場合、ｂｔｌｒ．ｆｒｋ［ｊ］：ｒｓｒｖｄ＝ｔｒｕｅｎかつｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φに設定。この場合、メッセージは送信されない。Ｐ［ｊ］はフォークを待つ。フォークは最終的に利用可能になった時に次のポーリングサイクルで送られる。応答が送信されないため、ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）はフォークが送られるまで全ての続くポーリングサイクルでｔｒｕｅと評価される。
【０６２２】
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）｛ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）；
ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅ；｝
ｅｌｓｅ｛ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ＝ｔｒｕｅ；
ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φ；｝
／＊以下では、ｂｔｌｒ．ｆ［ｊ］のｒｅａｄＭｅｍｏｒｙは空ではない。Ｐ［ｊ］によって返却されるフォークを含むことになる。ｂｔｌｒはフォークをテーブルに戻し、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｆａｌｓｅと設定する。これによって、応答がｒｅａｄＭｅｍｏｒｙ内のからのコンテナと共にｂｔｌｒ．ｆ［ｊ］：ｔｉｐ（）によってＰ［ｊ］．ｇに転送される＊／
¬ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）；
ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝．ｆａｌｓｅ；｝｝（ＩＩＩ．５）
ｂｔｌｒ．ｉ：ＴＩＰ（）＝
［／＊ｂｔｒｌ．ｉに割り込みメッセージが存在する場合にだけ以下が実行される。ｂｔｌｒ．ｐｅｎｄｍｇｓｔｏｐ＝ｆａｌｓｅの場合、信号をｂｔｌｒ．ｇを通して全ての哲学者にブロードキャストする。これによって、哲学者にゲームを終了するように求める。この場合、ｂｔｔｌ．ｉの割り込み信号には応答しないが、代わりにｂｔｌｒ．ｐｅｎｄｍｇｓｔｏｐ＝ｔｒｕｅと設定し、ゲームに対して保留中の停止が存在していることを示し、即座にｆｕｎｃｔｉｏｎＰｏｒｔ、ｂｔｌｒ．ｆ［ｊ］のサービスに進む。応答が送信されていないので、ｂｔｌｒ．ｉ：ｍＲ？（）はｂｔｒｌの次のポーリングサイクルにおいてｔｒｕｅと評価され、その時点で、ｂｔｌｒ．ｐｅｎｄｍｇｓｔｏｐはｔｒｕｅである。これによって、以下のｅｌｓｅ節が実行される。このｅｌｓｅ節において、ｂｔｌｒは全ての哲学者から終了したことを示している応答の受信を待つ。この応答が受信されると、ｂｔｌｒはｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅと設定し、肯定応答をｂｔｌｒ．ｉを通して受信した割り込み信号に送信する。ゲームは次のポーリングサイクルで停止する＊／
ｂｔｌｒ．ｉ：ｍＲ？（）｛ｓｅｌｅｃｔＯｎｅ｛
¬ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ｛ｂｔｌｒ．ｇ：ｓ（）；ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｔｒｕｅ；｝
¬ｂｔｌｒ：ａｌｌＦｒｋｓＯｎＴｂｌ？（）｛ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｆａｌｓｅ；
ｂｔｌｒ．ｇ：ｍＲ？（）＊｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；
ｉ：ｓ（）；｝｝｝｝］  （ＩＩＩ．６）
ただし、ｂｔｌｒは割り込み信号が検知されたポーリングサイクルで保留中のサービス要求のある全ての哲学者のサービスを行う。全てのフォークがテーブル上にあり、終了した全ての哲学者から肯定応答を受信した後で初めてゲームを終了する。
【０６２３】
ｂｔｌｒ：ＢＯＤＹ（）のｗｈｉｌｅループのループ不変式は□（¬∀（ｊ）Ｗ（ｊ））であって、Ｗ（ｊ）は哲学者Ｐ［ｊ］がフォークを待っていることを意味している。∀（ｊ）Ｗ（ｊ）はデッドロック状態である。この状態にゲーム中に到達することはない。これに対する証明はセクション６．４に示している。以下で特徴付ける全てのアクションと条件はＢｔｌｒクラスで定義されている。全てのアクションについて実装をここでは示していない。それらの特徴付けを以下に示す。
【０６２４】
定義：Ｂｔｌｒアクションと条件の特徴付け。
□［ｂｔｌｒ．ｆｒｋ［ｊ］：ｒｓｒｖｄ？（）⇔ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ＝ｔｒｕｅ］  （ＩＩＩ．７）
□［ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）⇔（ｂｔｌｒ．ｆｒｋ［ｊ］：ｏｎＴｂｌ＆ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５ｌ］．ｏｎＴｂｌ＆
¬ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］．ｒｓｒｖｄ）］  （ＩＩＩ．８）
∃（ｔ０＜ｔ１）［／／ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）の特徴付け
｛〈ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）〉（ｔ０）｝［・→ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）（ｔ０）］
｛〈ｂｔｌｒ．ｆ［ｊ］．ｗｒ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｂｔｌｒ．ｆｒｋ［ｊ］，ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］］＆
¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｏｎＴｂｌ＆¬ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］．ｏｎＴｂｌ＆
¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ〉（ｔ１）｝  （ＩＩＩ．９）
／／ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）の定義
｛〈ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｂｔｌｒ．ｆｒｋ［ｊ］，ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］］〉（ｔ０）｝
［・→ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）（ｔ０）］
｛〈ｂｔｌｒ．ｆｒｋ［ｊ］．ｏｎＴｂｌ＆ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］．ｏｎＴｂｌ＆
¬ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ）（ｔ１）Ｓｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝φ〉（ｔ１）｝  （ＩＩＩ．１０）
／／ｂｔｌｒ：ｒｐｌｎｓｈＦｄ（）の特徴付け
｛〈ｂｔｌｒ．ｆｏｏｄＣｏｎｔａｉｎｅｒ：ｅｍｐｔｙ？（）〉（ｔ０）｝［→ｂｔｌｒ：ｒｐｌｎｓｈＦｄ（）（ｔ０）］
｛（ｂｔｌｒ．ｆｏｏｄＣｏｎｔａｉｎｅｒ：ｆｕｌｌ？（）（ｔ１）｝  （ＩＩＩ．１１）
／／ｂｔｌｒ：ｓｔＵｐＴｂｌ（）の特徴付け
｛ｔｒｕｅ｝［→ｂｔｌｒ：ｓｔＵｐＴｂｌ（）（ｔ０）］
｛（∀（ｊ）（ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ（ｊ））ＳｆｏｏｄＣｏｎｔａｉｎｅｒ：ｆｕｌｌ？（））（ｔ１）｝］  （ＩＩＩ．１２）
【０６２５】
哲学者ＣＩＰとＴＩＰ：
ｖｏｉｄ  Ｐ：：ＣＩＰ（）｛ＩＮＩＴＯ；ＢＯＤＹ（）；｝  （ＩＩＩ．１３）
ｖｏｉｄ  Ｐ：：ＩＮＩＴ（）｛
／／Ｐ［ｊ］．ｇのｗｒｉｔｅＭｅｍｏｒｙは空のまま。パッケージの空のインスタンスがｒｅａｄＭｅｍｏｒｙにインストールされる。
【０６２６】
ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔｏｐＰｏｌｌｉｎｇ＝ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ；ｈａｓｆｏｒｋｓ＝φ；
ｉ：ｓ（）；ｇ．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔａｉｎｓ＝φ｝｝  （ＩＩＩ．１４）
ｖｏｉｄ  Ｐ：：ＢＯＤＹ（）｛
ｗｈｉｌｅ（¬ｓｔｏｐＰｏｌｌｉｎｇ）｛／／Ｐが思索をやめると空腹が始まる
Ｐ：ｔｈｉｎｋｉｎｇ（）；Ｐ．ｇ：ＴＩＰ（）；
／／割り込みの受信でゲームが停止し、そうでなければ思索に戻る
Ｐ．ｉ：ｍＲ？（）｛Ｐ．ｉ：ｓ（）；ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ；｝｝
ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）；｝（  ＩＩＩ．１５）
Ｐ．ｇ：ＴＩＰ（）＝／／空腹になって、Ｐ．ｇがメッセージの送信の準備ができていればフォークの要求を送信
［Ｐ：ｈｕｎｇｒｙ？（）｛Ｐ．ｇ：ｐＲ？（）＊｛Ｐ．ｇ：ｓ（）；
／＊フォーク要求をＰ．ｇを通して送信した後、フォークの到着を待ち、到着したらそれらを取り出し、食事を始める。食事後、フォークを梱包し、それらをｂｔｌｒに転送＊／
Ｐ．ｇ：ｍＲ？（）＊｛Ｐ．ｇ：ｐｉｃｋＵｐＦｒｋｓ（）；Ｐ：ｅａｔｉｎｇ（）；Ｐ．ｇ：ｐａｃｋＦｒｋｓ（）．ｆ（）；｝｝  （ＩＩＩ．１６）
【０６２７】
定義：哲学者のアクションと条件の特徴付け、０≦ｊ＜５：
∃（ｔ０＜ｔｉ＜ｔ１）［
／／ｐ［ｊ］．ｇ：ｐｉｃｋＵｐＦｏｒｋｓ（）の特徴付け
｛〈Ｐ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｆｒｋ［ｊ］，ｆｒｋ［ｊ（○＋）５１］］〉（ｔ０）｝
［・→Ｐ［ｊ］．ｇ：ｐｉｃｋＵｐＦｏｒｋｓ（）（ｔ０）］｛〈Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉（ｔ１）｝  （ＩＩＩ．１７）
／／Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）の定義
［Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）⇔Ｐ［ｊ］．ｈａｓＦｏｒｋｓ＝［ｂｔｌｒ．ｆｒｋ［ｊ］，ｂｔｌｒ．ｆｒｋ［ｊ（○＋）５１］］）＆
Ｐ［ｊ］．ｇ．ｒｄ：ｍｓｇ（）．ｃｏｎｔｅｎｔｓ＝φ）］  （ＩＩＩ．１８）
／／Ｐ［ｊ］：ｅａｔｉｎｇ（）の特徴付け
｛〈Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉ｔ０）｝［・→Ｐ［ｊ］：ｅａｔｉｎｇ（）（ｔ０）］
｛〈¬Ｐ［ｊ］：ｈｕｎｇｒｙ？＆Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉（ｔ１）｝  （ＩＩＩ．１９）
／／Ｐ［ｊ］：ｐａｃｋＦｒｋｓ（）の特徴付け
｛〈Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉（ｔ０）｝［・→Ｐ［ｊ］：ｐａｃｋＦｒｋｓ（）（ｔ０）］
｛〈Ｐ［ｊ］．ｇ：ｍｓｇ（）．ｃｏｎｔａｉｎｓ＝［ｆｒｋ［ｊ］，ｆｒｋ［ｊ（○＋）５１］］＆
¬Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉ｔ１）｝  （ＩＩＩ．２０）
／／Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）の特徴付け
｛〈¬Ｐ［ｊ］：ｈａｓＦｏｒｋｓ？（）〉ｔ０）｝［・→Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）（ｔ１）］
｛〈¬Ｐ［ｊ］：ｔｈｉｎｋｉｎｇＯＳＰ［ｊ］：ｈｕｎｇｒｙ？〉（ｔ２）｝  （ＩＩＩ．２１）
【０６２８】
ＡＬＬＥＯＰ：以下では、「｜」は選択肢を分離する。
Ｂｔｌｒ  ＡＬＬＥＯＰ：
ｂｔｌｒ：ＡＬＬＥＯＰ（）＝［ｂｔｌｒ．ｉｎｉｔ：ＡＬＬＥＯＰ（）・→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）］  （ＩＩＩ．２２）
ｂｔｌｒ．ｉｎｉｔ：ＡＬＬＥＯＰ（）＝／／Ｅはｂｔｌｒを開始する環境セルである
［ｉｎｉｔｉａｌｉｚｅ？（）｛ｓｔＵｐＴｂｌ（）／／表の設定
・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ・→ｓｔｏｐＰｅｎｄｉｎｇ＝ｆａｌｓｅ・→ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→ｇｓ［ｔ（ｂｔｌｒ．ｇ，０）］／／全ての哲学者を開始
→（∀（ｊ）（０≦ｊ＜５）（〈Ｐ［ｊ］．ｉＤ〉［ｔ（ｂｔｌｒ．ｇ，１）］｜｜→．．．→Ｐ［ｊ］．ｉｎｉｔ：ＡＬＬＥＯＰ（））
・→ｂｔｌｒ．ｉＳ［ｔ（ｂｔｌｒ．ｉ，０）］
→（〈Ｅ．ｇＤ〉［ｔ（ｂｔｌｒ．ｉ，１）］｜｜→．．．→Ｅ．ｇ：ＡＬＬＥＯＰ（））｝
・→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）］  （ＩＩＩ．２３）
ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）＝
［（¬ｓｔｏｐＰｏｌｌｉｎｇ？（）｛∀（ｊ）（０≦ｊ＜５）［ｂｔｌｒ．ｆ［ｊ］：ＡＬＬＥＯＰ（）］・→ｂｔｌｒ．ｉ：ＡＬＬＥＯＰ（）］
・→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（）｝｜
ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝］  （ＩＩＩ．２４）
ｂｔｌｒ：ｆ［ｊ：０．．．４］：ＡＬＬＥＯＰ（）＝
／＊信号がなければ次のポートのポーリングをスキップし、そうでなければ以下を実行。この選択肢は通常指定されていない。ここでは仮定されている。＊／
［¬ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）｛ｂｔｌｒ：ｆ［ｊ（○＋）５１］：ＡＬＬＥＯＰ（）｝
｜
／＊時刻ｔ（Ｐ［ｊ］．ｆ，１）に受信されたメッセージはフォークの要求である。この場合ｒｅａｄＭｅｍｏｒｙは空である。時刻ｔ（Ｐ［ｊ］．ｆ，３）に受信されたメッセージはＰ［ｊ］によって返却されたフォークをｒｅａｄＭｅｍｏｒｙに含んでいる。Ｂｔｌｒ：ｒｅｓｐｏｎｓｅ（ｊ）はこれらのメッセージを次のＡＬＬＥＯＰに記述されているように処理し、ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）をｔｒｕｅ、ｆａｌｓｅ、またはφに設定する。＊／
ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（〈ｂｔｌｒ．ｆ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｆ，１）｜ｔ（Ｐ［ｊ］．ｆ，３）］）｛
・→ｂｔｌｒ：ｒｅｓｐｏｎｓｅＡＬＬＥＯＰ（ｊ）
・→（ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）｛ｆ［ｊ］Ｓ［ｔ（ｂｔｌｒ．ｆ［ｊ］，０）］
（〈Ｐ［ｊ］．ｇＤ〉［ｂｔｌｒ．ｆ［ｊ］，Ｉ）］
｜｜→．．．→Ｐ［ｊ］．ｇ：ＡＬＬＥＯＰ（））｝
｜
¬ｆ［ｊ］：ｒｅｓｐｏｎｄ？（）｛ｆ［ｊ］Ｆ［ｔ（ｂｔｌｒ．ｆ［ｊ］，０）］
（〈Ｐ［ｊ］．ｇＤ〉［ｂｔｌｒ．ｆ［ｊ］，１）］｜｜→．．．→Ｐ［ｊ］．ｇ：ＡＬＬＥＯＰ（））｝
｜
ｔｒｕｅ｛｝）｝｝
ｂｔｌｒ：ｆ［ｊ（○＋）５ｌ］：ＡＬＬＥＯＰ（）／／次のポートのポーリングに進む］（ＩＩＩ．２５）
ｂｔｌｒ：ｒｅｓｐｏｎｓｅＡＬＬＥＯＰ（ｊ：０．．．４）＝
／＊Ｐ［ｊ］．ｇからのメッセージが空の場合、Ｐ［ｊ］はフォークを要求している。この場合、フォークが利用可能な場合、フォークをｂｔｌｒ．ｆ［ｊ］のｗｒｉｔｅＭｅｍｏｒｙ内のコンテナに梱包し、それをＰ［ｊ］．ｇに送信するために、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅと設定する。そうでなければ、左のフォーク、ｂｔｌｒ．ｆｒｋ［ｊ］を予約し、Ｐ［ｊ］．ｇにメッセージを返信しないために、ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φを設定する。ただし、ｂｔｌｒの次のポーリングサイクルにおいて、ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）はｔｕｒｅと判定され、同じ応答アクティビティが繰り返されることになる。このアクティビティのサイクルはフォークが利用可能になって、Ｐ［ｊ］．ｇに送られるまで継続する。メッセージが空ではない場合、Ｐ［ｊ］．ｇはフォークを返却中である。この場合、フォークをテーブルに戻し、空のコンテナをＰ［ｊ］．ｇに転送するためにｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｆａｌｓｅと設定する＊／
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛／／
（ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）｛ｂｔｌｒ：ｐａｃｋＦｒｋｓ（ｊ）・→ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝ｔｒｕｅ；｝
｜
¬ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ）｛ｂｔｌｒ．ｆｒｋ［ｊ］．ｒｓｒｖｄ＝ｔｒｕｅ
・→ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝φ；｝）｝
｜
¬ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）｛ｂｔｌｒ：ｐｕｔＦｒｋｓＯｎＴｂｌ（ｊ）
・→ｂｔｌｒ．ｆ［ｊ］．ｒｅｓｐｏｎｄ＝．ｆａｌｓｅ；｝）））］（ＩＩＩ．２６）
ｂｔｌｒ．ｉ：ＡＬＬＥＯＰ（）＝
／＊Ｅは執事を開始した環境セルである。Ｅ．ｇは割り込み信号をｂｔｌｒ．ｉに送信する。Ｅ．ｇ用ＡＬＬＥＯＰはここでは示していない。割り込み信号を検知すると、ｂｔｌｒ．ｐｅｎｄｍｇＳｔｏｐがｆａｌｓｅの場合、ｂｔｌｒはｔｒｕｅに設定し、信号はポート、ｂｔｌｒ．ｇから全ての哲学者のＩｎｔｅｒｒｕｐｔＰｏｒｔにブロードキャストされ食事が終わったことを忠告する。＊／
［ｂｔｌｒ．ｉ：ｍＲ？（〈ｂｔｌｒ．ｉＤ〉［ｔ（Ｅ．ｇ，３）］）｛
（¬ｂｔｌｒ：ｐｅｎｄｉｎｇＳｔｏｐ？（）｛ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｔｒｕｅ
・→ｇＳ［ｔ（ｂｔｌｒ．ｇ，２）］
∀（ｊ）（（０≦ｊ＜５）［〈→Ｐ［ｊ］．ｉＤ〉［ｂｔｌｒ．ｇ，３］
｜｜→．．．→Ｐ［ｊ］．ｉ：ＡＬＬＥＯＰ（））］｝
｜
／＊ｂｔｌｒ．ｐｅｎｄｍｇＳｔｏｐで全てのフォークがテーブル上にある場合、全ての哲学者からの応答を待つ。応答を受信すると、Ｅ．ｇからの割り込み信号の受信に肯定応答し、それから終了の準備をする。次のポーリングサイクルで終了する。ｂｔｌｒ：ｆｒｋｓＯｎＴｂｌ？（）は全ての哲学者が食事を終えてフォークを返却したことを示す。＊／
（ｂｔｌｒ：ｐｅｎｄｉｎｇＳｔｏｐ？（）Ｓｂｔｌｒ：ａｌｌＦｒｋｓＯｎＴｂｌ？（））｛
ｂｔｌｒ．ｇ：ｍＲ（）＊｛・→ｉＳ［ｔ（ｂｔｌｒ．ｉ，２）］
→（〈Ｅ．ｇＤ〉［ｔ（ｂｔｌｒ．ｉ，３）］｜｜→．．．→Ｅ．ｇ：ＡＬＬＥＯＰ（））｝
・→ｂｔｌｒ．ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ
・→ｂｔｌｒ．ｐｅｎｄｉｎｇＳｔｏｐ＝ｆａｌｓｅ｝）｝］  （ＩＩＩ．２７）
前述のように、ｂｔｌｒは全ての待っている哲学者がサービスを受けて全ての哲学者が食事を止めてフォークを返却した後で初めて動作を終了する。
【０６２９】
哲学者ＡＬＬＥＯＰ：
Ｐ［ｊ：０．．．４］：ＡＬＬＥＯＰ（）＝［Ｐ［ｊ］．ｉｎｉｔ：ＡＬＬＥＯＰＯ・→Ｐ［ｊ］．ｂｏｄｙ：ＡＬＬＥＯＰ（）］  （ＩＩＩ．２８）
Ｐ［ｊ：０．．．４］．ｉｎｉｔ：ＡＬＬＥＯＰ（）＝
［Ｐ［ｊ］：ｉｎｉｔｉａｌｉｚｅ？（）｛Ｐ［ｊ］．ｓｔｏｐＰｏｌｌｉｎｇ＝ｆａｌｓｅ→Ｐ［ｊ］．ｉｎｉｔｉａｌｉｚｅ＝ｆａｌｓｅ
・→Ｐ［ｊ］．ｈａｓＦｏｒｋｓ＝φ・→Ｐ［ｊ］．ｉｓ［ｔ（Ｐ［ｊ］．ｉ，０）］
→（〈ｂｔｌｒ．ｇＤ〉［Ｐ［ｊ］．ｉ，１）］｜｜→．．．→ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（））｝
・→Ｐ［ｊ］．ｇ．ｒｄ：ｍａｋｅ（ｐａｃｋａｇｅ，ｃｏｎｔａｉｎｓ＝φ）｝
・→Ｐ［ｊ］．ｂｏｄｙ：ＡＬＬＥＯＰＯ］  （ＩＩＩ．２９）
Ｐ［ｊ：０．．．４］．ｂｏｄｙ：ＡＬＬＥＯＰＯ＝
［（¬Ｐ［ｊ］：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛Ｐ［ｊ］．ｇ：ＡＬＬＥＯＰ（）・→Ｐ［ｊ］．ｉ：ＡＬＬＥＯＰ（）｝
・→Ｐ［ｊ］．ｂｏｄｙ：ＡＬＬＥＯＰ（）｝｜
Ｐ［ｊ］：ｓｔｏｐＰｏｌｌｉｎｇ？（）｛ｐｒｅｐａｒｅＴｏＴｅｒｍｉｎａｔｅ（）｝）］  （ＩＩＩ．３０）
Ｐ［ｊ：０．．．４］．ｇ：ＡＬＬＥＯＰＯ＝
［Ｐ［ｊ］：ｔｈｉｎｋｉｎｇ（）・→
Ｐ［ｊ］：ｈｕｎｇｒｙ？（）｛Ｐ［ｊ］．ｇ：ｐＲ？（）＊｛Ｐ［ｊ］：ｇＳ［ｔ（Ｐ［ｊ］．ｇ，０）］
→（〈ｂｔｌｒ．ｆ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｇ，１）］｜｜→．．．→ｂｔｌｒ．ｆ［ｊ］：ＡＬＬＥＯＰＯ）
・→Ｐ［ｊ］．ｇ：ｍＲ？（）＊｛Ｐ［ｊ］．ｇ：ｐｉｃｋＵｐＦｏｒｋｓ（）・→Ｐ［ｊ］：ｅａｔｉｎｇ（）
／＊食事後、フォークをＰ［ｊ］．ｇのｒｅａｄＭｅｍｏｒｙ内のコンテナに梱包し、それをｂｔｌｒ．ｆ［ｊ］に転送する。＊／
・→Ｐ［ｊ］．ｇ：ｐａｃｋＦｒｋｓ（）
・→Ｐ［ｊ］．ｇＦ［ｔ（Ｐ［ｊ］．ｇ，２）］
→（〈ｂｔｌｒ．ｆ［ｊ］Ｄ〉［ｔ（Ｐ［ｊ］．ｇ，３）］
｜｜→．．．→ｂｔｌｒ．ｆ［ｊ］：ＡＬＬＥＯＰ（））｝｝］  （ＩＩＩ．３１）
Ｐ［ｊ］．ｉ：ＡＬＬＥＯＰ（）＝
／＊（Ｉ．３０）において、Ｐ［ｊ］は食事を終えてフォークを返却した後で初めてｉｎｔｅｒｒｕｐｔＰｏｒｔをポーリングする。＊／
［Ｐ［ｊ］．ｉ：ｍＲ？（〈Ｐ［ｊ］．ｉＤ〉［ｔ（ｂｔｌｒ．ｇ，３）］）｛ｉＳ［ｔ（Ｐ［ｊ］．ｉ，２）］
→（ｂｔｌｒ．ｇＤ［ｔ（Ｐ［ｊ］．ｉ，３）］｜｜ｂｔｌｒ．ｂｏｄｙ：ＡＬＬＥＯＰ（））
・→ｓｔｏｐＰｏｌｌｉｎｇ＝ｔｒｕｅ｝］  （ＩＩＩ．３２）
待っている哲学者は食事を終えた後で初めて終了信号に応答する。したがって、ゲームが終了する前に、各哲学者は満足していることになる。
【０６３０】
ポーリングサイクル：
ｂｔｌｒ：Ｐｏｌｌｉｎｇ（）＝［ｂｔｌｒ．ｆ［０］：ｍＲ？（）→ｂｔｌｒ．ｆ［１］：ｍＲ？（）→ｂｔｌｒ．ｆ［２］：ｍＲ？（）
→ｂｔｌｒ．ｆ［３］：ｍＲ？（）→ｂｔｌｒ．ｆ［４］：ｍＲ？（）→ｂｔｌｒ．ｉ：ｍＲ？（）
→ｂｔｌｒ：Ｐｏｌｌｉｎｇ（）］  （ＩＩＩ．３３）
Ｐ［ｊ：０．．．４］：Ｐｏｌｌｉｎｇ（）＝［Ｐ［ｊ］．ｇ：ｐＲ（）＊→Ｐ［ｊ］．ｉ：ｍＲ？（）→Ｐ［ｊ］：Ｐｏｌｌｉｎｇ（）］  （ＩＩＩ．３４）
【０６３１】
区別されている述語と初期状態：
区別されている述語の集合は、ＴＩＰ用のＥＴＣ評価が始まる前に初期状態の指定に使用される。一般的に、区別されている述語にはＴＩＰの選択点において行われる選択を決める条件が含まれる。したがって、任意の非標準ガードとｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージのステータスがこの集合に含まれる。例えば、この例においては、ｆｕｎｃｔｉｏｎＰｏｒｔでのサービス要求が次のＴＩＰが始まる前に応答されない場合、任意の非標準ガードとｖｉｒｔｕａｌＭｅｍｏｒｙ内のメッセージのステータスがこの集合に含まれる。ＥＣＴのシンボリック評価の規則は、選択点において選択を決める述語が初期状態またはＥＣＴ評価で以前に使用された述語内で指定されていない場合、その選択点から始まる全ての因果チェーンを可能性のある選択肢としてシンボリック評価内に含めなければならない。
【０６３２】
ＤＰ解法については、区別されている述語には以下の条件が含まれる。
【０６３３】
ｂｔｌｒ：ｆｒｋｓＡｖｌｂｌ？（ｊ），Ｅ［ｊ］，Ｔ［ｊ］ａｎｄＷ［ｊ］，ｂｔｌｒ．ｆ［ｊ］：ｍＲ？（）および
ｂｔｌｒ．ｆ［ｊ］．ｒｄ：ｅｍｐｔｙ？（）、０≦ｊ＜５．  （ＩＩＩ．３５）
哲学者の状態Ｔ［ｊ］、Ｗ「ｊ」およびＥ［ｊ］はセクション６．４で定義される。ゲームの公理と初期状態もここで定義する。セクション６．４で示している証明にはＰ［ｊ］．ｇ：ｔｒａｃｅ（ｐ［ｊ］．ｇ．ｔ０）およびｂｔｌｒ．ｆ［ｊ］：ｔｒａｃｅ（ｂｆ［ｊ］．ｔ０）だけが必要である。これらのトレースから導出されたＥＣＴネットワークをセクション６．４の表ＩＶとＶに示している。便利さとわかりやすさために、互いに追従している、つまり並列起動によって互いに起動するネットワークを読みやすいブロックに分割している。読者は、各ＥＣＴブロックにおいて、アクションに対して定義されている事前と事後の条件がブロック内に含まれていることがわかる。証明に必要な情報がこれらの２つの表から選択される。
【０６３４】
これで、ＤＰ解法の実装と定義が完了する。請求項を示す前に、請求項がよりわかりやすくなるように、請求項で使用されるいくつかの用語を定義する。
【０６３５】
マルチコアチップ用の正式に検証された並列ソフトウェアを構築するためのＴＩＣＣパラダイム
発明者：ＥＤＳＳ，Ｉｎｃ．、社長、Ｃｈｉｔｏｏｒ  Ｖ．Ｓｒｉｎｉｖａｓａｎ、顧客番号：３３６４１
優先出願番号：６１／１９５，９６５、優先日：２００８年１０月１４日
電話：７７２３３７１３８８、ファックス：７７２３３７１３９９、携帯電話：７７２２８６６４６３、電子メール：ｓｒｉｎｉｖａｓ＠ｃｓ．ｒｕｔｇｅｒｓ．ｅｄｕ
特許請求の範囲に対する前文
特許請求の範囲の詳述に使用される名前、属性、データ、メソッド、条件、アブストラクト、リファイン、実行（ｒｕｎ）、アクション、イベントおよび通信イベントという用語は、この前文において定義されている：
（ｉ）名前は所与のアルファベット記号の任意の有限の文字列である。
（ｉｉ）データは値を表すために通常使用される２進数ビット０と１の任意の有限の文字列である。
（ｉｉｉ）属性は、オブジェクトインスタンスｘの特性を定義するために使用される任意の名前で、ｘ．属性はオブジェクトｘのその属性の値を参照するために使用され、ｘ．属性はオブジェクトインスタンスｘのクラスＸにおいて定義される。
(ｉｖ)メソッドはｘ：名前（〈引数〉）の形態であって〈引数〉はオプションで、各メソッドはコンピュータプログラムであって、メソッドｘ：名前（〈引数〉）に対するコンピュータプログラムは、オブジェクトインスタンスｘのクラスＸにおいて定義される。メソッドはそれに対してコンピュータプログラムが定義されていない場合にアブストラクトである。
(ｖ)条件は引数のないｘ：名前？（）の形態であって、各条件はコンピュータプログラムであって、メソッドｘ：名前？（）に対するコンピュータプログラムは、オブジェクトインスタンスｘのクラスＸにおいて定義される。条件の評価は、真理値、ｔｒｕｅまたはｆａｌｓｅ、あるいは真理値、ｔｒｕｅ、ｆａｌｓｅ、または未知を返すことになる。条件はそれに対してコンピュータプログラムが定義されていない場合にアブストラクトである。
（ｖｉ）アブストラクト：ソフトウェアコンポーネントはアブストラクトなメソッドおよび／または条件を含んでいる場合にアブストラクトである。
（ｖｉｉ）リファイン：ソフトウェアコンポーネントにおけるアブストラクトなメソッドと条件とに対してコンピュータプログラムを定義することは、そのソフトウェアコンポーネントのリファインと呼ばれる。ソフトウェアコンポーネントにおいてコンピュータプログラムが全てのメソッドと条件とに対して定義されている場合、そのソフトウェアコンポーネントは完全にリファインされる。
（ｖｉｉ）実行（ｒｕｎ）：アプリケーションＡに対する完全にリファインされている並列コンピュータプログラムの実行は、Ａの実行（ｒｕｎ）と呼ばれ、Ａ内の各並列コンピュータプログラムは別個の専用ＣＰＵ（ＣｏｍＰｕｔｉｎｇＵｎｉｔ）によって実行され、Ａが実行（ｒｕｎ）されている間にＡ内の並列コンピュータプログラムはメッセージ交換を通して互いに相互動作し、これはＡ内の並列プログラム内の相互動作の唯一のモードである。
(ｉｘ）アクションイベント：アクションイベントは（名前、ｔ）の形態であって、アクションイベントは、プログラミング言語におけるステートメントの実行またはメソッドまたは条件の実行に起因し、名前はその実行に起因するイベントの名前であって、ｔはそのイベントの発生の時刻である。
（ｘ）通信イベント：通信イベントは形態（名前Ｓ、ｔ）、（名前Ｄ、ｔ）、または（名前Ｆ、ｔ）（「Ｓ」は「Ｓｅｎｄ（送信）」、「Ｄ」は「Ｄｅｌｉｖｅｒ（配信）」、「Ｆ」は「Ｆｏｒｗａｒｄ（転送）」を表し）の形態であって、通信イベントの発生はＴＩＣＣＴＭ−Ｐｐｄｅプログラミング言語における通信ステートメントの実行に起因し、名前は通信において交換されるメッセージを送信／受信、または転送するセルに付属しているポートの名前であって、ｔはその通信イベントの発生の時間である。
【図１】
2012506076.tif 000028
【図２】
2012506076.tif 000029
【図３】
2012506076.tif 000030
【図４】
2012506076.tif 000031
【図５】
2012506076.tif 000032
【図６】
2012506076.tif 000033
【図７】
2012506076.tif 000034
【図８】
2012506076.tif 000035
【図９】
2012506076.tif 000036
【図１０】
2012506076.tif 000037
【図１１】
2012506076.tif 000038
【図１２】
2012506076.tif 000039
【図１３】
2012506076.tif 000040
【図１４】
2012506076.tif 000041
【図１５】
2012506076.tif 000042
【図１６】
2012506076.tif 000043
【図１７】
2012506076.tif 000044
【図１８】
2012506076.tif 000045
【図１９】
2012506076.tif 000046
【図２０−２１】
2012506076.tif 000047
【図２２】
2012506076.tif 000048
【図２３】
2012506076.tif 000049
【図２４】
2012506076.tif 000050