[concurrency-interest] Curious: How Java Memory Model is satisfied in JSR166 locks?
Compl Yue Still
complystill at gmail.com
Tue Aug 21 11:18:23 EDT 2007
Thanks much Dawid, this is the best answer I'd expected to hear!
However I'm still a little away from this happy conclusion, given your
suggested bullets from
* An unlock action on monitor m synchronizes-with all subsequent lock
actions on m (where subsequent is defined according to the
* A write to a volatile variable (§18.104.22.168) v synchronizes-with all
subsequent reads of v by any thread (where subsequent is defined
according to the synchronization order).
Where I understand that the order between actions is specific to a
monitor (of an object) or a volatile variable. But from JVM Spec 8.6 (
8.6 Rules About the Interaction of Locks and Variables
Let T be any thread, let V be any variable, and let L be any lock.
There are certain constraints on the operations performed by T with
respect to V and L:
* Between an assign operation by T on V and a subsequent unlock
operation by T on L, a store operation by T on V must intervene;
moreover, the write operation corresponding to that store must precede
the unlock operation, as seen by main memory. (Less formally: if a
thread is to perform an unlock operation on any lock, it must first
copy all assigned values in its working memory back out to main
* Between a lock operation by T on L and a subsequent use or store
operation by T on a variable V, an assign or load operation on V must
intervene; moreover, if it is a load operation, then the read
operation corresponding to that load must follow the lock operation,
as seen by main memory. (Less formally: a lock operation behaves as if
it flushes all variables from the thread's working memory, after which
the thread must either assign them itself or load copies anew from
Where I understand applies to all variables regardless their
associations with a lock.
So I still can't fully affirm that "_all_ changes made by A are visible
to B. (That is all memory, not just that one variable)." in case by
accessing a volatile variable. Am I wrongly interpreting those 2
bullets in JLS, or where is the problem in my understanding?
Oh, maybe fully memory synchronization upon volatile access is just a
guaranteed side-effect by Hostspot, so java.util.concurrent source are
not portable to other JVM implementations?
Thanks to Jason's reply, could you confirm whether the "memory
barrier" is specific to Hotspot or guaranteed for any JVM
Please inspire me :)
On 8/21/07, Dawid Kurzyniec <dawid.kurzyniec at gmail.com> wrote:
> On 8/21/07, Compl Yue Still <complystill at gmail.com> wrote:
> > 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?
> To extend upon Matthias' answer: Since Java 5.0, volatile has quite
> strong semantics, which is sufficient to implement memory
> synchronization as required by the spec you quote. Volatile write in
> thread A followed by a volatile read of the same variable in thread B
> is a memory synchronization point: _all_ changes made by A are visible
> to B. (That is all memory, not just that one variable). It is exactly
> the same memory behavior as Lock followed by Unlock. (Compare the
> first two bullets in
> Note that the above answers only the _memory_ synchronization
> question. If you wanted to implement your own full-blown exclusion
> locks without using synchronized keyword, AQS, or Unsafe, you would
> also need atomics (for resolving races) and LockSupport (for
> I think the Unsafe is a red-herring in the context of your question.
More information about the Concurrency-interest