In several cases the semantics of the RTSJ influence the semantics of classes from the standard Java class libraries. Specifically:
java.lang.Thread for real-time threads.
ThreadGroup class' behavior with respect to real-time threads.
ThreadGroup-related methods in Thread when they are applied to real-time threads.
The methods setPriority and getPriority in java.lang.Thread are final. The real-time thread classes are consequently not able to override them and modify their behavior to suit the requirements of the RTSJ scheduler. To bring the java.lang.Thread class in line with its real-time sub-classes, the semantics of the getPriority and setPriority methods are modified as follows:
Thread.setPriority():
Thread.setPriority()must not affect the correctness of the priority inversion avoidance algorithms controlled by PriorityCeilingEmulation and PriorityInheritance. Changes to the base priority of a real-time thread as a result of invoking Thread.setPriority()are governed by semantics from Synchronization.
setPriority to access the expanded range of priorities available to real-time threads. If the real-time thread's priority parameters object is not shared, setPriority behaves effectively as if it included the code snippet:PriorityParameters pp = getSchedulingParameters();
pp.setPriority(newPriority);
setPriority must give the thread an unshared PriorityParameters instance allocated in the same memory area as the real-time thread object and containing the new priority value.
setPriority throws IllegalArgumentException if the thread is a real-time thread and the new priority is outside the range allowed by the real-time thread's scheduler.
setPriority throws ClassCastException if the thread is a real-time thread and its scheduling parameters object is not an instance of PriorityParameters.
Thread.getPriority():
getPriority behaves effectively as if it included the code snippet:PriorityParameters)t.getSchedulingParameters()).getPriority();
PriorityParameters, then a ClassCastException is thrown.
All supported monitor control policies must apply to Java threads as well as to all schedulable objects.
Thread groups are rooted at a base ThreadGroup object which may be created in heap or immortal memory. All thread group objects hold references to all their member threads, and subgroups, and a reference to their parent group. Since heap and immortal memory can not hold references to scoped memory, it follows that a thread group can never be allocated in scoped memory. It then follows that no thread allocated in scoped memory may be referenced from any thread group, and consequently such threads are not part of any thread group and will hold a null thread group reference. Similarly, a NoHeapRealtimeThread can not be a member of a heap allocated thread group.
null thread groups are not included when thread groups are enumerated, interrupted, stopped, resumed, or suspended. However, when the current thread is a real-time thread with a null thread group:
Thread.enumerate class method returns the integer 1, and populates its array argument with the current real-time thread.
Thread.activeCount returns 1.
Thread.getThreadGroup returns null in all cases, not only when the thread has terminated.
SecurityException if the Java thread is not permitted to use the application root thread group.
IllegalAssignmentError.
ThreadGroup membership rules as the parent Thread class.
The interruptible methods in the standard libraries (such as Object.wait, Thread.sleep, and Thread.join) have their contract expanded slightly such
that they will respond to interruption not only when the interrupt method is invoked on the current thread, but also, for schedulable objects, when
executing within a call to AIE.doInterruptible and that AIE is fired. See
Asynchrony.
System properties and their String values allocated during system initialization shall be allocated in immortal memory.