- Scheduling
- Memory Management
- Synchronization
- Asynchronous Event Handling
- Asynchronous Transfer of Control
- Asynchronous Thread Termination
- Physical Memory Access
- Exceptions
- Minimum Implementations of the RTSJ
- Optionally Required Components
- Documentation Requirements
- Parameter Objects
- Java Platform Dependencies
Asynchronous Thread Termination
Although not a real-time issue, many event-driven computer systems that tightly interact with external real-world noncomputer systems (e.g., humans, machines, control processes, etc.) may require significant changes in their computational behavior as a result of significant changes in the non-computer real-world system. It is 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. Consider the opposite case. 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. It is an easier design task to code threads to computationally cooperate for only one (or a very few) possible states of the external system. When the external system makes a state transition, the changes in computation behavior might then be managed by an oracle, that terminates a set of threads useful for the old state of the external system, and invokes a new set of threads appropriate for the new state of the external system. Since the possible state transitions of the external system are encoded in only the oracle and not in each thread, the overall system design is easier.
Earlier versions of the Java language supplied mechanisms for achieving these effects: in particular the methods stop() and destroy() in class Thread. However, since stop() could leave shared objects in an inconsistent state, stop() has been deprecated. The use of destroy() can lead to deadlock (if a thread is destroyed while it is holding a lock) and although it has not yet been deprecated, its usage is discouraged. A goal of the RTSJ was to meet the requirements of asynchronous thread termination without introducing the dangers of the stop() or destroy() methods.
The RTSJ accommodates safe asynchronous thread termination through a combination of the asynchronous event handling and the asynchronous transfer of control mechanisms. If the significantly long or blocking methods of a thread are made interruptible the oracle can consist of a number of asynchronous event handlers that are bound to external happenings. When the happenings occur the handlers can invoke interrupt() on appropriate threads. Those threads will then clean up by having all of the interruptible methods transfer control to appropriate catch clauses as control enters those methods (either by invocation or by the return bytecode). This continues until the run() method of the thread returns. This idiom provides a quick (if coded to be so) but orderly clean up and termination of the thread. Note that the oracle can comprise as many or as few asynchronous event handlers as appropriate.