CODEWITHSUNDEEP
javamultithreadingconcurrencyjava.util.concurrent
Jim
Jim

Reputation: 19552

Guarantees of AtomicReference

What are the semantics of an AtomicReference?
If I do:

AtomicReference<CustomObject> ref = new AtomicReference<CustomObject>();

and then I do: 

public void someMethod(){  
 //do something  

 ref.set(loadNewData());  

}  

private final Sempahore updatePermit = new Sempahore(1);  

private CustomObject loadNewData(){  
     CustomObject obj = null;  
     if (updatePermit.tryAcquire()) {  
        obj = ...; //do the loading and create Object  
        updatePermit.release();  
    } else {  
        //update already running, wait  
        updatePermit.acquire();  
        //release the permit immediately  
        updatePermit.release();  
        obj = ref.get(); //????
    }  
    return obj;    
}

Is there a guarantee that on line obj = ref.get(); //???? the get will return the most fresh version of CustomObject?
This is related to the answer of assylias for post:

Upvotes: 2

Views: 3051

Answers (4)

jtahlborn
jtahlborn

Reputation: 53694

Actually, your code has a race condition which could cause new data to be lost:

  1. first caller goes into loadNewData and starts loading new data (has semaphore)
  2. second caller cannot get semaphore and waits at acquire
  3. first caller finishes loading and releases semaphore (but doesn't return new data yet)
  4. second caller acquires semaphore, calls ref.get() and gets old data
  5. first caller returns new data which is passed to ref.set()
  6. second caller return old data which overwrites new data when passed to ref.set()

Since someMethod() is always loading new data and you always want callers to wait while new data is loading, all this extra stuff is useless. just use a simple synchronized block (or Lock) around the whole block and ditch the atomic reference. according to the linked post, it seems like you only ever want to do this once, so use an initialized flag.

private boolean _initialized;

public synchronized void loadLatestData() {
  if(!_initialized) {
      // load latest data ...
      _initialized = true;
  }
}

Upvotes: 3

Ian Roberts
Ian Roberts

Reputation: 122364

Atomic variables (including AtomicReference) have the same properties as volatile fields, in that they establish a happens-before relation across threads. If one thread A writes a value to a volatile field (or atomic variable) and another thread B reads from that same variable then you can't necessarily guarantee whether B will or will not see A's change, but you can guarantee that

  • IF B sees the value written by A
  • THEN B will also see the results of any writes to other fields (volatile and non-volatile) that A did before it wrote the volatile field.

Upvotes: 1

Tomasz Nurkiewicz
Tomasz Nurkiewicz

Reputation: 340713

Reading JavaDoc of java.util.concurrent.atomic:

  • get has the memory effects of reading a volatile variable.

  • set has the memory effects of writing (assigning) a volatile variable.

So the guarantees are: get() always returns the last value passed to set(). It doesn't matter what you do in the meantime, what kind of locks you use, etc. Modifying volatile variable (which you effectively do) is guaranteed to be visible by all other threads reading that value.

Upvotes: 3

SLaks
SLaks

Reputation: 887285

Yes.
AtomicReference guarantees publication.

However, there is no guarantee that a different thread won't set it a millisecond later.

Note that if you aren't calling compareAndSet(), an AtomicReference is no better than a volatile field.

Upvotes: 3

Related Questions