From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3804 invoked by alias); 2 Nov 2016 10:05:29 -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 2963 invoked by uid 89); 2 Nov 2016 10:05:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=decades, Hx-languages-length:2275 X-HELO: mx1.redhat.com Message-ID: <1478081121.7146.673.camel@localhost.localdomain> Subject: Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware From: Torvald Riegel To: David Miller Cc: andreas@gaisler.com, libc-alpha@sourceware.org, adhemerval.zanella@linaro.org, carlos@redhat.com, software@gaisler.com Date: Wed, 02 Nov 2016 10:05:00 -0000 In-Reply-To: <20161101.125117.2228115672691137607.davem@davemloft.net> References: <1478015984.7146.645.camel@localhost.localdomain> <20161101.120933.844037675386229627.davem@davemloft.net> <1478018801.7146.655.camel@localhost.localdomain> <20161101.125117.2228115672691137607.davem@davemloft.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00051.txt.bz2 On Tue, 2016-11-01 at 12:51 -0400, David Miller wrote: > From: Torvald Riegel > Date: Tue, 01 Nov 2016 17:46:41 +0100 > > > On Tue, 2016-11-01 at 12:09 -0400, David Miller wrote: > >> From: Torvald Riegel > >> Date: Tue, 01 Nov 2016 16:59:44 +0100 > >> > >> > On Tue, 2016-11-01 at 16:07 +0100, Andreas Larsson wrote: > >> >> Any comments are most welcome. The spin lock based sparcv8 semaphore > >> >> implementation is currently unchanged by this patchset, but I would say > >> >> that that should go as well. > >> > > >> > Agreed. > >> > >> I think tossing out all of the ldstub based v8 code is not wise. > >> > >> I was envisioning adding code to use ldstub on v8 when CAS is not > >> available in order to maintain the status quo of what worked and > >> was functional before the changes which introduced this problem > >> for v8 in the first place. > >> > >> Having that in place until the kernel-side atomics could be > >> implemented, propagated, and supported in glibc would be a nice > >> intermediate state compared to what we have now. > > > > How do you intend to make the synchronization primitives work whose > > implementation requires a CAS and for which nobody has provided an > > alternative implementation that does not require CAS? > > The pure userland version will do what has been done for decades, > by using a spinlock that protects the word we want to do atomic > operations upon. A hash table of spinlocks is another option. I know about the available techniques; my question was rather aimed at who's going to do the work, in which rough stages, and when. An external table of locks does not work for process-shared synchronization. Do you plan to not support that, and abort() when someone tries to create a process-shared condvar, for example? Or do you intend to write sparc-specific versions of all the concurrent data structures that are process-shared? Note that in the new condvar, for example, there's no unused space in pthread_cond_t that could be used for a spinlock. So you'd have to reorganize quite a bit. If you want sparc-specific versions, who's going to implement them, and when? What do we do in the meantime?