Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I believe that <code>Atomic*</code> actually gives <em>both</em> atomicity and volatility. So when you call (say) <code>AtomicInteger.get()</code>, you're guaranteed to get the <em>latest</em> value. This is documented in the <code>java.util.concurrent.atomic</code> <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html" rel="noreferrer">package documentation</a>:</p> <blockquote> <p>The memory effects for accesses and updates of atomics generally follow the rules for volatiles, as stated in section 17.4 of The Java™ Language Specification.</p> <ul> <li>get has the memory effects of reading a volatile variable.</li> <li>set has the memory effects of writing (assigning) a volatile variable.</li> <li>lazySet has the memory effects of writing (assigning) a volatile variable except that it permits reorderings with subsequent (but not previous) memory actions that do not themselves impose reordering constraints with ordinary non-volatile writes. Among other usage contexts, > - lazySet may apply when nulling out, for the sake of garbage collection, a reference that is never accessed again.</li> <li>weakCompareAndSet atomically reads and conditionally writes a variable but does not create any happens-before orderings, so provides no guarantees with respect to previous or subsequent reads and writes of any variables other than the target of the weakCompareAndSet.</li> <li>compareAndSet and all other read-and-update operations such as getAndIncrement have the memory effects of both reading and writing volatile variables.</li> </ul> </blockquote> <p>Now if you have</p> <pre><code>volatile AtomicInteger count; </code></pre> <p>the <code>volatile</code> part means that each thread will use the latest <code>AtomicInteger</code> reference, and the fact that it's an <code>AtomicInteger</code> means that you'll <em>also</em> see the latest value for that object.</p> <p>It's not common (IME) to need this - because normally you wouldn't reassign <code>count</code> to refer to a different object. Instead, you'd have:</p> <pre><code>private final AtomicInteger count = new AtomicInteger(); </code></pre> <p>At that point, the fact that it's a <code>final</code> variable means that all threads will be dealing with the same object - and the fact that it's an <code>Atomic*</code> object means they'll see the latest value within that object.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload