Java 101: Understanding Java threads, Part 3: Thread scheduling and wait/notify

When you must determine a thread's current priority, call Thread's int getPriority() method, via that thread's thread object. The getPriority() method returns a value between MIN_PRIORITY (1) and MAX_PRIORITY (10). One of those values might be 5—the value that assigns to the NORM_PRIORITY constant, which represents a thread's default priority.

The setPriority(int priority) method proves useful in preventing processor starvation. For example, suppose your program consists of a thread that blocks and a calculation thread that doesn't block. By assigning a higher priority to the thread that blocks, you ensure the calculation thread will not starve the blocking thread. Because the blocking thread periodically blocks, the calculation thread will not starve. Of course, we assume the thread scheduler does not support time-slicing. If the thread scheduler does supports time-slicing, you will probably see no difference between calls to setPriority(int priority) and no calls to that method, depending on what the affected threads are doing. However, you will at least ensure that your code ports across thread schedulers. To demonstrate setPriority(int priority), I wrote PriorityDemo:

Listing 2. PriorityDemo.java

// PriorityDemo.java
class PriorityDemo
{
   public static void main (String [] args)
   {
      BlockingThread bt = new BlockingThread ();
      bt.setPriority (Thread.NORM_PRIORITY + 1);
      CalculatingThread ct = new CalculatingThread ();
      bt.start ();
      ct.start ();
      try
      {
          Thread.sleep (10000);
      }
      catch (InterruptedException e)
      {
      }
      bt.setFinished (true);
      ct.setFinished (true);
   }
}
class BlockingThread extends Thread
{
   private boolean finished = false;
   public void run ()
   {
      while (!finished)
      {
         try
         {
            int i;
            do
            {
               i = System.in.read ();
               System.out.print (i + " ");
            }
            while (i != '\n');
            System.out.print ('\n');
         }
         catch (java.io.IOException e)
         {
         }
      }
   }
   public void setFinished (boolean f)
   {
      finished = f;
   }
}
class CalculatingThread extends Thread
{
   private boolean finished = false;
   public void run ()
   {
      int sum = 0;
      while (!finished)
         sum++;
   }
   public void setFinished (boolean f)
   {
      finished = f;
   }
}

PriorityDemo has a blocking thread and a calculating thread in addition to the main thread. Suppose you ran this program on a platform where the thread scheduler did not support time-slicing. What would happen? Consider two scenarios:

1. Assume no bt.setPriority (Thread.NORM_PRIORITY + 1); method call: The main thread runs until it sleeps. At that point, assume the thread scheduler starts the blocking thread. That thread runs until it calls System.in.read(), which causes the blocking thread to block. The thread scheduler then assigns the calculating thread to the processor (assuming the main thread has not yet unblocked from its sleep). Because the blocking, main, and calculating threads all have the same priority, the calculating thread continues to run in an infinite loop.
2. Assume bt.setPriority (Thread.NORM_PRIORITY + 1); method call: The blocking thread gets the processor once it unblocks. Then assume that the thread scheduler arbitrarily chooses either the calculating thread or the main thread (assuming the main thread has unblocked from its sleep) when the blocking thread blocks upon its next call to System.in.read(). As a result, the program should eventually end. If the thread scheduler always picks the calculating thread over the main thread, consider boosting the main thread's priority to ensure eventual termination.

If you run PriorityDemo with time-slicing, you have the following two scenarios: