特表 2024-513076 メッセージパッシング回路構成及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-03-21

(54)【発明の名称】メッセージパッシング回路構成及び方法

(51)【国際特許分類】

   G06F 15/173 20060101AFI20240313BHJP

【ＦＩ】

G06F15/173 660C

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023561130

(86)(22)【出願日】2022-02-14

(85)【翻訳文提出日】2023-10-04

(86)【国際出願番号】 GB2022050388

(87)【国際公開番号】W WO2022214777

(87)【国際公開日】2022-10-13

(31)【優先権主張番号】17/225,674

(32)【優先日】2021-04-08

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】500395107

【氏名又は名称】アーム・リミテッド

(74)【代理人】

【識別番号】110000855

【氏名又は名称】弁理士法人浅村特許事務所

(72)【発明者】

【氏名】ビアード、ジョナサン カーティス

(72)【発明者】

【氏名】ダンハム、カーティス グレン

(72)【発明者】

【氏名】サンドバーグ、アンドレアス ラース

(72)【発明者】

【氏名】ルシトル、ロクサナ

【テーマコード（参考）】

5B045

【Ｆターム（参考）】

5B045BB01

5B045BB31

(57)【要約】

メッセージパッシング回路構成は、システムオンチップのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、チャネルコンシューマ情報構造から、ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得するルックアップ回路構成を含む。制御回路構成は、メッセージデータを、選択されたチャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込む。ターゲットメッセージチャネル及び所与のコンシューマノードに対してイベント通知条件が満たされ、イベント通知チャネルが使用されるとき、イベント通知データは、イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込まれる。
【選択図】図７

【特許請求の範囲】

【請求項1】

システムオンチップのノード間のメッセージパッシングのためのメッセージパッシング回路構成であって、前記メッセージパッシング回路構成は、
前記システムオンチップのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、複数のメッセージチャネル及び前記メッセージチャネルに加入している前記システムオンチップの１つ以上のコンシューマノードについてのチャネルコンシューマ情報を指定するためのチャネルコンシューマ情報構造から、前記ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得するためのルックアップ回路構成と、
制御回路構成であって、
前記プロデューサ要求によって示される前記メッセージデータを、前記選択されたチャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込むことと、
前記ターゲットメッセージチャネル及び前記所与のコンシューマノードに対してイベント通知条件が満たされるとき、
前記イベント通知条件に応答して前記ターゲットメッセージチャネルに対するイベント通知が前記所与のコンシューマノードに提供されるべきであるときに、前記所与のコンシューマノードに前記イベント通知を提供し、
前記ターゲットメッセージチャネルに対するイベント通知が前記複数のメッセージチャネルのイベント通知チャネル上に提供されるべきであるときに、前記イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションにイベント通知データが書き込まれるようにする、ことと、を行うための、制御回路構成と、を含む、メッセージパッシング回路構成。

【請求項2】

前記制御回路構成及び前記ルックアップ回路構成は、複数のメッセージチャネルが同じイベント通知チャネルを共有することを示す前記チャネルコンシューマ情報をサポートするように構成されている、請求項１に記載のメッセージパッシング回路構成。

【請求項3】

前記イベント通知チャネルに対してイベント通知条件が満たされるとき、前記制御回路構成は、前記所与のコンシューマノードにイベント通知を提供するように構成されている、請求項１又は２に記載のメッセージパッシング回路構成。

【請求項4】

前記制御回路構成は、前記選択されたチャネルコンシューマ情報において示されるイベント通知アドレスに関連付けられたロケーションへの書き込みを要求する書き込み要求を発行することによって、前記所与のコンシューマノードに前記イベント通知を提供するように構成されている、請求項１～３のいずれか一項に記載のメッセージパッシング回路構成。

【請求項5】

前記イベント通知データは、前記ターゲットメッセージチャネルに加入している前記所与のコンシューマノードに関連付けられた前記選択されたチャネルコンシューマ情報において指定されたコンシューマ定義値を含む、請求項１～４のいずれか一項に記載のメッセージパッシング回路構成。

【請求項6】

前記イベント通知条件は、前記ターゲットメッセージチャネル上に提供されたメッセージの数が閾値に達したか又は前記閾値を超えたことの検出を含む、請求項１～５のいずれか一項に記載のメッセージパッシング回路構成。

【請求項7】

前記閾値は、前記所与のコンシューマノードによって指定されたコンシューマ定義閾値である、請求項６に記載のメッセージパッシング回路構成。

【請求項8】

前記制御回路構成及び前記ルックアップ回路構成は、同じメッセージチャネルに加入している複数のコンシューマノードをサポートするように構成されており、前記複数のコンシューマノードの各々は、そのメッセージチャネルに対するプロデューサ要求に応答してメッセージデータが書き込まれるべきアドレス空間のそれぞれのコンシューマ定義領域を指定するそれぞれのチャネルコンシューマ情報に関連付けられている、請求項１～７のいずれか一項に記載のメッセージパッシング回路構成。

【請求項9】

所与のメッセージチャネルに関連付けられた識別子を指定する加入コンシューマノードからのチャネル加入要求に応答して、前記制御回路構成は、前記チャネルコンシューマ情報構造を更新して、前記所与のメッセージチャネルに加入する前記加入コンシューマノードについてのチャネルコンシューマ情報を指定するように構成されている、請求項１～８のいずれか一項に記載のメッセージパッシング回路構成。

【請求項10】

前記チャネル加入要求は、
前記所与のメッセージチャネルに加入する前記加入コンシューマノードに対する前記チャネルコンシューマ情報において指定されるべきアドレス空間の前記コンシューマ定義領域の前記アドレス、
前記所与のメッセージチャネルに加入する前記加入コンシューマノードに対する前記チャネルコンシューマ情報において指定されるべきコンシューマ定義イベント通知条件、及び
前記制御回路構成が、前記所与のメッセージチャネルについて前記イベント通知を前記加入コンシューマノードに提供するときに書き込む先のイベント通知アドレス、のうちの少なくとも１つを指定する、請求項９に記載のメッセージパッシング回路構成。

【請求項11】

前記チャネル加入要求は、前記加入コンシューマノードがイベント通知チャネルへの加入を要求しているか、又は前記イベント通知チャネル以外のメッセージチャネルへの加入を要求しているかを指定する、請求項９又は１０に記載のメッセージパッシング回路構成。

【請求項12】

イベント通知が前記イベント通知チャネル上に提供される、前記イベント通知チャネル以外の所与のメッセージチャネルへの加入を前記加入コンシューマノードが要求していることを前記チャネル加入要求が指定するとき、前記チャネル加入要求は、前記所与のメッセージチャネルに対して前記イベント通知条件が満たされたときに前記イベント通知データとして前記イベント通知チャネル上に提供されるべきコンシューマ定義値を指定する、請求項９～１１のいずれか一項に記載のメッセージパッシング回路構成。

【請求項13】

前記所与のメッセージチャネルに対する前記加入コンシューマノードに前記イベント通知を提供するときに前記制御回路構成が書き込む先のイベント通知アドレスを指定するためのイベント通知アドレスフィールドを前記チャネル加入要求が指定し、
前記加入コンシューマノードが前記イベント通知チャネルへの加入を要求していることを指定するイベントチャネル加入要求の処理の後、前記イベント通知アドレスフィールドが前記イベントチャネル加入要求の前記イベント通知アドレスフィールドと同じアドレスを指定する前記所与のメッセージチャネルに対するチャネル加入要求の受信に応答して、前記制御回路構成は、前記所与のメッセージチャネルに対するイベント通知が前記イベント通知チャネル上に提供されるべきであることを示すために、前記所与のメッセージチャネルに加入している前記加入コンシューマノードに対する前記チャネルコンシューマ情報を設定するように構成されている、請求項９～１２のいずれか一項に記載のメッセージパッシング回路構成。

【請求項14】

前記チャネル加入要求は、前記メッセージパッシング回路構成に関連付けられたコマンドインターフェースにマッピングされたアドレスをターゲットアドレスとして指定する、前記加入コンシューマノードによって発行された書き込み要求を含む、請求項９～１３のいずれか一項に記載のメッセージパッシング回路構成。

【請求項15】

前記プロデューサ要求は、前記メッセージパッシング回路構成に関連付けられたメッセージインターフェースにマッピングされたアドレスをターゲットアドレスとして指定する、前記プロデューサノードによって発行された書き込み要求を含む、請求項１～１４のいずれか一項に記載のメッセージパッシング回路構成。

【請求項16】

前記制御回路構成が、所与のプロデューサ要求によって示された前記メッセージを処理することができないとき、前記制御回路構成は、前記プロデューサ要求に応答して失敗インジケーションが前記プロデューサノードに返されるように構成されている、請求項１～１５のいずれか一項に記載のメッセージパッシング回路構成。

【請求項17】

前記制御回路構成は、前記メッセージデータが前記所与のコンシューマノードに関連付けられたキャッシュにスタッシングされることを要求するキャッシュスタッシュ要求を発行することによって、前記プロデューサ要求によって示された前記メッセージデータを、アドレス空間の前記コンシューマ定義領域内の前記アドレスに関連付けられた前記ロケーションに書き込むように構成されている、請求項１～１６のいずれか一項に記載のメッセージパッシング回路構成。

【請求項18】

前記キャッシュスタッシュ要求は、アドレス空間の前記コンシューマ定義領域内の仮想アドレスと、前記仮想アドレスを前記所与のコンシューマノードにおける物理アドレスに変換するための変換レジームを示すアドレス空間識別子とを指定する、請求項１７に記載のメッセージパッシング回路構成。

【請求項19】

システムオンチップであって、
複数のノードと、
前記ノード間でメッセージを受け渡しするためのメッセージパッシング回路構成であって、
前記システムオンチップのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、複数のメッセージチャネル及び前記メッセージチャネルに加入している前記システムオンチップの１つ以上のコンシューマノードについてのチャネルコンシューマ情報を指定するためのチャネルコンシューマ情報構造から、前記ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得するためのルックアップ回路構成と、
制御回路構成であって、
前記プロデューサ要求によって示される前記メッセージデータを、前記選択されたチャネルコンシューマ情報によって示されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込むことと、
前記ターゲットメッセージチャネル及び前記所与のコンシューマノードに対してイベント通知条件が満たされるとき、
前記イベント通知条件に応答して前記ターゲットメッセージチャネルに対するイベント通知が前記所与のコンシューマノードに提供されるべきであるときに、前記所与のコンシューマノードに前記イベント通知を提供し、
前記ターゲットメッセージチャネルに対するイベント通知が前記複数のメッセージチャネルのイベント通知チャネル上に提供されるべきであるときに、前記イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションにイベント通知データが書き込まれるようにする、ことと、を行うための、制御回路構成と、を含む、メッセージパッシング回路構成と、を含む、システムオンチップ。

【請求項20】

システムオンチップのノード間のメッセージパッシングのための方法であって、メッセージパッシング回路構成が、
前記システムオンチップのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、
複数のメッセージチャネル及び前記メッセージチャネルに加入している前記システムオンチップの１つ以上のコンシューマノードについてのチャネルコンシューマ情報を指定するためのチャネルコンシューマ情報構造から、前記ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得することと、
前記プロデューサ要求によって示される前記メッセージデータを、前記選択されたチャネルコンシューマ情報によって示されるアドレス空間のコンシューマ定義領域に書き込むことと、
前記ターゲットメッセージチャネル及び前記所与のコンシューマノードに対してイベント通知条件が満たされるとき、
前記イベント通知条件に応答して前記ターゲットメッセージチャネルに対するイベント通知が前記所与のコンシューマノードに提供されるべきであるときに、前記所与のコンシューマノードに前記イベント通知を提供し、
前記ターゲットメッセージチャネルに対するイベント通知が前記複数のメッセージチャネルのイベント通知チャネル上に提供されるべきであるときに、前記イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域にイベント通知データが書き込まれるようにする、ことと、を含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本技術は、システムオンチップ（ＳｏＣ）の分野に関する。

【0002】

システムオンチップ（ＳｏＣ）は、互いに通信し得るいくつかの回路ノードを有し得る。１つのノードで実行されるソフトウェアは、ＳｏＣの別のノードによって生成されるデータを取得する必要があり得る。１つの手法は、プロデューサノード及びコンシューマノードがメモリの共有領域を使用してメッセージを交換することができる手法であり得る。しかしながら、共有メモリの使用は、コヒーレンシ問題をもたらす可能性があり、特にプロデューサからの同じメッセージが複数のコンシューマによって受信されるとき、スケーリングがうまくいかないことがある。

【0003】

少なくともいくつかの実施例は、システムオンチップのノード間のメッセージパッシングのためのメッセージパッシング回路構成を提供し、このメッセージパッシング回路構成は、システムオンチップのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、複数のメッセージチャネル及びメッセージチャネルに加入しているシステムオンチップの１つ以上のコンシューマノードについてのチャネルコンシューマ情報を指定するためのチャネルコンシューマ情報構造から、ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得するためのルックアップ回路構成と、制御回路構成であって、プロデューサ要求によって示されるメッセージデータを、選択されたチャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込むことと、ターゲットメッセージチャネル及び所与のコンシューマノードに対してイベント通知条件が満たされるとき、イベント通知条件に応答してターゲットメッセージチャネルに対するイベント通知が所与のコンシューマノードに提供されるべきであるときに、所与のコンシューマノードにイベント通知を提供し、ターゲットメッセージチャネルに対するイベント通知が上記複数のメッセージチャネルのイベント通知チャネル上に提供されるべきであるときに、イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションにイベント通知データが書き込まれるようにする、ことと、を行うための制御回路構成と、を含む。

【0004】

少なくともいくつかの実施例は、複数のノードと、ノード間でメッセージを受け渡しするためのメッセージパッシング回路構成とを含むシステムオンチップを提供し、メッセージパッシング回路構成は、システムオンチップのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、複数のメッセージチャネル及びメッセージチャネルに加入しているシステムオンチップの１つ以上のコンシューマノードについてのチャネルコンシューマ情報を指定するためのチャネルコンシューマ情報構造から、ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得するためのルックアップ回路構成と、制御回路構成であって、プロデューサ要求によって示されるメッセージデータを、選択されたチャネルコンシューマ情報によって指定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込むことと、ターゲットメッセージチャネル及び所与のコンシューマノードに対してイベント通知条件が満たされるとき、イベント通知条件に応答してターゲットメッセージチャネルに対するイベント通知が所与のコンシューマノードに提供されるべきであるときに、所与のコンシューマノードにイベント通知を提供し、ターゲットメッセージチャネルに対するイベント通知が上記複数のメッセージチャネルのイベント通知チャネル上に提供されるべきであるときに、イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションにイベント通知データが書き込まれるようにする、ことと、を行うための制御回路構成と、を含む。

【0005】

少なくともいくつかの実施例は、システムオンチップのノード間のメッセージパッシングのための方法を提供し、メッセージパッシング回路構成は、システムオンチップのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、複数のメッセージチャネル及びメッセージチャネルに加入しているシステムオンチップの１つ以上のコンシューマノードについてのチャネルコンシューマ情報を指定するためのチャネルコンシューマ情報構造から、ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得することと、プロデューサ要求によって示されるメッセージデータを、選択されたチャネルコンシューマ情報によって示されるアドレス空間のコンシューマ定義領域に書き込むことと、ターゲットメッセージチャネル及び所与のコンシューマノードに対してイベント通知条件が満たされるとき、イベント通知条件に応答してターゲットメッセージチャネルに対するイベント通知が所与のコンシューマノードに提供されるべきであるときに、所与のコンシューマノードにイベント通知を提供し、ターゲットメッセージチャネルに対するイベント通知が上記複数のメッセージチャネルのイベント通知チャネル上に提供されるべきであるときに、イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域にイベント通知データが書き込まれるようにする、ことと、を含む。

【図面の簡単な説明】

【0006】

本技術の更なる態様、特徴、及び利点は、添付の図面とともに読まれるべき以下の例の説明から明らかになる。

【0007】

【図1】メッセージパッシング回路構成を有するシステムオンチップの例を概略的に示す。

【図2】メッセージパッシング回路構成をより詳細に示す。

【図3】メッセージチャネルを介してメッセージをプロデューサ仮想アドレス空間から１つ以上のコンシューマ仮想アドレス空間に渡す概念を概略的に示す。

【図4】コンシューマノードによるメッセージチャネルの構成と、メッセージチャネルを介したプロデューサノードからコンシューマノードへのメッセージの受け渡しとを概略的に示す。

【図5】ターゲットメッセージチャネル上にメッセージを提供するためのプロデューサ要求と、所与のメッセージチャネルに加入しているコンシューマノードによって構成された情報を提供するチャネルコンシューマ情報との例を示す。

【図6】比較のために、所与のコンシューマノードが複数のメッセージチャネルを監視するための手法を示す。

【図7】コンシューマノードが単一のアドレスを監視して複数のメッセージチャネルに関する通知を取得することを可能にするイベント通知チャネルの使用を示す。

【図8】イベント通知チャネルの使用をサポートするチャネルコンシューマ情報を示す。

【図9】チャネル加入要求の処理を示すフロー図である。

【図10】プロデューサ要求の処理及びイベント通知の提供を示すフロー図である。

【図10-1】プロデューサ要求の処理及びイベント通知の提供を示すフロー図である。

【図11】は、仮想キャッシュスタッシングの使用を示す。

【0008】

メッセージパッシングのためのイベント通知チャネル
システムオンチップ（ＳｏＣ）のノード間のメッセージパッシングを可能にするために、メッセージパッシング回路構成が提供される。メッセージパッシング回路構成は、２つ以上のメッセージチャネル及びメッセージチャネルに加入しているＳｏＣの１つ以上のコンシューマノードについてのチャネルコンシューマ情報を指定するチャネルコンシューマ情報構造から情報をルックアップするためのルックアップ回路構成を含む。ＳｏＣのプロデューサノードによってターゲットメッセージチャネル上に提供されるメッセージデータを示すプロデューサ要求に応答して、ルックアップ回路構成は、チャネルコンシューマ情報構造から、ターゲットメッセージチャネルに加入する所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報を取得する。制御回路構成は、プロデューサ要求によって示されるメッセージデータを、選択されたチャネルコンシューマ情報に基づいて決定されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込む。

【0009】

この手法では、プロデューサノード及びコンシューマノードが物理メモリの共有領域へのアクセスを共有しない場合であっても、メッセージをプロデューサノードからコンシューマノードに渡すことができる。メッセージパッシング回路構成は、プロデューサノードのアドレス空間とコンシューマノードのアドレス空間との間のトンネル又はワームホールと見なすことができるメッセージパッシングチャネルを実装するハードウェアアクセラレーションを提供する。メッセージデータが書き込まれるアドレスは、選択されたチャネルコンシューマ情報を使用してコンシューマノードによって定義され得るので、プロデューサノードは、メッセージデータが書き込まれるべきアドレスにアクセスする必要がない。また、コンシューマノードは、メッセージパッシング回路内のハードウェア構造からではなく、メモリ内のコンシューマ定義アドレス空間の領域からメッセージを読み取ることができるので、この手法は、コンシューマノードがメッセージを読み取ることができるまでメッセージをバッファリングするためにメッセージパッシング回路構成内の限られた容量のハードウェア記憶装置を使用する代替手法の場合よりも、異なる数のコンシューマ及び異なる数のチャネルに対してよりスケーラブルである。

【0010】

メッセージパッシング回路構成は、ターゲットメッセージチャネルに対してイベント通知条件が満たされたときに注目される所与のコンシューマにイベント通知を提供することができる。例えば、イベント通知は、特定の数のメッセージがターゲットメッセージチャネル上で受信されたこと、又は特定の基準若しくは基準のセットを満たすメッセージデータが受信されたことであり得る。いくつかのチャネルでは、イベント通知条件が所与のメッセージチャネル上で発生したときに、イベント通知を所与のコンシューマノードに直接提供することができる。しかしながら、いくつかのコンシューマノードでは、この手法は、コンシューマノードが複数のメッセージチャネル上でイベント通知を監視することを望む場合、コンシューマノードに性能オーバーヘッドを生じさせる可能性がある。いくつかのコンシューマノードによってサポートされる監視機構は、一度に単一のイベント通知の監視しかサポートしない場合があり、複数のチャネル上の通知の監視をより効率的にサポートするようにそのようなコンシューマノードを修正する際に高い開発コストがかかる場合がある。結果として、いくつかのコンシューマノードは、ポーリング（メモリの複数のアドレスからデータを推測的に読み出して、監視されている異なるチャネルについて関心のあるイベントがあるかどうかをチェックする）に頼らなければならない場合があり、これは、複数のチャネルがイベントについて監視されるときに性能を低下させる可能性がある。

【0011】

以下に説明する例では、イベント通知チャネルは、メッセージパッシング回路構成によってサポートされるメッセージチャネルのうちの１つとして定義され得る。イベント通知チャネルは、他のメッセージチャネル上で生じるイベント通知を受信するために使用することができる。したがって、プロデューサ要求がターゲットメッセージチャネル上で受信され、イベント通知条件がターゲットメッセージチャネル及び所与のコンシューマノードに対して満たされると、制御回路構成は、ターゲットメッセージチャネルに対するイベント通知が、所与のコンシューマノードに直接提供されるべきか、又はイベント通知チャネル上に提供されるべきかを決定し得る。イベント通知がイベント通知チャネル上に提供されるべきであるときに、イベント通知データは、イベント通知チャネルに関連付けられたイベント通知チャネルコンシューマ情報によって示されるアドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込まれる。

【0012】

事実上、イベント通知チャネルは、メッセージパッシング回路構成によって実装される他のメッセージチャネルと同様であると見なされてもよい（例えば、イベント通知チャネルに対するチャネルコンシューマ情報を構成するための回路構成、又はメッセージデータの書き込み若しくはイベント通知条件の検出を制御するための回路構成は、他のメッセージチャネル上で対応する機能を実行するための回路構成と共有され得る）。しかしながら、イベント通知チャネルの場合、プロデューサノードは、事実上、ＳｏＣの別個のノードではなく、メッセージパッシング回路構成自体である。したがって、イベント通知が他のチャネル上で発生したとき、イベント通知データは、イベント通知チャネルに対して定義されたアドレス空間の領域に書き込むことができる。これは、複数のメッセージチャネルに加入したい所与のコンシューマノードが、監視したいチャネルのグループ内の個々のチャネルごとに別々に通知を監視する必要があるのではなく、イベント通知チャネルの通知を監視することによって、これらのチャネルの全てを監視できることを意味する。これは、複数のチャネルを監視するためのアーキテクチャサポートを有しないコンシューマノードが、それにもかかわらず、各チャネルに関連付けられたロケーションを個々にポーリングする必要なしに、複数のメッセージチャネルに関する通知を受信することを可能にする。これは、性能を改善するのに役立つ。

【0013】

制御回路構成及びルックアップ回路構成は、２つ以上のメッセージチャネルが同じイベント通知チャネルを共有することを示すチャネルコンシューマ情報をサポートしてもよい。これは、チャネルのグループに対するイベント通知が、同じイベント通知チャネルを使用するものとして定義されることを可能にし、コンシューマが、複数の他のメッセージチャネル上に更新を提供する単一のチャネルに加入することを可能にする。チャネルコンシューマ情報が所与のメッセージチャネルとその対応するイベント通知チャネルとの関係を示すことができる、様々な方法が存在し得る。例えば、所与のチャネル／コンシューマ対に対するチャネルコンシューマ情報は、その特定のメッセージチャネル及びコンシューマに対するイベント通知を提供するためのイベント通知チャネルとして使用されるチャネルを示すチャネル識別子を提供するように設定することができるフィールドを含むことができる。

【0014】

制御回路構成及びルックアップ回路構成はまた、同じメッセージチャネルに加入している２つ以上の異なるコンシューマノードをサポートするように構成されていてもよく、この２つ以上のコンシューマノードの各々は、そのメッセージチャネルに対するプロデューサ要求に応答してメッセージデータが書き込まれるべきアドレス空間のそれぞれのコンシューマ定義領域を指定するチャネルコンシューマ情報のそれぞれのアイテムに関連付けられている。したがって、同じメッセージチャネルに加入している異なるコンシューマノードは、メッセージが書き込まれるべきアドレス空間の異なる領域を指定し得、その結果、複数のサブスクライバを有するメッセージチャネル上でプロデューサ要求が受信されると、同じメッセージがメッセージパッシング回路構成によってアドレス空間の複数の異なる領域に書き込まれる必要があり得る。したがって、この手法は、異なる数のコンシューマノードが同じチャネルに加入することに対してスケーラブルである。イベント通知チャネルが使用される場合、異なるコンシューマノードはまた、メッセージチャネルの異なる（潜在的に重複する）サブセットに対応し得る異なるイベント通知チャネルを指定してもよく、その結果、イベント通知条件が所与のメッセージチャネル上で発生すると、これは、異なるコンシューマ定義イベント通知データが、同じメッセージチャネルに加入しているそれぞれのコンシューマによって構成されている可能性がある２つ以上の異なるイベント通知チャネルに書き込まれることを必要とし得る。

【0015】

したがって、いくつかの例では、チャネルコンシューマ情報構造は、いくつかのチャネルコンシューマ情報エントリを有し得、各エントリは、所与のメッセージチャネルに対応し、所与のメッセージチャネルに加入している特定のコンシューマノードによって定義されるチャネルコンシューマ情報を指定する。複数のコンシューマがそのチャネルに加入している場合、同じメッセージチャネルに対して複数のエントリが存在し得る。チャネルコンシューマ情報構造を編成する異なる方法が存在することができ、例えば、同じチャネル識別子に対する複数のヒットを許可して同じチャネル上に複数のコンシューマを可能にする機構を有するチャネル識別子によって検索可能なコンテンツアドレス可能メモリ（ＣＡＭ）構造として編成することができ、あるいは、チャネルコンシューマ情報構造は、チャネルごとに１つのエントリを提供するチャネルルックアップ構造と、前述のチャネルコンシューマ情報エントリを提供するチャネルコンシューマ情報テーブルとを含むことができ、所与のメッセージチャネルに対応するチャネルルックアップ構造内のエントリは、所与のメッセージチャネルに対応するエントリの連結リストの先頭にあるチャネルコンシューマ情報テーブルのチャネルコンシューマ情報エントリを指定し、各チャネルコンシューマ情報エントリは、同じチャネルに加入している複数のコンシューマがある場合、連結リスト内の次のエントリへのポインタを指定することができる。連結リストの代替案は、チャネルコンシューマ情報テーブルのどのエントリが所与のメッセージチャネルのチャネル識別子に対応するかを示すビットマップをチャネルルックアップ構造の各エントリが指定し得ることであり得る。

【0016】

チャネルコンシューマ情報構造は、メッセージパッシング回路構成のハードウェアレジスタで、又はメッセージパッシング回路構成のルックアップ回路構成によってメモリからエントリを読み取ることができるメモリベースのデータ構造として、実装することができる。メモリベースのデータ構造が使用される場合、メッセージパッシング回路構成は、メモリから読み出されなければならない場合よりもアクセスを高速化するために、チャネルコンシューマ情報構造の部分をキャッシュするためのチャネルコンシューマ情報キャッシュを含むことが可能である。

【0017】

イベント通知チャネルはそれ自体が、それに関連付けられたイベント通知条件を有してもよく、制御回路構成がイベント通知チャネルに対してイベント通知条件が満たされたと判定すると、制御回路構成は、イベント通知を所与のコンシューマノードに提供し得る。例えば、イベント通知条件は、イベント通知データの特定の数のアイテムがイベント通知チャネルに書き込まれたことであり得る。したがって、イベント通知チャネルに関連付けられたロケーションにイベント通知データを書き込む各インスタンスに応答して、コンシューマノードに通知する必要はない。

【0018】

イベント通知は、異なる方法で実装され得る。一例では、イベント通知は、例えば、所与のコンシューマノードに送信されて、所与のコンシューマノードにおける処理を中断させ、監視されているメッセージチャネルに関連付けられた利用可能な情報があることを所与のコンシューマノードに通知する割り込みであり得る。しかしながら、イベント通知が発生するたびにコンシューマノードにおいて処理を中断させることは、性能に悪影響を及ぼすと考えられ得る。

【0019】

別の手法は、選択されたチャネルコンシューマ情報において示されるイベント通知アドレスに関連付けられたロケーションへの書き込みを要求する書き込み要求を発行することによって、イベント通知が所与のコンシューマノードに提供され得ることであり得る。イベント通知アドレスは、所与のコンシューマノードがターゲットメッセージチャネルに加入するときに、その所与のコンシューマノードによって定義され得る。

【0020】

いくつかのプロセッサアーキテクチャは、更新が監視されるべきメモリアドレスをプロセッサが設定し得る、イベント待ち（ＷＦＥ）機構をサポートし得る。実行されると、プロセッサに所与のスレッドにおける処理を停止させて、ＷＦＥイベントのセットのうちのいずれか１つが発生するのを待機させるＷＦＥ命令がサポートされ得る。ＷＦＥイベントは、割り込みの発生、デバッグモードの開始、又はプロセッサによって以前に指定された監視対象アドレスへの書き込みの検出を含むことができる。ＷＦＥ機構は、プロセッサが、ＷＦＥイベントが発生するのを待つ期間中、省電力状態に入るか、又は異なるスレッドの処理へ切り替えることを可能にすることができる。

【0021】

したがって、メッセージチャネル上の更新を監視するとき、ソフトウェアは、所与のアドレス（所与のチャネルに対するイベント通知を受信するためのイベント通知アドレスとしてメッセージパッシング回路構成に登録されている）をＷＦＥイベントに対する監視されるアドレスとして設定し、イベント通知を待つ期間中に省電力を可能にするか、又は他の動作を実行することを可能にするＷＦＥ命令を実行して、ソフトウェアがイベント通知をチェックするためにメモリを苦労してポーリングする必要があるのを回避することができる。したがって、イベントが所与のメッセージチャネル（イベント通知チャネルを含む）上で発生すると、イベント通知は、選択されたチャネルコンシューマ情報内に示されるコンシューマ定義イベント通知アドレスに書き込むことによって所与のコンシューマノードに送信され得、これは、メッセージチャネル上のイベントがコンシューマに通知されることを可能にする効率的な方法を提供することができる。

【0022】

しかしながら、いくつかのプロセッサアーキテクチャは、一度に単一のアドレスを監視することに関するＷＦＥイベントしかサポートしないことがあり、したがって、上述のようにＷＦＥ機構のサポートがある場合であっても、複数のチャネルが監視される必要があると、そのようなアーキテクチャ上では、コンシューマノードは、各チャネルに対するイベント通知アドレスとして同じＷＦＥアドレスを定義することができるが、その場合、イベント通知が受信されたとき、コンシューマは、イベントがどのチャネルに関連するかわからず、イベントが生成されたのはどのメッセージチャネルであるかを調査するために、各チャネルに関連付けられたメモリ内のロケーションを個々にポーリングする必要があり得、これは、監視されているチャネルの数が増加するにつれて非効率的になり得る。

【0023】

したがって、イベント通知チャネルの使用は、代わりに、単一のイベント通知チャネルに関連付けられたロケーションをポーリングし、複数の他のメッセージチャネル上のイベントに関してイベント通知チャネルにプッシュされたイベント通知データを取得することが可能であることから、そのようなアーキテクチャを有するプロセッサが、ＷＦＥイベントが発生した後に複数のチャネルを個々にポーリングする必要を回避することによって、複数のチャネルを監視する性能コストを低減することを可能にするのに特に有用であり得る。

【0024】

イベント通知が別のチャネルに対して発生するときにイベント通知チャネル上にプッシュされるイベント通知データは、異なる形式を有することができる。例えば、イベント通知データは、イベント通知条件が満たされたメッセージチャネルを識別し得る。しかしながら、実際には、メッセージパッシング回路構成のハードウェアによって使用されるチャネル識別子は、コンシューマノード上のソフトウェアにとって意味がない場合がある。そのため、いくつかの例では、イベント通知データが、ターゲットメッセージチャネルに加入している所与のコンシューマノードに関連付けられた選択されたチャネルコンシューマ情報において指定されたコンシューマ定義値を含むことが有用であり得る。所与のコンシューマノードが、ターゲットメッセージチャネルに加入しているときに、対応するチャネル上でイベントが発生したときにイベント通知データとして提供されるべきコンシューマ定義値を示す能力を提供することによって、これは、発生した特定のイベントを識別し得るコンシューマソフトウェアに対してイベント通知チャネルが意味のある情報を提供し得ることを意味する。メッセージパッシング回路構成の観点からは、コンシューマ定義値は単に任意の値であってもよく、メッセージパッシング回路構成のハードウェアに対して意味を有していなくてもよいが、イベント通知データとして提供されるべきコンシューマ定義値をコンシューマがメッセージパッシング回路構成に登録するためのメッセージパッシング回路構成内のハードウェアサポートを提供することにより、これは、イベント通知のソフトウェア処理を簡略化することができる。

【0025】

イベント通知条件は、異なる方法で実装することができる。いくつかの実装形態では、イベント通知条件は、所与のチャネル／コンシューマノード対に対するチャネルコンシューマ情報において所与のコンシューマノードによって指定されるいずれの情報とも無関係に、メッセージパッシング回路構成によって固定され得る。しかしながら、異なるコンシューマが、イベント通知が送信されるときを決める異なる条件を指定し得、かつ／又は異なるチャネルが、それらに対して定義された異なるイベント通知条件を有し得るように、イベント通知条件がコンシューマ定義イベント通知条件であることは有用であり得る。

【0026】

イベント通知条件が満たされているか否かを評価するために使用される基準も様々であり得る。例えば、イベント通知条件は、ターゲットメッセージチャネル上に提供されたメッセージが、例えば、特定のプロデューサノードから受信されたか、又は特定の基準を満たすメッセージペイロードを有するといった、特定の基準を満たすと満たされ得る。

【0027】

しかしながら、実際には、メッセージペイロードのフォーマット及び意味は、特定のプロデューサ及びコンシューマに特有であり得、したがって、いくつかの実装形態は、メッセージパッシング回路構成において、メッセージペイロードコンテンツのチェックを適用する回路構成を提供しなくてもよい。メッセージパッシング回路構成のハードウェアの観点からは、メッセージペイロードコンテンツは単に任意のバイナリデータであってもよい。

【0028】

ハードウェア内でサポートされるイベント通知条件の１つのタイプは、ターゲットメッセージチャネル上に提供されたメッセージの数が閾値に達したか又は閾値を超えたかをチェックすることであり得る。例えば、これは、所与のチャネル上で受信されたメッセージの数が、そのチャネルからのメッセージデータをキューイングするためにメモリ内に割り当てられたバッファデータ構造のサイズを超えている、バッファオーバーフローを検出することを可能にし得る。場合によっては、ターゲットメッセージチャネル上に提供されたメッセージの数に関する閾値は、ハードウェアにおいて指定される固定閾値であってもよく、この場合、これは、コンシューマノードが、所与のメッセージチャネルに対するメッセージデータを受け入れるためのバッファ空間の領域として、少なくとも閾値数のメッセージを受け入れるのに十分なサイズの領域を定義するように制約し得る。

【0029】

しかしながら、閾値が、所与のコンシューマノードによって指定されたコンシューマ定義閾値であると、特に有用であり得る。例えば、所与のメッセージチャネルに加入するための加入要求を送信するとき、コンシューマノードは、コンシューマ定義閾値を指定し得る。これにより、コンシューマは、そのニーズに応じて異なるサイズのバッファにメモリアドレス空間を割り当てる柔軟性が増し、その結果、あるコンシューマ（比較的小さいバッファを割り当てられている）は、チャネル上で特定の数のメッセージが受信された後に通知を要求し得、別のコンシューマ（より大きいバッファを割り当てられている）は、より多くの数のメッセージが受信された後に通知を要求し得る。

【0030】

ターゲットメッセージチャネル上に提供されたメッセージの数のカウントは、異なる方法で実施することができる。例えば、チャネルコンシューマ情報の一部は、対応するメッセージチャネル上でメッセージが受信されるたびに値が１増やされる又は減らされるカウントフィールドとすることができる。一手法では、カウント値は、コンシューマが最初にメッセージチャネルに加入すると最初は０であり得、コンシューマ定義イベント通知条件に対する閾値を指定する別個のフィールドが提供されてもよく、次いで、メッセージが受信されるたびにカウント値が１増やされ得、カウント値が閾値に達するとイベント通知条件が満たされたと見なされ得る。この場合、カウント値はまた、メッセージデータが書き込まれるべきアドレス空間のコンシューマ定義領域を識別するバッファベースアドレスに対するオフセットを決定するために使用することもでき、オフセットは、チャネル上で受信された最新のメッセージが書き込まれるそのバッファ空間内の相対ロケーションを示す。

【0031】

代替的に、別の手法は、コンシューマがターゲットメッセージチャネルに加入するときに最初に閾値に設定され、その後、メッセージがそのメッセージチャネル上で受信されるたびにイベント通知がトリガされる（コンシューマノードに直接提供されるか、又はイベント通知チャネル上に提供される）０に達するまで１減らされるように、デクリメントカウンタをカウントフィールドに使用することであり得る。この場合、アドレス空間のコンシューマ定義領域を識別するアドレスはまた、プロデューサ要求がそのチャネルに対して受信されるたびに単一のメッセージのサイズに相当する量だけ増分されることもでき、その結果、次にプロデューサ要求が同じチャネルに対して受信されたとき、その第２のプロデューサ要求のメッセージデータは、先のプロデューサ要求のメッセージデータが書き込まれたロケーションの後のアドレス空間のコンシューマ定義領域内の次のロケーションに書き込まれる。代替的に、アドレス空間のコンシューマ定義領域を識別するベースアドレスは一定のままであるが、メッセージの数をカウントする別個のインクリメントカウントフィールドを使用して、連続する各メッセージが書き込まれるべき、ベースアドレスに対するオフセットを生成することもできる。

【0032】

所与のメッセージチャネルに関連付けられた識別子を指定する加入コンシューマノードからのチャネル加入要求に応答して、制御回路構成は、チャネルコンシューマ情報構造を更新して、所与のメッセージチャネルに加入する加入コンシューマノードについてのチャネルコンシューマ情報を指定し得る。例えば、チャネル加入要求は、加入コンシューマノードによって提供される情報を指定することができ、この情報を使用して、メッセージパッシング回路構成がそのコンシューマにメッセージをどのように渡すかを制御することができる。例えば、チャネル加入要求は、所与のメッセージチャネルに加入する加入コンシューマノードに対するチャネルコンシューマ情報において指定されるべきアドレス空間のコンシューマ定義領域のアドレス、所与のメッセージチャネルに加入する加入コンシューマノードに対するチャネルコンシューマ情報において指定されるべきコンシューマ定義イベント通知条件、及び制御回路構成が、所与のメッセージチャネルについてイベント通知を加入コンシューマノードに提供するときに書き込む先のイベント通知アドレス、のうちの少なくとも１つを指定し得る。したがって、これは、加入コンシューマノードが所与のチャネルに対するメッセージパッシングを構成することを可能にする。異なるコンシューマノードは、同じメッセージチャネルに関連する異なるパラメータを定義することができる。所与のメッセージチャネルを識別するために使用される識別子は、プロデューサとコンシューマとの間で合意されたソフトウェア定義値であり得るメッセージハンドル値であり得る。いくつかの例では、メッセージパッシング回路構成は、メッセージハンドル値をチャネルコンシューマ情報構造内のチャネルコンシューマ情報の１つ以上のエントリにマッピングするチャネルルックアップ構造を有し得る。

【0033】

チャネル加入要求の一部は、加入コンシューマノードがイベント通知チャネルへの加入を要求しているか、又はイベント通知チャネル以外のメッセージチャネルへの加入を要求しているかのインジケーションであり得る。したがって、共通のイベント加入機構が使用され得るが、加入要求内のパラメータは、どのタイプのチャネルが構成されているかを指定し得る。

【0034】

イベント通知がイベント通知チャネル上に提供される、イベント通知チャネル以外の所与のメッセージチャネルへの加入を加入コンシューマノードが要求していることをチャネル加入要求が指定するとき、チャネル加入要求は、所与のメッセージチャネルに対してイベント通知条件が満たされたときにイベント通知データとしてイベント通知チャネル上に提供されるべきコンシューマ定義値を指定し得る。したがって、上述したように、コンシューマは、イベント通知チャネルにプッシュされるイベント通知データとして使用されるべき値をメッセージパッシング回路構成に登録して、ソフトウェアがどのイベントが発生したかを理解することを可能にし得る。

【0035】

所与のメッセージチャネルとその対応するイベント通知チャネルとの間の関連付けを加入要求において示すことができる様々な方法があり得る。例えば、イベントチャネル加入要求は、そのイベント通知チャネルが使用されるべき関連メッセージチャネルのメッセージチャネルハンドルを指定することができる。しかしながら、この手法は、同じイベント通知チャネルを共有することができるメッセージチャネルの数を制限する可能性がある。

【0036】

所与のメッセージチャネルに対する加入コンシューマノードにイベント通知を提供するときに制御回路構成が書き込む先のイベント通知アドレスを指定するためのイベント通知アドレスフィールドを所与のメッセージチャネルに対するチャネル加入要求が指定する実装形態では、より柔軟な手法を使用することができる。この場合、非イベント通知チャネル及びイベント通知チャネルに対する対応するチャネル加入要求を関連付ける１つの方法は、加入コンシューマノードがイベント通知チャネルへの加入を要求していることを指定するイベントチャネル加入要求の処理の後、イベント通知アドレスフィールドがイベントチャネル加入要求のイベント通知アドレスフィールドと同じアドレスを指定する所与のメッセージチャネルに対するチャネル加入要求の受信に応答して、制御回路構成は、所与のメッセージチャネルに対するイベント通知がイベント通知チャネル上に提供されるべきであることを示すために、所与のメッセージチャネルに加入している加入コンシューマノードに対するチャネルコンシューマ情報を設定することであり得る。したがって、以前に構成されたイベント通知チャネルに使用されるイベント通知アドレスと同じイベント通知アドレスをコンシューマノードが指定する、所与のメッセージチャネルは、そのイベント通知がイベント通知チャネルを介して報告されるべきであると仮定される。これは、メッセージチャネルの関連付けられたグループのチャネルハンドルを指定するためのイベント通知チャネル加入要求内の追加フィールドの必要性を回避し、したがって、非イベント通知メッセージチャネルのために使用される加入要求のフォーマットに対する修正がより少なくて済む。また、この手法は、イベント通知グループにグループ化される任意の数のメッセージチャネルに対してスケーラブルである。

【0037】

チャネル加入要求は、メッセージパッシング回路構成に関連付けられたコマンドインターフェースにマッピングされたアドレスをターゲットアドレスとして指定する、加入コンシューマノードによって発行された書き込み要求であり得る。したがって、これは、代わりに加入要求が、メッセージパッシング回路構成のコマンドインターフェースに対応するメモリマップされたアドレスに書き込みする標準的なメモリ書き込み動作であってもよいので、加入要求を実施するために加入コンシューマノードがハードウェア内の専用の信号プロトコルをサポートする必要がない。書き込み要求に関連付けられた書き込みデータは、上述したように、アドレス空間のコンシューマ定義領域のアドレス、コンシューマ定義イベント通知条件の閾値、又はイベント通知アドレスなどのチャネル加入情報を指定し得る。

【0038】

同様に、プロデューサ要求（チャネル上で渡されるべきメッセージデータがあることを示すためにプロデューサノードによって送信される）は、メッセージパッシング回路構成に関連付けられたメッセージインターフェースにマッピングされたアドレスをターゲットアドレスとして指定する、プロデューサノードによって発行された書き込み要求を含み得る。このメッセージインターフェースは、いくつかの例ではコマンドインターフェースと同じインターフェースであり得るか、又は代替的に、メッセージインターフェースはコマンドインターフェースとは別個であり得、メッセージインターフェース及びコマンドインターフェースは、物理アドレス空間内の異なるメモリアドレスにマッピングされる。したがって、プロデューサは、メッセージパッシングのためにハードウェアにおいて特定の信号プロトコルをサポートする必要はないが、メモリマップされたアドレスに対するメモリ書き込み動作を発行することによってそのプロデューサ要求を発行することができる。

【0039】

したがって、プロデューサ要求又は加入要求を送信するための機構としてメモリ書き込みを使用することによって、これは、よりスケーラブルであり、プロデューサ端及びコンシューマ端においてより少ないハードウェア修正を必要とする実装形態を提供する。

【0040】

プロデューサインターフェースは、プロデューサ要求が成功又は失敗することを可能にする機構をサポートし得る。したがって、制御回路構成が、所与のプロデューサ要求によって示されたメッセージを処理することができないとき、制御回路構成は、プロデューサ要求に応答して失敗インジケーションをプロデューサノードに返し得る。失敗したメッセージがプロデューサに通知されることができ、その結果、失敗したメッセージがプロデューサによって再試行されることができるように、失敗機構をサポートすることによって、これは、メッセージパッシング回路構成が、回路面積及び電力に関してより効率的であることと、異なる数のプロデューサ及びチャネル並びに異なるレベルのメッセージトラフィックに対してよりスケーラブルであることとを可能にすることができる。失敗機構がサポートされていなかったならば、メッセージが再試行されるべきであることをプロデューサに示す機構がないので、メッセージパッシング回路構成は、受信されたメッセージを処理できるまでバッファリングするのに十分なバッファ空間を必要とし、したがって、これは、最悪の場合のメッセージ需要に対処するためにバッファ容量の過剰供給を必要とする可能性があり、これはまた、プロデューサの数又は需要のレベルが特定の閾値を超えて増加すると、いずれかの選択されたバッファ容量が不十分になる可能性があるので、メッセージパッシング回路構成のスケーラビリティも制約するであろう。対照的に、失敗機構をサポートすることによって、必要とされるバッファ容量の量は、スケーラビリティを制約することなく、より実現可能なサイズに低減することが可能であり、これは、メッセージパッシング回路構成におけるいずれかのローカルバッファ容量が満杯になると、バッファ容量が再び利用可能になるまで失敗インジケーションをプロデューサに返すことができるからである。

【0041】

一般に、制御回路構成が所与のプロデューサ要求によって示されたメッセージを何らかの理由で処理することができない場合、失敗インジケーションが返され得る。失敗インジケーションが返され得る複数の理由があり得る。例えば、メッセージパッシング回路構成に、要求を収容するのに不十分なバッファ容量しかない場合、失敗インジケーションが返され得る。また、他のエラー状態が生じた場合、例えば、プロデューサ要求が、無効なメッセージチャネルの識別子を指定しているか、又はソフトウェアによってまだ適切に構成されていない場合、失敗インジケーションが返され得る。任意選択的に、メッセージチャネルは有効であるが、そのチャネルにまだコンシューマノードが加入していない場合にも失敗応答が返され得る。これは、プロデューサが更なるメッセージを送信する可能性を低減し、コンシューマが存在しないチャネル上でメッセージを処理するための、メッセージパッシング回路構成におけるリソース及び電力の不必要な消費を低減するのに有用であり得る。

【0042】

失敗インジケーションを返すことをサポートするプロデューサ要求機構を提供する１つの方法は、プロデューサ要求が、１キャッシュラインよりも大きいサイズ、例えば６４バイトのデータブロックのアトミックな更新を要求するアトミック書き込み要求である場合の方法であり得る。メモリシステムアーキテクチャは、アトミック書き込み要求によって更新されたデータブロックについて、他のオブザーバによるそのデータブロックのビューが、それらの他のオブザーバが（書き込み要求に応答して更新される前の）ブロック全体の古い値を観測するか、又は（書き込み要求に応答して設定された）ブロック全体のデータの新しい値を見るが、それらの他のオブザーバは、ブロックのいくつかの部分が更新され、他の部分が更新されていない部分的な更新を見ることができないようなものであるべきであるという保証を提供し得る。この動作の特定のマイクロアーキテクチャ実装は変化してもよく、この保証を実施するための様々な技術が存在し得る。例えば、いくつかの実装形態は、ブロック全体が更新されるまで、アトミック書き込み要求によって更新されているターゲットブロックに対する他のオブザーバの要求をブロックすることができ、一方、他の実装形態は、他のオブザーバからブロックにアクセスするための介入要求を可能にするが、ターゲットブロックの部分のうちの１つに対してブロックの第１の部分の更新とブロックの最後の部分の更新との間に別のオブザーバからの介入読み取り又は書き込みが発生した場合、失敗インジケーションをリクエスタに返させる（及び任意の部分更新を逆転させる）ことができる。アトミック性がそのようなアトミック書き込み要求に対してどのように実施されるかにかかわらず、アトミック書き込み要求は、成功／失敗インジケーションの返しをサポートして、いくつかの実装形態が、更新されているターゲットブロックへのアクセスをロックする必要を回避するために失敗インジケーションの返しを使用することを可能にし得る。そのようなアトミック書き込み要求は、アドレスの比較的大きいブロックの更新をサポートし得、成功／失敗インジケーションを返すためのサポートを有することができるので、このタイプの要求は、合理的なサイズのメッセージペイロードデータが単一の要求に応答して転送されることを可能にし、メッセージパッシング回路構成でエラーが発生した場合に失敗インジケーションを返すこともサポートするので、プロデューサ要求を実装するのに有用であり得る。

【0043】

同様に、チャネル加入要求もまた、そのようなアトミック書き込み要求を使用して実装されて、プロデューサ要求に対して説明したものと同様の利点をもたらし得る。

【0044】

いくつかの実装形態では、制御回路構成が、所与のチャネルに対するメッセージデータをアドレス空間のコンシューマ定義領域内のロケーションに書き込ませるとき、そのメッセージデータは、単にメモリの領域に書き込まれ得る。この場合、コンシューマノードが続いて所与のチャネル上のメッセージを処理するとき、コンシューマノードは、アドレス空間のコンシューマ定義領域内のアドレスに対する読み取り要求を発行し得、これらの要求はコンシューマキャッシュでミスとなることがあり、したがって、これは、メッセージデータがメモリからコンシューマキャッシュに読み込まれる間、コンシューマに遅延を引き起こし得る。

【0045】

別の手法では、キャッシュスタッシング要求がメッセージパッシング回路構成の制御回路構成によって使用されて、メッセージデータをアドレス空間のコンシューマ定義領域にプッシュし得、その結果、メッセージデータをコンシューマキャッシュにプッシュすることができ、コンシューマがそのデータを処理しようとするときのキャッシュミスの待ち時間が回避される。したがって、制御回路構成は、メッセージデータが所与のコンシューマノードに関連付けられたキャッシュにスタッシングされることを要求するキャッシュスタッシュ要求を発行することによって、プロデューサ要求によって示されたメッセージデータを、アドレス空間のコンシューマ定義領域内のアドレスに関連付けられたロケーションに書き込み得る。いくつかのシステムオンチップインターコネクトアーキテクチャは、所与のアドレスに対するデータを指定されたキャッシュに割り当てるための要求である、キャッシュスタッシング要求をサポートし得、キャッシュスタッシング要求は、スタッシングされたデータを受け取るキャッシュを有するノード以外のＳｏＣのノードによって開始される。キャッシュスタッシングをサポートする実装形態では、所与のメッセージチャネルに対するチャネルコンシューマ情報はまた、メッセージデータがスタッシングされるキャッシュを識別するノード識別子も含むことができる。

【0046】

同様に、イベント通知チャネルについて、イベント通知データがイベント通知チャネルにプッシュされるとき、これは、他のメッセージチャネルに対するメッセージデータのプッシュと同じ機構を使用し得る。イベント通知データは、キャッシュスタッシングなしにメモリに書き込むことができるか、又は上述のようにキャッシュスタッシング要求を使用することによってコンシューマのキャッシュにスタッシングされ得る。

【0047】

いくつかの例は、データがコンシューマキャッシュにスタッシングされるターゲットアドレスとして、物理アドレス空間内のデータを識別する物理アドレスを示すキャッシュスタッシング要求をサポートし得る。しかしながら、この手法では、実際には、メッセージパッシング回路構成は、仮想アドレスの物理アドレスへの変換を可能にするアドレス変換回路構成を実装する必要があり得る。実際には、メッセージパッシング回路構成は、それぞれが異なる仮想アドレスから物理アドレスへのマッピングを使用し得るいくつかのコンシューマ間で共有され得るので、アドレス変換機能を実装するメッセージパッシング回路構成には比較的大きなオーバーヘッドが存在する可能性がある。

【0048】

したがって、別の手法は、キャッシュスタッシュ要求が、アドレス空間のコンシューマ定義領域内の仮想アドレスと、仮想アドレスを所与のコンシューマノードにおける物理アドレスに変換するための変換レジームを示すアドレス空間識別子とを指定することであり得る。使用される仮想アドレス及びアドレス空間識別子は、コンシューマが対応するメッセージチャネルに加入するときに、メッセージパッシング回路構成に登録することができる。したがって、これにより、メッセージパッシング回路構成自体がアドレス変換を実行する必要がなくなり、代わりにそのキャッシュスタッシュ要求がそれに登録された仮想アドレス及びアドレス空間識別子を指定し得、次いでコンシューマノードにおける変換回路構成が、コンシューマのキャッシュ内のスタッシングされたデータの割り当てを制御するために仮想アドレスを物理アドレスに変換し得る。これにより、メッセージパッシング回路構成を実装する回路面積及び電力コストが削減され、コンシューマにおいて既に提供されているアドレス変換回路構成の再利用が可能になる。

【0049】

仮想キャッシュスタッシュ要求が使用される場合、仮想アドレスを指定するキャッシュスタッシュ要求は、必ずしもキャッシュされたデータ自体を指定しなくてもよい。一実装形態では、キャッシュスタッシングを要求するキャッシュスタッシュ要求は、仮想アドレスをコンシューマに提供し得、次いで、コンシューマは物理アドレスで応答し得、その結果、変換された物理アドレスに関連付けられた後続の要求によってデータを転送することができる。

【0050】

メッセージパッシング回路構成のルックアップ回路構成及び制御回路構成は、ＳｏＣのそれぞれのノードに関連付けられた２つ以上のキャッシュ間のコヒーレンシを管理するコヒーレントインターコネクトにおいて提供され得る。他の例では、メッセージパッシング回路構成は、そのようなコヒーレントインターコネクトとは別個のスタンドアロン構成要素であり得る。しかしながら、コヒーレントインターコネクトは、それぞれのキャッシュを有する複数のノードからの要求が受信されるポイントにあり得るので、メッセージパッシング回路構成に対して実装するのに便利な場所であり得る。

【0051】

システムオンチップの例
図１は、いくつかのリクエスタデバイス４、６、８と、リクエスタデバイスと他のキャッシュとの間のコヒーレンシを管理するためのインターコネクト１０とを含むシステムオンチップ（ＳｏＣ）２の例を概略的に示す。リクエスタデバイス４、６、８及びインターコネクト１０は、同じ集積回路上のオンチップデバイスである。この例では、リクエスタデバイスは、汎用処理を実行するための中央処理装置（ＣＰＵ）４と、グラフィックス処理を実行するためのグラフィックス処理装置（ＧＰＵ）６と、ネットワークを介したデータの送受信を制御するためのネットワークインタフェースコントローラ（ＮＩＣ）８とを含む。ＣＰＵ及びＧＰＵは、キャッシュ１１、１２、１４、例えば、特定のコア９に関連付けられたレベル１キャッシュと、ＣＰＵのための共有レベル２キャッシュ１２又はＧＰＵのための共有キャッシュ１４とを含む（実際には、ＧＰＵのコア９は個々のキャッシュを有することもあり得る）。ＮＩＣ８は、ネットワークパケットの送受信を制御するための処理回路構成１８と、ネットワークにパケットを送信し、ネットワークからパケットを受信するためのネットワークインターフェース２０とを有する。リクエスタデバイス４、６、８の各々は、コヒーレントインターコネクトと相互作用するためのコヒーレンシインターフェース１６、２２を有する。例えば、コヒーレンシインターフェース１６、２２は、関連するリクエスタからのキャッシュアクセスに応答して必要なコヒーレンシプロトコルトランザクションを生成すること、並びにインターコネクト１０からのスヌープ要求に対してコヒーレンシ状態の適切な応答及び変更で応答することに責任を負い得る。これは、いくつかのリクエスタデバイスの単なる一例であり、スクリーン上のデータの表示を制御するためのディスプレイコントローラ、又は例えばメモリと周辺デバイスとの間のデータの転送を制御するためのＤＭＡ（ダイレクトメモリアクセス）コントローラなど、他のタイプのリクエスタも提供され得ることが理解されよう。使用され得るコヒーレンシプロトコルの例は、英国、ケンブリッジのＡＲＭ（登録商標）Ｌｔｄによって提供されるＡＭＢＡ（登録商標）４ ＡＣＥ及びＡＭＢＡ（登録商標）５ ＣＨＩコヒーレンシプロトコルであるが、本明細書に記載の技術はまた、他のコヒーレンシプロトコルにも適用され得ることが理解されよう。システムキャッシュ３０は、コヒーレントインターコネクト１０に結合されるが、特定のリクエスタデバイスには割り当てられない。システムキャッシュ３０は、リクエスタからの全ての読み取り及び書き込みがメインメモリ３３によってサービスされなければならない場合と比較して、リクエスタによる一部のキャッシュデータへのアクセスを高速化するために提供され得る。メモリユニット３３は、リクエスタ４、６、８及びインターコネクト１０と同じ集積回路上のオンチップメモリ、又はＳｏＣ２とは別個の集積回路上のオフチップメモリを含み得る。インターコネクトはまた、リクエスタデバイス上で実行される動作に暗号サポートを提供するための暗号ユニットなど、他のタイプのデバイス３４に結合されてもよい。図１に示すように、コヒーレントインターコネクト１０は、どのデータアドレスが特定のリクエスタデバイス４、６においてキャッシュされているかを追跡するためのスヌープフィルタ４０を（任意選択で）含み得る。スヌープフィルタ４０は、特定のリクエスタにおいてデータがキャッシュされていないときをコヒーレントインターコネクト１０が判定できるようにすることによって、スヌープトラフィックを低減するために使用することができる。いくつかの例では、システムキャッシュ３０及びスヌープフィルタ４０は組み合わされてもよく、キャッシュされたデータとそのアドレスに関連付けられたスヌープフィルタ情報との両方を提供する単一の構造がアドレスに基づいてルックアップされる。

【0052】

コヒーレントインターコネクト１０によってサポートされるコヒーレンシプロトコルは、複数のリクエスタデバイスがメモリの共通領域へのアクセスを共有することを可能にするのに有用である。しかしながら、異なるリクエスタにおけるキャッシュされたデータ間のコヒーレンシを維持することは、性能及び回路面積コストを有し得る、スヌープトラフィックの追加のオーバーヘッド及び交換をもたらす可能性がある。

【0053】

いくつかの使用事例では、１つのリクエスタが別のリクエスタにメッセージを提供し、メッセージを送信するリクエスタは、メッセージを送信した後にそのメッセージのデータを必要とせず、したがって、メッセージを送信する「プロデューサ」リクエスタ及びメッセージを受信する「コンシューマ」リクエスタのそれぞれのキャッシュ内のメモリの共有領域からのデータ間のコヒーレンシを維持するオーバーヘッドは不要であり得ることが望ましい場合がある。

【0054】

そのようなメッセージを渡すことのコヒーレンシオーバーヘッドをなくすために、コヒーレントインターコネクト１０は、プロデューサノード及びコンシューマノードがメモリの共有領域へのアクセスを共有する必要なく、システムオンチップのプロデューサノードに関連付けられた仮想アドレス空間からシステムオンチップのコンシューマノードの仮想アドレス空間へのメッセージの受け渡しを加速させるハードウェアインターフェースを提供するメッセージパッシング回路構成５０を含む。事実上、メッセージパッシング回路構成５０は、２つの仮想アドレス空間の間にワームホールを提供し得、その結果、メッセージペイロードは、プロデューサノードがワームホールの一方の側で書き込むと、プロデューサノード及びコンシューマノードが物理アドレス空間内の共通領域にアクセスする必要なしに、コンシューマノードの仮想アドレス空間内の他方の側に現れる。これは、メッセージの発信データをプロデューサのキャッシュ１１に保存する必要がないので、コヒーレンシ問題を解消する。そのようなメッセージパッシングが有用であり得る例示的な使用事例は、例えば、ウェブサーバ上などのイベント駆動型プログラミング及びデータセンターの使用事例を含み得る。プロデューサノードは、例えば、ネットワークインターフェースコントローラ８、又はＣＰＵ４若しくはＧＰＵ６内の所与のプロセッサコア９であり得、コンシューマノードは、例えば、プロデューサからのメッセージの受信を監視しているコンシューマソフトウェアを実行しているＣＰＵ４又はＧＰＵ６内の別のコア９であり得る。

【0055】

図２は、メッセージパッシング回路構成５０の例をより詳細に示す。メッセージパッシング回路構成５０は、プロデューサノードからコンシューマノードへのメッセージの受け渡しを制御するための制御回路構成５２と、いくつかのメッセージチャネル、及びそれぞれのメッセージチャネルに対するメッセージを受信することに加入しているいくつかの加入コンシューマノードに関する情報を提供するチャネルコンシューマ情報構造６２からの情報をルックアップするためのルックアップ回路構成５４とを有する。図２に示す例では、チャネルコンシューマ情報構造６２は、物理アドレス空間の指定領域内のアドレスでメモリシステムに記憶されたメモリベースの構造である。チャネルコンシューマ情報構造６２のために使用される物理アドレス空間領域は、コア９のうちの１つで実行される監視ソフトウェアによって構成可能であり得る。例えば、メッセージパッシング回路構成５０は、チャネルコンシューマ情報構造６２のベースアドレスを指定するレジスタ（図示せず）を含み得る（又は、チャネルコンシューマ情報構造のそれぞれの部分を識別するための複数のベースアドレス、例えば、後述するチャネルルックアップ構造６４及びチャネルコンシューマ情報テーブル６６のための別々のベースアドレスが存在し得る）。

【0056】

チャネルコンシューマ情報構造はメモリに記憶されるが、チャネルコンシューマ情報構造からの情報は、より高速なアクセスのためにメッセージパッシング回路構成５０内で、１つ以上のチャネルコンシューマ情報キャッシュ５６内にキャッシュされ得る。例えば、チャネルコンシューマ情報構造６２の直近に使用されたエントリのサブセットが、コンシューマ情報キャッシュ５６にキャッシュされ得る。

【0057】

チャネルコンシューマ情報構造６２をメモリ内に配置する代わりに、チャネルコンシューマ情報構造６２を記憶するハードウェアレジスタをメッセージパッシング回路構成５０内に実装することも可能であり、これは、チャネルコンシューマ情報の特定のエントリにアクセスする際に遅延を引き起こすキャッシュミスの見込みがないので、チャネルコンシューマ情報構造へのより速いアクセスを提供し得る。しかしながら、チャネルコンシューマ情報構造がメモリ空間に記憶され、メッセージパッシング回路構成５０にキャッシュされる図２に示される手法は、異なるサイズのチャネルコンシューマ情報構造に対してよりスケーラブルであり得る。いずれの手法も使用することができる。

【0058】

図２に示す例では、チャネルコンシューマ情報構造６２は、チャネルルックアップ構造６４と、いくつかのチャネルコンシューマ情報エントリを提供するチャネルコンシューマ情報テーブル６６とを含む。チャネルルックアップ構造は、チャネル識別子によって識別されるメッセージチャネル上でメッセージを渡すことを要求するプロデューサ要求によって指定されるチャネル識別子（又はメッセージキューハンドル）に基づいてルックアップされ、チャネルルックアップ構造６４は、各チャネル識別子について、指定されたチャネル識別子を有するチャネルに加入している１つ以上のコンシューマによって定義されるチャネルコンシューマエントリの連結リストの先頭にある、テーブル６６内のチャネルコンシューマエントリのうちの１つのインジケーションを指定する。連結リスト内の最終エントリ以外の、連結リスト内の各チャネルコンシューマ情報エントリは、連結リスト内の次のエントリへのポインタ６８を含み、したがって、同じチャネルに加入している複数のコンシューマがある場合、そのチャネルの各コンシューマに対するチャネルコンシューマ情報エントリを見つけるためにポインタをたどることができる。チャネルコンシューマエントリの内容は、以下でより詳細に説明されるが、一般に、制御回路構成５２がプロデューサノードから受信されたメッセージペイロードを書き込むべきバッファ領域７０として、メッセージチャネルに加入している関連するコンシューマノードによって定義されたアドレス空間のコンシューマ定義領域（バッファ）を識別するために使用することができる。

【0059】

図２は、同じチャネルに加入している複数のコンシューマをサポートするために連結リスト構造が使用される例を示すが、代替案は、チャネルルックアップ構造６４が、各チャネル識別子に対して、そのメッセージチャネルに加入している１つ以上のそれぞれのコンシューマによって定義される特定のチャネルコンシューマ情報エントリを示すビットマップを指定することである。代替的に、チャネルルックアップ構造６４及びチャネルコンシューマ情報構造６６は、チャネルコンシューマ情報構造６２として働く単一の構造に組み合わされ得る。例えば、コンテンツアドレス可能メモリ（ＣＡＭ）構造は、チャネル識別子によってルックアップされ得、同じチャネル識別子に対する複数のヒットをサポートし得、その結果、複数のコンシューマが、同じチャネルに対する組み合わされた構造において定義されたエントリを有することができる。ＣＡＭ手法は、チャネルコンシューマ情報構造６２が、メッセージパッシング回路構成５０内のハードウェア記憶装置を使用して実装される場合に、より実現可能であり得る。別個のチャネルルックアップ及びチャネルコンシューマテーブル構造６４、６６を用いる手法は、ＣＡＭルックアップが回避されることを可能にすることによって、よりスケーラブルであり得、したがって、メモリを使用してチャネルコンシューマ情報構造６２を記憶することをより実現可能にし得る。それにもかかわらず、チャネルコンシューマ情報構造６２を編成する異なる方法が存在し得、一般に、所与のチャネル識別子について、そのチャネルに加入しているコンシューマに関連付けられた１つ以上のエントリの識別を可能にする任意の構造を使用することができることが理解されよう。

【0060】

メッセージパッシング回路構成５０は、コマンドインターフェース／キュー５８とメッセージインターフェース／キュー６０とを有する。各インターフェースは、メッセージパッシング回路構成５０によって受信された要求をバッファリングするためのキュー構造を含む。コマンドインターフェース５８及びメッセージインターフェース６０はそれぞれ、物理アドレス空間内の少なくとも１つのアドレスにマッピングされ、その結果、コマンドインターフェース５８にマッピングされたアドレス又はメッセージインターフェース６０にマッピングされたアドレスにデータを書き込むための書き込み要求は、書き込み要求の書き込みデータを、メッセージパッシング回路構成５０による処理待ちへのコマンドキュー５８又はメッセージキュー６０に挿入させる。コマンドキューは、メッセージパッシング回路構成の動作を構成するための監視コマンド（例えば、上述のようにチャネルコンシューマ情報構造のベースアドレスを定義する）など、メッセージパッシング回路構成５０の動作を構成するための任意のコマンド、又は指定されたメッセージチャネルに加入するためにコンシューマノードによって行われる加入要求のために使用される。ターゲットメッセージチャネルを指定する所与のコンシューマノードから受信された加入要求に応答して、コマンドインターフェース５８が加入要求を処理するとき、ターゲットメッセージチャネル上のメッセージが所与のコンシューマノードにどのように供給されるかを制御するためのコンシューマ定義情報を示すために、新しいエントリがチャネルコンシューマ情報構造６２に割り当てられ得る。

【0061】

メッセージインターフェース／キュー６０は、指定されたメッセージチャネルに加入している１つ以上のコンシューマに新しいメッセージを渡すことを要求するためにプロデューサノードによって送信されたプロデューサ要求を受信し、処理するために使用される。プロデューサ要求がメッセージインターフェース６０で受信されると、これは、ルックアップ回路構成５４に、チャネルコンシューマ情報構造６２を（場合によっては、チャネルコンシューマ情報キャッシュ５６が設けられている場合は、そのようなキャッシュ内で）ルックアップさせて、指定されたメッセージチャネル上の１つ以上のコンシューマに対するチャネルコンシューマ情報を識別させ、このチャネルコンシューマ情報は、プロデューサ要求によって指定されたターゲットメッセージチャネルに対して各コンシューマによって定義されたアドレス空間のコンシューマ定義領域７０へのメッセージの書き込みを制御するために、制御回路構成５２によって使用される。プロデューサ要求に応答してイベント通知条件が満たされると、イベント通知７４もまた所与のコンシューマに提供され得る。例えば、イベント通知７４は、以下でより詳細に説明するように、ＷＦＥ（イベント待ち）アドレスに関連付けられたロケーションへのデータの書き込みであり得る。

【0062】

図２は、メッセージインターフェース６０及びコマンドインターフェース５８に対して別個のインターフェースを示すが、共通のメモリマップされたアドレスにマッピングされた共有インターフェースを使用することも可能であり得る。しかしながら、メッセージを送信する必要があり得るいくつかのソフトウェアプロセスはコマンドを送信することを許可されないことがあり得、したがって、インターフェース５８、６０を分離することは、コマンドインターフェース５８にマッピングされたアドレスが、そのようなソフトウェアプロセスに対してアクセス不可能にされることを可能にすることが望ましい場合があるので、別個のメッセージインターフェース及びコマンドインターフェースを有することは、コマンドがメッセージよりも優先されることを可能にするのに、また同時にメモリ管理技術がメッセージインターフェースへのアクセスと比較してコマンドインターフェースへのアクセスを制限することを可能にするのに役立ち得る。

【0063】

図３は、メッセージパッシング回路構成５０を使用したメッセージパッシングを概略的に示す（メッセージパッシング回路構成は、以下の例では「ルータ」５０と呼ぶこともできる）。図３の例では、システムオンチップ２の２つの異なるコンシューマＢ及びＣ（例えば、ＳｏＣ内のそれぞれのコア９上で実行されるソフトウェア）は、所与のメッセージチャネルに加入している場合があり、そのメッセージチャネル上にメッセージを生成し得る１つ以上のプロデューサノード、例えば、仮想アドレス空間Ａに関連付けられたＳｏＣの別のコア９上で実行されるソフトウェア又はネットワークインターフェースコントローラ８などのデバイスが存在し得る。この例では、プロデューサ要求を送信するために使用される要求は、指定されたメモリアドレスへのアトミックな非コヒーレントストアを実行するための要求であり、これは、この例では、６４バイトのアトミックな非コヒーレントストア動作である（ただし、同様のアトミックな非コヒーレントストア動作が他のサイズのメモリブロックに対して実行され得ることが理解されるであろう）。プロデューサ要求として送信されると、アトミックな非コヒーレントストア動作は、そのターゲットアドレスとして、ルータ５０のメッセージインターフェース６０にマッピングされたアドレスを指定する。アトミックな非コヒーレントストア要求のアトミックな性質は、インターコネクト１０又はメモリシステムの他の部分が、メモリの６４バイト（又は他のサイズのブロック）を更新するためのストア要求の効果が他のオブザーバによってアトミックに見られるというアーキテクチャレベルでの保証を提供し得るという点において反映され、その結果、他のオブザーバは、メモリの指定された６４バイトに対する更新された値のいずれも見ないか、又はメモリの６４バイトに対する更新された値の全てを見ることを保証されるが、それらの６４バイトの一部が更新されているが他の部分は更新されていない部分的な更新を見ることはできない。これは、所与のプロセッサ実装に対するマイクロアーキテクチャの選択に応じて異なる方法で実施され得る。例えば、１つの手法は、指定された６４バイトへのアクセスを、それらが更新されるまでロックすることであり得る一方で、別の手法は、６４バイトへの介入アクセスを可能にするが、それらのアクセスを追跡することであり得、６４バイトブロックの第１の部分から６４バイトブロックの最後の部分までを更新する期間に６４バイトブロックの所与の部分に対して介入アクセスが行われる場合、６４バイトのアトミックな非コヒーレントストア要求によって行われた任意の変更が逆転され得、ストア要求を発行したリクエスタに失敗インジケーションが返され得る。ストア要求の非コヒーレントな性質は、ストア要求に関連付けられたデータが、要求を送信したリクエスタのキャッシュ１１、１４内に記憶される必要がないという事実によって反映され得る。

【0064】

したがって、プロデューサノードが、プロデューサ要求を表す６４バイトのアトミックな非コヒーレントストア要求を発行し、その６４バイトに書き込まれる書き込みデータが、チャネルに加入している任意のコンシューマに送信されるメッセージのメッセージペイロードを表すとき、ルータ５０は、要求を受信し、要求をそのメッセージバッファにバッファリングする。ルータ５０がメッセージを処理する準備ができているとき、ルータ５０のルックアップ回路構成５４は、ストア要求の一部で指定されたチャネル識別子に基づいてチャネルコンシューマ情報構造６２をルックアップする。チャネルコンシューマ情報構造６２が、そのチャネルに対するサブスクライバが存在することを示す場合、各サブスクライバについて、チャネルコンシューマ情報の対応するエントリが、それぞれのコンシューマの仮想アドレス空間内のコンシューマ定義バッファ領域７０のアドレスを識別するために使用され、メッセージペイロードが、各コンシューマに対するそのバッファ領域７０内のロケーションに書き込まれる。異なるコンシューマは、同じチャネルに対して異なるバッファ領域７０を定義してもよく、したがって、異なるロケーションへの同じメッセージデータの複数の書き込みが存在し得る。ルータ５０を使用することによって、プロデューサノードは、各コンシューマがメモリ内のどのロケーションにメッセージが書き込まれることを望むかを認識する必要がなく、プロデューサ及びコンシューマがメモリ内のそれらの領域へのアクセスを共有する必要がなく、コヒーレンシオーバーヘッドが回避される。

【0065】

図４は、所与のメッセージチャネル上にメッセージを生成するプロデューサノード８０と、そのチャネルに加入しているコンシューマノード８２とによって実行される動作をより詳細に示す。図４のステップ１で、コンシューマノード８２は、６４バイトのアトミックな非コヒーレントストア動作を発行することによって、加入要求をルータ５０に発行し、この動作は、チャネルコンシューマ情報構造６２に割り当てられる情報を指定する加入情報をその書き込みデータとして提供して、ルータ５０がどのように、コンシューマ８２によって定義されたバッファ領域メモリ７０にメッセージを書き込み、イベント通知条件が満たされたときにイベント通知をコンシューマに提供するかを定義する。これについては、以下でより詳細に説明する。加入要求は、そのターゲットアドレスにおいて、ルータ５０のコマンドインターフェース５８にマッピングされたアドレスを指定する。制御回路構成５２は、加入要求において指定された情報に従ってチャネルコンシューマ情報構造６２を更新する。

【0066】

図４のステップ２において、プロデューサノード８０は、再び６４バイトのアトミックな非コヒーレントストア動作を用いて、プロデューサ要求を発行して、指定されたターゲットメッセージチャネルに対するデータをルータ５０のメッセージキュー６０にエンキューする。ルータ５０は、プロデューサ要求を処理するようになると、ターゲットチャネルに対するチャネルコンシューマ情報６２をルックアップし、各コンシューマについて、メッセージがどこに書き込まれるべきかを指定するコンシューマ定義情報を読み取り、ステップ３において、コンシューマ８２に対してアクセス可能なコンシューマ定義アドレスにメッセージデータを書き込むための書き込み要求を発行する。図４に示すように、この例では、メッセージデータの書き込みは、書き込みデータをコンシューマ８２のプライベートキャッシュ１１、１２、１４にスタッシングさせ得るキャッシュスタッシング要求を発行することによって実行される。キャッシュスタッシング要求は、ＳｏＣの所与のノードのプライベートキャッシュにデータを割り当てる要求であり、その要求は、プライベートキャッシュに関連付けられた処理要素以外のリクエスタによって開始され、したがって、この場合、スタッシュ要求は、（プロデューサ８０からのプロデューサ要求に応答して）ルータ５０によって開始される。データをコンシューマノード８２のプライベートキャッシュに直接スタッシングすることによって、これは、コンシューマノードがその後データを読み取るようになるとき、読み取り要求がコンシューマのキャッシュ内でヒットすることができ、したがって、これにより、メインメモリからデータを読み取らなければならない待ち時間が回避されることを意味する。

【0067】

図５は、プロデューサ要求の例と、メッセージパッシング回路構成５０のルックアップ回路構成５４を使用してチャネルコンシューマ情報構造６２をルックアップする例とを示す。プロデューサ要求は、ターゲット物理アドレス８５及びメッセージペイロード８６を含む。メッセージペイロードは、メッセージが使用されている特定の使用事例に応じて、プロデューサ及びコンシューマ上で実行されるソフトウェアによって理解されるような任意の意味を有し得、したがってルータ５０はペイロード８６に対して特定のフォーマットを規定する必要はない。この例では、ペイロード８６は６４バイトのデータブロックであるが、他の実装形態は他のペイロードサイズをサポートし得る。

【0068】

メッセージが送信されるターゲットチャネルの識別子を識別するためにペイロードのビットを消費することを回避するために、この例では、ターゲット物理アドレス８５のアドレスビットの一部が、ターゲットチャネル識別子８７を識別するために使用される。ルータ５０のメッセージインターフェース６０として動作する入力レジスタは、実際には、物理アドレス空間内の物理アドレスの範囲にマッピングされ得、これは、ターゲットアドレスのアドレスビット（図５においてＲＩ、８８とマークされている）の共通部分を共有する。したがって、メッセージインターフェース６０にマッピングされたビットのパターンに設定された部分８８内のアドレスビットを有する任意の物理アドレスは、プロデューサ要求として働くと考えられ得る。メッセージインターフェースに全てマッピングされるアドレスの範囲を割り当てることによって、ターゲットアドレス８５の他のビットが入力レジスタ６０への要求のマッピングに影響を及ぼさないので、これらの他のビットが他の情報を示すために解放される。メッセージチャネル識別子（共有キューハンドル（ＳＱＨ））８７は、メッセージが送信されるターゲットメッセージチャネルの識別子を提供するために、これらの他のビットのいくつかにおいて識別され得る。図５に示す例では、ＳＱＨ８７は、物理アドレス空間の連続部分がメッセージインターフェース６０にマッピングされるように、アドレスがメッセージインターフェース６０にマッピングされるかどうかを指定するビットを識別するために使用されるターゲットアドレスの部分８８よりも下位部分にあるビットの部分において識別される。しかしながら、ＳＱＨビット８７をメッセージインターフェース識別ビット８８より上位のビットにおいて符号化することも可能であり得、この場合、メッセージインターフェースにマッピングされた物理アドレス空間の部分は、物理アドレス空間の複数の不連続領域を含み得る。

【0069】

ターゲットチャネル識別子（ＳＱＨ）８７は、チャネルルックアップ構造６４をルックアップするためにルックアップ回路構成５４によって使用される。プロデューサノード及びコンシューマノード上のソフトウェアは、共有キューハンドルを事前に合意し得、コマンドインターフェース５８に送信された（例えば、プロデューサソフトウェア、又はコンシューマソフトウェア、又は何らかの監視ソフトウェアのいずれかによって送信された）コマンドは、所与のメッセージチャネル上でメッセージを送信するのに先立って、そのチャネルに対するＳＱＨをチャネルルックアップ構造６４に登録するために使用され得る。

【0070】

ＳＱＨ８７に基づいてチャネルルックアップ構造６４をルックアップすることによって、これは、連結リストの先頭にあるコンシューマ需要テーブル（チャネルコンシューマ情報テーブル）６６のエントリを識別することができ、これは、指定されたチャネル上の第１のコンシューマに対するチャネルコンシューマ情報を提供する。同じチャネル上に複数のコンシューマが存在する場合、選択されたチャネルコンシューマ情報エントリの次エントリポインタフィールド９０は、連結リスト内の次のチャネルコンシューマ情報エントリを識別し、そのようなポインタは、連結リストの末尾にあるエントリまでエントリ間をたどることができる。したがって、図５に示す特定の例では、エントリＩＤ１が、４に設定された次エントリポインタ９０を有するので、現在のプロデューサ要求によって指定された特定のチャネルに対する連結リストは、エントリＩＤ１及びエントリＩＤ４の２つのエントリを含む。

【0071】

連結リストの先頭を追跡するだけでなく、チャネルルックアップ構造６４内の所与のエントリは、対応するメッセージチャネルに対する連結リストの末尾にあるコンシューマ需要テーブル６６のエントリのＩＤを指定することもできる。末尾エントリ識別子は、プロデューサ要求に応答して構造をルックアップするときには必要とされない。しかしながら、末尾エントリ識別子は、同じチャネルに加入している少なくとも１つの他のコンシューマが既に存在するとき、チャネルに対する新しい加入要求が別のコンシューマから受信された場合に、連結リストのポインタをトラバースする必要を回避するのに有用であり得る。この場合、連結リストの末尾に現在あるテーブル６６のエントリは、チャネルルックアップ構造６４から識別することができ、次いで、連結リスト内の現在の末尾エントリの次エントリポインタ９０は、加入要求に応答してコンシューマ需要テーブル６６に新たに割り当てられるエントリのＩＤを示すように更新することができ、チャネルルックアップ構造６４内の末尾エントリ識別子は、新たに割り当てられたエントリの識別子を示すように更新することができる。したがって、次エントリフィールド９０は、加入要求を送信したコンシューマによって定義されないが、ルータ制御回路構成５２によって制御される。

【0072】

各チャネルコンシューマ情報エントリ内の他の情報は、コンシューマノードによって加入要求内で（少なくとも最初に）指定され得る。チャネルコンシューマ情報テーブル６６の各エントリは、例えば、以下を指定し得る。
● コンシューマが加入しているチャネル上でメッセージが受信されたときにメッセージデータがスタッシングされるべき特定のキャッシュ１１、１２、１４を識別するために使用されるノード識別子９２。
● メッセージデータが書き込まれるバッファ領域７０に関連付けられたアドレス空間を識別するアドレス空間識別子９４。アドレス空間識別子は、コンシューマノードで使用され得る異なるアドレスマッピングのセット間を区別するのに役立つ。この例では、アドレス空間識別子は物理アドレス空間識別子（ＰＡＳＩＤ）である。他の例は、異なる方法でアドレス空間識別子を表し得る。例えば、いくつかの実装形態では、仮想マシン識別子（ＶＭＩＤ）が、処理システム上で実行される特定の仮想マシンに関連付けられ得、アドレス空間識別子（ＡＳＩＤ）は、仮想マシンによって管理される異なるプロセスに関連付けられた異なるアドレス変換レジームを区別し得る。その場合、ＶＭＩＤとＡＳＩＤとの組み合わせは、図５に示すＰＡＳＩＤと同様の方法でアドレス空間を識別することができる。
● コンシューマの仮想アドレス空間内のアドレス空間７０の割り当てられたコンシューマ定義領域を識別する仮想アドレスベース９５。
● メッセージチャネル上で受信されたメッセージの数をカウントして、特定のコンシューマ定義の数のメッセージが対応するメッセージチャネル上で受信されたときにイベント通知が生成されることを可能にするカウント値９６。
● （メモリベースの通知機構を使用してイベント通知が提供される場合）、イベント通知条件（例えば、カウント９６が、コンシューマ定義の数のメッセージがそのチャネル上で既に受信されていることを示すこと）が満たされたらルータ５０が書き込み要求を発行すべきイベント通知アドレス。この例では、以下で説明する具体的なコード例が、コンシューマコアが「イベント待ち」（ＷＦＥ）機能をサポートして、ＷＦＥアドレスとして設定されたアドレスへの更新が検出されるまでコアがスレッドの処理を一時停止することを可能にすると仮定しているので、イベント通知アドレスは「ＷＦＥアドレス」と呼ばれる。しかしながら、所与のアドレスへの更新を監視するためにＷＦＥ機構を使用することは必須ではなく、他の例は、別のメモリベースの通知機構を使用し得、その場合、メモリ内の指定されたイベント通知アドレスへの書き込みがイベント通知として使用され、プロセッサは、指定されたイベント通知アドレスへの更新をチェックするために別の機構（イベント待ち以外）を使用し得る。そのため、いくつかの例はＷＦＥアドレスに言及するが、これは、メモリ配信通知が提供され得るイベント通知アドレスの単なる一例であることが理解されよう。

【0073】

また、いくつかの実装形態は、イベント通知（ＷＦＥ）アドレス９８を完全に省略し、代わりに、コンシューマノードに割り込みを送信することによってイベント通知を提供し得る。この場合、イベント通知アドレスをコンシューマ需要テーブルに記憶する必要はない。

【0074】

仮想アドレスベース９５及びイベント通知アドレス９８（提供されている場合）の物理アドレスへの変換は、ルータ５０に対してローカルなアドレス変換回路構成を使用して、又はコンシューマノード内のアドレス変換回路構成を使用して、又は変換サービスを介して作動される変換索引バッファを使用して、又は例えばシステムメモリ管理ユニットを使用して行うことができる。したがって、仮想アドレス９５、９８を物理アドレスに変換するための仮想アドレスから物理アドレスへの変換を実装するための様々な選択肢が存在する。そのような変換は、１段変換又は中間アドレスを介した２段変換であり得る（いくつかのシステムは、両方の選択肢をサポートし得る）。

【0075】

カウントフィールド９６を使用してメッセージ数のカウントを実装するための様々な選択肢も存在し得る。図５に示す例では、コンシューマノードが所与のメッセージチャネルに加入するとき、加入要求は、イベント通知が提供される前にチャネル上で受信されるメッセージの数を表す特定のカウント値（例えば、図５に示すエントリＩＤ１に対する２０）を指定し得る。次いで、メッセージが受信されるたびに、カウント値９６は１減らされ得、アカウントが０に達すると、イベント通知がトリガされ得る。この例では、それぞれのメッセージペイロードが仮想アドレスベース９５に対して異なるオフセットに書き込まれることを可能にするために、チャネル上でメッセージが受信されるたびに、仮想アドレスベース９５自体が１つのメッセージペイロードのサイズに対応する量だけ増分され得るか、又はコンシューマがチャネルに加入してから受信されたメッセージの数を追跡するために追加のフィールドがコンシューマ需要テーブル６６に追加され得、したがって、そのフィールドは、割り当てられたバッファ領域７０に特定のメッセージを書き込むときに使用されるＶＡベース９５に対するオフセットを計算するために使用され得る。しかしながら、別の手法は、デクリメントカウンタを有する代わりに、インクリメントエンカウンタが使用され得、その結果、カウント値９６は０で開始し、イベント通知がトリガされるべきメッセージの閾値数を示す別個のフィールドが存在し（その閾値は、コンシューマからの加入コマンドにおいて指定されている）、この場合、代わりに、カウントフィールド９６は、コンシューマが最初にチャネルに加入するときに０で開始し、次いで、カウントアップするので、仮想アドレスベース９５を増分する必要がなく、したがって、カウントフィールド９６はまた、所与のメッセージが書き込まれるべきＶＡベース９５に対するオフセットを導出することにも使用され得る。

【0076】

図５に示すテーブル６４、６６は、コンシューマ情報キャッシュ５６にキャッシュすることができ、これは、エントリを、最長時間未使用などのキャッシュ割り当てポリシーに基づいてルータ５０によってメインメモリにスワップイン及びスワップアウトすることができることを意味する。

【0077】

図５に示されるルーティング機構を使用することによって、これは、各コンシューマエンドポイント又はデータターゲットが、それ自体のバッファ空間７０を割り当てる責任を負うことを意味し、その結果、各チャネルに対して、複数のエンドポイントが存在することができ、各エンドポイントは、それに取り付けられたバッファ（単一キャッシュラインほどの小さいバッファであっても）を有し得る。イーブン通知（even notification）をトリガするためのコンシューマ定義閾値は、異なるコンシューマがそれらのニーズに応じて異なるサイズのバッファを定義し得るが、バッファが満杯であるときにイベント通知をトリガすることができることを意味する。個々のアドレスの粒度ではなくチャネルベースでコンシューマ加入を定義することによって、これは、複数のプロデューサが、同じアドレスへのアクセスを共有しない場合であっても、同じチャネル上でメッセージを提供することができることを意味する。

【0078】

図５は、イベント通知チャネルの使用をサポートしないコンシューマ需要テーブル６６の基本的な実装を示す。図６に示すように、特定のコンシューマノード８２が複数のチャネルに加入することを望み、したがって、異なるチャネルに関連付けられたいくつかのキューのためのバッファ領域７０を確立するときに、問題が生じる可能性がある。コンシューマは、いくつかのメッセージチャネルに対して、それらのキューのロケーションをルータ５０に登録する加入要求を送信し得る。したがって、メッセージが異なるチャネル上で受信されると、対応するメッセージは、ルータによってそれぞれのキュー７０にプッシュされる。しかしながら、コンシューマノード８２は、キューのいずれかが更新されたかどうかを監視する際に問題に直面する。

【0079】

いくつかのプロセッサコアアーキテクチャは、コアがＷＦＥ命令を実行し得るイベント待ち（ＷＦＥ）機能をサポートし得、これにより、コアは、イベントが発生するのを待っている期間、省電力状態に切り替わるか、又は異なるスレッドの処理に切り替わる。いくつかの定義されたタイプのうちの１つのイベントが発生した時点で、コアは中断されることになり、ウェイクアップし、かつ／又はＷＦＥ動作を要求したスレッドにスイッチバックし得る。ＷＦＥ動作後にコアが割り込まれることをトリガし得るイベントの１つのタイプは、ＷＦＥ状態に入ったコア８２によってＷＦＥアドレスとして定義されたアドレスへの、別のコア、又は同じコア上の他のスレッドによる書き込みであり得る。しかしながら、問題は、いくつかのプロセッサアーキテクチャが、ＷＦＥアドレスとして一度に単一のアドレスのみが定義されることをサポートし得ることであり、これは、複数のキューの監視を可能にするために、それらのキューが全て、ＷＦＥフィールド９８内の同じアドレスに関連付けられる必要があり得ることを意味し、その結果、ＷＦＥイベントに遭遇したとき、コア８２は、どの特定のキューがイベントに遭遇したかわからないであろう。したがって、コンシューマコア８２上で実行されるスレッドは、ポーリング読み取り要求を各キューに関連付けられたアドレスに送信することによって新しいデータが利用可能であるかどうかを確認するために、全てのキューにわたってスピンする必要があり、これは、ウェブサーバなどのいくつかのアプリケーションではキューの数が多くなる可能性があるので、性能の点で無駄である可能性がある。同様に、プロセッサコアアーキテクチャがＷＦＥ機構を全くサポートしない場合、イベント通知は、ＷＦＥアドレスへの書き込みを使用して提供される代わりに、コンシューマコア８２に割り込みすることによってコンシューマコア８２に提供され得る。代替的に、別のメモリ配信通知機構が使用されてもよい（イベント通知アドレスへの書き込みが、上述のＷＦＥ機構以外の機構によって監視される）。しかしながら、これらの代替案もまた、中断又は通知されると、コンシューマコアはどのキューが更新されたかわからず、したがって、再び全てのキューにわたってスピンする必要があるという点で同様の問題に直面する。

【0080】

いくつかのプロセッサコアは、複数のアドレスへの更新を同時に監視することができるマルチアドレスＷＦＥ機構をサポートし得るが、多くのプロセッサコアは、この機能をサポートしない場合があり、この機構をサポートするように既存のプロセッサコア設計を修正することは、新しい命令がマルチアドレス監視機構を実装するための命令セットアーキテクチャサポートを必要とし得るので、著しい開発努力となり得る。多くの場合、システム開発者及びプロセッサ設計者は、この機能を追加する際の開発コストを負担することを望まないことがある。

【0081】

図７は、この問題に対処する方法を示す。命令セットアーキテクチャサポートを必要とするソリューションをプロセッサコア８２自体に構築する代わりに、この機構は、ルータデバイス５０自体内でメッセージチャネルイベントを自己監視する能力を追加する。ルータ５０のメッセージチャネルアーキテクチャは、イベント通知チャネルに対する任意選択の追加イベントキューをサポートするように適合させることができる。このイベントキュー（図７においてイベントレジストリ空間／ログとして示される）は、他のチャネル上で完了した各イベントに対するメタデータを受信して、どのメッセージチャネルが特定のイベントをトリガしたかを示す。所与のマルチイベントレジストリに対するイベントは、ルータによってＦＩＦＯ順で順序付けられ、その結果、コンシューマコア８２における呼び出しスレッドがそのイベントレジストリキューをチェックすると、最も古いイベントが最初に見られる。イベントログに保存されたメタデータは、固定幅の任意の識別特徴であり得る。例えば、加入コマンドを使用してイベントを登録するとき、コンシューマノードにおけるスレッドは、コンシューマ定義の通知値（例えば、ソフトウェアに対する特定のイベントを識別する３２ビットの整数値）を提供することができる。その番号は、チャネルコンシューマ情報テーブル６６の関連エントリに登録され、そのエントリによって定義されたメッセージチャネルに対するイベント通知条件が満たされると、イベント通知チャネルに対するイベントレジストリキュー１０２内に記憶される。

【0082】

したがって、図７に示すように、コンシューマコア８２が、チャネル上のメッセージに対するキューとして機能するそれぞれのバッファ７０に関連付けられた関連メッセージチャネルへの加入をセットアップするとき、コア８２はまた、イベント通知チャネル上のメッセージを受信するためのバッファ領域７０として、コンシューマコア８２によってイベントレジストリ空間１０２として定義されたメモリの所与の領域を有するイベント通知チャネル１００にコアを加入させる加入要求も送信する。メッセージが標準メッセージチャネルのいずれかで受信されると、それらは前述のようにそれらのチャネル用のそれぞれのバッファ７０にプッシュされる。監視されているチャネルのいずれかに対してイベント通知条件が満たされる（例えば、カウントが、チャネルに対して予め定義されたメッセージの閾値数が達成されたことを示す）と、イベント通知（例えば、イベント通知アドレスへの書き込み又は割り込み）をコンシューマコア８２に直接提供する代わりに、何らかのイベント通知データ１０４がイベント通知チャネル１００のバッファ領域１０２にプッシュされる。同じイベント通知チャネルが異なるデータチャネル間で共有され、その結果、それらの監視されたデータチャネルのいずれかでイベント通知条件が発生すると、何らかのイベント通知データがイベントレジストリログ１０２にプッシュされる。しかしながら、異なるコンシューマもまた、図７に示すコンシューマと同じメッセージチャネルに関連するイベント通知チャネルを指定している場合があり、したがって（図７には図示せず）、関連する通知イベントがそのチャネル上で発生したとき、ルータ５０が同じメッセージチャネルに対する複数のイベント通知チャネルを更新することがあり得る。

【0083】

コンシューマコア８２は、イベント通知チャネルに関連付けられたイベント通知アドレスを定義し得、その結果、特定の数のイベント通知がイベントレジストリログ１０２にプッシュされると（監視されるチャネルグループのいずれかに関連する）、指定されたイベント通知アドレスへの書き込みがトリガされ得、これは、コンシューマコア８２におけるシングルアドレス監視機構によって監視され得、その結果、コンシューマコアがポーリング機構を使用して複数のキューを監視する必要はない。代替的に、特定の数のイベント通知がイベント通知チャネルにプッシュされたときに、割り込みがコンシューマコアに送信されてもよい。いずれにしても、関連付けられたデータチャネルのうちの１つでイベント通知条件が発生したときにイベントレジストリログ１０２内のイベント通知データ１０４として指定される情報は、それらのチャネルを構成するときにコンシューマノード８２によって選択される任意の値であり得、その結果、イベントレジストリログ１０２から読み取られた値は、どのキューが対応するイベントに関連付けられているかを示すことができるか、又はどのタイプのイベントが発生したかに関する情報を示して、コンシューマコア８２上で実行されるスレッドが、その元の加入要求においてコンシューマによって定義されたイベント通知値１０４のソフトウェア固有の意味に応じて、どのキューをチェックすべきか、若しくはどのアクションをとるべきかを迅速に識別することを可能にする。

【0084】

要約すると、図７は、関連付けられたデータチャネル上の関心のある複数のイベントを登録するために、スレッドによって使用されるイベント通知チャネルとして、追加のメッセージチャネルがどのように登録されるかを示す。ルータ５０の観点からは、イベント通知チャネル１００は、任意の他のデータチャネルと同じように機能し、その結果、そのチャネルに挿入されたメッセージペイロードの数のカウント及びイベント通知のトリガに関して同様の考慮が行われ得る。しかしながら、イベント通知チャネルは、そのプロデューサとして、プロデューサ要求をルータ５０に送信している別のプロセッサコア９などのプロデューサノードを有するのではなく、ルータ５０自体が、イベント通知チャネル用のプロデューサノードであるという点において、他のメッセージチャネルとは異なる。

【0085】

図８は、イベント通知チャネルの使用をサポートするためのチャネルコンシューマ情報テーブル６６の使用を示す。各エントリは、依然として、上述したようにフィールド９０、９２、９４、９５、９６、９８を有する。イベント通知チャネルには、他のメッセージチャネルの場合と同様に、チャネルコンシューマ情報テーブル６６のエントリが割り当てられる。この例では、イベント通知が、イベント通知アドレスに書き込むことによってコンシューマノードに直接提供されるのではなく、関連付けられたイベント通知チャネル上に提供されるべきであることをコンシューマノードが示しているメッセージチャネルに関連するエントリに関して、イベント通知アドレスフィールド９８は、代わりにイベント通知チャネルに割り当てられたエントリのエントリＩＤを示すために、再利用することができる。例えば、図８において、ＩＤ１及び３を有するエントリは両方とも、イベント通知がエントリＩＤ０によって表されるイベント通知チャネル上で提供されるべきであることをコンシューマが示しているメッセージチャネルに関連する。図８には示されていないが、各エントリはまた、イベント通知アドレスフィールドがイベント通知アドレスとして解釈されるべきか、又は特定のイベント通知チャネルの識別として解釈されるべきかを示すフラグも含み得る。別個のイベント通知アドレスフィールド及びイベント通知チャネルＩＤフィールドを有することなどによって、特定のメッセージチャネルに関連するイベント通知チャネルを識別するための他の機構もあり得ること、又は割り込みを使用してイベント通知が提供される実装形態では、イベント通知アドレスフィールド９８は全く提供されなくてよく、したがって、別個のフィールドが、イベント通知チャネルに関連付けられたエントリのＩＤを示すために使用され得ることが理解されよう。

【0086】

したがって、チャネルコンシューマ情報構造６２、６６内のエントリのうちの１つによって表される所与のチャネル／コンシューマ対に対してイベント通知条件が満たされる場合（例えば、カウントフィールド９６に基づいて判定される）、そのエントリが通知はコンシューマに直接提供されるべきであると指定すると、メッセージパッシング回路構成５０の制御回路構成５２は、通知をコンシューマに直接発行するが（例えば、イベント通知アドレスへの書き込み又は割り込みとして）、指定されたチャネル及びコンシューマに対するイベント通知がイベント通知チャネル上で提供されるべきである場合は、代わりに、制御回路構成５２は、イベント通知チャネルに関連付けられたテーブル６６のエントリ（例えば、イベント通知条件に遭遇したチャネルのイベント通知アドレスフィールド９８内のエントリＩＤで指定される）を読み取り、次いで、イベント通知データを、イベント通知チャネルに関連付けられたエントリ内のアドレス空間ＩＤ９４及びＶＡベース９５を使用して識別されるイベントレジストリ空間１０２内のロケーションにプッシュすることによって、イベント通知データをそのイベント通知チャネルに書き込む。この場合も、キャッシュスタッシング機構を使用することができ、イベント通知チャネルのエントリ内のノードＩＤ９２によって識別されるキャッシュにイベント通知データをプッシュすることができる。関連するメッセージチャネルのうちの所与の１つでイベントが発生したときにイベント通知チャネルにプッシュされるイベント通知データ１０４の値は、イベントに遭遇した所与のメッセージチャネルのエントリ内の追加フィールド１１０で指定され得る。

【0087】

図８の上部に示される命令は、関連するデータメッセージチャネル及びイベント通知チャネルに加入するためにコンシューマノードにおいて実行するためのコード例を示す。このコード例は、ＷＦＥ機構をサポートする図８に示された実装に基づいており、したがって、イベント通知アドレスは、この特定の例ではＷＦＥアドレスとして説明される。

【0088】

コード例の１行目における第１のアトミックな非コヒーレントストア要求（ｓｔ６４）は、イベント通知チャネルへの加入を要求するためにコンシューマコアが発行するイベントチャネル加入要求である。ストア要求のターゲットアドレスは、メッセージパッシング回路構成５０のコマンドキュー５８にマッピングされたアドレスであり、ストア要求の残りのパラメータは、ストア要求の書き込みデータ内に含まれる。これらのパラメータは、この要求がイベント通知チャネルへの加入に関するものであることを区別するチャネルタイプパラメータ１１２、イベント通知チャネルに対するＶＡベース９５として指定されるアドレス１１４、ＷＦＥ通知がコンシューマコア８２に対して実行される前にイベント通知チャネルに書き込まれるイベント通知アイテム１０４の閾値数を表すコンシューマ定義カウント値１１６、及びイベント通知チャネルに対してそのような通知が行われるＷＦＥ仮想アドレス１１８を含む。

【0089】

コード例の２行目及び３行目における後続の２つの加入要求ｓｔ６４は、関連するデータチャネルに加入するための加入要求である。図８には示されていないが、加入要求は、それらのコマンドデータの一部として（又は、図５に関して前に説明したプロデューサ要求のターゲットアドレスにおける共有キューハンドル（ＳＱＨ）を定義するための機構と同様に、ストアのターゲットアドレスの一部として）、コンシューマが加入したいチャネルを識別するターゲットチャネル識別子を指定し得る。これらの加入要求はまた、ＶＡベース９５、ＷＦＥ ＶＡ９８、及びイベント通知が提供される前にチャネル上で受信されるメッセージの数のカウントを示す閾値も指定する。この例では、これらの加入要求は、１行目のｓｔ６４を使用して構成されたイベント通知チャネル上にイベント通知が提供されるチャネルに関連する。これは、２行目及び３行目における加入要求のＷＦＥ仮想アドレスが１行目におけるイベントチャネル加入要求に対して定義されたＷＦＥ仮想アドレス１１８と同じであることに基づいて識別される。したがって、この手法では、ソフトウェアが、イベント通知チャネル加入要求に対して、及びイベント通知チャネルを介してイベントが通知される監視対象キューのグループに対して、同じＷＦＥアドレスを定義する必要がある。これは、どのキューが通知グループに一緒に結合されるべきかを識別する１つの方法であるが、データメッセージチャネルとイベント通知チャネルとの関係を識別するために、例えば、ＳＱＨ（データチャネル加入要求において指定されている場合にはイベント通知チャネル、又はイベント通知チャネル加入要求において指定されている場合には個々のデータメッセージチャネルのいずれかのもの）を使用することによって、他の機構もまた使用され得ることは理解されよう（例えば、これは、イベント通知をコンシューマコアに提供するために割り込みが使用され、したがって、ＷＦＥフィールド９８が提供されなくてもよい、代替実装形態に有用であり得る）。また、図８には示されていないが、２行目及び３行目に示される後続の加入要求は、それらのコマンドデータの一部として、イベント通知条件がそれらの他のメッセージチャネルに対して生じたときにイベントチャネルにプッシュされるべきイベント通知データ１１０を指定し得る。

【0090】

コード例の４行目において、コア８２は、先の加入要求によって指定されたＷＦＥ仮想アドレスをそのターゲットアドレスとして指定するロード排他命令を実行する。これは、ＷＦＥ仮想アドレスをＷＦＥ機構によって監視されるアドレスとして登録する効果を有する。その後、５行目において、コアはＷＦＥ命令を実行して、コアに現在のスレッドの処理を中断させ、省電力状態に切り替えるか、又は異なるスレッドが実行されることを可能にする。ＷＦＥ仮想アドレスへのアクセスがトリガされる（例えば、インターコネクト１０から送信されたスヌープ要求に基づいてコア８２によって検出される）と、これは、コアをウェイクアップさせ、及び／又はＷＦＥ命令を実行したスレッドにコアを戻させ、これは、次いで、ＷＦＥアドレスへの更新によって表される通知を使用して、イベントレジストリ空間１０２が更新されている可能性があると判定し、次いで、そのイベントレジストリ空間のアドレスを読み取って、イベント通知データ１０４を識別し、関連するキュー内のメッセージをどのように処理するかを決定することができる。

【0091】

図９は、所与のメッセージチャネル（データメッセージチャネル又はイベント通知メッセージチャネルのいずれかであり得る）に加入することを望む加入コンシューマノードから受信されたチャネル加入要求の処理を示すフロー図である。ステップ２００において、例えば、メッセージパッシング回路構成５０のコマンドインターフェース５８にマッピングされたターゲットアドレスを指定するアトミックな非コヒーレントストア要求に基づいて、チャネル加入要求が受信される。チャネル加入要求は、以下のいずれかを含み得る加入パラメータを指定する。
● コンシューマノードが加入したい選択されたメッセージチャネルの識別子。この識別子は、プロデューサと以前に合意された共有キューハンドルであり得る。識別子は、異なる方法で、例えばコマンドのコマンドペイロードデータで、又はストア要求のターゲットアドレスのアドレスビットの一部が共有キューハンドル８９を指定する図５に示されるものと同様の手法を使用することによって、識別され得る（この場合も、アドレスの範囲は、その範囲内の任意のアドレスをコマンドとして解釈することができ、他のアドレスビットを使用してチャネルＩＤ及び他のパラメータを区別することができるように、メッセージパッシング回路構成５０のコマンドインターフェース５８に全てマッピングされ得る）。
● 所与のメッセージチャネルに対してメッセージデータがスタッシングされるべき加入コンシューマノードに関連付けられたキャッシュのノード識別子９２。
● 選択されたメッセージチャネルがイベント通知チャネルとなるか、又はイベント通知チャネル以外のメッセージチャネルとなるかを識別するパラメータ１１２。例えば、加入パラメータは、メッセージチャネルのタイプを指定するフラグ又は他のインジケータを含み得る。
● 選択されたメッセージチャネルに対してメッセージデータが書き込まれるべきアドレス空間のコンシューマ定義領域７０、１０２のアドレスを提供するＶＡベース９５。これはまた、ＶＡベース９５を変換するための異なる変換レジームを区別するために、前述のようにアドレス空間ＩＤ９４に関連付けられてもよい。
● 満たされると、イベント通知アドレスへの書き込みを使用する直接通知又はイベント通知チャネルを使用する通知のいずれかを使用してイベント通知をトリガすべきである、コンシューマ定義イベント通知条件を指定する情報。この例では、コンシューマ定義イベント通知条件は、イベント通知がトリガされる前に所与のメッセージチャネル上で渡されるメッセージの閾値数を示すカウント値１１６として定義される。しかしながら、他の実装形態は、コンシューマによって示され得る他のタイプのイベント通知条件をサポートすることもできる。
● （メモリ配信通知機構を使用してイベント通知がサポートされる場合）、イベント通知チャネルを使用しないチャネルに対して、イベント通知が提供されるときにデータが書き込まれるイベント通知アドレス９８を表すイベント通知アドレス（ＷＦＥアドレス）。所与のメッセージチャネルがイベント通知チャネルを介してそのイベント通知を提供する場合、このイベント通知アドレス値は、図８で述べたように、以前のイベント通知チャネル加入要求のために選択されたイベント通知アドレス１１８と同じになるように設定され得る。代替的に、イベント通知チャネル及びデータメッセージチャネルとの関連付けを識別するためにイベント通知アドレスとは別のフィールドを加入パラメータ内に提供することなど、所与のメッセージチャネルと対応するイベント通知チャネルとの関係を示すための別の機構を使用することができる。
● 選択されたメッセージチャネルに対するイベント通知がイベント通知チャネル上で提供される場合、加入要求はまた、所与のメッセージチャネル上のイベント通知が発生したときにイベントレジストリ１０２にプッシュされるべきコンシューマ定義イベント通知データ１１０も指定し得る。

【0092】

全ての実装形態がこれらのタイプの加入パラメータの全てを定義する必要があるわけではないことは理解されよう。例えば、キャッシュスタッシングを使用しない実装形態は、加入コンシューマノードのノードＩＤを省略してもよい。また、いくつかの実装形態は、イベント通知が生成されるべき特定のイベント通知条件をコンシューマが定義する能力を排除し得、例えば、代わりに、イベント通知が提供されるのに必要な特定のデフォルトのメッセージ数をルータが規定し得、この場合、加入要求は、コンシューマ定義イベント通知条件を指定する必要はない（閾値がコンシューマによって定義されない場合でも、テーブル６６は、メッセージの数をカウントするためのカウントフィールド９６を依然として含み得る）。しかしながら、実際には、コンシューマ定義イベント通知条件をサポートすることは、コンシューマが所与のチャネルに対してそのバッファ７０をどのようにセットアップするかにおける柔軟性を可能にするのに有用であり得る。また、イベント通知を提供するために割り込みを使用する実装形態は、イベント通知アドレスを省略することができる。

【0093】

チャネル加入要求に応答して、ステップ２０２において、制御回路構成５２は、コンシューマノードが加入を要求している所与のメッセージチャネルがイベント通知チャネルであるかどうかを判定し、そうである場合、ステップ２０４において、イベント通知チャネル及び加入コンシューマノードに対応するコンシューマチャネル情報エントリが割り当てられる。例えば、イベント通知チャネルに対するチャネルコンシューマ情報を表すために、コンシューマ需要テーブル６６の無効なエントリが選択され得、新たに割り当てられたエントリのフィールド９２、９４、９５、９６、９８は、加入要求のパラメータに基づいて設定され得、エントリは、有効であると（例えば、図８に示されていないエントリの有効フィールドを用いて）設定され得る。

【0094】

メッセージチャネルがイベント通知チャネルでなかった場合、ステップ２０６において、制御回路構成５２は、所与のメッセージチャネルに対するイベント通知がイベント通知チャネル上で提供されるべきかどうかを判定する（例えば、これは、前述のように加入要求において定義されるイベント通知アドレスに基づいて、又は別の機構によって判定されることができる）。方法は、イベント通知チャネルが使用されない場合はステップ２０８に進み、イベント通知チャネルが使用される場合はステップ２１０に進む。ステップ２０８及び２１０は、いくつかの共通の特徴を有しており、イベント通知チャネルが使用されるかどうかにかかわらず、制御回路構成５２は、新しいコンシューマのためのそのチャネルへの割り当てのために無効なコンシューマチャネル情報エントリを選択する。制御回路構成は、その所与のメッセージチャネルに対してそれより前に登録されているコンシューマがない場合、チャネルルックアップ構造６４を更新して、新しいチャネルルックアップエントリを割り当て得る（現在１つのエントリのみを含む連結リストの先頭及び末尾の両方として同じエントリを示す）。そのチャネル上に既に別のコンシューマが存在していた場合、新しいエントリは、そのチャネルに対する連結リストを拡張して連結リストの末尾に割り当てられ、したがって、以前に連結リストの末尾にあったエントリ内の次エントリポインタ９０は、コンシューマ需要テーブル６６の新しく追加されたエントリを示すように更新され、またチャネルルックアップ構造６４のルックアップされたエントリ内の末尾エントリ識別子も、前述のように新しく割り当てられたエントリを示すように更新される。いずれにしても、所与のメッセージチャネル及び加入コンシューマモードに対するコンシューマ需要テーブル６６内の割り当てられたコンシューマチャネル情報エントリは、加入要求のパラメータに基づいてフィールド９２、９４、９５、９６を指定する。

【0095】

ステップ２０８及びステップ２１０は、イベント通知がコンシューマノードに直接提供されるべきか（ステップ２０８）、又はイベント通知チャネルを使用して提供されるべきか（ステップ２１０）を示す情報の設定において異なる。この特定の例では、ステップ２０８及び２１０は、イベント通知アドレスフィールド９８及びイベント通知データフィールド１１０の設定が異なる。ステップ２０８において、イベント通知チャネルがイベント通知を提供するために使用されない場合、新たに割り当てられたエントリのためのイベント通知アドレス９８は、加入要求において指定されたイベント通知アドレスに設定される。一方、所与のメッセージチャネルに対するイベント通知がイベント通知チャネル上で提供される場合、ステップ２１０において、イベント通知アドレスフィールド９８は、イベント通知チャネルに対して以前に割り当てられたチャネル需要テーブル６６のエントリの識別子に設定される。また、ステップ２０８とは異なり、ステップ２１０において、イベント通知データフィールド１１０は、加入要求において指定されたコンシューマ定義値に設定され得る。これはステップ２０８では不要である。この場合も、代替実装形態（例えば、メモリ配信通知機構の代わりに、イベントをコンシューマコアにシグナリングするために割り込みベースの通知機構を使用する）は、エントリの他の情報（例えば、専用フラグ又はフィールド）を設定して、イベント通知がコンシューマノードに直接提供されるべきか（ステップ２０８）、又はイベント通知チャネルに関連付けられたアドレス空間の領域にイベント通知データを書き込むことによって提供されるべきか（ステップ２１０）を区別し得る。

【0096】

図１０は、メッセージパッシング回路構成５０のメッセージインターフェース６０で受信されたプロデューサ要求の処理を示すフロー図である。ステップ２５０において、ターゲットメッセージチャネルに対するメッセージデータ８６を提供するプロデューサ要求が受信される。それに応答して、ステップ２５２において、制御回路構成５２は、プロデューサ要求に対して何らかの失敗状態が識別されたかどうかを判定する。例えば、起こり得る失敗の理由は、受信されたメッセージを収容するのにメッセージキュー６０において十分な空間が存在しないこと、メッセージパッシング回路構成５０が現在ビジーであり、メッセージを処理できないこと、メッセージペイロードが不正に形成されていること、又はメッセージパッシング回路構成５０においてターゲットメッセージチャネルに対して有効なチャネル情報が定義されていないこと（例えば、何らかのスーパーバイザソフトウェアが、指定されたメッセージチャネルに対する有効な状態を示すようにメッセージパッシング回路構成５０を構成する必要があり得る前）であり得る。特定のプラットフォームのニーズに応じて、他のタイプの失敗状態も実装され得ることが理解されよう。失敗状態が識別され、その結果、メッセージを現在処理することができない場合、ステップ２５４において、失敗インジケーションが、プロデューサ要求を送信したプロデューサノードに返される。これは、メッセージパッシングが失敗したことをプロデューサに示す任意の返された信号又はデータ値であり得る。プロデューサは、これを使用して、後でメッセージを送信することを再試行するかどうか、又は監視コードが所与のメッセージチャネル上でのメッセージパッシングを可能にするようにメッセージパッシング回路構成５０を構成することを要求するかどうかを決定し得る。いくつかの例では、失敗インジケーションは、失敗の理由のインジケーションを含み得、その結果、プロデューサは、応答してどのアクションをとるべきかを決定することができる。

【0097】

一方、プロデューサ要求に応答して（ステップ２５２での失敗状態がないという識別に続いて、又はステップ２５０からステップ２５６に直接進む矢印によって示されるように失敗状態が発生したかどうかの評価と並行して）、ルックアップ回路構成５４は、チャネルコンシューマ情報構造６２をルックアップして、ターゲットメッセージチャネルに対して定義されたチャネルコンシューマ情報があるかどうかを判定する。これは、メモリ内の構造からデータを読み取る要求を発行することによって、又は内部レジスタ内若しくはチャネルコンシューマ情報キャッシュ５６内の構造をルックアップすることによって行うことができる。キャッシュが使用され、要求がキャッシュミスすると、メモリにチャネルコンシューマ情報を要求するためのラインフィル要求が発行され得る。

【0098】

ターゲットメッセージチャネルに対してチャネルコンシューマ情報が定義されていない場合、図１０に点線で示すように、いくつかの選択肢がある。１つの選択肢は、これを失敗として扱い、ステップ２５４に進んで失敗インジケーションをプロデューサノードに返すことである。別の選択肢は、単にメッセージを無視するが、メッセージパッシングが成功したことをプロデューサ要求に示すことであり、したがって、ステップ２５８で、成功インジケーションがプロデューサに返され得、次いで、メッセージパッシング回路構成５０は、次に受信されたプロデューサ要求を処理する準備が整い得る。有効なチャネル上でメッセージを送信したが、そのチャネルへのサブスクライバがまだないとき、プロデューサ要求に通知することが望ましいかどうかに応じて、これらのオプションのいずれかが可能である。

【0099】

チャネルコンシューマ情報の少なくとも１つの有効エントリがターゲットメッセージチャネルに対して利用可能である場合（例えば、チャネルコンシューマ需要テーブル６６がそのチャネルに対する少なくとも１つの有効エントリを含むことを定義するチャネルルックアップ構造６４内にエントリがあった場合、又は代替的にチャネルコンシューマ情報を提供するＣＡＭ構造において、少なくとも１つのヒットが識別された場合）、本方法はステップ２６０に進む。ステップ２６０において、ターゲットメッセージチャネルへのサブスクライバに対するチャネルコンシューマ情報の第１のアイテムが取得され、選択されたチャネルコンシューマ情報として扱われる。例えば、取得された情報は、先に説明した例での連結リストの先頭におけるテーブル６６のエントリであり得る。

【0100】

ステップ２６０において、制御回路構成５２は、選択されたチャネルコンシューマ情報のフィールド９４、９５、９６によって指定されるアドレス空間のコンシューマ定義領域７０内のアドレスに関連付けられたロケーションへの、プロデューサ要求において受信されたメッセージデータ８６の書き込みを要求する。例えば、カウントフィールド９６は、ＶＡベース９５に対するオフセットを識別するために使用され得、若しくは代替的に、オフセットを追跡する別個のフィールドが使用され得、又はいくつかの実装形態では、新しいメッセージが受信されるたびにＶＡベース９５が増分される場合、オフセットを適用する必要はなく、書き込みはＶＡベース９５自体によって識別されるロケーションに対するものとすることができる。アドレス空間識別子９４は、指定された仮想アドレスに対応する物理アドレスを取得するために使用される特定の仮想アドレスから物理アドレスへのマッピングを識別することができる。

【0101】

ステップ２６０におけるメッセージデータの書き込みは、図４に関して先に説明したように、キャッシュスタッシング要求を使用し得る。図１１は、キャッシュスタッシング動作をより詳細に示す。仮想キャッシュスタッシング機構が使用され得、それによって、コンシューマのキャッシュに送信される初期スタッシング要求は、選択されたチャネルコンシューマ情報内の仮想アドレス（ＶＡベースフィールド９５に基づく）及びアドレス空間識別子９４を最初に指定し得る。これは、代わりにコンシューマにおけるメモリ管理ユニットの変換索引バッファ（ＴＬＢ）１３０を使用してアドレス変換を実行することができるので、メッセージパッシング回路構成５０自体が仮想アドレスから物理アドレスへの変換をサポートする必要がないことを意味する。これにより、ルータ５０の実装を簡略化することができる。

【0102】

関連するチャネルに対する加入要求を送信するとき、コンシューマノードは、スタッシュが実行されるべき関連するキャッシュのノードＩＤ９２、バッファ領域７０の仮想アドレス９５、及び対応するアドレス空間ＩＤ９４をチャネルコンシューマ情報に登録している。したがって、メッセージがチャネル上で最初に受信されると、ルータ５０は、登録された仮想アドレス及びアドレス空間識別子を指定し、かつノードＩＤによって識別されるノードに発行される、仮想スタッシング要求を表すスヌープ要求１３２を発行することができ、並びにこれが仮想スタッシング要求を表すことを識別するパラメータを指定し、次いで、この要求は、コンシューマノードにおけるＴＬＢ１３０が、アドレス空間識別子９４によって識別される変換レジームのアドレス空間マッピングに従って仮想アドレスを物理アドレスに変換することをトリガする。コンシューマは、変換された物理アドレスを示すスヌープ応答１３４を提供する。変換された物理アドレスを受信した後、図１１のステップ３で、物理スタッシュ要求１３６がコンシューマノードのキャッシュに送信され、この物理スタッシュ要求は、変換された物理アドレスを指定し、かつ関連するメッセージチャネル上にプッシュされる実際のデータを伴い、コンシューマノードは、次いで、このデータをそのキャッシュのうちの１つに割り当てる。これは、関連するメッセージチャネル上で後続のイベント通知が発生したときに、対応するデータが既にそのキャッシュ内に常駐しているので、コンシューマコアがメインメモリ（ＤＲＡＭ）からそのデータをフェッチする必要がなく、したがって、アクセス待ち時間を短縮することができることを意味する。

【0103】

コンシューマは、その現在の状況に応じて、スタッシング要求を拒否することが可能であり得、例えば、指定された物理アドレスに対するデータとともに割り当てられ得るキャッシュエントリのセットは、コアが追い出すことを望まない可能性がある他のデータのために既に使用されていることがある。スタッシュ要求を受け入れるか拒否するかを決定するための特定の基準は、実装固有であってもよく、コンシューマコアのニーズに応じて変化することができる。コンシューマは、ステップ１で最初のスヌープ要求を受信したとき、又はステップ３で実際のスタッシュデータを受信したとき、又はその両方の機会に、キャッシュスタッシング要求を拒否することができ得る。コンシューマコアが、そのデータをコンシューマキャッシュに割り当てることができないと決定した場合、ステップ３で物理スタッシュ要求が受信されると、コンシューマは、データをスタッシュしないことを選択することができ、代わりに、ルータ５０から受信されたデータを、変換された物理アドレスによって識別されるＤＲＡＭ又は他のメモリ内のロケーションに書き込ませ得る。図１１に示されるものに対する代替手法は、ステップ２における仮想スタッシュ要求への応答として変換された物理アドレスを送信するステップ２におけるスヌープ応答が、コンシューマコアがスタッシングを受け入れるかどうかを示し得、この場合、ルータ５０は、コンシューマがスタッシュ要求を受け入れないことを示している場合、メッセージデータをＤＲＡＭに直接書き込み得る。

【0104】

代替手法は、図１１のステップ１及び３で送信されたメッセージを、仮想アドレス及び実際のスタッシングされたデータの両方を提供する単一の要求に組み合わせることができ、その結果、単一の要求が、仮想アドレスの物理アドレスへの変換を両方トリガし、次いで、データをキャッシュ内にスタッシングさせるか、又はコンシューマがスタッシングされたデータを受け入れない場合はメモリに書き込ませ得るので、スタッシングされたデータを提供する第２の要求を送信する必要がない。

【0105】

いずれにしても、図１０のステップ２６０における仮想スタッシングをサポートするこの手法は、ルータが複数のプロデューサとコンシューマとの間で共有されるときに比較的複雑となり得るアドレス変換をルータが実装する必要性を回避する。

【0106】

図１０に戻ると、ステップ２６０でメッセージデータを書き込んだ後、ステップ２６２で、選択されたチャネルコンシューマ情報エントリのカウントフィールド９６が更新されて、別のメッセージがターゲットメッセージチャネルにプッシュされたことを反映する。例えば、図８に示す手法では、カウントフィールドは１減らされ得、同時に仮想アドレスベース９５が１つのメッセージのサイズだけ増分され得るか、又は代替的に図８に示されていない別個のフィールドが増分されて以前に受信したメッセージのカウントを表して、これがＶＡベース９５に対するオフセットとして使用されることを可能にし得る。

【0107】

ステップ２６４において、制御回路構成５２は、選択されたチャネルコンシューマ情報エントリにおいて指定された情報に基づいて、ターゲットメッセージチャネルに対してイベント通知条件が満たされているか否かを判定する。例えば、制御回路構成は、ターゲットメッセージチャネル上に提供されたメッセージの数が、コンシューマがチャネルに加入したときに設定されたコンシューマ定義閾値であり得る閾値に達したか又は閾値を超えたことをカウントフィールド９６が示すかどうかを判定する。例えば、図８に示される実装形態では、イベント通知条件は、カウントフィールド９６が０に達したときに満たされたと見なされ得る。代替案は、選択されたチャネルコンシューマエントリ情報が、イベント通知条件が満たされるメッセージの閾値数を指定する閾値フィールドを含み得、閾値に向かって１ずつ増えるカウントフィールド９６は、カウントが閾値に等しいか又は閾値を超えるとイベント通知条件が満たされることをトリガし得ることである。

【0108】

イベント通知条件が発生していない場合、イベント通知をトリガする必要はなく、ステップ２６６において、ルックアップ回路構成５４は、プロデューサ要求が受信された同じターゲットメッセージチャネルに加入した別のコンシューマに対するチャネルコンシューマ情報があるかどうかを判定する。例えば、これは、ステップ２５６、２６０、２６２、２６４において使用される選択されたチャネルコンシューマ情報の次エントリポインタ９０に基づいて識別され得、又はこれは、複数のヒット信号がコンテンツアドレス可能メモリルックアップにおいて受信されたかどうかに基づいてもよい。同じターゲットメッセージチャネルに加入している別のコンシューマに対するチャネルコンシューマ情報の別のエントリがある場合、ステップ２６８で、その次のコンシューマに対するチャネルコンシューマ情報は、選択されたチャネルコンシューマ情報として扱われ、方法はステップ２６０に戻って、その次のコンシューマのエントリを先に論じたのと同じように処理する。同じターゲットメッセージチャネル上の別のコンシューマに対して識別された更なるチャネルコンシューマ情報がない場合、ステップ２６６に続いて、本方法はステップ２５８に進み、成功インジケーションがプロデューサに返され、メッセージパッシング回路構成５０は次のプロデューサ要求を処理する準備が整う。

【0109】

ステップ２６４において、制御回路構成５２が、選択されたチャネルコンシューマ情報に基づいて、イベント通知条件がターゲットメッセージチャネルに対して満たされたと判定した場合、ステップ２７０において、制御回路構成５２は、イベント通知がイベント通知チャネル上に提供されるべきであることを、選択されたチャネルコンシューマ情報が指定するかどうかを判定する。そうでない場合、イベント通知はコンシューマノードに直接提供されるべきであり、したがって、ステップ２７２で、イベント通知がコンシューマノードに送信される。例えば、イベント通知アドレスフィールド９８が読み取られ、書き込みが発行されて、選択されたチャネルコンシューマ情報において指定されるように、イベント通知アドレスに関連付けられたデータを更新する。コンシューマノードが以前にＷＦＥ監視をセットアップしており、イベント通知アドレスへの通知を待っている場合（図８のコード例において上述したように）、これは、コンシューマノードをウェイクアップ又は中断させてよく、適切なメッセージチャネルに関連付けられた情報を読み取ることができる。ステップ２７２でイベント通知アドレスへの書き込みを生成した後、方法はステップ２６６に進み、先に説明したのと同じように、別のコンシューマに対するチャネルコンシューマ情報をチェックする。他の例では、イベント通知は、イベント通知アドレスに書き込むのではなく、コンシューマノードに割り込み信号を送信することによってコンシューマノードに送信することができる（例えば、割り込みを送信するコンシューマノードは、ノードＩＤ９２に基づいて識別され得る）。

【0110】

しかしながら、ステップ２７０において、イベント通知がイベント通知チャネル上で提供されるべきであることを、選択されたチャネルコンシューマ情報が指定することを制御回路構成５２が識別する場合、ステップ２７４において、イベント通知チャネルとして使用されるべき特定のチャネルが、例えば、図８の例に示されるようにイベント通知アドレスフィールド９８からイベント通知チャネルのエントリＩＤを読み取ることによって、選択されたチャネルコンシューマ情報に基づいて識別される。ルックアップ回路構成５４は、その特定のイベント通知チャネルに関連付けられたチャネルコンシューマ情報のエントリをルックアップし、制御回路構成５２は、イベント通知チャネルのエントリを使用して、チャネルコンシューマ情報のイベント通知チャネルのエントリのＶＡベース９５に基づいて識別されるように、イベントレジストリ空間としてコンシューマによって定義されたアドレス空間１０２のコンシューマ定義領域内のアドレスに関連付けられたロケーションへのイベント通知データの書き込みを制御する。イベント通知チャネルのバッファ領域１０２に書き込まれるべきイベント通知データ１０４は、ターゲットメッセージチャネルに対する選択されたチャネルコンシューマ情報のイベント通知データ１１０に基づいて識別され得る。この場合も、イベント通知データの書き込みは、ステップ２６０で図１１に関して説明したように仮想キャッシュスタッシング機構を使用し得る。

【0111】

図１０のステップ２７６において、イベント通知チャネルコンシューマ情報のカウントフィールド９６は、ターゲットメッセージチャネルに対してステップ２６２と同様の方法で更新される（また、任意選択で、使用される実装形態に応じてＶＡベース９５の増分が実行され得る）。

【0112】

ステップ２７８において、制御回路構成５２は、ターゲットメッセージチャネルに対するステップ２６４に対応する方法で、例えば、イベント通知チャネルのコンシューマ情報エントリのカウントフィールド９６が、イベント通知チャネル上で提供されるメッセージの数が閾値に達したか又は閾値を超えたことを示すかどうかに再び基づいて、イベント通知チャネルに対してイベント通知条件が満たされたかどうかを判定する。したがって、ステップ２８０において、イベント通知条件がイベント通知チャネルに対して満たされる場合、制御回路構成５２は、例えば、チャネルコンシューマ情報のイベント通知チャネルのエントリにおいて指定されたイベント通知アドレスフィールド９８において定義されたイベント通知アドレスへの書き込みをトリガすることによって、イベント通知チャネルに関連付けられたイベント通知を生成する。代替的に、イベント通知チャネル上のイベント通知は、割り込み信号をコンシューマノードに送信することによって実行され得る。ステップ２７８でイベント通知条件が識別されなかった場合、ステップ２８０は省略される。

【0113】

いずれにしても、ステップ２７４、２７６、２７８、２８０は、ステップ２６０、２６２、２６４及び２７２においてターゲットメッセージチャネルに対して実行された動作を反映する。これは、メッセージパッシング回路構成５０の観点から、イベント通知チャネルが他の任意のメッセージチャネルと同様に機能し、したがって、通常のデータメッセージチャネルに対してこれらの動作を実行するために既に提供されている回路ロジックを再利用することができることを意味する。メッセージパッシング回路構成５０は、どのタイプのイベント通知が使用されるべきかをチェックするステップ２７０を実装するため、及びステップ２７４において、ルータ５０以外のプロデューサから受信されたメッセージデータをプッシュする代わりに、フィールド１１０において指定されたデータ値をイベント通知データとして生成するための何らかの追加のロジックを備える。

【0114】

ステップ２７８でイベント通知条件が発生したか否かにかかわらず、ステップ２７８又はステップ２８０のいずれかに続いて、本方法はステップ２６６に進み、前述したように、同じターゲットメッセージチャネル上の他のコンシューマに対する他の任意のチャネルコンシューマ情報を再びチェックする。ステップ２６４において１つのコンシューマに対してイベント通知条件が生じ得ると同時に、ステップ２６４において同じチャネル上の別のコンシューマに対してイベント通知条件が生じ得ないことが可能であることに留意されたい。同様に、イベント通知チャネルが所与のコンシューマに通知を提供するために使用されるべきかどうか、テーブル６６のどの特定のエントリがステップ２７４でイベント通知チャネルのチャネルコンシューマ情報を取得するために読み取られるか、及びイベント通知条件がステップ２７８で発生したかどうかに関するステップ２７０での結果は、所与のメッセージがチャネル上で受信されたとき、その同じチャネルに加入している異なるコンシューマ間で変化し得る。

【0115】

図９及び図１０は、ステップ間の特定の順序付け又は依存関係を示すフロー図を示すが、これは一例にすぎず、他の例は、ステップを並べ替えるか、又は代わりに、図９及び図１０に逐次的に示されたいくつかのステップを並列に実行し得ることが理解されよう。

【0116】

したがって、要約すると、上記の例は、メッセージチャネルルーティングデバイス５０が、コンシューマ自体がマルチアドレス監視をサポートすることを必要とせずに、所与のコンシューマによる複数のキューの監視を可能にする機構を提供する。これにより、メッセージチャネルルータを使用して複数のチャネル又はソケットを監視するために、単一のアドレスに対する単一のイベント待ち機構を使用することが可能になる。

【0117】

本出願において、「～ように構成された（configured to．．．）」という用語は、装置の要素が、定義された動作を実施することが可能である構成を有することを意味するために使用される。この文脈において、「構成」とは、ハードウェア又はソフトウェアの配設又は相互接続の方法を意味する。例えば、装置は、定義された動作を提供する専用ハードウェアを有し得るか、又はプロセッサ若しくは他の処理デバイスが、機能を実行するようにプログラムされ得る。「ように構成された」は、装置要素が、定義された動作を提供するために何らかの変更がなされる必要があることを意味しない。

【0118】

本発明の例示的な実施形態が添付の図面を参照して本明細書で詳細に説明されているが、本発明はこれらの正確な実施形態に限定されないこと、及び様々な変更及び修正が、当業者によって、添付の特許請求の範囲によって定義されている本発明の範囲から逸脱することなく、実施形態に行われ得ることが理解されよう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図10-1】

【図11】

【国際調査報告】