From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26265 invoked by alias); 26 Oct 2016 18:47:57 -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 26172 invoked by uid 89); 26 Oct 2016 18:47:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=bearing, Direct X-HELO: shards.monkeyblade.net Date: Wed, 26 Oct 2016 18:47:00 -0000 Message-Id: <20161026.144741.1659367414224835783.davem@davemloft.net> To: adhemerval.zanella@linaro.org Cc: andreas@gaisler.com, triegel@redhat.com, libc-alpha@sourceware.org, software@gaisler.com Subject: Re: Remove sparcv8 support From: David Miller In-Reply-To: <10b5e6a5-835d-8dc4-09c6-fc632e0736be@linaro.org> References: <5810C1A3.9030504@gaisler.com> <10b5e6a5-835d-8dc4-09c6-fc632e0736be@linaro.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00473.txt.bz2 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.