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. |
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 |
50 | | @end itemize |
| 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. |
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. |
| 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.} |
| 72 | @end itemize |
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 |
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. |
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. |
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. |
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. |