Threads that invoke Object.wait()
expect to wake up and resume execution when their condition predicate becomes true. To be compliant with 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 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 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, 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 provide the Condition.signal()
and Condition.signalAll()
methods to awaken threads that are blocked on a Condition.await()
call. 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 sameLock
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 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
Wiki Markup |
---|
The methods {{notify()}} and {{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). The method {{notify()}} is deceptive in most cases unless all of the following conditions hold: \[[Goetz 06|AA. Java References#Goetz 06]\] |
- Only one condition predicate is used with the locked object. Also, each thread must execute the same code after waking up from a wait.
- Only one thread must wake up on the notify signal. This is contingent on the condition predicate, in that, only one predicate must fulfill the condition and allow the thread to proceed.
These requirements are typically true when only one thread is waiting. Otherwise, if either condition does not hold, incorrect program behavior may result.
Noncompliant Code Example
This noncompliant code example violates the liveness property. A lock is held on a shared object list
and three threads are started. Two condition predicates are used. One checks whether the buffer has zero elements and the other checks if the buffer is full with ten elements. Initially the buffer is neither full nor empty. Conditions are created so that the buffer becomes empty and thread 1 goes into wait state, followed by thread 2.
Note that when thread 2 goes into the wait state, the condition predicate of thread 1 becomes false
. When notify()
is invoked by thread 3, it can be delivered to either thread 1 or thread 2 depending on the particular Java Virtual Machine (JVM). If thread 1 is chosen, its condition turns out to be false
. Even though this notification is meant for thread 2 (whose condition predicate is on the other hand, true
) thread 1 wakes up when its condition predicate is still false
.
Code Block | ||
---|---|---|
| ||
public final class MissedSignalProcessStep implements Runnable { private static final LinkedListObject listlock = new LinkedListObject(); private static int buffer_counttime = 50; private final int numberstep; // SelectsDo Perform functionoperations basedwhen onfield threadtime number // reaches this value public MissedSignalProcessStep(int numberstep) { this.numberstep = numberstep; } @Override public void run() { try { public void runsynchronized (lock) { synchronized(list while (time != step) { try { lock.wait(); } if(number == 1) { // Perform operations time++; System.out.println("Thread 1 started..."); while(buffer_count == 0) { System.out.println("Beginning wait() Thread 1..."); list.wait(); System.out.println("Thread 1 got notified this time..."); } System.out.println("Exiting because Thread 1 condition is false..."); } else if(number == 2) { System.out.println("Thread 2..."); while(buffer_count > 0) { System.out.println("Beginning wait() Thread 2..."); list.wait(); System.out.println("Thread 2 got notified this time..."); } System.out.println("Exiting because the thread 2 condition is false..."); } else if(number == 3) { Thread.sleep(2000); list.notify(); } 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 only one thread at a time. Unless it happens to wake the thread that is required to perform the next step, the program will deadlock.
Compliant Solution (notifyAll()
)
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:
Code Block | ||
---|---|---|
| ||
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() {
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
}
}
}
|
Noncompliant Code Example (Condition
Interface)
This noncompliant code example is similar to the noncompliant code example for notify()
but uses the Condition
interface for waiting and notification:
Code Block | ||
---|---|---|
| ||
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; // 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) { condition.await(); } // Perform operations time++; condition.signal(); } }catch (InterruptedException ie) { Thread.currentThread().interrupt(); // HandleReset theinterrupted exceptionstatus } finally }{ } lock.unlock(); } } public static void makeThread1Truemain(String[] args) { buffer_count = 0; for (int i = 4; i >= 0; i--) { new Thread(new ProcessStep(i)).start(); } } } |
As with Object.notify()
, the signal()
method may awaken an arbitrary thread.
Compliant Solution (signalAll()
)
This compliant solution uses the signalAll()
method 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 | ||
---|---|---|
| ||
public class ProcessStep implements Runnable { private static final Lock lock = new ReentrantLock(); publicprivate static void makeThread2True() { final Condition condition = lock.newCondition(); private buffer_countstatic int time = 100; } private final int step; // Perform operations when field time // reaches this value public static ProcessStep(int step) { this.step = step; } @Override public void main(String[] args) throws IOExceptionrun() { lock.lock(); try { makeThread1True(); while (time != step) { Runnable runnable1 = new MissedSignalcondition.await(1); } // Perform Threadoperations t1 = new Thread(runnable1) time++; t1condition.startsignalAll(); } catch (InterruptedException tryie) { new Thread.currentThread().sleepinterrupt(5000); // Reset interrupted status } finally { makeThread2True lock.unlock(); } catch (InterruptedException e) { // Handle the exception } Runnable runnable2 = new MissedSignal(2); Thread t2 = new Thread(runnable2); t2.start(); Runnable runnable3 = new MissedSignal(3); Thread t3 = new Thread(runnable3); t3.start(); } } |
Compliant Solution
This compliant solution uses the notifyAll()
method which sends notifications to all threads that wait on the same object. As a result, liveness is not affected unlike the noncompliant code example. The condition predicate controls which threads can resume their operations. Ensure that the lock is released promptly after the call to notifyAll()
.
Code Block | ||
---|---|---|
| ||
else if(number == 3) {
Thread.sleep(2000);
list.notifyAll();
}
|
Exceptions
EX1: If there are several similar threads waiting for a notification, and it is permissible to invoke any of them, notify()
may be used. The criteria for liveness is relaxed in this case.
Risk Assessment
}
}
|
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 | ||
---|---|---|
| ||
// 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; // 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 = 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();
}
}
}
|
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 |
---|
THI02-J |
Low |
Unlikely |
Medium | P2 | L3 |
Automated Detection
...
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
...
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.THI02.ANF | Do not use 'notify()'; use 'notifyAll()' instead so that all waiting threads will be notified | ||||||
SonarQube |
| S2446 | "notifyAll" should be used |
Related Guidelines
Bibliography
[API 2006] | |
Item 50, "Never Invoke | |
Section 14.2.4, |
...
"Notification" | |
[JLS 2015] |
...
\[[Bloch 01|AA. Java References#Bloch 01]\] Item 50: Never invoke wait outside a loopCON31-J. Always invoke wait() and await() methods inside a loop 11. Concurrency (CON) CON33-J. Address the shortcomings of the Singleton design pattern