Prev: 64-bit JNI
Next: Problem with interface implementation
From: Peter Duniho on 13 Feb 2010 15:41 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). I believe that the volatile longs is in fact what we are discussing here. But that doesn't really matter. As long as you're not trying to assert that reading or writing volatile longs or doubles isn't atomic, I have no disagreement with that.
From: John B. Matthews on 13 Feb 2010 15:44 In article <9rsdn59eljcpotcgqdifsal5q3qjvankls(a)4ax.com>, Roedy Green <see_website(a)mindprod.com.invalid> wrote: > 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? Looks OK on Ubuntu 2.6.31-19, Firefox 3.5.7. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Eric Sosman on 13 Feb 2010 15:59 On 2/13/2010 3:34 PM, Arne Vajhøj wrote: > [...] > 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. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Lars Enderin on 13 Feb 2010 17:48 Roedy Green wrote: > 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. 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
From: Christian on 14 Feb 2010 10:48
Am 12.02.2010 18:14, schrieb Lew: > Roedy Green wrote: >>> On Fri, 12 Feb 2010 07:23:13 -0800, Roedy Green wrote (all himself): >>>> I don't think the JLS guarantees that a volatile x++ must be atomic. >>>> It appears to be silent on the topic, which I take to mean you can't >>>> count on it. > > Andreas Leitgeb wrote: >> No, x++ is indeed *not* guaranteed to be atomic for any "++"-able type. > > If 'x' is volatile, the following guarantees hold for Java 5 and above: > snip > > Developerworks is a first choice for researching Java questions, plus GIYF. > in short x++ is not atomic... as its a read and a write isn't it? |