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