RTAI入門（３）何が出来るか？その３
この記事からの続きです。
RTAIで何が出来るか？の「IPC」編その１です。
- メッセージ
についてまとめます。
なお、RTAI入門（２）のタスクのリアルタイム化は、全ての基礎となっています。ですから、ここだけはご一読をお勧めします。
メッセージ
概要
リアルタイムタスクが複数あるとき、これらをうまく協調動作させないといけません。
そのための仕組みの１つに、「メッセージ」という機構があります。
メッセージとは、タスクからタスクへとデータを運んでくれる仕組みです。
図１ 「メッセージ」は、タスクからタスクへデータを運ぶ
運べるデータに特に制限はありません。ですが、だいたい数バイト～数百バイト程度の使用を想定しています。
メッセージとタスク挙動
じつは、メッセージとは単にデータを受け渡しするだけのものではありません。ただデータを受け渡したいだけなら、グローバル変数でも使えば十分です。
メッセージのキモは、データの受け渡しよりもむしろ、それにともなうタスクの挙動の方にあります。
メッセージとタスク挙動は次のようにまとめられます。
- メッセージは、特定のタスクに向けて送信できる
- メッセージを送信するときに・・・
- 受信タスクがメッセージ受け取り準備できていなければ、送信タスクはブロックする
- 受信タスクがメッセージ受け取り準備できていれば、送信タスクはブロックしない
- メッセージを受信するときに・・
- メッセージがどこからも来ていなければ、受信タスクはブロックする
- メッセージがどこかから来ていれば、受信タスクはブロックしない
ここで「ブロック」とは、タスクが一時停止する事をいいます。たとえば某ダム建設が、予算うんぬんでモメて工事止まってますよね。あれも、「工事タスク」がブロックしている状態と言えます。（ダムの場合は、ブロックどころかそのままタスクがKillされそうな勢いですが・・・）
ではここで、もう少し具体的に見てみましょう。
まず、ここにタスクが２つあるとします。タスク１から、タスク２に対してメッセージを送りたいものとしましょう。
これらのタスクは、次のように振る舞います。
- タスク２は、普段は何か別の処理をしている。する処理がなくなってヒマになったら、何かメッセージが来ないか待ちかまえる
「何かメッセージが来ないか待ちかまえる」というのが、「メッセージ受け取り準備」に相当します。ＲＴＡＩでは、rt_receive というＡＰＩを使用します。
- タスク１は、気が向いたらタスク２にメッセージを渡したがる
「メッセージを渡したがる」というのが、「メッセージ送信」に相当します。ＲＴＡＩでは、rt_send というＡＰＩを使用します。
この時のパターンとして３つ考えられます。
パターン１
タスク２が準備できてないのに、タスク１がメッセージを渡そうとした
図２ タスク２が準備できてないのに、メッセージを渡そうとした
ここで、（１）と（２）ではそれぞれ次のような会話がなされています。
（１）タスク１がメッセージを渡そうとした
タスク１ 「これ、あたらしいメッセージです！読んで下さい！」（＝ rt_send ）
タスク２ 「まだ他の仕事してるんだってば！受け取らないよ！？」
タスク１ 「スミマセン。準備できるまでずっと待ってます・・・」（＝ブロック）
（２）タスク２がやっと準備完了した
タスク２ 「えーっと、次のメッセージは・・・」（＝ rt_receive )
タスク１ 「はい！待ってました！ずっと！ さぁ、これです！！！」 ( = ブロック解除 ）
こんな感じで、メッセージ送信側であるタスク１は、rt_send を実行したとたんブロックします。
そのブロックが解除されるのは、メッセージ受信側であるタスク２が rt_receive を実行したときです。
パターン２
タスク２が準備できてから、メッセージを渡した。かつ、タスク２の方が優先度が高い
パターン２、パターン３では、設定を付け加えます。このシステムは１CPUとします。ですから、タスク１、タスク２のいずれかしか実行できません。
その場合、実行されるのは優先度の高いほうのタスクです。
まずパターン２では、優先度を タスク１ ＜ タスク２ とします。
図３ タスク２の準備が先にできた。そのあとからメッセージをわたした。
（１）タスク２の準備が先に完了した
タスク２「えーっと、次のメッセージは・・・」( = rt_receive )
タスク２「えっ、無いの！？じゃあ、寝て待つか・・・」（＝ブロック）
タスク１「よぅし！じゃまなタスク２が居なくなったぞ。さっそく活動開始だっ！」
（２）タスク１がメッセージの準備完了した
タスク１「メッセージ準備できました！」（＝rt_send 、ブロックしない）
タスク２「よしきた！これで仕事を続けられるぞ！」（＝ブロック解除）
タスク１「ちっ。タスク２が活動を始めたか。これじゃあ動けないな・・・」（＝ブロックされてはいないが、動けない）
ここで（２）の段階では、タスク１、タスク２ともにブロック解除されています。
だからどのタスクが動いても不思議ではありません。 しかし、ＲＴＡＩでは常に優先度の高いタスクがＣＰＵを占有するようになっています。
ですからこの場合は、優先度の高いタスク２が動く事になります。
パターン３
タスク２が準備できてから、原稿を渡した。かつ、タスク１のが優先度が高い
パターン２と似ていますが、優先度を タスク１ ＞ タスク２ とします。
図４ タスク２の準備が先にできた。そのあとからメッセージをわたした。
（１）タスク２の準備が先に完了した
タスク２「えーっと、次のメッセージは・・・」( = rt_receive )
タスク２「えっ、無いの！？じゃあ、寝て待つか・・・」（＝ブロック）
（２）タスク１がメッセージの準備完了した
タスク１「メッセージ準備できました！」（＝rt_send 、ブロックしない）
タスク２「よしきた！これで仕事を続けられるぞ！」（＝ブロック解除）
タスク２「え？タスク１のが優先！？そっか・・・うん、わかった」（＝ブロック解除されてはいるが、動けない）
ここで（２）の段階では、タスク１、タスク２、ともにブロック解除されています。
パターン２と違い、最優先なのはタスク１です。そのため、優先度の高いタスク１が動く事になります。タスク２が動けるのは、タスク１が何らかの理由でブロックされたりした時だけです。
まとめ
このように、
rt_send が先か？ rt_receive が先か？
送信タスク、受信タスクのどちらが優先度が高いか？
この２つの問題の兼ね合いによって、タスクの挙動が変わります。
さて、これらの挙動はあくまで典型的なものです。以降では、もっといろんな種類のメッセージ送受信についてご紹介します。
条件付きメッセージ送信
上記の例では、メッセージ送信しようとしたときに、次のように振る舞いました。
- 対象タスクが、すでに rt_receive していたら、送信元はブロックしない
- 対象タスクが、まだ rt_receive していなければ、送信元はブロックする
ＲＴＡＩでは、さらに次のようなメッセージ送信方法が用意されています。
ブロックしないメッセージ送信
送信元がブロックしてもらっては困る場合もあります。その場合には、rt_send_if というＡＰＩを使います。すると次のように振る舞います。
- 対象タスクが、すでに rt_receive していたら、メッセージを渡す。送信元はブロックしない
- 対象タスクが、まだ rt_receive していなければ、メッセージは渡さずにあきらめる。送信元はブロックしない
このように、対象タスクがrt_receive しなければ、さっさとあきらめてしまいます。根性のないやつめ！
決められた時間だけブロックするメッセージ送信
送信元がちょっとブロックする分にはいいけど、ずーっとは困る。そういう場合には、 rt_send_timed というＡＰＩを使います。
- 対象タスクが、すでに rt_receive していたら、メッセージを渡す。送信元はブロックしない
- 対象タスクが、まだ rt_receive していなければ、決められた時間だけブロックする。
それでもまだ対象タスクがrt_recieveしてくれなければ、メッセージは渡さずにあきらめる。そしてブロック解除する。
このように、対象タスクがrt_receiveしてくれるまである程度の時間だけ待機します。それでもダメならあきらめます。
条件付きメッセージ受信
メッセージ送信と同様、メッセージ受信でも条件付き挙動が可能です。
典型的な挙動は、次の通りです。
- どこかのタスクが、すでに rt_send してくれていたら、受信タスクはブロックしない
- どのタスクも、まだ rt_send してくれていなければ、受信タスクはブロックする
ＲＴＡＩでは、さらに次のようなメッセージ受信方法が用意されています。
ブロックしないメッセージ受信
rt_receive_if というＡＰＩを使うと、次のように振る舞います。
- どこかのタスクが、すでに rt_send してくれていたら、メッセージを受け取り、受信タスクはブロックしない
- どのタスクも、まだ rt_send してくれていなければ、メッセージ受信はあきらめる。受信タスクはブロックしない
このように、メッセージが来ていれば受け取ります。しかし、そうでなければ、さっさとあきらめてしまいます。
決められた時間だけブロックするメッセージ受信
rt_receive_timed というＡＰＩを使うと、こうなります。
- どこかのタスクが、すでに rt_send してくれていたら、メッセージを受け取る。受信タスクはブロックしない
- どこかタスクが、まだ rt_send してくれていなければ、受信タスクは決められた時間だけブロックする。
それでもま誰も rt_recieveしてくれなければ、メッセージ受信はあきらめる。そしてブロック解除する。
このように、どこかのタスクがrt_sendしてくれるまである程度の時間だけ待機します。それでもダメならあきらめます。
次回
次回は、IPC編その２として、メールボックスについて書きます。