On 26 Aug 2011, at 05:13, Niclas Hedhman wrote: > On Fri, Aug 26, 2011 at 11:06 AM, Stuart McCulloch <[email protected]> wrote: >> On 26 Aug 2011, at 03:57, Niclas Hedhman wrote: >> >>> I think that is correct. >>> Assuming the 'next' is volatile, right? >> >> I don't believe 'next' has to be volatile, since the AtomicReference acts as >> a memory barrier > > If not, the changed value in 'next' might not be visible to another > thread, just sitting in cache of a core/cpu.
According to the AtomicReference javadoc: http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/atomic/package-summary.html "The memory effects for accesses and updates of atomics generally follow the rules for volatiles: * get has the memory effects of reading a volatile variable. * set has the memory effects of writing (assigning) a volatile variable. * weakCompareAndSet atomically reads and conditionally writes a variable, is ordered with respect to other memory operations on that variable, but otherwise acts as an ordinary non-volatile memory operation. * compareAndSet and all other read-and-update operations such as getAndIncrement have the memory effects of both reading and writing volatile variables." So any thread getting an instance from the pool makes at least a volatile read via the atomic reference, and any thread returning an instance to the pool makes at least a volatile write via the atomic reference. This sets up a "happens-before" relationship, which will cause any pending changes in the cache to be flushed to main memory: http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile Or in other words you don't have to make every shared variable volatile when doing inter-thread communication, you just need to have the right "happens-before" relationship on at least one shared variable. (This is also why double-checked locking works correctly in Java5+ whereas it didn't in earlier JVMs). But if you want to be really, really sure then marking the 'next' field as volatile won't cause problems (may affect performance, but probably not by much) > > Cheers > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/24svnvk > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
