Date: Mon, 25 Jul 2022 10:29:12 -0700
On Sunday, 24 July 2022 21:37:46 PDT Ryan Nicholl via Std-Discussion wrote:
> Linux cannot implement wait correctly on 64 bit values without futex waitv
> which is a pretty recent add-on, but I think libatomic authors will find a
> workaround (I assume), though it might be slightly slower, such as a global
> lock?
The initial version of futex_waitv does not add support for other sizes
besides 32-bit. So even 5.19 will not yet support any size besides 32-bit.
That means atomic waits of any size other than 32-bit will be worse because,
as you'd expect, they need extra application overhead to make work. It's not
as bad as what you're assuming: it's not a global lock. libstdc++ implements
it via a pool of ints that are hashed by your atomic's address.
And since this is all inline code, because it's not using waiting via futex on
your actual atomic, it cannot be changed to use to futex_waitv even when that
becomes supported.
> Linux cannot implement wait correctly on 64 bit values without futex waitv
> which is a pretty recent add-on, but I think libatomic authors will find a
> workaround (I assume), though it might be slightly slower, such as a global
> lock?
The initial version of futex_waitv does not add support for other sizes
besides 32-bit. So even 5.19 will not yet support any size besides 32-bit.
That means atomic waits of any size other than 32-bit will be worse because,
as you'd expect, they need extra application overhead to make work. It's not
as bad as what you're assuming: it's not a global lock. libstdc++ implements
it via a pool of ints that are hashed by your atomic's address.
And since this is all inline code, because it's not using waiting via futex on
your actual atomic, it cannot be changed to use to futex_waitv even when that
becomes supported.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2022-07-25 17:29:14