The Java Language Specification allows 64-bit long
and double
values to be treated as two 32-bit values. For example, a 64-bit write operation could be performed as two separate , 32-bit operations.
Wiki Markup |
---|
According to the _Java Language Specification_ \[[JLS 2005|AA. Bibliography#JLS 05]\], §17.7, "Non-Atomic Treatment of {{double}} and {{long}}" \[[JLS 2005|AA. Bibliography#JLS 05]\]: |
This ... this behavior is implementation specific; Java virtual machines are free to perform writes to
long
anddouble
values atomically or in two parts. For the purposes of the Java programming language memory model, a single write to a non-volatilelong
ordouble
value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.
This behavior can result in indeterminate values being read in code that is required to be thread-safe. Consequently, multi-threaded multithreaded programs must ensure atomicity when reading or writing 64-bit values.
...
A similar problem can occur when i
is declared double
.
Compliant Solution (Volatile)
...
VNA05-EX0: If all reads and writes of 64-bit long
and double
values occur within a synchronized region, the atomicity of the read/write is guaranteed. This requires both that the value is exposed only through synchronized methods in the class , and also that the value is inaccessible from other code (whether directly or indirectly). For more information, see rule VNA02-J. Ensure that compound operations on shared variables are atomic.)
VNA05-EX1: This rule can be ignored for platforms that guarantee that 64-bit , long
and double
values are read and written as atomic operations. Note, however, that such guarantees fail to be are not portable across different platforms.
...
Failure to ensure the atomicity of operations involving 64-bit values in multithreaded applications can result in reading and writing indeterminate values. Many JVMs read and write 64-bit values atomically , even though the specification does not require them to.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
VNA05-J | low | unlikely | medium | P2 | L3 |
Automated Detection
The Coverity Prevent Version 5.0 ATOMICITY checker can detect the instances of non-atomic update of a concurrently shared value. The result of the update will be determined by the interleaving of thread execution.Some static analysis tools are capable of detecting violations of this rule.
Related Guidelines
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="43c1fca5b2028ac2-9de098b8-43f149aa-b6e78074-eef5b703c73e858100210c6e"><ac:plain-text-body><![CDATA[ | [[Goetz 2006 | AA. Bibliography#Goetz 06]] | 3.1.2. , Non-Atomic atomic 64-Bit Operations | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a0141e60fffa5663-739a7feb-456246ed-bec2b835-54e7d13789763a128e925c6d"><ac:plain-text-body><![CDATA[ | [[Goetz 2004c | AA. Bibliography#Goetz 04c]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="6d5d031d4583d37c-bd16e5ca-48d647fd-8b8aa3cf-a59e4e7f2388fef0211819a9"><ac:plain-text-body><![CDATA[ | [[JLS 2005 | AA. Bibliography#JLS 05]] | §17.7, Non-atomic Treatment of double and long | ]]></ac:plain-text-body></ac:structured-macro> |
...