Proposed
Change list RSTJ 1.0.1(a) to 1.0.1(b)
Note that changes to inherited methods are only itemized inthe 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 inthis 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. Where such semantics are mentioned, the change list includes enough text from the semantic to identify it.
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 byanalysis of the program, testing the program on particular implementations, orboth whether particular threads will always complete execution before a giventimeliness constraint.
3. change
Replaced: threads
With :
schedulable objects
In
We use the term scheduling (or scheduling algorithm) to refer to the production of asequence (or ordering) for the execution of a set of schedulableobjects (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 itssuperclass that may help determinefeasibility.
6. change
Inserted
Òreal-timeÓ
in
specifically including no-heap real-timethreads and no-heap asynchronous event handlers.
7. change
Replaced: ÒEvery Ò With: ÒThe contents of aÓ
Replaced Òareaeffectively maintainsÓ
With Òare discarded when no object in the scope can bereferenced. This is done by a technique similar to reference counting thescope. 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 finalizersexecute 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 arediscarded when no object in the scope can be referenced. This is done by atechnique similar to reference counting the scope. A conformant implementationmight maintain a count of the number ofexternal references to each memory area. Thereference count for a ScopedMemoryarea would be increased by entering a new scope throughthe enter() method of MemoryArea, by the creation of a schedulableobject using the particular ScopedMemory area,or by the opening of an inner scope. The reference count for a ScopedMemory area wouldbe decreased when returning from the enter() method, when the schedulable object using the ScopedMemory terminates, or when an inner scopereturns from its enter()method. When the countdrops to zero, the finalize method for each object in the memory would be executed to completion. Reuse of the scope isblocked until finalization is complete.
8. change
Replaced ÒEnclosingÓ With ÒOuterÓ
In
A reference to a scoped object cannot be assigned to avariable from an outer scope,
9. change
Replaced
ÒAsecond policy, priority ceiling emulation protocol (or highest lockerprotocol), is also specified for systems that support it. The highest lockerprotocol is also a well known algorithm in the literature, and it has thefollowing effect:
¥With this policy, a monitor is given a priority ceiling when it is created, which is the highest priority ofany thread that could attempt to enter the monitor.
¥As soon as a thread enters synchronized code, its priority is raised to themonitorÕs ceiling priority.
¥If, through programming error, a thread has a higher priority than the ceilingof the monitor it is attempting to enter, then an exception is thrown.
Notethat while the RTSJ requires that the execution of non-heap schedulable objectsmust not be delayed by the execution of the garbage collector, an applicationcan cause a no-heap schedulable to wait for garbage collection by synchronizingusing an object between an heap-using thread or schedulable object and anon-heap schedulable object. The RTSJ provides three wait-free queue classes toprovide protected, non-blocking, shared access to objects accessed by bothregular Java threads and no-heap real-time threads. These classes are providedexplicitly to enable communication between the real-time execution of non-heapschedulable objects and regular Java threads.Ó
With
ÒA second policy, priority ceiling emulation protocol (orhighest locker protocol), is also specified for systems that support it. Thisprotocol is also a well-known algorithm in the literature; somewhat simplified, its effect is asfollows:
¥ A monitor is given a Òpriority ceilingÓ when it iscreated; the programmer should choose the highest priority of any thread thatcould 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 programmingerror, a thread has a higher base priority than the ceiling of the monitor itis attempting to enter, then an exception is thrown.
¥ On leaving the monitor, the thread has its active priorityreset. 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 basepriority while it was in the monitor) a
different value is possible
Note that while the RTSJ requires that the execution ofnon-heap schedulable objects must not be delayed by garbage collection on behalfof lower-priority schedulable objects, an application can cause a no-heapschedulable object to wait for garbage collection by synchronizing using anobject between an heap-using thread or schedulable object and a non-heapschedulable object. The RTSJ provides wait-free queue classes to provideprotected, non-blocking, shared access to objects accessed by both regular Javathreads and no-heap real-time threads. These classes are provided explicitly toenable communication between the real-time execution of non-heap schedulableobjects 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 clocksthe underlying system might make available (such as a executiontime clock of some granularity).
11. change
Replaced ÒmethodsÓ with Òmethods, static initializersÓ
in
These ATC-deferred sections are synchronized methods, static initializers, and synchronizedstatements.
12. change
Replaced ÒthreadÓ With Òschedulable objectÓ
In
Code that responds to an ATC does not return to the point inthe schedulable object where the ATC wastriggered;
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 carrythe dangers of the ThreadclassÕs stop() and destroy() methods.
15. change
Inserted: Òreal-timeÓ
in
There should be straightforward idioms for common cases suchas timer handlers and real-time thread termination.
16. change
Deleted
ÒATCmust be implemented without inducing an overhead for programs that do not useit.Ó
17. change
Inserted: ÒReal-TimeÓ in the title.
18. change
Replaced ÒisÓ With Òwould beÓ
In
It would be convenient toprogram threads that abnormally terminate when the external real-time systemchanges in a way such that the thread is no longer useful.
19. change
deleted ÒwouldÓ
from
Withoutthis facility, a thread or set of threads wouldhave to be coded in such a manner so that their
computationalbehavior anticipated all of the possible transitions among possible states ofthe external system.
20. change
Inserted Òreal-timeÓ
in
The RTSJ accommodates safe asynchronous real-time thread termination through a combinationof the asynchronous event handling and the asynchronous transfer of controlmechanisms.
21. change
Inserted Òreal-timeÓ
in
To create such a set of real-timethreads 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 threadsaffected by the change
24. change
Inserted Òreal-timeÓ
in
After the handlers call interrupt() have them create a new set of real-timethreads appropriate to the current state of the external world
25. change
Inserted Òreal-timeÓ
in
Ultimately the run() methodof the real-time thread will completenormally.
26. change
Insert Òreal-timeÓ
in
This idiom provides a quick (if coded to be so) but orderlyclean up and termination of the real-timethread.
27. change
Deleted
ÒThe base implementation will provide aPhysicalMemoryManager and a set of PhysicalMemoryTypeFilter classes thatcorrectly identify memory classes that are standard for the (OS, JVM, andprocessor) platform.Ó
from
ThePhysicalMemoryManager is available for use by the various physical memoryaccessor objects (VTPhysicalMemory,LTPhysicalMemory, ImmortalPhysicalMemory, RawMemoryAccess, and RawMemoryFloatAccess)to create objects of the correct typethat are bound to areas of physical memory with the appropriate characteristics- or with appropriate accessor behavior. Examples of characteristics that mightbe 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 forthe (OS, JVM, and processor) platform.OEMs may provide PhysicalMemoryTypeFilter classes that allow additional characteristics ofmemory devices to be specified.
28. change
Inserted
ÒSubject to the usual assumptions, the methods injavax.realtime can safely be used concurrently by multiple threads unless it isotherwise documented.Ó
In the list of base requirements
29. change
Replaced
ÒAllows the application to control the processor utilizationof a thread or group of threads.Ó
With
ÒAllows the application to control the processor utilizationof a schedulable object.Ó
In the description of the cost enforcement option
30. change
Insert the following option in the option table:
ÒProcessingGroup Enforcement
Allows the application to control the processor utilizationof 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 groupdeadline Ò
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 aschedulable object creates objects in the heap.Ó
33. change
Inserted
ÒThe ProcessingGroupParameters class is only functional onsystems that support the processing group enforcement option. Cost enforcement,and cost overrun handlers are onlyfunctional on systems that support the cost enforcement option. If processinggroup enforcement is supported, ProcessingGroupParameters must function asspecified. If cost enforcement is supported, cost enforcement, and cost overrunhandlers must function as specified.Ó
34. change
Inserted
ÒIf the processing group deadline less than period is notsupported, values passed to the constructor for ProcessingGroupParameters andits setDeadline method are constrained to be equal to the period. If the optionis supported, processing group deadlines less than the period must be supportedand function as specified.Ó
&nbs