Ada has a high-level concurrency model that is designed to help avoid such errors. Concurrent activities (tasks) can communicate with each other either directly (rendezvous) or through protected operations on protected objects. A protected operation is performed with mutually exclusive access to a protected object, and the semantics help prevent race conditions. A predefined object-locking policy can be imple- mented extremely efficiently because of the requirement that tasks not block while executing protected operations.
Ada 2005 has extended the Ada tasking model. It defines some new task-dispatching policies (including Earliest Deadline First) and provides a framework in which multiple policies can coexist. It also allows applications to monitor and control execution time on a task-by-task basis, with run-time detection of budget overruns.
Many languages (such as C and C++) do not support concurrency directly and instead require the programmer to obtain the desired facilities through libraries. This interferes with portability. Others, most notably Java, have a low-level concurrency mechanism that is error-prone.
Embedded systems often have to perform low-level processing: dealing with storage addresses, laying out data structures with specific fields occurring at specific offsets, querying or specifying the size of data objects, handling interrupts, using specialized hardware instructions, treating data as "untyped" storage elements. All of those capabilities are found in Ada. Moreover, and in contrast to C and C++, the Ada rules make it clear to the reader of the program that such system-specific and perhaps potentially unsafe features are being used. Low-level programming in Java requires native code and a corresponding loss of protection.
Embedded systems typically have stringent requirements for a small memory footprint and high efficiency. "Simple" languages, such as C, that might meet those requirements are problematic with respect to reliability, and they lack some necessary features (such as concurrency support and exception handling). Higher-level languages like C++, Java and full Ada come with run-time libraries that may be large or complex. Ada supplies a mechanism, the Restrictions pragma, that lets the programmer select exactly those features that are needed. No run-time libraries are included for features outside the chosen subset.
A useful subset for embedded high-integrity real-time systems is the Ravenscar profile, a reliable concurrency model standardized in Ada 2005 as a set of Restrictions pragmas. Ravenscar is general enough to express the kinds of concurrency patterns that are needed but is simple enough to be supported by a small, reliable and efficient run-time library. The Ravenscar profile meets the requirements for determinism, schedulability analysis and memory boundedness, suiting it for both hard-real-time and high-integrity embedded systems.
Safe pointers
Pointers are important in low-level programming. But if the pointer facility is not strongly typed, an object of one type may be viewed (through a pointer) as having a different type. If an object becomes inaccessible--for example, by being popped off the run-time stack--but a pointer to the object still exists, the result is a notorious bug known as a dangling reference. And with dynamic allocation, storage reclamation is a concern.
Ada addresses those issues via a strongly typed pointer mechanism that includes scope accessibility checks to prevent dangling references. The Restrictions pragma may be used to indicate a constrained use of pointers (for example, dynamic allocations only occurring during system initialization). Since aggregate data can go on the stack, Ada does not require the overhead of a run-time garbage collector.
Ada is unique in explicitly addressing the mixed-language requirement of modern systems. The Ada standard provides interfacing mechanisms that allow an Ada program to import subprograms or global data from, or export them to, other language environments. Ada also lets the programmer specify that a data structure is to be laid out based on the conventions of a compiler for another language.
Thus, it's possible to combine Ada efficiently, reliably and portably with other languages in the same program. For example, if a scientific library in Fortran is needed in an Ada application, there is no need to convert the library to Ada; it can simply be called from the Ada code. In the other direction, if an existing Ada application is to be extended with new functionality that is to be implemented in another language (such as C++), the simplest approach is to use the Ada interfacing mechanisms so that the new code can call the existing Ada subprograms. There is no reason to undertake the risky and costly strategy of converting Ada to the other language.
Ben Brosgol (brosgol@ adacore.com) is senior software engineer at AdaCore in New York. José Ruiz ([email protected]) is senior software engineer at AdaCore in Paris.
