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 | |
---|