JAVA-BASED REAL-TIME PROGRAMMING

3. Multi-Threaded Programming
public void run() {
while (!isInterrupted ()) { // !interrupted() OK in most cases.
// here is where the actual code goes....
}
} // End of life for this thread.
After the loop, isInterrupted can be used to check how the loop was exited.
Instead of terminating after an interrupt, you can have an outer loop to restore
the state and continue execution. Additionally, you may need to catch
InterruptedException, or other Throwable objects such as those of type Error,
either outside the while loop above or at several places inside that loop depending
on the code. Note, however, you should normally not try to catch
and recover from an InterruptedException thrown from a blocking call that
have to do with access or allocation of shared resources/data, if resources are
not left in a consistent state (bank transaction not half made, etc.). When
resuming normal operation after such a call has been interrupted, there is a
big risk that execution continues as if resources where locked even if that is
not the case. Having each method to pass the exception (instead of catching
it locally) to the caller, by appending throws InterruptedException to its signature,
messes up the code too much. In practice, the result is often empty
catch-clauses with an intention to add the code later, which then never is
done and the application silently compiles and runs, but interrupting it may
result in disaster. The recommended approach therefore is to always convert
an InterruptedException to an Error. For this purpose, we will later use the
class RTInterrupted which is a subclass of Error with some enhancements:
try {
argout = methodThrowingInterruptedException(argin);
} catch (InterruptedException exc) {
throw new RTInterrupted(exc.toString ());
}
which means that the method containing the above code is not defined to
throw any InterruptedException, and the caller(s) of that method do not
need to be cluttered with try-catch clauses. Recall that the intended use of
the Error class is for throwing severe exceptions that the user is not expected
to catch, but he/she can catch them if that is needed. Hence, throwing an
error when a resource allocation request is interrupted agrees well with the
Java API conventions.
A different case is when an independent sequence of operations is to be
interrupted. Sequencing on an application level (that is, advancing the state
of the application, not caring about advancing the program counter for each
instruction) is typically done by waiting for time to pass, or on certain conditions
to be true. Interrupting such a thread, and letting the interrupted
thread handle the Exception/Error, can be a perfectly acceptable thing to do:
• If the interrupted sequence is a web-server transaction, closing files and
returning any resources in their initial state should be possible and
straight forward.
52 2012-08-29 16:05