Win a copy of The Journey To Enterprise Agility this week in the Agile and Other Processes forum! And see the welcome thread for 20% off.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

I dont understand Java's workaround for stopping a thread  RSS feed

 
Ranch Hand
Posts: 97
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI Everyone,

According to this article http://docs.oracle.com/javase/6/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html it says to perform the following as a mechanism for stopping a thread of execution




how is calling stop() method on this ensuring that the currently running thread of execution stops? what i mean is lets say repaint()method is already invoked. while repaint() method is executing , if i call sstop() according to me nothing will happen. repaint method will still complete execution. the above code ensures that the next time when this thread is picked up for execution, it will check for the stop flag.

AM i wrong in my understanding? please help
 
Sheriff
Posts: 23640
48
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the code is a little bit incomplete, but assuming that I'm right about what you didn't post...

Yes, your understanding is mostly correct. The "stop" method will not stop the thread instantly, it will just cause the thread to end when it's ready to end. However this part:

the above code ensures that the next time when this thread is picked up for execution, it will check for the stop flag.



I don't think that's correct. Although it really depends on what you mean by "picked up for execution". The Thread you've posted there runs an infinite loop which alternates between sleeping, repainting, and checking whether "stop" has been called. So after you call its "stop" method, it might still sleep for a while. It might repaint again after that. But then it will notice that the condition for the while-loop is no longer true, and it will exit from the "run" method. This causes the Thread to end.
 
Stanley Walker
Ranch Hand
Posts: 97
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you paul.

lets suppose i tweak the requirement a bit. lets say my run() method needs to call repaint() only once. in such a case, how do i stop a thread from completing the repaint() method

eg given below

 
Paul Clapham
Sheriff
Posts: 23640
48
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't. If you want the repaint() method to be interruptible, you have to write it that way. It just isn't possible for Java to interrupt arbitrary code and have it return from a method, abnormally or otherwise.
 
Stanley Walker
Ranch Hand
Posts: 97
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

It just isn't possible for Java to interrupt arbitrary code and have it return from a method, abnormally or otherwise.


I was thinking the same way, but numerous google searches on the internet on the same topic made me think that it might be possible. Thank you for the clarification, Paul
 
Bartender
Posts: 19660
92
Android Eclipse IDE Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the original Java, it was possible for an external source (another thread) to forcibly stop a thread.

This was determined to be a bad idea, since a thread could be halted while in the middle of a sensitive operation, while holding locks (synchronized code), and/or while holding resources that needed to be properly freed.

So support for that type of operation was withdrawn in favor of a convention where a thread would check for external notification that it should halt itself (after first properly cleaning up).

Even full-blown operating systems, which often have extensive built-in resource management, termination and recovery facilities have occasional problems with thread/process breakage, as can be seen with the Linux "Zombie" process status, so Java avoided all the complications by insisting on use of a simpler model.
 
Bartender
Posts: 543
4
Java Netbeans IDE Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The idea here is just that the thread runs its due course. The best method of being able to stop/interrupt a thread, is writing your code to check whether it is allowed to continue before it continues.

So if you're writing code where you need to call a Thread's API to interrupt or stop it, you're going about it the wrong way.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!