MinSeong Kim

Processing group parameters in the real-time specification for Java

The Real-Time Specification for Java (RTSJ) supports Processing Groups. However this typically requires the underlying operating system to provide group budgets, which is not widespread practice. As the RTSJ attempts to define its semantics for multiprocessor systems, the issue of the meaning and implementability of the ProcessingGroupParameters class needs to be re-examined. This paper reviews the possible options. It proposes that Processing Groups be directly represented with various subclasses providing different implementation mechanisms. The relationship between Processing Groups and the implementation of non-bound asynchronous event handlers is also explored.

An efficient and predictable implementation of asynchronous event handling in the RTSJ

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 real-time 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.

Efficient asynchronous event handling in the real-time specification for Java

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 requires further elaboration is asynchronous event handling (AEH). The primary goal for handlers in the RTSJ is to have a lightweight concurrency mechanism. Some implementation will, however, simply map a handler to a real-time thread and this results in undermining the original motivations and introduces performance penalties. However it is generally unclear how to map handlers to real-time threads effectively. Also the support for nonblocking handlers in the RTSJ is criticized as lacking in configurability as implementations are unable to take advantage of them. This article, therefore, examines the AEH techniques used in some popular RTSJ implementations and proposes two efficient AEH models for the RTSJ. We then define formal models of the RTSJ AEH implementations using the automata formalism provided by the UPPAAL model checking tool. Using the automata models, their properties are explored and verified. In the proposed models, blocking and nonblocking handlers are serviced by different algorithms. In this way, it is possible to assign a real-time thread to a handler at the right time in the right place while maintaining the fewest possible threads overall and to give a certain level of configurability to AEH. We also have implemented the proposed models on an existing RTSJ implementation, jRate and executed a set of performance tests that measure their respective dispatch and multiple-handler completion latencies. The results from the tests and the verifications indicate that the proposed models require fewer threads on average with better performance than other approaches.

Asynchronous event handling in the real-time specification for Java

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.

Asynchronous event handling and safety critical Java

Over the last few years, JSR 302 has been developing a subset of Java augmented by the RTSJ for use in safety critical systems. The concurrency model supported by Safety Critical Java (SCJ) relies, almost exclusively, on an event-based model rather than a thread-based model. This paper reviews the advantages and disadvantages of the two models and gives the pragmatic reasons why SCJ has adopted the former model. It argues that by basing the SCJ classes on the RTSJs BoundAsyncEvent class, some inconsistencies exist between the SCJ and the RTSJ models. Furthermore, some of the optimization that are possible when mapping handlers to server threads are inhibited, even though the programming restrictions necessary for these optimization are imposed by the SCJ specification. A revised model is presented that has a slightly more complicated API but is more consistent with the RTSJ and does allow the optimizations. However, there is a resulting increase in the necessary run-time support, particularly for multiprocessor implementations.

Refactoring Asynchronous Event Handling in the Real-Time Specification for Java

The primary goal for asynchronous event handling (AEH) in the Real-Time Specification for Java (RTSJ) is to have a lightweight concurrency mechanism. However the RTSJ neither provides a well-defined guideline on how to implement AEH nor requires the documentation of the AEH model used in the implementation. Also the AEH API in the RTSJ are criticized as lacking in configurability as they do not provide any means for programmers to have fine control over the AEH facilities, such as the mapping between real-time threads and handlers. For these reasons, it needs the refactoring of its application programming interface (API) to give programmers more configurability. This paper, therefore, proposes a set of AEH related classes and interfaces to enable flexible configurability over AEH components. We have implemented the refactored configurable AEH API using the new specifications on an existing RTSJ implementation and this paper shows that it allows more configurability for programmers than the current AEH API in the RTSJ does. Consequently programmers are able to specifically tailor the AEH subsystem to fit their applications’ particular needs.

Asynchronous event handling and Safety Critical Java

Over the last few years, the Java Community Process (under the auspices of Java Specification Request 302) has been developing a subset of Java augmented by the Real‐Time Specification for Java (RTSJ) for use in safety critical systems. The concurrency model supported by Safety Critical Java (SCJ) relies almost exclusively on an event‐based model rather than on a thread‐based model. This paper reviews the advantages and disadvantages of the two models and gives the pragmatic reasons that SCJ has adopted the former model. It describes the SCJ approach and gives a simple example of how it can be used, illustrating the difference in style between the RTSJ and SCJ code. The paper then considers the compatibility of the SCJ model with the RTSJ. It argues that by basing the SCJ classes on the RTSJs BoundAsyncEvent class, some inconsistencies exist between the SCJ and the RTSJ models. Furthermore, some of the optimizations that are possible when mapping handlers to server threads are inhibited, even though the programming restrictions necessary for these optimizations are imposed by the SCJ specification. A revised model is presented that has a slightly more complicated API but is more consistent with the RTSJ and allows the optimizations. However, there is a resulting increase in the necessary run‐time support, particularly for multiprocessor implementations. Copyright

Using the executor framework to implement asynchronous event handling in the RTSJ

The concurrency utilities in the Java library supply a feature called the executor framework that initiates and controls the execution of threads. It provides many adjustable parameters and extensibility hooks to be useful across a wide range of contexts for specifically configuring a pool of threads to execute submitted runnables depending on the applications specific needs. The Real-Time Specification for Java (RTSJ) supports asynchronous event handling (AEH), where the mapping of handlers to server threads is performed by the real-time JVM. In the past we have criticized the RTSJ facility as it lacks user configurability. Two simple changes to the RTSJ model would allow the user to provide their own policy for mapping handlers to server threads using the executor framework. Although the executor framework is not RTSJ-aware it is very flexible. This paper therefore discusses the feasibility of using the framework to implement various AEH mapping models. We first identify the issues associated with adapting the executor framework to AEH in the RTSJ. Based on the findings, we propose a blueprint on how the framework can be incorporated with AEH in the RTSJ with real-time guarantees. By doing so, the programmer can be given comprehensive configurability over the pool of threads provided by the executor framework to execute asynchronous event handlers in the RTSJ with realtime guarantees.

Multiprocessors and Asynchronous Event Handling in the Real-Time Specification for Java

The Real-Time Specification for Java (RTSJ) is silent on multiprocessor issues. It attempts not to preclude multiprocessor implementations but provides no direct support. Many areas of the RTSJ leave an implementation considerable freedom on how it provides the defined functionality. One such area is the asynchronous event handling (AEH) model. Events are fired and associated handlers are scheduled for execution in response; handlers have defined scheduling parameters and deadlines. The primary goal of the AEH model is to support a lightweight real-time concurrency model. Hence handlers, in general, do not have dedicated threads. Rather, the implementation is responsible for ensuring that all handlers meet their deadlines. Typically real-time threads are assigned to execute handlers by the implementation. This paper discusses the issues associated with implementing the AEH model on multiprocessor systems. The emphasis here is on achieving a lightweight model. A model is lightweight if it is able to meet the deadlines of all handlers with as few as possible real-time threads. In the RTSJ this is made more complicated because asynchronous event handlers are allowed to suspend themselves (for example, by waiting on a monitor condition). Such handlers are called blocking handlers. Most of an implementations freedom comes from being able to optimize the support for those handlers that do not block. The paper first examines all possible releasing sequences of non-blocking handlers on multiprocessor systems. Based on this, it proposes an efficient and scalable AEH mapping model for multiprocessor systems, which limits the number of real-time threads even in the worst case while retaining the schedulability of the system. The proposed model is then examined to prove its safety and liveness requirements using a model checking tool, UPPAAL. The verification and simulation results of the model indicate that the safety and liveness requirements are satisfied. Most importantly, this paper derives the proposed models greatest lower and least upper bounds of real-time threads required to execute a given number of non-blocking handlers. The greatest lower bound is equal to the number of processors, and the least upper bound is equal to the number of processors times that of the priority levels in the system. In the model, the number of real-time threads required to execute a given number of non-blocking handlers is restricted to between these two bounds depending on the releasing sequence of handlers. Even in the worst case, the model requires the least upper bound of real-time threads which is, in most cases, considerably less than the actual number of handlers in the system. This, in turn, enables the proposed model to be efficient and scalable by reducing time and space overheads, compared with a traditional 1:1 AEH mapping model where each handler is mapped to a single thread.