From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Carlos O'Donell <carlos@redhat.com>, Florian Weimer <fweimer@redhat.com>
Cc: nd <nd@arm.com>, "H.J. Lu" <hjl.tools@gmail.com>,
libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH] NUMA spinlock [BZ #23962]
Date: Thu, 10 Jan 2019 17:52:00 -0000 [thread overview]
Message-ID: <60bfc7d4-aa76-e5bf-1d1a-fd702d579128@arm.com> (raw)
In-Reply-To: <479415e1-3aba-b456-fc67-0614fbd462a1@redhat.com>
On 10/01/2019 16:41, 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.
>
in principle the pthread_spin_lock api can use this algorithm
assuming we can keep the pthread_spinlock_t abi and keep the
POSIX semantics. (presumably users ran into issues with the
existing posix api.. or how did this come up in the first place?)
next prev parent reply other threads:[~2019-01-10 17:52 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-26 9:51 Ma Ling
2019-01-03 4:05 ` 马凌(彦军)
[not found] ` <0a474516-b8c8-48cf-aeea-e57c77b78cbd.ling.ml@antfin.com>
2019-01-03 5:35 ` 转发:[PATCH] " 马凌(彦军)
2019-01-03 14:52 ` Szabolcs Nagy
2019-01-03 19:59 ` H.J. Lu
2019-01-05 12:34 ` [PATCH] " Carlos O'Donell
2019-01-05 16:36 ` H.J. Lu
2019-01-07 19:12 ` Florian Weimer
2019-01-07 19:49 ` H.J. Lu
2019-01-10 16:31 ` Carlos O'Donell
2019-01-10 16:32 ` Florian Weimer
2019-01-10 16:41 ` Carlos O'Donell
2019-01-10 17:52 ` Szabolcs Nagy [this message]
2019-01-10 19:24 ` Carlos O'Donell
2019-01-11 12:01 ` kemi
2019-01-14 22:45 ` Torvald Riegel
2019-01-15 9:32 ` Florian Weimer
2019-01-15 12:01 ` Torvald Riegel
2019-01-15 12:17 ` Florian Weimer
2019-01-15 12:31 ` Torvald Riegel
2019-01-11 16:24 ` H.J. Lu
2019-01-14 23:03 ` Torvald Riegel
2019-01-04 4:13 ` 转发:[PATCH] " 马凌(彦军)
2019-01-03 20:43 ` [PATCH] " Rich Felker
2019-01-03 20:55 ` H.J. Lu
2019-01-03 21:21 ` Rich Felker
2019-01-03 21:28 ` H.J. Lu
2019-01-14 23:18 ` Torvald Riegel
2019-01-15 2:33 ` kemi
2019-01-15 12:37 ` Torvald Riegel
2019-01-15 16:44 ` Rich Felker
2019-01-17 3:10 ` kemi
2019-02-04 17:23 ` Torvald Riegel
2019-01-14 22:40 ` Torvald Riegel
2019-01-14 23:26 ` Torvald Riegel
2019-01-15 4:47 ` 马凌(彦军)
2019-01-15 2:56 ` kemi
2019-01-15 4:27 ` 马凌(彦军)
2019-01-10 13:18 马凌(彦军)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60bfc7d4-aa76-e5bf-1d1a-fd702d579128@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).