Ubuntu 18.04.1 LTSでやる 30日OS本 〜16日目〜

Ubuntu 18.04.1 LTSでやる 30日OS本、16日目です。 他の章へのリンクはここにあります。

1. タスク管理の自動化

ごちゃごちゃした処理をまとめてしまうとスッキリして良いですね。

2. スリープしてみる

HLTする代わりに他のタスクを実行するようにします。ここでは何もなければタスクAをスリープさせてタスクBに注力するようにしています。

マウスやキーボードに触れない状態で実機で測定を行い、30回分の平均を取ると下の表のようになりました。「表示あり」は 1/100 秒ごとにその時点のカウント数を表示させる状態で、表示なしとあるのはtimer_settime(timer_put, 1)を消す方法で測定を行ったものです。 なお、比は13日目最後(マルチタスクなし)の場合のカウント数を1としたときの値を示しています。

カウント数
表示あり 1.663157(6)×108 0.989190
表示なし 1.681270(6)×108 0.999962

本文にあるような理由で単純な比較はできませんが、ほぼマルチタスクなしの場合と同じ値を達成しています。 タスクAのスリープはうまくいっているようです。

3. ウィンドウを増やそう

ウィンドウを増やします。本ではここでテキスト入力のできるウィンドウの幅を小さくしているので、キー入力→文字表示の処理のところに微修正が必要です。 あるいは、高解像度にしているならウィンドウ幅をそのままにしておいても良さそうです。

実機で動かしてみると、3つのウィンドウの数字のずれはだいたい103のオーダーになりました。大体揃っています。

4. 優先順位をつけよう(1)

タスクB0〜B2に優先度をそれぞれ1, 2, 3と付けたもとでカウント数の測定を実機で行いました。30回分の平均は下の表のとおりです。 タスクB0に対するカウント数の比もともに示しています。

タスク カウント数
B0 3.175(9)×107 1
B1 5.715067(3)×107 1.80
B2 8.32(2)×107 2.62

タスクB0, B2はばらつきがかなり大きくなっています。原因はよくわかりませんが、タスクAの影響でしょうか。 比も2倍、3倍からは少し離れています。

5. 優先順位をつけよう(2)

前節の状態だと確かにマウスの動きが少し遅い気がします。本にはタスクAの優先度を上げれば解決するとありますが、試してみたところ却ってカクつく ようになってしまいました。おそらくスリープ時にtask_timerを特にいじっていないことが原因です。タスクAがスリープしてタスクB0に移行すると、 タスクB0から次に移るまでの時間がタスクAの優先度によって決まってしまいます。つまり、Aの優先度を10とすると、 キーボードやマウスの入力に対する処理が約100 msごとにしか行われないことになります。

実際、task_b_mainをその時点でのcountを表示するように変更してタスクAの優先度を100程度まで大きくすると上記のような挙動が確認できます (タスクB0のカウントがタスクAの優先度を反映して1秒程度増え続ける)。タスクAの優先度を大きくしたもとでスリープをしないようにすればマウスの動きなどは快適にはなりますが… 一応改善を試みましたが、タイマの実装に手を加える必要がある気がして面倒になったので諦めました。スリープしうるタスクに極端に大きい優先度を指定するのは良くなさそうです。

なお、この節でレベル分けを導入すれば上のような問題は起こらなくなるはずなので、気にせず先に進むことにしました。