change log for rtems (2011-10-05)
rtems-vc at rtems.org
rtems-vc at rtems.org
Wed Oct 5 20:11:20 UTC 2011
*joel*:
2011-10-05 Joel Sherrill <joel.sherrill at oarcorp.com>
Petr Benes <benesp16 at fel.cvut.cz>
PR 1912/doc
* user/conf.t, user/schedule.t: Rework to add scheduler specific
information.
M 1.319 doc/ChangeLog
M 1.74 doc/user/conf.t
M 1.16 doc/user/schedule.t
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
@@ -1,3 +1,10 @@
+2011-10-05 Joel Sherrill <joel.sherrill at oarcorp.com>
+ Petr Benes <benesp16 at fel.cvut.cz>
+
+ PR 1912/doc
+ * user/conf.t, user/schedule.t: Rework to add scheduler specific
+ information.
+
2011-09-19 Joel Sherrill <joel.sherrill at oarcorp.com>
* user/Makefile.am, user/c_user.texi: Reorder chapters to put
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
@@ -436,13 +436,33 @@
configuration with SMP enabled at configure time, it may be explicitly
selected by defining @code{CONFIGURE_SCHEDULER_SIMPLE_SMP}.
+ at findex CONFIGURE_SCHEDULER_EDF
+ at 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
+ at code{CONFIGURE_SCHEDULER_EDF}.
+
+ at findex CONFIGURE_SCHEDULER_CBS
+ at 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}.
+
@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
-memory, non-deterministic priority scheduler suitable for use in small
-systems and an Earliest Deadline First Scheduler (EDF) to arrive in
-the future.
+memory and a non-deterministic priority scheduler suitable for use in small
+systems to arrive in the future.
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.
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
@@ -1,16 +1,11 @@
@c
- at c COPYRIGHT (c) 1988-2002.
+ at c COPYRIGHT (c) 1988-2011.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
- at c
- at c This figure is not included:
- at c Figure 17-1 RTEMS Task State Transitions
- at c
-
@chapter Scheduling Concepts
@cindex scheduling
@@ -18,72 +13,206 @@
@section Introduction
-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.
+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.
@section Scheduling Algorithms
@cindex scheduling algorithms
-RTEMS provides multiple possible scheduling algorithms, each
-of which are appropriate to different use case scenarios.
-The classic RTEMS scheduling algorithm -- the only
-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:
-
- at itemize @bullet
- at item Priority scheduling
- at end itemize
+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,
+the user can implement their own scheduling algorithm and
+configure RTEMS to use it.
+
+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.
@subsection Priority Scheduling
@cindex priority scheduling
-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.
+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:
+
+ at itemize @code{ }
+ at 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.}
+ at end itemize
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 other tasks.
- at section Scheduling Mechanisms
+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.
+
+ at itemize @bullet
+ at 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.
+
+ at 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.
+
+ at 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.
+
+ at 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.
+
+ at 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.
+
+ at 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.
+
+ at 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.
+
+ at subsection Earliest Deadline First Scheduler
+
+ at cindex earliest deadline first scheduling
+
+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
+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
+ at code{rtems_rate_monotonic_cancel} and @code{rtems_rate_monotonic_delete}
+calls clear the deadlines assigned to the task.
+
+ at subsection Constant Bandwidth Server Scheduling (CBS)
+
+ at 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:
+
+ at itemize @bullet
+ at 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.
+ at end itemize
+
+The CBS provides an extensive API. Unlike EDF, the
+ at code{rtems_rate_monotonic_period} does not declare a deadline because
+it is carried out using CBS API. This call only announces next period.
+
+ at section Scheduling Modification Mechanisms
@cindex scheduling mechanisms
-RTEMS provides four mechanisms which allow the user
-to impact the task scheduling process:
+RTEMS provides four mechanisms which allow the user to alter the task
+scheduling decisions:
@itemize @bullet
@item user-selectable task priority level
@@ -92,115 +221,71 @@
@item manual round-robin selection
@end itemize
-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.
+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.
@subsection Task Priority and Scheduling
@cindex task priority
-This mechanism affects the following scheduling algorithms:
- at itemize @bullet
- at item Priority scheduling
- at 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:
-
- at itemize @code{ }
- at item @b{The RTEMS scheduler will always select the highest
-priority task that is ready to run when allocating the processor
-to a task.}
- at end itemize
+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.
@subsection Preemption
-
@cindex preemption
-This mechanism affects the following scheduling algorithms:
- at itemize @bullet
- at item Priority scheduling
- at 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.
+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.
@subsection Timeslicing
-
@cindex timeslicing
@cindex round robin scheduling
-This mechanism affects the following scheduling algorithms:
- at itemize @bullet
- at item Priority scheduling
- at 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.
+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.
@subsection Manual Round-Robin
-
@cindex manual round robin
-This mechanism affects the following scheduling algorithms:
- at itemize @bullet
- at item Priority scheduling
- at 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}.
-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.
+The final mechanism for altering the RTEMS scheduling algorithm is
+called manual round-robin. Manual round-robin is invoked by using the
+ at 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.
@section Dispatching Tasks
-
@cindex dispatching
The dispatcher is the RTEMS component responsible for
@@ -219,41 +304,38 @@
saved or restored for a context switch is located either in the
TCB or on the task's stacks.
-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
+Tasks that utilize a numeric coprocessor and are created with the
+ at code{@value{RPREFIX}FLOATING_POINT} attribute require additional
+operations during a context switch. These additional operations
are necessary to save and restore the floating point context of
- at 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.
+ at 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.
@section Task State Transitions
-
@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.
-A task occupies the non-existent state before a
- at 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.
+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.
@float Figure,fig:RTEMS-Task-States
@caption{RTEMS Task States}
@@ -305,18 +387,20 @@
@end ifset
@end float
-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.
+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.
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.
+ at item The running task issues a @code{@value{DIRPREFIX}barrier_wait}
+directive.
+
@item The running task issues a @code{@value{DIRPREFIX}message_queue_receive}
directive with the wait option and the message queue is empty.
@@ -329,31 +413,31 @@
@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
-interval specified is zero, the task yields the processor and
-remains in the ready state.
+interval specified is zero, the task yields the processor and remains
+in the ready state.
@item The running task issues a @code{@value{DIRPREFIX}task_wake_when}
directive which blocks the task until the requested date and time arrives.
+ at item The running task issues a @code{@value{DIRPREFIX}rate_monotonic_period}
+directive and must wait for the specified rate monotonic period
+to conclude.
+
@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.
- at item The running task issues a @code{@value{DIRPREFIX}rate_monotonic_period}
-directive and must wait for the specified rate monotonic period
-to conclude.
@end itemize
-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
+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
to any of the following conditions:
@itemize @bullet
--
Generated by Deluxe Loginfo [http://www.codewiz.org/projects/index.html#loginfo] 2.122 by Bernardo Innocenti <bernie at develer.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/vc/attachments/20111005/27a4013a/attachment-0001.html>
More information about the vc
mailing list