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 | +------------+----------+--------+-----------+-------------+ |
---|
311 | | Tas k | RMS | Period | Execution | Processor | |
---|
312 | | | Priority | | Time | Utilization | |
---|
313 | +============+==========+========+===========+=============+ |
---|
314 | | 1 | High | 100 | 15 | 0.15 | |
---|
315 | +------------+----------+--------+-----------+-------------+ |
---|
316 | | 2 | Medium | 200 | 50 | 0.25 | |
---|
317 | +------------+----------+--------+-----------+-------------+ |
---|
318 | | 3 | Low | 300 | 100 | 0.33 | |
---|
319 | +------------+----------+--------+-----------+-------------+ |
---|
320 | |
---|
321 | The total processor utilization for this task set is |
---|
322 | 0.73 which is below the upper bound of 3 * (2**(1/3) - 1), or |
---|
323 | 0.779, imposed by the Processor Utilization Rule. Therefore, |
---|
324 | this task set is guaranteed to be schedulable using RMS. |
---|
325 | |
---|
326 | First Deadline Rule |
---|
327 | ~~~~~~~~~~~~~~~~~~~ |
---|
328 | .. index:: RMS First Deadline Rule |
---|
329 | |
---|
330 | If a given set of tasks do exceed the processor |
---|
331 | utilization upper limit imposed by the Processor Utilization |
---|
332 | Rule, they can still be guaranteed to meet all their deadlines |
---|
333 | by application of the First Deadline Rule. This rule can be |
---|
334 | stated as follows: |
---|
335 | |
---|
336 | For a given set of independent periodic tasks, if |
---|
337 | each task meets its first deadline when all tasks are started at |
---|
338 | the same time, then the deadlines will always be met for any |
---|
339 | combination of start times. |
---|
340 | |
---|
341 | A key point with this rule is that ALL periodic tasks |
---|
342 | are assumed to start at the exact same instant in time. |
---|
343 | Although this assumption may seem to be invalid, RTEMS makes it |
---|
344 | quite easy to ensure. By having a non-preemptible user |
---|
345 | initialization task, all application tasks, regardless of |
---|
346 | priority, can be created and started before the initialization |
---|
347 | deletes itself. This technique ensures that all tasks begin to |
---|
348 | compete for execution time at the same instant - when the user |
---|
349 | initialization task deletes itself. |
---|
350 | |
---|
351 | First Deadline Rule Example |
---|
352 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
353 | |
---|
354 | The First Deadline Rule can ensure schedulability |
---|
355 | even when the Processor Utilization Rule fails. The example |
---|
356 | below is a modification of the Processor Utilization Rule |
---|
357 | example where task execution time has been increased from 15 to |
---|
358 | 25 units. The following table details the RMS priority, period, |
---|
359 | execution time, and processor utilization for each task: |
---|
360 | .. code:: c |
---|
361 | |
---|
362 | +------------+----------+--------+-----------+-------------+ |
---|
363 | | Task | RMS | Period | Execution | Processor | |
---|
364 | | | Priority | | Time | Utilization | |
---|
365 | +============+==========+========+===========+=============+ |
---|
366 | | 1 | High | 100 | 25 | 0.25 | |
---|
367 | +------------+----------+--------+-----------+-------------+ |
---|
368 | | 2 | Medium | 200 | 50 | 0.25 | |
---|
369 | +------------+----------+--------+-----------+-------------+ |
---|
370 | | 3 | Low | 300 | 100 | 0.33 | |
---|
371 | +------------+----------+--------+-----------+-------------+ |
---|
372 | |
---|
373 | The total processor utilization for the modified task |
---|
374 | set is 0.83 which is above the upper bound of 3 * (2**(1/3) - 1), |
---|
375 | or 0.779, imposed by the Processor Utilization Rule. Therefore, |
---|
376 | this task set is not guaranteed to be schedulable using RMS. |
---|
377 | However, the First Deadline Rule can guarantee the |
---|
378 | schedulability of this task set. This rule calls for one to |
---|
379 | examine each occurrence of deadline until either all tasks have |
---|
380 | met their deadline or one task failed to meet its first |
---|
381 | deadline. The following table details the time of each deadline |
---|
382 | occurrence, the maximum number of times each task may have run, |
---|
383 | the total execution time, and whether all the deadlines have |
---|
384 | been met. |
---|
385 | .. code:: c |
---|
386 | |
---|
387 | +----------+------+------+------+----------------------+---------------+ |
---|
388 | | Deadline | Task | Task | Task | Total | All Deadlines | |
---|
389 | | Time | 1 | 2 | 3 | Execution Time | Met? | |
---|
390 | +==========+======+======+======+======================+===============+ |
---|
391 | | 100 | 1 | 1 | 1 | 25 + 50 + 100 = 175 | NO | |
---|
392 | +----------+------+------+------+----------------------+---------------+ |
---|
393 | | 200 | 2 | 1 | 1 | 50 + 50 + 100 = 200 | YES | |
---|
394 | +----------+------+------+------+----------------------+---------------+ |
---|
395 | |
---|
396 | The key to this analysis is to recognize when each |
---|
397 | task will execute. For example at time 100, task 1 must have |
---|
398 | met its first deadline, but tasks 2 and 3 may also have begun |
---|
399 | execution. In this example, at time 100 tasks 1 and 2 have |
---|
400 | completed execution and thus have met their first deadline. |
---|
401 | Tasks 1 and 2 have used (25 + 50) = 75 time units, leaving (100 |
---|
402 | - 75) = 25 time units for task 3 to begin. Because task 3 takes |
---|
403 | 100 ticks to execute, it will not have completed execution at |
---|
404 | time 100. Thus at time 100, all of the tasks except task 3 have |
---|
405 | met their first deadline. |
---|
406 | |
---|
407 | At time 200, task 1 must have met its second deadline |
---|
408 | and task 2 its first deadline. As a result, of the first 200 |
---|
409 | time units, task 1 uses (2 * 25) = 50 and task 2 uses 50, |
---|
410 | leaving (200 - 100) time units for task 3. Task 3 requires 100 |
---|
411 | time units to execute, thus it will have completed execution at |
---|
412 | time 200. Thus, all of the tasks have met their first deadlines |
---|
413 | at time 200, and the task set is schedulable using the First |
---|
414 | Deadline Rule. |
---|
415 | |
---|
416 | Relaxation of Assumptions |
---|
417 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
418 | |
---|
419 | The assumptions used to develop the RMS |
---|
420 | schedulability rules are uncommon in most real-time systems. |
---|
421 | For example, it was assumed that tasks have constant unvarying |
---|
422 | execution time. It is possible to relax this assumption, simply |
---|
423 | by using the worst-case execution time of each task. |
---|
424 | |
---|
425 | Another assumption is that the tasks are independent. |
---|
426 | This means that the tasks do not wait for one another or |
---|
427 | contend for resources. This assumption can be relaxed by |
---|
428 | accounting for the amount of time a task spends waiting to |
---|
429 | acquire resources. Similarly, each task's execution time must |
---|
430 | account for any I/O performed and any RTEMS directive calls. |
---|
431 | |
---|
432 | In addition, the assumptions did not account for the |
---|
433 | time spent executing interrupt service routines. This can be |
---|
434 | accounted for by including all the processor utilization by |
---|
435 | interrupt service routines in the utilization calculation. |
---|
436 | Similarly, one should also account for the impact of delays in |
---|
437 | accessing local memory caused by direct memory access and other |
---|
438 | processors accessing local dual-ported memory. |
---|
439 | |
---|
440 | The assumption that nonperiodic tasks are used only |
---|
441 | for initialization or failure-recovery can be relaxed by placing |
---|
442 | all periodic tasks in the critical task set. This task set can |
---|
443 | be scheduled and analyzed using RMS. All nonperiodic tasks are |
---|
444 | placed in the non-critical task set. Although the critical task |
---|
445 | set can be guaranteed to execute even under transient overload, |
---|
446 | the non-critical task set is not guaranteed to execute. |
---|
447 | |
---|
448 | In conclusion, the application designer must be fully |
---|
449 | cognizant of the system and its run-time behavior when |
---|
450 | performing schedulability analysis for a system using RMS. |
---|
451 | Every hardware and software factor which impacts the execution |
---|
452 | time of each task must be accounted for in the schedulability |
---|
453 | analysis. |
---|
454 | |
---|
455 | Further Reading |
---|
456 | ~~~~~~~~~~~~~~~ |
---|
457 | |
---|
458 | For more information on Rate Monotonic Scheduling and |
---|
459 | its schedulability analysis, the reader is referred to the |
---|
460 | following: |
---|
461 | |
---|
462 | - *C. L. Liu and J. W. Layland. "Scheduling Algorithms for |
---|
463 | Multiprogramming in a Hard Real Time Environment." *Journal of |
---|
464 | the Association of Computing Machinery*. January 1973. pp. 46-61.* |
---|
465 | |
---|
466 | - *John Lehoczky, Lui Sha, and Ye Ding. "The Rate Monotonic |
---|
467 | Scheduling Algorithm: Exact Characterization and Average Case |
---|
468 | Behavior." *IEEE Real-Time Systems Symposium*. 1989. pp. 166-171.* |
---|
469 | |
---|
470 | - *Lui Sha and John Goodenough. "Real-Time Scheduling |
---|
471 | theory and Ada." *IEEE Computer*. April 1990. pp. 53-62.* |
---|
472 | |
---|
473 | - *Alan Burns. "Scheduling hard real-time systems: a |
---|
474 | review." *Software Engineering Journal*. May 1991. pp. 116-128.* |
---|
475 | |
---|
476 | Operations |
---|
477 | ========== |
---|
478 | |
---|
479 | Creating a Rate Monotonic Period |
---|
480 | -------------------------------- |
---|
481 | |
---|
482 | The ``rtems_rate_monotonic_create`` directive creates a rate |
---|
483 | monotonic period which is to be used by the calling task to |
---|
484 | delineate a period. RTEMS allocates a Period Control Block |
---|
485 | (PCB) from the PCB free list. This data structure is used by |
---|
486 | RTEMS to manage the newly created rate monotonic period. RTEMS |
---|
487 | returns a unique period ID to the application which is used by |
---|
488 | other rate monotonic manager directives to access this rate |
---|
489 | monotonic period. |
---|
490 | |
---|
491 | Manipulating a Period |
---|
492 | --------------------- |
---|
493 | |
---|
494 | The ``rtems_rate_monotonic_period`` directive is used to |
---|
495 | establish and maintain periodic execution utilizing a previously |
---|
496 | created rate monotonic period. Once initiated by the``rtems_rate_monotonic_period`` directive, the period is |
---|
497 | said to run until it either expires or is reinitiated. The state of the rate |
---|
498 | monotonic period results in one of the following scenarios: |
---|
499 | |
---|
500 | - If the rate monotonic period is running, the calling |
---|
501 | task will be blocked for the remainder of the outstanding period |
---|
502 | and, upon completion of that period, the period will be |
---|
503 | reinitiated with the specified period. |
---|
504 | |
---|
505 | - If the rate monotonic period is not currently running |
---|
506 | and has not expired, it is initiated with a length of period |
---|
507 | ticks and the calling task returns immediately. |
---|
508 | |
---|
509 | - If the rate monotonic period has expired before the task |
---|
510 | invokes the ``rtems_rate_monotonic_period`` directive, |
---|
511 | the period will be initiated with a length of period ticks and the calling task |
---|
512 | returns immediately with a timeout error status. |
---|
513 | |
---|
514 | Obtaining the Status of a Period |
---|
515 | -------------------------------- |
---|
516 | |
---|
517 | If the ``rtems_rate_monotonic_period`` directive is invoked |
---|
518 | with a period of ``RTEMS_PERIOD_STATUS`` ticks, the current |
---|
519 | state of the specified rate monotonic period will be returned. The following |
---|
520 | table details the relationship between the period's status and |
---|
521 | the directive status code returned by the``rtems_rate_monotonic_period`` |
---|
522 | directive: |
---|
523 | |
---|
524 | - ``RTEMS_SUCCESSFUL`` - period is running |
---|
525 | |
---|
526 | - ``RTEMS_TIMEOUT`` - period has expired |
---|
527 | |
---|
528 | - ``RTEMS_NOT_DEFINED`` - period has never been initiated |
---|
529 | |
---|
530 | Obtaining the status of a rate monotonic period does |
---|
531 | not alter the state or length of that period. |
---|
532 | |
---|
533 | Canceling a Period |
---|
534 | ------------------ |
---|
535 | |
---|
536 | The ``rtems_rate_monotonic_cancel`` directive is used to stop |
---|
537 | the period maintained by the specified rate monotonic period. |
---|
538 | The period is stopped and the rate monotonic period can be |
---|
539 | reinitiated using the ``rtems_rate_monotonic_period`` directive. |
---|
540 | |
---|
541 | Deleting a Rate Monotonic Period |
---|
542 | -------------------------------- |
---|
543 | |
---|
544 | The ``rtems_rate_monotonic_delete`` directive is used to delete |
---|
545 | a rate monotonic period. If the period is running and has not |
---|
546 | expired, the period is automatically canceled. The rate |
---|
547 | monotonic period's control block is returned to the PCB free |
---|
548 | list when it is deleted. A rate monotonic period can be deleted |
---|
549 | by a task other than the task which created the period. |
---|
550 | |
---|
551 | Examples |
---|
552 | -------- |
---|
553 | |
---|
554 | The following sections illustrate common uses of rate |
---|
555 | monotonic periods to construct periodic tasks. |
---|
556 | |
---|
557 | Simple Periodic Task |
---|
558 | -------------------- |
---|
559 | |
---|
560 | This example consists of a single periodic task |
---|
561 | which, after initialization, executes every 100 clock ticks. |
---|
562 | .. code:: c |
---|
563 | |
---|
564 | rtems_task Periodic_task(rtems_task_argument arg) |
---|
565 | { |
---|
566 | rtems_name name; |
---|
567 | rtems_id period; |
---|
568 | rtems_status_code status; |
---|
569 | name = rtems_build_name( 'P', 'E', 'R', 'D' ); |
---|
570 | status = rtems_rate_monotonic_create( name, &period ); |
---|
571 | if ( status != RTEMS_STATUS_SUCCESSFUL ) { |
---|
572 | printf( "rtems_monotonic_create failed with status of %d.\\n", rc ); |
---|
573 | exit( 1 ); |
---|
574 | } |
---|
575 | while ( 1 ) { |
---|
576 | if ( rtems_rate_monotonic_period( period, 100 ) == RTEMS_TIMEOUT ) |
---|
577 | break; |
---|
578 | /* Perform some periodic actions \*/ |
---|
579 | } |
---|
580 | /* missed period so delete period and SELF \*/ |
---|
581 | status = rtems_rate_monotonic_delete( period ); |
---|
582 | if ( status != RTEMS_STATUS_SUCCESSFUL ) { |
---|
583 | printf( "rtems_rate_monotonic_delete failed with status of %d.\\n", status ); |
---|
584 | exit( 1 ); |
---|
585 | } |
---|
586 | status = rtems_task_delete( SELF ); /* should not return \*/ |
---|
587 | printf( "rtems_task_delete returned with status of %d.\\n", status ); |
---|
588 | exit( 1 ); |
---|
589 | } |
---|
590 | |
---|
591 | The above task creates a rate monotonic period as |
---|
592 | part of its initialization. The first time the loop is |
---|
593 | executed, the ``rtems_rate_monotonic_period`` |
---|
594 | directive will initiate the period for 100 ticks and return |
---|
595 | immediately. Subsequent invocations of the``rtems_rate_monotonic_period`` directive will result |
---|
596 | in the task blocking for the remainder of the 100 tick period. |
---|
597 | If, for any reason, the body of the loop takes more than 100 |
---|
598 | ticks to execute, the ``rtems_rate_monotonic_period`` |
---|
599 | directive will return the ``RTEMS_TIMEOUT`` status. |
---|
600 | If the above task misses its deadline, it will delete the rate |
---|
601 | monotonic period and itself. |
---|
602 | |
---|
603 | Task with Multiple Periods |
---|
604 | -------------------------- |
---|
605 | |
---|
606 | This example consists of a single periodic task |
---|
607 | which, after initialization, performs two sets of actions every |
---|
608 | 100 clock ticks. The first set of actions is performed in the |
---|
609 | first forty clock ticks of every 100 clock ticks, while the |
---|
610 | second set of actions is performed between the fortieth and |
---|
611 | seventieth clock ticks. The last thirty clock ticks are not |
---|
612 | used by this task. |
---|
613 | .. code:: c |
---|
614 | |
---|
615 | rtems_task Periodic_task(rtems_task_argument arg) |
---|
616 | { |
---|
617 | rtems_name name_1, name_2; |
---|
618 | rtems_id period_1, period_2; |
---|
619 | rtems_status_code status; |
---|
620 | name_1 = rtems_build_name( 'P', 'E', 'R', '1' ); |
---|
621 | name_2 = rtems_build_name( 'P', 'E', 'R', '2' ); |
---|
622 | (void ) rtems_rate_monotonic_create( name_1, &period_1 ); |
---|
623 | (void ) rtems_rate_monotonic_create( name_2, &period_2 ); |
---|
624 | while ( 1 ) { |
---|
625 | if ( rtems_rate_monotonic_period( period_1, 100 ) == TIMEOUT ) |
---|
626 | break; |
---|
627 | if ( rtems_rate_monotonic_period( period_2, 40 ) == TIMEOUT ) |
---|
628 | break; |
---|
629 | /* |
---|
630 | * Perform first set of actions between clock |
---|
631 | * ticks 0 and 39 of every 100 ticks. |
---|
632 | \*/ |
---|
633 | if ( rtems_rate_monotonic_period( period_2, 30 ) == TIMEOUT ) |
---|
634 | break; |
---|
635 | /* |
---|
636 | * Perform second set of actions between clock 40 and 69 |
---|
637 | * of every 100 ticks. THEN ... |
---|
638 | * |
---|
639 | * Check to make sure we didn't miss the period_2 period. |
---|
640 | \*/ |
---|
641 | if ( rtems_rate_monotonic_period( period_2, STATUS ) == TIMEOUT ) |
---|
642 | break; |
---|
643 | (void) rtems_rate_monotonic_cancel( period_2 ); |
---|
644 | } |
---|
645 | /* missed period so delete period and SELF \*/ |
---|
646 | (void ) rtems_rate_monotonic_delete( period_1 ); |
---|
647 | (void ) rtems_rate_monotonic_delete( period_2 ); |
---|
648 | (void ) task_delete( SELF ); |
---|
649 | } |
---|
650 | |
---|
651 | The above task creates two rate monotonic periods as |
---|
652 | part of its initialization. The first time the loop is |
---|
653 | executed, the ``rtems_rate_monotonic_period`` |
---|
654 | directive will initiate the period_1 period for 100 ticks |
---|
655 | and return immediately. Subsequent invocations of the``rtems_rate_monotonic_period`` directive |
---|
656 | for period_1 will result in the task blocking for the remainder |
---|
657 | of the 100 tick period. The period_2 period is used to control |
---|
658 | the execution time of the two sets of actions within each 100 |
---|
659 | tick period established by period_1. The``rtems_rate_monotonic_cancel( period_2 )`` |
---|
660 | call is performed to ensure that the period_2 period |
---|
661 | does not expire while the task is blocked on the period_1 |
---|
662 | period. If this cancel operation were not performed, every time |
---|
663 | the ``rtems_rate_monotonic_period( period_2, 40 )`` |
---|
664 | call is executed, except for the initial one, a directive status |
---|
665 | of ``RTEMS_TIMEOUT`` is returned. It is important to |
---|
666 | note that every time this call is made, the period_2 period will be |
---|
667 | initiated immediately and the task will not block. |
---|
668 | |
---|
669 | If, for any reason, the task misses any deadline, the``rtems_rate_monotonic_period`` directive will |
---|
670 | return the ``RTEMS_TIMEOUT`` |
---|
671 | directive status. If the above task misses its deadline, it |
---|
672 | will delete the rate monotonic periods and itself. |
---|
673 | |
---|
674 | Directives |
---|
675 | ========== |
---|
676 | |
---|
677 | This section details the rate monotonic manager's |
---|
678 | directives. A subsection is dedicated to each of this manager's |
---|
679 | directives and describes the calling sequence, related |
---|
680 | constants, usage, and status codes. |
---|
681 | |
---|
682 | RATE_MONOTONIC_CREATE - Create a rate monotonic period |
---|
683 | ------------------------------------------------------ |
---|
684 | .. index:: create a period |
---|
685 | |
---|
686 | **CALLING SEQUENCE:** |
---|
687 | |
---|
688 | .. index:: rtems_rate_monotonic_create |
---|
689 | |
---|
690 | .. code:: c |
---|
691 | |
---|
692 | rtems_status_code rtems_rate_monotonic_create( |
---|
693 | rtems_name name, |
---|
694 | rtems_id \*id |
---|
695 | ); |
---|
696 | |
---|
697 | **DIRECTIVE STATUS CODES:** |
---|
698 | |
---|
699 | ``RTEMS_SUCCESSFUL`` - rate monotonic period created successfully |
---|
700 | ``RTEMS_INVALID_NAME`` - invalid period name |
---|
701 | ``RTEMS_TOO_MANY`` - too many periods created |
---|
702 | |
---|
703 | **DESCRIPTION:** |
---|
704 | |
---|
705 | This directive creates a rate monotonic period. The |
---|
706 | assigned rate monotonic id is returned in id. This id is used |
---|
707 | to access the period with other rate monotonic manager |
---|
708 | directives. For control and maintenance of the rate monotonic |
---|
709 | period, RTEMS allocates a PCB from the local PCB free pool and |
---|
710 | initializes it. |
---|
711 | |
---|
712 | **NOTES:** |
---|
713 | |
---|
714 | This directive will not cause the calling task to be |
---|
715 | preempted. |
---|
716 | |
---|
717 | RATE_MONOTONIC_IDENT - Get ID of a period |
---|
718 | ----------------------------------------- |
---|
719 | .. index:: get ID of a period |
---|
720 | .. index:: obtain ID of a period |
---|
721 | |
---|
722 | **CALLING SEQUENCE:** |
---|
723 | |
---|
724 | .. index:: rtems_rate_monotonic_ident |
---|
725 | |
---|
726 | .. code:: c |
---|
727 | |
---|
728 | rtems_status_code rtems_rate_monotonic_ident( |
---|
729 | rtems_name name, |
---|
730 | rtems_id \*id |
---|
731 | ); |
---|
732 | |
---|
733 | **DIRECTIVE STATUS CODES:** |
---|
734 | |
---|
735 | ``RTEMS_SUCCESSFUL`` - period identified successfully |
---|
736 | ``RTEMS_INVALID_NAME`` - period name not found |
---|
737 | |
---|
738 | **DESCRIPTION:** |
---|
739 | |
---|
740 | This directive obtains the period id associated with |
---|
741 | the period name to be acquired. If the period name is not |
---|
742 | unique, then the period id will match one of the periods with |
---|
743 | that name. However, this period id is not guaranteed to |
---|
744 | correspond to the desired period. The period id is used to |
---|
745 | access this period in other rate monotonic manager directives. |
---|
746 | |
---|
747 | **NOTES:** |
---|
748 | |
---|
749 | This directive will not cause the running task to be |
---|
750 | preempted. |
---|
751 | |
---|
752 | RATE_MONOTONIC_CANCEL - Cancel a period |
---|
753 | --------------------------------------- |
---|
754 | .. index:: cancel a period |
---|
755 | |
---|
756 | **CALLING SEQUENCE:** |
---|
757 | |
---|
758 | .. index:: rtems_rate_monotonic_cancel |
---|
759 | |
---|
760 | .. code:: c |
---|
761 | |
---|
762 | rtems_status_code rtems_rate_monotonic_cancel( |
---|
763 | rtems_id id |
---|
764 | ); |
---|
765 | |
---|
766 | **DIRECTIVE STATUS CODES:** |
---|
767 | |
---|
768 | ``RTEMS_SUCCESSFUL`` - period canceled successfully |
---|
769 | ``RTEMS_INVALID_ID`` - invalid rate monotonic period id |
---|
770 | ``RTEMS_NOT_OWNER_OF_RESOURCE`` - rate monotonic period not created by calling task |
---|
771 | |
---|
772 | **DESCRIPTION:** |
---|
773 | |
---|
774 | This directive cancels the rate monotonic period id. |
---|
775 | This period will be reinitiated by the next invocation of``rtems_rate_monotonic_period`` with id. |
---|
776 | |
---|
777 | **NOTES:** |
---|
778 | |
---|
779 | This directive will not cause the running task to be |
---|
780 | preempted. |
---|
781 | |
---|
782 | The rate monotonic period specified by id must have |
---|
783 | been created by the calling task. |
---|
784 | |
---|
785 | RATE_MONOTONIC_DELETE - Delete a rate monotonic period |
---|
786 | ------------------------------------------------------ |
---|
787 | .. index:: delete a period |
---|
788 | |
---|
789 | **CALLING SEQUENCE:** |
---|
790 | |
---|
791 | .. index:: rtems_rate_monotonic_delete |
---|
792 | |
---|
793 | .. code:: c |
---|
794 | |
---|
795 | rtems_status_code rtems_rate_monotonic_delete( |
---|
796 | rtems_id id |
---|
797 | ); |
---|
798 | |
---|
799 | **DIRECTIVE STATUS CODES:** |
---|
800 | |
---|
801 | ``RTEMS_SUCCESSFUL`` - period deleted successfully |
---|
802 | ``RTEMS_INVALID_ID`` - invalid rate monotonic period id |
---|
803 | |
---|
804 | **DESCRIPTION:** |
---|
805 | |
---|
806 | This directive deletes the rate monotonic period |
---|
807 | specified by id. If the period is running, it is automatically |
---|
808 | canceled. The PCB for the deleted period is reclaimed by RTEMS. |
---|
809 | |
---|
810 | **NOTES:** |
---|
811 | |
---|
812 | This directive will not cause the running task to be |
---|
813 | preempted. |
---|
814 | |
---|
815 | A rate monotonic period can be deleted by a task |
---|
816 | other than the task which created the period. |
---|
817 | |
---|
818 | RATE_MONOTONIC_PERIOD - Conclude current/Start next period |
---|
819 | ---------------------------------------------------------- |
---|
820 | .. index:: conclude current period |
---|
821 | .. index:: start current period |
---|
822 | .. index:: period initiation |
---|
823 | |
---|
824 | **CALLING SEQUENCE:** |
---|
825 | |
---|
826 | .. index:: rtems_rate_monotonic_period |
---|
827 | |
---|
828 | .. code:: c |
---|
829 | |
---|
830 | rtems_status_code rtems_rate_monotonic_period( |
---|
831 | rtems_id id, |
---|
832 | rtems_interval length |
---|
833 | ); |
---|
834 | |
---|
835 | **DIRECTIVE STATUS CODES:** |
---|
836 | |
---|
837 | ``RTEMS_SUCCESSFUL`` - period initiated successfully |
---|
838 | ``RTEMS_INVALID_ID`` - invalid rate monotonic period id |
---|
839 | ``RTEMS_NOT_OWNER_OF_RESOURCE`` - period not created by calling task |
---|
840 | ``RTEMS_NOT_DEFINED`` - period has never been initiated (only |
---|
841 | possible when period is set to PERIOD_STATUS) |
---|
842 | ``RTEMS_TIMEOUT`` - period has expired |
---|
843 | |
---|
844 | **DESCRIPTION:** |
---|
845 | |
---|
846 | This directive initiates the rate monotonic period id |
---|
847 | with a length of period ticks. If id is running, then the |
---|
848 | calling task will block for the remainder of the period before |
---|
849 | reinitiating the period with the specified period. If id was |
---|
850 | not running (either expired or never initiated), the period is |
---|
851 | immediately initiated and the directive returns immediately. |
---|
852 | |
---|
853 | If invoked with a period of ``RTEMS_PERIOD_STATUS`` ticks, the |
---|
854 | current state of id will be returned. The directive status |
---|
855 | indicates the current state of the period. This does not alter |
---|
856 | the state or period of the period. |
---|
857 | |
---|
858 | **NOTES:** |
---|
859 | |
---|
860 | This directive will not cause the running task to be preempted. |
---|
861 | |
---|
862 | RATE_MONOTONIC_GET_STATUS - Obtain status from a period |
---|
863 | ------------------------------------------------------- |
---|
864 | .. index:: get status of period |
---|
865 | .. index:: obtain status of period |
---|
866 | |
---|
867 | **CALLING SEQUENCE:** |
---|
868 | |
---|
869 | .. index:: rtems_rate_monotonic_get_status |
---|
870 | |
---|
871 | .. code:: c |
---|
872 | |
---|
873 | rtems_status_code rtems_rate_monotonic_get_status( |
---|
874 | rtems_id id, |
---|
875 | rtems_rate_monotonic_period_status \*status |
---|
876 | ); |
---|
877 | |
---|
878 | **DIRECTIVE STATUS CODES:** |
---|
879 | |
---|
880 | ``RTEMS_SUCCESSFUL`` - period initiated successfully |
---|
881 | ``RTEMS_INVALID_ID`` - invalid rate monotonic period id |
---|
882 | ``RTEMS_INVALID_ADDRESS`` - invalid address of status |
---|
883 | |
---|
884 | **DESCRIPTION:** |
---|
885 | |
---|
886 | This directive returns status information associated with |
---|
887 | the rate monotonic period id in the following data structure:.. index:: rtems_rate_monotonic_period_status |
---|
888 | |
---|
889 | .. code:: c |
---|
890 | |
---|
891 | typedef struct { |
---|
892 | rtems_id owner; |
---|
893 | rtems_rate_monotonic_period_states state; |
---|
894 | rtems_rate_monotonic_period_time_t since_last_period; |
---|
895 | rtems_thread_cpu_usage_t executed_since_last_period; |
---|
896 | } rtems_rate_monotonic_period_status; |
---|
897 | |
---|
898 | .. COMMENT: RATE_MONOTONIC_INACTIVE does not have RTEMS_ in front of it. |
---|
899 | |
---|
900 | A configure time option can be used to select whether the time information is |
---|
901 | given in ticks or seconds and nanoseconds. The default is seconds and |
---|
902 | nanoseconds. If the period's state is ``RATE_MONOTONIC_INACTIVE``, both |
---|
903 | time values will be set to 0. Otherwise, both time values will contain |
---|
904 | time information since the last invocation of the``rtems_rate_monotonic_period`` directive. More |
---|
905 | specifically, the ticks_since_last_period value contains the elapsed time |
---|
906 | which has occurred since the last invocation of the``rtems_rate_monotonic_period`` directive and the |
---|
907 | ticks_executed_since_last_period contains how much processor time the |
---|
908 | owning task has consumed since the invocation of the``rtems_rate_monotonic_period`` directive. |
---|
909 | |
---|
910 | **NOTES:** |
---|
911 | |
---|
912 | This directive will not cause the running task to be preempted. |
---|
913 | |
---|
914 | RATE_MONOTONIC_GET_STATISTICS - Obtain statistics from a period |
---|
915 | --------------------------------------------------------------- |
---|
916 | .. index:: get statistics of period |
---|
917 | .. index:: obtain statistics of period |
---|
918 | |
---|
919 | **CALLING SEQUENCE:** |
---|
920 | |
---|
921 | .. index:: rtems_rate_monotonic_get_statistics |
---|
922 | |
---|
923 | .. code:: c |
---|
924 | |
---|
925 | rtems_status_code rtems_rate_monotonic_get_statistics( |
---|
926 | rtems_id id, |
---|
927 | rtems_rate_monotonic_period_statistics \*statistics |
---|
928 | ); |
---|
929 | |
---|
930 | **DIRECTIVE STATUS CODES:** |
---|
931 | |
---|
932 | ``RTEMS_SUCCESSFUL`` - period initiated successfully |
---|
933 | ``RTEMS_INVALID_ID`` - invalid rate monotonic period id |
---|
934 | ``RTEMS_INVALID_ADDRESS`` - invalid address of statistics |
---|
935 | |
---|
936 | **DESCRIPTION:** |
---|
937 | |
---|
938 | This directive returns statistics information associated with |
---|
939 | the rate monotonic period id in the following data structure:.. index:: rtems_rate_monotonic_period_statistics |
---|
940 | |
---|
941 | .. code:: c |
---|
942 | |
---|
943 | typedef struct { |
---|
944 | uint32_t count; |
---|
945 | uint32_t missed_count; |
---|
946 | #ifdef RTEMS_ENABLE_NANOSECOND_CPU_USAGE_STATISTICS |
---|
947 | struct timespec min_cpu_time; |
---|
948 | struct timespec max_cpu_time; |
---|
949 | struct timespec total_cpu_time; |
---|
950 | #else |
---|
951 | uint32_t min_cpu_time; |
---|
952 | uint32_t max_cpu_time; |
---|
953 | uint32_t total_cpu_time; |
---|
954 | #endif |
---|
955 | #ifdef RTEMS_ENABLE_NANOSECOND_RATE_MONOTONIC_STATISTICS |
---|
956 | struct timespec min_wall_time; |
---|
957 | struct timespec max_wall_time; |
---|
958 | struct timespec total_wall_time; |
---|
959 | #else |
---|
960 | uint32_t min_wall_time; |
---|
961 | uint32_t max_wall_time; |
---|
962 | uint32_t total_wall_time; |
---|
963 | #endif |
---|
964 | } rtems_rate_monotonic_period_statistics; |
---|
965 | |
---|
966 | This directive returns the current statistics information for |
---|
967 | the period instance assocaited with ``id``. The information |
---|
968 | returned is indicated by the structure above. |
---|
969 | |
---|
970 | **NOTES:** |
---|
971 | |
---|
972 | This directive will not cause the running task to be preempted. |
---|
973 | |
---|
974 | RATE_MONOTONIC_RESET_STATISTICS - Reset statistics for a period |
---|
975 | --------------------------------------------------------------- |
---|
976 | .. index:: reset statistics of period |
---|
977 | |
---|
978 | **CALLING SEQUENCE:** |
---|
979 | |
---|
980 | .. index:: rtems_rate_monotonic_reset_statistics |
---|
981 | |
---|
982 | .. code:: c |
---|
983 | |
---|
984 | rtems_status_code rtems_rate_monotonic_reset_statistics( |
---|
985 | rtems_id id |
---|
986 | ); |
---|
987 | |
---|
988 | **DIRECTIVE STATUS CODES:** |
---|
989 | |
---|
990 | ``RTEMS_SUCCESSFUL`` - period initiated successfully |
---|
991 | ``RTEMS_INVALID_ID`` - invalid rate monotonic period id |
---|
992 | |
---|
993 | **DESCRIPTION:** |
---|
994 | |
---|
995 | This directive resets the statistics information associated with |
---|
996 | this rate monotonic period instance. |
---|
997 | |
---|
998 | **NOTES:** |
---|
999 | |
---|
1000 | This directive will not cause the running task to be preempted. |
---|
1001 | |
---|
1002 | RATE_MONOTONIC_RESET_ALL_STATISTICS - Reset statistics for all periods |
---|
1003 | ---------------------------------------------------------------------- |
---|
1004 | .. index:: reset statistics of all periods |
---|
1005 | |
---|
1006 | **CALLING SEQUENCE:** |
---|
1007 | |
---|
1008 | .. index:: rtems_rate_monotonic_reset_all_statistics |
---|
1009 | |
---|
1010 | .. code:: c |
---|
1011 | |
---|
1012 | void rtems_rate_monotonic_reset_all_statistics(void); |
---|
1013 | |
---|
1014 | **DIRECTIVE STATUS CODES:** |
---|
1015 | |
---|
1016 | NONE |
---|
1017 | |
---|
1018 | **DESCRIPTION:** |
---|
1019 | |
---|
1020 | This directive resets the statistics information associated with |
---|
1021 | all rate monotonic period instances. |
---|
1022 | |
---|
1023 | **NOTES:** |
---|
1024 | |
---|
1025 | This directive will not cause the running task to be preempted. |
---|
1026 | |
---|
1027 | RATE_MONOTONIC_REPORT_STATISTICS - Print period statistics report |
---|
1028 | ----------------------------------------------------------------- |
---|
1029 | .. index:: print period statistics report |
---|
1030 | .. index:: period statistics report |
---|
1031 | |
---|
1032 | **CALLING SEQUENCE:** |
---|
1033 | |
---|
1034 | .. index:: rtems_rate_monotonic_report_statistics |
---|
1035 | |
---|
1036 | .. code:: c |
---|
1037 | |
---|
1038 | void rtems_rate_monotonic_report_statistics(void); |
---|
1039 | |
---|
1040 | **DIRECTIVE STATUS CODES:** |
---|
1041 | |
---|
1042 | NONE |
---|
1043 | |
---|
1044 | **DESCRIPTION:** |
---|
1045 | |
---|
1046 | This directive prints a report on all active periods which have |
---|
1047 | executed at least one period. The following is an example of the |
---|
1048 | output generated by this directive... index:: rtems_rate_monotonic_period_statistics |
---|
1049 | |
---|
1050 | .. code:: c |
---|
1051 | |
---|
1052 | ID OWNER PERIODS MISSED CPU TIME WALL TIME |
---|
1053 | MIN/MAX/AVG MIN/MAX/AVG |
---|
1054 | 0x42010001 TA1 502 0 0/1/0.99 0/0/0.00 |
---|
1055 | 0x42010002 TA2 502 0 0/1/0.99 0/0/0.00 |
---|
1056 | 0x42010003 TA3 501 0 0/1/0.99 0/0/0.00 |
---|
1057 | 0x42010004 TA4 501 0 0/1/0.99 0/0/0.00 |
---|
1058 | 0x42010005 TA5 10 0 0/1/0.90 0/0/0.00 |
---|
1059 | |
---|
1060 | **NOTES:** |
---|
1061 | |
---|
1062 | This directive will not cause the running task to be preempted. |
---|
1063 | |
---|
1064 | .. COMMENT: COPYRIGHT (c) 1988-2007. |
---|
1065 | |
---|
1066 | .. COMMENT: On-Line Applications Research Corporation (OAR). |
---|
1067 | |
---|
1068 | .. COMMENT: All rights reserved. |
---|
1069 | |
---|