Memory barrier and java.util.concurrent.locks.Condition example

Question

I have a question regarding memory barriers when using a Condition provided by a Lock.

Regarding the example provided in the javadoc for Condition, I have a question about the use of:

int putptr, takeptr, count;

Shouldn't these attributes be declared volatile? As I understand it from the example, a thread might not see the modifications of, e.g., count.

Or is it that, when signal() is called, all modifications made since the lock was acquired are visible to other threads? Much like some code in a synchronized block?

If yes, are the modifications visible when signal() is called, or when unlock() is called on the lock?

Thanks.

Edit: I see in the javadoc of Lock:

All Lock implementations must enforce the same memory synchronization semantics as provided by the built-in monitor lock, as described in section 17.4 of The Java™ Language Specification:

• 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.

Do they mean: "A successful lock operation has the same memory synchronization effects as entering a synchronized block", and "A successful unlock operation has the same memory synchronization effects as exiting a synchronized block"?

Answer 1

The way you should read into it is, all writes that occur prior to a lock.unlock are visible to all subsequent lock.lock. A thread that is awaiting, when woken up, will essentially do lock.lock. So all writes that occurred since the previous unlock will now be visible.

The signal has no memory semantics, as your latter point states or when unlock() is called on the lock is correct.

Do they mean: "A successful lock operation has the same memory synchronization effects as entering a synchronized block", and "A successful unlock operation has the same memory synchronization effects as exiting a synchronized block"?

Yes, exactly! More specifically the compiler will issue monitorenter and monitorexit byte code instructions.