The International Journal of Time-Critical Computing Systems, 18, 71–74 (2000)c© 2000 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.

A Case For Object-Oriented Real-Time Systems(OORTS)

ALAN SHAW* shaw@cs.washington.eduDepartment of Computer Science and Engineering, University of Washington, Seattle, WA 98195-2350, USA

1. Introduction

Real-time systems have several distinguishing features and requirements that make themdifficult or, at least challenging, examples for object orientation. These include the need tosatisfy much stricter timing, concurrency, and fault tolerance constraints than exist in mostother kinds of systems. Generally, real-time systems must have predictable behaviors—intime and in other resource usage. The question is whether object-oriented (OO) techniquesoffer or potentially offer a framework and discipline for designing and implementingpre-dictableandefficientsystems.

OO systems are those that use data abstraction ideas, abstract data types, encapsulation,classes and instances, inheritance, and polymorphism, in a central way. The main argumentsagainstOORTS are that that they lead to unpredictable and inefficient systems. (Similararguments, of course, were made against the use of higher-level languages, such as For-tran, in the 1950s, against the use of multi-tasking in the 70s, against the use of windowsystems in the 80s, and against many other innovations.) More specifically, inheritanceand polymorphism seem to be especially offending in this regard; for example, so-calledinheritance anomalies have been particularly worrisome. It is interesting to note that theother OO features have been around and used for a longer period of time, and are thus moremature.

At this point, there is an overwhelming amount of evidence for further supporting thestudy and development of OORTS. We present some of this evidence below. In each case,we note the existence and application of specific systems that use OO ideas, and point outthe relevance to OORTS; the cited references provide more details. An appendix discussesreal-time inheritance anomalies.

* c©Kluwer Academic Publishers, Boston. This paper was presented at the 22nd IFAC/IFIP Workshop on RealTime Programming, Lyon, September 15–17, 1997. Real-Time Systems is an IFAC-affiliated journal.

72 SHAW

2. The Evidence

2.1. Executable OO Methods for Specification and Modelling

At the design stage, object orientation is becoming a preferred approach, especially withthe availability of accompanying software tools. Well-publicized examples include objectmodelling with statecharts and the ROOM language and system (e.g., Selic et al., 1994).This kind of OO modelling also demonstrates how both hardware and software, as well asthe interfaces between them, can be described uniformly with interacting objects.

2.2. OO Programming Languages With Concurrency and Exceptions

Many mechanisms needed for real-time programming, particularly those required to handleconcurrency and fault detection and recovery, appear in standard OO languages and exten-sions. The widespread use of such mechanisms is compelling evidence that they can berealized and applied in practical OO settings. (We note that these standard OO languages,and their implementations and applications, are not always concerned with predictabilityand efficiency.) Most prominent are the Java language and the many concurrent exten-sions to C++, and their exception constructs. Some ways to handle inheritance anomalies,for example, those related to synchronization constraints, are addressed in a Java text onconcurrent programming (Lea, 1997).

2.3. Semi-OO Operating Systems

A number of operating systems have been written using many OO features, but excludinginheritance and polymorphism. A widely-used popular commercial example of a generalpurpose OS is NT (Custer, 1993). The OO framework is cited as particularly useful forensuring protection and security. Mach is an earlier OO OS that has been very influential,as well as successful. The process/ADT OS is a research real-time OS with simple objects(Callison and Shaw, 1991). Here the object model permitted an implementation where thehardware/software boundaries could be easily changed, and where target hardware couldbe simulated on a development machine.

2.4. Real-Time OO Programming Languages

There exist several programming languages designed specifically for real-time applicationsand used for research, government, and industrial systems. Ada 95 is the best knownexample; implementations require timing and resource predictability (Real-Time SystemsAnnex), and Ada-generated systems will no doubt eventually be efficient. RTC++, anextension of C++, has been used for building research systems (Ishikawa et al., 1992). TheJuly 1996 issue of theJournal of Parallel and Distributed Computingis devoted entirelyto OORTS, containing for example, articles on real-time Actors (Ren et al., 1996) and

OBJECT-ORIENTED REAL-TIME SYSTEMS 73

RealTimeTalk, a real-time language based on Smalltalk (Erikkson et al., 1996). A paper inthat issue by Bergmans and Aksit also discusses solutions to inheritance anomoly problemscaused by synchronization and real-time constraints; their solution is to use three differentkinds of “composition filters” which intercept messages or method calls.

2.5. Real-Time OO Operating Systems (OS)

Research in real-time OO OS has shown that predictability and scheduling control neednot be sacrificed with an OO approach. Examples of these systems are Chaos (Gheithand Schwan, 1995) and Maruti-II (Saksena et al., 1995). As an example, Chaos supportsfour primitive object classes: passive ADTs, active ADTS (executed by a thread), monitors(passive synchronized concurrent objects), and tasks (which behave like Ada tasks). Chaosalso provides support for atomic computations in a general multiprocessor environment.

3. Conclusions

The hope is that the proper use of OO methods may enhance, rather than impede predictabil-ity, and that efficiency need not be sacrificed. The evidence so far indicates that this hopecan be realized. In addition, the usual benefits of OO, such as code reuse and portability,should also be achievable for real-time applications.

Appendix

Synchronization and Timing Inheritance Anomalies: An Example and Solution

Generally, the term “inheritance anomaly” refers to a situation where defining a new methodor overriding an inherited method in a subclass requires that many other changes be made inthe class (Bergmans and Aksit, 1996). Synchronization and timing inheritance anomaliesoccur when new constraints are imposed in inherited classes. This problem is not uniqueto real-time systems but can occur in any OO system with concurrency. An example is areal-time bounded buffer (inspired by similar examples in (Ren et al., 1996) and (Bergmansand Aksit, 1996)). The standard bounded buffer has at least two operations or methods, aDEPOSIT and a REMOVE, with synchronization constraints that only permit a DEPOSITif there are free slots available and a REMOVE if there is at least one full slot.

Suppose now that we wish to modify the constraints so that REMOVEs cannot directlyfollow one another (every REMOVE has to be directly preceded by a DEPOSIT—i.e., thesequence of accepted methods must satisfy the path expression(DEPOSIT+REMOVE)∗),and there must be a time delay of DELTAT between the execution of any two operations.

To implement this with a conventional OO system requires that one rewrite both theDEPOSIT and REMOVE methods to include some history and other data. For example, onemight add a variable IWAS CALLED LAST with 2 values, “DEPOSIT” and “REMOVE”,and a time variable indicating the time of the last method execution.

74 SHAW

More straightforward solutions that do not require any changes to the class methodsDEPOSIT and REMOVE are given in the cited articles above; for example (Ren et al.,1996)’s RTsynchronizer mechanism with “patterns” and “asserts” allows access to stateand timing history. (If a system provides programming support for time-stamped eventhistories, for example, functions to access a finite history of the most recent events withtheir associated values and occurrence times, then this history information can be accesseddirectly (Shaw, 1997).)

References

Bergmans, L. and Aksit, M. 1996. Composing synchronization and real-time constraints.J. of Parallel andDistributed Computing36(1): 32–52.

Callison, H. and Shaw, A. 1991. Building a real-time kernel.Software-Practice and Experience21(4): 337–354.Custer, H. 1993.Inside Windows NT. Microsoft Press.Eriksson et al. 1996. An overview of RealTimeTalk, a design framework for real-time systems.J. of Parallel and

Distributed Systems36(1): 66–80.Geith, A. and Schwan, K. 1995. Chaos-arc: Real-time objects and atomicity for multiprocessors. InAdvances in

Real-Time Systems, Son, S., ed. Chapter 3, pp. 39–71.Ishikawa, Y. et al. 1992. Object-oriented real-time language design: Constructs for timing constraints.IEEE

ComputerOctober: 66–73.Lea, D. 1997.Concurrent Programming in Java. Addison-Wesley.Ren, S. et al. 1996. A modular approach to programming real-time systems.J. of Parallel and Distributed

Computing36(1): 4–12.Saksena et al. 1995. Design and implementation of Maruti-II. InAdvances in Real-Time Systems, Son, S., ed.

Chapter 4, pp. 73–102.Selic, B. et al.Real-Time Object-Oriented Modelling. Wiley.Shaw, A. Time-stamped event histories: A real-time programming object. InProc. 22nd IFAC/IFIP Workshop

on Real-Time Programming, Maranzana, M., ed. Lyon, pp. 97–100.Son, S. 1995 (ed).Advances in Real-Time Systems. Prentice-Hall.