というわけで、なんとなく気になったので書いてみたくなったネタです。電子工作系と教育系を兼ね備えるものといえばmicro:bitな訳ですが、そのタスクシステムにちょっとした疑問があるので考察して+調べてみよう、というわけです。
MakeCode(Scratch)でmicro:bitのプログラムを作った時を前提とする
micro:bitで動くプログラムを作ることができるツールはいくつかあるわけですが、今回はMicrosoftのMakeCodeを前提としたいと思います。MuやらPython Editor for micro:bitやらあるのですが、小学校や中学校でも使えるレベルで、となると大半がMakeCode経由のような気がしますので、これで話をしたいと思います。
「ずっと(forever）」を何個も使うと一体どんな実行のされ方をするのか？
まずはこれを見てください。
MakeCodeである３つのブロックを使おうとしたときの状態です。見てわかるとおり「最初だけ」のように複数あると意味がわからなくなるものや「ボタン○○を押したとき」のように、入力の割り込みによって動くのものは１つしか有効にならないようになっています。これはわかります。
ところが、「ずっと(forever)」に当たるブロックを作ろうとすると上の図にあるように２個作ってもどちらも有効です。なお、基本的には何個でも有効になります。つまり、「すべて動作させることができる」という（プログラムをやったことがない人から見ると）不思議な現象が発生します。だとすると「Aをずっと繰り返す」「Bをずっと繰り返す」「Cをずっと繰り返す」を同時にしたいときに「A、B、Cの順にしてそれを繰り返す」のように無理に直列化して書かなくても個別に書いてよい、ということになるのでしょうか。これをちょっと見てみたいと思います。
次のように書くとどう実行されるのか？
というわけで、こういうプログラムを作りました。
「ずっと」ブロック×３と「ボタンAが押されたとき」の動作です。ちなみにこれはちょっとしたトリックがあって、「ずっと」のブロックの上下が0の出力と256の出力だと256の出力が下になるように配置しています。
で、これを（あくまでシミュレータ上ですが）実行するとこういう動きになります。
「0を出力」→「256を出力」→「512を出力」→「0を出力」→「256を出力」→「512を出力」→「0を出力」→…
つまり、「ずっと」のブロックを上から3つを順番に回しながらに実行しているだけ、となりました。ちなみにボタンAによる割り込みをかけてみたのですが、「ずっと」による実行順番は変わらず、という結果になっています。あくまでシミュレータ上ですのでオシロスコープなどで実機計測すると微妙に違うかもしれません。
これについてはある程度推測ができて、
- 「ずっと」ブロックを使うとそれぞれがタスクとして独立に実行待ちキューに入る
- 実行時間になると実行待ちキューの先頭にあるタスクが実行状態となり実行される
- ブロックの実行が終了すると再度実行待ちキューの最後に入り待機状態となる
- 割り込みは特別なタスク扱いとなり、「ずっと」のタスクが実行されていないときにチェックされて状態が確認されればタスクとして実行される
という動きになっているのではないか、というものです。で、これをチェックするために「このプログラムをPython（もどき）で表したもの」とタスク実行に関する説明書（のようなもの）を見て確認してみました。
このプログラムをPythonで表すと…
MakeCodeのPythonで表す機能を使ってプログラムを変換するとこうなりました。
def on_button_pressed_a():
pins.analog_write_pin(AnalogPin.P0, 768)
input.on_button_pressed(Button.A, on_button_pressed_a)
def on_forever():
pins.analog_write_pin(AnalogPin.P0, 0)
basic.forever(on_forever)
def on_forever2():
pins.analog_write_pin(AnalogPin.P0, 256)
basic.forever(on_forever2)
def on_forever3():
pins.analog_write_pin(AnalogPin.P0, 512)
basic.forever(on_forever3)
どうでしょうか。「ずっと」の３つのブロックがon_forever関数、on_forever2関数、on_forever3関数の３つとして定義され、basic.forever関数を呼び出して渡されています。このコードとシミュレータの動きから推測するとbasic.foreverの動きは「渡された関数を（無限実行をする）実行待ちキューに登録する」ものだと考えられます。リファレンスのbasic.foreverの説明ではforeverのループとeventのループについて少し書いてありましたが、この動作については明確には改訂ないような気がします。
タスク実行に関する説明から考察してみる
で、このforeverの動きや「バックグラウンドで実行する」とはどういうことか？を説明しているのが（直リンクは張りませんが）「The micro:bit – a reactive system」というところです。micro:bitのタスク実行について実行間隔やポーリング、タスクを並行(Concurrent)で実行する方法について、ボタンを押す、などのイベントがあったときにどう動くのか？といったことについて詳しく書いてありますので見てみるとよいと思います。プログラム、特に組み込み処理に関して詳しい人ならば読めると思いますが、今回の処理に必要な部分を読んでみると、
- サブルーチン(この場合はforeverとして登録されるタスク)を登録するときには優先度がないタスクとして実行待ちキューに入る
- 一時停止(Pause処理）がタスク上で発生したときに一時停止キューで時間待ちを行う
- システムによりタスクが実行可能となったときは実行待ちキューの先頭にあるタスクを削除し実行状態に戻す
- 実行終了するか一時停止時間が経過したサブルーチン(foreverタスク)は実行待ちキューの最後に戻す
と書いてあることから上の考察の大半は合っているのではないか、と思われます。
「ずっと」ブロック内の時間待ちについて
micro:bitの時間待ちのうち「一時停止」よる時間待ちは上の説明から「一時停止キューにタスクを移す」ことにより待ちを行っていますので一度実行状態から抜けることになります。そのため、別のforever処理や入力割り込みによる処理などがあればそれを実行する時間がとれることになります。しかし「whiteなどによる無駄ループを使った時間待ち」は上の説明からmicro:bitのタスクとして待ち状態や実行待ちには移らず実行状態のままになりますのでタスク切り替えがうまくできません。そのため、入力の検知などを行う時間で割り込みそのものは検知できるのですが、割り込み後に動かすルーチンは実行待ちキューに移されるだけとなり実行されない、ということになるかと思います。
これは特にforever関数で長い処理を実行するタイプのタスク+ある程度の反応速度が求められる処理だとちょっと厳しいことになるかと思いますのでロボット操作をやるときやある程度速い周期で処理する必要があるルーチンでは気をつける必要があるかと思います。そもそもタスクの切り替え周期もどれだけ出せるのか微妙なところですか。
単に教育用として簡単なものを作るだけなら知る必要はないが…
例えば自由研究などで複雑なプログラムを作り実行させるとうまく動かない、というときにこういうことが絡んでいる可能性はあるかな～という例でした。MicroPythonを入れる例だとこういう風に動くのかどうかはまた別の検証が必要そうなので今はしません。ADVゲームシステムなどで本体内に別のスクリプトシステム(Luaなど)を使うタイプだと似たような現象が発生するのでちょっと調べてみた、というところにしておいてください。はい。