Some confusion about the "First Deadline Rule"

[Gedare Bloom]

On Mon, Sep 3, 2012 at 8:27 AM, Tom Smith <venture.g at gmail.com> wrote:
> Hi everyone,
>
> I am studying Chapter 19 "Rate Monotonic Manager"  of c_user.pdf, and I get
> some questions
>
> In c_user.pdf, it says
>
> "For a given set of independent periodic tasks, if each task meets its first
> deadline when all
> tasks are started at the same time, then the deadlines will always be met
> for any combination
> of start times."
>
> my question is that:
> 1. If a set of  independent periodic tasks do not meet the "Processor
> Utilization Rule",  but they satisfy the "First Deadline Rule",  can they be
> scheduled  using RMS ?
>
Yes; you may like to consult a handbook on real-time systems for
detailed explanations, but I'll make an effort here. The processor
utilization rule is a sufficient but not necessary test for
schedulability; some systems are schedulable that do not satisfy the
maximum processor utilization bounds. The "First Deadline Rule" is a
way to simplify the analysis of when tasks may start by stating the
worst-case scheduling window happens when all tasks start at the same
time; releasing all tasks at once ensures that every task has a
critical instant at the same time; this rule coincides with the
critical instance theorem. When you don't have simultaneous release of
tasks you cannot be certain when the critical instance of a given task
will occur, in which case you may need to compute the entire
hyperperiod; for non-harmonic task sets the hyperperiod could be
prohibitively large. (Harmonic periodic tasks are typically quite easy
to test for schedulability.)

> 2. Is it necessary to start all tasks at the same time in a real
> application, or  is it just a trick during analysis phase?
>
I suppose that depends how closely you want your analysis to match
your application. If you analyze with simultaneous release but do not
ensure that during execution then what have you analyzed? You cannot
be certain your application will meet its deadlines anymore. In this
case you should use a schedulability test that does not require
simultaneous release.

-Gedare

> any review on this point from anyone is welcomed. So feel  free to  comment.
> Best regards,
>
> Tom Smith
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>