[concurrency-interest] Re: synchronized vs ReentrantLock semantic

Michael Smith MSmith at netspoke.com
Mon Jun 13 15:12:54 EDT 2005

(Resurrecting a thread from a few weeks ago -- I have not previously
been on this list and didn't see it, otherwise I would have responded
On Monday May 23, 2005, Doug Lea wrote:
> Jean Morissette wrote:
> > Hi all,
> >  I would like to know whether replacing "synchronized" statement by 
> > ReentrantLock instances has the same semantic and meaning for the
jvm?  By 
> > exemple, I'm wondering whether ReentrantLock would allow reliable 
> > transmission of values or sets of values from one thread to another
> > shared variables?
> >
> yes. See the javadoc for the Lock interface, that says:
> Memory Synchronization
> All Lock implementations must enforce the same memory synchronization 
> semantics as provided by the built-in monitor lock:
>      * A successful lock operation acts like a successful monitorEnter

> action
>      * A successful unlock operation acts like a successful
> action

A coworker of mine brought up this exact question recently and while we
found this quoted documentation in the Lock API, we're not entirely
convinced that the implementation actually performs the requisite memory
synchronization required by the semantics defined for monitorEnter and
monitorExit.  ReentrantReadWriteLock uses AbstractQueuedSychronizer to
manage the locking but that class explicitly states that it does not
perform any memory synchronization other than the "state" that it
manages ("only the atomically updated int  value manipulated using
methods getState(), setState(int) and compareAndSetState(int, int) is
tracked with respect to synchronization").   
Thus, the following class will properly ensure the thread execution
semantics implied by the locks (cannot call getValue while another
thread is calling setValue, vice-versa, and multiple calls to getValue
are allowed simultanously), however it does not appear that it would
have proper memory synchronization semantics such that threads would see
the same value since there's no memory barriers that would copy a new
value from main memory to the thread's local memory.
public class Test {
  private Data data = new Data();
  private ReentrantReadWriteLock myLock =
    new ReentrantReadWriteLock(true);
  public setValue(int value) {
    try {
    finally {
  public getValue() {
    try {
      return data.getValue();
    finally {

Since this seems like the fundamental use-case for this API, we can only
assume that we are blind and just aren't seeing something in the code.
Can someone provide more details about how and where thread memory and
main memory are synchronized when using ReentrantReadWriteLock's locks?
Note:  My coworker started a thread on this question here:
Michael Smith
msmith at netspoke.com <mailto:msmith at netspoke.com> 
Software Engineering Manager
Netspoke, Inc.
5001 Centre Ave., 2nd Floor
Pittsburgh, PA 15213
t: (412) 605-1508
f: (412) 687-4615

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20050613/bb1b5ec5/attachment.htm

More information about the Concurrency-interest mailing list