Re: [sync] Optimizing Boost's sync using futex2

From: André Almeida (andrealmeid_at_[hidden])
Date: 2021-05-14 16:33:32

Às 13:11 de 13/05/21, Niall Douglas via Boost escreveu:
> 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.

Thanks Niall for your reply, it makes sense to me. Now it's more clear
for me how new kernel features are adopted in Boost and I assume that
this process is probably similar in others userspace libraries as well.

André