hos-v3: taskスケジューリング/SUSPENDとrdyque

• Informador: m-arai
• Propietario: m-arai
• Tipo: Patches
• Estado: Cerrado
• Componente: (Ninguno)
• Hito: (Ninguno)
• Prioridad: 7
• Gravedad: 5 - Medium
• Resolución: Postponed
• Fichero: 3

Details Responder

https://sourceforge.jp/forum/forum.php?thread_id=1699&forum_id=696

knakamuraさんよりの報告:
HOS-H8 V3のスケジューリングは、ディスパッチ要求を発行
しているタスクがあれば、既に実行しているタスクと同一優
先度であっても、タスクを切り替えてしまう。

「uITRON3.0標準ハンドブック」p.19には、「実行可能なタ
スクのうち、最高の優先度を持つタスクが1つだけ実行され
、そのタスクが待ちに入るなどの理由により実行不可能な状
態にならない限り、他のタスクは全く実行されない。」とあ
り、仕様と矛盾。


このようなことが発生するのは、レディキューが、
先頭 - task A(READY) - task B(RUNNING) - …
のようになっている状態で、ディスパッチが発生する場合
である。

この時、task Bは「実行可能なタスクのうち、最高の優先度
を持つタスク」であって「待ちに入るなどの理由により実行
不可能な状態にならない」にもかかわらず、ディスパッチに
よってREADYとなり、task Aが実行されることになってしま
う。

これを抑止するため、

1. タスク実行中におけるディスパッチ時の実行可能タスク
検索は、現実行タスクより上位の優先度のレディキューに
限り、その範囲で見つけられなければ、タスクスイッチを
発生させない。

という対処が考えられるが、この場合、

a) task Aがrot_rdqを発行しても無意味
b) 優先度内の優先順位は依然としてtask Aが上位である
ため、上位優先度で生じるディスパッチ時には同じ
ことになる

疑問点が残る。そこで、

2. 先に示したようなレディキューの状態を発生させない。
この状態は、キューに接続されたタスクが、SUSPEND→
READYと遷移した場合にのみ発生するから、SUSPEND状態
はレディーキューから削除する

という方針もあわせて提案する。

v3_task_1.diff.gzが 1.案による、
v3_task_2.diff.gzが 2.案による対策差分である。

Ticket History (3/6 Histories)

2003-01-06 21:48 Updated by: m-arai

• File 258: v3_task_1.diff.gz is attached

2003-01-06 21:49 Updated by: m-arai

• File 259: v3_task_2.diff.gz is attached

2003-01-07 23:12 Updated by: m-arai

Comentario Responder

Logged In: YES
user_id=1822

現状が仕様に矛盾しないという読み方も可能であるということを書
き忘れていた。


uITRON V3.0では、SUSPENDからrsm_tskによりREADYになる場合の、
レディーキュー
への挿入位置は実装依存である。従って、SUSPENDになっても
キューに繋がれたま
まで、rsm_tskするとその場でREADYになるというのは許容されると
思われる。
＃V4.0では同一タスク優先度中では最下位の優先順位になると規定
されている。

仕様の「実行可能なタスクのうち、最高の優先度を持つタスクが1
つだけ実行され」
の「優先度」が「同一タスク優先度内の優先順位」をも含むものと
するなら
ば、現在実行タスクと「タスク優先度」は同じでも「優先度」が高
い実行可能
タスクがrsm_tskにより現れる場合に、タスクスイッチが発生する
のは当然である。
よって、現状は仕様に矛盾しない。
＃が、やはり妙な感じはする。V4.0で整理された所を見ると、この
辺はV3.0
＃仕様の「穴」なのか...

2003-01-07 23:14 Updated by: m-arai

Comentario Responder

Logged In: YES
user_id=1822

現状が仕様に矛盾しないという読み方も可能であるということを書
き忘れていた。


uITRON V3.0では、SUSPENDからrsm_tskによりREADYになる場合の、
レディーキュー
への挿入位置は実装依存である。従って、SUSPENDになっても
キューに繋がれたま
まで、rsm_tskするとその場でREADYになるというのは許容されると
思われる。
＃V4.0では同一タスク優先度中では最下位の優先順位になると規定
されている。

仕様の「実行可能なタスクのうち、最高の優先度を持つタスクが1
つだけ実行され」
の「優先度」が「同一タスク優先度内の優先順位」をも含むものと
するなら
ば、現在実行タスクと「タスク優先度」は同じでも「優先度」が高
い実行可能
タスクがrsm_tskにより現れる場合に、タスクスイッチが発生する
のは当然である。
よって、現状は仕様に矛盾しない。
＃が、やはり妙な感じはする。V4.0で整理された所を見ると、この
辺はV3.0
＃仕様の「穴」なのか...

2003-01-10 08:12 Updated by: m-arai

• File 279: test.tgz is attached

Comentario Responder

Logged In: YES
user_id=1822

https://sourceforge.jp/forum/message.php?msg_id=3390

上記フォーラムで結果を示したテストプログラムを追試可能なように
添付。
但し、秋月C環境用の整備はしていない。

2003-04-01 19:08 Updated by: m-arai

• Ticket Close date is changed to 2003-04-01 19:08
• Resolución Update from Ninguno to Postponed
• Estado Update from Open to Cerrado

Comentario Responder

Logged In: YES
user_id=1822

一概にどちらという結論も出せず、論議も起きないことから、本件
は取り敢えず放置という形でcloseする。