Asynchronous Events and Handlers

Intro

• Interaction between real world object and their controllers can be time triggered or event triggered.
• In a time triggered system controller activates periodically to check status of object.
• In an event triggered system sensors are activated when the real world object enters certain states.
• Events are signaled via interrupts.
• Event triggered systems are more flexible.
• Time triggered systems are more predictable.
• Threads are not considered appropriate as controllers when:
  • external objects are many and their control algos are simple & non blocking. This leads to a proliferation of threads.
  • external objects are inter related and their control requires complex synchronization between the controllers. Complex commn protocols are difficult to design and may lead to deadlocks and blocking.
• Alternative is Event based programming.
• Each event has an associated handler, events are queued and their associated handler is executed.
• No need for communication among handlers as they can read/write from shared objects.
• Disadvantage:
  • Difficult to have tight DL's as long lived and non blocking handler must finish before a high priority handler can be executed.
  • Difficult to execute handlers on a multiprocessor system as handlers assume no contention for shared resources. Since handlers cannot execute simultaneously like threads.

RTSJ Approach

• Provides real time Asynchronous Events (AE's) and associated handlers (AEH).
• AE's are data less happening and are fired by the program or associated with occurrence of interrupts in the environment.
• Association betwen AE's and AEH's is dynamic. 1 AE can have many AEH. 1 AEH can be for many AEs.
• Each AEH has a count of fired events, When an event is fired, counter is atomically incremented.
• The fireCount field holds the number of times associated instances of AsyncEvent have occurred that have not had the method handleAsyncEvent() invoked.
• The handler is then released.

• ASEH has set of methods that allow to manipulate the fire count.
• The handler code is in handleAsyncEvent() unless a Runnable object is supplied to the AEH constructor.
• ASEH itself has a run() method which is called by system when AE is fired. So run() internally calls handleAsyncEvent() repeatedly whenever fireCount > 0.
• Example:
• NOTE: ASEH by default runs in daemon mode. So the program terminates when main terminates. To avoid this it must be made non daemon.

class MyAEH extends AsyncEventHandler {
	
	public MyAEH(SchedulingParameters scheduling, ReleaseParameters release,
			MemoryParameters memory, MemoryArea area,
			ProcessingGroupParameters group, boolean nonheap) {
		super(scheduling, release, memory, area, group, nonheap);
	}

	public void handleAsyncEvent() {
		try {
			Thread.sleep(3000);
		} catch (InterruptedException e) {
		}
		System.out.println("Handled an event. Pending fire count : " + getPendingFireCount());
	}
}

public class AEH1 {

	public static void main(String[] args) throws InterruptedException {
		
		AsyncEventHandler myAeh = new MyAEH(new PriorityParameters(25), new PeriodicParameters(new RelativeTime(5000,0)), null, null, null, false);
		myAeh.setDaemon(false);
		
		AsyncEvent ev = new AsyncEvent();
		
		ev.addHandler(myAeh);
		
		Thread.sleep(1000);
		System.out.println("Firing 1");
		
		ev.fire();
		Thread.sleep(500);
		System.out.println("Firing 2");
		ev.fire();
	}
}

• Both RT Thread's and AEH's are Schedulable objects.
• In practice, RTT's are vehicles for AEH's.
• An AEH is bound to a server RT Thread - this is done dynamically.
• This has some overhead, so time critical AEH's can bind themself to a dedicated real time thread.
• This is done by using a BoundAsyncEventHandler object which is a subclass of AsyncEventHandler.

Timers

• Timers are AsyncEvents which allows us to generate timer events.
• The timer class is abstract, two concrete classes OneShotTimer and PeriodicTimer exist.
• Timer is flexible, it can be enabled, disabled, rescheduled.