スマホ時代は国内メーカーの質は明らかに落ちました。SO-02Cはソツなく良かったんですけど、ストレージが少なすぎで買い替え直前は容量不足で挙動不審でした。SH-01Fは性能良いものの、電池がなくなるのが早く、本体が熱すぎでした。この機種で懲りてAndroidハイエンド機を買わなくなりました。

今になって調べてみたところ、この2機種はマシな部類だったようで、富士通ARROWSのように「カイロ機能搭載」「電話ができない」「メールがこない」など、怨嗟にまみれたレビューが未だに残っている機種もあります。悲惨です。

日本だけ異常にiPhone普及率が高い理由って、国内メーカーが2010年代初頭にやらかしたから……！？と思ってしまいました……。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2021/10/08 16:56)

コメント一覧

コメントはありません。

この記事にコメントする

2021年9月28日

permalink

編集する

マルチコアのブート処理

目次: RISC-V

メインCPUからサブCPUを起こすとき基本的には、

CPUのID（RISC-VであればCSRのmhartid）を見て、自身がメインかサブかを知る
サブ側は共有RAMをポーリングなどで見張り、メインCPUからの起動司令を受け取るまで待つ
メイン側は共有RAMに値を書いてサブCPUに起動司令を送る

RAMの初期値が不定であると仮定すると、サブCPUが下手にポーリングすると、不定値によって条件が成立してしまい、メインCPUからの起動司令がないのに勝手に起動してしまう事態に陥ります。

素朴な実装

先程書いた基本的な構造を素直に書くとこんなコードになるでしょう。

素朴なマルチコアのブート


/* メインCPUはHARTID=8, サブCPUはHARTID=0...3とする */

#define HARTID_MAIN         8
#define HARTID_SUB_START    0
#define HARTID_SUB_END      3

#define HARTID_MAX          9

struct {
	int boot_wait;
	int boot_done;
} init_core[HARTID_MAX] = {};

int get_hartid(void)
{
	int i;
	__asm__ volatile("csrr %0, mhartid" : "=r"(i));
	return i;
}

/* メインCPUが実行する */
void boot_main(void)
{
	for (int i = HARTID_SUB_START; i < HARTID_SUB_END; i++) {
		init_core[i].boot_wait = 1;
	}
}

/* サブCPUが実行する */
void boot_sub(void)
{
	int hartid = get_hartid();

	while (!init_core[hartid].boot_wait) {
		/* busy loop */
	}
}

残念ながらこのコードは正常に動作しません。共有RAMつまりinit_core[hartid].boot_waitの値が起動直後から != 0だったとき、boot_sub() はboot_main() からの起動司令を待つことなく起動してしまうからです。

不定値への対処

共有RAMの不定値に対処する方法を考えます。基本的にはサブCPUが変数を初期化（boot_wait = 0）してから待ちに入れば良いのですが、新たな問題が生じます。メインCPUとサブCPUの実行順序はどちらが先という保証はないため、

メインCPUからの起動司令boot_wait = 1
サブCPUで変数を初期化boot_wait = 0

以上の順で実行されるとメインCPU側の起動司令が消されてしまい、ハングアップする可能性があります。この問題の回避のため、変数を1つ追加し、サブCPUのブートが終わるまで、メインCPUは繰り返し起動司令を送るように変更します。

変数を2つ用意する（boot_wait, boot_done）
メイン: boot_done = 0
メイン: サブから応答（boot_done != 0）があるまで、boot_wait = 1を書き続ける
サブ: boot_wait = 0
サブ: boot_done = 0
サブ: boot_wait == 0なら待つ
サブ: boot_done = 1

先程書いた基本的な構造を素直に書くとこんなコードになるでしょう。

不定値への対処を入れたコード


/* メインCPUはHARTID=8, サブCPUはHARTID=0...3とする */

#define HARTID_MAIN         8
#define HARTID_SUB_START    0
#define HARTID_SUB_END      3

#define HARTID_MAX          9

struct {
	int boot_wait;
	int boot_done;
} init_core[HARTID_MAX] = {};

int get_hartid(void)
{
	int i;
	__asm__ volatile("csrr %0, mhartid" : "=r"(i));
	return i;
}

/* メインCPUが実行する */
void boot_main(void)
{
	for (int i = HARTID_SUB_START; i < HARTID_SUB_END; i++) {
		init_core[i].boot_done = 0;
		while (!init_core[i].boot_done) {
			init_core[i].boot_wait = 1;
		}
	}
}

/* サブCPUが実行する */
void boot_sub(void)
{
	int hartid = get_hartid();

	init_core[hartid].boot_wait = 0;
	init_core[hartid].boot_done = 0;

	while (!init_core[hartid].boot_wait) {
		/* busy loop */
	}
	init_core[hartid].boot_done = 1;
}

残念ながらこのコードも正常に動作しません。共有RAMへの値の反映が他のCPUに即座に見えること（アトミック性）を暗に期待しているからです。

アトミック性への対処

今日のマルチコアシステムでは、boot_wait = 0としたときに、他のCPUにも即座に同じ値が見えているとは限りません。主な要因としては、

コンパイラによる並べ替え
CPUのパイプライン
CPUのデータキャッシュ、ライトバッファ

などがあります。通常の変数への代入、参照が他のCPUに即座に値が見えないことにより、おかしくなるパターンはいくつか考えられそうですが、ありがちなパターンとして、

サブCPU 0が起動したboot_done = 1
メインCPUにboot_done = 1が伝わらず、サブCPU 1の起動指令がいつまでも送られない

以上の順で実行されるとメインCPU側が起動司令を送らないまま、サブCPU側も何もできずハングアップする可能性があります。この問題の回避のため、通常の変数への代入、参照ではなく他のCPUにも値が見えるように初期化、代入（アトミックアクセスする）必要があります。

従来C言語でアトミックアクセスを行うためには、実装対象アーキテクチャの知識やアセンブラの記述を必要とするなど、やや困難が伴いました。ですがC11でアトミックアクセス用の定義stdatomic.hが追加されたことで、アトミックアクセスはかなり楽になりました。素敵ですね。

ひとまず速度を全く気にせず、全てのアクセスをアトミックアクセスに入れ替えると、こんなコードになるでしょう。

アトミック性への対処を入れたコード


/* メインCPUはHARTID=8, サブCPUはHARTID=0...3とする */

#define HARTID_MAIN         8
#define HARTID_SUB_START    0
#define HARTID_SUB_END      3

#define HARTID_MAX          9

struct {
	atomic_int boot_wait;
	atomic_int boot_done;
} init_core[HARTID_MAX] = {};

int get_hartid(void)
{
	int i;
	__asm__ volatile("csrr %0, mhartid" : "=r"(i));
	return i;
}

/* メインCPUが実行する */
void boot_main(void)
{
	for (int i = HARTID_SUB_START; i < HARTID_SUB_END; i++) {
		atomic_store(&init_core[i].boot_done, 0);
		while (!atomic_load(&init_core[i].boot_done)) {
			atomic_store(&init_core[i].boot_wait, 1);
		}
	}
}

/* サブCPUが実行する */
void boot_sub(void)
{
	int hartid = get_hartid();

	atomic_store(&init_core[hartid].boot_wait, 0);
	atomic_store(&init_core[hartid].boot_done, 0);

	while (!atomic_load(&init_core[hartid].boot_wait)) {
		/* busy loop */
	}
	atomic_store(&init_core[hartid].boot_done, 1);
}

C11のアトミックアクセスは何も指定しない場合、一番制限の強い（= 確実に他のCPUに見えるものの、アクセス速度は遅い）memory_order_seq_cstアクセスになります。マルチコアのブートを行うにあたって、常に制限が強いアクセスは必要ありませんが、とりあえずこれで動くはず。

編集者:すずき(2022/04/04 06:05)

コメント一覧

コメントはありません。

この記事にコメントする

2021年9月26日

permalink

編集する

xtermの256色端末

まれにxtermの256色指定エスケープシーケンスに対応していない端末があってvimの表示が変な色になってしまいます。チェック用のスクリプトを作っておきました。単純に背景色を変更するエスケープシーケンスと、空白文字、色を元に戻すエスケープシーケンスを連打するだけです。

xterm 256色指定エスケープシーケンステスト用スクリプト


#!/bin/sh

ESC_ORG="\e[0m"

print_colors()
{
	for i in ${*};
	do
		printf " %3d\e[%dm  " ${i} ${i};
		echo -n ${ESC_ORG}
	done
	echo
}

print_xterm_colors()
{
	for i in ${*};
	do
		printf " %3d\e[48;5;%dm  " ${i} ${i};
		echo -n ${ESC_ORG}
	done
	echo
}

echo "System colors (ESC[Nm):"
print_colors `seq 40 47`

echo
echo "xterm 256 colors (ESC[48;5;Nm):"
for i in `seq 0 8 248`;
do
	j=`expr ${i} + 7`
	print_xterm_colors `seq ${i} ${j}`
done

実行するとこんな感じになります。

スクリプトの実行結果