RTC Magazine

Creating reliable software is largely a matter of applying careful and disciplined software development and maintenance practices. However, the choice of programming language also plays an important role. Two topics that are affected by programming language issues include simplicity and portability.

Use of a simpler programming language is more likely to result in reliable software because programmers are less likely to accidentally misuse the language when they misunderstand its semantics. Programmers who are dealing with less complexity are less likely to make programming errors. C++, for example, is a very complex language, and certain of its features, such as overriding standard operators, are often misunderstood by programmers. Teams that have used C++ for large development efforts generally reach the conclusion that every team member must be an expert C++ programmer, or the whole team will suffer the mistakes made by less experienced developers.

One area in which C and C++ are much more complex than Java is the way that they manage the allocation and deallocation of temporary memory objects. C programmers use malloc() and free() function calls. C++ programmers use the new and delete() services. In both C and C++, program reliability will suffer if memory becomes fragmented, and preventing fragmentation is largely outside the realm of control of the application developer. Further complications with dynamic memory management in C and C++ programs are the risks that the memory for allocated objects will not be reclaimed, and that program components will retain pointers to objects that have been reclaimed. These common programming errors are respectively known as memory leak and dangling pointer.

Memory management in traditional Java is much simpler, and thus much more reliable, than the techniques used in C and C++. Java s automatic garbage collection system reduces memory leaks by automatically reclaiming objects that are no longer in use, and garbage collection totally eliminates the possibility of dangling pointer errors. Typical Java garbage collection implementations also defragment memory in order to further enhance reliability. The draft safety-critical Java profile provides the same benefits, but does so without the use of traditional tracing garbage collection. Instead, it allocates temporary objects on the run-time stack, and the memory for these objects is instantly reclaimed when control leaves the currently executing method. All temporary memory allocation is organized as a stack to prevent memory fragmentation. Additionally, special compile-time analysis of the application programs guarantees the absence of dangling pointers.

Figure 1 illustrates the organization of temporary memory after a main thread has spawned three child threads, setting aside portions of its run-time stack to serve the temporary memory needs of each of the spawned thread s run-time stacks. The safety conventions allow pointers from inner-nested objects to outer-nested objects, as illustrated with the solid-filled arrowheads in this figure. Pointers in the other direction are disallowed. Enforcement of this protocol is performed at compile time by a special hard real-time byte-code verifier based on annotations provided in the source code.

Reliability benefits from portable development methodologies in two important ways. First, programmers who are able to target a portable platform are less likely to make programming errors because they misunderstand or overlook incompatibilities between platforms. Second, programming languages that support portability between different platforms make possible far greater reuse of software components that were developed for one platform but reused on another. When such software is reused, it can be reused exactly as is, without any changes required for porting. For typical deployments, this means a far greater percentage of the complete software system is comprised of mature time-proven software components.

Within the domain of real-time programming, the Real-Time Specification for Java (RTSJ) does not support portable real-time semantics. Compliant implementations of this specification may differ in significant and incompatible ways, preventing real-time Java code that was developed and tested on one RTSJ implementation from running correctly on another. Compliant RTSJ implementations may differ in the scheduling of real-time threads, the times at which task deadline and CPU cost overruns are detected and handled, access to scope-allocated objects within the standard libraries, and allocation of objects within scoped-memory contexts by the standard libraries. The proposed safety-critical Java profile addresses these portability issues by subsetting from the full set of RTSJ capabilities, and carefully specifying the required semantics of the subset to ensure that all compliant implementations represent the same portable real-time programming platform.

• Page 1 of 3
• Previous Page
• Next Page
• E-mail

LEAVE A COMMENT