This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] NUMA spinlock [BZ #23962]


On 1/10/19 12:52 PM, Szabolcs Nagy wrote:
> 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?)
 
Correct, but meeting the ABI contract of the pthread_spinlck_t turns
out to be hard, there isn't much space. I've spoken with Kemi Wang 
(Intel) about this specific issue, and he has some ideas to share,
but I'll leave it for him to describe.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]