Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

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

Learn about the mechanisms that help you set and manage thread priority

By Jeff Friesen, JavaWorld.com, 07/05/02

Page 7 of 7

1. Assume no bt.setPriority (Thread.NORM_PRIORITY + 1); method call: Time-slicing ensures that all equal-priority threads have a chance to run. The program eventually terminates.
2. Assume bt.setPriority (Thread.NORM_PRIORITY + 1); method call: The blocking thread will run more often because of its higher priority. But because it blocks periodically, the blocking thread does not cause significant disruption to the calculation and main threads. The program eventually terminates.

Schedule with the yield() method

Many developers prefer the alternative to the setPriority(int priority) method, Thread's static void yield();, because of its simplicity. When the currently running thread calls Thread.yield ();, the thread scheduler keeps the currently running thread in the runnable state, but (usually) picks another thread of equal priority to be the currently running thread, unless a higher-priority thread has just been made runnable, in which case the higher-priority thread becomes the currently running thread. If you have no higher-priority thread and no other equal-priority threads, the thread scheduler immediately reschedules the thread calling yield() as the currently running thread. Furthermore, when the thread scheduler picks an equal-priority thread, the picked thread might be the thread that called yield()—which means that yield() accomplishes nothing except delay. This behavior typically happens under a time-slicing thread scheduler. Listing 3 demonstrates the yield() method:

Listing 3. YieldDemo.java

// YieldDemo.java
class YieldDemo extends Thread
{
   static boolean finished = false;
   static int sum = 0;
   public static void main (String [] args)
   {
      new YieldDemo ().start ();
      for (int i = 1; i <= 50000; i++)
      {
           sum++;
           if (args.length == 0)
              Thread.yield ();
      }
      finished = true;
   }
   public void run ()
   {
      while (!finished)
         System.out.println ("sum = " + sum);
   }
}

From a logical perspective, YieldDemo's main thread starts a new thread (of the same NORM_PRIORITY priority) that repeatedly outputs the value of instance field sum until the value of instance field finished is true. After starting that thread, the main thread enters a loop that repeatedly increments sum's value. If no arguments pass to YieldDemo on the command line, the main thread calls Thread.yield (); after each increment. Otherwise, no call is made to that method. Once the loop ends, the main thread assigns true to finished, so the other thread will terminate. After that, the main thread terminates.

Now that you know what YieldDemo should accomplish, what kind of behavior can you expect? That answer depends on whether the thread scheduler uses time-slicing and whether calls are made to yield(). We have four scenarios to consider:

1. No time-slicing and no yield() calls: The main thread runs to completion. The thread scheduler won't schedule the output thread once the main thread exits. Therefore, you see no output.
2. No time-slicing and yield() calls: After the first yield() call, the output thread runs forever because finished contains false. You should see the same sum value printed repeatedly in an endless loop (because the main thread does not run and increment sum). To counteract this problem, the output thread should also call yield() during each while loop iteration.
3. Time-slicing and no yield() calls: Both threads have approximately equal amounts of time to run. However, you will probably see very few lines of output because each System.out.println ("sum =" + sum); method call occupies a greater portion of a quantum than a sum++; statement. (Many processor cycles are required to send output to the standard output device, while (relatively) few processor cycles are necessary for incrementing an integer variable.) Because the main thread accomplishes more work by the end of a quantum than the output thread and because that activity brings the program closer to the end, you observe fewer lines of output.
4. Time-slicing and yield() calls: Because the main thread yields each time it increments sum, the main thread completes less work during a quantum. Because of that, and because the output thread receives additional quantums, you see many more output lines.

The wait/notify mechanism

As you learned last month, each object's associated lock and waiting area allow the JVM to synchronize access to critical code sections. For example: When thread X tries to acquire a lock before entering a synchronized context guarding a critical code section from concurrent thread access, and thread Y is executing within that context (and holding the lock), the JVM places X in a waiting area. When Y exits the synchronized context (and releases the lock), the JVM removes X from the waiting area, assigns the lock to X, and allows that thread to enter the synchronized context. In addition to its use in synchronization, the waiting area serves a second purpose: it is part of the wait/notify mechanism, the mechanism that coordinates multiple threads' activities.

The idea behind the wait/notify mechanism is this: A thread forces itself to wait for some kind of condition, a prerequisite for continued execution, to exist before it continues. The waiting thread assumes that some other thread will create that condition and then notify the waiting thread to continue execution. Typically, a thread examines the contents of a condition variable—a Boolean variable that determines whether a thread will wait—to confirm that a condition does not exist. If a condition does not exist, the thread waits in an object's waiting area. Later, another thread will set the condition by modifying the condition variable's contents and then notifying the waiting thread that the condition now exists and the waiting thread can continue execution.

To support the wait/notify mechanism, Object declares the void wait(); method (to force a thread to wait) and the void notify(); method (to notify a waiting thread that it can continue execution). Because every object inherits Object's methods, wait() and notify() are available to all objects. Both methods share a common feature: they are synchronized. A thread must call wait() or notify() from within a synchronized context because of a race condition inherent to the wait/notify mechanism. Here is how that race condition works:

1. Thread A tests a condition and discovers it must wait.
2. Thread B sets the condition and calls notify() to inform A to resume execution. Because A is not yet waiting, nothing happens.
3. Thread A waits, by calling wait().
4. Because of the prior notify() call, A waits indefinitely.

To solve the race condition, Java requires a thread to enter a synchronized context before it calls either wait() or notify(). Furthermore, the thread that calls wait() (the waiting thread) and the thread that calls notify() (the notification thread) must compete for the same lock. Either thread must call wait() or notify() via the same object on which they enter their synchronized contexts because wait() tightly integrates with the lock. Prior to waiting, a thread executing wait() releases the lock, which allows the notification thread to enter its synchronized context to set the condition and notify the waiting thread. Once notification arrives, the JVM wakens the waiting thread, which then tries to reacquire the lock. Upon successfully reacquiring the lock, the previously waiting thread returns from wait(). Confused? The following code fragment offers clarification:

// Condition variable initialized to false to indicate condition has not occurred.
boolean conditionVar = false;
// Object whose lock threads synchronize on.
Object lockObject = new Object ();
// Thread A waiting for condition to occur...
synchronized (lockObject)
{
   while (!conditionVar)
      try
      {
         lockObject.wait ();
      }
      catch (InterruptedException e) {}
}
// ... some other method
// Thread B notifying waiting thread that condition has now occurred...
synchronized (lockObject)
{
   conditionVar = true;
   lockObject.notify ();
}

The code fragment introduces condition variable conditionVar, which threads A and B use to test and set a condition, and lock variable lockObject, which both threads use for synchronization purposes. The condition variable initializes to false because the condition does not exist when the code starts execution. When A needs to wait for a condition, it enters a synchronized context (provided B is not in its synchronized context). Once inside its context, A executes a while loop statement whose Boolean expression tests conditionVar's value and waits (if the value is false) by calling wait(). Notice that lockObject appears as part of synchronized (lockObject) and lockObject.wait ();—that is no coincidence. From inside wait(), A releases the lock associated with the object on which the call to wait() is made—the object associated with lockObject in the lockObject.wait (); method call. This allows B to enter its synchronized (lockObject) context, set conditionVar to true, and call lockObject.notify (); to notify A that the condition now exists. Upon receiving notification, A attempts to reacquire its lock. That does not occur until B leaves its synchronized context. Once A reacquires its lock, it returns from wait() and retests the condition variable. If this variable's value is true, A leaves its synchronized context.

Apply wait/notify to the producer-consumer relationship

To demonstrate wait/notify's practicality, I introduce you to the producer-consumer relationship, which is common among multithreaded programs where two or more threads must coordinate their activities. The producer-consumer relationship demonstrates coordination between a pair of threads: a producer thread (producer) and a consumer thread (consumer). The producer produces some item that a consumer consumes. For example, a producer reads items from a file and passes those items to a consumer for processing. The producer cannot produce an item if no room is available for storing that item because the consumer has not finished consuming its item(s). Also, a consumer cannot consume an item that does not exist. Those restrictions prevent a producer from producing items that a consumer never receives for consumption, and prevents a consumer from attempting to consume more items than are available. Listing 4 shows the architecture of a producer-/consumer-oriented program:

Listing 4. ProdCons1.java

// ProdCons1.java
class ProdCons1
{
   public static void main (String [] args)
   {
      Shared s = new Shared ();
      new Producer (s).start ();
      new Consumer (s).start ();
   }
}
class Shared
{
   private char c = '\u0000';
   void setSharedChar (char c) { this.c = c; }
   char getSharedChar () { return c; }
}
class Producer extends Thread
{
   private Shared s;
   Producer (Shared s)
   {
      this.s = s;
   }
   public void run ()
   {
      for (char ch = 'A'; ch <= 'Z'; ch++)
      {
           try
           {
              Thread.sleep ((int) (Math.random () * 4000));
           }
           catch (InterruptedException e) {}
           s.setSharedChar (ch);
           System.out.println (ch + " produced by producer.");
      }
   }
}
class Consumer extends Thread
{
   private Shared s;
   Consumer (Shared s)
   {
      this.s = s;
   }
   public void run ()
   {
      char ch;
      do
      {
         try
         {
            Thread.sleep ((int) (Math.random () * 4000));
         }
         catch (InterruptedException e) {}
         ch = s.getSharedChar ();
         System.out.println (ch + " consumed by consumer.");
      }
      while (ch != 'Z');
   }
}

ProdCons1 creates producer and consumer threads. The producer passes uppercase letters individually to the consumer by calling s.setSharedChar (ch);. Once the producer finishes, that thread terminates. The consumer receives uppercase characters, from within a loop, by calling s.getSharedChar (). The loop's duration depends on that method's return value. When Z returns, the loop ends, and, thus, the producer informs the consumer when to finish. To make the code more representative of real-world programs, each thread sleeps for a random time period (up to four seconds) before either producing or consuming an item.

Because the code contains no race conditions, the synchronized keyword is absent. Everything seems fine: the consumer consumes every character that the producer produces. In reality, some problems exist, which the following partial output from one invocation of this program shows:

consumed by consumer.
A produced by producer.
B produced by producer.
B consumed by consumer.
C produced by producer.
C consumed by consumer.
D produced by producer.
D consumed by consumer.
E produced by producer.
F produced by producer.
F consumed by consumer.

The first output line, consumed by consumer., shows the consumer trying to consume a nonexisting uppercase letter. The output also shows the producer producing a letter (A) that the consumer does not consume. Those problems do not result from lack of synchronization. Instead, the problems result from lack of coordination between the producer and the consumer. The producer should execute first, produce a single item, and then wait until it receives notification that the consumer has consumed the item. The consumer should wait until the producer produces an item. If both threads coordinate their activities in that manner, the aforementioned problems will disappear. Listing 5 demonstrates that coordination, which the wait/notify mechanism initiates:

Listing 5. ProdCons2.java

// ProdCons2.java

class ProdCons2
{
   public static void main (String [] args)
   {
      Shared s = new Shared ();
      new Producer (s).start ();
      new Consumer (s).start ();
   }
}

class Shared
{
   private char c = '\u0000';
   private boolean writeable = true;

   synchronized void setSharedChar (char c)
   {
      while (!writeable)
         try
         {
            wait ();
         }
         catch (InterruptedException e) {}

      this.c = c;
      writeable = false;
      notify ();
   }

   synchronized char getSharedChar ()
   {
      while (writeable)
         try
         {
            wait ();
         }
         catch (InterruptedException e) { }

      writeable = true;
      notify ();

      return c;
   }
}

class Producer extends Thread
{
   private Shared s;

   Producer (Shared s)
   {
      this.s = s;
   }

   public void run ()
   {
      for (char ch = 'A'; ch <= 'Z'; ch++)
      {
           try
           {
              Thread.sleep ((int) (Math.random () * 4000));
           }
           catch (InterruptedException e) {}

           s.setSharedChar (ch);
           System.out.println (ch + " produced by producer.");
      }
   }
}

class Consumer extends Thread
{
   private Shared s;

   Consumer (Shared s)
   {
      this.s = s;
   }

   public void run ()
   {
      char ch;

      do
      {
         try
         {
            Thread.sleep ((int) (Math.random () * 4000));
         }
         catch (InterruptedException e) {}

         ch = s.getSharedChar ();
         System.out.println (ch + " consumed by consumer.");
      }
      while (ch != 'Z');
   }
}
</code>

When you run ProdCons2, you should see the following output (abbreviated for brevity):

A produced by producer.
A consumed by consumer.
B produced by producer.
B consumed by consumer.
C produced by producer.
C consumed by consumer.
D produced by producer.
D consumed by consumer.
E produced by producer.
E consumed by consumer.
F produced by producer.
F consumed by consumer.
G produced by producer.
G consumed by consumer.

The problems disappeared. The producer always executes before the consumer and never produces an item before the consumer has a chance to consume it. To produce this output, ProdCons2 uses the wait/notify mechanism.

The wait/notify mechanism appears in the Shared class. Specifically, wait() and notify() appear in Shared's setSharedChar(char c) and getSharedChar() methods. Shared also introduces a writeable instance field, the condition variable that works with wait() and notify() to coordinate the execution of the producer and consumer. Here is how that coordination works, assuming the consumer executes first:

1. The consumer executes s.getSharedChar ().
2. Within that synchronized method, the consumer calls wait() (because writeable contains true). The consumer waits until it receives notification.
3. At some point, the producer calls s.setSharedChar (ch);.
4. When the producer enters that synchronized method (possible because the consumer released the lock inside the wait() method just before waiting), the producer discovers writeable's value as true and does not call wait().
5. The producer saves the character, sets writeable to false (so the producer must wait if the consumer has not consumed the character by the time the producer next invokes setSharedChar(char c)), and calls notify() to waken the consumer (assuming the consumer is waiting).
6. The producer exits setSharedChar(char c).
7. The consumer wakens, sets writeable to true (so the consumer must wait if the producer has not produced a character by the time the consumer next invokes getSharedChar()), notifies the producer to awaken that thread (assuming the producer is waiting), and returns the shared character.

The rest of the family

In addition to wait() and notify(), three other methods make up the wait/notify mechanism's method family: void wait(long millis);, void wait(long millis, int nanos);, and void notifyAll();.

The overloaded wait(long millis) and wait(long millis, int nanos) methods allow you to limit how long a thread must wait. wait(long millis) limits the waiting period to millis milliseconds, and wait(long millis, int nanos) limits the waiting period to a combination of millis milliseconds and nanos nanoseconds. As with the no-argument wait() method, code must call these methods from within a synchronized context.

You use wait(long millis) and wait(long millis, int nanos) in situations where a thread must know when notification arrives. For example, suppose your program contains a thread that connects to a server. That thread might be willing to wait up to 45 seconds to connect. If the connection does not occur in that time, the thread must attempt to contact a backup server. By executing wait (45000);, the thread ensures it will wait no more than 45 seconds.

notifyAll() wakens all waiting threads associated with a given lock—unlike the notify() method, which awakens only a single thread. Although all threads wake up, they must still reacquire the object lock. The JVM selects one of those threads to acquire the lock and allows that thread to run. When that thread releases the lock, the JVM automatically selects another thread to acquire the lock. That continues until all threads have run. Examine Listing 6 for an example of notifyAll():

Listing 6. WaitNotifyAllDemo.java

// WaitNotifyAllDemo.java
class WaitNotifyAllDemo
{
   public static void main (String [] args)
   {
      Object lock = new Object ();
      MyThread mt1 = new MyThread (lock);
      mt1.setName ("A");
      MyThread mt2 = new MyThread (lock);
      mt2.setName ("B");
      MyThread mt3 = new MyThread (lock);
      mt3.setName ("C");
      mt1.start ();
      mt2.start ();
      mt3.start ();
      System.out.println ("main thread sleeping");
      try
      {
         Thread.sleep (3000);
      }
      catch (InterruptedException e)
      {
      }
      System.out.println ("main thread awake");
      synchronized (lock)
      {
         lock.notifyAll ();
      }
   }
}
class MyThread extends Thread
{
   private Object o;
   MyThread (Object o)
   {
      this.o = o;
   }
   public void run ()
   {
      synchronized (o)
      {
         try
         {
             System.out.println (getName () + " before wait");
             o.wait ();
             System.out.println (getName () + " after wait");
         }
         catch (InterruptedException e)
         {
         }
      }
   }
}

WaitNotifyAllDemo's main thread creates three MyThread objects and assigns names A, B, and C to the associated threads, which subsequently start. The main thread then sleeps for three seconds to give the newly created threads time to wait. After waking up, the main thread calls notifyAll() to awaken those threads. One by one, each thread leaves its synchronized statement and run() method, then terminates.

Thread interruption

One thread can interrupt another thread that is either waiting or sleeping by calling Thread's void interrupt(); method. In response, the waiting/sleeping thread resumes execution by creating an object from InterruptedException and throwing that object from the wait() or sleep() methods.

When a call is made to interrupt(), that method either allows a waiting/sleeping thread to resume execution via a thrown exception object or sets a Boolean flag to true (somewhere in the appropriate thread object) to indicate that an executing thread has been interrupted. The method sets the flag only if the thread is neither waiting nor sleeping. An executing thread can determine the Boolean flag's state by calling one of the following Thread methods: static boolean interrupted(); (for the current thread) or boolean isInterrupted(); (for a specific thread). These methods feature two differences:

1. Because interrupted() is a static method, you do not need a thread object before you call it. For example: System.out.println (Thread.interrupted ()); // Display Boolean flag value for current thread. In contrast, because isInterrupted() is a nonstatic method, you need a thread object before you call that method.
2. The interrupted() method clears the Boolean flag to false, whereas the isInterrupted() method does not modify the Boolean flag.

In a nutshell, interrupt() sets the Boolean flag in a thread object and interrupted()/isInterrupted() returns that flag's state. How do we use this capability? Examine Listing 7's ThreadInterruptionDemo source code:

Listing 7. ThreadInterruptionDemo.java

// ThreadInterruptionDemo.java
class ThreadInterruptionDemo
{
   public static void main (String [] args)
   {
      ThreadB thdb = new ThreadB ();
      thdb.setName ("B");
      ThreadA thda = new ThreadA (thdb);
      thda.setName ("A");
      thdb.start ();
      thda.start ();
   }
}
class ThreadA extends Thread
{
   private Thread thdOther;
   ThreadA (Thread thdOther)
   {
      this.thdOther = thdOther;
   }
   public void run ()
   {
      int sleepTime = (int) (Math.random () * 10000);
      System.out.println (getName () + " sleeping for " + sleepTime +
                          " milliseconds.");
      try
      {
         Thread.sleep (sleepTime);
      }
      catch (InterruptedException e)
      {
      }
      System.out.println (getName () + " waking up, interrupting other " +
                          "thread and terminating.");
      thdOther.interrupt ();
   }
}
class ThreadB extends Thread
{
   int count = 0;
   public void run ()
   {
      while (!isInterrupted ())
      {
         try
         {
            Thread.sleep ((int) (Math.random () * 10));
         }
         catch (InterruptedException e)
         {
            System.out.println (getName () + " about to terminate...");
            // Because the Boolean flag in the consumer thread's thread
            // object is clear, we call interrupt() to set that flag.
            // As a result, the next consumer thread call to isInterrupted()
            // retrieves a true value, which causes the while loop statement
            // to terminate.
            interrupt ();
         }
         System.out.println (getName () + " " + count++);
      }
   }
}

ThreadInterruptionDemo starts a pair of threads: A and B. A sleeps for a random amount of time (up to 10 seconds) before calling interrupt() on B's thread object. B continually checks for interruption by calling its thread object's isInterrupted() method. As long as that method returns false, B executes the statements within the while loop statement. Those statements cause B to sleep for a random amount of time (up to 10 milliseconds), print variable count's value, and increment that value.

When A calls interrupt(), B is either sleeping or not sleeping. If B is sleeping, B wakes up and throws an InterruptedException object from the sleep() method. The catch clause then executes, and B calls interrupt() on its thread object to set B's Boolean flag to true. (That flag clears to false when the exception object is thrown.) The next call to isInterrupted() causes execution to leave the while loop statement because isInterrupted() returns true. The result: B terminates. If B is not sleeping, consider two scenarios. First, B has just called isInterrupted() and is about to call sleep() when A calls interrupt(). B's call to sleep() results in that method immediately throwing an InterruptedException object. This scenario is then identical to when B was sleeping: B eventually terminates. Second, B is executing System.out.println (getName () + " " + count++); when A calls interrupt(). B completes that method call and calls isInterrupted(). That method returns true, B breaks out of the while loop statement, and B terminates.

Review

This article continued to explore Java's threading capabilities by focusing on thread scheduling, the wait/notify mechanism, and thread interruption. You learned that thread scheduling involves either the JVM or the underlying platform's operating system deciphering how to share the processor resource among threads. Furthermore, you learned that the wait/notify mechanism makes it possible for threads to coordinate their executions—to achieve ordered execution, as in the producer-consumer relationship. Finally, you learned that thread interruption allows one thread to prematurely awaken a sleeping or waiting thread.

This article's material proves important for three reasons. First, thread scheduling helps you write platform-independent programs where thread scheduling is an issue. Second, situations (such as the producer-consumer relationship) arise where you must order thread execution. The wait/notify mechanism helps you accomplish that task. Third, you can interrupt threads when your program must terminate even though other threads are waiting or sleeping.

In next month's article, I'll conclude this series by exploring thread groups, volatility, thread local variables, and timers.

About the author

Read more about Core Java in JavaWorld's Core Java section.