This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]