Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware

[Torvald Riegel <triegel@redhat.com>]

On Tue, 2016-11-01 at 12:51 -0400, David Miller wrote:
> From: Torvald Riegel <triegel@redhat.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 <triegel@redhat.com>
> >> 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?