<div dir="ltr">I have committed this.<div><br></div><div>If there are academic references that a user should know or this</div><div>is theoretically based on, I would like to see them listed. Anything</div><div>that strengthens the user's understanding of where this originated.</div><div><br></div><div>It doesn't look like Chris has automatic updates on docs working yet</div><div>but it should show up before too long at <a href="https://docs.rtems.org/">https://docs.rtems.org/</a>.</div><div><br></div><div>Thanks.</div><div><br></div><div>--joel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 13, 2017 at 3:21 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was unable to compile rtems-docs (cleanly), so I have not committed<br>
this patch yet. If someone else who can compile docs can build with<br>
this patch, please commit. I need to debug my baseline build still...<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Dec 21, 2016 at 11:44 AM, Kuan-Hsun Chen <<a href="mailto:c0066c@gmail.com">c0066c@gmail.com</a>> wrote:<br>
> ---<br>
> c-user/rate_monotonic_manager.<wbr>rst | 30 +++++++++++++++++-------------<br>
> 1 file changed, 17 insertions(+), 13 deletions(-)<br>
><br>
> diff --git a/c-user/rate_monotonic_<wbr>manager.rst b/c-user/rate_monotonic_<wbr>manager.rst<br>
> index 8ad74e5..9ba22a5 100644<br>
> --- a/c-user/rate_monotonic_<wbr>manager.rst<br>
> +++ b/c-user/rate_monotonic_<wbr>manager.rst<br>
> @@ -132,7 +132,7 @@ milliseconds every 100 (10 percent of the CPU). As a general rule of thumb,<br>
> the higher frequency at which a task executes, the more important it is to<br>
> optimize that task.<br>
><br>
> -Rate Monotonic Manager Definitions<br>
> +Periodicity Definitions<br>
> ------------------------------<wbr>----<br>
> .. index:: periodic task, definition<br>
><br>
> @@ -170,7 +170,7 @@ Rate Monotonic Scheduling Algorithm<br>
> .. index:: RMS Algorithm, definition<br>
><br>
> The Rate Monotonic Scheduling Algorithm (RMS) is important to real-time systems<br>
> -designers because it allows one to guarantee that a set of tasks is<br>
> +designers because it allows one to sufficiently guarantee that a set of tasks is<br>
> schedulable. A set of tasks is said to be schedulable if all of the tasks can<br>
> meet their deadlines. RMS provides a set of rules which can be used to perform<br>
> a guaranteed schedulability analysis for a task set. This analysis determines<br>
> @@ -179,11 +179,11 @@ the predictability of the system's behavior. It has been proven that:<br>
><br>
> .. sidebar:: *RMS*<br>
><br>
> - RMS is an optimal static priority algorithm for scheduling independent,<br>
> + RMS is an optimal fixed-priority algorithm for scheduling independent,<br>
> preemptible, periodic tasks on a single processor.<br>
><br>
> RMS is optimal in the sense that if a set of tasks can be scheduled by any<br>
> -static priority algorithm, then RMS will be able to schedule that task set.<br>
> +fixed-priority algorithm, then RMS will be able to schedule that task set.<br>
> RMS bases it schedulability analysis on the processor utilization level below<br>
> which all deadlines can be met.<br>
><br>
> @@ -230,7 +230,7 @@ Schedulability Analysis<br>
><br>
> .. index:: RMS schedulability analysis<br>
><br>
> -RMS allows application designers to ensure that tasks can meet all deadlines,<br>
> +RMS allows application designers to ensure that tasks can meet all deadlines under fixed-priority assignment,<br>
> even under transient overload, without knowing exactly when any given task will<br>
> execute by applying proven schedulability analysis rules.<br>
><br>
> @@ -468,9 +468,10 @@ monotonic period results in one of the following scenarios:<br>
> immediately.<br>
><br>
> - If the rate monotonic period has expired before the task invokes the<br>
> - ``rtems_rate_monotonic_period`<wbr>` directive, the period will be initiated with<br>
> - a length of period ticks and the calling task returns immediately with a<br>
> - timeout error status.<br>
> + ``rtems_rate_monotonic_period`<wbr>` directive, the postponed job will be released<br>
> + until there is no more postponed jobs. The calling task returns immediately<br>
> + with a timeout error status. In the watchdog routine, the period will still<br>
> + be updated periodically and track the number of the postponed periods.<br>
><br>
> Obtaining the Status of a Period<br>
> ------------------------------<wbr>--<br>
> @@ -560,8 +561,8 @@ Subsequent invocations of the ``rtems_rate_monotonic_period`<wbr>` directive will<br>
> result in the task blocking for the remainder of the 100 tick period. If, for<br>
> any reason, the body of the loop takes more than 100 ticks to execute, the<br>
> ``rtems_rate_monotonic_period`<wbr>` directive will return the ``RTEMS_TIMEOUT``<br>
> -status. If the above task misses its deadline, it will delete the rate<br>
> -monotonic period and itself.<br>
> +status and the postponed job will be released. If the above task misses<br>
> +its deadline, it will delete the rate monotonic period and itself.<br>
><br>
> Task with Multiple Periods<br>
> --------------------------<br>
> @@ -629,8 +630,8 @@ will not block.<br>
><br>
> If, for any reason, the task misses any deadline, the<br>
> ``rtems_rate_monotonic_period`<wbr>` directive will return the ``RTEMS_TIMEOUT``<br>
> -directive status. If the above task misses its deadline, it will delete the<br>
> -rate monotonic periods and itself.<br>
> +directive status and the postponed job will be released. If the above task misses<br>
> +its deadline, it will delete the rate monotonic periods and itself.<br>
><br>
> Directives<br>
> ==========<br>
> @@ -839,7 +840,10 @@ DESCRIPTION:<br>
> period ticks. If id is running, then the calling task will block for the<br>
> remainder of the period before reinitiating the period with the specified<br>
> period. If id was not running (either expired or never initiated), the<br>
> - period is immediately initiated and the directive returns immediately.<br>
> + period is immediately initiated and the directive returns immediately.<br>
> + If id has expired its period, the postponed job will be released immediately<br>
> + and the following calls of this directive will release postponed<br>
> + jobs until there is no more deadline miss.<br>
><br>
> If invoked with a period of ``RTEMS_PERIOD_STATUS`` ticks, the current<br>
> state of id will be returned. The directive status indicates the current<br>
> --<br>
> 1.9.1<br>
><br>
> ______________________________<wbr>_________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div>