What does volatile guarantee?
in [Java Help]
|
Prev: 64-bit JNI
Next: Problem with interface implementation
From: Lew on 13 Feb 2010 15:28 Peter Duniho wrote: >> Those being primitive types, it does. Lew even described the relevant >> "volatile" rule in his earlier reply: Arne Vajhøj wrote: > Lew is talking about volatile long's, which is not what we are > discussing here (volatile long's has been atomic since 1.0). Did you read Peter's post? He specifically addressed 'volatile', hence his use of the word in his post, 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. Coincidentally, I linked to JLS s. 17.7 at roughly the same time you cited it. \ -- Lew
From: Lew on 13 Feb 2010 15:31 Roedy Green wrote: >> I have written an entry in the Java glossary merging the points all of >> you made. See http://mindprod.com/jgloss/volatile.html > > 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? It's not even volatile.html. The page looks fine here. Firefox 3.0.17 under Ubuntu Linux 9.04 kernel 2.6.28-18-generic, 64-bit. -- Lew
From: Mike Schilling on 13 Feb 2010 15:34 Lew wrote: > Eric Sosman wrote: >> The machines I'm familiar with distinguish 32- and 64-bit >> "modes" only by the way addresses are generated, handled, and >> mapped. 64-bit load and store instructions are available no >> matter what the addresses look like, and are atomic (given >> proper operand alignment). > > 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..
From: Arne Vajhøj on 13 Feb 2010 15:34 On 13-02-2010 15:28, Lew wrote: > Peter Duniho wrote: >>> Those being primitive types, it does. Lew even described the relevant >>> "volatile" rule in his earlier reply: > > Arne Vajhøj wrote: >> Lew is talking about volatile long's, which is not what we are >> discussing here (volatile long's has been atomic since 1.0). > > 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
From: Arne Vajhøj on 13 Feb 2010 15:35
On 13-02-2010 15:34, Mike Schilling wrote: > Lew wrote: >> Eric Sosman wrote: >>> The machines I'm familiar with distinguish 32- and 64-bit >>> "modes" only by the way addresses are generated, handled, and >>> mapped. 64-bit load and store instructions are available no >>> matter what the addresses look like, and are atomic (given >>> proper operand alignment). >> >> 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.. Very true. synchronized is good! Arne |