■あらまし
学生の頃からリアルタイム・システムに興味があって様々な書籍を読んでいた自分ですが、エンジニア・ライフを約一周ほど楽しんで、そろそろ思うことあってリアルタイムOS教材についても触れなければならないなと考え始めました。というのも、世の中に溢れる教材の中には、初学者に与えるべきでない間違った例が数あまたあり、それらが実開発の現場で様々な問題を生んでいるからです。今日はその中からひとつだけ取り上げてショート・ブレイクとして書いてみます。
■良くない例：タスク・スリープで排他処理
世の中には不思議な例を取り上げてリアルタイムOSの機能を紹介する例を見かけます。その代表例がタスク・スリープで排他処理やシステムの状態を管理する例です。
この例を取り上げる教材の多くは、リアルタイムOSの機能を紹介したいようでもあるのですが、よくよく読んでみると、結局のところどれも「こういうときはこうするのだ」と実際のアプリケーションについて触れています。しかし、このような設計で実システムを実現されてはひとたまりもありません。
リアルタイムOSの使い方として間違ったアイデア、「タスク・スリープで排他処理やシステムの状態を管理」が何を言っているのか図示してみます。
タスクAとタスクBは、それぞれグローバル変数であるint valueを操作します。もうグローバル変数が出てくる時点で完全に失格なのですが、問題はそこではありません。この典型的な間違ったアイデアは、よく以下のような方法で紹介されています。
①システム起動直後、タスクAは動作し、タスクBは寝ています。
②タスクAはint valueを操作し、タスクBを起こして自分は寝ます。
③起床したタスクBはint valueを操作後、タスクAを起こして自分は寝ます。
例えば、この設計には以下の疑問がつきまといます。
A. タスクAとタスクBが非同期で双方動作している瞬間について考慮されていない。
B. タスクAがタスクBを知っている。タスクBがタスクAを知っている。つまり循環参照関係にある。
C. やっている内容から考えると、そもそも単一タスクで良い。(説明に必然性が全く無い)
D. その他。
上の例、int valueと書いてあるものは物理デバイスであることもあります。となると、なおさら問題は複雑になります。というのも、物理デバイスは動作に時間がかかります。状態遷移中の物理デバイスの状態を適切に扱う場合、上記の例では対処できません。
■例えばどうすれば良いのか？
リアルタイムOSを使うのは、抽象化レベルを上げつつ、キビキビとした動作を実現できるからです。上記の例で言うと、int value(物理デバイスかもしれない)は、操作対象ですが、これはあるタスク内部で操作される操作対象と見ることができます。つまり、タスクAやタスクBから操作される新たなタスクCのようなものが内部で操作する対象とすることができます。
そして、タスクAやタスクBからメッセージ通信でタスクCに操作を依頼する形式を取ります。
「ちょっと待って！さっきの例で出来ていたタスクAとタスクBの同期ができないじゃない！」と言われるかもしれませんが、タスクCは単一スレッド上でメッセージ受信処理を行っているので操作は競合しません。
加えて、タスクCのAPIを工夫しておけば、操作自体も抽象化された表現で扱うことが可能になります。
- アームを上に上げろ！
- アームを下に下げろ！
- 緊急停止！
上記のような操作を抽象的に表現したAPIにするだけで、グンとシステムで操作する内容がわかりやすくなってきます。そして、実装の詳細はタスクCに隠ぺいされるというメリットも生まれます。タスクAとタスクBが循環参照状態になる事もありません。
■ということで・・・
リアルタイムOSの教材でタスクのスリープを使って状態をコントロールするような例を見かけたら、「この教材は怪しいな」と疑って内容をレビューしてみて下さい。
