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.
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 successfulLock
action.- A successful
unlock
operation has the same memory synchronization effects as a successfulUnlock
action.
来源:https://stackoverflow.com/questions/1570589/is-the-volatile-keyword-required-for-fields-accessed-via-a-reentrantlock