Lecture Notes for Concurrent Programming

3 July 2003 - Thread Interrupts

Thread Interrupts

• The Interrupt Flag

• Thread Interrupt Methods

• Using Thread Interrupts

• Handling Thread Interrupts

• Larger Issues

The Interrupt Flag

• The interrupt flag is a per-thread boolean flag.

• If the interrupt flag is true, the thread throws a InterruptedExecution .

  • The flag is cleared when the exception is thrown.

• The exception is thrown only at an interruption point.

  • An interruptible method contains interruption points.

  • It could take a thread a while to reach an interruption point.

    class Godot extends Thread {
      public void run() { while (true) { } }
      }
    

  • wait(), join(), and sleep() are interruptible methods.

    • Interrupts race with notify().

    • synchronized does not.

Thread Interrupt Methods

• Three Thread methods manipulate a thread's interrupt flag.

  • The flag's not externally accessable.

• t.interrupt() sets thread t's interrupt flag to true.

  • The current value of t's value is ignored.

  • If t is blocked, it is unblocked.

  • Setting the interrupt flag may not cause an immediate interrupt.

• Thread.interrupted() returns the current thread's interrupt flag.

  • Clears the calling thread's flag if it's set.

  • A thread with a cleared flag doesn't throw an interrupt.

  • This is a static Thread method.

• t.isInterrupted() returns t's interrupt flag.

  • t's flag is not changed.

Using Thread Interrupts

• Thread interrupts provide three main functions:

  1. asynchronous thread-to-thread communication,

  2. one-bit communication, and

  3. unblocing blocked threads.

• Convention interprets an interrupt as "cancel execution".

  • For this use thread interrupts are fine.

    • But consider developing custom mechanisms.

  • Threads are less appropriate for other uses.

Asynchronous Thread-to-Thread Communication

• Thread interrupts support asynchronous thread-to-thread communication.

  • The interrupting thread just calls interrupt().

  • No prior arrangement with the interrupted thread is needed.

  • Any thread with a thread reference can interrupt the referenced thread.

• Consider using a mutually shared class instance instead.

  class Interrupt {
    public boolean raised = false
    }
  
  final Interrupt intrpt = new Interrupt()
  final PCRunnable 
    producer = new PCRunnable(intrpt)
    consumer = new PCRunnable(intrpt)
    master   = new PCRunnable(intrpt)
  

  • Create arbitrary communication topologies with selective class instance sharing.

  • You can create anarchy too, if you're not careful.

Unblocking Threads

• An interrupt can unblock a blocked thread.

  • The thrown InterruptedExecution takes care of that.

  • The InterruptedIOException is essential in I-O operations.

    • Unfortunately, it it also ill defined and ill behaved.

• A suitably prepared shared class instance can also unblock threads.

  class PCRunnable
  implements Runnable
  
    private Interrupt intrpt
  
    PCRunnable(Interrupt i)
      intrpt = i
  
    public void run()
      while more work && !intrpt.raised
        // do more work
  

• You need InterruptedExecutions for blocking inside wait(), join(), and sleep().

One-Bit Communication

• Interrupts allow one-bit communication.

  • The interrupting thread sets the flag and the interrupted thread reads it (before InterruptedExecution is thrown).

• Shared class instances can communication arbitrary data.

  class Interrupt
    int id
  
  public void run()
    while more work && intrpt.id != myId
      // do more work
  

  • Don't forget to protect the shared data against concurrent access.

  • JVM semantics make this way harder than it should be.

Handling Thread Interrupts

• How can code handle InterruptedExecution exceptions?

• There are two problems to deal with directly.

  1. Handling premature exit from interruptible methods.

     • Re-establish consistent state, if necessary.

  2. Hnadling the InterruptedExecution exception.

     • Indicate failure, if appropriate.

• There are three ways to deal with them.

  • Indolence, ignorance, propagation.

  • The best choice depends on the situation.

Indolence

• Don't deal with interrupts at all.

  • Simple, but usually a bad choice.

    • The exception catcher can't do much either.

  • The exception may leave inconsistent state.

• Pretending interrupts never happen.

  synchronized void down() {
  
    // Manipulate some state to prepare.
  
    while (!condition) wait()
  
    // Manipulate the state some more.
    }
  

  • The while handles premature exit.

  • The exception, however, percolates out.

Ignorance

• Ignore exceptions.

  • Usually simple, but breaks interrupts.

  • Unbounded thread execution possible.

• Exception ignoring example.

  synchronized void down()
  
    // Manipulate some state in preparation.
  
    while (count < 1) 
      try { wait() }
      catch (InterruptedExecution ignore) { }
  
    // Manipulate the state some more.
  

  • The exception has disappeared.

Propagation

• The classic pass-the-buck response.

  • Catch the InterruptedExecution exception.

  • Do whatever clean-up's necessary.

  • Rethrow the exception, or use some other method to indicate failure.

• Simple initially, but can get complicated.

  • With no clean-up, it's similar to indolence.

  • Callers may not know how to deal with interrupted execution.

• Propagation example.

  synchronized void down()
    while count < 1
      try { wait() }
      catch (InterruptedExecution ie)
        // clean up
        throw ie
  

  • down() could also return a boolean to indicate success or failure, avoiding the rethrow.

Larger Issues

• Having enough interruption points.

  • Compute-bound threads may not ever get interrupts.

  • Structure the computation to check occasionally.

    class Godot extends Thread
      public void run()
        while (true)
          int i = 1000
          while (i-- > 0)
    	compute()
          if (Thread.interrupted())
    	// clean up and exit
    

• Interrupts are asynchronous and autonomous.

  • Not at all like hardware.

• Interrupts are not stacked.

  • Follow-up interrupts can get lost.

  • One-to-many works, many-to-one doesn't.

Points to Remember

• Interrupts provide asynchronous, zero-bit communication between threads.

  • Consider other forms first.

• Interrupts can unblock threads, and result in exceptions.

  • Good code should handle both.

• Interrupt behavior follows convention.

  • Usually premature thread termination.

• Follow convention, but consider interrupt alternatives.

  • Shared termination objects.

  • Blocking's the problem here.

This page last modified on 14 July 2003.