File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes join() and completely stopping a thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "join() and completely stopping a thread" Watch "join() and completely stopping a thread" New topic
Author

join() and completely stopping a thread

Francisco I
Ranch Hand

Joined: Mar 27, 2001
Posts: 44
Hi,
I am dealing with threads. I have an ArrayList of threads which I am trying to stop. The run() method in the threads is a while loop.. i.e. while(isRunning){ do something }
Now, I set this "isRunning" variable to false when I want to stop the thread. It exits the run method, but the thread is still alive. I use the join() method to make sure it has died, but it hangs on the join(). What can be keeping the threads from dying?. being dead and stopped are different?
thanks!
Francisco
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Francisco
Dead and stopped mean two different things, a dead thread is oe that has completed its run method, while a stopped thread is one that is not running for any number of reasons. I'm not sure what you mean by 'it hangs on' the join() method. I haven't tried joining to a thread that has already stopped at best I would think you'd get an exception at worst it would be unpredictable. Instead of testing useing join you should use isAlive(), it returns a boolean telling if the thread has started but has not completed its run method yet.
that should take care of your problem, hope it helps
Dave

[This message has been edited by Dave Vick (edited September 17, 2001).]


Dave
Francisco I
Ranch Hand

Joined: Mar 27, 2001
Posts: 44
Originally posted by Dave Vick:
Instead of testing useing join you should use isAlive(), it returns a boolean telling if the thread has started but has not completed its run method yet. 2001).]

Hi dave. Yes, my code looks like
if(t.isAlive()) t.join(); where t is a Thread.
should I test for isAlive() until it dies?... Actually, the debugger I am using shows the threads that are alive, and mine never die...
Any other advice on at least, a sudden stop?
thanks.
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Francisco
Can you post more code? Without seeing more of an example of what your doing the only thing I can think of is that you're running into a scheduleing conflict. Try joining to the thread then killing it. Maybe the thread is getting killed between the test and the join - that is probably pretty unlikely to happen all of the time, but possible.
Post some more code (if its a lot then cut out what isn't neccesary) and I'l take a look at it for you.

------------------
Dave
Sun Certified Programmer for the Java� 2 Platform
Geoffrey Falk
Ranch Hand

Joined: Aug 17, 2001
Posts: 171
    
    1
try using Thread.interrupt() to interrupt each thread.
Geoffrey

Sun Certified Programmer for the Java 2 Platform
Francisco I
Ranch Hand

Joined: Mar 27, 2001
Posts: 44
Ok. Here's some more code...
Sorry!, I forgot to put the code tag around it in the previous email....
controlThreads is an ArrayList..
so:

I hope you guys can help me.
Thanks!.
(The problem is: It hangs and waits forever in the t.join() )
Thnx again.

[This message has been edited by Marcela Blei (edited September 18, 2001).]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Well, I'm not sure if it is your problem or not, but it is certainly a source of JVM-dependent bugs: access to isStopped should be synchronized, or alternatively isStopped needs to be declared volatile.
Generally, a debugger or good old System.out.println will tell you whether the problem is that join() doesn't work or simply that the threads don't stop.
Finally, what was wrong with interrupt()? You're reinventing the wheel here (and paying for it from the looks of it).
- Peter
Francisco I
Ranch Hand

Joined: Mar 27, 2001
Posts: 44
Originally posted by Peter den Haan:
Well, I'm not sure if it is your problem or not, but it is certainly a source of JVM-dependent bugs: access to isStopped should be synchronized, or alternatively isStopped needs to be declared volatile.
Generally, a debugger or good old System.out.println will tell you whether the problem is that join() doesn't work or simply that the threads don't stop.
Finally, what was wrong with interrupt()? You're reinventing the wheel here (and paying for it from the looks of it).
- Peter

What would be the benefits of synchronize or volatile?... Oh, instead of isStopped, I had t.interrupted(), and I had used interrupt, but that didn't work at all. I would interrupt the thread, but the while loop, for some reason I don't know, would never exit. Any ideas?.. PS: I'd like to use thread methods, and not do the isStopped thing, so any advice is more than welcomed.
Francisco.
marilyn murphy
Ranch Hand

Joined: Aug 28, 2001
Posts: 84
I think interrupt() by itself does not stop the thread. You have to check with the isInterrupted() and if the flag has been set, do something to exit the thread.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Francisco Iacobelli:
What would be the benefits of synchronize or volatile?
Unless you use either, there is no guarantee that your code in the thread ever gets to see a modified value of isStopped - the variable might be held in a register and never re-read from memory. Again I'm not sure how theoretical this point is.
Oh, instead of isStopped, I had t.interrupted(), and I had used interrupt, but that didn't work at all. I would interrupt the thread, but the while loop, for some reason I don't know, would never exit. Any ideas?
Did you take into account that Thread.interrupted() actually clears the flag? If you'd do something likeit will not work. My preferred method of handling interrupts is simply stick inside a reasonable inner loop:and handle cleanup etc. in finally clauses. Typically the interrupt is caught only at the outermost level in the run() method.
- Peter

[This message has been edited by Peter den Haan (edited September 19, 2001).]
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Francisco Iacobelli:
Hi,
I am dealing with threads. I have an ArrayList of threads which I am trying to stop. The run() method in the threads is a while loop.. i.e. while(isRunning){ do something }
Now, I set this "isRunning" variable to false when I want to stop the thread. It exits the run method, but the thread is still alive. I use the join() method to make sure it has died, but it hangs on the join(). What can be keeping the threads from dying?. being dead and stopped are different?
thanks!
Francisco

No stopped and dead are not 2 differen things. You must remember that starting and ending a thread takes time. So for instance if you said

This will more than likely NOT print "is alive" because it takes time for a thread to start and it likely may not be running by the time x.isAlive() is called. Same with an ending thread. If you set a variable which will cause your thread to end, you can't expect the ending to occur instantaneously, it will take a few milliseconds and you can miss it.
try seeing what happens if you say this

you will see that this while loop will eventually quickly exit, but it will cycle a few times.
Francisco I
Ranch Hand

Joined: Mar 27, 2001
Posts: 44
Originally posted by CL Gilbert:
[B]
try seeing what happens if you say this

you will see that this while loop will eventually quickly exit, but it will cycle a few times.[/B]

Thank you. I'll check that.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: join() and completely stopping a thread