See:
          Description

Synchronization

This section describes classes that specifically manage synchronization.  These classes:

• Allow the setting of a priority inversion control policy either as the default or for specific objects
• Allow wait-free communication between schedulable objects (especially instances of NoHeapRealtimeThread) and regular Java threads.

This specification strengthens the semantics of Java synchronized code by mandating monitor execution eligibility control, commonly referred to as priority inversion control. The MonitorControl class is defined as the superclass of all such execution eligibility control algorithms. Its subclasses PriorityInheritance (required) and PriorityCeilingEmulation (optional) avoid unbounded priority inversions, which would be unacceptable in real-time systems.

The classes in this section establish a framework for priority inversion management that applies to priority-oriented schedulers in general, and a specific set of requirements for the base priority scheduler.

The wait-free queue classes provide safe, concurrent access to data shared between instances of NoHeapRealtimeThread and schedulable objects subject to garbage collection delays.

Semantics and Requirements

This list establishes the semantics and requirements that are applicable across the classes of this section. Semantics that apply to particular classes, constructors, methods, and fields will be found in the class description and the constructor, method, and field detail sections.

1. Terminology: If an object obj has been assigned (either by default or via an explicit method call) the MonitorControlPolicy mcp, then obj is said to be governed by mcp.
2. The initial default monitor control policy shall be PriorityInheritance. The default policy can be altered by using the setMonitorControl() method.
3. Notwithstanding the preceding rule, an RTSJ implementation may allow the program to establish a different initial default monitor control policy at JVM startup. The program can query the initial default monitor control policy via the method RealtimeSystem.getInitialMonitorControl.
4. The PriorityCeilingEmulation monitor control policy is optional, since it is not widely supported by current RTOSes.
5. An implementation that provides any additional MonitorControl subclasses must document their effects, particularly with respect to priority inversion control.
6. An object's monitor control policy affects any entity that attempts to lock the object; i.e., regular Java threads as well as schedulable objects.
7. When a thread or schedulable object enters synchronized code, the target object's monitor control policy must be supported by the thread or schedulable object's scheduler; otherwise an IllegalThreadStateException is thrown. An implementation that defines a new MonitorControl subclass must document which (if any) schedulers do not support this policy.

Semantics for the Base Priority Scheduler

The following list defines the main terms and establishes the general semantics and requirements that apply to threads and schedulable objects managed by the base priority scheduler when they synchronize on objects governed by monitor control policies defined in this section.

1. Each thread or schedulable object has a base priority and an active priority. A thread or schedulable object that holds a lock on a PCE-governed object also has a ceiling priority.
2. The base priority for a thread or schedulable object t is initially the priority that t has when it is created. The base priority is updated (immediately) as an effect of invoking any of the following methods:
   • pparams.setPriority(prio)
     if t is a schedulable object with pparams as its SchedulingParameters, where pparams is an instance of PriorityParameters; the new base priority is prio
   • t.setSchedulingParameters(pparams)
     if t is a schedulable object and pparams is an instance of PriorityParameters; the new base priority is pparams.getPriority()
   • t.setPriority(prio)
     if t is a schedulable object, the new base priority is prio. If it is a Java thread, the new base priority is the lesser of prio, and the maximum priority for t's thread group.
3. When t does not hold any locks, its active priority is the same as its base priority. In such a situation modification of the priority of t through an invocation of any of the above priority-setting methods for t causes t to be placed at the tail of its relevant queue (ready, blocked on a particular object, etc.) at its new priority.
4. When t holds one or more locks, then t has a set of priority sources. The active priority for t at any point in time is the maximum of the priorities associated with all of these sources. The priority sources resulting from the monitor control policies defined in this section, and their associated priorities for a schedulable object t, are as follows:
   1. Source: t itself
      Associated priority: The base priority for t
Note: This may have been changed (either synchronously or asynchronously) while t has been holding its lock(s).
   2. Source: Each object locked by t and governed by a PriorityCeilingEmulation policy
      Associated priority: The maximum value ceil such that ceil is the ceiling for a PriorityCeilingEmulation policy governing an object locked by t. This value is also referred to as the ceiling priority for t.
   3. Source: Each thread or schedulable object that is attempting to synchronize on an object locked by t and governed by a PriorityInheritance policy
      Associated priority: The maximum active priority over all such threads and schedulable objects
      Note: This rule accounts for recursive priority inheritance.
   4. Source: Each thread or schedulable object that is attempting to synchronize on an object locked by t and governed by a PriorityCeilingEmulation policy.
      Associated priority: The maximum active priority over all such threads and schedulable objects
      Note: This rule, which in effect allows a PriorityCeilingEmulation lock to behave like a PriorityInheritance lock, helps avoid unbounded priority inversions that could otherwise occur in the presence of nested synchronizations involving a mix of PriorityCeilingEmulation and PriorityInheritance policies.
5. The addition of a priority source for t either leaves t's active priority unchanged, or increases it. If t's active priority is unchanged, then t's status in its relevant queue (e.g. blocked waiting for some object) is not affected. If t's active priority is increased, then t is placed at the tail of the relevant queue at its new active priority level.
6. The removal of a priority source for t either leaves t's active priority unchanged, or decreases it. If t's active priority is unchanged, then t's status in its relevant queue (e.g. blocked waiting for some object) is not affected. If t's active priority is decreased and t is either ready or running, then t must be placed at the head of the ready queue at its new active priority level, if the implementation is supporting PriorityCeilingEmulation. If the implementation is not supporting PriorityCeilingEmulation then t should be placed at the head of the ready queue at its new active priority (Note the "should": this behavior is optional.) If PriorityCeilingEmulation is not supported, the implementation must document the queue placement effect. If t's active priority is decreased and t is blocked, then t is placed in the corresponding queue at its new active priority level. Its position in the queue is implementation defined, but placement at the tail is recommended.

The above rules have the following consequences:

• A thread or schedulable object t's priority sources from 4.b are added and removed synchronously; i.e., they are established based on t's entering or leaving synchronized code. However, priority sources from 4.a, 4.c and 4.d may be added and removed asynchronously, as an effect of actions by other threads or schedulable objects.
• If a thread or schedulable object holds only one lock then, when it releases this lock, its active priority is set to its base priority.
• A thread or schedulable object's active priority is never less than its base priority.
• When a thread or schedulable object blocks at a call of obj.wait() it releases the lock on obj and hence relinquishes the priority source(s) based on obj's monitor control policy. The thread or schedulable object will be queued at a new active priority that reflects the loss of these priority sources.

It is a consequence of other rules that, when a thread or schedulable object t attempts to synchronize on an object obj governed by a PriorityCeilingEmulation policy with ceiling ceil, then t's active priority may exceed ceil but t's base priority must not. In contrast, once t has successfully synchronized on obj then t's base priority may also exceed obj's monitor control policy's ceiling. Note that t's base priority and/or obj's monitor control policy may have been dynamically modified.

Requirements For Additional Schedulers

The following list establishes the semantics and requirements that apply to threads or schedulable objects managed by a scheduler other than the base priority scheduler when they synchronize on objects with monitor control policies defined in this section.

1. An implementation that defines a new Scheduler subclass must document which (if any) monitor control policies the new scheduler does not support.
2. An implementation must document how, if at all, the semantics of synchronization differ from the rules defined for the default PriorityInheritance instance. 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 default priority scheduler found in the previous section.

Rationale

Java's rules for synchronized code provide a means for mutual exclusion but do not prevent unbounded priority inversions and thus are insufficient for real-time applications. This specification strengthens the semantics for synchronized code by mandating priority inversion control, in particular by furnishing classes for priority inheritance and priority ceiling emulation. Priority inheritance is more widely implemented in real-time operating systems and thus is required and is the initial default mechanism in this specification.

Since the same object may be accessed from synchronized code by both a NoHeapRealtimeThread and an arbitrary thread or schedulable object, unwanted dependencies may result. To avoid this problem, this specification provides three wait-free queue classes as an alternative means for safe, concurrent data accesses without priority inversion.

.