(toppers-users 356) Re: Toppers CPU ロック状態について

[Takayuki WAKABAYASHI]

豊橋技術科学大学の若林です。

さきにこちらから回答させていただきます。

Shigemitu Takata <takata ＠ kyoto-sr.co.jp>さんは書きました:
 >   Toppers の仕様では、
 > ***********************************************************************
 >   割り込みハンドラ入り口での CPU ロック状態は未定義（実装依存）だが、割
 > り込みハンドラが実行される時点では CPU ロックは解除状態でなければならな
 > い。
 > ***********************************************************************
 >   と考えるのですが、よろしいのでしょうか。

これは正しいです。

ここで言えるのは、
 ・出入り口処理は割込み禁止であるが、CPUロック状態であるとは限らない
 ・ハンドラ実行時は常にCPUロック解除状態 だが 割込み許可状態であるとは限らない
    #多重割込みを許可するなら 常に割込み許可状態
であるということです。
 #出入り口処理が割込み禁止というのはCPU依存ですが多くの場合そうでしょう

V850依存部では、「割込み禁止 = CPUロック」です。
割込み出入り口処理部では、もともと割込み禁止であるのと、
多重割込みで破壊されるレジスタがある関係上、割込み禁止状態です。
そのため、割込み出入り口処理部はCPUロック状態です。
多重割り込みをサポートする関係上、ハンドラを起動する直前で
割込み許可状態にしています。そのため、ハンドラ実行時点では
CPUロック解除状態になっています。

Windows依存部では、「フラグがたってる = CPUロック」です。
割込み出入り口処理部では、割込み要求元となったスレッドを
そのまま止め、割込みハンドラに当たるスレッドを起動するだけ
なので、CPUロックフラグを操作しません。そのため、割込み
出入り口処理部もハンドラ実行時もCPUロック解除状態です。
しかし、割込み要求を処理するスレッドが一つしかない関係上、
出入り口処理は割込み禁止であるようにみえます。

あくまでも
 ・CPUロック状態  = カーネルが管理している割込み/例外ハンドラ/タスクへの
                    ディスパッチ禁止
 ・割込み禁止状態 = CPUが管理している割込み/例外要求の受付拒否
であり、両者は独立だということです。

ですからCPUロック状態でカーネル内部の割込み/例外ハンドラが動いてしまっても、
ユーザの割込み/例外ハンドラ/タスクが起動しなければ問題ありません。
また管理外であると明記されていればユーザのハンドラが動いてしまってもOKです。
問題が起こってしまったとすれば、それはユーザ責任です。

--------
 >   割り込みビットがクリアされて、割り込みが不許可であっても CPU ロック状
 >   態であるとは限らない。        ^^^^^^^^^^^^^^^^

というのも正しいと思います。

たとえば多重割り込みを許可しない場合、割込みハンドラ実行中は
割込み全禁止状態のままにしておくのが一般的です。
 #不慮の事態に備えてマスクで対処する場合もあります

しかし、ここで「割込み禁止 = CPUロック状態」としてしまうと、
この割り込みハンドラ実行中は常にCPUロック状態だということになってしまい、
ほとんどのAPIが実行できません。
また、前の項目の「ハンドラ起動時はCPUロック解除状態であるべき」に反します。
 #V850依存部のテストのときにこの現象を体験しました

ここまで書いていて気づいたのですが、「割込み禁止 = CPUロック状態」という
実装で一番厄介なケースが割込みハンドラ内のソフトウェア例外要求です。
このとき、次のような状況が発生します。

 1. def_exc(TRAP_0, {TA_HLNG, trap_handler}) で ハンドラを登録
 2. def_int(xxx, {TA_HLNG, xxx_hander}) で割込みハンドラを登録
 3. xxx割込みが発生して、xxx_handlerが実行される
     << このとき、割込み許可 かつ CPUロック解除状態 >>
 4. loc_cpuを実行し、CPUロック状態へ
     << このとき、割込み禁止 かつ CPUロック状態 >>
 5. 「TRAP #0x0」を実行する
 6. 通常ソフトウェア例外はマスクできないので、要求は受理される
 7. trap_handlerが起動してしまう
     -> CPUロック状態なのにCPU例外ハンドラが起動できる

上記のようなケースの場合、TRAPでハンドラを起動する前に現在
CPUロック状態であるかどうかを判定し、CPUロック状態であれば
要求をペンディングするような仕組みを設けるか、
これらの例外をカーネルの管理外とするなどの対策法がありそうです。

利用頻度によると思いますが、個人的にはサポート外とするのが妥当だと思います。
 #関数呼び出しやタスク例外ではなく、
 #TRAPで起動しようとする意図がちょっと思いつきません

長文になってしまいましたが、以上 参考になれば幸いです。

//-------------------------------------------------
//Takayuki WAKABAYASHI (わかばやし たかゆき)
//  mailto: takayuki ＠ ertl.ics.tut.ac.jp
//-------------------------------------------------
//豊橋技術科学大学 工学研究科 情報工学専攻
//  組込みリアルタイムシステム研究室
//    Embedded and realtime system laboratory
//      Dept. of information and computer science
//        Toyohashi univ. of technology