An important issue that must be faced while introducing Ada into the real time world is efficient and prodictable runtime behavior. One of the most effective methods employed during the traditional design of a real time system is the cyclic executive. The role cyclic scheduling might play in an Ada application in terms of currently available implementations and in terms of implementations that might be developed especially to support real time system development is examined. The cyclic executive solves many of the problems faced by real time designers, resulting in a system for which it is relatively easy to achieve approporiate timing behavior. Unfortunately a cyclic executive carries with it a very high maintenance penalty over the lifetime of the software that is schedules. Additionally, these cyclic systems tend to be quite fragil when any aspect of the system changes. The findings are presented of an ongoing SofTech investigation into Ada methods for real time system development. The topics covered include a description of the costs involved in using cyclic schedulers, the sources of these costs, and measures for future systems to avoid these costs without giving up the runtime performance of a cyclic system

Hood, Philip E.

English

NASA Technical Reports Server

c 
- _ _  
N89- 16322 / 6 ' 7 0 6 7  A 
Ada* and Cyclic Runtime Scheduling 
P h i l i p  E. Hood 
SofTech Inc. 
Abstract 
6 An ~mportant issue that must be faced while introducing Ada into the real 
t h e  world is efficient and predictable runtime behavior. One of the most 
effective methods employed during the traditional design of a real time system 
is the cyclic executive. Thia paper examines the role cyclic schedullng might 
Play in an Ada application in terms of currently available implementations and 
in terms of implementations that might be developed specifically to support 
real time system development. 
The cyclic executive solves many of the problems faced by real time 
designers, resulting in a system for which it is relatively easy to achieve 
appropriate timing behavior. Unfortunately a cyclic executive carries with it 
a very high maintenance penalty over the lifetime of the software that i t  
schedules. Additionally, these cyclic systems tend to be quite fragile when 
any aspect of the system changes. 
This paper presents the findings of an ongoing SofTech investigation into 
Ada methods for real time system development. Section 1 discusses cyclic 
scheduling in general - what it is and why i t  is used. Section 2 examines how 
cyclic scheduling might be applied to Ada real time systems. Methods of 
introducing cyclic schedulers into applications without violating Ada 
semantics is explicitly discussed. Several classes of cyclic schedulers will 
be evaluated on their compatibility with the Ada world. Section 3 briefly 
examines how future systems might use a cyclic scheduler without paying the 
high price levied upon current systems. The topics covered include a 
description of the costs involved in using cyclic schedulers, the sources of 
these costs, and measures for future systems to avoid these costs without 
giving up the runtime performance of a cyclic system. 
1.0 Cyclic Executive Description - 
A cyclic executive provides a mechanism for enforcing a predetermined 
ordering of processing events in a system. All processing to be performed is 
arranged within a schedule of finite duration. This schedule is repeated at a 
specified rate called the major cycle. The major cycle is broken down into a 
number (usually a power of two) of equal minor cycles. Each minor cycle is 
assigned a processing frame containing a list O E  processing elements 
(routines) to be performed during the associated minor cycle, An example of 
the basic cyclic executive structure is shown in Figure 1. ..................................... 
Ada is a registered trademark of the U.S. Government (AJPO) 
D.3.3.1 
https://ntrs.nasa.gov/search.jsp?R=19890006951 2020-03-20T03:43:48+00:00Z
Figure 1 - An Example Cyclic Executive Structure 
D . 3 . 3 . 2  
1 
I 
Although a l l  CYOliO OXocutlvor rhar8 the structure we have described, 
th8y vary in rlmort OV8ry othor arpout, Many types of cycllc executives have 
b80n d8v8lOpod to rupport variour appllcrtlonr, and each one Is dlfferent from 
the last.  80a8 O f  these variations, much 111 mode changes, varying frame 
assignments and handling frame overruns, are discussed below. 
1.1 Mode Changes 
One of the advantages of a cyclic executive is that the static schedule 
can be tuned to optimize the system's timing performance for the expected load 
conditions. The load on the system, however, may not be constant. A change 
in the system load may cause the cyclic executive to allocate run time in a 
very inefficient manner (a job with a long allocated run time may have little 
or no processing to perform), 
To solve this problem mode changes are introduced into the system. A 
mode change can change both the processing to be performed and the cyclic 
schedule. The more variation possible in the loading of the system, the more 
mode changing operations will be necessary. Each mode change is expensive in 
terms of new coding and tuning that must be performed and in terms of the 
damage to the program structure that always accompanies tuning operations. 
1.2 Varying Frame Assignments 
Schedule variations do not always require a mode change. If the 
variations can be localized to one frame, then that frame can use a local 
scheduler to resolve the problem. This solution of course, requires the 
overhead of some run time scheduling. Moreover, every possible scheduling 
possibility must be verified during system tuning. 
1.3 Handling Frame Overruns 
The greatest amount of variation between cyclic executives lies in the 
handling of frame overruns. We will consider the following four methods, b y  
no means a complete list (many variations and hybrids exist): overruns 
ignored, overruns logged, overruns suspended, and overruns terminated. 
1.3.1 Overruns Ignored 
In some systems the problem of frame overrun can be adequately addressed 
during system debugging; these systems may choose to ignore overruns during 
runtime. The designer 1s responsible for verifying that overruns can never 
occur. This type of executive is typical of systems with either very simple 
software or over-confident designers. 
D . 3 . 3 . 3  
* '18382 .Ovorrunr Logged ' ( ' I -  J,', 
' . b  , 1 .  .., ! 
is appropriate 
when' 8 "framo overruns, This 
approach resultr in asvery realistic oxocutivo for any rystem in which tuning 
issues can bo adequately addressed, In a properly tuned cyclic executive 
application, ftamer rhould not bo overrunning. Thur i t  this type of scheduler 
is inadequate, it implies that a cyclic schedule is not capable of providing a 
reliable rchedule for that application and must be enhanced. 
' T h h  itratogy ir w e d  in lrysIomr whore no runtime action 
Tho overrun ir rocordod for handling o f t  line, I 
8 L
I 
! 
1 
1.3.3 Overruns Suspended 
When a frame overruns in this type of system, it is suspended and the 
next frarar is allowed to start on time. When ther8 is free time the suspended 
frame is allowed to complete. 
This method greatly complicates data access in the application software. 
A built-in efficiency of a cyclic executive is the SynChrOnltAtiOn implied by 
static frame assignments. Additional synchronization is normally unnecessary 
during shared data references. When frame suspension is introduced, the 
implied synchronization is disrupted, and consequently references to shared 
data must include the appropriate synchronization mechanisms. 
1.3.4 Overruns Terminated 
When overruns occur in a system using this strategy, the overruning frame 
is terminated. It is restarted from the beginning at its next scheduled start 
time. This mechanism avoids the synchronization problems of the suspension 
mechanism but introduces its own problems. Software components that could 
possibly overrun frame boundaries must be written very carefully so that 
valuable data is not lost. There is also a potential problem with data that 
is incompletely updated when the frame is terminated - if this data is used by 
other components, serious problems could arise. 
2 . 0  Ada Implementation 02 Cyclic Executives -
Some varieties of cyclic executive fit very well into Ada, others do not 
map so naturally into the language. 
The basic cyclic structure is fairly easy to implement in Ada. Mactaren 
(11 and Hood 121 show how to write simple cyclic executives in Ada. The basic 
cyclic scheduler for this type of cxecutlve is shown in Figure 2. This type 
of executive ignores the issues of varying loads and overrunning Erames. 
D.3.3.4 
-.? : R " i . \  
with Frame-Package1 
package body Executive is 
task Cyclic-Scheduler i r  
end Cyclic-Scheduler; 
entry Minor-Cycle-Tickt 
for Minor-Cycle-Tick use at BIL00054t; 
task body Cyclic-Scheduler is 
begin 
loop --forever 
accept Minor-Cycle-Tick; 
Frame-Packaqe.Frame-1; 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-2; 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-3; 
accept Minor-Cycle-Tick; 
Frame-Packaqe.Frame-4; 
end loop! 
end Cyclic-Scheduler1 
end Executive; 
Figure 2. A Simple Cyclic Executive 
0.3.3.5 
The Simple 8tructure can bo easily expanded to incorporate mod* changes 
and vatiable tram0 assignmentr. ~ i g u r e  3 showr A cyclic executiva with mode 
Changing. Each modo i s  represented by a complete list of frames to be 
scheduled in that bode. At the beginning of each major cycle, the executive 
decider which schedule to run. Varying frame assignments require no change to 
the Cyclic schedulerr instead a local scheduler is created in the varying 
frame as ehown in Figure 4.  
Overruns can be logged by adding a task to receive the periodic interrupt 
and to check whether or not the previous schedule has completed. This type of 
scheduler is shown in Figure 5.  
None of the cyclic variations discussed so far has been difficult to 
implement in Ada. The last two variations, namely overrun suspension and 
termination, are considerably more difficult. In both cases, these executives 
could only be written if they were heavily supported by the underlying r u n  
time system. 
The only asynchronous scheduling point provided by Ada occurs when an 
interrupt is received, so this fact must be used in both the Suspension &.Id 
termination variations. Asynchronous response to an interrupt is not 
guaranteed by the Ada specification, however any Ada implementation that has 
any value in the development of real time systems have to provide asynchronous 
interrupt handling. The only ways to terminate an executing piece of Ada code 
are either to raise an exception or to abort the task, Asynchronous 
exceptions are not allowed in the Ada semantics, leaving only the abort 
statement. The abort statement is not guaranteed to stop the aborted task 
from executing at any particular time. Therefore, a frame termination 
executive could be written in Ada only if the underlying implementation 
guarantees the immediate termination of aborted tasks. 
The overrun suspension executive has similar problems. The only way to 
ensure the new frame will have precedence over the old one is to introduce the 
new frame as a task with higher priority than the old frame task. This 
technique works for the frames in a given major cycle, but when the first 
frame is reintroduced at the beginning of the next major cycle, it must wait 
for all the frames from the previous major cycle to complete before starting. 
This behavior is clearly not desirable. In order to implement this type of 
executive in Ada, the implementation must provide some sort of dynamic 
priority mechanism. Standard Ada priorities are not dynamic, thus a 
additional priority scheme must be introduced. These new priorities can not 
interfere with the workings Of the Ada priority system but can be used to 
assign priority to tasks that either have no standard Ada priority, 
o r  have the same standard priority. 
relative 
In general, these executives require more control over the processing 
resources than can be obtained Using a single thread of control (single Ada 
task). The resulting cyclic executive must be implemented using Ada tasking 
€acilities. Ada tasking facilities, however, lack support for the primitive 
(and often dangerous) functions necessary for these variations of the cyclic 
executive. 
D.3.3.6 
with FrameJackage; 
package body Executive 1s 
task Cgclic-Schedul*r is 
end Cyclic-Scheduler; 
entry Micx-Cycle-Tick; 
for Mlnor_Cyclr-Tlck use at 81100054@; 
task body Cyclic-Scheduler is 
type Mode-Typo is (Mode-1 Modr-2 ) ; 
Mode: Mode-Type := Mode-1; 
begin 
loop --forever 
cage Mode is 
when kiGde-1 => 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-1; 
accept Minor-Cycle-Tick: 
Frame-Package.Frame-2; 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-3; 
accept Minor-Cycle-Tick; 
Frame--Packdge. Frame-4 t 
accapt Minor-Cycle-Tick; 
Frame-Package.Frame-It 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-2: 
accept Minor-Cycle-Tick; 
Fra~o-Package.Frame-1; 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-2; 
when Mode-2 => 
end casei 
end loop; 
end Cyclic-Scheduler; 
end Execut ive ; 
Figurc 3. A Cyclic Executive with Mode Changing 
D.3.3 .7  
4 4 
I 
‘ G  
I 
'. tark 'CycliclSchedulet is 
'entry Minor-Cycle-Tick; 
for Minor-Cycle-Tick ure a t  8i1000541; 
end Cyclic-Scheduler a 
task body Cyclic-Scheduler ir 
begin 
Statu88 Frame-Package,Statur-Type I=  Frame_Package.Status-Type'Firrti 
loop --forever 
accept Minor-Cycle-Tick; 
Fraare-Package.Frame-1i 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-2; 
accept Minor-Cycle-Tick; 
Frame_Package.Frame-3i 
accept Minor-Cycle-Tickt 
Frame-Package.Frame-4 (Status); 
end loop; 
end Cyclic-Scheduler1 
end Executive; 
separate (Frame-Package) 
procedure Frame-4 (Status I in Status-Type) 1s 
begin 
0 
C1SQ Status iS 
whim Good 8 ,  
Application-1; 
Application-Zt 
Application-1: 
when others => 
end case8 
end Frame-4; 
Figure 4 .  A Cyclic Executfve with Frame Level Scheduling 
D.3.3.8 
..". ..., *. 
with drror-Handling_Pickrgr; 
with Pram@-Packagrt 
paCkag8 body EX8CUtiVO i8 
' task Pick-Handlrr i 8  
rnt r y Clock-P ic k ; 
tor Clock-Tlck use a t  811000541r 
f rnd Pick-Handlrt; 
1 
. task Cyclic-Scheduler is 
end Cyclic-Scheduler; 
entry Minor-Cycle-Tick; 
&ask kuidg pld&JimL?ua d.s 
loop -- forever 
accept Clock-Tick; 
select 
else 
end select; 
Cyclic-Scheduler.Minor_Cyclr_Tick; 
Error-Handling-Package.Log-Overrun; 
end loop; 
end Tick-Handler8 
task body Cyclic-Scheduler is 
begin 
loop --forever 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-1; 
accept Minor-Cycle-Tick; 
Frame-Package.Fcame-28 
accept Minor-Cycle-Tick; 
Frame-Package.Frame-38 
accept Minor-Cycle-T'.ck; 
Frame_Package.Frame_~~ 
end loop; 
end Cyclic-Scheduler: 
end Execut ive; 
Figure 5. A Cyclic Executive with Overrun Logging 
ORIGINAL PAGE S 
OF rOOR Q U A l l N  D. 3.3.9 

1.0 Avoidinq the Cost & Cvclic Schedulinq 
Cyclic scheduling ir very costly over the lifetime of a software System. 
The reason is very rimpler cyclic systems require software to be developed in 
modules according to their time consumption rather than according to 
functional coneiderations. Two phase8 o i  development are totally dominated by 
the timing structure of a cyclic executlve; detailed design/coding stage and 
tuning. During detailed design, frame assignments are designed and coded 
SPecfficallY to fit into their assigned time slots. Functionality is traded 
back and forth between routines and frames, depending on where there is time. 
Tuning can be though of as temporal debugging, during which timing errors 
are found and corrected. The correction methods include dividing up existing 
routines and shifting functionality between frames and routines. The end 
result io a very fragile schedule which meets the timing requirements but 
suffers several drawbacks: minor changes are likely to have sufficient impact 
on the schedule to require complete system retuning. Functional components 
are so dispersed that to understand any single component requires knowledge of 
the entire system. The structure of the software has been totally lost and 
maintenance efforts can only degrade thn structure further. Finally, one has 
a system in need of constant and expensive maintenance. 
In order to reduce the cost of this type of system, the creation of the 
cyclic structure must be separated from the cleation and maintenance of the 
software components. Modern software engineering techniques can be applied to 
the system development and maintenance issues, with an extra step added to 
derive a cyclic implementation from a more general design. The code developed 
would be structured according to functional rather than timing considerations. 
The timing of the system would move from the detailed design and coding steps 
into a new precompilation step. 
This extra step might be implemented as a machine-assisted (programmer 
directed) set of program transformations which parallel the cyclic design 
process that would normally take place during the software design. The 
transformational sequence as well as the the untransformed source would be 
save for future rederivations after necessary program maintenance is 
performed. 
A tool assisted tuning system need not be limited to cyclic 
transformations. While there may always be a class of real time systems 
requiring cyclic runtime performance, there is an equally large number of 
systems that do not require such extreme measures. Many of these systems 
would benefit from the flexibility of an Ada style runtime scheduler. This 
type of scheduling allows more flexibility in dealing with runtime loadinq 
variations, and is far more robust when maintenance changes are made. These 
systems still require tuning, although not to the same extent. For these 
systems, other types of tuning transformations can be made available, such as 
replacing monitor tasks with semaphores OK simplifying groups of tasks using 
program inversion techniques [31. By applying these techniques, a system can 
be tuned until the appropriate level of predictability and efficiency has been 
reached, 
D. 3.3.10 
ORiQlPlAC PAGE IS 
OF POOR QUACITY 
-**--#.e I . . ' " . "  
Conclusion 
There will always bo system that have a need for the runtime performance 
Of cyclic scheduling. Many of the cyclic scheduling models Lit well within 
the Ada language. In order for  the cost of a cyclic system to be brought 
under control, new methods aurt be developed to for their creation. These 
methods ought not be limited to tho creation of cyclic systems; however, they 
should provide a more general approach to the development of real time 
systemsr with cyclic scheduling as one of many options €or achieving real time 
performance. 
References 
111 MacLaren *Evolving toward Ada in Real Time Systems," SIGPLAN Notices, 
1980 
[2] Hood, Philip and Grover, Vinod, Desisninq Real Time Systems 
Technical Report 1123-1, SofTech Inc., Waltham, MA, January 1986. 
[ 3 ]  Rajeev, S., 9 Applying Ada to Real-Time Systems: The Inversion 
Technique and Some Examples, Technical Report TP 148, SofTech,  Inc., 
Waltham, MA, March 1983. 
Adaf 
( 4 1  Rajeev, S., Certain Optimizations Ada Tasking Implementations 
[SI Gonralezr M.J., Jr., "Deterministic Processor Scheduling," 
Technical Report 9074-2, SofTech, Walthamr MA, January 1983. 
Computinq Surveys, Vol. 9 . ,  No. 3 . ,  September 1977. 
D. 3.3.11 


Ada and cyclic runtime scheduling

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server