(toppers-users 3875) 小南様がお尋ねしたい2つの提案（SSP)

[高橋和浩@nifty]

小南様　MLの皆様　アライブビジョンソフトウエアの高橋です。

まず、一応コメントしておきます。ですが最後にしておきます。
あまり有意義だと思っていません。
----------------以下コメントはじまり---------------------------------------
と書かれている以降は読み飛ばすほうがいいかと思います


主題を先に書きます。

> ML参加者の皆さんに尾根画になりますが、2点の提案に対するご意見、あるいは2
> 点の提案に基づく議論をMLで出来ないでしょうか。
> 
> 

2点の提案以下のことですか？
> 1.『スタックを共有する』という用語は，一連のスタック領域を使うという意味に
> 限定して使う

> 2.「SPカーネルにおける追加機能として，タスクに対して，実行時優先度の情報を
> 持つ．SSPカーネルにおいては，タスクが起動された後，最初に実行状態になる
> 時に，タスクのベース優先度が，タスクの実行時優先度に設定される．実行時優先度の機能
> は，起動時優先度よりも高い優先度でタスクを実行することで，同時にスタックを使
> 用するタスクの組み合わせを限定し，スタック領域を節約するための機能である．」
という仕様書に記載内容のこと

いずれにしても、仕様書の記述の話についてですよね。
伺いたい提案が上記ではない場合には、この部分について回答ください。

よろしくお願いします。



----------------以下コメントはじまり---------------------------------------
と書かれている以降は読み飛ばすほうがいいかと思います

On Wed, 01 Feb 2012 14:30:03 +0900
小南靖雄 <ykominami ＠ nifty.com> wrote:

> 高橋様、皆様
> 
> 小南です。
> お返事が遅くなり、月をまたいでしまいました。すみません。
> 
> 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がスタッ
> クを共有するかしないかは、実行時優先度ではなく、（自身がプリエンプトされて）
> タスクの実行を開始したタイミングに依存します。
> 
> 「狭義の省スタック化」が実現できない場合、実行時優先度が同一のタスクの集まり
> が使用するスタックサイズは、それらの使用するスタックサイズの合計ではなく、そ
> れらの中の最大のもののサイズだけに収まるという、「保証」ができなくなります。
> 

まず話がかみあってません。プリエンプトすると狭義の省スタック化はできない。両立しないつまり100%できない
ということを書いているのに、プリエンプトすると狭義の省スタック化できない場合がある　と置き換え
さらに、プリエンプトした場合に狭義の省スタックができない「保証」できないと書いています。
否定していないにも関わらず、新しい定理でも見つけたかのごとくです。
ちょっと大丈夫ですか？　と言いたいです。

それから、
どこにも、誰も「保証」することは言ってませんし、書いていませんよね。

> 
> 
> 現在公開されている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での
> 全タスクが使用するスタックサイズの使用量を減らす効果が得られます。
> どれだけ減るかは「狭義の省スタック化」のように明確に示せませんが、用いない
> 場合に対して、用いる場合の方が使用量を減らす可能性が高くなるといえます。
> 
意味がよくわかりません。(toppers-users 3762)で提示された方法でスタックサイズを減らす
ように現在のSSPがなっているものと理解しています。さらに私が言う「狭義の省スタック化」
はその中の一部の機能として説明しているつもりです。
ところが、SSPがそれ（狭義の省スタック化）と比較するという表現がされていますが、違うものなのでしょうか？
たぶん、スタックを一本にすることの削減効果のように思いますが、そうではなく
何か別のことを言っているのでしょうか？

以下の部分も、何について理由を説明しようとしているのかもわかりません。
> 理由を以下に示します。
> 
> 
> 1.前提
> 
> まず、SSPの実装は以下のようになっています。
> 
> 　SSP1.1.0の実装では、全タスクで一つのスタックを共有するが、さらにそのなかで
> あるタスクの組み合わせが、特定の（アドレス空間の）領域をスタックとして共有
> することができる
間違いでは無いですが、ここで言う「スタックを共有する」と「特定の領域をスタックとして
共有する」は違うことを指していますね。でしたら以降の文面でもどちらかの表現に統一
すべきです。

> 
> 　その条件は以下のとおり。
> 　（あるタスクの組み合わせに含まれるタスクを、以下では該当タスクと呼ぶ）
> 
> 　　プリエンプトされたタスクの起動時優先度 < 該当タスクの起動時優先度 <= プリエンプト後に実行状態になるタスクの実行時優先度
> 
> 　(大小関係は、優先度の高低を示す。優先度を表す値の大小ではない)
> 
> 　該当タスクは、プリエンプト発生時に実行可能状態になっていなくても、プリエン
> プトされたタスクが実行状態に復帰する前までに実行可能状態なるものを含む。
> 
> 　プリエンプト発生から、プリエンプトされたタスクが実行状態に戻るまでの間、上
> 記の式中の該当タスク間でスタックを共有する。

これは「特定の領域をスタックとして共有する」ことですよね。

> 
> 2.SSPにおいて、起動時優先度より高い値の実行時優先度を指定した場合の効果
> 
> どのタスクの間でスタックが共有されるかは、実行時に動的に定まります。

これは「特定の領域をスタックとして共有する」こととして確認しますが、
静的に決まると思うのですがいかがでしょうか？


> しかし、プリエンプトされたタスクの起動時優先度と、プリエンプト後に実行状態に
> なるタスクの実行時優先度の差が大きいほど、スタックを共有するタスクの個数が増
> える可能性があります。

実行時優先度の差とはなんでしょうか？　優先度が1〜16で表現しますが、この値の差の
ことでしょうか？　差が違っても結果は同じと思いますがいかがでしょうか？

> 
> 起動時優先度より高い実行時優先度を指定されていれば、プリエンプト発生時にその
> 差が（起動時優先度が実行時優先度とすべて同じ場合と比較して、統計的に）大きく
> なることが期待できます。
> 
起動時優先度と実行時優先度がすべて同じであれば、「特定の領域をスタックとして共有する」
ことは一切ないので、「特定の領域をスタックとして共有する」タスクの個数が大きく
なるのはそうというより、SSPの仕組みとしてあたりまえですが。

> 
> 
> 以上は、高橋様のメールの「 1.スタック共有という（乱暴な）表現による誤解」に
> 対する、私の理解を説明したお返事になります。
> 
なんとなくわかりました。上記コメントいれているように未だにスタック共有という
乱暴な用語を使われているので混乱されているのかもしれませんね。
 
> 
> 
> 
> 以下は、このメールを書く際に私が感じた、SSPあるいは、SSPの２つの優先度に
> 関する議論の進み方に大しても、感想です。
> 
> さらにその後に、高田先生からの２つの優先度に関する、カーネル統合仕様の修正の
> 提案を載せます。
> 
> 
> 
> A.２つの優先度に関する現在のML上での議論の進み方に関する、私の感想
> 
> 今回返事を出そうとして、高橋様が書かれたこと、書かれていないことなどをきちん
> と把握しようとしたのですが、そのこと自体にかなり時間がかかってしまいました。
> 
> このMLの1月分アーカイブ
> 
> 　http://www.toppers.jp/TOPPERS-USERS/2012-January/date.html
> 
> には、151通の投稿があり、そのほとんどがSSPに関わるメールです。
> 
> 高橋様が書かれたメールは、それらを踏まえて書かれていると思いますので、単に高
> 橋様の書かれたメールだけではなく、一通りすべてのメールに目を通す必要を感じ、
> そうしました。
> 
> 話についていけてる、いけてないというのも、個人の理解力うんぬんだけでなく、そ
> の議論に関わろうとする好奇心とか、関わることに割ける時間がその人のその時の状
> 況で存在するのかというかも絡んでくると思います。
> もし理解力があっても、割ける時間をぎりぎり目一杯割いたとしても、期待する結果
> （何が本当の問題点なのか、誰が何を主張しているのか、その根拠は何か、あるいは
> 何を主張したいないのかを理解し、自分の意見をまとめ、メールを書き、MLに投稿す
> る）が得られる見通しが低ければ、議論に参加するのをやめようかとも思うかもしれ
> ません。
> あるいは「自分の意見はこうだ」と思っても、「自分はきちんと議論を理解している
> のか」と不安に思い、投稿することを躊躇するかもしれません。
> 
> 
> 私も最近はこのMLを読むだけでした。今回たまたま興味を持ち、時間が割ける状況に
> なったので議論に参加していますが、私も状況が変われば参加できなくなるで
> しょう。
> 
> 
> スレッドが伸びても、興味を持って読んでくれる人が少ない、議論に参加する人が
> 少ないとなったら、大変もったいないです。
> 
全くその通りですね。
質問しても、ソースを見ろとかなると聞くに聞けない人もでてきますよ。
さらに、定義してない用語で説明されても困ると思いますし、普通の人ならすでに定義
済みのことを聞いてしまったらと思って聞くのもおっくうですよ。
一番の問題は、(toppers-users 3790)のような、開発者側からのまだわかっていない人に対する
圧力のような回答です。これでは、議論に参加する人が減ってしまうと思います。
さらに開発者側は、終始一般論にとどめて例示して欲しいということに対して無視してきて
います。　それではどうしてもスレは不必要に伸びてしまうでしょう。

> 
> 
> 
> 
> B.２つの優先度に関する、カーネル統合仕様の修正の提案（高田先生による）
> 
> 私はTOPPERSプロジェクトの個人会員ですので、toppers-users ML以外にも、TOPPERS
> プロジェクトの開発用のTracにも参加できます。
> 
> 今回のメールを書く前に、そのうちの「カーネル統合仕様」のTracにアクセスし、
> 「SSPでの実行時仕様書での定義」としてチケットを作成して、高田先生とも議論
> しました。
> 私の理解する範囲で、toppers-users MLで問題にされていることを説明し、現在高
> 田先生から以下のカーネル統合仕様に対して、以下の2点が提案されています。
> 
> 
> （高田先生のチケットへの記載内容に関し、toppers-users への転載の許可をいた
> だいています。）
> 
> 
> 
> 1.『スタックを共有する』という用語は，一連のスタック領域を使うという意味に
> 限定して使う
> 
> これは、SSPに適用させると、SSPで全タスクが一つのスタックを用いることにのみ
> 限定するということです。
> 
> 
> 高田先生の記述を以下に引用します。
> 
> （注：タスク名(起動時優先度,実行時優先度)）
> 
> 「まず提案ですが，『スタックを共有する』という用語は，一連のスタック領域を使
> うという意味に限定して使うことにしてはどうかと思います。というのは，以下の記
> 述は，各タスクが使うスタックサイズによってTaskCとTaskAのスタックが重なること
> もあれば重ならないこともあるので，意味が薄いと考えるためです。
> 
結論には賛成ですが、「意味が薄い」ということがよくわかりません。
「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の意味での共有スタックのサイズが、全タスクの使用す
> るスタックのサイズの合計より小さくなることを狙っています。
> 
ようやく理解できたような気がします。
私が狭義の省スタック化が実行時優先度が同一のタスクの条件だけで実現するものと主張して
いると思ったのですね。とんでも無い間違いですよ。
そこまで勝手に書いていないことを決めつけて反論されると
その反論も限界を超えます。
厳しい言い方をしますと、言葉の意味を理解しない人に言葉で通じあえないです。

提案の1は、私の言う狭義の省スタック化と同じことですよ。再度引用すると
>例外として実行時優先度を指定することでいくつかのタスクのスタックサイズは、合計ではなく、
>そのいくつかのタスクは合計ではなくタスクの中の最大スタックサイズのみしか使用
>しなくすることが可能になる。これを仮に狭義の省スタック化と称して説明する。
きちんと書いているのになんで間違って理解するのか理解に苦しみます。



> 
> 「同時にスタックを使用するタスクの組み合わせを限定」というのは、SSP1.1.0の実
> 装を想定したもので、私がこのメールの前半で記述した、
> 
> 「1.前提
> 
> 　2.SSPにおいて、起動時優先度より高い値の実行時優先度を指定した場合の効果」
> 
> で説明した処理内容を指しています。
> 
> ただし、第4章の中では、「同時」は（マルチプロセッサの環境で）ある瞬間に
どこの第4章ですか？

> 複数のハンドラが起動するとか、複数の機能をもつサービスコールの処理内容の説明で「タ
> スクを終了と同時に削除するサービスコール（exd_tsk）」とか、静的APIで指定でき
> ない属性の組み合わせを定義するときに使われます。
> 
> そのため意味が分かりにくいと感じます。
> そのことはすでに高田先生にお伝えしてありますが、まだ他の案がないという状
> 態です。
> 
> この文章の案のMLの皆様のご提案をお待ちしています。

この文章とはどこの部分ですか？
> 2.「SPカーネルにおける追加機能として，タスクに対して，実行時優先度の情報を
> 持つ．SSPカーネルにおいては，タスクが起動された後，最初に実行状態になる
> 時に，タスクのベース優先度が，タスクの実行時優先度に設定される．実行時優先度の機能
> は，起動時優先度よりも高い優先度でタスクを実行することで，同時にスタックを使
> 用するタスクの組み合わせを限定し，スタック領域を節約するための機能である．」
の部分のことでしょうか？


> 
> 
> 
> それから、この高田先生のご提案は、今までのML内での議論の前提を変更するこ
> とになると思います。

意味がよくわかりません。ML上ですでに議論されています。
その前提が用語の規定をきめたり統合仕様書の記載内容を決めることで
議論の前提が変わるのでしょうか？

> 
> ML参加者の皆さんに尾根画になりますが、2点の提案に対するご意見、あるいは2
> 点の提案に基づく議論をMLで出来ないでしょうか。
> 
> 

2点の提案以下のことですか？
> 1.『スタックを共有する』という用語は，一連のスタック領域を使うという意味に
> 限定して使う

> 2.「SPカーネルにおける追加機能として，タスクに対して，実行時優先度の情報を
> 持つ．SSPカーネルにおいては，タスクが起動された後，最初に実行状態になる
> 時に，タスクのベース優先度が，タスクの実行時優先度に設定される．実行時優先度の機能
> は，起動時優先度よりも高い優先度でタスクを実行することで，同時にスタックを使
> 用するタスクの組み合わせを限定し，スタック領域を節約するための機能である．」
という仕様書に記載内容のこと

いずれにしても、仕様書の記述の話についてですよね。

> > -----------------------------------------------------------
> > 2.小南様がまずいと思う理由は、高橋が、(toppers-users 3818) 2つの優先度の有効な利用方法は？(長文　改造案)
> > 　で指摘された理由と同じでしょうか。
> 
> 勝手ですが、この質問は取り下げさせてください。
> 

了解しました。
---
アライブビジョンソフトウエア株式会社
高橋和浩
673-0005兵庫県明石市小久保2-2-7幹線ビル4F
Email:takahashi_kazuhiro ＠ nifty.com
http://homepage3.nifty.com/ALVS/