[PATCH] nptl: Add pthread_thread_number_np function

[Florian Weimer]

On 12/20/2017 09:06 AM, Carlos O'Donell wrote:

> If by "random bit generators" we are talking about arc4random, we could
> add this as an internal interface for direct use by arc4random? That
> wouldn't be a problem. I would not want this review to block arc4random.

I need to split the patch into manageable pieces anyway.

> One can create and destroy an infinite number of condition variables.

That's true.  But you cannot perform an arbitrary number of operations 
on a single condition variable.  Eventually, the sequence counter will 
overflow.  Which is why I think the comparison is still valid, as far as 
the implementation is concerned.

> The design of the pthread_thread_number_np API immediately limits the
> number of creatable threads to the size of the return type. If we allow
> creating more threads than that then we break the API.

> My objection is not with the internal implementation of a 64-bit counter.
> 
> My objection is to the external exposing of a limit on number of threads.

Well, the counterargument is that 2**64 is so large that by the time we 
have such machines which create as many threads within the life-time of 
a single process, we will have a new ABI (for off128_t) and can switch 
the return value to uint128_t.

The problem is that the 128-bit number actually *reduces* the usefulness 
of this interface because you cannot assume that a register-wide number 
confers uniqueness.  So using uint64_t here may not be entirely 
future-proof, but it will be good enough for currently-existing machines.

Current hardware can do around 200 million shared counter increments per 
second.  And that's just the counter, with single-threaded atomic 
increments.  As soon as multiple threads are involved, the performance 
drops.  Even if we assume a hundred-fold speed increase for the 
single-threaded case, we still end up with thirty years of run time 
until the wraparound happens.

I started to implement an alternative with two 64-bit counters in them, 
but to be honest, I don't think this interface has much value.

> The implementation can have an internal 64-bit limit, that's fine, but the
> external interface would then support an unlimited number of threads.
> 
> We can even provide a convenience function to turn the opaque value into
> an ASCII string, and such an implementation can just print a 64-bit value
> to the string buffer.
> 
> Would such an interface be truly terrible?

It would be pretty much useless for anything but logging.  Random bit 
stream generators typically need a fixed-size personalization string, 
and concurrency algorithms really need a register-sized thread number.

>> Lazy allocation would make the function not safe for use in signal handlers.
> 
> Are you going to mark this function as AS-safe in the documentation?
> 
> Yes, you used '@assafe{}' in the manual, OK.
> 
> Note that your '@acsafe{}' markup in the manual is wrong, since this function
> holds locks and is therefore not AS-safe.

The actual function doesn't use locking.  The only locking occurs during 
thread creation.

Thanks,
Florian