Question

In the following simple scenario:

class A {
  int x;
  Object lock;

  ...

  public void method(){
    synchronized(lock){
      // modify/read x and act upon its value
    }
  }
}

Does x need to be volatile? I know that synchronized guarantees atomicity, but I am not sure about visibility though... does lock -> modify -> unlock -> lock guarantee, that after the second lock the value of x will be "fresh"?

Was it helpful?

Solution

No it does not, because synchronized already has a memory barrier inserted after it, so all threads will see the update that the current thread performs, taking into account that the other threads will synchronize on the same lock.

Volatile, just like synchronized, has memory barriers that are attached to it - depending on the CPU, it is store/load/full barrier that ensures that an update from one thread is visible to the other(s). I assume this is performed with CPU cache invalidation.

EDIT From what I've just read, the store buffers are flushed to the CPU cache, and this is how the visibility is achieved.

OTHER TIPS

Simplified answer: If thread A updates a field and then releases a lock, then thread B will be guaranteed to see the update after thread B has acquired the same lock.

Note, "release a lock" means exit a synchronized block, and "acquire the same lock" means synchronize on the same object.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top