[4783b0d] | 1 | Rate Monotonic Manager |
---|
| 2 | ###################### |
---|
| 3 | |
---|
| 4 | .. index:: rate mononitonic tasks |
---|
| 5 | .. index:: periodic tasks |
---|
| 6 | |
---|
| 7 | Introduction |
---|
| 8 | ============ |
---|
| 9 | |
---|
| 10 | The rate monotonic manager provides facilities to implement tasks which execute |
---|
| 11 | in a periodic fashion. Critically, it also gathers information about the |
---|
| 12 | execution of those periods and can provide important statistics to the |
---|
| 13 | user which can be used to analyze and tune the application. The directives |
---|
| 14 | provided by the rate monotonic manager are: |
---|
| 15 | |
---|
| 16 | - ``rtems.rate_monotonic_create`` - Create a rate monotonic period |
---|
| 17 | |
---|
| 18 | - ``rtems.rate_monotonic_ident`` - Get ID of a period |
---|
| 19 | |
---|
| 20 | - ``rtems.rate_monotonic_cancel`` - Cancel a period |
---|
| 21 | |
---|
| 22 | - ``rtems.rate_monotonic_delete`` - Delete a rate monotonic period |
---|
| 23 | |
---|
| 24 | - ``rtems.rate_monotonic_period`` - Conclude current/Start next period |
---|
| 25 | |
---|
| 26 | - ``rtems.rate_monotonic_get_status`` - Obtain status from a period |
---|
| 27 | |
---|
| 28 | - ``rtems.rate_monotonic_get_statistics`` - Obtain statistics from a period |
---|
| 29 | |
---|
| 30 | - ``rtems.rate_monotonic_reset_statistics`` - Reset statistics for a period |
---|
| 31 | |
---|
| 32 | - ``rtems.rate_monotonic_reset_all_statistics`` - Reset statistics for all periods |
---|
| 33 | |
---|
| 34 | - ``rtems.rate_monotonic_report_statistics`` - Print period statistics report |
---|
| 35 | |
---|
| 36 | Background |
---|
| 37 | ========== |
---|
| 38 | |
---|
| 39 | The rate monotonic manager provides facilities to |
---|
| 40 | manage the execution of periodic tasks. This manager was |
---|
| 41 | designed to support application designers who utilize the Rate |
---|
| 42 | Monotonic Scheduling Algorithm (RMS) to ensure that their |
---|
| 43 | periodic tasks will meet their deadlines, even under transient |
---|
| 44 | overload conditions. Although designed for hard real-time |
---|
| 45 | systems, the services provided by the rate monotonic manager may |
---|
| 46 | be used by any application which requires periodic tasks. |
---|
| 47 | |
---|
| 48 | Rate Monotonic Manager Required Support |
---|
| 49 | --------------------------------------- |
---|
| 50 | |
---|
| 51 | A clock tick is required to support the functionality provided by this manager. |
---|
| 52 | |
---|
| 53 | Period Statistics |
---|
| 54 | ----------------- |
---|
| 55 | |
---|
| 56 | This manager maintains a set of statistics on each period object. These |
---|
| 57 | statistics are reset implictly at period creation time and may be reset or |
---|
| 58 | obtained at any time by the application. The following is a list of the |
---|
| 59 | information kept: |
---|
| 60 | |
---|
| 61 | - ``owner`` |
---|
| 62 | is the id of the thread that owns this period. |
---|
| 63 | |
---|
| 64 | - ``count`` |
---|
| 65 | is the total number of periods executed. |
---|
| 66 | |
---|
| 67 | - ``missed_count`` |
---|
| 68 | is the number of periods that were missed. |
---|
| 69 | |
---|
| 70 | - ``min_cpu_time`` |
---|
| 71 | is the minimum amount of CPU execution time consumed |
---|
| 72 | on any execution of the periodic loop. |
---|
| 73 | |
---|
| 74 | - ``max_cpu_time`` |
---|
| 75 | is the maximum amount of CPU execution time consumed |
---|
| 76 | on any execution of the periodic loop. |
---|
| 77 | |
---|
| 78 | - ``total_cpu_time`` |
---|
| 79 | is the total amount of CPU execution time consumed |
---|
| 80 | by executions of the periodic loop. |
---|
| 81 | |
---|
| 82 | - ``min_wall_time`` |
---|
| 83 | is the minimum amount of wall time that passed |
---|
| 84 | on any execution of the periodic loop. |
---|
| 85 | |
---|
| 86 | - ``max_wall_time`` |
---|
| 87 | is the maximum amount of wall time that passed |
---|
| 88 | on any execution of the periodic loop. |
---|
| 89 | |
---|
| 90 | - ``total_wall_time`` |
---|
| 91 | is the total amount of wall time that passed |
---|
| 92 | during executions of the periodic loop. |
---|
| 93 | |
---|
| 94 | Each period is divided into two consecutive phases. The period starts with the |
---|
| 95 | active phase of the task and is followed by the inactive phase of the task. In |
---|
| 96 | the inactive phase the task is blocked and waits for the start of the next |
---|
| 97 | period. The inactive phase is skipped in case of a period miss. The wall time |
---|
| 98 | includes the time during the active phase of the task on which the task is not |
---|
| 99 | executing on a processor. The task is either blocked (for example it waits for |
---|
| 100 | a resource) or a higher priority tasks executes, thus preventing it from |
---|
| 101 | executing. In case the wall time exceeds the period time, then this is a |
---|
| 102 | period miss. The gap between the wall time and the period time is the margin |
---|
| 103 | between a period miss or success. |
---|
| 104 | |
---|
| 105 | The period statistics information is inexpensive to maintain |
---|
| 106 | and can provide very useful insights into the execution |
---|
| 107 | characteristics of a periodic task loop. But it is just information. |
---|
| 108 | The period statistics reported must be analyzed by the user in terms |
---|
| 109 | of what the applications is. For example, in an application where |
---|
| 110 | priorities are assigned by the Rate Monotonic Algorithm, it would |
---|
| 111 | be very undesirable for high priority (i.e. frequency) tasks to |
---|
| 112 | miss their period. Similarly, in nearly any application, if a |
---|
| 113 | task were supposed to execute its periodic loop every 10 milliseconds |
---|
| 114 | and it averaged 11 milliseconds, then application requirements |
---|
| 115 | are not being met. |
---|
| 116 | |
---|
| 117 | The information reported can be used to determine the "hot spots" |
---|
| 118 | in the application. Given a periodâs id, the user can determine |
---|
| 119 | the length of that period. From that information and the CPU usage, |
---|
| 120 | the user can calculate the percentage of CPU time consumed by that |
---|
| 121 | periodic task. For example, a task executing for 20 milliseconds |
---|
| 122 | every 200 milliseconds is consuming 10 percent of the processorâs |
---|
| 123 | execution time. This is usually enough to make it a good candidate |
---|
| 124 | for optimization. |
---|
| 125 | |
---|
| 126 | However, execution time alone is not enough to gauge the value of |
---|
| 127 | optimizing a particular task. It is more important to optimize |
---|
| 128 | a task executing 2 millisecond every 10 milliseconds (20 percent |
---|
| 129 | of the CPU) than one executing 10 milliseconds every 100 (10 percent |
---|
| 130 | of the CPU). As a general rule of thumb, the higher frequency at |
---|
| 131 | which a task executes, the more important it is to optimize that |
---|
| 132 | task. |
---|
| 133 | |
---|
| 134 | Rate Monotonic Manager Definitions |
---|
| 135 | ---------------------------------- |
---|
| 136 | .. index:: periodic task, definition |
---|
| 137 | |
---|
| 138 | A periodic task is one which must be executed at a |
---|
| 139 | regular interval. The interval between successive iterations of |
---|
| 140 | the task is referred to as its period. Periodic tasks can be |
---|
| 141 | characterized by the length of their period and execution time. |
---|
| 142 | The period and execution time of a task can be used to determine |
---|
| 143 | the processor utilization for that task. Processor utilization |
---|
| 144 | is the percentage of processor time used and can be calculated |
---|
| 145 | on a per-task or system-wide basis. Typically, the taskâs |
---|
| 146 | worst-case execution time will be less than its period. For |
---|
| 147 | example, a periodic taskâs requirements may state that it should |
---|
| 148 | execute for 10 milliseconds every 100 milliseconds. Although |
---|
| 149 | the execution time may be the average, worst, or best case, the |
---|
| 150 | worst-case execution time is more appropriate for use when |
---|
| 151 | analyzing system behavior under transient overload conditions... index:: aperiodic task, definition |
---|
| 152 | |
---|
| 153 | In contrast, an aperiodic task executes at irregular |
---|
| 154 | intervals and has only a soft deadline. In other words, the |
---|
| 155 | deadlines for aperiodic tasks are not rigid, but adequate |
---|
| 156 | response times are desirable. For example, an aperiodic task |
---|
| 157 | may process user input from a terminal... index:: sporadic task, definition |
---|
| 158 | |
---|
| 159 | Finally, a sporadic task is an aperiodic task with a |
---|
| 160 | hard deadline and minimum interarrival time. The minimum |
---|
| 161 | interarrival time is the minimum period of time which exists |
---|
| 162 | between successive iterations of the task. For example, a |
---|
| 163 | sporadic task could be used to process the pressing of a fire |
---|
| 164 | button on a joystick. The mechanical action of the fire button |
---|
| 165 | ensures a minimum time period between successive activations, |
---|
| 166 | but the missile must be launched by a hard deadline. |
---|
| 167 | |
---|
| 168 | Rate Monotonic Scheduling Algorithm |
---|
| 169 | ----------------------------------- |
---|
| 170 | .. index:: Rate Monotonic Scheduling Algorithm, definition |
---|
| 171 | .. index:: RMS Algorithm, definition |
---|
| 172 | |
---|
| 173 | The Rate Monotonic Scheduling Algorithm (RMS) is |
---|
| 174 | important to real-time systems designers because it allows one |
---|
| 175 | to guarantee that a set of tasks is schedulable. A set of tasks |
---|
| 176 | is said to be schedulable if all of the tasks can meet their |
---|
| 177 | deadlines. RMS provides a set of rules which can be used to |
---|
| 178 | perform a guaranteed schedulability analysis for a task set. |
---|
| 179 | This analysis determines whether a task set is schedulable under |
---|
| 180 | worst-case conditions and emphasizes the predictability of the |
---|
| 181 | systemâs behavior. It has been proven that: |
---|
| 182 | |
---|
| 183 | - *RMS is an optimal static priority algorithm for |
---|
| 184 | scheduling independent, preemptible, periodic tasks |
---|
| 185 | on a single processor.* |
---|
| 186 | |
---|
| 187 | RMS is optimal in the sense that if a set of tasks |
---|
| 188 | can be scheduled by any static priority algorithm, then RMS will |
---|
| 189 | be able to schedule that task set. RMS bases it schedulability |
---|
| 190 | analysis on the processor utilization level below which all |
---|
| 191 | deadlines can be met. |
---|
| 192 | |
---|
| 193 | RMS calls for the static assignment of task |
---|
| 194 | priorities based upon their period. The shorter a taskâs |
---|
| 195 | period, the higher its priority. For example, a task with a 1 |
---|
| 196 | millisecond period has higher priority than a task with a 100 |
---|
| 197 | millisecond period. If two tasks have the same period, then RMS |
---|
| 198 | does not distinguish between the tasks. However, RTEMS |
---|
| 199 | specifies that when given tasks of equal priority, the task |
---|
| 200 | which has been ready longest will execute first. RMSâs priority |
---|
| 201 | assignment scheme does not provide one with exact numeric values |
---|
| 202 | for task priorities. For example, consider the following task |
---|
| 203 | set and priority assignments. |
---|
| 204 | |
---|
| 205 | +--------------------+---------------------+---------------------+ |
---|
| 206 | | Task | Period | Priority | |
---|
| 207 | | | (in milliseconds) | | |
---|
| 208 | +====================+=====================+=====================+ |
---|
| 209 | | 1 | 100 | Low | |
---|
| 210 | +--------------------+---------------------+---------------------+ |
---|
| 211 | | 2 | 50 | Medium | |
---|
| 212 | +--------------------+---------------------+---------------------+ |
---|
| 213 | | 3 | 50 | Medium | |
---|
| 214 | +--------------------+---------------------+---------------------+ |
---|
| 215 | | 4 | 25 | High | |
---|
| 216 | +--------------------+---------------------+---------------------+ |
---|
| 217 | |
---|
| 218 | RMS only calls for task 1 to have the lowest |
---|
| 219 | priority, task 4 to have the highest priority, and tasks 2 and 3 |
---|
| 220 | to have an equal priority between that of tasks 1 and 4. The |
---|
| 221 | actual RTEMS priorities assigned to the tasks must only adhere |
---|
| 222 | to those guidelines. |
---|
| 223 | |
---|
| 224 | Many applications have tasks with both hard and soft |
---|
| 225 | deadlines. The tasks with hard deadlines are typically referred |
---|
| 226 | to as the critical task set, with the soft deadline tasks being |
---|
| 227 | the non-critical task set. The critical task set can be |
---|
| 228 | scheduled using RMS, with the non-critical tasks not executing |
---|
| 229 | under transient overload, by simply assigning priorities such |
---|
| 230 | that the lowest priority critical task (i.e. longest period) has |
---|
| 231 | a higher priority than the highest priority non-critical task. |
---|
| 232 | Although RMS may be used to assign priorities to the |
---|
| 233 | non-critical tasks, it is not necessary. In this instance, |
---|
| 234 | schedulability is only guaranteed for the critical task set. |
---|
| 235 | |
---|
| 236 | Schedulability Analysis |
---|
| 237 | ----------------------- |
---|
| 238 | |
---|
| 239 | .. index:: RMS schedulability analysis |
---|
| 240 | |
---|
| 241 | RMS allows application designers to ensure that tasks |
---|
| 242 | can meet all deadlines, even under transient overload, without |
---|
| 243 | knowing exactly when any given task will execute by applying |
---|
| 244 | proven schedulability analysis rules. |
---|
| 245 | |
---|
| 246 | Assumptions |
---|
| 247 | ~~~~~~~~~~~ |
---|
| 248 | |
---|
| 249 | The schedulability analysis rules for RMS were |
---|
| 250 | developed based on the following assumptions: |
---|
| 251 | |
---|
| 252 | - The requests for all tasks for which hard deadlines |
---|
| 253 | exist are periodic, with a constant interval between requests. |
---|
| 254 | |
---|
| 255 | - Each task must complete before the next request for it |
---|
| 256 | occurs. |
---|
| 257 | |
---|
| 258 | - The tasks are independent in that a task does not depend |
---|
| 259 | on the initiation or completion of requests for other tasks. |
---|
| 260 | |
---|
| 261 | - The execution time for each task without preemption or |
---|
| 262 | interruption is constant and does not vary. |
---|
| 263 | |
---|
| 264 | - Any non-periodic tasks in the system are special. These |
---|
| 265 | tasks displace periodic tasks while executing and do not have |
---|
| 266 | hard, critical deadlines. |
---|
| 267 | |
---|
| 268 | Once the basic schedulability analysis is understood, |
---|
| 269 | some of the above assumptions can be relaxed and the |
---|
| 270 | side-effects accounted for. |
---|
| 271 | |
---|
| 272 | Processor Utilization Rule |
---|
| 273 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
| 274 | .. index:: RMS Processor Utilization Rule |
---|
| 275 | |
---|
| 276 | The Processor Utilization Rule requires that |
---|
| 277 | processor utilization be calculated based upon the period and |
---|
| 278 | execution time of each task. The fraction of processor time |
---|
| 279 | spent executing task index is Time(index) / Period(index). The |
---|
| 280 | processor utilization can be calculated as follows: |
---|
| 281 | .. code:: c |
---|
| 282 | |
---|
| 283 | Utilization = 0 |
---|
| 284 | for index = 1 to maximum_tasks |
---|
| 285 | Utilization = Utilization + (Time(index)/Period(index)) |
---|
| 286 | |
---|
| 287 | To ensure schedulability even under transient |
---|
| 288 | overload, the processor utilization must adhere to the following |
---|
| 289 | rule: |
---|
| 290 | .. code:: c |
---|
| 291 | |
---|
| 292 | Utilization = maximum_tasks * (2**(1/maximum_tasks) - 1) |
---|
| 293 | |
---|
| 294 | As the number of tasks increases, the above formula |
---|
| 295 | approaches ln(2) for a worst-case utilization factor of |
---|
| 296 | approximately 0.693. Many tasks sets can be scheduled with a |
---|
| 297 | greater utilization factor. In fact, the average processor |
---|
| 298 | utilization threshold for a randomly generated task set is |
---|
| 299 | approximately 0.88. |
---|
| 300 | |
---|
| 301 | Processor Utilization Rule Example |
---|
| 302 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
| 303 | |
---|
| 304 | This example illustrates the application of the |
---|
| 305 | Processor Utilization Rule to an application with three critical |
---|
| 306 | periodic tasks. The following table details the RMS priority, |
---|
| 307 | period, execution time, and processor utilization for each task. |
---|
| 308 | |
---|
| 309 | +------------+----------+--------+-----------+-------------+ |
---|
| 310 | | Tas k | RMS | Period | Execution | Processor | |
---|
| 311 | | | Priority | | Time | Utilization | |
---|
| 312 | +============+==========+========+===========+=============+ |
---|
| 313 | | 1 | High | 100 | 15 | 0.15 | |
---|
| 314 | +------------+----------+--------+-----------+-------------+ |
---|
| 315 | | 2 | Medium | 200 | 50 | 0.25 | |
---|
| 316 | +------------+----------+--------+-----------+-------------+ |
---|
| 317 | | 3 | Low | 300 | 100 | 0.33 | |
---|
| 318 | +------------+----------+--------+-----------+-------------+ |
---|
| 319 | |
---|
| 320 | The total processor utilization for this task set is |
---|
| 321 | 0.73 which is below the upper bound of 3 * (2**(1/3) - 1), or |
---|
| 322 | 0.779, imposed by the Processor Utilization Rule. Therefore, |
---|
| 323 | this task set is guaranteed to be schedulable using RMS. |
---|
| 324 | |
---|
| 325 | First Deadline Rule |
---|
| 326 | ~~~~~~~~~~~~~~~~~~~ |
---|
| 327 | .. index:: RMS First Deadline Rule |
---|
| 328 | |
---|
| 329 | If a given set of tasks do exceed the processor |
---|
| 330 | utilization upper limit imposed by the Processor Utilization |
---|
| 331 | Rule, they can still be guaranteed to meet all their deadlines |
---|
| 332 | by application of the First Deadline Rule. This rule can be |
---|
| 333 | stated as follows: |
---|
| 334 | |
---|
| 335 | For a given set of independent periodic tasks, if |
---|
| 336 | each task meets its first deadline when all tasks are started at |
---|
| 337 | the same time, then the deadlines will always be met for any |
---|
| 338 | combination of start times. |
---|
| 339 | |
---|
| 340 | A key point with this rule is that ALL periodic tasks |
---|
| 341 | are assumed to start at the exact same instant in time. |
---|
| 342 | Although this assumption may seem to be invalid, RTEMS makes it |
---|
| 343 | quite easy to ensure. By having a non-preemptible user |
---|
| 344 | initialization task, all application tasks, regardless of |
---|
| 345 | priority, can be created and started before the initialization |
---|
| 346 | deletes itself. This technique ensures that all tasks begin to |
---|
| 347 | compete for execution time at the same instant â when the user |
---|
| 348 | initialization task deletes itself. |
---|
| 349 | |
---|
| 350 | First Deadline Rule Example |
---|
| 351 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
| 352 | |
---|
| 353 | The First Deadline Rule can ensure schedulability |
---|
| 354 | even when the Processor Utilization Rule fails. The example |
---|
| 355 | below is a modification of the Processor Utilization Rule |
---|
| 356 | example where task execution time has been increased from 15 to |
---|
| 357 | 25 units. The following table details the RMS priority, period, |
---|
| 358 | execution time, and processor utilization for each task: |
---|
| 359 | |
---|
| 360 | |
---|
| 361 | +------------+----------+--------+-----------+-------------+ |
---|
| 362 | | Task | RMS | Period | Execution | Processor | |
---|
| 363 | | | Priority | | Time | Utilization | |
---|
| 364 | +============+==========+========+===========+=============+ |
---|
| 365 | | 1 | High | 100 | 25 | 0.25 | |
---|
| 366 | +------------+----------+--------+-----------+-------------+ |
---|
| 367 | | 2 | Medium | 200 | 50 | 0.25 | |
---|
| 368 | +------------+----------+--------+-----------+-------------+ |
---|
| 369 | | 3 | Low | 300 | 100 | 0.33 | |
---|
| 370 | +------------+----------+--------+-----------+-------------+ |
---|
| 371 | |
---|
| 372 | The total processor utilization for the modified task |
---|
| 373 | set is 0.83 which is above the upper bound of 3 * (2**(1/3) - 1), |
---|
| 374 | or 0.779, imposed by the Processor Utilization Rule. Therefore, |
---|
| 375 | this task set is not guaranteed to be schedulable using RMS. |
---|
| 376 | However, the First Deadline Rule can guarantee the |
---|
| 377 | schedulability of this task set. This rule calls for one to |
---|
| 378 | examine each occurrence of deadline until either all tasks have |
---|
| 379 | met their deadline or one task failed to meet its first |
---|
| 380 | deadline. The following table details the time of each deadline |
---|
| 381 | occurrence, the maximum number of times each task may have run, |
---|
| 382 | the total execution time, and whether all the deadlines have |
---|
| 383 | been met. |
---|
| 384 | |
---|
| 385 | +----------+------+------+------+----------------------+---------------+ |
---|
| 386 | | Deadline | Task | Task | Task | Total | All Deadlines | |
---|
| 387 | | Time | 1 | 2 | 3 | Execution Time | Met? | |
---|
| 388 | +==========+======+======+======+======================+===============+ |
---|
| 389 | | 100 | 1 | 1 | 1 | 25 + 50 + 100 = 175 | NO | |
---|
| 390 | +----------+------+------+------+----------------------+---------------+ |
---|
| 391 | | 200 | 2 | 1 | 1 | 50 + 50 + 100 = 200 | YES | |
---|
| 392 | +----------+------+------+------+----------------------+---------------+ |
---|
| 393 | |
---|
| 394 | The key to this analysis is to recognize when each |
---|
| 395 | task will execute. For example at time 100, task 1 must have |
---|
| 396 | met its first deadline, but tasks 2 and 3 may also have begun |
---|
| 397 | execution. In this example, at time 100 tasks 1 and 2 have |
---|
| 398 | completed execution and thus have met their first deadline. |
---|
| 399 | Tasks 1 and 2 have used (25 + 50) = 75 time units, leaving (100 |
---|
| 400 | - 75) = 25 time units for task 3 to begin. Because task 3 takes |
---|
| 401 | 100 ticks to execute, it will not have completed execution at |
---|
| 402 | time 100. Thus at time 100, all of the tasks except task 3 have |
---|
| 403 | met their first deadline. |
---|
| 404 | |
---|
| 405 | At time 200, task 1 must have met its second deadline |
---|
| 406 | and task 2 its first deadline. As a result, of the first 200 |
---|
| 407 | time units, task 1 uses (2 * 25) = 50 and task 2 uses 50, |
---|
| 408 | leaving (200 - 100) time units for task 3. Task 3 requires 100 |
---|
| 409 | time units to execute, thus it will have completed execution at |
---|
| 410 | time 200. Thus, all of the tasks have met their first deadlines |
---|
| 411 | at time 200, and the task set is schedulable using the First |
---|
| 412 | Deadline Rule. |
---|
| 413 | |
---|
| 414 | Relaxation of Assumptions |
---|
| 415 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
| 416 | |
---|
| 417 | The assumptions used to develop the RMS |
---|
| 418 | schedulability rules are uncommon in most real-time systems. |
---|
| 419 | For example, it was assumed that tasks have constant unvarying |
---|
| 420 | execution time. It is possible to relax this assumption, simply |
---|
| 421 | by using the worst-case execution time of each task. |
---|
| 422 | |
---|
| 423 | Another assumption is that the tasks are independent. |
---|
| 424 | This means that the tasks do not wait for one another or |
---|
| 425 | contend for resources. This assumption can be relaxed by |
---|
| 426 | accounting for the amount of time a task spends waiting to |
---|
| 427 | acquire resources. Similarly, each taskâs execution time must |
---|
| 428 | account for any I/O performed and any RTEMS directive calls. |
---|
| 429 | |
---|
| 430 | In addition, the assumptions did not account for the |
---|
| 431 | time spent executing interrupt service routines. This can be |
---|
| 432 | accounted for by including all the processor utilization by |
---|
| 433 | interrupt service routines in the utilization calculation. |
---|
| 434 | Similarly, one should also account for the impact of delays in |
---|
| 435 | accessing local memory caused by direct memory access and other |
---|
| 436 | processors accessing local dual-ported memory. |
---|
| 437 | |
---|
| 438 | The assumption that nonperiodic tasks are used only |
---|
| 439 | for initialization or failure-recovery can be relaxed by placing |
---|
| 440 | all periodic tasks in the critical task set. This task set can |
---|
| 441 | be scheduled and analyzed using RMS. All nonperiodic tasks are |
---|
| 442 | placed in the non-critical task set. Although the critical task |
---|
| 443 | set can be guaranteed to execute even under transient overload, |
---|
| 444 | the non-critical task set is not guaranteed to execute. |
---|
| 445 | |
---|
| 446 | In conclusion, the application designer must be fully |
---|
| 447 | cognizant of the system and its run-time behavior when |
---|
| 448 | performing schedulability analysis for a system using RMS. |
---|
| 449 | Every hardware and software factor which impacts the execution |
---|
| 450 | time of each task must be accounted for in the schedulability |
---|
| 451 | analysis. |
---|
| 452 | |
---|
| 453 | Further Reading |
---|
| 454 | ~~~~~~~~~~~~~~~ |
---|
| 455 | |
---|
| 456 | For more information on Rate Monotonic Scheduling and |
---|
| 457 | its schedulability analysis, the reader is referred to the |
---|
| 458 | following: |
---|
| 459 | |
---|
| 460 | - *C. L. Liu and J. W. Layland. "Scheduling Algorithms for |
---|
| 461 | Multiprogramming in a Hard Real Time Environment." *Journal of |
---|
| 462 | the Association of Computing Machinery*. January 1973. pp. 46-61.* |
---|
| 463 | |
---|
| 464 | - *John Lehoczky, Lui Sha, and Ye Ding. "The Rate Monotonic |
---|
| 465 | Scheduling Algorithm: Exact Characterization and Average Case |
---|
| 466 | Behavior." *IEEE Real-Time Systems Symposium*. 1989. pp. 166-171.* |
---|
| 467 | |
---|
| 468 | - *Lui Sha and John Goodenough. "Real-Time Scheduling |
---|
| 469 | Theory and Ada." *IEEE Computer*. April 1990. pp. 53-62.* |
---|
| 470 | |
---|
| 471 | - *Alan Burns. "Scheduling hard real-time systems: a |
---|
| 472 | review." *Software Engineering Journal*. May 1991. pp. 116-128.* |
---|
| 473 | |
---|
| 474 | Operations |
---|
| 475 | ========== |
---|
| 476 | |
---|
| 477 | Creating a Rate Monotonic Period |
---|
| 478 | -------------------------------- |
---|
| 479 | |
---|
| 480 | The ``rtems.rate_monotonic_create`` directive creates a rate |
---|
| 481 | monotonic period which is to be used by the calling task to |
---|
| 482 | delineate a period. RTEMS allocates a Period Control Block |
---|
| 483 | (PCB) from the PCB free list. This data structure is used by |
---|
| 484 | RTEMS to manage the newly created rate monotonic period. RTEMS |
---|
| 485 | returns a unique period ID to the application which is used by |
---|
| 486 | other rate monotonic manager directives to access this rate |
---|
| 487 | monotonic period. |
---|
| 488 | |
---|
| 489 | Manipulating a Period |
---|
| 490 | --------------------- |
---|
| 491 | |
---|
| 492 | The ``rtems.rate_monotonic_period`` directive is used to |
---|
| 493 | establish and maintain periodic execution utilizing a previously |
---|
| 494 | created rate monotonic period. Once initiated by the``rtems.rate_monotonic_period`` directive, the period is |
---|
| 495 | said to run until it either expires or is reinitiated. The state of the rate |
---|
| 496 | monotonic period results in one of the following scenarios: |
---|
| 497 | |
---|
| 498 | - If the rate monotonic period is running, the calling |
---|
| 499 | task will be blocked for the remainder of the outstanding period |
---|
| 500 | and, upon completion of that period, the period will be |
---|
| 501 | reinitiated with the specified period. |
---|
| 502 | |
---|
| 503 | - If the rate monotonic period is not currently running |
---|
| 504 | and has not expired, it is initiated with a length of period |
---|
| 505 | ticks and the calling task returns immediately. |
---|
| 506 | |
---|
| 507 | - If the rate monotonic period has expired before the task |
---|
| 508 | invokes the ``rtems.rate_monotonic_period`` directive, |
---|
| 509 | the period will be initiated with a length of period ticks and the calling task |
---|
| 510 | returns immediately with a timeout error status. |
---|
| 511 | |
---|
| 512 | Obtaining the Status of a Period |
---|
| 513 | -------------------------------- |
---|
| 514 | |
---|
| 515 | If the ``rtems.rate_monotonic_period`` directive is invoked |
---|
| 516 | with a period of ``RTEMS.PERIOD_STATUS`` ticks, the current |
---|
| 517 | state of the specified rate monotonic period will be returned. The following |
---|
| 518 | table details the relationship between the periodâs status and |
---|
| 519 | the directive status code returned by the``rtems.rate_monotonic_period`` |
---|
| 520 | directive: |
---|
| 521 | |
---|
| 522 | - ``RTEMS.SUCCESSFUL`` - period is running |
---|
| 523 | |
---|
| 524 | - ``RTEMS.TIMEOUT`` - period has expired |
---|
| 525 | |
---|
| 526 | - ``RTEMS.NOT_DEFINED`` - period has never been initiated |
---|
| 527 | |
---|
| 528 | Obtaining the status of a rate monotonic period does |
---|
| 529 | not alter the state or length of that period. |
---|
| 530 | |
---|
| 531 | Canceling a Period |
---|
| 532 | ------------------ |
---|
| 533 | |
---|
| 534 | The ``rtems.rate_monotonic_cancel`` directive is used to stop |
---|
| 535 | the period maintained by the specified rate monotonic period. |
---|
| 536 | The period is stopped and the rate monotonic period can be |
---|
| 537 | reinitiated using the ``rtems.rate_monotonic_period`` directive. |
---|
| 538 | |
---|
| 539 | Deleting a Rate Monotonic Period |
---|
| 540 | -------------------------------- |
---|
| 541 | |
---|
| 542 | The ``rtems.rate_monotonic_delete`` directive is used to delete |
---|
| 543 | a rate monotonic period. If the period is running and has not |
---|
| 544 | expired, the period is automatically canceled. The rate |
---|
| 545 | monotonic periodâs control block is returned to the PCB free |
---|
| 546 | list when it is deleted. A rate monotonic period can be deleted |
---|
| 547 | by a task other than the task which created the period. |
---|
| 548 | |
---|
| 549 | Examples |
---|
| 550 | -------- |
---|
| 551 | |
---|
| 552 | The following sections illustrate common uses of rate |
---|
| 553 | monotonic periods to construct periodic tasks. |
---|
| 554 | |
---|
| 555 | Simple Periodic Task |
---|
| 556 | -------------------- |
---|
| 557 | |
---|
| 558 | This example consists of a single periodic task |
---|
| 559 | which, after initialization, executes every 100 clock ticks. |
---|
| 560 | .. code:: c |
---|
| 561 | |
---|
| 562 | rtems_task Periodic_task(rtems_task_argument arg) |
---|
| 563 | { |
---|
| 564 | rtems_name name; |
---|
| 565 | rtems_id period; |
---|
| 566 | rtems_status_code status; |
---|
| 567 | name = rtems_build_name( 'P', 'E', 'R', 'D' ); |
---|
| 568 | status = rtems_rate_monotonic_create( name, &period ); |
---|
| 569 | if ( status != RTEMS_STATUS_SUCCESSFUL ) { |
---|
| 570 | printf( "rtems_monotonic_create failed with status of %d.\\n", rc ); |
---|
| 571 | exit( 1 ); |
---|
| 572 | } |
---|
| 573 | while ( 1 ) { |
---|
| 574 | if ( rtems_rate_monotonic_period( period, 100 ) == RTEMS_TIMEOUT ) |
---|
| 575 | break; |
---|
| 576 | /* Perform some periodic actions \*/ |
---|
| 577 | } |
---|
| 578 | /* missed period so delete period and SELF \*/ |
---|
| 579 | status = rtems_rate_monotonic_delete( period ); |
---|
| 580 | if ( status != RTEMS_STATUS_SUCCESSFUL ) { |
---|
| 581 | printf( "rtems_rate_monotonic_delete failed with status of %d.\\n", status ); |
---|
| 582 | exit( 1 ); |
---|
| 583 | } |
---|
| 584 | status = rtems_task_delete( SELF ); /* should not return \*/ |
---|
| 585 | printf( "rtems_task_delete returned with status of %d.\\n", status ); |
---|
| 586 | exit( 1 ); |
---|
| 587 | } |
---|
| 588 | |
---|
| 589 | The above task creates a rate monotonic period as |
---|
| 590 | part of its initialization. The first time the loop is |
---|
| 591 | executed, the ``rtems.rate_monotonic_period`` |
---|
| 592 | directive will initiate the period for 100 ticks and return |
---|
| 593 | immediately. Subsequent invocations of the``rtems.rate_monotonic_period`` directive will result |
---|
| 594 | in the task blocking for the remainder of the 100 tick period. |
---|
| 595 | If, for any reason, the body of the loop takes more than 100 |
---|
| 596 | ticks to execute, the ``rtems.rate_monotonic_period`` |
---|
| 597 | directive will return the ``RTEMS.TIMEOUT`` status. |
---|
| 598 | If the above task misses its deadline, it will delete the rate |
---|
| 599 | monotonic period and itself. |
---|
| 600 | |
---|
| 601 | Task with Multiple Periods |
---|
| 602 | -------------------------- |
---|
| 603 | |
---|
| 604 | This example consists of a single periodic task |
---|
| 605 | which, after initialization, performs two sets of actions every |
---|
| 606 | 100 clock ticks. The first set of actions is performed in the |
---|
| 607 | first forty clock ticks of every 100 clock ticks, while the |
---|
| 608 | second set of actions is performed between the fortieth and |
---|
| 609 | seventieth clock ticks. The last thirty clock ticks are not |
---|
| 610 | used by this task. |
---|
| 611 | .. code:: c |
---|
| 612 | |
---|
| 613 | rtems_task Periodic_task(rtems_task_argument arg) |
---|
| 614 | { |
---|
| 615 | rtems_name name_1, name_2; |
---|
| 616 | rtems_id period_1, period_2; |
---|
| 617 | rtems_status_code status; |
---|
| 618 | name_1 = rtems_build_name( 'P', 'E', 'R', '1' ); |
---|
| 619 | name_2 = rtems_build_name( 'P', 'E', 'R', '2' ); |
---|
| 620 | (void ) rtems_rate_monotonic_create( name_1, &period_1 ); |
---|
| 621 | (void ) rtems_rate_monotonic_create( name_2, &period_2 ); |
---|
| 622 | while ( 1 ) { |
---|
| 623 | if ( rtems_rate_monotonic_period( period_1, 100 ) == TIMEOUT ) |
---|
| 624 | break; |
---|
| 625 | if ( rtems_rate_monotonic_period( period_2, 40 ) == TIMEOUT ) |
---|
| 626 | break; |
---|
| 627 | /* |
---|
| 628 | * Perform first set of actions between clock |
---|
| 629 | * ticks 0 and 39 of every 100 ticks. |
---|
| 630 | \*/ |
---|
| 631 | if ( rtems_rate_monotonic_period( period_2, 30 ) == TIMEOUT ) |
---|
| 632 | break; |
---|
| 633 | /* |
---|
| 634 | * Perform second set of actions between clock 40 and 69 |
---|
| 635 | * of every 100 ticks. THEN ... |
---|
| 636 | * |
---|
| 637 | * Check to make sure we didn't miss the period_2 period. |
---|
| 638 | \*/ |
---|
| 639 | if ( rtems_rate_monotonic_period( period_2, STATUS ) == TIMEOUT ) |
---|
| 640 | break; |
---|
| 641 | (void) rtems_rate_monotonic_cancel( period_2 ); |
---|
| 642 | } |
---|
| 643 | /* missed period so delete period and SELF \*/ |
---|
| 644 | (void ) rtems_rate_monotonic_delete( period_1 ); |
---|
| 645 | (void ) rtems_rate_monotonic_delete( period_2 ); |
---|
| 646 | (void ) task_delete( SELF ); |
---|
| 647 | } |
---|
| 648 | |
---|
| 649 | The above task creates two rate monotonic periods as |
---|
| 650 | part of its initialization. The first time the loop is |
---|
| 651 | executed, the ``rtems.rate_monotonic_period`` |
---|
| 652 | directive will initiate the period_1 period for 100 ticks |
---|
| 653 | and return immediately. Subsequent invocations of the``rtems.rate_monotonic_period`` directive |
---|
| 654 | for period_1 will result in the task blocking for the remainder |
---|
| 655 | of the 100 tick period. The period_2 period is used to control |
---|
| 656 | the execution time of the two sets of actions within each 100 |
---|
| 657 | tick period established by period_1. The``rtems.rate_monotonic_cancel( period_2 )`` |
---|
| 658 | call is performed to ensure that the period_2 period |
---|
| 659 | does not expire while the task is blocked on the period_1 |
---|
| 660 | period. If this cancel operation were not performed, every time |
---|
| 661 | the ``rtems.rate_monotonic_period( period_2, 40 )`` |
---|
| 662 | call is executed, except for the initial one, a directive status |
---|
| 663 | of ``RTEMS.TIMEOUT`` is returned. It is important to |
---|
| 664 | note that every time this call is made, the period_2 period will be |
---|
| 665 | initiated immediately and the task will not block. |
---|
| 666 | |
---|
| 667 | If, for any reason, the task misses any deadline, the``rtems.rate_monotonic_period`` directive will |
---|
| 668 | return the ``RTEMS.TIMEOUT`` |
---|
| 669 | directive status. If the above task misses its deadline, it |
---|
| 670 | will delete the rate monotonic periods and itself. |
---|
| 671 | |
---|
| 672 | Directives |
---|
| 673 | ========== |
---|
| 674 | |
---|
| 675 | This section details the rate monotonic managerâs |
---|
| 676 | directives. A subsection is dedicated to each of this managerâs |
---|
| 677 | directives and describes the calling sequence, related |
---|
| 678 | constants, usage, and status codes. |
---|
| 679 | |
---|
| 680 | RATE_MONOTONIC_CREATE - Create a rate monotonic period |
---|
| 681 | ------------------------------------------------------ |
---|
| 682 | .. index:: create a period |
---|
| 683 | |
---|
| 684 | **CALLING SEQUENCE:** |
---|
| 685 | |
---|
| 686 | .. code:: c |
---|
| 687 | |
---|
| 688 | procedure Rate_Monotonic_Create ( |
---|
| 689 | Name : in RTEMS.Name; |
---|
| 690 | ID : out RTEMS.ID; |
---|
| 691 | Result : out RTEMS.Status_Codes |
---|
| 692 | ); |
---|
| 693 | |
---|
| 694 | **DIRECTIVE STATUS CODES:** |
---|
| 695 | |
---|
| 696 | ``RTEMS.SUCCESSFUL`` - rate monotonic period created successfully |
---|
| 697 | ``RTEMS.INVALID_NAME`` - invalid period name |
---|
| 698 | ``RTEMS.TOO_MANY`` - too many periods created |
---|
| 699 | |
---|
| 700 | **DESCRIPTION:** |
---|
| 701 | |
---|
| 702 | This directive creates a rate monotonic period. The |
---|
| 703 | assigned rate monotonic id is returned in id. This id is used |
---|
| 704 | to access the period with other rate monotonic manager |
---|
| 705 | directives. For control and maintenance of the rate monotonic |
---|
| 706 | period, RTEMS allocates a PCB from the local PCB free pool and |
---|
| 707 | initializes it. |
---|
| 708 | |
---|
| 709 | **NOTES:** |
---|
| 710 | |
---|
| 711 | This directive will not cause the calling task to be |
---|
| 712 | preempted. |
---|
| 713 | |
---|
| 714 | RATE_MONOTONIC_IDENT - Get ID of a period |
---|
| 715 | ----------------------------------------- |
---|
| 716 | .. index:: get ID of a period |
---|
| 717 | .. index:: obtain ID of a period |
---|
| 718 | |
---|
| 719 | **CALLING SEQUENCE:** |
---|
| 720 | |
---|
| 721 | .. code:: c |
---|
| 722 | |
---|
| 723 | procedure Rate_Monotonic_Ident ( |
---|
| 724 | Name : in RTEMS.Name; |
---|
| 725 | ID : out RTEMS.ID; |
---|
| 726 | Result : out RTEMS.Status_Codes |
---|
| 727 | ); |
---|
| 728 | |
---|
| 729 | **DIRECTIVE STATUS CODES:** |
---|
| 730 | |
---|
| 731 | ``RTEMS.SUCCESSFUL`` - period identified successfully |
---|
| 732 | ``RTEMS.INVALID_NAME`` - period name not found |
---|
| 733 | |
---|
| 734 | **DESCRIPTION:** |
---|
| 735 | |
---|
| 736 | This directive obtains the period id associated with |
---|
| 737 | the period name to be acquired. If the period name is not |
---|
| 738 | unique, then the period id will match one of the periods with |
---|
| 739 | that name. However, this period id is not guaranteed to |
---|
| 740 | correspond to the desired period. The period id is used to |
---|
| 741 | access this period in other rate monotonic manager directives. |
---|
| 742 | |
---|
| 743 | **NOTES:** |
---|
| 744 | |
---|
| 745 | This directive will not cause the running task to be |
---|
| 746 | preempted. |
---|
| 747 | |
---|
| 748 | RATE_MONOTONIC_CANCEL - Cancel a period |
---|
| 749 | --------------------------------------- |
---|
| 750 | .. index:: cancel a period |
---|
| 751 | |
---|
| 752 | **CALLING SEQUENCE:** |
---|
| 753 | |
---|
| 754 | .. code:: c |
---|
| 755 | |
---|
| 756 | procedure Rate_Monotonic_Cancel ( |
---|
| 757 | ID : in RTEMS.ID; |
---|
| 758 | Result : out RTEMS.Status_Codes |
---|
| 759 | ); |
---|
| 760 | |
---|
| 761 | **DIRECTIVE STATUS CODES:** |
---|
| 762 | |
---|
| 763 | ``RTEMS.SUCCESSFUL`` - period canceled successfully |
---|
| 764 | ``RTEMS.INVALID_ID`` - invalid rate monotonic period id |
---|
| 765 | ``RTEMS.NOT_OWNER_OF_RESOURCE`` - rate monotonic period not created by calling task |
---|
| 766 | |
---|
| 767 | **DESCRIPTION:** |
---|
| 768 | |
---|
| 769 | This directive cancels the rate monotonic period id. |
---|
| 770 | This period will be reinitiated by the next invocation of``rtems.rate_monotonic_period`` with id. |
---|
| 771 | |
---|
| 772 | **NOTES:** |
---|
| 773 | |
---|
| 774 | This directive will not cause the running task to be |
---|
| 775 | preempted. |
---|
| 776 | |
---|
| 777 | The rate monotonic period specified by id must have |
---|
| 778 | been created by the calling task. |
---|
| 779 | |
---|
| 780 | RATE_MONOTONIC_DELETE - Delete a rate monotonic period |
---|
| 781 | ------------------------------------------------------ |
---|
| 782 | .. index:: delete a period |
---|
| 783 | |
---|
| 784 | **CALLING SEQUENCE:** |
---|
| 785 | |
---|
| 786 | .. code:: c |
---|
| 787 | |
---|
| 788 | procedure Rate_Monotonic_Delete ( |
---|
| 789 | ID : in RTEMS.ID; |
---|
| 790 | Result : out RTEMS.Status_Codes |
---|
| 791 | ); |
---|
| 792 | |
---|
| 793 | **DIRECTIVE STATUS CODES:** |
---|
| 794 | |
---|
| 795 | ``RTEMS.SUCCESSFUL`` - period deleted successfully |
---|
| 796 | ``RTEMS.INVALID_ID`` - invalid rate monotonic period id |
---|
| 797 | |
---|
| 798 | **DESCRIPTION:** |
---|
| 799 | |
---|
| 800 | This directive deletes the rate monotonic period |
---|
| 801 | specified by id. If the period is running, it is automatically |
---|
| 802 | canceled. The PCB for the deleted period is reclaimed by RTEMS. |
---|
| 803 | |
---|
| 804 | **NOTES:** |
---|
| 805 | |
---|
| 806 | This directive will not cause the running task to be |
---|
| 807 | preempted. |
---|
| 808 | |
---|
| 809 | A rate monotonic period can be deleted by a task |
---|
| 810 | other than the task which created the period. |
---|
| 811 | |
---|
| 812 | RATE_MONOTONIC_PERIOD - Conclude current/Start next period |
---|
| 813 | ---------------------------------------------------------- |
---|
| 814 | .. index:: conclude current period |
---|
| 815 | .. index:: start current period |
---|
| 816 | .. index:: period initiation |
---|
| 817 | |
---|
| 818 | **CALLING SEQUENCE:** |
---|
| 819 | |
---|
| 820 | .. code:: c |
---|
| 821 | |
---|
| 822 | procedure Rate_Monotonic_Period ( |
---|
| 823 | ID : in RTEMS.ID; |
---|
| 824 | Length : in RTEMS.Interval; |
---|
| 825 | Result : out RTEMS.Status_Codes |
---|
| 826 | ); |
---|
| 827 | |
---|
| 828 | **DIRECTIVE STATUS CODES:** |
---|
| 829 | |
---|
| 830 | ``RTEMS.SUCCESSFUL`` - period initiated successfully |
---|
| 831 | ``RTEMS.INVALID_ID`` - invalid rate monotonic period id |
---|
| 832 | ``RTEMS.NOT_OWNER_OF_RESOURCE`` - period not created by calling task |
---|
| 833 | ``RTEMS.NOT_DEFINED`` - period has never been initiated (only |
---|
| 834 | possible when period is set to PERIOD_STATUS) |
---|
| 835 | ``RTEMS.TIMEOUT`` - period has expired |
---|
| 836 | |
---|
| 837 | **DESCRIPTION:** |
---|
| 838 | |
---|
| 839 | This directive initiates the rate monotonic period id |
---|
| 840 | with a length of period ticks. If id is running, then the |
---|
| 841 | calling task will block for the remainder of the period before |
---|
| 842 | reinitiating the period with the specified period. If id was |
---|
| 843 | not running (either expired or never initiated), the period is |
---|
| 844 | immediately initiated and the directive returns immediately. |
---|
| 845 | |
---|
| 846 | If invoked with a period of ``RTEMS.PERIOD_STATUS`` ticks, the |
---|
| 847 | current state of id will be returned. The directive status |
---|
| 848 | indicates the current state of the period. This does not alter |
---|
| 849 | the state or period of the period. |
---|
| 850 | |
---|
| 851 | **NOTES:** |
---|
| 852 | |
---|
| 853 | This directive will not cause the running task to be preempted. |
---|
| 854 | |
---|
| 855 | RATE_MONOTONIC_GET_STATUS - Obtain status from a period |
---|
| 856 | ------------------------------------------------------- |
---|
| 857 | .. index:: get status of period |
---|
| 858 | .. index:: obtain status of period |
---|
| 859 | |
---|
| 860 | **CALLING SEQUENCE:** |
---|
| 861 | |
---|
| 862 | .. code:: c |
---|
| 863 | |
---|
| 864 | procedure Rate_Monotonic_Get_Status ( |
---|
| 865 | ID : in RTEMS.ID; |
---|
| 866 | Status : out RTEMS.Rate_Monotonic_Period_Status; |
---|
| 867 | Result : out RTEMS.Status_Codes |
---|
| 868 | ); |
---|
| 869 | |
---|
| 870 | **DIRECTIVE STATUS CODES:** |
---|
| 871 | |
---|
| 872 | ``RTEMS.SUCCESSFUL`` - period initiated successfully |
---|
| 873 | ``RTEMS.INVALID_ID`` - invalid rate monotonic period id |
---|
| 874 | ``RTEMS.INVALID_ADDRESS`` - invalid address of status |
---|
| 875 | |
---|
| 876 | **DESCRIPTION:** |
---|
| 877 | |
---|
| 878 | This directive returns status information associated with |
---|
| 879 | the rate monotonic period id in the following data record: |
---|
| 880 | |
---|
| 881 | .. code:: c |
---|
| 882 | |
---|
| 883 | type Rate_Monotonic_Period_Status is |
---|
| 884 | begin |
---|
| 885 | Owner : RTEMS.ID; |
---|
| 886 | State : RTEMS.Rate_Monotonic_Period_States; |
---|
| 887 | Since_Last_Period : RTEMS.Unsigned32; |
---|
| 888 | Executed_Since_Last_Period : RTEMS.Unsigned32; |
---|
| 889 | end record; |
---|
| 890 | |
---|
| 891 | .. COMMENT: RATE_MONOTONIC_INACTIVE does not have RTEMS_ in front of it. |
---|
| 892 | |
---|
| 893 | A configure time option can be used to select whether the time information is |
---|
| 894 | given in ticks or seconds and nanoseconds. The default is seconds and |
---|
| 895 | nanoseconds. If the periodâs state is ``RATE_MONOTONIC_INACTIVE``, both |
---|
| 896 | time values will be set to 0. Otherwise, both time values will contain |
---|
| 897 | time information since the last invocation of the``rtems.rate_monotonic_period`` directive. More |
---|
| 898 | specifically, the ticks_since_last_period value contains the elapsed time |
---|
| 899 | which has occurred since the last invocation of the``rtems.rate_monotonic_period`` directive and the |
---|
| 900 | ticks_executed_since_last_period contains how much processor time the |
---|
| 901 | owning task has consumed since the invocation of the``rtems.rate_monotonic_period`` directive. |
---|
| 902 | |
---|
| 903 | **NOTES:** |
---|
| 904 | |
---|
| 905 | This directive will not cause the running task to be preempted. |
---|
| 906 | |
---|
| 907 | RATE_MONOTONIC_GET_STATISTICS - Obtain statistics from a period |
---|
| 908 | --------------------------------------------------------------- |
---|
| 909 | .. index:: get statistics of period |
---|
| 910 | .. index:: obtain statistics of period |
---|
| 911 | |
---|
| 912 | **CALLING SEQUENCE:** |
---|
| 913 | |
---|
| 914 | .. code:: c |
---|
| 915 | |
---|
| 916 | NOT SUPPORTED FROM Ada BINDING |
---|
| 917 | |
---|
| 918 | **DIRECTIVE STATUS CODES:** |
---|
| 919 | |
---|
| 920 | ``RTEMS.SUCCESSFUL`` - period initiated successfully |
---|
| 921 | ``RTEMS.INVALID_ID`` - invalid rate monotonic period id |
---|
| 922 | ``RTEMS.INVALID_ADDRESS`` - invalid address of statistics |
---|
| 923 | |
---|
| 924 | **DESCRIPTION:** |
---|
| 925 | |
---|
| 926 | This directive returns statistics information associated with |
---|
| 927 | the rate monotonic period id in the following data record: |
---|
| 928 | |
---|
| 929 | .. code:: c |
---|
| 930 | |
---|
| 931 | NOT SUPPORTED FROM Ada BINDING |
---|
| 932 | |
---|
| 933 | This directive returns the current statistics information for |
---|
| 934 | the period instance assocaited with ``id``. The information |
---|
| 935 | returned is indicated by the structure above. |
---|
| 936 | |
---|
| 937 | **NOTES:** |
---|
| 938 | |
---|
| 939 | This directive will not cause the running task to be preempted. |
---|
| 940 | |
---|
| 941 | RATE_MONOTONIC_RESET_STATISTICS - Reset statistics for a period |
---|
| 942 | --------------------------------------------------------------- |
---|
| 943 | .. index:: reset statistics of period |
---|
| 944 | |
---|
| 945 | **CALLING SEQUENCE:** |
---|
| 946 | |
---|
| 947 | .. code:: c |
---|
| 948 | |
---|
| 949 | procedure Rate_Monotonic_Reset_Statistics ( |
---|
| 950 | ID : in RTEMS.ID; |
---|
| 951 | Result : out RTEMS.Status_Codes |
---|
| 952 | ); |
---|
| 953 | |
---|
| 954 | **DIRECTIVE STATUS CODES:** |
---|
| 955 | |
---|
| 956 | ``RTEMS.SUCCESSFUL`` - period initiated successfully |
---|
| 957 | ``RTEMS.INVALID_ID`` - invalid rate monotonic period id |
---|
| 958 | |
---|
| 959 | **DESCRIPTION:** |
---|
| 960 | |
---|
| 961 | This directive resets the statistics information associated with |
---|
| 962 | this rate monotonic period instance. |
---|
| 963 | |
---|
| 964 | **NOTES:** |
---|
| 965 | |
---|
| 966 | This directive will not cause the running task to be preempted. |
---|
| 967 | |
---|
| 968 | RATE_MONOTONIC_RESET_ALL_STATISTICS - Reset statistics for all periods |
---|
| 969 | ---------------------------------------------------------------------- |
---|
| 970 | .. index:: reset statistics of all periods |
---|
| 971 | |
---|
| 972 | **CALLING SEQUENCE:** |
---|
| 973 | |
---|
| 974 | .. code:: c |
---|
| 975 | |
---|
| 976 | procedure Rate_Monotonic_Reset_All_Statistics; |
---|
| 977 | |
---|
| 978 | **DIRECTIVE STATUS CODES:** |
---|
| 979 | |
---|
| 980 | NONE |
---|
| 981 | |
---|
| 982 | **DESCRIPTION:** |
---|
| 983 | |
---|
| 984 | This directive resets the statistics information associated with |
---|
| 985 | all rate monotonic period instances. |
---|
| 986 | |
---|
| 987 | **NOTES:** |
---|
| 988 | |
---|
| 989 | This directive will not cause the running task to be preempted. |
---|
| 990 | |
---|
| 991 | RATE_MONOTONIC_REPORT_STATISTICS - Print period statistics report |
---|
| 992 | ----------------------------------------------------------------- |
---|
| 993 | .. index:: print period statistics report |
---|
| 994 | .. index:: period statistics report |
---|
| 995 | |
---|
| 996 | **CALLING SEQUENCE:** |
---|
| 997 | |
---|
| 998 | .. code:: c |
---|
| 999 | |
---|
| 1000 | procedure Rate_Monotonic_Report_Statistics; |
---|
| 1001 | |
---|
| 1002 | **DIRECTIVE STATUS CODES:** |
---|
| 1003 | |
---|
| 1004 | NONE |
---|
| 1005 | |
---|
| 1006 | **DESCRIPTION:** |
---|
| 1007 | |
---|
| 1008 | This directive prints a report on all active periods which have |
---|
| 1009 | executed at least one period. The following is an example of the |
---|
| 1010 | output generated by this directive. |
---|
| 1011 | |
---|
| 1012 | **NOTES:** |
---|
| 1013 | |
---|
| 1014 | This directive will not cause the running task to be preempted. |
---|
| 1015 | |
---|
| 1016 | .. COMMENT: COPYRIGHT (c) 1988-2007. |
---|
| 1017 | |
---|
| 1018 | .. COMMENT: On-Line Applications Research Corporation (OAR). |
---|
| 1019 | |
---|
| 1020 | .. COMMENT: All rights reserved. |
---|
| 1021 | |
---|