<div dir="ltr"><div><div><div><div><div>Hello All,<br><br></div>I have used rate_monotonic function series to do some cycle-accuracy emulation quite a long time. I believe that some missing features of scheduling are essentially required. As I'm not aware of any discussion about this before, please correct me if I misunderstand.<br></div><div><br></div>If I understand correctly, the current implementation of rtems_rate_monotonic_period() is explicitly assumed the implicit deadline or constraint deadline model that the task deadline is always less than or equal to the period deadline. If rtems_rate_monotonic_period() is called, it is the moment that either the task is finished on time or earlier than its period (or inactivate as the first call). If a task misses its period, the watchdog will mark the period as RATE_MONOTONIC_EXPIRED and update the deadline of watchdog. <br><br>However, the behavior is not correct currently. From my point of view, the periodic task should always release its workload on time, even it misses its deadline. If there are already two expired periods, the task should have two more remaining instances workload to execute.<br>Especially if the task has arbitrary deadline or even the task is a soft real time task, this feature should behave correctly.<br>(Soft Real Time task: If a task misses its deadline, it is still valuable to gather its result no matter when. If the utilization of uniprocessor is not 100%, the tardiness is proved to be bounded.)<br></div><br></div><div>Here I aim at a case that the task misses its deadline with the current implementation. <br>If a task period is time out (marked as RATE_MONOTONIC_EXPIRED), by referring to _Rate_monotonic_Block_while_expired(), the next call of rtems_rate_monotonic_period() will only release <b>one</b> following instance and manipulate the task period with <b>the calling moment + the next length of period</b>. However, this way of scheduling is in fact changing the behaviour of a periodic task:<br></div><ol><li>There may be more than one instances which are postponed due to the preemption of higher priority tasks. Trivially release only one instance is not correct in the sense of scheduling.<br></li><li>The period of expired task is shifted and unpredictable. This should be calculated correctly and rapidly by taking the time point of first period released. The deadline of watchdog in this case should be assigned with an absolute tick.</li></ol>I have enhanced this feature in the system by adding three additional counters in Rate_monotonic_Control structure and one more function to do the correct assignment of deadline and job release. I also prepare a heuristic example to demonstrate the results. I'm going to fix the case for arbitrary deadline later on.<br><br></div><div>Please let me know if this feature is sound and essential. I can patch it.<br></div><div><br>Best Regards,<br>Kuan-Hsun<br><br></div><div><div><div><div><div><div><div><div><div><div>-- <br><div class="gmail_signature"><div dir="ltr">M.Sc. Kuan-Hsun Chen<br>
<br>
TU Dortmund<br>
Department of Computer Science 12<br>
Design Automation of Embedded Systems<br>
Otto-Hahn-Strasse 16, Room 102<br>
<br>
44227 Dortmund<br>
Germany<br>
<br>
Phone:  <u><span style="color:rgb(0,0,255)">+49 231 755 6124</span></u><br>
Mail:   <a target="_blank" href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a><a target="_blank" href="mailto:kuan-hsun.chen@tu-dortmund.de"></a></div></div>
</div></div></div></div></div></div></div></div></div></div></div>