Syntax-Based Cyclic Tasks
CLOSE STARTUP;
MODULE;
SYSTEM;
Trigger: Hard_Int (2);
PROBLEM;
SPECIFY Trigger INTERRUPT; Main_Task: TASK MAIN PRIORITY 2;
AFTER 30 SEC ALL 10 SEC DURING 2 HRS
ACTIVATE Periodic_Task PRIORITY (10); AT 10:00 ALL 50 SEC ACTIVATE Counter; WHEN Trigger ACTIVATE Aperoidic_Task END; ! Main_Task Periodic_Task: TASK; . .. periodic code ... END; ! Periodic_Task Counter: TASK; ... counter code ... END; ! Counter Aperoidic_Task: TASK; ... aperiodic code ... END; ! Aperoidic_Task Listing 22
Cyclic tasks written in HAL/S.
Listing 23
Cyclic tasks written in PEARL.
Compared to HAL/S, PEARL provides richer semantics for cyclic tasks. A second ACTIVATE statement can reschedule a periodic task, while tasks with inter- rupt-based start conditions are scheduled with each raising of that interrupt. Thus, PEARL provides support for both periodic and aperiodic tasks, though like HAL/S does not offer language support for sporadic tasks or deadline con- ditions, and suffers from the properties of cyclic tasks being located within the body of the program.
Real-Time Euclid was a novel language designed to support schedulability analysis for real-time systems (Kligerman & Stoyenko, 1986). While never seeing outside use, its focus on schedulability saw the language define cyclic task properties on task declarations to allow schedulability analyser tools to identify these properties (Stoyenko, 1992). Furthermore, Real-Time Euclid only supports periodic and sporadic tasks.
As demonstrated in Listing x, Real-Time Euclid supports activating a task peri- odically or in response to an interrupt. For periodic tasks, the first activation can be a time, the raising of an interrupt or the earliest of either two events. Unlike HAL/S and PEARL, the cyclic specification of the task does not provide a means to deactivate a periodic task after a set period. However, Real-Time Euclid does support a limited means of deadline enforcement, with the language designed to raise a run-time error if a task exceeds its compiler calculated deadline (made possible by the constructs of the language being time bounded). Once again, the use of keywords to specify cyclic task parameters makes it difficult to add new parameters without affecting existing users.
Real-Time Euclid
Listing 24
Cyclic tasks written in Real-Time Euclid.
var CyclicMayhem: module
var Trigger: activation condition
process PeriodicTask: periodic frame 30 first activation atTime 100
... periodic code ...
end PeriodicTask
process Counter: periodic frame 100 ... counter code ...
end Counter
process SporadicTask: atEvent Trigger frame 500 ... sporadic code ...
end SporadicTask
end CyclicMayhem
37 CYCLIC TASKS AND ADA
Cyclic tasks form the cornerstone of real-time systems and derive from the nature of the fundamental system they are apart of: control systems — systems which manipulate their environment in response to stimuli in a calculated manner. In turn, the ultimately periodic nature of real-time tasks enables system designers to determine the schedulability of the system before its operation. This valuable technique helps identify and resolve timing faults early in a sys- tems development, and frees users from trying to locate and resolve otherwise costly defects. Ultimately, a schedulability analysis enables developers to guar- antee a system is free of timing defects, providing the necessary assurance for safety-critical applications.
Constraining the classical real-time task model has created a general cyclic task model to support the development of reliable and maintainable real-time systems free of timing defects. The model centres on tasks as the basic unit of work: an execution unit encapsulating the code, state and execution of an activity or algorithm. This definition fits neatly into the same definition used by Ada. The difference between Ada and the cyclic task model lies with Ada only offering direct support for sequential tasks, whereas the model introduces the concept of cyclic tasks: tasks’ whose code executes in response to an event. By contrast, Ada tries to replicate the functionality of the cyclic task model through its existing tasking model, supported by the extensive library services provided by its Real-Time System Annex. Ada 2012 achieves this with success,
being able to comprehensively cover the model with a set of lower-level re- al-time primitives, offering the ability to: build periodic, sporadic and aperiodic tasks; support cycle deadlines and execution budgets; build execution servers; and support a wide variety of schedulers. By providing a set of building blocks from which to build cyclic tasks, Ada offers users the ability to build the cyclic task that meets their needs.
However, this Chapter has shown Ada’s approach requires considerable and repetitive effort, increasing the scope for faults to enter a system. Ada’s prized traits of readability and maintainability suffer, with cyclic task attributes hard to identify from a system’s code and requires access to the body of the task. Compounding the problem, clear separation of a cyclic task’s code and the parts of the task making it cyclic does not exist.
The cost of building cyclic tasks on Ada would not be an issue if it were not for the importance of the abstraction for real-time systems. Two noted efforts exist in response — GNATColl’s Ravenscar patterns and the Real-Time Utilities Library — simplifying cyclic tasks by abstracting much of the cyclic task tem-
plate into reusable libraries. While these library-based solutions do reduce the effort and the amount of code required to implement a cyclic task, they do so by losing Ada’s task abstraction.
Losing Ada’s task abstraction negatively affects the development of real-time systems, as the abstraction provides a scope (enforced by the compiler) which only the task can access. The scope protects the integrity of a task by preventing users from incorrectly accessing the task’s state and clearly identifies to the user the task, its state and the code that operates on the state.
Finally, even comprehensive solutions like the Real-Time Utilities Library re-
quires decomposition of the cyclic task abstraction, leaving extra work for users
Conclusion
to write and understand cyclic tasks. Furthermore, Ada’s real-time facilities are not task dispatching policy independent, reducing the ability to seamlessly reuse existing tasks across different systems.
Consequently, while Ada provides the building blocks to build real-time cyclic tasks, the act of building them imposes development overheads: affecting the reliability, maintainability and cost of real-time systems. Because cyclic tasks form the cornerstone of real-time systems, the lack of a cyclic task model ham- pers Ada’s ability to lower software lifecycle cost.
As this Chapter detailed, many of these concerns were raised as part of the Ada 9X review process where suggestions were put forward to incorporate cyclic tasks into the language. While dismissed at the time for being too high-level and increasing the complexity of the language, this Chapter has shown other languages targeting real-time systems have successfully included cyclic task models in their language while also demonstrating the flaws with approaches that use library-based solutions.
HAL/S and PEARL have shown syntax-based cyclic tasks can have success in industrial applications, with PEARL actively used today. Their success derives from being developed on behalf of users rather than as an academic project. While later real-time languages like Real-Time Euclid and DSP have not had
any industrial success, they have demonstrated favourable cyclic task features. Real-Time Euclid established the advantage of having cyclic task properties on the definition of a task, while DSP showed the possibility of providing a rich real-time model allowing the description and enforcement of execution budgets and deadlines.
The Chapter also demonstrated the main flaw with syntax-based approaches: relying on syntax to annotate a task with its cyclic task properties. Incorporat- ing a similar approach in Ada would cause difficulties as these keywords will already be used by users as identifiers. The earlier suggestions for cyclic tasks within Ada’s semantics provides a path forward: using pragma’s or attributes to annotate the cyclic properties of a task without relying on new syntax.
39 CYCLIC TASKS AND ADA