The base requirements of this specification are:
javax.realtimepackage shall contain no public or protected methods not included in this specification.
javax.realtimecan safely be used concurrently by multiple threads unless it is otherwise documented.
PhysicalMemoryTypeFilteris required, but every implementation must support at least one such instance with the characteristic that it supports access to the range of physical memory that can be made accessible to the implementation.
PriorityScheduler, must be handled by the implementation such that their values cannot be resolved at compile time.
Many aspects of this specification set a minimum requirement, but permit the implementation latitude in its implementation. For instance, the required priority scheduler requires at least 28 consecutively numbered real-time priorities. It does not, however, specify the numeric value of the maximum and minimum priorities. Implementations are encouraged to offer as many real-time priority levels as they can support.
Except where otherwise specified, when this specification requires object creation the object is created in the current allocation context.
There are no bounds on extensions based on this specification, except that only extensions that conform with future versions of this specification may be implemented in the
Several optional extensions are included in this specification. An application cannot depend on these facilities in every implementation, but if an optional facility is implemented, the application may rely on it to behave as specified here. Those extensions are:
|Cost enforcement||Allows the application to control the processor utilization of a schedulable object.|
|Processing Group enforcement||Allows the application to control the processor utilization of a group of schedulable objects|
|Processing Group deadline less than period||Allows the application to specify a processing group deadline less than the processing group period|
|Priority Ceiling Emulation Protocol||An alternative to priority inheritance for priority inversion avoidance|
|Atomic access to raw memory||Most atomic access is optional. The implementation may provide the raw memory access characteristics in system properties of the form
|Allocation-rate enforcement on heap allocation||Allows the application to limit the rate at which a schedulable object creates objects in the heap.|
ProcessingGroupParameters class is only functional on systems that support the processing group enforcement option. Cost enforcement, and cost overruns handlers are only functional on systems that support the cost enforcement option. If processing group enforcement is supported,
ProcessingGroupParameters must function as specified. If cost enforcement is supported, cost enforcement, and cost overrun handlers must function as specified.
If the processing group deadline less than period is not supported, values passed to the constructor for
ProcessingGroupParameters and its
setDeadline method are constrained to be equal to the period. If the option is supported, processing group deadlines less than the period must be supported and function as specified.
If priority ceiling emulation is supported,
PriorityCeilingEmulation must be implemented as specified. If priority ceiling emulation is not supported,
PriorityCeilingEmulation must be present, but the implementation may not permit its use as a monitor control policy.
If heap allocation rate enforcement is supported, it must be implemented as specified. If heap allocation rate enforcement is not supported, the allocation rate attribute of
MemoryParameters must be checked for validity but otherwise ignored by the implementation.
The following semantics are optional for an RTSJ implementation designed and licensed exclusively as a development tool:
Thread.interruptare not required for a development tool, but such deviations from the RTSJ must be documented, and the implementation must be able to generate a run-time warning each time one of these methods deviates from standard RTSJ behavior.
An implementation must support conditionally-required facilities if the underlying hardware and software permits. This specification includes three conditionally-required facilities:
||This class shall be implemented on every platform where POSIX signals are supported|
||This shall be implemented on every platform for which the base JVM includes support for the float and double types.|
|Mapping memory||If the system supports address translation, the implementation shall support the memory mapping features of the raw memory access classes.|
If POSIX signals are not supported, the
POSIXSignalHandler class must not be present. If POSIX signals are supported,
POSIXSignalHandler must be implemented as specified.
If floating point is not supported by the platform,
RawMemoryFloatAccess must not be present. If floating point is supported, then
RawMemoryFloatAccess must be implemented as specified.
Each implementation of the RTSJ is required to provide documentation for several behaviors:
MonitorControlsubclasses not detailed in this specification must document their effects, particularly with respect to priority inversion control and which (if any) schedulers fail to support the new policy.
PriorityInheritancemonitor control policy. It must supply documentation for the behavior of the new scheduler with priority inheritance (and, if it is supported, priority ceiling emulation protocol) equivalent to the semantics for the base priority scheduler found in the Synchronization chapter. If there are restrictions on use of the scheduler from a no-heap context, the documentation must detail the effect of these restrictions for each RTSJ API.
AsyncEventbecause of a bound happening to releasing an associated
AsyncEventHandler(assuming no higher-priority schedulable objects are runnable) must be documented for some reference architecture.
AsynchronouslyInterruptedExceptionat an ATC-enabled thread and first delivery of that exception (assuming no higher-priority schedulable objects are runnable) must be documented for some reference architecture.
RealtimeSecurityis more restrictive than the required implementation, or has run-time configuration options, those features shall be documented.
A thread is an instance of the java.lang.Thread class.
A real-time thread is an instance of the javax.realtime.RealtimeThread class.
A Java thread is a thread that is not a real-time thread.
A no-heap real-time thread is an instance of the javax.realtime.NoHeapRealtimeThread class.
An asynchronous event handler is an instance of the javax.realtime.AsyncEventHandler class.
Schedulable object is distinct from the term schedulable object (SO). Every object that implements the
Schedulable interface can be termed a
Schedulable object, but only objects that are recognized as dispatchable entities by the base scheduler are schedulable objects with respect to that scheduler. The base scheduler's set of schedulable objects comprises instances of
AsyncEventHandler. Other schedulers may support a different set of schedulable objects, but this specification only defines the behavior of the base scheduler so the term schedulable object should be understood as "schedulable by the base scheduler."