Boost logo

Boost :

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-05-13 16:11:57


On 13/05/2021 15:27, André Almeida via Boost wrote:

> I'm the author of futex2[0], a WIP new set of Linux's syscalls that
> allows userspace to write efficient sync mechanisms. I would like to
> hear from Boost's developers if the project would benefit from this new
> interface.

Firstly, thanks for your work. I had already seen it on LKML. I'm
personally still fonder of how BSD implements wait queues, but futex2 is
a nice improvement on futex, so thanks!

> The detailed description of the API can be seen in the documentation
> patch[1]. Do you think that Boost would benefit from it?

To be honest, it's very much a case of "it depends" modulated by whether
adding more code to support newer Linux kernels is worth the added long
term maintenance costs, given the benefits to the average Boost user.

I'm very sure that in very specific use cases, futex2 is a large
benefit. However, because Boost must be portable, there is a certain
amount of needing to assume lowest common denominator. Boost.Thread is
an excellent example of this - works great on Windows XP, but because it
was written around XP, it would work a lot greater if rewritten around
Windows 10. But there isn't much incentive to rewrite it, given what
we've currently got is well understood, warts and all, and those who
need to will code around its limitations.

Another example is Boost.ASIO where one might think that if it used
io_uring instead of epoll() there might be significant gains. However,
benchmarks say no, epoll() is not a bottleneck almost all of the time.
I'd hazard a guess it will be similar with futex2, almost all of the
time in the ways Boost waits on the kernel, futex2 being many times
faster will only confer a small if any measurable gain to most Boost
code once measured from the top.

Others here will probably disagree with my assessment above. In any
case, they will agree with "patches adding support for futex2 are welcome".

Niall


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk