(toppers-users 3838) Re: 実行時優先度を指定しなければ なんて書いていません。逆ですよ

[yasuo kominami(nifty)]

高橋様、皆様

小南です。

2012年1月27日19:08 高橋和浩@nifty <takahashi_kazuhiro ＠ nifty.com>:
> こんばんは　アライブビジョンソフトウエアの高橋です。
>
>
>>SSPの実行時優先度を指定しなければ（起動時優先度のみを指定すれば）、「まずいことが起こりそうだ」
>>と感じることが出来るでしょうが、ここでSSPの実行時優先度を指定することで、
>>ASPなどと同じ挙動をすると勘違いしやすくなる（見えにくくなる）ことが高橋さんが「使えない」
>>と考えられる理由ではないかと思います。
>
> ものすごい勘違いされているようです。
> 実行時優先度を指定しなければ　とかどこかに書いていますか？
> あくまで2つの優先度を使用することについてのみ書いています。
> 今の実装では　DEF_EPRIを使わないことが良いと思っています。
> その反対を書かれています。
> 勘違いもここまで来るとすがすがしいですね。
>
> 何点かコメントしたいですが、誤解されたものにコメントしても
> しかたがないので控えておきます。

はい、確かに「実行時優先度を指定しなければ」とは高橋様は書かれていません。

>> 「SSPの実行時優先度を指定しなければ（起動時優先度のみを指定すれば）、「まずいこ
>> とが起こりそうだ」と感じることが出来るでしょうが、ここでSSPの実行時優先度を指定する
>>ことで、ASPなどと同じ挙動をすると勘違いしやすくなる（見えにくくなる）ことが」

というのは、私の意見です。
「この点はまずいな」と私が思っていることです。
そして、高橋様が「使えない」考えられた理由が、私がまずいなと思っている点と同じではない
かと、推測しました。
本来、その推測が正しいか高橋様にお尋ねすべきでしたが、それをせずに単なる推測を事実
であるかのように断定して書いてしまいました。


以下の三点をこの場にてお詫びいたします。
申し訳ありませんでした。

1.私の意見の部分を、はっきりと区別できない文章を書いたこと
2.私の単なる推測が正しいか間違っているか、高橋様にお尋ねしなかったこと
3.推測を断定し、なおかつ私の意見を高橋様が書かれたかのように受け取られる文章を書い
たこと


> ただMLの体裁について少し、
> もうすこし、コメントしやすいような配慮がまず必要じゃないですか
> サブジェクトや、古い文書に対するコメントならもう少し引用されたほうがいいですよ。

この点も私に甘えがありました。
読みやすくする工夫を怠りました。
このMLを読んでおられる方すべてにお詫びします。

> それから箇条書きすることと結論を先に書く習慣もつけたほうがいいんじゃないですかね。
> 何がいいたいのか途中からわからないです。みなさんは頭がいいのでわかって
> らっしゃるのでしょうか？

1では、冒頭の部分が私が最も主張したかったことです。
ただし、他にこの点を指摘している方が居られず、この部分だけで私の意図が伝わるか不安に
思い、補足のつもりで、文章を追加していったのですが、それが逆に分かりにくくしてしまい本
末転倒になってしまいました。

（私が主張したかったこと）
>> 1.２つの優先度について
>>
>> toppers-users 3795、3818での、アライブビジョンソフトウエアの高橋さんの指摘は、２つ
>> の優先度があることが原因というよりは、各タスクの優先度（起動時優先度）毎にタスクを
>> 1つのみ割り当てるということの影響の方が強いためだと思います。
>>
>> このケースで、起動時優先度のみを指定したとしても、同じことが起こります。
>> またTOPPERS/ASP,JSPなどでも同じです。
>>
>>



>>2.SSPでタスクがプリエンプトされても、スタックを共有できるわけ
> この後の文章は、読書感想文を求められたのになぜかあらすじを書いてしまった小学生の
> 読書感想文のようにしか見えないのは私だけでしょうか。
>

ここもおっしゃられるとおりですね。
私が伝えたかったのは、見出しの中の「SSPでタスクがプリエンプトされてもスタックを共有で
きる」ことと、その下に続く部分でした。

>> toppers-users 3737
>> において、μITRON4.0の仕様の制約タスクについて述べましたが、あらためてSSPのアー
>>カイブに同梱されているドキュメントを確認したところ、SSPは制約タスクのみをサポートし、
>>CRE_TSK にはスタック領域のアドレスを必ずNULLに指定することとなっていました。
>> したがって、SSPでは必ず全てのタスクでスタックが共有されることになります。
>> そこで、SSPのソースを確認したうえで、以下にコメントします。

この後は、以下のことをソースに即して説明したかったのですが、説明できないまま終わりま
した。

・SSPでは待ちが存在しないことから、プリエンプトされても（優先度の高いタスクが起動して
も）、すべてのタスクで１つのスタック領域を共有することができる
・SSPのスタック領域のサイズは各タスクが利用するスタックのサイズの合計である
・ただし、合計サイズから実行時優先度が同一のタスクのスタックのサイズを引いて、実行時
優先度が同一のタスクの中で、もっとも大きいスタックサイズを加えることが出来る（合計サイ
ズを小さくできる）
・さらに実行時にプリエンプトが発生しなければ、合計サイズをすべてのタスクのスタック領域
のサイズの中で最も大きいものにすることができる（1タスクのスタックサイズにまで小さく出来
る）
・http://www.j-tokkyo.com/2000/G06F/JP2000-132409.shtmlに示された特許では、優先度
毎（1優先度1タスク）にスタック領域を固定して割付けているが、SSPの実装では動的に割り
付ける（runk_task()の呼び出し）ことにより、管理データ領域が不要になり、スタックポインタの
入れ替えも必要ない

後、もうひとつお詫びしなければなりません。
>> toppers-users 3737
>> において、μITRON4.0の仕様の制約タスクについて述べましたが、あらためてSSPのアー
>>カイブに同梱されているドキュメントを確認したところ、SSPは制約タスクのみをサポートし、
>>CRE_TSK にはスタック領域のアドレスを必ずNULLに指定することとなっていました。

と書きましたが、ここに言及したドキュメントは、まだ決定稿ではなく、公開された状態のもので
はありませんでした。
私はTOPPERSプロジェクトの個人会員なので入手していたのですが、現時点でまだ未公開の
ドキュメントを取り違えて言及してしまいました。
未公開のドキュメントをこのMLでの発言の根拠には出来ませんので、この部分は、公開されて
いるSSPのアーカイブ中のファイルでのコメントと差し替えさせてください。

ssp-1.1.0.tar.gz内のssp/kernel/kernel.tfの339行目以降

339 $ 全ての処理単位のスタックは共有される．
340 $ そのため，スタックサイズに関するチェックは
341 $ 共有スタック設定のところでまとめて行う．

これはTOPPERS新世代カーネル用コンフィギュレータのスクリプト内のコメントです。
このスクリプトはもともとカーネル開発者だけが意識すればよいものなのですが、SSPについて
現時点で公開されているものの中で、すべてのタスクのスタックが共有されていると言及してい
るものはこれぐらいしか見つかりませんでした。



現在の以下の仕様のSSPに対して私は、DEF_EPRIで実行時優先度を明示的に指定するの
は、実行可能状態のタスクのスケジューリングに該当タスクの実行時優先度が係わり合いが
あるという誤解を招きやすいと思うため、まずいと思います。
DEF_EPIRを使わずに済ませたほうがよいとも思います。
（起動時優先度毎に1タスクのみという制約の方がきついため）

SSPの現在の仕様
・起動時優先度毎に1つのタスクのみを割り付けることが出来る
・（μITRON4.0仕様における）広義の待ちは存在しない
・全タスクが1つのスタックを共有する
・静的APIのDEF_EPRIで、タスクに対して起動時優先度より高い実行時優先度を明示的に指定
できる　（指定しない場合は、内部で等しい値が設定される）
・実行時優先度が同一のタスク間でスタックを共有する（全タスクで共有するスタックの中で、同じ
領域を使用する）
・タスクのスケジューリングに関わるのはタスクの起動時優先度と、実行状態のタスクの実行時
優先度のみ

私がまずいと思う理由は、高橋様が、

　(toppers-users 3818) 2つの優先度の有効な利用方法は？(長文　改造案)

で指摘された理由と同じでしょうか。

お返事がいただければうれしいです。