Applying fixed‐priority preemptive scheduling with preemption threshold to asynchronous event handling in the RTSJ

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.

Asynchronous event handling and Safety Critical Java

“…These can be classified by their runtime behaviour. The following defines the classification based on the number of handler(s) that a server executes during a single release at run‐time 20: 1:1 Mapping : An invoked server executes one handler and goes back to the waiting state where it sleeps until invoked again. The mapping can be either static or dynamic : ○ Static : Each server has a statically bound handler.…”

“…In previous work 20, 27–29 we have argued that the RTSJ lacks the facilities for the application to configure the support for asynchronous event handlers. The fact that the RTSJ does not specify constraints on the application code executed by handlers makes it very difficult for the implementation to optimize its support.…”

“…With a dynamic 1: N mapping model, the above scenario will execute using the same thread, with 32 priority changes and zero context switches. The schedulability analysis for this approach can be found in Kim and Wellings 20.…”

“…The number of active priority levels in the system can be further reduced by incorporating the notion of fixed‐priority preemptive scheduling with preemption threshold (FPPT) 32–34 with the server‐handler mapping model for the non self‐suspending handlers 20. This effectively reduces the least upper bound of server threads as it decreases the number of priority levels in the system.…”

Research on Multicore Node Performance in Wireless Sensor Network

“…Size and cost constraints on sensor nodes result in corresponding constraints on resources such as energy, memory, computational speed and communications bandwidth. A sensor node might finish many functions, such as data collection, processing, transmission, integration and reconstruction [1][2][3][4][5][6] .…”