第 8 章 実時間プログラミングと管理
この章では、SunOS 5.0 から 5.8 で実行する実時間アプリケーションの書き方と移植方法について説明します。この章は、実時間アプリケーションを書いた経験があるプログラマと、実時間処理と Solaris システムに詳しい管理者向けに書かれています。
実時間アプリケーションの基本的な規則
実時間応答は、一定の条件を満たした場合に保証されます。この節ではその条件を明らかにし、問題を生じたりシステムを無効にしたりしてしまう重大な設計上のエラーをいくつか説明します。
ここでは、システムの応答時間を遅くさせる可能性のある問題を取り上げます。その中にはワークステーションをハングさせてしまうものもあります。それほど重大ではないエラーとしては、優先順位の反転やシステムの過負荷 (処理が多すぎる) などがあります。
Solaris の実時間プロセスには、次のような特色があります。
-
「スケジューリング」で説明しているように、実時間スケジューリングクラスで動作します。
-
「メモリロッキング」で説明しているように、プロセスのアドレス空間内のすべてのメモリをロッキングします。
-
「共用ライブラリ」で説明しているように、静的にリンクされたプログラム、または動的結合が前もって完了しているプログラムから生じます。
この章では、実時間操作を単一スレッドのプロセスとして説明しますが、説明の内容はマルチスレッドプロセスにも当てはまります (マルチスレッドプロセスの詳細は、『マルチスレッドのプログラミング』を参照してください)。スレッドの実時間スケジューリングを保証するには、結合スレッドとして扱われなければならず、スレッドの LWP が実時間スケジューリングクラスで実行されなければなりません。メモリのロッキングと初期の動的結合は、プロセス内のすべてのスレッドについて有効です。
プロセスが最も高い優先順位を持つ場合は、次のようになります。
-
実行可能になると保証されているディスパッチ中の潜在的な時間期間の間、プロセッサを得る (「ディスパッチ中の潜在的な時間」を参照)
-
最も優先順位が高い実行可能なプロセスである限り、実行を継続する
実時間プロセスは、システム上の他のイベントのために、プロセッサの制御を失ったり、プロセッサの制御を得られなかったりすることがあります。そのようなイベントの例としては、外部イベント (割り込みなど)、資源不足、外部イベント待ち (同期入出力)、より高い優先順位のプロセスによる横取りなどがあります。
実時間スケジューリングは通常、open(2) や close(2) など、システムの初期化と終了を行うサービスには適用されません。
応答時間の低速化
この節で説明する問題は程度は異なりますが、どれもシステムの応答時間を遅くさせます。遅れが大きいと、アプリケーションがクリティカルデッドラインを逃してしまうことがあります。
実時間処理は、システム上で実時間アプリケーションを実行している他の有効なアプリケーションの操作に対しても大きな影響を及ぼします。実時間プロセスの優先順位は高いので、タイムシェアリングプロセスはかなりの時間、実行を妨げられます。表示に対してキーボードで応答するなどの対話型操作は著しく遅くなります。
システムの応答時間
SunOS 5.0 から 5.8 のシステムの応答が、入出力イベントのタイミングを制限することはありません。これは、実行がタイムクリティカルなプログラムセグメントには、同期入出力呼び出しを入れてはいけないということです。時間制限が非常に長いプログラムセグメントでも、同期入出力を行わないでください。たとえば、大量の記憶領域の入出力の際に読み取りや書き込み操作を行うと、その間システムはハングしてしまいます。
よくあるアプリケーションの誤りは、入出力を実行してエラーメッセージのテキストをディスクから取得することです。この処理は、独立した実時間ではないプロセスまたはスレッドから実行しなければなりません。
割り込みサービス
割り込みの優先順位は、プロセスの優先順位に左右されません。プロセスの優先順位を設定しても、プロセスの動作によって生じるハードウェア割り込みの優先順位は設定されません。つまり、実時間プロセスによって制御されるデバイスについての割り込み処理は、必ずしもタイムシェアリングプロセスによって制御される他のデバイスについての割り込み処理よりも前に実行されるとは限りません。
共用ライブラリ
タイムシェアリングプロセスでは、動的にリンクされる共用ライブラリを使用すると、メモリ量をかなり節約できます。このようなタイプのリンクは、ファイルマッピングの形で実装されます。動的にリンクされたライブラリルーチンは、暗黙の読み取りを行います。
実時間プログラムでは、プログラムを起動する際に、環境変数 LD_BIND_NOW を非 NULL に設定すると、共用ライブラリを使用しても動的結合が行われないようにできます。このようにすると、プログラムの実行前に動的結合が実行されます。詳細は、『リンカーとライブラリ』を参照してください。
優先順位の反転
実時間プロセスが必要とする資源を、タイムシェアリングプロセスが取得すると、実時間プロセスをブロッキングできます。優先順位の反転とは、優先順位の高いプロセスが優先順位の低いプロセスによってブロッキングされる際に生じる状態です。「ブロッキング」とは、あるプロセスが、1 つまたは複数のプロセスが資源の制御を手放すのを待っている状態を指します。このブロッキングが長引くと、たとえ低レベル資源についてでも、デッドラインを逃してしまうことがあります。
図 8-1 の場合を例にとると、優先順位の低いプロセスが共用資源を保持しているために、その共用資源を使用したい優先順位の高いプロセスがブロッキングされています。この優先順位の低いプロセスは、中間の優先順位を持つプロセスによって横取りされます。この状態は長く続く場合があり、実際には優先順位の高いプロセスが資源を待たなければならない時間は、優先順位の低いプロセスによって危険領域が実行されている継続時間だけではなく、中間のプロセスがブロッキングされるまでの時間によって決まるので、どれだけ長く続くかわかりません。中間のプロセスは、いくつ関与していてもかまいません。
図 8-1 制限されない優先順位の反転
この問題とその対処方法については、『マルチスレッドのプログラミング』の「相互排他ロック属性」の節で説明しています。
スティッキロッキング
ページは、ロッキングカウントが 65535 (0xFFFF) に達すると、メモリ内に永久にロッキングされます。0xFFFF の値は実装時に定義されており、将来のリリースで変更される可能性があります。このようにしてロッキングされたページのロッキングは解除できません。
ランナウェイ実時間プロセス
ランナウェイ実時間プロセスは、システムを停止させたり、システムが停止したように見えるほどシステムの応答を遅くしたりすることがあります。
注 -
SPARCTM システム上にランナウェイプロセスがある場合は、Stop-A キーを押します。この手順を何回も繰り返さなければならない場合があります。この手順がうまく機能しない場合や SPARC 以外のシステムの場合は、電源を切ってからしばらく待ち、もう一度電源を入れてください。
優先順位の高い実時間プロセスが CPU の制御を手放さない場合、無限ループを強制的に終了させなければ、システムの制御は得られません。このようなランナウェイプロセスは、Control-C キーを入力しても応答しません。ランナウェイプロセスよりも高い優先順に設定されているシェルを使用しようとしても失敗します。
入出力の特性
非同期入出力
非同期入出力操作がカーネルへの待ち行列に入った順序で行われるという保証はありません。また、非同期操作が実行された順序で呼び出し側に戻されるという保証もありません。
aioread(3AIO) 呼び出しの高速シーケンスのために単一のバッファが指定されている場合、最初の呼び出しが行われてから最後の結果が呼び出し側にシグナルとして送信されるまでの間のバッファの状態については、保証されていません。
1 つの aio_result_t 構造体は、一度に 1 つの非同期読み取りまたは書き込みだけに使用してください。
実時間ファイル
SunOS 5.0 から 5.8 には、ファイルを確実に物理的に連続して割り当てる機能は用意されていません。
通常のファイルについては、read(2) と write(2) の操作は常にバッファリングされます。アプリケーションは mmap(2) と msync(3C) を使用して、二次記憶領域とプロセスメモリ間の入出力転送を直接実行できます。
スケジューリング
実時間スケジューリング制約は、データ取得やプロセス制御ハードウェアの管理のために必要です。実時間環境では、プロセスが制限された時間内で外部イベントに反応する必要があります。この制約は、処理する資源をタイムシェアリングプロセスのセットに「公平に」分配するように設計されているカーネルの能力を超えることがあります。
この節では、SunOS 5.0 から 5.8 の実時間スケジューラ、その優先順位待ち行列、およびスケジューリングを制御するシステムコールとユーティリティの使用方法について説明します。
ディスパッチ中の潜在的な時間
実時間アプリケーションをスケジューリングする際に最も重要な要素は、実時間スケジューリングクラスを用意することです。標準のタイムシェアリングのスケジューリングクラスは、どのプロセスも平等に扱って優先順位の概念に制限があるので、実時間アプリケーションには適しません。実時間アプリケーションでは、プロセスの優先順位が絶対的なものとして受け取られ、アプリケーションの明示的な操作によってしか変更されないスケジューリングクラスが必要です。
ディスパッチ中の潜在的な時間とは、プロセスの操作開始の要求にシステムが応答するのにかかる時間を指します。アプリケーションの優先順位を尊重するように特別に作成されたスケジューラを使用すると、ディスパッチ中の潜在的な時間を制限した実時間アプリケーションを開発できます。
図 8-2 に、アプリケーションが外部イベントの要求に応答するのにかかる時間を示します。
図 8-2 アプリケーションの応答時間
全体的なアプリケーションの応答時間には、割り込み応答時間、ディスパッチ中の潜在的な時間、およびアプリケーションが応答を決定するのにかかる時間が含まれます。
アプリケーションの割り込み応答時間には、システムの割り込み中の潜在的な時間とデバイスドライバの割り込み処理時間が含まれます。割り込み中の潜在的な時間は、システムが割り込みを無効にして実行しなければならない最長の間隔によって決まります。これは SunOS 5.0 から 5.8 では、プロセッサの割り込みレベルの上昇を通常は要求しない同期プリミティブを使用して最小化されています。
割り込み処理中は、ドライバの割り込みルーチンが優先順位の高いプロセスを呼び起こして終了すると戻ります。システムでは、割り込まれたプロセスよりも高い優先順位を持つプロセスが現在ディスパッチ可能であることが検知され、そのプロセスをディスパッチするように指定されます。優先順位の低いプロセスから高いプロセスへコンテキストスイッチングする時間は、ディスパッチ中の潜在的な時間に含まれます。
図 8-3 に、システムが外部イベントに応答するのにかかる時間として定義された、システムの内部ディスパッチ中の潜在的な時間とアプリケーションの応答時間を示します。内部イベントのディスパッチ中の潜在的な時間は、あるプロセスがより高い優先順位のプロセスを呼び起こし、システムでそのプロセスがディスパッチされるのにかかる時間を表します。
アプリケーションの応答時間は、ドライバがより高い優先順位のプロセスを呼び起こし、優先順位の低いプロセスに資源を解放させ、より高い優先順位のタスクを再スケジュールして応答を計算し、タスクをディスパッチするのにかかる合計時間です。
注 -
ディスパッチ中の潜在的な時間のインタバル間に割り込みが入って処理されることがあります。この処理でアプリケーションの応答時間は増えますが、ディスパッチ中の潜在的な時間の測定には影響を与えないので、ディスパッチ中の潜在的な時間の保証によって制限されることはありません。
図 8-3 内部ディスパッチ中の潜在的な時間
実時間 SunOS 5.0 から 5.8 で用意されている新しいスケジューリング手法によって、システムのディスパッチ中の潜在的な時間は指定された範囲内になります。下の表に示すように、ディスパッチ中の潜在的な時間はプロセス数を制限すると改善されます。
表 8-1 SunOS 5.0 から 5.8 の実時間システムのディスパッチ中の潜在的な時間| ワークステーション | 制限されたプロセス数 | 任意のプロセス数 |
|---|---|---|
| SPARCstationTM 2 | 有効なプロセスが 16 個未満の場合は、システム内で 0.5 ミリ秒未満 | 1.0 ミリ秒 |
| SPARCstation 5 | 0.3 ミリ秒 | 0.3 ミリ秒 |
| UltraTM 1-1677 | 0.15 ミリ秒未満 | 0.15 ミリ秒未満 |
ディスパッチ中の潜在的な時間の検査と、製造業務やデータ収集業務などのクリティカルな環境での経験によって、Sun ワークステーションは実時間アプリケーション開発のための有効なプラットフォームであることが証明されています。(ただし上記の例は、最新製品によるものではありませんのでご了承ください)。
スケジューリングクラス
SunOS 5.0 から 5.8 のカーネルは、プロセスを優先順位によってディスパッチします。スケジューラ (またはディスパッチャ) は、スケジューリングクラスの概念をサポートしています。クラスは、実時間 (RT)、システム (sys)、またはタイムシェアリング (TS) として定義されます。各クラスには、プロセスをディスパッチするための固有のスケジューリング方式があります。
カーネルは、最も優先順位が高いプロセスを最初にディスパッチします。デフォルトでは、実時間プロセスが sys や TS のプロセスよりも優先されますが、管理者は TS と RT のプロセスの優先順位が重なり合うように設定することもできます。
図 8-4 に SunOS 5.0 から 5.8 のカーネルから見たクラスの概念を示します。
図 8-4 スケジューリングクラスのディスパッチ優先順位
最も優先順位が高いのはハードウェア割り込みで、これはソフトウェアでは制御できません。割り込みを処理するルーチンは、割り込みが生じるとただちに直接ディスパッチされ、その際には現在のプロセスの優先順位は考慮されません。
実時間プロセスは、ソフトウェアでは最も高い優先順位をデフォルトで持ちます。RT クラスのプロセスは、優先順位とタイムカンタム (time quantum) 値を持ちます。RT プロセスは、厳密にこれらのパラメタに基づいてスケジュールされます。RT プロセスが実行可能である限り、SYS や TS のプロセスは実行できません。固定優先順位スケジューリングでは、クリティカルプロセスを完了まで事前に指定した順序で実行できます。この優先順位は、アプリケーションで変更されない限り変わりません。
RT クラスのプロセスは、有限無限を問わず親プロセスのタイムカンタムを継承します。有限タイムカンタムを持つプロセスは、タイムカンタムの有効時間が切れるか、プロセスが終了するか、ブロッキングされるか (入出力イベントを待つ)、またはより高い優先順位を持つ実行可能な実時間プロセスに横取りされるまで実行されます。無限タイムカンタムを持つプロセスは、プロセスが終了するか、ブロッキングされるか、または横取りされるまで実行されます。
SYS クラスは、ページング、STREAMS、スワッパなどの特殊なシステムプロセスをスケジュールするために存在します。あるプロセスのクラスを SYS クラスに変更できません。プロセスの SYS クラスは、プロセスの開始時にカーネルによって確立された固定優先順位を持っています。
優先順位が最も低いのは、タイムシェアリング (TS) クラスです。TS クラスのプロセスは、各タイムスライスを数百ミリ秒として動的にスケジュールされます。TS スケジューラは、頻繁にコンテキストスイッチングを行なって、各プロセスに実行する機会を平等に与えます。これは、各プロセスのタイムスライスの値とプロセスの履歴 (プロセスが最後に休眠したのはいつか) に基づき、CPU の利用率を考慮して行われます。デフォルトのタイムシェアリング方式では、優先順位の低いプロセスに長いタイムスライスを与えます。
子プロセスは fork(2) を通じて、親プロセスのスケジューリングクラスと属性を継承します。プロセスのスケジューリングクラスと属性は、exec(2) を実行しても変わりません。
各スケジューリングクラスは、異なったアルゴリズムによってディスパッチされます。クラスに依存するルーチンは、カーネルによって呼び出され、CPU のプロセススケジューリングが決定されます。カーネルはクラスに依存し、待ち行列内から最も優先順位の高いプロセスを取り出します。各クラスは、自分のクラスのプロセスの優先順位値を計算しなければなりません。この値は、そのプロセスのディスパッチ優先順位変数に入れられます。
図 8-5 に示すように各クラスのアルゴリズムは、それぞれ独自の方法によってグローバル実行待ち行列に入れる最も優先順位の高いプロセスを指定します。
図 8-5 カーネルのディスパッチ待ち行列
各クラスには、そのクラスのプロセスに適用される優先順位レベルのセットがあります。クラス固有のマッピングによって、この優先順位がグローバル優先順位のセットに割り当てられます。グローバルスケジューリング優先順位のセットへの対応は 0 で始まったり連続したりしている必要はありません。
デフォルトでは、タイムシェアリング (TS) プロセスのグローバル優先順位の値は -20 から +20 までの範囲で、カーネルの 0 から 40 までに割り当てられており、一時的な割り当ては 99 まであります。実時間 (RT) プロセスのデフォルトの優先順位は 0 から 59 までの範囲で、カーネルの 100 から 150 までに割り当てられます。カーネルのクラスに依存しないコードは、待ち行列内のグローバル優先順位の最も高いプロセスを実行します。
ディスパッチ待ち行列
ディスパッチ待ち行列は、同じグローバル優先順位を持つプロセスが線状にリンクしたリストです。各プロセスは、それぞれに接続されているクラス固有の情報によって起動されます。プロセスは、グローバル優先順位に基づいたカーネルのディスパッチテーブルからディスパッチされます。
プロセスのディスパッチ
プロセスがディスパッチされると、プロセスのコンテキストがメモリ管理情報、レジスタ、スタックとともにメモリ内に割り当てられて実行が始まります。メモリ管理情報は、現在実行中のプロセスのために仮想記憶変換を実行する際、必要となるデータを含むハードウェアレジスタの形をとります。
横取り
より高い優先順位を持つプロセスがディスパッチ可能になると、カーネルは計算に割り込んでコンテキストスイッチングを強制し、現在実行中のプロセスを横取りします。より高い優先順位のプロセスがディスパッチ可能になったことをカーネルが見つけると、プロセスはいつでも横取りされます。
たとえば、プロセス A が周辺デバイスから読み取りを行なっているとします。プロセス A はカーネルによって休眠状態に置かれます。次に、カーネルはより優先順位の低いプロセス B が実行可能になったのに気づき、プロセス B がディスパッチされ実行が始まります。ここで周辺デバイスが割り込み、デバイスのドライバが入ります。デバイスドライバはプロセス A を実行可能にして戻ります。ここで、カーネルは割り込まれたプロセス B に戻るのではなく、B の処理を横取りして、呼び起こされたプロセス A の実行を再開します。
もう 1 つの重要な例としては、複数のプロセスがカーネル資源を奪い合う場合があります。優先順位の高い実時間プロセスが待っている資源を優先順位の低いプロセスが解放すると、カーネルはただちに優先順位の低いプロセスを横取りして、優先順位の高いプロセスの実行を再開します。
カーネル優先順位の反転
優先順位の反転は、優先順位の高いプロセスが 1 つまたは複数の優先順位の低いプロセスによって長時間ブロッキングされた場合に生じます。SunOS 5.0 から 5.8 のカーネルで相互排他ロッキングなどの同期プリミティブを使用すると、優先順位の反転につながることがあります。
「ブロッキング」とは、あるプロセスが 1 つまたは複数のプロセスが資源を手放すのを待たなければならない状態のことです。このブロッキングが継続すると、使用レベルが低いものでもデッドラインを逃してしまうことがあります。
相互排他ロッキングの優先順位反転の問題については、SunOS 5.0 から 5.8 のカーネルで基本的な優先順位継承方式を実装することによって対応しています。この方式では、優先順位の低いプロセスが優先順位の高いプロセスの実行をブロッキングすると、優先順位の低いプロセスが優先順位の高いプロセスの優先順位を継承することになります。このため、プロセスがブロッキングされている時間の上限が設定されます。この方式はカーネルの特性で、プログラマがシステムコールや関数の実行によって講じる解決策ではありません。ただしこの場合でも、ユーザレベルのプロセスは優先順位の反転を生じることがあります。
ユーザ優先順位の反転
この問題とその対処方法については、『マルチスレッドのプログラミング』の「相互排他ロック属性」の節で説明しています。
スケジューリングを制御する関数呼び出し
priocntl(2)
有効なクラスのスケジューリング制御は、priocntl(2) で処理します。クラスの属性は、fork(2) や exec(2) を実行した場合にも、優先順位制御に必要なスケジューリングパラメタやアクセス権とともに継承されます。この特色は、RT と TS クラスのどちらにも当てはまります。
priocntl(2) 関数は、システムコールが適用される実時間プロセス、プロセスのセット、またはクラスを指定するインタフェースを提供します。priocntlset(2) のシステムコールも、システムコールを適用するプロセスのセット全体を指定する、さらに一般的なインタフェースを提供します。
priocntl(2) のコマンド引数は、PC_GETCID、PC_GETCLINFO、PC_GETPARMS、PC_SETPARMS のいずれかにします。呼び出しプロセスの実識別子または実効識別子は、対象となるプロセスのものと一致するか、スーパーユーザ特権を持っていなければなりません。
|
PC_GETCID |
このコマンドは、認識可能なクラス名 (実時間なら RT、タイムシェアリングなら TS) を含む構造体の名前フィールドを受け入れます。クラス ID とクラス属性データの配列が戻されます。 |
|
PC_GETCLINFO |
このコマンドは、認識可能なクラス識別子を含む構造体の ID フィールドを受け入れます。クラス名とクラス属性データの配列が戻されます。 |
|
PC_GETPARMS |
このコマンドは、指定したプロセスの 1 つのスケジューリングクラス識別子またはクラス固有のスケジューリングパラメタ、あるいはその両方を戻します。idtype と id によって大きなセットが指定された場合でも、PC_GETPARMS は 1 つのプロセスのパラメタだけを戻します。どのプロセスを選択するかはクラスによって決まります。 |
|
PC_SETPARMS |
このコマンドは、指定したプロセス (複数でも可) のスケジューリングクラス識別子またはクラス固有のスケジューリングパラメタ、あるいはその両方を設定します。 |
sched_get_priority_max(3RT)
指定された方針の最大値を戻します。
sched_get_priority_min(3RT)
指定された方針の最小値を戻します (詳細は、sched_get_priority_max(3RT) のマニュアルページを参照してください)。
sched_rr_get_interval(3RT)
指定された timespec 構造体を現在の実行時間限界に更新します (詳細は、sched_get_priority_max(3RT) のマニュアルページを参照してください)。
sched_setparam(3RT) と sched_getparam(3RT)
指定されたプロセスのスケジューリングパラメタを設定または取得します。
sched_yield(3RT)
プロセスリストの先頭に戻るまで、呼び出しプロセスをブロッキングします。
スケジューリングを制御するユーティリティ
プロセスのスケジューリングを制御する管理用ユーティリティとして、dispadmin() と priocntl(1) があります。どちらのユーティリティも、互換性のあるオプションとロード可能なモジュールを伴う priocntl(2) のシステムコールをサポートします。これらのユーティリティは、実行中に実時間プロセスのスケジューリングを制御するシステム管理機能を提供します。
priocntl(1)
priocntl(1) コマンドは、プロセスのスケジューリングパラメタの設定と取り出しを行います。
dispadmin()
dispadmin() ユーティリティに -l コマンド行オプションを付けると、実行中に現プロセスのすべてのスケジューリングクラスが表示されます。実時間クラスを表す引数として RT を -c オプションの後ろに指定すると、プロセスのスケジューリングを変更することもできます。
表 8-2 に示しているオプションも使用できます。
表 8-2 dispadmin(1M) ユーティリティのクラスオプション|
オプション |
意味 |
|---|---|
|
-l |
現在設定されているスケージュリングクラスを表示する。 |
|
-c |
パラメタを表示または変更するクラスを指定する。 |
|
-g |
指定したクラスのディスパッチパラメタを取得する。 |
|
-r |
-g オプションと共に使用した場合、タイムカンタム (time quantum) の解像度を指定する。 |
|
-s |
値が保存されているファイルを指定する。 |
ディスパッチパラメタが保存されているクラス固有のファイルを実行中にロードすることもできます。このファイルを使用して、起動時に確立されたデフォルトの値を新しい優先順位のセットで置き換えることができます。このクラス固有のファイルでは、-g オプションで使用される書式の引数を挿入しなければなりません。RT クラスのパラメタは rt_dptbl(4) にあり、この節の終わりに例を示します。
システムに RT クラスのファイルを追加するには、次のモジュールが存在しなければなりません。
-
rt_dptbl(4) をロードするクラスモジュール内の rt_init() ルーチン
-
ディスパッチパラメタと、config_rt_dptbl へのポインタを戻すルーチンを提供する rt_dptbl(4)
-
dispadmin() 実行可能ファイル
-
次のコマンドでクラス固有のモジュールをロードします。
この場合、module_name はクラス固有のモジュールを指定します。
# modload /kernel/sched/module_name
-
dispadmin() コマンドを起動します。
# dispadmin -c RT -s file_name
上書きされるテーブルと同じ数のエントリを持つテーブルが、ファイルに記述されていなければなりません。
スケジューリングの設定
両方のスケジューリングクラスにはパラメタテーブル rt_dptbl(4) と ts_dptbl(4) が関連づけられています。これらのテーブルは、起動時にロード可能なモジュールを使用するか、実行中に dispadmin() を使用して設定できます。
ディスパッチャパラメタテーブル
実時間のための中心となるテーブルで、RT スケジューリングの設定項目を指定します。rt_dptbl(4) 構造体は、パラメタ配列の structrt_dpent_t 構造体から成り、これは n 個の優先順位レベルそれぞれに 1 つずつあります。ある優先順位レベルの設定項目は、配列内の i 番目のパラメタ構造体 rt_dptbl[i] によって指定されます。
パラメタ構造体は次のメンバーから成ります (/usr/include/sys/rt.h ヘッダファイルにも記述されています)。
|
rt_globpri |
この優先順位レベルに関係づけられているグローバルスケジューリング優先順位。rt_globpri の値は dispadmin() では変更できません。 |
|
rt_quantum |
このレベルのプロセスに割り当てられるタイムカンタムの長さを目盛で表したもの (「タイムスタンプ機能」を参照)。タイムカンタム値は、特定のレベルのプロセスのデフォルト値、つまり開始値です。実時間プロセスのタイムカンタムは、priocntl(1) コマンドまたは priocntl(2) システムコールによって変更できます。 |
config_rt_dptbl の再設定
実時間管理者は、いつでも config_rt_dptbl を再設定して、スケジューラの実時間部分の動作を変更できます。1 つの方法は、rt_dptbl(4) のマニュアルページの「REPLACING THE RT_DPTBL LOADABLE MODULE」の節で説明されています。
もう 1 つの方法は、dispadmin() コマンドを使用して、実行中のシステムで実時間パラメタテーブルを調査または変更する方法です。dispadmin() を実時間クラスで起動すると、カーネルの中心テーブルにある現在の config_rt_dptb1 内から現在の rt_quantum 値を取り出すことができます。現在の中心テーブルを上書きする際、dispadmin() への入力に使用された設定ファイルは、rt_dptbl(4) のマニュアルページで説明されている書式に合致していなければなりません。
config_rt_dptbl[] 内にある優先順位を設定されたプロセス rtdpent_t と、関連づけられているタイムカンタム値を次に示します。
rtdpent_t rt_dptbl[] = { 129, 60,
/* 優先順位レベルのタイムカンタム */ 130, 40,
100, 100, 131, 40,
101, 100, 132, 40,
102, 100, 133, 40,
103, 100, 134, 40,
104, 100, 135, 40,
105, 100, 136, 40,
106, 100, 137, 40,
107, 100, 138, 40
108, 100, 139, 40,
109, 100, 140, 20,
110, 80, 141, 20,
111, 80, 142, 20,
112, 80, 143, 20,
113, 80, 144, 20,
114, 80, 145, 20,
115, 80, 146, 20,
116, 80, 147, 20,
117, 80, 148, 20,
118, 80, 149, 20,
119, 80, 150, 10,
120, 60, 151, 10,
121, 60, 152, 10,
122, 60, 153, 10,
123, 60, 154, 10,
124, 60, 155, 10,
125, 60, 156, 10,
126, 60, 157, 10,
126, 60, 158, 10,
127, 60, 159, 10,
128, 60, }
|
メモリロッキング
メモリのロッキングは、実時間アプリケーションにとって最重要事項の 1 つです。実時間環境では潜在的な時間を減らし、ページングとスワッピングを防ぐために、プロセスは連続してメモリ内に常駐していることを保証される必要があります。
この節では、SunOS 5.0 から 5.8 で実時間アプリケーションに利用できるメモリロッキング機構について説明します。
概要
SunOS 5.0 から 5.8 では、プロセスのメモリ常駐性は、プロセスの現在の状態、使用できる全物理記憶、有効なプロセス数、およびプロセッサのメモリに対する要求によって決まります。これは、タイムシェアリング環境には適合しますが、実時間プロセスについては受け入れられないことがよくあります。実時間環境では、プロセスは、メモリアクセスとディスパッチ中の潜在的な時間を減らすために、プロセスの全部または一部がメモリ内に常駐していることが保証される必要があります。
SunOS 5.0 から 5.8 の実時間では、メモリロッキングはスーパーユーザ特権付きで実行されているプロセスが、自分の仮想アドレス空間の指定された部分を物理記憶にロッキングできるようにするライブラリルーチンのセットによって提供されています。このようにしてロッキングされたページは、ロッキングを解除されるか、プロセスが終了するまでページングの対象になりません。
一度にロッキングできるページ数には、システム全体で共通の制限があります。これは調整可能なパラメタで、デフォルト値は起動時に計算されます。値は、ページフレーム数マイナス一定のパーセント (現在は 10 パーセントに設定) が基本になります。
ページのロッキング
mlock(3C) は、メモリの 1 セグメントをシステムの物理記憶にロッキングするように要求します。指定したセグメントを構成するページは、ページフォルトが発生して物理記憶に入り、各ロッキングカウント値は 1 増やされます。ロッキングのカウントが 0 より大きいページは、ページング操作から除外されます。
特定のページを異なったマッピングで複数のプロセスを使って何度もロッキングできます。2 つの異なったプロセスが同じページをロッキングすると、両方のプロセスがロッキングを解除するまで、そのページはロッキングされたままです。ただし、マッピング内でページロッキングはネストしません。同じアドレスに対して同じプロセスがロッキング関数を何度も呼び出した場合でも、ロッキングは一度のロッキング解除要求で削除されます。
ロッキングが実行されているマッピングが削除されると、そのメモリセグメントのロッキングは解除されます。ファイルを閉じるまたは切り捨てることによってページが削除された場合も、ロッキングは解除されます。
fork(2) 呼び出しが行われた後、ロッキングは子プロセスには継承されません。したがって、メモリをロッキングしているプロセスが子プロセスをフォークすると、子プロセスはページをロッキングするために、自分でメモリロッキング操作を行わなければなりません。そうしないと、プロセスをフォークした場合に通常必要となるページのコピー即時書き込みを行わなければならなくなります。
ページのロッキング解除
メモリによるページのロッキングを解除するには、プロセスは munlock(3C) 呼び出しによって、ロッキングされている仮想記憶のセグメントを解放するように要求します。こうすると、指定された物理ページのロッキングカウントが減らされます。ページのロッキングカウントが 0 まで減ると、そのページは普通にスワップされます。
全ページのロッキング
スーパーユーザプロセスは、mlockall(3C) 呼び出しによって、自身のアドレス空間内の全マッピングをロッキングするように要求できます。MCL_CURRENT フラグが設定されている場合は、既存のメモリマッピングがすべてロッキングされます。MCL_FUTURE フラグが設定されている場合は、既存のページに追加されるか、既存のマッピングを置き換えるマッピングはすべてメモリ内にロッキングされます。
スティッキロッキング
ページのロッキングカウントが 65535 (0xFFFF) に達すると、そのページは永久にロッキングされます。0xFFFF の値は実装の際に定義されているため、将来のリリースでは変更される可能性があります。このようにしてロッキングされたページは、ロッキングを解除できません。復元するにはシステムを再起動してください。
高性能入出力
この節では、実時間プロセスでの入出力について説明します。SunOS 5.0 から 5.8 では、高速で非同期の入出力操作を実行するための 2 種類のインタフェースをライブラリで提供しています。POSIX 非同期入出力インタフェースは新しい標準です。堅牢性向上のため、SunOS は情報の消失やデータの不一致を防止するためのファイルおよびメモリ内同期操作とモードも提供しています。
標準の UNIX 入出力は、アプリケーションのプログラマと同期します。read(2) または write(2) を呼び出すアプリケーションは、通常はシステムコールが終了するまで待ちます。
実時間アプリケーションは、入出力に非同期で結合された特性を必要とします。非同期入出力呼び出しを発行したプロセスは、入出力操作の完了を待たずに先に進むことができます。呼び出し側は、入出力操作が終了すると通知されます。その間、プロセスは他の動作を行います。
非同期入出力は、任意の SunOS ファイルで使用できます。ファイルは同期して開かれますが、特別なフラグ設定は必要ありません。非同期入出力転送には、呼び出し、要求、操作の 3 つの要素があります。アプリケーションは非同期入出力関数を呼び出し、入出力要求が待ち行列に置かれ、呼び出しはただちに復帰します。ある時点で、システムは要求を待ち行列から取り出し、入出力操作を開始します。
非同期入出力要求と標準入出力要求は、任意のファイル記述子で混在させることができます。システムは、読み取り要求と書き込み要求の特定の順序を維持しません。システムは、保留状態にあるすべての読み取り要求と書き込み要求の順序を任意に並べ替えます。特定の順序を必要とするアプリケーションは、前の操作の完了を確認してから従属する要求を発行しなければなりません。
POSIX 非同期入出力
POSIX 非同期入出力は、aiocb 構造体を使用して行います。aiocb 制御ブロッキングは、各非同期入出力要求を識別し、すべての制御情報を持っています。制御ブロッキングは、一度に 1 つの要求だけに使用でき、その要求が完了すると再使用できます。
一般的な POSIX 非同期入出力操作は、aio_read(3RT) または aio_write(3RT) 呼び出しによって開始します。ポーリングまたはシグナルを使用して、操作の完了を判断できます。シグナルを操作の完了に使用する場合は、各操作に一意にタグを付けることができます。タグは生成されたシグナルの si_value 構成要素に戻されます (詳細は、siginfo(3HEAD) のマニュアルページを参照してください)。
aio_read(3RT)
aio_read(3RT) は、読み取り操作の開始のために非同期入出力制御ブロッキングを使用して呼び出します。
aio_write(3RT)
aio_write(3RT) は、書き込み操作の開始のために非同期入出力制御ブロッキングを指定して呼び出します。
aio_return(3RT) と aio_error(3RT)
aio_return(3RT) と aio_error(3RT)は、操作が完了しているとわかった後、それぞれ戻り値とエラー値を取得するために呼び出します。
aio_cancel(3RT)
aio_cancel(3RT) は、保留状態の操作を取り消すために非同期入出力制御ブロッキングを指定して呼び出します。
aio_fsync(3RT)
aio_fsync(3RT) は、指定したファイルで保留状態のすべての入出力操作に対する非同期の fsync(3C) または fdatasync(3RT) 要求を待ち行列に並べます。
aio_suspend(3RT)
aio_suspend(3RT) は、1 つ以上の先行する非同期入出力要求が同期して行われるかのように呼び出し側を一時停止します。
Solaris 非同期入出力
通知 (SIGIO)
非同期入出力呼び出しが正常に復帰しても、入出力操作は待ち行列に並べられただけであり、実行を待っています。実際の操作は、戻り値と潜在的なエラー識別子も持っています。これらの値は、同期呼び出しの結果として呼び出し側に戻されます。入出力が終了すると、戻り値とエラー値は、要求時点でユーザが aio_result_t へのポインタとして指定した位置に格納されます。aio_result_t 構造体は、<sys/asynch.h> に次のように定義されています。
typedef struct aio_result_t {
ssize_t aio_return; /* 読み取りまたは書き込みの戻り値 */
int aio_errno; /* 入出力によって生成されたエラー番号 */
} aio_result_t;
|
aio_result_t が変更されると、入出力要求を行なったプロセスに SIGIO シグナルが配信されます。
2 つ以上の非同期入出力操作を保留状態にしている場合、どの要求によって SIGIO シグナルが生じたか、またはどちらの要求によって SIGIO シグナルが生じたのかは調べることはできません。SIGIO を受け取ったプロセスは、SIGIO を生じた原因となる条件をすべてチェックしなければなりません。
aioread(3AIO)
aioread(3AIO) は read(2) の非同期版です。aioread(3AIO) は通常の読み取り引数に加えて、ファイル位置と、システムが操作結果を格納する aio_result_t 構造体のアドレスを指定する引数を取ります。ファイル位置には、操作前にファイル内で行うシークを指定します。aioread(3AIO) 呼び出しが成功したか失敗したかに関係なく、ファイルポインタが更新されます。
aiowrite(3AIO)
aiowrite(3AIO) 関数は write(2) の非同期版です。aiowrite(3AIO) は通常の書き込み引数以外にファイル位置と、操作結果が格納される aio_result_t 構造体のアドレスを指定する引数を取ります。
ファイル位置には、操作の前にファイル内で行うシークを指定します。aiowrite(3AIO) 呼び出しが成功すると、ファイルポインタはシークと書き込みが成功した場合の位置に変更されます。ファイルポインタは書き込みを行なった後、以降の書き込みができなくなった場合も変更されます。
aiocancel(3AIO)
aiocancel(3AIO) は、その aio_result_t 構造体を引数として指定した非同期要求の取り消しを試みます。aiocancel(3AIO) 呼び出しは、要求がまだ待ち行列にある場合だけに成功します。操作がすでに進行していると aiocancel(3AIO) は失敗します。
aiowait(3AIO)
aiowait(3AIO) を呼び出すと、少なくとも 1 つの未処理の非同期入出力操作が完了するまで呼び出しプロセスはブロッキングされます。タイムアウトパラメタは、入出力の完了を待つ最大インタバルを指します。0 のタイムアウト値は、待つ必要がないことを指定します。aiowait(3AIO) は、完了した操作の aio_result_t 構造体へのポインタを戻します。
poll(2)
非同期の入出力イベントの完了を、SIGIO 割り込みに依存するのではなく同期的に決定するには、poll(2) を使用してください。SIGIO 割り込みの原因を調べるためにポーリングすることもできます。
poll(2) をあまり多くのファイルで使用すると、処理が遅くなります。この問題は、poll(7D) で解決します。
poll(7D)
/dev/poll によって、多数のファイル記述子のポーリングを非常にスケーラブルに行うことができます。これは、新しい API のセットと新しいドライバである /dev/poll によって可能になっています。/dev/poll API は poll(2) の代替ではなく、選択して使用するものです。poll(7D) は /dev/poll API の詳細と例を示しています。適切に使用すると、/dev/poll API は poll(2) よりも適切にスケールが行われます。特に次の条件を満たすアプリケーションに適します。
-
多数のファイル記述子のポーリングを繰り返し行うアプリケーション。
-
ポーリングが行われたファイル記述子が比較的安定している、つまりひんぱんに開閉が行われないこと。
-
ポーリングイベントの総数に比較して、保留が少ないファイル記述子のセット。
close(2)
ファイルは、close(2) 呼び出しによって閉じられます。close(2) を呼び出すと、取り消すことができる未処理の非同期入出力要求はすべて取り消されます。close(2) 関数は、取り消せない操作の完了を待ちます (詳細は、「aiocancel(3AIO)」を参照してください)。close(2) 呼び出しが戻ると、そのファイル記述子について保留状態にある非同期入出力要求はなくなります。ファイルが閉じられると、取り消されるのは指定したファイル記述子に対する待ち行列内にある非同期入出力要求だけです。他のファイル記述子について、保留状態にある入出力要求は取り消されません。
同期入出力
アプリケーションは、情報が安定した記憶領域に書き込まれたことや、ファイル変更が特定の順序で行われることを保証する必要がある場合があります。同期入出力は、このような場合のために用意されています。
同期のモード
SunOS 5.0 から 5.8 では、物理記憶領域媒体でエラーなしに読み取れることがシステムで保証されている場合、書き込まれたデータがすべて、そのファイルをあとで開いた際に (システムや電源の障害後であっても)、書き込み操作のために通常ファイルへ正しく転送されます。物理記憶領域媒体上のデータのイメージを要求側のプロセスが利用できる場合、データは読み取り操作のために正しく転送されます。入出力操作は、関連づけられているデータが正しく転送されたか、操作が失敗と診断された場合に完了します。
入出力操作は、次の場合に同期入出力データの保全を完了します。
読み取りについては、操作は完了または失敗と診断されます。読み取りが完了するのは、データのイメージが要求側のプロセスに正しく転送された場合だけです。同期読み取り操作が要求された時点で、読み取るデータに影響を与える書き込み要求が保留状態にある場合は、データを読み取る前に書き込み要求が正しく転送されます。
書き込みについては、操作は完了または失敗と診断されます。書き込みが完了するのは、書き込み要求で指定されたデータが正しく転送され、そのデータを取り出すために必要なファイルシステム情報がすべて正しく転送された場合だけです。
データの取り出しに必要のないファイル属性 (アクセス時間、変更時間、状態変更時間) は、呼び出し側プロセスに戻る前に正しく転送されているわけではありません。
同期入出力ファイルの保全の完了は、呼び出し側プロセスに戻る前に入出力操作に関連するすべてのファイル属性 (アクセス時間、修正時間、状態変更時間を含む) が正しく転送されなければならない点を除けば、同期入出力データの保全の完了と同じです。
ファイルの同期
fsync(3C) 関数と fdatasync(3RT) 関数は、ファイルを二次記憶領域と明示的に同期をとります。形式は次のようになります。
fsync(3C) は、入出力ファイルの保全完了レベルで関数の同期をとることを保証し、fdatasync(3RT) は、入出力データの保全完了レベルで関数の同期をとることを保証します。
アプリケーションは、操作が完了する前に各入出力操作の同期をとるように指定できます。open(2) または fcntl(2) によってファイル記述に O_DSYNC フラグを設定すると、操作が完了したと見なされる前にすべての入出力書き込み (write(2) と aiowrite(3AIO)) が入出力データ完了に達します。ファイル記述に O_SYNC フラグを設定すると、操作が完了したと見なされる前に、すべての入出力書き込みが入出力ファイル完了に達します。ファイル記述に O_RSYNC フラグを設定すると、すべての入出力読み取り (read(2) と aio_read(3RT)) が、O_DSYNC または O_SYNC を記述子に設定した書き込み要求と同じ完了レベルに達します。
プロセス間通信
この節では、SunOS 5.0 から 5.8 のプロセス間通信 (IPCTM) 機能を、実時間処理との関連で説明します。シグナル、パイプ、FIFO (名前付きパイプ)、メッセージ待ち行列、共用メモリ、ファイルマッピング、およびセマフォについて説明します。プロセス間通信に役立つライブラリ、関数、およびルーチンについては、第 7 章「プロセス間通信」を参照してください。
概要
実時間処理は、しばしば高速な高いバンド幅のプロセス間通信を必要とします。どの機構を使用すればよいかは機能的な要求によって決まり、相対的な性能はアプリケーションの特性に依存します。
UNIX での従来のプロセス間通信の方法はパイプですが、パイプはフレーム上の問題を生じます。複数の人がメッセージを書いた結果が混合したり、あるメッセージを複数の人が読むと分断されてしまったりすることがあります。
IPC のメッセージは、ファイルの読み取りや書き込みと似たものです。これは 2 つ以上のプロセスが 1 つの媒体によって通信しなければならない場合、パイプより使いやすいです。
IPC の共用セマフォ機能では、プロセスの同期をとることができます。共用メモリは最も高速なプロセス間通信の形式です。共用メモリの主な長所は、メッセージデータのコピーが不要な点です。共用メモリアクセスの同期をとるには、通常はセマフォの機構を使用します。
シグナル
シグナルを使用してプロセス間で少量の情報を送信できます。次のように、送り側は sigqueue(3RT) 関数を使用して、少量の情報とともにシグナルをターゲットプロセスに送信します。
ターゲットプロセスは、以降に発生した保留状態のシグナルも待ち行列に入れるため、指定されたシグナルの SA_SIGINFO ビットを設定していなければなりません (詳細は、sigaction(2) のマニュアルページを参照してください)。
ターゲットプロセスは、シグナルを同期または非同期に受信できます。シグナルをブロッキングしたまま (sigprocmask(2) のマニュアルページを参照)、sigwaitinfo(3RT) または sigtimedwait(3RT) を呼び出すと、シグナルは、siginfo_t 引数の si_value メンバーに格納されている、sigqueue(3RT) の呼び出し側によって送信された値と同期をとって受信されます。シグナルのブロッキングを解除しておくと、シグナルは sigaction(2) によって指定されたシグナルハンドラに配信され、値はハンドラへの siginfo_t 引数の si_value に設定されます。
関連づけられた値を持つシグナルで、送信しても配信されないものの数は、1 プロセスあたり固定です。{SIGQUEUE_MAX} 個のシグナルの記憶領域は、sigqueue(3RT) を最初に呼び出した時点で割り当てられます。その後 sigqueue(3RT) を呼び出すと、ターゲットプロセスの待ち行列にシグナルが正常に入るか、または制限時間内で異常終了します。
パイプ
パイプは、プロセス間の一方方向の通信を提供します。プロセスがパイプで通信するには、共通の祖先を持っていなければなりません。パイプを通して渡されるデータは、通常の UNIX バイトストリームとして扱われます。パイプについては、「パイプ」を参照してください。
名前付きパイプ
SunOS 5.0 から 5.8 では名前付きパイプ (FIFO) が用意されています。FIFO はディレクトリ内の名前付きエンティティなので、パイプに比べて柔軟性があります。FIFO が作成されると、適切なアクセス権を持っていればどのプロセスでも FIFO を開くことができます。プロセスは親を共用している必要はなく、親がパイプを初期化して子孫に渡す必要もありません。詳細は、「名前付きパイプ」を参照してください。
メッセージ待ち行列
メッセージ待ち行列は、プロセス間で通信するもう 1 つの手段を提供します。任意の数のプロセスが 1 つのメッセージ待ち行列だけで送受信できます。メッセージは、バイトストリームとしてではなく、任意の大きさのブロッキングとして渡されます。メッセージ待ち行列は、System V 版と POSIX 版の両方で提供されています。詳細は、「System V メッセージ」と 「POSIX メッセージ」を参照してください。
セマフォ
セマフォは、共用資源に対してアクセスの同期をとる機構です。セマフォも、System V と POSIX の両方で提供されています。System V セマフォは非常に柔軟性がありますが、重量がかなりあります。POSIX セマフォは、極めて軽量です。詳細は、「System V セマフォ」と 「POSIX セマフォ」を参照してください。
セマフォを使用すると、この章で前述した技法によって明示的に回避しない限り、優先順位の反転が生じる場合があるので注意してください。
共用メモリ
プロセスが通信するための最も高速な方法は、直接メモリの共用セグメントを使用した場合です。共通メモリ領域が共用しているプロセスのアドレス空間に追加されます。アプリケーションは、データを格納することでデータを送信し、データを取り出すことで通信データを受信します。SunOS 5.0 から 5.8 では、共用メモリのための機構として、「メモリ管理インタフェース」で説明されているメモリにマッピングされたファイル、System V IPC 共用メモリ、POSIX 共用メモリ、の 3 つの方法を提供しています。
共用メモリを使用するときの最も大きな問題点は、3 つ以上のプロセスが同時に共用メモリに読み取りや書き込みを行おうとすると結果が正しくなくなる場合があることです。詳細は、「共用メモリの同期」を参照してください。
メモリにマッピングされたファイル
mmap(2) インタフェースは、共用メモリセグメントを呼び出し側のアドレス空間に接続します。呼び出し側は、アドレスと長さによって共用セグメントを指定します。呼び出し側は、アクセス保護フラグとマッピングされたページを管理する方法も指定しなければなりません。mmap(2) を使用して、ファイルまたはファイルのセグメントをプロセスのメモリにマッピングすることもできます。この技法は、あるアプリケーションでは非常に便利ですが、マッピングされたファイルセグメントへの格納が暗黙の入出力になる場合があるということを忘れがちです。それ以外の場合では、結合されているプロセスの応答時間が予測できないものになることもあります。msync(3C) は、指定したメモリセグメントのその時のまたは最終的なコピーをパーマネント記憶領域に作成します。詳細は、「メモリ管理インタフェース」を参照してください。
ファイルなしメモリマッピング
0 の特別ファイルである /dev/zero(4S) は、名前がなく 0 で初期化されたメモリオブジェクトを作成するのに使用できます。メモリオブジェクトの長さはマッピングを含むページの最小の番号になります。オブジェクトは、共通の先祖プロセスをもつ子孫だけが共用できます。
System V IPC 共用メモリ
shmget(2) 呼び出しを使用して、共用メモリセグメントの作成と既存の共用メモリセグメントを取得できます。shmget(2) 関数は、ファイル識別子に似た識別子を戻します。shmat(2) を呼び出すと、mmap(2) とほとんど同じように共用メモリセグメントがプロセスメモリの仮想セグメントになります。詳細は、「System V 共用メモリ」を参照してください。
POSIX 共用メモリ
POSIX 共用メモリは System V 共用メモリの変形で、若干の違いはありますが同様の機能を提供します。詳細は、「POSIX 共用メモリ」を参照してください。
共用メモリの同期
共用メモリでは、メモリの一部が 1 つ以上のプロセスのアドレス空間にマッピングされます。アクセスを協調させる方法は自動的には提供されないため、2 つのプロセスが同時に同じ場所の共用メモリに書き込もうとすることがあります。このため共用メモリは、通常はプロセスの同期をとるセマフォやその他の機構と一緒に使用します。System V セマフォと POSIX セマフォは、両方ともこの目的のために使用できます。マルチスレッドライブラリに提供されている相互排他ロッキング、リーダロッキングとライタロッキング、セマフォ、および条件変数もこの目的のために使用できます。
IPC および同期の機構の選択
アプリケーションには特定の機能上の要求があり、それによってどの IPC 機構を使用するかが決まります。いくつかの機構が使用できる場合は、アプリケーションの作成者が、そのうちどれが最もアプリケーションに適しているかを決定します。SunOS 5.0 から 5.8 のプロセス間通信の機構は、アプリケーションの動作により異なります。アプリケーションで使用される様々な長さのメッセージの組み合わせについて各機構のスループットを測定し、どの機構の応答が最も良いかを調べてください。
非同期ネットワーキング
この項では、ソケットまたは実時間アプリケーション用のトランスポートレベルインタフェース (TLI) を使用した非同期ネットワーク通信について説明します。ソケットを使用した非同期ネットワーキングを行うには、SOCK_STREAM タイプのオープンソケットを非同期および非ブロックに設定します (『ネットワークインタフェース』の「拡張機能」中の「非同期ソケット入出力」の節を参照してください)。TLI イベントの非同期ネットワーク処理は、STREAMS 非同期機能と TLI ライブラリルーチンの非ブロックモードの組み合わせによってサポートされます (『ネットワークインタフェース』の「非同期ネットワークの応用」を参照してください)。
トランスポートレベルインタフェースの詳細については、『ネットワークインタフェース』の「ソケットインタフェース」の章を参照してください。
ネットワーキングのモード
ソケットとトランスポートレベルインタフェースの両方で、「接続モード」と「接続なしモード」という 2 つのモードサービスが用意されています。
接続モードサービス
「接続モード」サービスは回線中心で、確立された接続上を信頼できるシーケンスでデータを伝送します。データ伝送フェーズでのアドレスの解決と伝送のオーバヘッドを避けるための識別手続きも用意されています。このサービスは、比較的長い時間持続するデータストリーム中心の対話を必要とするアプリケーションに適しています。
接続なしモードサービス
「接続なしモード」サービスはメッセージ中心で、複数のユニット間の論理的な関係を要求されない独立した単位でのデータ伝送をサポートします。宛先を含むデータのユニットを配信するために必要なすべての情報は、データと合わせて単一のサービス要求として送信側からトランスポートプロバイダに渡されます。接続なしモードサービスは、短い時間の要求と応答の対話を行い、データの配信の保証やシーケンスを必要としないアプリケーションに適しています。接続なしモードによる伝送は、概して信頼性が低いと言えます。
タイマ
この節では、SunOS 5.0 から 5.8 で実時間アプリケーションのために使用できるタイミング機能について説明します。実時間アプリケーションでこの機能を活用したい場合は、この節に示されているルーチンについてマニュアルページを参照してください。
SunOS 5.0 から 5.8 のタイミング機能は、「タイムスタンプ」と「インタバル」タイマという 2 つの機能に分けられます。タイムスタンプ機能は経過時間を測定して、アプリケーションが、ある状態の持続時間やイベント間の時間を測定できるようにします。インタバルタイマ機能は、アプリケーションを指定した時間に呼び起こして、アプリケーションが時間の経過に基づいて動作をスケジュールできるようにします。アプリケーションは、タイムスタンプ機能をポーリングして自分をスケジュールすることもできますが、そのようなアプリケーションは、プロセッサを独占して他のシステム関数に悪影響を与えます。
タイムスタンプ機能
タイムスタンプは 2 つの関数によって提供されます。gettimeofday(3C) 関数は、グリニッジ標準時間 1970 年 1 月 1 日午前 0 時からの秒数とマイクロ秒数によって時間を表し、現在の時間を timeval 構造体に与えます。clock_gettime(3R) 関数は、CLOCK_REALTIME のクロック ID とともに使用して、gettimeofday(3C) が戻すタイムインタバルと同じ時間を秒とナノ秒で表して、現在の時間を timespec 構造体に与えます。
SunOS 5.0 から 5.8 はハードウェア定期タイマを使用します。ある種のワークステーションでは、これが唯一の時間情報で、タイムスタンプの精度はその定期タイマの解像度までに制限されます。その他のプラットフォームでは、1 マイクロ秒の解像度を持つタイマレジスタによって、SunOS 5.0 から 5.8 ではタイムスタンプ精度は 1 マイクロ秒となっています。
インタバルタイマ機能
実時間アプリケーションは、インタバルタイマを使用して活動をスケジュールすることがよくあります。インタバルタイマには、「単発」型と「周期」型の 2 種類があります。
単発タイマは、現在時間または絶対時間に相対的な有効時間に設定されるタイマです。タイマは、有効時間が終了すると解除されます。このようなタイマは、データを記憶領域に転送した後のバッファの消去や操作のタイムアウトの管理に便利です。
周期タイマには、初期有効時間 (絶対時間または相対時間) と繰り返しインタバルが設定されています。インタバルタイマの有効時間が経過するたびに、タイマは繰り返し再ロードされ、自動的に再度有効になります。このタイマはデータロギングやサーボ制御に便利です。インタバルタイマ機能を呼び出す際は、システムのハードウェア定期タイマの解像度より小さな時間値は、ハードウェア定期タイマインタバル (10 ミリ秒) の時間値より大きい最小の倍数に丸められます。
SunOS 5.0 から 5.8 には、setitimer(2) インタフェースと getitimer(2) インタフェースの 2 組のタイマインタフェースがあります。これらのインタフェースは、タイムインタバルを指定する timeval 構造体を使用して、BSD タイマと呼ばれる固定設定タイマを動作させます。POSIX タイマである timer_create(3RT)、CLOCK_REALTIME は、POSIX クロック CLOCK_REALTIME を動作させます。POSIX タイマの動作は、timespec 構造体によって表されます。
getitimer(2) 関数と setitimer(2) 関数は、それぞれ指定された BSD インタバルタイマの値の取り出しと設定を行います。プロセスは ITIMER_REAL で指定する実時間タイマを含め、3 つの BSD インタバルタイマを利用できます。BSD タイマを使用して有効になっている場合は、システムによってタイマにふさわしいシグナルがタイマを設定したプロセスに送信されます。
timer_create(3RT) は、{TIMER_MAX} 個までの POSIX タイマを生成できます。呼び出し側はタイマの有効時間が経過したときに、どのシグナルと関連値をプロセスに送るかを指定できます。timer_settime(3RT) と timer_gettime(3RT) は、指定された POSIX インタバルタイマの値を、それぞれ設定および検索します。必要なシグナルが保留状態にある間に POSIX タイマの有効時間が経過すると配信がカウントされ、timer_getoverrun(3RT) はそのような有効時間切れのカウントを検索します。timer_delete(3RT) は、POSIX タイマの割り当てを解除します。
例 8-1 に、setitimer(2) を使用して定期割り込みを発生させる方法とタイマ割り込みの到着の制御方法を示します。
例 8-1 タイマ割り込みの制御
#include <unistd.h>
#include <signal.h>
#include <sys/time.h>
#define TIMERCNT 8
void timerhandler();
int timercnt;
struct timeval alarmtimes[TIMERCNT];
main()
{
struct itimerval times;
sigset_t sigset;
int i, ret;
struct sigaction act;
siginfo_t si;
/* SIGALRM をブロッキングする */
sigemptyset (&sigset);
sigaddset (&sigset, SIGALRM);
sigprocmask (SIG_BLOCK, &sigset, NULL);
/* SIGALRM のためのハンドラを設定する */
act.sa_action = timerhandler;
sigemptyset (&act.sa_mask);
act.sa_flags = SA_SIGINFO;
sigaction (SIGALRM, &act, NULL);
/*
* 3 秒後に開始し、そのあとは 3 分の 1 秒おきに開始するように
* インタバルタイマを設定する
*/
times.it_value.tv_sec = 3;
times.it_value.tv_usec = 0;
times.it_interval.tv_sec = 0;
times.it_interval.tv_usec = 333333;
ret = setitimer (ITIMER_REAL, ×, NULL);
printf ("main:setitimer ret = %d¥n", ret);
/* 現在はアラーム待ち */
sigemptyset (&sigset);
timerhandler (0, si, NULL);
while (timercnt < TIMERCNT) {
ret = sigsuspend (&sigset);
}
printtimes();
}
void timerhandler (sig, siginfo, context)
int sig;
siginfo_t *siginfo;
void *context;
{
printf ("timerhandler:start¥n");
gettimeofday (&alarmtimes[timercnt], NULL);
timercnt++;
printf ("timerhandler:timercnt = %d¥n", timercnt);
}
printtimes ()
{
int i;
for (i = 0; i < TIMERCNT; i++) {
printf("%ld.%0l6d¥n", alarmtimes[i].tv_sec,
alarmtimes[i].tv_usec);
}
}
|
- © 2010, Oracle Corporation and/or its affiliates