__libc_single_threaded design (was: Re: libpthread removal project)

[Florian Weimer <fweimer at redhat dot com>]

* Siddhesh Poyarekar:

> On 07/10/19 1:27 pm, Florian Weimer wrote:
>> This is what __libc_single_threaded is about.  It's a variable, not a
>> function, to avoid the function call overhead.
>
> Variable is fine too, but I suggest we publish it as a supported API and
> not an internal __libc_* detail.

Okay, let's change the subject of this subthread.

We need a name in the reserved space because the variable will be used
from libstdc++.

The name is easy to change.  I believe we have support in the link
editor so that linking to the public name also links against the private
name.  If everything else fails, we could also have two variables which
are updated at the same time.

>> As far as thread counts go, only the value 1 is special.  A general
>> thread count does not seem useful to me because it's not stable (for any
>> value above 1), and libraries do not know what the count means.  For
>> example, half of the threads could be parked on some rarely-occurring
>> condition, so for pretty much all practical purposes, they do not count.
>
> I'm thinking more about user applications and not just libraries; ideas
> like scaling/throttling of thread counts.

But an application can control how it calls pthread_create and maintain
the counter itself.  This kind of scheduling control is more in the
territory of libgomp and the hypethical execution agents library.  I
seriously doubt that a mere thread count is of any help at all.

Thanks,
Florian