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.Threa
d 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.