Standard Java Classes

In several cases the semantics of the RTSJ influence the semantics of classes from the standard Java class libraries. Specifically:


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:

    1. Use of 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.
    2. Real-time threads may use 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();
    3. If the real-time thread's priority parameters object is shared with other schedulable objects, 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.
    4. 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.
    5. setPriority throws ClassCastException if the thread is a real-time thread and its scheduling parameters object is not an instance of PriorityParameters.
    1. When used on a real-time thread, getPriority behaves effectively as if it included the code snippet:
    2. If the scheduling parameters are not of type 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

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.

  1. Real-time threads with 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:
    1. The Thread.enumerate class method returns the integer 1, and populates its array argument with the current real-time thread.
    2. Thread.activeCount returns 1.
    3. Thread.getThreadGroup returns null in all cases, not only when the thread has terminated.
  2. A Java thread that is created from a real-time thread inherits the thread group of the real-time thread, if it has one; otherwise an attempt is made to add it to the application root thread group. The constructor shall throw a SecurityException if the Java thread is not permitted to use the application root thread group.
  3. The thread group of a Java thread created by an async event handler is assigned as if it was created by a real-time thread without a thread group (as described in 2.)
  4. A thread group cannot be created in scoped memory. The constructor shall throw an IllegalAssignmentError.
  5. Limits on priority set in the thread group have no influence on real-time threads.
  6. Except as specified previously, real-time threads have the same 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

System properties and their String values allocated during system initialization shall be allocated in immortal memory.