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
On 12/21/2017 08:19 PM, Carlos O'Donell wrote:
On 12/21/2017 03:03 AM, Florian Weimer wrote:
On 12/21/2017 10:26 AM, Carlos O'Donell wrote:
+The returned number is only unique with regards to the current process.
+It may be shared by subprocesses and other processes in the system.
+
+The initial (main) thread has number 1. Thread numbers are not
+necessarily assigned in a consecutive fashion. They bear no
+relationship to POSIX thread IDs (@code{pthread_t} values), process IDs
+or thread IDs assigned by the kernel.
I would like us to add something like this:
~~~
While the return type of this function is only 64-bits wide, the intent
is not to impose an artificial limit on the number of threads that can be
created by the runtime. In the future this interface may be extended
to 128-bits to support creating as many threads as a user may need
for the lifetime of the process.
~~~
That way the intent of the interface and future changes are clear.
So how would a programmer use this interface in a future-proof way?
I think such a statement would raise more questions than it answers.
I went to bed thinking much the same thing and worried that perhaps this
text was not appropriate for the manual, but could serve as a comment in
the source code for future maintainers. Since this is really a question
about GNU ethos and avoiding artificial limits.
Would you be opposed to adding the comment to the new function sources?
What about this?
/* This function should ideally return an integer wider than uint64_t,
so that the thread number can never-ever overflow. We may have to
switch to a 128-bit return value for new architectures
(particularly if those provide atomic operations on 128-bit
integers). But with current architectures, the baked-in limit of
2**64 threads ever created by a process is not a problem because
architectural constraints result in a thread creation rate far
below one billion threads per second, and even at that rate, a
64-bit counter lasts for hundreds of years. */
People start relying on this counter incrementing from 1 upwards.
People start using this monotonic property for indexing.
Soon we can't change it because it's implied API behaviour.
I think we should disabuse them from doing something low cost to roll the value:
* Do nothing for thread 1, leaving it 1.
* Check global_thread_number for overflow instead.
* Pick a random number of bits to roll between 0-63 (picked at process startup)
* Roll the value by some that number of bits.
* Use the rolled value as the thread_number
Not sure if I understand this. Do you want us to start at a random
value? Or assign IDs randomly? The latter will have a collision
much sooner.
I can switch the thread numbers to a fixed, but random-looking
permutation of the integers in [0, 2**64), but this looks excessive.
I want a low cost solution that avoids abuses of the interface for
indexing into arrays, or other issues that would break when we change
this in the future. We do not want users to make assumptions about the
values we hand out.
But the result will be that the numbers are no longer short and easily
compared for logging/debugging purposes. I think the value of that is
higher than trying to punish developers who do not read the manual.
Thanks,
Florian