From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81857 invoked by alias); 10 Nov 2016 05:05:36 -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 81837 invoked by uid 89); 10 Nov 2016 05:05:34 -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=outcomes, wins, U*triegel, accomodated X-HELO: mx1.redhat.com Message-ID: <1478754319.7146.983.camel@localhost.localdomain> Subject: Re: Remove sparcv8 support From: Torvald Riegel To: David Miller Cc: carlos@redhat.com, adhemerval.zanella@linaro.org, andreas@gaisler.com, libc-alpha@sourceware.org, software@gaisler.com Date: Thu, 10 Nov 2016 05:05:00 -0000 In-Reply-To: <20161109.121552.63825213147087515.davem@davemloft.net> 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00372.txt.bz2 On Wed, 2016-11-09 at 12:15 -0500, 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. 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.