JAVA-BASED REAL-TIME PROGRAMMING

3. Multi-Threaded Programming
choice would be to let every potentially blocking monitor methods be declared
to throw an InterruptedException. However, in particular when there
are several levels of calls, this soon gets very messy. Furthermore, the monitor
method cannot complete its operation if the condition is not fulfilled, and
it cannot simply return before the operation is completed either (both these
alternatives would violate the correctness of the monitor).
So, the only reasonable alternative is to throw a Throwable object that
we do not need to catch or declare. Java provides two alternatives for doing
that: throwing an RuntimeException which is an Exception, or throwing an
Error. To emphasis that the normal user code is not supposed to catch an
interrupted wait (since it in most cases needs to propagate to the outermost
level of the thread), throwing an Error is the appropriate solution. That is, we
throw an instance of RTInterrupted, which is a subclass to java.lang.Error.
This solution corresponds to the SemViolation as described on page 65 for
semaphores.
The implication is that we normally call wait according to:
{ //.....
while (!ok) {
try {
wait();
} catch (InterruptedException exc) {
throw new RTInterrupted(exc);
}
}
}
Note that when an InterruptedException is thrown, the interrupted-flag of
that thread is cleared. Hence, it is only the fact that we get to the catch
clause that tells us that the thread is interrupted, and after the catch it is
only the thrown RTInterrupted that carries the interrupt information when
the call stack is popped.
If we use a framework that is predefined to catch InterruptedException
specifically, an RTInterrupted can of course be converted back to an InterruptedException
by catching the error and throwing a new InterruptedException
(or getting the original exception by calling getCause, see the exceptionchaining
of java.lang.Throwable in JDK1.4 and later).
Sometimes interrupting a thread is used to actually interrupt a command
or action in an almost expected way. That is, instead of cluttering the code
with a lot of tests if the operation is to be aborted, we can let execution
continue until it reaches a blocking call and then utilize the thrown RTInterrupted.
For instance, a robot performing its task according to a sequence of
instructions can be interrupted by the operator who issues another task or
simply stops the robot due to some fault. The thread that handles operator
input can then interrupt the ongoing robot work, and since computers are
faster than mechanics the work thread will be blocked on getting a new order
or on the completion of last order. By catching InterruptedException and
82 2012-08-29 16:05