Re: What does volatile guarantee?
On 2/12/2010 10:23 AM, Roedy Green wrote:
Originally I thought volatile just suppressed caching a value in a
register, so that other threads going to RAM would see the latest
value.
IIRC at least in some early JVM, you could not count on 64-bit loads
and stores being atomic.
But on reading the JLS, it seems to guarantee even more. It says all
threads must see a consistent value.
This suggests if your hardware stores a 64-bit long in two 32-bit
stores, it must somehow lock the pair together so that another thread
will not see half the store. I wonder just how they do that, and if
they indeed do.
I don't think the JLS guarantees that a volatile x++ must be atomic.
It appears to be silent on the topic, which I take to mean you can't
count on it.
"Consistent value" is what you're promised, and it's up to
the JVM to deliver it by doing whatever is required.
Your recollection about 64-bit accesses is correct, but it's
a remembrance of things past: Early Java allowed non-atomicity as
a concession to machines that lacked 64-bit atomic operations.
But 64-bit-capable machines are now the norm instead of the
exception, and the rules have been tightened up. (I think this
may have happened as part of the effort to nail down Java's memory
model, which was pretty loosey-goosey in the early days.)
There's no atomicity guarantee for things like x++ or x+=42,
because these are not single accesses: They need paired reads
and writes. The read will be atomic and fetch a consistent
value, the write will be atomic and store a consistent value,
but other (individually atomic) reads and writes may intervene.
Before anybody whines^H^H^H^H^H^Hsuggests that making +=
atomic would be easy, let him ponder
volatile int a,b,c,...,z;
a += b += c+= ... += z;
--
Eric Sosman
esosman@ieee-dot-org.invalid