Changeset 5ab8aef in rtems


Ignore:
Timestamp:
Mar 15, 2002, 7:03:52 PM (20 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.8, 4.9, 5, master
Children:
293c0e30
Parents:
dee576c
Message:

2002-03-15 Eric Norum <eric.norum@…>

  • rtmon.t: Correct example and correctly used ensure not insure.
Location:
doc/user
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/user/ChangeLog

    rdee576c r5ab8aef  
     12002-03-15      Eric Norum <eric.norum@usask.ca>
     2
     3        * rtmon.t: Correct example and correctly used ensure not insure.
     4
    152002-01-18      Ralf Corsepius <corsepiu@faw.uni-ulm.de>
    26
  • doc/user/rtmon.t

    rdee576c r5ab8aef  
    3838manage the execution of periodic tasks.  This manager was
    3939designed to support application designers who utilize the Rate
    40 Monotonic Scheduling Algorithm (RMS) to insure that their
     40Monotonic Scheduling Algorithm (RMS) to ensure that their
    4141periodic tasks will meet their deadlines, even under transient
    4242overload conditions.  Although designed for hard real-time
     
    8383sporadic task could be used to process the pressing of a fire
    8484button on a joystick.  The mechanical action of the fire button
    85 insures a minimum time period between successive activations,
     85ensures a minimum time period between successive activations,
    8686but the missile must be launched by a hard deadline.
    8787
     
    211211@cindex RMS schedulability analysis
    212212
    213 RMS allows application designers to insure that tasks
     213RMS allows application designers to ensure that tasks
    214214can meet all deadlines, even under transient overload, without
    215215knowing exactly when any given task will execute by applying
     
    265265@end example
    266266
    267 To insure schedulability even under transient
     267To ensure schedulability even under transient
    268268overload, the processor utilization must adhere to the following
    269269rule:
     
    380380are assumed to start at the exact same instant in time.
    381381Although this assumption may seem to be invalid,  RTEMS makes it
    382 quite easy to insure.  By having a non-preemptible user
     382quite easy to ensure.  By having a non-preemptible user
    383383initialization task, all application tasks, regardless of
    384384priority, can be created and started before the initialization
    385 deletes itself.  This technique insures that all tasks begin to
     385deletes itself.  This technique ensures that all tasks begin to
    386386compete for execution time at the same instant -- when the user
    387387initialization task deletes itself.
     
    389389@subsection First Deadline Rule Example
    390390
    391 The First Deadline Rule can insure schedulability
     391The First Deadline Rule can ensure schedulability
    392392even when the Processor Utilization Rule fails.  The example
    393393below is a modification of the Processor Utilization Rule
     
    716716@page
    717717@example
    718 rtems_task Periodic_task()
     718rtems_task Periodic_task(rtems_task_argument arg)
    719719@{
    720720  rtems_name        name;
     
    778778@page
    779779@example
    780 task Periodic_task()
     780rtems_task Periodic_task(rtems_task_argument arg)
    781781@{
    782782  rtems_name        name_1, name_2;
     
    837837tick period established by period_1.  The
    838838@code{@value{DIRPREFIX}rate_monotonic_cancel( period_2 )}
    839 call is performed to insure that the period_2 period
     839call is performed to ensure that the period_2 period
    840840does not expire while the task is blocked on the period_1
    841841period.  If this cancel operation were not performed, every time
    842 the @code{@value{DIRPREFIX}rate_monotonic_period( period_1, 40 )}
     842the @code{@value{DIRPREFIX}rate_monotonic_period( period_2, 40 )}
    843843call is executed, except for the initial one, a directive status
    844844of @code{@value{RPREFIX}TIMEOUT} is returned.  It is important to
    845 note that every time this call is made, the period_1 period will be
     845note that every time this call is made, the period_2 period will be
    846846initiated immediately and the task will not block.
    847847
Note: See TracChangeset for help on using the changeset viewer.