From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119194 invoked by alias); 26 Oct 2016 19:39:41 -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 119182 invoked by uid 89); 26 Oct 2016 19:39:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1944, bearing X-HELO: mail-ua0-f178.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0wrgg2mtG/TbbZxyiriYUp7UHK1zyVfGlVI+UthGYGQ=; b=i5blWzGKhM7TWEI5eb6SXjfLmhwLDdyIWIhDkWi6XvyNLZiMoj0lTS7q7ZFOnkrM0I iYYEu7pGehsKb2inCSsiNNG/vHPMuNHzuKCt/ckx8Ma4XoVu8ePvBaGYpUdzZZNQrB4s A9IKW0u5/8/tTmrs04JQJMeRYdLnmyhGqWIlLjqhVPTT/dvC9vM6TFa/yIDSo083THMB T6jcijX2HiGlLc2Sp1OmFUj2QmlvcC2tUQIHAN74XsYlqcclrphaZ2YzhhF8N8dkqM6O pDBb9QERBuHlKfWmO2jB1dDS4BRrOtMfFSRC6CJzBJfTGbYhQQjiF/UvqzC/AvIqxqg7 +swA== X-Gm-Message-State: ABUngveVkeOFiRZl3Q3VRkH5uaOqqZ/HaIok7EaOgI8e9Bsw4y2KyO79dtCOCbxb1krnixeL X-Received: by 10.176.3.136 with SMTP id 8mr2507617uau.73.1477510769027; Wed, 26 Oct 2016 12:39:29 -0700 (PDT) Subject: Re: Remove sparcv8 support To: David Miller References: <5810C1A3.9030504@gaisler.com> <10b5e6a5-835d-8dc4-09c6-fc632e0736be@linaro.org> <20161026.144741.1659367414224835783.davem@davemloft.net> Cc: andreas@gaisler.com, triegel@redhat.com, libc-alpha@sourceware.org, software@gaisler.com From: Adhemerval Zanella Message-ID: Date: Wed, 26 Oct 2016 19:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161026.144741.1659367414224835783.davem@davemloft.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00474.txt.bz2 On 26/10/2016 16:47, 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. And neither it is the idea for current glibc concurrency as described in the wiki [1]. Since the idea is using C11 atomic memory model and semantic, plain store on atomic variables is not supported. What I would expect is for sparc to have semantically correct atomic_{load,store}_* operation, either with custom implementation or even based on supported CAS operation. [1] https://sourceware.org/glibc/wiki/Concurrency