ユーザー空間の例外処理情報を利用した組み込みシステム向け例外処理実装方式の検討

全文

(1)Vol.2011-SLDM-151 No.2 Vol.2011-EMB-22 No.2 2011/7/3. 情報処理学会研究報告 IPSJ SIG Technical Report. ユーザー空間の例外処理情報を利用した組み込みシステム向け例外処理実装方式の検討. 1. はじめに近年の MISRA C++コーディングガイドライン制定の動きに見られるように組み込みシステム開発においてアセンブラや C 言語以外の言語によるクリティカルシステム開発が広まりつつある．C と比較した場合の C++の特徴的な機能の一つに例外処理機能がある．開発言語における例外処理は，定められた区間において，例外が発生した場合に復帰する箇所でのコンテキストを保持し，例外発生時には保持されたコンテキストを使ってプログラムの状態を戻して例外処理ハンドラを実行する． C 言語でエラー処理を実装する場合には，API やシステムコールの返り値を使った条件分岐で実装する．この方法にたいしては一般に以下の問題が指摘されている．・すべての返り値に対する処理を記述することは実行上困難．・エラー処理とメイン処理が混在し，最悪の場合，保守性等に悪影響を及ぼす．・分岐が増えることによるテストケースの増大．・返り値の値が全システムで整合的にさだめられていない．開発言語の例外処理はこれらの問題の解決を指向しており，言語仕様も標準化されているため移植性や可読性に優れている．さらに開発言語や開発環境の持つ様々な機能，例えば型チェック機能などの補助も受ける事が可能である．しかし，例外区間(C++ では try catch finally 区間)設定で実行コンテキストを保存するためのオーバーヘッドや，例外区間が入れ子になった場合に発生した例外を処理する手続きを検索するためのオーバーヘッドが存在する，例外安全なコード記述の難しさなどの多くの問題点がある．組み込みシステム開発では，使用メモリの増大や応答の低下への懸念から Embedded C++の実装など例外仕様をオプションとしたり，コンパイラスイッチにより例外処理機能をオフにする場合も多く，必ずしも好意的な見方は多くはない．一方，多くのオペレーティングシステムにも例外処理機構が実装されている．例えば，Mach における exception port への通信による方式，ITRON おけるタスク例外処理機能，Win32API における構造化例外処理機能などがある．オペレーティンスシステムの例外処理機構は例外受信設定，マスク設定，例外発生などの低レベルインターフェイスを通して提供されている．そのため，様々な例外に対して柔軟に対処でき，タスク間での例外転送なども可能であるが，低レベルインターフェイスであることからくるプログラミングの難易度の高さ，およびカーネルインターフェイスの利用によるトラップのオーバーヘッドなどの問題がある．これら二つの例外処理の実装方式にはそれぞれ得失がある．しかし，組み込みシス. 左近透† 中本幸一† 一般に例外処理機構は，プログラミング言語で提供される場合とオペレーティングシステムの一機能として提供される場合がある．組み込みシステムにおける例外処理は，オペレーティングシステムの機能として提供されている．組み込みシステム開発へのC++の広まりに対応し，システム例外を含めた処理を統一的な記述が可能でかつ効率的な例外処理の実装が求められる．本論文では，組み込みシステムをターゲットした，カーネル空間側からユーザ空間側の情報を参照することによりカーネル，言語双方での例外処理の効率化を目的とした例外処理実装方法を検討する．. Discussion of an exception handling implementation method for embedded systems which used exception handling information of the user space Toru Sakon† and Yukikazu Nakano† In general, the exception handling mechanism might be offered as one function of the operating system, or be offered as programming language semantics. Major real time operating systems have exception handling functions. As C++ is becoming an attractive alternative for system development language, efficient and integrated exception handling facility will be required. In this paper, we propose the exception handling mechanism, which utilize information sharing between operating system and tasks. Also we did some preriminary investigation for implementation both language and kernel side.. †. 1. 兵庫県立大害大学院応用情報科学研究科 Graduate School of Applied Informatics, University of Hyogo,. ⓒ2011 Information Processing Society of Japan.

(2) Vol.2011-SLDM-151 No.2 Vol.2011-EMB-22 No.2 2011/7/3. 情報処理学会研究報告 IPSJ SIG Technical Report. が高いうえに，従来あるライブラリは例外安全を意識していないため，開発者が意識していないところがエラーの原因とことが想定される．また，たとえ例外安全なコードであるとしても，例外が発生した場合，通常の C++の例外処理だと入れ子になった例外構造をたどって例外を処理する関数を検索する過程でかかる処理コストが大きい．逆に言えばこれらの問題点を回避できれば，組み込みシステムで言語による例外処理の実装に妥当性が見出せるようになる．そのためには，先にあげた問題に対応して，以下の相反する傾向のある要求を満たさなければならない．・（例外処理の準備コスト削減）例外処理が発生した際に処理を戻す先のコンテキストの保存や例外発生時の準備コストを下げる．このコストには，コンテキストの保存領域の削減と保存に要する処理の削減が含まれる．・（例外処理検索コストの削減）例外受信区間が入れ子になった場合でも高速に当該処理関数を検索，起動する．このことは，上のコンテキスト保存時の処理削減と相反する場合が多い．・（例外データ）例外のデータをシステムの様々な例外に対応できるよう程度柔軟に記述できる．このことは高速検索と相反する場合が多い．なぜならば，例えば UNIX の signal のような単純化すれば，分岐は高速になるが，Java の例外処理のように例外情報が複雑化すると例外処理コストは高くなる．・（例外安全の保証）例外安全でない区間で例外が発生しないようにする．特に trap を使って例外を通知すると，例外をマスクしておかない限り任意の場所で例外が発生する．ただし，オペレーティングシステムの機構をつかう例外を阻止するためには，オペレーティングシステムの機構を使う必要がある．これも処理コストをあげる．また，システムレベル例外を扱えることから，以下の要求も発生する．・（優先度変更）システムレベルの種類によっては，処理優先度を変更し，適切なレベルで処理を実施することが望ましい．とくに処理に時間制約がある場合には，この仕様により時間内処理が実現可能となる．ただし，このときには例外処理完了を明示的，非明示的にオペレーティングシステムに通知しなければならない．以下の章ではまず，オペレーティングシステムでの例外実装および，それらが開発言語と持つ関係について述べる．. テムに従来からある実行効率の向上という要求に加えて，近年の組み込みシステムへの耐障害性への要求，障害発生部分の部分リセットなどの障害回復手段による継続的な動作，さらには非組み込み分野の技術者からの組み込み開発への参加などを考慮すると，組み込みシステム開発言語における効率的な例外処理の実装は検討すべきであると考える．さらに組み込みシステムでしばしば取り扱われるシステムレベルの例外をも取り扱うためには，開発言語側およびオペレーティングシステムの例外処理の効率的に統合しなければならない．本報告では，オペレーティングシステムおよび言語レベルでの例外処理を統合し，なおかつ効率的な実行時動作を実現するため，例外に関連した情報をユーザー空間側に設定し，カーネル空間での動作は当該領域を参照することで，カーネル，言語双方の例外処理の効率化を目指した実装方法を検討する．本報告の構成は，以下の通りである．まず，従来のオペレーティングシステムで実装されている代表的な例外処理を検討する．次に本報告で提案する例外処理モデルを提示し，最後に組み込みシステムへの実装方法の概要を示す．. 2. 組み込みシステムにおける例外処理組み込みシステムでは，例外処理はオペレーティングシステムの提供する機構により実現されることが主流である．例外は，trap もしくはメッセージ通信により通知され，その内容を処理ルーチンに投げることで，プログラムを終了や例外の原因の対処など必要な例外処理を実施する．一方，組み込みシステムでは言語側の例外処理機能は言語機能として実装されない，もしくは実装されていてもオプションかコンパイルスイッチではずすことが可能（たとえば embedded C++（文献１））となっている．理由としては，①例外処理のサポートによりコードサイズが大きくなる傾向がある，②例外が発生しない場合の実行時間に影響を与える，③例外安全なコードを書くことが困難である．④例外が発生した場合のコストが大きく，また例外処理時間が推定しにくいなどがある．しかし，携帯電話開発用の Symbian C++（文献２）では，独自の実装により例外処理を実装していた．すなわち，上記の欠点を解決すれば例外処理も組み込みシステムで有効に使われると考えられる．言語側実装による例外処理は，まず，try∼catch 区間のように例外を受信する区間を設定する．この区間が宣言されるたびに，例外発生時に処理を戻す先のコンテキストを，例外を管理する構造体に保持する．そのためのメモリおよび操作のために常にオーバーヘッドが発生する．次に例外が発生した場合であるが，例外発生により処理が中断するため，メモリの開放，獲得，または大域変数の操作などクリティカルな部分の操作を行っている最中に例外が発生するとメモリリークや動作不安定の原因となる．これを回避する，いわゆる例外安全なコードを作成することは難度. 3. オペレーティングシステムの例外処理機構オペレーティングシステムが提供する例外処理機能として（文献３），通信機能によるもの(Mach)，大域エラーハンドリングによるもの(Chimera)，例外処理カーネルイ. 2. ⓒ2011 Information Processing Society of Japan.

(3) Vol.2011-SLDM-151 No.2 Vol.2011-EMB-22 No.2 2011/7/3. 情報処理学会研究報告 IPSJ SIG Technical Report. ある．これは，例外処理ハンドラをシステムの持つ exception handler chain に登録することで行われる．すなわち，ここでは例外の発生段数は１段である．例外が発生した場合，システムは exception handler chain に例外に相当する処理が登録されているかを確認し，無ければデフォルトの例外処理ハンドラが呼び出される．ただし，タイミングのエラーについてはオペレーティングシステム側で検出され，別のインターフェイスを用いてシステムに登録される． Chimera も Mach 同様，例外を処理するシステムを作成する場合，Chimera の提供するインターフェイスを意識したプログラミングを言語の提供する例外処理機能とは別に行わなければならない．表 2 Chimera の例外機能要求事項対応表. ンターフェイスによるもの(ITRON)および構造化例外処理（Win32 API）を取り上げる．最後にあげたものは，WindowsNT 以降，開発言語(VisualC++)での例外処理の実装に利用されている． 3.1 Mach Mach（文献４）は MacOSX などの核となっているマイクロカーネル OS である． Mach の例外処理モデルでは例外処理機構はカーネルの提供する通信機能をベースとして構築されている．例外処理は，タスクに送信されるメッセージをトリガとして起動される．例外を受信する exception port と例外処理との結びつきはカーネルインターフェイス（task_set_exception_port）で設定する． Mach の例外処理モデルでは，例外を扱うアプリケーションは例外ハンドラとデバッガの２種類にカテゴライズされる．例外発生時には，関連するスレッドを停止し，例外ハンドラ（またはデバッガ）に例外通知を送信する．例外を受信した例外ハンドラ（デバッガ）は適切な処理を行い，しかる後に関連スレッドは再起動もしくは終了する．一連の例外処理は例外発生スレッドからの例外通知(raise)，例外発生スレッドの例外処理完了待ち（wait），例外処理ハンドラの例外受信(catch)，例外処理の完了と例外発生スレッドの再起動(clear)の４段階で行われる． Mach の例外処理機構は，仮想メモリの外部ページャやデバッガ等で利用されているが，開発言語の持つ例外処理と連携するインターフェイスは特に設計されていない．また，基本的にマイクロカーネルの通信機能を利用するためカーネルインターフェイスでは比較的コストが高い．また，例外安全性を保証するための機構は特に提供していない．表 1 Mach の例外機能要求事項対応表例外伝達手法. メッセージ(kernel Interface)タスク間可. 例外準備コスト. 例外ポートの作成. 例外発生コスト. メッセージ通信コスト. 例外データ. 自由度が高い. 例外安全の保証. 例外発生禁止（発信先への設定）. 優先度変更. Kernel I/F により可. 例外伝達手法. 大域例外処理（明示的な I/F もあり）タスク間可. 例外準備コスト. 例外処理の登録. 例外発生コスト. Kernel I/F コスト. 例外データ. 固定. 例外安全の保証. 例外発生禁止. 優先度変更. Kernel I/F により可. 3.3 ITRON. ITRON（文献６）は T-Engine 組み込みシステム要準開発プラットフォームにおけるリアルタイムオペレーティングシステムである．開発効率と品質の向上のため，元となった ITRON での各機能の仕様標準化に加えて基本機能やシステム管理機能のシングルソース化されている． ITRON における例外処理機構は，タスク例外処理機能として実装されている．例外発生時にはタスク例外ハンドラは例外が発生したタスクのコンテキストで実施される．タスク例外は 0 から 31 のタスク例外コードで指定される．コード 0 のタスク例外をのぞき，例外ハンドラはネストして実行されない．また例外ハンドラ処理が終了した時点で例外発生時点に戻ること，setjmp で特定の位置にジャンプすることも可能であり，非常に柔軟に利用できる．カーネル API として例外処理ハンドラの登録，マスクの設定，指定タスクへの例外通知などが用意されている．しかし，ITRON も先のシステムと同様，カーネルインターフェイスを意識したプログラミングが必要である．表 3 ITRON の例外機能要求事項対応表. 3.2 Chimera Chimera（文献５）はセンサーネットワークシステムへの適用を主眼として開発されたオペレーティングシステムである．Chimera の例外処理システムは Global Error Handling を実装している．これは返り値によるエラー処理を記述しなくても，エラーが検出されたらシステムで定義された適切なハンドラを呼ぶ機構である．このデフォルトの処理を開発者が作成した例外処理機構でオーバーライドする事も可能で. 3. 例外伝達手法. kernel I/F(タスク間可). 例外準備コスト. 例外処理の登録. 例外発生コスト. Kernel I/F コスト. ⓒ2011 Information Processing Society of Japan.

(4) Vol.2011-SLDM-151 No.2 Vol.2011-EMB-22 No.2 2011/7/3. 情報処理学会研究報告 IPSJ SIG Technical Report 例外データ. 固定. 例外安全の保証. 例外送信の停止依頼. 優先度変更. Kernel I/F により可. ・システムレベルの例外を取り扱うために，例外発生手段は，kernel I/F を利用している．・コンテキストの保存コストを下げるためには，ハンドラ構造もしくは Chimera のように大域例外もしくはそれをオーバーライドする構造をとっている．・ Win32 API における構造化例外処理は，言語側の例外処理構造を意識したカーネル API となっている．しかし，コンテキスト保持や例外発生の方法などは言語側に依存した構造となっていることが例外処理コストの高さの要因となっている．・逆に，Win32 API 以外では例外にかかる情報がオペレーティングシステム側にあるため，利用に際して trap のコストを考慮しなければならない．そこで，例外発生の処理はオペレーティングシステム側で行うが，それを管理する管理構造をユーザー空間側におくことで，以下の目標を実現をめざす例外処理方式を検討する．・例外管理構造（マスク，例外受領制限など）をユーザー空間側におき，その情報をオペレーティングシステム側が参照する事により，trap のコストを押さえつつ例外の管理や例外安全区間の設定を行う．・コンテキストの保持や例外の発生は，kernel I/F で行うが，伝達される例外データは，最大サイズがあらかじめ決められているユーザ空間側の例外データ保持領域に格納することにより，ある程度柔軟な例外情報の設定を可能にし，かつ，自タスク内での例外発生通知のコストの低下も実現する．・例外受信ブロックの開始と終了を，関数呼び出しの開始と終了に合致させる．このことにより，コンテキストの保存や例外発生時のコンテキスト復旧処理が大幅に削減される．. 3.4 構造化例外処理 (Win32 API) Windows NT 以降のシステムでは Structured Exception Handling（ SEH 文献７，８，９）とよばれる例外処理機構が提供されている。この SEHWin32 API では，コンパイラとは独立の例外処理用 API を提供している．Microsoft 社の開発環境(Visual C++) などではこれらの API を利用してプログラミング言語の例外処理機能の実装を行っている．アプリケーション内部で例外を発生させるには RaiseException()を利用する．この API は指定された例外コードと入力パラメータ配列を持つ例外を発生させる．例外を補足する例外処理ハンドラは，try{. . .} except{. . .} finally{. . .}，ブロックを作成した際にスタック上に確保される EXCEPTION_REGISTORATION 領域にポインタが記載される．この領域は chain 構造となっており，例外発生時に処理を実施するハンドラを検索するにもなっている．一方，最も最後に設定された例外ハンドラへのポインタは，EXCEPTION_REGISTRATION データに，そして当該データへのポインタはメモリの特殊領域(thread information block)に確保される．例外発生の際には，これを逆にたどって例外処理ハンドラに処理を渡す．例外処理ハンドラでは，フィルタルーチンである GetExceptCode( ) を使って当該例外の情報を引き出して処理を進める．この機構はプロセス内で閉じておりプロセス間での例外受け渡しは実施できない．また，システムコールを用いることによるオーバーヘッドも同時に存在する．表 4 Win32 API の例外機能要求事項対応表例外伝達手法. kernel I/F(タスク間不可). 例外準備コスト. コンテキスト保存. 例外発生コスト. Kernel I/F コスト＋コンテキスト復旧. 例外データ. 引数の配列. 例外安全の保証. 例外送信の停止依頼. 優先度変更. 不可. 4. 処理モデル本論文では，カーネルとスレッドで例外に関する情報を共有することで例外関連処理の高速化とタスクレベルでの例外実装の統合をはかる．特徴は，①タスク内領域に例外情報格納用に設定されたレジスタ様領域およびその情報の退避領域を設定し，② 例外の入れ子定義は，退避領域への例外情報の退避／復旧操作で定義する．そして例外そのものは③タスクが実行状態になったときに初めて検知される一種の遅延実行として実現する． 4.1 例外情報保持領域タスク側ではスレッドごとに例外に関わる情報を保存する領域を設定する（図１）．当該領域は，①処理分岐先（必ずしもコールバック関数である必要はない），例外マスク値，例外を設定したアドレス，再帰的なプログラム構造の場合の再帰回数のカウン. 3.5 比較先の節でいくつかのオペレーティングシステムでの例外処理機構について分析した．結果，オペレーティングシステムにおける例外処理の実装には以下の特徴がある. 4. ⓒ2011 Information Processing Society of Japan.

(5) Vol.2011-SLDM-151 No.2 Vol.2011-EMB-22 No.2 2011/7/3. 情報処理学会研究報告 IPSJ SIG Technical Report. トなど，例外が発生した場合に直接参照される情報を保存する例外処理情報保存領域， ②例外処理が設定されている区間で，さらに別例外処理を設定する場合に，前に設定されていた①の情報を退避する例外情報退避領域および③例外が発生した場合，発生した例外の種類を区別するための情報を保存する例外引き渡しパラメータ領域，の３つの領域である．. 別タスク，別スレッドもしくはシステム側からあるタスクへの例外通知をサポートするために，カーネル側のタスク管理では④発生した例外を保存する領域および， ⑤セマフォやロックなどの資源獲得待ちや，通信完了待ちなどの待ち状態で例外が発生した場合や，逆に資源獲得状態の際，例外発生時にそれらの資源を解放するための，コールバック関数やパラメータを保持する領域および⑥タスク空間とカーネル空間でのデータの引き渡しを行う領域を追加する．なお，最後の⑥の領域はユーザ空間に設定されたものを使用する． 4.3 例外設定時動作スレッドは例外処理設定区間に入った時点で，処理分岐先やイベントマスク情報を ①の例外処理情報保存領域に設定する（図３）．このとき，以前に設定されていた例外処理情報がある場合には②の例外処理退避領域にそれらの情報を退避する．例外処理が完了した場合や例外が発生せずそのまま例外処理設定区間から抜けた場合は，例外処理退避領域から例外処理情報保存領域に退避した情報を復旧する．また，言語使用上例外の発生が好ましくない状態，たとえばデストラクタを動作させている場合などは，例外設定情報領域で例外の受信を禁止するフラグを立て，例外の通知を抑制する．なお，例外処理で必要な，継続についての情報の保持については，言語実装レベルで解決するものとする．. 図 1 タスク側での例外処理関連領域 4.2 カーネル側例外情報. カーネル側では，発生した例外に関する情報を保持する（図２）．. 図 3 タスク側から例外処理関連領域処理（例外発生なしの場合）図 2 カーネル側の例外処理関連領域 5. ⓒ2011 Information Processing Society of Japan.

(6) Vol.2011-SLDM-151 No.2 Vol.2011-EMB-22 No.2 2011/7/3. 情報処理学会研究報告 IPSJ SIG Technical Report. 領域中の処理分岐先に設定，処理を移行する．. 4.4 例外発生時の動作例外が発生した際には例外処理保存領域にあるマスク情報および処理分岐先情報を参照して処理を移行する．例外が発生するパターンとして，①自タスク内部で例外が発生した場合（図４）と，②他タスクやカーネルから例外が通知される場合がある（図５）．①の場合には，例外処理情報保存領域に例外の内容をセットし，空の kernelI/F 呼び出しを実施する．このことによりタスク内部での例外発生時にタスクカーネル間のデータコピーを削減し，処理の高速化をはかる．. 図 5 タスク外からの例外の受信 4.5 言語実装との関係. 言語側の実装は，例外制御を例外情報設定領域に設定し，オペレーティングシステムからの例外情報がくる事を制御する事が中心となる．ただし，例外安全を確保するために，以下の動作を行う構造を追加する． ① 例外は例外発生許可カウンタが０のときに通知される． ② 例外安全でない区間を呼び出す直前に，例外発生許可カウンタを一つあげる．このとき例外が発生したら始めの例外のみを例外としてそのデータを例外内容の保持領域にセットする． ③ 例外安全でない区間から出る際に，例外発生許可カウンタを一つ下げる． ④ 例外発生カウンタが０の時点で，待ちの例外があれば例外を発生させる．この構造により例外安全が確保されていない区間での例外発生の阻止と，発生した例外の受領を両立する．また，例外受信区間を関数呼び出しの構造と同一構造をとることにより， ① 戻すべきコンテキストは，当該例外受信区域に相当する関数呼び出しの時点となり，保持すべきコンテキストおよびコンテキスト復旧の手続きが容易になる． ② 例外が発生した場合には，例外は当該関数に渡す引数の一つとして扱う．これ. 図４タスクレベルでの例外発生時処理 ②の場合，例外の通知は例外を受信するタスクへの例外メッセージ送信に類似した手法をとる．通知された例外に関する情報はタスクにひも付けされる．例外を受信するタスクは，a.実行状態でタイマー割り込みなどにより周期的にカーネル処理に移行しているか，b.スケジューリング，排他資源やメッセージ待ち，外部からの suspend 実行などにより非実行状態となっているかのいずれかである．いずれにせよカーネルからの復帰の際に，カーネル内から例外処理情報保存領域を参照して例外の有無を確認し，当該例外であれば復帰時の処理を例外処理実施関数へ分岐させる．指定されたスレッドに例外が通知された場合，カーネル側では，タスク領域にある例外処理情報保存領域を参照し，当該スレッドが受信可能な例外ならば，⑤の領域に例外情報を設定する．例外処理の実施は，スケジューラによる処理状態への復帰やシステムコールや IO／クロック割り込みからの復帰の際に実施される．割り込みやスケジューラから復帰する際に，CPU に当該スレッドの情報を復旧するが，例外が発生している場合には，当該情報ならびに発生した例外に関するパラメータをいったんタスク共有領域にコピーする．そして処理の戻り先をスレッド側にある例外処理情報保存 6. ⓒ2011 Information Processing Society of Japan.

(7) Vol.2011-SLDM-151 No.2 Vol.2011-EMB-22 No.2 2011/7/3. 情報処理学会研究報告 IPSJ SIG Technical Report http://www.codeproject.com/KB/cpp/exceptionhandler.aspx. により例外処理の検索は，引数による分岐と同じ簡単な構造となる．. 5. 考察と課題今回，構造化した例外情報をタスクとカーネルで共用し，タスク内およびタスク外部からの例外処理に統一した構造を提案した．この構造をとる事により，カーネル側の処理およびタスク側の例外処理を統合し，かつ，例外処理時に発生させられるシステムコールオーバーヘッドなどを軽減する方式を検討した．一方，本提案で解決していない，または解決必要な問題点として，マルチスレッドプログラミングに対する検討と，セキュリティ問題が残存している．すなわち，ユーザー空間に例外処理情報をおく事により，例外情報の破壊，読み出しなどのリスクが懸念される．これは本質的には，Win32API も同じ問題点を持つと考えられる．そのため，Win32API で行われている様々なセキュリティ対策が参考になると考える．さらに，本機構では，プロセス間での例外の伝搬を認めているため，例外送信の可否を判定する機構をカーネル側例外処理機能に実装する必要がある．今後，これらの点をも勘案し，システム実装を通した実用性および性能の検証を進める．. 参考文献 1) Embedded C++ Homepage http://www.caravan.net/ec2plus/ 2) リチャード・ハリソン:Symbian OS C++ プログラミング,ISBN-4798105627,翔泳社(2004) 3) Lang, J. and Stewart,D.B.: A Study of the Applicability of Existing Exception-Handling Techniques to component-Based Real-Time Software Technology,CAN Transactions on Programming Language and Systems, Vol.20,No.2,PP274-301(1998) 4) Black,D.L., Golub, D.B., Hauth, K.,Tevanian, A., and Sanzi, R.:The Mach exception handling facility. Tech. Rep. CMU-CS=88-129, School of Computer Science, Carnegie Mellon Univ. Pittsburgh, Pa (1988). 5) STEWART, D. B., SCHMITZ, D. E., AND KHOSLA, P. K. :The CHIMERA II real-time operating system for advanced sensor-based control applications. IEEE Trans. Syst. Man Cybernet. 22, 6, 1282–1295. (1992). 6) T-Engine フォーラム編,T-Kernel 標準ハンドブック，ISBN-4-89362-229-3 パーソナルメディア社．(2005) 7) CUSTER, H. Inside Windows NT. Microsoft Press, Bellevue, Wash. (1993) 8) A Crash Cource on the Depths of Win32 Structured Exception Handling http:// www.microsoft.com/msj/0197/exception/exception.aspx 9) How a C++ compiler implements exception handling 7. ⓒ2011 Information Processing Society of Japan.

(8)