Home > Articles > Programming > Java

  • Print
  • + Share This

Minimum Implementations of the RTSJ

The flexibility of the RTSJ indicates that implementations may provide different semantics for scheduling, synchronization, and garbage collection. This section defines what minimum semantics for these areas and other semantics and APIs required of all implementations of the RTSJ. In general, the RTSJ does not allow any subsetting of the APIs in the javax.realtime package (except those noted as optionally required); however, some of the classes are specific to certain well-known scheduling or synchronization algorithms and may have no underlying support in a minimum implementation of the RTSJ. The RTSJ provides these classes as standard parent classes for implementations supporting such algorithms.

The minimum scheduling semantics that must be supported in all implementations of the RTSJ are fixed-priority preemptive scheduling and at least 28 unique priority levels. By fixed-priority we mean that the system does not change the priority of any RealtimeThread or NoHeapRealtimeThread except, temporarily, for priority inversion avoidance. Note, however, that application code may change such priorities. What the RTSJ precludes by this statement is scheduling algorithms that change thread priorities according to policies for optimizing throughput (such as increasing the priority of threads that have been receiving few processor cycles because of higher priority threads (aging)). The 28 unique priority levels are required to be unique to preclude implementations from using fewer priority levels of underlying systems to implement the required 28 by simplistic algorithms (such as lumping four RTSJ priorities into seven buckets for an underlying system that only supports seven priority levels). It is sufficient for systems with fewer than 28 priority levels to use more sophisticated algorithms to implement the required 28 unique levels as long as RealtimeThreads and NoHeapRealtimeThreads behave as though there were at least 28 unique levels. (e.g. if there were 28 RealtimeThreads (t1,...,t28) with priorities (p1,...,p28), respectively, where the value of p1 was the highest priority and the value of p2 the next highest priority, etc., then for all executions of threads t1 through t28 thread t1 would always execute in preference to threads t2, ..., t28 and thread t2 would always execute in preference to threads t3,..., t28, etc.)

The minimum synchronization semantics that must be supported in all implementations of the RTSJ are detailed in the above section on synchronization and repeated here.

All implementations of the RTSJ must provide an implementation of the synchronized primitive with default behavior that ensures that there is no unbounded priority inversion. Furthermore, this must apply to code if it is run within the implementation as well as to real-time threads. The priority inheritance protocol must be implemented by default.

All threads waiting to acquire a resource must be queued in priority order. This applies to the processor as well as to synchronized blocks. If threads with the same exact priority are possible under the active scheduling policy, threads with the same priority are queued in FIFO order. (Note that these requirements apply only to the required base scheduling policy and hence use the specific term "priority"). In particular:

  • Threads waiting to enter synchronized blocks are granted access to the synchronized block in priority order.

  • A blocked thread that becomes ready to run is given access to the processor in priority order.

  • A thread whose execution eligibility is explicitly set by itself or another thread is given access to the processor in priority order.

  • A thread that performs a yield() will be given access to the processor after waiting threads of the same priority.

  • However, threads that are preempted in favor of a thread with higher priority may be given access to the processor at any time as determined by a particular implementation. The implementation is required to provide documentation stating exactly the algorithm used for granting such access

The RTSJ does not require any particular garbage collection algorithm. All implementations of the RTSJ must, however, support the class GarbageCollector and implement all of its methods.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.