Changeset 5ab8aef in rtems

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:

• ChangeLog (modified) (1 diff)
• rtmon.t (modified) (9 diffs)

doc/user/ChangeLog

@@ +1 @@
+2002-03-15      Eric Norum <eric.norum@usask.ca>
+
+        * rtmon.t: Correct example and correctly used ensure not insure.
+
 2002-01-18      Ralf Corsepius <corsepiu@faw.uni-ulm.de>
 

doc/user/rtmon.t

@@ -38 +38 @@
 manage the execution of periodic tasks.  This manager was
 designed to support application designers who utilize the Rate
-Monotonic Scheduling Algorithm (RMS) to insure that their
+Monotonic Scheduling Algorithm (RMS) to ensure that their
 periodic tasks will meet their deadlines, even under transient
 overload conditions.  Although designed for hard real-time
@@ -83 +83 @@
 sporadic task could be used to process the pressing of a fire
 button on a joystick.  The mechanical action of the fire button
-insures a minimum time period between successive activations,
+ensures a minimum time period between successive activations,
 but the missile must be launched by a hard deadline.
 
@@ -211 +211 @@
 @cindex RMS schedulability analysis
 
-RMS allows application designers to insure that tasks
+RMS allows application designers to ensure that tasks
 can meet all deadlines, even under transient overload, without
 knowing exactly when any given task will execute by applying
@@ -265 +265 @@
 @end example
 
-To insure schedulability even under transient
+To ensure schedulability even under transient
 overload, the processor utilization must adhere to the following
 rule:
@@ -380 +380 @@
 are assumed to start at the exact same instant in time.
 Although this assumption may seem to be invalid,  RTEMS makes it
-quite easy to insure.  By having a non-preemptible user
+quite easy to ensure.  By having a non-preemptible user
 initialization task, all application tasks, regardless of
 priority, can be created and started before the initialization
-deletes itself.  This technique insures that all tasks begin to
+deletes itself.  This technique ensures that all tasks begin to
 compete for execution time at the same instant -- when the user
 initialization task deletes itself.
@@ -389 +389 @@
 @subsection First Deadline Rule Example
 
-The First Deadline Rule can insure schedulability
+The First Deadline Rule can ensure schedulability
 even when the Processor Utilization Rule fails.  The example
 below is a modification of the Processor Utilization Rule
@@ -716 +716 @@
 @page
 @example
-rtems_task Periodic_task()
+rtems_task Periodic_task(rtems_task_argument arg)
 @{
   rtems_name        name;
@@ -778 +778 @@
 @page
 @example
-task Periodic_task()
+rtems_task Periodic_task(rtems_task_argument arg)
 @{
   rtems_name        name_1, name_2;
@@ -837 +837 @@
 tick period established by period_1.  The
 @code{@value{DIRPREFIX}rate_monotonic_cancel( period_2 )}
-call is performed to insure that the period_2 period
+call is performed to ensure that the period_2 period
 does not expire while the task is blocked on the period_1
 period.  If this cancel operation were not performed, every time
-the @code{@value{DIRPREFIX}rate_monotonic_period( period_1, 40 )}
+the @code{@value{DIRPREFIX}rate_monotonic_period( period_2, 40 )}
 call is executed, except for the initial one, a directive status
 of @code{@value{RPREFIX}TIMEOUT} is returned.  It is important to
-note that every time this call is made, the period_1 period will be
+note that every time this call is made, the period_2 period will be
 initiated immediately and the task will not block.