-
Notifications
You must be signed in to change notification settings - Fork 0
Unified Parallel C
Unified Procedure Call
OS/omicron V4 におけるマイクロカーネル SMART のシステム構成プリミティブ．
SMARTでは，ソフトウェア割込みではなく，コールゲートを使ってシステムコールを実装している．それはなぜか．
システムの構成プリミティブを考えた場合，大半のマイクロカーネルはメッセージ通信に基づいた構成モデルを採用している．システムの拡張はサーバタスクの追加によって行い，send/receiveのプリミティブが提供されている．このメッセージ通信の問題点は，
- 通信オーバヘッド . コンテキストスイッチ，メッセージコピー . → Migrating Thread，LRPC(Lightweight Remote Procedure Call)
- プログラミング言語とメッセージ通信とのインタフェースギャップ . 手続き呼出しからパケットへの変換のオーバヘッド，ギャップ . → IDLなどのスタブジェネレータ(IDLとプログラミング言語間の一貫性の問題は依然存在する)
という点である．
そこで，SMARTでは，構成プリミティブとしてUPC(Unified Procedure Call)を提供している．UPCの特徴を次に述べる．
- インタフェースをプログラミング言語に統合 . 手続きの階層間の移動が容易になる(APから資源管理層へ，資源管理層からMKへ，etc)
- 拡張の単位とタスクを分離 . 細粒度の拡張が容易になる．システムはタスクとは分離されたモジュールから構成され，タスクは複数のモジュールをコンテキストスイッチなしに実行することができる．
- ダイナミックリンクを採用 . モジュール間のバインドは実行時に動的に確立されるので，手続き単位でシステムを拡張することが可能になる．
さて，UPCの実装を考えてみよう． ゲートはcallerから見れば，単なるセグメントである．つまり，ダイナミックリンクを採用しているので，手続き呼出しの際に，呼出しアドレスとしてコードセグメントを設定するのか，ゲートを設定するのかは実行時に決定することができることになる．SMARTはゲートとしてタスク間ゲート，保護空間ゲートを提供しているが，例えば，タスク間ゲートを呼び出した場合は，呼び出された手続きを別タスクで実行できる(ちなみに，タスク間ゲートと類似した機構にSpringのdoorがある)．
コードで示すと，callerがbarを実行した場合の振舞いは実行時に決定されることになる． {{{ foo() { bar(100); : } }}}
では，calleeの処理はどうなるでしょうか．ゲートのセットアップはいつ行うか．ダイナミックリンカが(ゲート作成の)スタブを自動生成してくれるような機構があるのがベストだけど(設計ではこうなっているはず)，残念ながら，現在の実装では，スタブの自動生成は行わず，ユーザがセットアップのコードを記述する必要がある．
UPCには，ここで説明したモジュール間UPC，タスク間UPCの他に割込みUPC，終了処理UPCが存在する．
また，コールゲートというとMulticsを想像する人がいるかもしれないが，Multicsのコールゲートとの違いはMulticsのコールゲートはリングレベル間の呼出しに制限されていたが，UPCはタスク間の通信や保護ドメイン間の通信に対して適用している点である．
性能評価
では，SMARTと他のマイクロカーネルにおけるシステムコールの速度を比較してみよう．データはかなり古いが森永さんの97年の論文より．測定マシンはDX4 100MHz．
[[[[[ [[[[ [処理内容][時間(us)] ]]]][[[[ [モジュール間UPC][0.898] ]]]][[[[ [タスク間UPC][113] ]]]][[[[ [タスク間UPC(非同期)][124] ]]]][[[[ [割込みUPC][12.4] ]]]][[[[ [割込みUPC(タスク間)][102] ]]]][[[[ [終了処理UPC][4.60] ]]]][[[[ [[[Mach(486 50MHz)]]][230] ]]]][[[[ [L3(486 50MHz)][10] ]]]][[[[ [[[SPIN(Alpha 21064 133MHz)]]][102] ]]]] ]]]]]
モジュール間UPCでは，コンテキストスイッチが発生しないので，MachやL3などのRPCと比較しても十分高速である．したがって，柔軟で効率的な資源管理を構築することができる．
しかし，タスク間UPC，[割込みUPC]はかなり時間がかかっている．ディスパッチャでコンテキストスイッチにかかる時間は4.58usなので，インタフェース部(SMARTは仮想マシン部，インタフェース部の2層構造になっている)の実装が非効率的であることが原因であると考えられる(コンテキストのセーブ，リストア処理など)．また，プロセッサのセグメント操作命令が低速であることも大きな問題である．
知見
UPC のアイデアは単純だけど，実装はアーキテクチャとコンパイラに強く依存してしまっていて，かなり複雑なものになってしまっている．しかし，UPC の肝はシステム記述言語とメッセージ通信のインタフェースギャップを解消するシステム構築プリミティブを提供したいということだから，カーネルレベルではメッセージ通信をベースにして，その上に UPC を構築するという実装もあり得たはずである．その方が実装がすっきりしそうだし，移植性にも優れている．
- あと困ったのが例外処理の弱さだろうか．シグナルみたいな機構を試したりもしたが，モデル的に合わなかったので，システムの混乱の元にもなった．