What does volatile guarantee?
in [Java Help]
|
Prev: 64-bit JNI
Next: Problem with interface implementation
From: Lew on 14 Feb 2010 11:35 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: > There's no atomicity guarantee for things like x++ or x+=42, > because these are not single accesses: They need paired reads > and writes. The read will be atomic and fetch a consistent > value, the write will be atomic and store a consistent value, > but other (individually atomic) reads and writes may intervene. > > 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; -- Lew
From: Andreas Leitgeb on 14 Feb 2010 16:30 Lew <noone(a)lewscanon.com> quoted: > 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; 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.
From: Lew on 14 Feb 2010 18:23 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; Andreas Leitgeb wrote: > 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! -- Lew
From: Arne Vajhøj on 14 Feb 2010 20:00 On 14-02-2010 10:48, Christian wrote: > 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
From: Roedy Green on 14 Feb 2010 20:48
On Sat, 13 Feb 2010 23:48:38 +0100, Lars Enderin <lars.enderin(a)telia.com> wrote, quoted or indirectly quoted someone who said : > >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) |