Asynchronous Event Handling and Real- time Threads in the Real-time Specification for Java* A.J. Wellings and A. Burns Department of Computer Science, University of York, YOlO 5DD, U .K. Email: {andy, burns}@cs.york.ac.uk Abstract the controller via interrupts. For example, a robot may trip a switch when it reaches a certain position. This paper discusses the role and implementation of This is a signal to the controller that the power to asynchronous event handlers in the Real-time speci- the motor should be turn off, thereby bringing the fication for Java (RTSJ). For non-blocking handlers, robot to a halt. an implementation model whereby all heap-using han- The system designer often has a choice on whether dlers are serviced by a single thread and all no-heap to implement the control algorithm as a time trig- handlers are serviced by another server thread is pro- gered or event triggered one. Event triggered systems posed and schedulability analysis is derived. The are often more flexible whereas time triggered system model is shown to have bounded priority inversion. are more predictable (Kopetz, 1997; Burns, 2002). In General multiple-server models are needed for non- either case, the controller is usually represented as a blocking handlers but the support in the RTSJ is crit- thread. However, there are occasions where this is icised as lacking in configurability. A solution is pro- not appropriate. These include (Ousterhout, 2002; posed which allow the number of servers to be spec- van Renesse, 1998) when: ified, and the allocation of handlers to servers to be controlled. ."!It:;-+1.~ t:;A"t:;L!laL~.,+~--~1 UUJt:;l;""~1.:--+~ aLt:; LLLaLLyaLLU 3 ,-1.-:-LJl~Jl l;UJlLruJ---,--l., algorithms are simple and non blocking, and 1 Introd uction .the external objects are inter-related and their collective control requires significant communi- One of the main reasonsfor a real-time programming cation and synchronization between the con- language to support concurrency is to facilitate the trollers. modelling of parallelism in the real world (Burns and Wellings, 2001). For example, within embeddedsys- In the former case, using a thread per controller leads tem design,the controllers for real world objects such to a proliferation of threads along with the associated as conveyorbelts, enginesand robots are represented per thread overhead. In the latter case, complex com- as threads in the program. The interaction between munication and synchronization protocols are needed the real world objects and their controllers can be which can be difficult to design correctly and may either time triggered or event triggered. In a time lead to deadlock or unbounded blocking. triggered systems,the controller is activated periodi- An alternative to thread-based programming is cally. It sensesthe environment in order to determin- event-based programming. Each event has an asso- ing the status of the real-time object it is controlling. ciated handler. When events occur, they are queued Based on its findings, it writes to actuators which and a server thread takes an event from the queue are able to affect the behaviour of the object. For ex- and executes its associated handler to completion. ample, a robot controller may determine the position When the handler has finished, the server takes an- of a robot via a sensor and decide that it must cut other event from the queue, executes the handler and the power to a motor thereby bringing the robot to so on. The execution of the handlers may generate a halt. In an event triggered system, sensorsin the further events. With this model, there is only one environment are activated when the real world object thread -the server thread. There is no need for ex- enters into certain states. The events are signalled to plicit communication between the handlers as they .Javais a trademarkof SunMicrosystems. can simply read and write from shared objects with- Proceedings of the Eighth IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’02) 0-7695-1739-0/02 $17.00 © 2002 IEEE out contention. The disadvantage of controlling all The ReleaseParameters class is a base abstract class external objects by event handlers include: and gives the general parameters that all schedula- ble objects need. A schedulable object can have a .it is difficult to have tight deadlines associated deadline and a cost associated with each time it is with event handlers as a long-lived or blocking released for execution, along with handlers for their handler must terminate before the server can ex- overrun. The cost is the amount of execution time ecute any newly arrived high-priority handlers; that a scheduler should give to the object. If the ob- ject is still executing when either its deadline or its .it is difficult to execute the handlers on a multi- cost expires, an associated event handler is scheduled. processorsystem as the handlers assumeno con- It should be noted that the RTSJ does not require tention for shared resources. an implementation to support execution-time moni- One of the main examples often quoted as requiring toring. However, it does require it to detect missed an event-handling system is the implementation of a deadlines. Of course, a program can indicate that it graphical user interface. For example, standard Java is not concerned with a missed deadline by passing a supports threads but its Swing and AWT toolkits are null handler. Subclasses of the ReleaseParameters event based. class support periodic, aperiodic and sporadic release In an attempt to provide the flexibility of threads parameters. and the efficiency of event handling, the Real-Time The Scheduling Parameters is a null abstract Specification for Java (RTSJ) (Bollella et al., 2000) class. It has subclasses for the definition of prior- has introduced the notion of real-time asynchronous ity parameters and important parameters. All RTSJ events and associatedhandlers. However, the spec- implementations are required to support at least 28 ification is silent on how these events can be imple- unique real-time priority levels. However, there is mented and how their timing requirements can be no defined values for the importance parameters. guaranteed. As the RTSJ is likely to becomea stan- The only scheduler that the RTSJ requires is a pre- dard implementation language for real-time applica- emptive priority-based one. tions, a detailed assessmentof its facilities is timely. Essentially there are two types of schedulable ob- The goal of this paper is to explore how RTSJ real- jects: real-time threads and asynchronous event han- time events can be implemented and integrated with dlers. Each AsyncEvent can have one or more han- the scheduling of real-time threads. In section 2, and dlers. When the event occurs {indicated by a call to overview of the RTSJ event handling model is pre- the fire method), all the handlers associated with sented. The only schedulingpolicy required by RTSJ the event are scheduled for execution according to is priority-based scheduling; section 3, therefore, con- their Scheduling Parameters. Note that the firing siders a priority-based implementation of event han- of an event can also be associated with the occur- dlers. Section 4 then developsthe responsetime anal- rence of an implementation-dependent external ac- ysis for this implementation model. Section 5 extends tion by using the bindTo method. Subclasses of the the model by considering multiple serversand bound AsyncEvent class provide time-triggered events. Fig- event handlers. Finally, conclusions are presentedin ure 1 illustrates the event class hierarchy. Section 6. Each handler is scheduled once for each outstand- ing event firing. However, the handler can modify the number of outstanding events by using the methods 2 The Event Handling Model in the AsyncEventHandler class. Although an event handler is a schedulable entity Objects which are to be scheduledin RTSJ must im- {i.e. at some point it must be executed by a thread), plement the Schedulable interface and specify: the intention of the RTSJ is that it will not suffer the same overhead as an application thread. Conse- .their memory requirements via the class quently, it cannot be assumed that there is a sepa- MemoryParameters-not consideredin this pa- rate implementation thread for each handler, as more per; than one handler may be associated with a partic- ular implementation thread. If a dedicated thread .their timing requirements via the class is required, the BoundAsyncEventHandler should be ReleaseParameters; used. However, other event handlers may also be .their scheduling requirements via the class associated with that thread. Figure 2 illustrates the event handler class and its relationship to other Scheduling Parameters; classes. Proceedings of the Eighth IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS’02) 0-7695-1739-0/02 $17.00 © 2002 IEEE Figure 1: Event class in RTSJ 3 Implemention Issues At the other extreme, a single server real-time thread could be used to execute all event handlers. The key challenge in implementing event handlers is This approach is illustrated in Figure 3. to limit the number of threads without jeopardising There are two main issues associated with this ap- the schedulability of the overall system. Further- proach: more, the RTSJ requires pre-emptive priority-based I. the order of the event handler queue scheduling of all schedulable objects. If interpreted strictly, this requires a high priority event handler to 2. the priority of the server pre-empt a low priority event handler. This severely To enable effective schedulability analysis, the event limits the freedom of the implementation and, ar- handler queue should be priority ordered. Note that guably, removesone of the motivations for an event for event firing, zero, one or more handlers may be handling paradigm (i.e.