The periodicity of scheduling

[Kuan Hsun Chen]

Hello All,

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.

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.

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.
Especially if the task has arbitrary deadline or even the task is a soft
real time task, this feature should behave correctly.
(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.)

Here I aim at a case that the task misses its deadline with the current
implementation.
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 *one* following instance
and manipulate the task period with *the calling moment + the next length
of period*. However, this way of scheduling is in fact changing the
behaviour of a periodic task:

   1. 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.
   2. 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.

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.

Please let me know if this feature is sound and essential. I can patch it.

Best Regards,
Kuan-Hsun

-- 
M.Sc. Kuan-Hsun Chen

TU Dortmund
Department of Computer Science 12
Design Automation of Embedded Systems
Otto-Hahn-Strasse 16, Room 102

44227 Dortmund
Germany

Phone:  *+49 231 755 6124*
Mail:   kuan-hsun.chen at tu-dortmund.de <kuan-hsun.chen at tu-dortmund.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160801/d85c91c5/attachment.html>