What does volatile guarantee?
in [Java Help]
|
Prev: 64-bit JNI
Next: Problem with interface implementation
From: Roedy Green on 13 Feb 2010 13:48 On Fri, 12 Feb 2010 11:44:47 -0800, Roedy Green <see_website(a)mindprod.com.invalid> wrote, quoted or indirectly quoted someone who said : >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? Browsershots will not let me investigate. Somebody else used up today's quota for mindprod.com Style sheets and HTML validate ok. -- 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)
From: Eric Sosman on 13 Feb 2010 14:41 On 2/13/2010 1:22 PM, Arne Vajh�j wrote: > On 12-02-2010 11:36, Eric Sosman wrote: >> 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.) > > I believe that current JLS still does not guarantee > atomicity of reading/writing long and double. See Peter Duniho's reply. > And even though most CPU's today support 64 bit, then > a lot of them are running in 32 bit mode. 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). YMMV. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Arne Vajhøj on 13 Feb 2010 15:18 On 13-02-2010 13:40, Peter Duniho wrote: > Arne Vajh�j wrote: >> I believe that current JLS still does not guarantee >> atomicity of reading/writing long and double. > > Those being primitive types, it does. Lew even described the relevant > "volatile" rule in his earlier reply: > > Lew wrote: > > [...] > > - Reads from and writes to 'x' are atomic, whether that variable > > represents any primitive including 'long' or 'double', or a reference. Section 17.7 in the JLS states: <quote> Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32 bit values. For efficiency's sake, this behavior is implementation specific; Java virtual machines are free to perform writes to long and double values atomically or in two parts. For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64 bit value from one write, and the second 32 bits from another write. Writes and reads of volatile long and double values are always atomic. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32 or 64 bit values. VM implementors are encouraged to avoid splitting their 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications. <quote> Lew is talking about volatile long's, which is not what we are discussing here (volatile long's has been atomic since 1.0). Arne
From: Arne Vajhøj on 13 Feb 2010 15:21 On 13-02-2010 14:41, Eric Sosman wrote: > On 2/13/2010 1:22 PM, Arne Vajh�j wrote: >> On 12-02-2010 11:36, Eric Sosman wrote: >>> 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.) >> >> I believe that current JLS still does not guarantee >> atomicity of reading/writing long and double. > > See Peter Duniho's reply. See JLS 17.7. >> And even though most CPU's today support 64 bit, then >> a lot of them are running in 32 bit mode. > > 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 32 bit refer to the size of the virtual address. A 32 bit processor or a 64 bit processor in 32 bit mode can have instructions that operate on 64 bit entities. But AFAIK the x86-64 in 32 bit mode does not. And even though that is just one out of many processors, then it it is a rather widely used one. Arne
From: Lew on 13 Feb 2010 15:24
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> -- Lew |