Design of the Real-Time Specification in Java
- Scheduling
- Memory Management
- Synchronization
- Asynchronous Event Handling
- Asynchronous Transfer of Control
- Asynchronous Thread Termination
- Physical Memory Access
- Exceptions
- Minimum Implementations of the RTSJ
- Optionally Required Components
- Documentation Requirements
- Parameter Objects
- Java Platform Dependencies
The RTSJ comprises eight areas of extended semantics. This chapter explains each in fair detail. Further detail, exact requirements, and rationale are given in the opening section of each relevant chapter. The eight areas are discussed in approximate order of their relevance to real-time programming. However, the semantics and mechanisms of each of the areas — scheduling, memory management, synchronization, asynchronous event handling, asynchronous transfer of control, asynchronous thread termination, physical memory access, and exceptions — are all crucial to the acceptance of the RTSJ as a viable real-time development platform.
Scheduling
One of the concerns of real-time programming is to ensure the timely or predictable execution of sequences of machine instructions. Various scheduling schemes name these sequences of instructions differently. Typically used names include threads, tasks, modules, and blocks. The RTSJ introduces the concept of a schedulable object. Any instance of any class implementing the interface Schedulable is a schedulable object and its scheduling and dispatching will be managed by the instance of Scheduler to which it holds a reference. The RTSJ requires three classes that are schedulable objects; RealtimeThread, NoHeapRealtimeThread, and AsyncEventHandler.
By timely execution of threads, we mean that the programmer can determine by analysis of the program, testing the program on particular implementations, or both whether particular threads will always complete execution before a given timeliness constraint. This is the essence of real-time programming: the addition of temporal constraints to the correctness conditions for computation. For example, for a program to compute the sum of two numbers it may no longer be acceptable to compute only the correct arithmetic answer but the answer must be computed before a particular time. Typically, temporal constraints are deadlines expressed in either relative or absolute time.
We use the term scheduling (or scheduling algorithm) to refer to the production of a sequence (or ordering) for the execution of a set of threads (a schedule). This schedule attempts to optimize a particular metric (a metric that measures how well the system is meeting the temporal constraints). A feasibility analysis determines if a schedule has an acceptable value for the metric. For example, in hard real-time systems the typical metric is "number of missed deadlines" and the only acceptable value for that metric is zero. So called soft real-time systems use other metrics (such as mean tardiness) and may accept various values for the metric in use.
Many systems use thread priority in an attempt to determine a schedule. Priority is typically an integer associated with a thread; these integers convey to the system the order in which the threads should execute. The generalization of the concept of priority is execution eligibility. We use the term dispatching to refer to that portion of the system which selects the thread with the highest execution eligibility from the pool of threads that are ready to run. In current real-time system practice, the assignment of priorities is typically under programmer control as opposed to under system control. The RTSJ's base scheduler also leaves the assignment of priorities under programmer control. However, the base scheduler also inherits methods from its superclass to determine feasibility. The feasibility algorithms assume that the rate-monotonic priority assignment algorithm has been used to assign priorities. The RTSJ does not require that implementations check that such a priority assignment is correct. If, of course, the assignment is incorrect the feasibility analysis will be meaningless (note however, that this is no different than the vast majority of real-time operating systems and kernels in use today).
The RTSJ requires a number of classes with names of the format <string>Parameters (such as SchedulingParameters). An instance of one of these parameter classes holds a particular resource demand characteristic for one or more schedulable objects. For example, the PriorityParameters subclass of SchedulingParameters contains the execution eligibility metric of the base scheduler, i.e., priority. At some times (thread create-time or set (reset)), later instances of parameter classes are bound to a schedulable object. The schedulable object then assumes the characteristics of the values in the parameter object. For example, if a PriorityParameter instance that had in its priority field the value representing the highest priority available is bound to a schedulable object, then that object will assume the characteristic that it will execute whenever it is ready in preference to all other schedulable objects (except, of course, those also with the highest priority).
The RTSJ is written so as to allow implementers the flexibility to install arbitrary scheduling algorithms and feasibility analysis algorithms in an implementation of the specification. We do this because the RTJEG understands that the real-time systems industry has widely varying requirements with respect to scheduling. Programming to the Java platform may result in code much closer toward the goal of reusing software written once but able to execute on many different computing platforms (known as Write Once, Run Anywhere) and that the above flexibility stands in opposition to that goal, The Real-Time Specification for Java also specifies a particular scheduling algorithm and semantic changes to the JVM that support predictable execution and must be available on all implementations of the RTSJ. The initial default and required scheduling algorithm is fixed-priority preemptive with at least 28 unique priority levels and will be represented in all implementations by the PriorityScheduler subclass of Scheduler.