(toppers-users 3874) 回答前の確認への返答と高田先生のカーネル仕様修正案紹介(Re: 実行時優先度を指定しなければ なんて書いていません。逆ですよ)
小南靖雄
ykominami ＠ nifty.com
2012年 2月 1日 (水) 14:30:03 JST
高橋様、皆様
小南です。
お返事が遅くなり、月をまたいでしまいました。すみません。
2012/1/29 高橋和浩@nifty <takahashi_kazuhiro ＠ nifty.com>:
> 小南様、MLの皆様
> こんばんは、アライブビジョンソフトウエアの高橋です。
>
> 2点に絞ってコメントします。
>
> 1.スタック共有という（乱暴な）表現による誤解
>
> 2.「小南様がまずいと思う理由は、高橋が、(toppers-users 3818) 2つの優先
度の有効な利用方法は？(長文 改造案)
> で指摘された理由と同じでしょうか。」の回答の前に確認
>
>
> ----------------------------------------------------------------
> 1.スタック共有という（乱暴な）表現による誤解
>
>> 私が伝えたかったのは、見出しの中の「SSPでタスクがプリエンプトされても
スタックを共有で
>> きる」ことと、その下に続く部分でした。
> ここの部分ですが、誤解されています。
>
> 「論点は2つの優先度があることの必要性についてです。2つの優先度は、ス
タックの共有化のために必要なことです。
> スタックの共有化は、プリエンプトしないことによって実現されるので、プリ
エンプトとスタック共有は両立しない。」
> と書きました。 ただ、この説明は一部表現が乱暴なところがあります。乱暴
の反対は丁寧だと思っていますが、
> 丁寧に書きなおします。
> 上記「」についてそのまま丁寧に書きます。
>
> 「SSPの省メモリな特徴の一つとしてスタックの共有化があります。スタック
の共有は各タスクのスタックおよびカーネルの
> スタックについても１つの連続するメモリ領域を使うことになっており、カー
ネルおよび非タスクコンテキスト実行時の最大
> スタックと全タスクの最大スタックサイズの合計を足したサイズを設定する必
要があるが、例外として実行時優先度を指定することで
> いくつかのタスクのスタックサイズは、合計ではなく、そのいくつかのタスク
は合計ではなくタスクの中の最大スタックサイズのみしか使用
> しなくすることが可能になる。これを仮に狭義の省スタック化と称して説明する。
> 論点は2つの優先度があることの必要性についてです。2つの優先度は、狭義の
省スタック化のために必要なことです。
> 狭義の省スタック化は、プリエンプトしないことによって実現されるので、プ
リエンプトと狭義の省スタック化は両立しない。」
>
> 確かにSSPはすべてスタック共有化していますし、プリエンプトできないカー
ネルではありません。
> 言葉として乱暴であったことは事実ですが、
> サブジェクトのしている2つの優先度の目的は狭義の省スタック化のために必
要なことが前提の話なので
> 議論についてきている方なら説明不要と思いましたが、誤解されるかたもい
らっしゃるようなので丁寧に説明してみました。
>
ご指摘された点について考えていて気がついたのですが、確かにプリエンプトが発生
すると「狭義の省スタック化」が実現できない場合があります。
以下にその例を示します。
例）タスク名(起動時優先度,実行時優先度)
TaskA(5,3)、TaskB(8,8)、TaskC(10,5)というタスクがあるとします。
TaskBが実行状態、TaskCが実行可能状態のとき、TaskAが起動されたとします。
TaskAのスタックはTaskBがプリエンプトされたところから始まります。
次にTaskAがリターンし、さらにTaskBがリターンし、TaskCが実行状態になります。
この時、TaskCは、TaskBが使用したスタックを使うとはいえますが、TaskAの
使ったス
タックとは同一ではありません。
従って、TaskAとTaskCが同一の実行時優先度をもっていても、TaskAとTaskCがスタッ
クを共有するかしないかは、実行時優先度ではなく、（自身がプリエンプトされて）
タスクの実行を開始したタイミングに依存します。
「狭義の省スタック化」が実現できない場合、実行時優先度が同一のタスクの集まり
が使用するスタックサイズは、それらの使用するスタックサイズの合計ではなく、そ
れらの中の最大のもののサイズだけに収まるという、「保証」ができなくなります。
現在公開されているSSP Release 1.1.0の実装は、
(toppers-users 3762) Re: SSPの DEF_EPRI とは何でしょうか。
2012/1/18 Hiroaki TAKADA <hiro ＠ ertl.jp>:
> 高橋様、皆様
>
> この件に関して、TOPPERS新世代カーネル仕様書に追加予定の文をお送りし
> ます。
>
> -----
> SSPカーネルにおける追加機能として，タスクに対して，実行時優先度の情報を
> 持つ．タスクの実行時優先度は，起動時優先度が異なるタスク間でスタック領
> 域を共有するために，起動時優先度とは異なる優先度でタスクを実行するため
> の機能である．タスクが起動された後，最初に実行状態になる時に，タスクの
> ベース優先度が，タスクの実行時優先度に設定される．
> -----
>
> 仕様書の文ですので、これだけでは導入意図がわかりにくいと思います。
>
> 読みにくい文ですので、お勧めはしませんが、以下に説明があります。
>
> http://www.j-tokkyo.com/2000/G06F/JP2000-132409.shtml
で高田先生が示された特許のものより、管理用データを省いたり、スタックポイント
の入れ替えなどが必要でなく、柔軟なものになっていますが、逆に仕様を満たすこと
が難しくなっています（満たせない場合があります）。
ただし現在のSSPの実装でも、「狭義の省スタック化」と比較すると、もっと緩い意
味になりますが、起動時優先度より高い値の実行時優先度を用いることで、SSPでの
全タスクが使用するスタックサイズの使用量を減らす効果が得られます。
どれだけ減るかは「狭義の省スタック化」のように明確に示せませんが、用いない
場合に対して、用いる場合の方が使用量を減らす可能性が高くなるといえます。
理由を以下に示します。
1.前提
まず、SSPの実装は以下のようになっています。
SSP1.1.0の実装では、全タスクで一つのスタックを共有するが、さらにそのなかで
あるタスクの組み合わせが、特定の（アドレス空間の）領域をスタックとして共有
することができる。
その条件は以下のとおり。
（あるタスクの組み合わせに含まれるタスクを、以下では該当タスクと呼ぶ）
プリエンプトされたタスクの起動時優先度 < 該当タスクの起動時優先度 <=
プリ
エンプト後に実行状態になるタスクの実行時優先度
(大小関係は、優先度の高低を示す。優先度を表す値の大小ではない)
該当タスクは、プリエンプト発生時に実行可能状態になっていなくても、プリエン
プトされたタスクが実行状態に復帰する前までに実行可能状態なるものを含む。
プリエンプト発生から、プリエンプトされたタスクが実行状態に戻るまでの間、上
記の式中の該当タスク間でスタックを共有する。
2.SSPにおいて、起動時優先度より高い値の実行時優先度を指定した場合の効果
どのタスクの間でスタックが共有されるかは、実行時に動的に定まります。
しかし、プリエンプトされたタスクの起動時優先度と、プリエンプト後に実行状態に
なるタスクの実行時優先度の差が大きいほど、スタックを共有するタスクの個数が増
える可能性があります。
起動時優先度より高い実行時優先度を指定されていれば、プリエンプト発生時にその
差が（起動時優先度が実行時優先度とすべて同じ場合と比較して、統計的に）大きく
なることが期待できます。
以上は、高橋様のメールの「 1.スタック共有という（乱暴な）表現による誤解」に
対する、私の理解を説明したお返事になります。
以下は、このメールを書く際に私が感じた、SSPあるいは、SSPの２つの優先度に
関する
議論の進み方に大しても、感想です。
さらにその後に、高田先生からの２つの優先度に関する、カーネル統合仕様の修正の
提案を載せます。
A.２つの優先度に関する現在のML上での議論の進み方に関する、私の感想
今回返事を出そうとして、高橋様が書かれたこと、書かれていないことなどをきちん
と把握しようとしたのですが、そのこと自体にかなり時間がかかってしまいました。
このMLの1月分アーカイブ
http://www.toppers.jp/TOPPERS-USERS/2012-January/date.html
には、151通の投稿があり、そのほとんどがSSPに関わるメールです。
高橋様が書かれたメールは、それらを踏まえて書かれていると思いますので、単に高
橋様の書かれたメールだけではなく、一通りすべてのメールに目を通す必要を感じ、
そうしました。
話についていけてる、いけてないというのも、個人の理解力うんぬんだけでなく、そ
の議論に関わろうとする好奇心とか、関わることに割ける時間がその人のその時の状
況で存在するのかというかも絡んでくると思います。
もし理解力があっても、割ける時間をぎりぎり目一杯割いたとしても、期待する結果
（何が本当の問題点なのか、誰が何を主張しているのか、その根拠は何か、あるいは
何を主張したいないのかを理解し、自分の意見をまとめ、メールを書き、MLに投稿す
る）が得られる見通しが低ければ、議論に参加するのをやめようかとも思うかもしれ
ません。
あるいは「自分の意見はこうだ」と思っても、「自分はきちんと議論を理解している
のか」と不安に思い、投稿することを躊躇するかもしれません。
私も最近はこのMLを読むだけでした。今回たまたま興味を持ち、時間が割ける状況に
なったので議論に参加していますが、私も状況が変われば参加できなくなるで
しょう。
スレッドが伸びても、興味を持って読んでくれる人が少ない、議論に参加する人が
少ないとなったら、大変もったいないです。
B.２つの優先度に関する、カーネル統合仕様の修正の提案（高田先生による）
私はTOPPERSプロジェクトの個人会員ですので、toppers-users ML以外にも、TOPPERS
プロジェクトの開発用のTracにも参加できます。
今回のメールを書く前に、そのうちの「カーネル統合仕様」のTracにアクセスし、
「SSPでの実行時仕様書での定義」としてチケットを作成して、高田先生とも議論
しました。
私の理解する範囲で、toppers-users MLで問題にされていることを説明し、現在高
田先生から以下のカーネル統合仕様に対して、以下の2点が提案されています。
（高田先生のチケットへの記載内容に関し、toppers-users への転載の許可をいた
だいています。）
1.『スタックを共有する』という用語は，一連のスタック領域を使うという意味に
限定して使う
これは、SSPに適用させると、SSPで全タスクが一つのスタックを用いることにのみ
限定するということです。
高田先生の記述を以下に引用します。
（注：タスク名(起動時優先度,実行時優先度)）
「まず提案ですが，『スタックを共有する』という用語は，一連のスタック領域を使
うという意味に限定して使うことにしてはどうかと思います。というのは，以下の記
述は，各タスクが使うスタックサイズによってTaskCとTaskAのスタックが重なること
もあれば重ならないこともあるので，意味が薄いと考えるためです。
その上で，すべてのタスクで共有するスタック（これを共有スタックと呼びます）の
サイズを決定する方法を検討したいわけです。TaskA(5,3)、TaskB(8,8)、
TaskC(10,5)
の3つのタスクがある例では，もし実行時優先度がなければ，共有スタックのサ
イズは，
3つのタスクが使用するスタックサイズの合計になります。それに対して，この
例のよ
うに実行時優先度をつけることで，TaskAとTaskCが同時にスタックを使うこと
と，TaskB
とTaskCが同時にスタックを使うことはなくなりますので，同時にスタックを使
うタス
クの組み合わせは，TaskAとTaskBしか残りません。よって，TaskAとTaskBが使用する
スタックサイズの合計(A)と，TaskCが使用するスタックサイズ(B)の大きい方
を，共有
スタックのサイズとすればよいことになります。このことを，『同時にスタックを
使用するタスクの組み合わせを限定し，』と表現しました。
2つのタスクが同時にスタックを使わない条件は，2つのタスクの中で起動時優先度が
低い方をTask1，起動時優先度が高い方をTask2と書くことにすると，
Task1の起動時優先度 ＜ Task2の起動時優先度 ≦ Task1の実行時優先度（＜は優先度
の高さ，優先度の値ではない）
になります。 」
2.「SPカーネルにおける追加機能として，タスクに対して，実行時優先度の情報を
持つ．SSPカーネルにおいては，タスクが起動された後，最初に実行状態になる
時に，
タスクのベース優先度が，タスクの実行時優先度に設定される．実行時優先度の機能
は，起動時優先度よりも高い優先度でタスクを実行することで，同時にスタックを使
用するタスクの組み合わせを限定し，スタック領域を節約するための機能である．」
「TOPPERS新世代カーネル統合仕様書 バージョン: Release 1.4.A
第４章 カーネルAPI仕様
4.1 タスク管理機能 より」
私がすでに引用した、「 (toppers-users 3762) Re: SSPの DEF_EPRI とは何でしょ
うか。」で、
高田先生が紹介された仕様案を変更したものです。
ここで、実行優先度の機能が変更されています。
実行時優先度が同一のタスク間で同一のスタック領域を用いることにより実現する、
共有スタックのサイズ削減、つまり高橋様の言葉の「狭義の省スタック化」を実現す
るのではなく、単に提案の1の意味での共有スタックのサイズが、全タスクの使用す
るスタックのサイズの合計より小さくなることを狙っています。
「同時にスタックを使用するタスクの組み合わせを限定」というのは、SSP1.1.0の実
装を想定したもので、私がこのメールの前半で記述した、
「1.前提
2.SSPにおいて、起動時優先度より高い値の実行時優先度を指定した場合の効果」
で説明した処理内容を指しています。
ただし、第4章の中では、「同時」は（マルチプロセッサの環境で）ある瞬間に
複数の
ハンドラが起動するとか、複数の機能をもつサービスコールの処理内容の説明で「タ
スクを終了と同時に削除するサービスコール（exd_tsk）」とか、静的APIで指定でき
ない属性の組み合わせを定義するときに使われます。
そのため意味が分かりにくいと感じます。
そのことはすでに高田先生にお伝えしてありますが、まだ他の案がないという状
態です。
この文章の案のMLの皆様のご提案をお待ちしています。
それから、この高田先生のご提案は、今までのML内での議論の前提を変更するこ
とにな
ると思います。
ML参加者の皆さんに尾根画になりますが、2点の提案に対するご意見、あるいは2
点の提
案に基づく議論をMLで出来ないでしょうか。
> -----------------------------------------------------------
> 2.小南様がまずいと思う理由は、高橋が、(toppers-users 3818) 2つの優先度
の有効な利用方法は？(長文 改造案)
> で指摘された理由と同じでしょうか。
> まず回答する前に、私のどの意見と貴殿のどの意見が同じと言っているか確認
したほうがよさそうです。
>
> さらにその前に質問そのものが間違っています。
> まず、最初に違うのは、「まずいと思う」というのとは大きく違います。
> 私が最初に言ったの（正確には同調したのは）は「美しくない」でそれが個人
的感覚とか言われる方がいらっしゃるので
> 「使い物にならない」と言い換えました。 「使い物にならない」と「まずい
と思う」はまず同じとは
> 到底思えませんが、いかがでしょうか？
>
>
> 次に意見が同じというのはここの部分ですか？ 自分の(toppers-users 3818)
のうち以下の部分
>>3.使える事例の本当の理由（意味がない）
>>お分かりかと思いますが、上記2の例では3つのタスクにする必要がありません。
>>タスク一個で、それぞれの役割のメイン関数を順番にコールするタスクで済む
はずです。
>>タスクにする意味がありません。
>>ただ、管理上 タスクaは担当者aが作るというような役割分担や、異常時のタ
スクがa,b,cの
>>どこで起こっているかが多少わかりやすくなるケースがあるぐらいだと思います。
>>なので、いかにも省スタックできるというのは実態的には使えないようなタス
クを増やすに
>>すぎないと考えています。
>
> 上記が貴殿のこの部分と同じだと言うのでしょうか
>> >>SSPの実行時優先度を指定しなければ（起動時優先度のみを指定すれば）、
「まずいことが起こりそうだ」
>> >>と感じることが出来るでしょうが、ここでSSPの実行時優先度を指定するこ
とで、
>> >>ASPなどと同じ挙動をすると勘違いしやすくなる（見えにくくなる）ことが
高橋さんが「使えない」
>
> 全く述べている点が違うのですが、たぶん該当箇所が違うのだと思います。
> 回答が欲しいのでしたら具体的に引用してこの部分とこの部分が同じと思った
と書いてください。
>
> 2回目ですが、適切に引用しないと話が伝わりません。
>
もともと私の方から質問したことのですが、今回上記の高田先生のカーネル統合
仕様の修正案を
私が紹介することになりました。
出来れば、この修正案に基づいた議論が始まることを希望します。
そして、この修正案に基づくと、そもそもの高橋様の主張されていたことの前提
が変更になり、
私の質問も続ける意味がなくなると感じています。
勝手ですが、この質問は取り下げさせてください。