The periodicity of scheduling

[Gedare Bloom]

On Mon, Aug 1, 2016 at 9:49 AM, Kuan Hsun Chen
<kuan-hsun.chen at tu-dortmund.de> wrote:
> 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.
>
Yes I think you understand correctly. Except, I don't think the
deadline of the watchdog is updated by the 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:
>
> 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.

I understand that counting the number of missed deadlines could be
correct for certain applications. The way to handle missed deadlines
should be a parameter of the RM manager though, since handling missed
deadlines is application specific property of how "soft" the deadlines
are.

> 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.
>
Yes. I would deal with this by having the watchdog timeout reprogram
itself with the next period immediately when it expires in
_Rate_monotonic_Timeout, along with incrementing the RM_Control
counter for currently missed deadlines/pending jobs. This way another
expiration indicates another deadline miss, or so the task finishes
its current job it can immediately start the next job with the correct
deadline already programmed in the watchdog.

> 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.
>
By arbitrary deadline you mean explicit deadlines? I don't think this
is a common requirement, but it would be a welcome addition if the
complexity is not that great and the common case (implicit deadline)
is negligibly affected.

> Please let me know if this feature is sound and essential. I can patch it.
>
The feature seems useful for some applications, but may be not all of
them will want to have this behavior for a missed deadline.

> 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
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users