This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Transition to C11 atomics and memory model
- From: Torvald Riegel <triegel at redhat dot com>
- To: GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: David Miller <davem at davemloft dot net>
- Date: Wed, 17 Sep 2014 16:53:59 +0200
- Subject: Re: Transition to C11 atomics and memory model
- Authentication-results: sourceware.org; auth=none
- References: <1410719669 dot 4967 dot 160 dot camel at triegel dot csb> <1410904080 dot 4967 dot 400 dot camel at triegel dot csb>
On Tue, 2014-09-16 at 23:48 +0200, Torvald Riegel wrote:
> sparc32 v9 ???:
> * Custom asm for CAS, exchange. 32b.
> * Full membar defined.
> * Read membar defined. I guess this would work as a
> memory_order_acquire barrier (or C11 fence).
> * Write membar defined. This does not seem to implement a
> memory_order_release barrier if I interpret the SPARC asm correctly, but
> rather be like a more traditional "don't reorder the preceding write
> with anything else" barrier; it issues a StoreLoad and StoreStore
> barrier, but if used as memory_order_release, it will be followed by an
> atomic store, so I guess it should be LoadStore and StoreStore? I
> haven't checked what GCC generates, so I'm not sure.
Dave,
on SPARC the membars are currently defined as:
#define atomic_full_barrier() \
__asm __volatile ("membar #LoadLoad | #LoadStore" \
" | #StoreLoad | #StoreStore" : : : "memory")
#define atomic_read_barrier() \
__asm __volatile ("membar #LoadLoad | #LoadStore" : : : "memory")
#define atomic_write_barrier() \
__asm __volatile ("membar #StoreLoad | #StoreStore" : : : "memory")
>From what I can see in uses of atomic_write_barrier and in how it's
implemented on other archs, this is intended to be similar to
memory_order_release. Throughout glibc, it's often used like this:
x = foo;
y = bar;
atomic_write_barrier;
flag = 1; // or pointer initialization
So we'd want to prevent reordering of stuff prior to the membar with the
store to flag becoming visible. This would mean -- if I interpret SPARC
asm correctly -- to have a #LoadStore | #StoreStore membar. This would
align with SPARC being TSO, so not needing an actual HW membar for
release or acquire (same as x86). However, atomic_write_barrier
currently includes #StoreLoad, which should make it a full barrier.
This is correct, but stronger than necessary.
Am I missing something, is this intended to be a full barrier, or just
an oversight?