This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove sparcv8 support
- From: David Miller <davem at davemloft dot net>
- To: triegel at redhat dot com
- Cc: carlos at redhat dot com, adhemerval dot zanella at linaro dot org, andreas at gaisler dot com, libc-alpha at sourceware dot org, software at gaisler dot com
- Date: Wed, 09 Nov 2016 12:15:52 -0500 (EST)
- Subject: Re: Remove sparcv8 support
- Authentication-results: sourceware.org; auth=none
- References: <502720f6-3057-41f5-7832-4b219f5f729f@redhat.com> <20161107.113825.631166023186879199.davem@davemloft.net> <1478711295.7146.969.camel@localhost.localdomain>
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.
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. Straight stores are only legal on the
initialization of the word before any CAS code paths can get to the
value.
I cannot think of any sane setup that can allow async stores
intermixed with CAS updates.