[PATCH 2/2] Spelling/Grammar Mistakes

Sun May 17 21:56:25 UTC 2020

Committed. Thanks for the detailed read and fixes.

--joel

On Fri, May 15, 2020 at 7:10 PM Richi Dubey <richidubey at gmail.com> wrote:

> ---
>  c-user/scheduling_concepts.rst | 50 +++++++++++++++++-----------------
>  1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/c-user/scheduling_concepts.rst
> b/c-user/scheduling_concepts.rst
> index dac39a8..d329bc4 100644
> --- a/c-user/scheduling_concepts.rst
> +++ b/c-user/scheduling_concepts.rst
> @@ -16,7 +16,7 @@ Introduction
>  ============
>
>  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
>  monitor hospital patients must take instant action if a change in the
> patient's
> @@ -38,7 +38,7 @@ The directives provided by the scheduler manager are:
>  - rtems_scheduler_get_maximum_priority_ - Get maximum task priority of a
> scheduler
>
>  - 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
>    prority
> @@ -58,8 +58,8 @@ The directives provided by the scheduler manager are:
>  Scheduling Algorithms
>  ---------------------
>
> -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
>  and configure RTEMS to use it.
> @@ -69,8 +69,8 @@ select the algorithm which is most appropriate to their
> use case. Most
>  real-time operating systems schedule tasks using a priority based
> algorithm,
>  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.
>
> @@ -87,7 +87,7 @@ in time is the one with the highest priority among all
> tasks in the ready
>  state.
>
>  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
>  there are ways to manipulate and adjust task priorities, the most
> important
> @@ -100,7 +100,7 @@ rule to remember is:
>
>  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.
>
>  There are a few common methods of accomplishing the mechanics of this
> @@ -127,7 +127,7 @@ algorithm.  These ways involve a list or chain of
> tasks in the ready state.
>    the ready queue.
>
>  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.
>
>  Uniprocessor Schedulers
> @@ -142,13 +142,13 @@ Deterministic Priority Scheduler
>  --------------------------------
>
>  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
>  priority.  It maintains a bitmap which is used to track which priorities
> have
>  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.
>
> @@ -167,7 +167,7 @@ determine where to insert the newly readied task.
>  This algorithm uses much less RAM than the Deterministic Priority
> Scheduler but
>  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.
>
>  This scheduler is only aware of a single core.
> @@ -179,23 +179,23 @@ This scheduler is only aware of a single core.
>  Earliest Deadline First Scheduler
>  ---------------------------------
>
> -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.
>
>  This implementation of EDF schedules two different types of task priority
> types
>  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.
>
> @@ -203,7 +203,7 @@ Every deadline-driven scheduling algorithm requires
> means for tasks to claim a
>  deadline.  The Rate Monotonic Manager is responsible for handling periodic
>  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.
>
> @@ -214,7 +214,7 @@ deadline. Moreover, the
> ``rtems_rate_monotonic_cancel`` and
>  Constant Bandwidth Server Scheduling (CBS)
>  ------------------------------------------
>
> -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
>  execution in terms of meeting deadlines must not be influenced by other
> tasks
> @@ -258,7 +258,7 @@ active deadline are background tasks.  In case
> deadlines are not used, then the
>  EDF scheduler behaves exactly like a fixed-priority scheduler.  The tasks
> with
>  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
>  affinity.  This is to avoid pathological cases if processors are
> added/removed
> @@ -431,7 +431,7 @@ directive.  While a task occupies this state it does
> not have a TCB or a task
>  ID assigned to it; therefore, no other tasks in the system may reference
> this
>  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.
>  It will remain in the dormant state until it is started via the
> @@ -457,10 +457,10 @@ of the following conditions:
>  - The running task issues a ``rtems_barrier_wait`` directive.
>
>  - The running task issues a ``rtems_message_queue_receive`` directive
> with the
> -  wait option and the message queue is empty.
> +  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.
> +- 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
>    option and the requested semaphore is unavailable.
> @@ -498,7 +498,7 @@ conditions:
>    waiting.
>
>  - 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
>    the semaphore on which the blocked task is waiting.
> --
> 2.17.1
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200517/f719bc9d/attachment-0001.html>