Asynchronously happenings are crucial in real-time systems. Many real-time applications are designed with some periodic execution logics and a significant number of asynchronous events. Evidently it would not be a good performance choice if each event handler is constructed with its own thread of control. However it is generally unclear how to map threads to handlers effectively in the Real-Time Specification for Java (RTSJ). This paper, therefore, summarizes the Asynchronous Event Handler (AEH) techniques used in several popular RTSJ implementations and proposes two efficient and predictable implementations of AEH for the RTSJ. Currently the support for non-blocking handlers in the RTSJ is criticised as lacking in configurability [12] as the AEH of the RTSJ takes no advantage of non-blocking handlers. In the proposed models, non-blocking handlers are serviced by realtime threads that assume handlers may not block and blocking handlers are dealt by real-time threads that assume handlers may block. In this way it is possible to assign a thread to handlers at the right time in the right place while maintaining the least possible number of threads overall. We have implemented the proposed models on an existing RTSJ implementation, jRate. With the implementations of the models we ran a set of performance tests that measure their respective dispatch and multiple handlers completion latency. The results from the tests are promising and indicates that the proposed models have fewer threads on average with better performance than other approaches.

The Real-Time Specification for Java (RTSJ) is becoming mature. It has been implemented, formed the basis for research and used in serious applications. Some strengths and weaknesses are emerging. One of the areas that require further elaboration is asynchronous event handling. The primary goal for AsyncEventHandlers is to have a light concurrency mechanism. Some implementation will, however, simply map an AsyncEventHandler to a server thread and this results in undermining the original motivations. In this paper we closely look at some known RTSJ implementations in terms of their asynchronous event handling techniques. We also present our own model of AEH, a monitor model. We then define formal models of RTSJ AEH implementations using the automata formalism provided in the UPPAAL tool. Using the models their properties are explored and verified. The results of the verifications have shown that the current AEH systems used in some RTSJ implementations can be optimised so that the original motivations for AEH could be better achieved.

No abstract

The primary goal of asynchronous event handlers (handlers for short) in the Real‐Time Specification for Java (RTSJ) is to have a lightweight concurrency mechanism. The emphasis here is on ‘lightweightness’ which should be achieved by having fewer real‐time threads (servers for short) to execute more handlers. However, it is generally unclear how to efficiently map handlers to servers. In this paper we first define the worst case scenario that demands the least upper bound of servers for self‐suspending and non‐self‐suspending handlers. Based on the worst case scenarios, it is proved that the number of servers required to execute a given number of non‐self‐suspending handlers depends on the number of priority levels, and not on the number of handlers. It is also shown that each self‐suspending handler is required to have its own server to prevent unbounded priority inversion. Based on these results we also propose to adapt the notion of preemption threshold to further minimize the number of priority levels in the system. We have extended the non‐self‐suspending asynchronous event handling (AEH) implementation to support the fixed‐priority scheduling with preemption threshold on an existing RTSJ implementation to show that the number of servers can be further decreased while feasibly scheduling a set of non‐self‐suspending handlers, regardless of the number of the handlers or the priority levels in the system. Copyright © 2010 John Wiley & Sons, Ltd.

No abstract