Java : Calling interruptible methods from the code

Question

I am reading the 7th chapter of Java Concurrency in Practice.

In a section which speaks about methods that do not have a cancellation policy of its own but calls methods that can be interruped, the book has the following thing to say.

Activities that do not support cancellation but still call interruptible blocking methods will have to call them in a loop, retrying when interruption is detected.In this case, they should save the interruption status locally and restore it just before returning, rather than immediately upon catching InterruptedException.

I haven't understood this fully.

Does it mean, if I call Thread.sleep in my method, I will have to call it in a loop or something?

Can anyone explain why it should be done so?

Answer 1

I call Thread.sleep in my method, I will have to call it in a loop or something ?

Thread.sleep() will throw an InterruptedException when the current thread is interrupted (by another thread). It's your choice how to react to that. If you want to sleep, regardless of if someone is trying to interrupt you, then yes, you have to build some kind of loop around the try-catch block. Probably you should use a clock (e.g. System.nanoTime()) to check how long you had slept before the exception was thrown, and then continue sleeping for the remaining time etc.

Note that InterruptedException is thrown only if another thread has interrupted the current thread, by calling (current)Thread.interrupt(). It doesn't happen by itself, so in general you don't need to build any loops around sleeps or anything like that. Usually threads are interrupted only for a good reason (e.g. application shutting down), so you probably want to support cancellation / interruption unless there's no special reason not to. A "special reason" could be, for instance, writing to an I/O device and trying to guarantee that all data will be written, regardless of cancellation attempts.

Answer 2

As far as I understand this: A long running Service, that cannot itself be or should not be interrupted, is calling other methods that can be interrupted. So this long running Service should be able to detect this and report it through a method or a flag. But it should be able to try the operation again instead of just throw the InterruptedException.

To call a method that blocks means, the current execution is blocked and is waiting until the blocking method will return a value. This could be done in a loop. You know then if the method call was successfull or if the method called is interrupted.

Answer 3

I don't have the book. But as far as i understood, if an activity interrupted (sleep is not an interrupt signal by the way. But you can awaken a thread from sleep via interrupt signal), the activity needs to save it's current dynamic data(interruption status) in order to restore itself and resume from previous state. For example;

//Let's say you have integer data named "a"...
a = 45646;

//Normally after interruption, and terminating the activity data a is currently
//referencing @memory will be released...

//If you want to continue using data in a you have to save it somewhere
// persistant(Let's say a file)
void onInterruptionDetected()
{
    saveToSomeFile(a, "temp.txt");
}

//After re-execution of activity(Assuming we need a's previous data in order to 
// continue...), we can recover a's data(which is 45646) in previous interruption...
void onResumeDetected()
{
    a = loadFromFile("temp.txt")
}

Hope this helps, i am still sleepy there might be an error :)

Answer 4

Some explanation first:

The interrupted status of a thread is basically a boolean flag, which is set to "true" by interrupt(). The current state of this flag can be read using Thread.currentThread().isInterrupted().

If an interruptible operation (like Object.wait() or Thread.sleep()) finds the interrupted flag set it will throw an InterruptedException and at the same time clear (set to "false") the flag, which could look like this:

if ( Thread.interrupted() ) { throw new InterruptedException(); }

Note and memorize that Thread.interrupted() implicitly clears the interrupted flag! This means that, by the time your catch( InterruptedException ie) {...} is executed, the thread itself does not know it was interrupted anymore.

That said, let's have a look at two examples:

First an example of a task which supports cancellation. Here, we don't really care how far the task proceeds before being aborted:

  public void run() {

    int x = 0;

    try {

      while (x < 10) {
        Thread.sleep(1000); // Some interruptible operation
        x++;
      }

      System.out.println("x = " + x);

    } catch (InterruptedException ie) {

      System.out.println("Interrupted: x = " + x);

      // We know we've been interrupted. 
      // Let the caller know it, too:
      Thread.currentThread().interrupt();
    }

  }

This code tries to count x from 0 to 10. If it is not interrupted, it will complete and output "x = 10". However, if the thread is interrupted in between, the InterruptedException will be thrown, aborting the ongoing task of incrementing x. In this case the output may be anything from "Interrupted: x = 0" to "Interrupted: x = 9", depending on when the thread was interrupted.

Note that it is considered good practice to restore the interrupted flag of the thread before exiting since otherwise the interrupted status will not be seen by the caller of this run() method.

Now, if it is crucial that our task executes in full, so that the output will always be "x = 10", which means the task does not support cancellation, we need another approach:

  public void run() {
    int x = 0;

    boolean wasInterrupted = false; // <- This is the local variable to store the interruption status

    while (x < 10) {

      wasInterrupted = wasInterrupted || Thread.interrupted(); // not really needed in this case, but for the sake of completeness...

      try {

        Thread.sleep(1000); // <- Some interruptible operation

      } catch (InterruptedException e) {
        wasInterrupted = true;
      }

      x++;
    }

    System.out.println("x = " + x);

    if ( wasInterrupted ) {
      Thread.currentThread().interrupt();
    }

  }

In this case we continue processing even after an InterruptedException until the task is completed. To keep being nice, if we detect an interruption, we store that condition in wasInterrupted so that we can correctly set the interrupted flag before returning from the method.

That's what is meant by

should save the interruption status locally and restore it just before returning.

It says "should" because we are not strictly required to handle interruption this way - we may as well just ignore any InterruptedException and just complete our task, then return. This is not the good practice mentioned above, though, and may cause trouble in some scenarios.