Is it necessary to declare an AtomicReference as volatile?

Question

The same for all other atomic objects? It's easier to explain the question for an AtomicInteger. Since more then 1 thread are accessing the reference to myInt, isn't it possible that one thread sees the registered cached value, for example null, for this object, unless it is also declared volatile? If not how come?

I try to make all AtomicReference fields final. You should avoid ever needing to change it. — Peter Lawrey, Aug 12 '11 at 08:41

score 10 · Accepted Answer · edited May 23 '17 at 12:11

10

Not only is it not necessary, it's actually semantically wrong. AtomicReference holds the "real" reference within itself, and manages access to it using its own synchronization constructs. The JVM's own synchronization constructs (synchronized, volatile, etc) and not used. The AtomicReference object itself should not be treated as volatile. If anything, consider making it final.

Also consider this question - volatile can be considered to be an alternative to using AtomicReference, if all you need is get and set operations.

edited May 23 '17 at 12:11

Community

1
1

answered Aug 12 '11 at 06:49

skaffman

398,947
96
818
769

Why not? A concurrent map could well be hold by a volatile field for legitimate reason, and I don't see why this shouldn't be true for the "atomic" objects? – Enno Shioji Aug 12 '11 at 07:16
@Enno: Sure, I suppose you could concoct a scenario where that would be appropriate. If you were to see `volatile AtomicReference` in code, though, it'd almost certainly not be what the author intended. – skaffman Aug 12 '11 at 08:09
@skaffman: Sure the AtomicReferance holds the real reference to the target object within itself but I am referring to the reference to this AtomicReference object. But indeed I can make it final, and it makes perfect sense too. Thanks! – Bogdan Balan Aug 13 '11 at 08:10

Enno Shioji · Answer 2 · 2011-08-12T07:33:01.860

The "atomic" objects are not immutable, so they should be thread safe only if they are published properly. For example, when you do something like this, you will need to use the volatile keyword.

volatile AtomicInteger counter = // initialize counter

int harvest(){
    AtomicInteger old = counter;
    counter = new AtomicInteger();
    return old.get();
}

If you remove the volatile from the above code, you could indeed lose some increments. According to the spec, you might also get a reference to an AtomicInteger object that is not fully constructed, and thus get undefined behavior.

So, do you need to declare your atomic object as volatile? The answer is it depends. They are only thread safe as long as they are published properly, as any other thread safe objects are (except immutable objects, which are special case). In most cases, you should make them final.

Is it necessary to declare an AtomicReference as volatile?

2 Answers2