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

Dawid Kurzyniec dawid.kurzyniec at gmail.com
Tue Aug 21 10:04:44 EDT 2007

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 mailing list