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

Boehm, Hans hans.boehm at hp.com
Mon Oct 10 12:25:18 EDT 2011


My current operating hypothesis is that the C++ rules (with Java volatile = memory_order_seq_cst and lazySet = memory_order_release) specified in http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html should apply here.  Some of these are finally backed up by formal proofs.

The major complication is that for PowerPC and ARM, there are at least two different plausible conventions, and it's unclear to me that the "leading full fence" convention used here is the right one, especially for ARM.  And the two conventions don't play together.  It wouldn't surprise me if some of the mappings on ARM and PowerPC changed in the future and/or are currently inconsistent between C++ and Java.

Hans

> From: Doug Lea
> 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.
> 
> -Doug
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list