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

Osvaldo Pinali Doederlein osvaldo at visionnaire.com.br
Tue Aug 21 08:46:35 EDT 2007


Hi,

Yes there is black magic - it's in class sun.misc.Unsafe, in methods 
like park(), compareAndSwapXxx() and others that are used by the 
implementations of j.u.c classes. These methods of the Unsafe class (as 
I understand it) are declared as common native methods, without any 
synchronization that you can notice, but they are really implemented as 
HotSpot intrinsics, i.e. the JVM will usually replace invocations to 
those methods for inline code that both avoids JNI overhead, and 
includes the necessary instructions for JMM satisfaction. Notice that 
you cannot invoke Unsafe's methods from your own code, access to that 
class is restricted to core classes. So you must channel your needs 
though public APIs like j.u.c locks, atomic objects and base classes 
like AQS.

A+
Osvaldo

Compl Yue Still escreveu:
> Hi list,
>
> I'm just curious that how lock implementations of JSR166 correctly
> satisfied the following requirement in the lock specification:
>
> "Memory Synchronization
>
> All Lock implementations must enforce the same memory synchronization
> semantics as provided by the built-in monitor lock, as described in
> The Java Language Specification, Third Edition (17.4 Memory Model):
> 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."
>
> 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?
>
> BTW, I'm currently figuring a methcanism that can assign locks to
> normal objects (transaction objects specifically, and
> detached/attached to worker threads over time) other than threads. I
> only have a rough understanding of AQS this far, and feels like it's
> adequate but not happily sure yet... Any suggestions?
>
> Best regards,
> Compl
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>   


-- 
-----------------------------------------------------------------------
Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223



More information about the Concurrency-interest mailing list