Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Parasoft Jtest 2021.1

The methods java.lang.Object.notify() and java.lang.Object.notifyAll() are used to waken waiting thread(s). These methods must be called from code that holds the same object lock as the waiting thread(s).

Any thread that has called wait() expects to wake up when some Threads that invoke Object.wait() expect to wake up and resume execution when their condition predicate becomes true. As recommended by CON18To be compliant with THI03-J. Always invoke wait() and await() methods inside a loop, any waiting thread, when woken, will test its condition predicate, and waiting threads must test their condition predicates upon receiving notifications and must resume waiting if the predicate has not become true.predicates are false.

The notify() and notifyAll() methods of package java.lang.Object are used to wake up a waiting thread 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 threadConsequently, the notifyAll() method is recommended rather than the notify() method. The notifyAll() method will wake wakes up all threads , and only waiting on an object lock and allows threads whose condition predicate is satisfied will remain awaketrue to resume execution. Furthermore, if all of the threads require whose condition predicate evaluates to true previously held a specific lock before going into the wait state, only one of them will obtain reacquire the lock upon being notified. Presumably, and the others may, presumably, the other threads will resume waiting. The notify() method wakes up only one thread, and makes no guarantees as to which thread gets woken up. If the thread's condition predicate is not satisified, the chosen thread may resume waiting, defeating the purpose of the notify() call.

The notify() method should only be called if

...

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.

Consequently, invoking the notify() method is permitted only when all of the following conditions are met:

  • All waiting threads have identical condition predicates.
  • All threads perform the same set of operations after waking up. That is, any one thread can be selected to wake up and resume for a single invocation of notify().
  • Only one thread is required to wake upon the notification.

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

The java.util.concurrent.locks utilities (interface Condition) provide the Condition.signal() and Condition.signalAll() methods to awaken waiting threads that are blocked on an a Condition.await() call. Like the notify() method, the signal() method wakes up any one of the threads that is waiting on the condition and consequently, may be insecure. Similarly, any thread that is blocked on a wait() method invocation on a Java object being used as a condition queue, should be notified using notifyAll(). Condition objects are required when using java.util.concurrent.locks.Lock objects. Although Lock objects allow the use of Object.wait(), Object.notify(), 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 await(), signal(), and signalAll() methods are used in place of the wait(), notify(), and notifyAll() methods.

The signal() method 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, 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.

or all of these conditions are met:

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

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

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 demonstrates shows a complex multi-step , multistep process being undertaken by several threads. Each thread executes one step of the process; the step being currently performed is maintained identified by the step time field. Each thread waits for the step time field to indicate that it is time to perform that the corresponding thread's step. When it is time to perform its After performing the step, each thread does so. It then increments step first increments time and then notifies the thread that is responsible for the next thread, notifies the thread, and exitsstep.

Code Block
bgColor#FFcccc

public final class SleepyThreadProcessStep implements Runnable {
  private static final Object lock = new Object();
  private static int time = 10;
  private final int myStepstep; // Do doPerform stuffoperations when the step raches field time 
                          // reaches this value

  public SleepyThreadProcessStep(int myStepstep) {
    this.myStepstep = myStepstep;
  }

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

        // ... do stuffPerform operations

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

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

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

Compliant Solution (notifyAll())

In this compliant solution, each thread uses completes its step and then calls notifyAll() to wake all of notify the other waiting threads when its step is complete. Consequently the proper thread can perform its next step, while all other threads note that their condition predicate has not been satisified and promptly go back to sleep.. 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:

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

  @Override public void run
Code Block
bgColor#ccccff

  public void run () {
    try {
      synchronized (lock) {
        while (time != myStepstep) { 
          lock.wait();  
        }
  
        // ... do stuff

Perform operations
  
        time++;
        lock.notifyAll(); // Use notifyAll() instead of notify()
      }
    } catch (InterruptedException ie) {
      Thread.currentThread().interrupt(); // Reset interrupted status
    }
    }

  }

Noncompliant Code Example (Condition

...

Interface)

This noncompliant code example derives from is similar to the previous noncompliant code example for notify() but uses the Condition interface . Field cond is used to let threads wait on different condition predicates.for waiting and notification:

Code Block
bgColor#FFcccc
public class ProcessStep implements Runnable {
  private static final ConditionLock condlock = lock.newConditionnew ReentrantLock();
// ...

public void run (){
   private static final Condition condition = lock.locknewCondition();
  private static int time = 0;
  try {    	 private final int step; // Perform operations when field time 
    if(number == 1) {	  
      while(buffer_count == 0) { 
        cond.await();		  // reaches this value
  public ProcessStep(int step) {
  }  
this.step = step;
  }

 else if(number == 2 @Override public void run() {
  	  lock.lock();
  		  try {
      while (buffer_counttime !== 10step) {	
        condcondition.await();
   	   }

    		  // Perform 	operations

      time++;
  	    condition.signal();
    }  }catch (InterruptedException ie) {
      
    } else if(number == 3)Thread.currentThread().interrupt(); // Reset interrupted status
    } finally {
      condlock.signalunlock();	
    }
 	 }

  
public static }void catch (InterruptedException iemain(String[] args) {
    //for Handle(int thei exception
= 4; i  Thread.currentThread().interrupt(); // Reset interrupted status>= 0; i--) {
  } finally {
  new  lock.unlockThread(new ProcessStep(i)).start();
    }
}	  }
}

Similar to As with Object.notify(), the cond.signal() method may choose either of the threads and awaken itawaken an arbitrary thread.

Compliant Solution (signalAll())

This compliant solution uses the signalAll() method to resume all the waiting threads whose condition predicate allows doing so.to notify all waiting threads. Before await() returns, the current thread reacquires the lock associated with this condition. When the thread returns, it is guaranteed to hold this lock [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:

Code Block
bgColor#ccccff

}public elseclass if(number == 3)ProcessStep implements Runnable {
   cond.signalAll();
} 

Compliant Solution (unique Condition variable per thread)

This compliant solution uses two different condition variables full and empty to indicate whether the the buffer is full or empty, respectively.

Code Block
bgColor#ccccff

private static final Lock lock = new ReentrantLock();
  private static final Condition fullcondition = lock.newCondition();
final Condition empty = lock.newCondition();
// ...

  private static int time = 0;
  private final int step; // Perform operations when field time 
                          // reaches this value
  public ProcessStep(int step) {
    this.step = step;
  }

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

      time++;
      while(buffer_count == 0) { 
  condition.signalAll();
    } catch (InterruptedException ie) {
      Thread.currentThread().interrupt(); // Reset interrupted status
    } finally {
      emptylock.awaitunlock();		
    }
  }

}

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:

Code Block
bgColor#ccccff
// Declare class as final because its  }  
    } else if(number == 2) {  	    		  
      while(buffer_count == 10) {	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; // Perform 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  full.await= step;
      conditions[step] = lock.newCondition();
    } else 	{
    		  throw new 	IllegalArgumentException("Too many threads");
    }
  	}

  @Override public void run() {
    lock.lock();
    try }{
     } elsewhile if(numbertime !== 3step) {
       empty.signal();	
      full.signal();  conditions[step].await();
      }

      // Perform operations

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

Even though signal() is used, it is guaranteed that only one thread will awaken because each condition predicate corresponds to a unique Condition variable.

Risk Assessment

  }

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

Even though the signal() method is used, only the thread whose condition predicate corresponds to the unique Condition variable will awaken.

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

Risk Assessment

Notifying a single thread rather than all waiting threads can violate the Invoking the notify() method instead of notifyAll() can be a threat to the liveness property of the system.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

CON19

THI02-J

low

Low

unlikely

Unlikely

medium

Medium

P2

L3

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

...

ToolVersionCheckerDescription
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.THI02.ANFDo not use 'notify()'; use 'notifyAll()' instead so that all waiting threads will be notified
SonarQube
Include Page
SonarQube_V
SonarQube_V
S2446"notifyAll" should be used

Related Guidelines

Bibliography

[API 2006]

Interface java.util.concurrent.locks.Condition

[Bloch 2001]

Item 50, "Never Invoke wait Outside a Loop"

[Goetz 2006]

Section

...

14.2.4,

...


...

Image Added Image Added Image Added \[[Bloch 01|AA. Java References#Bloch 01]\] Item 50: Never invoke wait outside a loopCON18-J. Always invoke wait() and await() methods inside a loop      11. Concurrency (CON)      CON20-J. Do not perform operations that may block while holding a lock