Re: Volatile keyword
On 12/14/11 10:39 AM, Robert Klemme wrote:
On 12/13/2011 08:54 AM, Peter Duniho wrote:
On 12/12/11 11:37 PM, Robert Klemme wrote:
[...]Bottom line is that the JVM spec does not make
any guarantees here (??17.7 see Lew's reference).
I think it's worth being careful about "does not make any guarantees
here". The implication of 17.7 is that there _is_ in fact a guarantee,
for certain 64-bit fields marked as "volatile". Specifically, those
which are of the type "double" or "long". This is true even on 32-bit
systems.
And what guarantee is there? Can you unambiguously formulate that and
provide reference to the JLS so everybody can check it?
In 32 bit, there is an assembler instruction cmpxchg8b designed to let
you implement a light weight atomic 64-bit read.
Since you do not know on what JVM your Java program will run when you
write it (or at least someone can choose to use a different JVM model)
it is safer to code under the assumption that a long and double write is
two operations i.e. not atomic.
There is no need to make that assumption provided the field involved is
marked "volatile".
I beg to differ - but I am eagerly waiting to be convinced otherwise.'
The JLS does specifically say that volatile will ensure atomic
operations on long and double.
The last paragraph of section 17.7:
"The load, store, read, and write actions on volatile variables are
atomic, even if the type of the variable is double or long."
<http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#28330>
So unless you use a non-conforming "JVM" implementation (which by
definition isn't really a JVM), then you will *always* have atomic reads
and atomic writes for volatile doubles and volatile longs.