[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