This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] nptl: Add pthread_thread_number_np function
- From: Florian Weimer <fweimer at redhat dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 15 Dec 2017 08:47:04 +0100
- Subject: Re: [PATCH] nptl: Add pthread_thread_number_np function
- Authentication-results: sourceware.org; auth=none
- References: <20171214185611.D08E1439942EA@oldenburg.str.redhat.com> <CA+=Sn1=3LF7DLHkM-ToTfrnYGXjg_HOYKTGPcN6kZnGySnHCFg@mail.gmail.com>
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