JSR-282 SI 12.1: Associate a Scheduling Eligibility with Async Events -------------------------------------------- Last Updated: 17 July ----------------------- Summary ------------- This proposal defines more fully the RTSJ interrupt handling model and allows an execution eligibility to be associated with an AE that has been bound to a happening. The following method is added to the AE class. public SchedulingParameters bindTo(String happening, Eligibility : SchedulingParameters); Specification References ----------------------- Chapter 11: Semantics and Requirements for Asynchronous Events and their Handlers Problem being address ------------------------------ An async event occurrence may be initiated by application logic, by mechanisms internal to the RTSJ implementation (for example to trigger deadline miss or cost overrun), or by the triggering of a happening external to the JVM (such as a software signal or a hardware interrupt handler). An event occurrence is initiated in program logic by the invocation of the fire() method of an AE. The triggering of an event due to a happening is implementation dependent except as specified in POSIXSignalHandler, When fired by application code, the executed code (the code that releases the associated event handlers) runs at the execution eligibility (priority) of the SO calling the fire method. However, in the other situations, it is not clear what execution eligibility the executed code runs. Currently semantics 2 and 3 (page 384 of 2nd Edition of the book) say 2. The release of attached handlers occurs in execution eligibility order (priority order with the default PriorityScheduler) and at the active priority of the schedulable object that invoked the fire method. The release of handlers resulting from a happening or a timer must begin within a bounded time (ignoring time consumed by unrelated activities in the system). This worst-case response interval must be documented for some reference architecture. 3. The release of attached handlers is an atomic operation with respect to adding and removing handlers. This would seem to imply (in the following, "highest execution eligibility" implies higher than the execution eligibility of all application schedulable objects): a) The code that executes in response to a "happening" (that releases the ASEHs) runs at the highest execution eligibility in the system b) Assuming that a POSIX signal can be viewed as a happening, then the code that executes in response to a POSIX signal (that releases the ASEHs) runs at the highest execution eligibility in the system c) Assuming that deadline misses and cost overruns can be viewed as executing in response to a timer event (see SI-7 - for CPU-Time clocks and timers). The code that executes in response to a deadline miss and cost overrun (that releases the ASEHs) also runs at the highest execution eligibility in the system. This approach can potentially cause execution eligibility inversion. Consider for example two happenings: one that indicates an extremely high priority event in the environment (e.g. power fail), the other an interrupt for a low priority device. In the former, a single high priority event handler is released. In the latter, many lower priority sporadic handlers are released. Now if the low priority interrupt occurs before the power-fail interrupt, there is no requirement for the system to interrupt the release of the low priority handlers. Proposed Solution Summary -------------------------------------- First we need to define the interrupt handling model. ASEH are the main RTSJ mechanism for handling interrupts. These should be viewed as third-level interrupt handlers. The first-level interrupt handlers are the code that the platform executes in response to the hardware interrupt (or signal). First level interrupts are assumed to be executed at an execution eligibility (priority) dictated by the underlying platform. The second-level interrupt handler is the code that the VM implements as a result of being notified by the first-level interrupt handler that the interrupt is targeted at the RTSJ application. It's job is to find the AE and then release the associated ASEH. Proposal: The goal is to allow the second level interrupt handler to be preempted whilst responding to one first-level interrupt notification by another first-level interrupt notication if the interrupt is deemed to be more urgent. 1) Each AE that has been associated with a happening is given a execution eligibility. By default this is the highest in the system. To allow the programmer to set the execution eligibility the following method is added to the AE class: public SchedulingParameters bindTo(String happening, Eligibility : SchedulingParameters); The method returns the current execution eligibility associated with the AE. If the AE is associated with more than one happening, the execution eligibility is the highest value. This is reflected in the returned SchedulingParameters object. 2) When an event is fired (by software): the firing code occurs at an eligibility of the firing SO 3) When an interrupt occurs: the second level interrupt handler once it has identified the associated ASE executes at the defined execution eligibility for that event. 4) An implementation must allow 3) above to be preemptible when an execution eligibility is given. (probably by introducing another thread). If none is provided, then the release occur at the highest priority. 5) POSIX signal ASEH are released at the highest execution eligibility. 6) Timer releases occur at the highest execution eligibility. This would be a change from the current semantics which says: (page 384 in 2nd Edition) says: 2. The release of attached handlers occurs in execution eligibility order (priority order with the default PriorityScheduler ) and at the active priority of the schedulable object that invoked the fire method. The release of handlers resulting from a happening or a timer must begin within a bounded time (ignoring time consumed by unrelated activities in the system). This worst-case response interval must be documented for some reference architecture. 3. The release of attached handlers is an atomic operation with respect to adding and removing handlers. Discussion Points --------- Compatibility Issues --------------------