(itron-club 1668) Re: 優先度上 限プロトコルについて

[Seiichi Miyagawa <miyagawa __at__ sanritz.co.jp>]

途中まで書いて若林さんのメールを読んだのですが書いたとこまで出してしまいます。

 //---[(itron-club 1665) Re: 優先度上限プロトコルについて]
//----[2003/12/19 From:Kominami Yasuo]

|> 質問者の中村さんではないのですが、ハンドブックは両方の場合の説明が有り、
|> そのうちの優先度上限の方について質問されたのだと思います。

あちゃ、ハンドブックを見ていないのがバレバレですね。
ハンドブックは手元に無いのでuITRON4.0仕様書の方を眺めてます。


|> 前回の投稿の後資料をさがして、「TECH I Vol.15 リアルタイム/マルチタスク
|> システムの徹底研究」(藤倉俊幸、CQ出版)の「第2部タスクスケジューリング技術入門
|> 第17章リアルタイムスケジューリング法の詳細 13 リアルタイム同期」にプライオリティ
|> シーリングの説明があるのを見つけました。

|> この説明を読むと、中村さんの質問や中村さんの挙げた文献の説明に近いと思いました。
|> 単にミューテックスをロックしただけでは、タスクの優先度は変らず、
|> 他のタスクがミューテックスをロックしようとして、ミューテックスの競合が起こったときに
|> はじめて、タスクの優先度が変るようです。

上にあげられた本との違いはシーリングする優先度の決め方と優先度変更のタイミングですね。

上記の本では
	上限優先度をシステム全体でひとつとして行っている
	優先度を変更するタイミングは競合が発生した時点で行う

となっていますね。

確かにシステム全体でシーリングを行えばロック順序による
デッドロックの回避と言う点では優れていますね。

しかし、別モジュールとして組み込まれたり、ダイナミックローディングされた
プログラムだったりするとミューテックスの管理情報とタスクの優先度を
管理するのは面倒ですね。

優先度を上げるタイミングの違いは、ロックしたときか、競合したときかは
まあ選択の問題かと思います(甘いかな)。他の高優先度タスクを出来るだけブロックしないと
言う事を優先させれば競合時でしょうし、ロックは短時間しかしないとすれば
タスクスイッチを少なく出来るし実装も簡単だしでロック時と言う選択も有ると思います。

この辺りは仕様書でも実装依存と書かれた部分が沢山有りますね。


|> ITRON仕様に従うと、タスクのスケジューリングは上記文献の説明とは大分異ったものになります。

若林さんから詳細な説明が既に出てますね。
仕様のバランスを考えて決められたのでしょうね。


//--------------------------------------------------------------------
// サンリツオートメイション(株)  宮川誠一
//--------------------------------------------------------------------