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