Changeset 418de42 in rtems
- Timestamp:
- 10/05/11 19:59:47 (11 years ago)
- Branches:
- 4.11, 5, master
- Children:
- 65253ab3
- Parents:
- 656f958
- Location:
- doc
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/ChangeLog
r656f958 r418de42 1 2011-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 1 8 2011-09-19 Joel Sherrill <joel.sherrill@oarcorp.com> 2 9 -
doc/user/conf.t
r656f958 r418de42 437 437 selected by defining @code{CONFIGURE_SCHEDULER_SIMPLE_SMP}. 438 438 439 @findex CONFIGURE_SCHEDULER_EDF 440 @item Earliest Deadline First Scheduler (EDF) - This is an alternative 441 scheduler in RTEMS for single core applications. The EDF schedules tasks 442 with dynamic priorities equal to deadlines. The deadlines are 443 declared using only Rate Monotonic manager which handles periodic behavior. 444 Period is always equal to deadline. If a task does not have any deadline 445 declared or the deadline is cancelled, the task is considered a background 446 task which is scheduled in case no deadline-driven tasks are ready to run. 447 Moreover, multiple background tasks are scheduled according their priority 448 assigned upon initialization. All ready tasks reside in a single ready queue. 449 This 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 454 scheduler in RTEMS for single core applications. The CBS is a budget aware 455 extention of EDF scheduler. The goal of this scheduler is to ensure temporal 456 isolation of tasks. The CBS is equipped with a set of additional rules and 457 provides with an extensive API. This scheduler may be explicitly selected 458 by defining @code{CONFIGURE_SCHEDULER_CBS}. 459 439 460 @end itemize 440 461 441 462 The pluggable scheduler interface was added after the 4.10 release series 442 463 so 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. 464 memory and a non-deterministic priority scheduler suitable for use in small 465 systems to arrive in the future. 446 466 447 467 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. -
doc/user/schedule.t
r656f958 r418de42 1 1 @c 2 @c COPYRIGHT (c) 1988-20 02.2 @c COPYRIGHT (c) 1988-2011. 3 3 @c On-Line Applications Research Corporation (OAR). 4 4 @c All rights reserved. … … 7 7 @c 8 8 9 @c10 @c This figure is not included:11 @c Figure 17-1 RTEMS Task State Transitions12 @c13 14 9 @chapter Scheduling Concepts 15 10 … … 19 14 @section Introduction 20 15 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. 16 The concept of scheduling in real-time systems dictates the ability to 17 provide immediate response to specific external events, particularly 18 the necessity of scheduling tasks to run within a specified time limit 19 after the occurrence of an event. For example, software embedded in 20 life-support systems used to monitor hospital patients must take instant 21 action if a change in the patient's status is detected. 22 23 The component of RTEMS responsible for providing this capability is 24 appropriately called the scheduler. The scheduler's sole purpose is 25 to allocate the all important resource of processor time to the various 26 tasks competing for attention. 34 27 35 28 @section Scheduling Algorithms … … 37 30 @cindex scheduling algorithms 38 31 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 32 RTEMS provides a plugin framework which allows it to support 33 multiple scheduling algorithms. RTEMS now includes multiple 34 scheduling algorithms in the SuperCore and the user can select which 35 of these they wish to use in their application. In addition, 36 the user can implement their own scheduling algorithm and 37 configure RTEMS to use it. 38 39 Supporting multiple scheduling algorithms gives the end user the 40 option to select the algorithm which is most appropriate to their use 41 case. Most real-time operating systems schedule tasks using a priority 42 based algorithm, possibly with preemption control. The classic 43 RTEMS scheduling algorithm which was the only algorithm available 44 in RTEMS 4.10 and earlier, is a priority based scheduling algorithm. 45 This scheduling algoritm is suitable for single core (e.g. non-SMP) 46 systems and is now known as the @b{Deterministic Priority Scheduler}. 47 Unless the user configures another scheduling algorithm, RTEMS will use 48 this on single core systems. 49 50 @subsection Priority Scheduling 51 52 @cindex priority scheduling 53 54 When using priority based scheduling, RTEMS allocates the processor using 55 a priority-based, preemptive algorithm augmented to provide round-robin 56 characteristics within individual priority groups. The goal of this 57 algorithm is to guarantee that the task which is executing on the 58 processor at any point in time is the one with the highest priority 59 among all tasks in the ready state. 60 61 When a task is added to the ready chain, it is placed behind all other 62 tasks of the same priority. This rule provides a round-robin within 63 priority group scheduling characteristic. This means that in a group of 64 equal priority tasks, tasks will execute in the order they become ready 65 or FIFO order. Even though there are ways to manipulate and adjust task 66 priorities, the most important rule to remember is: 67 68 @itemize @code{ } 69 @item @b{Priority based scheduling algorithms will always select the 70 highest priority task that is ready to run when allocating the processor 71 to a task.} 50 72 @end itemize 51 52 @subsection Priority Scheduling53 54 @cindex priority scheduling55 56 The RTEMS scheduler allocates the processor using a57 priority-based, preemptive algorithm augmented to provide58 round-robin characteristics within individual priority groups.59 The goal of this algorithm is to guarantee that the task which60 is executing on the processor at any point in time is the one61 with the highest priority among all tasks in the ready state.62 63 There are two common methods of accomplishing the64 mechanics of this algorithm. Both ways involve a list or chain65 of tasks in the ready state. One method is to randomly place66 tasks in the ready chain forcing the scheduler to scan the67 entire chain to determine which task receives the processor.68 The other method is to schedule the task by placing it in the69 proper place on the ready chain based on the designated70 scheduling criteria at the time it enters the ready state.71 Thus, when the processor is free, the first task on the ready72 chain is allocated the processor. RTEMS schedules tasks using73 the second method to guarantee faster response times to external74 events.75 73 76 74 Priority scheduling is the most commonly used scheduling algorithm. … … 79 77 are given priority over other tasks. 80 78 81 @section Scheduling Mechanisms 79 There are a few common methods of accomplishing the mechanics of this 80 algorithm. 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 84 chain forcing the scheduler to scan the entire chain to determine which 85 task receives the processor. 86 87 @item A more efficient method is to schedule the task by placing it 88 in the proper place on the ready chain based on the designated scheduling 89 criteria at the time it enters the ready state. Thus, when the processor 90 is 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. 93 When a task is readied, it is placed on the rear of the FIFO for its 94 priority. This method is often used with a bitmap to assist in locating 95 which FIFOs have ready tasks on them. 96 97 @end itemize 98 RTEMS currently includes multiple priority based scheduling algorithms 99 as well as other algorithms which incorporate deadline. Each algorithm 100 is discussed in the following sections. 101 102 @subsection Deterministic Priority Scheduler 103 104 This is the scheduler implementation which has always been in RTEMS. 105 After the 4.10 release series, it was factored into pluggable scheduler 106 selection. It schedules tasks using a priority based algorithm which 107 takes into account preemption. It is implemented using an array of FIFOs 108 with a FIFO per priority. It maintains a bitmap which is used to track 109 which priorities have ready tasks. 110 111 This algorithm is deterministic (e.g. predictable and fixed) in execution 112 time. This comes at the cost of using slightly over three (3) kilobytes 113 of RAM on a system configured to support 256 priority levels. 114 115 This scheduler is only aware of a single core. 116 117 @subsection Simple Priority Scheduler 118 119 This scheduler implementation has the same behaviour as the Deterministic 120 Priority Scheduler but uses only one linked list to manage all ready 121 tasks. When a task is readied, a linear search of that linked list is 122 performed to determine where to insert the newly readied task. 123 124 This algorithm uses much less RAM than the Deterministic Priority 125 Scheduler but is @i{O(n)} where @i{n} is the number of ready tasks. 126 In a small system with a small number of tasks, this will not be a 127 performance issue. Reducing RAM consumption is often critical in small 128 systems which are incapable of supporting a large number of tasks. 129 130 This scheduler is only aware of a single core. 131 132 @subsection Simple SMP Priority Scheduler 133 134 This scheduler is based upon the Simple Priority Scheduler and is designed 135 to have the same behaviour on a single core system. But this scheduler 136 is capable of scheduling threads across multiple cores in an SMP system. 137 When given a choice of replacing one of two threads at equal priority 138 on different cores, this algorithm favors replacing threads which are 139 preemptible and have executed the longest. 140 141 This algorithm is non-deterministic. When scheduling, it must consider 142 which tasks are to be executed on each core while avoiding superfluous 143 task migrations. 144 145 @subsection Earliest Deadline First Scheduler 146 147 @cindex earliest deadline first scheduling 148 149 This is an alternative scheduler in RTEMS for single core applications. 150 The primary EDF advantage is high total CPU utilization (theoretically 151 up to 100%). It assumes that tasks have priorities equal to deadlines. 152 153 This EDF is initially preemptive, however, individual tasks may be declared 154 not-preemptive. Deadlines are declared using only Rate Monotonic manager which 155 goal is to handle periodic behavior. Period is always equal to deadline. All 156 ready tasks reside in a single ready queue implemented using a red-black tree. 157 158 This implementation of EDF schedules two different types of task 159 priority types while each task may switch between the two types within 160 its execution. If a task does have a deadline declared using the Rate 161 Monotonic manager, the task is deadline-driven and its priority is equal 162 to deadline. On the contrary if a task does not have any deadline or 163 the deadline is cancelled using the Rate Monotonic manager, the task is 164 considered a background task with priority equal to that assigned 165 upon initialization in the same manner as for priority scheduler. Each 166 background task is of a lower importance than each deadline-driven one 167 and is scheduled when no deadline-driven task and no higher priority 168 background task is ready to run. 169 170 Every deadline-driven scheduling algorithm requires means for tasks 171 to claim a deadline. The Rate Monotonic Manager is responsible for 172 handling periodic execution. In RTEMS periods are equal to deadlines, 173 thus if a task announces a period, it has to be finished until the 174 end of this period. The call of @code{rtems_rate_monotonic_period} 175 passes the scheduler the length of oncoming deadline. Moreover, the 176 @code{rtems_rate_monotonic_cancel} and @code{rtems_rate_monotonic_delete} 177 calls clear the deadlines assigned to the task. 178 179 @subsection Constant Bandwidth Server Scheduling (CBS) 180 181 @cindex constant bandwidth server scheduling 182 183 This is an alternative scheduler in RTEMS for single core applications. 184 The CBS is a budget aware extension of EDF scheduler. The main goal of this 185 scheduler is to ensure temporal isolation of tasks meaning that a task's 186 execution in terms of meeting deadlines must not be influenced by other 187 tasks as if they were run on multiple independent processors. 188 189 Each task can be assigned a server (current implementation supports only 190 one task per server). The server is characterized by period (deadline) 191 and computation time (budget). The ratio budget/period yields bandwidth, 192 which is the fraction of CPU to be reserved by the scheduler for each 193 subsequent period. 194 195 The CBS is equipped with a set of rules applied to tasks attached to servers 196 ensuring that deadline miss because of another task cannot occur. 197 In case a task breaks one of the rules, its priority is pulled to background 198 until 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 202 unblocked when a ratio between remaining budget and remaining deadline 203 is higher than declared bandwidth. 204 @end itemize 205 206 The CBS provides an extensive API. Unlike EDF, the 207 @code{rtems_rate_monotonic_period} does not declare a deadline because 208 it is carried out using CBS API. This call only announces next period. 209 210 @section Scheduling Modification Mechanisms 82 211 83 212 @cindex scheduling mechanisms 84 213 85 RTEMS provides four mechanisms which allow the user 86 to impact the task scheduling process:214 RTEMS provides four mechanisms which allow the user to alter the task 215 scheduling decisions: 87 216 88 217 @itemize @bullet … … 93 222 @end itemize 94 223 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. 224 Each of these methods provides a powerful capability to customize sets 225 of tasks to satisfy the unique and particular requirements encountered 226 in custom real-time applications. Although each mechanism operates 227 independently, there is a precedence relationship which governs the 228 effects of scheduling modifications. The evaluation order for scheduling 229 characteristics is always priority, preemption mode, and timeslicing. 230 When reading the descriptions of timeslicing and manual round-robin 231 it is important to keep in mind that preemption (if enabled) of a task 232 by higher priority tasks will occur as required, overriding the other 233 factors presented in the description. 107 234 108 235 @subsection Task Priority and Scheduling … … 110 237 @cindex task priority 111 238 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 239 The most significant task scheduling modification mechanism is the ability 240 for the user to assign a priority level to each individual task when it 241 is created and to alter a task's priority at run-time. RTEMS supports 242 up to 255 priority levels. Level 255 is the lowest priority and level 243 1 is the highest. 135 244 136 245 @subsection Preemption 137 138 246 @cindex preemption 139 247 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. 248 Another way the user can alter the basic scheduling algorithm is by 249 manipulating the preemption mode flag (@code{@value{RPREFIX}PREEMPT_MASK}) 250 of individual tasks. If preemption is disabled for a task 251 (@code{@value{RPREFIX}NO_PREEMPT}), then the task will not relinquish 252 control of the processor until it terminates, blocks, or re-enables 253 preemption. Even tasks which become ready to run and possess higher 254 priority levels will not be allowed to execute. Note that the preemption 255 setting has no effect on the manner in which a task is scheduled. 256 It only applies once a task has control of the processor. 155 257 156 258 @subsection Timeslicing 157 158 259 @cindex timeslicing 159 260 @cindex round robin scheduling 160 261 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. 262 Timeslicing or round-robin scheduling is an additional method which 263 can be used to alter the basic scheduling algorithm. Like preemption, 264 timeslicing is specified on a task by task basis using the timeslicing 265 mode flag (@code{@value{RPREFIX}TIMESLICE_MASK}). If timeslicing is 266 enabled for a task (@code{@value{RPREFIX}TIMESLICE}), then RTEMS will 267 limit the amount of time the task can execute before the processor is 268 allocated to another task. Each tick of the real-time clock reduces 269 the currently running task's timeslice. When the execution time equals 270 the timeslice, RTEMS will dispatch another task of the same priority 271 to execute. If there are no other tasks of the same priority ready to 272 execute, then the current task is allocated an additional timeslice and 273 continues to run. Remember that a higher priority task will preempt 274 the task (unless preemption is disabled) as soon as it is ready to run, 275 even if the task has not used up its entire timeslice. 182 276 183 277 @subsection Manual Round-Robin 184 185 278 @cindex manual round robin 186 279 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. 280 The final mechanism for altering the RTEMS scheduling algorithm is 281 called manual round-robin. Manual round-robin is invoked by using the 282 @code{@value{DIRPREFIX}task_wake_after} directive with a time interval 283 of @code{@value{RPREFIX}YIELD_PROCESSOR}. This allows a task to give 284 up the processor and be immediately returned to the ready chain at the 285 end of its priority group. If no other tasks of the same priority are 286 ready to run, then the task does not lose control of the processor. 201 287 202 288 @section Dispatching Tasks 203 204 289 @cindex dispatching 205 290 … … 220 305 TCB or on the task's stacks. 221 306 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 307 Tasks that utilize a numeric coprocessor and are created with the 308 @code{@value{RPREFIX}FLOATING_POINT} attribute require additional 309 operations during a context switch. These additional operations 226 310 are necessary to save and restore the floating point context of 227 @code{@value{RPREFIX}FLOATING_POINT} tasks. To avoid unnecessary save and restore228 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 312 and restore operations, the state of the numeric coprocessor is only 313 saved when a @code{@value{RPREFIX}FLOATING_POINT} task is dispatched 314 and that task was not the last task to utilize the coprocessor. 231 315 232 316 @section Task State Transitions 233 234 317 @cindex task state transitions 235 318 … … 238 321 blocked, dormant, and non-existent. 239 322 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. 323 A task occupies the non-existent state before 324 a @code{@value{DIRPREFIX}task_create} has been issued on its behalf. 325 A task enters the non-existent state from any other state in the system 326 when it is deleted with the @code{@value{DIRPREFIX}task_delete} directive. 327 While a task occupies this state it does not have a TCB or a task ID 328 assigned to it; therefore, no other tasks in the system may reference 329 this task. 330 331 When a task is created via the @code{@value{DIRPREFIX}task_create} 332 directive it enters the dormant state. This state is not entered through 333 any other means. Although the task exists in the system, it cannot 334 actively compete for system resources. It will remain in the dormant 335 state until it is started via the @code{@value{DIRPREFIX}task_start} 336 directive, at which time it enters the ready state. The task is now 337 permitted to be scheduled for the processor and to compete for other 338 system resources. 257 339 258 340 @float Figure,fig:RTEMS-Task-States … … 306 388 @end float 307 389 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. 390 A task occupies the blocked state whenever it is unable to be scheduled 391 to run. A running task may block itself or be blocked by other tasks in 392 the system. The running task blocks itself through voluntary operations 393 that cause the task to wait. The only way a task can block a task other 394 than itself is with the @code{@value{DIRPREFIX}task_suspend} directive. 314 395 A task enters the blocked state due to any of the following conditions: 315 396 … … 318 399 which blocks either itself or another task in the system. 319 400 401 @item The running task issues a @code{@value{DIRPREFIX}barrier_wait} 402 directive. 403 320 404 @item The running task issues a @code{@value{DIRPREFIX}message_queue_receive} 321 405 directive with the wait option and the message queue is empty. … … 330 414 @item The running task issues a @code{@value{DIRPREFIX}task_wake_after} 331 415 directive which blocks the task for the given time interval. If the time 332 interval specified is zero, the task yields the processor and 333 remainsin the ready state.416 interval specified is zero, the task yields the processor and remains 417 in the ready state. 334 418 335 419 @item The running task issues a @code{@value{DIRPREFIX}task_wake_when} 336 420 directive 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} 423 directive and must wait for the specified rate monotonic period 424 to conclude. 337 425 338 426 @item The running task issues a @code{@value{DIRPREFIX}region_get_segment} … … 340 428 enough to satisfy the task's request. 341 429 342 @item The running task issues a @code{@value{DIRPREFIX}rate_monotonic_period}343 directive and must wait for the specified rate monotonic period344 to conclude.345 430 @end itemize 346 431 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 432 A blocked task may also be suspended. Therefore, both the suspension 433 and the blocking condition must be removed before the task becomes ready 434 to run again. 435 436 A task occupies the ready state when it is able to be scheduled to run, 437 but currently does not have control of the processor. Tasks of the same 438 or higher priority will yield the processor by either becoming blocked, 439 completing their timeslice, or being deleted. All tasks with the same 440 priority will execute in FIFO order. A task enters the ready state due 357 441 to any of the following conditions: 358 442
Note: See TracChangeset
for help on using the changeset viewer.