*
The moose likes Beginning Java and the fly likes Regarding non-static interrupt() and join() methods. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Regarding non-static interrupt() and join() methods." Watch "Regarding non-static interrupt() and join() methods." New topic
Author

Regarding non-static interrupt() and join() methods.

ven jovovich
Ranch Hand

Joined: Sep 06, 2012
Posts: 33
Hi all,
The following code is from the Java Tutorials:


Please tell me whether I am getting this correctly:
Supposing that the condition of "line 0" is always true, thread "t" will be interrupted at "line 1".
Now, we are doing "t.join()" on "line 2" so that the exception ALWAYS gets handled (caught)
and "I wasn't done!" always gets printed before "Finally!", right? If we commented out "line 2"
then "Finally!" might have been printed before "I wasn't done!" in some cases. Other than
this there is no point in joining a thread that has been interrupted.

Please let me know if my understanding is correct.

...and one more thing my fellow ranchers, please go through this thread:
https://www.coderanch.com/t/608307//java/Java

It makes me wonder if it's worth learning java, static methods in interfaces !!! ?? C'mon....
maybe java will be something different with release 12 or 13, they just might drop
curly braces as well (python style).

Regards,
Ven Jovovich.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

ven jovovich wrote:It makes me wonder if it's worth learning java, static methods in interfaces !!! ?? C'mon....

Wierdly enough, it's one of the things that I like (AND that I've had reason to want).

The fact is that you can already do it:but it's clumsy.

maybe java will be something different with release 12 or 13, they just might drop curly braces as well (python style).

And where do you think Python got it from?

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
ven jovovich
Ranch Hand

Joined: Sep 06, 2012
Posts: 33
Thanks Winston, but could you kindly let me know if what I understood from the code is correct...


it's one of the things that I like (AND that I've had reason to want)

Not that I don't like it, in fact it would be neat to have such a thing but what I meant was: by
defining a method in an interface, we are actually changing the definition of what an interface
is. Don't you think this is a huge deviation from what we currently know / understand? It's like
relearning what an interface is. After a few more releases we might have to relearn
what a class is ;)

And where do you think Python got it from?


Where?

Regards,
Ven Jovovich.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

ven jovovich wrote:they just might drop
curly braces as well (python style).


By all the gods and devils there may be, I hope not. Giving semantics to the amount of whitespace? Ick.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4167
    
  21

ven jovovich wrote:Please tell me whether I am getting this correctly:
Supposing that the condition of "line 0" is always true, thread "t" will be interrupted at "line 1".
Now, we are doing "t.join()" on "line 2" so that the exception ALWAYS gets handled (caught)
and "I wasn't done!" always gets printed before "Finally!", right? If we commented out "line 2"
then "Finally!" might have been printed before "I wasn't done!" in some cases.

RIght.

Other than this there is no point in joining a thread that has been interrupted.

I don't think I agree with that. In fact, just interrupting a Thread doesn't ensure it will end soon. The Thread has to respond to the interrupt, and even so it may take significant amount of time to clean up after itself. So if the task in the current Thread needs to wait for the other Thread to complete (interrupted or not) a join() is a good thing to do make sure the other Thread completed in an orderly fashion.

Steve
ven jovovich
Ranch Hand

Joined: Sep 06, 2012
Posts: 33

In fact, just interrupting a Thread doesn't ensure it will end soon. The Thread has to respond to the interrupt, and even so it may take significant amount of time to clean up after itself.

Thanks a ton, that explains this:


Output:


So even though my thread (main thread) interrupts another thread, there is no guarantee that the execution of the other thread will stop?

Regards,
Ven Jovovich.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4167
    
  21

ven jovovich wrote:So even though my thread (main thread) interrupts another thread, there is no guarantee that the execution of the other thread will stop?

Correct. And there is no way to guarantee that another Thread will stop (safely). The code in the other thread has to cooperate either checking for the interrupt status of the thread (Thread.interrupted() or currentThread.isInterrupted() depending on intent) and uses interruptable APIs whenever blocking. A common idiom is to use interruption in conjunction with a state variable so your code knows when an interrupt was intended for ending the task as opposed to being accidental:

Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

ven jovovich wrote:Thanks a ton, that explains this:...

At the risk of getting flamed by Threading nuts, and Steve's excellent advice notwithstanding, I'd add this personal opinion:
Java has (deliberately) made multi-threading very easy compared to a lot of other languages; but this apparent "simplicity" comes at the price of people giving it the old Harvard Try before they're ready for it.

The fact is that, like reflection (and a few other things) that Java allows, it needs to be approached with caution. Unless you work in a very specialized environment, the amount of time you spend writing multi-threaded programs is likely to be pretty low.

Writing them also involves a lot of side issues that Java doesn't cover as well - the most obvious of which is testing: Threaded programs can be absolute swines to test properly without getting into the world of "Bots" (and sometimes even then).

So, if this is a learning exercise, don't let me stop you - it's all good stuff - just be sure that you know what you're getting into if you plan on making it your "way of life".

Winston
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Winston Gutkowski wrote:The fact is that, like reflection (and a few other things) that Java allows, it needs to be approached with caution. Unless you work in a very specialized environment, the amount of time you spend writing multi-threaded programs is likely to be pretty low.


I agree with everything you said except this. Okay, so I kind of agree with the actual statement, but I don't agree with what it seems to imply. The amount of time I spend writing actually writing multithreading code or using reflection is low as a percentage of my total coding effort. That part is true.

However, it seems to imply that, A) Since it's not a large fraction of our total development effort, that implies it's not used in many applications, and B) Since it's not a large fraction of our development effort, it's not something we need to spend a lot of time understanding. I disagree strongly with both of those implications. Multithreading and reflection have both come into play in every project I can ever remember working on. Even if they occupy only a little bit of the code, that code still has to run correctly. Since both of those concepts have their own quirks that can make them tricky to use correctly--and especially because that code isn't a major fraction of our total development effort--we need to make sure we understand them properly so that when we are spending that small fraction of our time on them, we do it correctly.

And even if we're not actually writing multithreading code or reflective code, chances are we're interacting with it, so we still have to be acutely aware of the rules.

I'm pretty sure you didn't actually mean either of the implications I read into what you said, but I thought someone might take it that way, and as a "threading nut", I had to put my two cents in.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7552
    
  18

Jeff Verdegan wrote:However, it seems to imply that, A) Since it's not a large fraction of our total development effort, that implies it's not used in many applications, and B) Since it's not a large fraction of our development effort, it's not something we need to spend a lot of time understanding. I disagree strongly with both of those implications.

That wasn't my intent (especially B). I would, however, say that I tend to think of both as techniques of last resort (especially reflection); so if you do decide to use them, you'd better be prepared to defend the choice.

I think you know me well enough to know that I'd never say that anyone shouldn't learn new techniques; my advice was more on the lines of "understand before you use" and "know when (and, probably more importantly, when not) to use". For example: using reflection to save yourself typing (or thinking) is poor practise as far as I'm concerned.

I'm pretty sure you didn't actually mean either of the implications I read into what you said, but I thought someone might take it that way, and as a "threading nut", I had to put my two cents in.

Yeah. I knew I'd run into at least one.

Winston
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Winston Gutkowski wrote:
I think you know me well enough to know that I'd never say that anyone shouldn't learn new techniques


Of course.

my advice was more on the lines of "understand before you use" and "know when (and, probably more importantly, when not) to use".


Always sound advice.

Both those tools definitely have their place, but there are also a ton of places that don't belong to them but that the unwary will try to shoehorn them into.
 
Don't get me started about those stupid light bulbs.
 
subject: Regarding non-static interrupt() and join() methods.
 
Similar Threads
Thread,Join problem
Interrupt Handling
t.join() in Sun's thread example
Code confusion
what is happening here