Page History

Threads that invoke Object.wait() expect to wake up and resume execution when their condition predicate becomes true. To be compliant with rule THI03-J. Always invoke wait() and await() methods inside a loop, waiting threads must test their condition predicates upon receiving notifications and must resume waiting if the predicates are false.

The notify() and notifyAll() methods of package java.lang.Object are used to wake up a waiting thread (s)or threads, respectively. These methods must be invoked from a thread that holds the same object lock as the waiting thread(s); these methods throw an IllegalMonitorStateException when invoked from any other thread. The notifyAll() method wakes up all threads associated with waiting on an object lock and allows threads whose condition predicate is true to resume execution. Furthermore, if all the threads whose condition predicate evaluates to true previously held a specific lock before going into the wait state, only one of them will reacquire the lock upon being notified. Presumably, the other threads will resume waiting. The notify() method wakes up only one thread, and any with no guarantee regarding which specific thread is notified. The chosen thread is permitted to resume waiting if its condition predicate is unsatisfied; this often defeats the purpose of the notification.

...

These conditions are satisfied by threads that are identical and provide a stateless service or utility.

The java.util.concurrent.locks utilities (Condition interface) provide the Condition.signal() and Condition.signalAll() methods to awaken threads that are blocked on an a Condition.await() call. Condition objects are required when using java.util.concurrent.locks.Lock objects. A Although Lock object allows objects allow the use of Object.wait() and , Object.notify() methods. However, code , and Object.notifyAll() methods, their use is prohibited by LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects. Code that synchronizes using a Lock object uses one or more Condition objects associated with the Lock object rather than using its own intrinsic lock. These objects interact directly with the locking policy enforced by the Lock object. Consequently, the Condition.await(), Condition.signal(), and Condition.signalAll() methods are used in place of the Object.wait(), Object.notify(), and Object.notifyAll() methods.

Use of the The signal() method is insecure when multiple threads await the same Condition object unless the following must not be used unless all of these conditions are met:

• The Condition object is identical for each waiting thread.
• All threads must perform the same set of operations after waking up. This , which means that any one thread can be selected to wake up and resume for a single invocation of signal().
• Only one thread is required to wake upon receiving the signal.

Insecure use of the signal() method is forbidden.

Use of the signal() method is also permitted when both of the following or all of these conditions are met:

• Each thread uses a unique Condition object.
• Each Condition object is associated with a common the same Lock object.

The When used securely, the signal() method has better performance than signalAll() when used securely.

...

When notify()

...

or signal() is used to waken a waiting thread, and the thread is not prepared to resume execution, it often resumes waiting. Consequently, no thread wakens, which may cause the system to hang.

Noncompliant Code Example (notify())

This noncompliant code example shows a complex, multistep process being undertaken by several threads. Each thread executes the step identified by the time field. Each thread waits for the time field to indicate that it is time to perform the corresponding thread's step. After performing the step, each thread first increments time and then notifies the thread that is responsible for the next step.

public final class ProcessStep implements Runnable {
  private static final Object lock = new Object();
  private static int time = 0;
  private final int step; // Do Perform operations when field time 
 reaches this value

  public ProcessStep                     // reaches this value

  public ProcessStep(int step) {
    this.step = step;
  }

  @Override public void run() {
    try {
      synchronized (lock) {
        while (time != step) {
          lock.wait();
        }

        // Perform operations

        time++;
        lock.notify();
      }
    } catch (InterruptedException ie) {
      Thread.currentThread().interrupt(); // Reset interrupted status
    }
  }

  public static void main(String[] args) {
    for (int i = 4; i >= 0; i--) {
      new Thread(new ProcessStep(i)).start();
    }
  }
}

This noncompliant code example violates the liveness property. Each thread has a different condition predicate because each requires step to have a different value before proceeding. The Object.notify() method wakes up only one thread at a time. Unless it happens to wake up the thread that is required to perform the next step, the program will deadlock.

...

In this compliant solution, each thread completes its step and then calls notifyAll() to notify the waiting threads. The thread that is ready can then perform its task , while all the threads whose condition predicates are false (loop condition expression is true) promptly resume waiting.

Only the run() method from the noncompliant code example is modified, as follows:

public final class ProcessStep implements Runnable {
  private static final Object lock = new Object();
  private static int time = 0;
  private final int step; // DoPerform operations when field time reaches
  this value
  public ProcessStep(int step) {
    this.step = step             // reaches this value
  public ProcessStep(int step) {
    this.step = step;
  }


  @Override public void run() {
    try {
      synchronized (lock) {
        while (time != step) {
          lock.wait();
        }
  
        // Perform operations
  
        time++;
        lock.notifyAll(); // Use notifyAll() instead of notify()
      }
    } catch (InterruptedException ie) {
      Thread.currentThread().interrupt(); // Reset interrupted status
    }
  }

}

...

This noncompliant code example is similar to the noncompliant code example for notify() but uses the Condition interface for waiting and notification.:

public class ProcessStep implements Runnable {
  private static final Lock lock = new ReentrantLock();
  private static final Condition condition = lock.newCondition();
  private static int time = 0;
  private final int step; // DoPerform operations when field time 
 reaches this value

  public ProcessStep                     // reaches this value
  public ProcessStep(int step) {
    this.step = step;
  }

  @Override public void run() {
    lock.lock();
    try {
      while (time != step) {
        condition.await();
      }

      // Perform operations

      time++;
      condition.signal();
    } catch (InterruptedException ie) {
      Thread.currentThread().interrupt(); // Reset interrupted status
    } finally {
      lock.unlock();
    }
  }

  public static void main(String[] args) {
    for (int i = 4; i >= 0; i--) {
      new Thread(new ProcessStep(i)).start();
    }
  }
}

...

Compliant Solution (signalAll())

Wiki MarkupThis compliant solution uses the {{signalAll()}} method to notify all waiting threads. Before {{await()}} returns returns, the current thread reacquires the lock associated with this condition. When the thread returns, it is guaranteed to hold this lock \ [[API 2006|AA. Bibliography#API 06]\] The thread that is ready can perform its task, while all the threads whose condition predicates are false resume API 2014]. The thread that is ready can perform its task while all the threads whose condition predicates are false resume waiting.

Only the run() method from the noncompliant code example is modified, as follows:

public class ProcessStep implements Runnable {
  private static final Lock lock = new ReentrantLock();
  private static final Condition condition = lock.newCondition();
  private static int time = 0;
  private final int step; // DoPerform operations when field time 
                          // reaches this value
  public ProcessStep(int step) {
    this.step = step;
  }


    @Override public void run() {
      lock.lock();
      try {
        while (time != step) {
          condition.await();
        }
  
        // Perform operations

        time++;
        condition.signalAll();
      } catch (InterruptedException ie) {
        Thread.currentThread().interrupt(); // Reset interrupted status
      } finally {
        lock.unlock();
      }
    }

}

Compliant Solution (Unique Condition

...

per Thread)

This compliant solution assigns each thread its own condition. All the Condition objects are accessible to all the threads.:

// Declare class as final because its constructor throws an exception
public final class ProcessStep implements Runnable {
  private static final Lock lock = new ReentrantLock();
  private static int time = 0;
  private final int step; // DoPerform operations when field time 
                          // reaches this value
  private static final int MAX_STEPS = 5;
  private static final Condition[] conditions = new Condition[MAX_STEPS];

  public ProcessStep(int step) {
    if (step <= MAX_STEPS) {
      this.step = step;
      conditions[step] = lock.newCondition();
    } else {
      throw new IllegalArgumentException("Too many threads");
    }
  }

  @Override public void run() {
    lock.lock();
    try {
      while (time != step) {
        conditions[step].await();
      }

      // Perform operations

      time++;
      if (step + 1 < conditions.length) {
        conditions[step + 1].signal();
      }
    } catch (InterruptedException ie) {
      Thread.currentThread().interrupt(); // Reset interrupted status
    } finally {
      lock.unlock();
    }
  }

  public static void main(String[] args) {
    for (int i = MAX_STEPS - 1; i >= 0; i--) {
      ProcessStep ps = new ProcessStep(i);
      new Thread(ps).start();
    }
  }
}

...

This compliant solution is safe only when untrusted code cannot create a thread with an instance of this class.

...

Notifying a single thread rather than all waiting threads can pose a threat to the violate the liveness property of the system.

Related Guidelines

Bibliography

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image Removed      09. Thread APIs (THI)      Image Modified