What does volatile guarantee?
in [Java Help]
|
Prev: 64-bit JNI
Next: Problem with interface implementation
From: Joshua Cranmer on 12 Feb 2010 11:47 On 02/12/2010 10:23 AM, Roedy Green wrote: > This suggests if your hardware stores a 64-bit long in two 32-bit > stores, it must somehow lock the pair together so that another thread > will not see half the store. I wonder just how they do that, and if > they indeed do. Well, on Linux x86, it seems that they turn a putfield for a volatile into (essentially): volatile julong *p, julong v; *p = v; On Linux "zero" (seems to contain at least ARM or PPC), the equivalent code is "os::atomic_copy64(&v, p);". > 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. volatile only refers to reads and writes to a variable. x++ properly involves a read, then a copy, then a write, so it is not atomic. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Lew on 12 Feb 2010 12:14 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: - A write to 'x' establishes /happens-before/ for all prior writes in that thread (not just to 'x'), and /happens-before/ all subsequent reads of 'x' from any thread. - A read from 'x' /happens-before/ all subsequent reads (not just from 'x') in the same thread. - Therefore all writes in a thread prior to a write in that thread to 'x' /happen-before/ all reads from any thread subsequent to a read from 'x' in that other thread. - Reads from and writes to 'x' are atomic, whether that variable represents any primitive including 'long' or 'double', or a reference. Remarkably, this information is in the JLS (JLSIYF): <http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.3.1.4> <http://java.sun.com/docs/books/jls/third_edition/html/memory.html#61803> As well as in easily findable locations: <http://www.ibm.com/developerworks/java/library/j-jtp06197.html> Developerworks is a first choice for researching Java questions, plus GIYF. -- Lew
From: Roedy Green on 12 Feb 2010 14:44 I have written an entry in the Java glossary merging the points all of you made. See http://mindprod.com/jgloss/volatile.html I started on this exercise at the request of student Naheen Dhawan who asked for clarification on the old volatile entry. At least it is now clear in my mind. If you can think of better wording, or see typos, please pass your findings on. -- Roedy Green Canadian Mind Products http://mindprod.com Every compilable program in a sense works. The problem is with your unrealistic expections on what it will do.
From: Lew on 12 Feb 2010 17:45 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 started on this exercise at the request of student Naheen Dhawan who > asked for clarification on the old volatile entry. > > At least it is now clear in my mind. If you can think of better > wording, or see typos, please pass your findings on. The behavior of 'volatile' was significantly different in Java 1.4 and earlier. It only promised consistently for the volatile variable itself. Other reads and writes had no guarantees at all. This was before the JLS introduced the notion of /happens-before/. -- Lew
From: Tom Anderson on 13 Feb 2010 07:41
On Fri, 12 Feb 2010, 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 started on this exercise at the request of student Naheen Dhawan who > asked for clarification on the old volatile entry. > > At least it is now clear in my mind. If you can think of better > wording, or see typos, please pass your findings on. All i'll add is that what volatile does is somewhat subtle, tying in to the rest of the memory model, so there isn't a simple way to isolate it in explanation - but the memory model section in the JLS is really very good, and people ought to read it. I'd honestly suggest reading that rather than reading someone else's interpretation of it. Perhaps the most useful format would be an annotated copy of the JLS text on this matter? tom -- First man to add a mixer get a shoeing! -- The Laird |