Some confusion about the "First Deadline Rule"

Joel Sherrill joel.sherrill at OARcorp.com
Wed Sep 5 13:42:37 UTC 2012


Can any of this discussion be used as material to enhance
the section in the manual? This stuff is very hard to explain.

Tom .. any suggestions? Just emailing us a new version of
the section would help. It is just a few paragraphs.

On 09/05/2012 04:37 AM, Tom Smith wrote:
> hi Gedare
> Thank you very much for the quick reply.
> The relationship between "processor utilization rule" and "First 
> Deadline Rule"  you stated is clear and wonderfull.
> I think I got your key point. But I still need to read more to fully 
> understand RMS.
> Anyhow, thank you very much
> tom
> 2012/9/3 Gedare Bloom <gedare at rtems.org <mailto:gedare at rtems.org>>
>
>     On Mon, Sep 3, 2012 at 8:27 AM, Tom Smith <venture.g at gmail.com
>     <mailto: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 <mailto:rtems-users at rtems.org>
>     > http://www.rtems.org/mailman/listinfo/rtems-users
>     >
>
>


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120905/c9f3f088/attachment-0001.html>


More information about the users mailing list