Re: Remove sparcv8 support

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2016-11-10 at 11:41 -0500, Chris Metcalf wrote:
> On 11/9/2016 12:15 PM, David Miller wrote:
> > From: Torvald Riegel <triegel@redhat.com>
> > Date: Wed, 09 Nov 2016 09:08:15 -0800
> >
> >> What approach are you going to use in the kernel to emulate the CAS if
> >> the hardware doesn't offer one?  If you are not stopping all threads,
> >> then there could be concurrent stores to the same memory location
> >> targeted by the CAS; to make such stores atomic wrt. the CAS, you would
> >> need to implement atomic stores in glibc to also use the kernel (eg, to
> >> do a CAS).
> > I keep hearing about this case, but as long as the CAS is atomic what
> > is the difference between the store being synchronized in some way
> > or not?
> >
> > I think the ordering allowed for gives the same set of legal results.
> >
> > In any possible case either the CAS "wins" or the async store "wins"
> > and that determines the final result written.  All combinations are
> > legal outcomes even with a hardware CAS implementation.
> 
> That's not actually true.  Suppose you have an initial zero value, and you race
> with a store of 2 and a kernel CAS from 0 to 1.  The legal output is only 2:
> either the store hit first and the CAS failed, or the CAS hit first and succeeded,
> then was overwritten by the 2.  But if the kernel CAS starts first and loads the
> zero, then the store hits and sets the value to 2, the CAS will still decide it was
> successful and write the 1, thus leaving the value illegally set to 1.

Looking at tile's atomic-machine.h files again, it seems we're not
actually enforcing that atomic stores are atomic wrt. the CAS
implementation in the kernel.
The default implementation for atomic_store_relaxed in include/atomic.h
does a plain memory store instead of falling back to exchange.  This is
the right approach by default, I think, because that's what
pre-C11-concurrency code in glibc does (ie, there's no abstraction for
an atomic store at all, and plain memory accesses are used).

However, if we emulate CAS with locks or such in the kernel, atomic
stores need to synchronize with the CAS.  This would mean that all archs
such as tile or sparc that do that have to define atomic_store_relaxed
to fix this (at least for code converted to using C11 atomics, all
nonconverted code might still do the wrong thing).