分科会セッション2B 私のRTOS活用法〜私のタスク分割方法論〜 会場規模： 50人 参加人数： 20人 開催時間： 20:25〜22:00 チェア： 宿口氏 概要： 　RTOSを適用する上で常々問題となるタスク分割方法について、ポジショントーク の例から何が問題なのか、どう取り組むべきなのかを以下の流れの上で議論した。 分科会の流れ： 　1.ポジショントーク 　2.ポジショントーク質疑応答 　3.機能分割 　4.スタック共有 　5.結論 幾つかの議論の結論として、 　タスク分割は、機能単位の分割とリソース単位の分割、仕様書側の上から 　のアプローチとシステム側のしたからのアプローチがあるということを意 　識することが必要である。 を得た。 以下、分科会の記録 −−−−− 1.ポジショントーク テーマ提案の動機： 　・RTOSの基本的な仕組みを理解できない技術者は少ない 　・しかしRTOSを使いこなせる技術者は不足？ 　・実際RTOSでの問題は少なくない 　・システムを設計するには高度な技術力が必要？ 発生しがちな問題： 　・システム過負荷時の予期せぬ動作 　・タスク間の同期通信／排他制御の設計不良 　　→タスク分割数が多くなり同期通信／排他制御が複雑になる。 　　→資源を排他制御に回せなくなる。 　・タスクの優先順位の設計時の考慮不足 　　→タスク数が多いため適切な優先度に割り当てられない。 　・予期せぬタイミングでのタスク切替 解決策の例 小規模家電システムで実施。 　・タスク分割数を少なくした。 　　(設計上の並行処理の分だけタスクが必要なのか？の観点から) 　　→真に並行処理が必要な場合にのみタスクを分割する。 　　　特に前処理を待ってシーケンシャルに実行する場合はタスクを統合する。 　　→同じ資源を使うタスクをまとめて排他制御を少なくする。 　　→周期的なタスクもまとめる方向で検討する。 　・システムの意思決定は１つのタスクに集約する。 　・負荷調整のため高負荷時に実行しないタスクを決めておく。 　・タスク自身の処理時間はタスク自身が保証するような機構を組み込む。 　　→資源を確保している間はタスク切替を起こさせない。 今後の課題(分科会で話合いたいこと) ・RTOSはこのままでよいのか ・RTOSの仕組みとしてどの方向に行くのか 2.ポジショントーク質疑応答 Q.　RTOSについて何が不満なのか？ A.　現場の技術者がRTOSを理解したからといってもシステムは組めない。 　　組める場合はチームに経験者がいるはず。そうでない場合は危険なシステム 　になってしまい何かしらのフォローが必要になる。 Q.　つまり(RTOSを利用した開発についての)教育の問題か？ A.　システムは作ってみなければわからない面がある。 　　(教育の話題になりそうなので、開発についての話題に修正) A2. アプリの機能によるタスク分割は難しい。経験が必要。 　　より良い分割方法を思いついても製品が出荷したあとだったりする。 Q.　R(realtime)の部分に関しての不満はよくわからない。 　　何故タスクが自分で処理時間まで面倒をみるようにするのか。 A.　RTOSを使ってもRTかどうかの検証が必要。自分で面倒を見させる方が確実。 A2. RealTimeという語には2つの意味がある。 　　　優先度に従ったスケジューリングをする 　　　時間的制約を守る Q.　今日のポジショントークに関しては正直びっくりした。このやり方だと、 　システムが小さく、全ての部分に関して自分が判っている必要がある。 　もう少しシステムが大きくなると、破綻するのではないか。 　　OS屋としては、ユーザタスクが処理時間の面倒を見るのはおかしい。 　OSのスケジューリングを、どのタスクが何%CPUを使うかなど指定できる 　ように替える方がいい。OSとしては、管理をあきらめている話である。 　全体を把握していないと破綻するというのは、OSを使う意味がない。 A.　今はポジショントークとは別のプロジェクトを行っている。 　規模が大きくなったが今も同じやり方をしていて、ある意味破綻してしまった。 　本当に全部知らないでシステムを作れるのか？と思う。 会場から分析の必要性について： 　機能設計して、縮合・分離して、システムに収めること。 　ここでのオプティマイズによって、リソースを減らそう。 　少ないリソースで、ということなので、本来のタスク分割の話ではない。 　論理的なタス分割の方針 　　→　あるべきものはあるべき所に置け。 　機能分割を先にやって、まとめるのは別にやる。 Q.　問題の分析が必要ではないか？ 　ポジショントークの場合は、機能分析ができてないのではないか？ 　そのためにタスク分割がうまくできなかったのだろう。もっと分析をした方 　がよい A.　まとめるのも一つの形。今取り組んでいるプロジェクトの経験から「その通り」 　と思う。かなり設計時間もとったのに、何故うまくいかないのか。 3.タスク分割についてのフリーディスカッション タスク分割をどう考えるか？： 　普通の設計者は、シーケンシャルに物を考える。しかし、コンピュータ やLSI化するシステムは、パラレルに動く。それを理解できるかが重要。 　1つのタスクにまとめることで排他処理を不要にするという考え方は、 UNIXカーネルと一緒。RTOS屋から見ると汚いが考え易い。しかし、リアル タイムシステムで無い。 　タスク分割にはセンスが必要というが、さて、どうやってそのセンス を磨くのか？ 　プロセスモデルのOSでは資源管理が強力だが(組込み)使えないので、 各タスクを制限付きで設計することで資源を競合しないようにしている。 　今のITRON(スレッドモデル)ではこのような問題(ポジショントーク)は 起きて当然。設計者はシステム全体を知っている必要がある。 --- システムの破綻についてどう考えるか？： 　システムの「破綻」とは何を意味しているのか。 　→メッセージキューに到着するメッセージの方が処理されるメッセージ 　　より多く、キューが溢れてメッセージが破棄されてしまうような場合。 　　または、タスク間のメッセージの同期がとれないなど。 　→大きな不具合がある、問題が出た、すぐに修正できない、ということ。 　もぐらたたき式にトラブルに対応しているので、いつになっても完全なシステム になった気がしない。μITRONを使って作ると、ちゃんと設計して作らないとわから ないシステムになってしまう。 　システムの資源管理を一つのタスクに閉じてしまうのも「あり」だと思う。 　(反論)それは間違いであると思う。起きてない問題を知らないだけではないか 　もともとの設計が間違っているのではないか 　クリティカルな状況の分析が難しい。全体がイメージできない。 　RTOSを何故使うか？何をメリットと思って使っているのか？ 　→RTOSを利用する目的が、資産の再利用、拡張による開発の容易化にあるのに、 　　いまだにRTOSによるシステムの体系だった分析が確立されていないようでは、 機能分割の各種問題点： 　機能分割の仕方がわからないのでは？ 　→文献がない。あっても、システム分析はあまり複雑なことは行われていない。 　研究もケーススタディーが大半で、特定のケーススタディでうまくいった例が 　あるだけ。(オブジェクト指向と一緒。)自分の事例に適用できるか判らない。 　システムを仕様書の「機能」で分け、それぞれをタスクに分ける。その後 縮合&分割する。このやり方を実施して、破綻したことが無いので良い方法で はないか。 　そもそも機能ごとにタスクを分割するという方向は正しいのか？機能として １つでも複数のサブ機能で構成される場合は多い。機能仕様書レベルの機能と、 システムレベルの機能は違う。 　人の操作に対処する部分が結局一番難しい。機能分化することで結果的に楽に なることもある。 　機能分割を高度にしすぎるとシステムが複雑になる。結果としてリソース制限 や、応答速度の制約が厳しくなる。同時処理を減らす工夫が必要。一度システム を作成してみてから、機能を分割して練り上げていくのもよいのでは？機能レベル でタスクを統合することで分割してもタスクを減らすようにしている。 --- 　「機能」にも2種類ある 　　　・仕様書の機能 　　　　　複数の動作をひとまとめにしている 　　　・デバイスに近い視点でみた機能 　　　　　一つ一つの動作を分けて考える 　まとめてしまえば楽というのは疑問だ。機能を分けることによってファンクショ ン数が多くなっても、開発が楽になる。「仕様書の機能」をさらに分割することが 重要。 --- タスク分割数が増えることの弊害＝スタック領域の増大：について 　機能分割ではだんだんタスク数が増えてくる。タスクが増えること自体は良いが、 応答時間とスタック領域が増えるのが問題。各タスク毎に4〜8kのスタックを持たせ ると、タスクが35個の時250kB程度必要になってしまった。 　本当に同時に動作する必要があるのかを検討して、タスクを縮合する。 　設計段階からタスク数を押さえておく方法と、一旦作ったタスクをまとめるのと どちらがよいか？ 4.スタック共有について 　スタックの共有をOSにサポートさせることができるか？ 　スタックの共有はかなり前からある。μITRON 4.0 の自動車向けプロファイルの、 「待ち」のないタスクは「スタック共有」実現のためのもの。 　スタックを、各タスク毎の空間に退避するという発表があった。 　その昔、8bitマシンでOSを作って、優先度レベル毎にスタックを共有させた。 　「待ち」状態があるモデルでは無理だが、優先度のみで切り替えるならできる。 　「待ち」を言い替えると、プログラムをリニアにかけるか、ということ。システ ムコールを書いたあとにどうなるか、関数のコールレベルによってwaitが入るよう な場合ではスタック共有できない。昔はマクロを書いて、タスクのステータスをス タックに残さないように静的な領域にコピーしておいて、戻りの時にはそこから復 帰させていた。上のような工夫をしないなら、タスク毎におく必要がある。 　スタック共有をしようとすると、C等で一連のプログラムとしてタスクを書くこ とが難しくなる。(中断する時に、スタックを全部吐き出す必要があるので)関数の 中で中断することができなくなる。exitできれば問題ない。waitするのは難しい。 プログラムがスタックにデータを書かないならよい。 (ここで、「待ち」状態が無く、終了するまで資源を占有するタスクを仮定した 場合には「スタックを共有できる」、通常のマルチタスクでは「スタックを 共有できない」ということを確認) --- 　RTOSでは、静的なシステムが最も安定するのではないか？いきなり全部のタスクが 立ち上がって、無限ループで走り続けるもの。タスクが死んだ時に、各種資源をきっ ちり解放してくれるRTOSはほとんど無いのではないか。 　8bit時代は、走り続けるタスクというのはほとんど無かった。何故その後waitがで てきたかというと、高級言語で機能毎に分割して書きたかったため。そのためにタス ク毎のスタックなどを使う。 　静的なら安定かというと、そうはいえない。リソースの有効活用の点からみるとあ まりよくない。 　リソースをプールして干渉を防ぐ。RTの世界ではいくつかそのような「技」がある。 　・プールを分けることで干渉を防ぐ。 　・リソースを確保するがいくつかのタスクで共有できるようにする。 　このように少ないリソースを使い回し、かつhang upすることもなくするアプロー チもある。 　最初に全部立ちあげてしまうのは安全、とはいいきれないが、設計時には判りや すくてよい。割り込みを乱発するシステムが一番リソース的に難しい。 　静的にタスクを作ってしまうのは、考え易くてよい。理解しやすいので品質がよく なるかもしれない。動的にタスクを作っていくようなシステムは、ITRONでは、APIは あるものの想定しているモデルではない。 　OS的には、リソースへの参照ができているので、タスクを殺すのは難しい。OS屋の 技の見せどころでもある。 　「殺せる」と言っているOSでもダメなこともある。メモリリークや、セマフォがな くなってデッドロックが起きたりする。完全にやろうとすると管理テーブルが巨大化 する。計数セマフォだと、一つのセマフォに数十バイト使うことになり、管理テーブ ルだけでメモリを使いはたす羽目になる。制約を厳しくして、排他制御中は死なない などの工夫が必要になる。 　不確定性をなくすことで、リアルタイム性を損なうことになってしまう。いかにリ ソースを管理するかというのは、結局ユーザーの負担になる。 RTOS上で、機能分割した後の最適化としては、今回のポジショントークは面白い。 　ITRON 4.0では周期的に動く時には、wait_tskよりstart_tskを使って、スタック を共有して待ちの無いタスクを走らせる方がオーバーヘッドが少ないとか。 　タスク分割という点では、ファンクション側からみた機能とコンピュータ側から みた機能に違いがあることを、あたりまえだけど理解しておくことが大切。 5.結論 　タスク分割というのは、機能単位の分割とリソース単位の分割、仕様書側の上から のアプローチとシステム側のしたからのアプローチがあるということを意識すること が必要である。 2B以上