Example 9-13 Testing Once Every 1000 Iterations
for (i = 0; i < N; i++) {
a[i] = b[i];
if (i % 1000 == 0) {
if (Thread.interrupted()) {
throw new InterruptedException();
}
}
}
So how long a latency can you afford for cancellation? That's a decision for you to make. Most
likely the answer is going to be something like, "I want the target thread gone within 10 ms of
CPU time after the call to cancel, with a probability of 99.999%."[7] With any sort of normal
program, you'll have no problems. Analyze your program carefully, then test it.
[7]
What if you want 100% probability? Forget it. There is no such beast. When the probability of
program failure drops below the probability of the computer being hit by a meteorite (about 1E-11
per year), you can relax.
What if you want bounded wall-clock time? Things get a bit stickier. We are now talking about
realtime processing and an entirely different set of issues. The basic answer is, "Don't do that!" If
you are going to do it, you'll need to know more than we do about realtime.
Interrupting Blocked Threads
Now that we've taken care of the CPU-bound programs, what about the I/O-bound programs?
We've already stated that all blocking methods are intended to be interruptible. Is that enough? Or
is it too much?
The thing we want here is the same as above--we want a time bound for when our thread will see
the interruption. Moreover, we can generally be fairly generous about that time bound. In
particular, the amount of time it takes to read a block from disk (about 20 ms) is not going to be a
problem. We are not going to be concerned with interrupting local disk I/O. Unfortunately, if we
are reading remote files via NFS, we don't have that assurance. What do we want to do if NFS
fails? Can we treat that differently from waiting for clients? Perhaps.
Interrupting Sockets
Still, the most common issue is sockets, because we have no idea when a client might send the
next request. Taking the canonical case of wanting to shut down a server, we are concerned
primarily with forcing threads that are blocked, waiting on a read from a socket to pop out of that
read and see the shutdown request. In some systems it is actually possible for us to write into that
socket from the local program. This would make things much easier, but this is not generally the
case; certainly it is not the case with Java. With Java we need to use interruption.
What Should Throw InterruptedException?
That part is fine. Waiting for a socket? Throw an interruption and exit. The problem that occurs is
that many other methods may receive that interruption instead. If our thread is calling wait()
somewhere, that wait() will be the one to receive the interruption and we'll be forced to deal
with it there. We don't really want that. We can control the wait() code more directly and more
easily by using flags as in our StopQueue example. We would really prefer to use the
StopQueue technique everywhere except when blocking on the socket.
Search WWH :
