6

According to Goetz in his book JCIP :

Because each thread has its own interruption policy , you should not interrupt a thread unless you know what interruption means to that thread .

Why did the Java language provide a public interrupt () method then ?Is this a design flaw? Who or what is supposed to interrupt a thread then ?

Inquisitive
  • 7,476
  • 14
  • 50
  • 61

4 Answers4

4

What he means is that if you don't know what a thread does and how it works, you should not interrupt it. Since all threads can be interrupted, it is logical to have an interrupt() method in class Thread.

You could ask the same thing for many other methods that can do "harm" when executed at the wrong place. The methods are the tools, and the programmer must use these tools wisely in order to create a program that works correctly.

vainolo
  • 6,907
  • 4
  • 24
  • 47
2

I first recommend you to read Java Concurrency in Practice.

I think, this question can answer what you mentioned.

By the way, let's see how we can prevent threads. We can prevent a thread from execution by using any of the 3 methods of Thread class:

  1. yield()
  2. join()
  3. sleep()

  1. yield() method pauses the currently executing thread temporarily for giving a chance to the remaining waiting threads of the same priority to execute. If there is no waiting thread or all the waiting threads have a lower priority then the same thread will continue its execution. The yielded thread when it will get the chance for execution is decided by the thread scheduler whose behavior is vendor dependent.

  2. join() If any executing thread t1 calls join() on t2 i.e; t2.join() immediately t1 will enter into waiting state until t2 completes its execution.

  3. sleep() Based on our requirement we can make a thread to be in sleeping state for a specified period of time.

Community
  • 1
  • 1
Lion
  • 18,729
  • 22
  • 80
  • 110
  • 1
    I do not get how it answers my question .you provided text on what the yield(),join() and sleep can do ...I think your answer and my question are disconnected or am I missing something here ? – Inquisitive Jul 13 '12 at 11:52
  • If you don't understand what is mentioned there then you need to study more. I was just about to mention the same in my answer before I found that question. – Lion Jul 13 '12 at 12:00
  • the link is okay but everything after the first paragraph in your answer is unnecessary and did not add any value to my question . Hence the -1. – Inquisitive Jul 13 '12 at 12:11
  • -1 doesn't matter me but I added it just for an additional thing. Hopefully thought that it might be useful to someone. – Lion Jul 13 '12 at 12:14
1

Well, its not a flaw, by no means. (However, other methods like Thread.stop() indeed are)

What makes Thread.interrupt()better is that it only affects the thread if it is blocked/waiting/sleeping. If it is running interrupt() only asks the thread to stop doing so by setting a status variable, which can be queried by Thread.interrupted() or Thread.isInterrupted()

Usually, it is the best way to let threads return from their run() method instead of stopping them externally in any way. 

void run() {
    while(!isInterrupted())
        //executed

}

Be careful with Thread.interrupted() though, because it clears the interupt-status.

TeaOverflow
  • 2,468
  • 3
  • 28
  • 40
0

I don't think accepted answer exactly answers Goetzs statement. You should call interrupt() only to restore interrupted flag after catching InterruptedException if you can't rethrow it. Unless it is your own thread (you call start() on it somewhere)

Ivan
  • 87
  • 1
  • 6