How to indicate to JVM in code where is/is not a good place to kill my thread

[Stu Thompson]

Hi all,

This is really a two part question: A) how is a thread told/forced to exit? And, b) How can I code my thread so that it exits where I want (and not where I do not want.)

E.g.:

public class MyThread extends Thread{
 
    public void run(){
        
        while (true) {
            //do something here 
            doSomething();
 
            //do something there PART I
            doSomthingThere_1();
            //do something there PART ii
            doSomthingThere_2();   
         
            //do something everywhere
            doSomethingEveryWhere();
 
            try {
                Thread.sleep(10000);
 
            } catch (InterruptedException ignore) {
            }
        }
    }
}

In my above code, it is OK for the thread to exit everywhere except for from the start of doSomthingThere_1() and the end of doSomthingThere_2(). Basically, I want this work to be atomic. This atomic behaviour is not an absolute requirement, but rather a damn-nice-to-have kind of thing.

(My googling has been fruitless. As a threading newbie, my threading vocabulary is a bit weak so maybe that is the problem?)

It is probably worth mentioning that my thread is started by a Spring-based servlet in Tomcat...and that I am concerned about thread exit behavior on Tomcat shutdown.

Thanks in advance!

Stu

[Nicole Lacoste]

Hi,

I am also sort of a newbie... but as far as I understand it the way that a thread is shut down before it is finished naturally (returned from run), is the jvm explodes, not much you can do here or by being interrupted. You should do something when you are interrupted, either clean-up, log, and kill the thread by returning or by calling Thread.currentThread().interuppt() to return the interupt status of the thread. Never ignore checked exceptions unless you completly understand why you can ignore them!

Second part of your question is how to make a part of the code atomic. I think you have to know why you want to do that? Is it because it is manipulating data that shouldn't get corrupted by other threads? Use proper synchronization.

synchronized (lock on the data being used)
{
doSomthingThere_1()
doSomthingThere_2()
}

and of course lock the data.

Or is it because you want to time the two functions? I don't know how to do this except to give the thread that is running them top priority, so the scheduler doesn't give a turn to anyone else.

Try looking in the java.util.concurrency package at the atomic stuff to see if there's anything there you can use, or just wait for a better anwser :-)

Niki

[Stu Thompson]

Hi Nicole,

Thanks for the input. I was thinking there might be some sort of signal that I could catch so I could end the thread internally rather than have the JVM do the nasty deed.

The reason I want the two operations atomic is not because of any synchronization issues (I understand that stuff) but because my logic modifies two individual pieces of data--if my code modifies one then it should modify the other. My concern is that if the JVM stops the thread between the two operations. That would be undesirable.

Stu
[ February 08, 2007: Message edited by: Stu Thompson ]

[Nicole Lacoste]

Hi,

I realized that what I said wasn't totally clear.

If your thread is interrupted and you ignore it nothing happens. This means that no one else can force the thread to shut down by interrupting it. Interruption is a mechanism that allows threads to behave themselves but a thread is not required to behave, so it doesn't make much sense to interrupt threads who's behavour when interrupted is unknown. You can check to see if your thread has been interrupted by calling

public static boolean interrupted()

From the sun java api doc

Tests whether the current thread has been interrupted. The interrupted status of the thread is cleared by this method. In other words, if this method were to be called twice in succession, the second call would return false (unless the current thread were interrupted again, after the first call had cleared its interrupted status and before the second call had examined it).

If you call interrupted and then do something, like log it, you can call interrupt() to restore (not return as I mistyped in the previous post) its interrupt status.

One last way a thread can stop prematurely is due to an uncaught exception. If you extend ThreadGroup and override the uncaughtException method this method will be called when your thread dies, so here you can do stuff like log the problem or even start a new thread.

So I think that the ways a thread can stop are
1. reach the end of the run method
2. jvm explodes and kills the thread
3. gets interrupted and kills itself
5. gets exploded by a runtime exception

If anyone knows any other ways please tell me


Niki

[Stan James]

See Runtime for ShutdownHook. You might be able to make a hook that knows about running critical threads and waits for them to complete before returning. SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows may not run the shutdown hooks.

[Stu Thompson]

Hi Niki, Stan: Thanks for the feedback. After reading your posts over and over...and some experimentation...I finally have a grasp on how it works/should work. It looks like I need to go learn some more about Spring so I can tell my thread to shut down gracefully.

Thanks again.

Stu