[PATCH] NUMA spinlock [BZ #23962]

[Torvald Riegel]

On Tue, 2019-01-15 at 10:32 +0100, Florian Weimer wrote:
> * Torvald Riegel:
> 
> > On Thu, 2019-01-10 at 11:41 -0500, Carlos O'Donell wrote:
> > > On 1/10/19 11:32 AM, Florian Weimer wrote:
> > > > * Carlos O'Donell:
> > > > 
> > > > > My opinion is that for the health and evolution of a NUMA-aware spinlock
> > > > > and MCS lock, that we should create a distinct project and library that
> > > > > should have those locks, and then work to put them into downstream
> > > > > distributions. This will support key users being able to use supported
> > > > > versions of those libraries, and give the needed feedback about the API
> > > > > and the performance. It may take 1-2 years to get that feedback and every
> > > > > piece of feedback will improve the final API/ABI we put into glibc or
> > > > > even into the next ISO C standard as pat of the C thread interface.
> > > > 
> > > > I think it's something taht could land in tbb, for which many
> > > > distributions already have mechanisms to ship updated versions after a
> > > > release.
> > > 
> > > Absolutely. That's a great idea.
> > > 
> > 
> > I don't think tbb is a useful vehicle.  It would require that many
> > applications use the tbb mutexes, which I doubt is the case.
> 
> That doesn't really matter because it's a new API anyway.

What I mean is that applications would have to want to use locks provided
by tbb, whether those are locks/mutexes that exist in tbb today or a new
API that would be added.

Put differently, I'm not optimistic about tbb being a good way to get
feedback.