[PATCH] nptl: Add pthread_thread_number_np function
Florian Weimer
fweimer@redhat.com
Fri Dec 15 07:47:00 GMT 2017
On 12/15/2017 01:29 AM, Andrew Pinski wrote:
> Why can't you just make global_thread_number do an atomic addition
> instead of the lock here? It will be slightly faster.
Not sure about that. In the common case (no stack size specified) we
already acquire a lock. So we'd have to perform three atomic operations
instead of two if we don't reuse the lock.
There's also the problem of 32-bit architectures without 64-bit atomic
operations.
> But I notice
> you don't handle the case where you create and destroy over 2^64-1
> threads (that is an overflow of global_thread_number).
Yes, I should add a sanity check and an abort for this case.
> You don't even mention this limitation any where.
Traditionally, we have been ignoring 64-bit counter overflows, treating
them as impossible. For a simple counter with no countermeasures
against contention, I really don't see how the overflow can happen any
time soon.
Thanks,
Florian
More information about the Libc-alpha
mailing list