What does volatile guarantee?
in [Java Help]
|
Prev: 64-bit JNI
Next: Problem with interface implementation
From: Roedy Green on 14 Feb 2010 21:13 On Sun, 14 Feb 2010 18:23:23 -0500, Lew <noone(a)lewscanon.com> wrote, quoted or indirectly quoted someone who said : >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)
From: Arne Vajhøj on 14 Feb 2010 21:20 On 14-02-2010 21:13, Roedy Green wrote: > On Sun, 14 Feb 2010 18:23:23 -0500, Lew<noone(a)lewscanon.com> wrote, > quoted or indirectly quoted someone who said : >> 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. With today's CPU's an atomic ++ is relative expensive. But in older designs it was cheaper. VAX had the ADAWI instruction. Arne
From: Lew on 14 Feb 2010 21:35 Lew quoted or indirectly quoted someone who said : >> 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. Roedy Green wrote: > I have forgotten what the machine was, but I once used a machine that I believe it's called "the x86 family of processors". <http://en.wikipedia.org/wiki/X86_assembly_language#Instruction_types> >> Contains special support for atomic instructions (XCHG, CMPXCHG(8B), >> XADD, and integer instructions which [sic] combine with the LOCK prefix) Roedy Green wrote: > 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. The post I answered that Andreas Leitgeb wrote: >>> So, what to say to those whining^H^H^H^H^H^H^Hsuggesting >>> making just "++" atomic? 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). <http://www.ibm.com/developerworks/java/library/j-jtp11234/> > ... 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. -- Lew
From: Andreas Leitgeb on 14 Feb 2010 22:32 Lew <noone(a)lewscanon.com> wrote: > Eric Sosman wrote in this thread on 2/12: >>>> 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; > > 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.
From: Lew on 15 Feb 2010 00:47
Andreas Leitgeb wrote: > 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. -- Lew |