mirror of
https://git.rtems.org/rtems-docs/
synced 2025-07-24 04:34:25 +08:00
Spelling/Grammar Mistakes
This commit is contained in:
parent
d4ba908e42
commit
a23b1fbaa0
@ -16,7 +16,7 @@ Introduction
|
|||||||
============
|
============
|
||||||
|
|
||||||
The concept of scheduling in real-time systems dictates the ability to provide
|
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
|
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
|
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
|
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_get_maximum_priority_ - Get maximum task priority of a scheduler
|
||||||
|
|
||||||
- rtems_scheduler_map_priority_to_posix_ - Map task priority to POSIX thread
|
- 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
|
- rtems_scheduler_map_priority_from_posix_ - Map POSIX thread priority to task
|
||||||
prority
|
prority
|
||||||
@ -58,8 +58,8 @@ The directives provided by the scheduler manager are:
|
|||||||
Scheduling Algorithms
|
Scheduling Algorithms
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
RTEMS provides a plugin framework which allows it to support multiple
|
RTEMS provides a plugin framework that allows it to support multiple
|
||||||
scheduling algorithms. RTEMS includes multiple scheduling algorithms and the
|
scheduling algorithms. RTEMS includes multiple scheduling algorithms, and the
|
||||||
user can select which of these they wish to use in their application at
|
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
|
link-time. In addition, the user can implement their own scheduling algorithm
|
||||||
and configure RTEMS to use it.
|
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,
|
real-time operating systems schedule tasks using a priority based algorithm,
|
||||||
possibly with preemption control. The classic RTEMS scheduling algorithm which
|
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
|
was the only algorithm available in RTEMS 4.10 and earlier, is a fixed-priority
|
||||||
scheduling algorithm. This scheduling algoritm is suitable for uniprocessor
|
scheduling algorithm. This scheduling algorithm is suitable for uniprocessor
|
||||||
(e.g. non-SMP) systems and is known as the *Deterministic Priority
|
(e.g., non-SMP) systems and is known as the *Deterministic Priority
|
||||||
Scheduler*. Unless the user configures another scheduling algorithm, RTEMS
|
Scheduler*. Unless the user configures another scheduling algorithm, RTEMS
|
||||||
will use this on uniprocessor systems.
|
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.
|
state.
|
||||||
|
|
||||||
When a task is added to the ready chain, it is placed behind all other tasks of
|
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,
|
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
|
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
|
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
|
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
|
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.
|
other tasks.
|
||||||
|
|
||||||
There are a few common methods of accomplishing the mechanics of this
|
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.
|
the ready queue.
|
||||||
|
|
||||||
RTEMS currently includes multiple priority based scheduling algorithms as well
|
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.
|
the following sections.
|
||||||
|
|
||||||
Uniprocessor Schedulers
|
Uniprocessor Schedulers
|
||||||
@ -142,13 +142,13 @@ Deterministic Priority Scheduler
|
|||||||
--------------------------------
|
--------------------------------
|
||||||
|
|
||||||
This is the scheduler implementation which has always been in RTEMS. After the
|
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
|
schedules tasks using a priority based algorithm which takes into account
|
||||||
preemption. It is implemented using an array of FIFOs with a FIFO per
|
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
|
priority. It maintains a bitmap which is used to track which priorities have
|
||||||
ready tasks.
|
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
|
This comes at the cost of using slightly over three (3) kilobytes of RAM on a
|
||||||
system configured to support 256 priority levels.
|
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
|
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
|
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
|
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.
|
supporting a large number of tasks.
|
||||||
|
|
||||||
This scheduler is only aware of a single core.
|
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
|
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
|
primary EDF advantage is high total CPU utilization (theoretically up to
|
||||||
100%). It assumes that tasks have priorities equal to deadlines.
|
100%). It assumes that tasks have priorities equal to deadlines.
|
||||||
|
|
||||||
This EDF is initially preemptive, however, individual tasks may be declared
|
This EDF is initially preemptive, however, individual tasks may be declared
|
||||||
not-preemptive. Deadlines are declared using only Rate Monotonic manager which
|
not-preemptive. Deadlines are declared using only Rate Monotonic manager whose
|
||||||
goal is to handle periodic behavior. Period is always equal to deadline. All
|
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.
|
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
|
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
|
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
|
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
|
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
|
Monotonic manager, the task is considered a background task with priority equal
|
||||||
to that assigned upon initialization in the same manner as for priority
|
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
|
deadline-driven one and is scheduled when no deadline-driven task and no higher
|
||||||
priority background task is ready to run.
|
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
|
deadline. The Rate Monotonic Manager is responsible for handling periodic
|
||||||
execution. In RTEMS periods are equal to deadlines, thus if a task announces a
|
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
|
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
|
deadline. Moreover, the ``rtems_rate_monotonic_cancel`` and
|
||||||
``rtems_rate_monotonic_delete`` calls clear the deadlines assigned to the task.
|
``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)
|
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
|
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
|
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
|
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
|
EDF scheduler behaves exactly like a fixed-priority scheduler. The tasks with
|
||||||
an active deadline have a higher priority than the background tasks. This
|
an active deadline have a higher priority than the background tasks. This
|
||||||
scheduler supports :ref:`task processor affinities <rtems_task_set_affinity>`
|
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
|
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
|
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
|
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
|
ID assigned to it; therefore, no other tasks in the system may reference this
|
||||||
task.
|
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
|
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.
|
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
|
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_barrier_wait`` directive.
|
||||||
|
|
||||||
- The running task issues a ``rtems_message_queue_receive`` directive with the
|
- 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
|
- The running task issues a ``rtems_event_receive`` directive with the wait
|
||||||
option and the currently pending events do not satisfy the request.
|
option, and the currently pending events do not satisfy the request.
|
||||||
|
|
||||||
- The running task issues a ``rtems_semaphore_obtain`` directive with the wait
|
- The running task issues a ``rtems_semaphore_obtain`` directive with the wait
|
||||||
option and the requested semaphore is unavailable.
|
option and the requested semaphore is unavailable.
|
||||||
@ -498,7 +498,7 @@ conditions:
|
|||||||
waiting.
|
waiting.
|
||||||
|
|
||||||
- A running task issues an ``rtems_event_send`` directive which sends an event
|
- 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
|
- A running task issues a ``rtems_semaphore_release`` directive which releases
|
||||||
the semaphore on which the blocked task is waiting.
|
the semaphore on which the blocked task is waiting.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user