If you think you need goal 1, you'd best do some rethinking. First, it isn't possible; second, it isn't
even well defined.[6] So, instead of goal 1, what is it that you really want?
[6]
If nothing else, special relativity denies the concept of objective synchronisity. Practically
speaking, it will take at least 1 µs to send an interrupt anyway.
If it was goal 3 you were thinking of, you're in much the same boat. It really isn't possible and not
very meaningful. Now if you're satisfied with "not very many more global changes," we can put
that in with goal 4 and proceed.
Ensuring Bounded CPU Time
The exact time of cancellation (interruption) is not guaranteed by POSIX, Java, or Win32. The
target thread will become aware of a pending cancellation request some time after the function has
been called. If you are using asynchronous cancellation [i.e., stop()], the thread should indeed
spend very little extra time processing. No assurances here, but you can reasonably expect that it
will be gone within a few milliseconds of CPU time (who knows how long it might sleep for if it
needs a lock!). With deferred cancellation, the timing situation is more complex. The main point
to remember is that you cannot rely upon the target thread exiting at any specific time. If you need
to know when it has exited (you usually do!), you must use some sort of synchronization (either
call join or use a barrier).
As an example of a long wall-clock delay in cancellation, consider the case of a low-priority target
thread and a high-priority killer on one LWP. The cancellation will be sent, but as the high-
priority thread continues to run, the target thread will not get a chance to exit any time soon. If the
killer is running in realtime mode, the target might never exit! (Of course, in that case, you have
lots of other problems to deal with.)
Deferred cancellation is a polling scheme when a thread is running, and more like asynchronous
cancellation when the thread is blocked. For running threads, the polling is essentially as shown in
variable in the thread structure. When T1 enters a cancellation point such as read(), that
function then checks to see if the thread has been cancelled, and exits if so.
To ensure bounded cancellation time with interruptions, it is up to you, the programmer, to insert
calls to interruption points within every unbounded code path. In other words, for every loop that
might run longer than your declared time limit, you must make sure that there is an interruption
point in that loop. The obvious method is simply to include in the loop a call to
Thread.interrupted().
Example 9-12 Deferred Cancellation as Polling
interrupt()
read()
void interrupt(){
read(...) {
T1.interrupted = true;
...
...
if (self.interrupted)
throw new
InterruptedIOException();
}
}
Interrupting Computational Loops
In a tight loop, the overhead of Thread.interrupted() may prove excessive, even though it
is very fast (about 3µs on a 110-Mhz SS4). You can test only once every 1000 iterations, or
Search WWH :
