Index: c-user/scheduling_concepts.rst
===================================================================
--- c-user/scheduling_concepts.rst	(revision d4ba908e426f260cbd24c72a0875857cb557b4de)
+++ c-user/scheduling_concepts.rst	(revision a23b1fbaa0e89fafb2febee4350cb820facb5031)
@@ -17,5 +17,5 @@
 
 The concept of scheduling in real-time systems dictates the ability to provide
-immediate response to specific external events, particularly the necessity of
+an immediate response to specific external events, particularly the necessity of
 scheduling tasks to run within a specified time limit after the occurrence of
 an event.  For example, software embedded in life-support systems used to
@@ -39,5 +39,5 @@
 
 - rtems_scheduler_map_priority_to_posix_ - Map task priority to POSIX thread
-  prority
+  priority
 
 - rtems_scheduler_map_priority_from_posix_ - Map POSIX thread priority to task
@@ -59,6 +59,6 @@
 ---------------------
 
-RTEMS provides a plugin framework which allows it to support multiple
-scheduling algorithms. RTEMS includes multiple scheduling algorithms and the
+RTEMS provides a plugin framework that allows it to support multiple
+scheduling algorithms. RTEMS includes multiple scheduling algorithms, and the
 user can select which of these they wish to use in their application at
 link-time.  In addition, the user can implement their own scheduling algorithm
@@ -70,6 +70,6 @@
 possibly with preemption control.  The classic RTEMS scheduling algorithm which
 was the only algorithm available in RTEMS 4.10 and earlier, is a fixed-priority
-scheduling algorithm.  This scheduling algoritm is suitable for uniprocessor
-(e.g. non-SMP) systems and is known as the *Deterministic Priority
+scheduling algorithm.  This scheduling algorithm is suitable for uniprocessor
+(e.g., non-SMP) systems and is known as the *Deterministic Priority
 Scheduler*.  Unless the user configures another scheduling algorithm, RTEMS
 will use this on uniprocessor systems.
@@ -88,5 +88,5 @@
 
 When a task is added to the ready chain, it is placed behind all other tasks of
-the same priority.  This rule provides a round-robin within priority group
+the same priority.  This rule provides a round-robin within a priority group
 scheduling characteristic.  This means that in a group of equal priority tasks,
 tasks will execute in the order they become ready or FIFO order.  Even though
@@ -101,5 +101,5 @@
 Priority scheduling is the most commonly used scheduling algorithm.  It should
 be used by applications in which multiple tasks contend for CPU time or other
-resources and there is a need to ensure certain tasks are given priority over
+resources, and there is a need to ensure certain tasks are given priority over
 other tasks.
 
@@ -128,5 +128,5 @@
 
 RTEMS currently includes multiple priority based scheduling algorithms as well
-as other algorithms which incorporate deadline.  Each algorithm is discussed in
+as other algorithms that incorporate deadline.  Each algorithm is discussed in
 the following sections.
 
@@ -143,5 +143,5 @@
 
 This is the scheduler implementation which has always been in RTEMS.  After the
-4.10 release series, it was factored into pluggable scheduler selection.  It
+4.10 release series, it was factored into a pluggable scheduler selection.  It
 schedules tasks using a priority based algorithm which takes into account
 preemption.  It is implemented using an array of FIFOs with a FIFO per
@@ -149,5 +149,5 @@
 ready tasks.
 
-This algorithm is deterministic (e.g. predictable and fixed) in execution time.
+This algorithm is deterministic (e.g., predictable and fixed) in execution time.
 This comes at the cost of using slightly over three (3) kilobytes of RAM on a
 system configured to support 256 priority levels.
@@ -168,5 +168,5 @@
 is *O(n)* where *n* is the number of ready tasks.  In a small system with a
 small number of tasks, this will not be a performance issue.  Reducing RAM
-consumption is often critical in small systems which are incapable of
+consumption is often critical in small systems that are incapable of
 supporting a large number of tasks.
 
@@ -180,11 +180,11 @@
 ---------------------------------
 
-This is an alternative scheduler in RTEMS for single core applications.  The
+This is an alternative scheduler in RTEMS for single-core applications.  The
 primary EDF advantage is high total CPU utilization (theoretically up to
 100%). It assumes that tasks have priorities equal to deadlines.
 
 This EDF is initially preemptive, however, individual tasks may be declared
-not-preemptive. Deadlines are declared using only Rate Monotonic manager which
-goal is to handle periodic behavior. Period is always equal to deadline. All
+not-preemptive. Deadlines are declared using only Rate Monotonic manager whose
+goal is to handle periodic behavior. Period is always equal to the deadline. All
 ready tasks reside in a single ready queue implemented using a red-black tree.
 
@@ -192,9 +192,9 @@
 while each task may switch between the two types within its execution. If a
 task does have a deadline declared using the Rate Monotonic manager, the task
-is deadline-driven and its priority is equal to deadline.  On the contrary if a
+is deadline-driven and its priority is equal to deadline.  On the contrary, if a
 task does not have any deadline or the deadline is cancelled using the Rate
 Monotonic manager, the task is considered a background task with priority equal
 to that assigned upon initialization in the same manner as for priority
-scheduler. Each background task is of a lower importance than each
+scheduler. Each background task is of lower importance than each
 deadline-driven one and is scheduled when no deadline-driven task and no higher
 priority background task is ready to run.
@@ -204,5 +204,5 @@
 execution. In RTEMS periods are equal to deadlines, thus if a task announces a
 period, it has to be finished until the end of this period. The call of
-``rtems_rate_monotonic_period`` passes the scheduler the length of oncoming
+``rtems_rate_monotonic_period`` passes the scheduler the length of an oncoming
 deadline. Moreover, the ``rtems_rate_monotonic_cancel`` and
 ``rtems_rate_monotonic_delete`` calls clear the deadlines assigned to the task.
@@ -215,5 +215,5 @@
 ------------------------------------------
 
-This is an alternative scheduler in RTEMS for single core applications.  The
+This is an alternative scheduler in RTEMS for single-core applications.  The
 CBS is a budget aware extension of EDF scheduler. The main goal of this
 scheduler is to ensure temporal isolation of tasks meaning that a task's
@@ -259,5 +259,5 @@
 an active deadline have a higher priority than the background tasks.  This
 scheduler supports :ref:`task processor affinities <rtems_task_set_affinity>`
-of one-to-one and one-to-all, e.g.  a task can execute on exactly one processor
+of one-to-one and one-to-all, e.g.,  a task can execute on exactly one processor
 or all processors managed by the scheduler instance.  The processor affinity
 set of a task must contain all online processors to select the one-to-all
@@ -432,5 +432,5 @@
 task.
 
-When a task is created via the ``rtems_task_create`` directive it enters the
+When a task is created via the ``rtems_task_create`` directive, it enters the
 dormant state.  This state is not entered through any other means.  Although
 the task exists in the system, it cannot actively compete for system resources.
@@ -458,8 +458,8 @@
 
 - The running task issues a ``rtems_message_queue_receive`` directive with the
-  wait option and the message queue is empty.
-
-- The running task issues an ``rtems_event_receive`` directive with the wait
-  option and the currently pending events do not satisfy the request.
+  wait option, and the message queue is empty.
+
+- The running task issues a ``rtems_event_receive`` directive with the wait
+  option, and the currently pending events do not satisfy the request.
 
 - The running task issues a ``rtems_semaphore_obtain`` directive with the wait
@@ -499,5 +499,5 @@
 
 - A running task issues an ``rtems_event_send`` directive which sends an event
-  condition to a task which is blocked waiting on that event condition.
+  condition to a task that is blocked waiting on that event condition.
 
 - A running task issues a ``rtems_semaphore_release`` directive which releases
