[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a
From: |
Paolo Bonzini |
Subject: |
[Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations) |
Date: |
Tue, 18 Jun 2013 15:24:24 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
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
- [Qemu-devel] [PATCH v2 0/2] make AioContext's bh re-entrant, Liu Ping Fan, 2013/06/16
- [Qemu-devel] [PATCH v2 1/2] add a header file for atomic operations, Liu Ping Fan, 2013/06/16
- [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations),
Paolo Bonzini <=
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Paul E. McKenney, 2013/06/18
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Paolo Bonzini, 2013/06/18
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Torvald Riegel, 2013/06/18
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Paul E. McKenney, 2013/06/18
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Paolo Bonzini, 2013/06/19
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Torvald Riegel, 2013/06/19
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Paolo Bonzini, 2013/06/19
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Torvald Riegel, 2013/06/19
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Paolo Bonzini, 2013/06/20
- Re: [Qemu-devel] Java volatile vs. C11 seq_cst (was Re: [PATCH v2 1/2] add a header file for atomic operations), Torvald Riegel, 2013/06/22