From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9076 invoked by alias); 27 Oct 2016 10:54:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 9055 invoked by uid 89); 27 Oct 2016 10:53:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 spammy=Hx-languages-length:2777, upfront, non-atomic, adhemerval.zanella@linaro.org X-HELO: mx1.redhat.com Message-ID: <1477565575.7146.199.camel@localhost.localdomain> Subject: Re: Remove sparcv8 support From: Torvald Riegel To: David Miller Cc: adhemerval.zanella@linaro.org, andreas@gaisler.com, libc-alpha@sourceware.org, software@gaisler.com Date: Thu, 27 Oct 2016 10:54:00 -0000 In-Reply-To: <20161026.144741.1659367414224835783.davem@davemloft.net> References: <5810C1A3.9030504@gaisler.com> <10b5e6a5-835d-8dc4-09c6-fc632e0736be@linaro.org> <20161026.144741.1659367414224835783.davem@davemloft.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00486.txt.bz2 On Wed, 2016-10-26 at 14:47 -0400, David Miller wrote: > From: Adhemerval Zanella > Date: Wed, 26 Oct 2016 16:02:50 -0200 > > >> I am not sure it is as simple as that. Even if the kernel makes sure > >> that an emulated CAS is atomic against another emulated CAS, it would > >> not guarantee atomicity against a plain store instruction on a different > >> CPU, right? For the emulated CAS to work on an SMP system I would think > >> the atomic_store_relaxed and atomic_store_release functions would also > >> need to be handled by the kernel, locking the write out when the CAS is > >> emulated, to keep the interaction linearizable. > >> > > > > I would expect kernel to emulate all the define atomic operation defined > > in ISA to provide correct atomic semantic. I am not really sure how > > feasible it would be, but the idea is from library standpoint running > > on a machine with a emulated atomic provided by kernel is semantic > > equal to running on a machine with hardware provided atomic. > > > > And I think it would be not feasible to keep pushing for C11 atomics > > on glibc if we can not guarantee it. > > Plain stores would semantically not be allowed on such a shared value > anyways. > > If atomicity is required, then nobody should do direct stores. Direct > stores are unchecked and non-atomic. Whether the kernel implements > the CAS or the cpu does it directly has no bearing on this issue. > > All entities should always use the CAS operation to modify such values. I'm not quite sure what you're trying to say, so I'll make a few general comments that will hopefully help clarify. It is true that we do want to use the C11 memory model throughout glibc, which means a data-race-freedom requirement for glibc code, which in turn means having to use atomic operations (ie, atomic_* ()) whenever there would be a data race (as defined by C11) otherwise. The implementation of atomic_*() in glibc is an exception to that rule, in that on some systems we may know that in a controlled environment (eg, function not inlined or volatile used), the compiler will generate code for a plain store/load in the implementation of an atomic_*() function that is equivalent to a relaxed MO atomic store/load (including effects of fences). This makes concurrent relaxed MO loads/stores work. If we also have a non-multi-core system, entering the kernel emulation for CAS then stops all other execution on the system, so the CAS emulation in the kernel is atomic. If instead we have a multi-core system, either the kernel would have to temporarily stop all other cores while emulating the CAS, or all atomic_*() would have to use the kernel. Which of these two options is better is hard to say upfront.