FUTEX2 futex_waitv Wired Up For Other Architectures With Linux 5.16-rc3

[Developer12]

What about Alpha? The concept of a fast userspace mutex on a dead architecture from 2004 (at latest) that doesn't support multi-threading do anything for you?

Alpha at least had some minor sucess before being killed off by the itanic along with mips. Both DEC and SGI abandoned their RISC architectures for it and all it did was kill everything it touched. So much for intel's exit from the clusterfuck that is x86.

[F.Ultra]

What about Alpha? The concept of a fast userspace mutex on a dead architecture from 2004 (at latest) that doesn't support multi-threading do anything for you?

It gives the Completionist achievement.

[jeoshua]

I find the prospect of futex2 being available on the itanic downright hilarious.

What about Alpha? The concept of a fast userspace mutex on a dead architecture from 2004 (at latest) that doesn't support multi-threading do anything for you?

[Alex/AT]

Yup, these approaches are just different, and it's not like one is ahead of other, which is exactly the point, so I tend to agree there.

[oiaohm]

Do you mean that Windows is ahead of Linux (and it has been such for years) in this respect, and no Linux developer ever dreamed of having the same feature in Linux, but they kept struggling with standard futexes instead, and only now that some Windows-only game would benefit from this, then the Linux world wakes up and realizes how good this feature is?

Seems to me hard to believe, but I hope you prove me wrong.

https://lwn.net/Articles/811696/ This is one of those tricky ones. 95% of futex_waitv can be done by eventfd but the there are problems. Like eventfd consuming file handles and not ending best performance. Yes file handles being a limited resource on Linux using eventfd for a Linux designed program is not too bad because the file handle limitation is designed for. Windows wait for multi objects is not a limited resource. This leads to the wine problem of round peg square hole.

This is the problem Linux has had a close to the same feature as windows. Close enough people coding on Linux would mostly just code around the limitations to eventfd. Of course coding around the limitations means extra code so not the ideal performance at this point. Now windows programs under wine the application is not designed to expect limits in this area so you are stuffed.

Basically the primary original intent/aim of this new API is WinAPI emulation, so no, it's not 'ahead of', it's just such API is widely used under Windows and emulating it gives too much overhead when emulated other ways.

This is right and wrong. There have been decades of people attempting to improve eventfd and other items to handle the same problem better. Yes the developers work on futex_waitv come from wine but this is not the first time attempting to solve the problem this is just the most recent. eventfd can implement a 95 percent feature match. Problem is that 5%.

Yes those coding on Linux/Unix and BSD are use to the 5% missing. The reason funding the development of futex_waitv has been WinAPi emulation. The reasons of those reviewing the patches of futex_waitv for mainline are not all wine related. There have been a few changes to futex_waitv particularly for non wine use cases.

There has very much been we have a hammer so everything looks like nail. Yes eventfd and the other bits in the Linux kernel have been like using a hammer to drive in a screw (yes it does work as long as it lots and lots of taps) instead of using a screwdriver. Yes using a hammer to drive in screw does not end up with the best result in time either. So its not that the feature has been absolutely missing to Linux. Just the way Linux allowed doing the feature has horrible. Yes the horrible comes from the way Unix expect you to implement the feature remember the "everything is a file rule" of the Unix world (more guideline for how often in posix standard this is straight up broken). Futex break the everything is a file rule using a memory location.

Now windows with "everything is a object" rule means for particular problem is the screw driver. Do remember something here screwdriver yes just like a screw driver the windows idea when you have to drive in nails you are in trouble same is true with "everything is a object".

Yes this is why hammer and screwdriver is good examples here. Everything as a file and everything as a object both have their strict limitations. The ideal solution is going to be some middle ground between both ideas.

Also another thing to remember part of the reason for wine wanting to move to eventd and other items originally was to attempt to remove the need when using libwine of having to have wineserver. Wine goals don't just include emulation the project includes cross building its really simple to forget the winegcc bits.

wine="wine is not emulator" wine is not just an emulator is more correct. Its good to remember it this is a good way to remember when you use the word "emulation"/"emulator" with wine to explain why some change is being caused by wine that most of the time you will be missing half to all the picture of why something is happening.

Reduced dependence on wineserver is something long term futex_waitv will cause in wine and that a change for native building and emulation of windows binaries.

[microcode]

Oh they are already at it with copying io_uring https://twitter.com/axboe/status/1396837335141134336 and lets not forget that they copied FUTEX from Linux some 10 years later (and patented it).

Oh lol, I guess I was right about what would happen, after it happened. Anyway, strengthens my point that there is still a lot of improvement to go around, and each popular userspace environment has some strengths to learn from.

[Alex/AT]

Do you mean that Windows is ahead of Linux (and it has been such for years) in this respect, and no Linux developer ever dreamed of having the same feature in Linux, but they kept struggling with standard futexes instead, and only now that some Windows-only game would benefit from this, then the Linux world wakes up and realizes how good this feature is?

Seems to me hard to believe, but I hope you prove me wrong.

Basically the primary original intent/aim of this new API is WinAPI emulation, so no, it's not 'ahead of', it's just such API is widely used under Windows and emulating it gives too much overhead when emulated other ways.

[Alex/AT]

Hey; believe it or not there is still a significant install base of Itanium machines running fresh Linux, and many of them are doing pretty important work.

Meaning gaming which futex2 is basically for?

[F.Ultra]

But what about on RISC-V?

Unsure how it works but a quick glance at the risc-v code makes it look like it uses the generic syscall interface so it got it back when futex2 was added the first time.

[F.Ultra]

I mean, there's lots of stuff like this out there. Linux has inotify, which is way better in most practical situations than the equivalents on FreeBSD, macOS, and Windows. OpenBSD had the best random number facilities for years before they were copied. Copying good ideas is an ongoing process, WaitForMultipleObjects happens to be a good idea, probably IO_URING will get copied too..

Oh they are already at it with copying io_uring https://twitter.com/axboe/status/1396837335141134336 and lets not forget that they copied FUTEX from Linux some 10 years later (and patented it).