This is the mail archive of the libc-alpha@sourceware.org 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: __libc_single_threaded design (was: Re: libpthread removal project)


On 07/10/2019 18:54, Florian Weimer wrote:
> * 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.

__libc_single_threaded can be implemented such that
its value only changes when the application is
single threaded, which means normal non-atomic read
access is valid, it can be a plain _Bool or int
and it's 100% reliable when the read value is 1.

a thread count variable can change asynchronously
so users need atomic access, possibly requiring
libatomic to get linked in even if it's only used
for single-thread check, and if the value is >1
the meaning is unclear since it can change async.

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