...
Compliant Solution (synchronization)
This compliant solution declares recommends declaring both the toggle() and getFlag() methods as synchronized.
...
| Wiki Markup |
|---|
This approach may not be used when a getter method performs operations other than just returning the value of a {{volatile}} field, without having to use any synchronization. Unless read performance is critical, this technique may not offer significant advantages over synchronization \[[Goetz 06|AA. Java References#Goetz 06]\]. |
...
| Code Block | ||
|---|---|---|
| ||
final class Flag {
private AtomicBoolean flag = new AtomicBoolean(true);
public void toggle() {
boolean temp;
do {
temp = flag.get();
} while(!flag.compareAndSet(temp, !temp));
}
public AtomicBoolean getFlag() {
return flag;
}
}
|
It This ensures that updates to the variable are carried out by using the compareAndSet() method of the class AtomicBoolean. All updates are made visible to other threads.
...
This compliant solution synchronizes the setValues() and getSum() methods so that the entire operation is atomicto ensure atomicity.
| Code Block | ||
|---|---|---|
| ||
final class Adder {
private int a;
private int b;
public synchronized int getSum() throws ArithmeticException {
// Check for integer overflow
if (b > 0 ? a > Integer.MAX_VALUE - b : a < Integer.MIN_VALUE - b) {
throw new ArithmeticException("Not in range");
}
return a + b;
}
public synchronized void setValues(int a, int b) {
this.a = a;
this.b = b;
}
}
|
Unlike the noncompliant code examples, if a and b currently have the value 0, and one thread calls getSum() while another calls setValues(1, 1), getSum() may return return 0, or 2, depending on which thread obtains the intrinsic lock first. The locking strategy guarantees that getSum() never returns the unacceptable value 1.
...
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[API 06|AA. Java References#API 06]\] Class AtomicInteger \[[JLS 05|AA. Java References#JLS 05]\] [Chapter 17, Threads and Locks|http://java.sun.com/docs/books/jls/third_edition/html/memory.html], section 17.4.5 Happens-before Order, section 17.4.3 Programs and Program Order, section 17.4.8 Executions and Causality Requirements \[[Tutorials 08|AA. Java References#Tutorials 08]\] [Java Concurrency Tutorial|http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html] \[[Lea 00|AA. Java References#Lea 00]\] Sections, 2.2.7 The Java Memory Model, 2.1.1.1 Objects and locks \[[Bloch 08|AA. Java References#Bloch 08]\] Item 66: Synchronize access to shared mutable data \[[Goetz 06|AA. Java References#Goetz 06]\] 2.3. "Locking" \[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 667|http://cwe.mitre.org/data/definitions/667.html] "Insufficient Locking", [CWE ID 413|http://cwe.mitre.org/data/definitions/413.html] "Insufficient Resource Locking", [CWE ID 366|http://cwe.mitre.org/data/definitions/366.html] "Race Condition within a Thread", [CWE ID 567|http://cwe.mitre.org/data/definitions/567.html] "Unsynchronized Access to Shared Data" |
...