| 低レベルライブラリ中にあり、特権0の属性を持つことは解ります。そこで、
|ページフォルト例外#14が発生すると、現在実行中タスクのTSSから特権0
|のスタックセグメント情報を読み込んでスタック切替えが発生すると思われる。
| この時に、新たな特権0スタックにページフォルトが発生しない事は何の様に
|保証されるか、よく解りません。あらかじめ、メモリー常駐ページとして割り当
割り込みハンドラ全般が、カーネルモードのスタックを使用して起動するわ
けですから(この辺の私の理解が違っていたらごめんなさい)、常にカーネル
モードのスタックは常駐している(あるいはプロセスのスイッチと同時にアク
ティブになる)ということなのではないでしょうか。
| ページフォルトが発生したタスクは、最終的にはディスクI/Oの完了を待つ
|状態な訳ですから、SUSPEND状態よりもWAIT状態とするのが適当なの
|では無いでしょうか。ディスク入出力を管理するマネージャのメッセージキュー
ITRON において、「wait」状態は「自分が資源の獲得を明示的に待つ」状態
であるといえます。一方、「suspend 」状態は「他のタスクが自タスクの実行
を妨害している」状態です。また、割り込みハンドラは「wait」状態になるこ
とはできません(つまり、ページフォールトの割り込みハンドラがシステムコー
ルを発行することで待ちに入ることはできない)。
「割り込みハンドラからタスクの実行を抑制する」という機能から考えると
suspend がいちばん素直だと思うのですが、いかがでしょうか。また、メモリ
から読み出すだけでwaitになるというのは不自然だという感覚的な点も気にな
ります。
| それから、ITRON仕様からは逸脱しますが、誤って他のタスクからwup_tsk(),r
|el_wai()等の要求が出された場合の事を考えて、ページフォルト例外発生中のタ
|スクの状態として、内部的にページイン待ちか否かを区別して管理するほうが良
|いのでは無いでしょうか。
この場合、そのプロセスが実行されようとした時点で、同じページフォール
トがもう一度発生するだけので、あまり問題にはならないでしょう。
|が連なる事になると思います。待ち状態のタスクAには、ページフォルト例外発
|生タスク以外に通常のディスクI/Oを行っているタスクも存在すると思われる
|ので、SUSPENDよりもWAITとする方が良いのでは。
ディスクI/O待ちは、低レベルライブラリに返答メッセージを送りますが、
ページフォールトの場合はメモリマネージャに返答メッセージを送るものと思
います。この流れを考えると、ITRON の拡張なしにメモリマネージャが該当ア
プリケーションを有効化できるのを考えても、suspend 状態がいいように思い
ます。
P.S ふと思ったのですが、ITRON の拡張システムコール(かな?)にあ
る、「任意のリージョンへのリード/ライト」ですが、対象とするリー
ジョンが実メモリ上にない場合は周辺核側でメモリマネージャやファ
イルマネージャを呼ぶのでしょうか? この状況は、アプリケーショ
ンがレコードを読み出そうとして、読み出し待ちの間にアプリケーショ
ンのメモリがページアウトされてしまい、その後ファイルマネージャ
がアプリケーションのメモリにレコードを書き出そうとした場合など
に発生します。
JBA03350 3.14 こと 木元峰之