From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58639 invoked by alias); 10 Nov 2016 17:08:53 -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 58625 invoked by uid 89); 10 Nov 2016 17:08:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=synchronize, falling, H*Ad:U*davem, HCc:D*net X-HELO: mx1.redhat.com Message-ID: <1478797727.7146.1013.camel@localhost.localdomain> Subject: Re: Remove sparcv8 support From: Torvald Riegel To: Chris Metcalf Cc: David Miller , carlos@redhat.com, adhemerval.zanella@linaro.org, andreas@gaisler.com, libc-alpha@sourceware.org, software@gaisler.com Date: Thu, 10 Nov 2016 17:08:00 -0000 In-Reply-To: <06d4798f-cf0b-fb29-04e5-daf9faadf46c@mellanox.com> References: <502720f6-3057-41f5-7832-4b219f5f729f@redhat.com> <20161107.113825.631166023186879199.davem@davemloft.net> <1478711295.7146.969.camel@localhost.localdomain> <20161109.121552.63825213147087515.davem@davemloft.net> <06d4798f-cf0b-fb29-04e5-daf9faadf46c@mellanox.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00405.txt.bz2 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 > > 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).