This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] NUMA spinlock [BZ #23962]
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.