Some confusion about the "First Deadline Rule"

[Tom Smith]

hi joel

Glad to receive an email from you. To me, you are the God of RTEMS world. :)

For me, it is totally ok to use the discussion as a supplement to that
section in manual.
I think gedare's attitude is more important, because gedare provided the
deep insight on this topic.

For now,  I think I am just new to RTEMS and not sufficient to write some
usefull material. But I am studying
an OS course from Internet,  I will come up with a new version of that
section when I finished the scheduling chapters.

Best regards

Tom

2012/9/5 Joel Sherrill <joel.sherrill at oarcorp.com>

> 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>
>
>> 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
>> >
>>
>
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research&  Developmentjoel.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/94f3a189/attachment-0001.html>