• Post Reply Bookmark Topic Watch Topic
  • New Topic

Doubt on Thread Interrupt

 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

I often see this code construct in the java app that I have inherited. It's an application full of threaded operation but I havent
seriously work on such type of app so I have my doubt on the following hilited code..



I think the condition just checks if this current thread receives any interrupt, but what if i need the statement in the while
code to run indefinitely as long as the main app is running.

Would'nt it be better if i just create the following code construct?



Whats the trade-off between the two? Thanks
 
Duc Vo
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The first case is preferable since it gives you a mechanism to stop a thread when necessary. Imagine that you need to have form with two buttons one to trigger a process (i.e. create a new Thread) and another one to cancel it. The first case will easy support this. Just set the flag to true or call the interrupt() method of the thread. However the second case won't. There'll be no way to stop the thread without any error and/or kill the OS process.
 
Campbell Ritchie
Marshal
Posts: 52581
119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This question is more complicated than we usually see here on beginners'. Moving thread.
 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello duc, got your point.. thank you..

but just one more thing, the synchronized keyword in the run method, does it has something to do
with checking if there's any thread interruption?

is

and



does different thing on the background? I am really not sure about the synchronized keyword when
it comes to thread, I am not sure of this, because as I know making the run method synchronized
in thread classes does not guarantee that the thread will not be interrupted by the thread scheduler.

Thanks again
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
mark reyes wrote:hello duc, got your point.. thank you..

but just one more thing, the synchronized keyword in the run method, does it has something to do
with checking if there's any thread interruption?

No, it has nothing to do with interruption.

mark reyes wrote:does different thing on the background? I am really not sure about the synchronized keyword when
it comes to thread, I am not sure of this, because as I know making the run method synchronized
in thread classes does not guarantee that the thread will not be interrupted by the thread scheduler.

Thanks again


The synchronized keyword makes sure that method will not be executed twice at the same time on a single instance of the MyThread class. It is a sign that the method should be treated as a single unit and no other thread can execute that code until the first one is done.

Let's show an example. Let's say you have this code which holds some data that can be used later on. For this example I will make it a Runnable (rather than a Thread) which loads the data from a database, checks that the data meets some criteria, then releases it to the public for consumption by assigning it to a variable with an accessor method.

[Note that this is a pretty poor un-thought-out example... don't copy this code unless you put more thought into making it work right...]

I decide to run this code as such:

I then may want to load data again, like:

But there could be a problem. What if I start t2 before the first thread loading data finishes? We could get unforeseen circumstances. For example, the getData() method should fail if the dataLoaded boolean is false, and since the dataLoaded boolean is set to false at the start of the run() method, and only set to true after the data passes a check for consistency I would expect that as long as getData() does not throw an exception I have new data and that data is good.

But when I allow the run() method to execute twice simultaneously bad things can happen. For example:

In this case, Thread1 sets the dataLoaded variable to true because it was working on old data and the old data was good, but Thread2 overwrites the old data with new data which is bad, and so doesn't pass the test. But dataLoaded variable was set to true AFTER the bad data was assigned. So now a call to getData() thinks the data is good even though it is not. The problem is that the currently executing thread is controlled by the OS, we don't have the ability to make sure the Thread context doesn't switch at in-opportune times and causing errors.

If I put the synchronized keyword in the run() methods signature it would prevent both Threads from working at the same time, and would help prevent this sort of inconsistent state from occurring by making sure the first thread is done before the second call to run() is allowed to start:

Would force execution to look something like this:

Now when the getData() method gets called, and since Thread2 has set the data to bad data and the dataLoaded variable to false, then getData() method would throw the exception we would expect.

If you are starting on Threads, synchronized is a key concept you should learn well. There is a lot to it. You can start by reading this trail on the Java Tutorials about Threading. Looking up a good book on Concurrency in Java would help too, like perhaps Java Concurrency in Practice which I hear is good.
 
Duc Vo
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mark,

The synchronized keyword has nothing to do with thread interruption as mentioned by Steve in the previous post. Just an additional comment, if your class extends Thread, then there is not much difference to put or not to put a synchronized keyword on the run() method since you can only start a thread on a Thread object once (i.e. The run method of a Thread object won't be executed by concurrent threads anyway).

In short, to answer your question
(1) No, it has nothing to do with thread interruption.
(2) No, it makes no difference on the background if you extended Thread class as in your sample code.

Hope it help,

Duc

 
Mark Reyes
Ranch Hand
Posts: 426
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Steve, Duc...

Thank you for a very detailed explanation on this subject,
I got a clear insight on whats going on in the apps that i am working on..
Better to read more about this subject..

You both rock!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!