Chapter 22

設計指針と他の OS との比較

この章がなぜ必要なのか——ここまでの知識を「使える形」にまとめるため.

各章で個別に述べた指針を、設計・実装・レビューの順に並べ直す。 そして最後に、FreeRTOS で学んだ考え方が 他の OS にどこまで通用するのかを確認する。

OS の芯は共通である。 それを確かめて、このシリーズを終える。

この章で使う既出の用語（定義は各リンク先）. コンテキスト（01 章 6 節）、TCB（02 章 2 節）、タスク（02 章 2 節）、ビジーウェイト（02 章 3 節）、ハードウェア（03 章 2 節）、Blocked（04 章 1 節）、Ready（04 章 1 節）、Running（04 章 1 節）、Suspended（04 章 1 節）、CFS（06 章 1 節）、FreeRTOS（06 章 4 節）、RAM（06 章 4 節）、固定優先度（06 章 1 節）、バイナリセマフォ（12 章 5 節）、ブロック（13 章 1 節）、メッセージ（14 章 7 節）、ソフトウェアタイマ（15 章 1 節）、ティック（15 章 1 節）、不可（16 章 4 節）、MPU（17 章 5 節）、正確（17 章 5 節）、循環待ち（19 章 4 節）、デッドライン（20 章 2 節）、周期（20 章 2 節）、最高（20 章 4 節）、スタックオーバーフロー（21 章 9 節）、デッドロック（21 章 8 節）

1. 設計段階で決めること

タスク分割

優先度設計

通信路の選択

メモリ方針

ネットワーク／ハードウェアの選択

2. 実装段階の掟

タスク関数

void vTask( void *pv )
{
    /* 初期化（ここは 1 回だけ） */

    for( ;; )
    {
        /* ★ 必ずブロックする API を含める */
        xQueueReceive( q, &item, portMAX_DELAY );

        /* 処理 */
    }

    /* ★ ここには到達しない。到達するなら vTaskDelete(NULL) を書く */
}

排他制御

割り込み

戻り値

/* ★ すべての生成 API・送信 API の戻り値を確認する */
if( xTaskCreate( vTask, "T", 256, NULL, 2, &h ) != pdPASS )  { fail(); }
if( xQueueSend( q, &item, 0 )                  != pdPASS )  { handle_full(); }
if( xTimerStart( t, 0 )                        != pdPASS )  { fail(); }
if( ( q = xQueueCreate( 10, sizeof(int) ) )    == NULL   )  { fail(); }

「たぶん成功する」で書くと、ヒープ不足やキュー満杯が静かに無視される。

3. レビュー用チェックリスト

設計レビュー

• ☐ タスク数は 15 個以内か
• ☐ 各タスクは「独立して待つもの」になっているか
• ☐ 優先度はレートモノトニックに従っているか
• ☐ 共有データを一覧にし、保護方法を決めたか
• ☐ ミューテックスに順序番号を振ったか
• ☐ CPU 利用率の見積りは 70 % 以下か
• ☐ スタックとヒープの合計は RAM に収まるか
• ☐ 動的確保が必要な箇所を洗い出したか

コードレビュー

• ☐ タスク関数のループにブロックする API があるか
• ☐ ミューテックスを持ったままブロックしていないか
• ☐ ミューテックスをネストしていないか
• ☐ クリティカルセクション内でブロックする API を呼んでいないか
• ☐ ISR から通常版 API を呼んでいないか
• ☐ portYIELD_FROM_ISR を書いたか
• ☐ xHigherPriorityTaskWoken を初期化したか
• ☐ タイマコールバックでブロックしていないか
• ☐ アイドルフックでブロックしていないか
• ☐ static 変数を持つ関数を複数タスクから呼んでいないか
• ☐ 生成 API・送信 API の戻り値を確認しているか
• ☐ printf を高優先度タスクから直接呼んでいないか

検証

• ☐ configASSERT を有効にして全機能を通したか
• ☐ configCHECK_FOR_STACK_OVERFLOW = 2 で長時間動かしたか
• ☐ 全タスクの High Water Mark を確認したか
• ☐ xPortGetMinimumEverFreeHeapSize() を確認したか
• ☐ エラー処理経路も含めてスタックを測ったか
• ☐ デッドラインミスをカウントしているか
• ☐ 49.7 日（ティック折り返し）を跨ぐ試験をしたか（またはシミュレートしたか）

設計レビュー用チェックリスト

上のチェックリストを、分野別にたどれる形で確認できる。

4. よくある症状と原因

5. 他の OS との比較

用語の対応

設計思想の違い

どれが優れているか、ではない.

• RAM 8 KB のマイコンで動かす → FreeRTOS（Zephyr でも厳しい）
• ドライバとネットワークを自分で書きたくない → Zephyr
• ファイルシステム・プロセス分離・豊富なライブラリ → Linux
• 機能安全認証を取りたい → FreeRTOS（SafeRTOS）、あるいは商用 RTOS

規模が大きいほど機能が多く、RAM を食い、予測可能性が下がる。 トレードオフである。

共通している「OS の芯」

このシリーズで学んだことのうち、どの OS でも同じものを挙げる。

これがこのシリーズの結論である.

FreeRTOS は小さいが、OS が OS であるための要素はすべて持っている。 そして、その要素は他の OS でも同じ形で存在している。

Linux の schedule() は 1000 行を超え、 CFS の赤黒木、CPU ごとのランキュー、負荷分散、 cgroup による制限——さまざまなものが載っている。

だがその芯にあるのは、「Ready なタスクから 1 つ選んで、コンテキストを差し替える」 という、FreeRTOS の vTaskSwitchContext() と同じ処理である。

小さいものを完全に理解することは、大きいものを理解する最短経路である。

6. FreeRTOS の SMP 対応（補足）

v11 でマルチコア（SMP）が本体に統合された。単一コアとの違いを簡単に述べる。

#define configNUMBER_OF_CORES  2

SMP になると、02 章で「単一コアでは並列は起きない」と述べた前提が崩れる.

• 「読む・足す・書く」の途中でなくても、本当に同時に同じ変数を触りうる
• taskENTER_CRITICAL() は「自コアの割り込みを止める」だけでは不十分
• 単一コアで「たまたま動いていた」コードが、確実に壊れる

単一コアから SMP への移行は、排他制御の全面的な見直しを要する。 安易に configNUMBER_OF_CORES を増やしてはいけない。

7. これから読むもの

最後に、ソースを読むときの助言.

tasks.c は 5,500 行あるが、#if の中身の大半は使わない機能である。 自分の FreeRTOSConfig.h で有効になっているものだけを追えば、 実質的に読むべきは 1,500 行程度である。

そして、その 1,500 行の中身は——このシリーズで全部説明した。

地図は渡した。あとは歩くだけである。

8. このシリーズのまとめ

OS は魔法ではない。 レジスタをスタックに積み、ポインタを差し替え、リストの間でノードを動かす—— それだけのことを、正確に、漏れなく、速くやっているだけである。

その「それだけのこと」を最後まで追えたなら、 あなたはもう、どの OS のソースを開いても道に迷わない。