...
Noncompliant Code Example (Volatile)
Declaring flag volatile does not also fails to solve the problem either:
| Code Block | ||
|---|---|---|
| ||
final class Flag {
private volatile boolean flag = true;
public void toggle() { // Unsafe
flag ^= true;
}
public boolean getFlag() { // Safe
return flag;
}
}
|
This code remains unsuitable for multithreaded use because declaring a variable volatile does not fails to guarantee the atomicity of compound operations on the variable.
...
This solution guards reads and writes to the flag field with a lock on the instance, that is, this. Furthermore, doing so synchronization ensures that changes are visible to all the threads. Now, only two execution orders are possible, one of which is shown in the following scenario:
...
The simple replacement of the two int fields with atomic integers , in this example, fails to eliminate the race condition because the compound operation a.get() + b.get() is still non-atomic.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="740815aef0e6c4d9-ed197199-4e944a6b-92bc8523-62794e6932f05474baa7e9fb"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | Class | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d25751141b619c23-0bd1030f-4e2f40ef-93d88851-608782486284770da124eba8"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 66. Synchronize access to shared mutable data | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="94080ff7140e0332-01d5f1f9-4010466e-993787ea-6827acba9c27e53e6e660934"><ac:plain-text-body><![CDATA[ | [[Goetz 2006 | AA. Bibliography#Goetz 06]] | 2.3, Locking | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4b4f1b577cd16857-799bda6f-4a134712-a0b1bedb-5be81613abdbdf4139d0f925"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | [Chapter 17, Threads and Locks, | http://java.sun.com/docs/books/jls/third_edition/html/memory.html], ]]></ac:plain-text-body></ac:structured-macro> | |
| §17.4.5, Happens-Before Order | ||||
| §17.4.3, Programs and Program Order | ||||
| §17.4.8, Executions and Causality Requirements | ||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a0862f2b232e2102-d81dfabd-44d34d0b-995b9750-5f2f381dbbcd851f46e8ef8d"><ac:plain-text-body><![CDATA[ | [[Lea 2000 | AA. Bibliography#Lea 00]] | Section 2.2.7, The Java Memory Model | ]]></ac:plain-text-body></ac:structured-macro> | |
| Section 2.1.1.1, Objects and Locks | ||||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6f9de2dcd997cfe2-040d3469-47e94f37-a4529cb1-3856ad9638832dc01e2bc966"><ac:plain-text-body><![CDATA[ | [[Tutorials 2008 | AA. Bibliography#Tutorials 08]] | [Java Concurrency Tutorial | http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html] | ]]></ac:plain-text-body></ac:structured-macro> |
Issue Tracking
...
...