This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: __libc_single_threaded design (was: Re: libpthread removal project)
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Cc: nd <nd at arm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 7 Oct 2019 18:05:21 +0000
- Subject: Re: __libc_single_threaded design (was: Re: libpthread removal project)
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Taxm5eIFu9j3UkGZv68jiS7MQyp/ypR9HNpo6qAPG4A=; b=UwTJKKDb56/Zwkf/Tob5+0xHWJlcRxHjWp077KG9CK5j2h030ZIP9VYe0SETPYS4vrcrrNLHaIrR4KUKaOqiJeaSZcHIgQPbEAAv+qH4FwfKocWTNqNcemVQQTs+T9MK/Ny0pafP3kE84tXuYcpsXzZWGtj9NWFbNWTKX/cwmpVZgTQtBGJaBUOZWU9guvRDTWYSh7Vh6agjS79q9/KVcJUx6vcBfKsXfUPHLa8qFJntx6lqBpykiAwAiwc6xCxbTjSXe3mG/IbUi+n/I87RBL1pBM1Ki1Ify46ueM672NVeZmYMecd5qO3c7BNSWZGnM51n4tACYScDhLbdAWsciQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d1ZIrZcI86DaEDZT7WD1HfTM2iC6lHLlINUByQ7KIW5ZncP14dh5nkb82UK7UJf35IUAomkFcsK0yG4i+/ugPJuoU7F4tVPFGMlc2rb646F1OK0cq4+u11EUpV4xzbdmFKINJOegMsCi6s1WIxlQSM2H81DMWWyaC6WyBWU1usr7rYQ6lhijiCFAwQ3/CQCdfrO/1RQJZlbgSnmuhy+Dum5r+BLJKb5zZMhOT3WyMrBbfm0XlKMeJxX9EqKBFJMA1ffaLn/NMNq7vZM8RMjxIXPYUKxrkvj9531LNCOLM4QLTmXFOfz3XdQkAbwWz9DN4ylcD7FQiWFVxCtIZNEE3w==
- Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- References: <87eezsj0jb.fsf@oldenburg2.str.redhat.com> <a121002c-2f22-2b18-c1a5-771bce61002f@gotplt.org> <87k19gh3e5.fsf@oldenburg2.str.redhat.com> <905e820f-1603-ac16-4763-eea36ca9ecb3@gotplt.org> <87wodgfnki.fsf_-_@oldenburg2.str.redhat.com>
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.