[concurrency-interest] Re: synchronized vs ReentrantLock semantic

Dawid Kurzyniec dawidk at mathcs.emory.edu
Tue Jun 14 00:33:27 EDT 2005

David Holmes wrote:

>Gregg Wonderly wrote:
>>Okay, then this is sure not clear to me either.  I guess I'm really
>>confused now.  I would suggest there should be some even more explicit
>>wording about all the specific steps and the specific ties into the
>>memory model.
>Where has this confusion arisen?
>Locks are intended as a direct alternative for use of synchronized
>blocks/methods. Hence the Lock interface specifies:
>"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 monitorExit action "
I agree with Greg that perhaps the javadoc should be more verbose on 
this. Including the spec of AQS. As it is, it is perfectly accurate but 
requires the reader to have read and understood the JVM spec, in 
particular the semantics of monitorEnter/monitorExit and the JMM. I 
think it would be beneficial for the average API user if you briefly 
reiterate some crucial properties here, without implicitly referring to 
the JVM spec.

I think that some people may not even immediately understand, or be sure 
about, the connection between phrases "built-in monitor lock, 
monitorEnter, monitorExit" and "synchronized() {}". Maybe just a simple 
example could remove the confusion.


More information about the Concurrency-interest mailing list