Why don't we need volatile with StampedLock?

Question

Given a code sample from Oracle docs https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/StampedLock.html

class Point {
   private double x, y;
   private final StampedLock sl = new StampedLock();

   void move(double deltaX, double deltaY) { // an exclusively locked method
     long stamp = sl.writeLock();
     try {
       x += deltaX;
       y += deltaY;
     } finally {
       sl.unlockWrite(stamp);
     }
   }

   double distanceFromOrigin() { // A read-only method
     long stamp = sl.tryOptimisticRead();
     double currentX = x, currentY = y;
     if (!sl.validate(stamp)) {
        stamp = sl.readLock();
        try {
          currentX = x;
          currentY = y;
        } finally {
           sl.unlockRead(stamp);
        }
     }
     return Math.sqrt(currentX * currentX + currentY * currentY);
   }

   void moveIfAtOrigin(double newX, double newY) { // upgrade
     // Could instead start with optimistic, not read mode
     long stamp = sl.readLock();
     try {
       while (x == 0.0 && y == 0.0) {
         long ws = sl.tryConvertToWriteLock(stamp);
         if (ws != 0L) {
           stamp = ws;
           x = newX;
           y = newY;
           break;
         }
         else {
           sl.unlockRead(stamp);
           stamp = sl.writeLock();
         }
       }
     } finally {
       sl.unlock(stamp);
     }
   }
 }

And provided that all methods of class Point might be called from different threads:

Why exactly do we not need fields x and y to be declared as volatile?

Is it guaranteed that the code executing the Point#moveIfAtOrigin method would always see the freshest changes to the x and y fields after acquiring StampedLock#readLock?

Is there any kind of memory barrier being established when we call StampedLock#writeLock, StampedLock#readLock?

Could anyone point to a quote from documentation regarding that?

Answer 1

I can't tell why that is not explicitly cited in the doc - may be because it is sort of implied, but internally that does a Unsafe.compareAndSwapLong which translates to LOCK CMPXCHG, which on x86 has full memory barrier (I assume something like this is done on other platforms); so there is no need for those to be volatile indeed.

Actually any instruction on x86 that has a lock will have a full memory barrier.

Answer 2

The Javadoc of the Lock interface states the following:

Memory Synchronization

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 (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. Unsuccessful locking and unlocking operations, and reentrant locking/unlocking operations, do not require any memory synchronization effects.

Even though StampedLock does not implement Lock, it has a method like asReadLock() that:

Returns a plain Lock view of this StampedLock in which the Lock.lock() method is mapped to readLock(), and similarly for other methods.

It returns an instance of StampedLock's inner class ReadLockView, which IS an actual implementation of Lock.

But because it's merely a delegator, that means the original methods must create memory barriers in order to comply with the Memory Synchronization enforcement of the Lock interface.