OSDN -- オープンソース・ソフトウェアの開発とダウンロード
日本語の翻訳状況 translation status for ja

フォーラム: 開発者 (スレッド #3528)
話題(スレッド)一覧に戻る RSS

起動キューイングされたタスクのext_tsk (2003-10-12 23:27 by m-arai #6144)

多分致命的なバグが発見されました。

今の所、美しい解法は見つけていませんが、一応その問題
について修正パッチを作成し、Patchesに登録しました。

[#3133] 起動キューイングされたタスクのext_tsk
https://sourceforge.jp/tracker/index.php?func=detail&aid=3133&group_id=183&atid=780

mknl層にkernel層が混じっていたり、これが生きてくる局
面は滅多に無いであろうと予想されるにも関わらず、常に
ディスパッチにおける処理が増えてパフォーマンスが低下
する等、かなりのやっつけです。

目からウロコの新案募集。

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 15:07 by m-arai #6146)

かなり強引な2版も上げておきました。

果たして本当に安全なのか、他プラットフォームでも
同様な真似が出来るのか、その辺が不明ですが…。
#6144 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 21:46 by hamayan #6157)

すいません、このスタックの余裕度(伸張度)はどれ位でしょうか。

あまりぎりぎりにスタックを設定すると、単にスタック不足で落ちているとかになりかねないので。
#6144 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 22:10 by m-arai #6158)

えーと、自タスクを起動するために、スタックの底にエン
トリ番地や拡張情報等をコンテキストスイッチで交換する
レジスタ分積む処理が、スタックで現在使用している部分
を破壊したり、その逆が起きたりする可能性があること
が、この問題の肝です。

従って、余裕度はあまり関係無くて、ext_tskした時の
スタックポインタが、hospac_cre_ctx_asmで上書きされる
領域と被っているかどうかに関わってくる…

と思ったら、現状ではどうあろうとext_tskの終わりに
その瞬間に既に無効なタスクコンテキストからのディス
パッチが生じるので、折角hospac_cre_ctx_asmで初期化
したコンテキストは破壊されてしまうのでした。
これではスタックが伸びていようとどうしようとダメです
ね。

スタック云々については忘れてくださいmOm。
問題発生条件は、起動キューイングされていることだけで
お願いします。
#6157 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 23:11 by hamayan #6160)

そうですか、

今、patchesに上げられたサンプルではないのですが、二つのTASKを同一優先度、TA_ACTで起動し、
task1に相当するタスクからtask2に相当するTASKをact_tskし、
その後定周期でメッセージを表示、task2はメッセージを表示後、ext_tskするプログラムを動作させていますが、
これがちゃんと動いちゃうんです。TASK2は二回メッセージを表示。

もちろん、パッチを当てる前のカーネルです。
#6158 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 23:33 by m-arai #6162)

その場合、本当にact_tskと目的のタスクの起動回数は
一致していますか？ちょっとした偶然で、致命的になら
ない場合が有り得るのではないかと、今は疑っています。

Pactchesの方に書いてあるサンプルで一番最初に
現状をテストした時は、確かにキューイングカウントは
1になっているのにTask2は再び起動せず、Task1は死なない
という謎な状況になりました。
…それで、更にact_tskを一回追加すると暴走しました。
#6160 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 23:47 by hamayan #6164)

起動回数は一致していると思われます。
つまりTA_ACTの一回と、act_tskの一回です。

偶然動いちゃっている？と言うのはきっとそうだと思います。

Ryuzさんの指摘を考慮してtask2相当のTASKは、入ったらメッセージの表示も無しに、いきなりext_tskさせましたが、
Task1側は動いている・・・。

新井さんのコードと同じ物を用意して動かすのも、検証としてはなんなので、
今アプリケーションを書いているコードを流用して検証しましたが、
再現性が低いのは、私自身になんか有るんだろうなあ、と不安になってきたりして。
#6162 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 23:51 by m-arai #6165)

といわれると何かこちらも不安になってくるんですが…
起動要求キューイングは確かに発生してるんですよね？
#6164 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-14 00:47 by hamayan #6167)

取り敢えず極端な事をしないと判らない可能性が有るので、
Task1から連続4回act_tskしてみました。

見事暴走しています。
メッセージを見ると、2回までは耐えて見たみたいですが、3回目で失敗しています。

次は対策版でやってみます。
#6165 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-14 01:17 by hamayan #6168)

アー良いですね。

2版の方のパッチをルネサスに展開して動かしてみましたが、
4回起動すれば、ちゃんと4回答えてきます。
#6167 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 10:27 by hamayan #6268)

pacctx.srcを手元で修正して実験中なのですが、私以外にSH2を触る方が出てきたので？、Pacthesにpacctx.srcのパッチを上げてみました。

お試し下さい。
#6168 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 10:54 by m-arai #6269)

↓はアセンブルが通らないような？
　mov.l　#_kernel_int_sp,r4
最後のレジスタ復帰も、既にスタックが切り替えられて
しまっているので無意味のような。
　rts
　mov.l　@r15+,r4

hospac_int_ctx()は、スタックポインタ(r15)をkernel_int_sp
にするだけなので、
　　mov.l　L_int_sp, r0
　　rts
　　mov.l　@r0, r15　; 割り込み用スタックを設定
だけでいいと思ったんですが。

＃最近SHも触ってないから…いい加減かも(--;

それと、実は起動キューイングされたext_tsk修正差分は
既に3版になってますのでご覧下さい。動作検証はして
いませんが、SH版も作業してあります。
#6268 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 11:02 by hamayan #6270)

＞ ↓はアセンブルが通らないような？
＞　mov.l　#_kernel_int_sp,r4

ルネサスのアセンブラの場合、勝手に領域確保してくれるので、大丈夫です。


＞それと、実は起動キューイングされたext_tsk修正差分は
＞既に3版になってますのでご覧下さい。動作検証はして
いませんが、SH版も作業してあります

すいません、H8300H版を参考に、同じ様にしたつもりでしたが、3版が有ったのですね。
流石早い、と言うか、調べろよおれ！
#6269 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 11:29 by m-arai #6271)

Trackerアイテムも「モニター」出来ますよ。

arm並びにia32gccの__asm__は、私にとって呪文の類なの
で、かなりいい加減です。
#6270 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-22 06:54 by tkato #6325)

加藤です。

すみません、IA32では、
パイプラインに極力影響を与えたくない
という理由から、インラインアセンブラを
使ってます。
#最近の石だと結構効果が高いので・・・

やんなきゃと思いつつ、仕事にかまけて
さわってませんでした。
えーと、IA32なにかいじるところありますか?
何とか時間をとってやりますが・・・

#そういえば、asmの処理は、原則インクルードで
#吸収するようにしてたのですが、Cソースに
#埋めこんでるとこが残ってましたね。
#近日中に修正します。
#6271 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-22 06:58 by tkato #6326)

加藤です。

というか、まずテストですね。
今週末にでも作業します。
重ね重ね申し訳ないです。
#6325 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-22 22:33 by m-arai #6339)

いくつか提案していますが、今一番新しい修正案ではCPU
依存部に次の2点の対応が必要です。

1. 起動キューイングされたタスクの動作中にext_tsk()
が呼ばれた場合、mknl_sta_tsk()→hospac_cre_ctx()
においてスタックの頭(番地的には末尾)がタスク起動
データで上書きされるが、それがスタックの現在使用部分
と干渉しないことをタスクへのエントリ部分で保証する。

具体的には、初期化データが書き込まれる分だけスタック
ポインタを進めることです。Cのレジスタ保存則や生成され
る関数エントリによっては不要な場合もあります。


2. 終了したタスク実行状態からのコンテキストスイッチ
発行用に、現コンテキストを保存しないhospac_chg_ctx()
を追加する。

起動キューイングされているタスクがext_tsk()で終了
する際のディスパッチで、既に次回のタスク起動
の為に更新されているコンテキスト情報を上書きしない
ために必要です。

コードを共有するため、hospac_swi_ctxの引数の順番を
入れ替えています。


う～ん、こんな風でちゃんと伝わるかどうか？？？
取り敢えず、Patchesに上げてある修正差分のh83用を
参考にしてみて下さい。ia32の部分も何やらやってあり
ますが、それは無視してください。ダメだということは
確認済みです。



それと、これは以前聞いてみようと思っていてすっかり
忘れていたのですが、include/ia32/hospac.hにgccに
依存した__asm__の記述がそのまま(#ifdef等で括ること
もなく)あるのはどうでしょうか？今の所gccのみですし、
サポートコンパイラが増える予定がある訳でもないので
どうでもいいことかもしれませんが。
#6325 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-22 23:57 by tkato #6341)

加藤です。

了解しました。
ご提示頂いた2点やってみます。

あと、
include/ia32/hospac.h
の件は、
ia32gccと思いこんでいたので、それに
気づかなかったのです(あぅ)
まあ、最近はインテルの(非商用利用にかぎるんだっけか)フリーコンパイラとかもあるので
まあ、gccに限らない方が良いと思います。
#インテルのはGNU拡張を解釈するようですが
そっちも、今週末に対応したいと思います。
#6339 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 11:55 by hamayan #6272)

sh2htのpacctx.srcを3版のパッチを当てて、カーネルライブラリの再構築を試してみたら、2箇所で問題が出ています。

diffの880行目で、実行コンテキストの切り替えをEXPORTしていますが、これがラベル不明のエラー。
914行目で_hospac_swi_ctxが多重に宣言されている。
です。

多分914行目が_hospac_chg_ctxだったのかな？と踏んでいるのですが。
#6270 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 12:02 by m-arai #6273)

ああ、そのようです。

+　　mov.l　r15, @(0, r5)　;　スタックポインタ保存
+_hospac_swi_ctx:
+　　mov.l　@(0, r4), r15　;　スタックポインタ復帰

の_hospac_swi_ctxは_hospac_chg_ctxの間違いです。
コピーして修正するのを忘れていたみたいですね。
日立版はコンパイルもしていないのでmOm
#6272 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 13:32 by hamayan #6283)

もうひとつお願いします。

3版パッチの1028行目辺りからヘッダーファイルの修正に入るのですが、

Index: includehosdenv.h
===================================================================
RCS file: /cvsroot/hos/hos/hos-v4/include/hosdenv.h,v
retrieving revision 1.8
diff -u -r1.8 hosdenv.h
--- includehosdenv.h 1 Apr 2003 23:28:45 -0000 1.8
+++ includehosdenv.h 14 Oct 2003 12:44:06 -0000

でincludeパス以下のスラッシュが抜けている為か、ヘッダーファイルの更新が行われませんでした。
#6273 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 17:14 by m-arai #6292)

重ね重ね済みません。余計な/を排除した時に、誤って必要
な分まで削除してしまったみたいです。

それにしても、スタックを強引に切替えるこの策は、危険
だし不細工だし、保証の限りではないんですよねぇ。

あともう一つ考えはあって、ctx_entryでcre_ctx中で潰さ
れる分だけスタックポインタを進めておくというのものな
んですが、これだとまぁ安全だしスタックに触らなくて済
みます。ただ、スタックが無駄に消費されてしまうのが難
点で。

中々妙案は浮かびません。
#6283 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 17:29 by hamayan #6293)

＞それにしても、スタックを強引に切替えるこの策は、危険
＞だし不細工だし、保証の限りではないんですよねぇ。

成る程ですね。
実際の所、このスタック操作を理解している訳では無いのですが、元々Ryuzさんの思想として、スタックをいじるような場面を小さくして、移植性を良くするのが有ったと思いますので、多少スタックサイズが増えても、m-araiさんの、美しいと思える実装の方が、後々宜しいのでは！と思います。

動作確認等は任せて下さい。それくらいは出来ます。
#6292 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 17:33 by hamayan #6294)

ああそうか！
m-araiさん的にはどちらも決定的な程美しくないんですね。

では、後の方の案に賛成します。
パッチを作って頂ければ、試します。
#6293 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-20 19:25 by m-arai #6297)

貧乏性な私にとっては、無駄も美しさからは遠いのです。
(--;

言葉は容易いんですがねぇ。
#6294 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-28 11:25 by hamayan #6383)

遅くなりましたが、zomb3を当てようと作業しています。
が、以下のメッセージが出て、パッチが当たらないみたいなので、申し訳ございませんが、パッチの当て方を教えてもらえないでしょうか。

C:\projects\homesjis\hos\hos-v4>\patch < zomb3.dif
patching file `src/arm/arm/pacctx.s'
patch: **** malformed patch at line 27:

現在は、WIN2KのDOS窓から起動しています。
zomb3.difはSJISに変換しました。
patch -p4でも、-p5でも同じです。

すいません、不慣れで。
#6297 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-28 12:29 by m-arai #6384)

う～ん、手元では、

C:\cvs\o\hos\hos-v4>patch < d:\z3.dif
…(略)…
patching file `src/sh/sh2ht/pacint.src'
Hunk #1 FAILED at 169.
Hunk #2 FAILED at 938.
2 out of 2 hunks FAILED -- saving rejects to src/sh/sh2ht/pacint.src.rej
patching file `src/sh/sh4gcc/pacctx.s'

という風に、CVSから取得したソースをcvssyncでSJIS
CRLFに変換したものに一応最後まで当たっているのです
が…
(最後の2つのrejは、この間_HOS_int_cnt/_HOS_int_sp
の修正が入ったせいです。)

もう一度CVSからソース、Trackerから差分を取り直して
やってみて戴けないでしょうか。
また、使っているpatchは何ですか？私がWin上で確認した
のに使ったのは、例のWinCVS 1.2の日本語対応版に同梱
のものです。

arm関連はそもそもテストするレベルにあるか怪しい状態
ですし、hamayanさんのところにテスト環境があるとも
聞いていませんから、差分からエラーの出る
'src/arm/arm/pacctx.s'の部分を削除してしまうという
後ろ向きな対策もあります。
#6383 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-28 13:16 by hamayan #6385)

CVSからの取得の件は了解しました。
現在のカーネルは確かリリース版を使っています。
既に幾つか出ているパッチを当てたものです。
但し、今回の一連のext_tskに関するパッチを当てる前の物です。

patchも実は何処から？か判らなくなりました。
patch -vでは

patch 2.5
Copyright 1988 Larry Wall
Copyright 1997 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall with lots o' patches by Paul Eggert

と出ます。
うーん、環境めちゃくちゃです。
#6384 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-28 19:55 by m-arai #6392)

私の試したpatchは、

C:\>patch -v
patch 2.5
Copyright 1988 Larry Wall
Copyright 1997 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall with lots o' patches by Paul Eggert

です。同じものかな？不正なオプションを与えると
こんなのが出ます。

C:\>patch ---
C:\PROGRA~1\GNU\WINCVS~1.2_J\PATCH.EXE: unrecognized option `---'
patch: Try `C:\PROGRA~1\GNU\WINCVS~1.2_J\PATCH.EXE --help' for more information.

日本語化されたWinCVS 1.2をデフォルトでインストール
した結果、このようなパスに入っています。
#6385 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 23:27 by ryuz #6161)

　お世話になります。Ryuzです。

> その瞬間に既に無効なタスクコンテキストからの
> ディスパッチが生じるので折角hospac_cre_ctx_asm
> で初期化したコンテキストは破壊されてしまう
> のでした。
> これではスタクが伸びていようとどうしようと
> ダメですね。

　タスクコンテキスト時に現状保存の為に破壊する
領域は現在のスタックポインタ位置で、
hospac_cre_ctxで書き込むのは、スタックポインタ
初期位置なので、ext_tsk呼び出し時にスタックが
十分伸びていたら動いちゃいそうな気がします...


#6158 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-13 23:37 by m-arai #6163)

いや、私も最初はそう思ったのですが、次に生じる
コンテキストスイッチで、「その瞬間は既に無効である
コンテキスト情報」により「次の起動に備えて初期化され
たコンテキスト情報」が上書きされてしまうので、正しく
タスクが起動されることはありません。

致命的でないデータで上書きされることは有り得る
と思いますが…。
#6161 への返信

RE: 起動キューイングされたタスクのext_tsk (2003-10-14 00:45 by m-arai #6166)

最初のテストで起きたことを順を追って考えてみます。

actcnt==1で迎えたext_tskの最後のディスパッチの時、
自タスクが最高優先順位なので、コンテキストスイッチは
生じない(その場ではコンテキスト情報の上書きは起きない)

で、ext_tskからそのままリターン→kernel_tsk_entryに
リターン→kernel_tsk_entryで"再び"ext_tsk

今度はactcnt==0で、しかもレディキューから外れてい
るので、必ず別のコンテキストにスイッチ、コンテキスト
破壊発生、但し(キューイングされた分起動しないことを
除いては)致命的問題にはならない。

actcnt == 2の状態でext_tskを迎えると、kernel_ctx_entry
にリターンして迎える2度目のext_tskでも、actcnt==1な
のでレディーキューから削除されず、いずれkernel_ctx_entry
からのあての無いリターンをすることになる…。

ということだと思うんですが。

考えてみると、kernel_ctx_entryを経由しているので、
いくら関数呼び出しのネストが低い状態でも、タスク実行
中にスタックの頭の方に触ってしまう可能性は低いのでは
ないでしょうか？
#6163 への返信

タスク実行と自タスクコンテキスト生成は衝突するか？ (2003-10-14 10:12 by m-arai #6176)

起動要求キューイングされている場合のext_tskで、現在
実行と自タスクコンテキスト初期化情報設定のスタックの
衝突が起こり得るのか、h83 gcc 3.3.1の場合を例に考え
てみました。


kernel_task_entry()にジャンプしてきた時、スタック
ポインタはスタック領域の底を指している。

現在のコンパイルオプションだと、
_kernel_task_entry:
　　mov.l　　er4,@-er7
　　mov.l　　er5,@-er7

ということで8byte分の(無意味な)レジスタ保存がある
ため、スタックの底には8byteの触れない部分が生じて
いる。

hospac_cre_ctx_asmでコンテキスト初期化用情報が
置かれるのは底の12byte分。但し最後の4byte分、
即ちer6の分はポインタデクリメントのみで実際に値は
書きこまれないので、実質8byteとなる。

よって、kernel_task_entry()以上(=正常にタスクが実行
されている状態)の関数呼出しネストレベルでは、コンテキ
スト生成操作が動作中のスタックを破壊することや、その
逆は起こらない。


しかし、結果としてkernel_task_entry()においてコンテ
キスト生成処理で書き込まれる部分が保護されるという
この状況は、プロセッサ、使用するC、コンパイルオプ
ションに依存するものであり、これを一般に保証されたものと認識することは出来ない。

結論としては、タスク実行中の自タスク開始の際には、
スタック切り替えを行ってコンテキスト生成と現在使用
スタックの衝突が発生しないことを保証しなければなら
ないということになる。
#6166 への返信

ext_tskへのパッチで判らない事が有ります (2006-04-04 21:56 by hamayan #21011)

ext_tskへのパッチの中に、mknl_srh_topへのパッチが有りますが、このパッチは優先度別キューの範囲を越えた位置の参照を行っていないでしょうか？。

+ /* 登録予約タスクを全てレディキューに接続 */
+ if ( ( mtcb_head = mknl_rdq_tbl[mknl_rdq_cnt].head ) != NULL )
+ {


ちなみに最大優先度数を8とした時のkernel_cfg.cの出力は
/* ------------------------------------------ */
/* create ready queue */
/* ------------------------------------------ */

T_MKNL_QUE mknl_rdq_tbl[8];
const INT mknl_rdq_cnt = 8;
です。

敢えてこの様になっていたのなら、すいませんです。
#6144 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-04 22:07 by hamayan #21012)

すいません、コンフィギュレータへのパッチが正しく当たっていない様です。
#21011 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-04 22:19 by m-arai #21013)

確かアレはわざとです。言うなれば'優先度0の掃除屋'を
作って、問題の回避を狙っていた…筈…だよなぁ…。
当然、コンフィグレータもそれにあわせて改造します。
多分どこかに書いたと思いますが、これを適用すると
微妙にITRONの規定する振る舞いと違いが出ます。

更に言うと、「最新版」(2003-10-20 19:13！)だと、
その手は棄てています。

実は3ヶ月程前、この件の解決策を閃いたような気が
しているのですが、全く手が動いていないので、錯覚か
どうかの確認もとれていません。(^^;

アイドルコンテキストを流用することで、CPU依存部に
手を加えることなく問題回避が出来る…かも。
#21012 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-04 23:15 by ryuz #21014)

Ryuzです。

本件、私の大ポカから話が続いていて申し訳ないです。
タスク先頭へのlongjumpに相当する(つまりタスクをリセットする)関数をPACに設けておけばよかったのですが....
PACはプロセッサの種類分派生してしまっているので、修正が厄介ですよね...


> アイドルコンテキストを流用することで、CPU依存部に
> 手を加えることなく問題回避が出来る…かも。

に、すごーく期待しています (^^)
思い出してくださいまし
#21013 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-05 00:06 by m-arai #21015)

>> アイドルコンテキストを流用することで、CPU依存部に
>> 手を加えることなく問題回避が出来る…かも。
>
>に、すごーく期待しています (^^)
>思い出してくださいまし

あまりに単純なので何ですが、書いてしまうとこういう
ことです。即ち、自コンテキストが無効な時の
コンテキストスイッチに関して、現コンテキストの
保存先をアイドルコンテキストにしてしまうのです。

この改造の副作用により、アイドルコンテキストでの
処理は常時ランダムなタイミングでの中断、先頭
からの再入を許すものでなければならないという
制限が付き、アイドルコンテキストへのスイッチを
行う際には、同コンテキストのセットアップを
必要に応じて行わなければならなくなります。
この2点は、アイドルコンテキストの在り方を考えると
特に大きなマイナスにはならないと思いますけど。

素朴に過ぎ、本当にこれが解決になるのか疑問が…
後は手を動かすだけなんですけどねぇ…

誰か
　その案はかくかくしかじかで駄目！
あるいは、
　やってみたら出来ました。はい、パッチ。
と言ってくれないだろうか。
#21014 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-11 00:01 by ryuz #21145)

Ryuzです。
しばし悩みましたができそうな気がしますね...

下記のような動作ですよね？

1) exinf にタスク情報もらって、それのタスクを生成した後、アイドルに飛ぶルーチンを用意
2) ext_tskで、アイドルコンテキストを、自タスクをexinfに渡して1)を実行するように再生成して、アイドルに swi_ctx

で、もって、めでたく ext_tsk に入ったタスクは、アイドルコンテキストから再生成してもらえるので自殺せずにすむと (^^;;

どないですかね？ あってますか？
#21015 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-11 07:28 by m-arai #21153)

私の思いつきはもっと単純なものでした。

基本的には、起動キューイングされている状態での
ext_tsk実行の際のmknl_exe_dsp中のhospac_swi_ctxの
引数、ctxinf_runを&mknl_idlctxにするだけです。
それに伴い、アイドルコンテキストへのスイッチの
場合は、(何らかの判別を入れない限り)無条件に
アイドルコンテキストの初期化を行ってから
ということになります。

ryuzさんのでうまくいきそうな感じがしますね。
#21145 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-11 22:46 by m-arai #21173)

更に考えてみると、ryuzさん案の方が環境依存性が
少ないと言うメリットがあるかな？と思い始めました。

この件に関しては二つの問題があって、

a. もはやゾンビとなったタスクがコンテキスト
スイッチによって成仏する際、すぐ次の復活に備えて
自ら整えたコンテキストを無効な情報で潰してくれる

b. 次の復活に備える作業の成果が、成仏の瞬間を
待つまでも無く、ゾンビとしての活動で破壊されている

ryuzさんの案なら、aは勿論のこと、転生する
コンテキストとは別なアイドルコンテキストで
その作業が行われるため、bの危険性がありません。

私がかつて出した修正案の一つか二つも、スタックを
割込みスタックに強制的に切り替えるとか「優先度0」の
コンテキストを作ってタスクの再生を担当させる
ようなものがあったと思いますが、それぞれに
イケてない部分があって棄てました。

先日思いついたアイドルコンテキストをゾンビの屍骸
置き場として流用する方法だと、aは問題ないですが、
bは環境によっては保障できません。

ext_tskが呼ばれる場合で最もスタックの伸張が小さい
のは、kernel_task_entryの最後のext_tskです。

このkernel_task_entryのエントリで伸びる分と
ext_tskへのサブルーチンコールで積まれる帰ってこない
リターンアドレスの分、これらの和がhospac_cre_ctx_asmで
スタックの底に積まれる量を超えていないと、bからの
安全を保障出来ないのです。

それを避けるために、前もってスタックポインタを
生成情報分だけ引いておくなんていう泥縄な策も
提案したような…それだと使えなくて勿体無いメモリが
スタック領域の底できてしまって嫌な感じが。

H8/300H gccにおいては、bについては問題は無かった
と思いますが、一般にそれを保障することは出来ません。

はぁ、はぁ、思いのほか中文になってしまいました。

まとめると、ryuzさんの案は
(うまくいくとした)私の思いつきに比べ、
1. アイドルスタック必要量が少々し大きめになり、
2. タスク再起動のコストが僅かに大きく、
3. 上記bの危険性と環境異存無く無縁
となりましょうか。

//
最後にちょっと細かいことを
>1) exinf にタスク情報もらって、それのタスクを
>生成した後、アイドルに飛ぶルーチンを用意
タスクを生成してディスパッチするルーチンですね。
#21153 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-11 23:17 by ryuz #21178)

Ryuzです。いろいろ考えていただきありがとうございます。

個人的には、動作中のタスクのスタックを操作すること自体が気持ち悪くて...
＃ C言語なんでコンパイラ次第でスタックに何時PUSHされちゃうかわからない（保証がない）ので...

> 最後にちょっと細かいことを
> >1) exinf にタスク情報もらって、それのタスクを
> >生成した後、アイドルに飛ぶルーチンを用意
> タスクを生成してディスパッチするルーチンですね。

あ"。。。 ですね (^^;; すいません。

ディスパッチが終わってからですね、アイドル飛ぶのは。
とりあえずディスパッチ後にアイドルに飛ぶように書いておけば、流用したアイドルコンテキストの後始末が不要なので。。。

#21173 への返信

RE: ext_tskへのパッチで判らない事が有ります (2006-04-12 00:10 by m-arai #21181)

＞とりあえずディスパッチ後にアイドルに飛ぶように書いておけば、流用したアイドルコンテキストの後始末が不要なので。。。

失礼しました。素で気付いていませんでした。(^^;;;;
#21178 への返信

ゾンビ3パッチのエラー？ (2006-04-20 23:18 by hamayan #21403)

zomb_3の中でMKNL_TTS_DRASの値を0x03に変更していますが、これにより、mexe_tskの以下の条件式が成立しないと連絡をもらってしまいました。
if ( (mknl_run_mtcb->texstat & MKNL_TTS_RDLY)
&& !(mknl_run_mtcb->texstat & MKNL_TTS_DRAS) )
{
確かに、、、。

ところで素朴な疑問ですが、mknl_run_mtcb->texstatに値の代入ってどこで行っているんでしょう。
検索しても判りませんでした。（；´д｀ ）
#6144 への返信

RE: ゾンビ3パッチのエラー？ (2006-04-21 00:03 by m-arai #21406)

分かりません。ええ、もうキッパリと。

MKNL_TSS_DINTも3になっていますが、どんな意図をもって
そうしているか、はたまた何かの誤解、単なる手作業の
ミスなのかもまるで見当がつきません。

こんな反古のパッチをひっくり返すより、
見えかかっている良さげな筋に注力(できれば)した
方が有益に思えますので、そういうものを垂れ流した
立場を省みずお願いします。
hamayanさんもhamayanさんに連絡を戴いた方も、
申し訳ありませんがこれに関しては忘れてください。
＃そして、もし次のパッチが出たなら、記憶が新しい
＃うちに突っ込んで下さい。
#21403 への返信

RE: ゾンビ3パッチのエラー？ (2006-04-22 01:30 by hamayan #21427)

了解です。
#21406 への返信