[concurrency-interest] AtomicXXX.lazySet and happens-before reasoning

Doug Lea dl at cs.oswego.edu
Mon Oct 10 09:12:58 EDT 2011

On 10/10/11 08:56, Vitaly Davidovich wrote:
> I agree that the way StoreLoad is implemented ensures that volatile reads of
>  different memory location don't move before the store, but I think the JMM
> only talks about needing this for loads of same memory location (see Doug's
> cookbook web page description).

Additionally, the "synchronization order" (roughly, any trace of
all volatile accesses) is required to be a total order, which
is the main constraint that forces the Dekker example to work.
This is not made clear enough in cookbook, which should be improved.

> By the way, would be great if someone from the Hotspot runtime/compiler team
> could shed some light on how Hotspot handles these, with the caveat that
> people shouldn't necessarily base their code on it if it makes stronger
> guarantees than the JMM :).

The main visible cases are processor- not JVM- based, and
most are only visible in giving you more consistency than required
for non-volatile accesses. In general, x86 and sparc are
stronger than POWER and ARM, with a few others
(Azul, IA64) in the middle.


More information about the Concurrency-interest mailing list