連載｜組込みシステムにおけるマルチコア
第3回並列化の限界とソフトウェアによる対策

並列化の真価を引き出すには、ハードウェアの力を活かす「設計の知恵」が欠かせません。

第3回では、スレッド、プロセス、同期制御、排他といった並列プログラミングの基本概念を整理し、どのようにタスクを分解・連携させるかを考えます。「理論」を「実装」に落とし込むための橋渡しとなる回です。

この連載の記事一覧

連載｜組込みシステムにおけるマルチコア

1. 並列化するタスクの依存性による分類

2. 並列化をサポートするソフトウェア技術

3. SMP型RTOSの実装技術

1. 並列化するタスクの依存性による分類

シングルコアで動作している既存システムをマルチコア・マルチCPUで並列化するには、タスク（スレッド）間の結合度が1つの尺度となります。

細粒度並列（fine-grained parallelism）

スレッド間で頻繁な通信や同期が行われているシステムです。並列化するには、スレッド間の同期通信や排他処理がコア透過で実行できることが望ましいです。

このような結合度では、SMP型マルチコアおよびSMP OS（RTOS）を採用することで、シームレスに移行できる可能性があります。

その一方で、AMP型マルチコアやマルチCPUでは、シームレスな移行は難しいと考えます。

粗粒度並列（coarse-grained parallelism）

スレッド間の通信や同期がほとんど不要なシステムです。この場合は、より大きな塊の処理（機能）を並列化します。例えば、モータ制御とネットワーク通信システムという大きな塊を機能分散します。

SMP型マルチコアに加え、AMP型マルチコアやマルチCPUを使った並列化も有効な手段です。

自明な並列性（embarrassingly parallel）

スレッド間に依存関係が全くないことが自明であり、スレッド間の同期通信や排他を全く必要としないシステムです。これは、並列化が最も簡単です。SMP型マルチコアに加え、AMP型マルチコアやマルチCPUを使った並列化も検討できます。

多くのRTOSを利用した既存システムは、細粒度と粗粒度の中間粒度であると考えます。マルチコアシステムは、SMP型とAMP型のハイブリッドを検討してみるのも良いでしょう。

2. 並列化をサポートするソフトウェア技術

大規模な分散処理システムを除外して、特に組込みシステムに関連するマルチコア支援のソフトウェア技術を説明します。

1) SMP型マルチコアを抽象化するSMP型OS（RTOS）

SMP型OS（RTOS）は、SMP型マルチコアの詳細を隠ぺい・抽象化する透過性があります。これは、従来のシングルコアと同じプログラミング環境・実行環境を提供します。細粒度並列（fine-grained parallelism）のシステムを、素直にSMP型OSアプリケーションとしてマッピングすることが可能です。

現在、SMP型OS機能は、下記のように、Linuxをはじめ多くのRTOSでサポートされています。

SMP-Linux
TOPPERS FMP/FMP3
FreeRTOS SMP
Azure RTOS(旧ThreadX/SMP)
Zephyr SMP

2) コア間の通信ライブラリ

コア間のデータ通信をライブラリ機能として提供します。通信ライブラリは、CPUの命令セットアーキテクチャやメモリモデルに依存しないことが特徴として挙げられます。

SMP型マルチコアシステムに加え、AMP構成における異種CPU間、異種OS間、CPUチップ間の通信ライブラリにも適用できます。

ライブラリには、以下のようなものが存在します。

TOPPERS DualOS COM
OpenAMP

3) 並列化コンパイラ

シングルコンピュータ用に逐次記述されたソースコードから並列性を抽出し、並列に実行するプログラムコードを作成する技術です。

実装として、以下が存在します。

OpenMP
OpenMPI

並列化コンパイラは、OSが提供するスレッド生成・管理機能を利用します。独自で並列化コードを生成するものではありません。

3. SMP型RTOSの実装技術

このコラムでは、ホモジニアスなSMP型マルチプロセッサを前提としたRTOSを「SMP型RTOS」と呼びます。

SMP型マルチプロセッサのコアは同じ命令セットを持ち、レジスタセット、FPU、L1キャッシュ、MMUなどのシステム構成部品の複製をすべてのコアで備えています。SMP型マルチプロセッサの全てのコアは、共有メモリを使用します。すなわち、同一物理メモリを、同一アドレス空間から同じ操作（命令）でアクセスすることが可能である必要があります。

ここからは、SMP型RTOSの技術要素を見ていきましょう。

(1) タスク実行のスケジュール

RTOSは、タスクスケジューリング機能を拡張します。コアごとに実行待ち行列を持ち、RTOSのスケジューリングポリシー（μITRONであれば厳密な優先度によるスケジューリング）によって待ち行列を管理し、コンテキストスイッチを行います。コアごとにタスクスケジューリングして並列実行するということを覚えておきましょう。

(2) 割込み管理

コアごとに割込みベクタを持ち、割込みを受け付け、実行します。各コアに割込みを配分するグローバル割込みコントローラ（割込みディストリビュータ）と、コアごとのローカル割込みコントローラを持ちます。RTOSの割込み管理処理は、コアごとにローカル割込みコントローラを管理・操作します。

(3) システム時刻・タイムイベント管理

シングルコアシステムのRTOS要件として、最低限1つのハードウェアタイマが必要でした。

マルチコアのRTOSには、システム時刻やタイムイベントはコアで1つのハードウェアタイマによって管理するグローバルタイマ方式と、コアごとの複数のハードウェアタイマで管理するローカルタイマ方式が存在します。

(4) ロードバラシング（CPUコア負荷の平滑化）

特定のコアに実行負荷が偏らないようにすることを「ロードバランシング」と呼びます。Linuxのような汎用OSまたは汎用OS型RTOSは、全てのコアの負荷状態を観測します。特定のコアに負荷が偏った場合、実行中のプロセスやタスクが実行しているコアを別のコアに移動（マイグレーション）させることで負荷を平滑化します。これは、このようなOSでは平均的なパフォーマンスが重要視されるためです。

ハードリアルタイム性を重視する組込みシステムでは、平均的なパフォーマンスは重要ではありません。重要なのは、イベントに対する処理完了の実行最小時間と最悪時間の振れが少ないこと、予測可能であることです。

予測ができないカオスな状態を作ることは、高信頼性システムには不向きです。ミッションクリティカルな処理を実行中に、❝神の一声❞でいきなり実行コアを移動させられたら時間の約束はできないですよね。組込みOSは、ロードバランシングを実装しないことが一般的です。

(5) サービスコールの実行方法

直接操作方式

カーネルオブジェクト（タスク、セマフォなど）の管理領域を直接参照・操作し、その結果として他コアのタスクにディスパッチを行う必要がある場合は、IPI（コア間割込み）を発生させてディスパッチ要求を伝えます。ディスパッチ要求を受け付けたコアは、タスク切り替えを行います。サービスコールを最小限の実行コストで実行できることが利点であり、この方式は共有メモリを前提としています。

また、並列実行するコアが同一管理領域を読み出し・書き込み操作を行うため、カーネル内部にロック（いわゆるスピンロック）の機能を実装する必要があります。

間接実行方式

対象コアにサービスコールのコマンドを転送し、転送を受けたコアがサービスコールを実行してその結果を転送元に返却します。これは、コア間のいわゆるRPC（遠隔手続き呼び出し）で実現するモデルです。

間接実行方式は、RPCの実行オーバヘッドは高いですが、共有メモリを必要とせず、ローカルメモリしか持たないマルチコア構成にも適用できるという多様性があります。なお、間接実行方式のカーネル自体はロックフリーです。

ちょっと昔の話になりますが、今のようにマルチコアや分散コンピューティングに注目が集まる前、まだ無線LANは存在せず、Ethernetも普及していない1993年に仕様が公開されたμITRON ver3.0には、ノード接続という機能概念が説明されています。

これは、何らかの通信路によって接続された疎結合のCPUネットワークにおいて、カーネルのμITRONサービスコールをコマンド/レスポンスパケット化し、ユニキャスト通信で配達するという内容で、μITRONを分散コンピューティング（TRON流に表現すると電脳社会）の基盤技術とする提案だったかと記憶しています。このμITRONのノード接続も間接実行方式を前提としていました。

この連載の記事一覧