This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Transition to C11 atomics and memory model

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.


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;
  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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]