Re: Remove sparcv8 support

[Torvald Riegel <triegel@redhat.com>]

On Wed, 2016-11-09 at 12:15 -0500, 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.

See this example, a is initially 0:

Thread 1:
atomic_store_relaxed (&a, 1);
r = atomic_load_relaxed (&a);

Thread 2:
exp = 0;
atomic_compare_exchange_weak_relaxed (&a, &exp, 2); // succeeds

r should never equal 2.  But if the CAS is not atomic wrt. the store by
Thread 1, then the CAS can load 0, then Thread 1's store comes in, and
then Thread 2's CAS stores 2 because it thought the value of a would be
the expected value of 0.

> I really don't think such asynchronous stores are legal, nor should
> the be explicitly accomodated in the CAS emulation support.  Either
> the value is maintained in an atomic manner, or it is not.  And if it
> is, updates must use CAS.

Yes, the implementation of atomic_store_* in glibc must use the CAS
emulation.  We do not care about plain stores because we consider them
data races in the context of the C11 model.  However, we still have
quite a few cases of plain stores that should be atomic stores in glibc;
so we might have a few problems until we've converted all of those.