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/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