RTOSのIPC（セマフォ・ミューテックス・キュー）

同期・相互排除・通信を切り分ける

RTOS（リアルタイムOS）上では複数のタスクが並行して走り、割り込み（ISR）とも協調します。このとき必要になるのが、タスク間の待ち合わせと受け渡しの仕組み——IPC（Inter-Process Communication、プロセス間通信） です。組込みで使う語彙はセマフォ・ミューテックス・メッセージキュー・イベントフラグと少数ですが、混同すると優先度逆転やデータ破壊を招きます。まず整理すべきは、それぞれが解く問題が違うことです。

RTOSの内部では、これらはいずれも待ち行列（ブロックされたタスクのリスト）とスケジューラの連携で実装されます。資源が得られないタスクをレディキューから外してブロック状態にし、条件が満たされたら待ち行列の先頭（多くは待機タスク中の最高優先度）を起こす。土台となる優先度ベースのプリエンプティブスケジューリングは /embedded/rtos-scheduling-rms-edf/ で扱った通りです。

セマフォ：カウンタによる同期

セマフォはダイクストラが定式化した、内部にカウンタを持つ整数です。操作は2つだけ——take（P操作、待って減算）と give（V操作、加算して起床）です。

take():                        give():
  もし count > 0:                count = count + 1
    count = count - 1            もし待ち行列にタスクあり:
    続行                            先頭タスクを起床（レディへ）
  そうでなければ:
    呼び出しタスクをブロック
    （count が正になるまで待つ）

バイナリセマフォはカウンタが0か1のみで、事象が起きたか否かのフラグとして働きます。典型は割り込みとの同期です。ISRがデータを用意して give し、待っていた処理タスクが take で起きて後半処理を行う——/embedded/interrupt-handling-isr/ で述べた前半／後半分離を、セマフォで実現する形です。

カウンティングセマフォはカウンタが上限まで増えます。ここが重要な設計点で、give された回数を落とさずに数えられます。DMA完了やパケット到着が連続で起きても、バイナリセマフォなら2回目以降の give は飽和して失われますが、カウンティングセマフォなら回数ぶん take で回収でき、イベントの取りこぼしを防げます。空きバッファ数のような「資源の在庫数」を表すのにも使います。

ミューテックスと優先度継承

ミューテックス（相互排除） は、共有資源を一度に1タスクだけが使うためのロックです。カウンタが常に1のバイナリセマフォと構造は似ていますが、決定的な違いが所有権です。ミューテックスは lock したタスクだけが unlock でき、「今どのタスクが握っているか」を保持します。この所有者情報があるからこそ、優先度継承が実装できます。

なぜ所有権が要るのか。共有資源が絡むと優先度逆転（priority inversion） が起きるからです。低優先度タスク L がミューテックスを保持中に高優先度タスク H が同じロックを要求してブロックされる。ここで中間優先度のタスク M が現れると、M は L をプリエンプトして走り続け、L はロックを解放できず、結果 H は M の都合で青天井に待たされます。優先度の序列が事実上逆転するのです。この現象が1997年の火星探査機 Mars Pathfinder のリセット多発を引き起こしたのは有名な事例です。

ミューテックスにはもう一つ再帰（recursive）版があり、同じタスクが同じロックを入れ子で複数回取得できます。取得回数をカウントし、同数の unlock で初めて解放します。ただしISRからは絶対に使えません。ISRには「呼び出しタスク」という概念がなく、所有権を持てないためです。

メッセージキュー：コピー渡しで競合を消す

同期だけでなくデータそのものを渡したいならメッセージキューです。キューは固定長のリングバッファで、send（末尾へ追加）と receive（先頭から取り出し）を提供します。満杯での send と空での receive は、それぞれ空き／データができるまでブロックできます。つまりキューは通信と同期を同時に担います。

キューの本質的な利点は、多くのRTOS実装が値コピー（by copy） でメッセージを受け渡す点にあります。送信側のデータはキュー内の領域へ丸ごとコピーされ、受信側は自分のバッファへコピーして取り出します。送受信が同じメモリを同時に触ることがないため、ミューテックスで別途保護しなくてもデータ競合が原理的に起きません。生産者と消費者は、相手の実行タイミングもポインタの寿命も気にせず疎結合になれます。

[生産者・消費者をキューで疎結合にする]

  生産者タスク:
    msg = センサ値をパック
    queue_send(q, &msg)        # 満杯ならブロック。中身はコピーされる

  消費者タスク:
    queue_receive(q, &out)     # 空ならブロックして待つ
    処理(out)                   # 自分のコピーを安全に扱える

大きなデータをコピーしたくない場合はポインタだけを送る設計も可能ですが、その瞬間に「指した先の所有権をいつ誰が解放するか」という問題が復活し、コピー渡しの安全性は失われます。速度と安全性のトレードオフとして意識的に選ぶべき箇所です。

イベントフラグ：複数条件の待ち合わせ

イベントフラグ（イベントグループ） は、1つのワード内の各ビットをそれぞれ独立したイベントとして扱う仕組みです。タスクは複数ビットの組み合わせを待てます。ここでセマフォやキューと決定的に違うのは、AND待ちとOR待ちを表現できることです。

• OR待ち：指定ビットのいずれか1つが立てば起床（例 A または B のどちらか到着で進む）。
• AND待ち：指定ビットが全部揃って初めて起床（例 A と B の両方が揃うまで待つ）。

「センサXとセンサYの両方のデータが揃ったら計算を始める」のように、複数の前提条件を1回の待ち合わせにまとめられるのが強みです。セマフォを条件の数だけ並べて逐次 take する実装に比べ、待ち合わせのロジックが単純になり、途中で片方だけ取得して中途半端にブロックする事故も避けられます。

ISRからの利用：待てないという制約

最後に、すべてのプリミティブに共通する落とし穴がISR（割り込み文脈）からの利用です。原則は単純で、ISRの中では絶対にブロックしてはいけません。ISRには対応するタスク制御ブロックがなく、ブロックして待ち行列に入れる「呼び出しタスク」が存在しないからです。空のキューで receive、ロック済みミューテックスで lock といった「待つ可能性のある操作」は、ISRから呼ぶとシステムが破綻します。

したがってISRから使えるのは、待たずに済む片方向の操作だけです。バイナリ／カウンティングセマフォの give、キューの send（満杯なら失敗を返すだけでブロックしない）、イベントフラグのセット——いずれもタスクを起こす向きの操作です。ミューテックスは所有権が必要なため、ISRからは一切使えません。

この「ISRは give／send して即抜け、重い処理と待ち合わせはタスク側」という構図は、割り込みの前半／後半分離そのものです。ブロック時間をこうして有界に保つことが、締切を保証する最悪実行時間解析——/embedded/real-time-wcet/ の前提になります。

まとめ

RTOSのIPCは、同期・相互排除・通信という別々の目的に、それぞれ最適化されたプリミティブを当てる体系です。セマフォは所有権を持たないカウンタで事象を同期し（バイナリは有無、カウンティングは計数）、ミューテックスは所有権ゆえに優先度継承でブロック時間を有界化し、キューはコピー渡しでデータ競合を根絶して生産者・消費者を疎結合にし、イベントフラグは複数条件のAND／OR待ちをまとめます。そしてISRからは待てないという制約が全体を貫き、片方向の非ブロッキング操作と遅延コンテキストスイッチで応答時間を守ります。この使い分けを目的から逆引きできれば、優先度逆転もデータ破壊も設計段階で潰せます。より低レイヤーの割り込み機構は /embedded/interrupt-handling-isr/、OSを持たない場合の同期設計は /embedded/bare-metal-firmware/ と併せて理解すると立体的になります。