[concurrency-interest] How bad can volatile long++ be?

Mark Thornton mthornton at optrak.co.uk
Wed Dec 12 17:00:45 EST 2007

David Gallardo wrote:
>  Goetz et al., in Java Concurrency in Practice, as this to say about that:
> "When a thread reads a variable without synchronization, it may see a
> stale value, but at least it sees a value that was actually placed
> there by some thread rather than some random value. This safety
> guarantee is called out-of-thin-air safety.
> "Out-of-thin-air safety applies to all variables, with one exception:
> 64-bit numeric variables (double and long) that are not declared
> volatile (see Section 3.1.4). The Java Memory Model requires fetch
> and store operations to be atomic, but for nonvolatile long and
> double variables, the JVM is permitted to treat a 64-bit read or
> write as two separate 32-bit operations. If the reads and writes
> occur in different threads, it is therefore possible to read a
> nonvolatile long and get back the high 32 bits of one value and the
> low 32 bits of another.[3] Thus, even if you don't care about stale
> values, it is not safe to use shared mutable long and double
> variables in multithreaded programs unless they are declared volatile
> or guarded by a lock."
I think Osvaldo was assuming that long (or double) reads/writes would be 
atomic on a 64 bit JVM. It is certainly not true on a typical 32 bit x86 

Mark Thornton

More information about the Concurrency-interest mailing list