Changes Accepted in Early May 2005
Change list RSTJ 1.0.1(a) to 1.0.1(b)
Note that changes to inherited methods are only itemized in the class where the method is defined.
Note that numbered items such as semantics are identified by unique numbers in this change list. Since deleted semantics and new semantics have numbers, the numbers in this change list may not match either the 1.0.1(a) or 1.0.1(b) documents. Because if this, cross references that appear in this change list may not make sense.
1. change
The non-normative thread safety chapter has been removed.
2. change
Replaced:
By timely execution of threads we mean that
With:
Timely execution of schedulable objects means that
In
Timely execution of schedulable objects means that the programmer can determine by analysis of the program, testing the program on particular implementations, or both whether particular threads will always complete execution before a given timeliness constraint.
3. change
Replaced: threads
With :
schedulable objects
In
We use the term scheduling (or scheduling algorithm) to refer to the production of a sequence (or ordering) for the execution of a set of schedulable objects (a schedule).
4. change
Replaced thread
With
schedulable object
In
Priority is typically an integer associated with a schedulable object;
5. change
Replaced
?to?
With
?that may help?
In
However, the base scheduler also inherits methods from its superclass that may help determine feasibility.
6. change
Inserted
?real-time?
in
specifically including no-heap real-time threads and no-heap asynchronous event handlers.
7. change
Replaced: ?Every ? With: ?The contents of a?
Replaced ?area effectively maintains?
With ?are discarded when no object in the scope can be referenced. This is done by a technique similar to reference counting the scope. A conformant implementation might maintain?
Replaced: ?that? With ?each?
Replaced: ?is? With ?would be?
Replaced: ?is? With ?would be?
Replaced ?is? With ?would be?
Replaced ?The? With: ?Reuse of the?
Replaced ?Cannot be reused? With ?is blocked?
Replaced ?complete and the RTSJ requires that the finalizers execute to completion before the next use (calling enter() or in a constructor) of the scoped memory area? With ?complete?
In
The contents of a scoped memory are discarded when no object in the scope can be referenced. This is done by a technique similar to reference counting the scope. A conformant implementation might maintain a count of the number of external references to each memory area. The reference count for a ScopedMemory area would be increased by entering a new scope through the enter() method of MemoryArea, by the creation of a schedulable object using the particular ScopedMemory area, or by the opening of an inner scope. The reference count for a ScopedMemory area would be decreased when returning from the enter() method, when the schedulable object using the ScopedMemory terminates, or when an inner scope returns from its enter() method. When the count drops to zero, the finalize method for each object in the memory would be executed to completion. Reuse of the scope is blocked until finalization is complete.
8. change
Replaced ?Enclosing? With ?Outer?
In
A reference to a scoped object cannot be assigned to a variable from an outer scope,
9. change
Replaced
?A second policy, priority ceiling emulation protocol (or highest locker protocol), is also specified for systems that support it. The highest locker protocol is also a well known algorithm in the literature, and it has the following effect:
? With this policy, a monitor is given a priority ceiling when it is created, which is the highest priority of any thread that could attempt to enter the monitor.
? As soon as a thread enters synchronized code, its priority is raised to the monitor?s ceiling priority.
? If, through programming error, a thread has a higher priority than the ceiling of the monitor it is attempting to enter, then an exception is thrown.
Note that while the RTSJ requires that the execution of non-heap schedulable objects must not be delayed by the execution of the garbage collector, an application can cause a no-heap schedulable to wait for garbage collection by synchronizing using an object between an heap-using thread or schedulable object and a non-heap schedulable object. The RTSJ provides three wait-free queue classes to provide protected, non-blocking, shared access to objects accessed by both regular Java threads and no-heap real-time threads. These classes are provided explicitly to enable communication between the real-time execution of non-heap schedulable objects and regular Java threads.?
With
?A second policy, priority ceiling emulation protocol (or highest locker protocol), is also specified for systems that support it. This protocol is also a well-known algorithm in the literature; somewhat simplified, its effect is as follows:
? A monitor is given a ?priority ceiling? when it is created; the programmer should choose the highest priority of any thread that could attempt to enter the monitor.
? As soon as a thread enters synchronized code, its (active) priority is raised to the monitor?s ceiling priority. If, through programming error, a thread has a higher base priority than the ceiling of the monitor it is attempting to enter, then an exception is thrown.
? On leaving the monitor, the thread has its active priority reset. In simple cases it will set be to the thread?s previous active priority, but under some circumstances (e.g. a dynamic change to the thread?s base priority while it was in the monitor) a
different value is possible
Note that while the RTSJ requires that the execution of non-heap schedulable objects must not be delayed by garbage collection on behalf of lower-priority schedulable objects, an application can cause a no-heap schedulable object to wait for garbage collection by synchronizing using an object between an heap-using thread or schedulable object and a non-heap schedulable object. The RTSJ provides wait-free queue classes to provide protected, non-blocking, shared access to objects accessed by both regular Java threads and no-heap real-time threads. These classes are provided explicitly to enable communication between the real-time execution of non-heap schedulable objects and regular Java threads or heap-using schedulable objects.?
10. change
Replaced ?soft? With ?execution time?
in
The Clock class may be extended to represent other clocks the underlying system might make available (such as a execution time clock of some granularity).
11. change
Replaced ?methods? with ?methods, static initializers?
in
These ATC-deferred sections are synchronized methods, static initializers, and synchronized statements.
12. change
Replaced ?thread? With ?schedulable object?
In
Code that responds to an ATC does not return to the point in the schedulable object where the ATC was triggered;
13. change
Replaced ?thread? With ?schedulable object?
Replaced ?thread? With ?thread or schedulable object?
Replaced ?thread ? with ?thread or schedulable object?
in
14. change
Inserted: ?real-time?
in
Through ATC it must be possible to abort a real-time thread but in a manner that does not carry the dangers of the Thread class?s stop() and destroy() methods.
15. change
Inserted: ?real-time?
in
There should be straightforward idioms for common cases such as timer handlers and real-time thread termination.
16. change
Deleted
?ATC must be implemented without inducing an overhead for programs that do not use it.?
17. change
Inserted: ?Real-Time? in the title.
18. change
Replaced ?is? With ?would be?
In
It would be convenient to program threads that abnormally terminate when the external real-time system changes in a way such that the thread is no longer useful.
19. change
deleted ?would?
from
Without this facility, a thread or set of threads would have to be coded in such a manner so that their
computational behavior anticipated all of the possible transitions among possible states of the external system.
20. change
Inserted ?real-time?
in
The RTSJ accommodates safe asynchronous real-time thread termination through a combination of the asynchronous event handling and the asynchronous transfer of control mechanisms.
21. change
Inserted ?real-time?
in
To create such a set of real-time threads consider the following steps
22. change
Inserted ?real-time?
in
Make all of the application methods of the real-time thread interruptible
23. change
Inserted ?real-time?
in
Have the handlers call interrupt() on each of the real-time threads affected by the change
24. change
Inserted ?real-time?
in
After the handlers call interrupt() have them create a new set of real-time threads appropriate to the current state of the external world
25. change
Inserted ?real-time?
in
Ultimately the run() method of the real-time thread will complete normally.
26. change
Insert ?real-time?
in
This idiom provides a quick (if coded to be so) but orderly clean up and termination of the real-time thread.
27. change
Deleted
?The base implementation will provide a PhysicalMemoryManager and a set of PhysicalMemoryTypeFilter classes that correctly identify memory classes that are standard for the (OS, JVM, and processor) platform.?
from
The PhysicalMemoryManager is available for use by the various physical memory accessor objects (VTPhysicalMemory, LTPhysicalMemory, ImmortalPhysicalMemory, RawMemoryAccess, and RawMemoryFloatAccess) to create objects of the correct type that are bound to areas of physical memory with the appropriate characteristics - or with appropriate accessor behavior. Examples of characteristics that might be specified are: DMA memory, accessors with byte swapping, etc. The base implementation will provide a PhysicalMemoryManager and a set of PhysicalMemoryTypeFilter classes that correctly identify memory classes that are standard for the (OS, JVM, and processor) platform. OEMs may provide PhysicalMemoryTypeFilter classes that allow additional characteristics of memory devices to be specified.
28. change
Inserted
?Subject to the usual assumptions, the methods in javax.realtime can safely be used concurrently by multiple threads unless it is otherwise documented.?
In the list of base requirements
29. change
Replaced
?Allows the application to control the processor utilization of a thread or group of threads.?
With
?Allows the application to control the processor utilization of a schedulable object.?
In the description of the cost enforcement option
30. change
Insert the following option in the option table:
?Processing Group Enforcement
Allows the application to control the processor utilization of a group of schedulable objects?
31. change
Insert the following option in the option table:
?Processing Group deadline less than period
Allows the application to specify a processing group deadline ?
32. change
Insert the following option in the option table:
?Allocation-rate enforcement on heap allocation
Allows the application to limit the rate at which a schedulable object creates objects in the heap.?
33. change
Inserted
?The ProcessingGroupParameters class is only functional on systems that support the processing group enforcement option. Cost enforcement, and cost overrun handlers are only functional on systems that support the cost enforcement option. If processing group enforcement is supported, ProcessingGroupParameters must function as specified. If cost enforcement is supported, cost enforcement, and cost overrun handlers must function as specified.?
34. change
Inserted
?If the processing group deadline less than period is not supported, values passed to the constructor for ProcessingGroupParameters and its setDeadline method are constrained to be equal to the period. If the option is supported, processing group deadlines less than the period must be supported and function as specified.?
35. change
Replaced
?If cost enforcement is not supported, the ProcessingGroupParameters class must not be present. If cost enforcement is supported, ProcessingGroupParameters must be implemented as specified.?
With
?If priority ceiling emulation is supported, PriorityCeilingEmulation must be implemented as specified. If priority ceiling emulation is not supported, PriorityCeilingEmulation must be present, but the implementation may not permit its use as a monitor control policy.?
36. change
Replaced
?If priority ceiling emulation protocol is not supported, the PriorityCeilingEmulation class must not be present. If priority ceiling emulation is supported, PriorityCeilingEmulation must be implemented as specified.?
With
?If heap allocation rate enforcement is supported, it must be implemented as specified. If heap allocation rate enforcement is not supported, the allocation rate attribute of MemoryParameters must be checked for validity but otherwise ignored by the implementation.?
37. change
Inserted
?The following semantics are optional for an RTSJ implementation designed and licensed exclusively as a development tool:
? The priority scheduler need not support fixed-priority preemptive scheduling or priority inheritance. This does not excuse an implementation from fully supporting the relevant APIs. It only reduces the required behavior of the underlying scheduler to the level of the scheduler in the Java specification extended to at least 28 priorities.
? No semantics constraining timing beyond the requirements of the Java specifications need be supported. Specifically, garbage collection may delay any thread without bound and any delay in delivering asynchronously interrupted exceptions is permissible including never delivering the exception. Note, however, that if any AIE other than the generic AIE is delivered, it must meet the AIE semantics, and all heap-memory-related semantics other than preemption remain fully in effect. Further, relaxed timing does not imply relaxed sequencing. For instance, semantics for scoped memory must be fully implemented.
? The RTSJ semantics that alter standard Java method behavior—such as the modified semantics for Thread.setPriority and Thread.interrupt—are not required for a development tool, but such deviations from the RTSJ must be documented, and the implementation must be able to generate a run-time warning each time one of these methods deviates from standard RTSJ behavior.
? These relaxed requirements set a floor for RTSJ development system tool implementations. A development tool may choose to implement semantics that are not required.?
38. change
Replaced ?admission control? with ?feasibility testing?
twice in
If the feasibility testing algorithm is not the default, document the feasibility testing algorithm.
39. change
Replaced ?the base? With ?each other?
In
document the behavior of the scheduler and its interaction with each other scheduler
40. change
Deleted
?3 An implementation of the RTSJ is permitted to spuriously release waiting threads, but it must document the circumstances under which that may happen.?
41. change