Hi guys!

probably this one should be more a concurrency-interest question, but I'm 
sure that's will fit with most of the people around here as well :)
I was looking to how ReentrantLock and synchronized are different from a 
semantic point of view and I've found (there are no experimental proofs on 
my side TBH) something interesting on 
the http://gee.cs.oswego.edu/dl/jmm/cookbook.html. 
It seems to me that:

normal store;
monitorEnter;
[mutual exclusion zone]
monitorExit;
....

is rather different from a:

normal store;
(loop of...)
volatile load
volatile store (=== CAS)
---
[mutual exclusion zone]
volatile store

With the former to represent a synchronized block and the latter a spin 
lock acquisition and release, both with a normal store on top.
>From anyone coming from other worlds than the JVM i suppose that the 
volatile load could be translated as a load acquire, while the volatile 
store as a sequential consistent store.

About the monitorEnter/Exit that's more difficult to find something that 
fit other known memory models (C++) and that's the reason of my request :) 
>From the point of view of the compiler guarantees seems that a normal store 
(ie any store release as well) preceding monitorEnter could be moved inside 
the mutual exclusion zone (past the monitorEnter), because the compiler 
isn't enforcing 
any memory barrier between them, while with the current implementation of a 
j.u.c. lock that's can't happen.
That's the biggest difference I could spot on them, but I'm struggling to 
find anything (beside looking at the JVM source code) that observe/trigger 
such compiler re-ordering.
What do you think about this? I'm just worried of something that actually 
isn't implemented/isn't happening on any known JVM implementation?

Thanks,
Franz

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to