<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>change log for rtems (2011-10-05)</title>
</head>
<body text='#000000' bgcolor='#ffffff'>
<a name='cs1'></a>
<table border='0' cellspacing='0' cellpadding='5' width='100%' bgcolor='#eeeeee'>
<tr><td colspan='3' bgcolor='#dddddd'>
<font color='#bb2222'><strong>joel</strong></font>
</td></tr>
<tr><td colspan='3' bgcolor='#dddddd'><pre>2011-10-05 Joel Sherrill <joel.sherrill@oarcorp.com>
Petr Benes <benesp16@fel.cvut.cz>
PR 1912/doc
* user/conf.t, user/schedule.t: Rework to add scheduler specific
information.
</pre></td></tr>
<tr><td width='1%'><a href="http://www.rtems.com/cgi-bin/viewcvs.cgi//rtems/doc/ChangeLog.diff?r1=text&tr1=1.318&r2=text&tr2=1.319&diff_format=h">M</a></td><td width='1%'>1.319</td><td width='100%'>doc/ChangeLog</td></tr>
<tr><td width='1%'><a href="http://www.rtems.com/cgi-bin/viewcvs.cgi//rtems/doc/user/conf.t.diff?r1=text&tr1=1.73&r2=text&tr2=1.74&diff_format=h">M</a></td><td width='1%'>1.74</td><td width='100%'>doc/user/conf.t</td></tr>
<tr><td width='1%'><a href="http://www.rtems.com/cgi-bin/viewcvs.cgi//rtems/doc/user/schedule.t.diff?r1=text&tr1=1.15&r2=text&tr2=1.16&diff_format=h">M</a></td><td width='1%'>1.16</td><td width='100%'>doc/user/schedule.t</td></tr>
</table>
<pre>
<font color='#006600'>diff -u rtems/doc/ChangeLog:1.318 rtems/doc/ChangeLog:1.319
--- rtems/doc/ChangeLog:1.318 Mon Sep 19 20:06:47 2011
+++ rtems/doc/ChangeLog Wed Oct 5 14:59:47 2011
</font><font color='#997700'>@@ -1,3 +1,10 @@
</font><font color='#000088'>+2011-10-05 Joel Sherrill <joel.sherrill@oarcorp.com>
+ Petr Benes <benesp16@fel.cvut.cz>
+
+ PR 1912/doc
+ * user/conf.t, user/schedule.t: Rework to add scheduler specific
+ information.
+
</font> 2011-09-19 Joel Sherrill <joel.sherrill@oarcorp.com>
* user/Makefile.am, user/c_user.texi: Reorder chapters to put
<font color='#006600'>diff -u rtems/doc/user/conf.t:1.73 rtems/doc/user/conf.t:1.74
--- rtems/doc/user/conf.t:1.73 Fri Jul 29 14:50:22 2011
+++ rtems/doc/user/conf.t Wed Oct 5 14:59:47 2011
</font><font color='#997700'>@@ -436,13 +436,33 @@
</font> configuration with SMP enabled at configure time, it may be explicitly
selected by defining @code{CONFIGURE_SCHEDULER_SIMPLE_SMP}.
<font color='#000088'>+@findex CONFIGURE_SCHEDULER_EDF
+@item Earliest Deadline First Scheduler (EDF) - This is an alternative
+scheduler in RTEMS for single core applications. The EDF schedules tasks
+with dynamic priorities equal to deadlines. The deadlines are
+declared using only Rate Monotonic manager which handles periodic behavior.
+Period is always equal to deadline. If a task does not have any deadline
+declared or the deadline is cancelled, the task is considered a background
+task which is scheduled in case no deadline-driven tasks are ready to run.
+Moreover, multiple background tasks are scheduled according their priority
+assigned upon initialization. All ready tasks reside in a single ready queue.
+This scheduler may be explicitly selected by defining
+@code{CONFIGURE_SCHEDULER_EDF}.
+
+@findex CONFIGURE_SCHEDULER_CBS
+@item Constant Bandwidth Server Scheduler (CBS) - This is an alternative
+scheduler in RTEMS for single core applications. The CBS is a budget aware
+extention of EDF scheduler. The goal of this scheduler is to ensure temporal
+isolation of tasks. The CBS is equipped with a set of additional rules and
+provides with an extensive API. This scheduler may be explicitly selected
+by defining @code{CONFIGURE_SCHEDULER_CBS}.
+
</font> @end itemize
The pluggable scheduler interface was added after the 4.10 release series
so there are not a lot of options at this point. We anticipate a lower
<font color='#880000'>-memory, non-deterministic priority scheduler suitable for use in small
-systems and an Earliest Deadline First Scheduler (EDF) to arrive in
-the future.
</font><font color='#000088'>+memory and a non-deterministic priority scheduler suitable for use in small
+systems to arrive in the future.
</font>
The pluggable scheduler interface enables the user to provide their own scheduling algorithm. If you choose to do this, you must define multiple configuration macros.<span style="background-color: #FF0000"> </span>
<font color='#006600'>diff -u rtems/doc/user/schedule.t:1.15 rtems/doc/user/schedule.t:1.16
--- rtems/doc/user/schedule.t:1.15 Wed Nov 24 09:52:21 2010
+++ rtems/doc/user/schedule.t Wed Oct 5 14:59:47 2011
</font><font color='#997700'>@@ -1,16 +1,11 @@
</font> @c
<font color='#880000'>-@c COPYRIGHT (c) 1988-2002.
</font><font color='#000088'>+@c COPYRIGHT (c) 1988-2011.
</font> @c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
<font color='#880000'>-@c
-@c This figure is not included:
-@c Figure 17-1 RTEMS Task State Transitions
-@c
-
</font> @chapter Scheduling Concepts
@cindex scheduling
<font color='#997700'>@@ -18,72 +13,206 @@
</font>
@section Introduction
<font color='#880000'>-The concept of scheduling in real-time systems
-dictates the ability to provide 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 status is detected.
-
-The component of RTEMS responsible for providing this
-capability is appropriately called the scheduler. The
-scheduler's sole purpose is to allocate the all important
-resource of processor time to the various tasks competing for
-attention.<span style="background-color: #FF0000"> </span>
</font><font color='#000088'>+The concept of scheduling in real-time systems dictates the ability to
+provide 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 status is detected.
+
+The component of RTEMS responsible for providing this capability is
+appropriately called the scheduler. The scheduler's sole purpose is
+to allocate the all important resource of processor time to the various
+tasks competing for attention.
</font>
@section Scheduling Algorithms
@cindex scheduling algorithms
<font color='#880000'>-RTEMS provides multiple possible scheduling algorithms, each<span style="background-color: #FF0000"> </span>
-of which are appropriate to different use case scenarios.<span style="background-color: #FF0000"> </span>
-The classic RTEMS scheduling algorithm -- the only<span style="background-color: #FF0000"> </span>
-algorithm available in RTEMS 4.10 and earlier -- is the priority
-scheduling algorithm. When not specified, the priority scheduling
-algorithm can be assumed.
-
-RTEMS currently supports the following scheduling algorithms:
-
-@itemize @bullet
-@item Priority scheduling
-@end itemize
</font><font color='#000088'>+RTEMS provides a plugin framework which allows it to support
+multiple scheduling algorithms. RTEMS now includes multiple
+scheduling algorithms in the SuperCore and the user can select which
+of these they wish to use in their application. In addition,<span style="background-color: #FF0000"> </span>
+the user can implement their own scheduling algorithm and
+configure RTEMS to use it.<span style="background-color: #FF0000"> </span>
+
+Supporting multiple scheduling algorithms gives the end user the
+option to 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 priority based scheduling algorithm.
+This scheduling algoritm is suitable for single core (e.g. non-SMP)
+systems and is now known as the @b{Deterministic Priority Scheduler}.
+Unless the user configures another scheduling algorithm, RTEMS will use
+this on single core systems.
</font>
@subsection Priority Scheduling
@cindex priority scheduling
<font color='#880000'>-The RTEMS scheduler allocates the processor using a
-priority-based, preemptive algorithm augmented to provide
-round-robin characteristics within individual priority groups.
-The goal of this algorithm is to guarantee that the task which
-is executing on the processor at any point in time is the one
-with the highest priority among all tasks in the ready state.
-
-There are two common methods of accomplishing the
-mechanics of this algorithm. Both ways involve a list or chain
-of tasks in the ready state. One method is to randomly place
-tasks in the ready chain forcing the scheduler to scan the
-entire chain to determine which task receives the processor.
-The other method is to schedule the task by placing it in the
-proper place on the ready chain based on the designated
-scheduling criteria at the time it enters the ready state.
-Thus, when the processor is free, the first task on the ready
-chain is allocated the processor. RTEMS schedules tasks using
-the second method to guarantee faster response times to external
-events.
</font><font color='#000088'>+When using priority based scheduling, RTEMS allocates the processor using
+a priority-based, preemptive algorithm augmented to provide round-robin
+characteristics within individual priority groups. The goal of this
+algorithm is to guarantee that the task which is executing on the
+processor at any point 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 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 rule to remember is:
+
+@itemize @code{ }
+@item @b{Priority based scheduling algorithms will always select the
+highest priority task that is ready to run when allocating the processor
+to a task.}
+@end itemize
</font>
Priority scheduling is the most commonly used scheduling algorithm.
It should be used by applications in which multiple tasks contend for<span style="background-color: #FF0000"> </span>
CPU time or other resources and there is a need to ensure certain tasks
are given priority over other tasks.
<font color='#880000'>-@section Scheduling Mechanisms
</font><font color='#000088'>+There are a few common methods of accomplishing the mechanics of this
+algorithm. These ways involve a list or chain of tasks in the ready state.
+
+@itemize @bullet
+@item The least efficient method is to randomly place tasks in the ready
+chain forcing the scheduler to scan the entire chain to determine which
+task receives the processor.
+
+@item A more efficient method is to schedule the task by placing it
+in the proper place on the ready chain based on the designated scheduling
+criteria at the time it enters the ready state. Thus, when the processor
+is free, the first task on the ready chain is allocated the processor.
+
+@item Another mechanism is to maintain a list of FIFOs per priority.
+When a task is readied, it is placed on the rear of the FIFO for its
+priority. This method is often used with a bitmap to assist in locating
+which FIFOs have ready tasks on them.
+
+@end itemize
+RTEMS currently includes multiple priority based scheduling algorithms
+as well as other algorithms which incorporate deadline. Each algorithm
+is discussed in the following sections.
+<span style="background-color: #FF0000"> </span>
+@subsection 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 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 comes at the cost of using slightly over three (3) kilobytes
+of RAM on a system configured to support 256 priority levels.
+
+This scheduler is only aware of a single core.
+
+@subsection Simple Priority Scheduler
+
+This scheduler implementation has the same behaviour as the Deterministic
+Priority Scheduler but uses only one linked list to manage all ready
+tasks. When a task is readied, a linear search of that linked list is
+performed to determine where to insert the newly readied task.
+
+This algorithm uses much less RAM than the Deterministic Priority
+Scheduler but is @i{O(n)} where @i{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 supporting a large number of tasks.
+
+This scheduler is only aware of a single core.
+
+@subsection Simple SMP Priority Scheduler
+
+This scheduler is based upon the Simple Priority Scheduler and is designed
+to have the same behaviour on a single core system. But this scheduler
+is capable of scheduling threads across multiple cores in an SMP system.
+When given a choice of replacing one of two threads at equal priority
+on different cores, this algorithm favors replacing threads which are
+preemptible and have executed the longest.
+
+This algorithm is non-deterministic. When scheduling, it must consider
+which tasks are to be executed on each core while avoiding superfluous
+task migrations.
+
+@subsection Earliest Deadline First Scheduler
+
+@cindex earliest deadline first scheduling
+
+This is an alternative scheduler in RTEMS for single core applications.<span style="background-color: #FF0000"> </span>
+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
+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 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 deadline-driven one
+and is scheduled when no deadline-driven task and no higher priority
+background task is ready to run.
+
+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 @code{rtems_rate_monotonic_period}
+passes the scheduler the length of oncoming deadline. Moreover, the
+@code{rtems_rate_monotonic_cancel} and @code{rtems_rate_monotonic_delete}
+calls clear the deadlines assigned to the task.
+
+@subsection Constant Bandwidth Server Scheduling (CBS)
+
+@cindex constant bandwidth server scheduling
+
+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 as if they were run on multiple independent processors.
+
+Each task can be assigned a server (current implementation supports only
+one task per server). The server is characterized by period (deadline)
+and computation time (budget). The ratio budget/period yields bandwidth,
+which is the fraction of CPU to be reserved by the scheduler for each
+subsequent period.
+
+The CBS is equipped with a set of rules applied to tasks attached to servers
+ensuring that deadline miss because of another task cannot occur.
+In case a task breaks one of the rules, its priority is pulled to background
+until the end of its period and then restored again. The rules are:
+
+@itemize @bullet
+@item Task cannot exceed its registered budget, @item Task cannot be
+unblocked when a ratio between remaining budget and remaining deadline
+is higher than declared bandwidth.
+@end itemize
+
+The CBS provides an extensive API. Unlike EDF, the
+@code{rtems_rate_monotonic_period} does not declare a deadline because
+it is carried out using CBS API. This call only announces next period.
+
+@section Scheduling Modification Mechanisms
</font>
@cindex scheduling mechanisms
<font color='#880000'>-RTEMS provides four mechanisms which allow the user
-to impact the task scheduling process:
</font><font color='#000088'>+RTEMS provides four mechanisms which allow the user to alter the task
+scheduling decisions:
</font>
@itemize @bullet
@item user-selectable task priority level
<font color='#997700'>@@ -92,115 +221,71 @@
</font> @item manual round-robin selection
@end itemize
<font color='#880000'>-Each of these methods provides a powerful capability
-to customize sets of tasks to satisfy the unique and particular
-requirements encountered in custom real-time applications.
-Although each mechanism operates independently, there is a
-precedence relationship which governs the effects of scheduling
-modifications. The evaluation order for scheduling
-characteristics is always priority, preemption mode, and
-timeslicing. When reading the descriptions of timeslicing and
-manual round-robin it is important to keep in mind that
-preemption (if enabled) of a task by higher priority tasks will
-occur as required, overriding the other factors presented in the
-description.
</font><font color='#000088'>+Each of these methods provides a powerful capability to customize sets
+of tasks to satisfy the unique and particular requirements encountered
+in custom real-time applications. Although each mechanism operates
+independently, there is a precedence relationship which governs the
+effects of scheduling modifications. The evaluation order for scheduling
+characteristics is always priority, preemption mode, and timeslicing.
+When reading the descriptions of timeslicing and manual round-robin
+it is important to keep in mind that preemption (if enabled) of a task
+by higher priority tasks will occur as required, overriding the other
+factors presented in the description.
</font>
@subsection Task Priority and Scheduling
@cindex task priority
<font color='#880000'>-This mechanism affects the following scheduling algorithms:
-@itemize @bullet
-@item Priority scheduling
-@end itemize
-
-The most significant of these mechanisms is the
-ability for the user to assign a priority level to each
-individual task when it is created and to alter a task's
-priority at run-time. RTEMS provides 255 priority levels.
-Level 255 is the lowest priority and level 1 is the highest.
-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 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 rule to remember is:
-
-@itemize @code{ }
-@item @b{The RTEMS scheduler will always select the highest
-priority task that is ready to run when allocating the processor
-to a task.}
-@end itemize
</font><font color='#000088'>+The most significant task scheduling modification mechanism is the ability
+for the user to assign a priority level to each individual task when it
+is created and to alter a task's priority at run-time. RTEMS supports
+up to 255 priority levels. Level 255 is the lowest priority and level
+1 is the highest.
</font>
@subsection Preemption
<font color='#880000'>-
</font> @cindex preemption
<font color='#880000'>-This mechanism affects the following scheduling algorithms:
-@itemize @bullet
-@item Priority scheduling
-@end itemize
-
-Another way the user can alter the basic scheduling
-algorithm is by manipulating the preemption mode flag
-(@code{@value{RPREFIX}PREEMPT_MASK}) of individual tasks. If preemption is disabled
-for a task (@code{@value{RPREFIX}NO_PREEMPT}), then the task will not relinquish
-control of the processor until it terminates, blocks, or
-re-enables preemption. Even tasks which become ready to run and
-possess higher priority levels will not be allowed to execute.
-Note that the preemption setting has no effect on the manner in
-which a task is scheduled. It only applies once a task has
-control of the processor.
</font><font color='#000088'>+Another way the user can alter the basic scheduling algorithm is by
+manipulating the preemption mode flag (@code{@value{RPREFIX}PREEMPT_MASK})
+of individual tasks. If preemption is disabled for a task
+(@code{@value{RPREFIX}NO_PREEMPT}), then the task will not relinquish
+control of the processor until it terminates, blocks, or re-enables
+preemption. Even tasks which become ready to run and possess higher
+priority levels will not be allowed to execute. Note that the preemption
+setting has no effect on the manner in which a task is scheduled.
+It only applies once a task has control of the processor.
</font>
@subsection Timeslicing
<font color='#880000'>-
</font> @cindex timeslicing
@cindex round robin scheduling
<font color='#880000'>-This mechanism affects the following scheduling algorithms:
-@itemize @bullet
-@item Priority scheduling
-@end itemize
-
-Timeslicing or round-robin scheduling is an
-additional method which can be used to alter the basic
-scheduling algorithm. Like preemption, timeslicing is specified
-on a task by task basis using the timeslicing mode flag
-(@code{@value{RPREFIX}TIMESLICE_MASK}). If timeslicing is enabled for a task
-(@code{@value{RPREFIX}TIMESLICE}), then RTEMS will limit the amount of time the task
-can execute before the processor is allocated to another task.
-Each tick of the real-time clock reduces the currently running
-task's timeslice. When the execution time equals the timeslice,
-RTEMS will dispatch another task of the same priority to
-execute. If there are no other tasks of the same priority ready
-to execute, then the current task is allocated an additional
-timeslice and continues to run. Remember that a higher priority
-task will preempt the task (unless preemption is disabled) as
-soon as it is ready to run, even if the task has not used up its
-entire timeslice.
</font><font color='#000088'>+Timeslicing or round-robin scheduling is an additional method which
+can be used to alter the basic scheduling algorithm. Like preemption,
+timeslicing is specified on a task by task basis using the timeslicing
+mode flag (@code{@value{RPREFIX}TIMESLICE_MASK}). If timeslicing is
+enabled for a task (@code{@value{RPREFIX}TIMESLICE}), then RTEMS will
+limit the amount of time the task can execute before the processor is
+allocated to another task. Each tick of the real-time clock reduces
+the currently running task's timeslice. When the execution time equals
+the timeslice, RTEMS will dispatch another task of the same priority
+to execute. If there are no other tasks of the same priority ready to
+execute, then the current task is allocated an additional timeslice and
+continues to run. Remember that a higher priority task will preempt
+the task (unless preemption is disabled) as soon as it is ready to run,
+even if the task has not used up its entire timeslice.
</font>
@subsection Manual Round-Robin
<font color='#880000'>-
</font> @cindex manual round robin
<font color='#880000'>-This mechanism affects the following scheduling algorithms:
-@itemize @bullet
-@item Priority scheduling
-@end itemize
-
-The final mechanism for altering the RTEMS scheduling
-algorithm is called manual round-robin. Manual round-robin is
-invoked by using the @code{@value{DIRPREFIX}task_wake_after}
-directive with a time interval of @code{@value{RPREFIX}YIELD_PROCESSOR}.<span style="background-color: #FF0000"> </span>
-This allows a task to give up the
-processor and be immediately returned to the ready chain at the
-end of its priority group. If no other tasks of the same
-priority are ready to run, then the task does not lose control
-of the processor.
</font><font color='#000088'>+The final mechanism for altering the RTEMS scheduling algorithm is
+called manual round-robin. Manual round-robin is invoked by using the
+@code{@value{DIRPREFIX}task_wake_after} directive with a time interval
+of @code{@value{RPREFIX}YIELD_PROCESSOR}. This allows a task to give
+up the processor and be immediately returned to the ready chain at the
+end of its priority group. If no other tasks of the same priority are
+ready to run, then the task does not lose control of the processor.
</font>
@section Dispatching Tasks
<font color='#880000'>-
</font> @cindex dispatching
The dispatcher is the RTEMS component responsible for
<font color='#997700'>@@ -219,41 +304,38 @@
</font> saved or restored for a context switch is located either in the
TCB or on the task's stacks.
<font color='#880000'>-Tasks that utilize a numeric coprocessor and are
-created with the @code{@value{RPREFIX}FLOATING_POINT} attribute
-require additional operations during a context switch. These
-additional operations
</font><font color='#000088'>+Tasks that utilize a numeric coprocessor and are created with the
+@code{@value{RPREFIX}FLOATING_POINT} attribute require additional
+operations during a context switch. These additional operations
</font> are necessary to save and restore the floating point context of
<font color='#880000'>-@code{@value{RPREFIX}FLOATING_POINT} tasks. To avoid unnecessary save and restore
-operations, the state of the numeric coprocessor is only saved
-when a @code{@value{RPREFIX}FLOATING_POINT} task is dispatched and that task was not
-the last task to utilize the coprocessor.
</font><font color='#000088'>+@code{@value{RPREFIX}FLOATING_POINT} tasks. To avoid unnecessary save
+and restore operations, the state of the numeric coprocessor is only
+saved when a @code{@value{RPREFIX}FLOATING_POINT} task is dispatched
+and that task was not the last task to utilize the coprocessor.
</font>
@section Task State Transitions
<font color='#880000'>-
</font> @cindex task state transitions
Tasks in an RTEMS system must always be in one of the
five allowable task states. These states are: executing, ready,
blocked, dormant, and non-existent.
<font color='#880000'>-A task occupies the non-existent state before a
-@code{@value{DIRPREFIX}task_create} has been
-issued on its behalf. A task enters the
-non-existent state from any other state in the system when it is
-deleted with the @code{@value{DIRPREFIX}task_delete}
-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 @code{@value{DIRPREFIX}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 @code{@value{DIRPREFIX}task_start}
-directive, at which time it enters the ready state. The task is
-now permitted to be scheduled for the processor and to compete
-for other system resources.
</font><font color='#000088'>+A task occupies the non-existent state before
+a @code{@value{DIRPREFIX}task_create} has been issued on its behalf.
+A task enters the non-existent state from any other state in the system
+when it is deleted with the @code{@value{DIRPREFIX}task_delete} 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 @code{@value{DIRPREFIX}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 @code{@value{DIRPREFIX}task_start}
+directive, at which time it enters the ready state. The task is now
+permitted to be scheduled for the processor and to compete for other
+system resources.
</font>
@float Figure,fig:RTEMS-Task-States
@caption{RTEMS Task States}
<font color='#997700'>@@ -305,18 +387,20 @@
</font> @end ifset
@end float
<font color='#880000'>-A task occupies the blocked state whenever it is
-unable to be scheduled to run. A running task may block itself
-or be blocked by other tasks in the system. The running task
-blocks itself through voluntary operations that cause the task
-to wait. The only way a task can block a task other than itself
-is with the @code{@value{DIRPREFIX}task_suspend} directive.<span style="background-color: #FF0000"> </span>
</font><font color='#000088'>+A task occupies the blocked state whenever it is unable to be scheduled
+to run. A running task may block itself or be blocked by other tasks in
+the system. The running task blocks itself through voluntary operations
+that cause the task to wait. The only way a task can block a task other
+than itself is with the @code{@value{DIRPREFIX}task_suspend} directive.
</font> A task enters the blocked state due to any of the following conditions:
@itemize @bullet
@item A task issues a @code{@value{DIRPREFIX}task_suspend} directive
which blocks either itself or another task in the system.
<font color='#000088'>+@item The running task issues a @code{@value{DIRPREFIX}barrier_wait}
+directive.
+
</font> @item The running task issues a @code{@value{DIRPREFIX}message_queue_receive}
directive with the wait option and the message queue is empty.
<font color='#997700'>@@ -329,31 +413,31 @@
</font>
@item The running task issues a @code{@value{DIRPREFIX}task_wake_after}
directive which blocks the task for the given time interval. If the time
<font color='#880000'>-interval specified is zero, the task yields the processor and
-remains in the ready state.
</font><font color='#000088'>+interval specified is zero, the task yields the processor and remains
+in the ready state.
</font>
@item The running task issues a @code{@value{DIRPREFIX}task_wake_when}
directive which blocks the task until the requested date and time arrives.
<font color='#000088'>+@item The running task issues a @code{@value{DIRPREFIX}rate_monotonic_period}
+directive and must wait for the specified rate monotonic period
+to conclude.
+
</font> @item The running task issues a @code{@value{DIRPREFIX}region_get_segment}
directive with the wait option and there is not an available segment large
enough to satisfy the task's request.
<font color='#880000'>-@item The running task issues a @code{@value{DIRPREFIX}rate_monotonic_period}
-directive and must wait for the specified rate monotonic period
-to conclude.
</font> @end itemize
<font color='#880000'>-A blocked task may also be suspended. Therefore,
-both the suspension and the blocking condition must be removed
-before the task becomes ready to run again.
-
-A task occupies the ready state when it is able to be
-scheduled to run, but currently does not have control of the
-processor. Tasks of the same or higher priority will yield the
-processor by either becoming blocked, completing their
-timeslice, or being deleted. All tasks with the same priority
-will execute in FIFO order. A task enters the ready state due
</font><font color='#000088'>+A blocked task may also be suspended. Therefore, both the suspension
+and the blocking condition must be removed before the task becomes ready
+to run again.
+
+A task occupies the ready state when it is able to be scheduled to run,
+but currently does not have control of the processor. Tasks of the same
+or higher priority will yield the processor by either becoming blocked,
+completing their timeslice, or being deleted. All tasks with the same
+priority will execute in FIFO order. A task enters the ready state due
</font> to any of the following conditions:
@itemize @bullet
</pre>
<p> </p>
<p>--<br />
<small>Generated by <a href="http://www.codewiz.org/projects/index.html#loginfo">Deluxe Loginfo</a> 2.122 by Bernardo Innocenti <bernie@develer.com></small></p>
</body>
</html>