Changeset 418de42 in rtems


Ignore:
Timestamp:
Oct 5, 2011, 7:59:47 PM (10 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.11, 5, master
Children:
65253ab3
Parents:
656f958
Message:

2011-10-05 Joel Sherrill <joel.sherrill@…>

Petr Benes <benesp16@…>

PR 1912/doc

  • user/conf.t, user/schedule.t: Rework to add scheduler specific information.
Location:
doc
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • doc/ChangeLog

    r656f958 r418de42  
     12011-10-05      Joel Sherrill <joel.sherrill@oarcorp.com>
     2                Petr Benes <benesp16@fel.cvut.cz>
     3
     4        PR 1912/doc
     5        * user/conf.t, user/schedule.t: Rework to add scheduler specific
     6        information.
     7
    182011-09-19      Joel Sherrill <joel.sherrill@oarcorp.com>
    29

  • doc/user/conf.t

    r656f958 r418de42  
    437437selected by defining @code{CONFIGURE_SCHEDULER_SIMPLE_SMP}.
    438438
     439@findex CONFIGURE_SCHEDULER_EDF
     440@item Earliest Deadline First Scheduler (EDF) - This is an alternative
     441scheduler in RTEMS for single core applications. The EDF schedules tasks
     442with dynamic priorities equal to deadlines. The deadlines are
     443declared using only Rate Monotonic manager which handles periodic behavior.
     444Period is always equal to deadline. If a task does not have any deadline
     445declared or the deadline is cancelled, the task is considered a background
     446task which is scheduled in case no deadline-driven tasks are ready to run.
     447Moreover, multiple background tasks are scheduled according their priority
     448assigned upon initialization. All ready tasks reside in a single ready queue.
     449This scheduler may be explicitly selected by defining
     450@code{CONFIGURE_SCHEDULER_EDF}.
     451
     452@findex CONFIGURE_SCHEDULER_CBS
     453@item Constant Bandwidth Server Scheduler (CBS) - This is an alternative
     454scheduler in RTEMS for single core applications. The CBS is a budget aware
     455extention of EDF scheduler. The goal of this scheduler is to ensure temporal
     456isolation of tasks. The CBS is equipped with a set of additional rules and
     457provides with an extensive API. This scheduler may be explicitly selected
     458by defining @code{CONFIGURE_SCHEDULER_CBS}.
     459
    439460@end itemize
    440461
    441462The pluggable scheduler interface was added after the 4.10 release series
    442463so there are not a lot of options at this point.  We anticipate a lower
    443 memory, non-deterministic priority scheduler suitable for use in small
    444 systems and an Earliest Deadline First Scheduler (EDF) to arrive in
    445 the future.
     464memory and a non-deterministic priority scheduler suitable for use in small
     465systems to arrive in the future.
    446466
    447467The pluggable scheduler interface enables the user to provide their own scheduling algorithm.  If you choose to do this, you must define multiple configuration macros. 

  • doc/user/schedule.t

    r656f958 r418de42  
    11@c
    2 @c  COPYRIGHT (c) 1988-2002.
     2@c  COPYRIGHT (c) 1988-2011.
    33@c  On-Line Applications Research Corporation (OAR).
    44@c  All rights reserved.
    … …  
    77@c
    88
    9 @c
    10 @c   This figure is not included:
    11 @c      Figure 17-1  RTEMS Task State Transitions
    12 @c
    13 
    149@chapter Scheduling Concepts
    1510
    … …  
    1914@section Introduction
    2015
    21 The concept of scheduling in real-time systems
    22 dictates the ability to provide immediate response to specific
    23 external events, particularly the necessity of scheduling tasks
    24 to run within a specified time limit after the occurrence of an
    25 event.  For example, software embedded in life-support systems
    26 used to monitor hospital patients must take instant action if a
    27 change in the patient's status is detected.
    28 
    29 The component of RTEMS responsible for providing this
    30 capability is appropriately called the scheduler.  The
    31 scheduler's sole purpose is to allocate the all important
    32 resource of processor time to the various tasks competing for
    33 attention. 
     16The concept of scheduling in real-time systems dictates the ability to
     17provide immediate response to specific external events, particularly
     18the necessity of scheduling tasks to run within a specified time limit
     19after the occurrence of an event.  For example, software embedded in
     20life-support systems used to monitor hospital patients must take instant
     21action if a change in the patient's status is detected.
     22
     23The component of RTEMS responsible for providing this capability is
     24appropriately called the scheduler.  The scheduler's sole purpose is
     25to allocate the all important resource of processor time to the various
     26tasks competing for attention.
    3427
    3528@section Scheduling Algorithms
    … …  
    3730@cindex scheduling algorithms
    3831
    39 RTEMS provides multiple possible scheduling algorithms, each
    40 of which are appropriate to different use case scenarios.
    41 The classic RTEMS scheduling algorithm -- the only
    42 algorithm available in RTEMS 4.10 and earlier -- is the priority
    43 scheduling algorithm.  When not specified, the priority scheduling
    44 algorithm can be assumed.
    45 
    46 RTEMS currently supports the following scheduling algorithms:
    47 
    48 @itemize @bullet
    49 @item Priority scheduling
     32RTEMS provides a plugin framework which allows it to support
     33multiple scheduling algorithms. RTEMS now includes multiple
     34scheduling algorithms in the SuperCore and the user can select which
     35of these they wish to use in their application.  In addition,
     36the user can implement their own scheduling algorithm and
     37configure RTEMS to use it. 
     38
     39Supporting multiple scheduling algorithms gives the end user the
     40option to select the algorithm which is most appropriate to their use
     41case. Most real-time operating systems schedule tasks using a priority
     42based algorithm, possibly with preemption control.  The classic
     43RTEMS scheduling algorithm which was the only algorithm available
     44in RTEMS 4.10 and earlier, is a priority based scheduling algorithm.
     45This scheduling algoritm is suitable for single core (e.g. non-SMP)
     46systems and is now known as the @b{Deterministic Priority Scheduler}.
     47Unless the user configures another scheduling algorithm, RTEMS will use
     48this on single core systems.
     49
     50@subsection Priority Scheduling
     51
     52@cindex priority scheduling
     53
     54When using priority based scheduling, RTEMS allocates the processor using
     55a priority-based, preemptive algorithm augmented to provide round-robin
     56characteristics within individual priority groups.  The goal of this
     57algorithm is to guarantee that the task which is executing on the
     58processor at any point in time is the one with the highest priority
     59among all tasks in the ready state.
     60
     61When a task is added to the ready chain, it is placed behind all other
     62tasks of the same priority.  This rule provides a round-robin within
     63priority group scheduling characteristic.  This means that in a group of
     64equal priority tasks, tasks will execute in the order they become ready
     65or FIFO order.  Even though there are ways to manipulate and adjust task
     66priorities, the most important rule to remember is:
     67
     68@itemize @code{ }
     69@item @b{Priority based scheduling algorithms will always select the
     70highest priority task that is ready to run when allocating the processor
     71to a task.}
    5072@end itemize
    51 
    52 @subsection Priority Scheduling
    53 
    54 @cindex priority scheduling
    55 
    56 The RTEMS scheduler allocates the processor using a
    57 priority-based, preemptive algorithm augmented to provide
    58 round-robin characteristics within individual priority groups.
    59 The goal of this algorithm is to guarantee that the task which
    60 is executing on the processor at any point in time is the one
    61 with the highest priority among all tasks in the ready state.
    62 
    63 There are two common methods of accomplishing the
    64 mechanics of this algorithm.  Both ways involve a list or chain
    65 of tasks in the ready state.  One method is to randomly place
    66 tasks in the ready chain forcing the scheduler to scan the
    67 entire chain to determine which task receives the processor.
    68 The other method is to schedule the task by placing it in the
    69 proper place on the ready chain based on the designated
    70 scheduling criteria at the time it enters the ready state.
    71 Thus, when the processor is free, the first task on the ready
    72 chain is allocated the processor.  RTEMS schedules tasks using
    73 the second method to guarantee faster response times to external
    74 events.
    7573
    7674Priority scheduling is the most commonly used scheduling algorithm.
    … …  
    7977are given priority over other tasks.
    8078
    81 @section Scheduling Mechanisms
     79There are a few common methods of accomplishing the mechanics of this
     80algorithm.  These ways involve a list or chain of tasks in the ready state.
     81
     82@itemize @bullet
     83@item The least efficient method is to randomly place tasks in the ready
     84chain forcing the scheduler to scan the entire chain to determine which
     85task receives the processor.
     86
     87@item A more efficient method is to schedule the task by placing it
     88in the proper place on the ready chain based on the designated scheduling
     89criteria at the time it enters the ready state.  Thus, when the processor
     90is free, the first task on the ready chain is allocated the processor.
     91
     92@item Another mechanism is to maintain a list of FIFOs per priority.
     93When a task is readied, it is placed on the rear of the FIFO for its
     94priority.  This method is often used with a bitmap to assist in locating
     95which FIFOs have ready tasks on them.
     96
     97@end itemize
     98RTEMS currently includes multiple priority based scheduling algorithms
     99as well as other algorithms which incorporate deadline.  Each algorithm
     100is discussed in the following sections.
     101 
     102@subsection Deterministic Priority Scheduler
     103
     104This is the scheduler implementation which has always been in RTEMS.
     105After the 4.10 release series, it was factored into pluggable scheduler
     106selection.  It schedules tasks using a priority based algorithm which
     107takes into account preemption.  It is implemented using an array of FIFOs
     108with a FIFO per priority.  It maintains a bitmap which is used to track
     109which priorities have ready tasks.
     110
     111This algorithm is deterministic (e.g. predictable and fixed) in execution
     112time.  This comes at the cost of using slightly over three (3) kilobytes
     113of RAM on a system configured to support 256 priority levels.
     114
     115This scheduler is only aware of a single core.
     116
     117@subsection Simple Priority Scheduler
     118
     119This scheduler implementation has the same behaviour as the Deterministic
     120Priority Scheduler but uses only one linked list to manage all ready
     121tasks.  When a task is readied, a linear search of that linked list is
     122performed to determine where to insert the newly readied task.
     123
     124This algorithm uses much less RAM than the Deterministic Priority
     125Scheduler but is @i{O(n)} where @i{n} is the number of ready tasks.
     126In a small system with a small number of tasks, this will not be a
     127performance issue.  Reducing RAM consumption is often critical in small
     128systems which are incapable of supporting a large number of tasks.
     129
     130This scheduler is only aware of a single core.
     131
     132@subsection Simple SMP Priority Scheduler
     133
     134This scheduler is based upon the Simple Priority Scheduler and is designed
     135to have the same behaviour on a single core system.  But this scheduler
     136is capable of scheduling threads across multiple cores in an SMP system.
     137When given a choice of replacing one of two threads at equal priority
     138on different cores, this algorithm favors replacing threads which are
     139preemptible and have executed the longest.
     140
     141This algorithm is non-deterministic. When scheduling, it must consider
     142which tasks are to be executed on each core while avoiding superfluous
     143task migrations.
     144
     145@subsection Earliest Deadline First Scheduler
     146
     147@cindex earliest deadline first scheduling
     148
     149This is an alternative scheduler in RTEMS for single core applications.
     150The primary EDF advantage is high total CPU utilization (theoretically
     151up to 100%). It assumes that tasks have priorities equal to deadlines.
     152
     153This EDF is initially preemptive, however, individual tasks may be declared
     154not-preemptive. Deadlines are declared using only Rate Monotonic manager which
     155goal is to handle periodic behavior. Period is always equal to deadline. All
     156ready tasks reside in a single ready queue implemented using a red-black tree.
     157
     158This implementation of EDF schedules two different types of task
     159priority types while each task may switch between the two types within
     160its execution. If a task does have a deadline declared using the Rate
     161Monotonic manager, the task is deadline-driven and its priority is equal
     162to deadline.  On the contrary if a task does not have any deadline or
     163the deadline is cancelled using the Rate Monotonic manager, the task is
     164considered a background task with priority equal to that assigned
     165upon initialization in the same manner as for priority scheduler. Each
     166background task is of a lower importance than each deadline-driven one
     167and is scheduled when no deadline-driven task and no higher priority
     168background task is ready to run.
     169
     170Every deadline-driven scheduling algorithm requires means for tasks
     171to claim a deadline.  The Rate Monotonic Manager is responsible for
     172handling periodic execution. In RTEMS periods are equal to deadlines,
     173thus if a task announces a period, it has to be finished until the
     174end of this period. The call of @code{rtems_rate_monotonic_period}
     175passes the scheduler the length of oncoming deadline. Moreover, the
     176@code{rtems_rate_monotonic_cancel} and @code{rtems_rate_monotonic_delete}
     177calls clear the deadlines assigned to the task.
     178
     179@subsection Constant Bandwidth Server Scheduling (CBS)
     180
     181@cindex constant bandwidth server scheduling
     182
     183This is an alternative scheduler in RTEMS for single core applications.
     184The CBS is a budget aware extension of EDF scheduler. The main goal of this
     185scheduler is to ensure temporal isolation of tasks meaning that a task's
     186execution in terms of meeting deadlines must not be influenced by other
     187tasks as if they were run on multiple independent processors.
     188
     189Each task can be assigned a server (current implementation supports only
     190one task per server). The server is characterized by period (deadline)
     191and computation time (budget). The ratio budget/period yields bandwidth,
     192which is the fraction of CPU to be reserved by the scheduler for each
     193subsequent period.
     194
     195The CBS is equipped with a set of rules applied to tasks attached to servers
     196ensuring that deadline miss because of another task cannot occur.
     197In case a task breaks one of the rules, its priority is pulled to background
     198until the end of its period and then restored again. The rules are:
     199
     200@itemize @bullet
     201@item Task cannot exceed its registered budget, @item Task cannot be
     202unblocked when a ratio between remaining budget and remaining deadline
     203is higher than declared bandwidth.
     204@end itemize
     205
     206The CBS provides an extensive API. Unlike EDF, the
     207@code{rtems_rate_monotonic_period} does not declare a deadline because
     208it is carried out using CBS API. This call only announces next period.
     209
     210@section Scheduling Modification Mechanisms
    82211
    83212@cindex scheduling mechanisms
    84213
    85 RTEMS provides four mechanisms which allow the user
    86 to impact the task scheduling process:
     214RTEMS provides four mechanisms which allow the user to alter the task
     215scheduling decisions:
    87216
    88217@itemize @bullet
    … …  
    93222@end itemize
    94223
    95 Each of these methods provides a powerful capability
    96 to customize sets of tasks to satisfy the unique and particular
    97 requirements encountered in custom real-time applications.
    98 Although each mechanism operates independently, there is a
    99 precedence relationship which governs the effects of scheduling
    100 modifications.  The evaluation order for scheduling
    101 characteristics is always priority, preemption mode, and
    102 timeslicing.  When reading the descriptions of timeslicing and
    103 manual round-robin it is important to keep in mind that
    104 preemption (if enabled) of a task by higher priority tasks will
    105 occur as required, overriding the other factors presented in the
    106 description.
     224Each of these methods provides a powerful capability to customize sets
     225of tasks to satisfy the unique and particular requirements encountered
     226in custom real-time applications.  Although each mechanism operates
     227independently, there is a precedence relationship which governs the
     228effects of scheduling modifications.  The evaluation order for scheduling
     229characteristics is always priority, preemption mode, and timeslicing.
     230When reading the descriptions of timeslicing and manual round-robin
     231it is important to keep in mind that preemption (if enabled) of a task
     232by higher priority tasks will occur as required, overriding the other
     233factors presented in the description.
    107234
    108235@subsection Task Priority and Scheduling
    … …  
    110237@cindex task priority
    111238
    112 This mechanism affects the following scheduling algorithms:
    113 @itemize @bullet
    114 @item Priority scheduling
    115 @end itemize
    116 
    117 The most significant of these mechanisms is the
    118 ability for the user to assign a priority level to each
    119 individual task when it is created and to alter a task's
    120 priority at run-time.  RTEMS provides 255 priority levels.
    121 Level 255 is the lowest priority and level 1 is the highest.
    122 When a task is added to the ready chain, it is placed behind all
    123 other tasks of the same priority.  This rule provides a
    124 round-robin within priority group scheduling characteristic.
    125 This means that in a group of equal priority tasks, tasks will
    126 execute in the order they become ready or FIFO order.  Even
    127 though there are ways to manipulate and adjust task priorities,
    128 the most important rule to remember is:
    129 
    130 @itemize @code{ }
    131 @item @b{The RTEMS scheduler will always select the highest
    132 priority task that is ready to run when allocating the processor
    133 to a task.}
    134 @end itemize
     239The most significant task scheduling modification mechanism is the ability
     240for the user to assign a priority level to each individual task when it
     241is created and to alter a task's priority at run-time.  RTEMS supports
     242up to 255 priority levels.  Level 255 is the lowest priority and level
     2431 is the highest.
    135244
    136245@subsection Preemption
    137 
    138246@cindex preemption
    139247
    140 This mechanism affects the following scheduling algorithms:
    141 @itemize @bullet
    142 @item Priority scheduling
    143 @end itemize
    144 
    145 Another way the user can alter the basic scheduling
    146 algorithm is by manipulating the preemption mode flag
    147 (@code{@value{RPREFIX}PREEMPT_MASK}) of individual tasks.  If preemption is disabled
    148 for a task (@code{@value{RPREFIX}NO_PREEMPT}), then the task will not relinquish
    149 control of the processor until it terminates, blocks, or
    150 re-enables preemption.  Even tasks which become ready to run and
    151 possess higher priority levels will not be allowed to execute.
    152 Note that the preemption setting has no effect on the manner in
    153 which a task is scheduled.  It only applies once a task has
    154 control of the processor.
     248Another way the user can alter the basic scheduling algorithm is by
     249manipulating the preemption mode flag (@code{@value{RPREFIX}PREEMPT_MASK})
     250of individual tasks.  If preemption is disabled for a task
     251(@code{@value{RPREFIX}NO_PREEMPT}), then the task will not relinquish
     252control of the processor until it terminates, blocks, or re-enables
     253preemption.  Even tasks which become ready to run and possess higher
     254priority levels will not be allowed to execute.  Note that the preemption
     255setting has no effect on the manner in which a task is scheduled.
     256It only applies once a task has control of the processor.
    155257
    156258@subsection Timeslicing
    157 
    158259@cindex timeslicing
    159260@cindex round robin scheduling
    160261
    161 This mechanism affects the following scheduling algorithms:
    162 @itemize @bullet
    163 @item Priority scheduling
    164 @end itemize
    165 
    166 Timeslicing or round-robin scheduling is an
    167 additional method which can be used to alter the basic
    168 scheduling algorithm.  Like preemption, timeslicing is specified
    169 on a task by task basis using the timeslicing mode flag
    170 (@code{@value{RPREFIX}TIMESLICE_MASK}).  If timeslicing is enabled for a task
    171 (@code{@value{RPREFIX}TIMESLICE}), then RTEMS will limit the amount of time the task
    172 can execute before the processor is allocated to another task.
    173 Each tick of the real-time clock reduces the currently running
    174 task's timeslice.  When the execution time equals the timeslice,
    175 RTEMS will dispatch another task of the same priority to
    176 execute.  If there are no other tasks of the same priority ready
    177 to execute, then the current task is allocated an additional
    178 timeslice and continues to run.  Remember that a higher priority
    179 task will preempt the task (unless preemption is disabled) as
    180 soon as it is ready to run, even if the task has not used up its
    181 entire timeslice.
     262Timeslicing or round-robin scheduling is an additional method which
     263can be used to alter the basic scheduling algorithm.  Like preemption,
     264timeslicing is specified on a task by task basis using the timeslicing
     265mode flag (@code{@value{RPREFIX}TIMESLICE_MASK}).  If timeslicing is
     266enabled for a task (@code{@value{RPREFIX}TIMESLICE}), then RTEMS will
     267limit the amount of time the task can execute before the processor is
     268allocated to another task.  Each tick of the real-time clock reduces
     269the currently running task's timeslice.  When the execution time equals
     270the timeslice, RTEMS will dispatch another task of the same priority
     271to execute.  If there are no other tasks of the same priority ready to
     272execute, then the current task is allocated an additional timeslice and
     273continues to run.  Remember that a higher priority task will preempt
     274the task (unless preemption is disabled) as soon as it is ready to run,
     275even if the task has not used up its entire timeslice.
    182276
    183277@subsection Manual Round-Robin
    184 
    185278@cindex manual round robin
    186279
    187 This mechanism affects the following scheduling algorithms:
    188 @itemize @bullet
    189 @item Priority scheduling
    190 @end itemize
    191 
    192 The final mechanism for altering the RTEMS scheduling
    193 algorithm is called manual round-robin.  Manual round-robin is
    194 invoked by using the @code{@value{DIRPREFIX}task_wake_after}
    195 directive with a time interval of @code{@value{RPREFIX}YIELD_PROCESSOR}. 
    196 This allows a task to give up the
    197 processor and be immediately returned to the ready chain at the
    198 end of its priority group.  If no other tasks of the same
    199 priority are ready to run, then the task does not lose control
    200 of the processor.
     280The final mechanism for altering the RTEMS scheduling algorithm is
     281called manual round-robin.  Manual round-robin is invoked by using the
     282@code{@value{DIRPREFIX}task_wake_after} directive with a time interval
     283of @code{@value{RPREFIX}YIELD_PROCESSOR}.  This allows a task to give
     284up the processor and be immediately returned to the ready chain at the
     285end of its priority group.  If no other tasks of the same priority are
     286ready to run, then the task does not lose control of the processor.
    201287
    202288@section Dispatching Tasks
    203 
    204289@cindex dispatching
    205290
    … …  
    220305TCB or on the task's stacks.
    221306
    222 Tasks that utilize a numeric coprocessor and are
    223 created with the @code{@value{RPREFIX}FLOATING_POINT} attribute
    224 require additional operations during a context switch.  These
    225 additional operations
     307Tasks that utilize a numeric coprocessor and are created with the
     308@code{@value{RPREFIX}FLOATING_POINT} attribute require additional
     309operations during a context switch.  These additional operations
    226310are necessary to save and restore the floating point context of
    227 @code{@value{RPREFIX}FLOATING_POINT} tasks.  To avoid unnecessary save and restore
    228 operations, the state of the numeric coprocessor is only saved
    229 when a @code{@value{RPREFIX}FLOATING_POINT} task is dispatched and that task was not
    230 the last task to utilize the coprocessor.
     311@code{@value{RPREFIX}FLOATING_POINT} tasks.  To avoid unnecessary save
     312and restore operations, the state of the numeric coprocessor is only
     313saved when a @code{@value{RPREFIX}FLOATING_POINT} task is dispatched
     314and that task was not the last task to utilize the coprocessor.
    231315
    232316@section Task State Transitions
    233 
    234317@cindex task state transitions
    235318
    … …  
    238321blocked, dormant, and non-existent.
    239322
    240 A task occupies the non-existent state before a
    241 @code{@value{DIRPREFIX}task_create} has been
    242 issued on its behalf.  A task enters the
    243 non-existent state from any other state in the system when it is
    244 deleted with the @code{@value{DIRPREFIX}task_delete}
    245 directive.  While a task occupies
    246 this state it does not have a TCB or a task ID assigned to it;
    247 therefore, no other tasks in the system may reference this task.
    248 
    249 When a task is created via the @code{@value{DIRPREFIX}task_create} directive
    250 it enters the dormant state.  This state is not entered through
    251 any other means.  Although the task exists in the system, it
    252 cannot actively compete for system resources.  It will remain in
    253 the dormant state until it is started via the @code{@value{DIRPREFIX}task_start}
    254 directive, at which time it enters the ready state.  The task is
    255 now permitted to be scheduled for the processor and to compete
    256 for other system resources.
     323A task occupies the non-existent state before
     324a @code{@value{DIRPREFIX}task_create} has been issued on its behalf.
     325A task enters the non-existent state from any other state in the system
     326when it is deleted with the @code{@value{DIRPREFIX}task_delete} directive.
     327While a task occupies this state it does not have a TCB or a task ID
     328assigned to it; therefore, no other tasks in the system may reference
     329this task.
     330
     331When a task is created via the @code{@value{DIRPREFIX}task_create}
     332directive it enters the dormant state.  This state is not entered through
     333any other means.  Although the task exists in the system, it cannot
     334actively compete for system resources.  It will remain in the dormant
     335state until it is started via the @code{@value{DIRPREFIX}task_start}
     336directive, at which time it enters the ready state.  The task is now
     337permitted to be scheduled for the processor and to compete for other
     338system resources.
    257339
    258340@float Figure,fig:RTEMS-Task-States
    … …  
    306388@end float
    307389
    308 A task occupies the blocked state whenever it is
    309 unable to be scheduled to run.  A running task may block itself
    310 or be blocked by other tasks in the system.  The running task
    311 blocks itself through voluntary operations that cause the task
    312 to wait.  The only way a task can block a task other than itself
    313 is with the @code{@value{DIRPREFIX}task_suspend} directive. 
     390A task occupies the blocked state whenever it is unable to be scheduled
     391to run.  A running task may block itself or be blocked by other tasks in
     392the system.  The running task blocks itself through voluntary operations
     393that cause the task to wait.  The only way a task can block a task other
     394than itself is with the @code{@value{DIRPREFIX}task_suspend} directive.
    314395A task enters the blocked state due to any of the following conditions:
    315396
    … …  
    318399which blocks either itself or another task in the system.
    319400
     401@item The running task issues a @code{@value{DIRPREFIX}barrier_wait}
     402directive.
     403
    320404@item The running task issues a @code{@value{DIRPREFIX}message_queue_receive}
    321405directive with the wait option and the message queue is empty.
    … …  
    330414@item The running task issues a @code{@value{DIRPREFIX}task_wake_after}
    331415directive which blocks the task for the given time interval.  If the time
    332 interval specified is zero, the task yields the processor and
    333 remains in the ready state.
     416interval specified is zero, the task yields the processor and remains
     417in the ready state.
    334418
    335419@item The running task issues a @code{@value{DIRPREFIX}task_wake_when}
    336420directive which blocks the task until the requested date and time arrives.
     421
     422@item The running task issues a @code{@value{DIRPREFIX}rate_monotonic_period}
     423directive and must wait for the specified rate monotonic period
     424to conclude.
    337425
    338426@item The running task issues a @code{@value{DIRPREFIX}region_get_segment}
    … …  
    340428enough to satisfy the task's request.
    341429
    342 @item The running task issues a @code{@value{DIRPREFIX}rate_monotonic_period}
    343 directive and must wait for the specified rate monotonic period
    344 to conclude.
    345430@end itemize
    346431
    347 A blocked task may also be suspended.  Therefore,
    348 both the suspension and the blocking condition must be removed
    349 before the task becomes ready to run again.
    350 
    351 A task occupies the ready state when it is able to be
    352 scheduled to run, but currently does not have control of the
    353 processor.  Tasks of the same or higher priority will yield the
    354 processor by either becoming blocked, completing their
    355 timeslice, or being deleted.  All tasks with the same priority
    356 will execute in FIFO order.  A task enters the ready state due
     432A blocked task may also be suspended.  Therefore, both the suspension
     433and the blocking condition must be removed before the task becomes ready
     434to run again.
     435
     436A task occupies the ready state when it is able to be scheduled to run,
     437but currently does not have control of the processor.  Tasks of the same
     438or higher priority will yield the processor by either becoming blocked,
     439completing their timeslice, or being deleted.  All tasks with the same
     440priority will execute in FIFO order.  A task enters the ready state due
    357441to any of the following conditions:
    358442
Note: See TracChangeset for help on using the changeset viewer.