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 Java Personal Embedded
Family) (J2SE, Java Java
J2EE) (J2ME)
ROM Size 4 MB <2 MB < 512 KB

RAM Size 2 – 4 MB 512 KB – < 512 MB

1 MB
CPU 32 Bit, 32 Bit, 16/32 Bit,
100 MHz+ 50 MHz+ 25 MHz+
Real-time Java
(A brief intro)
What is Real-time Java (RTJ)?
Standard Java is not enough to handle real-
time 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. Thread scheduling and dispatching.
2. Memory management.
3. Synchronization and Resource sharing.
4. Asynchronous Event Handling.
5. Asynchronous Transfer of Control.
6. Asynchronous Thread Termination.
7. Physical Memory Access.
RTSJ Implementations
RTSJ is still under evaluation.
Sun has no practical implementation.
Some implementations by others:
- VisualAge 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)
AsyncEvent
AsyncEventHandler
AsyncEventHandler behave
like Thread. It has run()
method.
BoundAsynchronousHandler
can be used for added BoundAsyncEventHandler
timeliness by binding each
handler to a dedicated thread.
Asynchronous Event (contd.)
Event2
Event1 Event3

Handler B
Handler A

• One event can be handled by more than one handler.

• One handler can handle more than one event.
• Many to many relationship.
AsyncEvent (how it works)
Real • Handler implements
bindTo() world Schedulable and Runnable
event interfaces.
AsyncEvent
addHandler() abstract class AsyncEventHandler:
run() // final
handleAsyncEvent()
getAndDecrementPendingFireCount()

A Handler can choose to process its

fire-counts individually or collectively.
Sample code for AsyncEvent handling

public static void main(String args){

AsyncEventHandler hdlrA = new AsyncEventHandler(){
public void handleAsyncEvent(){
do{
System.out.print(“Handler A executed.”);
} while(getAndDecrementPendingFireCount()>0);
}
}
AsyncEvent Sample Code
AsyncEvent event1 = new AsyncEvent();

event1.addHandler(hdlrA);
System.out.println(“AsyncEvent Test.\n”);
event1.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
(AsynchronouslyInterruptedException)

Object

Throwable

Exception
Interruptible (I)
InterruptedException

AsynchronouslyInterruptedException
Parameter for
AIE.doInterruptible()
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
asynchronouslyInterruptedExcept
ion {…}
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
AIE caught
AIE method (catch)
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:
 Carriage (floor pos,
door open?, moving?)
 MotorControl (up,
down)
 PanelControl (buttons
pressed,next dest)
Elevator (contd.)
Events;
 A floor select button is pressed.
 Elevator request button is pressed.
 Fire alarm sounded.
Exceptions;
 Hazard (fire, blackout, etc.).
AsyncEvent classes
class ButtonEvent extends AsyncEvent{
public ButtonEvent(String bindstring){
bindTo(bindstring);
}
}
class FireAlarm extends AsyncEvent{
public FireAlarm(){
super();
bindTo("FireSignal");
}
}
Event Handlers (inner classes)
class ReqBtnHandler extends
Code
AsyncEventHandler{
int flr;
ReqBtnHandler(int f){flr=f;}
public void
handleAsyncEvent(){floorReq[flr]=true;}
}
class SelBtnHandler extends
AsyncEventHandler{
int flr;
SelBtnHandler(int f){flr=f;}
public void
handleAsyncEvent(){floorSel[flr]=true;}
Hazard Handler
(in Carriage class)
class HzHandler extends Code
AsyncEventHandler{
public void handleAsyncEvent(){
aie.fire(); // fire AIE to
interrupt control thread
// … open the door
if (curFloor==0 && !moving)
openDoor();
}
}
Linking Events to Handlers
// in PanelControl class
ButtonEvent sb0=new ButtonEvent("selbutton0"); Code //
1,2,…
ButtonEvent rb0=new ButtonEvent("reqbutton0"); //
1,2,…
sb0.addHandler(new SelBtnHandler(0)); // 1,2,…
rb0.addHandler(new ReqBtnHandler(0)); // 1,2,…
// in Carriage class Code
HzHandler hh=new HzHandler();
e.addHandler(hh); // fire alarm is stored in
attribute e of Carriage.
// similarly in PanelControl, 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 HazardAie extends
synchronouslyInterruptedException{
public HazardAie(){super();}
}
HazardAie myAie= new HazardAie();
Carriage car=new Carriage(fa,myAie);

Somebody has to fire it. So pass to

Carriage that receive the fire event
AIE handling
public class MotorControl implements
Interruptible{
….
// action when AIE is fired.
public void
interruptAction(AsynchronouslyInterrupted
Exception e){
if (carriage.getFloor()>0){
carriage.closeDoor();
godown();
}
}
MotorControl (contd.)
// action when interruptible code is run
public void
run(AsynchronouslyInterruptedException
e){
while(true){
try{myrun(e);}
catch(AsynchronouslyInterruptedExcep
tion e1){…}
}// while
}
void
myrun(AsynchronouslyInterruptedExceptio
n e)
Main body of program
public class ElevatorSim {
public static void
main(java.lang.String[] args) {
FireAlarm fa = new FireAlarm(); //
create fire alarm event
HazardAie myAie = new HazardAie();
Carriage car = new Carriage(fa,myAie);
PanelControl pc = new
PanelControl(5,fa);
MotorControl mc = new MotorControl(car,
pc, 4, 0);

myAie.doInterruptible(mc); // run
Memory Management
Purpose
To allow memory areas of different
behavior to be accessed by real-time
tasks.
Specify memory consumption behavior
of RT tasks.
RT tasks can enter and exit memory
areas and allocate objects as needed.
Memory Class Types
MemoryArea
 Heap Memory (normal Java Heap)
 Scoped Memory (limited lifetime.)
 Immortal Memory (app lifetime)
 ImmortalPhysicalMemory (app lifetime, physical)
PhysicalMemoryFactory (Supply physical
mem to other mem objects, e.g. DMA, Byte
swapping)
RawMemoryAccess (Drivers, Memory
mapped I/O)
Memory Class Hierarchy
VTMemory
Object HeapMemory
LTMemory
MemoryArea ScopedMemory
ScopedPhysicalMemory
ImmortalMemory

ImmortalPhysicalMemory

PhysicalMemoryFactory

RawMemoryAcess RawMemoryFloatAcess
Scoped Memory Rules
Reference to an object in ScopeMemory;
 Can never be stored in an object in Java Heap.
 Can never be stored in an object in
ImmortalMemory.
 Can be stored in an object in the same scope or
inner scope memory.
An object in Immortal or Heap may store
references in ScopeMemory.
ScopeMemory activation
An area of ScopeMemory can become active
for a thread by;
 Calling enter() method of ScopeMemory object.
 Creating instances of objects in ScopeMemory.
ScopeMemory 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.