[concurrency-interest] Curious: How Java Memory Model is satisfied in JSR166 locks?

Compl Yue Still complystill at gmail.com
Tue Aug 21 09:44:30 EDT 2007

Thanks Osvaldo & Gregg,

I know Unsafe is there, but when I read the
java.util.concurrent.locks.ReentrantLock source code from JDK6, the
only connection from a successful lock acquisition to Unsafe is the
state manipulation method defined at AQS, and these methods just "has
memory semantics of a volatile write", how is this enough adequate to
make compatible with the default synchronization lock mechanisms?

Thanks & expecting more ideas.


On 8/21/07, Gregg Wonderly <gregg at cytetech.com> wrote:
> Compl Yue Still wrote:
> > I saw dl.util.concurrent code leverages synchronized(){} blocks to
> > assure similar effects, but I found no equivalent code in jdk source,
> > it's such a myth to me.
> >
> > Is any black magic there?
> The underlying JVM facilities for monitor-entry and monitor-exit are used by
> lock and unlock.  In a simple sense, synchronized is equivalent to:
> lock.lock();
> try {
>        ...
> } finally {
>        lock.unlock();
> }
> If you're familar with the JNI environment, you know that there is a monitor
> entry and monitor exit function available.  These are at the core of what
> synchronized() is.  In Sun's JVM, these functions are now made available to
> application code through their visibility in the Unsafe class.  If you look at
> the JDK1.6 source code on Java.net, you can find the Unsafe class and unsafe.cpp
> to see all of the things in the internals which are available in Sun's
> implementation.
> Gregg Wonderly

More information about the Concurrency-interest mailing list