This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] pthread support for FUTEX_WAIT_MULTIPLE
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Pierre-Loup A. Griffais" <pgriffais at valvesoftware dot com>
- Cc: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, "libc-alpha\@sourceware.org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Thu, 01 Aug 2019 11:39:15 +0200
- Subject: Re: [RFC] pthread support for FUTEX_WAIT_MULTIPLE
- References: <a56dd13f-910c-6ec2-648e-0a6fd46c1189@valvesoftware.com> <1606fc05-b2c0-92e9-07d5-a0b5fa766156@arm.com> <483d6398-8455-8022-0c36-dac69c5753aa@valvesoftware.com>
* Pierre-Loup A. Griffais:
> I would think there's still a queue somewhere to acquire jobs, this
> would be used before and after. For instance, job threads want to
> sleep until work has been queued, or another system event occurs that
> might require them to wake up, like app shutdown or scene
> transition. Similarly, after firing off N jobs, the job manager will
> want to sleep until one of the jobs is complete to perform some
> accounting and publish the results to other systems. For both of these
> usecases, using eventfd to wait for multiple events seems to result in
> more CPU spinning than the futex-based solution, both in userspace and
> the kernel.
Why do you consider eventfd the only viable alternative? If you want a
futex-based solution today, you can use condition variables. It won't
give you the theoretical minimum of context switches, but neither does
FUTEX_WAIT_MULTIPLE, as far as I can tell.
Thanks,
Florian