[concurrency-interest] AtomicXXX.lazySet and happens-before reasoning
vitalyd at gmail.com
Mon Oct 10 09:20:03 EDT 2011
I'm aware that the type of instruction and whether a fence is a no-op is
arch specific, but I was curious how the compilers (c1/c2) make decisions
around these things, such as if they track pairs of read/write of same
volatile across method bounds ( I believe they don't at the moment).
On Oct 10, 2011 9:14 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:
> On 10/10/11 08:56, Vitaly Davidovich wrote:
>> I agree that the way StoreLoad is implemented ensures that volatile reads
>> different memory location don't move before the store, but I think the
>> only talks about needing this for loads of same memory location (see
>> 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
>> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest