Asynchronous Events and Handlers

From Wiki
Jump to navigationJump to search


  • 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 {
		} 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);
		AsyncEvent ev = new AsyncEvent();
		System.out.println("Firing 1");;
		System.out.println("Firing 2");;
  • 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 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.