JP4782771B2 - コンピュータ装置におけるプロセス間通信 - Google Patents

Description

本発明は、コンピュータ装置におけるプロセス間通信（ＩＰＣ：inter process communication）を管理する方法に関し、特に、プロパティまたはイベントの発行元と、プロパティまたはイベントを通知されることを要求する１以上の引用先との間で、プロパティまたはイベントを共有できるようにするための、改良された発行および引用機構に関する。本発明は、このようなプロセス間通信を管理するように構成されたコンピュータ装置にも、コンピュータ・ソフトウェアにも関し、特に、このような通信をコンピュータ装置に管理させる、コンピュータ装置用のオペレーティング・システムに関する。

本明細書で使用するコンピュータ装置という用語は、広くは、どのような形態の電気装置にも当てはまることが企図されるものであり、どの形状因子のデジタル静止画および動画カメラなどのデータ記録装置も、ハンド・ヘルドおよびパーソナル・コンピュータを含むどのタイプまたは形態のコンピュータも、１台の装置内で通信、画像の記録および再生の少なくともいずれか、ならびに計算機能を併用する携帯電話、スマート・フォン、発信機を含むどの形状因子の通信装置も、ならびに他の形の無線および有線情報装置も含むものである。

ほとんどのコンピュータ装置は、オペレーティング・システムの制御下で動作するようにプログラミングされる。オペレーティング・システムは、コンピュータ装置の中央処理装置に給送されるコードの形をした一連の命令を用いて、コンピュータ装置を制御する。こうした命令は、オペレーティング・システムによってスケジュールされる、一連の、実行の準自律基本単位とみなすことができる。こうした実行の基本単位は、それぞれ、コンピュータ装置内で実施されるスレッドおよびプロセスとして知られ、常に１以上のスレッドを含む。一般的なオペレーティング・システムは、コンピュータ装置によって実施される非常に様々なタスクを制御するために、異なる多くのスレッドをスケジュールする。

オペレーティング・システムは、いくつかの構成要素からなるとみなすことができ、こうした構成要素の一部は、コンピュータ装置のハードウェア資源への、他の構成要素よりも特権的なアクセス権を有する。より特権的なアクセス権を有する構成要素は、特権的構成要素として知られる。こうした１以上の特権的構成要素は、一般にオペレーティング・システムのカーネルとして知られるものを形成する。

オペレーティング・システムのカーネルは、概してユーザ・モード・プログラムとして知られるものを、こうしたプログラムがカーネルを用いてアプリケーション・プログラム・インターフェース（ＡＰＩ）を介してのみシステム資源にアクセスすることができるように実行する。ユーザ・モード・プログラムは通常、ユーザ・インターフェースを有し、したがって、こうしたプログラムは一般に、アプリケーションとして知られる。コンピュータ装置上で実行される各アプリケーションは、装置メモリ内にそれ自体の仮想アドレス空間をもつプロセス中で実行され、あるアプリケーションと別のアプリケーションの間の境界は、プロセス境界として知られる。したがって、こうしたアプリケーションのメモリ・アドレス空間は完全に別々に保たれるので、プロセス境界は、あるアプリケーションが、別のアプリケーションのデータを誤って上書きすることがないように保証する。したがって、プロセスは、オペレーティング・システム内の保護の基本単位とみなすことができる。

しかし、プロセス境界を越えて通信を遂行する必要のある状況があり、こうした通信は、プロセス間通信（ＩＰＣ）として知られる。プロセス間通信を用いる場合、カーネルは、保護の基本単位、すなわちプロセス境界が、こうした通信を供給することができるように安全に越えられることを可能にする機構を提供しなければならない。ほとんどのオペレーティング・システムは、システム・サーバとの通信を強化する１以上のクライアント／サーバ機構を提供する。

スマート・フォンなど、特定の形態のコンピュータ装置には、オペレーティング・システムの他のスレッド／プロセスの対象にもなり得る、オペレーティング・システムのあるプロセス中に起こり得る多くのイベントがある。こうしたイベントの一般的な例は、
・電話信号強度
・ブルートゥース接続／切断
・ショート・メッセージ・サービス（ＳＭＳ）の到着
・着信赤外線（ＩＲ：Infra Red）転送
・バッテリ・レベル
である。

こうしたイベントそれぞれに対しては、主にイベントを扱うことを担当する１つのプロセスが通常は存在するが、しばしば他のプロセス中には、やはりそのイベントに関心をもつ他のスレッドがある。例えば、状況ディスプレイである。

上記の種類のイベントの通知は、プロセス境界を越える必要があるが、今までは、様々な通知サーバを使用して、一部のオペレーティング・システムにおいて対処されていた。例えば、システム・エージェント・サーバおよびブロードキャスト・サーバなどの通知サーバが、英国ロンドンのＳｙｍｂｉａｎ Ｌｉｍｉｔｅｄから販売されているＳｙｍｂｉａｎ ＯＳ（商標）として知られる、スマート・フォンのオペレーティング・システムに組み込まれている。

しかし、非常に類似したタスクをすべてが実施している上記タイプのいくつかのサーバが存在するとき、それに伴う、各サーバからの、全システム資源を求めるそれぞれの要求が存在する。さらに、こうしたサーバはそれぞれ、関連付けられた、比較的要求が厳しい資源要件を有する比較的「重い」サーバとみなすことができるので、こうしたサーバの使用による、システム資源に対する全体的な要求は比較的高い。したがって、スマート・フォンなど、比較的制約された物理資源を有するコンピュータ装置においては望ましくないと考えられる。

さらに、上記タイプの多様なサーバの使用には、本質的に、クライアント／サーバ・インターフェースの間の特有の依存を必要とし、その結果、システム・アーキテクチャの柔軟性を制限することになる。例えば、一部のオペレーティング・システムを用いた場合は、特定の通知サーバがそれ以外の場合は必要とされないとしても、その通知サーバを組み込まずにＲＯＭに通信能力を組み込むことができない。

さらに、スマート・フォンは、装置の全体的な行動に影響を与える、いくつかのグローバルな「システム」状態を有する。こうしたグローバルなシステム状態の例は、
・電源状態：オン、オフ、充電中、ＭＰ３モードなど
・プロファイル状態：静音、大音量、ハンドバッグなど
・ネットワーク接続状態：ＧＰＲＳ、３Ｇ、ＧＳＭ、圏外、オンライン／オフライン
である。

装置上で実行される一部のアプリケーションは、グローバル・システム状態の状況変化に関心をもち得るが、多くは、動作が実施されるべき特定の時点でどのように行動するかを決定するように、単に装置の現在の状態に関心をもつだけである。例えば、ＳＭＳメッセージまたは後で送信するためのキューを送信し、音を鳴らすかどうか、キーの押下に反応するという行動である。他の状態はグローバルでなくてよいが、オペレーティング・システムの様々なエリアの間で容易に共有される必要がある場合があり、したがって、グローバル状態のサブセットとみなすことができる。

オペレーティング・システムに、装置のいくつかのグローバル状態または値を管理させるという要件もある。いくつかのオペレーティング・システムは、このような値を既に利用しているが、現在では、上記の種類の状態は、あまり効率的なやり方では扱われていない。通常、特殊ケース・コードおよびランダム・インターフェースが用いられる。例えば、カーネル内の電力モデルへの、または電話が、ＭＰ３モードなど、ある特定のモードで動作しているのを記録するのに使われる特定のサーバへのインターフェースを用いることが知られている。したがって、現在のシステムは、グローバル状態をうまく扱っておらず、実際に存在するそうした機構は製品特有で、アドホックなものであり、コードの重複をもたらしてしまう。

「永続性」の状態は、グローバル・システムの値の一般的な例である。永続性の状態は、永続的である必要がある状態情報を有する構成要素とみなすことができ、永続する必要があるグローバル状態もある。いくつかの構成要素は、永続的である必要がある状態情報を有し、永続する必要があるグローバル状態もある。こうした状態情報の例は、デフォルトのファイル名、ローカル設定、ユーザの好みなどを含む。一部の項目に対しては、項目の値を単に取得し設定することができるだけで十分であるが、他の項目は、項目の値が変わったとき、特定のスレッドが通知を受けることを要求する。

歴史的に、オペレーティング・システムのカーネルは、管理されるデータへのアクセス権を必要としたが、比較的最近のオペレーティング・システムにとっては、この要件はもはや主流ではない。カーネルがデータ内容を知ることを強く要求する一般的なソリューションが、現在は好ましいと考えられている。さらに、このような状態を、特定のシステム・ファイルを使って格納する、より高いレベルのシステム・ソフトウェアが提案されているが、このソフトウェアは、安全なオペレーティング・システム・プラットフォームという状況では、もはや望ましいとは考えられておらず、代替ソリューションが極めて望ましいと考えられている。

コンピュータ装置上で実行されるあるアプリケーションが、その装置上で実行される別のアプリケーションと、「発行および引用」として知られる機構を用いて直接通信することも可能である。この公知の発行および引用機構を用いると、第１のアプリケーション（発行元）がプロパティを確立し、第２のアプリケーション（引用先）が、第１のアプリケーションによって確立されたそのプロパティに登録することができるようになる。発行元は次いで、そのプロパティ用に新規の値を発行し、特定の引用先は、そのプロパティが変更されたことを通知される。引用先は次いで、そのプロパティ用の新規の値を取得することができる。この公知の発行および引用機構は、分散型システムから派生し、ミドルウェアとして実現され、あるアプリケーションが発行を行い、別のアプリケーションが引用を行い、この２つのアプリケーションの間のすべての通信は、オペレーティング・システムのカーネルの外側であるユーザ側で実行される。したがって、２つのアプリケーションの間に、具体的なクライアント／サーバ関係を確立する必要がない。しかしながら、通信は、２つのアプリケーションの間に限られる。

したがって、本発明の目的は、コンピュータ装置におけるプロセス間通信を可能にする改良型の発行および引用機構、詳細には、より効率的に、リアルタイムで、かつセキュリティが強化されて実現される発行および引用の技術を提供することである。

本発明の第１の態様によると、第１のプロセス中で発行されたプロパティを取得し、該プロパティへの登録をリクエストしている他の１以上のプロセスに、前記取得されたプロパティを通知するように、コンピュータ装置用のオペレーティング・システムのカーネル部分を構成する工程を備えることを特徴とするコンピュータ装置の制御方法が提供される。

本発明の第２の態様によると、第１の態様の方法に従って動作するように構成されたコンピュータ装置が提供される。

本発明の第３の態様によると、第２の態様によるコンピュータ装置を、第１の態様の方法に従って動作させるオペレーティング・システムが提供される。

ここで、本発明の実施形態を、例示としてのみ説明する。

本発明の方法は、本明細書において「Ｐ＆Ｓ（Publish and Subscribe）」と呼ばれ、システム全体の「グローバル変数」を格納するための手段、およびコンピュータ装置用のオペレーティング・システムにおけるスレッドの間のピア・ツー・ピア通信のための新しいプロセス間通信（ＩＰＣ）機構の両方を提供する。本発明の以下の例を、Ｓｙｍｂｉａｎ ＯＳ（商標）オペレーティング・システムを具体的に参照して説明するが、本発明を用いることで、他の形態のコンピュータ装置用オペレーティング・システムにおいても同等の利点がもたらされることを理解されたい。

本発明の以下の実施形態では、Ｐ＆Ｓ機構に対する３つの基本構成要素がある。
・プロパティ：プロパティとは、単一のデータ値、すなわち整数キーによって識別される単一の変数である。
・発行元：プロパティをアップデートするスレッド。
・引用先：プロパティに対する変更を聴取（listen）するスレッド。

プロパティに対して実施することができる６つの基本動作がある。
・定義：プロパティ変数を作成し、そのタイプおよびアクセス制御を定義する。
・消去：システムからプロパティを削除する。
・発行：プロパティの値を変更する。
・取得：プロパティの現在の値を入手する。
・登録：プロパティに対する変更の通知に登記する。
・登録中止：変更の通知を解除する。

本発明において、Ｐ＆Ｓは、ユーザおよびカーネル・プログラム両方によって、同様のＡＰＩを介して使うことができるカーネルＡＰＩとして提供され、したがって、ユーザとカーネル・コードの間の非同期通信機構を提供することもできる。

上で概説したように、１以上の専用ファイルを使用することは、状態情報を格納するために現在好んで用いられているソリューションである。各アプリケーション用の状態情報を格納するために、別個のファイルを使ってもよく、或いは、すべてのアプリケーション用の状態情報を格納するために、一つのグローバル・システム・ファイルを使ってもよい。ただし、別個のファイルが使われる場合、ファイルの激増により、コードが重複し、必要なすべてのファイルを識別するのが、ますます困難になる。グローバル・システム・ファイルが使われる場合、グローバル設定アプリケーションを実用化するのが、非常に難しくなる。すべてのアプリケーション用の状態情報に対してグローバル・システム・ファイルを使用することは、具体的には、特に装置起動時の、装置性能のボトルネックと認識されている。これは、ファイル自体が、装置動作のこの初期期間中に激しい競合にさらされる資源であるからであり、また、アクセス権を要求するすべてのクライアントがファイルへの読取り／書込みロックを取得し、かつ、ファイル・システムがスレッドの間で情報を共有するように、手配するＡＰＩをもそのファイルが有するからである。

このようなグローバル・システム・ファイルを使用して装置の性能を向上するために、いくつかの対策が提案されている。例えば、通信能力を含むスマート・フォン用のＳｙｍｂｉａｎ ＯＳ（商標）オペレーティング・システムでは、比較的大量のデッドロック防止コードが、いくつかの機能を動作しやすくするために、オペレーティング・システムの通信コード中で与えられる。しかし、通信コード中に含まれるデッドロック・ルーチンは、システムの統合およびテストまで明らかにならないことが多い、わずかなコードの矛盾を引き起こす可能性があり、開発上の問題を引き起こす。さらに、より多くの通信プロトコルが装置に追加されるのに従って、オペレーティング・システム全体は、ますますテストしにくくなる。さらに、デッドロック防止コードも、オペレーティング・システム内のダイナミック・リンク・ライブラリ（ＤＬＬ）の数の増加につながり、ＤＬＬはそれぞれ、それに関連付けられたＲＯＭ空間を有し、したがって装置資源を要求する。

非同期または２方向のメッセージ通信が必要とされる場合は、クライアント／サーバ・リンクの逆転が用いられている。しかし、この機能性をサポートするために提供される通知フレームワークにおいては、通常、すべての通知プロバイダが、専用のＤＬＬ内に配置され、理論的にはそこに組み込まれることが期待される実際のアプリケーションから分離される必要がある。このことは、オペレーティング・システムにおけるＤＬＬの数の一層の増加につながる。ＤＬＬの数のいかなる増加に対する要件も、物理資源が比較的制約されているスマート・フォンにおいては、特に望ましくないとみなすことができる。さらに、非同期メッセージ通信が欠如しているせいで、通知装置が実行中に他のサーバとコンタクトをとることも、より困難になり、同じように、デッドロックにつながり得る。したがって、上記の対策はそれぞれ、オペレーティング・システムにおいてさらに問題を引き起こすと考えることもできる。

コンピュータ装置のオペレーティング・システムにおいて用いられる最も一般的なＩＰＣ機構は、クライアント／サーバ・フレームワークである。この機構は通常、クライアント・プロセスからサーバ・プロセスにいくつかのｎビット量を転送する非同期コールを介して実現される。次いで、より多くのデータを、プロセスのスレッドの間で、適切なＲｅａｄスレッドおよびＷｒｉｔｅスレッド・コールを使って転送することができる。

送信および受信コールを使うためには、クライアントおよびサーバ・スレッドがクライアント／サーバ関係を予め確立しておくことが常に必要である。この関係の確立は、適切な「ＣｒｅａｔｅＳｅｓｓｉｏｎ」コールを使って実現される。この機構は、単純かつ堅牢であることが十分に証明されており、多くの通信要件に適している。しかし、一部のアプリケーションの場合は、こうした特定のコールによってさらに問題が引き起こされている。

ＣｒｅａｔｅＳｅｓｓｉｏｎコールは、スレッドの間のＣａｎｃｅｌコールがそうであるように、同期コールである。したがって、クライアント・スレッドは、ＣｒｅａｔｅＳｅｓｓｉｏｎコールを発行すると、一時的にブロックされ、サーバがこのコールに応答するのを待つ。したがって、サービスのために他方にそれぞれ依存する２つのスレッド、すなわちＡとＢがある場合、両方のスレッドが、他方がそれぞれのリクエストを完了するのを待っているので、デッドロックが生じ得る。このように相互に依存する２つのサーバの例は、実際には比較的まれであるが、デッドロックは、３つ以上のサーバの間でループが形成されるときは、より頻繁に起こる。オペレーティング・システムにおけるクライアントおよびサーバの数が、付加的な装置機能とともに増大するのに従って、新たな依存がデッドロックの可能性をもたらすことがないようにするのは、ますます困難になることが理解されよう。また、このような起こり得るデッドロックをテストすることは非常に困難であり、時間のかかるプロセスであることが理解されよう。

非常駐サーバ用には、ＣｒｅａｔｅＳｅｓｓｉｏｎコールは、通常、このコールにハンドルを付加することによって処理される。そうすることによって、サーバがまだ実行されていない場合、サーバを始動する。ハンドルという用語は、当業者によって容易に理解されるものと考えられるので、本発明においてはこれ以上説明しない。しかし、ハンドルの使用は、クライアント・アプリケーションのコードに合流することになる実行可能ファイルの名称の埋込みを伴う。こうすると、コードを変更せずにリクエストに応える相異なる構成要素を有することができないので、柔軟性のないシステム・アーキテクチャをもたらす。言い換えると、ハンドルを使用して、ＣｒｅａｔｅＳｅｓｓｉｏｎコールは、指定される特定のサーバの名称を要求するので、クライアントは、本質的に、どのサーバがそのリクエストに応えることができるかに関して、固定されている。

ＣｒｅａｔｅＳｅｓｓｉｏｎコールにより、クライアントがその目標サーバへのコールを開始する際、目標サーバが存在しなければならない。しかし、情報のクライアント送信者が、目標サーバからのいかなる応答も要求しない状況、具体的には、目標サーバに送信された情報が実際に受信されたかどうかを知る必要がない状況がある。スマート・フォンの形態のコンピュータ装置においては、バッテリ・レベルおよび通信活動など、特定の状況アップデートが、この情報の例である。したがって、クライアント／サーバ・フレームワークを用いると、クライアントは、実際にはサーバなしで機能することができる場合でも、サーバに依存するよう強制される。この補助的な依存は、オペレーティング・システムの構成要素の間の結合を不必要に増し、システムの柔軟性を低下させ、異なる装置に対してオペレーティング・システムをより形成しにくくする。

したがって、クライアント／サーバ機構は、相互作用に関して、理想とは程遠いとみなすことができ、この機構において、エンティティはクライアント／サーバ関係にあるのではなく、製造元／消費者関係にある。クライアント／サーバ・リンクは相互関係ではあり得ず、オペレーティング・システムには、２つの相互リンクとして、よりうまく扱われるいくつかの通信パスがある。上で概説したように、この欠点を克服することができる公知の一方法は、クライアント／サーバ・リンクを逆に二重にすることによるものである。しかし、この対策は、付随する問題を伴うコードの複雑さの増大につながることが、当業者には理解されよう。

したがって、既存の状態およびイベント・ソリューションに伴う問題の多くは、オペレーティング・システムにおけるクライアント／サーバ・フレームワークへの依拠に関連する。どの通知も状態サービスも、新たなサーバを要求し、サーバは、かなりの資源、すなわちＲＡＭおよびＲＯＭ両方を消費する。オペレーティング・システムのいくつかの既存サーバは、この付加的な機能性を提供するように拡張可能であり得るが、他の既存サーバは拡張可能でなく、代替ソリューションもない。こうしたことはすべて、様々な製造元からの異なるいくつかのスマート・フォンが、一般的なオペレーティング・システムの制御下で実行されることを要求されるときなど、オペレーティング・システムがある範囲のコンピュータ装置の開発に適合されると、資源をさらに複製することになる。

現在、スレッドの間の真に非同期な通知を可能にする機構はまだ提供されていないので、中間サーバを使わなければならない。しかし、こうした中間サーバは、物理資源を消費し、上で詳述した問題をさらに悪化させ得る。

したがって、本発明の提案は、オペレーティング・システムのカーネルにおいて実現される新たな形の発行（publish）および引用（subscribe）機構を提供することである。このようなＰ＆Ｓ機構は、上述した発行および引用機構のすべてに勝る多くの利点を有し、リアルタイム・システムに適しており、これによって、状態情報の項目を設定及び取得することができ、状態が変化したことをリアルタイムで引用先に通知することができる。この機構は、イベント通知のために非常に効率的な機構を提供し、この機構は、コンピュータ装置のオペレーティング・システムにおけるＩＰＣの新規な方法をもたらすことが理解されよう。

本発明のＰ＆Ｓ機構は、以下の重大な利点を有するものと考えられる。
・多くの引用先が、プロパティの変更を監視することができる。
・発行元と引用先の間の循環依存が、デッドロックを引き起こさない。
・引用先が欲していないプロパティ用の値を格納するメモリが浪費されない。

しかし、引用先は、プロパティがとる全部の値を見ることはできず、発行元は、発行された新規の値に引用先がいつ反応するのかということと、反応するのかどうかの少なくともいずれかはわからず、イベントに応答するのが困難である。

したがって、Ｐ＆Ｓは、以下の条件が成り立つとき、特に有利に用いることができる。
・イベントが、システム全体にブロードキャストされる必要がある。
・プロパティの中間値ではなく、最新の値のみが重要と考えられる。
・値を取得するスレッドが、その値の出所を知る必要がない。
・特定の状態またはイベントが、システム内のいくつかの場所で入手可能にされる必要がある。

したがって、Ｐ＆Ｓは、以下の場合には不適切であると考えることができる。
・クライアントが、サーバからのサービスを必要とする。
・クライアントが、そのリクエストへの応答を必要とする。
・クライアントが、「メモリ不足」条件が存在し得る場合でも、リクエストが完了され、場合によってはエラーを起こしたという確認を必要とする。

カーネル実装としてのＰ＆Ｓ ＡＰＩの提供は、以下の付加的な利益ももたらす。
・機構が、ユーザとカーネル・コードの間の通信にも用いられることを可能にする。現在、一部のオペレーティング・システムでは、特定のデバイス・ドライバ・チャネルまたはハードウェア抽象化レイヤ（ＨＡＬ：hardware abstraction layer）機能が、これを遂行する唯一の方法である。
・リアルタイムのタスクが、リアルタイム保証を損なわずにプロパティを確実に発行できるようにすることができる。これは、クライアント／サーバ・ソリューションに対しては可能でない。
・性能に関して、より一層効率的である。サーバ・プロセスとの間のコンテキスト切換えが排除されることにより、おそらく劇的な性能向上をもたらし得る。
・ユーザ・コードが、一定の項目に対して、それ以外の場合にはそのユーザ・コードによる使用が可能でない永続性の能力を利用することを可能にする。

本発明の好適な実装形態では、発行されるプロパティは、２つの３２ビット部からなる６４ビット・キーによって識別される。プロパティ用の名前空間は、好ましくは、一意の識別子（ＵＩＤ：unique identifier）によって識別される「カテゴリ」に分けられる。各カテゴリは、好ましくは、３２ビット「キー」によって識別される個々のプロパティを含む。このキーは、単にカテゴリ用の索引または他の列挙方式でもよく、カテゴリが概して拡張可能であるように設計されている場合は、別のＵＩＤでもよい。

異なるタイプのプロパティを使うことができるとも想定される。例えば、どのプロパティも、単一の３２ビット整数値であるか、または長さが０と５１２バイトの間のバイト配列（記述子）でよい。カテゴリは、整数およびバイト配列プロパティの混合物を含み得る。ただし、プロパティは、タイプを、一度設定されると変更することはできないが、バイト配列プロパティは、異なる長さの新規の値に設定することができる。便宜上、Ｐ＆Ｓ ＡＰＩは、好ましくは、バイト配列プロパティをユニコード・テキストとして設定及び取得する能力を与えられ、この場合、基底の実装は、単にこれらをバイトとして扱う。

バイナリ・プロパティに対する上記の制限は、Ｐ＆Ｓ機構を用いて、システムＡＰＩの一部に対してリアルタイム保証を行わせるので、望ましいものと考えられる。さらに、任意のサイズをもつプロパティがサポートされると、Ｐ＆Ｓ ＡＰＩが不適切に使われる見込みを増すことになり、以下の２つの結論を引き出すことができる。
・プロパティ・セット全体がカーネル・メモリに格納されるので、ＲＡＭの使用が不必要に増し得る。
・永続的プロパティがブート時に復元されるので、ブート時間が劇的に増加し得る。

本発明のＰ＆Ｓ ＡＰＩを用いると、プロパティが変更されたという通知は、「プロパティＸがＹに変更された」という形ではなく、「プロパティＸが変更された」という形である。したがって、プロパティ用の新規の値は、要求された場合、引用先によって、明示的に取得されなければならない。プロパティ用の新規の値は通知の中に含まれないので、プロパティの値の多様な変更は、すべての引用先に、プロパティが想定している全部の中間値を処理させるのではなく、単一の通知に凝縮することができる。このことは、競合状態を回避するのを助ける。というのは、通知リクエストは、現在の値が取得される前にポストし直すことができ、アップデートし損なうことがないように保証するからである。

システム資源の消耗以外は、単一のプロパティへの登録の数に制限を課す必要はない。しかし、登録の数に対する制限が課されない場合、リアルタイム性能に影響を与える可能性があるので、このような制限を課すことが好ましい。

登録の完了順序に関しては、定義されても、あるいは、未定義のままでもよい。順序が定義されない場合、引用先スレッドの優先度順で完了するのではない。

リアルタイム保証を満たすために、資源に対するロックを要求するどのカーネル・アクションも、有限時間のものであるべきである。そうでない場合、無限時間、その資源から他のスレッドをブロックすることができ、期限が守られないことになる。プロパティ値が、自動的に、すなわち分割されない一度の動作として、読み取られ、書き込まれる。これにより、どのプロパティも読み取るスレッドが、不明瞭な値や、混同され得る同時に存在する多様な不明瞭値を、取得することは決してない。ただし、このことは、全部のアップデートまたは取得し動作向けにロックを保持しなければならないことを意味する。したがって、コピーすることができるデータのサイズは、好ましくは、ロックを保持するのに費やされる時間を制限するように限界を定められる。さらに、メモリ割当は、オペレーティング・システムにおいてリアルタイムではないので、可変サイズをもつプロパティが、予め定義されたサイズのメモリ空間に予め割り当てられ、そうすることによって、新規の各値の発行が、それぞれのメモリ割当動作を要求しないことが望ましい。したがって、メモリ割当は、新規のプロパティ値が、予め定義された記憶割当より大きい場合に必要になるだけである。メモリ割当が必要になった場合、発行動作に対するどのリアルタイム保証も無効になる。

登録が、発行スレッドの状況で完了された場合、処理される登録リストのサイズに対する制限がないので、このスレッドを、任意の長さの期間、維持してよい。そうではなく、登録は、（既知の優先順位の）代替カーネル・スレッドを使用して完了することができ、優先順位の高いスレッドに、有限時間中に値を発行させる。オペレーティング・システムのカーネルにおけるスーパーバイザー型スレッド（supervisor type thread）を、この目的のために用いることができる。このタイプのスレッドは、ほとんどのオペレーティング・システム内に存在し、主に、活動のクリーンアップおよびユーザ側のコードへの、非時間制約型イベントの通知の提供を担当する。プロパティへの新規の値の発行は、リアルタイム・サービスであることが特に有利である。というのは、値の発行は、時間制約型スレッドから呼び起こすことができ、例えば、スマート・フォンにおける通信プロトコルは、Ｐ＆Ｓ ＡＰＩを使って、接続が確立されたことを示すことができるからである。しかし、上で概説したように、所与のいずれかのプロパティに対して任意に大きい数の登録がある場合、実行時間は、本質的に無限になり、リアルタイム保証は無効になる。この欠点は、登録を実際に完了させるために、スーパーバイザー・スレッドにおけるキューに入れられた、延期された関数呼出し（ＤＦＣ：deferred function call）を用いることによって解決することができる。延期された関数呼出しの使用は、当業者によく知られていると考えられるので、本発明においては特に説明しない。プロパティの値は、発行元によってアップデートされ、プロパティは、通知が未処理であるプロパティのキューに配置される。キューは次いで、スーパーバイザー・コンテキスト中のＤＦＣによって排出され、引用先が通知を受ける。

プロパティの各カテゴリには、作成時に定義されるセキュリティ・ポリシーを与えることができる。ポリシーは、好ましくは、カテゴリ中のプロパティへの読取りおよび書込みアクセスに対する別個の検査を行わせる。Ｒｅａｄアクセスは、プロパティの取得および登録の両方を含む。各動作は、能力によって、またはセキュリティ識別子（ＳＩＤ：Security Identifier）によって制御されるアクセス権を有し得る。好ましくは、プロパティは、プロパティを作成したアプリケーションによってのみ、オペレーティング・システムから削除することができるように構成されるべきである。この特徴は、ＳＩＤによって制御することもできる。

発行（Publish）＆引用（Subscribe）は、カテゴリおよびプロパティ定義のみが、発行元と引用先の間で共有されることを要求する。ただし、発行元が、引用先を格納するコンピュータ装置に存在さえしないこともあり得るが、引用先は、依然として正しく動作するべきであり、さらに、こうした環境では、悪意のあるコードが発行元として変装できないようにすることが重要である。したがって、その引用先による、特定のプロパティを取得しようとする試みが、その特定のプロパティが発行されたことがないという応答に遭ったときでも、また、存在しないプロパティへの登録が有効であり、プロパティが初めて発行されたときに期待通り完了したときも、どの引用先も正しく動作するべきである。

悪意のあるコードの問題に関しては、プロパティは、作成され、または定義されるまで、発行することはできない。したがって、この問題は、あるプロパティが定義されたとき、そのプロパティに対するアクセス制御を設定し、そのプロパティに対してそれ以降はアクセス制御を変更できないようにすることによって、システムが定義したカテゴリ（例えば、場所に基づくデータ）に関して解決することができる。ただし、許可されたコードのみがプロパティを発行できることをさらに確実にするために、以下の２つの追加的な保護手段も採用することができる。
・プロパティは、オペレーティング・システムのブート中に、無許可のコードが実行される前に定義される。このことは、そのプロパティを発行する適度に厳しいポリシーが確実に定義されるようにする。
・プロパティは、システム・データ書込み能力を有するプロセスによって、ただカテゴリ中でプロパティを定義させる予約済みのカテゴリに分類される。

これまでに述べたＰ＆Ｓ ＡＰＩは、永続性を含まない。すなわち、すべてのプロパティは非常駐値である。しかし、プロパティへの「永続性」の属性の追加によりＰ＆Ｓ ＡＰＩを拡張し、特別な「永続性」のＡＰＩを提供することによって、プロパティ値の永続性を与えることができる。オペレーティング・システムにおける信頼されるスレッドはしたがって、変更されたプロパティの取得および、例えばファイルへの格納、ならびに格納されたプロパティの、ブート中の復元も担当するようにすることができる。このような機構は、システム構成要素に対して、安全な、リアルタイムのグローバル状態をもたらす。永続性の特徴の無制限な悪用を防止するために、プロパティの格納を、システム・ソフトウェアに関するものにのみ限定することが好ましい。

上記のようにして与えられる永続性は、同期永続性、すなわち、新規のプロパティ値が、実行を継続する前に記憶装置に書き込まれたという保証は与えない。この特徴は、要求される場合、どのプロパティに対する変更も、発行されて間もなく、永続的な記憶装置に確実に向けられるようにすることによって与えられる。こうすることにより、プロパティ変更をセーブする効率的なソリューションが提供される。ただし、格納されるデータの重要性により、用いられる格納アルゴリズムが、プロパティをアップデートする途中の不具合に対して十分に堅牢であることが、保証されることが非常に好ましい。

オペレーティング・システムの通常のシャットダウンの一部として、Ｐ＆Ｓ ＡＰＩは、プロパティ変更が紛失されることがないようにするために、未処理の変更を記憶装置にコミットするように構成される。しかし、突然の予期せぬ電源故障の場合、どのプロパティ中のすべての変更も確実に保存されるようにすることが、常に可能なわけではない。しかし、このことは、このような「実」プロパティが、電源故障の際にオペレーティング・システム内の他のコミットしていない実データとまったく違わないので、問題があるとは考えられない。

メッセージ・キュー機構は、Ｐ＆Ｓ ＡＰＩの一部としても提供することができる。この提供の仕方は、ピア・ツー・ピア通信に関する今日の多くの傾向に特に適していると考えられる。この機構を提供すると、Ｐ＆Ｓ機構は、発行元が、登録しているいずれかのパーティ（当事者）が聴取しているかどうかを知る必要なく、メッセージを、登録している数人のパーティに送信することを可能にすることができる。発行元は、登録しているどの受信者の識別も、実際に知る必要もない。

Ｐ＆Ｓ機構のこの特徴の基本構成要素は、メッセージおよびメッセージ・キューである。メッセージは、受信者への配信用のキューに配置された構造とみなすことができる。各メッセージ・キューは、キューが管理するメッセージのサイズを定義し、このサイズは通常、オペレーティング・システムによって制限される。単一のキューは、多くのメッセージ・リーダ（引用先）とメッセージ・ライタ（発行元）の間で共有することができる。メッセージは、関連付けられた優先順位を有し、より優先順位の高いメッセージが通常、より優先順位の低いメッセージの前に配送される。すなわち、事実上、キューの中のより優先順位の低いメッセージに勝る。本発明のＰ＆Ｓ機構において、メッセージ・キューは、ハンドルを付加することができる通常のカーネル・オブジェクトとして提供することができる。このようにして、メッセージ・キュー「オブジェクト」は、キューの中のメッセージのリーダおよびライタ両方によってオープンすることができる。

メッセージおよびメッセージ・キューは、キューに対する最後のハンドルがクローズされた後は持続しないという点で、永続的ではない。したがって、この機構は、いくつかの既存オペレーティング・システムにおいて実装されるメールボックスまたはメッセージ引渡し機構と同様であるとみなすことができる。したがって、本発明によるＰ＆Ｓ ＡＰＩの提供、および特定のオペレーティング・システムへのこのようなメッセージ・キュー機構の組込みは、メールボックスおよびメッセージ引渡し機構を有するオペレーティング・システムから、その特定のオペレーティング・システムへのコードの移植を容易にすることができるという点で、さらに有益である。

メッセージ・キュー機構を有するこのようなＰ＆Ｓ ＡＰＩによってサポートされる必要がある５つの基本動作がある。
・メッセージ・キューの作成／オープン
・メッセージの送信
・メッセージの受信
・キューの中の空間を待つ
・キューの中のデータを待つ
メッセージ・キューの中のメッセージを読み取り、または書き込むのに、以下のコールを使うことができる。

「Ｗｒｉｔｅ」関数呼出しは、指定された優先順位をもたせて、キューの中にメッセージを配置するのに使うことができる。この呼出しが起こるには、キューが予めオープンされていなければならない。キューが満杯の場合、キューがオープンするのを待つのではなく、ＫＥｒｒＯｖｅｒｆｌｏｗなど、適切なエラー・オーバーフロー・リクエストを戻すことができる。発信者は次いで、エラー・オーバーフロー・リクエストの遮断が要求される場合、「Ｗａｉｔ Ｆｏｒ Ｓｐａｃｅ」コールを使うことができる。メッセージは次いで、空間が使用可能になると直ちに、メッセージ・キューの中に配置される。

「Ｒｅａｄ」関数呼出しは、キューにある最も優先順位の高いメッセージを取得するのに使うことができる。このコールが効力をもつ前に、スレッドはメッセージ・キューをオープンしていなければならない。キューにメッセージがない場合、キューの中にメッセージが現れるのを待つのではなく、ＫＥｒｒＵｎｄｅｒｆｌｏｗなど、アンダーフロー・エラー・リクエストを戻すことができる。発信者は次いで、アンダーフロー・エラー・リクエストの遮断が要求される場合、「Ｗａｉｔ Ｆｏｒ Ｄａｔａ」コールを使うことができ、この場合、メッセージ・キューの中にメッセージが現れると直ちに、Ｒｅａｄコールを起こしたパーティに、メッセージが通知される。メッセージ・キューにある同じ優先順位のメッセージは、先入れ先出し（ＦＩＦＯ）順序で配送することができる。

「Ｏｐｅｎ」関数呼出しは、指定されたキューにあるどのメッセージへの関心も登記するのに使うことができる。キューは、存在しない場合は作成されるので、このコールは、ＫＥｒｒＮｏＭｅｍｏｒｙなどのメモリ・リクエストが戻されずに失敗する可能性がある。このＯｐｅｎコールは、ＲｅａｄまたはＷｒｉｔｅコールを使う前に使われなければならない。キューは、名称で識別することができ、このコールは、各メッセージのサイズおよび空間を提供するメッセージの数を指定することもできる。

「Ｗａｉｔ ｆｏｒ Ｓｐａｃｅ」コールも使うことができる。このタイプのコールは、キューの中に、使用可能な、指定された量の空間（ｎ個のメッセージ・スロット）があるときに完了する非同期リクエストである。ただし、一度に単一のスレッドのみがこの特定の特徴を利用することができるように構成されるべきである。別のスレッドが現在、空間を待っていると、Ｐ＆Ｓ ＡＰＩを混乱させる可能性がある。

「Ｗａｉｔ Ｆｏｒ Ｄａｔａ」コールも使うこともできる。このコールも、キューの中に、使用可能な、指定された量のメッセージがあるときに完了する非同期リクエストである。「Ｗａｉｔ Ｆｏｒ Ｓｐａｃｅ」コールと同様に、一度に単一のスレッドのみがこの特徴を利用することができる。別のスレッドが現在、データを待っていると、やはり、Ｐ＆Ｓ ＡＰＩを混乱させる可能性がある。

「Ｃｌｏｓｅ」コールは、メッセージ・キューへのハンドルをクローズするのに使うことができる。このコールが使われるときにキューへのオープン・ハンドルがない場合、キューおよびどの未処理のメッセージも消去される。

本発明によるＰ＆Ｓ ＡＰＩは、オペレーティング・システムにおいて、既存のＩＰＣ機構を用いて、ユーザ側のサーバとして実装することができるであろうが、カーネル実装が、以下の付加的な利益をもたらすと考えられる。
・Ｐ＆Ｓ機能が、クライアント／サーバＩＰＣを有する真のピアであることを保証し、別のプロセスと通信する同様の性能を提供することができる。
・リアルタイムのタスクが、リアルタイム保証を損なわずに、メッセージ・キューを使うことができることを保証する。このことは、メッセージ・キュー用の、現在のクライアント／サーバに基づくソリューションには当てはまらない。

好ましくは、最大メッセージ・サイズが制限される。最大メッセージ・サイズを制限することによって、はるかに単純なロック機構を、メッセージ・キュー用に使うことができる。さらに、具体的には、メッセージ・サイズを３６バイトに制限すると、非常に速い実装が可能になることがわかっている。すなわち、メッセージの内容は、ユーザ／カーネル境界を越えて手作業でコピーする必要がなく、レジスタで渡すことができる。メッセージ・キュー自体のサイズは、「Ｏｐｅｎ」するための第１のコールによって確定することができ、このコールが、メッセージ・サイズおよびカウントを設定する。それ以降に、メッセージ・キューに対してさらに空間が割り当てられる場合、それ以外の場合に行うことができるどのリアルタイム保証も無効化する傾向がある。

メッセージ優先順位を与えることができ、通常、こうした順序は、０と７の範囲内に収めることができる。この範囲の優先順位のサポートは、優先順位を利用しないキューの場合であっても、装置のＲＡＭ資源に対してあまり負担にならず、それにも関わらず、メッセージ・キューの中でメッセージを配列するのに十分な数の優先レベルを与えると考えられる。

標準カーネル資源用に利用可能なもの以外のセキュリティはサポートされない。したがって、オブジェクトは安全ではなく、グローバルにアクセス可能であり、あるプロセスに対してプライベートであり、または、匿名であるが既存ハンドル所有者によるアクセスを認めさせる場合がある。

要約すると、本発明は、オペレーティング・システムのカーネルにおいて、リアルタイムのシステムに適したやり方で実装される発行および引用機構を提供する。したがって、この機構は、ユーザとカーネル・コードの間の通信用に機構が用いられることを可能にし、したがって、今まで用いられてきたクライアント／サーバ・アーキテクチャに関連づけられた問題に対する解決策を提供する。この機構は、リアルタイムのタスクが、リアルタイム保証を損なわずに、確実にプロパティを発行できるようにすることもできる。このことは、どのクライアント／サーバ・ソリューションにも当てはまらない。さらに、サーバ・プロセスとの間のコンテキスト切換えが排除されるので、この機構は、全体的なオペレーティング・システム性能に関して、はるかにより効率的である。

本発明を、特定の実施形態を参照して説明したが、添付の特許請求の範囲によって定義される本発明の範囲内で修正可能であることが理解されよう。

Claims (33)

1. オペレーティング・システムのカーネル・コードにより制御される、コンピュータの動作方法であって、
   第１のプロセス中で発行されたプロパティを取得することと；
   前記プロパティへの登録をリクエストしている１つ以上の他のプロセスに、前記プロパティに変更があったことを通知することと；
   前記１つ以上の他のプロセスの要求に応じて前記取得したプロパティを供給することと；
   を含み、ただし前記供給することは、前記取得したプロパティを、プロパティ名前空間を備える第１の部分と、プロパティ・タイプを備える第２の部分とを含む形式で供給することを含み、前記プロパティ・タイプは、前記プロパティが作成されるときに定義されるアクセス制御ポリシーを与えられ、前記アクセス制御ポリシーは、前記オペレーティング・システムのブート中に定義される、方法。
2. 前記第１のプロセスおよび前記他のプロセスはユーザーモードのプロセスである、請求項１に記載の方法。
3. 前記取得したプロパティを、カーネル・オブジェクトであるメッセージ・キューに格納し、前記メッセージ・キューを介して前記プロパティを前記他のプロセスに供給することを含む、請求項１または２に記載の方法。
4. 前記プロパティ名前空間はカテゴリ部およびキー部を備える、請求項１から３のいずれかに記載の方法。
5. 前記カテゴリ部は一意の識別子（ＵＩＤ）を備える、請求項４に記載の方法。
6. 前記キー部はＵＩＤを備える、請求項４又は５に記載の方法。
7. 前記プロパティ名前空間は、２つの３２ビット部からなる６４ビット整数を備える、請求項４から６のいずれか１項に記載の方法。
8. 前記プロパティ・タイプは、整数値とバイト配列記述子との少なくともいずれかを備える、請求項３から７のいずれか１項に記載の方法。
9. 前記バイト配列記述子は可変長である、請求項８に記載の方法。
10. 前記バイト配列記述子の長さは０から５１２バイトの間である、請求項８または９に記載の方法。
11. 前記バイト配列記述子はユニコード・テキストの形で与えられる、請求項８から１０のいずれか１項に記載の方法。
12. 前記アクセス制御ポリシーは、前記プロパティが作成された後に変更することができない、請求項１から１１のいずれかに記載の方法。
13. 前記アクセス制御ポリシーは、前記プロパティを、そのカテゴリ中においては、プロパティが、システム・データ書き込み能力を有するプロセスによって定義されることのみを許可する予約済みのカテゴリに分類する、請求項１から１２のいずれか１項に記載の方法。
14. 前記カーネル・コードは、前記プロパティに登録する更なるプロセスの数を制限するように前記コンピュータを制御する、請求項１から１３のいずれか１項に記載の方法。
15. 前記カーネル・コードは、前記プロパティが前記他の１以上のプロセスに通知される順序を定義するように前記コンピュータを制御する、請求項１から１４のいずれか１項に記載の方法。
16. 前記カーネル・コードは、
    前記取得されたプロパティを、前記取得されたプロパティのサイズに決められていない、予め定義されたサイズを有する、前記コンピュータのメモリ空間に書き込むように前記コンピュータを制御する、請求項１から１５のいずれか１項に記載の方法。
17. 前記カーネル・コードは、
    前記取得されたプロパティが、予め定義されたサイズの前記メモリ空間に収まらない場合のみ、前記取得されたプロパティの書込み用にさらにメモリ空間を割り当てるように前記コンピュータを制御する、請求項１３に記載の方法。
18. 前記プロパティは、前記プロパティを作成したプロセスによってのみ、前記オペレーティング・システムから削除されることが可能であるように構成される、請求項１から１７のいずれか１項に記載の方法。
19. 前記オペレーティング・システムからのプロパティの除去は、セキュリティ識別子（ＳＩＤ）によって制御される、請求項１８に記載の方法。
20. 前記プロパティの取得と登録との少なくともいずれかは、セキュリティ識別子（ＳＩＤ）によって制御される、請求項１から１９のいずれか１項に記載の方法。
21. 前記プロパティは永続性の属性を与えられる、請求項１から２０のいずれか１項に記載の方法。
22. 前記カーネル・コードは、前記取得したプロパティを、永続的な記憶装置の中へ向けるように前記コンピュータを制御する、請求項２１に記載の方法。
23. 前記カーネル・コードは、前記プロパティに対する未処理の変更をオペレーティング・システムのシャットダウン中に記憶装置に保存するように前記コンピュータを制御する、請求項１から２２のいずれか１項に記載の方法。
24. 前記メッセージ・キューは、メッセージ・キュー・オブジェクトが、前記メッセージ・キューの中のメッセージの、リーダとライタとの少なくともいずれかによってオープンされることを可能にするハンドルを与えられる、請求項３に記載の方法。
25. 前記カーネル・コードは、前記メッセージ・キューの中に配置することができるメッセージの最大サイズを制限するように前記コンピュータを制御する、
    請求項３または２４に記載の方法。
26. 前記最大サイズが３６バイトである、請求項２５に記載の方法。
27. 前記メッセージ・キューのサイズは、前記メッセージ・キューをオープンするための第１のコールによって確定される、請求項３または２４から２６のいずれか１項に記載の方法。
28. 前記メッセージ・キューの中に配置されたメッセージは、前記メッセージ・キューの中にメッセージを並べる優先レベルを与えられる、請求項３または２４から２７のいずれか１項に記載の方法。
29. 前記メッセージ・キューの中に並べられたメッセージに、７つの優先レベルが与えられる、請求項２８に記載の方法。
30. 同じ優先レベルを有する、メッセージ・キューの中のメッセージは、前記メッセージ・キューから、先入れ先出しに基づいて配送される、請求項２８または２９に記載の方法。
31. 前記メッセージ・キューにあるメッセージを取得するためのリクエストが前記他のプロセスから受信されたときにメッセージ・キューにメッセージが存在しない場合、前記メッセージ・キューに現れるメッセージが、前記他のプロセスからのそれ以上のコールを必要とせずに、そのパーティに通知されることを可能にする、データ待ち機構が与えられる、請求項３又は２４から３０のいずれか１項に記載の方法。
32. コンピュータであって、前記コンピュータを請求項１から３１のいずれか１項で定義される方法に従って動作させるように構成されたプログラムを備える、コンピュータ。
33. コンピュータを、請求項１から３１のいずれか１項で定義される方法に従って動作させるように構成されるコードを備える、オペレーティング・システム。