[Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations)

[Paolo Bonzini <pbonzini@redhat.com>]

Il 17/06/2013 20:57, Richard Henderson ha scritto:
>> + * And for the few ia64 lovers that exist, an atomic_mb_read is a ld.acq,
>> + * while an atomic_mb_set is a st.rel followed by a memory barrier.
> ...
>> + */
>> +#ifndef atomic_mb_read
>> +#if QEMU_GNUC_PREREQ(4, 8)
>> +#define atomic_mb_read(ptr)       ({             \
>> +    typeof(*ptr) _val;                           \
>> +    __atomic_load(ptr, &_val, __ATOMIC_SEQ_CST); \
>> +    _val;                                        \
>> +})
>> +#else
>> +#define atomic_mb_read(ptr)    ({           \
>> +    typeof(*ptr) _val = atomic_read(ptr);   \
>> +    smp_rmb();                              \
>> +    _val;                                   \
> 
> This latter definition is ACQUIRE not SEQ_CST (except for ia64).  Without
> load_acquire, one needs barriers before and after the atomic_read in order to
> implement SEQ_CST.

The store-load barrier between atomic_mb_set and atomic_mb_read are
provided by the atomic_mb_set.  The load-load barrier between two
atomic_mb_reads are provided by the first read.

> So again I have to ask, what semantics are you actually looking for here?

So, everything I found points to Java volatile being sequentially
consistent, though I'm still not sure why C11 suggests hwsync for load
seq-cst on POWER instead of lwsync.  Comparing the sequences that my
code (based on the JSR-133 cookbook) generate with the C11 suggestions
you get:

    Load seqcst               hwsync; ld; cmp; bc; isync
    Store seqcst              hwsync; st
    (source: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html)

    Load Java volatile        ld; lwsync
    Store Java volatile       lwsync; st; hwsync
    (source: http://g.oswego.edu/dl/jmm/cookbook.html)

where the lwsync in loads acts as a load-load barrier, while the one in
stores acts as load-store + store-store barrier.

Is the cookbook known to be wrong?

Or is Java volatile somewhere between acq_rel and seq_cst, as the last
paragraph of
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile
seems to suggest?

Paolo