Is the volatile keyword required for fields accessed via a ReentrantLock?

Question

My question refers to whether or not the use of a ReentrantLock guarantees visibility of a field in the same respect that the synchronized keyword provides.

For example, in the following class A, the field sharedData does not need to be declared volatile as the synchronized keyword is used.

class A 
{
  private double sharedData;

  public synchronized void method() 
  {
    double temp = sharedData;
    temp * 2.5;
    sharedData = temp + 1;
  } 
}

For next example using a ReentrantLock however, is the volatile keyword on the field necessary?

class B 
{
  private final ReentrantLock lock = new ReentrantLock();
  private volatile double sharedData;

  public void method() 
  {
    lock.lock();
    try
    {
      double temp = sharedData;
      temp * 2.5;
      sharedData = temp + 1;
    }
    finally
    {
      lock.unlock();
    }
  } 
}

I know that using the volatile keyword anyway will only likely impose a miniscule performance hit, but I would still like to code correctly.

Answer 1

It's safe without volatility. ReentrantLock implements Lock, and the docs for Lock include this:

All Lock implementations must enforce the same memory synchronization semantics as provided by the built-in monitor lock, as described in The Java Language Specification, Third Edition (17.4 Memory Model):

• A successful lock operation has the same memory synchronization effects as a successful Lock action.
• A successful unlock operation has the same memory synchronization effects as a successful Unlock action.