FreeRTOSにおけるタスクの遷移について

Joさん、こんにちは。NoMaYと申します。

ここまで詳細な動作の問い合わせは、本家FreeRTOSのフォーラムに問い合わせた方が良さそうに思います。(それが一番近道だと思うのです。) ただ、以下のウェブページを読んでみた印象では、「そのような場合には、実行中のタスクがブロック状態になるまで、同一優先度の他のタスクに切り替わることは無い」と明言されていないことから推測すると、仕様未定義なのではないでしょうか。(仕様というのを、意図してそういう動作にした、みたいな感じで捉えてのことですけれども。)

素朴には、同一優先度ですから、明言されていなければ、単に動くように動く、みたいなところではないかなぁ、と思ってしまうのです。記憶では、μITRONにはタイムスライス機能は無かったと思う一方で、FreeRTOSはタイムスライス機能ありで使うのがデフォルトだったと思うのですけれども、そのあたりから、このような場合の「単に動くように動く」という観点での挙動の違いも現れて来そうに思うのです。

タイムスライス機能無し → ブロック状態に遷移してレディキューの先頭から外されるまで実行され続けるのが自然な挙動な気がしますね(正しい言葉使いでは無いかも知れませんけれども)

タイムスライス機能あり → もともと同一優先度のタスクはラウンドロビンで切り替わっていくのだからブロック状態になるまで実行され続けることは自然では無い挙動な気がしますね

www.freertos.org/RTOS-task-states.html
www.freertos.org/RTOS-task-priority.html
www.freertos.org/single-core-amp-smp-rtos-scheduling.html
　

Joさん、こんにちは。NoMaYです。

＞ もともと同一優先度のタスクはラウンドロビンで切り替わっていく

一晩明けて思ったのですけれども、「そうだとしても、タイムスライス切り替え以外の要因で、同一優先度の他のタスクに切り替わってしまうとしたら、それはそれで仕様がザルなのではないですか？」と突っ込まれたとしますと、確かにそれもそうかも知れません、とも思ったのが今朝のことでした。

Joさん、NoMaYさん

こんにちは、シェルティです。ルネサスの中の人です。

ご報告いただき感謝いたします。

ただ何か本件変ですね。ちょっと連休中に実験して確かめてみます。例示いただいたtaskAとtaskBを生成し、Tracealyzerというツールを使って内部状態をモニタしてみようかと思います。そのあと必要に応じてAWS本社の技術メンバに確認してみようかと思います。

JoさんやNoMaYさんと同じくタイムスライスOFFなのにタスクが切り替わるのは変だとシェルティは思っています。

以上です

シェルティさん、こんにちは。NoMaYです。

実験する時、以下の点がミソ、なのではないかなぁ、と思ったのでした。

＞ この時タスクAがタスクBのBlocked状態を解除するシステムコールを呼んだとします。

あと、どのシステムコールで解除したかも影響するかも知れません。RTOSというと、プライオリティインバージョン(だったでしょうかね、、、)とか、本件とは直接関係無いかも知れませんけれども、特殊な事例があることですので。

NoMaYさん、シェルティさん

こんにちは、早速のご連絡ありがとうございます。

たしかにドキュメントに明言はされてないので、そういうものだと言われたらあきらめるしかないのですが、これまでμITRONで慣れていたので違和感がありました。

シェルティさん

実験までしていただけるということで、ありがとうございます。なお、使用したシステムコールは「xEventGroupSetBits」です。タスクBが「xEventGroupWaitBits」で待っている状態でした。

こちらからも進展ありましたらご報告したいと思います。

こんにちは。NoMaYです。

私の書いた以下の文面は、意図が伝わらない文面だったかも、という気がしてきました。

＞ タイムスライス機能無し → ブロック状態に遷移してレディキューの先頭から外されるまで実行され続けるのが自然な挙動な気がしますね(正しい言葉使いでは無いかも知れませんけれども)

＞ タイムスライス機能あり → もともと同一優先度のタスクはラウンドロビンで切り替わっていくのだからブロック状態になるまで実行され続けることは自然では無い挙動な気がしますね

上側はμITRONのことを指していて、そもそもOSにタイムスライス機能が無いのだから、このようにしか動きようが無い、と思いました、という感じのことを意図していました。

下側はFreeRTOSのことを指していて、タイムスライス機能があって、かつ、それを使うのがデフォルトであるようなOSなのであり、まずそのデフォルトのことを考えると、一旦選択されたタスクがブロック状態になるまで実行され続ける、という仕様は根本的に無いわけで(そういう動作ではラウンドロビンで切り替わることにならないですので)、にも関わらず、そのような仕様がコンフィグレーションでタイムスライス機能を無効にした途端に発現する、ということは考え難いよなぁ、と思いました、という感じのことを意図していました。

ただ、今朝思ったのは、そのデフォルトの場合で、タイムスライス切り替え以外の要因で、同一優先度の他のタスクに切り替わってしまうことが無いような(ちゃんとした？(というのは適切な言い回しでは無いのかも知れませんけれども))作りであったなら、結果的に、μITRONの場合と同じ動作になる筈かなぁ、とも思ったのでした。

逆に言うと、FreeRTOSでは、そのデフォルトの場合で、タイムスライス切り替え以外の要因で、同一優先度の他のタスクにタイムスライスの途中であってもポンポンと切り替わってしまっているのだろうなぁ、という気がしたのでした。それでも、そのうちラウンドロビンで、またタイムスライスの順番が回って来ますので、さほど差し障りは無さそう、と思いました。

＃すみません、知ったかぶりをしているだけ、だったとしたらちょっと恥ずかしいですけれども、、、

こんにちは。NoMaYです。

私の書いた以下の文面は、意図が伝わらない文面だったかも、という気がしてきました。

＞ タイムスライス機能無し → ブロック状態に遷移してレディキューの先頭から外されるまで実行され続けるのが自然な挙動な気がしますね(正しい言葉使いでは無いかも知れませんけれども)

＞ タイムスライス機能あり → もともと同一優先度のタスクはラウンドロビンで切り替わっていくのだからブロック状態になるまで実行され続けることは自然では無い挙動な気がしますね

上側はμITRONのことを指していて、そもそもOSにタイムスライス機能が無いのだから、このようにしか動きようが無い、と思いました、という感じのことを意図していました。

下側はFreeRTOSのことを指していて、タイムスライス機能があって、かつ、それを使うのがデフォルトであるようなOSなのであり、まずそのデフォルトのことを考えると、一旦選択されたタスクがブロック状態になるまで実行され続ける、という仕様は根本的に無いわけで(そういう動作ではラウンドロビンで切り替わることにならないですので)、にも関わらず、そのような仕様がコンフィグレーションでタイムスライス機能を無効にした途端に発現する、ということは考え難いよなぁ、と思いました、という感じのことを意図していました。

ただ、今朝思ったのは、そのデフォルトの場合で、タイムスライス切り替え以外の要因で、同一優先度の他のタスクに切り替わってしまうことが無いような(ちゃんとした？(というのは適切な言い回しでは無いのかも知れませんけれども))作りであったなら、結果的に、μITRONの場合と同じ動作になる筈かなぁ、とも思ったのでした。

逆に言うと、FreeRTOSでは、そのデフォルトの場合で、タイムスライス切り替え以外の要因で、同一優先度の他のタスクにタイムスライスの途中であってもポンポンと切り替わってしまっているのだろうなぁ、という気がしたのでした。それでも、そのうちラウンドロビンで、またタイムスライスの順番が回って来ますので、さほど差し障りは無さそう、と思いました。

＃すみません、知ったかぶりをしているだけ、だったとしたらちょっと恥ずかしいですけれども、、、