[concurrency-interest] Re: synchronized vs ReentrantLock semantic

David Holmes dholmes at dltech.com.au
Mon Jun 13 21:36:44 EDT 2005

> Gregg Wonderly wrote:
> When you use this lock to protect reading and writing of other values,
> those values must be volatile if you want their changed state to
> propagate between threads/processors etc.

Absolutely NOT! You do not need to have the shared data that is protected by
a Lock - any kind - be declared volatile. The Lock implementations take care
of all the required memory model semantics.

Sorry Gregg but I have to make sure this misconception is entirely squashed
(both here are on the referenced forum).

Hopefully it is clear now that the lock implementations use AQS and its
getState, setState and compareAndSetState methods are specified to have the
same memory model semantics as a volatile read, write, read/write -
respectively. So if you use those methods in a class like ReentrantLock then
you automatically get the required memory model semantics

I think we (JSR-166 EG) do need to clarify the ReadWriteLock interface
documentation, because at present while both readLock() and writeLock()
returns Lock instances - and so have the specified memory model semantics
relating to lock() and unlock() - what is missing is any statement that the
two Lock instances act as if they read/write the *same* volatile. ie there
is nothing that indicates that a writeLock().unlock() has the right memory
effects related to a following readLock().lock(). The implementation
certainly does, but the spec for the interface doesn't make that clear.

David Holmes

More information about the Concurrency-interest mailing list