<div dir="ltr">Committed. Thanks for the detailed read and fixes.<div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 15, 2020 at 7:10 PM Richi Dubey <<a href="mailto:richidubey@gmail.com">richidubey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---<br>
 c-user/scheduling_concepts.rst | 50 +++++++++++++++++-----------------<br>
 1 file changed, 25 insertions(+), 25 deletions(-)<br>
<br>
diff --git a/c-user/scheduling_concepts.rst b/c-user/scheduling_concepts.rst<br>
index dac39a8..d329bc4 100644<br>
--- a/c-user/scheduling_concepts.rst<br>
+++ b/c-user/scheduling_concepts.rst<br>
@@ -16,7 +16,7 @@ Introduction<br>
 ============<br>
<br>
 The concept of scheduling in real-time systems dictates the ability to provide<br>
-immediate response to specific external events, particularly the necessity of<br>
+an immediate response to specific external events, particularly the necessity of<br>
 scheduling tasks to run within a specified time limit after the occurrence of<br>
 an event.  For example, software embedded in life-support systems used to<br>
 monitor hospital patients must take instant action if a change in the patient's<br>
@@ -38,7 +38,7 @@ The directives provided by the scheduler manager are:<br>
 - rtems_scheduler_get_maximum_priority_ - Get maximum task priority of a scheduler<br>
<br>
 - rtems_scheduler_map_priority_to_posix_ - Map task priority to POSIX thread<br>
-  prority<br>
+  priority<br>
<br>
 - rtems_scheduler_map_priority_from_posix_ - Map POSIX thread priority to task<br>
   prority<br>
@@ -58,8 +58,8 @@ The directives provided by the scheduler manager are:<br>
 Scheduling Algorithms<br>
 ---------------------<br>
<br>
-RTEMS provides a plugin framework which allows it to support multiple<br>
-scheduling algorithms. RTEMS includes multiple scheduling algorithms and the<br>
+RTEMS provides a plugin framework that allows it to support multiple<br>
+scheduling algorithms. RTEMS includes multiple scheduling algorithms, and the<br>
 user can select which of these they wish to use in their application at<br>
 link-time.  In addition, the user can implement their own scheduling algorithm<br>
 and configure RTEMS to use it.<br>
@@ -69,8 +69,8 @@ select the algorithm which is most appropriate to their use case. Most<br>
 real-time operating systems schedule tasks using a priority based algorithm,<br>
 possibly with preemption control.  The classic RTEMS scheduling algorithm which<br>
 was the only algorithm available in RTEMS 4.10 and earlier, is a fixed-priority<br>
-scheduling algorithm.  This scheduling algoritm is suitable for uniprocessor<br>
-(e.g. non-SMP) systems and is known as the *Deterministic Priority<br>
+scheduling algorithm.  This scheduling algorithm is suitable for uniprocessor<br>
+(e.g., non-SMP) systems and is known as the *Deterministic Priority<br>
 Scheduler*.  Unless the user configures another scheduling algorithm, RTEMS<br>
 will use this on uniprocessor systems.<br>
<br>
@@ -87,7 +87,7 @@ in time is the one with the highest priority among all tasks in the ready<br>
 state.<br>
<br>
 When a task is added to the ready chain, it is placed behind all other tasks of<br>
-the same priority.  This rule provides a round-robin within priority group<br>
+the same priority.  This rule provides a round-robin within a priority group<br>
 scheduling characteristic.  This means that in a group of equal priority tasks,<br>
 tasks will execute in the order they become ready or FIFO order.  Even though<br>
 there are ways to manipulate and adjust task priorities, the most important<br>
@@ -100,7 +100,7 @@ rule to remember is:<br>
<br>
 Priority scheduling is the most commonly used scheduling algorithm.  It should<br>
 be used by applications in which multiple tasks contend for CPU time or other<br>
-resources and there is a need to ensure certain tasks are given priority over<br>
+resources, and there is a need to ensure certain tasks are given priority over<br>
 other tasks.<br>
<br>
 There are a few common methods of accomplishing the mechanics of this<br>
@@ -127,7 +127,7 @@ algorithm.  These ways involve a list or chain of tasks in the ready state.<br>
   the ready queue.<br>
<br>
 RTEMS currently includes multiple priority based scheduling algorithms as well<br>
-as other algorithms which incorporate deadline.  Each algorithm is discussed in<br>
+as other algorithms that incorporate deadline.  Each algorithm is discussed in<br>
 the following sections.<br>
<br>
 Uniprocessor Schedulers<br>
@@ -142,13 +142,13 @@ Deterministic Priority Scheduler<br>
 --------------------------------<br>
<br>
 This is the scheduler implementation which has always been in RTEMS.  After the<br>
-4.10 release series, it was factored into pluggable scheduler selection.  It<br>
+4.10 release series, it was factored into a pluggable scheduler selection.  It<br>
 schedules tasks using a priority based algorithm which takes into account<br>
 preemption.  It is implemented using an array of FIFOs with a FIFO per<br>
 priority.  It maintains a bitmap which is used to track which priorities have<br>
 ready tasks.<br>
<br>
-This algorithm is deterministic (e.g. predictable and fixed) in execution time.<br>
+This algorithm is deterministic (e.g., predictable and fixed) in execution time.<br>
 This comes at the cost of using slightly over three (3) kilobytes of RAM on a<br>
 system configured to support 256 priority levels.<br>
<br>
@@ -167,7 +167,7 @@ determine where to insert the newly readied task.<br>
 This algorithm uses much less RAM than the Deterministic Priority Scheduler but<br>
 is *O(n)* where *n* is the number of ready tasks.  In a small system with a<br>
 small number of tasks, this will not be a performance issue.  Reducing RAM<br>
-consumption is often critical in small systems which are incapable of<br>
+consumption is often critical in small systems that are incapable of<br>
 supporting a large number of tasks.<br>
<br>
 This scheduler is only aware of a single core.<br>
@@ -179,23 +179,23 @@ This scheduler is only aware of a single core.<br>
 Earliest Deadline First Scheduler<br>
 ---------------------------------<br>
<br>
-This is an alternative scheduler in RTEMS for single core applications.  The<br>
+This is an alternative scheduler in RTEMS for single-core applications.  The<br>
 primary EDF advantage is high total CPU utilization (theoretically up to<br>
 100%). It assumes that tasks have priorities equal to deadlines.<br>
<br>
 This EDF is initially preemptive, however, individual tasks may be declared<br>
-not-preemptive. Deadlines are declared using only Rate Monotonic manager which<br>
-goal is to handle periodic behavior. Period is always equal to deadline. All<br>
+not-preemptive. Deadlines are declared using only Rate Monotonic manager whose<br>
+goal is to handle periodic behavior. Period is always equal to the deadline. All<br>
 ready tasks reside in a single ready queue implemented using a red-black tree.<br>
<br>
 This implementation of EDF schedules two different types of task priority types<br>
 while each task may switch between the two types within its execution. If a<br>
 task does have a deadline declared using the Rate Monotonic manager, the task<br>
-is deadline-driven and its priority is equal to deadline.  On the contrary if a<br>
+is deadline-driven and its priority is equal to deadline.  On the contrary, if a<br>
 task does not have any deadline or the deadline is cancelled using the Rate<br>
 Monotonic manager, the task is considered a background task with priority equal<br>
 to that assigned upon initialization in the same manner as for priority<br>
-scheduler. Each background task is of a lower importance than each<br>
+scheduler. Each background task is of lower importance than each<br>
 deadline-driven one and is scheduled when no deadline-driven task and no higher<br>
 priority background task is ready to run.<br>
<br>
@@ -203,7 +203,7 @@ Every deadline-driven scheduling algorithm requires means for tasks to claim a<br>
 deadline.  The Rate Monotonic Manager is responsible for handling periodic<br>
 execution. In RTEMS periods are equal to deadlines, thus if a task announces a<br>
 period, it has to be finished until the end of this period. The call of<br>
-``rtems_rate_monotonic_period`` passes the scheduler the length of oncoming<br>
+``rtems_rate_monotonic_period`` passes the scheduler the length of an oncoming<br>
 deadline. Moreover, the ``rtems_rate_monotonic_cancel`` and<br>
 ``rtems_rate_monotonic_delete`` calls clear the deadlines assigned to the task.<br>
<br>
@@ -214,7 +214,7 @@ deadline. Moreover, the ``rtems_rate_monotonic_cancel`` and<br>
 Constant Bandwidth Server Scheduling (CBS)<br>
 ------------------------------------------<br>
<br>
-This is an alternative scheduler in RTEMS for single core applications.  The<br>
+This is an alternative scheduler in RTEMS for single-core applications.  The<br>
 CBS is a budget aware extension of EDF scheduler. The main goal of this<br>
 scheduler is to ensure temporal isolation of tasks meaning that a task's<br>
 execution in terms of meeting deadlines must not be influenced by other tasks<br>
@@ -258,7 +258,7 @@ active deadline are background tasks.  In case deadlines are not used, then the<br>
 EDF scheduler behaves exactly like a fixed-priority scheduler.  The tasks with<br>
 an active deadline have a higher priority than the background tasks.  This<br>
 scheduler supports :ref:`task processor affinities <rtems_task_set_affinity>`<br>
-of one-to-one and one-to-all, e.g.  a task can execute on exactly one processor<br>
+of one-to-one and one-to-all, e.g.,  a task can execute on exactly one processor<br>
 or all processors managed by the scheduler instance.  The processor affinity<br>
 set of a task must contain all online processors to select the one-to-all<br>
 affinity.  This is to avoid pathological cases if processors are added/removed<br>
@@ -431,7 +431,7 @@ directive.  While a task occupies this state it does not have a TCB or a task<br>
 ID assigned to it; therefore, no other tasks in the system may reference this<br>
 task.<br>
<br>
-When a task is created via the ``rtems_task_create`` directive it enters the<br>
+When a task is created via the ``rtems_task_create`` directive, it enters the<br>
 dormant state.  This state is not entered through any other means.  Although<br>
 the task exists in the system, it cannot actively compete for system resources.<br>
 It will remain in the dormant state until it is started via the<br>
@@ -457,10 +457,10 @@ of the following conditions:<br>
 - The running task issues a ``rtems_barrier_wait`` directive.<br>
<br>
 - The running task issues a ``rtems_message_queue_receive`` directive with the<br>
-  wait option and the message queue is empty.<br>
+  wait option, and the message queue is empty.<br>
<br>
-- The running task issues an ``rtems_event_receive`` directive with the wait<br>
-  option and the currently pending events do not satisfy the request.<br>
+- The running task issues a ``rtems_event_receive`` directive with the wait<br>
+  option, and the currently pending events do not satisfy the request.<br>
<br>
 - The running task issues a ``rtems_semaphore_obtain`` directive with the wait<br>
   option and the requested semaphore is unavailable.<br>
@@ -498,7 +498,7 @@ conditions:<br>
   waiting.<br>
<br>
 - A running task issues an ``rtems_event_send`` directive which sends an event<br>
-  condition to a task which is blocked waiting on that event condition.<br>
+  condition to a task that is blocked waiting on that event condition.<br>
<br>
 - A running task issues a ``rtems_semaphore_release`` directive which releases<br>
   the semaphore on which the blocked task is waiting.<br>
-- <br>
2.17.1<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>