In principle this solution would work. But when a thread hits an interruption-tripwire (an interrupted exception is thrown when such a tripwire is passed), the interrupt status is removed. And if the InterruptedException is wrapped in a RuntimeException (a practice I see quite often) all information about the desired stop is lost.

Another problem is that you don\’t always want to interrupt, but want to stop as soon as the thread is ready for the next iteration.

So personally I would still go for a stop flag (to prevent not stopping) and maybe for the interrupt (if a thread needs to be shutdown immediately).

public void stop( )
{
Thread.currentThread().interupt();
}

and make some other thread call stop method would be enough to safely stop a thread, though you may need to add some housekeeping code to implement a interruption policy like clean up unfinished operation etc..

Hmm.. under the 1.4 virtual machine the variable is visible, but the reordering is still possible. The behavior of this code under 1.4 is not very well defined. The 1.4 vm’s should not be used, they are broken.

Volatile (under 1.5) does 2 things:
-prevent visibility problems
-prevent reorderings

True.. partly.. I have seen way too much code that just gobbles up the interrupted exception.

try{
..some blocking call
}catch(InterruptedException ex){
throw new RuntimeException(ex);
}

In this case the interrupted status is removed from the thread, and the interruptedexception is hidden. So for the loop it is very hard to figure out what to do. If you look at the ThreadPoolExecutor, they also are not just relying on the Thread interrupt status because it is very easy to break.

I a single iteration takes 5 minutes for example, the shutdown of the thread can take 5 minutes. If the task blocks for and undetermined amount of time, you can’t say anything about the shutdown duration.

>>Or are you coming back to the interruption of >>Threads later on in your top 10?

I don’t think so. If you really want to know more about shutting down threads, please have a look at “Concurrent Programming in Java” chapter 7.

interesting read. Would be declaring stop as volatile solve the problem? Under 1.4.2? Under 1.5+? Maybe you can explain shortly what “volatile” means.

Thanks.