This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][RFC] Fix SPARC atomic_write_barrier.
- From: Torvald Riegel <triegel at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 31 Oct 2014 01:22:16 +0100
- Subject: Re: [PATCH][RFC] Fix SPARC atomic_write_barrier.
- Authentication-results: sourceware.org; auth=none
- References: <1414703220 dot 10085 dot 209 dot camel at triegel dot csb> <20141030 dot 190816 dot 1208675760538972795 dot davem at davemloft dot net>
On Thu, 2014-10-30 at 19:08 -0400, David Miller wrote:
> From: Torvald Riegel <triegel@redhat.com>
> Date: Thu, 30 Oct 2014 22:07:00 +0100
>
> > This patch changes SPARC write barriers to be just release barriers. I
> > haven't tested this, so this is based on my understanding of the SPARC
> > memory model (TSO).
>
> The sparc memory model is variable.
>
> It can be TSO, PSO, or RMO.
>
> It is controlled by a bit in the processor state register, and not
> all cpus support all memory models.
>
> Linux happens to run all threads in TSO currently, but this is not
> something GLIBC or any userland code should really depend upon.
>
> So we should use whatever memory barriers are necessary in the least
> strict memory model possible, which is RMO.
The patch doesn't rely on TSO. If you consider RMO, then it could be
considered a bug fix because LoadStore was missing from the release
barrier.
With "my understanding of the SPARC memory model" I was referring to the
assumption that on TSO, acquire and release barriers are no-ops,
effectively, because the reordering constraints that make up the
barriers are implicitly provided. And StoreLoad is not, but was part of
the release barrier, so this seemed to be a mistake.
Do you have an opinion on the actual patch, rather than my description?