Date: Tue, 24 Aug 2021 09:32:17 -0700
On Tuesday, 24 August 2021 00:01:53 PDT Marko Mäkelä via Std-Proposals wrote:
> Good points. I thought that having this in the standard library would
> create more pressure to operating system developers to provide some
> futex-like functionality.
Linux, Windows and Darwin have it, though for Darwin it doesn't appear to be
documented. Your code has shown OpenBSD does too, something I didn't know.
FreeBSD definitely has it for its Linux-compatibility layer, but I don't know
if that has been exposed to the FreeBSD native ABI (just as eventfd hasn't).
I don't think the standard library can force that much. We'd end up with the
opposite: the futex functionality is emulated by way of locks. An example is
Linux itself: Linus is quite against extending the futex functionality to 64-
bit values, so std::atomic<int64_t>::wait will likely remain emulated on Linux
for a long time.
If this was your reason, please re-evaluate.
> Good points. I thought that having this in the standard library would
> create more pressure to operating system developers to provide some
> futex-like functionality.
Linux, Windows and Darwin have it, though for Darwin it doesn't appear to be
documented. Your code has shown OpenBSD does too, something I didn't know.
FreeBSD definitely has it for its Linux-compatibility layer, but I don't know
if that has been exposed to the FreeBSD native ABI (just as eventfd hasn't).
I don't think the standard library can force that much. We'd end up with the
opposite: the futex functionality is emulated by way of locks. An example is
Linux itself: Linus is quite against extending the futex functionality to 64-
bit values, so std::atomic<int64_t>::wait will likely remain emulated on Linux
for a long time.
If this was your reason, please re-evaluate.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2021-08-24 11:32:25