コグノスケ

signalの未定義動作を見る - その1

目次: C言語とlibc

シグナルマスクのマニュアル（sigprocmaskのマニュアル）を見ると下記のように「規定されていない」とあります。実際Linuxだとどうなるか気になります。

マルチスレッドのプロセスでsigprocmask()を使用した場合の動作は規定されていない。

実行環境は下記のとおりです。他のプラットフォームや過去/将来のバージョンのLinuxで今回の実験結果と同じ動作をするとは限りませんのでご注意ください。

• Debian Testing (trixie/sid)
• Linux 6.12.12-1

実験内容は5つのマルチスレッド（親スレッド＋4つの子スレッド）で全員でsigwait()するのは共通、誰がsigprocmask()を呼ぶか？を変えながら、下記4パターンを試します。

• 最初のスレッドがsigprocmask()
• 最初のスレッド「以外」の1スレッドがsigprocmask()
• 全スレッドがsigprocmask()
• 全スレッドがpthread_sigmask()

最後のパターンはマルチスレッドでsigwait()する場合の正しい方法（全スレッドがpthread_sigmask()）で、他の3つと動作を比較するためのものです。

プログラム

コードは長くなってしまったので最後にファイルへのリンクを張っておきます。

実験方法はコンパイル時にマクロを適宜切り替えて、生成された./a.outを起動し、別のターミナルからkillコマンドなどでSIGUSR1を送るだけです。

結果1 - 最初のスレッドがsigprocmask()

最初のスレッドがsigprocmask()した場合です。ゆっくり5回シグナルを送ると、親スレッド（th 4）のsigwait()がシグナルを受け取り、子スレッド（th 0）のsigwait()はEINTRが返ってきます。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK -DID_MAINTHREAD=4 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: sub  (child ) thread start
th  1: sub  (child ) thread start
th  2: sub  (child ) thread start
th  4: main (parent) thread start
th  4: sigprocmask(block)
th  3: sub  (child ) thread start
th  3: loop start
th  2: loop start
th  4: loop start
th  0: loop start
th  1: loop start
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)

一見すると良い感じに動くように見えますが、大量にシグナルを送りつけるとabortします。ありゃりゃ。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK -DID_MAINTHREAD=4 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: sub  (child ) thread start
th  1: sub  (child ) thread start
th  2: sub  (child ) thread start
th  4: main (parent) thread start
th  4: sigprocmask(block)
th  3: sub  (child ) thread start
th  3: loop start
th  1: loop start
th  0: loop start
th  2: loop start
th  4: loop start
ユーザー定義シグナル1


（別ターミナルから）
$ while :; do kill -USR1 123450; if [ $? -ne 0 ]; then break; fi; done

一見動くように見えて、だめなパターンですね。

結果2 - 最初のスレッド「以外」の1スレッドがsigprocmask()

最初のスレッド「以外」の1スレッドがsigprocmask()した場合です。1回シグナルを送っただけでabortしました。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK -DID_MAINTHREAD=0 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: main (child ) thread start
th  0: sigprocmask(block)
th  1: sub  (child ) thread start
th  2: sub  (child ) thread start
th  4: sub  (parent) thread start
th  3: sub  (child ) thread start
th  3: loop start
th  0: loop start
th  2: loop start
th  1: loop start
th  4: loop start
ユーザー定義シグナル1

結果1の動きを見る限り納得の結果と言えるでしょう。シグナルは常に親スレッドにも飛んでいたので、シグナルをマスクしてない親スレッドはabortするのはそりゃそうだなと思います。

続きはまた今度やります。

ソースコード

こちらからどうぞ。

•  ソースコード

JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信改善

目次: Arduino

M5Stamp C3 + Raspberry Piを組み合わせて作った的あてゲーム、秋葉原のTarget-1（お店のサイト）で壊れることなく1年ほど安定稼働しているようです。良かった良かった。しかし最近、故障ではないもののタイトル画面に戻ってしまう頻度が増えているそうです。

ゲーム画面の例

以前に日記で紹介したとおり、的あてゲームのシステムはM5Stamp C3をBluetooth LEデバイスにして、Linux PCもしくはRaspberry PiなどのLinux SBCと通信しています。Bluetoothの接続が切れるとタイトル画面に戻って再接続する実装にしていますので、不意にタイトル画面に戻る = Bluetoothの接続が切断されていることを意味します。

原因の仮説と対策

お店での運用を見ていると、ゲームリザルト画面で放置されることが多いです。今の実装ではリザルト画面でBluetoothの通信を一切行いません。あまりにも長い間通信しないとBluetooth接続が切れてしまう？のかもしれません。

とりあえず今回は小手先の対処として、リザルト画面でM5Stamp C3本体のLEDを点滅させる指令を送り続け、Bluetooth接続を維持するようにしました。家でテストしてみたところ1日以上放置しても接続を維持できています。

代償として消費電力が0.1Wくらい増えますが、何度もタイトル画面に戻されるよりはマシでしょう……。

目指すは先代の実績？

先代のTSS（ターゲットシューティングシステム、作者さんの紹介サイト）は5年位稼働していたらしい（すごい！）ので、追いつくにはあと4年ですか、長いな〜……。

4年後を考えてみると、Linux側のマシンROCK 3Cはほぼ確実にEOL（End Of Life、生産終了、販売終了）だと思います。Linux側のシステムはHW依存は少ないし、SWも枯れたやつが多いので、そのとき販売されているお買い得なARM SBCボード（Raspberry Pi 6とか7とか？ROCK 3C後継のボードとか）への乗り換えは容易だと思います。

困るのはM5Stamp C3ですね。EOLになると別ボードへのSW移植とドッキングするためのボード再設計が必要でしょう。M5Stampは安くて良いんですけど、世代ごとに形がガンガン変わって互換性ゼロなのが良くない点ですね。作り直すとしたら、今のM5Stamp C3の2枚使い設計はダサいので、I/Oピン数の多いボード1枚に改めると思います。

timespecの操作関数

目次: C言語とlibc

POSIXには時間を表す構造体が2つあります。マイクロ秒単位のstruct timevalと、ナノ秒単位のstruct timespecです。struct timespecの方が後発なのか、比較的新しいAPIはstruct timespecを使う傾向にありますが、基本的には混在しています。

struct timeval {
    time_t      tv_sec;     /* 秒 */
    suseconds_t tv_usec;    /* マイクロ秒 */
};

struct timespec {
    time_t tv_sec;     /* 秒 */
    long   tv_nsec;    /* ナノ秒 */
};

見てのとおり構造体ですから、足し算や引き算をするにも桁上がりを考える必要があって一苦労必要かと思いきや、POSIXはtimeradd/timersubなどのマクロを用意しており、struct timevalの加減算と比較などが比較的簡単に行えます。便利ですね。

ではstruct timespecにも同様にtimespecadd/timespecsubがあると思いますよね？ところが一部のlibc（BSD系やnewlib）以外は実装していません。なぜ……！？

#define timespecadd(a, b, res)					\
	do {							\
		(res)->tv_sec = (a)->tv_sec + (b)->tv_sec;	\
		(res)->tv_nsec = (a)->tv_nsec + (b)->tv_nsec;	\
		if ((res)->tv_nsec >= 1000000000) {		\
			(res)->tv_sec++;			\
			(res)->tv_nsec -= 1000000000;		\
		}						\
	} while (0)
#define timespecsub(a, b, res)					\
	do {							\
		(res)->tv_sec = (a)->tv_sec - (b)->tv_sec;	\
		(res)->tv_nsec = (a)->tv_nsec - (b)->tv_nsec;	\
		if ((res)->tv_nsec < 0) {			\
			(res)->tv_sec--;			\
			(res)->tv_nsec += 1000000000;		\
		}						\
	} while (0)
#define timespecclear(tsp)    ((tsp)->tv_sec = (tsp)->tv_nsec = 0)
#define timespecisset(tsp)    ((tsp)->tv_sec || (tsp)->tv_nsec)
#define timespeccmp(a, b, cmp)					\
	(((a)->tv_sec == (b)->tv_sec) ?				\
		((a)->tv_nsec cmp (b)->tv_nsec) :		\
		((a)->tv_sec cmp (b)->tv_sec))

いつもstruct timespecを要求するAPIを使うたびにtimespecadd/timespecsubがなくて演算しづらさにイライラするので、コピペで使い回せるように実装例をメモしておきます。この程度なら誰が書いてもほとんど同じコードになると思いますが、気になる方のためにもし著作権が発生する場合はBSD 3条項ライセンス扱いでお願いします。

首都高バトルSteam版、フルチューン後の姿 - その3

目次: ゲーム

首都高バトル（Steam版）高ランクの車をひたすらフルチューンするやつの続きです。前回と合わせて8車種ほどフルチューンしました。もう飽きました。

SUZUKI SWIFT Sport(ZC33S)フルチューン

TOYOTA SUPRA RZ(JZA80)フルチューン

検索用にフルチューン後の主要パラメータを書いておきます。ちなみにスピード指標はギア比を最高速重視にすると高い数値になるので、参考程度です。

あとはインプレッサのどれかをフルチューンするかもなあくらいですが、あまり気力が沸きません。

ローダウンの謎

アップデート前は車高は下げれば下げるほどカーブが速くなる謎システムでしたが、アップデート後は限界まで車高を下げるとストレートで地面と擦って火花が出る＆逆に遅くなる変更が入ったそうです。キャプチャでは5段階のうち4まで下げた状態で撮っています。個人的には見た目は3か2くらいが一番バランスが良いですね。

RX-7のフロントRIDE HIGHT = -5

5まで下げるとおかしなことが起きる車もあって、RX-7はフロントを限界まで下げるとタイヤがフェンダーとボンネットを貫通して変な表示になります……。