(toppers-users 3829) 8bit時代の手法

[高橋和浩@nifty]

おはようございます。アライブビジョンソフトウエアの高橋です。

SSPでの2つの優先度の有効な事例ですね。

>   H_max < 1秒
>   H_max*60 + M_max < 1分
>  (H_max*60 + M_max)*10 + L_max < 10分

ということで、なるほどこれでSSPで動きそうに思いますが、たぶん一点問題が
あってそう上手くいかないと思います。
理由は、全タスクが一回づつ動かないからです。
例えば、Lグループのタスクが複数あるはずですが、L1 L2 L3があるとしたら
L1が起動優先度のLの中で最も高い場合としては、L1起動して処理が終わりタスク終了し、その後L2が
起動して処理終了してタスク終了した場合、L1が起動された後、L2の終了までに
L1が再度起動されていた場合にL3ではなくL1が起動されてしまう場合があると考えるからです。

これは、ちゃんとわかってられるので、以下対策をすれば問題ないです。、
> > ちょっと大きな処理は、再度走り始める時にステータスを
> > 見て今は何をしないといけないかを毎回判定して実行する
> > 様な作りに成ります。
で対策するということなのですが、結局スケジューラを別途持つような対策が必要
ということです。起動してやらないとか結構いやらしい処理になります。

この事例は現状のSSPのスタック共有の欠点を端的に示す良い例だと思います。

なので、5.先取り方式の提案 をさせていただいています。
5.先取り方式の提案なら貴殿の方式で再度走り出しの防止対策も不要になり、利用できると思います。



On Mon, 23 Jan 2012 23:56:07 +0900
Miyagawa <miyagawa ＠ trail4you.com> wrote:

> どうも間違いが多いなぁ
> 
> >   (H_max*60 + M_max)*10 < 10分
> 
>   (H_max*60 + M_max)*10 + L_max < 10分
> 
> -----
> アドレス変えました。
> 
> 
> 
> (2012/01/23 19:16), Miyagawa wrote:
> > 昔を思い出したのでちょっとだけ昔話を書きます。
> > 
> > 今やメモリーは数GBという世界に住んでいるので
> > オブジェクトにたっぷりとメモリーを割り当てて
> > 疎結合なシステム設計をするのが当たり前な状況ですが
> > 30年前は 8bit CPUをアセンブラでプログラムしてました。
> > 
> > その頃はメモリーの制約が大きく、タスクモニターの
> > 課題のひとつがスタック領域でした。
> > 
> > 各タスク毎にスタックを割り付ければ、待ちを行う
> > システムコールは比較的簡単に作れます。しかし、
> > そうするとタスク数分のスタックが必要となる。
> > 
> > そこで、待ちは必ずスタックがボトムに戻った時しか
> > 出来ないようにすれば、スタックを共有していても
> > 待つ事が出来る。しかし、これをやるのは実際は
> > 面倒です。昔はアセンブラでやっていましたけれどね。
> > 
> > まあ、タスクは待つ事が出来ないとして、一旦走りきって
> > 終了する物とするのが簡単確実な手でした。
> > 
> > ちょっと大きな処理は、再度走り始める時にステータスを
> > 見て今は何をしないといけないかを毎回判定して実行する
> > 様な作りに成ります。
> > 
> > 優先度設計は例えば下記のように時間制限で決めます。
> > 
> > 優先度 H : 1秒以内に走らなければ成らないタスク
> > 優先度 M : 1分以内に走らなければ成らないタスク
> > 優先度 L : 10分以内に走らなければ成らないタスク
> > 
> > それぞれの優先度のタスクの実行時間の和をH_max,
> > M_max, L_maxとすると下記の条件が成り立つように
> > システム設計します。
> > 
> > 話を簡単にするため割り込み処理時間は無視します。
> > H_maxに含まれると考えてください。
> > 
> >   H_max < 1秒
> >   H_max*60 + M_max < 1分
> >   (H_max*60 + M_max)*10 < 10分
> > 
> > 極々当たり前の話ですね。
> > 
> > ここで、優先度Lのタスクが走りきれないというのは
> > 設計上許さないと言う事に成ります。
> > 
> > 例外的にLのタスクが1本だけで、状況に応じて品質を
> > 調整するような作りは有りです。
> > 忙しすぎれば間引いてしまうような事です。
> > 
> > また、1秒のタスクが1秒以内に全目的を完了する必要は無く
> > 完了まで定期的に呼ばれて順次実行する作りも有りです。
> > 時間制限を満たす所で一旦終わるわけです。
> > 
> > 昔の記憶だと、優先度の高いのが制御や計測部分、
> > 中くらいがその加工や記録部分、低いのが印刷等の
> > レポート機能部分と言う様な感じが多かったかな?
> > 
> > 例えば3本のレポート印刷するタスクがあれば
> > そいつらは全部まとめて10分以内に印刷できれば良い
> > という感じです。
> > 
> > 根本的にオーバーロードな設計を禁止すれば
> > それなりに動きます。
> > 
> > SSPだとHグループ(実行時1、起動時2-4)、Mグループ
> > (実行時5、起動時6-8)、Lグループ(実行時9、起動時10-16)
> > 見たいな感じかなぁ。
> > 
> > まあ、レベル数は3段階でなくても良いし。
> > 
> > スタックの共有が出来れば各グループの最大値の和程度に
> > 割込み分を加えた値位に抑えられますよね。
> > 
> > タスク毎に持たなくて良いと言うのは大きいですし、
> > 通常は余裕度の部分が優先度グループ分足されて多少楽になる
> > はずですよね。
> > 
> > 昔の作り方からすればSSPもシステム設計しだいで
> > 役に立つのではないかなぁ?
> > 
> > でもまぁ
> > 
> > 待ちが出来ないと手続き通りの素直なプログラミングが出来ない
> > と言うのは間違いないので開発効率は下がりますよね。
> > 
> > ------
> > このメールはsanritz.co.jpから出しますが、実は1/20で
> > 辞めちゃいましたので、アドレス登録しなおします。
> > 今回だけ御免なさい。
> > 
> > 
> > 
> > 
> 
---
アライブビジョンソフトウエア株式会社
高橋和浩
673-0005兵庫県明石市小久保2-2-7幹線ビル4F
Email:takahashi_kazuhiro ＠ nifty.com
http://homepage3.nifty.com/ALVS/