What does volatile guarantee?

[Mike Schilling]

The JLS does not guarantee the atomicity of 'long' and 'double'
accesses absent volatility or other sychronization. /Au contraire/:

http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7

A fact that's IMHO of little practical consequence. If the value isn't
shared, this doesn't matter. If it is shared, volatility or other
sychronization is already required for sensible behavior. Admittedly it can
lead to bizarre behavior when one thread sets a long to -1 and another to 0,
and the result is that every once in a great while its value is 2**32 - 1..

 

[Arne Vajhøj]

Did you read Peter's post? He specifically addressed 'volatile', hence
his use of the word in his post,

Yes, which is why I mentioned that point.

which is also the subject of this
entire thread. You completely failed to mention that you were deviating
from that subject in your response to Eric to which Peter responded. If
you were suddenly to stop talking about the rules for 'volatile' you
should've said so.

And I don't think it was me that switched to non volatile. Both
Roedy and Eric were referring to something being non atomic
in the old days.

That can not be volatile. JLS version 1 made an explicit exception
for volatile long's and double's.

Arne

 

[Arne Vajhøj]

A fact that's IMHO of little practical consequence. If the value isn't
shared, this doesn't matter. If it is shared, volatility or other
sychronization is already required for sensible behavior. Admittedly it can
lead to bizarre behavior when one thread sets a long to -1 and another to 0,
and the result is that every once in a great while its value is 2**32 - 1..

Very true.

synchronized is good!

Arne

 

[John B. Matthews]

I got a report that Firefox under Linux is rendering this page with
all the body text in transparent ink. It works fine with Firefox and
windows. Is anyone else seeing this? It is just volatile.html or
other pages too?

Looks OK on Ubuntu 2.6.31-19, Firefox 3.5.7.

 

[Eric Sosman]

[...]
And I don't think it was me that switched to non volatile. Both
Roedy and Eric were referring to something being non atomic
in the old days.

And my recollection was mistaken on at least two counts:

- I believed that in the Old Days even volatile could not
guarantee atomic loads and stores of long and double variables.
This was incorrect: Loads and stores of volatile variables of
all kinds are and always have been atomic, possibly requiring
JVM magic to make them so.

- I believed that non-atomicity of loads and stores for
longs and doubles was a thing of the past. This is not so: A
non-volatile long or double may still be accessed non-atomically,
even today. (Accesses to narrower types and to references, even
to 64-bit references, are and always have been atomic whether
volatile or non-volatile.)

Sorry for the misinformation, and thanks for the correction.

 

[Lars Enderin]

I got a report that Firefox under Linux is rendering this page with
all the body text in transparent ink. It works fine with Firefox and
windows. Is anyone else seeing this? It is just volatile.html or
other pages too?

Browsershots will not let me investigate. Somebody else used up
today's quota for mindprod.com

Style sheets and HTML validate ok.

Some text is rather faint, for example text rendered according to the
CSS classes keyword, date, reviewed, statistic. It's readable, but very
low contrast. My setup is shown by
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7)
Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7 GTB6

 

[Lew]

Christian wrote on 2/14:

in short x++ is not atomic...
as its a read and a write isn't it?

Eric Sosman wrote in this thread on 2/12:

 

[Andreas Leitgeb]

Eric Sosman wrote in this thread on 2/12:

I'm not whining (nor suggesting) for += nor ++ being atomic,
but that particular argument does not extend to the "++"
operator.

So, what to say to those whining^H^H^H^H^H^H^Hsuggesting
making just "++" atomic?

Just curious.

 

[Lew]

Eric Sosman wrote in this thread on 2/12:

I'm not whining (nor suggesting) for += nor ++ being atomic,
but that particular argument does not extend to the "++"
operator.

Actually, it does. The particular argument is an extension of the observation
that += and ++ both represent a read followed by a write, with an increment or
addition in there somewhere. Those are inherently separate operations.

So, what to say to those whining^H^H^H^H^H^H^Hsuggesting
making just "++" atomic?

What Joshua Cranmer said, with "increment" added:

x++ properly involves a read, then a copy[, then an increment],
then a write, so it is not atomic.

and correspondingly for a pre-increment:

++x properly involves a read[, then an increment], then a write,
then a copy, so it is not atomic.

Also tell them that there already is an atomic version of that operation,
'AtomicInteger#getAndIncrement()', et al., to be happy that synchronization is
built in to the language, and to quit whining.

Not every operation can be atomic. Some actions involve too many steps to be
atomic. It is clear that a simple 'volatile' read or write can, and should,
be atomic. It is clear that a long sequence of steps, such as:

x = 0;
y = x * 3;
x = y / 17;
x = Math.sqrt( x );

should not be atomic without explicit synchronization. Therefore it is clear
that not all operations involving a mix of reads and writes should be atomic.
Since 'synchronized' or similar is needed to synchronize such multiple
operations, and 'synchronized' and similar are built into the platform, it
makes sense that those mechanisms should apply to all situations involving a
mix of reads and writes, rather than to draw some arbitrary and hard-to-manage
boundary between mixes that are atomic and those that are not.

Really, though, whining about the absence of a feature that is already
provided by other means is just stupidity and childish petulance. THE FEATURE
ALREADY EXISTS. You just can't use the ++ operator for it. Sheesh!

 

[Arne Vajhøj]

in short x++ is not atomic...
as its a read and a write isn't it?

On some computers it will be:

1) read from memory@x to register
2) add 1 to register
3) write from register to memory@x

It is not a natural atomic operation.

Java has explicit synchronization techniques
to enable the programmer to make it atomic if
needed.

Arne

 

[Roedy Green]

Some text is rather faint, for example text rendered according to the
CSS classes keyword, date, reviewed, statistic. It's readable, but very
low contrast. My setup is shown by
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7)
Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7 GTB6

Hmm. I wonder if it has something to do with having anti-aliasing on
or off. Some fonts that are designed for anti-aliasing look spidery
thin when rendered without.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Nothing has really happened until it has been recorded.
~ Virginia Woolf (born: 1882-01-25 died: 1941-03-28 at age: 59)

 

[Roedy Green]

Actually, it does. The particular argument is an extension of the observation
that += and ++ both represent a read followed by a write, with an increment or
addition in there somewhere. Those are inherently separate operations.

I have forgotten what the machine was, but I once used a machine that
had an atomic ++ to memory machine instruction. You used it for
implementing locks rather that Test and Set. It is a plausible
question to ask if ++ is atomic.

--
Roedy Green Canadian Mind Products
http://mindprod.com

Nothing has really happened until it has been recorded.
~ Virginia Woolf (born: 1882-01-25 died: 1941-03-28 at age: 59)

 

[Arne Vajhøj]

I have forgotten what the machine was, but I once used a machine that
had an atomic ++ to memory machine instruction. You used it for
implementing locks rather that Test and Set. It is a plausible
question to ask if ++ is atomic.

With today's CPU's an atomic ++ is relative expensive.

But in older designs it was cheaper.

VAX had the ADAWI instruction.

Arne

 

[Lew]

Lew quoted or indirectly quoted someone who said :

I have forgotten what the machine was, but I once used a machine that

I believe it's called "the x86 family of processors".

Contains special support for atomic instructions (XCHG, CMPXCHG(8B),
XADD, and integer instructions which [sic] combine with the LOCK prefix)

had an atomic ++ to memory machine instruction. You used it for
implementing locks rather that Test and Set. It is a plausible
question to ask if ++ is atomic.

Of course.

wasn't about how to answer a question whether ++ is atomic, but a whine that
it isn't.

To a simple question about whether ++ in Java is atomic, a simple answer is,
"No, but you can use 'AtomicInteger##getAndIncrement()', et al., or
'synchronized'."

I would not be astounded to learn that the 'AtomicInteger' method is
implemented in terms of an atomic instruction where available (e.g., on x86
processors).

... the JVM improvements in JDK 5.0, ... exposed (to the class
libraries, but not to user classes) an interface to access
hardware-level synchronization primitives. The atomic variable
classes, and other classes in java.util.concurrent, in turn[,]
expose these features to user classes.

 

[Andreas Leitgeb]

Eric Sosman wrote in this thread on 2/12:

Actually, it does. The particular argument is an extension of the observation
that += and ++ both represent a read followed by a write, with an increment or
addition in there somewhere. Those are inherently separate operations.

Those who whine (not me!) actually suggest changing that, by adding
new bytecodes for a combined & atomic e.g. "read+add+write"

On re-thought, even Eric's argument seems not too strong anymore:
First, z is read,
Then y is atomically increased by the previously read value.
Then x ...
...
While e.g. "n" is increased, some other thread could modify "a" and "z".
Obviously, that is irrelevant to the current thread, which no longer
cares for "z"'s value, and not yet cared for "a"'s old value.
...
Finally the resulting value of "b" would be added to the new value of "a".

No ambiguities involved.

Also tell them that there already is an atomic version of that operation,
'AtomicInteger#getAndIncrement()', et al., to be happy that synchronization is
built in to the language, and to quit whining.

So it's all just about whether "++","--","+=" and "-=" would be made
shorthands for what is already possible by the Atomic* classes.

The real reason boils down to that those atomic operations are still
slightly slower than the non-atomic ones, while the cases not caring
about atomicity by far outnumber the others. That's why I added
those "(not me!)"s.

Afterall, making "++" and "--" and the "op="s atomic just for volatile
variables wouldn't seem all that wrong to me. As there is no "Math.sqrt="
operator your other snippet seems quite irrelevant.

Since 'synchronized' or similar is needed to synchronize such multiple
operations, and 'synchronized' and similar are built into the platform, it
makes sense that those mechanisms should apply to all situations involving a
mix of reads and writes, rather than to draw some arbitrary and hard-to-manage
boundary between mixes that are atomic and those that are not.

The "arbitrary" boundary would be imposed by the (relative) frequency
of single-variable atomic get&calc&sets versus complex multivariable blocks
needing overall synchronization. The same way, as this boundary exists
already between uses for volatile,Atomic* and synchronized.

Really, though, whining about the absence of a feature that is already
provided by other means is just stupidity and childish petulance.

Development of a language is like dynamic compression: tasks that are
found to occur frequently enough are made simpler and shorter (see 1.5's
new for-syntax, autoboxing, static imports...).

There's enough room to differ on what deserves simplification, and what
doesn't, but principially negating the usefulness of making shorter syntax
for any already existing functionality is just as childish as being overly
greedy for syntactic sugar.

 

[Lew]

Afterall, making "++" and "--" and the "op="s atomic just for volatile
variables wouldn't seem all that wrong to me. As there is no "Math.sqrt="
operator your other snippet seems quite irrelevant.

Then you missed the point.

At one end of the spectrum are operations that already are atomic for volatile
variables, those involving a simple single read or a simple single write. At
the other end of the spectrum are combined reads and writes that clearly
should not be atomic, like 'x = Math.sqrt(x);'. In between are the questions
of whether ++ += or chained += expressions should be atomic for volatile
variables. Unlike the operations involving only a single read or write, these
involve combined reads and writes, just like the expressions that we all agree
should not be atomic.

The matter of the existence or not of a shorthand combining operator is a red
herring.

 

[Lars Enderin]

Hmm. I wonder if it has something to do with having anti-aliasing on
or off. Some fonts that are designed for anti-aliasing look spidery
thin when rendered without.

No, the text is not thin, it's just faint, with low contrast, but
readable. It looks almost transparent, which is what you asked about
initially.

 

[Andreas Leitgeb]

Then you missed the point.

I have, w.r.t the spectrum.
You have, w.r.t certain points of the spectrum lending themselves
to a boundary line more than others, and not less than the current.

The matter of the existence or not of a shorthand combining operator is a red
herring.

Java programming must really stink to you, with all those red herrings.

The shorthand combining operators already differ from their explicit
a = a <op> b variants. (especially for array-elements and fields
of non-trivially obtained objects)
Adding their atomicity for volatiles wouldn't exactly wreck the whole
paradigm.

For consistency, however, *all* of them would have to be atomic then,
including e.g. /=, >>>= ... which do not even have counterparts in
the Atomic* classes so far.

I'm not really proposing them, just arguing that they wouldn't be *bad*.
I make no claim, that they'd be anything more than just a convenience.

Sometimes, conveniences happen.

 

[Jukka Lahtinen]

I got a report that Firefox under Linux is rendering this page with
all the body text in transparent ink. It works fine with Firefox and
windows. Is anyone else seeing this? It is just volatile.html or

Looks just fine here.
64 bit Fedora 12 Linux with kernel-2.6.31.12-174.2.3.fc12.x86_64 and
firefox-3.5.6-1.fc12.x86_64.
Also looks all right with seamonkey-2.0.1-1.fc12.x86_64.

 

[Eric Sosman]

I'm not whining (nor suggesting) for += nor ++ being atomic,
but that particular argument does not extend to the "++"
operator.

So, what to say to those whining^H^H^H^H^H^H^Hsuggesting
making just "++" atomic?

Just curious.

Could be (or have been) done, I guess. Nowadays most
machines have compare-and-swap or something of the kind, and
these can be repeated in a loop until successful:

loop: load r0,x
load r1,r0
inc r1
cas r0,r1,x // if x==r0, set x=r1 and r1==x
cmp r0,r1 // did the swap happen?
jneq loop // failed: retry

Such instructions tend to be fairly expensive, though, since
they need to do things like flush a CPU's store buffers and
maybe bypass caches to go all the way to (s-l-o-w) RAM. The
expense isn't fatal in and of itself (`synchronized' needs to
do similar things) -- but from a language perspective it means
you can no longer say "++ is shorthand for +=1" unless you also
promise atomicity for +=, and then comes the slippery slope.

Atomic x++ when x is Double.NaN could be *really* fun ...