This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware
- From: Torvald Riegel <triegel at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: andreas at gaisler dot com, libc-alpha at sourceware dot org, adhemerval dot zanella at linaro dot org, carlos at redhat dot com, software at gaisler dot com
- Date: Wed, 02 Nov 2016 11:05:21 +0100
- Subject: Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Tue, 2016-11-01 at 12:51 -0400, David Miller wrote:
> From: Torvald Riegel <email@example.com>
> Date: Tue, 01 Nov 2016 17:46:41 +0100
> > On Tue, 2016-11-01 at 12:09 -0400, David Miller wrote:
> >> From: Torvald Riegel <firstname.lastname@example.org>
> >> 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?