Realtime Java Asynchronous Transfer of Control Jihua Zhong

Real-time Java & Asynchronous Transfer of Control Jihua Zhong Marc E Loy Maung Han Seminor in Real-time Systems Instructor: Professor Insup Lee

Different Flavours of Java (Java Family) ROM Size Java (J 2 SE, J 2 EE) 4 MB RAM Size 2 – 4 MB CPU Personal Java (J 2 ME) <2 MB 512 KB – 1 MB 32 Bit, 100 MHz+ 50 MHz+ Embedded Java < 512 KB < 512 MB 16/32 Bit, 25 MHz+

Real-time Java (A brief intro)

What is Real-time Java (RTJ)? Standard Java is not enough to handle realtime constraints. Java (and JVM) lacks semantic for standard real-time programming techniques. Embedded Java Specification was there, but merely a subset of standard Java API. There is a gap for a language real-time capable and equipped with all Java’s powerful advantages.

Real-time Spec. for Java (RTSJ) IBM, Sun and other partners formed Real-time for Java Expert Group sponsored by NIST in 1998. It came up with RTSJ to fill this gap for real-time systems. RTSJ proposed seven areas of enhancements to the standard Java.

RTSJ – 7 Areas of Enhancement 1. 2. 3. 4. 5. 6. 7. Thread scheduling and dispatching. Memory management. Synchronization and Resource sharing. Asynchronous Event Handling. Asynchronous Transfer of Control. Asynchronous Thread Termination. Physical Memory Access.

RTSJ Implementations RTSJ is still under evaluation. Sun has no practical implementation. Some implementations by others: - Visual. Age by IBM - Simple RTJ by RTJ Computing There’s another spec by J-consortium backed by Microsoft, HP. Other just sit on the fence.

Asynchrony

Asynchrony Asynchronous event handling and transfer of control in execution. Not all real-life events are predictable in time and frequency. Ability of real-time systems to react to them correctly requires reliable asynchrony techniques.

Asynchrony (contd. ) Conventional ways of achieving it in Java is by interrupts and exceptions. They are deadlock prone. Can cause data structure corruption.

Asynchrony (contd. ) Leaving exiting techniques intact for conventional codes, RTSJ offers two extended approaches for real-time threads 1. Asynchronous Events (AEv). 2. Asynchronously Interrupted Exceptions (AIE).

I. Asynchronous Events Some internal or external event that happens. System need to respond to the changing environment. Not known in advance about time or frequency.

Class Hierarchy Runnable (I) Object Schedulable (I) Async. Event. Handler behave like Thread. It has run() method. Bound. Asynchronous. Handler can be used for added timeliness by binding each handler to a dedicated thread. Async. Event. Handler Bound. Async. Event. Handler

Asynchronous Event (contd. ) Event 1 Handler A Event 2 Event 3 Handler B • One event can be handled by more than one handler. • One handler can handle more than one event. • Many to many relationship.

Async. Event (how it works) bind. To() Async. Event add. Handler() Real world event • Handler implements Schedulable and Runnable interfaces. abstract class Async. Event. Handler: run() // final handle. Async. Event() get. And. Decrement. Pending. Fire. Count() A Handler can choose to process its fire -counts individually or collectively.

Sample code for Async. Event handling public static void main(String args){ Async. Event. Handler hdlr. A = new Async. Event. Handler(){ public void handle. Async. Event(){ do{ System. out. print(“Handler A executed. ”); } while(get. And. Decrement. Pending. Fire. Count()>0); } }

Async. Event Sample Code Async. Event event 1 = new Async. Event(); event 1. add. Handler(hdlr. A); System. out. println(“Async. Event Test. n”); event 1. fire(); System. out. println(“Event fired. n”); } // main()

Use of AEv Handling In real-time systems, there can be hundreds (or even thousands) of possible events. But usually, only few happens at one time. Impractical to create and assign one thread for each possible event. AEv Handling offers low cost alternative to threads. Not like methods, AEv handlers can be scheduled and executed asynchronously.

II. ATC (Asynchronous Transfer of Control) Some change in the system environment needs immediate attention. Abandon current execution or take appropriate action.

AIE (Asynchronously. Interrupted. Exception) Object Throwable Exception Interruptible (I) Parameter for AIE. do. Interruptible() Interrupted. Exception Asynchronously. Interrupted. Exception Timed

AIE (contd. ) In RT Java, ATC is achieved by throwing a special exception “AIE”. RT threads and methods can choose to receive (or not to) AIE by including it in throws clause. e. g. void run() throws asynchronously. Interrupted. Exception {…} Existing Non-RT implementations are not affected.

AIE (contd. ) AIE can be thrown to cut short a thread’s execution and take appropriate action. It can be thrown explicitly by “firing” in program codes, or implicitly by “interrupting” a real-time thread. e. g. aie. fire() or thread. interrupt() If AIE is fired in a methods it did not declare AIE in “throws clause”, AIE is put to pending state until control reaches AIE-enabled method.

Some rules on AIE Only one AIE can become active at any one time, no nested AIEs. If newly generated AIE is less in depth than the pending AIE, it is replaced by new one. If newly generated AIE is deeper in depth, it is discarded.

How AIE works Stack top AIE method (catch) AIE caught and cleared Non-AIE method AIE fired AIE method Deferred until AIE method AIE Handler should invoke the AIE. happened() method to clear it. Otherwise, it will continue to propagate outward.

When AIE is deferred In AIE methods, it is deferred if control is in synchronized block. In non-AIE methods, deferred until control reaches in AIE method. If both AIE and other exceptions occurred when control enters AIE method, AIE overrides others.

When AIEs overlap Another AIE can get generated while one is in execution. If AIE of outer block is fired, execution stops and control transfers to outer block.

Asynchronous Thread Termination AEv and AIE in RTJ provides ways to manage execution loci in real-time systems asynchronously. Using these two together can achieve asynchronous termination of threads.

Sample Implementation Single Elevator Control system. Separate classes for: n n n Carriage (floor pos, door open? , moving? ) Motor. Control (up, down) Panel. Control (buttons pressed, next dest)

Elevator (contd. ) Events; n n n A floor select button is pressed. Elevator request button is pressed. Fire alarm sounded. Exceptions; n Hazard (fire, blackout, etc. ).

Async. Event classes class Button. Event extends Async. Event{ public Button. Event(String bindstring){ bind. To(bindstring); } } class Fire. Alarm extends Async. Event{ public Fire. Alarm(){ super(); bind. To("Fire. Signal"); } }

Event Handlers (inner classes) class Req. Btn. Handler extends Async. Event. Handler{Code int flr; Req. Btn. Handler(int f){flr=f; } public void handle. Async. Event(){floor. Req[flr]=true; } } class Sel. Btn. Handler extends Async. Event. Handler{ int flr; Sel. Btn. Handler(int f){flr=f; } public void handle. Async. Event(){floor. Sel[flr]=true; } }

Hazard Handler (in Carriage class) class Hz. Handler extends Async. Event. Handler{ Code public void handle. Async. Event(){ aie. fire(); // fire AIE to interrupt control thread // … open the door if (cur. Floor==0 && !moving) open. Door(); } }

Linking Events to Handlers // in Panel. Control class Button. Event sb 0=new Button. Event("selbutton 0"); // 1, 2, … Code Button. Event rb 0=new Button. Event("reqbutton 0"); // 1, 2, … sb 0. add. Handler(new Sel. Btn. Handler(0)); // 1, 2, … rb 0. add. Handler(new Req. Btn. Handler(0)); // 1, 2, … // in Carriage class Hz. Handler hh=new Hz. Handler(); Code e. add. Handler(hh); // fire alarm is stored in attribute e of Carriage. // similarly in Panel. Control, share the same event. Need to link every single event and handler, cannot differentiate between different events of the same class. Better if we can pass instance specific data along with event. But RTSJ does not allow that.

AIE exception class Hazard. Aie extends synchronously. Interrupted. Exception{ public Hazard. Aie(){super(); } } Hazard. Aie my. Aie= new Hazard. Aie(); Carriage car=new Carriage(fa, my. Aie); Somebody has to fire it. So pass to Carriage that receive the fire event

AIE handling public class Motor. Control implements Interruptible{ …. // action when AIE is fired. public void interrupt. Action(Asynchronously. Interrupted. Exception e){ if (carriage. get. Floor()>0){ carriage. close. Door(); godown(); } }

Motor. Control (contd. ) // action when interruptible code is run public void run(Asynchronously. Interrupted. Exception e){ while(true){ try{myrun(e); } catch(Asynchronously. Interrupted. Exception e 1){…} }// while } void myrun(Asynchronously. Interrupted. Exception e) throws Asynchronously. Interrupted. Exception { // … normal control sequence }

Main body of program public class Elevator. Sim { public static void main(java. lang. String[] args) { Fire. Alarm fa = new Fire. Alarm(); // create fire alarm event Hazard. Aie my. Aie = new Hazard. Aie(); Carriage car = new Carriage(fa, my. Aie); Panel. Control pc = new Panel. Control(5, fa); Motor. Control mc = new Motor. Control(car, pc, 4, 0); my. Aie. do. Interruptible(mc); // run interruptible code } }

Memory Management

Purpose To allow memory areas of different behavior to be accessed by real-time tasks. Specify memory consumption behavior of RT tasks can enter and exit memory areas and allocate objects as needed.

Memory Class Types Memory. Area n n Heap Memory (normal Java Heap) Scoped Memory (limited lifetime. ) Immortal Memory (app lifetime) Immortal. Physical. Memory (app lifetime, physical) Physical. Memory. Factory (Supply physical mem to other mem objects, e. g. DMA, Byte swapping) Raw. Memory. Access (Drivers, Memory mapped I/O)

Memory Class Hierarchy Object Memory. Area Heap. Memory Scoped. Memory Immortal. Memory VTMemory LTMemory Scoped. Physical. Memory Immortal. Physical. Memory. Factory Raw. Memory. Acess Raw. Memory. Float. Acess

Scoped Memory Rules Reference to an object in Scope. Memory; n n n Can never be stored in an object in Java Heap. Can never be stored in an object in Immortal. Memory. Can be stored in an object in the same scope or inner scope memory. An object in Immortal or Heap may store references in Scope. Memory.

Scope. Memory activation An area of Scope. Memory can become active for a thread by; n n Calling enter() method of Scope. Memory object. Creating instances of objects in Scope. Memory areas can be activated in nested manner. Objects in an inner scope can refer to outer scopes, but not the other way.

Conclusion Java is trying to become real-time capable. Most systems today are either non real-time or implement only a subset of RTSJ. We expect to see more complete and robust implementations soon with increasingly popular embedded and real-time systems.