Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

join() and completely stopping a thread

 
Francisco I
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
Francisco I
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3244
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 171
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
try using Thread.interrupt() to interrupt each thread.
Geoffrey
 
Francisco I
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic