[PATCH] nptl: Add pthread_thread_number_np function

[Florian Weimer]

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